Hi Jouni, David and I work on it to address your comments.
Thanks, Lucy -----Original Message----- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Thursday, August 18, 2016 10:40 AM To: Lucy yong; gen-art@ietf.org (gen-art@ietf.org); draft-ietf-tsvwg-gre-in-udp-encap....@ietf.org Subject: Re: [Gen-art] Generate review of draft-ietf-tsvwg-gre-in-udp-encap-16 Hi Lucy, See inline ;) 8/12/2016, 2:10 PM, Lucy yong kirjoitti: > 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. 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. > - 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. 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 > > Regards, > Lucy > > > > -----Original Message----- > From: Gen-art [mailto:gen-art-boun...@ietf.org] On Behalf Of Jouni > Sent: Friday, August 12, 2016 1:51 AM > To: gen-art@ietf.org (gen-art@ietf.org); > draft-ietf-tsvwg-gre-in-udp-encap....@ietf.org > 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. > > 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 > _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
