Mobility with Traversal Using Relays around NAT (TURN)
draft-ietf-tram-turn-mobility-09

= Section 3 =

The diagram needs a caption and some explanation. Why does the first Allocate request result in a 401 error? This is not discussed anywhere in the document.

= Appendix A =

In the data structure there is a "state" field but the text below it refers to an "encrypted_state" field.

Hi, I have a few minor comments and (mostly) questions:

- General: I wonder if this should consider the potential for allocation flapping, e.g. if a client is sitting on the border between two wireless networks. Is this an issue, and is their any reasonable guidance that could be offered?

- 3.1.2, 2nd paragraph:
I'm curious why the server disallows this mechanism would explicitly reject a request with the MOBILITY-TICKET attribute rather than ignoring it as if it didn't understand it? Is there an advantage in letting the client know that the server undertands the extension but chooses not to use it, verses simply not understanding it?

- 3.1.4: If the client receives "Mobility Forbidden", is it allowed (or encouraged) to retry without mobility? 

- 3.2.2: 

I'm (also) curious why the server rejects a refresh request with the original 5-tuple and the mobility ticket. 

Also, during the transition window (before it gets a Send Indication or ChannelData message on the new allocation), am I correct to assume that the server forwards inbound data _only_ to the old client address? That is, not both? If so, I think that could use some reinforcement.

- 5.1: Does MICE here refer to the draft in it's current state, or an earlier version? (assuming there is any material difference.)

Editorial:

-1, 2nd paragraph: "the TURN client has to request for a new
   allocation"
s/request for a new/request a new
-- "new relayed candidate address would have to be tricked"
s/tricked/trickled

Is the following scenario worth to be discussed in the doc?

A client receives a MOBILITY-TICKET from the server but when it tries to send a Refresh Request the server ignors the ticket and sets up a new association (maybe because the server seemlessly migrated to a machine that does not support/understand MOBILITY-TICKETs or because of policy reasons) and therefore also does not send a new MOBILITY-TICKET back. I guess in this case the client would probably still want to communication with the destination server and just start a new transport connection, right?

Tbanks for so speedily handling my discuss points.

* Section 3

In the figure (without number/title) why is there an Allocate failure in the second message? I could not find the associated text.

* Section 3.2.1

The section on sending a Refresh when the IP address does not change needs a little bit more tightening. Given that the server would reject the request with a mobility ticket in this case, it would be good to put in an explicit restriction to not add the mobility ticket in the following statement

OLD: 
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it will send a Refresh Request as described in Section 7.1 of [RFC5766]

NEW:
If a client wants to refresh an existing allocation and update its time-to-expiry or delete an existing allocation, it MUST send a Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT include a MOBILITY-TICKET attribute.