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

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 19 August 2016 16:19 UTC

Return-Path: <jouni.nospam@gmail.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 3DD2D12D0CA; Fri, 19 Aug 2016 09:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7lGRMdaTBKPJ; Fri, 19 Aug 2016 09:19:54 -0700 (PDT)
Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2943212D18E; Fri, 19 Aug 2016 09:19:54 -0700 (PDT)
Received: by mail-pa0-x22f.google.com with SMTP id pp5so17474037pac.3; Fri, 19 Aug 2016 09:19:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=reply-to:subject:references:to:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=Yf2rijN7bWiCRFGOztWMQfLns3ldHf3igtZRvKAfvbc=; b=Dx1nmjxFrlrNyeX/Aug15lK/AQZaeds/pajnxg4OUZAt9jZs7itMwHSHdRKlKmfGNR LjLRsxwDwjES8JzEkPGsmxrxMH8pOBOYspSMnQpcrpmr2/mF78aRVfhHnSsCT+MkMJyN kOKvYbdpN3yfxc/k3UZ9Yf5T9L6FqRX9qwcSSnPkW431V74pAyorxKMIl6MFR46mRhAD Ok74phaD3Ceuv1KECDUGiNEcvtLlbAIoDw9Vl1Td80u1ysi6F4ltbXZxNv5sduBHRyyc njmHbeUkwje6XX3RdPhF+ysdSXIAyckvEZdttk0ghb6B5wRlzRbrn3TbcuupW0lDyD0v JtBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:cc:from :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=Yf2rijN7bWiCRFGOztWMQfLns3ldHf3igtZRvKAfvbc=; b=PceJ5f6V9xBtEF/5hewyTOMWVdJaPIOqAoQbyJoJFJXE/O7czoC+CX8P1BavfdrrPf 8dvZsh+vtqpinckyB5FI4OGAzms7UANFKSqZhxxWQ/2t5E525Zg73JWn8xP9Pp/BKeaI /h0WqmomD0EzS3E+LxmU2tiCtfAYUR6XQxYkP70d2MGTzhUS/zqTzEe4jtj8X83PPGh7 3GXcDhCyqzeMMpV+2Kqqd3ts/ngPfevqIW1YOIU9DcPa6xKL6368CR9vJMG5rDk1zcxX asAW3pftwcQw2Wsk8a7MI1Bv4yrZNeA1qRo9g3v6Y2HwOWOQJBPOGEgg6m+3vS9ekc8g F8iQ==
X-Gm-Message-State: AEkoouuwGUZt1U1Y5az07RZVwrd2heUJaj0UQYxU+dljoarV/6ifXAd6gIIqybGveWpDQQ==
X-Received: by 10.66.246.134 with SMTP id xw6mr15257330pac.35.1471623593125; Fri, 19 Aug 2016 09:19:53 -0700 (PDT)
Received: from [10.16.66.0] ([216.31.219.19]) by smtp.googlemail.com with ESMTPSA id n69sm7683321pfa.77.2016.08.19.09.19.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Aug 2016 09:19:52 -0700 (PDT)
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>
To: "Black, David" <david.black@emc.com>
From: Jouni Korhonen <jouni.nospam@gmail.com>
Message-ID: <7c4013a0-2c8c-7c6a-39b1-66a4073a6558@gmail.com>
Date: Fri, 19 Aug 2016 09:19:45 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362F64B443@MX307CL04.corp.emc.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/EbLBHuQ8xe3tqp3ctz1IFGmu0G4>
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>
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
Reply-To: jouni.nospam@gmail.com
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, 19 Aug 2016 16:19:57 -0000

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