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

From: Robert Thurlow <[email-masked]>
Date: Wed, 03 Nov 2010 16:19:16 -0600

James Lentini wrote:

> There has been some discussion regarding the fedfsAnnotation LDAP 
> attribute defined in Section 4.2.1.12 that I wanted to record as part 
> of this thread.
> 
> Chuck Lever discovered some ambiguities in the description of this 
> attribute's format. We discussed those issues during the FedFS concall 
> on 10/14. A revised description that attempts to eliminate those 
> ambiguities is included below.

I like the revised text without reservation.

> In the process of reviewing the revised text, Chuck, my co-authors, 
> and I have have been considering the utility of including this 
> annotation mechanism. Before LDAP was chosen for the NSDB protocol, 
> this attribute was created to allow private schema extensions. Given 
> our use of LDAP, this attribute may be obsolete.
> 
> Using LDAP there are other, arguably more natural, ways to allow for 
> schema extensions. For example, LDAP allows an entry's schema 
> definition to be extended by adding additional object types to the 
> entry. In this approach, the KEYs and VALUEs defined in Section 
> 4.2.1.12 map to LDAP attribute types and values respectively. This 
> approach would allow implementers to define their own annotation 
> attributes, and would allow for standardizing such attributes if there 
> was interest.
> 
> Are there objections to removing the fedfsAnnotation attribute from 
> the schema and recommending that schema extensions be handled as 
> described above?

I wish to create a management application which uses the
annotations fields as described in the current NSDB schema,
and I think the use case really requires the current form
of the specification, and not schema extensions.

The interesting-to-me use case is a kind of a back pointer -
a way to track back from an FSL and/or FSN to the place in
the namespace where this item is referenced.  I don't think
this can every be truly reliable, but if you're taking a
disk array down for planned maintenance and can send an
outage warning saying that "the following filesystem paths
are known to be affected", that could be useful at times.
The unreliability is why this is not something I have tried
to make a core part of the NSDB protocol.

So the goal is something like a "mountpath=/nfs4/my/path"
piece of data.  The NSDB protocol as currently specified
will let me just write this attribute whenever I manage a
junction.

If I need to do this with LDAP schema extensions, someone
must go through the non-standard LDAP management interface
to get these bits added to the schema before I do my first
bit of work in my management application.  That might be me,
the vendor, trying to script something for all known LDAP
implementations, or it might be my customer trying to read
the fine manuals and do what I conceptually guide him to do.
How many of us would ever do that as a vendor or a customer?
Even if my environment is homogeneous, I may have to touch
every LDAP server I use for FedFS, depending on what any
replication solution supports.

In summary, I think I have something I would really like to
implement which cannot be done properly without annotations
as currently specified, so I would like them kept.

Rob T

---

From: Chuck Lever <[email-masked]>
Date: Thu, 4 Nov 2010 09:57:48 -0400

On Oct 22, 2010, at 1:31 PM, James Lentini wrote:

> 
> 
> On Mon, 4 Oct 2010, Spencer Shepler wrote:
> 
>> 
>> Last call for the following document starts today and ends on October 22nd
>> 
>> NSDB Protocol for Federated Filesystems
>> draft-ietf-nfsv4-federated-fs-protocol-09
>> 
>> Comments on the document, other than the editorial, should be
>> directed to the NFSv4 WG alias.   Document links are as follows:
>> 
>> html: http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-09
>> txt: http://tools.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-09.txt
> 
> -james
> Revised text for Section 4.2.1.12 
> (if fedfsAnnotation is retained):
> ------------------------------------------
> 
> 4.2.1.12. fedfsAnnotation
> 
> 
>   A fedfsAnnotation contains an object annotation formatted as a 
>   key/value pair.
> 
>   This attribute is multi-valued; an object type that permits
>   annotations may have any number of annotations per instance.
> 
>   A fedfsAnnotation attribute is a human-readable UTF-8 string.
>   The value MUST NOT contain a non-terminal NUL character and

Rob pointed out to me that UTF-8 strings by definition may not have a non-terminal NUL character, so the above MUST NOT text is not necessary.

