Re: [nfsv4] Meetings in July or After

Chuck Lever <> Mon, 08 June 2020 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C9373A0C79 for <>; Mon, 8 Jun 2020 08:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Umyw5Qzhc5GY for <>; Mon, 8 Jun 2020 08:10:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5F7F3A0916 for <>; Mon, 8 Jun 2020 08:10:51 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id 058F8QsA153345; Mon, 8 Jun 2020 15:10:47 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=corp-2020-01-29; bh=Pssy7ROmhTOKL5er523bQ4pnAU1QkpfmC5OS4uoObsc=; b=pNJnz2xhRLDmT0BBiUmJpJJKaek5dMHXDpxOh8TU2MRWXMGuGba+cFg/HbN5MlnYXTKw 2sP9k1byQPgZgtzrTjoplYhEUv5WJObtGxAtj3plLVSPm+3gyA+87H0A81HtWFTtYJWv wyNnVf/V+Ft+pYm7A31zPrc0d5bWwiYkAhIBDsDuAxb5q33w1lB/HSRZ16Dkl7Z/58x2 2U57Vnw3drwVGQnq1KzHe5hgdpeNpX+yROYSJwnVzngbaw11D2ZxfChpadRTcT7YmTAh pB/c8p3FNFY1T4d4HeXpOGkuUpnBCNZMVNA6Bf4VhLIi1kW5s+3r0QdaK+zybq6nQm+o Fg==
Received: from ( []) by with ESMTP id 31g2jqydyp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 08 Jun 2020 15:10:47 +0000
Received: from pps.filterd ( []) by ( with SMTP id 058F8LMu061481; Mon, 8 Jun 2020 15:08:46 GMT
Received: from ( []) by with ESMTP id 31gmwq2huw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Jun 2020 15:08:46 +0000
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id 058F8jPq024007; Mon, 8 Jun 2020 15:08:45 GMT
Received: from (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Jun 2020 08:08:45 -0700
From: Chuck Lever <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6DFDB1FD-1AB1-46B0-B7F3-A25F7844C40E"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 08 Jun 2020 11:08:43 -0400
In-Reply-To: <>
Cc: NFSv4 <>, Magnus Westerlund <>
To: David Noveck <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.14)
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9645 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 spamscore=0 adultscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 malwarescore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080113
X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9645 signatures=668680
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 impostorscore=0 cotscore=-2147483648 priorityscore=1501 spamscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 mlxlogscore=999 malwarescore=0 mlxscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006080113
Archived-At: <>
Subject: Re: [nfsv4] Meetings in July or After
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NFSv4 Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Jun 2020 15:10:54 -0000

Hi Dave-

> On Jun 8, 2020, at 8:50 AM, David Noveck <> wrote:
> We've had some input from Magnus regarding our near-term meeting plans.  It appears Magnus will be on vacation in August and July 13-17.  I gather that a virtual meeting in the last two weeks of July is a no-go.
> As a result, I am proposing that we schedule one two-hour virtual interim in the second week of July (7/6-7/10) .  To help give presenters time to prepare, it should be later in the week.  If anyone has a problem with a meeting 7/9 at 9AM PDT == Noon EDT == 1600 UTC == 1800 CEST, let us know quickly.
> As far as priority for meeting time:
> First priority will be for it's relating to the current working group agenda, i. e. Things with current wg documents or milestones plus things related to rfc5661bis.  I need to hear from other people about their plans but my expectation is that this stuff is unlikely to take more than an hour. For my thoughts about use of this time, see below
> Second priority will be for follow-up discussion of new work proposals made at the previous virtual meeting.  I'll have some suggestions below about how we might use time.
> Third priority will be for other new work proposals.  Unsure if there will be any time for these so I expect that any of these that don't fit will be deferred to a later virtual interim to be scheduled in September.
> Regarding items in the current work category:
> I expect to take about about one half-hour to discuss things related to rfc5661bis.  
> For internationalization, I want to move to a working group document and need review within the group.  Review outside the group resulted in Nico telling me I was "on the right track"  and should write a totally different document😊.
> I expect dicussion of our security choices to take the majority of this time.   I had expected to submit draft-dnoveck-nfsv4-internationalization in May, but it has slipped to around May 45th😞 
> Won;t be much to say about rfc5661bis.  Has been on hold waiting for sequii to turn into an RFC and RFC editing is kind of stuck right now😖
> I anticipate us hearing about pNFS/NVMe from David and/or Sorin.  David indicated to me that they had reconnected with Christoph and expected to clarify things in June.   I think we need an update on that process.  Not sure whether we will dicuss a document submitted in June or expectations regarding a document to be submitted later.   In either case, we will want to set a realistic milestone for this work.
> I don't expect us to hear anything new about integrity measurement but will schedule someting if Chuck expects to have a useful update.
There has been some progress, but nothing I can discuss in a public setting yet.
> I am anticipating some sort of update for rpc-over-RDMA version two and am assuming, for planning purposes, about ten minutes.  I need an update from check in the next few weeks so I can put an agenda together.
You mentioned a while back you had some input for me regarding restructuring of the header types, so I stopped working on that document temporarily, but that has turned into a lengthy hiatus. I can restart work with what I have and present that during the interim meeting, unless you have a different thought.

> With regard to follow-up discussion from new-work discussions last time:

Should there be an item in this category to discuss the RDMA Flush document?

> I've decided that rfc5661bis-related working group documents (draft-ietf-nfs4-internationlization, draft-ietf-nfsv4-security-needs, draft-ietf-nfsv4-security, draft-ietf-rfc5661bis) will be managed using github.   Hope to get Chuck's help on a presentation about how this will affect the writing and review process for these documents.
> We have anther opportunity to hear from Sorin about data reduction attributes.  To make the time useful, we need a more substantial I-D.  If one cannot be made available in June, suggest moving this discussion into the September meeting.
> I think there is a need for some sort of followup discussion regarding the directory operation performance issues discussed last time.   Due to lack of interest, I'm dropping the idea of (non-striped) directory layouts.   
> With regard to directory delegation, it appears that a significant issue in is non-implementation is Chuck's belief (possibly shared by others) that any change to a directory, requires refetching the entire directory.  I think this is incorrect and makes directory notification essentially useless.   We might resolve this on the mailing list and I will send an email about the issue in the next few weeks.   If there needs to be further discussion of this issue, we will need 5-10 minutes of meeting time.     
> I want to follow up on Chuck's speculation of protocol help for rm -r and would also like to discuss similar possible extensions usable for build apllications.
> With regard to the effect of access-based enumeration on directory caching , we will want to follow up sufficiently to clarify what we will want to say (evenually) in rfc5661bis.

Perhaps we could move this topic to one or two separate design calls that focus specifically on collecting and refining ideas about directory scalability. A separate series of calls would allow more time for discussion -- and could begin sooner than July.

Chuck Lever