Thank you very much Kathleen for the review. Based on this review and my own 
quick review, I have balloted No-Objection.

Jari

On Mar 29, 2013, at 11:58 PM, "Haynes, Tom" <[email protected]> wrote:

> Hi Kathleen,
> 
> Thanks for the review.
> 
> Tom
> 
> On Mar 29, 2013, at 10:34 AM, "Moriarty, Kathleen" <[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>.
>> 
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>> 
>> Document: draft-ietf-nfsv4-rfc3530bis-dot-x-16.txt
>> Reviewer: Kathleen Moriarty
>> Review Date: March 29, 2013
>> IETF LC End Date: 2013-04-16
>> IESG Telechat date: (if known)
>> 
>> Summary: The document is ready to publish after correcting the nits and the 
>> idnits results.  I did not perform any validation on the XDR description.
>> 
>> Major issues:
>> 
>> Minor issues:
>> 
>> Nits/editorial comments:
>> In the first sentence of the Abstract, consider adding the word "its":
>> Change from:The Network File System (NFS) version 4 is a distributed 
>> filesystem
>>  protocol which owes heritage to NFS protocol version 2, RFC 1094, and
>>  version 3, RFC 1813.
>> To: The Network File System (NFS) version 4 is a distributed filesystem
>>  protocol which owes its heritage to NFS protocol version 2, RFC 1094, and
>>  version 3, RFC 1813.
> 
> 
> Agreed
> 
>> 
>> Recommend adding a comma in the second sentence of the abstract:
>> Change from: Unlike earlier versions, the NFS version 4
>>  protocol supports traditional file access while integrating support
>>  for file locking and the mount protocol.
>> To: Unlike earlier versions, the NFS version 4
>>  protocol supports traditional file access, while integrating support
>>  for file locking and the mount protocol.
>> 
> 
> 
> Agreed
> 
> 
>> In the first sentence of paragraph 2 of the Abstract, I recommend changing 
>> from:
>> RFC3530bis is formally obsoleting RFC 3530.
>> To: RFC3530bis formally obsoletes RFC 3530.
> 
> 
> Agreed
> 
>> 
>> In the second sentence, I recommend changing from (remove but):
>> But this document,
>>  together with RFC3530bis replaces RFC 3530 as the definition of the
>>  NFS version 4 protocol.
>> To: This document,
>>  together with RFC3530bis replaces RFC 3530 as the definition of the
>>  NFS version 4 protocol.
> 
> 
> Agreed
> 
>> 
>> Introduction, second paragraph, first sentence:
>> Recommend changing from:  The XDR description is provided in this document 
>> in a way that makes
>>  it simple for the reader to extract into ready to compile form.
>> To:  The XDR description is provided in this document in a way that makes
>>  it simple for the reader to extract it into a ready to compile form.
> 
> 
> Agreed
> 
> 
>> 
>> Please resolve all of the idnit errors:
>> 
>> Miscellaneous warnings:
>> ----------------------------------------------------------------------------
>> 
>> == Line 262 has weird spacing: '...xpected   comp...'
>> 
>> == Line 628 has weird spacing: '...ned int    cb_...'
>> 
>> == Line 689 has weird spacing: '...S4resok   reso...'
>> 
>> == Line 719 has weird spacing: '...T4resok   reso...'
>> 
>> == Line 785 has weird spacing: '...R4resok  resok...'
>> 
>> == (11 more instances…)
> 
> 
> These are because of the XDR - I would prefer not to change them.
> 
> 
>> 
>> == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
>>    2119 boilerplate text.
> 
> 
> Agreed
> 
>> 
>> == The document seems to contain a disclaimer for pre-RFC5378 work, but was
>>    first submitted on or after 10 November 2008.  The disclaimer is usually
>>    necessary only for documents that revise or obsolete older RFCs, and that
>>    take significant amounts of text from those RFCs.  If you can contact all
>>    authors of the source material and they are willing to grant the BCP78
>>    rights to the IETF Trust, you can and should remove the disclaimer. 
>>    Otherwise, the disclaimer is needed and you can ignore this comment. 
>>    (See the Legal Provisions document at
>>    http://trustee.ietf.org/license-info for more information.)
> 
> 
> This is essentially a -bis work of RFC3530, with a publication date of
> April 2003. The splitting of RFC3530 into two documents is confusing the tool.
> 
> I will however contact all of the authors and see if they are willing to 
> grant BCP78.
> 
> 
>> 
>> There are also some errors with references.
> 
> Could you please elaborate here?
> 
>   [I-D.ietf-nfsv4-rfc3530bis]
>              Haynes, T. and D. Noveck, "NFS Version 4 Protocol",
>              draft-ietf-nfsv4-rfc3530bis-25 (work in progress),
>              Feb 2013.
> 
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", March 1997.
> 
>   [RFC4506]  Eisler, M., "XDR: External Data Representation Standard",
>              STD 67, RFC 4506, May 2006.
> 
> _______________________________________________
> Gen-art mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to