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

[Elwyn Davies <[e-mail]>]

Hi, Paul.
[Resend to all addressees]

We seem to be converging...

On Wed, 2013-09-25 at 22:22 +0000, Paul E. Jones wrote:
> 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.  
OK.. that is what I suspected would be the case.

It doesn't answer the question as to whether the SBC would always
reflect the SID back to A, and if it didn't might A get upset.  And
hence is it a requirement that A should bite its lip rather than
complaining if the SID doesn't come back?

> 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).
This is indeed an admirable aim.
> 
> >>  >
> >>  >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".
That also solves your problem. Excellent.
> 
> >>  >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.
Fine.

Cheers,
Elwyn

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