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.
- [nfsv4] Proposed charter changes (with updates) David Noveck
- Re: [nfsv4] Proposed charter changes (with update… Magnus Westerlund
- Re: [nfsv4] Proposed charter changes (with update… Tom Talpey
- Re: [nfsv4] Proposed charter changes (with update… Magnus Westerlund
- Re: [nfsv4] Proposed charter changes (with update… Tom Talpey
- Re: [nfsv4] Proposed charter changes (with update… David Noveck
- Re: [nfsv4] Proposed charter changes (with update… Tom Talpey
- Re: [nfsv4] Proposed charter changes (with update… David Noveck
- Re: [nfsv4] Proposed charter changes (with update… David Noveck
- Re: [nfsv4] Proposed charter changes (with update… Magnus Westerlund
- Re: [nfsv4] Proposed charter changes (with update… Lars Eggert
- Re: [nfsv4] Proposed charter changes (with update… Tom Talpey
- Re: [nfsv4] Proposed charter changes (with update… David Noveck
- Re: [nfsv4] Proposed charter changes (with update… Tom Talpey