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

[James Lentini <[e-mail]>]

On Fri, 5 Nov 2010, Daniel Ellard wrote:

> On Fri, Nov 5, 2010 at 4:51 PM, Nicolas Williams
> <[e-mail]> wrote:
> > On Fri, Nov 05, 2010 at 03:15:16PM -0400, James Lentini wrote:
> >> On Thu, 4 Nov 2010, Nicolas Williams wrote:
> >> > I think we should pre-define an attribute for back pointers, as that
> >> > seems valuable even though it's unreliable.
> >>
> >> There isn't interest in this across vendors.
> >
> > But is that the test of whether a feature should in a Proposed Standard?
> >
> > The test for a Standard is that any given feature must have two or more
> > interoperable implementations, but this being a Proposed Standard the
> > actual rule is more relaxed.
> >
> > I think a free-for-all annotation is much too likely to result in
> > interoperability problems.  A rule that "there must be enough interest
> > across implementors" is not at all helpful if it leads to ad-hoc
> > solutions.  The WG needs a happy middle.
> 
> 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)

Thank you for the background Dan. It helps frame the discussion.

Rob has a specific use for the fedfsAnnotation attribute (mountpoint 
backpointers), so the fedfsAnnotation attribute can't be eliminated 
without adding an attribute for mountpoint backpointers to the 
specification. If a "fedfsMountpoint" attribute was included in the 
MAY list for the FSN and FSL object, it would have the same semantics 
as the fedfsAnnotation attribute does now: it would be part of the 
base schema and available to implementations that wanted to use it, 
but not required to create an FSN or FSL entry. That seems reasonable 
to me, provided we've identified all the uses for the fedfsAnnotation 
attribute.

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

As Nico suggested, one approach to preventing incompatible extensions 
would be an IANA-maintained registry of annotation keys. I'm not 
certain of how such a registry would function, but I suspect it would 
only prevent namespace collisions. In other words, the registry should 
prevent two different definitions of the annotation key "foo", but 
would it detect that annotation key "foo" and annotation key "bar" 
implemented overlapping ideas?