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

Tom Haynes <thomas.haynes@primarydata.com> Wed, 06 January 2016 00:37 UTC

Return-Path: <thomas.haynes@primarydata.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37DE1B2DC8 for <nfsv4@ietfa.amsl.com>; Tue, 5 Jan 2016 16:37:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTKHa-ZYuqHj for <nfsv4@ietfa.amsl.com>; Tue, 5 Jan 2016 16:37:54 -0800 (PST)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 777A41B2DC5 for <nfsv4@ietf.org>; Tue, 5 Jan 2016 16:37:50 -0800 (PST)
Received: by mail-pa0-x232.google.com with SMTP id yy13so130912672pab.3 for <nfsv4@ietf.org>; Tue, 05 Jan 2016 16:37:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=primarydata-com.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NC1c0N2UkLLkbF2ZYUvzoQo6sKynnJsAFZprqB3vaWY=; b=mglIGcLulDegHwfcHkc0T7X+/09MQofn3dm9syz685W09LNDjwJ0zt0DDWp+jiWCSU sesGU6+6OthIk9XUoUQsdJ3t99+FI1TLZHS2J/qcv1jaWXVh7rR4PXeto5UWO52eCo1Q yMGyedBaOSL8L4/HSoAstcdrfL0TnqZE0e0OdBL77NS1Y/gkYGwnafQn74aruSXJVxku 88jdKvQJDn9uins7mAEUd5q3eluadXKW7t0rD/gV7mNRKL40PbvJv2ji7mcwZJJ9gOji q8iDqs4wOr/HQaG2bBv57JPsaU9lrW4L4YzMZbMgEJThz85e6Vo8WLASv8hbJpNJyHBi B+Dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=NC1c0N2UkLLkbF2ZYUvzoQo6sKynnJsAFZprqB3vaWY=; b=jOg5GP17/97dsqYtKso6l6z9NYkHe8j5GYWaup1ALcBqxOf7EzN6JzniVJxagvCASo vE6M7CwTa3V7W4CcVQhIWF+K9WzJ7Wfdx8oa1Gn8xrx4BJRVrUr/R4xehqX58BYOvQB1 QeX3vmc9nSxgC1UQUBen3lXAEEdSZAhIu6ECqwMxadghwB8ebN4NFNBDypDpD41lwMdA 7rwCl16klAnSIKVGaOSc+7epfwGQ/ejK4kSCmKUC0h32fmNQ75vsK6hbJaX6oJ2g1RoC ZaWdRZk/6Z9xYJ/Bafc/BypCXOXw3mdyZL1z3fVvp3Cc4dPycDiWHojinM++LitI1Nej TsXA==
X-Gm-Message-State: ALoCoQnOJBrp0UtUJCtBX9LJr7fJFZqZPyW1XfZ/NJY40kFgHkyBjBcL+9K8by8T6SyQ8ZA6/+PSNHImdbbXauK4pBrnXA7wKg==
X-Received: by 10.66.100.198 with SMTP id fa6mr97001778pab.123.1452040669467; Tue, 05 Jan 2016 16:37:49 -0800 (PST)
Received: from kinslayer.corp.primarydata.com (63-157-6-18.dia.static.qwest.net. [63.157.6.18]) by smtp.gmail.com with ESMTPSA id tu9sm136130038pac.0.2016.01.05.16.37.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 05 Jan 2016 16:37:48 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C08FF8D-4737-42CD-8CC5-F5D7B8D59343"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Tom Haynes <thomas.haynes@primarydata.com>
In-Reply-To: <20160105041039.24450.918.idtracker@ietfa.amsl.com>
Date: Tue, 05 Jan 2016 16:37:48 -0800
Message-Id: <0292C233-4BD2-496C-9D7E-7D61136D4DEE@primarydata.com>
References: <20160105041039.24450.918.idtracker@ietfa.amsl.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/8IclFwPdTT4UjsvGIjTOTmkg5eM>
Cc: nfsv4-chairs@ietf.org, The IESG <iesg@ietf.org>, nfsv4@ietf.org, draft-ietf-nfsv4-minorversion2@ietf.org
Subject: Re: [nfsv4] Ben Campbell's Discuss on draft-ietf-nfsv4-minorversion2-39: (with DISCUSS and COMMENT)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jan 2016 00:37:57 -0000

> On Jan 4, 2016, at 8:10 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
> 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:
> 

Hi Ben,

Proposals inline.


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

Note that this was taken verbatim from RFC5661 and RFC5662.


> This draft normatively depends on
> [NFSv42xdr] anyway, so why not completely delegate the assigned Id
> numbers to it?


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.



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


I’m okay with making that a 


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


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




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


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




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

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.



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

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.


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

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.


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


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


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

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

> 
> - 4.2, paragraph 4: "traditional copy authentication approach"
> 
> Is "authentication" the right word? The paragraph otherwise seems about
> authorization.

Changed


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

Done

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


Argh, thanks!


> 
> - 9.6.1.1, first paragraph, first sentence:
> 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.


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

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.