[Insipid] FW: Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt

["DRAGE, Keith (Keith)" <[e-mail]>]

As part of the IETF review process, internet drafts get reviewed by a number of people.

This is the gen-art review.

Regards

Keith

-----Original Message-----
From: Elwyn Davies [mailto:[e-mail]] 
Sent: 23 September 2013 14:18
To: General Area Review Team
Cc: [e-mail]
Subject: Gen-art LC review of draft-ietf-insipid-session-id-reqts-08.txt

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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) -

Summary:
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:
None.

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
SBCs?    

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
Bob)/ 

s3.2, 5th bullet and sub-bullets:  The 2nd sub-bullet is a bit
confusing:  Maybe:
OLD:
     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
           session
NEW
     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
3261.

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/