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 protected] SIP/2.0
NEW:
INVITE sip:[email protected] 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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
