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

[Paul Giralt (pgiralt) <[e-mail]>]

Brett, 

Thanks again for the detailed review. See inline… 

> On Mar 23, 2016, at 12:31 PM, Brett Tate <[e-mail]> wrote:

> 1) Section 2 paragraph 3:  To remove compliance ambiguity (e.g. if section
> 6 or 7 must be followed), please add something like the following to the
> paragraph: The "endpoint" definition's "generally located" exclusion
> allows intermediaries to originate and terminate SIP messages without an
> endpoint being part of the session or transaction.
> 

I’ve added the following at the end of the paragraph: 

"In certain scenarios, intermediaries are allowed to originate and terminate SIP messages without an endpoint being part of the session or transaction."


> 2) Section 6 paragraph 2 and bullet 1: The text is vague concerning if the
> "MUST NOT change" only applies to the endpoint originating the request.
> 

I think it’s clear that it’s talking about the endpoint that allocates the UUID value (which presumably is the one originating the request), but in the interest of clarity, I’ll change the sentence to: 

"Once an endpoint allocates a UUID value for a communication session, the endpoint originating the request MUST NOT change that UUID value for the duration of the session"


> 3) Section 6 paragraph 6 and section 7 last paragraph: If not intentional,
> "must" is lowercase.
> 

It was actually intentional, but looking at it again, doesn’t hurt to make it capitalized. Fixed.


> 4) Section 6 paragraph 6: CANCEL usage isn't limited to INVITE requests.
> Thus potentially should reword so that it applies to the transaction being
> cancelled.
> 


Assuming you meant paragraph 7. Changed “the original INVITE” to “the original request” 


> 5) Section 6 paragraph 8: Should something similar to this paragraph be
> added to section 7?  For instance, it is currently ambiguous if section 7
> paragraph 6, section 7 paragraph 12, or something else applies if
> intermediary receives message without Session-ID when there are cached
> values for the dialogs.  One aspect of the ambiguity is contained within
> comment 14.
> 

Yes, I think similar verbiage is needed. I will distinguish between receiving a message without Session-ID where one has never been received before as opposed to when one has already been previously received. Modified text and added a new paragraph: 

     If an intermediary receives a SIP message without a Session-ID header field 
     or valid header field value from an endpoint for which the intermediary is not 
     storing a "remote-uuid" value, the intermediary MAY  assign a "local-uuid" value 
     to represent that endpoint and, having done so, MUST insert that assigned value 
     into all signaling messages on behalf of the endpoint for that dialog.  In effect, 
     the intermediary becomes dialog stateful and it MUST follow the endpoint procedures 
     in Section 6 with respect to Session-ID header field value treatment with itself 
     acting as the endpoint (for the purposes of the Session-ID header field) for which 
     it inserted a component into the Session-ID header field value.  If the intermediary 
     is aware of the UUID value that identifies the endpoint to which a message is 
     directed, it MUST insert that UUID value into the Session-ID header field value as 
     the "remote-uuid" value.  If the intermediary is unaware of the UUID value that 
     identifies the receiving endpoint, it MUST use the null UUID value as the 
     "remote-uuid" value.
     
     If an intermediary receives a SIP message without a Session-ID header field 
     or valid header field value from an endpoint for which the intermediary has 
     previously received a Session-ID and is storing a "remote-uuid" value for that 
     endpoint, the lack of a Session-ID MUST have no effect on what the intermediary 
     believes is the UUID value of the endpoint.  That is, the intermediary MUST NOT 
     change the internally maintained "remote-uuid" value for the peer.



> 6) Section 7 paragraph 10: CANCEL usage isn't limited to INVITE requests.
> Thus potentially should reword so that it applies to the transaction being
> cancelled.
> 

Changed “the corresponding INVITE” to “the corresponding request” 


> 7) Section 7 last paragraph: Append something like the following: "if they
> maintain knowledge of the session identifier”.

Good callout. Done. 

