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

["Dawes, Peter, Vodafone Group" <[e-mail]>]

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 responses
     *   WIth one typo "intermediaries transmits" (will fix that in the next version)
  *   Changed the UUID values used for OOD REFER (Section 9.9) per list discussion
  *   Added 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