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

[Jouni Korhonen <[e-mail]>]

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:[e-mail]]
>> Sent: Sunday, August 14, 2016 8:49 PM
>> To: Black, David
>> Cc: [e-mail] ([e-mail]); draft-ietf-tsvwg-gre-in-udp-
>> [e-mail]
>> 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 <[e-mail]> 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:[e-mail]]
>>>> Sent: Friday, August 12, 2016 2:51 AM
>>>> To: [e-mail] ([e-mail]); draft-ietf-tsvwg-gre-in-udp-
>>>> [e-mail]
>>>> 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”.
>>>
>