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

Looks good, but I think the RFC2119 "OPTIONAL" is inappropriate in the Abstract.
It should be simply "optional" here. It should perhaps be repeated in the body in
normative form.

In the new paragraph, "described in the current document" is a bit vague. Suggest
"conforming to RFC8166".

The final sentence of the new paragraph can be restated a bit, to make the OPTIONAL
statement as well as making it explicit that RFC8166 conformance doesn't change:

"Support for the private data payload specified in this document is OPTIONAL. When
the private data payload is successfully exchanged, peers MAY perform the extended
RDMA semantics. The RFC8166 protocol itself is unchanged."

That's a suggestion, better wording is fine too.

Tom.

-----Original Message-----
From: Chuck Lever <[email protected]> On Behalf Of Chuck Lever
Sent: Wednesday, November 6, 2019 11:23 AM
To: Tom Talpey <[email protected]>
Cc: spencer shepler <[email protected]>; Magnus Westerlund <[email protected]>; [email protected]; [email protected]
Subject: Re: [nfsv4] Publication has been requested for draft-ietf-nfsv4-rpcrdma-cm-pvt-data-04

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