> 
> 8) Section 8: Concerning paragraph 1 statement "To ensure that all
> endpoints and intermediaries involved in a session agree upon the current
> session identifier", following the process does not guarantee it.  There
> is too much potential for race conditions to guarantee it (e.g. see RFC
> 6141 section 4.8).  Please add a statement within this section to indicate
> that following this document does not provide a way to ensure that all
> endpoints and intermediaries involved in a session will agree upon the
> current session identifier.


Totally agree and I avoided using the word “guarantee” for the specific reason you outline, but I guess “ensure” might be too strong as well. How’s this? 


     Both endpoints and intermediaries MUST assume that the UUID value of the 
     session peer MAY change at any time due to service interactions.  It is desirable
     to have all endpoints and intermediaries involved in a session agree upon the 
     current session identifier when these changes occur. Due to race conditions or
     certain interworking scenarios, it is not always possible to guarantee session 
     identifier consistency; however, in an attempt to ensure the highest likelihood
     of consistency, all endpoints and intermediaries involved in a session MUST 
     accept a peer's new UUID under the following conditions:


> 
> 9) Section 8 bullets: Concerning the MUST 'include this new UUID as the
> "remote" parameter for any subsequent messages' statements, it isn't clear
> concerning the impacts when an intermediary relays a received Session-ID.
> For instance, are the bullets indicating that the intermediary MUST fix
> the remote UUID when relaying requests/responses?  I think that they
> should be reworded or a paragraph added to help interpret the bullets.
> 


I took this a step further and added text stipulating that an intermediary that accepts a new UUID SHOULD communicate this new UUID to other endpoints involved in the session to help prevent this problem from happening in the first place. 

I’m not sure what the best approach here is, but I’m inclined to say that the intermediary MUST fix the remote UUID when relaying a request / response although I’d be okay with a SHOULD. Do you have any opinion? 


> 10) Section 8 bullet 1: As I mentioned within 1/6/2016 email (linked
> below), I'd prefer CANCEL and its response not be able to update the
> session identifier.  Does anyone know the precise timing concerning when
> 481 should be sent for late CANCEL?  For instance, it looks like RFC 6026
> Timer L means that a device should still return 200 for CANCEL up to 64*T1
> after having sent 2xx for INVITE (even if already received ACK).  This
> would mean that a CANCEL can be 64*T1 seconds late and cause a session
> identifier change.  The behavior appears to be similar within 3xx-6xx
> response to INVITE situation; however the default timer to forget the
> transaction appears to be smaller and I'm not sure what should occur for
> late CANCEL if return 2xx.  Allowing CANCEL to update things also appears
> to conflict with RFC 6141 section 3.3 "SHOULD return 2xx" since the
> desired impact of CANCEL is to cause a 487 response for the cancelled
> transaction (which appears would undo the CANCEL changes).
> 
> http://www.ietf.org/mail-archive/web/insipid/current/msg01085.html
> 

I’m trying to think if there is any downside to disallowing CANCEL from modifying the stored value. At first glance, I can’t think of any downside. Typically a CANCEL will result in a 487 which already results in the value not being stored, so the only case where disallowing CANCEL from modifying the stored value would actually make a material change would be in the 2xx for CANCEL case. Even then, because CANCEL is not end-to-end and it must be identical to what was in the INVITE, it probably does not make sense to store the value from the CANCEL. I’ve added an additional bullet to Section 8: 


       <t>As stated in Section 6 and Section 7, the Session-ID header field value 
       included in a CANCEL request MUST be identical to the Session-ID header field 
       value included in the corresponding INVITE. Upon receiving a CANCEL request, 
       an endpoint or intermediary would normally send a 487 response which, by the
       rules outlined above, would result in the endpoint or intermediary not storing
       any UUID value contained in the CANCEL. Section 3.8 of 
       <xref target="RFC6141"></xref> specifies conditions where a CANCEL can result 
       in 2xx response. Because CANCEL is not passed not end-to-end and will always
       contain the UUID from the original INVITE, retaining a new UUID value received 
       in a CANCEL may result in inconsistency with the Session-ID value stored on 
       the endpoints and intermediaries involved in the session. To avoid this situation, 
       an endpoint or intermediary MUST NOT accept the new UUID value received in a 
       CANCEL and any subsequent messages MUST contain the previously stored UUID value 
       in the "remote" parameter".</t>



