RFC 8166, "Remote Direct Memory Access Transport for Remote Procedure Call Version 1", June 2017Source of RFC: nfsv4 (tsv)
Errata ID: 6528
Publication Format(s) : TEXT
Reported By: David Noveck
Date Reported: 2021-04-12
Section 4.2.4 says:
A Requester MUST NOT send an RPC-over-RDMA header with the RDMA_ERROR procedure. A Responder MUST silently discard RDMA_ERROR procedures
It should say:
An RDMA_ERROR header cannot be sent without an assurance that, the receiver has posted a receive operation which its sending will satisfy. In most cases, this means that a Requester (i.e. one sending RPC Calls) MUST NOT send an RPC-over-RDMA header with the RDMA_ERROR procedure. Similarly, a Responder (i.e. one sending RPC Replies) MUST silently discard RDMA_ERROR procedures. However, in the case of providing an RDMA_ERROR headers containing an error code of ERR_VERS, such a schema is not realizable, since there is no way for a receiver who does not support a particular version, to determine whether an RPC Call or Reply is being sent, leaving the receiver uncertain as to whether it is being Addressed as a Requester or a Responder, leaving it unable to participate in version negotiation. In the case of version errors, the implementation is to rely on the assumption that forward direction requests are being done and reserve direction requests only done once the version is properly negotiated. As a result, such messages MUST NOT be sent by the client and MUST be silently discarded by servers.
Even if one feels that this is not an appropriate correction, the existing text must be fixed somehow. In assuming that the terms Requester and Responder can be used this way in this context is likely to result in some implementers concluding that version errors can never be sent while other might be unabble to coonclude that given the effort expended in the spec to make such errors be interpretable by anf rpc-over-rdma version.