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

Adam Roach <adam@nostrum.com> Wed, 24 May 2017 22:24 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: nfsv4@ietf.org
Delivered-To: nfsv4@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5C31242F7; Wed, 24 May 2017 15:24:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nfsv4-versioning@ietf.org, Spencer Shepler <spencer.shepler@gmail.com>, nfsv4-chairs@ietf.org, spencer.shepler@gmail.com, nfsv4@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.51.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149566464280.8636.3410259789096739461.idtracker@ietfa.amsl.com>
Date: Wed, 24 May 2017 15:24:02 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/xfzRGwscqow-YhgMq_fRNZpI1hk>
Subject: [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
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: Wed, 24 May 2017 22:24:03 -0000

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..."