> 11) Section 8 bullet 2: In my opinion, 3xx (for instance 305) should be
> handled like 4xx-6xx.  If the 305 was generated for security/overload
> reasons, it seems like an exposure to comply with the bullet's mandate.
> However since mid-dialog 3xx isn't well defined (mentioned within RFC
> 5057), I don't have a strong opinion on the topic.
> 


I’m inclined to leave it as-is, especially because mid-dialog changes resulting in a 3xx are almost non-existent. 


> 12) Section 8 bullet 3: Clarify the last sentence since unsure what
> "latest UUID value" means: stored UUID or request's UUID.
> 


It means the request’s UUID. Fixed. 


> 13) Section 8 bullet 4: Concerning ACK for 3xx, I have the same comment as
> bullet 2.
> 

Also inclined to leave as-is for the same reasons as above. 


> 14) Section 8 bullet 5: Allowing failure responses to update the cached
> UUID is a little odd (although it provides a value for ACK).  It can
> potentially cause a disagreement concerning session identifier.  

I think the value changing in a failure response is in itself an unlikely scenario to begin with and this scenario is not likely to occur. 

As you mentioned, without updating the UUID on a failure response, we don’t have a value for ACK. Having the value in the ACK outweighs any potential out of sync that may occur in a rare scenario where the UUID changes on a failure response. I’m inclined to leave as-is. 


> Unless
> clarify within the draft, it also adds ambiguity when attempting multiple
> mid-dialog locations per RFC 3263.
> 
> If there were multiple failure responses causing resubmit with higher
> cseq, the last change is cached on intermediary.  If session identifier is
> subsequently missing from 2xx response (or other final response), the
> intermediary will have a cached UUID which does not get relayed to the
> endpoint (except maybe when section 7 paragraph 12 is applicable).
> 


I’m not understanding why the 2xx would suddenly be missing the session identifier in this case. I already addressed this case above to ensure that a missing session identifier when one was present in previous messages does not overwrite. Does this address your concern here? 


> Concerning devices that attempt multiple mid-dialog locations per RFC
> 3263, I guess that they will decide how to correlate potentially
> conflicting values associated with multiple responses (such as 503, 482,
> and other response or timeout) since they can select a specific branch to
> honor similar to if outside of dialog.  Their decision might conflict with
> how other intermediaries which saw the responses might interpret what
> should be the current session identifier.  Concerning re-INVITE, I'm not
> really sure what remote UUID to include within the ACKs of non-winning
> branches.  For instance if receive 2xx for branch A and then receive 503
> for branch B (i.e. both requests sent before 2xx received), branch A is
> obviously the desired winner.  Should the late 503 cause an update of the
> stored UUID?  If not, should remote UUID within ACK reflect 503's value or
> stored UUID?


When multiple locations are attempted, wouldn’t they be attempted in series? I would think that the 503 would actually come back before the request that leads to the 2xx if the session establishment really does succeed. If the 503 never made it to the far-end endpoint and this is really traversing proxies, I’m guessing the 503 will likely come back without a session identifier anyway, which would not cause a problem. I’m struggling to find a real-world case where something like this would happen that would realistically cause a problem with the current draft. 

To answer your specific questions - if it really did play out the way you outlined above and the 503 does include a session identifier (and it happens to be different than the one in the 2xx), then yes, the 503 should cause an update and the remote UUID in the ACK for the 503 would reflect the 503’s value (which would also now be the stored value because we accept stored values from the 503). Not ideal, but this scenario does not seem realistic to me. Please correct me if I’m missing something. 


Thanks again for all your feedback. Please let me know your thoughts so we can try to drive this to WGLC. 

Thanks 
-Paul