Re: [Insipid] Posted draft-ietf-insipid-session-id-06

["Paul E. Jones" <[e-mail]>]

Peter,

Thanks for the feedback.  I'll try to go through these by the end of the 
day tomorrow; I'm completely consumed with meetings today.

Paul

------ Original Message ------
From: "Dawes, Peter, Vodafone Group" <[e-mail]>
To: "Paul E. Jones" <[e-mail]>; "[e-mail]" 
<[e-mail]>
Sent: 6/19/2014 5:05:23 AM
Subject: RE: [Insipid] Posted draft-ietf-insipid-session-id-06

>Hi Paul,
>
>I have read through the latest session-id solutions draft 
>http://www.ietf.org/id/draft-ietf-insipid-session-id-06.txt and I have 
>the comments below, organized by the line number in the draft. I 
>haven’t yet checked the details of all of the signalling scenarios in 
>clause 9 so I might have some more comments later.
>
>
>
>Rgds,
>
>Peter
>
>
>
>
>
>Line
>
>Draft Text
>
>Comment or Question
>
>95
>
>9.5. Single Focus Conferencing using WebEx ....................16
>
>Is an internet draft allowed to refer to a commercial product, i.e. 
>WebEx?
>
>149 - 152
>
>This draft presents a new identifier , referred to as the Session  
>Identifier, or "Session ID", and associated syntax intended to  
>overcome the issues that exist with the currently defined call  
>identifiers.
>
>It would help to describe the scope of this new identifier, e.g. SIP 
>only, SIP and H.323, or something else.
>
>169 - 171
>
>The terms "Session Identifier" and "Session ID" refer to the value of  
>the identifier, whereas "Session-ID" refers to the header  used to  
>convey the identifier.
>
>It would be clearer to refer to the value using only "Session 
>Identifier" throughout.
>
>170
>
>"Session-ID" refers to the header
>
>Change to "Session-ID" refers to the SIP header field
>
>187
>
>[I-D.ietf-insipid-session-id-reqts] .
>
>Now RFC7206
>
>196 - 197
>
>The version number  in the UUID indicates the manner in which the UUID 
>is generated,
>
>I did not see version number defined in the draft
>
>202 - 211
>
>When generating a version 5 UUID, endpoints or intermediaries MUST
>    utilize the following "name space ID" (see Section 4.3 of 
>[RFC4122]):
>
>        uuid_t NameSpace_SessionID = {
>            /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
>            0xa58587da,
>            0xc93d,
>            0x11e2,
>            0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
>        }
>
>The procedure and syntax being described by the draft are not clear to 
>me.
>
>225 - 228
>
>Note that if an intermediary is stateless and the endpoint on one end
>    of the call is replaced with another endpoint due to some service
>    interaction, the values used to create the UUID might change  and, 
>if
>    so, the intermediary will compute a different UUID.
>
>a) If an endpoint is replaced then I would expect the UUID to always 
>change but the text says "might"
>b) text says "the values used to create the UUID" but the draft does 
>not describe a UUID creation algorithm
>c) text says that intermediary is stateless but also says that the 
>intermediary will compute  a different UUID. Surely a stateless 
>intermediary does not compute a UUID
>
>327
>
>null          = 32("0")
>
>since 32 zeros is a valid UUID, it might be better to use the string 
>"null" for the NULL value.
>
>451 - 454
>
>If an intermediary receives a SIP message without a Session-ID header
>    value , the intermediary MAY assign a "local-uuid" value to 
>represent
>    the sending endpoint and insert that value into all signaling
>    messages on behalf of the sending endpoint.
>
>a) Does the intermediary receive an empty Session-ID header field, or a 
>message with no Session-ID header field?
>b) messages can be originated in both directions, so is it always 
>local-uuid that is assigned or is it sometimes remote-uuid?
>c) the text "all signalling messages" does not seem specific enough 
>e.g. the sending endpoint might initiate a completely new dialog
>
>471 - 473
>
>, the intermediary MUST
>    place the one known UUID in the "remote-uuid" field  and set the
>    "local-uuid" field to the null UUID value.
>
>Might be clearer to say "use the one known UUID as the "remote-uuid" 
>since "remote-uuid" is not a header field or a header field parameter. 
>Likewise for "local-uuid"
>
>493
>
>MUST construct a Session-ID header value
>
>MUST use a Session-ID header value
>
>511
>
>MCUs, including cascaded MCUs ,
>
>Is "cascaded MCU" a well understood term?
>
>543 - 546
>
>Intermediary devices, such as proxies  or session border controllers,
>    or network diagnostics equipment might assume that when they see two
>    or more sessions with different Session Identifiers, but with one
>    UUID in common, that the sessions are part of the same conference.
>
>Maybe proxies should be left off the list of devices that will examine 
>the session identifier
>
>566
>
>"N" represents a null UUID
>
>
>
>585 - 586
>
>UA-Alice populates the "local-uuid" portion of the Session-ID
>         header-value.
>
>This bullet seems to be redundant and could be deleted
>
>554
>
>9. Various Call Flow Operations Utilizing the Session ID
>
>I think it would help if at least one of the signalling examples shows 
>SIP (and maybe SDP). For a while, I was confused about whether 
>"local-uuid" and "remote-uuid" were header field parameters and then 
>wondered why the only IANA registration was for a "remote" parameter.
>
>1423
>
>11. Security Considerations
>
>At the London meeting, security was identified as an open issue that 
>needs to be fully analysed. Does this analysis still need to be done?
>
>
>
>
>
>
>
>From: insipid [mailto:[e-mail]] On Behalf Of Paul E. 
>Jones
>Sent: 10 April 2014 04:53
>To:[e-mail]
>Subject: [Insipid] Posted draft-ietf-insipid-session-id-06
>
>
>
>Folks,
>
>
>
>I just uploaded a revised version of the Session ID solution draft.  In 
>this draft, we did the following:
>
>Added text to Section 7 (intermediaries) to describe handling of 
>provisional responsesWIth one typo "intermediaries transmits" (will fix 
>that in the next version)Changed the UUID values used for OOD REFER 
>(Section 9.9) per list discussionAdded one new paragraph on security 
>considerations
>Please have a look at the draft and suggest other things we need to 
>address, including any issues you believe we need to raise in the 
>security considerations.
>
>
>
>Thanks,
>
>Paul
>
>
>