Re: [Insipid] 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:bob@example.com SIP/2.0
      Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
      From: Alice <sip:alice@example.net>;tag=1234567
      To: Bob <sip:bob@example.com>
      Call-Id: 123456mcmxcix@1.2.3.4
      Session-ID: ab30317f1a784dc48ff824d0d3715d86;
           remote=00000000000000000000000000000000
      CSeq: 1 INVITE
      Contact: <sip:alice@192.168.1.1>

  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:bob@example.com>tag=a6c85cf
      From: Alice <sip:alice@example.net>;tag=1234567
      Call-Id: 123456mcmxcix@1.2.3.4
      Session-ID: ab30317f1a784dc48ff824d0d3715d86;
                  remote=47755a9de7794ba387653f2099600ef2
      CSeq: 1 INVITE
      Contact: <sip:bob@192.0.2.4>

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:insipid-bounces@ietf.org] Im Auftrag von Gonzalo Salgueiro (gsalguei)
Gesendet: Donnerstag, 24. Juli 2014 18:50
An: insipid@ietf.org
Cc: insipid-chairs@tools.ietf.org
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
insipid@ietf.org
https://www.ietf.org/mailman/listinfo/insipid