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

[Spencer Dawkins at IETF <[e-mail]>]

I'll wait to see what Suresh thinks (we're discussing his Comment), but

On Tue, Sep 6, 2016 at 8:44 PM, Tirumaleswar Reddy (tireddy) <
[e-mail]> wrote:

> *From:* Pete Resnick [mailto:[e-mail]]
> *Sent:* Tuesday, September 6, 2016 9:25 PM
> *To:* IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail]; General
> Area Review Team <[e-mail]>
> *Subject:* GenART post-telechat comment on draft-ietf-tram-turn-mobility-
> 08
>
>
>
> Greetings,
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please treat these comments just like any other
> participants comments.
>
> For more information, please see the FAQ at
>
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.
>
> Document: draft-ietf-tram-turn-mobility-03
> Reviewer: Pete Resnick
> Review Date: 2016-09-06
> IESG Telechat date: 2016-09-01
>
> Summary: This is an odd post-telechat review, but I think the draft has
> gone from "Ready" to "Ready with an issue" because of an IESG Eval change.
>
> Details:
>
> I did not get to my post-Last Call GenART review of
> draft-ietf-tram-turn-mobility until after the telechat. Had I done so,
> which would have been on version -05, I would have said "Looks fine to me".
> However, I happened to look at the latest version, figuring I would just
> confirm. I found that a change was made in response to an IESG Evaluation
> comment from Suresh https://mailarchive.ietf.org/arch/msg/tram/
> SYVAXc1dF6xUcm0OQ9xyuaknJco:
>
> ------------------------------
> COMMENT:
>
>    - Section 3.2.1
>
> The section on sending a Refresh when the IP address does not change
> needs a little bit more tightening. Given that the server would reject
> the request with a mobility ticket in this case, it would be good to put
> in an explicit restriction to not add the mobility ticket in the
> following statement
>
> 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'm not sure if the "MUST NOT" in the latter part of the sentence is
> correct: Since the server will reject it anyway, I don't see the harm in
> including the attribute that the "MUST NOT" implies, but perhaps this is
> belt-and-braces protocol description. On this point, I can't complain too
> much.
>
> [TR] “MUST NOT” is required to prevent the client from sending the request
> with the ticket which will be rejected by the server and the client will
> have to again re-try the request without the ticket.
>
> However, I believe Suresh was incorrect in suggesting the first "MUST",
> and it should be removed. There is no harm being prevented here. "If a
> client wants X, it MUST send Y" is absolutely no different protocol-wise
> from "If a client wants X, it will send Y". The "MUST" is a misuse. I
> believe that this change should be undone before publication.
>
> [TR] I can the update the line; including Suresh to see if he has any
> objections
>

Given that we're usually in a minimize-the-number-of-round-trips
environment here, I'm more sympathetic to MUST as an optimization, and not
just belt-and-suspenders ("ask me no questions and I'll tell you no lies")
in this case than I would usually be.

Spencer


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