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

[Daniel Ellard <[e-mail]>]

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)

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.

-Dan