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

From: Elwyn Davies <[email-masked]>
Date: Thu, 4 Aug 2016 19:18:35 +0100

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:[email-masked] SIP/2.0
NEW:
    INVITE sip:[email-masked] 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.

---

From: "Paul Giralt (pgiralt)" <[email-masked]>
Date: Thu, 4 Aug 2016 20:40:51 +0000

Elwyn,

Thank you for the review. We should be able to address these issues. See my comments inline..

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

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

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

> I know this is partly carried over from RFC 7329, but, as currently drafted, it seems pointless.  Can we not just have:
> 
> 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 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.

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

> Because of the inherent property that Session Identifiers are conveyed

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