Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 07 Jan 2015 04:28:37 +0000

Roland,

Also, please accept my apologies for the late reply.  See my comments 
below:

>comment on Abstract
>
>Do we need really the hint to "in the wild" implementation?
>I would propose to refer only to implementations existing based on 
>UUID.
>i.e. the Kaplan draft which is now RFC is within this scope.

I agree that's not desirable.

We now have an RFC for this "in the wild" behavior (RFC 7329).  Is it 
acceptable to refer to the RFC in the abstract?  Perhaps replace "in the 
wild" with "(RFC 7329)"?  Generally there should not be references in 
Abstracts, but I'm thinking that might be helpful in this case.  Or 
shall we just remove the text and have no reference?

>Section 4.1 (and Section 5)
>
>Would it be worth to mention if the Session-id is case sensitive.
>Since when we will need to implement it we have to explicit state it if 
>it is case sensitive or not.

Per RFC 3261, "field names are always case-insensitive". I don't think 
that needs to be repeated here.

>
>I think it would be worth to mention that the UUID is case insensitive 
>as defined in RFC 4122

The text currently states that the UUID characters are lower-case.  The 
syntax also enforces this.  The RFC 4122 text is funny, because it says 
"lower case characters and are case insensitive".  I don't know what 
that means, except that "F" is not a valid character.  Rather than 
create confusing language, I'd rather just leave the text as it is in 
saying the characters are lowercase.

>
>Section 5 (editorial minor)
>
>Text:
>In the case where an entity compliant with this specification is
>    interworking with an entity that implemented [RFC7329], the "remote"
>    parameter might be absent, but otherwise the remote parameter MUST 
>be
>    present.
>
>I would propose to replace might by may. This is from my point of view 
>better for standard ruling if this is a option = may (but the decision 
>I led to the English grammar experts ;-))
>
>Proposal:
>In the case where an entity compliant with this specification is
>    interworking with an entity that implemented [RFC7329], the "remote"
>    parameter may be absent, but otherwise the remote parameter MUST be
>    present.

The reason for using "might" is just to avoid the normative word "may".  
I appreciate that the IETF "MAY" is different than the IETF "may", but I 
prefer to sidestep all confusion by using a word that is not normative.

That said, I'll accept your proposed changes since you think it is 
clearer.

>These are the only comments I have.
>Seen from my point of view the draft is ready for publication.

Thanks!  I am about ready with a new version, as soon as I can resolve 
Brett's comments.  Please watch the list this week for a new version (I 
hope!).

Paul

