Subject: [nfsv4] NFSv4 WG meeting in Berlin?

From: Spencer Shepler <[email-masked]>
Date: Mon, 2 May 2016 16:18:24 +0000

Working Group scheduling has opened for Berlin.

>From the dates to know section of the meeting our request is due June 3rd....

2016-06-03 (Friday): Cut-off date for requests to schedule Working Group meetings

If we want to meet, I propose that we have a draft working group agenda pulled together by May 20th.

Therefore, please submit agenda items, etc. before then.  Also, if anyone has a proposal to change the decision date, please speak up.

Spencer

---

From: David Noveck <[email-masked]>
Date: Mon, 2 May 2016 13:15:38 -0400

> If we want to meet,

First of all, is there anyone who doesn't think we should meet in Berlin?

Please speak if that's your view.

> I propose that we have a draft working group agenda pulled together by
May 20th.

When do we actually need this to satisfy the IETF? Why isn't June 2-3 the
appropriate time?

> Therefore, please submit agenda items, etc. before then.

It's nice to have an accurate draft agenda but we have to remember that the
final agenda may
be different from that.

> Also, if anyone has a proposal to change the decision date, please speak
up.

I've already (sort of) made one proposal but I might as  well make another.

I propose that we decide ASAP about meeting and we build our agenda  based
on what people want to discuss closer to the date of the actual meeting.

On Mon, May 2, 2016 at 12:18 PM, Spencer Shepler <[email-masked]>
wrote:

> From the dates to know section of the meeting our request is due June 3rd
> ….
>
>
>
> Therefore, please submit agenda items, etc. before then.  Also, if anyone
> has a proposal to change the decision date, please speak up.
>
>
>
> Spencer
>
>
>
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>
>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 2 May 2016 15:26:33 -0400

> On May 2, 2016, at 12:18 PM, Spencer Shepler <[email-masked]> wrote:
> 
>  
> From the dates to know section of the meeting our request is due June 3rd….
>  

I can propose a number of topics related to NFS-over-RDMA.
Any or all of these would be appropriate for a f2f
discussion, depending on interest.

- progress report on RFC 5666bis and bidirectional
   RPC-over-RDMA, and review of final steps

- progress report on RFC 5667bis, which should be open by
   then, and discussion of direction for this work

- discussion of items related to RPC-over-RDMA Version One
   follow-on work, including:

   + RPC-over-RDMA Version Two
   + draft-dnoveck-nfsv4-rpcrdma-rtissues-00
   + draft-dnoveck-nfsv4-rpcrdma-xcharext-00
   + Priorities for work on optional features

- proposals related to pNFS block and NVMe/F

- proposals related to NFS-over-RDMA and remote persistent
   memory

> Also, if anyone has a proposal to change the decision date, please speak up.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sat, 7 May 2016 18:03:42 -0400

> Also, if anyone has a proposal to change the decision date,

I'm not sure what you mean when you refer to a "decision date".

As I understood your message you had referred to two possible dates:

   - Meeting requests are due June 3rd.  That is a decision date, but there
   is no point in proposing a change to it.  We have to consider that fixed.
   - The date of May 20th was mentioned as a target date to try to get a
   draft agenda together.  Chuck has already mentioned things he could talk
   about but he appears to be waiting for indications of interest from the
   working group, which makes sense if the goal is to have the best possible
   agenda. I will later respond to Chuck's list including things I would be
   interested in talking about and hearing about, but I don't understand why
   we need a draft agenda by this particular date or why it might be a basis
   for a "decision point".  Please clarify.

Regarding "if we want to meet", I've heard nobody in the working group
indicating any doubt about the desirability of meeting, except for Spencer
who, by framing it this way, treats this as an open question, for reasons
that I don't understand.

If Spencer, or anyone else thinks a meeting is not desirable, he should
explain why.

So far nobody has indicated an objection to meeting, so we should assume we
are meeting.  That way we can work on an agenda without artificial
deadlines or "decision points".  If people can't arrange travel, we should
be prepared for remote participation.

One thing that we should have before a June 2-3 decision point is time zone
information from remote participants outside Europe to help in scheduling
the session, if possible.  Note that CEST is 6 hours later than EDT and 9
hours later than PDT.

---

