[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 10/20 teleconf
The proposed minutes are attached. Please read the text on action item 40 and 10 to ensure I captured the intent of your points. Send any corrections to the entire list before monday morning. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Preliminary Minutes WSRX TC Teleconf
|
Preliminary Minutes WSRX TC Teleconf October 20, 2005 – Tom Rutt agreed to take the minutes. 1 Roll CallFrom Kavi,
Meeting is Quorate 2 Review and approve of Agenda1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Oct 13, 2005
meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14939/MinutesWSRX-101305.htm 4) Administrative Issues Open ballots Email issues 5) AI Review 6) New issues since last conf-call 7) Discussion around AI40 (aka i024) 8) Issue Discussion: a> Issue 10: Sequence port
spanning b> Issue 22: RM Policy Assertion
Model's Base Retransmission Interval Clarification Needed c> Issue 23: Robust recovery
from low-resource conditions d> Issue 50: spec talks about
delivery assurances but does not clearly relate them to the protocol e> Issue 2: AckTo
EPR and seq lifetime 9) Any other business Anish: I gave email about the DA usage in the core spec. Where should this be defined. Paul: Agenda item 7 a) is for 40 which was for 24. Anish: I may need help in pointing out the email I sent. Chris F: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00181.html Tom: it is relevant to the new issue 50. 3 Approval of Oct 13 meeting minuteshttp://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14939/MinutesWSRX-101305.htm
Tom R moved, Chris F seconded to approve the Minutes of Oct 13 meeting. § No objection, Minutes of Oct 13 meeting Approved. 4 Administrative Issues4.1 Open ballotsCD ballots issued and are due next Thursday. 4.2 Email issuesUmit has recognized a problem, which OASIS staff is dealing with. 5 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 12 – remains open 31 – remains open 34 – remains open 40 Ashok – provided text, however it is not agree, leave open. 41 – open 49 –completed 6 New Issues since last con callhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00170.html
---------------------------------------------------------------------------- Proposed-01 Title: Should DA be separate assertion or parameter Proposed-02 Title: Which occurances within the
specs, if any, of the term "URI" need to be replaced with
"IRI"? Proposed-03 Title: Target of RM Assertion parameters are confusing with
respect to how they are specified and attached Proposed-04 Title: Whose Inactivity Timeout is it anyway? Proposed-05 Title: How can RMS communicate the Base Retransmission
Interval, Exponential Backoff and Inactivity Timeout
values? Proposed-06 Title: Classification of References (normative vs.
non-normative) is needed ---------------------------------------------------------------------------- 6.1
Proposed-01
Title: Should DA be separate assertion or parameter Description: The resolution to issue i009 [2], created an
element for DeliveryAssurance: <wsrm:DeliveryAssertion
mode="[AtLeastOnce|AtMostOnce|ExactlyOnce]"
ordered="[xs:boolean]"? ...=""
> The question that was not resolved as part of that
discussion is whether the element should be a child of <wsrm:RMAssrtion>
or whether it should be a separate assertion. Justification: We need to make a decision Target: WS-RM Policy Assertion Type: technical Proposal: TBD Related: i009 [2] [1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_item.php?action_item_id=1043 [2]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14682/Relia#i009 Accepted as new issue with Umit as owner. ---------------------------------------------------------------------------- 6.2
Proposed-02
Title: Which occurances within the
specs, if any, of the term "URI" need to be replaced with
"IRI"? Description: In closing i038, we determined that it would be
necessary to review each use of the term URI to determine whether it needed to be replaced with
"IRI" and thus require the addition of a reference to RFC3987. Justification: Ensure correct use of the terminology within
the spec wherever a URI could be an IRI. Target: WS-Reliable Messaging, WS-RM Policy Assertion Type: technical/editorial Proposal: TBD Related: i038 Accepted as new issue with Umit to
own ---------------------------------------------------------------------------- 6.3
Proposed-03
Title: Target of RM Assertion parameters are confusing with
respect to how they are specified and attached Description: Currently the WS-RM Policy Assertion describes four
distinctive parameters in Section 2.1 [1]: Base Retransmission Interval,
Exponential Backoff, Inactivity Timeout and
Acknowledgement Interval. Further, these parameters are scoped with respect to
two distinct roles as summarized below: RMS: -- Base Retransmission Interval (BRI) -- Exponential Backoff (EB) -- Inactivity Timeout (IT) RMD: -- Inactivity Timeout (IT) -- Acknowledgement Interval (AI) Clearly there is a separation between which roles these
assertions would apply in the specification.
However, the definition of the RM assertion includes ALL of the
parameters regardless of the role. This
causes a problem in interpreting what is being intended in Section 2.3 [1]
which describes attachment of the policy. >From the perspective of WSDL, the service is always
described from the perspective of the provider and lists the requirements of
the provider. Hence the WS-Policy attachment of RM Assertion will appear to
apply to RMD alone. If we were to take this assumption into consideration,
semantics of supplying all the 4 parameters in a RM Assertion is not very
clear. There are two possible interpretations: (1) Although, there are two separate roles of RMS and RMD,
it is the RMD who owns the WSDL and dictates all these parameters. This means
the BRI, EB although are defined for RMS, are not really defined by RMS. RMS in
essence has no control over these parameters.
Note that this interpretation appears to contradict the Lines 112-113
and 117-119. (2) All the parameters appearing in a WSDL for RMD are
applicable for the RMD only. However each parameter is scoped to request and/or
response. For example, the BRI, EB and IT will apply when the RMD acts in a
sender role (for a response message), and only the IT and AI apply in the RMD's receiver role (for a request message). RMS is free to
use its own parameters. Note that this interpretation appears to conflict with
the example provided in Section 2.3, lines 225-227 where RMS is mentioned, but it
is not stated that the RMD will be in the role of sender when these parameters
apply. It is not clear which of the above interpretations is
correct. Further, different sections of the specification are in conflict with
each other regardless of the interpretation assumed as illustrated above. Justification: It should be clear in the specification where the assertion
parameters apply and how. Currently, there are two distinct and possible
interpretations leading to confusion. Further, not making the clarification
affects resolution of issues that pertain to attachment of policy in general
since it is not obvious how the RM Assertion parameters apply with respect to
the roles that are acknowledged in the specification. Target: policy Type: design Proposal: 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. Detailed proposal: TBD. Related Issues: i021, i006 References: [1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf
Umit gave an overview of the new issue. Agreed to accept proposed 03 as new issue, with Umit as owner 6.4
Proposed-04
Title: Whose Inactivity Timeout is it anyway? Description: Currently the WS-RM Policy Assertion describes four
distinctive parameters in Section 2.1 [1]: Base Retransmission Interval,
Exponential Backoff, Inactivity Timeout and
Acknowledgement Interval. Further, these parameters are scoped with respect to
two distinct roles as summarized below: RMS: -- Base Retransmission Interval (BRI) -- Exponential Backoff (EB) -- Inactivity Timeout (IT) RMD: -- Inactivity Timeout (IT) -- Acknowledgement Interval (AI) The current WS-RM Policy Specification allows the
specification of the Inactivity Timeout, however it is
not clear who actually "owns" this value. Is it the RMS or the RMD
that specifies the value of the Inactivity Timeout? Currently the specification indicates the following in Lines
108-111: {The assertion defines an inactivity timeout parameter that
either the RM Source or RM Destination MAY include. If during this duration, an
endpoint has received no application or control messages, the endpoint MAY
consider the RM Sequence to have been terminated due to inactivity. } If either of the parties can include this value, which party
does the WS-RM Policy Attachment refer to? If it applies to, say RMD, shouldn't
the RMS be able to specify this in some fashion? Justification: Simply, it is not clear from the
specification which party it applies to. This must be clarified. Further, if
either of the parties can include this value, it should be stated when RMS or
RMD may specify this value. Target: policy Type: design Proposal: TBD RelatedTo: Previous New Issue
Posted, "Target of RM Assertion parameters are confusing with respect to
how they are specified and attached" ("soon" ;-) to
appear at the tc website near you if you are patient!
). References: [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf
Umit gave an overview of the new issue. Ashok: is this not the same as previous issue. Umit: it is related, however this one inactivity timeout appears for both roles. Vikas: would not the resolution to previous issue be the same as for this. Umit: It is possible. Chris F: could we not update the other issue to fold this in. Marc G: I agree with keeping the separation of these issues. Agreed to accept proposed 4 as new issue,
with Marc G as owner. 6.5
Proposed-05
Title: How can RMS communicate the Base Retransmission
Interval, Exponential Backoff and Inactivity Timeout
values? Description: Currently the WS-RM Policy Assertion specification describes
four distinctive assertion parameters in Section 2.1 [1]: Base Retransmission
Interval, Exponential Backoff, Inactivity Timeout and
Acknowledgement Interval. Further, these parameters are scoped with respect to
two distinct roles as summarized below: RMS: -- Base Retransmission Interval (BRI) -- Exponential Backoff (EB) -- Inactivity Timeout (IT) RMD: -- Inactivity Timeout (IT) -- Acknowledgement Interval (AI) The specification makes the above distinction and allows
both the RMS and the RMD to include their respective parameters. However, it is
not clear "where" these parameters would be included and
"how" they would be communicated between the RMS and RMD.
Specifically, the current RM Assertion element appears to apply only to a WSDL
which enables the RMD to communicate it assertions. However, it is not clear
how the RMS can express and communicate its RM Assertion parameters. Justification: Although the specification defines certain parameters with
respect to a role, namely the RMS, it is not clear how they would be expressed
and communicated. This makes the specification incomplete and unusable from the
perspective of RMS. For example, it is
impossible for an RMS to configure its system once with parameters that suits
its own needs and allow these parameters to be negotiated with the RMD. Target: policy Type: design Proposal: Scope the RM Assertion parameters on a per Sequence basis
and utilize the CreateSequence message exchange for
communicating RM Assertion parameters between the RMS and the RMD. Detailed proposal: TBD. Related Issues: References: [1]
http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf
Doug B: what negotiation are you talking about. Umit: I expect there is a utility in being able to convey these parameters. It is unclear to me how this is conveyed. It might not require a negotiation. Chris F: If we remove them all this issue goes away. Agreed to accept proposed 05 as new issue with Chris F as owner. Paul C: Are some of these issues related to I022. If so it might be better to solve before we
work on this issue. 6.6
Proposed-06
Title: Classification of References (normative vs.
non-normative) is needed Description: Currently our working draft references are all over the map.
-- WS-RM: Lists most references as Normative, except those
that are related to WS-Policy. [1] -- WS-RM Policy Assertion: All references are non-normative.
[2] As one of the editors of this spec, to put all references as
non-normative was deliberate on my part. IMO, the tc should make the decision about the references and
which bucket they belong to. This is not an editorial decision and other TCs, such as WS-RF, went through each reference and
determined where they belong to. Justification: Obvious :-) . We need normative and
non-normative references clearly delineated. Target: core, policy Type: design Proposal: Review each reference by the tc and determine whether the reference is normative.
This must be done before we go to public draft (PD). I think we can live with this issue right now and should not
affect our first CD. For the first CD, I propose we leave everything as is and put a
note stating that the decision on classifying references is pending. References: [1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14785/wsrm-1.1-spec-wd-05.pdf
[2] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/14793/wsrmp-1.1-spec-wd-01.pdf Agreed to accept as a new issue, with 7 Discussion around AI40 (aka i024)Ashok stated he started with a clarification of semantics of word “observed”. However the discussion of this issue has been extended in the email. I would like us to discuss what we want from a resolution to this issue. Paul C: can you relate this to what the TC decided. Ashok: the TC asked for wordings to clarify the meaning of word observed. Marc G pushed back on this, he wanted the word replaced instead. Paul C: are the two alternative on the table yet. Ashok: I put one proposal on the table. Umit: Can someone point to the email. Paul F: there are actually two proposals on the table, one from Ashok and one from Marc G. Anish: The TC decided at the F2F that the semantics of parms was as wsp:observed, IE they do not affect messages on wire. Similar to privacy policy on a web site. We wanted to get it in there, without relying on WS-policy. I thought this was supposed to be a trivial clarification. Marc G: Ashok proposal does not talk about observed. The original issue did talk about QOS so it also pertains to DA. Paul C: can chair point to two proposals. Anish: I also sent a proposal this morning. Paul C: So there are three proposals. Marc G: My proposal is to change all occurrences of "observed" to "in effect" Ashok proposal at http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200510/msg00134.html Please see attached document. The wording is written as a delta
to the WS-RX Policy document. The words highlighted in green are
suggested additions and the paragraph
highlighted in red is a suggested deletion. There are additions and deletions
to section 2.3 Assertion Attachment and a new
section to be added between sections 2.4 and 2.4 entitled Assertion
Semantics. I also suggest that the attribute /wsrmp:RMAssertion/@wsp:Optional="true"
on line 158 of section 2.2 be removed as
it makes no sense. The semantics assume that the
assertion is purely informational and does not
appear as a header in neither the messages in the sequence nor the
signaling messages. Some of the people in the WS-RX WG
have expressed the opinion that that WS-RX policy information should be made
available from the signaling messages (CreateSequence,
CreateSequenceResponse, etc) so that the RMS can
adjust its retransmission interval and perhaps its inactivity timeout based on
the acknowledgement interval of the RMD and the RMS can perform some
optimization based on
the delivery assurances between the RMD and the AD. This is a reasonable
position. If the WG so decides, I can
modify the wording to reflect these semantics. The attachment was not available in PDF. Jeff M: the text is short. In the Reliable Exchange model
there is an Application Source (AS), a Reliable Messaging Source (RMS) that
acts on behalf of the AS, an Application Destination (AD) and a Reliable
Messaging Destination (RMD) that acts on behalf of the AD. The message flow is
between the AS and the AD with the RMS and the RMD acting as intermediaries. Policies containing the RM
assertion may be attached to the [WSDL 1.1] specification of the AS or the AD.
The assertion has Endpoint Policy Subject [WS-PolicyAttachment]. The RM assertion does not impact the
content of the messages flowing in the relaible
sequence between the AS and the AD.
Neither does it impact the sequence signalling
messages such as CreateSequence and CreateSequenceResponse.
It does, however, constitute a property of the service and users of the
service are informed that a such a policy is in
effect. Anish: my proposal is to document the fact that these parameters do not affect the message on the wire, and be done with it. That captures what we decided at the face to face. Ashok: that would be enough. Chris F: I am not sure I agree with Ashok proposal. The RM assertion does affect what goes on the wire, because it turns RM on. The parameters within the rm assertion do not affect what is on the wire, however. Chris F: The RM assertion states to put the sequence header on the messages. Anish: My proposals was regarding the parameters, not the rm assertion. Chris F: The important thing to note, is that the parameters are purely informational. However, it might be better to discuss first whether we have parameters. Paul F: we do not have a proposal that is agreed. Marc G: people are reading into the original issue proposal for Issue 24. Paul F: I propose we either continue discussion of this action item on the email list, or someone should raise a new issue. Doug B: we have a number of clear proposals, which are not aligned, but we could as a TC vote each up or down. Paul C: I have not seen the proposal of Ashok doing anything to the word “observed”. His proposal does not satisfy the action item of the TC, which was to clarify the meaning of “observed”. So I do not think we have clear proposals. Doug B: we have three proposals, however I was not saying that the proposal of Ashok meets the AI. Doug B: I move that we accept Marc G proposal to close the issue by changing “observed” to “in effect”. Marc G seconded. Paul F: I agree this could close the Issue 24. Ashok: we could follow it up with a new issue to clarify semantics. Chris F: I do not understand the issue with informational parameters. They do not change what goes on the wire, so I do not understand the obsession with the word observed. Ashok: Anish has a one line solution which could resolve this. Anish: I agree this is not that important, I thought this was already decided at f2f that it is informational, and does not affect what goes on wire. However, with uncertainty of WS-policy spec, my wording would allow us to express what our parameters mean for our specification. Chris F: we have been obsessing over policy, however we are waiting for policy to become a standard. Paul F: this discussion does not seem to help with the motion on the table. We have a motion, however are people objecting to the motion. Paul F the motion is to close action item 40, using email message 144 proposal from Marc Goodner. To change “observe” to “in effect”. Paul F: I would like the discussion to focus on the motion. Anish: I do not think this motion is completely solving what we wanted to do. It is not complete. Anish I would amend to remove observed, and to say that the value of rm assertion parameters do not affect what is on the wire. Anish: I move to amend by adding words “rm assertion parameters do not affect the messages which are sent on the wire”, seconded by Chris F. Marc G: there was a clear resolution accepted by TC which stated to clarify meaning of word Observed, My proposal does this. These other proposals are not addressing the intent of the TC at the F2F. Paul F: Anish additional sentence clarifies the motion. Marc G: I would prefer to know where it goes. Anish : right after the text change you propose. § No objection to amendment, it passes. § No objection to amended motion, it passes. Issue 024 resolutions are now complete, and action item 40 should be closed. 8 Issue Discussion8.1
a> Issue 10: Sequence port spanning
Doug D explained his proposal. Paul C: I do not understand the meaning of the word “Scope” in your proposal. Are you saying scope is how they are architected. Doug D: I would like to clarify that an RMS or RMD is not a single endpoint. Paul C: I do not see these words in your proposal. Doug D:: I would prefer such explicit text, however other people had complained. I could add that text with “for example” added. Does anyone have concerns. Sanjay:: my concern was that we should not define a new capability, but using “for example” would be acceptable. Paul C: whiy the 477 thru 480 Strikeout Doug D: I want to avoid implications of single RM processor. Paul C: ok Jacques: I think there may be a new issue on the exact nature of rm source and destination endpoints. Ø Action: Jacques will raise new issue on the nature of reliable message endpoints . Umit: It defines a messaging protocol to identify, track, and manage the reliable delivery of messages between a source and a destination. Paul C: look at diagram on 188. On left hand side there is initial sender. Although this is not same as soap 1.2, however does this term contradict what you are trying to say. Doug D: I am not bothered by the figure. Paul C: I am looking for transient closure, and the diagrams currently explain the text. I think you should look at this figure as well. Doug D: I will rethink this in my next proposal. 8.2
b> Issue 22: RM Policy Assertion Model's Base
Retransmission Interval Clarification Needed
Vadim: these are QOS parameters. The protocol of WS-rx is no more reliabile than TCP/IP. Chris F: Bob has put a mail out on this issue. Any fixed timing parameters is not going to solve any problems. We did not have in mind that these were fixed in the initial spec, but were intial values. Bob F has stated that there are several algorithms than can be uses. I not think that these parameters should be removed altogether to resolve this issue. Anish: I agree with Chris F an Bob’s email. I see them as operational, with no sense to have them be as static values, I agree they should not be policy. However, Vadim states they should be part of the protocol itself. Vadim: In my issue the wording is to clarify as rm assertions. These are not assertions , but are dynamic values which need to be communicated between source and destination. This is a layer of reliability on top of TCP/IP. You are saying ws-rx is just as reliabile as TCP./IP. Bob F: I have dealt with these issues too many times over too may years. Specifying the parameters does not work, even in TCP high performance extensions. Early TCP implementations ran into perf issue with fixed parameters. Even issu of communication of these values is a mistake, the mechanisms may appear to be different on each end, depending on media. The concern I have is that we are in policy assertion, leading implementers astray. That is why I am proposing deletion of these parameters. If you delete them, there is nothing left which uses the term retransmit. Thus we need to have some text on the concept of re-transmission. The spec needs retransmission in order for it to work. This might be a new issue. Paul: can we have text on the list for a proposal. Bob F: I will do that and also raise a new issue on the need to discuss retransmission. No more time. 8.3
c> Issue 23: Robust recovery from
low-resource conditions
No time 8.4
d> Issue 50: spec talks about delivery
assurances but does not clearly relate them to the protocol
No time 8.5
e> Issue 2: AckTo
EPR and seq lifetime
No time. 9 New BusinessMeeting adjourned at 5:30 PM Eastern Time. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]