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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Please see inline
From: Pete Resnick [mailto:[e-mail]]
Sent: Wednesday, September 7, 2016 8:53 PM
To: Suresh Krishnan <[e-mail]>
Cc: IESG <[e-mail]>; General Area Review Team <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: GenART post-telechat comment on draft-ietf-tram-turn-mobility-08


[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.

[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.

Cheers,
-Tiru

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/<http://www.qualcomm.com/%7Epresnick/>
Qualcomm Technologies, Inc. - [phone]