[nfsv4] Ben Campbell's Discuss on draft-ietf-nfsv4-minorversion2-39: (with DISCUSS and COMMENT)

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

Ben Campbell has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-39: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have a couple of items I would like to see discussed prior to approval.
Hopefully they can be resolved easily:

- 12.1 says:

"Id:  The number assigned to the attribute.  In the event of conflicts
   between the assigned number and [NFSv42xdr], the latter is likely
   authoritative, but should be resolved with Errata to this document
   and/or [NFSv42xdr].  See [IESG08] for the Errata process."

This leaves a window open for considerable confusion down the road. Is
there a reason not to just fix it now? This draft normatively depends on
[NFSv42xdr] anyway, so why not completely delegate the assigned Id
numbers to it?

- 4.4.2, "The client SHOULD write back the data..."
SHOULD seems weak for something where failure  could result in data
corruption. Are there ever situations where it might make sense not to do
this?


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

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