Chuck, I'll cheerfully settle for the status quo. Please ignore that comment.
Thanks. -Peter On Oct 22, 2012, at 4:10 PM, Chuck Lever <chuck.le...@oracle.com> wrote: > > On Oct 21, 2012, at 11:35 PM, Peter Yee <pe...@akayla.com> wrote: > >> Chuck, >> Ranges include the 0,255 that appears commonly in the document in >> attribute definitions along with one case of -2147483648,2147483647. > > Hi Peter- > > Upon further review, I see the document uses "interval notation" when > defining ranges of allowed values in attributes. The use of square brackets > denotes inclusivity. If you feel readers need more, or our use of this > notation is inconsistent, I'm happy to add clarification. > >> Kind regards, >> -Peter >> >> On 10/21/12 3:27 PM, "Chuck Lever" <chuck.le...@oracle.com> wrote: >> >>> >>> On Oct 21, 2012, at 5:39 PM, Peter Yee <pe...@akayla.com> wrote: >>> >>>> 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. >>> >>> Can you give me an example of a range that might need clarification? >>> >>> I will address these comments and co-ordinate draft updates with our WG >>> editor, Tom Haynes. >>> >>> Thanks for your review. >>> >>>> 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". >>> >>> -- >>> Chuck Lever >>> chuck[dot]lever[at]oracle[dot]com >> >> <default[4].xml> > > -- > Chuck Lever > chuck[dot]lever[at]oracle[dot]com > > > > >