[rddp] RDMAP PROTO writeup
Black_David@emc.com Thu, 29 September 2005 17:19 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL24T-0006V0-At; Thu, 29 Sep 2005 13:19:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL24S-0006Uu-1G for rddp@megatron.ietf.org; Thu, 29 Sep 2005 13:19:48 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23449 for <rddp@ietf.org>; Thu, 29 Sep 2005 13:19:44 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL2C9-0007xq-BE for rddp@ietf.org; Thu, 29 Sep 2005 13:27:45 -0400
Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j8THJcS3006534 for <rddp@ietf.org>; Thu, 29 Sep 2005 13:19:43 -0400 (EDT)
Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id <RT6ADTC6>; Thu, 29 Sep 2005 13:19:37 -0400
Message-ID: <F222151D3323874393F83102D614E0557A6EEF@CORPUSMX20A.corp.emc.com>
To: rddp@ietf.org
Date: Thu, 29 Sep 2005 13:19:31 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.9.29.18
X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_BODY_1+ -5, EMC_FROM_00+ 0, NO_REAL_NAME 0, __C230066_P5 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __IMS_MSGID 0, __IMS_MUA 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0'
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Subject: [rddp] RDMAP PROTO writeup
X-BeenThere: rddp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" <rddp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rddp@ietf.org>
List-Help: <mailto:rddp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rddp>, <mailto:rddp-request@ietf.org?subject=subscribe>
Sender: rddp-bounces@ietf.org
Errors-To: rddp-bounces@ietf.org
The PROTO process (cf. draft-ietf-proto-wgchair-doc-shepherding-05.txt) is being used for the RDMAP draft. Here is the 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) [... not sent to the WG ...] 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. ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp
- [rddp] RDMAP PROTO writeup Black_David