-----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”.
