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

[Jouni <[e-mail]>]

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