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 rev. | no specific revision (document currently at 41) | |
| Type | Last Call Review | |
| Team | Ops Directorate (opsdir) | |
| Deadline | 2016-01-05 | |
| Requested | 2015-12-04 | |
| Draft last updated | 2016-01-04 | |
| Completed reviews |
Genart Last Call review of -39 by Elwyn Davies
(diff)
Genart Telechat review of -40 by Elwyn Davies (diff) Secdir Last Call review of -39 by Scott Kelly (diff) Opsdir Last Call review of -39 by Sheng Jiang (diff) |
|
| Assignment | Reviewer | Sheng Jiang |
| State | Completed | |
| Review | review-ietf-nfsv4-minorversion2-39-opsdir-lc-jiang-2016-01-04 | |
| Reviewed rev. | 39 (document currently at 41) | |
| Review result | Has Issues | |
| Review completed: | 2016-01-04 |
Review
review-ietf-nfsv4-minorversion2-39-opsdir-lc-jiang-2016-01-04
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