Re: [nfsv4] Adam Roach's No Objection on draft-ietf-nfsv4-versioning-09: (with COMMENT)

David Noveck <davenoveck@gmail.com> Thu, 25 May 2017 13:16 UTC

Return-Path: <davenoveck@gmail.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFE24129470; Thu, 25 May 2017 06:16:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Yxc7sA9N223s; Thu, 25 May 2017 06:16:00 -0700 (PDT)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 8E9E51270A7; Thu, 25 May 2017 06:16:00 -0700 (PDT)
Received: by mail-io0-x234.google.com with SMTP id f102so135421392ioi.2; Thu, 25 May 2017 06:16:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AwGpD6H7HOjWLHnS0wdcT0gZ29bNlPolfdZ95mS/yW8=; b=dyl3sq1AujsXCHbLvtnFf+Fl7+ZHm6crWld7ZXd8//tHztba6MVqqnB5tKhGbEZ7pX Csxi/zxsz52jtJWq6QujB5voMqqn8vGdQc0n6c7GEpt8GfGLHpyIUszLIWOD+ntEvGGQ yytXeQm2gOf0ZeoyIm9FbM3KAYEAJsAK62XS3/gS3so1EJK5KNdbN68w3t1zAn6sZeIp qrfdtvV56ObUy5H1TR8pwngqqY8Fm+7szit30nVV3ocVWCx+NE4o0IDd1Tbn36I3qIR/ uE2RQtd3gbBqx0tfpTIx7vs4FAwiU1Q838lwfIsIouA69mM6Yz8rG3mGiFIHnaXB3x9a 1s0g==
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; bh=AwGpD6H7HOjWLHnS0wdcT0gZ29bNlPolfdZ95mS/yW8=; b=dSe2xnHrntDUU82kk7Owz/RYBbJ/ZRL72TwUz7RTarRtirgch8xQ0Iuz1la1aejVZZ NpUvehkZi9H9jVVkSa6STIF707dnXrEnervgwNHH17lNYTbIiV0ODd7+hU/wJlDmRQnG FKFT43xkf1Z7zpygAdmD0Tvp/FDaeX7EUUkPVXJl3OepSYs81s2e31AgicqfoHP3HDhf DmiKVwX+vhmL37qUHvG8sp5QsFU2sQTWtPkvtT7YtXeM2d2oeqfoWF4t18rBPpXGi3c/ +/KHDbUkr6R1YkVR+SrB2lfqOml72IdjrDdVPSToFNkFiJgKQ2+uBg2wHcFJf6d4UsUO yhpQ==
X-Gm-Message-State: AODbwcAk+Lrb6ozbHXUrcptdUCrsAT1PwE23FjDtuyKEceDbADADt7OY Ct5slSQFf/FhgZsBxRkugNmNgNjHFg==
X-Received: by 10.107.6.69 with SMTP id 66mr37109521iog.163.1495718159854; Thu, 25 May 2017 06:15:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.4.148 with HTTP; Thu, 25 May 2017 06:15:59 -0700 (PDT)
In-Reply-To: <149566464280.8636.3410259789096739461.idtracker@ietfa.amsl.com>
References: <149566464280.8636.3410259789096739461.idtracker@ietfa.amsl.com>
From: David Noveck <davenoveck@gmail.com>
Date: Thu, 25 May 2017 09:15:59 -0400
Message-ID: <CADaq8jcGOggSZFnuvWc-4Z_FCUxYERHyRmKZb-rwbzfE_gSfJg@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-nfsv4-versioning@ietf.org, Spencer Shepler <spencer.shepler@gmail.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, "nfsv4@ietf.org" <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="001a113edff89a36d20550590599"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/ME8Voe_MJP0avXcl1r4Vk0cP1CE>
Subject: Re: [nfsv4] Adam Roach's No Objection on draft-ietf-nfsv4-versioning-09: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 13:16:03 -0000

>- The document uses both "interversion" and "inter-version" -- please
> choose one and stick with it.

Will fix by adopting "inter-version".

> - As section 8 is targeted at an audience that may not be concerned with
> the remainder of the document, I would suggest that the introduction
> specifically point implementors to it.

Propose adding the following new (final) paragraph to the Introduction.

The rules in this document supersede previous rules regarding
minor versions.  The new rules concerning protocol extension and
minor versions are summarized in Section 3 while rules regarding
the interaction of minor versions appear in Section 8.


> - The first bullet under "Based on the type of server" in section 9.2
> says older servers can only interoperate with older clients; when, in
> fact, they can clearly operate with newer clients described by the third
> bullet of "Based on the type of client:". Recommend: "...interoperate
> with clients implementing the older version. However, clients that do not
> implement the older version of the feature..."

Good catch.  Will Fix.

On Wed, May 24, 2017 at 6:24 PM, Adam Roach <adam@nostrum.com>; wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-nfsv4-versioning-09: 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-nfsv4-versioning/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I suspect this was discussed as part of the document's development, but
> it's clear that this new approach to versioning presents new challenges
> for preventing collisions of numeric constants and bitmap bit meanings.
> Previously (by my understanding; this isn't my area), minor versions
> included a full XDR, and therefore effectively carried their own complete
> and hermetically-sealed registry with them. With the new approach,
> additional documents may extend the XDR independently. I understand that
> IANA registration of the various codepoints in NFS is probably too
> daunting a task to consider reasonable, and that there is effectively an
> understanding in the working group that future extensions to a minor
> version are responsible for checking that they don't conflict with any
> published or pending extensions prior to publication. I don't have an
> issue with this approach per se, but I think it should be more clearly
> spelled out in this document.
>
> Editorial:
>
> - The document uses both "interversion" and "inter-version" -- please
> choose one and stick with it.
>
> - As section 8 is targeted at an audience that may not be concerned with
> the remainder of the document, I would suggest that the introduction
> specifically point implementors to it.
>
> - The first bullet under "Based on the type of server" in section 9.2
> says older servers can only interoperate with older clients; when, in
> fact, they can clearly operate with newer clients described by the third
> bullet of "Based on the type of client:". Recommend: "...interoperate
> with clients implementing the older version. However, clients that do not
> implement the older version of the feature..."
>
>
>