Re: [nfsv4] Proposed charter changes (with updates)

Tom Talpey <tom@talpey.com> Fri, 05 June 2020 13:19 UTC

Return-Path: <tom@talpey.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 2475A3A096E for <nfsv4@ietfa.amsl.com>; Fri, 5 Jun 2020 06:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 oZmHXq9aHDYI for <nfsv4@ietfa.amsl.com>; Fri, 5 Jun 2020 06:19:14 -0700 (PDT)
Received: from p3plsmtpa06-06.prod.phx3.secureserver.net (p3plsmtpa06-06.prod.phx3.secureserver.net [173.201.192.107]) (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 4C00D3A0A63 for <nfsv4@ietf.org>; Fri, 5 Jun 2020 06:19:14 -0700 (PDT)
Received: from [192.168.0.78] ([24.218.182.144]) by :SMTPAUTH: with ESMTPSA id hCFcjRMuD4ZBJhCFdjekwn; Fri, 05 Jun 2020 06:19:13 -0700
X-CMAE-Analysis: v=2.3 cv=cICeTWWN c=1 sm=1 tr=0 a=ugQcCzLIhEHbLaAUV45L0A==:117 a=ugQcCzLIhEHbLaAUV45L0A==:17 a=IkcTkHD0fZMA:10 a=SEc3moZ4AAAA:8 a=48vgC7mUAAAA:8 a=t3tta_b7Ymsf6192dr4A:9 a=QEXdDO2ut3YA:10 a=5oRCH6oROnRZc2VpWJZ3:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: tom@talpey.com
To: David Noveck <davenoveck@gmail.com>
Cc: NFSv4 <nfsv4@ietf.org>, Magnus Westerlund <magnus.westerlund@ericsson.com>, Lars Eggert <lars@eggert.org>
References: <CADaq8jfgREzCvi=rZk4tEg8uLnA2mDeeQF0drC9kWrL11JH4Sg@mail.gmail.com> <4a88fddce55d78d1b64fc0a4f6d71d910bb7ada2.camel@ericsson.com> <MN2PR00MB068665937287B4AF541F8A3EA0880@MN2PR00MB0686.namprd00.prod.outlook.com> <6d9f4bb4c0c0661841f38940fe0b4a71893764fa.camel@ericsson.com> <MN2PR00MB06861C2E6C2982BC2C39A3FAA0880@MN2PR00MB0686.namprd00.prod.outlook.com> <CADaq8jcQpxAYqWk3RigviVFq4rauMx9Q8QPEQKf+UQWmm2hbJw@mail.gmail.com> <CADaq8jfAz1_hck2txuPt8jmCGjysknWfrk_9SaPPWjEGQZkDyw@mail.gmail.com> <019be9c15328961d7950add1b2a191a7e9bf3b89.camel@ericsson.com> <1EE87C51-9D97-4AB5-AEFD-962298FA8AC7@eggert.org> <005dbafa-cd3d-5de1-2b10-7edaf2e57205@talpey.com> <CADaq8jfzeG3WHgjnHrVrD_4r30xM3KOCMKAUZF3t997ngyEWnQ@mail.gmail.com>
From: Tom Talpey <tom@talpey.com>
Message-ID: <e7cb7fc4-8fdb-363a-a335-da71745b00f9@talpey.com>
Date: Fri, 05 Jun 2020 09:19:12 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <CADaq8jfzeG3WHgjnHrVrD_4r30xM3KOCMKAUZF3t997ngyEWnQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-CMAE-Envelope: MS4wfKwC9cCk4pYzxgixn95kKsJ6egLbyW25qTmwr2OZqVwB+KfgyRbDY1HB8IcKtzbt/X7TuPEt+a64+nn85vCQz+Xrp7Hjd/bh73bhR2Hfm5X4XPgvjXeA f66kOjakBJawtsRZG4JuVMzKebSLzhl7EMaARx4SswVfAKufvdSx1bRAltmlS7nJRsqoqcdea6On54a1NtSL1ErlMFRCxKMc0OGwHMD7o9TOzfeIKwZx5v1D krObGSECMsOh6SkQpwzeG9S+vedmCWcG9hqws329/+8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/dQ5vdqDcxsSynlEPltY9n4ON3aQ>
Subject: Re: [nfsv4] Proposed charter changes (with updates)
X-BeenThere: nfsv4@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 05 Jun 2020 13:19:23 -0000

On 6/5/2020 9:03 AM, David Noveck wrote:
> 
> 
> On Fri, Jun 5, 2020 at 8:15 AM Tom Talpey <tom@talpey.com 
> <mailto:tom@talpey.com>> wrote:
> 
>     On 6/5/2020 3:25 AM, Lars Eggert wrote:
>      > Hi,
>      >
>      > On 2020-6-5, at 10:23, Magnus Westerlund
>     <magnus.westerlund=40ericsson.com@dmarc.ietf.org
>     <mailto:40ericsson.com@dmarc.ietf.org>> wrote:
>      >> For that reason I would recommend that one work through the
>     technical proposal
>      >> to better understand what desired propoerties of RDMA over QUIC
>     has, as well as
>      >> what is required to realize those from QUIC. Then one can likely
>     make a good
>      >> decision if that work should be done in QUIC WG or in this or
>     another WG.
>      >
>      > +1
>      >
>      > An initial individual draft would be very useful in triaging
>     where the best place for this work would be.
> 
>     So, to be clear I was describing a process for a potential
>     NFSv4-over-QUIC binding, not an RDMA-over-QUIC one. 
> 
> 
> That would probably take the form of an extension to RPC, updating RFC 
> 5531, with no change to QUIC itself anticipated.  Unless I'm missing 
> something, that could be done even under the current charter, although 
> I'm cc-ing Lars to make sure he is aware of the possibility of us doing 
> this.

The NFSv4 WG has already published an Upper Layer Binding ("ULB") for
various dialects of NFS atop RPC-over-RDMA, so yes, I agree.

However, with a new transport, in my opinion, there is always the
possibility of finding something "missing", for example, the current
Push Mode extension for RDMA. It's this latter aspect in which I
strongly believe the upper layer, e.g. NFSv4, can add value.

>     Although,
>     I have been thinking about both.
> 
> Apparently, Magnus read your mind.   I'm not sure how I feel about 
> having AD's with that capability :-)
> 
>     I'd like to get the RDMA Push Mode extension draft process
>     through the knothole before considering the next one. :-)
> 
> 
> I hope "through the knothole" means waiting for IESG approval.   Waiting 
> for publication as an RFC has lately become a process of unbounded duration.

Achieving IESG approval, yes. That's why I added the word "process".
Once approved, we can start the actual work.

> I think you are the right person to do the individual draft for 
> RDMA-over-QUIC and hope that you would be interested in doing it, when 
> the time is ripe.
> 
> With regard to RPC-over-QUIC, I'd be glad if you are interested in doing 
> this, but there are a number of people that can participate so it would 
> not take all that much of your time.  It is interesting to the working 
> group primarily because of its security implications.

I'm flattered, and thanks. I'm not unique in having thought about it
though. Earlier, it was clear that standardizing a base QUIC protocol
was needed before considering this. As QUIC moves forward, I'd be hopeful
that it makes sense to explore RDMA.

Tom.