IETF Logo Mail Archive

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

<david.noveck@emc.com> Wed, 13 October 2010 18:04 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 2482A3A69CD for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 11:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.681
X-Spam-Level:
X-Spam-Status: No, score=-6.681 tagged_above=-999 required=5 tests=[AWL=-0.082, 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 01vchrZTqtB6 for <nfsv4@core3.amsl.com>; Wed, 13 Oct 2010 11:04:21 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id D52193A69F5 for <nfsv4@ietf.org>; Wed, 13 Oct 2010 11:04:18 -0700 (PDT)
Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9DI5WPi007521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Oct 2010 14:05:33 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Wed, 13 Oct 2010 14:05:20 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9DI4xtL003332; Wed, 13 Oct 2010 14:05:06 -0400
Received: from CORPUSMX50A.corp.emc.com ([128.221.62.41]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Oct 2010 14:04:22 -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: Wed, 13 Oct 2010 14:04:21 -0400
Message-ID: <BF3BB6D12298F54B89C8DCC1E4073D80028514CB@CORPUSMX50A.corp.emc.com>
In-Reply-To: <026701cb6af1$c3c19f20$4b44dd60$@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] [FedFS] XDR encoding of path "/"
Thread-Index: AQHzFhZ9XQuROseVy1CgJIihDpkxKZLvtgXQgAAMcwA=
References: <alpine.LFD.2.00.1010130934190.4707@jlentini-linux.nane.netapp.com> <026701cb6af1$c3c19f20$4b44dd60$@gmail.com>
From: david.noveck@emc.com
To: spencer.shepler@gmail.com, jlentini@netapp.com, nfsv4@ietf.org
X-OriginalArrivalTime: 13 Oct 2010 18:04:22.0084 (UTC) FILETIME=[102EE840:01CB6B01]
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: Wed, 13 Oct 2010 18:04:23 -0000

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.

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. 

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

v2.23.0 | Report a Bug | By Email