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

[Pete Resnick <[e-mail]>]

[Trimming down a bit]

On 6 Sep 2016, at 22:57, Suresh Krishnan wrote:

>>     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.
>
> I will try to explain my line of reasoning. Let me know where you 
> disagree.
> If the client includes a MOBILTY-TICKET attribute in the refresh 
> method, the
> refresh will fail. So, the MUST NOT is aimed at preventing the client 
> from
> sending a useless packet that will be rejected anyway.

"Useless" seems not a good reason for a "MUST NOT". Perhaps Tiru's 
explanation of "will cause an extra retransmission" is a better reason. 
But as I said, this isn't one that I will complain too vociferously 
about: What this says is "don't include the attribute; it will be 
rejected and you'll have to retransmit"; if you want a "MUST NOT" for 
that, so be it. But:

> The MUST stresses that
> the original Refresh procedure from RFC5766 needs to be used instead 
> of the
> Refresh procedure with the MOBILITY-TICKET described in this one.

Ah! If that's was meant, that's not what was said. It sounds like you're 
saying that the client *can't* refresh a request by simply sending an 
allocate request with the old MOBILITY-TICKET. And then I get a bit 
confused about the MUST NOT: The next sentence after this bit says:

    If the client wants to retain
    the existing allocation in case of IP change, it will include the
    MOBILITY-TICKET attribute received in the Allocate Success response.

The previous sentence says that you MUST NOT include the attribute. This 
sentence says that you do include it. I suspect that what was intended 
was, "If you *just* want to refresh to retain the existing allocation in 
case of an IP change, you can send an allocate request including the old 
MOBILITY-TICKET attribute. If you need to update time-to-expiry or 
delete the allocation, then you *can't* just send a new allocate request 
with the attribute; that will get rejected. You instead *have to* use 
the refresh request in 5766." Do I have that right? If so, the paragraph 
could use a rewrite; it's not the MUST and the MUST NOT that are the 
problem.

> Anyway, I
> am not wedded to keeping the MUST as long as the MUST NOT prevents the
> sending of a packet that is certain to be rejected.

Ack. See above.

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