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.
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
