[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..."
- [nfsv4] Adam Roach's No Objection on draft-ietf-n… Adam Roach
- Re: [nfsv4] Adam Roach's No Objection on draft-ie… David Noveck