Subject: [nfsv4] 3/29 Conference call

From: David Noveck <[email-masked]>
Date: Mon, 28 Mar 2016 04:39:50 -0400

We're going to have a conference call regaring nfsv4 extension on March 29
 at 12-2 PM Pacific time.
The subject will be draft-ietf-nfsv4-versioning and some likely extensions
that might be incorporated
into nfsv4.  Right now, these include xattrs and node_umask.

If you want to participate in this call, you need to get the conference
call information from Spencer.
This information has not been posted to the mailing list.

As this call was originally thought of as a substitute for a remote
presentation for the meeting in
Buenos Aires, I started by creating slides.  I eventually wound up with two
set of slides, one discussing
where we are in the process of creating/reviewing  the extension draft and
the second serving as an
introduction to that draft.

It isn't necessary to see the slides to participate.  Their man function
will be to serve as my notes on
topics to cover.  Also, they might be helpful to anyone acting as note
taker.

I can send the slides to anybody who is interested.  Unfortunately they are
too large to be sent to the
mailing list.

---

From: [email-masked] (J. Bruce Fields)
Date: Tue, 29 Mar 2016 20:04:25 -0400

I've tried to do a proper review of the document and made it through
about 25 pages and gave up.  I apologize.

I'm afraid I don't understand what problem the document solves.

I'm in favor of allowing protocol extensions without bumping the minor
version number, but I think the way we should do that is by accepting a
document that describes an extension to the protocol that doesn't bump
the minor version number.

When I review such a document, my main priority will be to convince
myself that the proposal will maintain backwards-compatibility with
protocol implementations.

I could in addition check whether the proposal meets the specific
requirements laid about by this draft, but I'm not convinced that would
help.

Anyway, some random observations:

This defines a lot of new terminology ("feature", "feature elements",
"feature package", "version group", "E-to-F status", etc.).  There are a
lot of definitions to learn.

I think there may be some cases where BAD_XDR could also be returned.
E.g. when the client used a previously undefined flag bit.

2.2: "In using these terms, RFCs which specify the status of features or
protocol elements inform:

      o  client implementations whether they need to deal with the
      absence of support for the protocol elements

      o  server implementations whether they need to provide support for
      the protocol elements"

I think you could also reverse "client" and "server" in the above.
(Trying to recall--I think 4.1 referring triples might have been such a
case?  Or dynamic slot table size negotiation?)  Possibly remove the
words "client" and "server" from the above.

5.2.1: "One class of behavioral change involves changes in the set of
errors to be returned in the event of various errors.  When the set of
valid requests remain the same, and the behavior for each of them
remains the same, such changes can be implemented with only limited
disruption to existing clients."  I don't think that's really true.
Errors aren't all treated the same, they often trigger very specific
kinds of recovery from clients of applications.

But again in all these cases it's much simpler for me just to think
about whether a given change will preserve interoperability than to
try to apply this very long list of specific guidelines.

--b.

---

From: David Noveck <[email-masked]>
Date: Wed, 30 Mar 2016 05:55:36 -0400

> I'm afraid I don't understand what problem the document solves.

The problem that it attempts to solve is that the existing,
approved-by-the-IESG, treatment of versioning (in RFC5661) is one that has
problems that we want to correct., going forward.

Normally, the problem that is to be solved is addressed in the abstract but
I have not been as explicit as I might have been about the problems in the
existing model.  Let's go through ithe abstract.

This document describes the management of versioning within the NFSv4
family of protocols.

I'm not explicit about this, but the implication is that the existing
treatment is in some way deficient/wrong.

It covers the creation of minor versions,

This has been described before but the treatment in RFC5661 has some
problems ("infratsructural" features etc.), addressed in the new document's
body.

the addition of optional features to existing minor versions,

Although the working group seems OK with this and you are eager to do it,
those outside the working group, including IESG members. may have a
different perspective. For them, the versioning model in effect is the one
in RFC5661 and it makes no provision for the addition of optional features
to minor versions, without changing the minor version number.

and the correction of flaws in features already published as Proposed
Standards.

We always had the option of publishing updates, but the problem was with
the general assumption that changes in XDR were out of bounds. The document
attempts to correct that and tries to make it clear that extending the XDR
is a better option in allowing interoperability.

The rules relating to the construction of minor versions and the
interaction of minor version implementations that appear in this
document supersede the minor versioning rules in RFC5661.

