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

Ship it.

On Sun, Dec 15, 2019, 3:48 PM Chuck Lever <[email protected]> wrote:

> 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
>

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