Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)

"Everhart, Craig" <Craig.Everhart@netapp.com> Mon, 08 November 2010 17:19 UTC

Return-Path: <Craig.Everhart@netapp.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 4630C3A68E3 for <nfsv4@core3.amsl.com>; Mon, 8 Nov 2010 09:19:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 fYlZYsgv7AGf for <nfsv4@core3.amsl.com>; Mon, 8 Nov 2010 09:19:18 -0800 (PST)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 71D203A67F3 for <nfsv4@ietf.org>; Mon, 8 Nov 2010 09:19:18 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.58,314,1286175600"; d="scan'208";a="479227870"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 08 Nov 2010 09:19:24 -0800
Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id oA8HJO9Q028465; Mon, 8 Nov 2010 09:19:24 -0800 (PST)
Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 09:19:24 -0800
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Nov 2010 12:19:23 -0500
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: Mon, 08 Nov 2010 12:19:22 -0500
Message-ID: <E7372E66F45B51429E249BF556CEFFBC0F78E18C@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <20101108165833.GD6536@oracle.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)
Thread-Index: Act/Zm2k7gPS32OdQrWMdoc0uo1//wAALd/Q
References: <E043D9D8EE3B5743B8B174A814FD584F0A6BFD9C@TK5EX14MBXC126.redmond.corp.microsoft.com><alpine.LFD.2.00.1010221251120.4707@jlentini-linux.nane.netapp.com><4CD1DFE4.1060004@oracle.com> <20101104193632.GX6536@oracle.com><alpine.LFD.2.00.1011051500050.14303@jlentini-linux.nane.netapp.com><20101105205132.GP6536@oracle.com><AANLkTi=octHZF_Cf0kqbfoL78jOTCfmq_pYDoMW1B2Pr@mail.gmail.com> <20101108165833.GD6536@oracle.com>
From: "Everhart, Craig" <Craig.Everhart@netapp.com>
To: Nicolas Williams <Nicolas.Williams@oracle.com>, Daniel Ellard <ellard@gmail.com>
X-OriginalArrivalTime: 08 Nov 2010 17:19:23.0549 (UTC) FILETIME=[1678A4D0:01CB7F69]
Cc: nfsv4@ietf.org
Subject: Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)
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: Mon, 08 Nov 2010 17:19:19 -0000

IANA is more than capable of discerning semantic overlap between
candidates for registration and the existing registrants.  Probably
they're more than capable of discerning such overlap between multiple
candidates.

Creating yet another registry feels like a big hammer, but perhaps it's
the way to go.

I don't know why machines would have problems skipping whitespace.
Postel's Law would suggest it.

		Craig

> -----Original Message-----
> From: Nicolas Williams [mailto:Nicolas.Williams@oracle.com]
> Sent: Monday, November 08, 2010 11:59 AM
> To: Daniel Ellard
> Cc: nfsv4@ietf.org
> Subject: Re: [nfsv4] Last call for NSDB Protocol for Federated
> Filesystems (Oct 4 - Oct 22nd)
> 
> On Fri, Nov 05, 2010 at 06:36:06PM -0400, Daniel Ellard wrote:
> > I'm the person who initially proposed annotations, and their purpose
> > (as originally conceived, anyway) was to provide an ad-hoc way to
> > extend the protocol, while it was at the I-D stage, until we nailed
> > things down.  The idea was that if there was any annotation whose
> > value was widely recognized (at least to the point of
standardization
> > discussion) then that annotation should be given its own field and
> > made part of the standard, rather than left as an ad-hoc field.
That
> > was nearly three years ago, and I think things have been nailed down
> > sufficiently since then so that the requirements are fulfilled by
the
> > other fields.  If I'm wrong about that--and there are annotations
> that
> > people have determined to be valuable enough so that this field is
> > needed in order to deploy working systems--then maybe we should
begin
> > discussing folding them into the protocol.  (or maybe that
discussion
> > is already happening--I've been out of the loop for a while)
> 
> Rob has a need for an informative[*], optional attribute pointing to
> junctions that refer to an FSN.
> 
> [*] Informative in that it's value(s) is(are) allowed to be incorrect/
>     stale.
> 
> > On the other hand, if the main reason to have this field is as a
> > loophole for adding new features in the future, without making those
> > features part of the standard, then I think it should be removed.
If
> > we have to make a version 2 of the protocol because we later realize
> > that we forgot something essential, I'd rather start with a new I-D
> > than have to deal with ad-hoc, incompatible extensions to version 1.
> 
> LDAP itself is ad-hoc-ish -- there's a schema element registry, but
its
> registration rules for it do not do what you seem to wish for.  By
> choosing LDAP as the NSDB protocol, the WG has implicitly decided that
> vendor-specific extensions are allowed.
> 
> Nico
> --
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4