Re: Additional WG chair and the WG future

Hi Magnus-

I recognize that this is a difficult topic to bring up.


> On Oct 25, 2019, at 3:39 AM, Magnus Westerlund <[email protected]> wrote:
> 
> NFSv4 WG,
> 
> I am well aware of the frustration over the lack of progress in the WG. One of
> the issues has been lack of WG chair activities in progressing and managing the
> work items. As a first step to address that I want to recruit an additional WG
> chair for the WG. Although that is not the only issue, it is one that will have
> to be addressed directly.
> 
> Anyone interested in becoming a WG chair please contact me. I will not make a
> decision within the next two weeks to allow people some time to seek support in
> their organizations if they are considering taking on the role. I will solicit 
> persons outside of the WG also, as I feel it is more important that we get
> someone that has time to devote to run to processes, than necessary deep
> technical knowledge of NFS. That the other chairs and the WG participants can
> provide. 
> 
> Secondly, considering that the WG have a very small number of active
> participants, and beyond these few there appears to be little energy.

However, it also needs to be said that the glacial WG process has been
one thing that has turned away potential WG participants I've spoken
with. Once the process issues are addressed, we might find that the WG
becomes more healthy and energetic.


> I am deeply worried about the breadth of review this work gets.

That's fair, but consider that this is a problem for any small WG.
Does the IESG have a plan for ensuring broader document review in
general?


> I think it is
> important the WG focus on the most important work to finish up. And I seriously
> think we need to consider if the right action is to close the WG, soon but in a
> controlled fashion. Other WGs have done this in the past. The IETF has
> procedures for maintenance and handling errata for existing specifications
> beyond the WG active life. 
> 
> So this is a heads up to the WG, that several things will have to improve in the
> WG if it is to go one any longer time. I know that in Montreal there discussion
> of new work. But, as the situation stands I am extremely hesitant to add any new
> milestones. Instead we need to show that the work currently taken on is dealt
> with. If the WG wants to reprioritize existing work that can also improve the
> situation. 
> 
> - Successful recruitment of a WG chair.
> - Identification of what work is crucial to complete. 
> - Good progress on the main items with both active editors and reviewers. 
> 
> If the above is shown in the next 6 months and there are still work the WG is
> interested in then we can discuss adding new work.

Work that is crucial to complete:

Aside from the work on RFC 5661, there are existing milestones that
haven't been met or are unlikely to be met.

Date            Milestone 
Dec 2019	Submit final document defining RPC-over-RDMA Version 2 (as Proposed Standard)
Sep 2019	Submit final document describing pNFS RDMA Layout (as Proposed Standard)
Jun 2019	Submit final document describing CM private data convention for RPC-over-RDMA version 1 (Informational)

RPC-over-RDMA Version 2, as discussed in Montreal, has two
significant pieces of work remaining: support for host
authentication, and enhancements to its credit management mechanism.
Given the slow progress we've seen in WG process, it's not likely
it will be ready by December, even if we had closure on the
technical issues tomorrow.

The pNFS RDMA layout type work is highly desirable, but is currently
inactive, and its milestone data has already passed.

The CM private data convention milestone has also passed.

There is currently no milestone for RPC-on-TLS. This work has public
exposure, active authors, and active prototyping. In Montreal we
agreed to add a milestone for this, and I believe at this point we
have no choice but to add it.

There is no milestone for two current Working Group documents:
delstid and integrity-measurement. I think we should strive to
complete this work before a putative WG close down. IIRC there was
consensus in Montreal to add milestones for these. integrity-
measurement has an active author and is ready for WGLC, so there is
little WG effort needed to get it published.

Given the changes you're looking for and the amount of known work
there is left to do (rfc5661bis, and rpc-tls, at least) I think 6
months is aggressive... the bis, at least, is probably a multi-year
effort by itself.


NFS seems to have renewed relevance in cloud environments, thus
we certainly have been considering new work in this area. For
example:

- Even as we proposed RPC-on-TLS there have been complaints about
the known weaknesses in the TLS host authentication model.

- As QUIC matures and moves in to replace TCP, we will need to
respond with standards work to enable RPC on QUIC.

- We might want to consider supporting global authentication schemes
like OAuth to replace AUTH_SYS, which is still a widely-used yet
obsolete authentication scheme.

- NFS has very well-known performance weaknesses when it comes to
managing directory metadata. We have, in the past, considered
delegation to improve cache effectiveness, pNFS striping techniques
to increase throughput, and user space parallelism to help deal with
these weaknesses. It might be time to focus on protocol extensions
to help in this area.

A discussion of open technical issues and their stakeholders should
be part of the conversation about WG close down.


> This is my view of the situation, and that is fairly dire. If WG participants
> thinks the issues the WG faces can be addressed, I will listen to you. But
> improvements need to be shown.

IMO it is also important, as part of this conversation, to identify
the processes that will be used without a WG to extend the NFSv4
protocols and manage interoperability. The Linux NFS community, for
example, usually requires a standards document before considering
significant new features.

If we have new protocol work, where will it be proposed? Will we
need an IETF BoF to decide whether it is worth pursuing?

What will be the process for making authoritative changes to NFSv4?

Can you post some BCPs or other documentation that describes what
this might look like?


--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4