From: David Noveck <[email-masked]>
Date: Sat, 7 May 2016 18:07:55 -0400

I'm going to first respond to Chuck's list and then add a few items of my
own:

>   RPC-over-RDMA, and review of final steps.

In the past, when I've proposed discussing things like this, I've been
accused of "status-mongering".

Nevertheless, I think we could afford some time to keep the working group
up-to-date about the process of going from wg consensus to a published
RFC.  We need more transparency in this area.

BTW, v4.2 entered WGLC over a year ago, and I don't understand why this has
taken so long.

>   then, and discussion of direction for this work

I want this discussion to happen.  In particular we need working group
discussion of the RPC-over-RDMA implications/choices of READ_PLUS.

>   + RPC-over-RDMA Version Two

I agree that this should be discussed.

>    + draft-dnoveck-nfsv4-rpcrdma-rtissues-00

Will be able to talk about this.  There's a good chance, I'll also be able
to talk about a draft-dnoveck-nfsv4-rpcrdma-rtrext-00.  I think I have
until late June to submit this,
so there is a goo chance I'll be abl to tlk about it.

>   + draft-dnoveck-nfsv4-rpcrdma-xcharext-00

Will be able to talk about this.

>   + Priorities for work on optional features

This a useful discussion to have but I don't think we should expect to make
decisions in this area.

> - proposals related to pNFS block and NVMe/F

I definitely want to hear about this.

> - proposals related to NFS-over-RDMA and remote persistent

Not sure exactly what is going to be proposed but it sounds like an
interesting area.

Most of the things I would add to Chuck's list have to do with the NFSv4
extension area.

I think we need to close on a decision on the future of
draft-ietf-nfsv4-versioning and the related question of how it affects our
nfsv4 extension practices going forward.  There are a number of people with
different opinions in this area and the working group would be better off
 if we were able to move closer to agreement with regard to this area,
specially since, as Spencer pointed out during our conference call, getting
agreement on this could hold up adjusting the charter which is now
unfortunately out-of-date.

I have a mixture of items I can talk about and want to hear about.  I don't
expect people having much difficulty figuring out which is which:

   - I need to give a presentation following up on the comments that I got
   on the conference call.  While I'm prepared to make large parts of what is
   in the current document informational, there is a core of items that need
   to be standards-track, if only to contradict the existing standards track
   treatment of versioning which has no place for anything other than the
   minor version model.  As I've never heard anyone who is satisfied with the
   current model, I assume the working group wants some change and so we need
   to have a discussion that leads to progress in this area.
   - If there is anyone who favors the minor version model, we should give
   them an opportunity to argue for their position.
   - I think we need to hear from the authors of draft-ietf-nfsv4-umask an
   rft-ietf-nfsv4-xattrs about their plans to move their documents forward.
   - If there is anyone who has a relatively large extension in mind, I
   hope they can present an outline to help us decide how hard we should work
   to keep the minor version model still available.

During the discussion of draft-ietf-nfsv4-rpcrdma-biirection, it appeared
that there are a number of people who are interested in a level of
bidirection support beyond what is necessary to support nfsv4.x for 0 <= x
<=2.  I'd be interested in hearing from those people if possible,both
because of the inherent interest of their proposed features and also to
help start thinking about how we would deal with co-ordinating extensions
to multiple extensible protocols.

---

From: Christoph Hellwig <[email-masked]>
Date: Sun, 8 May 2016 09:49:35 +0200

> I definitely want to hear about this.

I've promised chuck a personal draft once the NVMe over Fabrics spec
and our reference implementation is published, which should be in
about a month.  I'd be happy to present this, especially that Berlin
is a short trip for me.

---

From: David Noveck <[email-masked]>
Date: Sun, 8 May 2016 07:27:07 -0400

> about a month.

It doesn't sound like you'll have much trouble meeting the draft submission
cutoff, which two months from now, on July 8.

> I'd be happy to present this, especially that Berlin
> is a short trip for me.

I'm going to try to arrange travel, to see this in person,  If I can't, it
is
possible that this will wind up being at 3AM EDT for me.

I'd like to get the travel issue resolved as soon as possible.
Unfortunately, that is made difficult when a working group co-chair is
making public statements about a future "decision point" regarding the
question of whether the working group will be meeting in Berlin.