Those rules make no provision for the addition of optional features or the
correction of flaws (including XDR changes) in approved Proposed Standards.

In summary, I think the problem is that you can't see the trees for the
forest. You see the forest as necessary/desirable and I agree. But when you
bring a document to the IESG, one gets questions about why particular trees
are where they are, pruning that needs to be done, etc. :-(

> the minor version number.

We've already done that. The xattr document was accepted as a working group
document.

If you and Andreas want to convert your document to be a working group
document, then
I can't see that the fact that it doesn't mention bumping the version
number being an obstacle.

If we think about WGLC for these documents, we will have to think about
getting the document approved by the IESG.

I think we need to consider the possibility of questions like the
following:being asked:

   - You add new attributes/operations to v4.2. But RFCv42,, recently
   approved, is defined as a set of deltas to v4.1. You are changing v4.2 and
   so changing the set of deltas. So why isn't your document marked as
   updating RFCv42?
   - You indicate some changes in the XDR (for v4.2) are necessary to
   enable this extension. If so, why isn't your document marked as updating
   RFCv42xdr?
   - With these two proposed extensions, there are now four possible XDR
   files that might be considered as a valid 4.2 XDR. As a result, there are
   now 16 possible combinations of client and server XDRs that might be asked
   to interoperate. Although the working group clearly believes that the
   interoperability problems have been satisfactorily addressed, the documents
   don't make clear how this all works with clients and servers having
   different XDR files and still interoperating. Wasn't the purpose of the
   minor version field in compound to make sure that the client and server had
   the same XDR files? Please explain.
   - With this and other proposed extensions, where is someone to go to get
   the current definition of v4.2 or its XDR? Since these are Proposed
   Standards, and not works in progress, why should we approve these ideas for
   changes?
   - RFC 5661 says that these sorts of changes (addition of optional
   features) are to be made by creating minor versions. If that is no longer
   true, why isn't your document marked as updating RFC5661?

To get back to the purpose of the document, it is to provide an explanation
that individual feature authors can point to to address such questions.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 30 Mar 2016 19:24:47 -0400

On Wed, Mar 30, 2016 at 05:55:36AM -0400, David Noveck wrote:
> document

Whoops, I don't know how to do that.  Googling around....  Sounds like
the answer is "ask a chair"?  Spencer?

--b.

---

From: Thomas Haynes <[email-masked]>
Date: Thu, 31 Mar 2016 07:57:00 -0700

> On Mar 30, 2016, at 4:24 PM, J. Bruce Fields <[email-masked]> wrote:
> 

Just change the name from draft-bfields-nfsv4-umask-01 to draft-ietf-nfsv4-umask-00
and resubmit.

That will let Spencer accept it and it will become a WG document.

---

From: William Allen Simpson <[email-masked]>
Date: Thu, 31 Mar 2016 14:10:08 -0400

> That will let Spencer accept it and it will become a WG document.
To be honest, lots and lots of IETF WG documents started off as
personal drafts, and during WG consideration they stay as personal
drafts.  That makes the automated diff tools work better.

A document is a WG document IFF the WG wants it and the author agrees.
The name has nothing to do with it.

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 31 Mar 2016 19:59:31 +0000

Bruce,

Follow Tom's suggestion on naming/submission and make sure that you let me know when you submit (in personal email).

Spencer

-----Original Message-----
From: nfsv4 [mailto:[email-masked]] On Behalf Of William Allen Simpson
Sent: Thursday, March 31, 2016 11:10 AM
To: Thomas Haynes <[email-masked]>; J. Bruce Fields <[email-masked]>
Cc: [email-masked]
Subject: Re: [nfsv4] 3/29 Conference call

On 3/31/16 10:57 AM, Thomas Haynes wrote:
>> Whoops, I don't know how to do that.  Googling around....  Sounds 
>> like the answer is "ask a chair"?  Spencer?
>
>
> Just change the name from draft-bfields-nfsv4-umask-01 to 
> draft-ietf-nfsv4-umask-00 and resubmit.
>
To be honest, lots and lots of IETF WG documents started off as personal drafts, and during WG consideration they stay as personal drafts.  That makes the automated diff tools work better.

_______________________________________________
nfsv4 mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fnfsv4&data=01%7c01%7csshepler%40microsoft.com%7c5e3b1e8df549459b1ef908d3598fb551%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=5UnWAGFL6TXquTZRek%2fsA5831RxwKJnNFOKavdvVlD4%3d