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".