Namespace Database (NSDB) Protocol for Federated File Systems
draft-ietf-nfsv4-federated-fs-protocol-15

The -14 version resolves all my earlier comments, and clears my earlier DISCUSS.  Thanks for addressing all this.

The -15 version resolves the late issue that came up with the registry in Section 7.2.  Thanks for that, and, again, my apology that that came up so late.

My DISCUSS-DISCUSS is now cleared: "While it's not ideal, since you have the LDAP OID experts green light and also running code, I'll clear my DISCUSS."

For the record, here was my DISCUSS-DISCUSS
This is a DISCUSS-DISCUSS.

Hopefully a little bit of LDAP education will quickly resolve this one.
I'm looking at section 7.2 http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-14#section-7.2, which speaks about OID. 
So my OPS AD level of attention suddenly increased. 

   ... one of the authors was
   assigned the Internet Private Enterprise Numbers range
   1.3.6.1.4.1.31103.x.  Within this range, the subrange
   1.3.6.1.4.1.31103.1.x is permanently dedicated for use by the
   federated file system protocols.

From http://www.iana.org/assignments/enterprise-numbers, I see
31103
  Daniel Ellard
    Daniel Ellard
      ellard&gmail.com

Then I thought: Ok, maybe, even if I read "permanently", this enterprise specific number requested by a specific person was a temporary solution.
However, reading further, yes, there is a new "FedFS Object Identifiers" registry, but it will still use the 1.3.6.1.4.1.31103.1.x range.
 
Then I looked at existing practice: http://tools.ietf.org/html/rfc4517
And I see, for example:
   The LDAP definition for the Other Mailbox syntax is:
      ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )

From http://www.iana.org/assignments/enterprise-numbers:
1466
  Mark Wahl
    Mark Wahl
      M.Wahl&isode.com


Is it normal that Standards Track documents register OIDs under enterprise specific numbers (on top of that, representing individuals)?
Is it normal that OIDs are registered this way in LDAP?

Note: I know of one PEN used within a standards track document, but this one was distinctly labeled.
29305
  IPFIX Reverse Information Element Private Enterprise
    RFC5103 Authors
      ipfix-biflow&cert.org


Disclaimer 1: My lack of LDAP is probably the cause of this DISCUSS-DISCUSS. So please shed some light. 
Disclaimer 2: I spoke with Martin Stiemerling before posting this.
So I'm really after a reply (from the APPS ADs, I guess) such as: "don't worry, there are no problems with this."

2.8:

   A fileset MAY be accessible by protocols other than NFS.  For each
   such protocol, a corresponding FSL subtype SHOULD be defined.  The
   contents and format of such FSL subtypes are not defined in this
   document.

That doesn't look like protocol to me. I think you can strike the whole paragraph, but at least get rid of the 2119 terms.

2.8.1.2:

   ...any non-ASCII UTF-8 code points and any URI-
   reserved characters, such as the slash ("/") character, contained in
   a component4 element MUST be represented by URI percent encoding.

The phrase "non-ASCII UTF-8 code points" isn't correct. Change it to "non-ASCII characters". It's closer to right.

2.8.1.3:

   In its "server" field, the NFSv4 fs_location4 data type contains a
   list of universal addresses or UTF-8 hostnames.

This is in all likelihood a problem with 5661 as well. What exactly do you mean by "UTF-8 hostname"? Do you mean a U-Label as described in IDNA (RFC 5890, et. al.), or do you simply mean a US-ASCII hostname in a UTF-8 string data type? If the former, you're going to have to say more. If the later, you should say "US-ASCII hostnames" instead.

4.2.1.6:

I've never been clear on why 4512 did as much in the way of customized ABNF as it did. You could replace all of the ABNF you have in this section with:

      ANNOTATION = KEY "=" VALUE
      KEY = ITEM
      VALUE = ITEM
      ITEM = *WSP DQUOTE UTF8-octets DQUOTE *WSP

DQUOTE and WSP are defined in 5234, and UTF8-octets is defined in 3629. But it's up to you.


8:

   Client:  Any client that accesses fileserver data using a supported
      file-access protocol.

   Fileserver:  A server exporting one or more filesystems via a file-
      access protocol.

See the admin document. Not very good definitions.

1) Had a bunch of questions about the 2119-language, but I see that you got some other comments along the same lines and caught some others on your own.  Here are the ones I noted, if you already got them great:

s2.7: The FsnUuid is a required attribute - REQUIRED?

s2.7/s2.8 Annotations/Descriptions: r/optional/OPTIONAL? X2

s2.12: r/an FSN UUID must be/an FSN UUID MUST be ?

s2.12: r/FSL UUIDs must be unique/ FSL UUIDs MUST be unique ?

s4.2: r/Code components extracted from this document must include the following license:/Code components extracted from this document MUST include the following license: ?

s4.2.1: r/describes the required/describes the REQUIRED ?

s5.1.5: r/must not/MUST NOT

2) s2.7: Is an NSDB client the same as a file-access client?  Ah now I see NSDB client is defined later in s5 - shouldn't it be listed in s2?  Is an NSDB client just an administrator or a fileserver based on the users of the two sub-protocols in s5 t seems like it is?

3) s4.1: r/NSBD/NSDB

4) s5: There's three sub-sections in s5.  Is the following just a typo?

  The NSDB sub-protocols are defined in the next two sub-sections.

5) s5.1.1: When you say validity and consistency are talking about validating the schema?:

 The NSDB node that receives the request SHOULD check all of the
 attributes for validity and consistency

6) s5.1.*.1: Nice examples!

7) So do I have it right that the protocols described in this document are only used by fileservers and admins and that a file-access client never needs to implement LDAP?

Other than the comments on 4.2.1.3 and section 6, these
are pretty much nits.  

- 2.8: I'm not quite clear on the term "subtype" - does that
mean that the NFS-specific information is contained in an FSL
"annotation"? I guess it does, but this is the first time the
term "subtype" is used.

- 2.8.1.2: what is "component4" ? I guess its an NFSv4 thing
but maybe good to say. (Same for other foo4 things, but just
saying once would be fine.)

- 2.12: Do you mean that FSN UUIDs only need to be unique per
NSDB node. (You might also want to use upper case MUST/SHOULD
for some of the uniqueness statements.)

- 4.2.1.3: LDAP integers can be of unlimited size.  Do you
need some kind of max for the fedfsFsnTTL to avoid any
potential DoS? What about negative integers? I assume you do
not want those? You could say that LDAP clients here 
MUST implement some kind of max and MUST NOT accept negative
integer values. Or, as with other integers you could just
say it MUST be between [0,MAX].

- 5.3: I wondered if it would make sense to say that LDAP
referrals MUST have the same or better security properties
than the original LDAP request that caused the referral?  That
is, if I start with LDAP/TLS, then I'd barf on a cleartext
LDAP referral.

- section 6: *use* of TLS is RECOMMENDED which is fine, but
you don't say that implementation of TLS is a MUST.  I think
it'd be good to be explicit about that. (LDAP is a bit oddly
structured, maybe in a way to leave wiggle room to say you
conform here even though you don't support LDAP/TLS.)