[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of WSRX TC Teleconf june 08
Prelim minutes attached. Please post corrections 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: Minutes of OASIS WS-RX Teleconference
Prelim
Minutes of OASIS WS-RX Teleconference Junk
8, 2006 Start Time:4:00 PM Eastern
Daylight Time Sanjay acted as chair. Textual Conventions Ø Action Item Motion § Resolution 1 Roll CallFrom Kavi: Over 42 of voting members, meeting is quorate Tom Rutt agreed to take minutes. 2 Agenda ApprovalAgenda: 1) Roll Call 2) Review and approval of the
agenda 3) Approval of the Jun 1, 2006
meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18625/MinutesWSRX-060106.html 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) New issues since last conf-call Watch for Marc's email 6) Issue Discussion: a> i089 suggest the restricted
use of anonymous URI http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 b> i121 security threats and
requirements http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121 c> i122 security profiles http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122 d> i124 security composition
policy http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i124 e> i123 security profile
agreement http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i123 f> i125 Protocol precondition
requires knowledge of policies http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125 7) Any other business Sanjay suggested we add Two new agenda items after AI Review regarding
3 Approval of the 6/1 minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18625/MinutesWSRX-060106.html Tom R moved, Marc G seconded to approve 6/1 minutes. § No objection minutes for 6/1 meeting approved. 4 Administrative4.1 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0100: Tom Rutt & Bob volunteered to work on state table revisions with Jacques Owner: Jacques Durand Status: Still Open Assigned: 2006-05-09 Due: --- --------------------------------------------------------------------------------
#0102: Marc G will prepare to start an issues list for Public review comments Owner: Marc Goodner Status: Still Open Assigned: 2006-05-22 Due: --- --------------------------------------------------------------------------------
#0104: Gill will clarify his proposal for i121 to clarify the relationship between requirements and the threats Owner: Gilbert Pilz Status: Still Open Assigned: 2006-05-30 Due: --- 4.2 WD reviewMarc G: the comments that were raised as new issues fix the problems the members found. Paul C: will the editors revise the document to fix the problems. Doug D: I have opened up issues on the ones which are not purely editorial. Sanjay: Have editors have another review draft leaving the minor editorials. Doug B: why, the editors can point to the email for the editorial comments. As a reviewer I do not see a substantial difference between having to correlate changes with email comments, than with issue resolutions. Paul F: we expect the editors to do a lot of work over next month, leaving editorials for later gives them more time. Wait till all the new issues are resolved before a new version. Paul F: I would prefer a next document to include all the new issues raised. Paul C: I want to ensure the editors have a plan for WG progression. Sanjay: No opposition to next draft having both changes from issues and comments made, with appropriate annotation as to source of comment. Doug D: we could make a draft available with all issues accepted today by next week. Our intermediate editor’s drafts will all be made visible to TC. 4.3 Conf Call Hosting VolunteersBEA Nortel Microsoft Need others for future. 5 New issues since last conf-call5.1 Proposed 08From Doug D: http://lists.oasis-open.org/archives/ws-rx/200606/msg00053.html Title: Make Accept/AcksTo consistent Description/Justification: The definition of CS/AcksTo says: ... It specifies the endpoint
reference to which messages containing <wsrm:SequenceAcknowledgement> header blocks and faults
related to the
created Sequence are to be sent, unless otherwise noted in this specification
(for example, see Section 3.2). However, the Accept/AcksTo says: ... The RM Source SHOULD send
messages with <wsrm:SequenceAcknowledgement> header
blocks related to the accepted Sequence to the referenced endpoint. This is a bit inconsistent since
the 2nd one doesn't say anything about sending
faults the EPR. Since the Offered
sequence should be no different from a
sequence created using a CS we need to align these two definitions. Target: wsrm
spec Type: design Proposal: Modify the Accept/AcksTo to say: ... Like the wsrm:CreateSequence/wsrm:AcksTo element, this element specifies
the endpoint reference to which messages containing <wsrm:SequenceAcknowledgement> header blocks and faults
related to the
offered Sequences are to be sent, unless otherwise noted in this
specification (for example, see Section 3.2). Implementations MUST NOT use an
endpoint reference in the AcksTo element that would
prevent the sending of Sequence Acknowledgements back to the RM Source.
For example, using the WS-Addressing "none" IRI would make it impossible
for the RM Destination to ever send Sequence Acknowledgements. I basically stole the CS/AcksTo text. No objection to accepting proposed 08 as new TC issue. 5.2 Proposed 07From Doug D: http://lists.oasis-open.org/archives/ws-rx/200606/msg00045.html Title: define unspecified IncompleteSequenceBehavior Description/Justification: When CSR/IncompleteSequenceBehavior
is not present the spec is silent on
what the default value might be. We
should be clear that there
is no default value. Target: wsrm
spec Type: design Proposal: Add the text in bold: /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior This optional element, if present,
specifies the behavior that the RM Destination will exhibit upon the closure of an incomplete sequence. If omitted, there is no implied value. Doug D: Matt has pointed to the correct text in the document. I would like to withdraw this proposal. Matt we should put the line number in. Doug D: Line 317 has the text which I missed before. Doug B: I move to accept proposed 07 as new issue, and to close with no action, since line 317 covers what is missing. Seconded by Marc G. § No objections, proposed 07 closed with no action, since line 317 is acceptable. 5.3 Proposed 06[NEW ISSUE] Define "discard" Doug
Davis Title: Define
"discard" Description/Justification:
In WD13.pdf section 3 -
line 308++ - should we define "discard" - its not clear to me that we mean the
discarded messages will NEVER (and have never) be delivered to the
AD, instead of just "from now on the RMD won't deliver them". Target: wsrm spec Type: design Proposal: Modify the text for IncompleteSequenceBehavior to be (new stuff in bold): (Chris/Bob is this new
stuff consistent with what you guys wanted?) /wsrm:CreateSequenceResponse/wsrm:IncompleteSequenceBehavior
This optional element,
if present, specifies the behavior that the RM Destination will exhibit upon
the closure of an incomplete sequence.
For the purposes of defining the values used, the term 'discard' refers
to the RM Destination never delivering a particular message to the AD. A value of “DiscardEntireSequence” indicates that the entire sequence
will be discarded by the RM Destination if the sequence is closed when there
are one or more gaps in the SequenceAcknowledgement/Final. Note, this means that
the RM Destination will not deliver any messages to the AD until the final SequenceAcknowledgement is determined and there are no gaps
in it. A value of “DiscardFollowingFirstGap” indicates that messages in the
sequence beyond the first gap will be discarded by the RM Destination when
there are one or more gaps in the SequenceAcknowledgement/Final.
The default value of “NoDiscard” indicates that no acknowledged messages in the
sequence will be discarded by the RM Destination. No objections to accepting Proposed 06 as new TC
issue. 5.4 Propose 05[NEW ISSUE] What does ack
interval refer to Doug
Davis Title: what does ack interval refer to Description/Justification:
In WD13.pdf section 3 -
line 301 - defines the AckInterval element as: This element, if present, specifies the
duration after which the RM Destination
will transmit an acknowledgement. If omitted, there is no
implied value. 'after'
what? It isn't clear when this mystery
timer is kicked off. - "...specifies the
duration after which the RM Destination will
transmit..." After
what? It should say 'after
receipt of a message' or something like that. Target: wsrm spec Type: design Proposal: Replace the above text
with: This element, if present, specifies the
maximum duration, after receipt of a
reliably sent message, which the RM Destination will wait before transmitting
an acknowledgement. If omitted, there is
no implied value. This still allows the
RMD to send it sooner if it wants to. Doug B: I think the proposal changes the semantics, however I am in favor with accepting as a new
issue. No objections to accepting Proposed 05 as New TC
issue. 5.5 Proposed 004[NEW ISSUE] Remove sections 1.1 and 1.1.1 Doug
Davis Title: Remove sections
1.1 and 1.1.1 Description/Justification:
there's no text in there so there's no reason to keep 'em Target: wsrm spec Type: design Proposal: remove
sections 1.1 and 1.1.1 No objection to accepting as new issue. Marc G moved to accept proposal to resolve proposed 04 § No objection, proposed 04 closed with proposal to resolve 5.6 Proposed 003NEW Issue: Change default value of fault uri Marc
Goodner Title: Change default
value of fault uri Description: The default
value for the fault uri is set to the default value
of the WS-A faults. WS-A Rec says this value should only be used for WS-A faults. We
need to define our own default uri for faults. Target: core Type: design Proposal: In section 4 change: In section 4 change: Entities that generate
WS-ReliableMessaging faults MUST include as the
[action] property the default fault action IRI defined in WS-Addressing. The
value from the W3C Recommendation is below for informational purposes: http://schemas.xmlsoap.orgwww.w3c.org/ws/20045/08/addressing/fault To: Entities that generate
WS-ReliableMessaging faults MUST include as the
[action] property the default fault action IRI defined below: http://docs.oasis-open.org/ws-rx/wsrm/200604/fault Marc G: someone has asked that the word “default”
be removed. I can agree with that. Doug B: I agree with Peter N comments on
email. If this is a MUST, why is it a default. Marc G: I agree with striking the word default. No objection to accepting as new issue. Tom R moves to accept the following replacement to resolve new issue proposed 02, Gil seconded. Entities that
generate WS-ReliableMessaging faults MUST include as
the [action] property the fault action IRI defined below: http://docs.oasis-open.org/ws-rx/wsrm/200604/fault § Motion to resolve proposed 03 resolved. 5.7 Proposed 02NEW Issue: Duplicate text in fault section Marc
Goodner Title: Duplicate text in
fault section Description: In Section 4 of WS-RM the first
two paragraphs of this section are practically duplicates of each other. Target: core Type: editorial Proposal: The first paragraph can
be stricken by adding a one sentence description of WSRMRequired
after the second sentence of the second paragraph in Section 4. Agreed to accept
proposed 02 as a new issue. 5.8 Proposed 01NEW Issue: Update acknowledgements Marc
Goodner Title: Update acknowledgements Description: In the Acknowledgements, Section E of WS-RM and
Section A of WS-RM Policy, the TBD needs
to be updated to reflect the individuals who contributed to developing the spec
in the TC. Target: core, policy Type: editorial Marc G: we could assign this to an owner, and perhaps Defer. No objections to accepting as a new Issue. 6
Issue Discussion:
6.1
i089 suggest the
restricted use of anonymous URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 Sanjay: Doug D posted the combined proposal on the list. Doug D: I posted a compromise proposal last week. We also had some discussions on the mail list. Jacques: I do not have strong concerns about the proposal, however the corner cases might need clarification. I would like to take another week to nail down the remaining loose ends to resolve my comments on the list. Sanjay: Are your concerns substantive, or are they editorial corrections. Could we accept this today, and work you changes as new issues or comments. Jacques: While I do not want to hold back this issue too long, I am not sure my concerns are editorial. If anyone moved to accept I would abstain, and would submit new issues to resolve any concens. Marc G: I would like another week on this proposal as well. We have been looking at this proposal with our security team. The URI plus UUID method has problems on being secured. We still view this proposal and the entire issue as outside the scope of this TC. Doug B: I agree with both Jacques and Marc G. There have been answers provided on the list to several concerns expressed, but they are not reflected in the text proposed by Doug. This needs to happen to make the text clear. We may need a special majority vote to change the Charter to add this new soap binding. Dave O: If the changes were made, would that make you be in a position to get you to vote yes on the resolution. Doug B: I am pretty sure that there is inefficiency to work on this before we change our charter. Anish: I feel that our use cases put this mechanism within the scope of the charter, particularly the suport a sender behind a firewall. Doug D: I am ok with postponing a week, but forms of the proposal have been out there for quite some time. It is depressing to wait to day of TC call to get any serious comments on it. Sanjay: I agree with Doug D, and ask all TC members to have their comments sent soon on the list. Paul C: lack of email on list does not mean that there is no activity going on. There are lots of out of band discussions and work going on. Jacques: I do not think we should be pressured. This is the major issue we have to deal with, and it deserves sufficient time to resolve properly. I am not sure that this polling must not be visible outside the RM component. Dave O: We could have a number of comments made on this proposal that would make it better. I am leery to put off the vote on this thing, If the comment resolutions will not change anyone’s vote. We know the opinions of Doug B and Marc G, but others seem to be silent. Umit: I move to accept the Compromise proposal from Doug D http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00310.html to Resolve Issue 89, seconded by Martin C Paul C: to Reiterate our concerns, we have spent time to analyze in detail, we are working with our security team and the co-authors to come up with an acceptable solution. I speak in opposition to the motion. Glen D: I have not had sufficient time, I would like another week, while I am in general agreement with the direction. Doug D: I do not want to pressure anyone, however for those who have minor concerns, any text added to the document with a no vote, can be changes by future issues being raised. Dave O: I asked for comments on needing more time, and Glen D responded. Are there others that need more time to make a yes or no decision? I still recommend a yes vote, since the text could be changed. Doug B: I like the Idea about calling the motion on the floor to resolve it. The exact text in the proposal vs a vote on continuing in this direction could be separated. Umit: There are some folks who do not want this approach in the spec at all. I am not convinced that tinkering with this proposal will change their opposition. If we put the text in, we can better deal with resolving specific issues remaining. Paul C: In our technical view, this compromise is a union of other proposals. There are some security risks in part of the proposal. If we put the entire union in, it will be more difficult to take the problem part out of the document. Anish: What are the specific security issues. Paul C: we supplied the comments offline from our security experts to some of the authors of the merged proposal, but have not sent to the TC yet. As soon as our security experts come up with countermeasure for the threat, we could be ready. We could send something to the TC early next week. Dave O: Lets assume the proposal is modified to deal with your security concerns, and all the merger authors agree with your changes, would Paul be in a position to vote yes on the amended proposal. Objection to Unanimous Consent from Paul C. Vote: 19 Yes 9 No § Motion to accept compromise proposal posted by Doug D for resolve issue 89 was accepted. 6.2
b> i121 security threats and requirements
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121 Gil: since I have not completed my action item, I would prefer we do not resolve this today. I intend to post a new proposal by Monday. Sanjay: we should have discussion on the list soon. Chris F: Gil should remove all forward references to other unresolved issue resolutions Paul C: can Gil give us an overview of changes. Gil: For each threat I added expected countermeasures I then discuss soap level security and transport level security, and how each can be used for countermeasures. I also added text relating to “co-ownership” of protection. I also removed section 5.4 and 5.5 from the earlier proposal. Sanjay: could Gil post a summary of his changes to the list before Monday, to allow comments from members. 6.3
c> i122 security profiles
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i122 Gil: there has been a counterproposal for 122, 123 and 124, could the authors review it. Chris F: this proposal http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00036.html is similar to the earlier security token reference text in the submission. A difference is that this new header can be marked with soap:mustUnderstand. There is also a policy assertion to indicate whether this security token feature is to be used. A conformant endpoint need not do anything to support this mechanism, while it does provide security from issuer that it will be used if requested, or the sequence will not be set up. Marc G: Bob raised another issue message 62, wd13 missing resolution to issue 106. Ø Action: editors to determine if issue 106 resolution has been incorporated into the WD. Paul C: this proposal follows advice from TC vote, in that it uses the soap header and the soap:MustUnderstand to indicate to the receiver that a particular form of security is required. Gil: Is it required that the lifetime of the session indicated in the STR be greater than the particular sequence? Marc G: a security context should be less than the lifetime of the sequence. Gil: I pass a STR that references a security context at create sequence time. When it expires, the sequence can still be alive. When the next message comes on sequence after expiry, how does the receiver behave? Stefan: the text should clarify that the security context lifetime should be the same as for the sequence itself. Gil: Then your are saying that the lifetime of the sequence is bounded to the length of the lifetime of the security context. Doug D: one issue with earlier 122 proposals was the overlap of perceived work of WS-I. I am wondering why this does not run into same kind of issues for us defining any specific security profile. Umit: does this mean that is must be understood, and as such is a capability required by all rm implementers. This needs to be discussed. Sanjay: Doug B and Umit should post there questions to the email list. 7 Any other businessnone _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]