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

[Elwyn Davies <[e-mail]>]

Hi, Paul.

Thanks also for the speedy response.

Just two items to consider.. I've deleted all the items where there is
agreement.

Regards,
Elwyn
 
On Wed, 2013-09-25 at 04:25 +0000, Paul E. Jones wrote:
> Elwyn,
> 
> Thanks for the review.  Please see my comments below:
> 
> ------ Original Message ------
> From: "Elwyn Davies" <[e-mail]>
> To: "General Area Review Team" <[e-mail]>
> Cc: [e-mail]
> Sent: 9/23/2013 9:17:42 AM
> 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?
> 
> There will be special considerations for B2BUAs.  REQ3 requires B2BUAs 
> to pass it unchanged.  Of course, there is the possibility that existing 
> devices will not; we cannot change that.  However, devices compliant 
> with the spec should.  The intent is that the solution document will 
> spell out what B2BUAs should do when they receive a Session-ID and when 
> they do not.  This will be fully covered in the solution specification 
> currently being progressed.
Right.. Not being a deep SIP expert, I was not sure if a legacy B2BUA
would pass through a Session-ID added by a non-legacy UA (say, A) when
it created the call to B, which might or might not be legacy.  If it
didn't, does it matter or does it give rise to any requirements?
Presumably the legacy B2BUA would reflect the Session-ID - or if not A
shouldn't complain if it doesn't come back
> 
> >
> >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".
> 
> You're right.  I struggled with placement.  Finally, I decided that it 
> sounds best as the last paragraph of Section 1 (just copying the entire 
> abstract).  Sound OK?
> 
> I could mention "Session-ID" as the name of the header, but this 
> actually could be dangerous.  At present, we're struggling with 
> interworking with an already-existing (and implemented) I-D that uses 
> "Session-ID".  We hope to re-use the same header and provide 
> interworking with that draft.  However, if we find we cannot, we may 
> want to select a different header name.
Your problem here is that Session-ID is used explicitly in the rest of
the document (starting with the title of Section 3 ;-) ).  So I guess
you have to find some form of weasel words like 'tentatively named
"Session-ID"' or '(NSIDIH - new session id identifying header)' and use
NSIDIH instead in the rest of the doc.  
<<snip>>
> 

> >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.
> 
> I changed it to show "UA-A" and "UA-B".  I'm not sure what to put in the 
> lines going left/right to showcase a B2BUA.    Something like this?
> 
>         UA-A                                                  UA-B
>         SIP message(s) ------- [ B2BUAs ] --------> SIP message(s)
>         SIP message(s) <------ [ B2BUAs ] --------- SIP message(s)
> I'm not sure that's more readable.  What did you have in mind?
Maybe just...
        UA-A                     B2BUAs                       UA-B
        SIP message(s) ------- [] --- [] ---------> SIP message(s)
        SIP message(s) <------ [] --- [] ---------- SIP message(s)

> >s3.2, 6th bullets and sub-bullets: Add periods (full stops) at end of 
> >each.
> 
> Periods just at the end of the two sub-bullets starting  with "The call 
> between Alice..."?
Yep.
<<snip>>
> 
> >s4.1: Acronyms UA, B2BUA and SBC need expansion (UA and B2BUA are
> >effectively used in s1. SBC may need a reference (RFC 6135?)
> 
> Did you mean RFC 5853?
Looking at it probably yes!
I was (mindlessly) going on the ref in the RFC Editor's abbreviation
expansion list -
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt
They probably ought to be told this is not the best ref.
<<snip>>
> Thanks!
> Paul
>