Re: [nfsv4] [FedFS] XDR encoding of path "/"

<david.noveck@emc.com> Thu, 14 October 2010 09:47 UTC

Return-Path: <david.noveck@emc.com>
X-Original-To: nfsv4@core3.amsl.com
Delivered-To: nfsv4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F89F3A68CC for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 02:47:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.679
X-Spam-Level:
X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-JWUu34SeXw for <nfsv4@core3.amsl.com>; Thu, 14 Oct 2010 02:47:25 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B18AC3A67A7 for <nfsv4@ietf.org>; Thu, 14 Oct 2010 02:47:25 -0700 (PDT)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9E9mh91025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Oct 2010 05:48:43 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Thu, 14 Oct 2010 05:48:37 -0400
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9E9mPY6016353; Thu, 14 Oct 2010 05:48:25 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.41]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Oct 2010 05:48:24 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Oct 2010 05:48:23 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80028515C8@CORPUSMX50A.corp.emc.com>
In-Reply-To: <alpine.LFD.2.00.1010131704120.4707@jlentini-linux.nane.netapp.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] [FedFS] XDR encoding of path "/"
Thread-Index: ActrGyeVWmYteCzmRaCgf0Ob2HOe6gAaIgyA
References: <alpine.LFD.2.00.1010130934190.4707@jlentini-linux.nane.netapp.com><026701cb6af1$c3c19f20$4b44dd60$@gmail.com><BF3BB6D12298F54B89C8DCC1E4073D80028514CB@CORPUSMX50A.corp.emc.com> <alpine.LFD.2.00.1010131704120.4707@jlentini-linux.nane.netapp.com>
From: <david.noveck@emc.com>
To: <jlentini@netapp.com>
X-OriginalArrivalTime: 14 Oct 2010 09:48:24.0565 (UTC) FILETIME=[F1BB9A50:01CB6B84]
X-EMM-MHVC: 1
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] [FedFS] XDR encoding of path "/"
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 14 Oct 2010 09:47:27 -0000

Since your document will be going first, I think it does make sense to
put text relative to this issue in federated-fs-admin.  If this is a new
type, I think it would simplify things to simply say that it had to be a
zero-length array for "/".  Dealing with one value is easier than
dealing with two.

You could mention that this issue is not addressed in RFC3530 and that
if it is addressed in a future NFSv4.0 specification (i.e.
RFC3530{bis,tris,...}), any greater liberality regarding other ways to
encode this for pathname4 would not apply to FedFsPathName.

-----Original Message-----
From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
Of James Lentini
Sent: Wednesday, October 13, 2010 5:10 PM
To: Noveck, David
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] [FedFS] XDR encoding of path "/"



On Wed, 13 Oct 2010, david.noveck@emc.com wrote:

> It seems like the right place is RFC3530bis.  We should of put it in
> RFC3530 and then we wouldn't have two forms to deal with.  But that's
> life.

A clarification in RFC3530bis would be great.

> I have no objection to this being mentioned in a FedFS document but
> since pathname4 is introduced by RFC3530, this piece of clarification
> belongs in RFC3530bis. 

The FedFS admin protocol defines an XDR type, FedFsPathName, with the 
same structure as a pathname4. For that reason, I could imagine a note 
about this in draft-ietf-nfsv4-federated-fs-admin. If this issue is 
discussed in RFC3530bis, then a reference in 
draft-ietf-nfsv4-federated-fs-admin to the relevant text RFC3530bis 
would make sense to me.

What would the text in RFC3530bis say about this?

> -----Original Message-----
> From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On Behalf
> Of Spencer Shepler
> Sent: Wednesday, October 13, 2010 12:15 PM
> To: 'James Lentini'; nfsv4@ietf.org
> Subject: Re: [nfsv4] [FedFS] XDR encoding of path "/"
> 
> 
> 
> > -----Original Message-----
> > From: nfsv4-bounces@ietf.org [mailto:nfsv4-bounces@ietf.org] On
Behalf
> Of
> > James Lentini
> > Sent: Wednesday, October 13, 2010 7:17 AM
> > To: nfsv4@ietf.org
> > Subject: [nfsv4] [FedFS] XDR encoding of path "/"
> > 
> > 
> > At the BAT, Chuck Lever and I discussed what the pathname4 encoding
of
> "/"
> > should be.
> > 
> > In addition to being used by the fs_locations and fs_locations_info
> > attributes, the pathname4 format is used by the fedfsNfsPath LDAP
> > attribute (see Section 4.2.1.14 of
> draft-ietf-nfsv4-federated-fs-protocol-
> > 09), and the FedFsPathName XDR type (see
> draft-ietf-nfsv4-federated-fs-
> > admin-07).
> > 
> > I'm aware of two different approaches to encoding "/".
> > 
> > One interpretation is to encode an array with zero compnent4 values.
> > This encoding is a single 32-bit field containing a 0. The Linux NFS
> > server and the SNSDB tools use this format.
> > 
> > Another interpretation is to encode an array with one zero-length
> > component4 value. The encoding of this is a 32-bit field containing
a
> > 1 followed by a 32-bit field containing a 0.
> > 
> > The Linux NFS client appears to accept both of these encodings for
> "/".
> > 
> > Are there any implementations using a different encoding than the
ones
> > above?
> > 
> > I'm thinking it would make sense to record these different formats
or
> > recommend the use of a specific format in one (or both) of the FedFS
> > specifications.
> >
> 
> Good point. FedFS specification is a good choice.  As to the
specifics,
> I would mildly prefer both be specified as acceptable encodings.
> 
> Spencer
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> 
_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4