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”. > >
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Jouni Korhonen
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Lucy yong
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Jouni Korhonen
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Jouni Korhonen
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Black, David
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Jouni
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Lucy yong
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Lucy yong
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Black, David
- [Gen-art] Generate review of draft-ietf-tsvwg-gre… Jouni
- Re: [Gen-art] Generate review of draft-ietf-tsvwg… Jari Arkko
- [Gen-art] Gen-ART Review of draft-ietf-straw-b2bu… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-straw-… Lorenzo Miniero
- [Gen-art] Gen-ART Review of draft-ietf-6lo-dispat… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Paul Miller (NT)
- [Gen-art] Gen-ART Review of draft-ietf-straw-b2bu… Russ Housley
- [Gen-art] Gen-ART Review of draft-ietf-kitten-pki… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Michiko Short
- Re: [Gen-art] Gen-ART Review of draft-ietf-straw-… Lorenzo Miniero
- Re: [Gen-art] Gen-ART Review of draft-ietf-straw-… Ben Campbell
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Michiko Short
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Benjamin Kaduk
- Re: [Gen-art] Gen-ART Review of draft-ietf-straw-… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Jari Arkko
- Re: [Gen-art] Gen-ART Review of draft-ietf-kitten… Michiko Short
- Re: [Gen-art] Gen-ART Review of draft-ietf-6lo-di… Gabriel Montenegro
- [Gen-art] Gen-ART Review of draft-ietf-6lo-dispat… Russ Housley
- Re: [Gen-art] Gen-ART Review of draft-ietf-6lo-di… Gabriel Montenegro
- Re: [Gen-art] Gen-ART Review of draft-ietf-6lo-di… Jari Arkko