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

From: Jouni <[email-masked]>
Date: Thu, 11 Aug 2016 23:51:04 -0700

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

---

From: "Black, David" <[email-masked]>
Date: Fri, 12 Aug 2016 19:25:01 +0000

Hi Jouni,

>    - 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" ;-).

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

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

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

>  o On line 654 is says:
>  	        MUST comply with requirement 1 and 8-10 in Section 5 of RFC 6936

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.

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

Thanks, --David

> -----Original Message-----
> From: Jouni [mailto:[email-masked]]
> Sent: Friday, August 12, 2016 2:51 AM
> To: [email-masked] ([email-masked]); draft-ietf-tsvwg-gre-in-udp-
> [email-masked]
> Subject: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
>

---

From: Lucy yong <[email-masked]>
Date: Fri, 12 Aug 2016 20:51:38 +0000

Hi Jouni,

Thank you for the review and correction. Pls see inline below.

-----Original Message-----
From: Gen-art [mailto:[email-masked]] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: [email-masked] ([email-masked]); [email-masked]
Subject: [Gen-art] 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.

Major issues: None.

Minor issues: Read on..

Editorials/nits:

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.
[Lucy] I will check. 
 o In the Introduction give a reference to EtherType e.g., the repository where they
   are maintained or by whom they are maintained.
[Lucy] I will put RFC7042 as the reference.
 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..”
[Lucy] ack.
 o On line 143 I would also (following the previous style in the paragraph) capitalize
   “wide area networks” as well.
[Lucy] ack.
 o In multiple places (lines 236, 887) the reference is after the full stop. Place full
   stop after the reference.
[Lucy] My mistake. Will correct them.
 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.
[Lucy] I would prefer to use two teams in the document. Tunnel ingress and egress is the view from network perspective,
And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is odd to say encapsulator IP address. I open to add a clarification if that causes a concern.

 o On line 654 is says:
 	        MUST comply with requirement 1 and 8-10 in Section 5 of
   How is this “MUST” enforced?
[Lucy] Do you concern on the wording or the implementation? 

 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.
[Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP applications do not perform UDP checksum in IPv4 network; most UDP applications perform UDP checksum in IPv6 network because of IPv6 requirement [RFC2460]. Thus some middleboxes validate UDP checksum if it is in IPv6. [RFC6935] [RFC6936] relax the need to perform UDP checksum in some special cases, which is applicable to this draft. But we need to state out the potential impact that is specific in IPv6.  
 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.
[Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not appropriate"? (match the wording in requirement 3 of Section 2.1.1)  
 o Line 909 typo “ether” -> “either”.
[Lucy] ack. Thx. 

Regards,
Lucy

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Lucy yong <[email-masked]>
Date: Fri, 12 Aug 2016 21:10:10 +0000

Hi Jouni,

OOPS, forget this one, sorry.

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.
Lucy: perhaps some can reference previous section. 
   - 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.
Lucy: When we were developing this document, we kindly became clear ourselves, we need to address two parts and want to do in one document.

Regards,
Lucy

-----Original Message-----
From: Gen-art [mailto:[email-masked]] On Behalf Of Jouni
Sent: Friday, August 12, 2016 1:51 AM
To: [email-masked] ([email-masked]); [email-masked]
Subject: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Major issues: None.

Minor issues: Read on..

Editorials/nits:

The other nits.

---

From: Jouni <[email-masked]>
Date: Sun, 14 Aug 2016 17:48:56 -0700

Hi David,

See inline.

> On 12 Aug 2016, at 12:25, Black, David <[email-masked]> wrote:
> 
> Hi Jouni,
> 

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

> We'll revise the draft accordingly, including ...

Thanks. 

> 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…

Ok. Thanks.

> 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 t…

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.

> 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)?

> 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 fl…

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

---

From: "Black, David" <[email-masked]>
Date: Mon, 15 Aug 2016 14:01:46 +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.

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

> Sent: Sunday, August 14, 2016 8:49 PM
> To: Black, David
> Cc: [email-masked] ([email-masked]); draft-ietf-tsvwg-gre-in-udp-
> [email-masked]
> Subject: Re: Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16
> 
> Hi David,
> 
> See inline.
> 
> 
> > 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):
> >
> > 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:
> 
> 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..”.
> 
> >
> > 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).
> >
> > 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.
> 
> >
> > 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 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:
> > 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.
> 
> > 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
> >

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Aug 2016 08:34:24 -0700

Hi Lucy,

Thank you for the response. Sorry for my slow response. I tried to be on 
a vacation last week/weekend so my checking of emails was sparse at best 
;) See inline.

> [Lucy] I will put RFC7042 as the reference.

Or maybe  http://standards.ieee.org/regauth/ethertype/eth.txt
Either one works.

> And encapsulator/decapsulator is the view at the ingress or egress. E.g. it is odd to say encapsulator IP address. I open to add a clarification if that causes a concern.

Maybe you should say this also in the draft?

> [Lucy] Do you concern on the wording or the implementation?

See the discussion I had with David.

> [Lucy] This section describes middlebox specialty on IPv6 traffic. Most UDP applications do not perform UDP checksum in IPv4 network; most UDP applications perform UDP checksum in IPv6 network beca…

Here as well, see the discussion I had with David.

> [Lucy] By IETF standard. :)  How about replace "MUST NOT" with "are not appropriate"? (match the wording in requirement 3 of Section 2.1.1)

Again, we did some more elaborations with David. Anyway, one concern I 
had was on having MUSTs on things that you cannot really guard or 
control using some protocol.. they are more like deployment 
recommendations or good wishes at best then.. which I think do not 
belong to a protocol spec.

- JOuni

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 18 Aug 2016 08:39:45 -0700

Hi Lucy,

See inline ;)

> Lucy: perhaps some can reference previous section.

See my response to Davin on this. Basically, when you say "this document 
specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.

> Lucy: When we were developing this document, we kindly became clear ourselves, we need to address two parts and want to do in one document.

There's definitely wordsmithing to do here. Now the "guidelines" and 
protocol specification (the very short one) and kind of mixed, which to 
me makes reading a bit confusing experience. If you want to keep all in 
one document, it is fine by me. I was just expressing my personal 
opinion on structuring.

- JOuni

---

From: Lucy yong <[email-masked]>
Date: Thu, 18 Aug 2016 15:42:15 +0000

Hi Jouni,

David and I work on it to address your comments.

Thanks,
Lucy 

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Thursday, August 18, 2016 10:40 AM
To: Lucy yong; [email-masked] ([email-masked]); [email-masked]
Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16

Hi Lucy,

See inline ;)

> Lucy: perhaps some can reference previous section.

See my response to Davin on this. Basically, when you say "this document specifies.." etc do not spread that to multiple paragraphs and sections. 
Keep them in one place and not in increamental style spread around.

> Lucy: When we were developing this document, we kindly became clear ourselves, we need to address two parts and want to do in one document.

There's definitely wordsmithing to do here. Now the "guidelines" and protocol specification (the very short one) and kind of mixed, which to me makes reading a bit confusing experience. If you want to keep all in one document, it is fine by me. I was just expressing my personal opinion on structuring.

- JOuni

> To: [email-masked] ([email-masked]); 
> [email-masked]

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 19 Aug 2016 09:19:45 -0700

David,

> 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