Last Call Review of draft-ietf-insipid-session-id-24
review-ietf-insipid-session-id-24-genart-lc-davies-2016-08-04-00

  
  
    I am the assigned Gen-ART reviewer for this draft. The General Area
    


    Review Team (Gen-ART) reviews all IETF documents being processed
    


    by the IESG for the IETF Chair.  Please treat these comments just
    


    like any other last call comments.
    





    For more information, please see the FAQ at
    







<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

.
    





    Document:
    draft-ietf-insipid-session-id-24.txt


    Reviewer:
    Elwyn Davies


    Review Date:
    2016/08/04


    IETF LC End Date:
    2016/08/04


    IESG Telechat date: (if known)
    -





    Summary:
    Almost ready.  I think it would be worth emphasising the
    interoperability with H.323 more than is done at present.  I am also
    not sure if Version 4 UUIDs are actually allowed - there was a
    previous query on UUID types and I am not sure if the Version 4
    mention was intended to be removed.  Caveat: I haven't checked the
    fine details of the examples but have looked them over.  





    Major issues:


    None 





    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.





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





    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?





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





    Nits/editorial comments: 


    s1, paras 1 and 3; s2, last para : s/like/such as/ (total of 3
    places)





    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.





    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?





    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.





    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. 





    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.





    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





    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.





    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.





    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.





    s7, para 12: Expand 3PCC on first use.





    s7, para 12: s/locally-frabricated/locally-fabricated/





    s8, bullet 5: s/487/Request Terminated (487 - see Section 15.1.2 of
    [RFC3261])





    s10.1, start of expansion of SIP messages:


    I think there is a missing 'example.'...


    OLD:


       INVITE 

sip:bob at biloxi.com

 SIP/2.0


    NEW:


       INVITE 

sip:bob at biloxi.example.com

 SIP/2.0


    END





    s11: Effectively there is another new/old requirement: the sess-uuid
    field has to use lower case letters (probably).





    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





    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.