Hi Pete, On 09/06/2016 12:05 PM, Pete Resnick wrote: > 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. 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.
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. 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. 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. Thanks Suresh _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
