[Gen-art] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11

Richard L. Barnes <rbarnes@bbn.com> Tue, 19 June 2012 15:31 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F04821F8522; Tue, 19 Jun 2012 08:31:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 309x36VYmpwj; Tue, 19 Jun 2012 08:31:45 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 1558B21F8508; Tue, 19 Jun 2012 08:31:44 -0700 (PDT)
Received: from ros-dhcp192-1-51-6.bbn.com ([192.1.51.6]:54956) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Sh0OW-0004gM-WF; Tue, 19 Jun 2012 11:31:05 -0400
From: Richard L. Barnes <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Jun 2012 11:31:42 -0400
Message-Id: <D48790C9-D5B0-407E-A917-DC6D5BC42D9D@bbn.com>
To: ietf@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-nfsv4-federated-fs-admin@tools.ietf.org, gen-art@ietf.org
Mime-Version: 1.0 (Apple Message framework v1278)
X-Mailer: Apple Mail (2.1278)
Subject: [Gen-art] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2012 15:31:46 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-nfsv4-federated-fs-admin-11
Reviewer: Richard Barnes
Review Date: Jun-19-2012
IETF LC End Date: Not known
IESG Telechat date: Jun-28-2012

Summary: Almost ready, couple of issues

MAJOR: 

4. / 7.
This protocol allows for the provisioning of security information as part of the FedFsNsdbParams, in the form of a certificate to be used in verifying a TLS server certificate.  There are two notable issues with how the document does this now:
1. Section 4 does not adequately specify how the certificate in the FedFsNsdbParams should be used in the verification process.  Is it to be used as a trust anchor, so that any subordinate certificate is considered valid?  Or perhaps it is to be matched against the end-entity certificate.  In either case, it seems like it would be sufficient to provision a certificate fingerprint (or even a public key fingerprint) instead of the whole certificate.
2. In the security considerations, the document should discuss the implications of provisioning trust information in this way (depending on how it is used), and any requirements for security mechanisms to be used in these cases.


MINOR:

2. 
It's not clear what the difference is between utf8string_cs and utf8string_cis.  Should you mention at some point that these MUST be UTF-8, even though the XDR won't enforce that?  (Say, at the beginning of Section 4?)

3.
It's not clear to me how FEDFS_ERR_PERM differs from FEDFS_ERR_ACCESS.  I don't see it called out for use anywhere in the procedure calls.  Perhaps this is a legacy of prior versions that should be deleted?


EDITORIAL: 

3. 
The definition of FEDFS_ERR_LOOP isn't actually related to looping.  It seems like this should either detect a loop (e.g., via a repeated name), or be renamed something like FEDFS_ERR_TOOMANYREFERS.

4. "The port is the NSDB transport port for the LDAP interface"
Suggest rewording to clarify that this is an LDAP/TCP port (I initially wondered if other transports could be used), e.g.:
"The port value in the FedFsNsdbName indicates the LDAP port on the NSDB"