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

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