OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Prelim minutes of wsrx TC 11/17/2005


Prelim minutes are attached.
Please provide corrections to the list by next Monday.

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Preliminary Minutes WSRX TC Teleconf

Preliminary Minutes  WSRX TC Teleconf

 Nov 17, 2005 –

Date:  Thursday, 17 November 2005

Time:  01:00pm - 02:30pm PT

Tom Rutt agreed to take the minutes.

1         Roll Call

From Kavi,

 

 

Meeting is  Quorate

2         Review and approve of Agenda

1) Roll Call

2) Minute taker

3) Review and approval of the agenda

4) Approval of the previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15349/MinutesWSRX-111005.htm

5) Editorial report

a) timetable for restructured RM document?

b) timetable for an Editor's draft before Dec F2F meeting

6) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

7) New issues since last conf-call

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00177.html

8) Issue Discussion:

i065 Matt Lovett - Reword Closing a sequence section

i061 Dug Davis - Anonymous AcksTo

054 Umit Yalcinalp Target of RM Assertion parameters are confusing with respect to how they are specified

i055 Marc Goodner Whose Inactivity Timeout is it anyway?

i056 Chris Ferris How can RMS communicate the Base Retransmission Interval, Exponential Backoff and Inactivity Timeout values?

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056

i066 Remove LastMessage

i050 Marc Goodner spec talks about delivery assurances but does not clearly relate them to the protocol

i021 Policy applies two-way

9) Any other business

 

 

Steve W: move issue 61 to next call.  No objections

 

Tom Rutt: we should not finalize issue 50 today, since it depends on 49.

 

Paul F: I would like to have discussion of Issue 50 today, although we will not finalize it today.

 

4) Approval of the previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15349/MinutesWSRX-111005.htm

 

Paul Cotton moved, Tom Rutt seconded to approve 11/10 minutes

 

§    Minutes of 11/10 approved.

 

 

5) Editorial report

a) timetable for restructured RM document?

 

b) timetable for an Editor's draft before Dec F2F meeting

 

 

Umit: There will be a new working draft by Dec 1. 

 

Paul F: what about the restructured draft with a diff from the last CD.

 

Paul C: what if we reject the restructured draft.  This will avoid risk.  We can approve the restructure before new items.

 

Doug D: the restructured draft should be out there soon. 

 

Paul C: there is no meeting next week, due to Turkey day.

 

Paul C: we will see restructured draft soon, with a new draft diffed against restructured draft in time for F2F.

 

Umit: that is the plan.  With changes from the last time we had a draft out.  I was hoping to have that by Dec 1.

 

Paul F: I do not remember a need for a vote on the restructured doc.  I though its purpose was to be a basis for future diffs showing technical changes.  We need to review it asap, and discuss on the email list before thanksgiving.  The editors should have a restructured draft available before this weekend.  If there are issues with it we can do an electronic vote.  Any nits can be fixed by the end of that week.

 

Doug D: lets put out the current wd with just restructuring before end of fhis week.  If there are problems with the restructuring new issues can be raised..

 

Paul C: I am concerned about having sufficient time for review.

 

Doug D: there is no due date for there will be no vote.

 

Doug B: I do not think we should assume there will not be a need for a vote.  There is a possibility of dispute, which may have to be resolved by a vote.

 

 

 

6) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

 

Action - a

Stefan – no change

 

Action - b

Bridge for Sunnyvale f2f – Jacques how many people,  Paul F: 20.  Action assigned to Jacques, and kept open.

 

Action c gill

No change, left open

 

Action D: second definition of received

No progress , left open

 

7) New issues since last conf-call

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00177.html

 

Title: Case of multiple RM Policies and DAs within an RMD scope

 

 

 

Description: As the 1-1 relationnship between RMD and port (or RMD-WSDL) is no longer required (i010 allows RMS and RMD to span several endpoints) the specification needs be clearer on how RM Policies apply, as an RMD will handle messages and sequences that are subject to different RM policies - meaning protocol parameters as well as DAs.

 

 

 

 

 

Justification: RM policy parameters are so far attached to the endpoint, while they actually concern the RMD behavior, and this may cause an issue if one RMD serves several ports with different policy parameters. Regarding DAs, same 1-n issue: an RMD must be able to handle messages according to different DAs. While the DA to be enforced on a message can be resolved separately from protocol concerns (e.g. based on endpoint info), that would require looking at extra headers if this RMD is deployed as an intermediary. Also that would not work if DAs are to be attached at a finer granularity

 

than endpoint (e.g. message or operation).

 

 

Target: all

 

 

Type: design

 

 

 

