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

[Nicolas Williams <[e-mail]>]

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