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

["Paul E. Jones" <[e-mail]>]

Elwyn,

Comments below:

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

What a deployed SBC will do varies.  Some might pass the header value 
through and some might not.  We already know that some definitely would 
not.  If a deployed SBC does not pass the header through unmodified, 
then it "breaks" the end-to-end identifier.  We know that and it is one 
of the reasons for doing this work.  We want something that could be 
used end-to-end if domain owners will allow it.  Other values are not 
necessarily safe to use end-to-end (e.g., they might leak personal 
data).

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

I can fix this rather easily.  I'll change "Session-ID" to "session 
identifier".  In no place are we explicitly referring to the header 
itself, but just the "identifier".

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

OK, done.

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

OK, I'll insert an informative reference to that spec.

Paul