Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Jari Arkko <jari.arkko@piuha.net> Thu, 29 September 2016 05:41 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CDA12B05B; Wed, 28 Sep 2016 22:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dPgCWEbN7ND; Wed, 28 Sep 2016 22:41:19 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4612B057; Wed, 28 Sep 2016 22:41:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CFA232CC9B; Thu, 29 Sep 2016 08:41:17 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhgVOcEgWJ1U; Thu, 29 Sep 2016 08:41:16 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id CC5EB2CC40; Thu, 29 Sep 2016 08:41:15 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4596C05C-27BD-46FD-B167-3B9B7CB52861"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <7c4013a0-2c8c-7c6a-39b1-66a4073a6558@gmail.com>
Date: Thu, 29 Sep 2016 08:41:13 +0300
Message-Id: <7AF1006F-41B2-46A5-BF67-B8D38E373234@piuha.net>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <CE03DB3D7B45C245BCA0D243277949362F63C060@MX307CL04.corp.emc.com> <5E8635C6-A600-4D4C-9009-C2134B79BFAE@gmail.com> <CE03DB3D7B45C245BCA0D243277949362F64B443@MX307CL04.corp.emc.com> <7c4013a0-2c8c-7c6a-39b1-66a4073a6558@gmail.com>
To: jouni.nospam@gmail.com
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Lv3AU2BfBms6iFTt_rqWhiKFOn0>
Cc: "draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org" <draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org>, "Black, David" <david.black@emc.com>, "gen-art@ietf.org \(gen-art@ietf.org\)" <gen-art@ietf.org>
Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Sep 2016 05:41:23 -0000

Thanks for the review, Jouni!

I see that the newer versions have corrected at least some of the issues discussed here; didn’t check all but it seems fine enough now for me to ballot no-objection. Which I have done.

Jari

On 19 Aug 2016, at 19:19, Jouni Korhonen <jouni.nospam@gmail.com>; wrote:

