Elwyn, I went ahead and published an update that incorporates your feedback.
https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-25 <https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-25> Note that I chose not to include the definition of communication session in the draft because paragraph 1 of section 3 already references RFC7206 for the definition. Hopefully this addresses your concerns. -Paul > On Aug 4, 2016, at 6:17 PM, Elwyn Davies <elw...@folly.org.uk> wrote: > > > Hi. > > Thanks for the very rapid response. > > Most of this looks just fine. > > Couple of points: > - On the conference CANCEL issue: My SIP knowledge is severely lacking... > could the CANCEL ever apply to the original INVITE? If not it is probably > sufficient just to remind people that the M' UUID would be used once the > conference was joined. I guess you might want to use M1 etc if the conferece > joining failed in some way. In any case I'd add a few words to clarify which > UUID they should be using - I'm not sure it is totally obvious. > > - On the s11 nit.. whether you need to do something here depends on what the > decision on the spec of sess-uuid settles as. > > I'd be happy to scan a pre-release of the updated draft before publishing if > you send it along. > > Cheers, > Elwyn > > Sent from Samsung tablet. > > -------- Original message -------- > From: "Paul Giralt (pgiralt)" <pgir...@cisco.com> > Date: 04/08/2016 21:40 (GMT+00:00) > To: Elwyn Davies <elw...@folly.org.uk> > Cc: General area reviewing team <gen-art@ietf.org>, > draft-ietf-insipid-session-id....@ietf.org > Subject: Re: Gen-art LC review of draft-ietf-insipid-session-id-24 > > Elwyn, > > Thank you for the review. We should be able to address these issues. See my > comments inline.. > > >> >> Minor issues: >> Interoperability with H.323 >> The requirements for the Session Identifier [RFC7206] Section 4.2 stresses >> interoperability with H.323. This is mentioned in passing in s1 and in a >> bit more detail in s3. I think it would be worth mentioning this somewhat >> more prominently and that the relevant interoperability will potentially be >> achieved since the format of the Session-ID in H.460.27 appears to match the >> one defined in this draft. To this end, I suggest: >> - Mentioning the interoperability in the abstract and stating the ITU rec >> number - this effectively indicates its 'use' in H.323 per the end of para 1 >> in the abstract. >> - Say a bit more about about interoperability in s1, mention H.460.27 and >> give it as a reference there also. >> > > ok - sounds reasonable. > > > >> GIven that H.323 now supports the use of Session Identifiers, it might be >> useful to indicate how Session-IDs need to be handled at SBCs [Caveat: I am >> not a SIP expert and this may be trivial, but I think something probably >> needs to be mentioned.] >> > > > An SBC interworking between H.323 and SIP should still follow the rules of an > intermediary. This draft will define its behavior for the SIP call leg and > H.460.27 will define its behavior for the H.323 call leg. I can put some > verbiage to this effect. > > >> s4.1: Para 2 mentions the possible use of Version 4 or Version 5 UUIDs. The >> last para constrains stateless intermediaries to using Version 5 UUIDs 'to >> ensure consistent generation'. I am confused about whether this >> consistency would be maintained if endpoints and/or stateful intermediaries >> generated Version 4 UUIDs, or whether in fact all UUIDs should be Version 5? >> > > > Both Version 4 and Version 5 UUIDs would be maintained for endpoints / > stateful intermediaries because they can retain the value of the generated > Version 4 UUID as part of that state. The reason stateless intermediaries > must use Version 5 is they need a way to generate the same UUID for the > session without storing the UUID between messages and a Version 4 UUID would > not provide this consistency. > > >> s8, bullet 5, s6 , s7 and s9: If an endpoint is involved in a multi-point >> conference has to send a CANCEL message, which remote UUID should it be >> using? The one that came back with the original INVITE response or the one >> used to identify the conference that is sent in the re-INVITEs from the >> conference focus? (e.g., in s10.4, for Alice M1 or M'). [Note lack of SIP >> expertise: I am not sure if there are circumstances in which this would >> arise.] > > > CANCELling a re-INVITE would be unusual and unlikely to happen in the > scenario you describe, but is technically possible. As mentioned in s8, > bullet 5, the Session-ID header field value in the CANCEL request MUST be > identical to the Session-ID header field value in the corresponding INVITE. > In this case, because the CANCEL corresponds to the re-INVITE, the Session-ID > header field value would be that of the re-INVITE, as that is the transaction > being cancelled. I think the draft as it stands is clear enough on the > expected behavior but can modify if you feel strongly that this should be > clarified. > > >> >> Nits/editorial comments: >> s1, paras 1 and 3; s2, last para : s/like/such as/ (total of 3 places) >> > > Will change. Thanks. > > >> s2: There is no definition of the term 'communication session' in the >> draft. A definition is given in s3.2 of RFC 7206 and H.460.27 has: >>> 3.2.1 communication session: A communication session, or simply >>> ''session'', refers to a call or series of calls initiated or received by >>> an endpoint for which the endpoint utilizes the same universally unique >>> identifier (UUID) value in call signalling messages. From a calling user's >>> perspective, this would be all call signalling messages from the time the >>> user initiates a call until the time the call is terminated. From the >>> called user's perspective, this would be all call signalling messages from >>> first message received by the user's terminal until the call is terminated. > > > I’m good with copying this text from 7206 into Section 2. > > >> In the light of the interoperability question, should the definition say >> something about SBCs? And how the session identifier is >> generated/interpreted in a 'session' that extends across an interconnected >> SIP/H.323 network? Would SBC be an 'intermediary' within the meaning of the >> definition in s2? >> > > Yes, it would be considered an intermediary except Section 2 specifically > calls out intermediaries as being “any SIP entity”. It might be softening the > language there to include any intermediaries that are interworking between > SIP and another protocol that also supports the Session Identifier defined in > this draft. > > Section 7, which discusses the behavior of intermediaries, already notes that > SBC’s are a type of intermediary, so don’t think we need to make that callout. > > >> s2, last para: The expansion of the B2BUA acronym occurs on the second >> instance rather than the first that is a couple of lines earlier. > > Good catch. Thanks. > >> >> s4.2, end of para 2 and in many places thereafter: The 'null UUID' is known >> as the 'nil UUID' in s4.1.7 of RFC 4122. For consistency s/null/nil/g. A >> reference to s4.1.7 of RFC 4122 should be added to the first instance in >> s4.2. > > > Thanks for this. I wasn’t aware of this and makes sense to use consistent > naming from 4122. > > >> >> s5: Given that RFC 7329 will be obsoleted by this document, it would be >> desirable to copy the gist of the statements in the first para of s7 of RFC >> 7329: >>> This document adds the "Session-ID" token to the definition of the >>> element "message-header" in the SIP message grammar. The Session-ID >>> header is a single-instance header. >> Something like an additional para at the beginning of s5: >> This document replaces the definition of the "Session-ID" token that was >> added to the definition of the >> element "message-header" in the SIP message grammar by [RFC7329]. The >> Session-ID >> header is a single-instance header. >> > > > Sounds reasonable. I can add something along those lines for clarity. > > > >> s5, para 3: >> OLD: >> The UUID values for each endpoint are inserted into the "Session-ID" >> header field of all transmitted SIP messages. >> >> This is potentially confusing when it comes to conference calls as there may >> be more than two endpoints involved in a communication session if it is a >> multi-point conference. Maybe >> NEW: >> Any SIP message associated with a communication session has the UUIDs for >> the session created by the message source and destination endpoints inserted >> into the "Session-ID header field of the transmitted SIP message. >> END >> > > > Let me see how I might be able to clarify this for the multipoint use case > where there are more than two endpoints in the session. I don’t think your > new version is as clear as it could be either. > > >> s5, last para: >>> The Session-ID header field value is technically case-INSENSITIVE, >>> but only lowercase characters are allowed in the sess-uuid >>> components. Receiving entities MUST treat sess-uuid components as >>> case-insensitive and not produce an error if an uppercase hexadecimal >>> character is received. >> I know this is partly carried over from RFC 7329, but, as currently drafted, >> it seems pointless. Can we not just have: >> >> sess-uuid = 32(DIGIT / %x41-46 / %x61-66) ;32 chars of [0-9A-Fa-f] >> >> If the reasoning is that sending upper case to 'old' implementations will >> break them, then it would be better to be explicit about it. Perhaps, >> replace the para with: >> To allow interoperation with implementations conforming to the >> pre-standard specification in [RFC7329], implementations SHOULD use >> only lower case letters ("a" - "f") in the sess-uuid field. >> > > > To be honest I’m not sure why this was written this way originally and, like > you say, it was just carried over from 7329. Will look into whether we should > make a change here. > > >> s6, para 2: There could be some minor confusion as to whether the 'no change >> of UUID' rule is broken when a conference focus (per s9 and the examples in >> s10) changes its UUID after processing the initial INVITE and issuing a >> re-INVITE with a different UUID associated with the conference. Some words >> covering (I guess) the idea that the conference itself is a different >> communication session from the setup request(s) would be useful. See also >> the comments on s10.4 in Minor Issues above. > > > Section 6 describes Endpoint behavior so don’t think a change is needed > there, but could possibly add some text in Section 9 that describes what is > shown in the example in section 10.4. > >> >> s6 and s7, next to last paras: These are near duplicates. They could be >> replaced by a single instance at the end of s5, but no big deal. >> > > > I’m not totally sure if it makes sense as-is in section 5, but could probably > modify slightly to make it fit into section 5. > > >> s7, para 12: Expand 3PCC on first use. >> > > > Will do. Thanks. > > >> s7, para 12: s/locally-frabricated/locally-fabricated/ > > > Thanks. > > >> >> s8, bullet 5: s/487/Request Terminated (487 - see Section 15.1.2 of >> [RFC3261]) >> > > Ok. Thanks. > > >> s10.1, start of expansion of SIP messages: >> I think there is a missing 'example.'... >> OLD: >> INVITE sip:b...@biloxi.com <mailto:sip:b...@biloxi.com> SIP/2.0 >> NEW: >> INVITE sip:b...@biloxi.example.com <mailto:sip:b...@biloxi.example.com> >> SIP/2.0 >> END >> > > > Nice catch. Thanks! > > >> s11: Effectively there is another new/old requirement: the sess-uuid field >> has to use lower case letters (probably). >> > > > The old and the new both specify the identifier is lowercase, so not sure > what needs to change here. > > > >> s12, para 3: >> I think 'inherit' is not what you mean here... >> OLD: >> Because of the inherit property that Session Identifiers are conveyed >> end-to-end >> NEW >> Because of the inherent property that Session Identifiers are conveyed >> end-to-end >> END >> > > > Yes, thanks for the correction. > > >> s13.2: As of this moment, no header parameters have been registered for the >> old RFC 7329 Session-ID header. I don't know if any proprietary, >> non-documented parameters are around given the status of RFC 7329, but would >> it be worth explicitly banning the registration of any new parameters under >> the old scheme - and maybe explicitly not allowing any other parameters than >> 'remote' for the new version, to avoid issues of privacy etc. If not it >> might be necessary to copy over some of the words about the nature of >> parameters in Session-ID headers and what B2BUAs might have to do from the >> security considerations of RFC 7329. > > I’d actually prefer to leave generic-param as allowed so that this version > could interoperate with any potential future version that might add > additional parameters. Explicitly banning such additional parameters could > cause issues if we decide to extend the capabilities in a future draft. That > said, some mention along the same lines as specified in 7329 are worth > considering so that arbitrary additional parameters are not added which could > then lead to privacy issues. Let me chew on this one… > > -Paul > > > > > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
