From mailman-bounces@ietf.org Wed Dec 1 06:54:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18554 for ; Wed, 1 Dec 2004 06:54:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZT98-0006YX-P2 for rddp-web-archive@ietf.org; Wed, 01 Dec 2004 06:59:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZS98-0001mF-8n for rddp-web-archive@ietf.org; Wed, 01 Dec 2004 05:55:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: rddp-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:33:39 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for rddp-web-archive@ietf.org: List Password // URL ---- -------- rddp@ietf.org jOsP https://www1.ietf.org/mailman/options/rddp/rddp-web-archive%40ietf.org From rddp-bounces@ietf.org Fri Dec 3 13:22:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14707 for ; Fri, 3 Dec 2004 13:22:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaIAK-0006YO-Ks for rddp-web-archive@ietf.org; Fri, 03 Dec 2004 13:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaEbc-00056H-8O; Fri, 03 Dec 2004 09:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaDw1-0007uz-TY for rddp@megatron.ietf.org; Fri, 03 Dec 2004 08:57:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05218 for ; Fri, 3 Dec 2004 08:57:20 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaE1l-0003ur-0q for rddp@ietf.org; Fri, 03 Dec 2004 09:03:18 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Fri, 3 Dec 2004 05:56:43 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Dec 2004 05:51:34 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Dec 2004 05:51:33 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Fri, 3 Dec 2004 05:51:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Dec 2004 05:51:31 -0800 Message-ID: Thread-Topic: last call before interop is resolved? thread-index: AcTZPzHIvgwhMPZ5TC6JxbfGlRChtQ== From: "Jim Pinkerton" To: X-OriginalArrivalTime: 03 Dec 2004 13:51:33.0822 (UTC) FILETIME=[3330CDE0:01C4D93F] X-Spam-Score: 0.5 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Subject: [rddp] last call before interop is resolved? X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0640532290==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 This is a multi-part message in MIME format. --===============0640532290== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D93F.32F78B0F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D93F.32F78B0F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I am very concerned that the current path we're on is to try to do last call before we close on the interop issues with the RDMA Consortium protocols. To me this would be a mistake because it effectively fragments the market when in fact we have a very concrete interop proposal on the table that appears to be holding water, which has very specific text change recommendations that appear to be straightforward to put into the specs. =20 Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems like the only outstanding issue raised so far is what is the exact text used in the RDMAP/DDP specs on what is a "valid" version number (i.e. do we leave it up to the vendor, or do we state something more explicit). That seems like a pretty small outstanding issue?=20 =20 Further, it seems like we should be able to get out updated drafts within a few days which incorporate the recommendations, and the recommendations do not have significant complexity to implement in the normative body of the specs (unlike the outstanding issue of normative statements in the security chapters of DDP/RDMAP (!!). =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C4D93F.32F78B0F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I am very concerned that the current path we’re = on is to try to do last call before we close on the interop issues with the = RDMA Consortium protocols. To me this would be a mistake because it = effectively fragments the market when in fact we have a very concrete interop = proposal on the table that appears to be holding water, which has very specific text = change recommendations that appear to be straightforward to put into the = specs.

 

Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems like the only outstanding issue raised so far is = what is the exact text used in the RDMAP/DDP specs on what is a = “valid” version number (i.e. do we leave it up to the vendor, or do we state = something more explicit). That seems like a pretty small outstanding issue? =

 

Further, it seems like we should be able to get out = updated drafts within a few days which incorporate the recommendations, and the recommendations do not have significant complexity to implement in the normative body of the specs (unlike the outstanding issue of normative statements in the security chapters of DDP/RDMAP (!!).

 

 

Jim

 

 

 

------_=_NextPart_001_01C4D93F.32F78B0F-- --===============0640532290== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0640532290==-- From rddp-bounces@ietf.org Fri Dec 3 15:10:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01507 for ; Fri, 3 Dec 2004 15:10:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJrA-0003BQ-LT for rddp-web-archive@ietf.org; Fri, 03 Dec 2004 15:16:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJYt-0004SL-Jv; Fri, 03 Dec 2004 14:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaJBI-0002E7-Gs for rddp@megatron.ietf.org; Fri, 03 Dec 2004 14:33:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25918 for ; Fri, 3 Dec 2004 14:33:27 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaJH4-0001Sd-JS for rddp@ietf.org; Fri, 03 Dec 2004 14:39:28 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] last call before interop is resolved? MIME-Version: 1.0 Date: Fri, 3 Dec 2004 11:34:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [rddp] last call before interop is resolved? Thread-Index: AcTZPzHIvgwhMPZ5TC6JxbfGlRChtQALs44g From: "Caitlin Bestler" To: "Jim Pinkerton" , X-Spam-Score: 0.6 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0225685441==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd This is a multi-part message in MIME format. --===============0225685441== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4D96E.DE7EADD6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4D96E.DE7EADD6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. The *most* that we might have to change is to make it clear that an iWARP implementation *may* choose to interoperate with the RDMAC versions, and that there is nothing in the main drafts that forbids this. =20 The requirements on what is a "valid" version number is the only thing that might have to be clarified, so I think it is doable. I also do not think it is necessary, since interoperability is extra functionality which has no impact on the pure IETF protocol. But it is better to be clear that more liberal interpretation of "valid" that enables interoperability *is* legitimate and even ever so slightly encouraged (but probably not to the level of a "should"). =20 ________________________________ From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Jim Pinkerton Sent: Friday, December 03, 2004 5:52 AM To: rddp@ietf.org Subject: [rddp] last call before interop is resolved? =09 =09 =20 I am very concerned that the current path we're on is to try to do last call before we close on the interop issues with the RDMA Consortium protocols. To me this would be a mistake because it effectively fragments the market when in fact we have a very concrete interop proposal on the table that appears to be holding water, which has very specific text change recommendations that appear to be straightforward to put into the specs. =20 Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems like the only outstanding issue raised so far is what is the exact text used in the RDMAP/DDP specs on what is a "valid" version number (i.e. do we leave it up to the vendor, or do we state something more explicit). That seems like a pretty small outstanding issue?=20 =20 Further, it seems like we should be able to get out updated drafts within a few days which incorporate the recommendations, and the recommendations do not have significant complexity to implement in the normative body of the specs (unlike the outstanding issue of normative statements in the security chapters of DDP/RDMAP (!!). =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C4D96E.DE7EADD6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree. The *most* that we might have to = change is to make=20 it clear that an
iWARP implementation *may* choose to = interoperate with the=20 RDMAC versions,
and that there is nothing in the main drafts = that forbids=20 this.
 
The requirements on what is a "valid" version = number is the=20 only thing that
might have to be clarified, so I think it is = doable. I also=20 do not think it is
necessary, since interoperability is extra = functionality=20 which has no impact
on the pure IETF protocol. But it is better to = be clear=20 that more liberal interpretation
of "valid" that enables interoperability *is* = legitimate=20 and even ever so slightly
encouraged (but probably not to the level of a=20 "should").
 

From: rddp-bounces@ietf.org=20 [mailto:rddp-bounces@ietf.org] On Behalf Of Jim=20 Pinkerton
Sent: Friday, December 03, 2004 5:52 = AM
To:=20 rddp@ietf.org
Subject: [rddp] last call before interop is=20 resolved?

 

I am very concerned that = the=20 current path we’re on is to try to do last call before we close = on the interop=20 issues with the RDMA Consortium protocols. To me this would be a = mistake=20 because it effectively fragments the market when in fact we have a = very=20 concrete interop proposal on the table that appears to be holding = water, which=20 has very specific text change recommendations that appear to be=20 straightforward to put into the specs.

 

Can we quickly get = through the=20 interop changes to MPA/DDP/RDMAP? Seems like the only outstanding = issue raised=20 so far is what is the exact text used in the RDMAP/DDP specs on what = is a=20 “valid” version number (i.e. do we leave it up to the = vendor, or do we state=20 something more explicit). That seems like a pretty small outstanding = issue?=20

 

