Please see inline From: Pete Resnick [mailto:[email protected]] Sent: Wednesday, September 7, 2016 8:53 PM To: Suresh Krishnan <[email protected]> Cc: IESG <[email protected]>; General Area Review Team <[email protected]>; [email protected]; [email protected] 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. - +1 (858)651-4478
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
