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

Hi Lars,

Thanks for the careful review.  I plan to submit a new revision of the draft in a day or so.  Following are my responses/resolutions.

Mallikarjun


>   Has idnits (unused references, tabs, non-ASCII characters, etc.) and

Now fixed (most of them).  I just didn't know what to do about 
non-ASCII character complaints - idnits is flagging every hyphen as a non-ASCII 
character for some reason....

>   Document talks about the "Datmover protocol" as a wire protocol in

David responded to this.  Just to make it very clear, I tweaked the Abstract to say the following:
".....While DA defines the architectural functions required of the class of Datamover protocols, it does not define any specific Datamover protocols.  Each such Datamover protocol, to be defined in a separate document, provides a reliable transport for all iSCSI PDUs, but actually....."
Hope that makes it clearer.

>   some places and in others it says the opposite (that it isn't a wire
>   protocol) - this is confusing.

Datamover protocol is one artifact within the umbrella DA architecture.  While the former is a wire protocol, the latter is not.  The draft has been pretty careful to consistently separate the two out.

>Section 2.1, paragraph 1:
>   Paragraph probably needs to be updated to reflect recent history  
>(RDMA
>   done, not proposed anymore).

Done.

>
>
>Section 2.2, paragraph 2:
>   Nit: would not capitalize "architecture" here (and later)

Subjective.  I now changed "Architecture" to "DA architecture"

>Section 3, paragraph 1:
>   Might want to point out that RDMA over SCTP also exists (and cite
>   corresponding ID).

David responded to it, no changes made here.

>Section 5.4, paragraph 3:
>>         shared memory etc.) is really upto the implementations.
>
>   Nit: s/upto/up to/

Done.

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

Per your & David's feedback, I changed the last sentence to read:
 "A TCP connection is an example of a Transport Connection."

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

True, the sentence can be misleading for it is too terse.  I rephrased it to:
A target iSCSI layer being notified of an ungraceful connection termination by the Datamover layer when the underlying Transport Connection is torn down due to receiving a  TCP RESET is one example when the Connection_Terminate_Notify Operational Primitive is invoked.

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

David had already responded to this.  I did what David suggested, replaced the paragraph with a single sentence:
DA architecture does not have any IANA considerations.

>Section 15, paragraph 2:
>
>   Some of these are also listed as authors.

Not sure who, I double checked the list.

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

If it's okay, I'd prefer to leave this section in the DA draft, because 
the text is too DA-ish to belong to iSER draft.





----- Original Message ----
From: Lars Eggert <[email protected]>
To: [email protected]
Cc: [email protected]; [email protected]
Sent: Thursday, October 12, 2006 12:53:11 AM
Subject: [Ips] 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



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