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

"Black, David" <david.black@emc.com> Mon, 15 August 2016 14:02 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 3017912B018; Mon, 15 Aug 2016 07:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ePsyNGik; dkim=pass (1024-bit key) header.d=emc.com header.b=hHzBQV8M
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 X-9kETKHGAjD; Mon, 15 Aug 2016 07:02:07 -0700 (PDT)
Received: from esa6.dell-outbound.iphmx.com (esa6.dell-outbound.iphmx.com [68.232.149.229]) (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 1EA6A12DDC1; Mon, 15 Aug 2016 07:02:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=emc.com; i=@emc.com; q=dns/txt; s=jan2013; t=1471269727; x=1502805727; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8MaXOZDl90gyv3crJiv+fMw/V4R97CYFlrIKI/qhARs=; b=ePsyNGikofarZTFfRF0JLJS7LDrJZEgStihxYtdiEEWX+NazrEif66h/ 3b3dCx/ndEH/XVv3q9LRmOA+kw0SkK+ou6pVpMmwdoeRz/THCTHE/rdcE HFLAP2b3ZnPZSjV5ofipQsXx9JFaEbe5DXOB5rwOuP9aP9TGPchC0BMvG A=;
Received: from mailuogwhop.emc.com ([168.159.213.141]) by esa6.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Aug 2016 09:02:05 -0500
Received: from maildlpprd05.lss.emc.com (maildlpprd05.lss.emc.com [10.253.24.37]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7FE23Ig027516 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Aug 2016 10:02:04 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u7FE23Ig027516
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1471269725; bh=7RJ8GXoIK1ePlzmQEIpBwwy7mS8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=hHzBQV8MLsuAKy8MuL3WE5nsfUIqHWw+gVppTtyr+61RqaClK9qMPViej1R4W4rao KcM3EK+sgJ3kW9cG8fETN7xfjU9gxSwlMTv2LXFhr0M/28M2aTLQqJ0t5OxfGxYFo6 bNPPPr/UqcdlYQ6AAMLrnJOsvHjTz0ollHYfBt6I=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com u7FE23Ig027516
Received: from mailusrhubprd53.lss.emc.com (mailusrhubprd53.lss.emc.com [10.106.48.18]) by maildlpprd05.lss.emc.com (RSA Interceptor); Mon, 15 Aug 2016 10:00:31 -0400
Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd53.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id u7FE1m7T012976 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Mon, 15 Aug 2016 10:01:48 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0266.001; Mon, 15 Aug 2016 10:01:47 -0400
From: "Black, David" <david.black@emc.com>
To: Jouni <jouni.nospam@gmail.com>
Thread-Topic: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
Thread-Index: AQHR9GXqHo5l3sUqzUW22tNYgGEdsKBFrVMwgAPKiQCAAJgkEA==
Date: Mon, 15 Aug 2016 14:01:46 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362F64B443@MX307CL04.corp.emc.com>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com> <CE03DB3D7B45C245BCA0D243277949362F63C060@MX307CL04.corp.emc.com> <5E8635C6-A600-4D4C-9009-C2134B79BFAE@gmail.com>
In-Reply-To: <5E8635C6-A600-4D4C-9009-C2134B79BFAE@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.252.48.185]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd53.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/NHIbH8n901lg1cMuMDkfr7O1Cww>
Cc: "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>, "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: Mon, 15 Aug 2016 14:02:10 -0000

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

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