Re: [Gen-art] Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13

[Peter Yee <[e-mail]>]

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 <[e-mail]> wrote:

> 
> On Oct 21, 2012, at 11:35 PM, Peter Yee <[e-mail]> 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" <[e-mail]> wrote:
>> 
>>> 
>>> On Oct 21, 2012, at 5:39 PM, Peter Yee <[e-mail]> 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
> 
> 
> 
> 
>