Subject: [nfsv4] Spencer Dawkins' Yes on draft-ietf-nfsv4-versioning-09: (with COMMENT)

From: Spencer Dawkins <[email-masked]>
Date: Fri, 12 May 2017 07:36:44 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-nfsv4-versioning-09: Yes

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

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

Russ Housley has provided a Gen-ART review for -09 version of this
document, and the author is responding to those comments.

I did have one question that came up during AD Evaluation that I wanted
to mention.

The first two drafts that used this mechanism (umask and xattrs) used two
different idioms for discovering support. The xaddrs draft defines an
xaddr_support attribute, while umask does not.

In conversations with the working group, the reasoning was that xattrs
defines a number of operations, so discovering that the complete
mechanism is supported before you start trying to use the attributes
makes sense, while umask defines only one attribute, and for any
attribute, you can find out if it is supported within a given file system
by interrogating the appropriate bit position in the REQUIRED attribute
supported_attrs, so there is no advantage to adding a umask_support
attribute. 

That all made perfect sense to me, but the explanation was helpful enough
to me that I wonder if it's worth a sentence or two, pointing out that
some protocol designers may choose one idiom, while other protocol
designers choose the other, and saying that's not a problem.

If the answer is "that explanation isn't needed", that won't change my
ballot position from Yes, of course.

---

From: David Noveck <[email-masked]>
Date: Fri, 12 May 2017 10:49:20 -0400

I think this is a good idea.  I'll work on an additional paragraph for
section 6, explaining why and when an extension-supported attribute would
be helpful.

---

From: Trond Myklebust <[email-masked]>
Date: Fri, 12 May 2017 11:17:26 -0400

> designers choose the other, and saying that's not a problem.

It's an extra mechanism that could be a convenience, but is not
something that a client can or should rely on. The only reliable
mechanism for verifying that the feature is available is to try it, and
handle the resulting NFS4ERR_NOTSUPP and/or NFS4ERR_OP_ILLEGAL error.

This is how the Linux client handles all the other NFSv4.x optional
features as well.

Cheers
  Trond

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 25 May 2017 12:13:31 -0400

Dear -versioning- folk,

> This is how the Linux client handles all the other NFSv4.x optional

This draft was approved on today's telechat, but the secretariat is holding
off sending the approval announcement until I let them know that all the
comments have been addressed.

It looked like David had a plan for this specific comment on idioms for
detecting support, and Trond had a response, so if others have thoughts
that would affect the text that appears in the RFC, it would be great to
hear that, Real Soon Now.

Thanks!

Spencer (D)

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 26 May 2017 11:24:27 -0400

Dear NFSv4,

On Thu, May 25, 2017 at 12:13 PM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> This draft was approved on today's telechat, but the secretariat is
> holding off sending the approval announcement until I let them know that
> all the comments have been addressed.
>

David has submitted a -10 version of this draft, that does not discuss
idioms about detecting support (that I can find).

I don't think that's a problem for this document, so I won't hold this
document up. I would, of course, appreciate the working group thinking
about comments in this thread, and discussing whether it would be helpful
to say something in a future draft (or, potentially, a revision to the RFC
this draft will become).

And thanks for the explanations.

Spencer

---

From: David Noveck <[email-masked]>
Date: Fri, 26 May 2017 11:39:50 -0400

>  David has submitted a -10 version of this draft, that does not discuss
idioms about detecting support
>  (that I can find).

It was lost in the update process.  Anyway the following is what I intended
to add:

 <t>
      In some cases extensions will contain elements such as new operations
      or previously invalid switch cases.  Although it is possible to
      determine whether these OPTIONAL elements are supported using the
      rules described above, those defining extensions containing such
      elements have the option of defining new attributes that specify
      whether the feature is present and supported.  Since it is easy to
      determine whether a new attribute is supported using the
      supported_attrs attribute, this can make it simple and
      convenient for clients to determine whether support is present,
      particularly when a feature involves support for multiple
      such elements.
    </t>

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 26 May 2017 10:27:31 -0700

David Noveck <[email-masked]> writes:

>       whether the feature is present and supported.  

I'd like to replace the second sentence with something like

  Although it is possible to determine whether these OPTIONAL elements are
  supported using the rules described above, an extension that contains
  such elements could also define a new attribute that indicates whether
  the feature is present and supported.

The concerns I have with the original wording are

1. I think the use of singular "extension" and "attribute" is clearer
than using plurals.

2. I'm uneasy about using "specify" in this context, since it seems to
imply that the attribute's sole purpose is to indicate whether the
feature is supported.  If the feature is already defining a new
attribute, I don't want to encourage the creation of another attribute
when the first one would be good enough for indicating support.

The rest of the text looks fine to me.

mike

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 26 May 2017 11:01:45 -0700

I noticed a couple editorial nits that -10 introduced.  I'm told that
since WGLC has ended, I need the broad cc above.  Anyway, it'd be nice
if we could get these fixed prior to publication as an RFC, especially
the first one.

Section 4.4.2: "When minor version" -> "When the minor version"

Section 6: "RFC defining" -> "RFC that defines"

mike

---

From: David Noveck <[email-masked]>
Date: Fri, 26 May 2017 14:05:32 -0400

I'll fix these in the next iteration, originally targeted at fixing my
merge screwups.