Proposal:

 

Associate more explicitly policies (and DAs) with sequences, e.g. either in CreateSequence, or CreateSequenceResponse, so that an RMD can apply different policies to different sequences just based on sequence ID.

 

 

§    No objection to accepting as new issue, Umit took ownership.

 

8) Issue Discussion:

 

i065 Matt Lovett - Reword Closing a sequence section

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i065

 

Proposal

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00172.html

 

Doug D moved to accept proposal for Issue 65, Paul C seconded.

 

§    No objections, issue 65 closed with proposed change.

---------------------------------

 

054 Umit Yalcinalp Target of RM Assertion parameters are confusing with respect to how they are specified

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i054

 

Proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00023.html

Proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00131.html

 

Umit gave an overview of the three proposals:

Proposal 1 2005-10-18

Clarify and explicitly state in the specification that each role manages its own parameters. Update the example to include in the WSDL only the parameters that are applicable to RMD: IT and AI. In addition, clarify whether the parameters that apply to RMS may be used within the content of RM Assertions and when.

 

Proposal 2 2005-11-02

See message

 

As indicated for the proposal for resolving i022 [1], we favor retaining InactivityTimeout and AcknowledgementInterval in the WS-RM Policy specification.

 

If we retain these two parameters, we think that the values that are specified in the policy document are applied to RMD only to resolve i054[2]. The attachment of values apply to the endpoint/binding hence they should pertain to RMD.

 

Note that we acknowledge that RMS may also have an InactivityTimeout which may be internal to the RMS, but it is not specified in the policy document. As far as the Policy Attachment is concerned, we would like to see Inactivity Timeout (as well as Acknowledgement Interval) to apply to RMD configuration. This is basically a variation of proposal 1 in the original issue posting.

 

Proposal 3 2005-11-08

 

See message, line numbers refer to wsrmp-1.1-spec-cd-01.

 

Change lines 148-149 from:

 

"The assertion defines an inactivity timeout parameter that either the RM Source or RM Destination MAY include."

 

To:

 

"The assertion defines an inactivity timeout parameter that the RM Destination MAY include."

 

 

Jacques: I have a minor suggested improvement, instead of a single rm assertions, give two assertions, one for RMS and other for RMD.

 

Paul F: some of the other issues may have solutions which would supplant these proposals.

 

Gil: I wonder if we want to actually specify these base transmission and backoff  intervals.

 

Umit: these are gone, all we have on table is IT and Ack Interval.  Ack interval is only for RMD.  The question is on Inactivity Timeout.

 

Umit moved that message 131 be applied to close issue, Steve W seconded.

Change lines 148-149 from:

“The assertion defines an inactivity timeout parameter that either the RM Source or RM

Destination MAY include.”

 

To:

“The assertion defines an inactivity timeout parameter that the RM

Destination MAY include.”

 

Anish: this proposal does not close issue 21.

 

Paul F: agree

 

§    No opposition, issue 54 closed with proposed change from message 131.

 

-----------------------------------

 

i055 Marc Goodner Whose Inactivity Timeout is it anyway?

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i055

 

Proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00037.html

Proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00132.html

 

Marc G: I propose that we close with no action.

 

Chris F: I would like to determine if we really need an inactivity timeout parameter.  There has been much discussion on the list on this matter.  I see people linking inactivity timeout to message retransmission.

 

Umit: I object to what Chris if saying.

 

Chris F: why does there need to be a control on the message retransmission interval.  The whole point of rm is to be able to recover from failure.  This is counter to that goal   In the proposal I had was to redefine inactivity timeout.

 

Paul C: I have not had a chance to evaluate Chris F proposal.  I am not ready to act on this.  I would like to hear views on why their proposals are better than others.

 

Umit: There is a problem with specificity of meaning of inactivity timeout.  I do not want to limit it to a very narrow problem.  I want to accommodate rms rate of message on the RMD.  I do not agree with the narrowing from Chris F email.

 

Jacques: Chris F case is valid, if sequence is inactive after creation something is wrong and it should be reclaimed.  I never thought to apply the same policy to a sequence which has been used.  I see some value in expressing this in an agreement.  

 

Steve W: I have heard the term orphan sequence, but I have heard different definitions.

 

Chris F: basically the rms sends create sequence, but create sequence response is never received.  IF the rms keeps trying there will be several orphan sequences.  Another case is a sequence where none of the responses are received.  This is more common than the RMS taking a permanent nap.  The only case to automatically delete is if you say, if you do not talk within n minutes, I will delete the sequence.  Lets deal with the case which is easily recoverable, that is when the rms never gets notification of the sequence id so it cannot use it.

 

