[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 7/28 teleconf
The prelim minutes are attached. Please send corrections before 12 noon pacific time, 7/29. I will post the corrected minutes to the server after 12 noon pacific, because I am leaving for a two week vacation Friday Afternoon. I will talk to you all after a two week leave of absense. Tom Rutt Secretary -- ---------------------------------------------------- Tom Rutt email: email@example.com; firstname.lastname@example.org Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes OASIS (WS-RX) TC formation meeting
Prelim Minutes OASIS WS-RX TC Weekly Conference Call
Date: Thursday, 28 July 2005
Time: 01:00pm - 02:30pm PT
Minutes Style Conventions
§ Motion Resolution text
Ø Action item text
Ø Potential new issue Text:
Tom Rutt agreed to take the minutes.
1 Roll call
Meeting is quorate.
2 Review and Approval of Agenda
1) Roll Call
2) Review and approval of the agenda
3) Approval of the Jul 21st meeting minutes
4) AI Review
5) New issues since last conf-call
6) Issue Discussion: Assign owner and discuss resolution
b> Issue i013: Max message number in policy
c> Issue i018: Is an implementation supporting a smaller max message number valid?
d> Issue i019: Sequence termination on Fault
e> Review issues i015, i016 and i017
7) Any other business
Marc G wanted to add meetings in august as part of any other business.
Paul F: leave of absence requests also to be discussed in ahy other business.
3 Approval of the Jul 21 meeting minutes
Tom Rutt moved, Anish seconded to approve the 7/21 minutes.
§ No Opposition Minutes approved.
4 AI Review
#0002: OASIS Staff should fix typographical error in charter of missing space between “produces” and “to” the next time the charter is updated.
Owner: James Bryce Clark
Status: Open: Jamie has not yet posted the changes
#0007: Sanjay to set up editing team Subcommittee or mailing list
Owner: Sanjay Patil
#0011: Chairs should start a KAVI ballot asking members if they will attend the Face to Face meeting, either in person or by teleconference
Owner: Paul Fremantle
Status: Closed – members should cast their vote soon.
#0012: Chair took an action item to get a ruling from Jamie on CVS repository usage.
Owner: Paul Fremantle
Status: Open – waiting for response
#0013: Chairs will propose a mechanism to manage the Queue on the conference calls.
Owner: Sanjay Patil
#0014: Marc G should review Jacques suggestion for new issue status, and report to TC by next week call
Owner: Marc Goodner
Status: Closed Marc G stated it would not help his work flow. Do not need to add new status for submitted issues.
#0015: Forumulate use case/requirement for issue i009 (Declaration of QoS policies)
Owner: Christopher Ferris
5 New issues since last conf-call
Marc G email on this topic
Semantics of "At most once" Delivery assurance
all - design - unassigned
The semantics of the "at most once" delivery assurance are not clear.
One interpretation is that at most once implies that the sender is not required to retransmit mesages which are not acked.
Related to i009
It is important to clarify whether the sender must retransmit unacknowledged messages when the "at most once" delivery assurance is in use.
Clarify the semantics. There are at least three possible semantics associated with "at most once"
1. At most once means that the sender will never retransmit a message, regardless of whether it is acknolweged by the destination.
2. The sender may retransmis messages, but is not required to to so, however the destination will not deliver duplicates
3. The sender must retransmit messages, however the destination may drop messages in times of resource saturation, but will never deliver a duplicate.
Agreed to add proposed-01 to issues list – owner Tom Rutt.
An RM Policy applies two-way
policy - design - unassigned
In WS-RM Policy, and per WS-PolicyAttachment, RM Policy assertions may be attached to ports. E.g, details of parameters for the resending mechanism. It is implied by doing so, that both inbound and outbound messages are subject to this policy. This assumes that there is a strong case for in and out messages always using the same Delivery assurance. In effect this is saying that an RM Policy applies to two Destinations: the destination of the inbound messages, and the destination of the outbound messages (meaning for example to both a WS endpoint and its clients).
Evidence for such an aggregation of quality of service is unclear: On the contrary, both (a) differences in technical capabilities between Source and Destination, and (b) differences in business and QoS requirements, suggest that a policy (delivery assurance) defined for messages going one direction, may not be appropriate for messages going the other way.
Even if the scope of an RM Policy remains at port level there could be an additional scoping attribute stating inbound vs outbound. Yet a cleaner way seems to make use of finer granularity in the attachment (as allowed by WS-PolicyAttachment).
Deferred discussion until Jacques is present
Jacques stated that the policy attached to an input message should not always be the same as that applied to the response message. They apply to different endpoints.
Ashok: would it be ok if the policy was attached to the message rather than port type.
Jacques: that would one resolution to this issue.
Marc G: is this the same as Issue i08 on policy granularity.
Tom Rutt: that is more about operation level at the destination.
Jacques: they might be seen as related, and solutions for one could apply to the other. I would prefer to keep them separate.
Agreed to add proposed-02 to issues list, with Jacques as owner.
RM Policy Assertion Model's Base Retransmission Interval Clarification Needed
policy - design - unassigned
The RM policy assertion model defines InactivityTimeout and BaseRetransmissionInterval. The text in the specification WS-RM Policy (Page 5) implies that these two parameters are essentially serving the same purpose i.e. to trigger a retransmit based on a timeout value. If this is the intention, the spec needs to clarify the pecking order for an implementation i.e. what if timeout occurs before base retransmission interval has expired.
There is no obvious case mentioned in the spec that requires two timers for retransmission upon timeout.
Merge the two into one timer called Retransmission Timeout.
Anish: From my understanding there is some misunderstanding about what the two assertions are for. Chris F email states they are for different purposes and cannot be combined.
Tom: The inactivity timout is for closing the sequence, however the BaseRetransmission interval is a smaller value for the time between individual retransmissions of same message id.
Agreed to add propose-03 to issues list, with Vikas as owner.
Robust recovery from low-resource conditions
core - design - unassigned
In situations where the RMD is running low on resources, it may want to provide hints to the RMS of its situation with the expectation that the RMS pauses or slows down the (re)transmittal of messages and avoid further straining of RMD resources until recovery. The current solution of statically associating an ExponentialBackoff policy assertion may not be timely and sufficient in all the cases and a more dynamic solution for throttling the message flow may be needed.
In a low-resource situation, it is likely that the RMD would discard any incoming messages and stop sending any Acks. Since the current protocol design does not provide for the RMS to become cognizant of the situation on the RMD side, RMS may simply keep on (re)transmitting messages resulting into further resource utilization (network bandwidth, processing power on both ends, etc.) and possibly making the situation worse. It seems that a better option may be for the RMD to push back on the RMS in the event of low-resource like situations and request the RMS for pausing or slowing down any (re)transmissions.
RM Protocol to support RMD pushing back on the RMS for slowing down or stopping (re)transmission of messages.
Agreed to add proposed-04 to issues list, Marc G agreed to be owner..
Anish: I think that this flow control scenario is quite valid. However, I would like to raise caution that the protocol submission has not addressed flow control, and there are more issues that this.
Marc G: there may be scope issues with the charter itself.
The owner drives the issue, by presenting during calls, and should propose solutions and leads email discussions.
Ashok: I had send out mail about possible issue, on WS-RX policies not being reflected in messages.
Sanjay: I request that you submit using the formal template.
6 Issue Discussion: Assign owner and discuss resolution
6.1 c> Issue i018: Is an implementation supporting a smaller max message number valid?
Doug B: the email to date indicates that people are comfortable with a designed in limitation for an implementation that is less than the max unsigned long for a sequence number. The spec should not attempt to define a max for conformance. Testing would be that the declared max is supported in an implementation. I am unsure how to fully close this issue without opening the conformance clause rat hole.
Duane N: could we have a parking lot for conformance issues.
Doug B: close no action means that there is nothing in the spec requiring an implementation to support the full length of unsigned long.
Doug B: Proposal:
The answer to the question is “yes”. Enforcement of a particular smaller number is not currently disallowed, so we should close this issue with no action.
Anish: I though should go to draft status, editor’s would not have to do anything.
Peter Niblet: Is the intention to add an appendix for conformance clause, beyond the normative MUST clauses.
Sanjay: Marc G is going to start a group on how to gather individual conformance issues.
Chris F: Is the substance whether an implementation may support a max less than the schema max.
Doug B: the rationale to close with yes is that any lower limit enforced in the spec will be impossible in some deployment scenarios.
Chris F: your proposal is to leave as is, implying that it is ok for a Java to support only the max of a long, rather than unsigned long.
Tom R: why would a clarification not be useful.
Doug B: the clarifications would be better to deal with in the other two issues in this area.
Jeff M: what about the conformance issue.
Doug B: one of the other issues has a proposal to add a policy statement on the max messageID value supported by the implementation.. Conformance would be related to this policy value.
Sanjay: the core of this issue is just whether a smaller value of max is allowed.
Ø Action: Marc G will form a team to discuss how do deal with conformance related issues on the specification.
Sanjay: Why not put this clarification in the spec.
Doug B: a policy assertion allowing an implementation to state it supports something less makes this very clear.
Jeff M: What if there is no policy assertion, is the implementation still allowed to support smaller than schema max.
Paul F: this issue is prior to the policy issue. We should record the answer that we support max values less than the schema max, then move to issue 19. This will be clear in the spec. However we should make the answer to issue 18 known.
Chris F: It is more than just a policy issue. We can table this discussion for now, perhaps with a straw poll on the answer, and then move on to resolving the other issues in this area. The destination threshold being exceeded can be less than the xs: schema max for unsigned long. I suggest we move on, and discuss the other issues in this area, then close them together.
Duane N: when we talk about this we have to distinguish the sequence number being exhausted, versus the resources are exhausted. Large messages can cause overload in the resources of the destination.
Doug B: I would like to take another stab at the proposal, incorporating some of the discussion in a rewording:
Doug B new Proposal:
The answer to the question is yes. An implementation may support a smaller max than the xs: schema definition for unsigned long.. No change is necessary to the text as a result of this answer to the question. Any changes to text are likely to come from the other issues. Table discussion of text changes until we see resolution of other issues.
Chris F: we could just record the answer as yes, then close the issue with no text changes necessary.
Jeff M: we should not be reopening closed issues.
Chris F: I agree that we do now re-open issues, we could open up new issues.
Sanjay: how can we stop from reopening old issues.
Chris F: To make progress the group should not reopen old issues.
Jeff M: We need a very high bar to re-open issues. Adding clarifying text could be incorporated through a new issue.
Paul Cotton: New compelling information raised at a future meeting should allow an issue closed a prior meeting to be re-opened.
Paul F: people may try to add a new issue which, in effect, reopens an older issue. However the committee would have to agree to the new issue as being warranted. We need to get more progress on closing issues.
Motion by Doug B, Seconded by Chris F: “The answer to the question asked in the title is "yes"; an implementation supporting less than 18 quintillion as the maximum message number is valid. With regard to the specification at this time, no change seems necessary. Any clarification necessary to make this lack of an implementation requirement clear is likely to come from resolutions to i013: Max message number in policy and / or Issue i019: Sequence termination on Fault.”
§ No objections, issue moves to closed with no action necessary.
6.2 b> Issue i013: Max message number in policy
Current the message id rollover fault terminates the sequence.
Deferred for lack of time
6.3 d> Issue i019: Sequence termination on Fault
It is unclear what the termination os the sequence is. Does it allow resumption of the sequence.
Deferred for lack of time
6.4 a> Issue i014: Document Names
Deferred for lack of time
6.5 e> Review issues i015, i016 and i017
Deferred for lack of time.
7 Any other business
Sanjay: Thurs 18 august, and 25 august both chairs will not be able to participate in a tele-conf.
Paul C: we could appoint pro-temp chairs in this situation.
Jacques: I have no issue with spacing meetings in slow months, such as August. Giving how much work is needed, keeping some meetings might work , but the chairs should consider making up with longer meetings for subsequent meetings.
Paul C: That is just reopening our discussions at the last fact to face. Skipping meetings seems to be a bad idea. We need as many meetings as possible.
Sanjay: We could post a ballot on just those two meetings.
Paul F: You are about to enter into a complex negotiation with a large number of different people. If you go alternate weeks, they better not be on the wrong days.
Chris F: It is important to keep moving forward, We can rely on leave of absence to help with any quorum problems. I agree with Paul. C
Paul C moved to meet on the two days 18 august and 25 August, Seconded by Tom Rutt.
Bob F moved to limit debate,
§ No objection on motion to limit debate.
Meeting ran out of time, Chair suggested a ballot on the meetings, with a separate ballot for pro temp chairs.
§ Two ballots will be raised, one for each of the dates.