Re: [nfsv4] Comments on minutes of wg meeting at IETF114

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

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



> BIS document will be discussed on the mailing list.

Good idea.  Since it hasn't been done yet, I wil have to start the discussion.  See below.

Chuck
Lever         20m  RDMA.     RPC-over-RDMA

> Major concern is lack of security in the protocol.

We need to address this.

David Black wonders what is practical to implement.

In any case, we need to provide a protocol.

>Tom Talpey and David Black think QUIC would be straightforward - suggest avoiding TLS for RDMA.

No problem with this on my part.

> Richard S wants a security standard protocol.

No sure what this means.

> Christoph believes security and performance can co-exist.

I agree.

> Perhaps a new WG to explore extensions to both NFS and RDMA?

I don't see the point.   We have an NFSv4 working group and it has successfully done RDMA-related protocol work.

> Chuck believes urgency of v2 is less than it used to be.

I agree if security is addressed otherwise.

> Should we let this work expire?

I agree it is not urgent but that doesn't means it is useless.

>Tom Talpey agrees to let the document sit as a reference.

Not sure how to work this out.

The conclusion of this discussion was to let the RDMA and ULB documents expire and remove the charter milestone.

A version 2 of RPC/RDMA is not in demand by any customer. I feel it’s time to let it rest, unless or until there are sufficient resources to attack the addition of transport-layer security to MPA/RDMAP.

I fear these minutes do not capture the entire discussion. Is there a video recording of the session available?


Chuck has informed me that a wg decision was made to abandon this document but that does not appear in the minutes.  In any case, I need either this document or some replacement to proceed with security-05

Rick says he plans to implement a simple rejection of RPCs when a server’s security policy does not permit AUTH_SYS without TLS, using existing RPC or upper layer status code. The client can decide to retry with TLS (why was it not defaulting to TLS in the first place?) or let such requests fail.

I’d like Rick to write a brief description of his idea.


> Zahed questions whether we had an adoption call for the BIS document?

I guess not.   The issue is complicated by current plans for document split-up.

We haven’t had any deep public discussion of the scope of each the replacement documents. They have grown to encompass quite a bit more than what was in RFC 5661. I would feel more comfortable if the WG could agree on a limited scope for each of these to prevent scope creep from making them impossible to complete.

The idea that we are addressing every errata against RFC 5661 with the bis effort is new to me. I know we had some vague plans to address some of them, and I had proposed keeping track of these with the github issue tracker. However, github has not been adopted for any of these documents, so at this time there is no real tracking of these outstanding issues.

There are, of course, errata against other RFCs that this WG is responsible for. My impression of the discussion during the session was that all of these errata were a problem, not just the errata against RFC 5661.