Re: [nfsv4] Meetings in July or After

[Chuck Lever <[e-mail]>]

Hi Dave-

> On Jun 8, 2020, at 8:50 AM, David Noveck <[e-mail]> 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