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

From: "Dawes, Peter, Vodafone Group" <[email-masked]>
Date: Thu, 19 Jun 2014 09:05:23 +0000

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:[email-masked]] On Behalf Of Paul E. Jones
Sent: 10 April 2014 04:53
To: [email-masked]
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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 19 Jun 2014 18:31:37 +0000

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" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "[email-masked]" 
<[email-masked]>
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
>
>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.
>
>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.
>
>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")
>
>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
>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
>
>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
>
>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?
>
>
>
>
>
>
>
>To:[email-masked]
>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
>
>
>

---

From: James Polk <[email-masked]>
Date: Thu, 19 Jun 2014 16:02:24 -0500

At 04:05 AM 6/19/2014, Dawes, Peter, Vodafone Group wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99870C73C3VOEXM31Winterna_"
>
>Hi Paul,
><http://www.ietf.org/id/draft-ietf-insipid-session-id-06.txt>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.

Peter

Thanks for doing this review.

Comments are in-line with the questions/comments you have...

>line 95

This is only in the examples section of the 
document. Because it is used so pervasively 
throughout the industry, and has a substantially 
different model to other conferencing systems (it 
uses another protocol - the secure form of HTTP), 
we thought it wise to have in the doc (but only in the example text).

>lines 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.

reading the opening paragraphs of the Intro 
section should answer this for anyone

>lines 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.

Sometimes we need to talk about the value "of" 
the header, and others we need to talk about the header itself.

>line 170

I'm not sure what you are getting at, this is a 
SIP doc (ITU's SG16 just introduced its own 
version of the Session-ID header (under H.460) this week).

>line 187

indeed

>I did not see version number defined in the draft

it's one number always, version 5 -- and the present doc does say that.

>lines 202 - 211

look to "Section 4.3 of [RFC4122]" for this

>lines 225 - 228
>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

hmm, I have the only mention of the word "stateless" on line 215...

a) this is only under the condition of the intermediary being stateless.
b) ? , we state the UUID reference RFC for 
creating it several times in this section (RFC 4122, S3)
c) not "that" but "if" an intermediate is stateless.

>line 327
>null          = 32("0")
>since 32 zeros is a valid UUID, it might be 
>better to use the string "null" for the NULL value.

I'll consult with my co-editor and the WG

>lines 451 - 454
>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

a) not empty, "non-existent"
b) always local, except under the conditions of section 10
c) new dialog means new UUIDs in both directions

>lines 471 - 473
>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"

"since "remote-uuid" is not a header field or a 
header field parameter". The local-uuid is a 
header-value and the remote-uuid is a header-parameter, always.

>line 493

what if there isn't a Session-ID: there in the 
first place? Then "use" (something that's non-existent) isn't right.

>line 511

I guess the real question is if the implementor 
understands what the word cascade is. S9.6 gives 
good diagrams of the most common use-cases.

>lines 543 - 546
>Maybe proxies should be left off the list of 
>devices that will examine the session identifier

folks look for proxy when talking about SIP, and 
it it's left off some list involving servers, it'll be a distract (best case)

>line 566

I'll talk to my co-editor about this

>lines 585 - 586

I'm lost here. There are three instances of the 
word "populates", and UA-Alice isn't on page 11 
(line 585-86). There is a "Bob's UUID populates 
the "remote-uuid"... ", which I'd like to keep

>line 554
>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.

Instead of this, look at the top of page 7 for the Session-ID: example.

>line 1423
>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?

We're always open to more comments. The SecAD 
(Sean Turner ?) has been contacted, but hasn't 
gotten back to us or the chairs...

Again, thanks for the thorough review

James

>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)
>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
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid