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

[Suresh Krishnan <[e-mail]>]

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