Re: [nfsv4] NFSv4 WG meeting in Berlin?

[David Noveck <[e-mail]>]

> If you are talking about allowing chunks in the backward
> direction, I don't know of any solid requirement or
> 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
> current RDMA-related I-Ds from disallowing a future
> protocol that might want to use chunks.

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.

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

OK with me.

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

>
> > On May 7, 2016, at 6:07 PM, David Noveck <[e-mail]> wrote:
> >
> > I'm going to first respond to Chuck's list and then add a few items of
> my own:
> >
> > > - progress report on RFC 5666bis and bidirectional
> > >   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.
> >
> > > - progress report on RFC 5667bis, which should be open by
> > >   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.
> >
> > > - discussion of items related to RPC-over-RDMA Version One
> > >   follow-on work, including:
> >
> > >   + 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.
>
> 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.
>
>
> >
> > > - proposals related to NFS-over-RDMA and remote persistent
> > >   memory
> >
> > 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).
>
>
> > On Mon, May 2, 2016 at 3:26 PM, Chuck Lever <[e-mail]>
> wrote:
> >
> > > On May 2, 2016, at 12:18 PM, Spencer Shepler <[e-mail]>
> wrote:
> > >
> > >
> > > 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.
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > nfsv4 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> >
>
> --
> Chuck Lever
>
>
>
>