Namespace Database (NSDB) Protocol for Federated File Systems
Note: This ballot was opened for revision 13 and is now closed.
(Martin Stiemerling) Yes
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Gonzalo Camarillo) No Objection
Benoit Claise (was Discuss) No Objection
Comment (2012-11-29 for -14)
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 22.214.171.124.4.1.31103.x. Within this range, the subrange 126.96.36.199.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 188.8.131.52.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: ( 184.108.40.206.4.1.14220.127.116.11.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."
(Wesley Eddy) No Objection
(Adrian Farrel) No Objection
Stephen Farrell No Objection
Comment (2012-11-28 for -14)
Other than the comments on 18.104.22.168 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. - 22.214.171.124: 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.) - 126.96.36.199: 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.)
(Brian Haberman) No Objection
(Russ Housley) No Objection
(Barry Leiba) (was Discuss, No Objection, Discuss) No Objection
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.
(Pete Resnick) No Objection
Comment (2012-11-28 for -14)
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. 188.8.131.52: ...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. 184.108.40.206: 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. 220.127.116.11: 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.
(Robert Sparks) No Objection
(Sean Turner) No Objection
Comment (2012-11-29 for -14)
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?