Anish: this is intriguing proposal.  I was interpreting the IT as a sequence of message heartbeat.  My question to Chris F is does his proposal make Ack Interval go away as well.

 

Chris F: Bob F has stated we could get rid of Ack interval as well.  Something that is tuned over time can be used by the implementation.  If it is too slow, send more frequent accRequested messages.  The two intervals were not related in my understanding.

 

Bob F:  the conflation issues from Chris F are inappropriate; they deserve to be discussed independently.  Only when trying to over control flow of traffic, do the two react.   I have distate for Inactivity timeout, since there are deployment scenarios when the RMD is an ATM (days in deserted areas) long inactivity is not a failure.  The app has an idea of the responsiveness of the other side.  The IT could be iin an API, and not be on the wire.  However its firing might require systems management to be engaged to fix a problem.  Every implementation will have to deal with resource management, give buffers and stacks.   I am highly suspicious of utility of Inactivity timeout, and argue strongly not to retain IT as a feature of the protocol.  

 

Bob:Ack interval may allow more frequent piggybacking on responses, which involves a tradeoff.  The time piggybacking is most beneficial is when queues are building (when you got something to piggyback.  I have arguments to get rid of both of these parameters.  However I could accept some mechanism for the orphan sequence case if it was properly motivated.

 

Doug B: I generally agree with Bob’s proposal.  One concern:: what would rms do with this information. If the reaction is to generate keep alive message, I am not sure this is good for bandwidth utilization.  Another concern:: if to keep connection alive one sends ack request more often.  I think these parameters may cause more confusion than what we have time to resolve in the time period we have in this TC.

 

Umit: what is rate of messages from RMS to RMD, and what is rate from RMD to RMS.  The higher level application requirements, which have rates that are know, you do not want the other side to time out and remove resources, thus we eant to keep Inactivity Timeout.  Other use case (in proposal for I56) involves the ackInterval, from RMD to RMS, and how long the RMS has to keep its resources engaged.  This has to be coordinated between RMS and RMD.  We would like to retain both.

 

Jacques: IT or AI discussions can be specific to RMS.  One endpoint may have multiple RMS which want to have different values of these parameters over the protocol.    The policy assertions had many parameters, we got rid of some of them, by we do not need to get rid of all of them.  IT and AI affect the way the RMS behaves.  These parameters have a strong flavor of agreement.

 

Sanjay: Chris F suggested to limit IT for the sequences which do not get set up properly.

 

Chris F: I would be happy with deleting the whole thing, but to keep it with any value would be for systems management activities.

 

Anish: in response to UMIT: and keep alive.

 

Umit: if we remove all the parameters

 

Anish: If we move only to apply to sequence creation, we do not need heart beat messages.

 

Umit: then you have to keep sequences forever.

 

Anish: only until they expire.

 

Chris F: I move resolve Issue 55 to delete inactivity timeout, Seconded by Doug D.

 

Umit: what about the orphaned sequences case.

 

Chris F: I will raise a new issue on that orphan sequence case.

 

Paul F: the motion can be phrased to also include the need for a new issue on the orphan sequence.

 

Chris F: conflating infrastructure level parameters with application parameters has caused problems.

 

Jacques: I heard there will be a new issue on orphan sequences.  I would rather deal with that with this issue, before opening a new issue.  I would rather not remove IT as a parameter at this time.

 

Vote:

 

23 Yes

3 No

 Many abstain

 

§    Motion passes: issue 55 closed by removing IT as a parameter.

----------------------------------

 

 

i056 Chris Ferris How can RMS communicate the Base Retransmission Interval, Exponential Backoff and Inactivity Timeout values?

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i056

 

Proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00040.html

Counter-Prop: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00062.html

 

Marc G: it seems we should close this issue with no action, since the three parameters are gone.

 

Gil: I see Umit has brought Ack Interval into this discussion on I056.

 

Umit: If people close this I can add a new issue later.

 

Doug B: I would rather discuss Umit’s ackInterval case as a separate issue.

 

Umit: I will do that if this issue 56 is closed.

 

Bob F: I move to close issue 56 with no action,  Tom Rutt seconded.

 

Paul F: given Umit will raise a new issue on Ack interval is there any objection to closing 56 with no change.

 

§    No objections, Issue 56 closed with no action.

 

----------------------------------

i066 Remove LastMessage

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i066

 

Proposal in original issue

 

Doug D: please send objections to proposal to the issue list

----------------------------------

 

No time to discuss other issues

 

9) Any other business

 

None

 

Meeting ended at 5:30 ET.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]