[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of 7/6 teleconf
Prelim minutes of 7/6 teleconf are attached. Plese post corrections to 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: Minutes of OASIS WS-RX Teleconference
Prelim
Minutes of OASIS WS-RX Teleconference July
6, 2006 Start Time:4:00 PM Eastern
Daylight Time Paul F acted as chair. Textual Conventions Ř Action Item Motion § Resolution 1 Roll CallFrom Kavi: Over 27 of 4x 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 June 29th
meeting minutes http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/19031/MinutesWSRX-062906.html
4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php
5) Administrative Schedule tracking 6) New issues since last conf-call Watch for Marcs email 7) Update from the editor’s 8) Issue Discussion: k>
i139 Inappropriate Fault destination http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i139
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> i113 Tightening up the state
tables http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i113
g> i147 Extensibility (or not)
of the Protocol Elements http://lists.oasis-open.org/archives/ws-rx/200606/msg00225.html
h> i140 add sub-headings to
fault descriptions http://lists.oasis-open.org/archives/ws-rx/200606/msg00190.html
k>
i143 messages have to be received for them to beexamined: with new highlighting http://lists.oasis-open.org/archives/ws-rx/200606/msg00200.html
j> i144 RMS MessageNumberRollover
behavior unclear http://lists.oasis-open.org/archives/ws-rx/200606/msg00212.html
k> i145 Implications of Sequence
Expiration not specified http://lists.oasis-open.org/archives/ws-rx/200606/msg00216.html Bob F asked that issue 140 be deferred to next week. Anish: 122, 123 and 124 could be deferred. Marc G: I do not understand the rationale to delay. The proposals for 121, and for 122-124 have been out there for some time. I do not see why we should Tom R: what about putting a time limit on discussion for each of these. Paul F: I would like to spend time towards resolving each issue. Anish: There have been conversations going on about 122 123 124, involving liaisons with ws-SX. Others (Pratik and Martin R) are working on proposals for these three issues, but cannot send until next Monday. More email is required for these three issues. Anish: I might be worth discussion 121 on the call, but I would hope that we get to an AI on revised proposal to vote on next week. Paul C: I thought the proposal from Pratik and Martin R was on 121 thread. Anish: yes but it relates to the other issues. Paul F: these proposals have been around a significant amount of time. I do not like to delay just because people have not provided a proposal. Chris F: Why are we delaying further? I has been kicked around both in and out of
committee. Paul F give 122-124 thirty minutes each. Anish: I want to clarify that there has been quite a bit of activities lately. Pratik has been talking to several people. I would be ok with time bounding. Paul F: give 30 minutes from when we get to it. Anish: I suggest a reorder then. Paul C: I am against a reorder. Paul F: these are crucial issues to resolve before progressing. If there is agreement at 80% level, we can save the effort of an alternative proposal. Anish: We would like to do that effort, to let the TC see the alternate proposal, whether it is accepted or rejected. Paul F: I suggest we continue in the order. Anish I object we move to end. Paul F: Straw poll on moving 122-124to end: 14 leave 8 Move. Agenda stays. 3 Approval of the 6/29 minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/19031/MinutesWSRX-062906.html Bob F moved, Tom R seconded to approve 6/29 minutes. § No objection minutes for 6/29 meeting approved. 4 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #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: --- -------------------------------------------------------------------------------- #0106: Bob address polling in the state tables (once the
first round of state table changes are stabilized) Owner: Robert Freund Status: Still Open Assigned: 2006-07-03 Due: --- Bob F: There are two ways to put polling into state tables. configuring event causes get message to be transmitted does not fit into the context of a sequence beneath it. I am drifting to make it a separate underlying state table, transport aware, and perhaps dealing also with retrial. Paul F: I have a simple view on that. I will contact you out of band. -------------------------------------------------------------------------------- #0107: Bob and Anish to develop
proposal for i140 resolution Owner: Robert Freund Status: Still Open Assigned: 2006-07-03 Due: --- -------------------------------------------------------------------------------- #0108: Doug B to send note describing his thoughts on the
extensibility of Protocol Elements Owner: Doug Bunting Status: Still Open Assigned: 2006-07-03 Due: --- 5
Administrative
Schedule tracking Paul F: we are running a month behind our last published
schedule. We should push hard to close
remaining issues over next few weeks, to get public review initiated. 6
New issues since last conf-call
None 7
Update from the editor's
Doug D: all the issues have been incorporated in the latest editors drafts. We do not have a new update for the state tables yet. Marc G will post a new issues list after the meeting. 8
Issue Discussion:
8.1
i139 Inappropriate
Fault destination
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i139 Agreed to defer to when Jacques returns from leave of absence. 8.2
b> i121 security threats and requirements
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i121 Gil: I sent the new proposal out http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00000.html There have been some email discussion on this, with minor issues regarding encryption. I suggest we give this one more week before voting on a resolution. Paul F: Are the discussions significant or minor Gill: the only significant disagreement is on references to things in ws-sx. We should apply minor edits, and vote on that next week. Tom R: by our charter we cannot refer to specs which are not ready, but can instead give a more abstract specification within the context of WS-RX. Some of the discussions have suggested we indicate our interpretation of where WS-SX is moving, and include this in the WS-RX spec, as necessary to help interop. Anish: The token ref in create sequence should not be referenced as a SHOULD in the text for 121. Paul C: if all the techniques were listed would you be concerned. Anish: I would prefer that all be listed if there is a SHOULD recommendation. Marc G: unique refs vs local refs to tokens is one issue in SX tx. I am confused about three techniques in SC, as mentioned by Anish. I do not agree with linking this to that issue. Anish: I might be confused, but section 8 of SC does talk about these techniques. Marc G: there is only one for the linking of SC to particular message. Anish: I will send an email asking for any particular changes to the proposal. Marc G: WS-RX should not describe how the SC is composed. Paul C: I would like to amend the proposal now the get the issue flattened. I think we can fix the problems right now. Gil: Bullet point 2 of 5.2.2.1 model for secure conversations: two ways to decide which token 1) Implicitly – create sequence in context, keeps that context 2) Explicitly – put SC token into create sequence. Having two ways to tie SC to rm sequence makes two different mechanisms required to interop. Regarding three mechanisms for secure conversation, I have not referenced the creation or maintenance of a secure conversation, or security session. I think reintroducing TLS is simple, as are some others. However Pratik was asking for an explicit list of what needs to be signed or not signed, and this would required adding a table. Paul C: is that last change additive and could be a new issue. Gil : yes it could. Chris F: I move we accept the proposal for I121 and later amend it, Marc G seconded. Martin R Discussion: on multiple ways to create token, have a relationship to intended usage of token. Anish: I am surprised Paul C is asking to close an issue with changes where we do not have exact text. Anish: It might be better to have headers point to bodies. We can talk about embedding the scr in create sequence message. For explicit you could either put the token in a header or could use pointing to the create sequence in the body. Umit I object the motion. Paul C: I Move we could amend by including Changes 41 for encryption and ssl changes in message 28, seconded by Marc G http://lists.oasis-open.org/archives/ws-rx/200607/msg00041.html http://lists.oasis-open.org/archives/ws-rx/200607/msg00028.html Anish: I still would rather wait until next week to vote on this. Marc G: the SX TC does not even have CDs, so asking for a delay on this proposal seems inappropriate. They could be added to the things being described now. § No objection to accepting amendment from Paul C. Chris F: I do not see why the other changes could not be made using this proposal as a basis. We should make substantial progress if possible. Martin R: I was not referencing new mechanisms in WS-SX, the mechanism is in the submitted document and the editor’s draft. Gil: with regard to the bullet point Anish has a problem with, it is tricky. You want to lead the discussion to what you think must be done. This is the part that ties to 122-124. We can agree to put something there, which might be need to be changed after resolution to 122-124. Anish: I would prefer we leave the bullet out, and add it later after agreement on 122-124. Paul C : I suggest we proceed with a vote. Anish: I suggest that we remove the 5.2.2.1 bullet be removed. Not seconded. Gil: the text makes no sense with that bullet missing. We should instead have wording to make more general. Anish: I would rather have a bullet 2 which is more abstract. Gill: So 39-41 will read: Integrity threats are generally countered via the use of digital signatures at some level of the communication protocol stack.
Anish moved to ammend, seconded by Chris F: replace bullet 2 with: The RM source SHOULD explicitly identify the security context that will be used to protect the Sequence. anish + This is done so that, in cases where the CreateSequence message is signed by more than one security
context, the RM Source can explicitly indicate which security context should be used to protect the newly created
Sequence. § Anish amendment accepted. § No objection to close issue i121 with motion including three changes in two amendments. 8.3 issues i122-124c> 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 Marc G: there have been minor updates posted as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200607/msg00036.html . The Header does not make sense with mustUnderstand not equal true, so this was changed. I added text pointing to the WS-SC drafts. SCR Reference concerns expressed by Gil, I added text to state you SHOULD use unique identifier. Anish: uses Sequence STR, why is SHOULD not MUST. Marc G: I discussed this with Sanjay on list, the fact that Create Sequence has extensibility point, a MUST is too strong. Anish: This MUST is conditional, if you use the extensibility defined above, you MUST use it. Marc G: I could accept a conditional MUST there, but prefer the SHOULD. Chris F: I move to accept Marc G proposal with conditional MUST for header, seconded by Marc G. Gil: I have some specific concerns on the current proposal, but have not had time to provide replacement text. How does RMS say I am using TLS session for sequence in this proposal. My concerns could be raised as separate issues. Marc G: I recall these conversations. We could define a well known URI to use in STR saying to use credentials in TLS. This could be defined within WS-SX TC, independent of what we need to do. Another way is a parallel header binding to a tls sessions. Both of these warrant further discussion, based of the resolution text to this issue. Chris F: everyone has been operating in good faith, and we may need to provide some further tweeks, but I would prefer we make progress. Points can be made to these other TCs which can provide solutions. Gil: while a ref to tls session may seem simple, I would not like this spec to go out with this issue in the air. While I agree it could be done in the future, I would be more comfortable with us defining a mechanism to use TLS session this sequence was set up within. Anish: I agree with Gil. The implementation may not recognize ws-sc, if it uses TLS. Paul F: are there objections to motion on floor. Ran out of time for completion of vote on
motion. --------------- No time for remaining issue discussions. _______________________________________________________________________ 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]