Re: [Gen-art] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

[Pete Resnick <[e-mail]>]

On 9 Sep 2016, at 4:33, Suresh Krishnan wrote:

> Hi Tiru,
>
> On 09/07/2016 10:50 PM, Tirumaleswar Reddy (tireddy) wrote:
>> [TR] I propose the following text to avoid the confusion:
>>
>>    If a client wants to refresh an existing allocation and update its
>>    time-to-expiry or delete an existing allocation in case of no IP 
>> address
>> change, it will send a
>>    Refresh Request as described in Section 7.1 of [RFC5766] and MUST 
>> NOT
>>    include a MOBILITY-TICKET attribute.  If the client wants to 
>> retain
>>    the existing allocation in case of IP address change, it will 
>> include the
>>    MOBILITY-TICKET attribute received in the Allocate Success 
>> response
>>    in the Refresh Request.
>
> I have no issues with this new text. Please check with Pete if it 
> resolves
> his concerns.

Wait, now I'm even more confused. The second sentence says that you *are 
allowed* to include the MOBILITY-TICKET attribute in a Refresh Request 
if you want to retain the allocation, even though the first sentence 
says you MUST NOT. Is this because the Refresh Request with the 
MOBILITY-TICKET attribute will only be rejected if the IP address is the 
same? If so, perhaps this is what you meant:

     If a client wants to refresh an existing allocation and update its
     time-to-expiry or delete an existing allocation, it sends a Refresh
     Request as described in Section 7.1 of [RFC5766]. If IP address of
     the client has changed and the client wants to retain the existing
     allocation, the client includes the MOBILITY-TICKET attribute
     received in the Allocate Success response in the Refresh Request. 
If
     there has been no IP address change, the client MUST NOT include a
     MOBILITY-TICKET attribute, as this will be rejected by the server
     and the client would need to retransmit the Refresh Request.

If that's not what you meant, you should probably clarify.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]