[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-rx] Prelim minutes of WSRX TC Teleconf june 08
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.
I believe DougB said this, not me.
-DougD
Tom Rutt <tom@coastin.com>
06/08/2006 05:42 PM
|
|
Textual Conventions
Ø Action
Item
Motion
§ Resolution
1 Roll Call
From Kavi:
Over 42 of voting members, meeting is quorate
Tom Rutt agreed to take minutes.
2 Agenda Approval
Agenda:
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
§ No
objection minutes for 6/1 meeting approved.
4 Administrative
4.1 AI Review
http://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 review
Marc 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
Volunteers
BEA
Nortel
Microsoft
Need others for future.
5 New issues
since last conf-call
5.1 Proposed 08
From 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 07
From 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 003
NEW 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 02
NEW 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 01
NEW 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
business
none
_______________________________________________________________________
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]