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

Peter Yee <peter@akayla.com> Mon, 22 October 2012 03:35 UTC

Return-Path: <peter@akayla.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4540421F8AB3 for <ietf@ietfa.amsl.com>; Sun, 21 Oct 2012 20:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.279
X-Spam-Level:
X-Spam-Status: No, score=-0.279 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MANGLED_LIST=2.3, MIME_BASE64_BLANKS=0.041]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2QyNcZUpLQe for <ietf@ietfa.amsl.com>; Sun, 21 Oct 2012 20:35:43 -0700 (PDT)
Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by ietfa.amsl.com (Postfix) with SMTP id 723CD21F8AB0 for <ietf@ietf.org>; Sun, 21 Oct 2012 20:35:43 -0700 (PDT)
Received: (qmail 21731 invoked from network); 22 Oct 2012 03:35:42 -0000
Received: from unknown (64.134.68.84) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 22 Oct 2012 03:35:40 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Sun, 21 Oct 2012 20:35:36 -0700
Subject: Re: Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13
From: Peter Yee <peter@akayla.com>
To: Chuck Lever <chuck.lever@oracle.com>
Message-ID: <CCAA0CA5.11A5%peter@akayla.com>
Thread-Topic: Gen-ART review of draft-ietf-nfsv4-federated-fs-protocol-13
In-Reply-To: <8E799E97-421F-4ECE-A1F0-CFCBE605C3E6@oracle.com>
Mime-version: 1.0
Content-type: multipart/mixed; boundary="B_3433696546_3314490"
X-Mailman-Approved-At: Mon, 22 Oct 2012 08:14:18 -0700
Cc: gen-art@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, draft-ietf-nfsv4-federated-fs-protocol.all@tools.ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2012 03:35:44 -0000

Chuck,
	Ranges include the 0,255 that appears commonly in the document in
attribute definitions along with one case of -2147483648,2147483647.

	Kind regards,
		-Peter

On 10/21/12 3:27 PM, "Chuck Lever" <chuck.lever@oracle.com> wrote:

>
>On Oct 21, 2012, at 5:39 PM, Peter Yee <peter@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
>
>
>
>
>