>
>Thank you and Best Regards
>
>Roland
>
>
>
>>  -----Ursprüngliche Nachricht-----
>>  Von: Jesske, Roland
>>  Gesendet: Montag, 28. Juli 2014 16:00
>>  An: 'Gonzalo Salgueiro (gsalguei)'; [email-masked]
>>  Cc: [email-masked]
>>  Betreff: AW: Reviews for INSIPID Session-ID solution draft
>>
>>  Hi Gonzalo,
>>  I did a review of the draft till section 9.1 Here are my comments:
>>
>>  Section 2
>>
>>  Text:
>>     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.
>>
>>  For me it is not really clear what th3e difference between "Session
>>  Identifier", "Session ID" and "Session-ID" is.
>>  It is really hard to read the whole text in mind of this description.
>>  Somebody who is not aware of the difference will struggle a little 
>>bit.
>>  I would propose to replace all "Session ID" with "Session 
>>Identifier".
>>
>>
>>  Section 4.1
>>
>>  I'm missing some more description in the start of section 4 that a 
>>local
>>  and remote UUID exists.
>>
>>  Old:
>>
>>  4.1. Constructing the Session Identifier
>>
>>     The Session Identifier comprises two UUIDs [RFC4122], with each 
>>UUID
>>     representing one of the endpoints participating in the session.
>>
>>  Proposal:
>>
>>  4.1. Constructing the Session Identifier
>>
>>    RFC4412 describes the construction of the Universally Unique
>>  Identifier (UUID).
>>     The Session Identifier comprises two UUIDs [RFC4122], with each 
>>UUID
>>     representing one of the endpoints (local UUID and remote UUID)
>>  participating in the session.
>>
>>  Section 4.1 uuid_t
>>
>>  This text:
>>  ...
>>
>>     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
>>         }
>>
>>  ...
>>
>>  Is/was hard to understand what is here meant by. So if I understand
>>  correctly this is the specific name space definition for our "Session
>>  ID". Thus this is used to calculate our Session-ID/UUID local/remote.
>>
>>  So I would propose to change the following text:
>>
>>  New proposal:
>>     When generating a version 5 UUID, endpoints or intermediaries MUST
>>     Follow the procedures described in Section 4.3 of [RFC4122]. The
>>  following "name space ID" MUST be taken for the calculation of the 
>>UUID.
>>
>>     /* Name string is a Session ID */
>>       uuid_t NameSpace_SessionID = {
>>             /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
>>             0xa58587da,
>>             0xc93d,
>>             0x11e2,
>>             0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
>>         }
>>
>>
>>
>>  Section 4.2 first Paragraph:
>>  ...
>>
>>
>>  ABNF: Section 5 (1st comment)
>>  This draft defines the header "session-id" (ABNF: session-id =
>>  "Session-ID" HCOLON local-uuid) while I-D.kaplan-insipid-session-id
>>  defines the header "Session-ID" (ABNF Session-ID = "Session-ID" 
>>HCOLON
>>  sess-id*( SEMI generic-param )).
>>  Seen from syntax there is no difference with regard to the value both
>>  are 32 bytes (32(DIGIT / %x61-66) ;32 chars of [0-9a-f]) Was this 
>>done
>>  by purpose or does this not care?
>>
>>
>>  ABNF: Section 5 (2nd comment)
>>  The definition sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-
>>  f] is shown, but there is no real hint that this value is at least 
>>the
>>  built UUID regarding RFC4412. I think we should spent some words of
>>  clarification.
>>
>>
>>  Section 6:
>>
>>  Reading this text is a little bit hard to distinguish the UAC/UAS
>>  behavior. I think it would be worth to spend a little bit more words 
>>to
>>  describe the UAC/UAS behavior in addition. Like what happens in the
>>  Initial request seen from UAC and first response from UAS.
>>
>>  Section 7 3rd paragraph:
>>
>>  Text:
>>     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. If the intermediary is
>>     aware of a "remote" value that identifies the receiving UA, it 
>>MUST
>>     insert that value if also inserting the "local-uuid" value.
>>
>>  Perhaps a note would be valuable what such intermediary (e.g. Network
>>  border) could be.
>>  e.g.
>>  Note: Such an intermediary could be an entry point interconnecting to 
>>a
>>  network belonging to another domain or service provider which is not
>>  supporting the Session ID.
>>
>>  Would it be also worth to mention the Interworking behavior between
>>  PSTN/ISDN and SIP?
>>
>>  Section 9. /9.1
>>
>>  Would it be worth to show one example Request INVITE and on response.
>>  I know it is redundant text but people like to see an example to show
>>  how it looks like.
>>
>>  e.G.
>>
>>  INVITE sip:[email-masked] SIP/2.0
>>        Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
>>        From: Alice <sip:[email-masked]>;tag=1234567
>>        To: Bob <sip:[email-masked]>
>>        Call-Id: [email-masked]
>>        Session-ID: ab30317f1a784dc48ff824d0d3715d86;
>>             remote=00000000000000000000000000000000
>>        CSeq: 1 INVITE
>>        Contact: <sip:[email-masked]>
>>
>>    SIP/2.0 200 OK
>>        Via: SIP/2.0/UDP b2bua.atlanta.com
>>           ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
>>        Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
>>        To: Bob <sip:[email-masked]>tag=a6c85cf
>>        From: Alice <sip:[email-masked]>;tag=1234567
>>        Call-Id: [email-masked]
>>        Session-ID: ab30317f1a784dc48ff824d0d3715d86;
>>                    remote=47755a9de7794ba387653f2099600ef2
>>        CSeq: 1 INVITE
>>        Contact: <sip:[email-masked]>
>>
>>  So that are my comments till 9.1.
>>
>>  Editorial
>>  Page 8 last paragraph responseand --> response and Page 15 1st 
>>Paragraph
>>  and following is "passcode" correct or should it be "pass code" ?
>>  Page 25 last Paragraph "The authors would like to than" --> "The 
>>authors
>>  would like to thank"
>>
>>
>>  Best Regards
>>
>>  Roland
>>
>>  -----Ursprüngliche Nachricht-----
>>  Von: insipid [mailto:[email-masked]] Im Auftrag von Gonzalo
>>  Salgueiro (gsalguei)
>>  Gesendet: Donnerstag, 24. Juli 2014 18:50
>>  An: [email-masked]
>>  Cc: [email-masked]
>>  Betreff: [Insipid] Reviews for INSIPID Session-ID solution draft
>>
>>  Hi -
>>
>>  The chairs met and had a WG sync while here in Toronto. Conversations
>>  with the draft authors clearly indicate that we are getting very 
>>close
>>  to WGLC for the Session-ID draft (http://tools.ietf.org/html/draft-
>>  ietf-insipid-session-id). The chairs feel it would be helpful if we
>>  were to get additional reviews prior to WGLC. We have proactively
>>  reached out specifically to some obvious review candidates but we 
>>would
>>  welcome and appreciate partial or complete reviews from anyone in the
>>  WG.
>>
>>
>>  Cheers,
>>
>>  Gonzalo
>>  (as co-chair)
>>  _______________________________________________
>>  insipid mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/insipid
>
>_______________________________________________
>insipid mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/insipid

---

From: <[email-masked]>
Date: Thu, 22 Jan 2015 07:47:13 +0100

Hi Paul,
Thank you for your mail.
I also needed some time now to look on you proposals.

