[nfsv4] Barry Leiba's No Objection on draft-ietf-nfsv4-lfs-registry-05: (with COMMENT)

"Barry Leiba" <barryleiba@computer.org> Thu, 09 April 2015 18:33 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AFD1A8854; Thu, 9 Apr 2015 11:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 dfVbkdaKreNn; Thu, 9 Apr 2015 11:33:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B571A87C2; Thu, 9 Apr 2015 11:33:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Barry Leiba <barryleiba@computer.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150409183353.28077.92552.idtracker@ietfa.amsl.com>
Date: Thu, 09 Apr 2015 11:33:53 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/gXXMUrZzSPQZO7890txAzJEMmuw>
Cc: nfsv4@ietf.org
Subject: [nfsv4] Barry Leiba's No Objection on draft-ietf-nfsv4-lfs-registry-05: (with COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 09 Apr 2015 18:33:55 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-nfsv4-lfs-registry-05: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-nfsv4-lfs-registry/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Version -05 addresses my most significant comment, and thanks very much
for that.

Some non-blocking, minor comments here:

Very much a nit, but drafts have this sort of thing all the time, and we
should probably say something more generally (I think I'll post to the
IETF discussion list about the general point):

In the abstract...

   To allow multiple MAC mechanisms and label formats to co-exist in a
   network, this document proposes a registry of label format
   specifications.  This registry would contain label format identifiers
   and would provide for the association of each such identifier with a
   corresponding extensive document document outlining the exact syntax
   and use of the particular label format.

When the draft was written, it was "proposing" a registry, and should
that registry be created it "would contain" and "would provide" things. 
But it's now up for approval for RFC publication, and these
characterizations are inapt; when it's published, the registry will have
been created and will be providing all that.  Drafts should be written --
at least by the time they enter last call -- to have the right tone as
published RFCs.  Here, I suggest these changes:

1. "proposes" -> "creates"
2. "would contain" -> "contains"
3. "would provide" -> "provides"

-- Section 5 --
As best I can tell, this question from IANA wasn't answered in the last
call discussion, and it needs to be:

> Where should this new registry be located? Should it be placed at an
> existing URL? If not, should the title of the new webpage be "NFS
> Security Label Format Selection," or do you expect other registries
> that would require a different title to be placed there? Also, should
> it be filed under a new or an existing category at
http://www.iana.org/protocols?

IANA will sort this out with you in any case, but it would be good for
the document to say where you would like IANA to put the registry.

In Table 1, I think "Available for IANA Assignment" would be better than
"Reserved for IANA Assignment", but it's a really small point.

In Section 5.2, I suggest using the full name for the registry (add the
word "Security").