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

From: Chuck Lever <[email-masked]>
Date: Mon, 22 Oct 2012 15:37:48 -0400

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?

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

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 22 Oct 2012 15:46:14 -0400

> 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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 22 Oct 2012 15:59:18 -0400

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

> nobody steps forward to defend this, I'd be just as happy to remove

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.