Re: [nvo3] Comments on draft-ietf-nvo3-gue-05
Tom Herbert <tom@herbertland.com> Mon, 13 March 2017 23:15 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C48129B24 for <nvo3@ietfa.amsl.com>; Mon, 13 Mar 2017 16:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePvZarMpC4eh for <nvo3@ietfa.amsl.com>; Mon, 13 Mar 2017 16:15:13 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81ED1129BC7 for <nvo3@ietf.org>; Mon, 13 Mar 2017 16:15:13 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id x35so44069922qtc.2 for <nvo3@ietf.org>; Mon, 13 Mar 2017 16:15:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z/n+KWGfGBkzqoiTmI90kPA1zPffh14ONaD0XwfrwSU=; b=XTrglOY7W7IW055PNOZJFiVlELvE0FP6gZXxDHgrTl8pgFsUiY0MD2bK2cHyNGVfHI UaH+NYjoGuuXXUZS1+t4NITv9Gh+whmU8iF6lDQXL3DwVCwdGbOSbphstFd0B9d+ylHv 5U9sTKket2BfiBEAtF408R9m4R7lZji/Va5iDlGD03QnJpJ01R6cFEFc5IRiBGGuL88M wALoEAevjnZDNxYMy/1WuYgvgrvimvMmeey428zvV3gL3UJgJoEM5DPfZ3E+5BruQQbf noZs5rTwE/qFbH1vysTRUBDPI3dRlQS51kmwXCWetQgo7wmV8inXHS7b2Z6hNivr7ppB TPWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Z/n+KWGfGBkzqoiTmI90kPA1zPffh14ONaD0XwfrwSU=; b=pmYtorNuDczOW3YSOsY+x32UjM1CpihGaAUBTdQGP/eR+YpTVBfUssQuVJCt8A7Wfd mF/L7Jb2S7hZ0oIAhLBcTmm+zZuBLAnXPTn1/5y1nCWGFWd9js1mfBWq0IebVIdcSzwc n09mpJUwWm2ims/f1/K8knLG+CYH5PtJRjOiySsXt2ScIX07HaYcUHiBB0P0o9ZpimRr XBS0HCD/8rS0JzcSrwPgAVNDGWyuiI9IZlpN15qRz/Um5WlOc1+XBo8i+mxzXFsOKm6W QrJ5nb6Oqe4qTM/kOKMZufc+cRn+j5wKOd+vvO+MMvYo5g8067ssKjpgkVT9IEsbwWPt 5dfw==
X-Gm-Message-State: AMke39nX8Y+R57Nbyx3+7x9p7JBO27291ltv6BHnxuPcpJB+zWoAxa5fbBOEsK/wtnq9sIJ1lSBk5j/kQCZ00Q==
X-Received: by 10.237.35.83 with SMTP id i19mr35059056qtc.70.1489446912440; Mon, 13 Mar 2017 16:15:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.84.83 with HTTP; Mon, 13 Mar 2017 16:15:12 -0700 (PDT)
In-Reply-To: <CAL0qLwbcU5OL2r-LsR7Fvh9LTzKS_j9CLu6GHRegBMsO8_nNvw@mail.gmail.com>
References: <CAL0qLwbcU5OL2r-LsR7Fvh9LTzKS_j9CLu6GHRegBMsO8_nNvw@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 13 Mar 2017 16:15:12 -0700
Message-ID: <CALx6S35L-mv_h+MRRuEJ+XPRYAzsj_dFWMfruOUprJC78WFCPw@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/2bA7Vf6bRnvzTNdHIFPIVle9scc>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [nvo3] Comments on draft-ietf-nvo3-gue-05
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 23:15:16 -0000
Hi Murray, Thanks for the detailed reviewed! I've cc'ed int-area WG list also since GUE in a WG item there now. A few replies are inline... On Wed, Mar 8, 2017 at 1:07 AM, Murray S. Kucherawy <superuser@gmail.com> wrote: > Hi all, > > Tom asked me to review this and some related drafts. These are mostly raw > notes; hopefully you can make some sense of them. If not, I'm happy to > clarify what any of them mean. > > The document seems to me (with my ART area eyes) to be generally in good > shape. The vast majority of my feedback is editorial stuff, but there are a > few key points I want to highlight: > > 1. In a few places you use MUST, which I assume is meant to indicate a > normative requirement. To do that in an RFC, you have to reference RFC2119 > and include in your Introduction section some boilerplate that it specifies. > Then, depending on how strict the IESG feels like being, all your uses of > MUST/SHOULD/SHOULD NOT/MAY (in lowercase or in all-caps) now need to be > all-caps (or changed to synonyms). In addition, sometimes they would like > you to explain, given a SHOULD or SHOULD NOT, when one might legitimately > deviate from that advice. You might even be asked to explain some of the > MUSTs if they aren’t already obvious. In my raw notes below I've called out > the lowercase must, may, etc. to which this applies. Will be more specific with normative language. > 2. There are several acronyms that need to be expanded and/or > references provided on first use. > 3. The IANA Considerations section establishes Tom as the reference > point for the port registration, but it uses an old work email address. If > that’s actually in the registry, this one should update it, preferably to > something that will be useful long-term. Yes, we will update contact information. > 4. Again with the IANA Considerations section, you’re using Standards > Action as the gate for registering anything. The IESG might ask you to > explain why such strict rules are being used. Specifically, why would one > of the lower requirements for registry changes be inadequate? Changed to "RFC required" > 5. Although I think I managed to figure out the rest of the document, > Section 3.6 confused me. Maybe if you explain what’s going on there I can > suggest some alternative text. Rewrote this a bit. > 6. As far as I know, appendices are never normative, so there’s no > need to say that. > Okay. > -MSK > > Abstract: > - such tunnels => such as tunnels > > Section 1: > - such as virtual => such as a virtual (or “the”) > > Section 1.1: > - don't end the "C-bit" entry with a period, or do it for all of them > > Section 2: > - expand OAM on first use > - what's going to happen when versions 2 and 3 are exhausted? > Then we need a new protocol :-). In reality, I think it is unlikely this will ever happen in the lifetime of the protocol. Because GUE is arbitrarily extensible, the version number is mostly a fail-safe so that if we found a deficiency in the primary GUE header we could fix this with a new version. Note that version 1 is a convenient means to do header compression for the most common use case and not really a another version, we don't foresee burning any more version numbers for anything like that. > Section 3.1: > - do we need to define or reference a definition for "local tuple"? > - define or reference ECMP > - "not applied" => "not applied," > - using "MUST" needs a reference to RFC2119 somewhere in Section 1 with the > usual boilerplate > - "C-bit: When set, indicates" ... > - Hlen: "header_len" is bytes, correct? > - Proto/ctype: "When the C-bit is set, this ..." > - "Flags." => "Flags:" > - "Private data: ... If private data are present, that portion of the > payload immediately follows the extension fields in the header. The length > ..." > > Section 3.2: > - where are control message types enumerated? > > Section 3.2.1: > - "When the C-bit is not set, the ..." > - When the outer IP protocol is IPv4, the proto ..." > - "the proto field can be set" > - "MUST NOT"? > > Section 3.2.2: > - "MUST" > - include a reference to where type 0 is defined > > Section 3.3: > - missing comma > - "may" > - "optional" > > Section 3.3.1: > - "may" > - why "may" a flag indicate the presence of an extension field? should that > be "some flags indicate..."? > - "must" > - "may" again > - don't understand "if two flag bits are paired, a field may possibly be > three different lengths" I added an example. > - "must" > - "... for example ..." is a run-on sentence > - "must not" > - "may" > - "... is set, which indicates ..." > - don't understand how I would know bits 17-19 are paired > > Section 3.4: > - "may" > - starting sentence with "Where" > - "... necessary, for instance it might contain ..." > - "... from an encapsulator, the packet ..." x2 > - "may" > > Section 3.5.1 > - "carry formatted message" => "carry formatted data" > - "may" > - the mdash needs a space before it > > Section 3.6: > - this part is confusing > - what is a “GUE Transform Field” and where is it defined? > - "... obfuscated, that is the transport..." needs a comma or mdash > - "a trivial destination options" > - Where is "PadN" defined? > - "In this case, 'Next header' MUST refer ..." > > Section 4.2: > - title says IPv6, first line says IPv4 > > Section 5: > - "Server 1" should be "Host 1" to match the diagram > > Section 5.3: > - "may" > - "for instance" > - "packets, that is encapsulating ... " needs an extra comma or an mdash > - "should" > - "GUE then" needs a comma > > Section 5.4: > - "may" > > Section 5.4.1: > - "received" needs a comma > - "in tact" > - comma before "which" between the boxes > > Section 5.4.2: > - comma after "received" > - "must" > > Section 5.5: > - when would one legitimately deviate from the "SHOULD NOT" advice? > - "may" > - "In this case the router..." > > Section 5.6: > - "may" > - comma after "For instance" > - "must not" > - "because" should be "merely because"? > > Section 5.6.1: > - "may" > - comma after "For instance" > - "may" > - "must" x3 > - "should" > > Section 5.6.2: > - "must" > - "may" > > Section 5.7: > - "must" => "needs to be" > - "may" > > Section 5.7.1: > - "must" > - "permissable" => "permissible" > - semicolon or period after "IPv4" > - comma after "IPv6" > - "may" > > Section 5.7.2: > - comma before "it SHOULD" > - comma after "By default" > - comma after "for instance" > > Section 5.7.3: > - comma after "IPv6" > - "must" x2; weird use of "must" before a list of non-MUSTard clauses > - "may" > - "should not" > - comma after "By default" > > Section 5.8: > - "should" > - missing period at end of first paragraph > - "must" > - "should" > > Section 5.9: > - "Note" should be "Note that" > - "may" > - "finer-grained" > - "may" > > Section 5.10: > - "may" > - "should" > - "may" > > Section 5.11.1: > - "finer-grained" > - "contents of clear-text packet" > - final paragraph is a run-on sentence > > Section 5.11.2: > - "should" x4, and when would you not? > - remove "to one", add a comma > - "may" x3 > - "should not", and when would you deviate? > > Section 5.12: > - "must" > - "optional" > - "but" or "however" before "the details" > - last bullet: "If security is used that would..." => "Use of security would > ..." > > Section 6.1: > - expand and reference all the acronyms in the last bullet > > Section 6.2: > - expand TCAM > > Section 7: > - end first bullet with a period > - "may" > > Section 8.1: > - do you still want to use your google.com address? what if you move from > FB? > - is draft-herbert-gue correct? > > Section 8.2-8.4: > - is Standards Action necessary? why not Specification Required? > > Sections 10.1 and 10.2: > - should be ordered > > Appendix A: > - aren't all appendices informational? > > Appendix A.1: > - "must" > - "should" x3 > - "out-of-order" > > Appendix A.2: > - comma after "encapsulation" > > Appendix A.2.1: > - "may" > - comma after "method" > - comma after "offload" > - comma after "method" > - "cover" should be "covered" > - maybe quote "not", as is done later in the section > - comma after "So", and maybe use "Thus" or "Therefore" > > Appendix A.3: > - comma before "which" > - parenthesize "if tunneling" > - "recommended" > - faulty mdash > - "should not" > > Appendix B.2: > - "should" > > Appendix B.3: > - don't understand the first sentence > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 >
- [nvo3] Comments on draft-ietf-nvo3-gue-05 Murray S. Kucherawy
- Re: [nvo3] Comments on draft-ietf-nvo3-gue-05 Tom Herbert