Re: [nfsv4] Meeting at IETF115, or not

[Chuck Lever III <[e-mail]>]

On Sep 25, 2022, at 4:11 PM, David Noveck <[e-mail]<mailto:[e-mail]>> wrote:

On Sat, Sep 24, 2022 at 12:22 PM Chuck Lever III <[e-mail]<mailto:[e-mail]>> wrote:


We need to follow up appropriately, but, as I've said before wg "decisions" cannot be made on the basis of the people who attend a working group meeting, but need to be confirmed on the wg mailing list.

So let's do that.

  *   Retirement of rpcrdma-v2 and nfs-ulb-v2 and the associated removal of related charter milestones

We've discussed this before.   I agree with the removal of charter milestones but I do not feel an adequate case has been made to retire these documents.

I think the issue turns on implementations.   If there are no existing implementations, then I agree with retirement and I feel we can proceed on that basis.

I have a prototype of the protocol before the flow control features were fixed last winter. The early prototype does not implement message chaining or transport properties. This prototype has been available for a long while, having been mentioned during slide presentations at previous WG sessions.

https://git.kernel.org/pub/scm/linux/kernel/git/cel/linux.git/log/?h=topic-rpcrdma-version-two

You can see the dates on the latest commits in this branch: June of 2021.

I do not have an implementation of what's in the current revision of the document. So effectively, there are no implementations of the protocol as it is now documented.


On the other hand, if an implementation exists and you are waiting for a second one, then I would want the document to be maintained as-is so that I could work on an implementation.

The discussion during IETF 114 was to let the documents expire. If more work is to be done on this protocol, it's a simple matter to revivify them from the expired revisions that remain in the document archive.


  *   Propose a plan to assess and handle the backlog of errata not related to rfc5661bis

Maybe Brian can do that with some input from you.

I feel it's the responsibility of the chairs to generate this type of plan and see that the WG executes on it. Brian was part of the same conversation I was part of, and he knows what needs to be done. So I expect to see you and Brian, as chairs, come up with this plan, because ultimately you two are responsible for moving chartered work (and yes, addressing errata is part of our charter) forward.

People are actually asking the WG to address errata. No-one is asking us for an RPC/RDMA v2.


As WG resources are few, IMHO shepherds should be chosen for the new WG documents and a last call schedule should be proposed, as part of their promotion.

Two points to be made:

  *    Shepherding resources are quite limited.  For example, it will be difficult to find a shepherd for the internationalization document.

Exactly. It was difficult to identify shepherds and expert reviewers for the RPC-with-TLS document, but eventually I (as the document's editor) was able to recruit strong reviewers, with the help of others in the Transport Area. I don't think it's out of place to ask you, as author of the i18n document and as WG chair, to do the same. Set a good example.


  *   As the example of rpc-over-rdma, it is hard to predict when last call will be arrived and there is no evidence thhat any particular will be met, or that picking a date soon in the future will accelerate the process.

A plan does not have to have dates-certain attached to it.


--
Chuck Lever