>   MUST be formatted according to the following ABNF [RFC 5234] rules:
> 
>   ANNOTATION = KEY EQUALS VALUE
>   KEY        = ITEM
>   VALUE      = ITEM
>   ITEM       = BLANK DQUOTE STR DQUOTE BLANK
>   BLANK      = 0*EMPTY
>   EMPTY      = SPACE / HTAB
>   HTAB       = %x09 ; horizontal tab
>   STR        = 0*UTF8
> 
>   The DQUOTE, EQUALS, UTF8, and SPACE rules are defined in [RFC4512].
> 
>   The following escape sequences are allowed:
> 
>                     +-----------------+-------------+
>                     | escape sequence | replacement |
>                     +-----------------+-------------+
>                     |        \\       |      \      |
>                     |        \"       |      "      |
>                     +-----------------+-------------+
> 
>   A fedfsAnnotation value SHOULD be processed as follows:
> 
>   1. Scan through the attribute value and replace the above escape 
>      sequences.
>   2. Parse the results of the previous step according to the 
>      ANNOTATION rule.
> 
>   A fedfsAnnotation attribute that does not adhere to this format
>   SHOULD be ignored.
> 
>   The following are examples of valid fedfsAnnotation attributes:
> 
>            "key1" = "foo"
>            "another key"=    "x=3"
>            "key-2" = "A string with \" and \\ characters."
>            "key_3" = "Backslash before final quote: \\" 
> 
>   which correspond to the following key/value pairs:
> 
>            +-------------+-----------------------------------+
>            |     key     |               value               |
>            +-------------+-----------------------------------+
>            |     key1    |                foo                |
>            | another key |                x=3                |
>            |    key-2    | A string with " and \ characters. |
>            |    key_3    | Backslash before final quote: \   |
>            +-------------+-----------------------------------+
> 
>   <CODE BEGINS>
> 
>           ///
>           /// attributetype (
>           ///     1.3.6.1.4.1.31103.1.12 NAME 'fedfsAnnotation'
>           ///     DESC 'Annotation of an object'
>           ///     SUP name
>           ///     )
>           ///
> 
>   <CODE ENDS>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

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

---

From: James Lentini <[email-masked]>
Date: Thu, 4 Nov 2010 14:25:57 -0400 (EDT)

On Wed, 3 Nov 2010, Robert Thurlow wrote:

> James Lentini wrote:
> 
> > There has been some discussion regarding the fedfsAnnotation LDAP attribute
> > defined in Section 4.2.1.12 that I wanted to record as part of this thread.
> > 
> > attribute's format. We discussed those issues during the FedFS concall on
> > 10/14. A revised description that attempts to eliminate those ambiguities is
> > included below.
> 
> > In the process of reviewing the revised text, Chuck, my co-authors, and I
> > have have been considering the utility of including this annotation
> > mechanism. Before LDAP was chosen for the NSDB protocol, this attribute was
> > created to allow private schema extensions. Given our use of LDAP, this
> > attribute may be obsolete.
> > 
> > Using LDAP there are other, arguably more natural, ways to allow for schema
> > extensions. For example, LDAP allows an entry's schema definition to be
> > extended by adding additional object types to the entry. In this approach,
> > the KEYs and VALUEs defined in Section 4.2.1.12 map to LDAP attribute types
> > and values respectively. This approach would allow implementers to define
> > their own annotation attributes, and would allow for standardizing such
> > attributes if there was interest.
> > 
> > Are there objections to removing the fedfsAnnotation attribute from the
> > schema and recommending that schema extensions be handled as described
> > above?
> 

Clearly there is a use for this attribute. The next revision of 
draft-ietf-nfsv4-federated-fs-protocol will include this attribute 
with the revised definition of its format.

-james

---

From: James Lentini <[email-masked]>
Date: Thu, 4 Nov 2010 14:49:50 -0400 (EDT)

> On Oct 22, 2010, at 1:31 PM, James Lentini wrote:
<snip>
> Rob pointed out to me that UTF-8 strings by definition may not have 
> a non-terminal NUL character, so the above MUST NOT text is not 
> necessary.

Since arriving at this conclusion required some discussion, I think 
noting this point would be benefit future readers. The "MUST NOT" 
could be removed like this:

   A fedfsAnnotation attribute is a human-readable UTF-8 string.
   By definition, the value will not contain a non-terminal NUL character.
   The value MUST be formatted according to the following ABNF [RFC 5234]
   rules:

Is that better?

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Nov 2010 14:36:32 -0500

On Wed, Nov 03, 2010 at 04:19:16PM -0600, Robert Thurlow wrote:
> James Lentini wrote:
> >In the process of reviewing the revised text, Chuck, my
> >co-authors, and I have have been considering the utility of
> >including this annotation mechanism. Before LDAP was chosen for
> >the NSDB protocol, this attribute was created to allow private
> >schema extensions. Given our use of LDAP, this attribute may be
> >obsolete.
> >[...]
> >Are there objections to removing the fedfsAnnotation attribute
> >from the schema and recommending that schema extensions be handled
> >as described above?
> 

I think we should pre-define an attribute for back pointers, as that
seems valuable even though it's unreliable.

I think a free-form text annotation for sysadmins to make notes is also
a good idea.

I don't think a free-for-all attribute/value namespace is a good idea,
as then each vendor will add random things that will then create interop
problems (because of collisions, because others will feel pressured to
implement the same attributes with undocumented/obscure/unstable
semantics, ...).  OTOH, a FedFS-specific attribute/value namespace
subject to IANA registration would be fine, and even desirable for the
reasons that you state.

