Re: [nfsv4] Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13

[Daniel Ellard <[e-mail]>]

On Mon, Oct 22, 2012 at 3:37 PM, Chuck Lever <[e-mail]> wrote:
> Hi-
>
> Gen-ART review comment:
>
>> Section 4.2.2.2, 5th paragraph: how is the prohibition on referencing
>> other attributes in the fedfsFsn object class supposed to work if this
>> document is the defining document for that object class?
>
>
> The referenced paragraph, in it's entirety:
>
>> A fedfsFsn MAY also have additional attributes, but these attributes
>> MUST NOT be referenced by any part of this document.
>
> Does anyone recall why this language is here?

Reconstructing part of a discussion from several years ago...

Someone wanted to add some additional fields to a fedfsFsn that
mattered for some capability that only made sense in the context of
their file system (automatic replication?  I don't remember).

I said that I couldn't prevent them from adding fields to the LDAP
attributes, but they would only work on their implementation and must
not be required for correct implementations, and they were OK with
that.  Vendors can extend, but none of the extensions are required.

I wouldn't mind if this was removed.  I haven't heard anyone talking
about vendor-specific extensions (but then again, I no longer work
with any of the vendors, so I'm in no position to hear much).  If
nobody steps forward to defend this, I'd be just as happy to remove
it.

-Dan