Comments see below:

Roland
-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [mailto:[email-masked]] 
Gesendet: Mittwoch, 7. Januar 2015 05:29
An: Jesske, Roland; Jesske, Roland; [email-masked]; [email-masked]
Cc: [email-masked]
Betreff: Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11

>shall we just remove the text and have no reference?

[RJ] OK for me

>that needs to be repeated here.

[RJ] I looking here from Operator point of view. We have so many discussions about the case (in-) sensivity of fields with vendors who should know. I'm partly OK with your proposal. But nevertheless it will led to wrong implementations seen from my experience with vendors. And the point the following point will confuse a little. On one point we say UUID lower case but RFC3261 points that header filds are case insensitive. Thus I would at least prefer a note.

>saying the characters are lowercase.

[RJ] OK

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Jan 2015 09:42:09 -0500

>> saying the characters are lowercase.

The *safest* (belt and suspenders) way of dealing with this would be to 
require that senders always insert lower case, but require that 
receivers properly process either upper/lower case.

IMO it *should* always have been case-insensitive. IIRC the reason it 
isn't that way is because Kaplan was case sensitive and there are 
implementations in the wild that depend on it.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:49:31 +0000

Roland,

>[RJ] I looking here from Operator point of view. We have so many 
>discussions about the case (in-) sensivity of fields with vendors who 
>should know. I'm partly OK with your proposal. But nevertheless it will 
>led to wrong implementations seen from my experience with vendors. And 
>the point the following point will confuse a little. On one point we 
>say UUID lower case but RFC3261 points that header filds are case 
>insensitive. Thus I would at least prefer a note.

I'm open to adding anything that will add clarity.  At the end of the 
last paragraph in Section 5 seems to be the right place, since that is 
where we explain that the UUID is lower-case hexadecimal characters.   
However, what I'm not sure about is what else to say.  If you can 
suggest text that makes this clear, I would appreciate it.

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:53:48 +0000

Paul,

>implementations in the wild that depend on it.

I just looked at RFC 7239 and found this:

    NOTE: The sess-id value is technically case-INSENSITIVE, but only
    lowercase characters are allowed.

Shall we include the same text in our draft?

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 23 Jan 2015 04:58:16 +0000

Specifically, how about this at the end of section 5?

NOTE: The Session-ID header-value is technically case-INSENSITIVE, but 
only lowercase characters are allowed in the sess-uuid components of the 
syntax.

------ Original Message ------
From: "Paul E. Jones" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; [email-masked]
Sent: 1/22/2015 11:53:48 PM
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft 
Version 11

>>The *safest* (belt and suspenders) way of dealing with this would be 
>>to require that senders always insert lower case, but require that

---

From: <[email-masked]>
Date: Fri, 23 Jan 2015 07:45:02 +0100

For me OK.

Best Regards
Roland

-----Ursprüngliche Nachricht-----
Von: insipid [mailto:[email-masked]] Im Auftrag von Paul E. Jones
Gesendet: Freitag, 23. Januar 2015 05:58
An: Paul E. Jones; Paul Kyzivat; [email-masked]
Betreff: Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11

NOTE: The Session-ID header-value is technically case-INSENSITIVE, but only lowercase characters are allowed in the sess-uuid components of the syntax.

------ Original Message ------
From: "Paul E. Jones" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>; [email-masked]
Sent: 1/22/2015 11:53:48 PM
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft Version 11

>Paul,
>
>>>>>I think it would be worth to mention that the UUID is case 
>>>>>insensitive as defined in RFC 4122
>>>>
>>>>syntax also enforces this. The RFC 4122 text is funny, because it 
>>>>says "lower case characters and are case insensitive". I don't know 
>>>>what that means, except that "F" is not a valid character. Rather 
>>>>than create confusing language, I'd rather just leave the text as it 
>>>>is in saying the characters are lowercase.
>>>
>>>[RJ] OK
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Jan 2015 10:54:45 -0500

> only lowercase characters are allowed in the sess-uuid components of the

Its better than nothing. But I think it would be better to make a 
normative requirement to support reception of uuids in either case, 
while requiring that they be sent in lower case. This makes it clear 
that it is only an accommodation to non-conforming implementations.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Sat, 24 Jan 2015 00:49:47 +0000

OK.  How about this?

"The Session-ID header-value is technically case-INSENSITIVE, but only 
lowercase characters are allowed in the sess-uuid components. Receiving 
entities MUST treat sess-uuid components as case-insensitive and not 
produce an error if an uppercase character is received in a sess-uuid."

Do you have better wording than "component"?  I don't like that, but I 
guess that's clear.  I'm open to suggested changes.

Paul

------ Original Message ------
From: "Paul Kyzivat" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; [email-masked]
Sent: 1/23/2015 10:54:45 AM
Subject: Re: [Insipid] Reviews for INSIPID Session-ID solution draft 
Version 11

>>>>>>says

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Jan 2015 10:34:43 -0500

WFM