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

From: Pete Resnick <[email-masked]>
Date: Tue, 6 Sep 2016 10:55:25 -0500

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 7 Sep 2016 01:44:46 +0000

From: Pete Resnick [mailto:[email-masked]]
Sent: Tuesday, September 6, 2016 9:25 PM
To: IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; General Area Review Team <[email-masked]>
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.

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

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.

-Tiru

pr
--
Pete Resnick http://www.qualcomm.com/~presnick/<http://www.qualcomm.com/%7Epresnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 6 Sep 2016 20:58:48 -0500

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-masked]> wrote:

> *From:* Pete Resnick [mailto:[email-masked]]
> *Sent:* Tuesday, September 6, 2016 9:25 PM
> *To:* IESG <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; General
> Area Review Team <[email-masked]>
> *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.
>
> gone from "Ready" to "Ready with an issue" because of an IESG Eval change.
>
> Details:
>
> 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
>
> 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/

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 7 Sep 2016 03:57:20 +0000

Hi Pete,

On 09/06/2016 12:05 PM, Pete Resnick wrote:
> 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.
>
> 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:
>
> 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".
> comment from Suresh
> https://mailarchive.ietf.org/arch/msg/tram/SYVAXc1dF6xUcm0OQ9xyuaknJco:
>
>     -----------------------------------------------------------------------------
>
>
>         COMMENT:
>
>       * Section 3.2.1
>
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 7 Sep 2016 08:24:32 +0100

Hi Pete,

> believe that this change should be undone before publication.

This is something we rehearsed at length and fairly
regularly (if only occasionally) when one Mr. Resnick
was on the IESG:-)

My impression of those discussions is that we ended
up with a draw: Pete continues to not like when such
gratuitous MUST statements are included, and is strictly
correct that they aren't needed. However, authors do do
that and the sky does not fall in, so others (incl. me)
feel that the IESG badgering authors on this topic is
counter-productive.

IOW, I don't think the change needs to be undone. But
I don't care if that happens or not in this case.

If the IESG were to extrapolate from that to suggesting
that Pete's preferred approach MUST be followed, then
I would have a problem with that. (But I hope we're not
going there:-)

S.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 7 Sep 2016 10:23:27 -0500

[Trimming down a bit]

On 6 Sep 2016, at 22:57, Suresh Krishnan wrote:

> sending a useless packet that will be rejected anyway.

"Useless" seems not a good reason for a "MUST NOT". Perhaps Tiru's 
explanation of "will cause an extra retransmission" is a better reason. 
But as I said, this isn't one that I will complain too vociferously 
about: What this says is "don't include the attribute; it will be 
rejected and you'll have to retransmit"; if you want a "MUST NOT" for 
that, so be it. But:

> The MUST stresses that
> Refresh procedure with the MOBILITY-TICKET described in this one.

Ah! If that's was meant, that's not what was said. It sounds like you're 
saying that the client *can't* refresh a request by simply sending an 
allocate request with the old MOBILITY-TICKET. And then I get a bit 
confused about the MUST NOT: The next sentence after this bit says:

    If the client wants to retain
    the existing allocation in case of IP change, it will include the
    MOBILITY-TICKET attribute received in the Allocate Success response.

The previous sentence says that you MUST NOT include the attribute. This 
sentence says that you do include it. I suspect that what was intended 
was, "If you *just* want to refresh to retain the existing allocation in 
case of an IP change, you can send an allocate request including the old 
MOBILITY-TICKET attribute. If you need to update time-to-expiry or 
delete the allocation, then you *can't* just send a new allocate request 
with the attribute; that will get rejected. You instead *have to* use 
the refresh request in 5766." Do I have that right? If so, the paragraph 
could use a rewrite; it's not the MUST and the MUST NOT that are the 
problem.

> Anyway, I

Ack. See above.

pr

---

From: Pete Resnick <[email-masked]>
Date: Wed, 7 Sep 2016 10:27:12 -0500

Stephen,

As per my reply to Suresh: It is often the case that the gratuitous use 
of "MUST"s hides ambiguities in meaning that need to be fixed anyway.

And for the sake of keeping things the same as they were when I was on 
the IESG, I say to you, with great affection:

:-b

pr

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 8 Sep 2016 02:50:14 +0000

Please see inline
From: Pete Resnick [mailto:[email-masked]]
Sent: Wednesday, September 7, 2016 8:53 PM
To: Suresh Krishnan <[email-masked]>
Cc: IESG <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

[Trimming down a bit]

"Useless" seems not a good reason for a "MUST NOT". Perhaps Tiru's explanation of "will cause an extra retransmission" is a better reason. But as I said, this isn't one that I will complain too vociferously about: What this says is "don't include the attribute; it will be rejected and you'll have to retransmit"; if you want a "MUST NOT" for that, so be it. But:
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.

Ah! If that's was meant, that's not what was said. It sounds like you're saying that the client can't refresh a request by simply sending an allocate request with the old MOBILITY-TICKET. And then I get a bit confused about the MUST NOT: The next sentence after this bit says:

The previous sentence says that you MUST NOT include the attribute. This sentence says that you do include it. I suspect that what was intended was, "If you just want to refresh to retain the existing allocation in case of an IP change, you can send an allocate request including the old MOBILITY-TICKET attribute. If you need to update time-to-expiry or delete the allocation, then you can't just send a new allocate request with the attribute; that will get rejected. You instead have to use the refresh request in 5766." Do I have that right? If so, the paragraph could use a rewrite; it's not the MUST and the MUST NOT that are the problem.

