Re: [Insipid] draft-ietf-insipid-session-id-14: comments and questions

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

Brett,

>>  >Section 5 paragraph 7: In my opinion, the MUST should
>>  >be changed to SHOULD (along with similar changes
>>  >elsewhere); however since I guess the working group
>>  >disagrees... Should add text somewhere concerning the
>>  >impacts of race conditions, retries, CANCEL,
>>  >authentication, overload, et cetera upon the "most
>>  >recently received UUID" algorithm.  For instance if
>>  >"most recently received UUID" was processed as a retry,
>>  >it potentially isn't the best choice for inclusion as
>>  >the remote-uuid.
>
>Retry was potentially addressed good enough since I don't think 
>implementers
>would interpret "peer endpoint MAY change at any time" as including 
>retries.
>However since it doesn't need to pass authentication (and draft 
>overrides
>RFC 3261 section 8.2's "all state changes MUST NOT be performed"), I'm 
>not
>sure where within the processing steps (like RFC 3261 section 8.2) they 
>will
>place the decision to update the stored remote UUID.

Nothing in this draft changes the processing rules.  If a message is 
received and determined to be valid and processed, the UUID is updated 
-- if there is a new UUID.


>Unknown or unsupported request situations are interesting.  Even though 
>the
>request is unknown or unsupported, the draft still mandates allowing it 
>to
>update the UUID.

One could interpret it that way, though one could equally not update the 
UUID given the message could not be processed.  I think it's a matter of 
whether you trust the message to be valid.


>  Malformed message situations are interesting.  The draft currently 
>allows a
>malformed messages to update the UUID.  I can't wait until I hear "I 
>sent
>you a malformed message containing Session-ID, why didn't you update 
>the
>stored remote UUID?"

No, I think you're reading too much into this.  No sensible 
implementation of any protocol should result in accepting a known 
malformed message and pulling out parts of it for use.  If the message 
is clearly malformed, then the whole thing should be junked.  That's not 
even something that should have to be said at this point.  If the 
message is malformed, the UA should send a 400, not try to pull out some 
part of a malformed message and use it.


>Large SIP message situations are interesting.  Even though a device 
>might
>reject large messages, the draft still mandates processing the message
>enough to update the UUID.

No, I don't think that's the case.  If a large message is rejected, I 
would not expect the UA to go pull out the UUID and use it.  This is 
similar to the malformed message case.  The SIP stack is going to parse 
the message or discard messages long before the message gets to the 
state machine where it would deal with UUIDs.


>>  >Since CANCEL can contain an older UUID, it potentially
>>  >isn't the best choice for inclusion as the remote-uuid.
>
>You should likely discuss the impacts of CANCEL if you are really 
>intending
>to allow it to roll back the UUID.  Otherwise, implementers might not 
>think
>that the draft truly intended for the rollback to occur.

There is no intent for it to roll back a UUID.   The UA sending the 
CANCEL will use the original UUID is used before, but it will not 
include the "remote" part.  That was a change we made in a recent draft 
-- it has to match the orginal INVITE.

Not sure why I would have said "older" :-/


>
>
>>  >Because of race conditions, the "most recently received
>>  >UUID" is not necessarily the most recent UUID sent by
>>  >the remote endpoint.
>
>Potentially addressed good enough.  However, adding a statement about 
>race
>conditions within the draft would help silence complaints if anyone was
>thinking that the draft provides a way to ensure all of the devices 
>truly
>know the current Session-ID.

The only case, I think, where this is an issue is with certain service 
interaction.  And this is called out in the examples (e.g., in 9.3).  It 
is shown how to address this problem.  Maybe "race condition" was not 
the right term to use, but I don't think there are any problems with the 
current procedures in this regard.

>
>
>>  >If a device returns 500 because lower CSeq, it seems
>>  >strange that the UAS MUST update the stored UUID.
>
>Potentially addressed good enough since I don't think implementers 
>would
>interpret "peer endpoint MAY change at any time" as including requests
>containing lower cseq.

Indeed.  This did not mean to throw out all logical message processing 
;-)


>>  >If the "most recently received UUID" hasn't passed
>>  >authentication (i.e. returning 401, 407, or 403), should
>>  >the request (or the related ACK) still be allowed to
>>  >alter the stored UUID?
>
>As far as I know, the draft indicates yes.  Is this acceptable?

If it's a valid response, yes.  If the UA sends an INVITE with {A,N} and 
gets a 407 with {A,B}, then it should accept {B} if the 407 isn't bogus.


>>  >If an overloaded device returns a failure response
>>  >(such as 503), is the overloaded device actually
>>  >supposed to still update the stored UUID to be
>>  >compliant with this mandate?  If this draft is
>>  >mandating an overloaded server process an
>>  >unauthenticated request to update stored information,
>>  >it should be mentioned within section 11.
>>
>>  Whew!  OK, that's a lot to chew on. :)
>
>As far as I know, the draft indicates yes.  Is this acceptable and 
>should it
>be mentioned within section 11?  I'm glad that the draft only indicates 
>that
>the B2BUA SHOULD (instead of MUST) communicate the update to the remote
>device.

If a server is overloaded and not processing messages and, instead, 
returning 5xx, I don't expect it to update the UUID value.  There is an 
assumption here that I don't think needs to be stated, and that is that 
acceptance of a UUID is only done if the message is accepted and 
processed.  Malformed, 5xx, etc. errors should not mean we ignore all 
other processing and go pull out and update a UUID.


>>  >Section 6 paragraph 2: Should clarify authentication behavior.
>>  >For instance, RFC 3261 allows the challenger to behave mostly
>>  >stateless (such as by not retrying 401/407); however this draft
>>  >currently appears to mandate maintaining additional information
>>  >and perform related modifications.
>>
>>  I see value in keeping that state.  This is in line with also
>>  maintaining the UUID value even in the face of getting a 3xx,
>>  too.  We want this to effectively persist from the moment the
>>  user lifts the handset and makes a call to the moment the user
>>  hangs up the phone.
>
>Sounds okay from a UAC perspective; however since the Call-ID can 
>change, I
>don't see how that mandate is always possible from a UAS perspective.

>From the UAS perspective, the call is over when it sends back a 4xx.  I 
only meant that the client would maintain this state, not the server.  
If that needs clarification, tell me where to add it, but only the UAC 
should maintain UUID information between INVITE / 3xx, for example.


>>  >Section 7 paragraph 3: If the intermediary knows it is relaying
>>  >the request to a different session, can it fix the remote-uuid
>>  >(such as changing it to null)?
>>
>>  For the response aggregation case, definitely.  For what other
>>  cases are you thinking that should happen?
>
>Basically any cases where the B2BUA likely has a more accurate view of 
>the
>current remote UUID.  For instance, section 9.3 example.  Similarly, 
>the
>endpoint may be incorrect concerning section 6's "believes may be a new 
>peer
>endpoint" check and included non-null remote UUID.  Similarly, consider 
>race
>conditions (although it could also cause B2BUA to be wrong).

I'm struggling with what other words need to be added here.  I don't see 
where things are going to go unpredictably off course.  We know there 
are cases (esp. service interaction cases) where the two ends might have 
a different view of the UUID values, but the B2BUA is in a position to 
fix the problem, since it likely caused the problem.

If we just get rid of B2BUAs and 3PCC, we would have no problems. But in 
those cases, those devices that causes confusion have to fix it.

Paul