I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-nfsv4-federated-fs-protocol-13
Reviewer: Peter Yee
Review Date: Oct-19-2012
IETF LC End Date: Oct-22-2012
IESG Telechat date: TBD


Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication. [Ready with nits.]


This Standards Track document describes a protocol for maintaining a
Namespace Database for use with federated filesystem protocols.  The
document is well-written with good examples and little need to jump back
and forth in the text to understand it.

General: Are ranges (in attribute values) inclusive or exclusive?  They
appear to be inclusive, but it might be worth saying that somewhere, if
only once.

Section 2.7, NsdbName definition: expand NSDB to Namespace Database as
this is the first use of the term.

Section 2.8.1, 2nd sentence: "extention" -> "extension"

Section 2.8.3, 2nd paragraph, last sentence: in addition to checking for
added FSL records, shouldn't the fileserver also be checking for deleted
or migrated FSLs?  And why would the fileserver do this at the expiration
of the FSN TTL instead of waiting for the next access to the that FSN?
Otherwise the fileserver could be generating unnecessary traffic, although
there is a tradeoff to be made vs. performance.

Section 2.8.3, 3rd paragraph after bullet items, 1st sentence: "which" ->
"that".  (Yeah, I know, grammar police.)

Section 2.9, 3rd paragraph, 2nd sentence: "admininistrative" ->
"administrative"

Section 2.12, 2nd paragraph, last sentence: expand NCE (NSDB Container
Entry) as this is the first use of the term.

Section 3.2, item #5: "fs_location" -> "fs_locations"

Section 4.1, 1st paragraph, 3rd sentence: probably worth expanding "DSE"
to "DSA-specific entry" here.

Section 4.2.1.8, 1st paragraph, 2nd sentence: bracket "Section 2.8.1" in
"(see" and ")" for readability.

Section 4.2.2: "LDAP Objects" -> "LDAP Object Classes" seems appropriate.

Section 4.2.2.1, 2nd and 3rd sentences: replace "fedfsFsn" with
"fedfsNsdbContainerInfo"

Section 4.2.2.2, 5th paragraph: how is the prohibition on referencing
other attributes in the fedfsFsn object class supposed to work if this
document is the defining document for that object class?

Section 5.1.3.1, 1st paragraph after LDIF definition: a port number of
2049 is given.  Since this is already the default value, why not use a
different value?  Otherwise, there would be no practical need to include
that port number in the FSL creation request.

Section 5.1.3.1, 1st paragraph after LDIF definition: "up to date" ->
"up-to-date"

Section 5.1.3.2, 2nd paragraph: "a" -> "an"

Section 5.1.3.2, table entry for "fedfsNfsVarSub": "substituion" ->
"substitution"

Section 5.1.4, 1st paragraph, 1st sentence: "a Fileset location" -> "an
FSL"

Section 7.3, 2nd paragraph, "Specification" value: presumably this will be
changed to the RFC number when issued?

Section 8, 1st paragraph (definition of Administrator): "an" -> "a"

Section 8, 3rd paragraph (definition of Client): "filesystem access" ->
"file-access" for consistency of usage with the rest of the document.

Section 8, 5th paragraph (definition of Fileserver): rather than
discussing "a filesystem", should this be "one or more filesystems"?  Or
is a fileserver limited to exporting one filesystem?

Section 8, 8th paragraph (definition of Filesystem Access Protocol):
following up on the 3rd paragraph, should this be "File-access Protocol"
for consistency?

Section 8, 9th paragraph (definition of FSL), 2nd sentence: "fs_location"
-> "fs_locations".