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]> |
> On Nov 6, 2019, at 1:40 PM, Chuck Lever <[email protected]> wrote: > >> >> 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. Re-reading your proposed text, it says exactly what I said here. Sigh! >> 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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4> -- Chuck Lever _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4