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) < [email protected]> wrote:
> *From:* Pete Resnick [mailto:[email protected]] > *Sent:* Tuesday, September 6, 2016 9:25 PM > *To:* IESG <[email protected]> > *Cc:* [email protected]; [email protected]; General > Area Review Team <[email protected]> > *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. - +1 (858)651-4478 >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
