Re: Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

Chuck Lever <[email protected]>
Newsgroups gmane.ietf.nfsv4
Message-ID <[email protected]>
Hi everyone (but especially Tom) -

> On Nov 5, 2019, at 12:22 PM, Tom Talpey <[email protected]> wrote:
> 
> TL;DR Proposed Standard is appropriate.
>  
> Longer version, I may be the guilty party here. When Chuck originally was exploring using private data to extend rpcrdmav1, I encouraged him to publish the format as a draft. By design, the private data is optional, for both the sender and the receiver. Its presence, and its recognition at the peer, drives the extended features.
>  
> At the time, the concern for standardization was whether it would be of interest to the WG, and/or to other implementations. Its adoption as a WG item settles that.
>  
> When published as Proposed Standard, the document should additionally be tagged as an optional extension to RFC8166.

To address this issue, I've made the following changes to the document.
Please let me know if additional changes are needed. I plan to separately
address the other issues arising from the AD write-up.


The status has been changed:

Network File System Version 4                                   C. Lever
Internet-Draft                                                    Oracle
Updates: 8166 (if approved)                             November 6, 2019
Intended status: Standards Track
Expires: May 9, 2020


The Abstract now reads:

   This document specifies the format of RDMA-CM Private Data exchanged
   between RPC-over-RDMA version 1 peers as part of establishing a
   connection.  The addition of the private data payload specified in
   this document is an OPTIONAL extension that does not alter the RPC-
   over-RDMA version 1 protocol.  This document updates RFC 8166.


A paragraph has been added near the end of the Introduction:

....
   the base RPC-over-RDMA version 1 protocol defined in [RFC8166].

   To enable current RPC-over-RDMA version 1 implementations to
   interoperate with implementations that support the message format
   described in the current document, the private message is not
   required to be present, and the message format does not alter the XDR
   definition of the RPC-over-RDMA version 1 protocol.  When the private
   message is not present, implementations conform to the defaults
   already found in [RFC8166].

   The message format is intended to be further extensible within the
....

--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.