Re: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd)

"Haynes, Tom" <> Fri, 22 June 2012 15:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D81C821F86F7; Fri, 22 Jun 2012 08:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8fEOXcta-sQ4; Fri, 22 Jun 2012 08:06:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DF36021F86E5; Fri, 22 Jun 2012 08:06:15 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.77,458,1336374000"; d="scan'208";a="657232717"
Received: from ([]) by with ESMTP; 22 Jun 2012 08:06:15 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q5MF6FDB015259; Fri, 22 Jun 2012 08:06:15 -0700 (PDT)
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Fri, 22 Jun 2012 08:05:23 -0700
From: "Haynes, Tom" <>
To: "" <>, "" <>, "" <>, "" <>, "" <>
Subject: Re: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd)
Thread-Topic: [nfsv4] Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11 (fwd)
Thread-Index: AQHNUIiR3/6yfq+JwEWuYsxcwIlj9Q==
Date: Fri, 22 Jun 2012 15:06:14 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 25 Jun 2012 07:15:31 -0700
Cc: "" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jun 2012 15:06:17 -0000

<comments inline>

On 6/20/12 11:53 AM, "James Lentini" <> wrote:

>Below is the Gen-ART review comments for the FedFS admin protocol.
>---------- Forwarded message ----------
>Date: Tue, 19 Jun 2012 11:31:42 -0400
>From: Richard L. Barnes <>
>To:, The IESG <>,
>Subject: Gen-ART LC review of draft-ietf-nfsv4-federated-fs-admin-11
>I am the assigned Gen-ART reviewer for this draft. For background on
>Gen-ART, please see the FAQ at
>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
>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.

I'm going to have to work with the rest of the group to answer this one.

>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?)

Argh, we did away with utf8string_cs and utf8string_cis in 3530bis.

utf8string_cis should be utf8val_REQUIRED4
utf8string_cs should be ascii_REQUIRED4

In 3530bis, these are defined as:

typedef :opaque  :utf8string<>:UTF-8 encoding for strings.
typedef :utf8string:utf8_expected:String expected to be UTF-8 but no
typedef :utf8string:utf8val_RECOMMENDED4:String SHOULD be sent UTF-8 and
SHOULD be validated
typedef :utf8string:utf8val_REQUIRED4:String MUST be sent UTF-8 and MUST
be validated
typedef :utf8string:ascii_REQUIRED4:String MUST be sent as ASCII and thus
is automatically UTF-8

I'll change the types and there is already some text pointing the reader
to Chapter 12 of 3530bis.

>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?

This is inherited from the base NFSv4.0 documentation and also NFSv3. It
is also the difference between EPERM and EACCES. (see  NFS4ERR_ACCESS (Error Code 13)

   Indicates permission denied.  The caller does not have the correct
   permission to perform the requested operation.  Contrast this with
   NFS4ERR_PERM (Section, which restricts itself to owner or
   privileged user permission failures.  NFS4ERR_PERM (Error Code 1)

   Indicates requester is not the owner.  The operation was not allowed
   because the caller is neither a privileged user (root) nor the owner
   of the target of the operation.

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

This has its roots in a Linux error code:

>> As I recall this error is supposed to be returned when fedfsd is passed
>>a pathname that contains too many symlinks.  The equivalent errno on
>>Linux is called ELOOP.

We are striving to maintain parity.

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

Thanks, we've been struggling with this issue, I'll take your suggested
change here.

>nfsv4 mailing list