IESG review: Define "FSL subtype" on first use in NSDB doc

Stephen Farrell say:
> - 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.
IESG review: Cite when using NFSv4-related items in NSDB doc

Stephen Farrell says:
> - 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.)
IESG review: Specify non-negative TTL in NSDB doc

Stephen Farrell says:
> - 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].
IESG review: Require implementation of TLS in NSDB doc

Stephen Farrell says:
> - 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.)
IESG review: Clarify meaning of zero port value in ADMIN doc

Ralph Droms says:
> s/should/MUST/ ?
>
>   FedFsNsdbName:  A (hostname, port) pair.
>      [...]
>      A value of 0 indicates that the standard LDAP port number, 389,
>      SHOULD be assumed.
>
> s/SHOULD/MUST/, or explain when 389 is not assumed and what is used
> instead of 389.  Why would one set the port to 0 instead of just using
> the more direct 389, anyway?  The answer to this question should be
> applied in section 4.1.
IESG review: Clarify use of IP addresses in FedFsNsdbNames

Ralph Droms says:
>      [...]Therefore, a FedFsNsdbName SHOULD NOT contain a network address,
>      such as an IPv4 or IPv6 address, as this would indefinitely assign
>      the network address.
>
> s/SHOULD NOT/MUST NOT/, or explain the syntax for encoding a network
> address in a FedFsNsdbName.
IESG review: Clarify i18n rules for FedFsPathComponent in ADMIN doc

Ralph Droms says:
>   FedFsPathComponent:  A case sensitive UTF-8 string containing a
>      filesystem path component.  It SHOULD be prepared using the
>      component4 rules defined in Chapter 12 "Internationalization" of
>      [3530bis].
>
> When would it not "be prepared using the component4 rules[...]" and
> how would that case be identified?

These component4 arrays are now specified as "utf8val_REQUIRED4" in
the XDR for the ADMIN protocol.

RFC 3530bis, section 12.2.2 says:

"utf8val_REQUIRED4/UVMUST:  indicating that strings of this type MUST
be in the form of the UTF-8 encoding of Unicode.  Strings will be
checked by the server for valid UTF-8 and the server SHOULD ensure
that when sent to the client, they are valid UTF-8."

Thus I'm changing the string preparation requirements for pathname
components in both the ADMIN and NSDB documents from "SHOULD be
prepared" to "MUST be prepared."
IESG review: Clarify 2119 qualifiers in ADMIN doc

Ralph Droms says:
> In section 5, some error conditions are specified as "MUST be
> returned", some as "SHOULD be returned", some as "MUST fail with
> status [...]" and some are not specified with any RFC 2119 language.
> At the risk of suggesting foolish consistency, I suggest a editing
> pass for consistency, with explanations of what to do if a SHOULD is
> not followed, would likely ease the mind of an implementor.  (OK, I
> admit this comment is mostly stylistic, except for the clarification
> of SHOULDs.)