Last Call Review of draft-ietf-insipid-session-id-reqts-08

Request Review of draft-ietf-insipid-session-id-reqts
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-09-24
Requested 2013-09-12
Authors Paul Jones, Gonzalo Salgueiro, James Polk, Laura Liess, Hadriel Kaplan
Draft last updated 2013-11-15
Completed reviews Genart Last Call review of -08 by Elwyn Davies (diff)
Genart Telechat review of -09 by Elwyn Davies (diff)
Secdir Last Call review of -08 by Magnus Nystrom (diff)
Assignment Reviewer Elwyn Davies 
State Completed
Review review-ietf-insipid-session-id-reqts-08-genart-lc-davies-2013-11-15
Reviewed rev. 08 (document currently at 11)
Review result Ready with Issues
Review completed: 2013-11-15


I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-insipid-session-id-reqts-08.txt
Reviewer: Elwyn Davies
Review Date: 23 September 2013
IETF LC End Date: 24 September 2013
IESG Telechat date: (if known) -

Amost ready with very minor issues/nits.  The only issue that is of any
consequence to my mind is handling of legacy B2BUAs etc. 

Major issues:

Minor issues:
s4.3: I am not clear whether there needs to be any special consideration
if the B2BUA doesn't support Session-ID.  There could be a number of
other cases to consider.  In particular whether the B2BUA would forward
the Session-ID if it didn't understand it.  Does this also affect

Nits/editorial comments:
s1: The purpose of the document is not explicitly set out in s1 -
although of course it is clear in the abstract.  s1 should contain a
near copy of the abstract which also states that the document proposes
requirements for a new SIP header (I assume) called "Session-ID". 

s1, para 2:
> This important fact makes it
>    impossible for call identifiers to be exchanged end-to-end when a
>    network uses one or more session protocols.
I would have thought that using just one session protocol didn't give problems.
Do you mean "... uses more than one session protocol."?

s1, last para: Expand acronym PBX.

s3.1, para 6: s/some constraint/some constraints/ [arguable!]

s3.2, Figure 1: [very nitty] Might be desirable to indicate the
existence of the middlebox(es) on the message arrows 
(e.g.,  .....()..... or some such). Also label A and B as user agents.

s3.2, 4th bullet: s/(e.g., Alice and Bob)/(e.g., between Alice and

s3.2, 5th bullet and sub-bullets:  The 2nd sub-bullet is a bit
confusing:  Maybe:
     o A call between any two user agents wherein two or more user
       agents are engaged in a conference call via a conference focus

         o Each call between the user agent and the conference focus
           would be a communication session

         o Each communication session is a distinct communication
     o A call between any two user agents wherein two or more user 
       agents are engaged in a conference call via a conference focus:

         o each call between the user agent and the conference focus
           would be a communication session, and

         o each of these is a distinct communication session.

s3.2, 6th bullets and sub-bullets: Add periods (full stops) at end of each.

s4.1: Acronyms UA, B2BUA and SBC need expansion (UA and B2BUA are
effectively used in s1.  SBC may need a reference (RFC 6135?)

s4.1: Desirable to specify that "(SIP) dialog" is defined in s12 of RFC

s4.2: Once you have expanded SBC in s4.1 you could use it in s4.2!

s4.3, para 1: s/SIP users, device or domain identity./SIP users, device
or domain identities./

s4.3, para 1: s/or when security issue arise (e.g./or when a security
issue arises (e.g.,/

s4.7, para 1: s/between two or more parties./between two or more parties
other than the one setting up the call./

s7, para 2: s/In adherence with/In adhering to/