[TR] I propose the following text to avoid the confusion:
   If a client wants to refresh an existing allocation and update its
   time-to-expiry or delete an existing allocation in case of no IP address change, it will send a
   Refresh Request as described in Section 7.1 of [RFC5766] and MUST NOT
   include a MOBILITY-TICKET attribute.  If the client wants to retain
   the existing allocation in case of IP address change, it will include the
   MOBILITY-TICKET attribute received in the Allocate Success response
   in the Refresh Request.

Cheers,
-Tiru

Anyway, I

Ack. See above.

pr

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 9 Sep 2016 09:33:14 +0000

Hi Tiru,

On 09/07/2016 10:50 PM, Tirumaleswar Reddy (tireddy) wrote:
> Please see inline
>
> *From:*Pete Resnick [mailto:[email-masked]]
> *Sent:* Wednesday, September 7, 2016 8:53 PM
> *To:* Suresh Krishnan <[email-masked]>
> *Cc:* IESG <[email-masked]>; General Area Review Team <[email-masked]>;
> [email-masked]; [email-masked]
> *Subject:* Re: GenART post-telechat comment on draft-ietf-tram-turn-mobility-08
>
>
>
> [Trimming down a bit]
>
> explanation of "will cause an extra retransmission" is a better reason. But
> as I said, this isn't one that I will complain too vociferously about: What
> this says is "don't include the attribute; it will be rejected and you'll
> have to retransmit"; if you want a "MUST NOT" for that, so be it. But:
>
>     The MUST stresses that
>
> saying that the client /can't/ refresh a request by simply sending an
> allocate request with the old MOBILITY-TICKET. And then I get a bit confused
> about the MUST NOT: The next sentence after this bit says:
>
> sentence says that you do include it. I suspect that what was intended was,
> "If you /just/ want to refresh to retain the existing allocation in case of
> an IP change, you can send an allocate request including the old
> MOBILITY-TICKET attribute. If you need to update time-to-expiry or delete the
> allocation, then you /can't/ just send a new allocate request with the
> attribute; that will get rejected. You instead /have to/ use the refresh
> request in 5766." Do I have that right? If so, the paragraph could use a
> rewrite; it's not the MUST and the MUST NOT that are the problem.
>

I have no issues with this new text. Please check with Pete if it resolves 
his concerns.

Thanks
Suresh

---

From: Pete Resnick <[email-masked]>
Date: Fri, 9 Sep 2016 11:08:05 -0500

On 9 Sep 2016, at 4:33, Suresh Krishnan wrote:

>>    time-to-expiry or delete an existing allocation in case of no IP 
>> address
>> change, it will send a

Wait, now I'm even more confused. The second sentence says that you *are 
allowed* to include the MOBILITY-TICKET attribute in a Refresh Request 
if you want to retain the allocation, even though the first sentence 
says you MUST NOT. Is this because the Refresh Request with the 
MOBILITY-TICKET attribute will only be rejected if the IP address is the 
same? If so, perhaps this is what you meant:

     If a client wants to refresh an existing allocation and update its
     time-to-expiry or delete an existing allocation, it sends a Refresh
     Request as described in Section 7.1 of [RFC5766]. If IP address of
     the client has changed and the client wants to retain the existing
     allocation, the client includes the MOBILITY-TICKET attribute
     received in the Allocate Success response in the Refresh Request. 
If
     there has been no IP address change, the client MUST NOT include a
     MOBILITY-TICKET attribute, as this will be rejected by the server
     and the client would need to retransmit the Refresh Request.

If that's not what you meant, you should probably clarify.

pr

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 9 Sep 2016 18:19:50 +0000

On Sep 9, 2016, at 12:08 PM, Pete Resnick <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tiru,
time-to-expiry or delete an existing allocation in case of no IP address

Wait, now I'm even more confused. The second sentence says that you are allowed to include the MOBILITY-TICKET attribute in a Refresh Request if you want to retain the allocation, even though the first sentence says you MUST NOT. Is this because the Refresh Request with the MOBILITY-TICKET attribute will only be rejected if the IP address is the same? If so, perhaps this is what you meant:

received in the Allocate Success response in the Refresh Request. If

To be precise, “IP address” here should be “IP address or source port”, right?  One case I’m thinking of is where a client moved to a new private IP address, but is still behind the same CGN and so has the same external IP address.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 10 Sep 2016 04:39:27 +0000

From: Pete Resnick [mailto:[email-masked]]
Sent: Friday, September 9, 2016 9:38 PM
To: Suresh Krishnan <[email-masked]>
Cc: Tirumaleswar Reddy (tireddy) <[email-masked]>; IESG <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

[TR] Thanks, Looks good, will add at the end of the last line "without a MOBILITY-TICKET attribute".

-Tiru

pr

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 10 Sep 2016 04:40:12 +0000

From: Jonathan Lennox [mailto:[email-masked]]
Sent: Friday, September 9, 2016 11:50 PM
To: Pete Resnick <[email-masked]>
Cc: Suresh Krishnan <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; The The IESG <[email-masked]>; Tirumaleswar Reddy (tireddy) <[email-masked]>; [email-masked]
Subject: Re: [tram] GenART post-telechat comment on draft-ietf-tram-turn-mobility-08

Hi Tiru,

and the client would need to retransmit the Refresh Request.
If that's not what you meant, you should probably clarify.
To be precise, “IP address” here should be “IP address or source port”, right?

[TR] Yup, will update.

-Tiru

One case I’m thinking of is where a client moved to a new private IP address, but is still behind the same CGN and so has the same external IP address.