Subject: [nfsv4] IETF96 presentations for NFSv4

From: spencer shepler <[email-masked]>
Date: Tue, 19 Jul 2016 08:41:52 -0700

I have posted all presentation material to the proceedings site.

Presenters - if you see something missing/wrong, please send me email.

Will need minutes from the meeting in case someone took notes.

All IETF meetings' recordings are here:

https://ietf96.conf.meetecho.com/index.php/Recordings

The NFSv4 meeting can be viewed here:

http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_NFSV4&chapter=chapter_1

Spencer

---

From: "Marc Eshel" <[email-masked]>
Date: Wed, 27 Jul 2016 11:20:37 -0700

I waited for the meeting minutes but since I am not sure if they are 
coming I decided to just respond after listening to the presentations and 
consulting with Manoj.

First, unlike what Chuck said in the meeting, we (Marc and Manoj) never 
said that we did not want to wait for minor-versioning, we believe it is 
the right direction and would like xattr to be the first to use it.

We haven’t abandoned it - right now, the document is technically complete 
(we’ll release another revision with some new comments, from mainly Dave) 
and it’s waiting for the process to finish. Not sure who talked to the 
authors and claims otherwise.

It looks like the consensus in the meeting was to submit minor-versioning 
+ xattr to the IESG together, we support that approach, but we don’t want 
to combine the documents though - they should stay separate.

Marc.

From:   spencer shepler <[email-masked]>
To:     "[email-masked]" <[email-masked]>
Date:   07/19/2016 08:52 AM
Subject:        [nfsv4] IETF96 presentations for NFSv4
Sent by:        "nfsv4" <[email-masked]>

Spencer
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Wed, 27 Jul 2016 15:02:21 -0400

Hi Marc-

> On Jul 27, 2016, at 2:20 PM, Marc Eshel <[email-masked]> wrote:
> 

I don't think I claimed I spoke with the authors of the
xattr draft. However I recall a mention of a perceived
linkage between these documents during the design call
in March. Bruce may have been one of the commenters,
wrt to his umask document.

If that is not correct, feel free to blame my faltering
memory.

--
Chuck Lever

---

From: "Marc Eshel" <[email-masked]>
Date: Wed, 27 Jul 2016 12:57:57 -0700

Hi Chuck,
No need for blames, just wanted to make our position clear. I think we all 
agree on the way to proceed.
Marc.

From:   Chuck Lever <[email-masked]>
To:     Marc Eshel/Almaden/IBM@IBMUS
Cc:     spencer shepler <[email-masked]>, Manoj Naik 
<[email-masked]>, "[email-masked]" <[email-masked]>
Date:   07/27/2016 12:02 PM
Subject:        Re: [nfsv4] IETF96 presentations for NFSv4

Hi Marc-

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Wed, 27 Jul 2016 16:24:31 -0400

> the right direction and would like xattr to be the first to use it.

I'm not sure exactly what Chuck said at the meeting but I don't think that's
the important issue.

> Not sure who talked to the authors and claims otherwise.

I'm pretty sure nobody claimed otherwise.

> + xattr to the IESG together,

Last time I used the C-word, I got a lot of compaints, so let me say
that there seemed to be general agreement that the IESG would
respond  better, if presented, at the same time, with a new approach
to versioning and something which used it.  In particular, David Black
was worried that the IESG would not respond well to being presented
with a new versioning model in the abstract without any particular use
of it.

> we support that approach, but we don’t want

Nobody was talking about combining the documents. I think the idea
would be that the versioning document and the xattr document would
go forward together as a document cluster since xattr would have to
normatively reference the versioning document.

One issue that I think was not fully resolved was the identity of the
versioning
document going forward.  The two possible approaches would be:

   - To continue with the existing draft-ietf-nfsv4-versioning
   - To switch to a document with a considerably smaller scope, such as
   might be done if the document were based on my current I-D,
   draft-dnoveck-nfsv4-extension.

---

From: "Marc Eshel" <[email-masked]>
Date: Wed, 27 Jul 2016 13:57:52 -0700

Dave,
You keep giving multiple option, for a group that can not make decision 
even with one option, instead of give one clear route and build consensus 
around it. I will always vote for shorter documents so I think the 
extension draft is a better route, but I think you should choose the one 
you prefer and the one you got the most positive support for and lets go 
with it.
Marc. 

From:   David Noveck <[email-masked]>
To:     Marc Eshel/Almaden/IBM@IBMUS
Cc:     spencer shepler <[email-masked]>, Manoj Naik 
<[email-masked]>, "[email-masked]" <[email-masked]>
Date:   07/27/2016 01:24 PM
Subject:        Re: [nfsv4] IETF96 presentations for NFSv4

> the right direction and would like xattr to be the first to use it.

I'm not sure exactly what Chuck said at the meeting but I don't think 
that's
the important issue.

 

One issue that I think was not fully resolved was the identity of the 
versioning 
document going forward.  The two possible approaches would be:
To continue with the existing draft-ietf-nfsv4-versioning
To switch to a document with a considerably smaller scope, such as might 
be done if the document were based on my current I-D, 
draft-dnoveck-nfsv4-extension.  

Marc.

Spencer

---

From: [email-masked] (J. Bruce Fields)
Date: Thu, 28 Jul 2016 13:02:48 -0400

> you prefer and the one you got the most positive support for and lets go 

I'm really concerned about the length of the last minor versioning
document, so if we have something simpler, I'd be happy.  I'll give it a
read.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 28 Jul 2016 13:04:58 -0400

> document, so if we have something simpler, I'd be happy.  I'll give it a

(But, like Mark, my main concern is just to get the new protocol
features in.  We have customers waiting on the umask fix, and as far as
we're concerned it's ready.)

--b.