[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?
- [tsvwg] Ben Campbell's No Objection on draft-ietf… Ben Campbell
- Re: [tsvwg] Ben Campbell's No Objection on draft-… Lucy yong
- Re: [tsvwg] Ben Campbell's No Objection on draft-… Ben Campbell
- [tsvwg] Ben Campbell's No Objection on draft-ietf… Lucy yong
- Re: [tsvwg] Ben Campbell's No Objection on draft-… Ben Campbell