Resolve Barry Leiba's IESG DISCUSS item (NSDB section 2.7 and 4.2.1.3)

-- Sections 2.7 and 2.8.3 --

 ...

 First, is the text in 2.7 meant to refer to the "FsnTTL" item that was
 just defined?  Why aren't the normative requirements for its use defined
 there?

 In Section 2.8.3, the MAY in the first paragraph looked inappropriate,
 but I wasn't positive until I read the MUST NOT in the second.  There's
 also a SHOULD NOT in the second paragraph of the section that conflicts
 with that MUST NOT.  You're saying the same stuff too often, in too many
 places, inconsistently.  This information needs to be clearly specified
 normatively in one place, and cited from elsewhere without extra 2119
 language that will confuse things.

 -- Section 2.8.3 --

 There are two places where you use "FSN TTL", which was defined in
 Section 2.7 as "FsnTTL".  It's probably better to use "FsnTTL"
 consistently.

 -- Section 4.2.1.3 --

 This is related to the stuff above: You've previously said that caching
 MAY be done, and now you're saying SHOULD.  You've previously specified
 FsnTTL as the *maximum* cache time, and now you're describing it as the
 *only* cache time.  I suggest that you take the 2119 language out of this
 and use a citation to Section 2.7 here, making sure that 2.7 says what
 you want.
Resolve Barry Leiba's IESG DISCUSS item (NSDB section 4.2.1.24)

-- Section 4.2.1.24 --

   A fedfsNfsVarSub stores the value of an FSL's NFSv4.1 FSLI4F_VAR_SUB
   bit [RFC5661].

 This should be "FSLI4IF_VAR_SUB" (it's missing an "I").
Resolve Barry Leiba's IESG COMMENT item (NSDB section 1)

-- Section 1 --

 All the "MAY"s in the second paragraph are inappropriate, and should be
 "may" (or "might", of you prefer).  That's all non-normative explanation
 of how this is all meant to fit together, not normative text about
 interoperability choices.
Resolve Barry Leiba's IESG COMMENT item (NSDB section 2.8.1)

-- Section 2.8.1.1 --

 It's probably not a good idea to repeat normative information from
 elsewhere without citation.

 -- Section 2.8.1.2 --

 Again, none of the encoding stuff is new.  I'd really like it if you made
 it clear that this is all just in conformance with normal RFC 3986 rules.
Resolve Barry Leiba's IESG COMMENT item (NSDB section 2.8.3)

-- Section 2.8.3 --

 I also suggest adding a forward reference to Section 2.10 the first time
 "junction" is mentioned.
Resolve Barry Leiba's IESG COMMENT item (NSDB section 2.11)

-- Section 2.11 --

 Is there a document where [root filesets] are or will be defined, which
 you can cite?  If so, please do; if not, it might be better to say why
 they're not defined here ("...are implementation dependent and are not
 in scope for this document," or whatever is appropriate).
Resolve Barry Leiba's IESG COMMENT item (NSDB section 2.12)

-- Section 2.12 --

  Of course, there is no way to guard against UUID re-use, but that is
  highly unlikely provided that UUIDs are constructed carefully.

 Is "carefully" the right word?  Or maybe, "properly, according to
 [RFC4122]." ?
Resolve Barry Leiba's IESG COMMENT item (NSDB section 3.3)

-- Section 3.3 --

   Fileset annotations MAY be used to convey additional attributes of a
   fileset

 Apart from a missing full stop at the end, here's another inappropriate
 "MAY", which should be "may" or "can".  This isn't describing a protocol
 choice that affects interoperability.  It's telling us what fileset
 annotations are used for.
Resolve Barry Leiba's IESG COMMENT item (NSDB section 4.1)

-- Section 4.1 --

   All implementations SHOULD use the same schema, or, at minimum, a
   schema that includes all of the objects, with each of the attributes,
   named in the following sections.

 The "SHOULD" and "at minimum" have an unclear relationship.

 --

   Given the above configuration guidelines, an NSDB SHOULD be
   constructed using a dedicated LDAP directory.  Separate LDAP
   directories are RECOMMENDED for other purposes, such as storing user
   account information.

 Again, the relationship of the second sentence to the SHOULD in the first
 is unclear.
Resolve Barry Leiba's IESG COMMENT item (NSDB section 4.2)

-- Section 4.2 --

   As stated above, code components extracted from this document must
   include the following license:

 As stated "above" where?  Maybe say "in the Copyright Notice at the
 beginning of this document," or just leave that off and start with "Code
 components...."
Resolve Barry Leiba's IESG COMMENT item (NSDB section 4.2.1.6)

-- Section 4.2.1.6 --

   A fedfsAnnotation value SHOULD be processed as follows:

 Why?  Is this talking about interoperability, or imposing an
 implementation?  What happens if I reverse those two steps in my
 implementation?  Is there a difference?

   A fedfsAnnotation attribute that does not adhere to this format
   SHOULD be ignored.

 What other options are there?  What else could I possibly do with it?

 You might also include an example that doesn't have the optional SPACE
 characters around the EQUALS:

   "key1"="foo"
Resolve Barry Leiba's IESG COMMENT item (NSDB sections 4.2.1.10ff)

-- Section 4.2.1.10 --

   A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
   FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
   is true.  A value of "FALSE" indicates the bit is false.

 RFC 5661 never uses "true" or "false" to refer to that bit.  It uses
 "set" and "on".  I suggest this:
 NEW
   A fedfsNfsGenFlagWritable stores the value of an FSL's NFSv4.1
   FSLI4GF_WRITABLE bit [RFC5661].  A value of "TRUE" indicates the bit
   is set.  A value of "FALSE" indicates the bit is not set.

I suggest the same change for Sections 4.2.1.11, 12, and 13.
Resolve Barry Leiba's IESG COMMENT item (ADMIN sections 5.[234567].2)

-- Section 5.2.2 --

   If the path contains an invalid UTF-8 character, then status
   FEDFS_ERR_BADCHAR MUST be returned.

 What characters are valid?  When I look at the definition of
 FEDFS_ERR_BADCHAR, I think you mean "unsupported", rather than
 "invalid"... yes?  [I'm picking on this because the IDNA specs actually
 *do* define valid and invalid characters, and you probably don't want to
 try to mess with that. :-) ]

 This also appears in Sections 5.3.2, 5.4.2, 5.5.2, 5.6.2, and 5.7.2.
