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