[Insipid] Pre-WGLC INSIPID Session-ID Review Comments

["Adam Gensler (agensler)" <[e-mail]>]

Hi all,

I've reviewed the INSIPID Session-ID draft located here:
http://tools.ietf.org/html/draft-ietf-insipid-session-id


I have a few comments/questions, listed below in no particular order:



---
4.1. Constructing the Session Identifier
"To satisfy the requirement that no user or device information be
conveyed, endpoints SHOULD generate version 4 (random) or version 5
(SHA-1) UUIDs."

"Intermediaries that insert a Session-ID header into a SIP message on
behalf of a sending User Agent MUST utilize version 5 UUIDs to ensure that
UUIDs for the communication session are consistently generated."

Comment: What's the rational behind allowing two different types of UUID
generation in the first paragraph, then mandating a kind in the second
paragraph? It seems that mandating version 5 UUIDs would provide two
benefits. First, it would ensure the UUIDs are consistently generated in
all scenarios, and second, it would be inline with the security guidelines
spelled out in section 11.
---

---
7. Processing by Intermediaries

"When intermediaries transmits a 100 (Trying) provisional responseand when
the UUID of the destination UA is unknown, the intermediary MUST place the
one known UUID in the "remote-uuid" field and set the "local-uuid" field
to the null UUID value.  When an intermediary transmits any other
provisional response and when the UUID of the destination UA is unknown,
the intermediary MUST place the one known UUID in the "remote-uuid" field
and MAY set the "local-uuid" field to a locally created UUID value or the
null UUID value.

Comment: What's the rational behind the difference in behavior between the
100 and other 1xx responses?
---

---
9.6. Cascading Conference Bridge Support for the Session ID

General Comment: I'll admit to not being well versed in cascading MCU
setups. Are multiple MCUs linked together always from the top down? Or, is
it possible that a downstream MCU may link upstream, thereby potentially
causing a race condition of Session-ID indication via simultaneous
isfocus-INVITEs between two MCUs?
---

---
9.4 Single Focus Conferencing

Comment: This example shows reINVITEs being sent to change the UUID from
the temporary, IVR-connected session, to the UUID of the conference. Is a
SIP UPDATE/200OK exchange also a possibility for updating the UUID? If so,
the validity of using an UPDATE to reflect changes in the UUID should be
specifically mentioned.
---

---
General Comment: The opening introduction discusses the challenges of
end-to-end session IDs in multi-protocol environments. Are any provisions
given for inter-working this draft with something like H.323? If not, is
there specific guidance worth providing for intermediate devices that
interwork between multiple protocols (CUCM/CUBE)?

General Comment: How does this draft mesh with SIP OPTIONS ping/keepalive
functionality? Should a Session-ID be included there?

General Comment: The Webex specific example seems out of place and product
specific. What's the generally accepted rule in regard to mentioning
specific products in an RFC?
---

---
7. Processing by Intermediaries

"Devices that initiate communication sessions following the procedures for
third party call control MUST fabricate a UUID value that will be utilized
only temporarily. Once the responding endpoint provides a UUID value in a
response message, the temporary value MUST be discarded and replaced with
the endpoint-provided UUID value. Refer to the third-party call control
example for an illustration."

**snip**

"If a SIP intermediary initiates a dialog between two UAs in a 3PCC
scenario, the SIP request in the initial INVITE will have a non-null
"local-uuid" value; call this temporary UUID X. The request will still
have a null "remote-uuid" value; call this value N. The SIP server MUST be
transaction stateful. The UUID pair in the INVITE will be {X,N}. A
non-redirected or rejected response will have a UUID pair {A,X}. This
transaction stateful, dialog initiating SIP server MUST replace its own
UUID, i.e., X, with a null UUID (i.e., {A,N}) as expected by other UAS"

Comment: These paragraphs both seem to be describing 3PCC scenarios, but
are separated in this section by three paragraphs not talking about 3PCC.
Would it be beneficial to move this paragraphs closer together?
---

---
6. Endpoint Behavior

"It is also possible to for the UA to receive a "remote-uuid" value that
does not match the UA's assigned UUID for the session."

Comment: Typo - "...is also possible to for the UA to..."
---


---
7. Processing by Intermediaries

"When intermediaries transmits a 100 (Trying) provisional responseand when
the UUID of the destination UA is unknown"

Comment: Typo - "...provisional responseand when the..."
---


---
9.6. Cascading Conference Bridge Support for the Session ID

"The one MCU that generates the UUID informs one or several MCUs of this
common UUID, and they inform downstream MCUs of this common UUID each will
be using for this one conference, or"

Comment: Truncated sentence? "...this one conference, or"
---

Any input and/or feedback on the above would be great.

Best regards,
Adam

---
Adam Gensler
[e-mail]