Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-insipid-session-id-24

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Wed, 10 Aug 2016 14:16:06 +0000

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 <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> 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)" <[email-masked] <mailto:[email-masked]>>
>>> Date: 04/08/2016 21:40 (GMT+00:00)
>>> To: Elwyn Davies <[email-masked] <mailto:[email-masked]>>
>>> Cc: General area reviewing team <[email-masked] <mailto:[email-masked]>>, [email-masked] <mailto:[email-masked]>
>>> 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:[email-masked] <mailto:sip:[email-masked]> SIP/2.0
>>>> NEW:
>>>>    INVITE sip:[email-masked] <mailto:sip:[email-masked]> 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
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/gen-art <https://www.ietf.org/mailman/listinfo/gen-art>
>

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 10 Aug 2016 15:11:39 +0100

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

      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. 

      
      -Paul

        
          
            On Aug 4, 2016, at 6:17 PM, Elwyn Davies <[email-masked]> wrote:

                

                Hi.

                

                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

                

                
                  -------- Original message --------
                  From: "Paul Giralt (pgiralt)" <[email-masked]>
                  
                  Date: 04/08/2016 21:40 (GMT+00:00) 
                  To: Elwyn Davies <[email-masked]>
                  
                  Cc: General area reviewing team <[email-masked]>,
                    [email-masked]
                  
                  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: 

                          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:

                          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

                        

                    

                    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:

                          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. 

                    

                        

                    

                    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. 

                    

                          OLD:

                             INVITE sip:[email-masked]
                          SIP/2.0

                          NEW:

                             INVITE sip:[email-masked]
                          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:

                          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

                    

                    

                          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
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art