Remote Direct Memory Access (RDMA) over IP Problem Statement
RFC 4297

Received changes through RFC Editor sync (changed abstract to 'Overhead due to the movement of user data in the end-system network I/O processing path at high speeds is significant, and has limited the use of Internet protocols in interconnection networks, and the Internet itself -- especially where high bandwidth, low latency, and/or low overhead are required by the hosted application.

This document examines this overhead, and addresses an architectural, IP-based "copy avoidance" solution for its elimination, by enabling Remote Direct Memory Access (RDMA). This memo provides information for the Internet community.')

[Ballot comment]
The Introduction provides a clear description of the situation.  However,
  I find the Abstract very confusing.  I believe that some wordsmithing will
  greatly improve the Abstract.

  The use of IPsec, TLS, or any other protocol that provides authentication
  will not fit well into the proposed architecture.  The integrity check
  cannot be performed until the entire packet (or record in the case of TLS)
  is available in memory.  So, the data must be copied from the I/O interface
  to memory, which may involve some reassembly, before the integrity check
  can be performed.  This issue should be discussed in the second paragraph
  of the security considerations.

  The security considerations section talks about 'threats.'  The use does
  not align with the definitions in RFC 2828.  I suggest some rewording. I
  think the authors ought to look review the definition of 'vulnerability'
  in RFC 2828.

  s/IPSec/IPsec/

  s/privacy/confidentiality/

[Ballot comment]
From John Louhghney, Gen-ART reviewer:

Less important and/or editorial
===============================

a) last sentence in Section 2.1 on page 6:

(Of course this argument would
    be specious if the amount of overhead were insignificant, but it
    has been shown to be substantial.)

  It would be nice to have some sort of reference to a document where it
  is shown that the amount of overhead has been shown to be substantial.

b) Page 9, in the table:
  s/Thruput/Throughput

c) Note to the RFC Editor on page 14 probably unnecessary.

d) In the references, I think "et al" should be "et al.* - i.e. - it is
  missing a period after "al".

[Ballot discuss]
Needs an editing pass before being released.
From John Loughney, Gen-ART reviewer:

I would recommend the following changes:

Fairly important:
=================
a) Expand "RDMA" in draft title.
b) The draft is really crying out for a terminology section.  I am not well
  versed in this area, so RDMA, fibre channel, SAN, etc. should be added
  to a terminolgy section.
c) Related to point b, abbreviations / acronyms should be expanded on their
  first use. For example Gbits/s, SAN, RDMA and so forth. 
d) Section 4 does a good job at explaining the applicability of this particular
  problem to the internet architecture.  I think that part of this really needs
  to be summarized in section 1, perhaps under a 'Motivation' or 'Applicability
  to the Internet' section, so that this document is easier to understand to
  the lay-person.
e) It needs the IPR notices added.
f) In the security section, the discussion seems OK, but I think there needs to
  be some discussion about authorization / authentication for data copy.
  One can imagine that DoS attacks could be launched if applications / peers
  are not properly authenticated and authorized before a session takes place.

More comments in "comments" section.