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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 04 Jan 2016 20:10:39 -0800

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

---

From: Tom Haynes <[email-masked]>
Date: Tue, 5 Jan 2016 16:37:48 -0800

> On Jan 4, 2016, at 8:10 PM, Ben Campbell <[email-masked]> wrote:
> 

Hi Ben,

Proposals inline.

> there a reason not to just fix it now?

Note that this was taken verbatim from RFC5661 and RFC5662.

> This draft normatively depends on

How about:

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

> corruption. Are there ever situations where it might make sense not to do

I’m okay with making that a 

Yes, it is. We had a huge problem with NFSv4.1 in the sheer size of the document.
We decided to not repeat things that did not change and when we make a change,
we would provide a separate document. I.e., if we were to change migration, we get
drafts like https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530-migration-update/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530-migration-update/>.

> on what expectations of interoperability exist between 4.2., 4.1, and

If asked by two separate parties, I guess it must mean I’m the one that is blind
to the issue! :-)

Here is the new Section 1.1:

1.1.  Scope of This Document

   This document describes the NFSv4.2 protocol.  With respect to
   NFSv4.0 and NFSv4.1, this document does not:

   o  describe the NFSv4.0 or NFSv4.1 protocols, except where needed to
      contrast with NFSv4.2

   o  modify the specification of the NFSv4.0 or NFSv4.1 protocols

   o  clarify the NFSv4.0 or NFSv4.1 protocols, that is any
      clarifications made here apply only to NFSv4.2 and neither of the
      prior protocols

   NFSv4.2 is a superset of NFSv4.1, with all of the new features being
   optional.  As such, NFSv4.2 maintains the same compatibility that
   NFSv4.1 had with NFSv4.0.  Any interactions of a new feature with
   NFSv4.1 semantics, is described in the relevant text.

   The full External Data Representation (XDR) [RFC4506] for NFSv4.2 is
   presented in [NFSv42xdr].

> forms of privacy protection?

Yes - for example such security may be provided with a network which has restricted physical access.

For NFSv4.x, we have a strong requirement that kerberos MUST be supported, but we
have a weak requirement that it be deployed.

See Section 2.2.1.1.1.2 of RFC5661.

> the attribute is successful? 

The intent is to say that the server may be configured to accept the label as is from the client OR it may examine the attribute to see if it is acceptable based on some local policy.

> not validate the security attributes?

It is MAY because we don’t control the policies on the server - that is a decision that may be controlled by the software or even by a conjuration made by the administrator.

“Full Mode” simply means that both the client and server may make decisions.

> The reference to [Quigley14] needs to be normative.

Yes, it is already normative in what will be draft-40.

> would help to move this section into the section on the new operations. 

We wanted to pull them out to provide an overview. How about:

3.  pNFS considerations for New Operations

   The interactions of the new operations with non-pNFS functionality is
   straight forward and covered in the relevant sections.  However, the
   interactions of the new operations with pNFS is more complicated and
   this section provides an overview.

3.1.  Atomicity for ALLOCATE and DEALLOCATE

> Also, please expand pNFS on first mention

Done

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

Changed

> Please expand ONC on first mention.

Done

> should "cfp_shared_secret" be "cap_shared_secret"?

Argh, thanks!

> I don’t understand this sentence. Does it add value to the paragraph?

You mean this:

   The ability to create a file is an action that a MAC model may wish
   to mediate. 

I think it does - it points out that the decision is made by the MAC model and not LNFS.

> if you reference the I-D.)

I’ve grabbed the draft reference from http://xml2rfc.ietf.org/public/rfc/bibxml3/ <http://xml2rfc.ietf.org/public/rfc/bibxml3/> and will just use that.

   [I-D.ietf-nfsv4-minorversion2-dot-x]
              Haynes, T., "NFSv4 Minor Version 2 Protocol External Data
              Representation Standard (XDR) Description", draft-ietf-
              nfsv4-minorversion2-dot-x-40 (work in progress), January
              2016.

And I’ve applied this same type of change to the XDR document.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 14 Jan 2016 22:46:21 -0600

Thanks for the response. Comments inline (I deleted sections that do not 
seem to need further discussion.)

On 5 Jan 2016, at 18:37, Tom Haynes wrote:

>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html

It seems odd there, too :-)

>    See [IESG08] for the Errata process.

That's better, and enough for me to clear the discuss. I'd still prefer 
to remove the reference to the errata process; the draft does not need 
to invoke that now to use it later. As it is, it gives the impression 
that it's not necessary to get this draft right, because we can fix it 
later. (Which I doubt very much is the intent.) In any case, I will not 
block further on it.

> I’m okay with making that a

The sentence was cut off. I assume you were going to say "MUST"? (It's 
still a SHOULD in version 40.)

[...]

> See Section 2.2.1.1.1.2 of RFC5661.

(I meant 40.10.2.1, but you seem to have found it anyway)

I think it would help to have an explanation to that effect in the text.

[...]

> It is MAY because we don’t control the policies on the server - that 
> is a decision that may be controlled by the software or even by a 
> conjuration made by the administrator.
>

On re-reading this section, I think I understand this to mean that the 
implementation MAY (or MAY not) limit the security attributes acceptable 
from a certain _peer_, (as opposed to a certain user and/or resource). 
Given that, I think the MAY makes sense.

[...]