Further, it seems like = we should=20 be able to get out updated drafts within a few days which incorporate = the=20 recommendations, and the recommendations do not have significant = complexity to=20 implement in the normative body of the specs (unlike the outstanding = issue of=20 normative statements in the security chapters of DDP/RDMAP=20 (!!).

 

 

Jim

 

 

 

------_=_NextPart_001_01C4D96E.DE7EADD6-- --===============0225685441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0225685441==-- From rddp-bounces@ietf.org Fri Dec 3 17:46:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15047 for ; Fri, 3 Dec 2004 17:46:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaMIP-0007kI-Et for rddp-web-archive@ietf.org; Fri, 03 Dec 2004 17:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLnR-0003qt-6E; Fri, 03 Dec 2004 17:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLNt-00018c-Kp for rddp@megatron.ietf.org; Fri, 03 Dec 2004 16:54:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09768 for ; Fri, 3 Dec 2004 16:54:35 -0500 (EST) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaLTc-000616-8C for rddp@ietf.org; Fri, 03 Dec 2004 17:00:38 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB3Lrsjd434764 for ; Fri, 3 Dec 2004 16:53:54 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB3LroMW280458 for ; Fri, 3 Dec 2004 14:53:50 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB3LroCD021575 for ; Fri, 3 Dec 2004 14:53:50 -0700 Received: from d03nm130.boulder.ibm.com (d03nm130.boulder.ibm.com [9.17.195.174]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB3LrokX021570; Fri, 3 Dec 2004 14:53:50 -0700 Subject: RE: [rddp] last call before interop is resolved? To: X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Fri, 3 Dec 2004 15:53:48 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 12/03/2004 14:53:49 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 27ec2ff0f5c3b18b49c722f4f1748838 Cc: Jim Pinkerton X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0431591328==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 --===============0431591328== Content-type: multipart/related; Boundary="0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790" --0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: multipart/alternative; Boundary="1__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790" --1__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 DQoNCg0KDQpJIGFncmVlLiAgSXQgc2VlbXMgdG8gbWUgdGhlIGNvbW11bml0eSB3b3VsZCBiZSBi ZXR0ZXIgc2VydmVkIGJ5IGFsbG93aW5nDQp0aGlzIGNob2ljZSwgIHZzICB0YWtpbmcgc3RlcHMg dG8gcHJldmVudCBpdC4NCg0KQWxzbywgIHRoZSBSRE1BUCBTZWN1cml0eSBzZWN0aW9uIGNoYW5n ZXMgYXJlIGRvbmUuICBCZXJuYXJkIE1ldHpsZXIgZnJvbQ0KSUJNIGNyZWF0ZWQgYW4gdXBkYXRl ZCB2ZXJzaW9uIG9mIHRoZSBSRE1BUCBTcGVjIHRoYXQgaW5jbHVkZXMgdGhlIGNoYW5nZXMNCmhp Z2hsaWdodGVkIGluIHRoZSBlLW1haWwgSSBzZW50IG9uIDExLzEzLCB3aXRoIGEgc3ViamVjdCBv ZiBbcmRkcF0gUkRNQVANClNlY3VyaXR5IFNlY3Rpb24uICBIb3dldmVyLCBiZWZvcmUgcG9zdGlu ZyB0aGF0IHZlcnNpb24gdG8gdGhlIFJERFANCnJlZmxlY3RvciwgSSB3YXMgd2FpdGluZyBmb3Ig KmFueSogcmVzcG9uc2Ugb24gdGhlIDExLzEzIGUtbWFpbC4gIEkgaGF2ZQ0Kbm90IHNlZW4gKmFu eSogcmVzcG9uc2Ugb24gdGhhdCBlLW1haWwuDQoNCklmIGZvbGtzIGNvdWxkIHBsZWFzZSByZXNw b25kIHRvIHRoYXQgZS1tYWlsIGFzIHdlbGwsICBJIHdvdWxkIGJlIGhhcHB5IHRvDQptYWtlIHRo aXMgdXBkYXRlIGFuZCBhbnkgYWRkaXRpb25hbCBSRE1BUCBTZWN1cml0eSBTZWN0aW9uIHVwZGF0 ZXMgbmV4dA0Kd2VlayBhbmQgcG9zdCB0aGUgcmVzdWx0IHRvIHRoZSByZWZsZWN0b3IuDQoNClJl bmF0byBKIFJlY2lvDQpDaGllZiBBcmNoaXRlY3QsIGVTZXJ2ZXIgSS9PDQpJQk0gRGlzdGluZ3Vp c2hlZCBFbmdpbmVlcg0KTWVtYmVyIElCTSBBY2FkZW15IG9mIFRlY2hub2xvZ3kNClRlbCA1MTIt ODM4LTM2ODUsIFQvTCA2NzgtMzY4NQ0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQogICAgICAgICAgICAgICAgICAgICAgIkNhaXRsaW4gQmVzdGxlciIgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICA8Y2Fp dGxpbmJAc2lsaXF1ZSAgICAgICAgVG86ICAgICAgICJKaW0gUGlua2VydG9uIiA8anBpbmtAd2lu ZG93cy5taWNyb3NvZnQuY29tPiwgPHJkZHBAaWV0Zi5vcmc+ICAgICAgICAgICAgICAgICAgICAg IA0KICAgICAgICAgICAgICAgICAgICAgIG50LmNvbT4gICAgICAgICAgICAgICAgICBjYzogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgU2Vu dCBieTogICAgICAgICAgICAgICAgIFN1YmplY3Q6ICBSRTogW3JkZHBdIGxhc3QgY2FsbCBiZWZv cmUgaW50ZXJvcCBpcyByZXNvbHZlZD8gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICByZGRwLWJvdW5jZXNAaWV0ZiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgIC5v cmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgIDEyLzAzLzIwMDQgMDE6MzQgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAg UE0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KDQoNCkkgYWdyZWUuIFRoZSAqbW9zdCogdGhhdCB3ZSBtaWdodCBoYXZlIHRv IGNoYW5nZSBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQNCmFuDQppV0FSUCBpbXBsZW1lbnRhdGlv biAqbWF5KiBjaG9vc2UgdG8gaW50ZXJvcGVyYXRlIHdpdGggdGhlIFJETUFDIHZlcnNpb25zLA0K YW5kIHRoYXQgdGhlcmUgaXMgbm90aGluZyBpbiB0aGUgbWFpbiBkcmFmdHMgdGhhdCBmb3JiaWRz IHRoaXMuDQoNClRoZSByZXF1aXJlbWVudHMgb24gd2hhdCBpcyBhICJ2YWxpZCIgdmVyc2lvbiBu dW1iZXIgaXMgdGhlIG9ubHkgdGhpbmcgdGhhdA0KbWlnaHQgaGF2ZSB0byBiZSBjbGFyaWZpZWQs IHNvIEkgdGhpbmsgaXQgaXMgZG9hYmxlLiBJIGFsc28gZG8gbm90IHRoaW5rIGl0DQppcw0KbmVj ZXNzYXJ5LCBzaW5jZSBpbnRlcm9wZXJhYmlsaXR5IGlzIGV4dHJhIGZ1bmN0aW9uYWxpdHkgd2hp Y2ggaGFzIG5vDQppbXBhY3QNCm9uIHRoZSBwdXJlIElFVEYgcHJvdG9jb2wuIEJ1dCBpdCBpcyBi ZXR0ZXIgdG8gYmUgY2xlYXIgdGhhdCBtb3JlIGxpYmVyYWwNCmludGVycHJldGF0aW9uDQpvZiAi dmFsaWQiIHRoYXQgZW5hYmxlcyBpbnRlcm9wZXJhYmlsaXR5ICppcyogbGVnaXRpbWF0ZSBhbmQg ZXZlbiBldmVyIHNvDQpzbGlnaHRseQ0KZW5jb3VyYWdlZCAoYnV0IHByb2JhYmx5IG5vdCB0byB0 aGUgbGV2ZWwgb2YgYSAic2hvdWxkIikuDQoNCg0KIEZyb206IHJkZHAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnJkZHAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQogSmltIFBpbmtl cnRvbg0KIFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDMsIDIwMDQgNTo1MiBBTQ0KIFRvOiByZGRw QGlldGYub3JnDQogU3ViamVjdDogW3JkZHBdIGxhc3QgY2FsbCBiZWZvcmUgaW50ZXJvcCBpcyBy ZXNvbHZlZD8NCg0KDQogSSBhbSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IHRoZSBjdXJyZW50IHBhdGgg d2XigJlyZSBvbiBpcyB0byB0cnkgdG8gZG8gbGFzdA0KIGNhbGwgYmVmb3JlIHdlIGNsb3NlIG9u IHRoZSBpbnRlcm9wIGlzc3VlcyB3aXRoIHRoZSBSRE1BIENvbnNvcnRpdW0NCiBwcm90b2NvbHMu IFRvIG1lIHRoaXMgd291bGQgYmUgYSBtaXN0YWtlIGJlY2F1c2UgaXQgZWZmZWN0aXZlbHkgZnJh Z21lbnRzDQogdGhlIG1hcmtldCB3aGVuIGluIGZhY3Qgd2UgaGF2ZSBhIHZlcnkgY29uY3JldGUg aW50ZXJvcCBwcm9wb3NhbCBvbiB0aGUNCiB0YWJsZSB0aGF0IGFwcGVhcnMgdG8gYmUgaG9sZGlu ZyB3YXRlciwgd2hpY2ggaGFzIHZlcnkgc3BlY2lmaWMgdGV4dA0KIGNoYW5nZSByZWNvbW1lbmRh dGlvbnMgdGhhdCBhcHBlYXIgdG8gYmUgc3RyYWlnaHRmb3J3YXJkIHRvIHB1dCBpbnRvIHRoZQ0K IHNwZWNzLg0KDQogQ2FuIHdlIHF1aWNrbHkgZ2V0IHRocm91Z2ggdGhlIGludGVyb3AgY2hhbmdl cyB0byBNUEEvRERQL1JETUFQPyBTZWVtcw0KIGxpa2UgdGhlIG9ubHkgb3V0c3RhbmRpbmcgaXNz dWUgcmFpc2VkIHNvIGZhciBpcyB3aGF0IGlzIHRoZSBleGFjdCB0ZXh0DQogdXNlZCBpbiB0aGUg UkRNQVAvRERQIHNwZWNzIG9uIHdoYXQgaXMgYSDigJx2YWxpZOKAnSB2ZXJzaW9uIG51bWJlciAo aS5lLiBkbw0KIHdlIGxlYXZlIGl0IHVwIHRvIHRoZSB2ZW5kb3IsIG9yIGRvIHdlIHN0YXRlIHNv bWV0aGluZyBtb3JlIGV4cGxpY2l0KS4NCiBUaGF0IHNlZW1zIGxpa2UgYSBwcmV0dHkgc21hbGwg b3V0c3RhbmRpbmcgaXNzdWU/DQoNCiBGdXJ0aGVyLCBpdCBzZWVtcyBsaWtlIHdlIHNob3VsZCBi ZSBhYmxlIHRvIGdldCBvdXQgdXBkYXRlZCBkcmFmdHMgd2l0aGluDQogYSBmZXcgZGF5cyB3aGlj aCBpbmNvcnBvcmF0ZSB0aGUgcmVjb21tZW5kYXRpb25zLCBhbmQgdGhlIHJlY29tbWVuZGF0aW9u cw0KIGRvIG5vdCBoYXZlIHNpZ25pZmljYW50IGNvbXBsZXhpdHkgdG8gaW1wbGVtZW50IGluIHRo ZSBub3JtYXRpdmUgYm9keSBvZg0KIHRoZSBzcGVjcyAodW5saWtlIHRoZSBvdXRzdGFuZGluZyBp c3N1ZSBvZiBub3JtYXRpdmUgc3RhdGVtZW50cyBpbiB0aGUNCiBzZWN1cml0eSBjaGFwdGVycyBv ZiBERFAvUkRNQVAgKCEhKS4NCg0KDQogSmltDQoNCg0KICBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KIHJkZHAgbWFpbGluZyBsaXN0DQogcmRkcEBpZXRm Lm9yZw0KIGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JkZHANCg0K --1__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: text/html; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHk+DQo8cD5JIGFncmVlLiAgSXQgc2VlbXMgdG8gbWUgdGhlIGNvbW11bml0eSB3 b3VsZCBiZSBiZXR0ZXIgc2VydmVkIGJ5IGFsbG93aW5nIHRoaXMgY2hvaWNlLCAgdnMgIHRha2lu ZyBzdGVwcyB0byBwcmV2ZW50IGl0Ljxicj4NCjxicj4NCkFsc28sICB0aGUgUkRNQVAgU2VjdXJp dHkgc2VjdGlvbiBjaGFuZ2VzIGFyZSBkb25lLiAgQmVybmFyZCBNZXR6bGVyIGZyb20gSUJNIGNy ZWF0ZWQgYW4gdXBkYXRlZCB2ZXJzaW9uIG9mIHRoZSBSRE1BUCBTcGVjIHRoYXQgaW5jbHVkZXMg dGhlIGNoYW5nZXMgaGlnaGxpZ2h0ZWQgaW4gdGhlIGUtbWFpbCBJIHNlbnQgb24gMTEvMTMsIHdp dGggYSBzdWJqZWN0IG9mIFtyZGRwXSBSRE1BUCBTZWN1cml0eSBTZWN0aW9uLiAgSG93ZXZlciwg YmVmb3JlIHBvc3RpbmcgdGhhdCB2ZXJzaW9uIHRvIHRoZSBSRERQIHJlZmxlY3RvciwgSSB3YXMg d2FpdGluZyBmb3IgKmFueSogcmVzcG9uc2Ugb24gdGhlIDExLzEzIGUtbWFpbC4gIEkgaGF2ZSBu b3Qgc2VlbiAqYW55KiByZXNwb25zZSBvbiB0aGF0IGUtbWFpbC48YnI+DQo8YnI+DQpJZiBmb2xr cyBjb3VsZCBwbGVhc2UgcmVzcG9uZCB0byB0aGF0IGUtbWFpbCBhcyB3ZWxsLCAgSSB3b3VsZCBi ZSBoYXBweSB0byBtYWtlIHRoaXMgdXBkYXRlIGFuZCBhbnkgYWRkaXRpb25hbCBSRE1BUCBTZWN1 cml0eSBTZWN0aW9uIHVwZGF0ZXMgbmV4dCB3ZWVrIGFuZCBwb3N0IHRoZSByZXN1bHQgdG8gdGhl IHJlZmxlY3Rvci48YnI+DQo8YnI+DQpSZW5hdG8gSiBSZWNpbzxicj4NCkNoaWVmIEFyY2hpdGVj dCwgZVNlcnZlciBJL088YnI+DQpJQk0gRGlzdGluZ3Vpc2hlZCBFbmdpbmVlcjxicj4NCk1lbWJl ciBJQk0gQWNhZGVteSBvZiBUZWNobm9sb2d5PGJyPg0KVGVsIDUxMi04MzgtMzY4NSwgVC9MIDY3 OC0zNjg1PGJyPg0KPGJyPg0KPGltZyBzcmM9ImNpZDoxMF9fPTA5QkJFNUNDREZFNDI3OTA4Zjll OGE5M2RmOTM4QHVzLmlibS5jb20iIHdpZHRoPSIxNiIgaGVpZ2h0PSIxNiIgYWx0PSJJbmFjdGl2 ZSBoaWRlIGRldGFpbHMgZm9yICZxdW90O0NhaXRsaW4gQmVzdGxlciZxdW90OyAmbHQ7Y2FpdGxp bmJAc2lsaXF1ZW50LmNvbSZndDsiPiZxdW90O0NhaXRsaW4gQmVzdGxlciZxdW90OyAmbHQ7Y2Fp dGxpbmJAc2lsaXF1ZW50LmNvbSZndDs8YnI+DQo8YnI+DQo8YnI+DQoNCjx0YWJsZSBWNURPVEJM PXRydWUgd2lkdGg9IjEwMCUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5n PSIwIj4NCjx0ciB2YWxpZ249InRvcCI+PHRkIHdpZHRoPSIxJSI+PGltZyBzcmM9ImNpZDoyMF9f PTA5QkJFNUNDREZFNDI3OTA4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgaGVp Z2h0PSIxIiB3aWR0aD0iNzIiIGFsdD0iIj48YnI+DQo8L3RkPjx0ZCBzdHlsZT0iYmFja2dyb3Vu ZC1pbWFnZTp1cmwoY2lkOjMwX189MDlCQkU1Q0NERkU0Mjc5MDhmOWU4YTkzZGY5MzhAdXMuaWJt LmNvbSk7IGJhY2tncm91bmQtcmVwZWF0OiBuby1yZXBlYXQ7ICIgd2lkdGg9IjElIj48aW1nIHNy Yz0iY2lkOjIwX189MDlCQkU1Q0NERkU0Mjc5MDhmOWU4YTkzZGY5MzhAdXMuaWJtLmNvbSIgYm9y ZGVyPSIwIiBoZWlnaHQ9IjEiIHdpZHRoPSIyMjUiIGFsdD0iIj48YnI+DQoNCjx1bD4NCjx1bD4N Cjx1bD4NCjx1bD48Yj48Zm9udCBzaXplPSIyIj4mcXVvdDtDYWl0bGluIEJlc3RsZXImcXVvdDsg Jmx0O2NhaXRsaW5iQHNpbGlxdWVudC5jb20mZ3Q7PC9mb250PjwvYj48YnI+DQo8Zm9udCBzaXpl PSIyIj5TZW50IGJ5OiByZGRwLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PSIyIj4xMi8wMy8yMDA0IDAxOjM0IFBNPC9mb250PjwvdWw+DQo8L3VsPg0KPC91bD4NCjwvdWw+ DQo8L3RkPjx0ZCB3aWR0aD0iMTAwJSI+PGltZyBzcmM9ImNpZDoyMF9fPTA5QkJFNUNDREZFNDI3 OTA4ZjllOGE5M2RmOTM4QHVzLmlibS5jb20iIGJvcmRlcj0iMCIgaGVpZ2h0PSIxIiB3aWR0aD0i MSIgYWx0PSIiPjxicj4NCjxmb250IHNpemU9IjEiIGZhY2U9IkFyaWFsIj4JPC9mb250Pjxicj4N Cjxmb250IHNpemU9IjIiPglUbzoJPC9mb250Pjxmb250IHNpemU9IjIiPiZxdW90O0ppbSBQaW5r ZXJ0b24mcXVvdDsgJmx0O2pwaW5rQHdpbmRvd3MubWljcm9zb2Z0LmNvbSZndDssICZsdDtyZGRw QGlldGYub3JnJmd0OzwvZm9udD48YnI+DQo8Zm9udCBzaXplPSIyIj4JY2M6CTwvZm9udD48YnI+ DQo8Zm9udCBzaXplPSIyIj4JU3ViamVjdDoJPC9mb250Pjxmb250IHNpemU9IjIiPlJFOiBbcmRk cF0gbGFzdCBjYWxsIGJlZm9yZSBpbnRlcm9wIGlzIHJlc29sdmVkPzwvZm9udD48L3RkPjwvdHI+ DQo8L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwRkYiIGZhY2U9IkFyaWFs Ij5JIGFncmVlLiBUaGUgKm1vc3QqIHRoYXQgd2UgbWlnaHQgaGF2ZSB0byBjaGFuZ2UgaXMgdG8g bWFrZSBpdCBjbGVhciB0aGF0IGFuPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMEZGIiBm YWNlPSJBcmlhbCI+aVdBUlAgaW1wbGVtZW50YXRpb24gKm1heSogY2hvb3NlIHRvIGludGVyb3Bl cmF0ZSB3aXRoIHRoZSBSRE1BQyB2ZXJzaW9ucyw8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMw MDAwRkYiIGZhY2U9IkFyaWFsIj5hbmQgdGhhdCB0aGVyZSBpcyBub3RoaW5nIGluIHRoZSBtYWlu IGRyYWZ0cyB0aGF0IGZvcmJpZHMgdGhpcy48L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6ZT0iNCIgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAwMEZGIiBm YWNlPSJBcmlhbCI+VGhlIHJlcXVpcmVtZW50cyBvbiB3aGF0IGlzIGEgJnF1b3Q7dmFsaWQmcXVv dDsgdmVyc2lvbiBudW1iZXIgaXMgdGhlIG9ubHkgdGhpbmcgdGhhdDwvZm9udD48YnI+DQo8Zm9u dCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0iQXJpYWwiPm1pZ2h0IGhhdmUgdG8gYmUgY2xhcmlmaWVk LCBzbyBJIHRoaW5rIGl0IGlzIGRvYWJsZS4gSSBhbHNvIGRvIG5vdCB0aGluayBpdCBpczwvZm9u dD48YnI+DQo8Zm9udCBjb2xvcj0iIzAwMDBGRiIgZmFjZT0iQXJpYWwiPm5lY2Vzc2FyeSwgc2lu Y2UgaW50ZXJvcGVyYWJpbGl0eSBpcyBleHRyYSBmdW5jdGlvbmFsaXR5IHdoaWNoIGhhcyBubyBp bXBhY3Q8L2ZvbnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwRkYiIGZhY2U9IkFyaWFsIj5vbiB0 aGUgcHVyZSBJRVRGIHByb3RvY29sLiBCdXQgaXQgaXMgYmV0dGVyIHRvIGJlIGNsZWFyIHRoYXQg bW9yZSBsaWJlcmFsIGludGVycHJldGF0aW9uPC9mb250Pjxicj4NCjxmb250IGNvbG9yPSIjMDAw MEZGIiBmYWNlPSJBcmlhbCI+b2YgJnF1b3Q7dmFsaWQmcXVvdDsgdGhhdCBlbmFibGVzIGludGVy b3BlcmFiaWxpdHkgKmlzKiBsZWdpdGltYXRlIGFuZCBldmVuIGV2ZXIgc28gc2xpZ2h0bHk8L2Zv bnQ+PGJyPg0KPGZvbnQgY29sb3I9IiMwMDAwRkYiIGZhY2U9IkFyaWFsIj5lbmNvdXJhZ2VkIChi dXQgcHJvYmFibHkgbm90IHRvIHRoZSBsZXZlbCBvZiBhICZxdW90O3Nob3VsZCZxdW90OykuPC9m b250Pjxicj4NCjxmb250IHNpemU9IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48 YnI+DQo8YnI+DQo8aHIgd2lkdGg9IjEwMCUiIHNpemU9IjIiIGFsaWduPSJsZWZ0Ij48Yj48Zm9u dCBmYWNlPSJUYWhvbWEiPkZyb206PC9mb250PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEiPiByZGRw LWJvdW5jZXNAaWV0Zi5vcmcgWzxhIGhyZWY9Im1haWx0bzpyZGRwLWJvdW5jZXNAaWV0Zi5vcmci Pm1haWx0bzpyZGRwLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8L2ZvbnQ+PGI+PGZvbnQgZmFjZT0i VGFob21hIj5PbiBCZWhhbGYgT2YgPC9mb250PjwvYj48Zm9udCBmYWNlPSJUYWhvbWEiPkppbSBQ aW5rZXJ0b248L2ZvbnQ+PGI+PGZvbnQgZmFjZT0iVGFob21hIj48YnI+DQpTZW50OjwvZm9udD48 L2I+PGZvbnQgZmFjZT0iVGFob21hIj4gRnJpZGF5LCBEZWNlbWJlciAwMywgMjAwNCA1OjUyIEFN PC9mb250PjxiPjxmb250IGZhY2U9IlRhaG9tYSI+PGJyPg0KVG86PC9mb250PjwvYj48Zm9udCBm YWNlPSJUYWhvbWEiPiByZGRwQGlldGYub3JnPC9mb250PjxiPjxmb250IGZhY2U9IlRhaG9tYSI+ PGJyPg0KU3ViamVjdDo8L2ZvbnQ+PC9iPjxmb250IGZhY2U9IlRhaG9tYSI+IFtyZGRwXSBsYXN0 IGNhbGwgYmVmb3JlIGludGVyb3AgaXMgcmVzb2x2ZWQ/PC9mb250Pjxmb250IHNpemU9IjQiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxicj4NCjxmb250IHNpemU9IjQiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48YnI+DQo8Zm9udCBmYWNlPSJBcmlhbCI+SSBh bSB2ZXJ5IGNvbmNlcm5lZCB0aGF0IHRoZSBjdXJyZW50IHBhdGggd2XigJlyZSBvbiBpcyB0byB0 cnkgdG8gZG8gbGFzdCBjYWxsIGJlZm9yZSB3ZSBjbG9zZSBvbiB0aGUgaW50ZXJvcCBpc3N1ZXMg d2l0aCB0aGUgUkRNQSBDb25zb3J0aXVtIHByb3RvY29scy4gVG8gbWUgdGhpcyB3b3VsZCBiZSBh IG1pc3Rha2UgYmVjYXVzZSBpdCBlZmZlY3RpdmVseSBmcmFnbWVudHMgdGhlIG1hcmtldCB3aGVu IGluIGZhY3Qgd2UgaGF2ZSBhIHZlcnkgY29uY3JldGUgaW50ZXJvcCBwcm9wb3NhbCBvbiB0aGUg dGFibGUgdGhhdCBhcHBlYXJzIHRvIGJlIGhvbGRpbmcgd2F0ZXIsIHdoaWNoIGhhcyB2ZXJ5IHNw ZWNpZmljIHRleHQgY2hhbmdlIHJlY29tbWVuZGF0aW9ucyB0aGF0IGFwcGVhciB0byBiZSBzdHJh aWdodGZvcndhcmQgdG8gcHV0IGludG8gdGhlIHNwZWNzLjwvZm9udD48YnI+DQo8Zm9udCBzaXpl PSI0IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGJyPg0KPGZvbnQgZmFjZT0iQXJp YWwiPkNhbiB3ZSBxdWlja2x5IGdldCB0aHJvdWdoIHRoZSBpbnRlcm9wIGNoYW5nZXMgdG8gTVBB L0REUC9SRE1BUD8gU2VlbXMgbGlrZSB0aGUgb25seSBvdXRzdGFuZGluZyBpc3N1ZSByYWlzZWQg c28gZmFyIGlzIHdoYXQgaXMgdGhlIGV4YWN0IHRleHQgdXNlZCBpbiB0aGUgUkRNQVAvRERQIHNw ZWNzIG9uIHdoYXQgaXMgYSDigJx2YWxpZOKAnSB2ZXJzaW9uIG51bWJlciAoaS5lLiBkbyB3ZSBs ZWF2ZSBpdCB1cCB0byB0aGUgdmVuZG9yLCBvciBkbyB3ZSBzdGF0ZSBzb21ldGhpbmcgbW9yZSBl eHBsaWNpdCkuIFRoYXQgc2VlbXMgbGlrZSBhIHByZXR0eSBzbWFsbCBvdXRzdGFuZGluZyBpc3N1 ZT8gPC9mb250Pjxicj4NCjxmb250IHNpemU9IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwv Zm9udD48YnI+DQo8Zm9udCBmYWNlPSJBcmlhbCI+RnVydGhlciwgaXQgc2VlbXMgbGlrZSB3ZSBz aG91bGQgYmUgYWJsZSB0byBnZXQgb3V0IHVwZGF0ZWQgZHJhZnRzIHdpdGhpbiBhIGZldyBkYXlz IHdoaWNoIGluY29ycG9yYXRlIHRoZSByZWNvbW1lbmRhdGlvbnMsIGFuZCB0aGUgcmVjb21tZW5k YXRpb25zIGRvIG5vdCBoYXZlIHNpZ25pZmljYW50IGNvbXBsZXhpdHkgdG8gaW1wbGVtZW50IGlu IHRoZSBub3JtYXRpdmUgYm9keSBvZiB0aGUgc3BlY3MgKHVubGlrZSB0aGUgb3V0c3RhbmRpbmcg aXNzdWUgb2Ygbm9ybWF0aXZlIHN0YXRlbWVudHMgaW4gdGhlIHNlY3VyaXR5IGNoYXB0ZXJzIG9m IEREUC9SRE1BUCAoISEpLjwvZm9udD48YnI+DQo8Zm9udCBzaXplPSI0IiBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPiA8L2ZvbnQ+PGJyPg0KPGZvbnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4gPC9mb250Pjxicj4NCjxmb250IGZhY2U9IkFyaWFsIj5KaW08L2ZvbnQ+PGJyPg0KPGZv bnQgc2l6ZT0iNCIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxicj4NCjxmb250IHNp emU9IjQiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48YnI+DQo8Zm9udCBzaXplPSI0 IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgZmFjZT0iQ291cmllciBOZXci Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KcmRk cCBtYWlsaW5nIGxpc3Q8YnI+DQpyZGRwQGlldGYub3JnPGJyPg0KPC9mb250Pjxmb250IGZhY2U9 IkNvdXJpZXIgTmV3Ij48YSBocmVmPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9yZGRwIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZGRwPC9h PjwvZm9udD48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPC9mb250Pg0KDQo8L2JvZHk+ PC9odG1sPg== --1__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790-- --0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE5CCDFE427908f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE5CCDFE427908f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790 Content-type: image/gif; name="pic22418.gif" Content-Disposition: inline; filename="pic22418.gif" Content-ID: <30__=09BBE5CCDFE427908f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE5CCDFE427908f9e8a93df938690918c09BBE5CCDFE42790-- --===============0431591328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0431591328==-- From rddp-bounces@ietf.org Sat Dec 4 18:57:52 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03330 for ; Sat, 4 Dec 2004 18:57:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cajso-0003Le-7k for rddp-web-archive@ietf.org; Sat, 04 Dec 2004 19:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caj6t-0006Iq-MD; Sat, 04 Dec 2004 18:14:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Caibj-0001Eg-S0 for rddp@megatron.ietf.org; Sat, 04 Dec 2004 17:42:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27290 for ; Sat, 4 Dec 2004 17:42:24 -0500 (EST) Received: from palrel11.hp.com ([156.153.255.246]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Caiha-0001tb-DI for rddp@ietf.org; Sat, 04 Dec 2004 17:48:41 -0500 Received: from esmail.cup.hp.com (esmail.cup.hp.com [15.0.65.164]) by palrel11.hp.com (Postfix) with ESMTP id EA39620657 for ; Sat, 4 Dec 2004 14:42:09 -0800 (PST) Received: from MK73191c.cup.hp.com ([15.244.201.58]) by esmail.cup.hp.com (8.9.3 (PHNE_29774)/8.8.6) with ESMTP id OAA15660 for ; Sat, 4 Dec 2004 14:39:26 -0800 (PST) Message-Id: <6.1.2.0.2.20041204143344.01ed0270@esmail.cup.hp.com> X-Sender: krause@esmail.cup.hp.com X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 04 Dec 2004 14:35:14 -0800 To: From: Michael Krause Subject: Re: [rddp] last call before interop is resolved? In-Reply-To: References: Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1721506095==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 --===============1721506095== Content-Type: multipart/alternative; boundary="=====================_21333916==.ALT" --=====================_21333916==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I concur. We need to get a good handle on interoperability since there will be a time differential between the two sets of specs relative to deployment. The draft proposal makes a good start on how to document the minor changes required to resolve this issue. Therefore, we should drive to get closure no later than January which should have minimum impact on last call. Mike At 05:51 AM 12/3/2004, Jim Pinkerton wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C4D93F.32F78B0F" > > >I am very concerned that the current path we're on is to try to do last >call before we close on the interop issues with the RDMA Consortium >protocols. To me this would be a mistake because it effectively fragments >the market when in fact we have a very concrete interop proposal on the >table that appears to be holding water, which has very specific text >change recommendations that appear to be straightforward to put into the specs. > >Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems >like the only outstanding issue raised so far is what is the exact text >used in the RDMAP/DDP specs on what is a "valid" version number (i.e. do >we leave it up to the vendor, or do we state something more explicit). >That seems like a pretty small outstanding issue? > >Further, it seems like we should be able to get out updated drafts within >a few days which incorporate the recommendations, and the recommendations >do not have significant complexity to implement in the normative body of >the specs (unlike the outstanding issue of normative statements in the >security chapters of DDP/RDMAP (!!). > > >Jim > > > >_______________________________________________ >rddp mailing list >rddp@ietf.org >https://www1.ietf.org/mailman/listinfo/rddp --=====================_21333916==.ALT Content-Type: text/html; charset="us-ascii" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id RAA27290 Content-Transfer-Encoding: quoted-printable
I concur.  We need to get a good handle on interoperability since there will be a time differential between the two sets of specs relative to deployment.  The draft proposal makes a good start on how to document the minor changes required to resolve this issue.  Therefore, we should drive to get closure no later than January which should have minimum impact on last call.

Mike


At 05:51 AM 12/3/2004, Jim Pinkerton wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
        boundary=3D= "----_=3D_NextPart_001_01C4D93F.32F78B0F"

 
I am very concerned that the current path we=92re on is to try to do last call before we close on the interop issues with the RDMA Consortium protocols. To me this would be a mistake because it effectively fragments the market when in fact we have a very concrete interop proposal on the table that appears to be holding water, which has very specific text change recommendations that appear to be straightforward to put into the specs.
 
Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems like the only outstanding issue raised so far is what is the exact text used in the RDMAP/DDP specs on what is a =93valid=94 version number (i.e.= do we leave it up to the vendor, or do we state something more explicit). That seems like a pretty small outstanding issue?
 
Further, it seems like we should be able to get out updated drafts within a few days which incorporate the recommendations, and the recommendations do not have significant complexity to implement in the normative body of the specs (unlike the outstanding issue of normative statements in the security chapters of DDP/RDMAP (!!).
 
 
Jim
 
 
 
_______________________________________________
rddp mailing list
rddp@ietf.org
https://www1.ietf.org/mailman/listinfo/rddp
--=====================_21333916==.ALT-- --===============1721506095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1721506095==-- From rddp-bounces@ietf.org Sat Dec 4 19:58:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06099 for ; Sat, 4 Dec 2004 19:58:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CakpT-0004RI-UO for rddp-web-archive@ietf.org; Sat, 04 Dec 2004 20:04:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CakHT-0002Ec-PI; Sat, 04 Dec 2004 19:29:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CajoI-0002Pv-79 for rddp@megatron.ietf.org; Sat, 04 Dec 2004 18:59:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03432 for ; Sat, 4 Dec 2004 18:59:26 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CajuK-0003Mt-JB for rddp@ietf.org; Sat, 04 Dec 2004 19:05:45 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB4NwwFJ269448 for ; Sat, 4 Dec 2004 18:58:58 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB4NwwWP447564 for ; Sat, 4 Dec 2004 16:58:58 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB4Nwwo3028020 for ; Sat, 4 Dec 2004 16:58:58 -0700 Received: from d03nm130.boulder.ibm.com (d03nm130.boulder.ibm.com [9.17.195.174]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB4NwvbJ028015 for ; Sat, 4 Dec 2004 16:58:57 -0700 To: X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Sat, 4 Dec 2004 17:58:56 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 12/04/2004 16:58:57 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [rddp] RDMAP Security Section Update X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0335176310==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 --===============0335176310== Content-type: multipart/alternative; Boundary="0__=09BBE5F3DF117D078f9e8a93df938690918c09BBE5F3DF117D07" Content-Disposition: inline --0__=09BBE5F3DF117D078f9e8a93df938690918c09BBE5F3DF117D07 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Folks, Given the updates to the RDMA Protocol Specification's Security Section= s are rather extensive, we decided to post an update to the RDMAP Specification containing the Security Section changes, so that folks ca= n begin reviewing the new text. We will post a subsequent update, that includes any changes from the Security Section review and informative t= ext regarding IETF v1 interoperability with RDMAC v0. Our goal is to post = the second update in time for the Spring IETF meeting. Thanks, Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685= --0__=09BBE5F3DF117D078f9e8a93df938690918c09BBE5F3DF117D07 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Folks,

Given the updates to the RDMA Protocol Specification's Security Section= s are rather extensive, we decided to post an update to the RDMAP Spec= ification containing the Security Section changes, so that folks can be= gin reviewing the new text. We will post a subsequent update, that inc= ludes any changes from the Security Section review and informative text= regarding IETF v1 interoperability with RDMAC v0. Our goal is to post= the second update in time for the Spring IETF meeting.

Thanks,

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685
= --0__=09BBE5F3DF117D078f9e8a93df938690918c09BBE5F3DF117D07-- --===============0335176310== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0335176310==-- From rddp-bounces@ietf.org Tue Dec 7 10:21:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12792 for ; Tue, 7 Dec 2004 10:21:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbhGP-0006LX-Gf for rddp-web-archive@ietf.org; Tue, 07 Dec 2004 10:28:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbh22-0002C7-ND; Tue, 07 Dec 2004 10:13:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbguQ-0000CR-Ap for rddp@megatron.ietf.org; Tue, 07 Dec 2004 10:05:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10660 for ; Tue, 7 Dec 2004 10:05:44 -0500 (EST) Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbh10-0005wW-1r for rddp@ietf.org; Tue, 07 Dec 2004 10:12:34 -0500 Received: from cceexg12.americas.cpqcorp.net (cceexg12.americas.cpqcorp.net [16.81.1.38]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id B6AB8E48 for ; Tue, 7 Dec 2004 09:05:13 -0600 (CST) Received: from cceexc15.americas.cpqcorp.net ([16.81.1.40]) by cceexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 7 Dec 2004 09:05:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [rddp] last call before interop is resolved? Date: Tue, 7 Dec 2004 09:05:11 -0600 Message-ID: Thread-Topic: [rddp] last call before interop is resolved? Thread-Index: AcTZPzHIvgwhMPZ5TC6JxbfGlRChtQC4UapA From: "Barron, Dwight" To: "Jim Pinkerton" , X-OriginalArrivalTime: 07 Dec 2004 15:05:12.0557 (UTC) FILETIME=[269D41D0:01C4DC6E] X-Spam-Score: 0.6 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0018072821==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba This is a multi-part message in MIME format. --===============0018072821== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC6E.2633B1E2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4DC6E.2633B1E2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point Jim. I agree. A very small amount of work now (most of which you and John have already done) will remove ambiguities that would otherwise confuse those trying create interoperability tests and linger on for at least one generation.=20 =20 Regards, Dwight ________________________________ From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of Jim Pinkerton Sent: Friday, December 03, 2004 7:52 AM To: rddp@ietf.org Subject: [rddp] last call before interop is resolved? =09 =09 =20 I am very concerned that the current path we're on is to try to do last call before we close on the interop issues with the RDMA Consortium protocols. To me this would be a mistake because it effectively fragments the market when in fact we have a very concrete interop proposal on the table that appears to be holding water, which has very specific text change recommendations that appear to be straightforward to put into the specs. =20 Can we quickly get through the interop changes to MPA/DDP/RDMAP? Seems like the only outstanding issue raised so far is what is the exact text used in the RDMAP/DDP specs on what is a "valid" version number (i.e. do we leave it up to the vendor, or do we state something more explicit). That seems like a pretty small outstanding issue?=20 =20 Further, it seems like we should be able to get out updated drafts within a few days which incorporate the recommendations, and the recommendations do not have significant complexity to implement in the normative body of the specs (unlike the outstanding issue of normative statements in the security chapters of DDP/RDMAP (!!). =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C4DC6E.2633B1E2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good point Jim. I agree. A very small amount of = work now=20 (most of which you and John have already done) will remove ambiguities = that=20 would otherwise confuse those trying create interoperability tests and=20 linger on for at least one generation.
 
Regards,
Dwight

From: rddp-bounces@ietf.org=20 [mailto:rddp-bounces@ietf.org] On Behalf Of Jim=20 Pinkerton
Sent: Friday, December 03, 2004 7:52 = AM
To:=20 rddp@ietf.org
Subject: [rddp] last call before interop is=20 resolved?

 

I am very concerned that = the=20 current path we’re on is to try to do last call before we close = on the interop=20 issues with the RDMA Consortium protocols. To me this would be a = mistake=20 because it effectively fragments the market when in fact we have a = very=20 concrete interop proposal on the table that appears to be holding = water, which=20 has very specific text change recommendations that appear to be=20 straightforward to put into the specs.

 

Can we quickly get = through the=20 interop changes to MPA/DDP/RDMAP? Seems like the only outstanding = issue raised=20 so far is what is the exact text used in the RDMAP/DDP specs on what = is a=20 “valid” version number (i.e. do we leave it up to the = vendor, or do we state=20 something more explicit). That seems like a pretty small outstanding = issue?=20

 

Further, it seems like = we should=20 be able to get out updated drafts within a few days which incorporate = the=20 recommendations, and the recommendations do not have significant = complexity to=20 implement in the normative body of the specs (unlike the outstanding = issue of=20 normative statements in the security chapters of DDP/RDMAP=20 (!!).

 

 

Jim

 

 

 

------_=_NextPart_001_01C4DC6E.2633B1E2-- --===============0018072821== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0018072821==-- From rddp-bounces@ietf.org Wed Dec 8 01:45:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23926 for ; Wed, 8 Dec 2004 01:45:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbvgp-0005Yo-68 for rddp-web-archive@ietf.org; Wed, 08 Dec 2004 01:52:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbvTC-0000RE-N7; Wed, 08 Dec 2004 01:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbvOY-0007M3-7y for rddp@megatron.ietf.org; Wed, 08 Dec 2004 01:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23346 for ; Wed, 8 Dec 2004 01:33:49 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbvVH-0005Kk-1I for rddp@ietf.org; Wed, 08 Dec 2004 01:40:47 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iB86XkAf006846; Wed, 8 Dec 2004 01:33:46 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Dec 2004 01:33:46 -0500 Message-ID: To: sganguly@yahoo.com, rddp@ietf.org Date: Wed, 8 Dec 2004 01:33:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.12.7.19 X-PerlMx-Spam: Gauge=, SPAM=7%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, TO_HAS_SPACES 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __MIME_TEXT_ONLY 0' X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [rddp] IPsec X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 IPsec with encryption alone provides no integrity protection (if the ciphertext is modified, junk is decrypted); this is not a good idea, as there a need for integrity protection usually accompanies needs for encryption. For some forms of encryption, the cipher doesn't scramble bits (each bit of ciphertext depends on only the corresponding bit of plaintext), and hence integrity protection is needed to prevent ciphertext changes that have predictable plaintext effects. AES counter-mode is one example. Thanks, --David > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On > Behalf Of Sukanta ganguly > Sent: Tuesday, November 30, 2004 10:21 AM > To: Michael C. Cambria; RDDP > Subject: Re: [rddp] Need some clarification on how to "locate > the start of theFPDU unambiguously" > > MikeC, > IPSec with encryption will also attain the same > level of integrity and hence it should be OK. > Encryption based on IPSec is a much better mechanism > rather than just CRC32c. > I am not sure what you mean by "negotiating the > policy down". Once the IPSec connection with the > remote pair is established that is your policy, which > is established at the time of connection setup. > > SG > > --- "Michael C. Cambria" wrote: > > > > > > > Caitlin Bestler wrote: > > > > > Keep in mind that "CRC suppression" does not > > eliminate the field, > > > only generating it and checking it. > > > > > > So my reading has always been that when CRCs are > > "suppressed" > > > that the CRC field is always "valid". > > > > This has been my assumption as well. > > > > > Given the scenarios identified for suppressing > > CRCs, when there > > > is equivalent protection from IPSEC or something > > else, I think > > > it is also clear that this was the intent. > > > > Since I'm on the subject of making assumptions > > explicit... > > > > When IPsec is mentioned in this context, doesn't it > > specifically mean > > IPsec with Authentication (or Authentication & > > Encryption)? IPsec with > > Encryption alone isn't a substitute for CRC32c. > > > > This is also assuming that the IPsec SPD is setup to > > ensure that this > > policy will happen, e.g. there is no way for the > > remote peer to > > negotiate the security policy "down". > > > > Regards, > > MikeC > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - Helps protect you from nasty viruses. > http://promotions.yahoo.com/new_mail > > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp > _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Dec 8 01:47:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24262 for ; Wed, 8 Dec 2004 01:47:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbviu-0005d7-KZ for rddp-web-archive@ietf.org; Wed, 08 Dec 2004 01:54:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbvbI-0002Hp-Jm; Wed, 08 Dec 2004 01:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbvXO-0001NY-QS for rddp@megatron.ietf.org; Wed, 08 Dec 2004 01:42:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23727 for ; Wed, 8 Dec 2004 01:42:57 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbve5-0005UQ-MK for rddp@ietf.org; Wed, 08 Dec 2004 01:49:55 -0500 Received: from MAHO3MSX2.corp.emc.com (maho3msx2.corp.emc.com [128.221.11.32]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id iB86gsAX003147 for ; Wed, 8 Dec 2004 01:42:54 -0500 (EST) Received: by maho3msx2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Dec 2004 01:42:54 -0500 Message-ID: To: rddp@ietf.org Subject: RE: [rddp] Draft progress & schedule Date: Wed, 8 Dec 2004 01:42:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PMX-Version: 4.6.1.107272, Antispam-Core: 4.6.1.106808, Antispam-Data: 2004.12.7.19 X-PerlMx-Spam: Gauge=, SPAM=0%, Report='EMC_FROM_0 -0, __TLG_EMC_ENVFROM_0 0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 > (2) I want to see ready-for-WG-Last-Call versions of the > DDP, RDMAP, and Security drafts by the end of next > week (submit them to the secretariat by Fri, Dec 3 > and cc: me on the submission email). This is so > that this WG Last Call can be finished before the > end-of-December holidays divert everyone's attention. I think I see rough consensus on the list to delay WG Last Call in order to get the interoperability appendices into the drafts. This needs to be concluded a lot faster than just before the Spring IETF meeting - I would encourage the group to work out what's needed on the list in the next week or so, and plan to submit drafts that can be last called by early January. I just had to slip the WG milestones on the IETF web site by a year (they're not updated yet) - if these have to be slipped again, our AD may start to wonder whether this WG should continue. Thanks, --David (WG chair) ---------------------------------------------------- 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 From rddp-bounces@ietf.org Wed Dec 8 02:09:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05143 for ; Wed, 8 Dec 2004 02:09:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cbw47-00060h-Hw for rddp-web-archive@ietf.org; Wed, 08 Dec 2004 02:16:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CbvwN-00017Y-AX; Wed, 08 Dec 2004 02:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbvpo-0005qg-Km for rddp@megatron.ietf.org; Wed, 08 Dec 2004 02:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27000 for ; Wed, 8 Dec 2004 02:01:58 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CbvwT-0005rH-Ud for rddp@ietf.org; Wed, 08 Dec 2004 02:08:57 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Draft progress & schedule MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Dec 2004 23:03:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Message-ID: Thread-Topic: [rddp] Draft progress & schedule Thread-Index: AcTc8eO3NBeSw4SfQ0ugpJZWmA89/AAAZBgg From: "Caitlin Bestler" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable I'm David is also considering that we need to get *two*=20 rounds of WG Last Call -- the adaptation layer and applicability drafts will follow DDP/RDMAP/Security and we need to squeeze them in after than and before The next IETF. > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Black_David@emc.com > Sent: Tuesday, December 07, 2004 10:43 PM > To: rddp@ietf.org > Subject: RE: [rddp] Draft progress & schedule >=20 > > (2) I want to see ready-for-WG-Last-Call versions of the > > DDP, RDMAP, and Security drafts by the end of next > > week (submit them to the secretariat by Fri, Dec 3 > > and cc: me on the submission email). This is so > > that this WG Last Call can be finished before the > > end-of-December holidays divert everyone's attention. >=20 > I think I see rough consensus on the list to delay WG Last=20 > Call in order to get the interoperability appendices into the=20 > drafts. This needs to be concluded a lot faster than just=20 > before the Spring IETF meeting - I would encourage the group=20 > to work out what's needed on the list in the next week or so,=20 > and plan to submit drafts that can be last called by early=20 > January. I just had to slip the WG milestones on the IETF=20 > web site by a year (they're not updated yet) - if these have=20 > to be slipped again, our AD may start to wonder whether this=20 > WG should continue. >=20 > Thanks, > --David (WG chair) > ---------------------------------------------------- > 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 > ---------------------------------------------------- >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Dec 8 08:30:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22177 for ; Wed, 8 Dec 2004 08:30:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc20l-0005Cm-C7 for rddp-web-archive@ietf.org; Wed, 08 Dec 2004 08:37:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc1nU-00074Y-Nr; Wed, 08 Dec 2004 08:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc1cz-0004vV-OB for rddp@megatron.ietf.org; Wed, 08 Dec 2004 08:13:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20903 for ; Wed, 8 Dec 2004 08:13:08 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc1jl-0004nZ-SD for rddp@ietf.org; Wed, 08 Dec 2004 08:20:10 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 8 Dec 2004 05:12:38 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 8 Dec 2004 05:12:37 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Wed, 8 Dec 2004 05:12:37 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1277); Wed, 8 Dec 2004 05:12:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Draft progress & schedule Date: Wed, 8 Dec 2004 05:12:38 -0800 Message-ID: Thread-Topic: [rddp] Draft progress & schedule Thread-Index: AcTc8eIDIP6GlaFaSSuj6PhSa0rCfgANXjMg From: "Jim Pinkerton" To: X-OriginalArrivalTime: 08 Dec 2004 13:12:37.0459 (UTC) FILETIME=[96ACDA30:01C4DD27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Given the rough concensus call, Paul, is it possible to get the appendix that is proposed glued into the MPA draft, with the minor text changes in the body of the doc? Hemal, Renato, seems like the changes are well contained in the DDP and RDMAP drafts as well. Any hope of quickly submitting a draft update? Jim > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Black_David@emc.com > Sent: Tuesday, December 07, 2004 10:43 PM > To: rddp@ietf.org > Subject: RE: [rddp] Draft progress & schedule >=20 > > (2) I want to see ready-for-WG-Last-Call versions of the > > DDP, RDMAP, and Security drafts by the end of next > > week (submit them to the secretariat by Fri, Dec 3 > > and cc: me on the submission email). This is so > > that this WG Last Call can be finished before the > > end-of-December holidays divert everyone's attention. >=20 > I think I see rough consensus on the list to delay WG Last > Call in order to get the interoperability appendices into > the drafts. This needs to be concluded a lot faster than > just before the Spring IETF meeting - I would encourage > the group to work out what's needed on the list in the > next week or so, and plan to submit drafts that can be > last called by early January. I just had to slip the WG > milestones on the IETF web site by a year (they're not > updated yet) - if these have to be slipped again, our > AD may start to wonder whether this WG should continue. >=20 > Thanks, > --David (WG chair) > ---------------------------------------------------- > 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 > ---------------------------------------------------- >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Wed Dec 8 11:11:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09688 for ; Wed, 8 Dec 2004 11:11:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4W8-0000u4-4i for rddp-web-archive@ietf.org; Wed, 08 Dec 2004 11:18:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc4G4-00058b-Fr; Wed, 08 Dec 2004 11:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cc44a-0002NC-LT for rddp@megatron.ietf.org; Wed, 08 Dec 2004 10:49:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07493 for ; Wed, 8 Dec 2004 10:49:46 -0500 (EST) Received: from e33.co.us.ibm.com ([32.97.110.131]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cc4BN-0000LR-Tf for rddp@ietf.org; Wed, 08 Dec 2004 10:56:50 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB8FnFDr261002 for ; Wed, 8 Dec 2004 10:49:16 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB8FnF5D442200 for ; Wed, 8 Dec 2004 08:49:15 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB8FnFIM025706 for ; Wed, 8 Dec 2004 08:49:15 -0700 Received: from d03nm130.boulder.ibm.com (d03nm130.boulder.ibm.com [9.17.195.174]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB8FnFnO025669 for ; Wed, 8 Dec 2004 08:49:15 -0700 Subject: RE: [rddp] Draft progress & schedule To: rddp@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Wed, 8 Dec 2004 09:49:12 -0600 X-MIMETrack: Serialize by Router on D03NM130/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 12/08/2004 08:49:14 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1467381602==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd --===============1467381602== Content-type: multipart/related; Boundary="0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1" --0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: multipart/alternative; Boundary="1__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1" --1__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: text/plain; charset=US-ASCII I recommend the interoperability draft be submitted to the WG soon. After it has been submitted, I will submit another revision of the RDMAP Spec, with the interoperability related (informational changes). Thanks Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 Black_David@emc.c om To: rddp@ietf.org Sent by: cc: rddp-bounces@ietf Subject: RE: [rddp] Draft progress & schedule .org 12/08/2004 12:42 AM > (2) I want to see ready-for-WG-Last-Call versions of the > DDP, RDMAP, and Security drafts by the end of next > week (submit them to the secretariat by Fri, Dec 3 > and cc: me on the submission email). This is so > that this WG Last Call can be finished before the > end-of-December holidays divert everyone's attention. I think I see rough consensus on the list to delay WG Last Call in order to get the interoperability appendices into the drafts. This needs to be concluded a lot faster than just before the Spring IETF meeting - I would encourage the group to work out what's needed on the list in the next week or so, and plan to submit drafts that can be last called by early January. I just had to slip the WG milestones on the IETF web site by a year (they're not updated yet) - if these have to be slipped again, our AD may start to wonder whether this WG should continue. Thanks, --David (WG chair) ---------------------------------------------------- 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 --1__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I recommend the interoperability draft be submitted to the WG soon.

After it has been submitted, I will submit another revision of the RDMAP Spec, with the interoperability related (informational changes).

Thanks

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

Inactive hide details for Black_David@emc.comBlack_David@emc.com




          Black_David@emc.com
          Sent by: rddp-bounces@ietf.org

          12/08/2004 12:42 AM



To: rddp@ietf.org
cc:
Subject: RE: [rddp] Draft progress & schedule


> (2) I want to see ready-for-WG-Last-Call versions of the
> DDP, RDMAP, and Security drafts by the end of next
> week (submit them to the secretariat by Fri, Dec 3
> and cc: me on the submission email). This is so
> that this WG Last Call can be finished before the
> end-of-December holidays divert everyone's attention.

I think I see rough consensus on the list to delay WG Last
Call in order to get the interoperability appendices into
the drafts. This needs to be concluded a lot faster than
just before the Spring IETF meeting - I would encourage
the group to work out what's needed on the list in the
next week or so, and plan to submit drafts that can be
last called by early January. I just had to slip the WG
milestones on the IETF web site by a year (they're not
updated yet) - if these have to be slipped again, our
AD may start to wonder whether this WG should continue.

Thanks,
--David (WG chair)
----------------------------------------------------
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
 --1__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1-- --0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <10__=09BBE5F7DFC54CC18f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <20__=09BBE5F7DFC54CC18f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1 Content-type: image/gif; name="pic24659.gif" Content-Disposition: inline; filename="pic24659.gif" Content-ID: <30__=09BBE5F7DFC54CC18f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=09BBE5F7DFC54CC18f9e8a93df938690918c09BBE5F7DFC54CC1-- --===============1467381602== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1467381602==-- From rddp-bounces@ietf.org Thu Dec 9 09:41:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25764 for ; Thu, 9 Dec 2004 09:41:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcPaw-0006Op-6N for rddp-web-archive@ietf.org; Thu, 09 Dec 2004 09:48:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcPON-0002vW-UY; Thu, 09 Dec 2004 09:35:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcPFN-0001X5-R4 for rddp@megatron.ietf.org; Thu, 09 Dec 2004 09:26:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24532 for ; Thu, 9 Dec 2004 09:26:20 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcPMI-00064V-AE for rddp@ietf.org; Thu, 09 Dec 2004 09:33:35 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iB9EPcFJ733134 for ; Thu, 9 Dec 2004 09:25:38 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iB9EPciB067660 for ; Thu, 9 Dec 2004 07:25:38 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB9EPbgg022328 for ; Thu, 9 Dec 2004 07:25:37 -0700 Received: from d03mc013.boulder.ibm.com (d03mc013.boulder.ibm.com [9.17.195.89]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iB9EPb6W022308 for ; Thu, 9 Dec 2004 07:25:37 -0700 Subject: RE: [rddp] Draft progress & schedule To: rddp@ietf.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 Message-ID: From: Renato Recio Date: Thu, 9 Dec 2004 07:25:31 -0700 X-MIMETrack: Serialize by Router on D03MC013/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 12/09/2004 07:25:37 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1159700808==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 --===============1159700808== Content-type: multipart/related; Boundary="0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895" --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: multipart/alternative; Boundary="1__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895" --1__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Folks, John Carrier kindly pointed me to the interoperability draft (which I h= ad missed). I am working on adding the interoperability changes to the RD= MAP spec. I plan to post an updated draft by end of day 12/13. Thanks Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 ----- Forwarded by Renato Recio/Austin/IBM on 12/09/2004 08:22 AM -----= = Renato Recio = To: rddp@ietf.org = 12/08/2004 09:49 cc: = AM From: Renato Recio/Au= stin/IBM@IBMUS Subject: RE: [rddp] Draf= t progress & schedule(Document link: Renato Recio) = = I recommend the interoperability draft be submitted to the WG soon. After it has been submitted, I will submit another revision of the RDM= AP Spec, with the interoperability related (informational changes). Thanks Renato J Recio Chief Architect, eServer I/O IBM Distinguished Engineer Member IBM Academy of Technology Tel 512-838-3685, T/L 678-3685 = Black_David@emc.c = om To: rddp@ietf.org = Sent by: cc: = rddp-bounces@ietf Subject: RE: [rddp] Dra= ft progress & schedule .org = = = 12/08/2004 12:42 = AM = = = > (2) I want to see ready-for-WG-Last-Call versions of the > DDP, RDMAP, and Security drafts by the end of next > week (submit them to the secretariat by Fri, Dec 3 > and cc: me on the submission email). This is so > that this WG Last Call can be finished before the > end-of-December holidays divert everyone's attention. I think I see rough consensus on the list to delay WG Last Call in order to get the interoperability appendices into the drafts. This needs to be concluded a lot faster than just before the Spring IETF meeting - I would encourage the group to work out what's needed on the list in the next week or so, and plan to submit drafts that can be last called by early January. I just had to slip the WG milestones on the IETF web site by a year (they're not updated yet) - if these have to be slipped again, our AD may start to wonder whether this WG should continue. Thanks, --David (WG chair) ---------------------------------------------------- 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 = --1__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable

Folks,

John Carrier kindly pointed me to the interoperability draft (which I h= ad missed). I am working on adding the interoperability changes to the= RDMAP spec. I plan to post an updated draft by end of day 12/13.

Thanks

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

----- Forwarded by Renato Recio/Aust= in/IBM on 12/09/2004 08:22 AM -----



          Renato Recio

          12/08/2004 09:49 AM

3D""
To: rddp@ietf.org
cc:
From: Renato Recio/Austin/IBM= @IBMUS
Subject: RE: [rddp] Draft pro= gress & schedule3D"Renato

I recommend the interoperability draft be submitted to the WG soon.
=
After it has been submitted, I will submit another revision of the RDM= AP Spec, with the interoperability related (informational changes).
=
Thanks

Renato J Recio
Chief Architect, eServer I/O
IBM Distinguished Engineer
Member IBM Academy of Technology
Tel 512-838-3685, T/L 678-3685

3D"Inactive

          Black_David@emc.com
          Sent by: rddp-bounces@ietf.org

          12/08/2004 12:42 AM

3D""

To: rddp@ietf.org
cc:
Subject: RE: [rddp] Draft pro= gress & schedule

> (2) I want to see ready-for-WG-Last-Cal= l versions of the
> DDP, RDMAP, and Security drafts by the end of next
> week (submit them to the secretariat by Fri, Dec 3
> and cc: me on the submission email). This is so
> that this WG Last Call can be finished before the
> end-of-December holidays divert everyone's attention.

I think I see rough consensus on the list to delay WG Last
Call in order to get the interoperability appendices into
the drafts. This needs to be concluded a lot faster than
just before the Spring IETF meeting - I would encourage
the group to work out what's needed on the list in the
next week or so, and plan to submit drafts that can be
last called by early January. I just had to slip the WG
milestones on the IETF web site by a year (they're not
updated yet) - if these have to be slipped again, our
AD may start to wonder whether this WG should continue.

Thanks,
--David (WG chair)
----------------------------------------------------
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

= --1__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895-- --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <10__=08BBE5F6DFDD78958f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: image/gif; name="pic27449.gif" Content-Disposition: inline; filename="pic27449.gif" Content-ID: <20__=08BBE5F6DFDD78958f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWwBQAKL/AKFEobl0udKl0urV6sDAwAAAAAAAAAAAACH5BAEAAAQALAAAAABbAFAAQAP/ SLrc/jDKSau9mIBwxyBfJo7QAAjPFkbC56ErKUdBzGwOYDtCD+C/H6o3gEGEs0HgV2MoPTmAw4R6 FAPLIHOzFJw4it2i+GkxBGCL8kTpTcUEbDDQM/eaIHlRCr8h+TgTShQ/O2hVMxNpGjoSUGEpOWYP iIkYaFgeXw19Cl6NEY+WGEGTGWt4o6qrrGNZlSEuL3FZG1q1Oh90rRlsPFyVamUEVUs1prycRSmL nkEyLx50u1a4WnMnRJ1OPw/NzifbySAaRcgOxn07gw2fwYmIT+yjhVOpYedh9+NeZZrS3yJIobSM U8BxgrwsAONmigpH3RBaaChCyTuJia7MMSaE/wjGjyAreNiDiskxUWoGhpTQj9zKlwtavllC5pOc Qlrc1IAiSxxCE94CwUQos4FKJz4aYeFw6Es3JmXyYaQSqkG6oW9cVFB4JFhEew8dzSpZKmZOlFbQ lA0VsOjCsFjPSCVHldhFl06otWMyV4JeCHSA2iUmbYI7Hr9SgLICQmsMcWAGHRo5giZLTr6setmX 4RAaC2sNc/4V0IRPeFiIAWLaYnGJTH6ZSTSROs6Gz9CW/Hpn4mhcwC/SNNNNweJpiVLwuIaYOejB lw0/4RU5+ndMVWuaW3ekNvCkxxpLHd9Ovrz5EudXSdPRovdSnKVQ7HQsimv5zX+FEdtv++R4jP/G pIcRXMqQ9AkX/gko0GtIjAHJC/LVggsuaK0k1Bls/KfgGdMpEOCGM1xoVh91MMEIEkQYUZ52CrCI ijhjcVTWPFN9dcY37mhIHo1GvVOPYbK0t90TELilwV3m1LMUMXQ4JQVUdm2jDS0I9sXfG8FYRAmU p5DTXjNqmaTNWAfeVlw4BgW1nCpZ5CeSTR16aIhvzlT4oGNOUFBdZ8CY1dYONjJw020etYCHEjRt NkILVtrWyV3fNLnnKMHsVKIjH+a1g2UG6SiCQg0d45FhgR7xjWBpDYqNWl7gxsM0rYHwxX/SdeYm OIF1IOdCIcwHj4icGNVWgzM0EdykjVnQBSWgaTqELAawCeKhajDCWGoYnsrwWT8I0umNOLyxKJGi JklxqZ5r5pEPGQD6wl4gS9oKFiW1YdRaLExecJF2mfqRLQmLqTONbsSN6EQfz1nXxFKmwMIpSwUp rM8hN4pr211mYQwSByHc0fEdGvc3gcVD6eJZvW2gzNh5i4WcgssKwmwQsOmhOYNNMlunybUs1fJv XFfU0l14c+QM4htHJ71hAgA7 --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: image/gif; name="doclink.gif" Content-Disposition: inline; filename="doclink.gif" Content-ID: <30__=08BBE5F6DFDD78958f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhDAAOALMAAAAAAP///7q6w7m5wrW1vf7+/u/v7+Hh4dLS0sDAwLu7u7KysqKiooCAgP// /wAAACH5BAEAAA4ALAAAAAAMAA4AAARC0MkGmrwXhKbqwtoWBAslAV4zjsBJNuraOuEqu/Z4zPV6 BLzcDxH0BRC7BK2gOx6IiwWqsXAiAVFJyfPEKjFb1CcCADs= --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <40__=08BBE5F6DFDD78958f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895 Content-type: image/gif; name="pic28218.gif" Content-Disposition: inline; filename="pic28218.gif" Content-ID: <50__=08BBE5F6DFDD78958f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=08BBE5F6DFDD78958f9e8a93df938690918c08BBE5F6DFDD7895-- --===============1159700808== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============1159700808==-- From rddp-bounces@ietf.org Fri Dec 10 13:05:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02999 for ; Fri, 10 Dec 2004 13:05:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcpFk-0001kG-Di for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 13:12:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcowF-0000Sz-MY; Fri, 10 Dec 2004 12:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcotN-0008N9-46 for rddp@megatron.ietf.org; Fri, 10 Dec 2004 12:49:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02113 for ; Fri, 10 Dec 2004 12:49:18 -0500 (EST) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ccp0H-0001T0-JS for rddp@ietf.org; Fri, 10 Dec 2004 12:56:49 -0500 Received: (qmail 12074 invoked from network); 10 Dec 2004 17:48:59 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 10 Dec 2004 17:48:59 -0000 Message-ID: <41B9E1D2.4060507@fid4.com> Date: Fri, 10 Dec 2004 12:50:10 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [rddp] Freeing QN=1 State X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit When does draft-ietf-rddp-rdmap-02.txt consider an inbound RDMA Read Request Message finished such that the state associated with QN=1 (the IRRQ) for the RDMA Read Request can be freed? Put another way, if IRRQ is 1 (for simplicity), when is it legal for a new RDMA Read Request to be received? Is it: a) Once the RDMA Read Response Message has been given to DDP? b) Once the RDMA Read Response Message has been "acked" by the data sink? c) up to the implementation? d) specified somewhere that I just missed? Using (a) as a solution I ran into a DoS problem. The data sink keeps issuing RDMA Read Requests but the LLP window advertised by the data sink is so small (or closed) that the resources I believe the IRD negotiation was meant to protect actually get depleted. A compliant sender should not send the next RDMA Read Request until a prior one has completed. However, is the draft assuming a non malicious sender? Personally, I prefer to protect my resources regardless. I can't find supporting text in the draft for (b). Doing (c) allows for (a) so is the same problem IMHO. Thanks, MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Dec 10 15:15:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13617 for ; Fri, 10 Dec 2004 15:15:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcrHl-0004XD-KT for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 15:22:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccr5Z-0000tK-Nr; Fri, 10 Dec 2004 15:10:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccqyz-0003Wc-Jj for rddp@megatron.ietf.org; Fri, 10 Dec 2004 15:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11818 for ; Fri, 10 Dec 2004 15:03:15 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccr6D-0004Dr-L3 for rddp@ietf.org; Fri, 10 Dec 2004 15:10:46 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Freeing QN=1 State MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 10 Dec 2004 12:04:18 -0800 Message-ID: Thread-Topic: [rddp] Freeing QN=1 State Thread-Index: AcTe4tWC7Z0wQJCUTz2j9Jgw/N12mwADlAgg From: "Caitlin Bestler" To: "Michael C. Cambria" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Michael C. Cambria > Sent: Friday, December 10, 2004 9:50 AM > To: rddp@ietf.org > Subject: [rddp] Freeing QN=3D1 State >=20 >=20 > When does draft-ietf-rddp-rdmap-02.txt consider an inbound=20 > RDMA Read Request Message finished such that the state=20 > associated with QN=3D1 (the > IRRQ) for the RDMA Read Request can be freed? >=20 > Put another way, if IRRQ is 1 (for simplicity), when is it=20 > legal for a new RDMA Read Request to be received? Is it: >=20 > a) Once the RDMA Read Response Message has been given to DDP? > b) Once the RDMA Read Response Message has been "acked" by=20 > the data sink? > c) up to the implementation? > d) specified somewhere that I just missed? >=20 The other side must not consider its RDMA Read Request complete until it receives the RDMA Read Response. When the Data Source considers it complete is a matter of implementation. But conceptually, you should imagine that the RDMA Read engine is simply an alternate ULP: - it pre-posts receive buffers to accept RDMA Read Requests. It posts enough buffers for the number of credits it has been told were issued. - it posts send requests to transmit RDMA Read Responses. So basically, it has completed an RDMA Read Request when its transmit requests complete. Just as with RDMA Write Requests Submitted by the main ULP, completion is implementation dependent. It indicates to the ULP that the source buffers are no longer required. That may be because it has been LLP acked, or it may be because the LLP has the buffers fully cached on its own. Of course ultimately, its when the "RDMA Read Engine" has freed up enough resources to repost its receive request. That depends on how it tracks pending requests. If the other side does not=20 post excess RDMA Read requests it will never have to know the details of how the peer RDMA Read Engine is implemented. -- Caitlin Bestler Director Software Architecture Siliquent Technologies caitlinb@siliquent.com =20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Dec 10 18:33:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10747 for ; Fri, 10 Dec 2004 18:33:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcuO7-0003Qq-MX for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 18:41:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuFa-0004X6-UR; Fri, 10 Dec 2004 18:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccu8Z-00020M-1g for rddp@megatron.ietf.org; Fri, 10 Dec 2004 18:25:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09687 for ; Fri, 10 Dec 2004 18:25:20 -0500 (EST) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CcuFW-0003AI-EL for rddp@ietf.org; Fri, 10 Dec 2004 18:32:54 -0500 Received: (qmail 11555 invoked from network); 10 Dec 2004 23:25:01 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 10 Dec 2004 23:25:01 -0000 Message-ID: <41BA3094.90204@fid4.com> Date: Fri, 10 Dec 2004 18:26:12 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rddp@ietf.org Subject: Re: [rddp] Freeing QN=1 State References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: > > > >>-----Original Message----- >>From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On >>Behalf Of Michael C. Cambria >>Sent: Friday, December 10, 2004 9:50 AM >>To: rddp@ietf.org >>Subject: [rddp] Freeing QN=1 State >> >> >>When does draft-ietf-rddp-rdmap-02.txt consider an inbound >>RDMA Read Request Message finished such that the state >>associated with QN=1 (the >>IRRQ) for the RDMA Read Request can be freed? >> >>Put another way, if IRRQ is 1 (for simplicity), when is it >>legal for a new RDMA Read Request to be received? Is it: >> >>a) Once the RDMA Read Response Message has been given to DDP? >>b) Once the RDMA Read Response Message has been "acked" by >>the data sink? >>c) up to the implementation? >>d) specified somewhere that I just missed? >> > > The other side must not consider its RDMA Read Request complete > until it receives the RDMA Read Response. Agreed. This is in the draft Sec 7.5 #19. A compliant sender isn't what I was concerned about. I'm interpreting this to imply that the Data Source is justified in knocking down the session if it feels that the IRRQ is "still full". This addresses my concern about DoS. > When the Data Source > considers it complete is a matter of implementation. Is there a window where the Data Sink ORRQ doesn't match the Data Source IRRQ? For example, a compliant Data Sink completes the RDMA Read as you describe and sends a new one. However, the Data Source doesn't have its implementation specific criteria met for considering the Read in Queue 1 to be complete. The new RDMA Read from the Data Sink results in the session being terminated. Both sides claim they comply. Thanks, MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Dec 10 18:46:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11541 for ; Fri, 10 Dec 2004 18:46:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccuao-0003h8-De for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 18:54:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuOQ-0006Qd-Qe; Fri, 10 Dec 2004 18:41:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcuN0-0005ym-GA for rddp@megatron.ietf.org; Fri, 10 Dec 2004 18:40:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11205 for ; Fri, 10 Dec 2004 18:40:14 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcuUF-0003Yt-Nm for rddp@ietf.org; Fri, 10 Dec 2004 18:47:49 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Freeing QN=1 State MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 10 Dec 2004 15:41:24 -0800 Message-ID: Thread-Topic: [rddp] Freeing QN=1 State Thread-Index: AcTfD3ww/i3hdNqGTn+t5nNC6iGSSAAAUuWw From: "Caitlin Bestler" To: "Michael C. Cambria" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable >=20 > Is there a window where the Data Sink ORRQ doesn't match the=20 > Data Source IRRQ? For example, a compliant Data Sink=20 > completes the RDMA Read as you describe and sends a new one. =20 > However, the Data Source doesn't have its implementation=20 > specific criteria met for considering the Read in Queue 1 to=20 > be complete. The new RDMA Read from the Data Sink results in=20 > the session being terminated. Both sides claim they comply. >=20 Essentially you are asking, can the Data Sink have received the completion of its RDMA Read Reply, and then submit a new RDMA Read Request which will reach the peer *before* the ack of the RDMA Read Reply does? The answer is that it cannot because, the completion of the RDMA Read Reply cannot be delivered to the Data Sink ULP before The LLP has committed to LLP Ack that TCP Segment / SCTP chunk. The next RDMA Read Request, being submitted *later* than the decision to LLP Ack, cannot reach the other side *earlier* than the LLP ack. From the LLP's perspective the ack must occur earlier, or at worst get blurred to the "same time". The order cannot get reversed. If the Data Sink ULP cheats and peaks at memory to determine When the RDMA Read has finished rather than waiting for the Completion you could indeed get that type of race condidtion. That's one of many reasons why all warranties are void if the ULP acts upon buffers before they are delivered. -- Caitlin Bestler Director Software Architecture Siliquent Technologies caitlinb@siliquent.com _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Dec 10 19:21:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13538 for ; Fri, 10 Dec 2004 19:21:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ccv8g-0004J8-Pd for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 19:29:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccv00-0005CU-U8; Fri, 10 Dec 2004 19:20:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccuxw-0004OY-3H for rddp@megatron.ietf.org; Fri, 10 Dec 2004 19:18:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13319 for ; Fri, 10 Dec 2004 19:18:25 -0500 (EST) Received: from lilly.csoft.net ([63.111.22.101] helo=mail102.csoft.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ccv5D-0004EV-3u for rddp@ietf.org; Fri, 10 Dec 2004 19:26:00 -0500 Received: (qmail 85150 invoked from network); 11 Dec 2004 00:18:25 -0000 Received: from unknown (HELO ?127.0.0.1?) (63.111.26.110) by mail102.csoft.net with SMTP; 11 Dec 2004 00:18:25 -0000 Message-ID: <41BA3D19.7010400@fid4.com> Date: Fri, 10 Dec 2004 19:19:37 -0500 From: "Michael C. Cambria" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Caitlin Bestler Subject: Re: [rddp] Freeing QN=1 State References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: rddp@ietf.org X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Caitlin Bestler wrote: >>Is there a window where the Data Sink ORRQ doesn't match the >>Data Source IRRQ? For example, a compliant Data Sink >>completes the RDMA Read as you describe and sends a new one. >>However, the Data Source doesn't have its implementation >>specific criteria met for considering the Read in Queue 1 to >>be complete. The new RDMA Read from the Data Sink results in >>the session being terminated. Both sides claim they comply. >> > > > Essentially you are asking, can the Data Sink have received > the completion of its RDMA Read Reply, and then submit a new > RDMA Read Request which will reach the peer *before* the > ack of the RDMA Read Reply does? As the draft reads now, when to clean up state is implementation dependent. You said so yourself :-) So the draft allows a Data Source to e.g. set a timer to some large value and not clean up state until it fires and claim that it complies. Text that says that state must be freed when the Read Response is acked (or sooner) fixes this. Regards, MikeC _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Fri Dec 10 19:40:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14833 for ; Fri, 10 Dec 2004 19:40:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcvQp-0004hz-DV for rddp-web-archive@ietf.org; Fri, 10 Dec 2004 19:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcvBR-0007cN-2J; Fri, 10 Dec 2004 19:32:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccv77-0006xZ-IG for rddp@megatron.ietf.org; Fri, 10 Dec 2004 19:27:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13990 for ; Fri, 10 Dec 2004 19:27:54 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=silexch.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcvEP-0004O2-9a for rddp@ietf.org; Fri, 10 Dec 2004 19:35:29 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Freeing QN=1 State MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 10 Dec 2004 16:29:07 -0800 Message-ID: Thread-Topic: [rddp] Freeing QN=1 State Thread-Index: AcTfFvIlSLXxB/STRy6K2JAkcLWxewAASLEg From: "Caitlin Bestler" To: "Michael C. Cambria" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Well an implementation is free to lose track of its resources totally. The key is that you cannot receive the RDMA Read Request that your RDMA Read Response enabled sooner than you *could* have released all resources associated with the RDMA Read. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 09:28:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01377 for ; Mon, 20 Dec 2004 09:28:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgOft-0001dC-Db for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 09:38:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOQB-0002Wd-Fr; Mon, 20 Dec 2004 09:21:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgOLD-0001k0-GV for rddp@megatron.ietf.org; Mon, 20 Dec 2004 09:16:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00469 for ; Mon, 20 Dec 2004 09:16:49 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgOUU-0001L0-2u for rddp@ietf.org; Mon, 20 Dec 2004 09:26:26 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id AECCB5490186; Mon, 20 Dec 2004 09:16:44 -0500 From: "Barry Reinhold" To: Date: Mon, 20 Dec 2004 09:16:40 -0500 Message-ID: <000901c4e69e$89c6e0b0$467fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: RDDP Subject: [rddp] Conformance test design issue with exposed MULPDU X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit I am seeking to write a conformance tests that addresses that following item from DDP clause 3, first item, which states: " 1. LLPs MUST expose MULPDU & MULPDU Changes. This is required so that the DDP layer can perform segmentation aligned with the MULPDU and can adapt as MULPDU changes come about. The corner case of how to handle outstanding requests during a MULPDU change is covered by the requirements below. 2. In the event of a MULPDU change, DDP MUST NOT be required by the LLP to re-segment DDP Segments that have been previously posted to the LLP. Note that under pathological conditions the LLP may change the advertised MULPDU more frequently than the queue of previously posted DDP Segment transmit requests is flushed. Under this pathological condition, the LLP transmit queue can contain DDP Messages which were posted multiple MULPDU updates previously, thus there may be no correlation between the queued DDP Segment(s) and the LLP's current value of MULPDU. " In seeking to test the DUT's exposing of MULPDU changes I am currently assuming that if: 1. There has been no TCP MAXSEG option advertisement, 2. The maximum sized TCP window seen by the DUT is N octets (where N is not limited by the lower bound of a segment, and is smaller than that advertised by the DUT) 3. The window size is advertised to the DUT at a time when no RDMA operation has been requested. then when a RDMA Send/write operation is requested of the DUT w/ Nish octets the DUT will send one FPDU in one TCP segment. (Nish implies that N is selected with an awareness of the need to take into account headers). What I am a less sure on is the next step. I would like to know if people believe that the following is required normative behavior: Once the DUT has sent the FPDU as outlined above, consuming the N octets advertised by the test station, the test station advertises a window smaller that N, uses PULP to queue additional RDMA send/write requests, and then checks to see that the new FPDUs are such that they fit into the now smaller TCP segment. I believe this to be the heart of what the conformance item is requesting, but I'm not sure how quickly a LLP is supposed to map a change in the EMSS to the MULPDU and expose it to the ULP. If this is an invalid test in your mind, is there a delta (in either time or octet stream space) by which the DUT would have to change the exposed MULPDU? Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 12:03:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16073 for ; Mon, 20 Dec 2004 12:03:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgR62-00060T-Rl for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 12:13:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgQsC-0000Hi-MB; Mon, 20 Dec 2004 11:59:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgQln-00083h-LQ for rddp@megatron.ietf.org; Mon, 20 Dec 2004 11:52:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15399 for ; Mon, 20 Dec 2004 11:52:24 -0500 (EST) Received: from 67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=fiona.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgQv5-0005kE-24 for rddp@ietf.org; Mon, 20 Dec 2004 12:02:03 -0500 Subject: RE: [rddp] Conformance test design issue with exposed MULPDU Date: Mon, 20 Dec 2004 08:53:34 -0800 Message-ID: <8508251A6FC08A489844A94261D3693A386D@fiona.siliquent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [rddp] Conformance test design issue with exposed MULPDU Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcTmoIfS3k5vkLgbRKOBgh5415lLLwAEuV8g From: "Caitlin Bestler" To: "Barry Reinhold" , , "RDDP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Any specific performance requirements would have to be in the LLP Requirements of the DDP draft. They are not there, which I believe represents a deliberate decision to leave this as a "quality of implemnetation" issue that does not require standards enforcement. Keep in mind that in the extreme case, long delays in reporting changes in the PMTU would effectively degrade to the same behavior as a non-MPA/DDP aware LLP. For TCP This would mean non-aligned MPA frames, for SCTP it would mean IP fragmentation. Neither of which will prevent Interoperability, merely degrade performance. > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On=20 > Behalf Of Barry Reinhold > Sent: Monday, December 20, 2004 6:17 AM > To: iwarp-tech@iol.unh.edu > Cc: RDDP > Subject: [rddp] Conformance test design issue with exposed MULPDU >=20 > I am seeking to write a conformance tests that addresses that=20 > following item from DDP clause 3, first item, which states: >=20 > " 1. LLPs MUST expose MULPDU & MULPDU Changes. This is required so=20 > that the DDP layer can perform segmentation aligned with the=20 > MULPDU and can adapt as MULPDU changes come about. The corner=20 > case of how to handle outstanding requests during a MULPDU=20 > change is covered by the requirements below. >=20 > 2. In the event of a MULPDU change, DDP MUST NOT be=20 > required by the=20 > LLP to re-segment DDP Segments that have been=20 > previously posted=20 > to the LLP. Note that under pathological conditions=20 > the LLP may=20 > change the advertised MULPDU more frequently than the queue of=20 > previously posted DDP Segment transmit requests is flushed.=20 > Under this pathological condition, the LLP transmit queue can=20 > contain DDP Messages which were posted multiple MULPDU updates=20 > previously, thus there may be no correlation between=20 > the queued=20 > DDP Segment(s) and the LLP's current value of MULPDU. " >=20 > In seeking to test the DUT's exposing of MULPDU changes I am=20 > currently assuming that if: >=20 > 1. There has been no TCP MAXSEG option advertisement, 2. The=20 > maximum sized TCP window seen by the DUT is N octets (where N=20 > is not limited by the lower bound of a segment, and is=20 > smaller than that advertised by the DUT) 3. The window size=20 > is advertised to the DUT at a time when no RDMA operation has=20 > been requested. >=20 > then when a RDMA Send/write operation is requested of the DUT=20 > w/ Nish octets the DUT will send one FPDU in one TCP segment.=20 > (Nish implies that N is selected with an awareness of the=20 > need to take into account headers). >=20 > What I am a less sure on is the next step. I would like to=20 > know if people believe that the following is required=20 > normative behavior: >=20 > Once the DUT has sent the FPDU as outlined above, consuming=20 > the N octets advertised by the test station, the test station=20 > advertises a window smaller that N, uses PULP to queue=20 > additional RDMA send/write requests, and then checks to see=20 > that the new FPDUs are such that they fit into the now=20 > smaller TCP segment. >=20 > I believe this to be the heart of what the conformance item=20 > is requesting, but I'm not sure how quickly a LLP is supposed=20 > to map a change in the EMSS to the MULPDU and expose it to the ULP. >=20 > If this is an invalid test in your mind, is there a delta (in=20 > either time or octet stream space) by which the DUT would=20 > have to change the exposed MULPDU? >=20 >=20 >=20 >=20 >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > =20 >=20 >=20 >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 14:48:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27599 for ; Mon, 20 Dec 2004 14:48:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgTfj-0001PH-TT for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 14:58:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgTV2-0005jM-D7; Mon, 20 Dec 2004 14:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgTQl-0005Js-SY for rddp@megatron.ietf.org; Mon, 20 Dec 2004 14:42:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27302 for ; Mon, 20 Dec 2004 14:42:54 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgTa4-0001Hc-IY for rddp@ietf.org; Mon, 20 Dec 2004 14:52:33 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Mon, 20 Dec 2004 11:42:23 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Mon, 20 Dec 2004 11:42:23 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 11:42:22 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 20 Dec 2004 11:42:21 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Freeing QN=1 State Date: Mon, 20 Dec 2004 11:42:20 -0800 Message-ID: Thread-Topic: [rddp] Freeing QN=1 State thread-index: AcTfFvIlSLXxB/STRy6K2JAkcLWxewAASLEgAezectA= From: "Jim Pinkerton" To: "Caitlin Bestler" , "Michael C. Cambria" , X-OriginalArrivalTime: 20 Dec 2004 19:42:21.0767 (UTC) FILETIME=[05C41570:01C4E6CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Note that the security draft, section 7.5.2.4, walks through DoS attacks on the RDMA Read Request Queue. Technically, the attack described on this thread is not a DoS attack unless the RDMA Read Request Queue is shared by multiple connections (the security draft walks through normative mitigations to solve this). If it is a single connection, the only person you're hurting is yourself - thus this isn't DoS - but it is a bug. Jim > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Caitlin Bestler > Sent: Friday, December 10, 2004 4:29 PM > To: Michael C. Cambria; rddp@ietf.org > Subject: RE: [rddp] Freeing QN=3D1 State >=20 > Well an implementation is free to lose track of its resources totally. >=20 > The key is that you cannot receive the RDMA Read Request that your > RDMA Read Response enabled sooner than you *could* have released > all resources associated with the RDMA Read. >=20 >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 15:02:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28413 for ; Mon, 20 Dec 2004 15:02:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgTtN-0001iw-2h for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 15:12:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgTfj-0007Ap-8i; Mon, 20 Dec 2004 14:58:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgTZN-0006Sp-64 for rddp@megatron.ietf.org; Mon, 20 Dec 2004 14:51:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27790 for ; Mon, 20 Dec 2004 14:51:47 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgTig-0001So-Og for rddp@ietf.org; Mon, 20 Dec 2004 15:01:27 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 11:51:17 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 11:49:46 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 11:51:16 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 20 Dec 2004 11:51:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [rddp] Conformance test design issue with exposed MULPDU Date: Mon, 20 Dec 2004 11:51:15 -0800 Message-ID: Thread-Topic: [rddp] Conformance test design issue with exposed MULPDU thread-index: AcTmoIfS3k5vkLgbRKOBgh5415lLLwAEuV8gAAY2m8A= From: "Jim Pinkerton" To: "Caitlin Bestler" , "Barry Reinhold" , , "RDDP" X-OriginalArrivalTime: 20 Dec 2004 19:51:16.0052 (UTC) FILETIME=[44398140:01C4E6CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: quoted-printable I think the tests could even be tougher than that defined below.=20 To me the goal of the text was to require a conformant implementation to enable data transfer whenever the PMTU changes. In terms of testing for compliance with this intent, the PMTU update could occur at a variety of points, including: 1) data sent, but not ACKed 2) data not sent, still in the RDMAP/DDP/MPA/TCP/SCTP layer=20 (tough to test a specific layer independently, but=20 probably worth a try) 3) data in the application layer (i.e. connection established,=20 but data not yet posted to RDMAP/DDP/MPA/TCP/SCTP) I would prefer a test for at least the above three categories. 1) would require the recipient to be able to explicitly control when the TCP/SCTP window update occurred (i.e. don't ack the data, change the PMTU up/down), drop all the data, let the transmitter retransmit, but only except MTU's that are less than or equal to the revised value). 2) could be exercised by asking the target to send a very long message (say, 10's of megabytes on a 1 gig link), sending a PMTU update, and then only accepting data with a MTU less than or equal to the PMTU (the target should update the PMTU before the final connection timeout to ensure forward progress). And finally, 3) is send some data with the old PMTU, send a PMTU update, and then send some new data, and only accept the new data if it's MTU is <=3D the new PMTU value. Jim > -----Original Message----- > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On Behalf Of > Caitlin Bestler > Sent: Monday, December 20, 2004 8:54 AM > To: Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP > Subject: RE: [rddp] Conformance test design issue with exposed MULPDU >=20 > Any specific performance requirements would have to be > in the LLP Requirements of the DDP draft. They are not > there, which I believe represents a deliberate decision > to leave this as a "quality of implemnetation" issue that > does not require standards enforcement. >=20 > Keep in mind that in the extreme case, long delays in > reporting changes in the PMTU would effectively degrade > to the same behavior as a non-MPA/DDP aware LLP. For TCP > This would mean non-aligned MPA frames, for SCTP it would > mean IP fragmentation. Neither of which will prevent > Interoperability, merely degrade performance. >=20 >=20 > > -----Original Message----- > > From: rddp-bounces@ietf.org [mailto:rddp-bounces@ietf.org] On > > Behalf Of Barry Reinhold > > Sent: Monday, December 20, 2004 6:17 AM > > To: iwarp-tech@iol.unh.edu > > Cc: RDDP > > Subject: [rddp] Conformance test design issue with exposed MULPDU > > > > I am seeking to write a conformance tests that addresses that > > following item from DDP clause 3, first item, which states: > > > > " 1. LLPs MUST expose MULPDU & MULPDU Changes. This is required so > > that the DDP layer can perform segmentation aligned with the > > MULPDU and can adapt as MULPDU changes come about. The corner > > case of how to handle outstanding requests during a MULPDU > > change is covered by the requirements below. > > > > 2. In the event of a MULPDU change, DDP MUST NOT be > > required by the > > LLP to re-segment DDP Segments that have been > > previously posted > > to the LLP. Note that under pathological conditions > > the LLP may > > change the advertised MULPDU more frequently than the queue of > > previously posted DDP Segment transmit requests is flushed. > > Under this pathological condition, the LLP transmit queue can > > contain DDP Messages which were posted multiple MULPDU updates > > previously, thus there may be no correlation between > > the queued > > DDP Segment(s) and the LLP's current value of MULPDU. " > > > > In seeking to test the DUT's exposing of MULPDU changes I am > > currently assuming that if: > > > > 1. There has been no TCP MAXSEG option advertisement, 2. The > > maximum sized TCP window seen by the DUT is N octets (where N > > is not limited by the lower bound of a segment, and is > > smaller than that advertised by the DUT) 3. The window size > > is advertised to the DUT at a time when no RDMA operation has > > been requested. > > > > then when a RDMA Send/write operation is requested of the DUT > > w/ Nish octets the DUT will send one FPDU in one TCP segment. > > (Nish implies that N is selected with an awareness of the > > need to take into account headers). > > > > What I am a less sure on is the next step. I would like to > > know if people believe that the following is required > > normative behavior: > > > > Once the DUT has sent the FPDU as outlined above, consuming > > the N octets advertised by the test station, the test station > > advertises a window smaller that N, uses PULP to queue > > additional RDMA send/write requests, and then checks to see > > that the new FPDUs are such that they fit into the now > > smaller TCP segment. > > > > I believe this to be the heart of what the conformance item > > is requesting, but I'm not sure how quickly a LLP is supposed > > to map a change in the EMSS to the MULPDU and expose it to the ULP. > > > > If this is an invalid test in your mind, is there a delta (in > > either time or octet stream space) by which the DUT would > > have to change the exposed MULPDU? > > > > > > > > > > > > Barry Reinhold > > Lamprey Networks > > bbr@lampreynetworks.com > > (603) 868-8411 > > > > > > > > > > > > _______________________________________________ > > rddp mailing list > > rddp@ietf.org > > https://www1.ietf.org/mailman/listinfo/rddp > > >=20 > _______________________________________________ > rddp mailing list > rddp@ietf.org > https://www1.ietf.org/mailman/listinfo/rddp _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 16:41:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12418 for ; Mon, 20 Dec 2004 16:41:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVQR-0006Bo-6U for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 16:50:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgV3p-0006hN-Hl; Mon, 20 Dec 2004 16:27:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgUqd-0005Si-3e for rddp@megatron.ietf.org; Mon, 20 Dec 2004 16:13:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06546 for ; Mon, 20 Dec 2004 16:13:40 -0500 (EST) Received: from ppp-67-118-4-34.ded.pacbell.net ([67.118.4.34] helo=fiona.siliquent.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgUzw-00046P-Ok for rddp@ietf.org; Mon, 20 Dec 2004 16:23:21 -0500 Content-class: urn:content-classes:message Subject: RE: [rddp] Conformance test design issue with exposed MULPDU Date: Mon, 20 Dec 2004 13:14:58 -0800 Message-ID: <8508251A6FC08A489844A94261D3693A3874@fiona.siliquent.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thread-Topic: [rddp] Conformance test design issue with exposed MULPDU X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcTmoIfS3k5vkLgbRKOBgh5415lLLwAEuV8gAAY2m8AAAtJ30A== From: "Caitlin Bestler" To: "Jim Pinkerton" , "Barry Reinhold" , , "RDDP" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Jim Pinkerton [mailto:jpink@windows.microsoft.com]=20 > Sent: Monday, December 20, 2004 11:51 AM > To: Caitlin Bestler; Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP > Subject: RE: [rddp] Conformance test design issue with exposed MULPDU >=20 >=20 > I think the tests could even be tougher than that defined below.=20 >=20 > To me the goal of the text was to require a conformant=20 > implementation to enable data transfer whenever the PMTU=20 > changes. In terms of testing for compliance with this intent,=20 > the PMTU update could occur at a variety of points, including: >=20 > 1) data sent, but not ACKed > 2) data not sent, still in the RDMAP/DDP/MPA/TCP/SCTP layer=20 > (tough to test a specific layer independently, but=20 > probably worth a try) > 3) data in the application layer (i.e. connection established,=20 > but data not yet posted to RDMAP/DDP/MPA/TCP/SCTP) >=20 But unless you can intercept the DDP to LLP communications, I don't See how you can design a conformance test. The DDP layer only segments once, but there is no constraint as to How early or late the segmentation is done. An implementation could Segment when requests are submitted, and immediately submit the Resulting segments to the LLP -- or it could segment "just in time". A lot depends on the nature of the DDP/LLP interface -- but that itself is not standardized. It could be a push, pull or hybrid interface. The closer to a "just in time" interface the easier it would be to=20 see the reaction to the change PMTU. But if the LLP accepts 2 GB of segments in advance then lagging on recognizing the new PMTU until the 2 GB made its way through the LLP queue would be correct behavior. It's not very desirable, and an excessive amount of buffering capacity for the LLP to provide, but it would be legitimate. The actual interface will more likely resemble a pull than a push, but implementations will vary in their definition of "just in time". _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 17:04:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16243 for ; Mon, 20 Dec 2004 17:04:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVnT-0007V4-Po for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 17:14:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgVHZ-0007fm-Ob; Mon, 20 Dec 2004 16:41:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgV6G-0008Qx-Ns for rddp@megatron.ietf.org; Mon, 20 Dec 2004 16:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10227 for ; Mon, 20 Dec 2004 16:29:50 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVFR-0005Qf-8l for rddp@ietf.org; Mon, 20 Dec 2004 16:39:31 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A43BD20F02A2; Mon, 20 Dec 2004 16:29:31 -0500 From: "Barry Reinhold" To: "'Caitlin Bestler'" , "'Jim Pinkerton'" , , "'RDDP'" Subject: RE: [rddp] Conformance test design issue with exposed MULPDU Date: Mon, 20 Dec 2004 16:29:27 -0500 Message-ID: <002b01c4e6da$ff14d1b0$467fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <8508251A6FC08A489844A94261D3693A3874@fiona.siliquent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit -----Original Message----- From: Caitlin Bestler [mailto:caitlinb@siliquent.com] Sent: Monday, December 20, 2004 4:15 PM To: Jim Pinkerton; Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP Subject: RE: [rddp] Conformance test design issue with exposed MULPDU > -----Original Message----- > From: Jim Pinkerton [mailto:jpink@windows.microsoft.com] > Sent: Monday, December 20, 2004 11:51 AM > To: Caitlin Bestler; Barry Reinhold; iwarp-tech@iol.unh.edu; RDDP > Subject: RE: [rddp] Conformance test design issue with exposed MULPDU > > > I think the tests could even be tougher than that defined below. > > To me the goal of the text was to require a conformant > implementation to enable data transfer whenever the PMTU > changes. In terms of testing for compliance with this intent, > the PMTU update could occur at a variety of points, including: > > 1) data sent, but not ACKed > 2) data not sent, still in the RDMAP/DDP/MPA/TCP/SCTP layer > (tough to test a specific layer independently, but > probably worth a try) > 3) data in the application layer (i.e. connection established, > but data not yet posted to RDMAP/DDP/MPA/TCP/SCTP) > But unless you can intercept the DDP to LLP communications, I don't See how you can design a conformance test. The DDP layer only segments once, but there is no constraint as to How early or late the segmentation is done. An implementation could Segment when requests are submitted, and immediately submit the Resulting segments to the LLP -- or it could segment "just in time". A lot depends on the nature of the DDP/LLP interface -- but that itself is not standardized. It could be a push, pull or hybrid interface. The closer to a "just in time" interface the easier it would be to see the reaction to the change PMTU. But if the LLP accepts 2 GB of segments in advance then lagging on recognizing the new PMTU until the 2 GB made its way through the LLP queue would be correct behavior. It's not very desirable, and an excessive amount of buffering capacity for the LLP to provide, but it would be legitimate. The actual interface will more likely resemble a pull than a push, but implementations will vary in their definition of "just in time". I don't think I have an issue with this, the tests are designed to allow the DUT to see whatever events cause the MULPDU change to take place before the data to be sent is submitted to the RDMA interface of the DUT. After reviewing RFC 1122 I am no longer convinced that I can change the EMSS through the advertised window as RFC 1122 clearly links the EMSS to a default value or the value set at connection startup via TCP MSS option. Not using the TCP MSS option results in use of the default, not a value based on the largest seen window. Thus the only way to change the EMSS within the context of a live connection is by changing the PMTU. However, path discovery is not something I anticipate many implementation supporting. I will probe the list to see what the situation is. _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 17:09:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17276 for ; Mon, 20 Dec 2004 17:09:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVry-0007ju-IA for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 17:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgVfr-0008DL-Do; Mon, 20 Dec 2004 17:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgVNM-0001av-4T for rddp@megatron.ietf.org; Mon, 20 Dec 2004 16:47:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13467 for ; Mon, 20 Dec 2004 16:47:29 -0500 (EST) Received: from mail.ttlc.net ([66.94.32.4] helo=lampreynetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgVWg-0006Wh-VV for rddp@ietf.org; Mon, 20 Dec 2004 16:57:11 -0500 Received: from i8600 [64.222.186.225] by lampreynetworks.com with ESMTP (SMTPD32-7.07) id A8724B270230; Mon, 20 Dec 2004 16:47:30 -0500 From: "Barry Reinhold" To: "RDDP" Date: Mon, 20 Dec 2004 16:47:26 -0500 Message-ID: <003601c4e6dd$823d68c0$467fa8c0@i8600> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: iwarp-tech@iol.unh.edu Subject: [rddp] Path MTU discovery X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit To: Parties who are interested in performing iWARP conformance testing Re: Conformance Test Suite Design Issue In attempting to design a rigorous iWARP conformance test I am looking at changing the EMSS in the DUT during a connection via changes in the path MTU. It is not clear to me that this is a good idea as I fear there may be limited support for path MTU discovery. Please email me directly if you care and have an opinion that you don't want to post. Barry Reinhold Lamprey Networks bbr@lampreynetworks.com (603) 868-8411 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Mon Dec 20 20:38:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02493 for ; Mon, 20 Dec 2004 20:38:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgZ8Q-0003qY-Da for rddp-web-archive@ietf.org; Mon, 20 Dec 2004 20:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgYxc-00069i-5T; Mon, 20 Dec 2004 20:37:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgYx6-000616-3O for rddp@megatron.ietf.org; Mon, 20 Dec 2004 20:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02313 for ; Mon, 20 Dec 2004 20:36:38 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgZ6R-0003mP-Ob for rddp@ietf.org; Mon, 20 Dec 2004 20:46:21 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 17:36:06 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 17:34:21 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Dec 2004 17:36:06 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 20 Dec 2004 17:36:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Dec 2004 17:36:17 -0800 Message-ID: Thread-Topic: iwarp-tech Path MTU discovery thread-index: AcTm3ZvzpYNvPNR4QPihpCxCVfaC+gAHQoaA From: "Jim Pinkerton" To: "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 21 Dec 2004 01:36:06.0110 (UTC) FILETIME=[7075CFE0:01C4E6FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: iwarp-tech@iol.unh.edu, Dave Thaler Subject: [rddp] RE: iwarp-tech Path MTU discovery X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Personally I think any TCP implementation must support PMTU discovery, regardless of whether it's an offloaded implementation or in the host stack.=20 Specifically RFC 1191 (for IPv4) and RFC 1981 (for IPv6). Both are standards track.=20 However, understood though that RFC 1122 technically doesn't require their implementation (but it was written back in *1989*). However, section 3.3.3 does state normative requirements, particularly if you don't implement PMTU discovery (EMTU_S set to <=3D 576 bytes if not on = the local link). Further, the algorithm is *freakin* old (technical term), and a much better algorithm is to implement PMTU discovery... Jim > -----Original Message----- > From: owner-iwarp-tech@io.iol.unh.edu [mailto:owner-iwarp- > tech@io.iol.unh.edu] On Behalf Of Barry Reinhold > Sent: Monday, December 20, 2004 1:47 PM > To: RDDP > Cc: iwarp-tech@iol.unh.edu > Subject: iwarp-tech Path MTU discovery >=20 > To: Parties who are interested in performing iWARP conformance testing > Re: Conformance Test Suite Design Issue >=20 > In attempting to design a rigorous iWARP conformance test I am looking > at changing the EMSS in the DUT during a connection via changes in the > path MTU. It is not clear to me that this is a good idea as I fear there > may be limited support for path MTU discovery. >=20 > Please email me directly if you care and have an opinion that you don't > want to post. >=20 > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 >=20 >=20 >=20 _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp From rddp-bounces@ietf.org Tue Dec 21 10:29:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19616 for ; Tue, 21 Dec 2004 10:29:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgm6D-0006Zk-1I for rddp-web-archive@ietf.org; Tue, 21 Dec 2004 10:38:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cglo4-0006qs-Bg; Tue, 21 Dec 2004 10:20:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CglmB-0006Ir-Cf for rddp@megatron.ietf.org; Tue, 21 Dec 2004 10:18:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18199 for ; Tue, 21 Dec 2004 10:18:12 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cglve-0006J7-86 for rddp@ietf.org; Tue, 21 Dec 2004 10:28:02 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Dec 2004 07:17:42 -0800 Received: from red-hub-02.redmond.corp.microsoft.com ([157.54.7.100]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 21 Dec 2004 07:17:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Dec 2004 07:17:41 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 21 Dec 2004 07:17:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Dec 2004 07:14:17 -0800 Message-ID: Thread-Topic: iwarp-tech Path MTU discovery thread-index: AcTm3ZvzpYNvPNR4QPihpCxCVfaC+gAHQoaAAB1FzII= From: "Jim Pinkerton" To: "Jim Pinkerton" , "Barry Reinhold" , "RDDP" X-OriginalArrivalTime: 21 Dec 2004 15:17:40.0841 (UTC) FILETIME=[3668D590:01C4E770] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: iwarp-tech@iol.unh.edu, Dave Thaler Subject: [rddp] RE: iwarp-tech Path MTU discovery X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0754711502==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e This is a multi-part message in MIME format. --===============0754711502== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E770.35AC4317" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E770.35AC4317 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI, it was pointed out to me that the tcpm work group has a great = document in the works, attempting to enumerate the various RFCs that = apply to TCP. However it doesn't have any normative text in it - looks = to be simply informative. =20 http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-roadmap-00.txt =20 =20 jim =20 =20 ________________________________ From: owner-iwarp-tech@io.iol.unh.edu on behalf of Jim Pinkerton Sent: Mon 12/20/2004 5:36 PM To: Barry Reinhold; RDDP Cc: iwarp-tech@iol.unh.edu; Dave Thaler Subject: RE: iwarp-tech Path MTU discovery Personally I think any TCP implementation must support PMTU discovery, regardless of whether it's an offloaded implementation or in the host stack. Specifically RFC 1191 (for IPv4) and RFC 1981 (for IPv6). Both are standards track. However, understood though that RFC 1122 technically doesn't require their implementation (but it was written back in *1989*). However, section 3.3.3 does state normative requirements, particularly if you don't implement PMTU discovery (EMTU_S set to <=3D 576 bytes if not on = the local link). Further, the algorithm is *freakin* old (technical term), and a much better algorithm is to implement PMTU discovery... Jim > -----Original Message----- > From: owner-iwarp-tech@io.iol.unh.edu [mailto:owner-iwarp- > tech@io.iol.unh.edu] On Behalf Of Barry Reinhold > Sent: Monday, December 20, 2004 1:47 PM > To: RDDP > Cc: iwarp-tech@iol.unh.edu > Subject: iwarp-tech Path MTU discovery > > To: Parties who are interested in performing iWARP conformance testing > Re: Conformance Test Suite Design Issue > > In attempting to design a rigorous iWARP conformance test I am looking > at changing the EMSS in the DUT during a connection via changes in the > path MTU. It is not clear to me that this is a good idea as I fear there > may be limited support for path MTU discovery. > > Please email me directly if you care and have an opinion that you don't > want to post. > > Barry Reinhold > Lamprey Networks > bbr@lampreynetworks.com > (603) 868-8411 > > > ------_=_NextPart_001_01C4E770.35AC4317 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: iwarp-tech Path MTU discovery=0A= =0A= =0A=
=0A=
FYI, it was = pointed out to me =0A= that the tcpm work group has a great document in the works, attempting = to =0A= enumerate the various RFCs that apply to TCP. However it doesn't have = any =0A= normative text in it - looks to be simply informative.
=0A=
 
=0A= =0A=
 
=0A=
 
=0A=
jim
=0A=
 
=0A=
 
=0A=

=0A=
=0A= From: = owner-iwarp-tech@io.iol.unh.edu on behalf =0A= of Jim Pinkerton
Sent: Mon 12/20/2004 5:36 PM
To: = Barry =0A= Reinhold; RDDP
Cc: iwarp-tech@iol.unh.edu; Dave =0A= Thaler
Subject: RE: iwarp-tech Path MTU = discovery

=0A=

=0A=

Personally I think any TCP implementation must support = PMTU =0A= discovery,
regardless of whether it's an offloaded implementation or = in the =0A= host
stack.
Specifically RFC 1191 (for IPv4) and RFC 1981 (for = IPv6). Both =0A= are
standards track.

However, understood though that RFC 1122 =0A= technically doesn't require
their implementation (but it was written = back in =0A= *1989*). However,
section 3.3.3 does state normative requirements, =0A= particularly if you
don't implement PMTU discovery (EMTU_S set to = <=3D 576 =0A= bytes if not on the
local link). Further, the algorithm is *freakin* = old =0A= (technical term),
and a much better algorithm is to implement PMTU =0A= discovery...


Jim




> -----Original =0A= Message-----
> From: owner-iwarp-tech@io.iol.unh.edu [mailto:owner-iwarp-
> = tech@io.iol.unh.edu] =0A= On Behalf Of Barry Reinhold
> Sent: Monday, December 20, 2004 1:47 =0A= PM
> To: RDDP
> Cc: iwarp-tech@iol.unh.edu
> Subject: =0A= iwarp-tech Path MTU discovery
>
> To: Parties who are = interested in =0A= performing iWARP conformance testing
> Re: Conformance Test Suite = Design =0A= Issue
>
> In attempting to design a rigorous iWARP = conformance test =0A= I am looking
> at changing the EMSS in the DUT during a connection = via =0A= changes in the
> path MTU. It is not clear to me that this is a = good idea =0A= as I fear
there
> may be limited support for path MTU =0A= discovery.
>
> Please email me directly if you care and have = an =0A= opinion that you
don't
> want to post.
>
> Barry =0A= Reinhold
> Lamprey Networks
> = bbr@lampreynetworks.com
> (603) =0A= 868-8411
>
>
>


=0A= =0A= =0A= ------_=_NextPart_001_01C4E770.35AC4317-- --===============0754711502== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0754711502==-- From rddp-bounces@ietf.org Tue Dec 21 21:51:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09998 for ; Tue, 21 Dec 2004 21:51:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgwkK-0005pK-21 for rddp-web-archive@ietf.org; Tue, 21 Dec 2004 22:01:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgwWL-0001xw-MT; Tue, 21 Dec 2004 21:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgwPj-00005X-0A for rddp@megatron.ietf.org; Tue, 21 Dec 2004 21:39:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06787 for ; Tue, 21 Dec 2004 21:39:44 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CgwZI-00057D-Ph for rddp@ietf.org; Tue, 21 Dec 2004 21:49:41 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 21 Dec 2004 18:39:14 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Dec 2004 18:39:01 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1264); Tue, 21 Dec 2004 18:39:03 -0800 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 21 Dec 2004 18:39:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 21 Dec 2004 18:39:02 -0800 Message-ID: Thread-Topic: latest security draft posted (-06) thread-index: AcTnz2XsTMo/4Qd+RpKRp763BSfg6A== From: "Jim Pinkerton" To: "RDDP" X-OriginalArrivalTime: 22 Dec 2004 02:39:03.0685 (UTC) FILETIME=[667BC350:01C4E7CF] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Subject: [rddp] latest security draft posted (-06) X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238987695==" Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de This is a multi-part message in MIME format. --===============0238987695== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E7CF.6571C7AE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4E7CF.6571C7AE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I just posted the latest security draft update (-06). The internet draft folks should post this to the reflector shortly.=20 =20 Mallikarjun and Tom Talpey both provided very thorough reviews of the draft. I'd appreciate any reviews people have the time to do on the current draft. Also, send me email if you'd like a version that has change-bars since the -05 draft. From my perspective there are no outstanding issues in the document, other than any new feedback that comes in. =20 =20 Jim =20 =20 =20 ------_=_NextPart_001_01C4E7CF.6571C7AE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I just posted the latest security draft update (-06). = The internet draft folks should post this to the reflector shortly. =

 

Mallikarjun and Tom Talpey both provided very = thorough reviews of the draft.  I’d appreciate any reviews people have = the time to do on the current draft. Also, send me email if you’d like = a version that has change-bars since the -05 draft. From my perspective = there are no outstanding issues in the document, other than any new feedback that = comes in.

 

 

Jim

 

 

 

------_=_NextPart_001_01C4E7CF.6571C7AE-- --===============0238987695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --===============0238987695==-- From rddp-bounces@ietf.org Mon Dec 27 16:42:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04404 for ; Mon, 27 Dec 2004 16:42:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cj2oR-0002Ua-EY for rddp-web-archive@ietf.org; Mon, 27 Dec 2004 16:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1hy-0004SK-PW; Mon, 27 Dec 2004 15:43:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cj1da-0002BZ-F0; Mon, 27 Dec 2004 15:38:42 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19990; Mon, 27 Dec 2004 15:38:40 -0500 (EST) Message-Id: <200412272038.PAA19990@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 27 Dec 2004 15:38:40 -0500 Cc: rddp@ietf.org Subject: [rddp] I-D ACTION:draft-ietf-rddp-security-06.txt X-BeenThere: rddp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Remote Direct Data Placement \(rddp\) WG" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rddp-bounces@ietf.org Errors-To: rddp-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Direct Data Placement Working Group of the IETF. Title : DDP/RDMAP Security Author(s) : J. Pinkerton, et al. Filename : draft-ietf-rddp-security-06.txt Pages : 56 Date : 2004-12-27 This document analyzes security issues around implementation and use of the Direct Data Placement Protocol(DDP) and Remote Direct Memory Access Protocol (RDMAP). It first defines an architectural model for an RDMA Network Interface Card (RNIC), which can implement DDP or RDMAP and DDP. The document reviews various attacks against the resources defined in the architectural model and the countermeasures that can be used to protect the system. Attacks are grouped into spoofing, tampering, information disclosure, denial of service, and elevation of privilege. Finally, the document concludes with a summary of security services for RDDP, such as IPSec. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-rddp-security-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-rddp-security-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-12-27154918.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-rddp-security-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-rddp-security-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-12-27154918.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ rddp mailing list rddp@ietf.org https://www1.ietf.org/mailman/listinfo/rddp --NextPart--