Direct Data Placement over Reliable Transports
draft-ietf-rddp-ddp-07

IANA Last Call Comment:

As described in the IANA Considerations section, we understand this document
to have NO IANA Actions.

We take note of the IANA note in the document to be guidance to future
applications for port numbers.

PROTO writeup:
              Direct Data Placement over Reliable Transports
                    draft-ietf-rddp-ddp-05.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited review outside the WG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG as a whole understands and agrees with this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits checker doesn't like the page separators or absence thereof
(it thinks the document is 1 page).  It says everything else is ok.

  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are two normative references to Internet-Drafts:

o draft-ietf-rddp-rdmap - publication has been requested along
with this draft.
o draft-ietf-rddp-mpa - publication will be requested within
the next 2 weeks.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

  Direct Data Placement Protocol (DDP) enables an Upper Layer Protocol
  (ULP) to send data to a Data Sink without requiring the Data Sink to
  Place the data in an intermediate buffer - thus when the data
  arrives at the Data Sink, the network interface can Place the data
  directly into the ULP's buffer. This can enable the Data Sink to
  consume substantially less memory bandwidth than a buffered model
  because the Data Sink is not required to move the data from the
  intermediate buffer to the final destination. Additionally, this can
  also enable the network protocol to consume substantially fewer CPU
  cycles than if the CPU was used to move the data, and removes the
  bandwidth limitation of only being able to move data as fast as the
  CPU can copy the data.

  DDP preserves ULP record boundaries (messages) while providing a
  variety of data transfer mechanisms and completion mechanisms to be
  used to transfer ULP messages.

-- Working Group Summary

  DDP provides two mechanisms, a Tagged Buffer mechanism for Remote
  DMA transfers where the network communication contains a destination
  memory offset, and an Untagged Buffer mechanism that supports
  socket-like sends where the receiver chooses the buffer on its own.
  The WG has strong consensus that both mechanisms are required in order
  for an implementation to exercise control over all memory buffer
  resources used for network communication.

-- Protocol Quality

  The protocol has been reviewed for the rddp WG by David L. Black.

PROTO writeup:
              An RDMA Protocol Specification
                  draft-ietf-rddp-rdmap-05.txt

Requested Publication Status: Proposed Standard
PROTO shepherd: David L. Black (RDDP WG Chair)
------------------------------------------------------------------------

  1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        to forward to the IESG for publication?

Yes.

  1.b) Has the document had adequate review from both key WG members
        and key non-WG members?

Yes, primarily from WG members.

        Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The draft has had limited review outside the WG.

  1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

  1.d) Do you have any specific concerns/issues with this document that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of the
        document, or have concerns whether there really is a need for
        it.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No.

  1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

The WG as a whole understands and agrees with this document.

  1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

No.

  1.g) Have the chairs verified that the document adheres to all of the
        ID nits? (see http://www.ietf.org/ID-Checklist.html).

The ID nits checker found a few minor format problems (long lines, non-
ascii characters, missing apostrophe in "Authors Addresses) that are
readily correctable by the RFC Editor.

  1.h) Is the document split into normative and informative references?

Yes.

        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that the RFC editor will not publish an RFC with
        normative references to IDs, it will delay publication until all
        such IDs are also ready for publication as RFCs.)

There are four normative references to Internet-Drafts:

o draft-hilland-rddp-verbs - This reference is not cited in the body
of this (RDMA Protocol) draft, which is a good thing because the
verbs draft will not be published as an RFC.  An RFC Editor Note
should be used to delete this reference if the RDMA Protocol draft
is not revised prior to IESG approval.
o draft-ietf-rddp-ddp - Publication has been requested along with
this draft.
o draft-ietf-rddp-mpa - Publication will be requested within
the next 2 weeks.
o draft-ietf-rddp-security - Publication has been requested along
with this draft.

  1.i) For Standards Track and BCP documents, the IESG approval
        announcement includes a write-up section with the following
        sections:

        *    Technical Summary

        *    Working Group Summary

        *    Protocol Quality

  1.j) Please provide such a write-up.  Recent examples can be found in
        the "protocol action" announcements for approved documents.

-- Technical Summary

  This document defines a Remote Direct Memory Access Protocol
  (RDMAP) that operates over the Direct Data Placement Protocol (DDP
  protocol).  RDMAP provides read and write services directly to
  applications and enables data to be transferred directly into ULP
  Buffers without intermediate data copies. It also enables a kernel
  bypass implementation.

-- Working Group Summary

  RDMAP supports both DMA (direct read/write to identified buffer) style
  and message (send, receiver selects buffer) style transfers.  The WG has
  strong consensus that both transfer styles are required in order for an
  implementation to exercise control over all memory buffer resources
  used for network communication, and to appropriately support usage
  where a DMA style transfer is followed by a message style transfer
  whose reception is used to infer completion of the preceding DMA
  style transfer.

-- Protocol Quality

  The protocol has been reviewed for the rddp WG by David L. Black.

State Change Notice email list have been change to rddp-chairs@tools.ietf.org, paul.culley@hp.com, dave.garcia@hp.com, jeff.hilland@hp.com, bmt@zurich.ibm.com, recio@us.ibm.com, hemal.shah@intel.com, jpink@microsoft.com from black_david@emc.com