Re: [nfsv4] NFSv4 WG meeting in Berlin?

Chuck Lever <chuck.lever@oracle.com> Sun, 08 May 2016 19:48 UTC

Return-Path: <chuck.lever@oracle.com>
X-Original-To: nfsv4@ietfa.amsl.com
Delivered-To: nfsv4@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1022C12D117 for <nfsv4@ietfa.amsl.com>; Sun, 8 May 2016 12:48:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.216
X-Spam-Level:
X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpGQRXBhr0ei for <nfsv4@ietfa.amsl.com>; Sun, 8 May 2016 12:48:57 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C27712D0BC for <nfsv4@ietf.org>; Sun, 8 May 2016 12:48:57 -0700 (PDT)
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u48Jmt7K024076 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 8 May 2016 19:48:56 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u48JmtBR001485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 May 2016 19:48:55 GMT
Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u48Jmqkc014026; Sun, 8 May 2016 19:48:54 GMT
Received: from anon-dhcp-171.1015granger.net (/68.46.169.226) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 08 May 2016 12:48:52 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <CADaq8jdpiPSWKbr8SVYXBo0yK9mXinJBakQrhya4FBPX5J2Z5Q@mail.gmail.com>
Date: Sun, 08 May 2016 15:48:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8EA3587B-B2DB-4975-8A88-C7C28024E3A6@oracle.com>
References: <CO2PR03MB2280CF567A3E019FC230CAF8C7790@CO2PR03MB2280.namprd03.prod.outlook.com> <4A5DDEA4-8B52-4D4B-978E-A6301D54C7FF@oracle.com> <CADaq8jdpiPSWKbr8SVYXBo0yK9mXinJBakQrhya4FBPX5J2Z5Q@mail.gmail.com>
To: David Noveck <davenoveck@gmail.com>
X-Mailer: Apple Mail (2.3124)
X-Source-IP: userv0022.oracle.com [156.151.31.74]
Archived-At: <http://mailarchive.ietf.org/arch/msg/nfsv4/h46zf7I4prGe-nB4E2uSEL0C7yI>
Cc: "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: [nfsv4] NFSv4 WG meeting in Berlin?
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NFSv4 Working Group <nfsv4.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nfsv4/>
List-Post: <mailto:nfsv4@ietf.org>
List-Help: <mailto:nfsv4-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nfsv4>, <mailto:nfsv4-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 May 2016 19:48:59 -0000

> On May 7, 2016, at 6:07 PM, David Noveck <davenoveck@gmail.com> 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 <chuck.lever@oracle.com> wrote:
> 
> > On May 2, 2016, at 12:18 PM, Spencer Shepler <sshepler@microsoft.com> 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
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 

--
Chuck Lever