Re: [Int-area] [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: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6A2129BDC for <int-area@ietfa.amsl.com>; Mon, 13 Mar 2017 16:15:15 -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=ham 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 RvUt7LzazrYR for <int-area@ietfa.amsl.com>; Mon, 13 Mar 2017 16:15:13 -0700 (PDT)
Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (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 9C2B8129BCE for <int-area@ietf.org>; Mon, 13 Mar 2017 16:15:13 -0700 (PDT)
Received: by mail-qt0-x22f.google.com with SMTP id n21so44169390qta.1 for <int-area@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=rAoQ/DmcOA8M97UmJ0GjEU5asidn1Mxf8Qof3skMaEy+FhTB+sLE+YLNNmYErOzDfL qh0y2U9SNiBmPrE8SCUFSgtOw5w29iRNh+lhS52bQ81GzQTTMT+jGt9KAn00gHpRBiWW QQp+yjRjQo+37pv29pmrSnaYNaHHc0JIohZPOx+kGz8PZuih9iyhIF5Z2Dbizs9BIdBd oWrxTeJ6qzfPXpeEr4apN/QR8LHzlIeNgo8RdOPiuXMZ/fYQlk2OXbp432z0I3YYqeOl DW+ogcOgSZ6OToToRKFVIJ14D3prDKYD0pH3fl6Cbk3rUWs3ziYyX/DpGByvwhGYS5Ce TKjQ==
X-Gm-Message-State: AMke39mwOXanxJKaGFL+0Wu3aqmm0YH221Z4Vdd77LTYikT5wjmx3gn4eFq0r6tKlp8Kp3Uwbc/H9Puh0UGajA==
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/int-area/k0CClnvSPfidDkm46yC_uGEHlt0>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] [nvo3] Comments on draft-ietf-nvo3-gue-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Mar 2017 23:15:15 -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
>