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

[Suresh Krishnan]

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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-tram-turn-server-discovery-08

[Tirumaleswar Reddy (tireddy)]

Hi Ralph,

Please see inline [TR]

From: Ralph Droms [mailto:rdroms.i...@gmail.com]
Sent: Thursday, September 1, 2016 4:36 PM
To: Jari Arkko 
Cc: Tirumaleswar Reddy (tireddy) ; 
draft-ietf-tram-turn-server-discovery@ietf.org; Review Area 
gen-art@ietf.org Team ; IETF discussion list 
Subject: Re: Review of draft-ietf-tram-turn-server-discovery-08

RI just completed a quick review of draft-ietf-tram-turn-server-discovery-08.  
The DNS Service Discovery section is much improved.  I have a couple of 
comments on the revised text:


I suggest adding a reference to the IANa "Service Name and Transport Protocol 
Port Number Registry", 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=Turn,
 as the source of the service  names "turn" and "turns".

[TR] Will refer to RFC5766 which introduced the above service names.

While the example DNS records for "exampleco TURN Server" are technically 
correct, they would most likely be generated by the DNS-SD/mDNS library in a 
server, rather than appearing in a DNS server zone file somewhere.  For 
clarity, it might be better to use the unicast DNS versions of the DNS-SD 
records by substituting "example.com" for "local".

[TR] May be I am missing something, 
https://tools.ietf.org/html/rfc6763#section-4.1.1 says the instance name will 
not be machine-generated and will be a user-friendly name.

In my opinion, the details in section 5.1 are redundant with and (possibly) not 
identical to the specification in RFC 6762 and RFC 6763.  Specifically, Figure 
1 includes a typo; there should be separate A/ query and reply messages.  
More generally, DNS-SD/mDNS servers may return the SRV, TXT, A and  records 
in the first reply, as an optimization.  I think it would be better, in this 
document, to specify simply that TURN servers and clients use the message 
exchanges specified in those RFCs for TURN server discovery.

[TR] Sure, will remove the figure.

Thanks and Regards,
-Tiru



- Ralph


On Sep 1, 2016, at 4:05 AM, Jari Arkko 
> wrote:
Ralph, Tiru — thanks for the updates and the review. I’ve looked at the change 
draft and I think it is fine now.

Jari

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Spencer Dawkins at IETF]

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) <
tire...@cisco.com> wrote:

> *From:* Pete Resnick [mailto:presn...@qti.qualcomm.com]
> *Sent:* Tuesday, September 6, 2016 9:25 PM
> *To:* IESG 
> *Cc:* t...@ietf.org; draft-ietf-tram-turn-mobility@ietf.org; General
> Area Review Team 
> *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.
>
> 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.
>
> [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/
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Tirumaleswar Reddy (tireddy)]

From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: Tuesday, September 6, 2016 9:25 PM
To: IESG 
Cc: t...@ietf.org; draft-ietf-tram-turn-mobility@ietf.org; General Area 
Review Team 
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.

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.

