Skip to main content

Last Call Review of draft-ietf-nfsv4-rfc3530bis-dot-x-16
review-ietf-nfsv4-rfc3530bis-dot-x-16-genart-lc-moriarty-2013-03-29-00

Request Review of draft-ietf-nfsv4-rfc3530bis-dot-x
Requested revision No specific revision (document currently at 24)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-04-16
Requested 2013-03-21
Authors Thomas Haynes , David Noveck
I-D last updated 2013-03-29
Completed reviews Genart Last Call review of -16 by Kathleen Moriarty (diff)
Genart Last Call review of -22 by Elwyn B. Davies (diff)
Genart Last Call review of -22 by Martin Thomson (diff)
Genart Telechat review of -22 by Elwyn B. Davies (diff)
Secdir Last Call review of -16 by Magnus Nyström (diff)
Assignment Reviewer Kathleen Moriarty
State Completed
Request Last Call review on draft-ietf-nfsv4-rfc3530bis-dot-x by General Area Review Team (Gen-ART) Assigned
Reviewed revision 16 (document currently at 24)
Result Ready w/nits
Completed 2013-03-29
review-ietf-nfsv4-rfc3530bis-dot-x-16-genart-lc-moriarty-2013-03-29-00
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.

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.

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.

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.

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.

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...)

  == The document doesn't use any RFC 2119 keywords, yet seems to have RFC
     2119 boilerplate text.

  == 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.)

There are also some errors with references.