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

"Black, David" <david.black@emc.com> Fri, 12 August 2016 19:25 UTC

Return-Path: <david.black@emc.com>
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 32BFE12DA84; Fri, 12 Aug 2016 12:25:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=emc.com header.b=t7L7ApNq; dkim=pass (1024-bit key) header.d=emc.com header.b=muKo7/Vp
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 wTrFtqFnsGPq; Fri, 12 Aug 2016 12:25:16 -0700 (PDT)
Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DFEA12D84B; Fri, 12 Aug 2016 12:25:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1471029916; x=1502565916; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uNuHE+mPTxL9HmkvRn76hu63FUix924N9AnwzMDtgz4=; b=t7L7ApNqtqFH4f2aEJJDndPeYWMLX3B3XDxLMu1jxJC4k0TSIKjDINx6 oVxjw5NegeR4bJv9iBZ7fhbEgsJtpp48gLlbdbR5O59gg+MLGWW3wWfSS C52xBdBEHKg8zkl0xbIJzntqQudpkQlzYEgkApQSA6B9/5XHGGxEsOQKe Q=;
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2016 14:25:14 -0500
Received: from maildlpprd54.lss.emc.com (maildlpprd54.lss.emc.com [10.106.48.158]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7CJPC5Q008605 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Aug 2016 15:25:13 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u7CJPC5Q008605
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1471029913; bh=C98co2u5HDwqFElzfffKp8XJUXw=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=muKo7/VpEYjkBoQsuz9Icej0IXLo4gD5JXouXeIvjdMjp4boWjOuGgAUcnRyFaxII Xa/7QBcK71KxgLU5nw38oMTu7cB6cFF76pe249Tc+cK4c6QJjVG05Gk5Khmn3/giAS 3bkwJwWHl3aLk20JC5z25M8WYVHmM3m+KlDEVb8U=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com u7CJPC5Q008605
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd54.lss.emc.com (RSA Interceptor); Fri, 12 Aug 2016 15:24:41 -0400
Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7CJP2AY012677 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 12 Aug 2016 15:25:03 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0266.001; Fri, 12 Aug 2016 15:25:02 -0400
From: "Black, David" <david.black@emc.com>
To: Jouni <jouni.nospam@gmail.com>, "gen-art@ietf.org (gen-art@ietf.org)" <gen-art@ietf.org>, "draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org" <draft-ietf-tsvwg-gre-in-udp-encap.all@ietf.org>
Thread-Topic: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
Thread-Index: AQHR9GXqHo5l3sUqzUW22tNYgGEdsKBFrVMw
Date: Fri, 12 Aug 2016 19:25:01 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F63C060@MX307CL04.corp.emc.com>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com>
In-Reply-To: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.130]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/_Dy58d3LRkzLfVR7F11xjZpPbSo>
Cc: "Black, David" <david.black@emc.com>
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: Fri, 12 Aug 2016 19:25:18 -0000

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" ;-).

>    - 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 ...

>  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.

>  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.

>  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.

>  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.

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”.