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:jouni.nos...@gmail.com] > Sent: Sunday, August 14, 2016 8:49 PM > To: Black, David > Cc: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp- > encap....@ietf.org > 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 <david.bl...@emc.com> 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:jouni.nos...@gmail.com] > >> Sent: Friday, August 12, 2016 2:51 AM > >> To: gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp- > >> encap....@ietf.org > >> 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
