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 > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