Resolve Barry Leiba's IESG COMMENT item (ADMIN sections 5.5.2 and 5.6.2)

-- Section 5.5.2 --

   The server SHOULD permit this operation even on read-only filesets,
   but MAY return FEDFS_ERR_ROFS if this is not possible.

 You might mean exactly this, in which case it's fine, but this is a
 SHOULD/MAY construct that's often wrong, so I'm checking.  "SHOULD do X
 but MAY do Y" is correct if Y is *always* optional.  But more often, this
 is what's really intended:

   The server SHOULD permit this operation even on read-only filesets,
   but MUST return FEDFS_ERR_ROFS if this is not possible.

 Is that the case here?
 This also appears in Section 5.6.2.
Resolve Barry Leiba's IESG COMMENT item (ADMIN sections 5.[234567].2)

This one is related:
   The server MAY enforce the local permissions on the path, including
   the final component.  If the path cannot be traversed because of
   insufficient permissions, or the final component is an unexecutable
   or unwritable directory, then the operation MAY fail with status
   FEDFS_ERR_ACCESS.

 If you mean this, then the phrasing above is correct:
 1. The server MAY enforce local permissions.
 2. If it does, then it MAY use FEDFS_ERR_ACCESS to convey failures (but
 that's entirely optional, and it could use some other code instead).

 But if you mean this, then you should re-phrase:
 1. The server MAY enforce local permissions.
 2. If it does, then it MUST use FEDFS_ERR_ACCESS to convey failures.

 This also appears in Sections 5.2.2, 5.3.2, 5.4.2, 5.6.2, and 5.7.2.
Resolve Barry Leiba's IESG COMMENT item (ADMIN sections 5.8.2 and others)

-- Section 5.9.2 --

   On failure, an error value indicating the type of error is returned.
   This operation MAY return FEDFS_ERR_NSDB_PARAMS to indicate that
   there are no connection parameters on record for the given NSDB.  The
   operation MAY return FEDFS_ERR_ACCESS if the operation's associated
   user does not have sufficient permissions to view NSDB connection
   parameters.

 This is similar to some of the others.  If you mean to say that using
 those error codes is entirely optional, even under the conditions
 specified, then this is fine.  But if you mean to say that certain error
 codes are definitely the ones to use in these situations, then the MAYs
 are wrong, and you should re-word this.

 There are similar situations at the ends of Sections 5.8.2 and 5.10.2.