Re: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)

Mike Kupfer <mike.kupfer@oracle.com> Fri, 26 May 2017 17:27 UTC

Return-Path: <mike.kupfer@oracle.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 3EF961294B3; Fri, 26 May 2017 10:27:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 XpGpGj6Pca6m; Fri, 26 May 2017 10:27:41 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13020129329; Fri, 26 May 2017 10:27:41 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v4QHRdid000387 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 May 2017 17:27:39 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v4QHRcNR000320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 26 May 2017 17:27:39 GMT
Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id v4QHRcsC012298; Fri, 26 May 2017 17:27:38 GMT
Received: from athyra.us.oracle.com (/10.132.144.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 26 May 2017 10:27:38 -0700
From: Mike Kupfer <mike.kupfer@oracle.com>
To: David Noveck <davenoveck@gmail.com>
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, "nfsv4-chairs@ietf.org" <nfsv4-chairs@ietf.org>, draft-ietf-nfsv4-versioning@ietf.org, NFSv4 <nfsv4@ietf.org>, The IESG <iesg@ietf.org>, Mike Kupfer <mike.kupfer@oracle.com>
References: <149459980428.13464.2287524739238339362.idtracker@ietfa.amsl.com> <1494602246.10434.3.camel@gmail.com> <CAKKJt-c=K-V0OPX3gk1bFGG9qwKTYuULn-ANd=7=fy=sZ5r_mA@mail.gmail.com> <CAKKJt-fzBMPAcvubV7EecOfQLM_QLBKbc3uK_gc1dH=tU=nTPw@mail.gmail.com> <CADaq8jc9JjaUCNeTrhKAWPoUpQzvaMp-sXXBtkUD0PeoP+GTbQ@mail.gmail.com>
Date: Fri, 26 May 2017 10:27:31 -0700
In-Reply-To: <CADaq8jc9JjaUCNeTrhKAWPoUpQzvaMp-sXXBtkUD0PeoP+GTbQ@mail.gmail.com> (David Noveck's message of "Fri, 26 May 2017 11:39:50 -0400")
Message-ID: <86zidzv88s.fsf@athyra.us.oracle.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/0YgZ0lPaqnS4alJa-xiR429P0OY>
Subject: Re: [nfsv4] Spencer Dawkins' Yes 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: Fri, 26 May 2017 17:27:42 -0000

David Noveck <davenoveck@gmail.com> writes:

>       In some cases extensions will contain elements such as new operations
>       or previously invalid switch cases.  Although it is possible to
>       determine whether these OPTIONAL elements are supported using the
>       rules described above, those defining extensions containing such
>       elements have the option of defining new attributes that specify
>       whether the feature is present and supported.  

I'd like to replace the second sentence with something like

  Although it is possible to determine whether these OPTIONAL elements are
  supported using the rules described above, an extension that contains
  such elements could also define a new attribute that indicates whether
  the feature is present and supported.

The concerns I have with the original wording are

1. I think the use of singular "extension" and "attribute" is clearer
than using plurals.

2. I'm uneasy about using "specify" in this context, since it seems to
imply that the attribute's sole purpose is to indicate whether the
feature is supported.  If the feature is already defining a new
attribute, I don't want to encourage the creation of another attribute
when the first one would be good enough for indicating support.

The rest of the text looks fine to me.

mike