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

[Suresh Krishnan <[e-mail]>]

Hi Tiru,

On 09/07/2016 10:50 PM, Tirumaleswar Reddy (tireddy) wrote:
> 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.

I have no issues with this new text. Please check with Pete if it resolves 
his concerns.

Thanks
Suresh