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

[Paul Kyzivat <[e-mail]>]

On 2/9/15 6:00 PM, Paul E. Jones wrote:
> 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.

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

	Thanks,
	Paul