Skip to main content

Last Call Review of draft-ietf-nfsv4-minorversion2-39
review-ietf-nfsv4-minorversion2-39-opsdir-lc-jiang-2016-01-04-00

Request Review of draft-ietf-nfsv4-minorversion2
Requested revision No specific revision (document currently at 41)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-01-05
Requested 2015-12-04
Authors Thomas Haynes
I-D last updated 2016-01-04
Completed reviews Genart Last Call review of -39 by Elwyn B. Davies (diff)
Genart Telechat review of -40 by Elwyn B. Davies (diff)
Secdir Last Call review of -39 by Scott G. Kelly (diff)
Opsdir Last Call review of -39 by Sheng Jiang (diff)
Assignment Reviewer Sheng Jiang
State Completed
Request Last Call review on draft-ietf-nfsv4-minorversion2 by Ops Directorate Assigned
Reviewed revision 39 (document currently at 41)
Result Has issues
Completed 2016-01-04
review-ietf-nfsv4-minorversion2-39-opsdir-lc-jiang-2016-01-04-00
Hi, OPS-DIR, Authors,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.

This Standards Track document specifies describes NFS version 4 minor version
two, describing the protocol extensions made from NFS version 4 minor version
1. It has been coupled with another document, "NFSv4 Minor Version 2 Protocol
External Data Representation Standard (XDR) Description,
draft-ietf-nfsv4-minorversion2-dot-x. They two should be published together, I
believe. This document is well written. It is almost ready to be published.
There are a major comment below, which may be fixed by two references if there
is already specification by another existing document:

In Section 3.3, "As the File Layout Type does not provide a means for informing
the client as to which minor version a particular storage device is providing,
it will have to negotiate this via the normal RPC semantics of major and minor
version discovery." It is not clear how negotiation to be performed and the
procedure. I did not find existing specification for minor version discovery,
neither. If there were existing specifications, two references could solve my
concern. But if there were not, the document may need to define the procedure
by itself.

Two more comments between major and minor:

The compatibility and potential interoperation among this 4.2 and 4.1, 4.0, is
still not very clear from operational perspective. It would be helpful to add
one more subsection in section 1 or 2 to clarify this.

It would help to clarify whether this specification is IP independent, although
my guess is positive. This document does give IPv4 examples, but not clear
whether it is also working with IPv6.

Minor comments:

  RFC 2401 has been obsoleted by RFC 4301,
  RFC 2616 has been obsoleted by RFC 7230 series.

A few abbreviations does not give full name explanation: ONC, NIS, NTFS, HFS,
HPC, pNFS, EOF, although they may be well known.

A few typos: Section 4.10.1.1.5, the last paragraph, nounce/nonce,
<"copy_to_auth", user id, source list, nounce, nounce MIC, context handle,
handle version>.
      Section 4.10.1.2, the second paragraph, uiniquely/uniquely, "The
      cnr_stateid returned from the COPY_NOTIFY can be used to uiniquely
      identify the destination server to the source server." Section 15.3, the
      third last paragraph, destination/ destination, "As the source does not
      know which netloc4 network location the destination might use to
      establish the copy operation" Section15.13.3, the third last paragraph,
      wlll/will, "the clone block size wlll be zeroed."

Best regards,

Sheng