[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/
Qualcomm Technologies, Inc. - +1 (858)651-4478
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-art LC review: draft-ietf-taps-transports-11

[Robert Sparks]

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 last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-taps-transports-11
Reviewer: Robert Sparks
Review Date: 6 Sep 2016
IETF LC End Date: 9 Sep 2016
IESG Telechat date: not yet scheduled

Summary: Ready (with very small nits) for publication as an 
Informational RFC


Please consider a light touch to the Introduction and perhaps the 
Abstract making the point of this survey explicit. I can figure it out 
from reading the TAPS charter - I shouldn't have to go that far. The 
Abstract touches (too) briefly on this being background for determining 
a common set of transport services, but the message is lost in the 
roll-call of protocols that dominate the text. I don't think listing the 
surveyed protocols in the abstract is going to help anyone in the future 
- consider leaving the list for the body of the text.


Please also make it more clear that this is _only_ background for input 
into the next task of converging on a common core set of transport 
services. It would be a disservice to the community if someone in the 
future could argue "That service wasn't identified in 
draft-ietf-taps-transport so it's out of scope for anything the working 
group should be targeting". It looks like a lot went into this survey to 
try to make sure it provided a comprehensive overview of existing 
services, but I don't think that it's intent was to provide the 
definitive, exhaustive, list.


Should 3.7 acknowledge the state of work on TLS 1.3?

I find a list of things that have RTP and ICMP as peers to be 
unsettling.  I don't think it's worth the delay to ask the group to 
rationalize what's in the list and what isn't, or to restructure the 
psuedo-transports and the helpfully-related-protocol into different 
sections (questions like "why didn't you give FECFRAME its own section?" 
aren't going to help with the work this is supposed to inform). Perhaps 
the touch to the abstract and introduction requested above can say 
something like "The protocols listed here were chosen to help expose as 
many potential transport services as possible, and are not meant to be a 
comprehensive survey or classification of all transport protocols." With 
that thought, I challenge "classifies" in the Abstract - I think the 
document would serve just as well (and maybe avoid introducing 
controversy) if it doesn't claim to classify things.


I'm not finding the tables in Section 5 illuminating and they're 
potentially distracting and may not be right (why isn't reliability for 
RTP "Poss"  for example?). Please consider just removing the tables.


Nits:

The last paragraph of 3.3.1 was particularly hard to parse.

Searching the existing RFCs for "back-up" I don't find it used the way 
this document uses it. Should it use "back-off" instead?



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Gen-ART LC review of draft-ietf-mptcp-experience-06

[Dan Romascanu]

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 last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-mptcp-experience-06

Reviewer: Dan Romascanu
Review Date: 9/6/16
IETF LC End Date: 9/13/16
IESG Telechat date: 9/15/16

Summary: Ready with issues

A very useful and well written document, which gathers implementation
and deployment experience and expands the list of the Multipath TCP
Use Cases. A few minor issues described below, if addressed, could
improve the clarity and usability of the document.

Major issues:

Minor issues:

1. The 'Introduction' section starts with the statement:

> Multipath TCP was standardized in [RFC6824] and five independent
   implementations have been developed.

Saying 'was standardized' seems misleading to me, as RFC 6824 is an
experimental RFC, so not even standards-track (this putting aside the
discussions whether RFCs are standards). Actually at no point this
document mentions that Multipath TCP is Experimental, this seems odd.

2. It would be useful to clarify the statement about the iOS
implementation of Multipath TCP in the Introduction by mentioning what
'single application' is referred.

> However, this particular Multipath TCP implementation is currently only used 
> to support a single application.'

3. I am questioning whether the 'Multipath TCP proxies' section really
belongs to the use cases or rather to operational experience. After
all it's about a strategy of deployment of Multipath TCP in cases
where clients and/or servers do not support Multipath TCP but the need
exists probably because of the combination of one or several other use
cases.

4. In section 3.5:

>There have been suggestions from Multipath TCP users to modify the
   implementation to allow the client to use different destination ports
   to reach the server.  This suggestion seems mainly motivated by
   traffic shaping middleboxes that are used in some wireless networks.
   In networks where different shaping rates are associated to different
   destination port numbers, this could allow Multipath TCP to reach a
   higher performance.  As of this writing, we are not aware of any
   implementation of this kind of tweaking.

Beyond the potential problems described in the following paragraph, is
such a 'tweak' consistent with the protocol definition, or would it
need to cause changes in the protocol as defined now? A clear
recommendation seems to be needed here.

5. A more clear recommendation would be useful also in 3.8. It is not
clear here whether the segment size selection is a design or a tuning
issue that can/should be added to applications.


Nits/editorial comments:

1. Section 3.12 contains a timed statement 'As of September 2015 ...'
which should be updated or maybe edited to make it less
time-dependent.

2. It seems to me that [RFC6824] and [RFC6181] should be Normative
References as they describe the protocol extensions, and the initial
list of use cases which is expanded by this document. Without reading
these two documents, this one does not make too much sense.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

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

[Pete Resnick]

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

.

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 
:



--
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 
Qualcomm Technologies, Inc. - +1 (858)651-4478___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art