Re: [nfsv4] I-D Action: draft-talpey-rdma-commit-02.txt

[Tom Talpey <[e-mail]>]

On 1/26/2023 5:23 PM, Chuck Lever III wrote:
> I read through this document to get a flavor. A couple of observations/comments follow:

Thanks for the early review!

> The Requirements Language section needs to be updated to include a reference to RFC 8174. For reference, the most recent version of the RL boilerplate looks like this:

Interesting, the id-nits tool does not flag this. Because this is still 
an individual draft, I didn't update any of the boilerplate from the 
earlier versions. Obviously this will be done if it becomes a WG document.

> Section 1 is lengthy and contains considerable repetition.

Yes, this informational section was lightly updated, but for this review 
it was left in place. We can certainly discuss what part(s) remain 
useful in a normative standards-track version, and either edit, move or 
delete.

One note however:

> 	• The definition of "Persistence" in Section 1.1 is confusing.
> 		• Perhaps a short discussion of the terms "persistence" and "durability" (or a mention that they are synonyms) might be appropriate.

I intended to remove the no-longer-preferred term "durable", but oops I 
did neglect to delete the single reference to the term.

I also intended to remove "commit" where it was used to mean "flush", 
and there is at least one vestige. Its use in the filename is purely to 
maintain continuity and will be renamed if adopted.

> 	• Is there a purpose for "Global" in the definition of "Global Visibility" (as opposed to "Local Visibility")? A brief discussion of that distinction would help orient readers; or perhaps it is covered elsewhere in the document and I missed it.

Yes, "global" is an important qualifier and it's in the first sentence 
of the glossary. But it could be made clearer. In a nutshell, 
persistence is for storage semantics, while global visibility is for 
shared memory semantics. Upper layer processing is required to implement 
these over traditional RDMA.

> Section 3 is marked "INCOMPLETE". What is the plan to complete this section? Is there other remaining significant work planned for this document?

It's intended to mirror the format of RFC5040 and RFC7306, but there are 
some new requirements that make the old table format difficult to reuse. 
I have an idea, but thought it was better to get the ball rolling now.

And, I don't plan other additions, apart from things that a WG 
discussion might generate.

> Is there any implementation status to document via an "Implementation Status" section? I would like to see one... or at least an informal report on the mailing list about current implementation plans, as part of the planned IETF 116 discussion of this document.

There have been experimental implementations, which are not for me to 
cite in a standards-track document. There is also at least one non-IETF 
protocol which has implemented a similar set of functionalities, in fact 
whose semantics were based on earlier versions of this draft.

> The third paragraph of "6. Security Considerations" touches on this, but what is the trust relationship between the peers in push mode? How do push mode peers authenticate to each other?

This is entirely the domain of the upper layer. It needs to determine 
whether the peer is trusted, prior to creating and advertising a 
push-mode memory handle for that peer. Perhaps this can be stated more 
forcefully.

Tom.


>> -------- Forwarded Message --------
>> Subject: I-D Action: draft-talpey-rdma-commit-02.txt
>> Date: Wed, 25 Jan 2023 10:52:21 -0800
>> From: [e-mail]
>> Reply-To: [e-mail]
>> To: [e-mail]
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>         Title           : RDMA Extensions for Enhanced Memory Placement
>>         Author          : Tom Talpey
>>   Filename        : draft-talpey-rdma-commit-02.txt
>>   Pages           : 37
>>   Date            : 2023-01-25
>>
>> Abstract:
>>    This document specifies extensions to RDMA (Remote Direct Memory
>>    Access) protocols to provide capabilities in support of enhanced
>>    remotely-directed data placement on memory-addressable devices,
>>    including persistent memory.  The extensions include new operations
>>    supporting remote commitment to persistence of remotely-managed
>>    buffers, which can provide enhanced guarantees and improve
>>    performance for low-latency storage applications, and to the
>>    visibility of such buffers in support of remote shared memory
>>    semantics.  This document updates RFC 5040 (Remote Direct Memory
>>    Access Protocol (RDMAP)) and updates RFC 7306 (RDMA Protocol
>>    Extensions).
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-talpey-rdma-commit/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-talpey-rdma-commit-02
>>
>> A diff from the previous version is available at:
>> https://author-tools.ietf.org/iddiff?url2=draft-talpey-rdma-commit-02
>>
>>
>> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4