Re: [Insipid] draft-ietf-insipid-session-id-10: comments

["Paul E. Jones" <[e-mail]>]

Paul,

>>>>That would be true of intermediaries like PBXes that are switching 
>>>>calls
>>>>from one leg to another. It's only in situations where the 
>>>>intermediary
>>>>is going to do something that causes endpoints to have the wrong 
>>>>value
>>>>that they need to ensure they convey the right value. If the SBC is 
>>>>not
>>>>in the business of switching call legs from one device to another 
>>>>like a
>>>>PBX does, it would not have to maintain this state at all.
>>>
>>>I think *most* B2BUAs will sometimes need to originate messages. 
>>>E.g.,
>>>- send a BYE to terminate a session by policy
>>>- send a session timer refresh.
>>>
>>>Any B2BUA that will ever originate a message needs to maintain this
>>>state.
>>>
>>
>>Fair point, though this is not really altering a value -- which is 
>>what
>>most of Section 7 deals with. In this case, it would be just using
>>known values to initiate messages.
>
>The point is that such devices must keep state remembering the values 
>to use.

Understood.


>
>>But, I don't think we speak about that. Want to suggest a blurb to 
>>say?
>>
>>Maybe some "Finally, " text at the end (after that "Having said the
>>foregoing," paragraph I proposed to Brett) like this:
>>
>>====
>>Finally, intermediaries compliant with this specification that 
>>initiate
>>messages not in response to having received a message from a remote
>>endpoint, such as sending a BYE to terminate a dialog, MUST ensure 
>>that
>>the proper Session-ID value is conveyed in that message. If the UUID 
>>of
>>the remote endpoint is known, that value MUST be used as the
>>"local-uuid" value of the transmitted message. If the UUID of the
>>remote endpoint is unknown, then the intermediary MUST use either the
>>null UUID (preferred) or fabricate a UUID to populate the "local-uuid"
>>field. Likewise, if the UUID of the receiving endpoint is known, that
>>value must be included in the "remote-uuid" field. If the UUID of the
>>receiving endpoint is unknown, the "remote-uuid" field must be set to
>>null UUID.
>>====
>
>I think that almost works, depending on what "is known" means.
>A box that doesn't maintain state about the last values used could be 
>considered to "not know" the values when sending a new message.
>Also, from the perspective of the intermediary, both of the endpoints 
>are "remote endpoints".
>
>If the intermediary is between Alice and Bob, and it has seen a message 
>containing {A,B}, then when originating a message toward Bob it should 
>include {A,B}, and when originating a message toward Alice it should 
>use {B,A}.
>
>But I think *saying* that in a clear way is going to require more text. 
>a

Your request and one of Brett's is the same.  In trying to enhance the 
paragraph related to tracking UUID values, maybe we have it covered.  
So, let's remove the last paragraph I propose above and have this as the 
first two paragraphs of Section 7:

The Call-ID often reveals personal, device, domain or other sensitive 
information associated with a user, which is why intermediaries, such as 
session border controllers, sometimes alter the Call-ID.  In order to 
ensure the integrity of the end-to-end Session Identifier, it is 
constructed in a way which does not reveal such information, removing 
the need for intermediaries to alter it.
Intermediaries MAY track the Session Identifier values associated with a 
transaction and dialog.  However, since it is generally NOT REQUIRED and 
because of other reasons, they might provide inaccurate Session-ID 
values when generating related requests and responses.  As a general 
rule, intermediaries MUST NOT alter the UUID values found in the 
Session-ID header, except as described in this section.  When 
autonomously originating a message, an intermediary MAY insert a tracked 
UUID value, or the “null” UUID or a locally generated UUID (in the case 
that there is no known UUID for the peer UA), or not include the 
Session-ID header at all to avoid miscommunicating an incorrect UUID 
value.
How does that sound?

Paul