A Session Identifier for the Session Initiation Protocol (SIP)
draft-kaplan-insipid-session-id-04

It seems to me to be slightly simplistic to say that because the 
Session ID has no sensitive information in it, it will not reveal any
information related to any SIP device or domain identity.  That is,
of course, examined in isolation it will not reveal anything, but it
becomes a piece of metadata that can be examined at several points in
the network to discover information about the session. Indeed, it 
seems that the purpose of the Session ID is exactly to provide 
correlation that would not otherwise be possible (or might only be
possible if the B2BUAs sisn't mess with the Call IDs).


This does not speak against the use of a Session ID, but does suggest 
that its use might not be quite as harmless as this document suggests.

---

There is a wrinkle with 4.5.1...

Imagine there are two B2BUAs along the path both of which change the 
Call-ID. Suppose also that the original request does not contain a
Session ID. The first B2BUA does not add a Session ID (it is a "MAY"
and anyway it is a legacy implementation). The second B2BUA adds a
Session ID using the received Call-ID, but this is not original one.

Question: why does the text require that the Session ID inserted by
a B2BUA be derived from the received Call-ID? It doesn't seem to make
any difference (it is, after all, using the B2BUA's secret) and the
received Call-ID is no different to the B2BUA's substituted Call-ID.

---

There is, of course, a very small chance that two Session IDs will be
identical. This could happen at one point of generation or across two
such points. 

Should you include advice to a Session ID generator to catch such cases?
Should you give a warning to users of the Session ID that this might 
happen?

Unlikely though it is, it will happen in the field the first time the
function is enabled :-)

This is a non-blocking comment/suggestion:
The security considerations section should include a sentence about the requirement to avoid any values that may raise privacy concerns in the SIP header.  This is already listed earlier int he document, but may be helpful to repeat in this section.

- Were the IESG discusses/comments on the insipid WG
requirements document considered in this text? If not, why
not? I suspect (without having looked back) that some of
them might apply here and be ok to handle here as well. (I
had a discuss on that that I'd like you to look at.)

- Why are we only implicitly recommending implementations
follow the standards track approach and not this?