> [...]

Just because it's unreliable doesn't mean it's a bad idea to have it in
the core spec.  Hints can be useful even if they're wrong some of the
time.

> bit of work in my management application.  [...]

Right, so let's get this attribute in _now_, while it's still early
enough :)

Nico
--

---

From: James Lentini <[email-masked]>
Date: Fri, 5 Nov 2010 15:15:16 -0400 (EDT)

> seems valuable even though it's unreliable.

There isn't interest in this across vendors.
 
> I think a free-form text annotation for sysadmins to make notes is 
> also a good idea.

This is part of the specification. See the fedfsDescr.
 
> I don't think a free-for-all attribute/value namespace is a good 
> idea, as then each vendor will add random things that will then 
> create interop problems (because of collisions, because others will 
> feel pressured to implement the same attributes with 
> undocumented/obscure/unstable semantics, ...).  OTOH, a 
> FedFS-specific attribute/value namespace subject to IANA 
> registration would be fine, and even desirable for the reasons that 
> you state.

Would the registration of vendor-specific attributes be allowed?

-james

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 5 Nov 2010 15:51:32 -0500

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

> This is part of the specification. See the fedfsDescr.

But we've heard one implementor (us) talk about using it in an ad-hoc
way, rather than as free-form text.  Is that really what's desired?

> Would the registration of vendor-specific attributes be allowed?

That would be the point of a hole subject to registration...  If that's
not desired then surely neither is ad-hoc usage of existing free-form
fields.

Nico
--

---

From: Daniel Ellard <[email-masked]>
Date: Fri, 5 Nov 2010 18:36:06 -0400

> 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

---

From: James Lentini <[email-masked]>
Date: Mon, 8 Nov 2010 11:06:35 -0500 (EST)

<snip>
> way, rather than as free-form text.  Is that really what's desired?

The fedfsDescr attribute is a free-form text field.

Are you confusing the subject of this thread, the fedfsAnnotation 
attribute, with the fedfsDescr attribute? I don't remember any posts 
from you or Rob on using the fedfsDescr attribute for a purpose 
incompatible with free-form text.

---

From: James Lentini <[email-masked]>
Date: Mon, 8 Nov 2010 11:06:51 -0500 (EST)

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

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

---

From: Chuck Lever <[email-masked]>
Date: Mon, 8 Nov 2010 11:32:01 -0500

>   The value MUST be formatted according to the following ABNF [RFC 5234]

"As a UTF-8 string by definition does not contain a non-terminal NUL character, the annotation value (VAL) can never contain a non-terminal NUL character." might be a little more clear for the second sentence.  I do realize this restriction applies for the entire fedfsAnnotation value, but my issue was specifically around what the intended payload of VAL might contain.

I still might wish for a fedfsAnnotation format that was less sloppy (ie, easier to parse without worrying about white space variations).  Is there any reason to allow such flexibility?

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 10:42:06 -0600

> incompatible with free-form text.

fedfsAnnotation is a free-form key/value space.  I think that's a bit
silly, this being LDAP and all...  But also, without a registry, what's
to prevent collisions?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 10:44:34 -0600

> implemented overlapping ideas?

The registration rules could be such that a description of the value
contents (semantic and syntactic) would be required, thus achieving more
than collision prevention: the registry would also enable
interoperability.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 10:58:34 -0600

> is already happening--I've been out of the loop for a while)

Rob has a need for an informative[*], optional attribute pointing to
junctions that refer to an FSN.

[*] Informative in that it's value(s) is(are) allowed to be incorrect/
    stale.

> than have to deal with ad-hoc, incompatible extensions to version 1.

LDAP itself is ad-hoc-ish -- there's a schema element registry, but its
registration rules for it do not do what you seem to wish for.  By
choosing LDAP as the NSDB protocol, the WG has implicitly decided that
vendor-specific extensions are allowed.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 8 Nov 2010 12:19:22 -0500

IANA is more than capable of discerning semantic overlap between
candidates for registration and the existing registrants.  Probably
they're more than capable of discerning such overlap between multiple
candidates.

Creating yet another registry feels like a big hammer, but perhaps it's
the way to go.

I don't know why machines would have problems skipping whitespace.
Postel's Law would suggest it.

		Craig

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, November 08, 2010 11:59 AM
> To: Daniel Ellard
> Cc: [email-masked]
> Subject: Re: [nfsv4] Last call for NSDB Protocol for Federated
> Filesystems (Oct 4 - Oct 22nd)
>

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 8 Nov 2010 12:35:09 -0500

> incompatible with free-form text.

I don't think I'm confusing it, although that possibility is always on
the table.

