Re: [nfsv4] FYI on an update to "RDMA Flush" I-D and IETF107

David Noveck <davenoveck@gmail.com> Mon, 02 March 2020 17:57 UTC

Return-Path: <davenoveck@gmail.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 5FC563A0DBE; Mon, 2 Mar 2020 09:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 X-tWC5GUvDTH; Mon, 2 Mar 2020 09:57:33 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FDE3A0DBD; Mon, 2 Mar 2020 09:57:33 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id c7so873320edu.2; Mon, 02 Mar 2020 09:57:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jtyqjd019T8Rcf0Z0co/RNlenpi6W9uQVtJcW6ON+74=; b=HTH5qcmoKIiQ3X0eQCWcK3bv9aJxVWN9pOTVHHFOfZF5pi72JT75IssYA8ioRrwSTG oaXuJStrg6U0O3RtXS9ZNR7dpmoTFikmMk+xvoFObY2nx2LKD1hsSTM+w3cBaXwDTqnt Dy2VpTNGiMjm+hPHk5Loa+/+K8nftQ7cGG36R8j5LP6QJP9Ar2I0LYaONLdvaBzPaDXZ U4nRl0d3b8289k+8aTLfdtqQ54Kovci7CXERZG9LEOFi0atv63ofHjp3fB1UmojOK1tE NMg2THYgqO6M/srbGvHJDZ5wnSoiHMRPk3de4AULfkC+mvpCUEby0Smf2heAYu4O/GMf SJQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jtyqjd019T8Rcf0Z0co/RNlenpi6W9uQVtJcW6ON+74=; b=rMm1HxxECnO+GXcwo8e1fa6pzMc08B5oU+6fyqyzZXAYy7oLWwMMP5bpVbL86AH+3S KUcbrVrsUNeJgtIqhh5j9bWzZsqE9Z7iCYXq+FKBb7wpj7WkGxuZoYdt5ghIUZpZRs5R szuw1X8wn1R1T/IZz9JdyxwOZjL9AxmTD5YjUnRxq+6fI0zkxKoCSNpSWbG8JlhneSEK MpSgCEO8NRcIZwcvFFgnJos8ejbsBxRF+2G2lhw3mAQmKZd1YYA+yr7QR9Wq64DEFA2L WR0tUxgpXsGr2clh3ZeAI5ZYysJTMsn9AGGVFW2WamKfmN6dGMHxXLtdUpI83h4FRr2U CpLQ==
X-Gm-Message-State: ANhLgQ2p4aM5tSADHvLM5Wsnp+ieQdIVhVONW6/RzA0E9rsQMTpTMdS0 VFXfaCK8ntABaNclJPBe3MJGPZ9W2a4muVfXgv1Tjg==
X-Google-Smtp-Source: ADFU+vs829VfsXRki0VTTRr8bgVT+DFq4bNl5RBmKnovKzFrP8ji7k96OOdTIkx9T5qextPOFdggPYSKLR1n2nGkzqU=
X-Received: by 2002:a17:906:76c6:: with SMTP id q6mr534473ejn.176.1583171851874; Mon, 02 Mar 2020 09:57:31 -0800 (PST)
MIME-Version: 1.0
References: <03bf747f-b255-677d-1e6c-900accac463c@talpey.com> <36BC4F65-C6E0-4030-B650-52AB209E2804@oracle.com>
In-Reply-To: <36BC4F65-C6E0-4030-B650-52AB209E2804@oracle.com>
From: David Noveck <davenoveck@gmail.com>
Date: Mon, 02 Mar 2020 12:57:20 -0500
Message-ID: <CADaq8jcKUGxxpf2BVfNg=V8PwC22Px2viQiGgnPkfVBD-35DuA@mail.gmail.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Tom Talpey <tom@talpey.com>, nfsv4-chairs <nfsv4-chairs@ietf.org>, NFSv4 <nfsv4@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d97742059fe2eba2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/nfsv4/NHVWiHF2FTlcDRVB4Yd7eI83Rns>
Subject: Re: [nfsv4] FYI on an update to "RDMA Flush" I-D and IETF107
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: Mon, 02 Mar 2020 17:57:36 -0000

Assuming Tom is OK with making this presentation, I will add it to the next
iteration of the agenda.

To keep ten minutes available we will have to enforce time discipline for
existing talks.

If Tom does not provide a short description by EOD tomorrow, I will do my
best to boil down Chuck's reasonable list into something that fits the
existing agenda format.

On Mon, Mar 2, 2020 at 11:36 AM Chuck Lever <chuck.lever@oracle.com> wrote:

> [ Cc: corrected ]
>
> > On Mar 1, 2020, at 12:41 PM, Tom Talpey <tom@talpey.com> wrote:
> >
> > A couple of things FYI.
> >
> > - I am updating the draft-talpey-rdma-commit document* in
> > advance of IETF107. This is an iWARP extension in support of
> > RDMA access to persistent memory, although it is somewhat more
> > general than simply pmem. There is a parallel effort in IBTA.
> >
> > - Because there is no longer an RDDP working group, one option
> > discussed in the past with several WG chairs and Transport ADs was
> > to move this forward in the NFSv4 WG. With the new chair situation,
> > and the document republication, it may be worthwhile to discuss
> > this again. I believe there is good merit to the idea.
> >
> > - I plan to attend IETF107 NFSv4 WG meeting, but can only be
> > there one day. I hope to discuss this further there. If you
> > would like me to say something as part of the agenda, I am
> > happy to do so.
> >
> > Tom.
> >
> >
> > * https://datatracker.ietf.org/doc/draft-talpey-rdma-commit/
>
> The final IETF 107 session agenda has been published, and now both
> nfsv4 WG sessions are planned for Thursday afternoon.
>
> I propose the addition of a 10-minute session led by Tom, if there
> is room on the nfsv4 agenda, to discuss the following matters:
>
> - A review of the material for those unfamiliar with RDMA Flush
> - Whether this work falls in the current WG charter
> - Whether the I-D should be adopted as an nfsv4 WG document
> - Whether a milestone is needed
> - Whether this is a one-time proposal, or if we are agreeing
>   that until there is another IETF home for RDMA-related documents,
>   the nfsv4 WG should act as shepherd for such work.
>
>
> --
> Chuck Lever
>
>
>
>