[nfsv4] Joel Jaeggli's No Objection on draft-ietf-nfsv4-minorversion2-39: (with COMMENT)

["Joel Jaeggli" <[e-mail]>]

Joel Jaeggli has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-39: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

At this time I have no objection while awaiting the outcome of the opsdir
review performed by sheng jiang

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