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 <jouni.nos...@gmail.com> 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: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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
