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

[Jari Arkko <[e-mail]>]

Thanks for the review, Jouni!

I see that the newer versions have corrected at least some of the issues discussed here; didn’t check all but it seems fine enough now for me to ballot no-objection. Which I have done.

Jari

On 19 Aug 2016, at 19:19, Jouni Korhonen <[e-mail]> wrote:

> 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”.
>>>> 
>> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art