[nfsv4] Ben Campbell's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-40: 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:
----------------------------------------------------------------------

I've cleared my DISCUSS position based on email discussion.

=== Substantive Comments ===

-1.1 and 1.2
It would help to clarify the relationship between this draft and NFS 4.0
and 4.1. This section says that this document does not describe or
clarify them. This led me to expect that the  NFS 4.2 spec would stand
alone, but it seems more like this draft is incremental to at least 4.1.

Also, as mentioned in the opsdir review, it would be helpful to comment
on what expectations of interoperability exist between 4.2., 4.1, and
4.0.

-4.10.1.1, last paragraph: "Servers SHOULD reject..."
Why not MUST? Do you envision circumstances where it might be okay to
accept COPY_NOTIFY requests over insecure channels? Channels with other
forms of privacy protection?

-- Last sentence in same paragraph:
- 9.6.1.1, first paragraph, last sentence:

Does this mean to imply that it may also choose _not_ to evaluate whether
the attribute is successful? 

- 9.6.1.2, last paragraph:

Why just MAY? does it ever make sense for a "Full Mode" implementation to
not validate the security attributes?

- 18

The reference to [Quigley14] needs to be normative.


=== Editorial and Nits ===

- 3:
This section seems out of context. It jumps into specifics without
introduction. Maybe an introductory paragraph would help, or perhaps it
would help to move this section into the section on the new operations. 

Also, please expand pNFS on first mention

- 4.2, paragraph 4: "traditional copy authentication approach"

Is "authentication" the right word? The paragraph otherwise seems about
authorization.

-4.2.2, paragraph 6:
Please expand ONC on first mention.

- 4.10.1.1, paragraph after first code fragment:
should "cfp_shared_secret" be "cfap_shared_secret"?

- 9.6.1.1, first paragraph, first sentence:
I don’t understand this sentence. Does it add value to the paragraph?

-- [NFSv42xdr]

The reference is missing the short name for the I-D, and should be
designated as a work-in-progress. (I know you intend for the RFC editor
to replace this, but they have processes in place to do the right thing
if you reference the I-D.)