The purpose of my post was to provide context for my opinion that
fedfsAnnotation can be eliminated from the protocol, which is what I
thought this thread was about.  Apologies if otherwise.

(and as far as fedfsDescr being a free-form text field, I do have an
opinion about that as well.   The problem with free-form text fields
is that eventually someone will put something in there at that you
never expected.  I would at least advocate some structural framework
so that a user can at least know how to skip over parts of the Descr
that they don't grok...)

-Dan

---

From: Daniel Ellard <[email-masked]>
Date: Mon, 8 Nov 2010 12:42:14 -0500

> to me, provided we've identified all the uses for the fedfsAnnotation

I like the idea of giving it a name that relates to its purpose, and a
well-specified semantic, and then making it optional.

> implemented overlapping ideas?

The registry would have to go through the same sort of review as other
WG items (because, in effect, the registry would have the same weight
as an RFC).  To make things easier to play with, experimental keys
could be drawn from a lightweight, semi-administered namespace (i.e.,
all keys starting with 'X-' would be experimental, non-standard keys,
administered only to prevent collisions) but "real" names should go
through the WG process, in my opinion.

-Dan

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 11:41:58 -0600

> they're more than capable of discerning such overlap between multiple

I don't agree.  IANA is good at following simple, clear rules.  For
anything more elaborate you need to require Expert Review or stronger
review.

> Creating yet another registry feels like a big hammer, but perhaps it's

IANA registries are cheap (to us, WG participants anyways).

I'd rather use LDAP schema for this than an LDAP attribute with
key/value pairs as values.  We might be able to get a sub-namespace of
LDAP attribute/class names (all those starting with "fedFs", say) to
have different rules than LDAP as a whole, if the WG feels that strongly
about preventing semantic overlap.

> Postel's Law would suggest it.

What's that got to do with anything?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 11:46:19 -0600

> through the WG process, in my opinion.

See also draft-saintandre-xdash-considered-harmful-01.  (And the lengthy
debate that resulted in the Apps Area.)

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 12:09:59 -0600

> about preventing semantic overlap.

RFC4520 sets up the IANA LDAP parameters registry.  Among other things:

 - RFC4520 allows registration of attribute and class name prefixes
   (prefixes must end in '-').

 - RFC4520 requires Expert Review for attribute/class names.  (Note
   though that one can identify attributes and classes by OID instead of
   name, and no registration of private OIDs is required in the LDAP
   registry.)

 - RFC4520 allows for private use (unregistered) and experimental use
   (first come first served) sub-namespaces for attribute and class
   names (x- and e-, respectively).

I believe we can register the 'fedfs-' prefix and create a registry with
whatever rules the NFSv4 WG prefers for attribute/class names starting
with that prefix.

My personal preference is for Expert Review and/or Specification
Required.  If the WG preferred something stronger than I would suggest
Standards Action.

Nico
--

---

From: "Everhart, Craig" <[email-masked]>
Date: Mon, 8 Nov 2010 13:20:52 -0500

That feels about right to me.  Perhaps the fedfsAnnotation and
fedfsDescr fields would simply be removed in favor of such a schema use.

Rob, would you be interested in proposing some text defining your
proposed hint of a mount path?  That attribute could be the first entity
in such a set of schema uses?  Something like a "fedfsMountHint" name
and OID?

		Craig

> Sent: Monday, November 08, 2010 1:10 PM
> To: Everhart, Craig
> Cc: [email-masked]
> Subject: LDAP Registry rules and sub-namespaces (Re: [nfsv4] Last call
> for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd))
>

---

From: James Lentini <[email-masked]>
Date: Mon, 8 Nov 2010 14:07:13 -0500 (EST)

On Mon, 8 Nov 2010, Chuck Lever wrote:

> I still might wish for a fedfsAnnotation format that was less sloppy 
> (ie, easier to parse without worrying about white space variations).  
> Is there any reason to allow such flexibility?

The flexibility allows a person to type a fedfsAnnotation value 
without having to worry about whitespace.

-james

---

From: James Lentini <[email-masked]>
Date: Mon, 8 Nov 2010 14:12:28 -0500 (EST)

> silly, this being LDAP and all...  But also, without a registry, what's

Our signals are getting crossed.

I'm pointing out that the "free-form text annotation for sysadmins to 
make notes" that you suggested is already part of the specification. 
It is called a fedfsDesc, not to be confused with a fedfsAnnotation.

-james

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 8 Nov 2010 13:47:32 -0600

> It is called a fedfsDesc, not to be confused with a fedfsAnnotation.

I understood what you said.  I may have been a bit sloppy in referring
to fedfsAnnotation as free-form, but, then again, it practically is that
-- fedfsAnnotation is only slightly less free-form than fedfsDesc.