[tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Mon, 26 September 2016 23:13 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8674812B03F; Mon, 26 Sep 2016 16:13:35 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.34.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147493161550.5041.6760488501697947208.idtracker@ietfa.amsl.com>
Date: Mon, 26 Sep 2016 16:13:35 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/iEQqXLl0Nfpr_WFHLUAnvny2baQ>
Cc: david.black@emc.com, tsvwg-chairs@ietf.org, tsvwg@ietf.org, draft-ietf-tsvwg-gre-in-udp-encap@ietf.org
Subject: [tsvwg] Ben Campbell's No Objection on draft-ietf-tsvwg-gre-in-udp-encap-18: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 23:13:35 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-tsvwg-gre-in-udp-encap-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm balloting no objection, but I have a few comments that may be worth
considering:

- general: The draft has a structure where you mention requirements in
one section, then go into more detail in later sections. While this is a
perfectly reasonable structure, it has resulted in a fair bit of
redundant 2119 language. In general it's better to avoid that because it
can make future updates more error prone. In this case, most of the
language is consistent, so it's probably not worth changing. But there
are a few cases where the language appears inconsistent, or is restated
in sufficiently different ways to be potentially confusing. I've tried to
call out specifics, but may have missed some.

-1, paragraph 5, first sentence: I found the sentence structure
confusing. I think you mean to say that GRE-in-UDP tunnels are not safe
to carry arbitrary traffic over the Internet, but it can be read to mean
to say that since the internet is an arbitrary traffic environment, it's
not safe to use GRE-in-UDP on it.

-1, paragraph 6: When might security not be a concern? Would it make
sense to start with an assumption that security _is_ a concern, then
consider situations for which it might not be?

- 6.1, paragraph 1: Previous sections said UDP checksums SHOULD be used
for IPv4. Should this section be interpreted to mean that _if_ the
checksum is used, it MUST be processes this way? If so, that could use
clarification.

-6.2, paragraph 2: Does the allowance to use the zero-checksum in some
cases violate the MUST for UDP checksums over IPv6?

-8, third paragraph:
Isn’t this just a restatement of the previous requirement that all
traffic carried over default gre-in-udp tunnels must be congestion
controlled?

-8, paragraph 5:
This also seems a restatement of the requirement that traffic on generic
tunnels MUST be congestion controlled. Given that you probably don’t
select your network path based on the nature of the data, I think it’s
better stated in the original terms.

-8, last paragraph:
Do circuit-breakers really keep non congestion-controlled traffic from
“escaping”, or does it mitigate the damage if it does escape?

-11, 2nd paragraph: Previous sections just said DTLS can be used if there
are security concerns. This is not consistent with that. (I prefer the
SHOULD to a "can")

-11, last paragraph: Is SHOULD sufficient for this case?