Elwyn, Thanks again for the feedback. I’ll discuss the point about 7206 with the other authors and determine the best course of action.
-Paul > On Aug 10, 2016, at 10:11 AM, Elwyn Davies <elw...@folly.org.uk> wrote: > > Hi, Paul. > > Unfortunately, I should have pointed out that if you leave your two primary > definitions in RFC 7206, I think this becomes a normative reference. RFC > 7206 is informative rather than standards track and so becomes the dreaded > downref. Apart from the process hassle this entails, you may be hard pushed > to persuade people that this is an appropriate downref. Copying them over > (and in the process checking they are still correct) is rather less hassle > IMO - and makes the RFC more self-contained as regards its basic > functionality. > Otherwise, this looks fine. I have looked into the INVITE/CANCEL story a bit > deeper, and think I see that all is well. > Regards, > > Elwyn > > On 08/08/2016 19:32, Paul Giralt (pgiralt) wrote: >> 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 >>> <mailto: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 <mailto:pgir...@cisco.com>> >>> Date: 04/08/2016 21:40 (GMT+00:00) >>> To: Elwyn Davies <elw...@folly.org.uk <mailto:elw...@folly.org.uk>> >>> Cc: General area reviewing team <gen-art@ietf.org >>> <mailto:gen-art@ietf.org>>, draft-ietf-insipid-session-id....@ietf.org >>> <mailto: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 >>> >>> >>> >>> >>> >>> >> >> >> >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org <mailto:Gen-art@ietf.org> >> https://www.ietf.org/mailman/listinfo/gen-art >> <https://www.ietf.org/mailman/listinfo/gen-art> >
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
