Hi Tiru, On 09/07/2016 10:50 PM, Tirumaleswar Reddy (tireddy) wrote: > 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.
I have no issues with this new text. Please check with Pete if it resolves his concerns. Thanks Suresh _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
