Telechat Review of draft-ietf-tram-turn-mobility-08
review-ietf-tram-turn-mobility-08-genart-telechat-resnick-2016-09-06-00

Request Review of draft-ietf-tram-turn-mobility
Requested rev. no specific revision (document currently at 09)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-08-30
Requested 2016-08-23
Authors Tirumaleswar Reddy.K, Dan Wing, Prashanth Patil, Paal-Erik Martinsen
Draft last updated 2016-09-06
Completed reviews Genart Last Call review of -03 by Pete Resnick (diff)
Genart Telechat review of -08 by Pete Resnick (diff)
Secdir Last Call review of -02 by David Waltermire (diff)
Rtgdir Early review of -03 by Tony Przygienda (diff)
Assignment Reviewer Pete Resnick 
State Completed
Review review-ietf-tram-turn-mobility-08-genart-telechat-resnick-2016-09-06
Reviewed rev. 08 (document currently at 09)
Review result Ready with Issues
Review completed: 2016-09-06

Review
review-ietf-tram-turn-mobility-08-genart-telechat-resnick-2016-09-06

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