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

Reply via email to