AD review of draft-ietf-ips-iwarp-da

Hi,

please find the AD review of draft-ietf-ips-iwarp-da-03.txt below. In  
a nutshell: No major issues but a number of comments and nits that  
might best be handled by a new revision before IESG review.

Lars

---<snip>---

   Has idnits (unused references, tabs, non-ASCII characters, etc.) and
   boilerplate issues (some due to boilerplate changes during the
   too-long AD review - mea culpa).


   Document talks about the "Datmover protocol" as a wire protocol in
   some places and in others it says the opposite (that it isn't a wire
   protocol) - this is confusing.


Section 2.1, paragraph 1:
 >         There are new industry and standards initiatives to develop
 >         Remote Direct Memory Access (RDMA) and Remote Direct Data
 >         Placement (RDDP) technologies to work over IP fabrics.  The
 >         principal value proposition of these technologies is that
 >         they enable one end node to place data in the final intended
 >         buffer on the remote end node, thus eliminating the data copy
 >         that traditionally happens in the receive path to move the
 >         data to the final buffer.  The data copy avoidance in turn
 >         eliminates unnecessary memory bandwidth consumption, substan-
 >         tially decreases the reassembly buffer size requirements, and
 >         preserves CPU cycles that would otherwise be spent in
 >         copying.

   Paragraph probably needs to be updated to reflect recent history  
(RDMA
   done, not proposed anymore).


Section 2.2, paragraph 2:
 >           a)      Provide guidance to Datamover protocol designers
 >                   with respect to the functional boundary between
 >                   iSCSI and the Datamover protocols.  This  
guidance is
 >                   critical since a significant part of the [RFC3720]
 >                   protocol definition is left unchanged by this
 >                   Architecture and the iSCSI notions from [RFC3720]
 >                   (e.g., tasks, ITTs) are leveraged by the Datamover
 >                   protocol.

   Nit: would not capitalize "architecture" here (and later)


Section 3, paragraph 1:
 >         Figure 1 illustrates an example of the architectural layering
 >         of iSCSI and Datamover layers, in conjunction with a TCP/IP
 >         implementation of RDMAP/DDP layers in an iSCSI end node.
 >         Note that RDMAP/DDP/MPA, and TCP protocol layers are shown
 >         here only as an example and in reality, DA is completely
 >         oblivious to protocol layers below the Datamover layer.

   Might want to point out that RDMA over SCTP also exists (and cite
   corresponding ID).


Section 5.4, paragraph 3:
 >         shared memory etc.) is really upto the implementations.

   Nit: s/upto/up to/


Section 5.5, paragraph 1:
 >         The term "Transport Connection" is used in this document as a
 >         generic term to represent the end-to-end logical connection
 >         as defined by the underlying reliable transport protocol.
 >         For this revision of this document, a Transport Connection
 >         means only a TCP connection.

   What about RDMA over SCTP? Or, rather, isn't the Transport Connection
   an RDMAP connection and hence independent of TCP or SCTP anyway?


Section 9.2, paragraph 4:
 >         A target iSCSI layer being notified of the arrival of TCP
 >         RESET is an example of when the Connection_Terminate_Notify
 >         Operational Primitive is invoked.

   RDMAP RESET? TCP events should be hidden.


Section 12, paragraph 1:
 >         If a well-known port is chosen as the mechanism to identify a
 >         Datamover protocol on TCP, the well-known port must be
 >         registered with IANA.  Because the use of the well-known port
 >         is specific to the Datamover protocol in such a case, the
 >         resulting IANA considerations from such use must be specified
 >         by the specific Datamover protocol.  DA itself does not have
 >         any specific IANA considerations.

   Datamover protocol sits on top of RDMAP and would need to be
   registered in an IANA registry there, rather that with a TCP port
   number.


Section 15, paragraph 2:
 >         In addition, the following individuals had reviewed and
 >         contributed to the improvement of this document.  The authors
 >         are grateful for their contribution.

   Some of these are also listed as authors.


Section 16.1, paragraph 1:
 >         This section discusses the specific considerations for RDMA-
 >         based and RDDP-based Datamover protocols.

   Shouldn't this section move to the iSER draft?

-- 
Lars Eggert                                     NEC Network Laboratories

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips