Proposed updates to draft-ietf-nfsv4-rpcrdma-cm-pvt-data

As a result of expert review, changes are needed to Section 4.1.2
to clarify the purpose and implementation guidance of the Format
Identifier field.

I propose that the new Section read (in its entirety):


4.1.2.  Amongst Implementations of Other Upper-Layer Protocols

   The Format Identifier field in the message format defined in this
   document is provided to enable implementations to distinguish RPC-
   over-RDMA version 1 Private Data from private data inserted at layers
   below RPC-over-RDMA version 1.  An example of a layer below RPC-over-
   RDMA version 1 that makes use of CM Private Data is iWARP, via the
   MPA enhancement described in [RFC6581].

   During connection establishment, an implementation of the extension
   described in this document checks the Format Identifier field before
   decoding subsequent fields.  If the RPC-over-RDMA version 1 CM
   Private Data Format Identifier is not present as the first 4 octets,
   an RPC-over-RDMA version 1 receiver MUST ignore the CM Private Data,
   behaving as if no RPC-over-RDMA version 1 Private Data has been
   provided (see above).

   Because the Format Identifier field is newer than some other
   potential users of private data (such as iWARP), there is a risk that
   a lower layer might inject its own private data with a payload
   somehow containing the identifier of RPC-over-RDMA version 1.  It is
   recommended that RPC-over-RDMA version 1 implementations perform
   additional checks on the content of received CM private data before
   making use of it.


--
Chuck Lever



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