> David,
> 
> 8/15/2016, 7:01 AM, Black, David kirjoitti:
>> Hi Jouni,
>> 
>> Three quick responses:
>> 
>> IPv6 NATs - Ah, now I see the concern.  We'll rewrite the middlebox material on IPv6 zero checksums to avoid using NATs as examples.
>> 
>> The "MUST" for the "MAY" requirement in RFC 6936 (#9) doesn't do anything aside from telling people to go read that requirement in the context of the rest of RFC 6936, which seems useful.
>> 
>>>>> o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not known to be
>>>>>  congestion-controlled.. I would be interested in knowing how to enforce this “MUST”
>>>>>  specifically in the Internet case.
>>>> 
>>>> In contrast, this is effectively a rhetorical question - there is no plausible
>>> protocol mechanism to enforce this, as a Congestion-Controlled header flag is
>>> about as realistic as the Evil header flag
>> [... snip ...]
>>> Ok. Knowing this MUST has no meaning is real world I would then consider not
>>> having the MUST here.. that would be a waste of precious capital letters ;)
>> 
>> That's not quite right.  There are no protocol means to enforce this, but it does clearly tell an operator not to do this, which does have meaning in the real world ;-).
> 
> I kind of agree on that. However, in that case I would reword the use of MUST differently. Since there is no "protocol way" etc to enforce the MUST I would reword text here more clearly as a deployment guidance. Something along lines "a deployment using a default GRE-in-UDP tunnel MUST take any precautions not to forward traffic that is not known to be congestion controlled into the GRE-in-UDP tunnel". Clumsy English but something to that direction..
> 
> - Jouni
> 
> 
>> 
>> Please be patient with us - I'm trying to take vacation this week and have a bunch of drafts that need attention "in the queue" ahead of this one, so it may take a couple of weeks to do the editing and post a new version.
>> 
>> Thanks, --David
>> 
>>> -----Original Message-----
>>> From: Jouni [mailto:jouni.nospam@gmail.com]
>>> Sent: Sunday, August 14, 2016 8:49 PM
>>> To: Black, David
>>> Cc: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-
>>> encap.all@ietf.org
>>> Subject: Re: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
>>> 
>>> Hi David,
>>> 
>>> See inline.
>>> 
>>> 
>>>> On 12 Aug 2016, at 12:25, Black, David <david.black@emc.com>; wrote:
>>>> 
>>>> Hi Jouni,
>>>> 
>>>> Thanks for the review.  I have a few comments as draft shepherd (anything that
>>> I don't comment on below is editorial and will likely just be fixed in the next
>>> version):
>>>> 
>>>>>  - It repeats.. the same statements multiple times.
>>>> 
>>>> If you have specific examples of repeated statements that caught your eye,
>>> please let us know.  Otherwise, the response will be "Thank you for your input" ;-
>>> ).
>>> 
>>> 
>>> Stuff like this..
>>> 
>>> 1. Introduction:
>>> 
>>>  "This document specifies a generic GRE-in-UDP encapsulation for..”
>>>  ..
>>>  "This document specifies GRE-in-UDP tunnel requirements for two..”
>>>  ..
>>> 
>>> 2. Applicability Statement
>>> 
>>>  "This document specifies GRE-in-UDP tunnel usage in the general..”
>>> 
>>> It is mostly about the writing style - so very subjective. Specifically in the Intro
>>> could be condensed into fewer fewer paragraphs. It is more like I’d like to see
>>> what this document specifies in one place and not reading multiple paragraphs
>>> saying again “this document specifies..”.
>>> 
>>>> 
>>>>>  - When reading the document I get the feeling it is actually two documents. The
>>>>>    technical specification (which is very short) and the general deployment
>>>>>    considerations document. I would have split it to two but that is just me.
>>>> 
>>>> Well, that suggests that something important is missing.
>>>> 
>>>> As specified in full generality, the GRE-in-UDP protocol is not safe for general
>>> deployment in the public Internet.  Therefore, two different applicability
>>> scenarios are specified in Section 2:
>>>> 	- Default: Restrict the protocol implementation and usage to that which is
>>> safe for general deployment in the public Internet.
>>>> 	- Traffic Managed Controlled Environment (TMCE): Restrict the nature of
>>> the network so that the general protocol is safe to deploy.
>>>> This is why the two specifications have to go together - the protocol spec by
>>> itself is not safe to deploy in the public Internet, and hence needs the
>>> deployment material.  In 20/20 hindsight, I think this should have been explained
>>> at the start of Section 2 (there is  a brief mention of this in the Introduction, but
>>> that's clearly not sufficient to convey the point).
>>>> 
>>>> We'll revise the draft accordingly, including ...
>>> 
>>> Thanks.
>>> 
>>>> 
>>>>> o On line 129 is says:
>>>>> 	   This document specifies GRE-in-UDP tunnel requirements for two
>>>>>  Based on the earlier text I would suggest saying “..document also specifies..”
>>>> 
>>>> That's the brief mention of the same applicability topic in the introduction.
>>> While "also" is definitely the wrong word to use in this context, we'll look into
>>> rephrasing that sentence to make it clearer.
>>> 
>>> Ok. Thanks.
>>> 
>>>> 
>>>>> o In Section 7.1 I find it a bit odd discussing NATs in the specific context of IPv6. If
>>>>>  you have a specific IPv6 NAT scenario in mind either spell it out or give a reference
>>>>>  to a specification that describes the technology/use case.
>>>> 
>>>> Section 7.1 is not about NATs in general - it's about middlebox interactions with
>>> UDP zero checksums for IPv6.   This discussion is necessitated by RFC 6936's
>>> discussion of middleboxes, and needs to remain in about its current form for that
>>> reason.
>>> 
>>> I mean the following here. Section 7.1 starts off:
>>> 
>>>  "IPv6 datagrams with a zero UDP..”
>>> 
>>> Then few lines later:
>>> 
>>>  "updates the UDP checksum field, such as NATs or firewalls."
>>> 
>>> I get really itchy bringing NAT even into examples in IPv6 context. We do have
>>> RFC6296 NPTv6, which is checksum neutral. If there are other IPv6 NAT thingies in
>>> mind here, I would be explicit or just leave the NAT out.
>>> 
>>>> 
>>>>> o On line 654 is says:
>>>>> 	        MUST comply with requirement 1 and 8-10 in Section 5 of RFC 6936
>>>>>  How is this “MUST” enforced?
>>>> 
>>>> The same as any other "MUST" in this draft - those four are implementation
>>> requirements for GRE-in-UDP implementations - the requirements have been
>>> referenced instead of copied.
>>> 
>>> Ok. It seem I misunderstood this slightly wrong. I was more thinking middleboxes
>>> on path that are not my implementations and how to enforce the MUST on those
>>> e.g., cases where there is a middlebox that does not obey the MUST but still
>>> seems to work ok.
>>> 
>>> One more question. How do I MUST a MAY requirement (RFC6936 Section 5 req.
>>> #9)?
>>> 
>>>> 
>>>>> o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not known to be
>>>>>  congestion-controlled.. I would be interested in knowing how to enforce this “MUST”
>>>>>  specifically in the Internet case.
>>>> 
>>>> In contrast, this is effectively a rhetorical question - there is no plausible
>>> protocol mechanism to enforce this, as a Congestion-Controlled header flag is
>>> about as realistic as the Evil header flag - see RFC 3514, taking notion of its
>>> publication date.   Hmm ... is this C-C header flag a candidate for next April ;-) ??
>>> Applicability restrictions on deployment/usage are generally not enforceable via
>>> technical means - all we can say is that a deployment that does not comply with
>>> the applicability restrictions is not compliant with the RFC.
>>> 
>>> Ok. Knowing this MUST has no meaning is real world I would then consider not
>>> having the MUST here.. that would be a waste of precious capital letters ;)
>>> Seriously, if one cannot control it or even know whether some traffic is
>>> congestion controlled beyond a generic assumption state in previous sentence I
>>> see no need for RFC2119 language here.
>>> 
>>> Thanks,
>>> 	Jouni
>>> 
>>> 
>>>> 
>>>> Thanks, --David
>>>> 
>>>>> -----Original Message-----
>>>>> From: Jouni [mailto:jouni.nospam@gmail.com]
>>>>> Sent: Friday, August 12, 2016 2:51 AM
>>>>> To: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-
>>>>> encap.all@ietf.org
>>>>> Subject: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
>>>>> 
>>>>> 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
>>>>> 
>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>>>>> 
>>>>> Document: draft-ietf-tsvwg-gre-in-udp-encap-16
>>>>> Reviewer: Jouni Korhonen
>>>>> Review Date: 8/11/2016
>>>>> IETF LC End Date: 2016-08-12
>>>>> IESG Telechat date: (if known)
>>>>> 
>>>>> Summary:  Ready with minor nits.
>>>>> 
>>>>> Major issues: None.
>>>>> 
>>>>> Minor issues: Read on..
>>>>> 
>>>>> Editorials/nits:
>>>>> o My “complaint” of this document is basically on the following.. these are
>>>>> writing
>>>>>  style things so feel free to neglect:
>>>>>  - It repeats.. the same statements multiple times.
>>>>>  - When reading the document I get the feeling it is actually two documents.
>>> The
>>>>>    technical specification (which is very short) and the general deployment
>>>>>    considerations document. I would have split it to two but that is just me.
>>>>> 
>>>>> The other nits.
>>>>> 
>>>>> o There are bunch of acronyms that are not expanded either never or on their
>>> first use.
>>>>>  Some examples include UDP, DSCP, DS, PMTU, MPLS, VNP, .. Pay attention
>>> to these.
>>>>> o In the Introduction give a reference to EtherType e.g., the repository where
>>> they
>>>>>  are maintained or by whom they are maintained.
>>>>> o On line 129 is says:
>>>>> 	   This document specifies GRE-in-UDP tunnel requirements for two
>>>>>  Based on the earlier text I would suggest saying “..document also specifies..”
>>>>> o On line 143 I would also (following the previous style in the paragraph)
>>> capitalize
>>>>>  “wide area networks” as well.
>>>>> o In multiple places (lines 236, 887) the reference is after the full stop. Place
>>> full
>>>>>  stop after the reference.
>>>>> o The document uses both tunnel ingress/egress and
>>>>> encapsulator/decapsulator. Is there a
>>>>>  specific reason to have this differentiation? If not use common terminology
>>> throughout
>>>>>  the document.
>>>>> o On line 654 is says:
>>>>> 	        MUST comply with requirement 1 and 8-10 in Section 5 of
>>>>>  How is this “MUST” enforced?
>>>>> o In Section 7.1 I find it a bit odd discussing NATs in the specific context of IPv6.
>>> If
>>>>>  you have a specific IPv6 NAT scenario in mind either spell it out or give a
>>>>> reference
>>>>>  to a specification that describes the technology/use case.
>>>>> o In Section 8 and lines 784-785 has a “MUST NOT” for traffic that is not known
>>> to be
>>>>>  congestion-controlled.. I would be interested in knowing how to enforce this
>>> “MUST”
>>>>>  specifically in the Internet case.
>>>>> o Line 909 typo “ether” -> “either”.
>>>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art