This has unfortunately become something of an nfsv4wg tradition.  In
my opinion,
we are better off dropping it.  It is just not a good idea for the
working group
and one of its co-chairs to repeatedly struggle over the will-we-meet
question.
There are better uses for our time.

Spencer, the June 3, 11:59 UTC time is a deadline.  There is nothing
preventing the working group from deciding earlier that a meeting is
required, and a meeting is clearly required, as shown by the discussion so
far of prospective  talks. There is no need to wait for June 3, May 20, or
any other future date.  I suggest that you use the IETF Meeting Session
Request Too
<https://datatracker.ietf.org/cgi-bin/wg/wg_session_requester.cgi>l to
request a session for the working group as soon as possible.

BTW, the deadline for submission of working group draft agendas is July 8.

---

From: Christoph Hellwig <[email-masked]>
Date: Sun, 8 May 2016 14:00:01 +0200

> request a session for the working group as soon as possible.

Btw, after writing the previous mail I just noticed that I only return
to Europe on July 18th.  So I could only make it July 19-22.

---

From: David Noveck <[email-masked]>
Date: Sun, 8 May 2016 08:05:46 -0400

That needs to be taken into account.

Is there anyone else with date restrictions that should be taken note
of when scheduling the wg session(s)?

---

From: Chuck Lever <[email-masked]>
Date: Sun, 8 May 2016 15:45:25 -0400

> On May 8, 2016, at 7:27 AM, David Noveck <[email-masked]> wrote:
> 
> It doesn't sound like you'll have much trouble meeting the draft submission cutoff, which two months from now, on July 8.
> 
> I'm going to try to arrange travel, to see this in person,  If I can't, it is
> I'd like to get the travel issue resolved as soon as possible.  Unfortunately, that is made difficult when a working group co-chair is making public statements about a future "decision point" regarding the question of whether the working group will be meeting in Berlin.
> 
> This has unfortunately become something of an nfsv4wg tradition.  In my opinion, we are better off dropping it.  It is just not a good idea for the working group and one of its co-chairs to repeatedly struggle over the will-we-meet question.  There are better uses for our time.
> 
> Spencer, the June 3, 11:59 UTC time is a deadline.  There is nothing preventing the working group from deciding earlier that a meeting is required, and a meeting is clearly required, as shown by the discussion so far of prospective  talks. There is no need to wait for June 3, May 20, or any other future date.  I suggest that you use the IETF Meeting Session Request Tool to request a session for the working group as soon as possible.

My experience has been the sooner that a go/no-go decision
can be made, the better. This helps immensely with travel
arrangements.

Right now, my plan is to attend in person if the nfsv4 WG
is going to meet.

--
Chuck Lever

---

From: Chuck Lever <[email-masked]>
Date: Sun, 8 May 2016 15:48:51 -0400

> On May 7, 2016, at 6:07 PM, David Noveck <[email-masked]> wrote:
> 
> I'm going to first respond to Chuck's list and then add a few items of my own: 
> 
> In the past, when I've proposed discussing things like this, I've been accused of "status-mongering".
> 
> Nevertheless, I think we could afford some time to keep the working group up-to-date about the process of going from wg consensus to a published RFC.  We need more transparency in this area.
> 
> BTW, v4.2 entered WGLC over a year ago, and I don't understand why this has taken so long.
> 
> I want this discussion to happen.  In particular we need working group discussion of the RPC-over-RDMA implications/choices of READ_PLUS.
> 
> Will be able to talk about this.  There's a good chance, I'll also be able to talk about a draft-dnoveck-nfsv4-rpcrdma-rtrext-00.  I think I have until late June to submit this,
> This a useful discussion to have but I don't think we should expect to make decisions in this area.
> 

Christoph's suggested a simple binding between
pNFS block/SCSI layout and NVMe/F. He's mentioned
that he is physically available later in the week.
I hope we can accommodate him.

> Not sure exactly what is going to be proposed but it sounds like an interesting area.

I was thinking that Tom might take the opportunity to
summarize his current RDMA Commit personal draft, provide
some context, and discuss some implications of his
proposed Push mode on NFS/RDMA.

