IANA review: fedfsFsnUuid is no longer "historic"

Table 1 in Section 7.2  Registry for FedFS Object Identifiers:

| 1.3.6.1.4.1.31103.1.4    | fedfsFsnUuid            | RFC-TBD1 |

The Object Identifier descriptor is however listed as 'historic' in
the list under Section 7.3.  LDAP Descriptor Registration:

  Object Identifier:  1.3.6.1.4.1.31103.1.4
  Descriptor (short name):  fedfsFsnUuid
  Usage:  attribute type (historic)

Please resolve the discrepancy in the next version.
Gen-ART review: Add braces for readability in NSDB doc

Peter Yee says:
> Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket "Section 2.8.1"  in
> "(see" and ")" for readability.
Use "NFSv4.0" to mean RFC 3530

Commit 1b7fe350 'Use "NFSv4.0" to mean RFC 3530', Sep 11 10:08:02
2012, updated the NSDB protocol document to use the term NFSv4 to
mean any minor version of NFSv4, and NFSv4.0 to mean specifically
minor version 0.

The same change is needed in the ADMIN protocol document.
IESG review: Update glossary definitions of "client" and "fileserver"

Pete Resnick says:
> 1.1
>
>   Client:  Any client that accesses fileserver data using a supported
>      file-access protocol.
>
> I love circular definitions as much as the next guy, but how about at
> least indicating whether the client is the software, the machine, the
> user, or some other theoretical entity? The above is not useful.
>
>   Fileserver:  A server exporting one or more filesystems via a file-
>      access protocol.
>
> Hmmmm....That's not a terribly helpful definition.

The "glossary.xml" file is included in both the ADMIN and the NSDB
protocol documents, so the definitions are updated in both places.

Commit 8cd92fc1 'Use the term "file-access client" consistently',
Tue Sep 11 10:07:51 2012, changed the term "client" to "file-access
client" in the NSDB protocol document.  The same distinction should
be made when discussing ADMIN protocol operation status codes.
IESG review: Clarify first sentence of ADMIN document section 4

Pete Resnick says:
> 4.  Data Types
>
>   The basic data types defined above MUST be formatted as follows:
>
> The MUST is strange. I always say that you should use MUST if an
> implementation might accidentally choose to do otherwise and cause an
> interoperability problem. In this case, choosing to do otherwise is not
> an accident; it's just insanity. It's probably just as good to say "The
> basic data types defined above are formatted as follows:".
IESG review: Clarify ADMIN document's definition of FedFsUuid

Pete Resnick says:
>   FedFsUuid:  A universally unique identifier (UUID) as described in
>      [RFC4122] as a version 4 UUID.  The UUID should be formatted in
>      network byte order.
>
> There's something weird about the first sentence. The contradiction of
> the "MUST" above

 [ in the first sentence of section 4 ]

> and the "should" here is glaring. Don't you want to say
> here that the UUID MUST be in network byte order? *That* would cause an
> interoperability issue, wouldn't it?
IESG review: Clarify DNS resolution recommendation

Pete Resnick says:
>      A system (i.e.,
>      fileserver or administrative host) SHOULD resolve the fully
>      qualified domain name to a network address using the system's
>      standard resolution mechanisms.
>
> SHOULD do something that is implementation dependent? That doesn't look
> right.
IESG review: Clarify ADMIN protocol's use of secType field

Pete Resnick says:
>      The secType field indicates the security mechanism that MUST be
>      used to protect all connections to the NSDB with the connection
>      parameters.
>
>      A value of FEDFS_SEC_NONE indicates that no security mechanism is
>      necessary.  In this case, the secData array will have 0 length.
>
> There appears to be a conflict in the above. I read the first sentence as
> saying that whatever is in secType MUST be used; you can not use an
> alternative. However, the second sentence indicates that no security
> mechanism is "necessary", implying that you *could* use a security
> mechanism if you wanted to. Which is it? Do I have to respect what's in
> secType, or are there instances where I can choose what I like?