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

Sorry about this top-post, but it'll get ugly if I switch modes in Outlook.

Regarding my suggestion of MAY, yes perhaps the normative form is inappropriate.
How about "may"? Or "may elect to"?

-----Original Message-----
From: Chuck Lever <[email protected]> On Behalf Of Chuck Lever
Sent: Wednesday, November 6, 2019 1:41 PM
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


> On Nov 6, 2019, at 11:40 AM, Tom Talpey <[email protected]> wrote:
> 
> 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.

idnits did not complain about this, but I've changed it as suggested.


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

Not sure about using MAY here. MAY usually means "you shouldn't, but
there are some cases where it might be necessary." Not even sure if
SHOULD or MUST captures the precise intention.

And, "RFC8166 protocol itself is unchanged" is not strictly true: When
Remote Invalidation is in use, Send With Invalidate may be used on the
wire instead of Send. The XDR definition is definitely unchanged,
however.


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

After updating, here's what I have:


Abstract

   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.


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 this 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.  In other words, implementation
   of the private data message specified in this document is OPTIONAL.
   When the private message is not present, implementations strictly
   conform to [RFC8166].

   The message format is intended to be further extensible within the

....


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

--
Chuck Lever



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