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

["Black, David" <[e-mail]>]

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

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