There is a good portion of Working Group members who
have not been exposed to this work via SNIA or the
other arenas where Tom has been presenting this work.

> Most of the things I would add to Chuck's list have to do with the NFSv4 extension area.
> 
> I think we need to close on a decision on the future of draft-ietf-nfsv4-versioning and the related question of how it affects our nfsv4 extension practices going forward.  There are a number of people with different opinions in this area and the working group would be better off  if we were able to move closer to agreement with regard to this area, specially since, as Spencer pointed out during our conference call, getting agreement on this could hold up adjusting the charter which is now unfortunately out-of-date.  
> 
> I have a mixture of items I can talk about and want to hear about.  I don't expect people having much difficulty figuring out which is which:
> 	• I need to give a presentation following up on the comments that I got on the conference call.  While I'm prepared to make large parts of what is in the current document informational, there is a core of items that need to be standards-track, if only to contradict the existing standards track treatment of versioning which has no place for anything other than the minor version model.  As I've never heard anyone who is satisfied with the current model, I assume the working group wants some change and so we need to have a discussion that leads to progress in this area.
> 	• If there is anyone who favors the minor version model, we should give them an opportunity to argue for their position.
> 	• I think we need to hear from the authors of draft-ietf-nfsv4-umask an rft-ietf-nfsv4-xattrs about their plans to move their documents forward.
> 	• If there is anyone who has a relatively large extension in mind, I hope they can present an outline to help us decide how hard we should work to keep the minor version model still available.

I agree some or all of these should be part of the
Berlin meeting agenda.

> During the discussion of draft-ietf-nfsv4-rpcrdma-biirection, it appeared that there are a number of people who are interested in a level of bidirection support beyond what is necessary to support nfsv4.x for 0 <= x <=2.  I'd be interested in hearing from those people if possible,both because of the inherent interest of their proposed features and also to help start thinking about how we would deal with co-ordinating extensions to multiple extensible protocols. 

If you are talking about allowing chunks in the backward
direction, I don't know of any solid requirement or
proposal in this area. The desire was simply to prevent
current RDMA-related I-Ds from disallowing a future
protocol that might want to use chunks.

Did you mean more than that?

(My only concern here is that the agenda seems to be
filling already; this might be a topic that can be moved
to a later meeting, because it is currently rather
nebulous AFAICT).

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Sun, 8 May 2016 20:27:25 -0400

> proposal in this area.

I don't either but I was basically asking anyone who does
have a proposal to speak about it.  Actually I wan't expecting
a solid proposal but hoped for a non-gaseous non-diaphanous
one.

> The desire was simply to prevent

If that's all it is, then there is no point in taking up
time in Berlin.

> Did you mean more than that?

Not much more.

> to a later meeting, because it is currently rather

OK with me.

On Sun, May 8, 2016 at 3:48 PM, Chuck Lever <[email-masked]> wrote:

> > Nevertheless, I think we could afford some time to keep the working
> group up-to-date about the process of going from wg consensus to a
> published RFC.  We need more transparency in this area.
> >
> > Will be able to talk about this.  There's a good chance, I'll also be
> able to talk about a draft-dnoveck-nfsv4-rpcrdma-rtrext-00.  I think I have
> > I have a mixture of items I can talk about and want to hear about.  I
> don't expect people having much difficulty figuring out which is which:
> >       • I need to give a presentation following up on the comments that
> I got on the conference call.  While I'm prepared to make large parts of
> what is in the current document informational, there is a core of items
> that need to be standards-track, if only to contradict the existing
> standards track treatment of versioning which has no place for anything
> other than the minor version model.  As I've never heard anyone who is
> satisfied with the current model, I assume the working group wants some
> change and so we need to have a discussion that leads to progress in this
> area.
> >       • If there is anyone who favors the minor version model, we should
> give them an opportunity to argue for their position.
> >       • I think we need to hear from the authors of
> draft-ietf-nfsv4-umask an rft-ietf-nfsv4-xattrs about their plans to move
> their documents forward.
> >       • If there is anyone who has a relatively large extension in mind,
> I hope they can present an outline to help us decide how hard we should
> work to keep the minor version model still available.
>
> > During the discussion of draft-ietf-nfsv4-rpcrdma-biirection, it
> appeared that there are a number of people who are interested in a level of