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