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

[Chuck Lever <[e-mail]>]

On Oct 22, 2012, at 3:46 PM, Daniel Ellard <[e-mail]> wrote:

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

There are at least two ways implementations can extend these object classes without changing them:

1.  Define and use a fedfsAnnotation, as specified in this draft (this typically also requires interaction with IANA), or

2.  Define an additional object class, then have entries inherit from both the standard class and the vendor specific one

I can add words to this effect in section 4.2 (or elsewhere) if we think it's valuable to point this out.

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

In any event, I'm not sure we can prevent an implementor from altering the object class definitions.  In fact some LDAP server implementations require schema changes.

If no-one barks, I'll remove that paragraph.

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com