Re: [nfsv4] Meetings in July or After

[David Noveck <[e-mail]>]

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.
   - 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.

With regad to folow-up discussion from new-work discussions last time:

   - 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.




On Sat, Jun 6, 2020, 7:17 AM David Noveck <[e-mail]> wrote:

> It has been decided that IETF 108 will be virtual-only.  The good thing
> about that is that it would allow wider participation, being cheaper and
> safer than a trip to Madrid. There will be a fee, but it is much smaller
> than onsite fees have been and should not pose an obstacle for most people.
>
> What is likely to pose an obstacle is that it appears to have been decided
> that virtual Madrid, will, like actual Madrid, be in CEST. This mean that
> the latest 50-minute session will start at around 1600 CEST = 7AM PDT.  A
> 100-minute session would start even earlier.  Both of these are likely to
> be difficult to schedule so I think we will wind up with one or more
> virtual interim nfsv4wg meetings.
>
> Meetings before the week of IETF 108 make sense but I'm not sure they will
> be allowed. Meetings in the weeks after IETF 108 wind up conflicting with
> August vacations but I'm not sure if that is all that important in present
> circumstances.
>
> I'd like to get input from the working group about:
>
>    - Preferences for meeting dates and times including discussion of
>    dates to avoid.
>
>
>    - Information about what you want to hear discussed and and what you
>    are topcis you are willing to present about or lead a focused discussion
>    of.   Although I'm not clear about meeting numbers and format, I think it
>    makes sense for us have coverage of both current working group items and
>    new ideas as well.
>
> I'll be sending out my own ideas on things to discuss next week.   If we
> don't want a meeting slot within IETF108 proper, as I believe is the case,
> we don't have to worry about the 6/12 session request cutoff.   Still, I'd
> like us to get a clear idea about this meeting cycle relatively quickly so
> I'd aprreciate it we had people's input on topics within the next few weeks
>
>
>
>