From david.black@emc.com Tue Jul 2 06:18:20 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEE321F9CEB for ; Tue, 2 Jul 2013 06:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bbEWiyKFQp8 for ; Tue, 2 Jul 2013 06:18:15 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6142221F9CDC for ; Tue, 2 Jul 2013 06:18:15 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62DICJ5010064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 09:18:12 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Jul 2013 09:18:02 -0400 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62DI1de029364; Tue, 2 Jul 2013 09:18:01 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Tue, 2 Jul 2013 09:18:00 -0400 From: "Black, David" To: Tom Talpey , "storm@ietf.org" , "Paul_Koning@Dell.com" Importance: high X-Priority: 1 Date: Tue, 2 Jul 2013 09:18:00 -0400 Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAEen/Yw Message-ID: <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 13:18:20 -0000 > 1) In section 1 Introduction, the term "IP Storage protocols" is not defi= ned. [... snip ...] > Technically speaking, this comment applies to the title of the document a= s well. I need to propose a new draft title, as that'll be needed to update referen= ces in other drafts. The straightforward thing to do is start from RFC 3723's title, Securing Block Storage Protocols over IP. Therefore I propose the following new title for draft-ietf-storm-ipsec-ips-update; Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3 The abstract and introduction will explain that these requirements have bee= n applied to protocols beyond block storage. Does that work? Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Wednesday, June 26, 2013 5:11 PM > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > Subject: Comments on draft-ietf-storm-ipsec-ips-update >=20 > I have the following comments from a review of the latest draft. >=20 >=20 >=20 > 1) In section 1 Introduction, the term "IP Storage protocols" is not defi= ned. > For example, it's not clear whether NFS or SMB are intended to fall under= this > scope. And the document later refers to the various iWARP specifications, > which are not limited to transporting storage. Assuming that's not the in= tent, > I suggest defining the term, or restating it more generically. Technicall= y > speaking, this comment applies to the title of the document as well. >=20 >=20 >=20 > 2) In section 1 Introduction, the text in the following sentence is vague= : >=20 > ... IP storage protocols can > be expected to operate at high data rates (multiple Gigabits/second); > the requirements in this document are strongly influenced by that > expectation, and hence may not be appropriate for use of IPsec with > other protocols that do not operate at high data rates. >=20 > It's not clear what requirements may not be appropriate, and why. Indeed, > later discussion makes specific requirements for >1Gb, and is silent on l= ower > speed. If the requirements are not applicable in some cases, the cases sh= ould > be named. >=20 > Perhaps simply dropping the entire parenthetical statement "...and hence = may > not...high data rates". >=20 >=20 >=20 > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not cl= ear > what is updated in the many affected documents. Are there any required > changes, outside of extending their RFC3723 references? And presumably, i= t is > not the intention to retroactively make these requirements, therefore any > existing RFC3723-compliant security approach remains intact? Perhaps the > statement would be more accurately "provides updated reference guidance f= or > IPsec security requirements beyond those of RFC3723." >=20 > The requirements for IPsec usage with IP storage in RFC 3723 are used > by a number of protocols. For that reason, beyond updating RFC 3723, > this document also updates the IPsec requirements for each protocol > specification that uses RFC 3723, i.e., the following RFCs in > addition to RFC 3723: >=20 >=20 >=20 > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary and > should be deleted. Is there a reference for the 2^69 birthday bound of AE= S > blocks? Point the discussion there. >=20 > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > block size, which results in an astronomical birthdaya bound (2^69 > bytes). AES CBC is the primary mandatory-to-implement cryptographic >=20 > The word "may" in the relevant requirement is not in RFC2119 form: >=20 > o Implementations that support IKEv2 SHOULD also implement AES GCM > with 128-bit keys; other key sizes may be supported. >=20 >=20 >=20 > 5) Also in section 2.2, the following requirement is unclear whether AES = in > CBC mode MUST be supported, or whether any use of AES in CBC mode MUST be > implemented with a specific minimum key size. It seems the statement is "= AES > in CBC mode SHOULD be supported, with keys that MUST be at least 128 bits= in > length." Correct? >=20 > o AES in CBC mode MUST be implemented with 128-bit keys; other key > sizes MAY be supported, and >=20 >=20 >=20 > 6) Finally, in section 2.2 there is a new MUST requirement. This would ap= pear > to introduce an incompatibility with RFC 3723. Is it a SHOULD? >=20 > In addition, NULL encryption [RFC2410] MUST be implemented to enable > use of SAs that provide data origin authentication and data > integrity, but not confidentiality. Other transforms MAY be > implemented in addition to those listed above. >=20 >=20 From ttalpey@microsoft.com Tue Jul 2 07:08:21 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694FE21F9E45 for ; Tue, 2 Jul 2013 07:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erIeJNDx+84T for ; Tue, 2 Jul 2013 07:08:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 15E9F21F9E4A for ; Tue, 2 Jul 2013 07:08:09 -0700 (PDT) Received: from BN1BFFO11FD007.protection.gbl (10.58.52.201) by BN1AFFO11HUB007.protection.gbl (10.58.52.117) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 2 Jul 2013 14:08:07 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD007.mail.protection.outlook.com (10.58.53.67) with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 2 Jul 2013 14:08:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Tue, 2 Jul 2013 14:07:49 +0000 From: Tom Talpey To: "Black, David" , "storm@ietf.org" , "Paul_Koning@Dell.com" Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal Thread-Index: AQHOdyake/EKhFKYKkimVm1d8CF5RplRbEWw Date: Tue, 2 Jul 2013 14:07:49 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454003)(199002)(51704005)(164054003)(13464003)(54316002)(77096001)(33656001)(69226001)(77982001)(6806003)(23726002)(74706001)(59766001)(80022001)(50466002)(66066001)(65816001)(47736001)(74876001)(76796001)(50986001)(46102001)(55846006)(47976001)(76786001)(49866001)(56816003)(79102001)(46406003)(81342001)(76482001)(51856001)(31966008)(16406001)(561944002)(54356001)(74502001)(74366001)(81542001)(63696002)(74662001)(4396001)(56776001)(53806001)(47776003)(47446002)(83072001)(20776003); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB007; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0895DF8FFD Subject: Re: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:08:21 -0000 Looks good to me. The addition of "Block" is good context, and mirroring th= e previous title is a good approach. I assume the I-D tag (draft-storm-ipsec-ips-update) does not need to change= , since it will be replaced when promoted to RFC. Tom. > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Tuesday, July 2, 2013 9:18 AM > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > Subject: draft-ietf-storm-ipsec-ips-update - New title proposal > Importance: High >=20 > > 1) In section 1 Introduction, the term "IP Storage protocols" is not de= fined. > [... snip ...] > > Technically speaking, this comment applies to the title of the document= as > well. >=20 > I need to propose a new draft title, as that'll be needed to update refer= ences > in other drafts. The straightforward thing to do is start from RFC 3723'= s title, > Securing Block Storage Protocols over IP. Therefore I propose the follow= ing > new title for draft-ietf-storm-ipsec-ips-update; >=20 > Securing Block Storage Protocols over IP: > RFC 3723 Requirements Update for IPsec v3 >=20 > The abstract and introduction will explain that these requirements have b= een > applied to protocols beyond block storage. >=20 > Does that work? >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > Sent: Wednesday, June 26, 2013 5:11 PM > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > I have the following comments from a review of the latest draft. > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not de= fined. > > For example, it's not clear whether NFS or SMB are intended to fall > > under this scope. And the document later refers to the various iWARP > > specifications, which are not limited to transporting storage. > > Assuming that's not the intent, I suggest defining the term, or > > restating it more generically. Technically speaking, this comment appli= es to > the title of the document as well. > > > > > > > > 2) In section 1 Introduction, the text in the following sentence is vag= ue: > > > > ... IP storage protocols can > > be expected to operate at high data rates (multiple Gigabits/second)= ; > > the requirements in this document are strongly influenced by that > > expectation, and hence may not be appropriate for use of IPsec with > > other protocols that do not operate at high data rates. > > > > It's not clear what requirements may not be appropriate, and why. > > Indeed, later discussion makes specific requirements for >1Gb, and is > > silent on lower speed. If the requirements are not applicable in some > > cases, the cases should be named. > > > > Perhaps simply dropping the entire parenthetical statement "...and > > hence may not...high data rates". > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's not > > clear what is updated in the many affected documents. Are there any > > required changes, outside of extending their RFC3723 references? And > > presumably, it is not the intention to retroactively make these > > requirements, therefore any existing RFC3723-compliant security > > approach remains intact? Perhaps the statement would be more > > accurately "provides updated reference guidance for IPsec security > requirements beyond those of RFC3723." > > > > The requirements for IPsec usage with IP storage in RFC 3723 are use= d > > by a number of protocols. For that reason, beyond updating RFC 3723= , > > this document also updates the IPsec requirements for each protocol > > specification that uses RFC 3723, i.e., the following RFCs in > > addition to RFC 3723: > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > and should be deleted. Is there a reference for the 2^69 birthday > > bound of AES blocks? Point the discussion there. > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > > block size, which results in an astronomical birthdaya bound (2^69 > > bytes). AES CBC is the primary mandatory-to-implement > > cryptographic > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > o Implementations that support IKEv2 SHOULD also implement AES GCM > > with 128-bit keys; other key sizes may be supported. > > > > > > > > 5) Also in section 2.2, the following requirement is unclear whether > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > mode MUST be implemented with a specific minimum key size. It seems > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > MUST be at least 128 bits in length." Correct? > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other key > > sizes MAY be supported, and > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This would > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? > > > > In addition, NULL encryption [RFC2410] MUST be implemented to enable > > use of SAs that provide data origin authentication and data > > integrity, but not confidentiality. Other transforms MAY be > > implemented in addition to those listed above. > > > > From david.black@emc.com Tue Jul 2 07:45:18 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA9821F9F77 for ; Tue, 2 Jul 2013 07:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJebhVQl-WiG for ; Tue, 2 Jul 2013 07:45:12 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8546A21F9E91 for ; Tue, 2 Jul 2013 07:45:12 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62Ej4Sb014954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jul 2013 10:45:05 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com [10.254.222.129]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 2 Jul 2013 10:44:54 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62EisbW001801; Tue, 2 Jul 2013 10:44:54 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 2 Jul 2013 10:44:54 -0400 From: "Black, David" To: Tom Talpey , "storm@ietf.org" , "Paul_Koning@Dell.com" Date: Tue, 2 Jul 2013 10:44:53 -0400 Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal Thread-Index: AQHOdyake/EKhFKYKkimVm1d8CF5RplRbEWwgAAKXTA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 14:45:18 -0000 Yes - that filename will remain as-is. I'll make that title change in the -02 version that I submit after WG Last Call completes, and as part of that= , all use of "IP Storage protocols" (and any other use of "IP Storage" will get removed. Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Tuesday, July 02, 2013 10:08 AM > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > Subject: RE: draft-ietf-storm-ipsec-ips-update - New title proposal >=20 > Looks good to me. The addition of "Block" is good context, and mirroring = the > previous title is a good approach. >=20 > I assume the I-D tag (draft-storm-ipsec-ips-update) does not need to chan= ge, > since it will be replaced when promoted to RFC. >=20 > Tom. >=20 > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Tuesday, July 2, 2013 9:18 AM > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > Subject: draft-ietf-storm-ipsec-ips-update - New title proposal > > Importance: High > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not > defined. > > [... snip ...] > > > Technically speaking, this comment applies to the title of the docume= nt as > > well. > > > > I need to propose a new draft title, as that'll be needed to update > references > > in other drafts. The straightforward thing to do is start from RFC 372= 3's > title, > > Securing Block Storage Protocols over IP. Therefore I propose the foll= owing > > new title for draft-ietf-storm-ipsec-ips-update; > > > > Securing Block Storage Protocols over IP: > > RFC 3723 Requirements Update for IPsec v3 > > > > The abstract and introduction will explain that these requirements have= been > > applied to protocols beyond block storage. > > > > Does that work? > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > I have the following comments from a review of the latest draft. > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is not > defined. > > > For example, it's not clear whether NFS or SMB are intended to fall > > > under this scope. And the document later refers to the various iWARP > > > specifications, which are not limited to transporting storage. > > > Assuming that's not the intent, I suggest defining the term, or > > > restating it more generically. Technically speaking, this comment app= lies > to > > the title of the document as well. > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following sentence is v= ague: > > > > > > ... IP storage protocols can > > > be expected to operate at high data rates (multiple Gigabits/secon= d); > > > the requirements in this document are strongly influenced by that > > > expectation, and hence may not be appropriate for use of IPsec wit= h > > > other protocols that do not operate at high data rates. > > > > > > It's not clear what requirements may not be appropriate, and why. > > > Indeed, later discussion makes specific requirements for >1Gb, and is > > > silent on lower speed. If the requirements are not applicable in some > > > cases, the cases should be named. > > > > > > Perhaps simply dropping the entire parenthetical statement "...and > > > hence may not...high data rates". > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's no= t > > > clear what is updated in the many affected documents. Are there any > > > required changes, outside of extending their RFC3723 references? And > > > presumably, it is not the intention to retroactively make these > > > requirements, therefore any existing RFC3723-compliant security > > > approach remains intact? Perhaps the statement would be more > > > accurately "provides updated reference guidance for IPsec security > > requirements beyond those of RFC3723." > > > > > > The requirements for IPsec usage with IP storage in RFC 3723 are u= sed > > > by a number of protocols. For that reason, beyond updating RFC 37= 23, > > > this document also updates the IPsec requirements for each protoco= l > > > specification that uses RFC 3723, i.e., the following RFCs in > > > addition to RFC 3723: > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is unnecessary > > > and should be deleted. Is there a reference for the 2^69 birthday > > > bound of AES blocks? Point the discussion there. > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > > > block size, which results in an astronomical birthdaya bound (2^69 > > > bytes). AES CBC is the primary mandatory-to-implement > > > cryptographic > > > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > > > o Implementations that support IKEv2 SHOULD also implement AES GC= M > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear whether > > > AES in CBC mode MUST be supported, or whether any use of AES in CBC > > > mode MUST be implemented with a specific minimum key size. It seems > > > the statement is "AES in CBC mode SHOULD be supported, with keys that > > > MUST be at least 128 bits in length." Correct? > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other ke= y > > > sizes MAY be supported, and > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This woul= d > > > appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented to enab= le > > > use of SAs that provide data origin authentication and data > > > integrity, but not confidentiality. Other transforms MAY be > > > implemented in addition to those listed above. > > > > > > >=20 From Paul_Koning@Dell.com Tue Jul 2 08:08:11 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED62D11E80D5 for ; Tue, 2 Jul 2013 08:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltgvpx6OeTId for ; Tue, 2 Jul 2013 08:08:00 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id C391E21F9F81 for ; Tue, 2 Jul 2013 08:07:33 -0700 (PDT) X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="4.87,980,1363150800"; d="scan'208";a="172003332" From: To: Thread-Topic: draft-ietf-storm-ipsec-ips-update - New title proposal Thread-Index: AQHOdyadL/l6bQVh20OL/cknnJIXSplRwJWAgAAKW4CAAAZPgA== Date: Tue, 2 Jul 2013 15:07:29 +0000 Message-ID: References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298333250@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EC0B32@TK5EX14MBXC283.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983332A6@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.90.69] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: storm@ietf.org Subject: Re: [storm] draft-ietf-storm-ipsec-ips-update - New title proposal X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 15:08:12 -0000 Sounds good to me. paul On Jul 2, 2013, at 10:44 AM, Black, David wrote: > Yes - that filename will remain as-is. I'll make that title change in th= e > -02 version that I submit after WG Last Call completes, and as part of th= at, > all use of "IP Storage protocols" (and any other use of "IP Storage" will > get removed. >=20 > Thanks, > --David >=20 >> -----Original Message----- >> From: Tom Talpey [mailto:ttalpey@microsoft.com] >> Sent: Tuesday, July 02, 2013 10:08 AM >> To: Black, David; storm@ietf.org; Paul_Koning@Dell.com >> Subject: RE: draft-ietf-storm-ipsec-ips-update - New title proposal >>=20 >> Looks good to me. The addition of "Block" is good context, and mirroring= the >> previous title is a good approach. >>=20 >> I assume the I-D tag (draft-storm-ipsec-ips-update) does not need to cha= nge, >> since it will be replaced when promoted to RFC. >>=20 >> Tom. >>=20 >>> -----Original Message----- >>> From: Black, David [mailto:david.black@emc.com] >>> Sent: Tuesday, July 2, 2013 9:18 AM >>> To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com >>> Subject: draft-ietf-storm-ipsec-ips-update - New title proposal >>> Importance: High >>>=20 >>>> 1) In section 1 Introduction, the term "IP Storage protocols" is not >> defined. >>> [... snip ...] >>>> Technically speaking, this comment applies to the title of the documen= t as >>> well. >>>=20 >>> I need to propose a new draft title, as that'll be needed to update >> references >>> in other drafts. The straightforward thing to do is start from RFC 372= 3's >> title, >>> Securing Block Storage Protocols over IP. Therefore I propose the foll= owing >>> new title for draft-ietf-storm-ipsec-ips-update; >>>=20 >>> Securing Block Storage Protocols over IP: >>> RFC 3723 Requirements Update for IPsec v3 >>>=20 >>> The abstract and introduction will explain that these requirements have= been >>> applied to protocols beyond block storage. >>>=20 >>> Does that work? >>>=20 >>> Thanks, >>> --David >>>=20 >>>> -----Original Message----- >>>> From: Tom Talpey [mailto:ttalpey@microsoft.com] >>>> Sent: Wednesday, June 26, 2013 5:11 PM >>>> To: storm@ietf.org; Black, David; Paul_Koning@Dell.com >>>> Subject: Comments on draft-ietf-storm-ipsec-ips-update >>>>=20 >>>> I have the following comments from a review of the latest draft. >>>>=20 >>>>=20 >>>>=20 >>>> 1) In section 1 Introduction, the term "IP Storage protocols" is not >> defined. >>>> For example, it's not clear whether NFS or SMB are intended to fall >>>> under this scope. And the document later refers to the various iWARP >>>> specifications, which are not limited to transporting storage. >>>> Assuming that's not the intent, I suggest defining the term, or >>>> restating it more generically. Technically speaking, this comment appl= ies >> to >>> the title of the document as well. >>>>=20 >>>>=20 >>>>=20 >>>> 2) In section 1 Introduction, the text in the following sentence is va= gue: >>>>=20 >>>> ... IP storage protocols can >>>> be expected to operate at high data rates (multiple Gigabits/second)= ; >>>> the requirements in this document are strongly influenced by that >>>> expectation, and hence may not be appropriate for use of IPsec with >>>> other protocols that do not operate at high data rates. >>>>=20 >>>> It's not clear what requirements may not be appropriate, and why. >>>> Indeed, later discussion makes specific requirements for >1Gb, and is >>>> silent on lower speed. If the requirements are not applicable in some >>>> cases, the cases should be named. >>>>=20 >>>> Perhaps simply dropping the entire parenthetical statement "...and >>>> hence may not...high data rates". >>>>=20 >>>>=20 >>>>=20 >>>> 3) In section 1.2 Updated RFCs, the word "update" appears but it's not >>>> clear what is updated in the many affected documents. Are there any >>>> required changes, outside of extending their RFC3723 references? And >>>> presumably, it is not the intention to retroactively make these >>>> requirements, therefore any existing RFC3723-compliant security >>>> approach remains intact? Perhaps the statement would be more >>>> accurately "provides updated reference guidance for IPsec security >>> requirements beyond those of RFC3723." >>>>=20 >>>> The requirements for IPsec usage with IP storage in RFC 3723 are use= d >>>> by a number of protocols. For that reason, beyond updating RFC 3723= , >>>> this document also updates the IPsec requirements for each protocol >>>> specification that uses RFC 3723, i.e., the following RFCs in >>>> addition to RFC 3723: >>>>=20 >>>>=20 >>>>=20 >>>> 4) [editorial] In section 2.2 the word "astronomical" is unnecessary >>>> and should be deleted. Is there a reference for the 2^69 birthday >>>> bound of AES blocks? Point the discussion there. >>>>=20 >>>> 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit >>>> block size, which results in an astronomical birthdaya bound (2^69 >>>> bytes). AES CBC is the primary mandatory-to-implement >>>> cryptographic >>>>=20 >>>> The word "may" in the relevant requirement is not in RFC2119 form: >>>>=20 >>>> o Implementations that support IKEv2 SHOULD also implement AES GCM >>>> with 128-bit keys; other key sizes may be supported. >>>>=20 >>>>=20 >>>>=20 >>>> 5) Also in section 2.2, the following requirement is unclear whether >>>> AES in CBC mode MUST be supported, or whether any use of AES in CBC >>>> mode MUST be implemented with a specific minimum key size. It seems >>>> the statement is "AES in CBC mode SHOULD be supported, with keys that >>>> MUST be at least 128 bits in length." Correct? >>>>=20 >>>> o AES in CBC mode MUST be implemented with 128-bit keys; other key >>>> sizes MAY be supported, and >>>>=20 >>>>=20 >>>>=20 >>>> 6) Finally, in section 2.2 there is a new MUST requirement. This would >>>> appear to introduce an incompatibility with RFC 3723. Is it a SHOULD? >>>>=20 >>>> In addition, NULL encryption [RFC2410] MUST be implemented to enable >>>> use of SAs that provide data origin authentication and data >>>> integrity, but not confidentiality. Other transforms MAY be >>>> implemented in addition to those listed above. >>>>=20 >>>>=20 >>=20 >=20 From david.black@emc.com Tue Jul 2 14:49:46 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19BE211E80E0 for ; Tue, 2 Jul 2013 14:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRh3YCu+WDNG for ; Tue, 2 Jul 2013 14:49:41 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E91B021F8A50 for ; Tue, 2 Jul 2013 14:49:40 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62LneqU026404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Jul 2013 17:49:40 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Tue, 2 Jul 2013 17:49:35 -0400 Received: from mxhub26.corp.emc.com (mxhub26.corp.emc.com [10.254.110.182]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r62LnZT1019052 for ; Tue, 2 Jul 2013 17:49:35 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub26.corp.emc.com ([10.254.110.182]) with mapi; Tue, 2 Jul 2013 17:49:35 -0400 From: "Black, David" To: "storm@ietf.org" Date: Tue, 2 Jul 2013 17:49:33 -0400 Thread-Topic: storm WG draft Status - July 2 Thread-Index: Ac53bgoHi8qvQhIoRT6lf3Q0+mOj6Q== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983333BB@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] storm WG draft Status - July 2 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 21:49:46 -0000 It's time for another one of my occasional "where are we?" messages on the storm WG's drafts. 1) iSCSI consolidated draft. Almost done! All of the IESG Evaluation comments have been resolved, and the Discuss positions cleared. A new version is needed to clean up a few things. The IPsec requirements update draft Working Group Last Call needs to finish first before approval of this draft for RFC publication can be announced - see item 5). 2) iSCSI SAM (new features) draft. In WG Last Call through July 10, primarily to check that the iSCSIProtocolLevel text key, and its associated new registry are specified correctly. The hope is to get the revised version submitted before the July 15 cutoff for the Berlin IETF meeting. This will go to the IESG along with the iSCSI MIB draft. 3) iSCSI MIB draft. The IETF Last Call and MIB Doctor review comments have been resolved in the latest version. It's waiting for the iSCSI SAM draft because the MIB's compliance provisions depend on the value of the iSCSIProtocolLevel text key. 4) iSER draft. Almost done! The IESG has approved this draft for publication as an RFC. An editorial update is required to deal with a few minor comments, after which the draft also has to wait for the IPsec requirements update draft Working Group Last Call to finish before approval of this draft for RFC publication can be announced - next item. 5) RFC 3723 IPsec requirements update draft. After working through the IPsec requirements situation for iSER, where we were headed for two different IPsec profiles for iSCSI/iSER vs. iWARP, it became apparent=20 that the right thing to do is update the IPsec requirements in RFC 3723 across the board. The draft that does that is in WG Last Call through tomorrow. My intent is to submit a new version by early next week to enable publication announcements for the iSCSI consolidated draft and iSER drafts (based on revised versions of both) later next week. 6) That leaves the RDMA Extensions draft, whose authors have been patiently waiting for the above to complete. I need to review this draft promptly and send it to Working Group Last Call. This draft will expire next week, so a new version will be needed by July 15 in order to send it to Working Group Last Call. I'm going to try to review this draft over the weekend, and I will offer the authors the choice of how much of my comments to put into the new version vs. treat as initial Working Group Last Call comments. I offer my usual apology for delays caused by my day job having the temerity to interfere with my IETF activity :-). Please feel free to send questions to the list or directly to me. Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Fri Jul 5 16:27:55 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C803321F9D0A for ; Fri, 5 Jul 2013 16:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqmkbBwgS4PX for ; Fri, 5 Jul 2013 16:27:50 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6C82721F9D08 for ; Fri, 5 Jul 2013 16:27:46 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r65NRjCd013731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jul 2013 19:27:46 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 5 Jul 2013 19:27:37 -0400 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r65NRbcZ025782 for ; Fri, 5 Jul 2013 19:27:37 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Fri, 5 Jul 2013 19:27:36 -0400 From: "Black, David" To: "storm@ietf.org" Date: Fri, 5 Jul 2013 19:27:35 -0400 Thread-Topic: iscsi-sam draft: David Black's WG Last Call comments Thread-Index: Ac551zsb7PyMoXFvS8uAzsNAvkfzfQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F2AB7@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iscsi-sam draft: David Black's WG Last Call comments X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 23:27:55 -0000 This draft is in reasonably good shape - it's been reviewed enough times ;-). The IETF reviewers (e.g., Sec-Dir, Gen-ART) aren't acknowledged in the acknowledgements section - I'll leave the decision about whether to acknowledge them (and the ADs who made comments) up to the authors. I found 7 things that need attention, most of them minor. -- Two significant issues: [1] Section 7.1.1 still contains the "logical superset" text: Negotiation of the iSCSIProtocolLevel key to a value corresponding to an RFC indicates that both negotiating parties are compliant to the RFC in question, and agree to support the corresponding PDU formats and semantics on that iSCSI session. An operational value of iSCSI ProtocolLevel =3D "x" on an iSCSI session requires that the iSCSI protocol semantics on that iSCSI session be a logical superset of the capabilities in all RFCs that have claimed values of an iSCSIProtocolLevel less than "x". The above paragraph needs to be removed in favor of the paragraph in the IANA considerations section that begins with the following three sentences: Special care must be taken in the assignment of new values in this registry. Compatibility and interoperability will be adversely impacted if proper care is not exercised. Features using this key are expected to be cumulative. That third sentence above captures the requirement without causing problems if T10 decides to reduce functionality (e.g., hypothetically, T10 could decide in the future to obsolete one of the new task management functions for which this draft specifies iSCSI support). The effect should be the same, as we're going to rely on the expert for the registry to ensure that the proverbial "right thing" happens. [2] Some changes are needed to the IANA registry for the iSCSI Protocol Level values. The proximate reason for these changes is that T10 is going to require that the words "No version claimed" be associated with the value 0 in order to use these values to generate iSCSI version descriptors for use in standard inquiry data (see SPC-4, 6.6.2). Those words need to appear in the registry. OLD Fields to record in the registry: Assigned value, and its associated RFC reference. 0, [RFCxxx] 1, [RFC-cons] 2, [RFCxxx] NEW Fields to record in the registry: Assigned value, description (text string) and associated RFC reference. 0, No version claimed, [RFCxxx] 1, RFC-cons, [RFCxxx] 2, RFCxxx features, [RFCxxx] The reference for the value 1 is now this RFC, even though the features that the value refers to are defined in RFC-cons, so that's another reason to have both a description string and a reference. The RFC EDITORS note needs some slight revision to deal with the fact that I didn't put [square brackets] around the RFC numbers in the description. -- One Procedural item [3] The text in Section 4.2 on SCSI version descriptors requires that T10 approve the associated changes (probably as a proposal adopted for incorporation into SPC-5) before this draft is published as an RFC. The easiest way to deal with this is to insert an RFC EDITORS NOTE at the end of Section 4.2: -------------------------------------------------------- RFC EDITORS NOTE: The specification text in this section requires corresponding changes in a SCSI standard (SPC-4 or SPC-5) that is developed by INCITS Technical Committee T10. Confirmation that these T10 changes have been made is necessary before publishing this draft as an RFC; the contacts for obtaining this confirmation are the draft authors and storm WG chairs. -------------------------------------------------------- If these changes wind up going into SPC-5, this draft may need to reference SPC-5 - that can be dealt with when this draft is ready for RFC publication= . -- Editorial Nits: [4] Section 4.1 contains this sentence twice: The iSCSIProtocolLevel operational text key (see 7.1.1) containing a value of "2" MUST be negotiated to enable the use of features described in this RFC. Once instance will suffice ;-). [5] Near end of 2nd paragraph in Section 4.1: sufficient for hse of the SCSI capabilities enabled by the iSCSI features in this RFC. "sufficient for hse" -> "sufficient for use" [6] At the end of section 5.1.1 See [SAM5] for special considerations on the use of the priority field. The meaning of "special" is unclear in this context - "additional" would be better. [7] Abstract Silly rule - reference citations are forbidden in the Abstract. Change both instances of "[draft-ietf-storm-iscsi-cons-xx]" to "RFCxxx" and make the corresponding change to the RFC EDITORS NOTE. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From david.black@emc.com Fri Jul 5 18:03:32 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD6E11E80FC for ; Fri, 5 Jul 2013 18:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUdrT92BnBRu for ; Fri, 5 Jul 2013 18:03:28 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 99A8C11E80F5 for ; Fri, 5 Jul 2013 18:03:27 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6613OV1016931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jul 2013 21:03:25 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 5 Jul 2013 21:03:04 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6613478011445 for ; Fri, 5 Jul 2013 21:03:04 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Fri, 5 Jul 2013 21:03:04 -0400 From: "Black, David" To: "storm@ietf.org" Date: Fri, 5 Jul 2013 21:03:03 -0400 Thread-Topic: David Black's review of draft-ietf-storm-rdmap-ext-04 Thread-Index: Ac555JDwK6QsDppJRjas//rbxrYADQ== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F2ABC@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] David Black's review of draft-ietf-storm-rdmap-ext-04 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 01:03:33 -0000 As I previously indicated, the authors should revise what they can reasonably edit this coming week and submit a -05 version of this draft by the midnight UTC cutoff on Monday, July 15 [WARNING - that's midnight Greenwich (Zulu) Time, not any US Time and not British Summer Time!]. I'm happy to carry any of the comments below over to become initial WG Last Call comments on that -05 version due to the severe delays in dealing with this draft. Surprising omission - the term "atomic" is never defined (!). No, the definition is not obvious ... a crucial question (which could be answered by a definition or in Section 5.3) is: "Atomic with respect to what?". There are atomic operations defined in other contexts that are atomic only with respect to other atomic operations (and not atomic wrt other non-atomic operations), and I think considerably more is intended here. Section 7 does not appear to be sufficient, as it describes behavior from the viewpoint of a single operation issuer, which does not include behavior with respect to operations that may have been issued from=20 elsewhere, including local memory access by the Remote Peer. Section 4 - say how large the Atomic Request and Atomic Response headers ar= e. Section 4.1 - I think Figure 1 actually contains 3 fields - the two Control Fields and the Invalidate STag field (see Figure 4 in RFC 5040). It would be helpful to add some text below the figure to indicate which bytes are which field (this is also a problem in RFC 5040). Appendix A helps, but the field delineations really need to be here. Throughout section 5 - these operations are specified in terms of "destination address". Would it be better to talk about "buffer offset"? Section 5: The discovery of whether the Atomic Operations are implemented or not is outside the scope of this specification and it should be handled by the ULPs or applications. That's just asking for an IESG Discuss position :-). At least say something about how discovery could work. Moreover, what's wrong with just trying an atomic operation? If the operation fails, the resulting error will be: 0x0/0x2/0x06, Remote Operation Error / Unexpected OpCode It looks like a FetchAdd with Add Data=3D0 is a no-op that could safely be used for this purpose, providing a simple robust discovery mechanism. As part of this, I would add a requirement that if any of the atomic operations are supported, then all of them MUST be supported, so that=20 the FetchAdd no-op can be used to discover all of them. Section 5.1.1: The "multiple fields of selectable length" text in the Add Mask description is not clear - I see how this works, but an example that uses an Add Mask to designate multiple fields would help. the FetchAdd pseudo code contains a lot of doubled complement operations, e.g., carry =3D !(!(sum & 2)) - why is that not carry =3D sum & 2 ?? Section 5.1.2 This sentence in the last paragraph is problematic standing by itself: Additionally an error MUST be surfaced and a terminate message MUST be generated. I think that needs to be combined with the previous sentence to introduce a bullet list of what has to happen when a non-64-bit-aligned address is us= ed: If a Swap Atomic Operation is attempted on a target buffer address that is not 64-bit aligned, then: o The operation MUST NOT be performed, o The Responder's memory MUST NOT be modified, o The result MUST be surfaced as an error, and o A terminate message MUST be generated. In addition, it's important to say which error is generated. Section 8.2 indicates 0x0/0x2/0x07, Remote Operation Error / Catastrophic error, localized to RDMAP Stream - say that here also. Section 5.1.3 Same comments as last paragraph in Section 5.1.2 This section uses "Original Remote Data Value". Sections 5.1.1 and 5.1.2 use "Original Remote Data". All three should use the same term, and based on Section 5.2.2, "Original Remote Data Value" appears to be correct. Section 5.2.1 Request Identifier: 32 bits. The Request Identifier specifies a number that is used to identify Atomic Operation Request Message. The use of this field is implementation dependent and outside the scope of this specification. That's not right. This identifier is returned in the response and used by the Requestor to associate the response to the request. The Requestor can choose any value it likes that enables it to do that, and the details of how those values are generated is outside the scope of this specification, but their use is definitely in scope. Section 10, IANA Considerations: 0x9, Immediate Data with SE, [RFCXXXX] Spell out SE as "Solicited Event" Section 10.1 This one's my fault, partly. The specification of the new registry is based on a version of the rddp registries draft that was subsequently changed (e.g., the Assignment Policy paragraph needs to be removed. See the -02 version of the rddp registries draft for text to use as a model: http://tools.ietf.org/id/draft-ietf-storm-rddp-registries-02.txt I'd suggest working from Section 3.5 in that -02 version. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From donald.e.wood@intel.com Mon Jul 8 12:40:19 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3A21F8FAA for ; Mon, 8 Jul 2013 12:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywZAjL7vxM8C for ; Mon, 8 Jul 2013 12:40:14 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id C99C921F88D2 for ; Mon, 8 Jul 2013 12:40:13 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 08 Jul 2013 12:37:45 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,1021,1363158000"; d="scan'208,217";a="366687201" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga002.jf.intel.com with ESMTP; 08 Jul 2013 12:40:11 -0700 Received: from fmsmsx102.amr.corp.intel.com (10.19.9.53) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 8 Jul 2013 12:39:52 -0700 Received: from fmsmsx105.amr.corp.intel.com ([169.254.5.61]) by FMSMSX102.amr.corp.intel.com ([169.254.2.49]) with mapi id 14.03.0123.003; Mon, 8 Jul 2013 12:37:52 -0700 From: "Wood, Donald E" To: "storm@ietf.org" Thread-Topic: iWARP Storm RFC Comment Thread-Index: Ac57+fia6Bn597bTQp6DiUXuGYEivg== Date: Mon, 8 Jul 2013 19:37:51 +0000 Message-ID: <51C8F64AEA6A2E45A08166544F762D0B53D30AE8@FMSMSX105.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.200.106] Content-Type: multipart/alternative; boundary="_000_51C8F64AEA6A2E45A08166544F762D0B53D30AE8FMSMSX105amrcor_" MIME-Version: 1.0 Subject: [storm] iWARP Storm RFC Comment X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 19:50:41 -0000 --_000_51C8F64AEA6A2E45A08166544F762D0B53D30AE8FMSMSX105amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following text is in section 6.1: * At the Data Sink: * If the Immediate Data operation is Completed successfully, th= e RDMAP Layer passes the following information to the ULP Layer: * Eight bytes of Immediate Data * An Event, if the Data Sink is configured to generate an Event= and the RDMA Message Opcode indicates Message Type Immediate Data with Sol= icited Event. The last bullet is either says too much or too little but is not complete a= s written. The Immediate Data Message (without Solicited Event) may also c= ause an event. One approach is to stop the sentence sooner, "An Event, if the Data Sink is= configured to generate an Event." Another approach is to add another bullet that says almost the same thing, = "An Event, if the Data Sink is configured to generate an Event and the RDMA= Message Opcode indicates Message Type Immediate Data." Don Wood --_000_51C8F64AEA6A2E45A08166544F762D0B53D30AE8FMSMSX105amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following text is in section 6.1:

·         At the Data Sink:

·             If the Immediate Data operation is Completed= successfully, the RDMAP Layer passes the following information to the ULP = Layer:

·             Eight bytes of Immediate Data

·             An Event, if the Data Sink is configured to = generate an Event and the RDMA Message Opcode indicates Message Type Immedi= ate Data with Solicited Event.

The last bullet is either says too much or too littl= e but is not complete as written.  The Immediate Data Message (without= Solicited Event) may also cause an event.

 

One approach is to stop the sentence sooner, “= An Event, if the Data Sink is configured to generate an Event.” 

 

Another approach is to add another bullet that says = almost the same thing, “An Event, if the Data Sink is configured to g= enerate an Event and the RDMA Message Opcode indicates Message Type Immedia= te Data.”

 

Don Wood

--_000_51C8F64AEA6A2E45A08166544F762D0B53D30AE8FMSMSX105amrcor_-- From internet-drafts@ietf.org Tue Jul 9 08:06:18 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4116D21F9EB9; Tue, 9 Jul 2013 08:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWzY9tJwVVKh; Tue, 9 Jul 2013 08:06:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CFE9221F9E8B; Tue, 9 Jul 2013 08:06:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709150617.18812.90832.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 08:06:17 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-ipsec-ips-update-02.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:06:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Securing Block Storage Protocols over IP: RFC 3723 Requi= rements Update for IPsec v3 Author(s) : David Black Paul Koning Filename : draft-ietf-storm-ipsec-ips-update-02.txt Pages : 16 Date : 2013-07-08 Abstract: RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP. This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-ipsec-ips-update-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-ipsec-ips-update-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ttalpey@microsoft.com Tue Jul 9 08:26:13 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1DA321F9E95 for ; Tue, 9 Jul 2013 08:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhhVKgiHYyB9 for ; Tue, 9 Jul 2013 08:26:02 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 4455B21F9DA9 for ; Tue, 9 Jul 2013 08:26:01 -0700 (PDT) Received: from BY2FFO11FD002.protection.gbl (10.1.15.201) by BY2FFO11HUB038.protection.gbl (10.1.14.121) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 9 Jul 2013 15:26:00 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 9 Jul 2013 15:26:00 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.03.0136.001; Tue, 9 Jul 2013 15:25:57 +0000 From: Tom Talpey To: "Black, David" , "Paul_Koning@Dell.com" Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7Q Date: Tue, 9 Jul 2013 15:25:57 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444003)(164054003)(51704005)(13464003)(377454003)(51914003)(31014004)(189002)(199002)(77982001)(31966008)(56816003)(77096001)(50986001)(56776001)(63696002)(69226001)(55846006)(74706001)(49866001)(47976001)(54316002)(59766001)(76786001)(47446002)(4396001)(51856001)(54356001)(20776003)(83072001)(53806001)(66066001)(23726002)(46406003)(79102001)(47736001)(33656001)(47776003)(6806003)(46102001)(74366001)(81542001)(76796001)(74876001)(65816001)(50466002)(74662001)(44976004)(81342001)(74502001)(80022001)(16406001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB038; H:TK5EX14HUBC105.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0902222726 Cc: "storm@ietf.org" Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:26:13 -0000 I reviewed the udated draft-ietf-storm-ipsec-ips-update-02 and the changes = address my earlier concerns, thanks. I did notice one new issue, the new text has a redundancy which is stated s= lightly differently in its two appearances. In section 1, I suggest deletin= g the last paragraph, which restates the second paragraph while adding the = (imo risky) term "any future protocols". For brevity, this document uses the term "block storage protocols" to= =20 refer to all of the above protocols (and any future protocols) to =20 which RFC 3723's requirements (as updated by the requirements in thi= s =20 document) are applicable. =20 =20 > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Friday, June 28, 2013 12:54 AM > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update >=20 > Inline ... >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > Sent: Thursday, June 27, 2013 4:37 PM > > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > ... I could leave > > > 3DES as mandatory to implement for backwards compatibility if that > > > helps, but AES CBC really has to be mandatory to implement due to > > > the problems w/3DES at high data rates. If both AES CBC and 3DES > > > are supported, AES CBC SHOULD be used in preference to 3DES. > > > > I'm ok with this, as long as these requirements are clearly stated. > > Any 3DES support seems to me an implementation choice - a target could > > validly refuse to do so based on data privacy requirements. So I would > > agree it is not a MUST. >=20 > Good - in that case, I'll leave the requirements as they are - the birthd= ay > effects on 3DES justify it becoming a MAY, with AES CBC as the new MUST. > I'll add the "SHOULD be used in preference" sentence. >=20 > > > that developed them. The draft title might be better restated to > > > reference RFC 3723, and I'll see about changing the text from use of > > > "IP Storage protocols" to talking about protocols that use the RFC > > > 3723 IPsec requirements. The first paragraph of the introduction > > > will need to be expanded to explain this. > > > > Sounds good, I'll look for the new proposed text. > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's > > > > not clear what is updated in the many affected documents. Are > > > > there any required changes, outside of extending their RFC3723 > references? > > > > > > Section 1.2 says that it "updates the IPsec requirements for each > > > protocol specification that uses RFC 3723" I think that > > > sufficiently defines the > > scope. > > > > Well, at least I was confused. Consider the reader of one of the > > original documents, who might follow the RFC3723 reference and be > > redirected to this new document. How would they read "updates"? It > > could mean "replaces" or "adds", and the difference will be important > > to an implementation. The text should strive for clarity. >=20 > Sections 2 and 3 and their subsections are clear about what's going on, b= ut > the introduction could use a summary of what is extended vs. actually > changed that section 1.2 could then refer to (the older IPsec requirement= s > are reproduced here so that everything is in one place). I'll do that. >=20 > > > Actually, that is the intention, particularly the 3DES to AES CBC > > > change in mandatory encryption algorithm due to birthday problems > > > with 3DES at high data rates. Older implementations may still claim > > > compliance to RFC 3723 prior to this update, but the intent of this > > > update is to move away from > > 3DES > > > in all cases. > > > > Absolutely. As long as it is clear that this document deprecates 3DES. >=20 > Ok, I need to add text to say that the MUST for 3DES and the SHOULD for A= ES > CTR have each been replaced by a MAY. >=20 > > > The birthday bound calculation for AES is in an email message and > > > hence I'll need to reproduce that in an added appendix. > > > > I guess that would help. I'd be ok with a milder statement which > > leaves birthday bounds to other documents. Surely, storage is not the > > only upper layer which seeks to protect its messages at high data > > rates, so others may have discussed? >=20 > Nope, have a reference for 3DES birthday bound, but not AES. >=20 >=20 > > > The requirement is basically correct as stated, AES in CBC mode with > > > 128-bit keys MUST be supported. Other key sizes for AES in CBC mode > > > are OPTIONAL. > > > I can rephrase in that form if it helps. > > > > I think that would clarify the intent, yes. If you choose OPTIONAL, > > note that there are other places in the document which refer to key > > size. And, instead of "other", would "longer" be better guidance? > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > sentence in section 2.3.1 on Transforms: > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > That is the same requirement expressed in a different fashion. > > > > Ah, ok. The text immediately prior to this paragraph reads "In > > addition", which makes it appear to be a new requirement as are the > > others. Stating that it is an existing requirement of RFC3723 would suf= fice. >=20 > Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll add tex= t there to > make that clear. >=20 > > > > Tom. > > > > > > > > > -----Original Message----- > > > From: Black, David [mailto:david.black@emc.com] > > > Sent: Thursday, June 27, 2013 1:41 AM > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > Tom, > > > > > > Thanks for the thorough review. > > > > > > Most of this is editorial - the one item that is a technical issue > > > is that > > the > > > encryption algorithm requirement changes may not be backwards > > > compatible, as 3DES is no longer appropriate for this use; AES CBC > > > is the > > new > > > mandatory to implement encryption algorithm in this draft. I could > > > leave 3DES as mandatory to implement for backwards compatibility if > > > that helps, but AES CBC really has to be mandatory to implement due > > > to the problems w/3DES at high data rates. If both AES CBC and 3DES > > > are supported, AES CBC SHOULD be used in preference to 3DES. > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is > > > > not > > defined. > > > > For example, it's not clear whether NFS or SMB are intended to > > > > fall under this scope. And the document later refers to the > > > > various iWARP specifications, which are not limited to transporting > storage. > > > > Assuming that's not the intent, I suggest defining the term, or > > > > restating it more generically. Technically speaking, this comment > > > > applies > > to > > > the title of the document as well. > > > > > > I took another look at RFC 3723 - it's entitled "Securing Block > > > Storage Protocols over IP" although, as you point out, its IPsec > > > requirements have been applied to iWARP. I've referred to these > > > requirements as the IP Storage IPsec requirements, in part due to > > > the name of the working group that developed them. The draft title > > > might be better restated to reference RFC 3723, and I'll see about > > > changing the text from use of "IP Storage protocols" to talking > > > about protocols that use the RFC 3723 IPsec requirements. The first > > > paragraph of the introduction will need to be expanded to explain thi= s. > > > > > > > 2) In section 1 Introduction, the text in the following sentence is= vague: > > > > > > > > ... IP storage protocols can > > > > be expected to operate at high data rates (multiple Gigabits/sec= ond); > > > > the requirements in this document are strongly influenced by tha= t > > > > expectation, and hence may not be appropriate for use of IPsec w= ith > > > > other protocols that do not operate at high data rates. > > > > > > > > It's not clear what requirements may not be appropriate, and why. > > > > Indeed, later discussion makes specific requirements for >1Gb, and > > > > is silent on lower speed. If the requirements are not applicable > > > > in some cases, the cases should be named. > > > > > > > > Perhaps simply dropping the entire parenthetical statement "...and > > > > hence may not...high data rates". > > > > > > Sure. > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's > > > > not clear what is updated in the many affected documents. Are > > > > there any required changes, outside of extending their RFC3723 > references? > > > > > > Section 1.2 says that it "updates the IPsec requirements for each > > > protocol specification that uses RFC 3723" I think that > > > sufficiently defines the > > scope. > > > > > > > And presumably, it is > > > > not the intention to retroactively make these requirements, > > > > therefore any existing RFC3723-compliant security approach remains > intact? > > > > > > Actually, that is the intention, particularly the 3DES to AES CBC > > > change in mandatory encryption algorithm due to birthday problems > > > with 3DES at high data rates. Older implementations may still claim > > > compliance to RFC 3723 prior to this update, but the intent of this > > > update is to move away from > > 3DES > > > in all cases. > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > unnecessary and should be deleted > > > > > > Ok. > > > > > > > Is there a reference for the 2^69 birthday bound of AES blocks? > > > > Point the discussion there. > > > > > > The birthday bound calculation for AES is in an email message and > > > hence I'll need to reproduce that in an added appendix. > > > > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > > > > > o Implementations that support IKEv2 SHOULD also implement AES > GCM > > > > with 128-bit keys; other key sizes may be supported > > > > > > Ok. > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > whether AES in CBC mode MUST be supported, or whether any use of > > > > AES in CBC mode MUST be implemented with a specific minimum key > > > > size. It seems the statement is "AES in CBC mode SHOULD be > > > > supported, with keys that MUST be at least 128 bits in length." Cor= rect? > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other > key > > > > sizes MAY be supported, and > > > > > > The requirement is basically correct as stated, AES in CBC mode with > > > 128-bit keys MUST be supported. Other key sizes for AES in CBC mode > > > are OPTIONAL. > > > I can rephrase in that form if it helps. > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This > > > > would appear to introduce an incompatibility with RFC 3723. Is it a > SHOULD? > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > sentence in section 2.3.1 on Transforms: > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > That is the same requirement expressed in a different fashion. > > > > > > Thanks, > > > --David > > > > > > > > > > -----Original Message----- > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > I have the following comments from a review of the latest draft. > > > > > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is > > > > not > > defined. > > > > For example, it's not clear whether NFS or SMB are intended to > > > > fall under this scope. And the document later refers to the > > > > various iWARP specifications, which are not limited to transporting > storage. > > > > Assuming that's not the intent, I suggest defining the term, or > > > > restating it more generically. Technically speaking, this comment > > > > applies > > to > > > the title of the document as well. > > > > > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following sentence is= vague: > > > > > > > > ... IP storage protocols can > > > > be expected to operate at high data rates (multiple Gigabits/sec= ond); > > > > the requirements in this document are strongly influenced by tha= t > > > > expectation, and hence may not be appropriate for use of IPsec w= ith > > > > other protocols that do not operate at high data rates. > > > > > > > > It's not clear what requirements may not be appropriate, and why. > > > > Indeed, later discussion makes specific requirements for >1Gb, and > > > > is silent on lower speed. If the requirements are not applicable > > > > in some cases, the cases should be named. > > > > > > > > Perhaps simply dropping the entire parenthetical statement "...and > > > > hence may not...high data rates". > > > > > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it's > > > > not clear what is updated in the many affected documents. Are > > > > there any required changes, outside of extending their RFC3723 > > > > references? And presumably, it is not the intention to > > > > retroactively make these requirements, therefore any existing > > > > RFC3723-compliant security approach remains intact? Perhaps the > > > > statement would be more accurately "provides updated reference > > > > guidance for IPsec security > > > requirements beyond those of RFC3723." > > > > > > > > The requirements for IPsec usage with IP storage in RFC 3723 are= used > > > > by a number of protocols. For that reason, beyond updating RFC = 3723, > > > > this document also updates the IPsec requirements for each proto= col > > > > specification that uses RFC 3723, i.e., the following RFCs in > > > > addition to RFC 3723: > > > > > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > unnecessary and should be deleted. Is there a reference for the > > > > 2^69 birthday bound of AES blocks? Point the discussion there. > > > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 bit > > > > block size, which results in an astronomical birthdaya bound (2^= 69 > > > > bytes). AES CBC is the primary mandatory-to-implement > > > > cryptographic > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 form: > > > > > > > > o Implementations that support IKEv2 SHOULD also implement AES > GCM > > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > whether AES in CBC mode MUST be supported, or whether any use of > > > > AES in CBC mode MUST be implemented with a specific minimum key > > > > size. It seems the statement is "AES in CBC mode SHOULD be > > > > supported, with keys that MUST be at least 128 bits in length." Cor= rect? > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; other > key > > > > sizes MAY be supported, and > > > > > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This > > > > would appear to introduce an incompatibility with RFC 3723. Is it a > SHOULD? > > > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented to > enable > > > > use of SAs that provide data origin authentication and data > > > > integrity, but not confidentiality. Other transforms MAY be > > > > implemented in addition to those listed above. > > > > > > > > > > From david.black@emc.com Tue Jul 9 09:22:05 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A58E21F9C69 for ; Tue, 9 Jul 2013 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfwz6LPZe99W for ; Tue, 9 Jul 2013 09:21:56 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 44ECA21F9C25 for ; Tue, 9 Jul 2013 09:21:55 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69GLqLd012561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 12:21:53 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Tue, 9 Jul 2013 12:21:38 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69GLcTt031285; Tue, 9 Jul 2013 12:21:38 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub16.corp.emc.com ([128.222.70.237]) with mapi; Tue, 9 Jul 2013 12:21:37 -0400 From: "Black, David" To: Tom Talpey , "Paul_Koning@Dell.com" Importance: high X-Priority: 1 Date: Tue, 9 Jul 2013 12:21:36 -0400 Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7QAAG3MlA= Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "storm@ietf.org" Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:22:05 -0000 Tom, > I reviewed the updated draft-ietf-storm-ipsec-ips-update-02 and the chang= es > address my earlier concerns, thanks. Thank you for checking quickly. > I did notice one new issue, the new text has a redundancy which is stated > slightly differently in its two appearances. In section 1, I suggest dele= ting > the last paragraph, which restates the second paragraph while adding the = (imo > risky) term "any future protocols". I see the concern. I'd prefer to mention the term "block storage protocols= " in the introduction, as that term is used there with its broader meaning, b= ut you're correct about the duplication wrt Section 1.3. Would the following two text changes suffice to address this? - Section 1: OLD For brevity, this document uses the term "block storage protocols" to refer to all protocols to which RFC 3723's requirements (as updated by the requirements in this document) are applicable. NEW For brevity, this document uses the term "block storage protocols" to refer to all protocols to which RFC 3723's requirements apply, see Section 1.3 for details. Section 1.3: OLD For brevity, this document uses the term "block storage protocols" to refer to all of the above protocols (and any future protocols) to which RFC 3723's requirements (as updated by the requirements in this document) are applicable. NEW For brevity, this document uses the term "block storage protocols" to refer to the protocols listed above to which RFC 3723's requirements (as updated by the requirements in this document) apply. If so, I'll submit a -03 version to make those changes Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Tuesday, July 09, 2013 11:26 AM > To: Black, David; Paul_Koning@Dell.com > Cc: storm@ietf.org > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > I reviewed the udated draft-ietf-storm-ipsec-ips-update-02 and the change= s > address my earlier concerns, thanks. > > I did notice one new issue, the new text has a redundancy which is stated > slightly differently in its two appearances. In section 1, I suggest dele= ting > the last paragraph, which restates the second paragraph while adding the = (imo > risky) term "any future protocols". > > For brevity, this document uses the term "block storage protocols" = to > refer to all of the above protocols (and any future protocols) to > which RFC 3723's requirements (as updated by the requirements in t= his > document) are applicable. > > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Friday, June 28, 2013 12:54 AM > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > Inline ... > > > > Thanks, > > --David > > > > > > > -----Original Message----- > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > Sent: Thursday, June 27, 2013 4:37 PM > > > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > ... I could leave > > > > 3DES as mandatory to implement for backwards compatibility if that > > > > helps, but AES CBC really has to be mandatory to implement due to > > > > the problems w/3DES at high data rates. If both AES CBC and 3DES > > > > are supported, AES CBC SHOULD be used in preference to 3DES. > > > > > > I'm ok with this, as long as these requirements are clearly stated. > > > Any 3DES support seems to me an implementation choice - a target coul= d > > > validly refuse to do so based on data privacy requirements. So I woul= d > > > agree it is not a MUST. > > > > Good - in that case, I'll leave the requirements as they are - the birt= hday > > effects on 3DES justify it becoming a MAY, with AES CBC as the new MUST= . > > I'll add the "SHOULD be used in preference" sentence. > > > > > > that developed them. The draft title might be better restated to > > > > reference RFC 3723, and I'll see about changing the text from use o= f > > > > "IP Storage protocols" to talking about protocols that use the RFC > > > > 3723 IPsec requirements. The first paragraph of the introduction > > > > will need to be expanded to explain this. > > > > > > Sounds good, I'll look for the new proposed text. > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it'= s > > > > > not clear what is updated in the many affected documents. Are > > > > > there any required changes, outside of extending their RFC3723 > > references? > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for each > > > > protocol specification that uses RFC 3723" I think that > > > > sufficiently defines the > > > scope. > > > > > > Well, at least I was confused. Consider the reader of one of the > > > original documents, who might follow the RFC3723 reference and be > > > redirected to this new document. How would they read "updates"? It > > > could mean "replaces" or "adds", and the difference will be important > > > to an implementation. The text should strive for clarity. > > > > Sections 2 and 3 and their subsections are clear about what's going on,= but > > the introduction could use a summary of what is extended vs. actually > > changed that section 1.2 could then refer to (the older IPsec requireme= nts > > are reproduced here so that everything is in one place). I'll do that. > > > > > > Actually, that is the intention, particularly the 3DES to AES CBC > > > > change in mandatory encryption algorithm due to birthday problems > > > > with 3DES at high data rates. Older implementations may still clai= m > > > > compliance to RFC 3723 prior to this update, but the intent of this > > > > update is to move away from > > > 3DES > > > > in all cases. > > > > > > Absolutely. As long as it is clear that this document deprecates 3DES= . > > > > Ok, I need to add text to say that the MUST for 3DES and the SHOULD for= AES > > CTR have each been replaced by a MAY. > > > > > > The birthday bound calculation for AES is in an email message and > > > > hence I'll need to reproduce that in an added appendix. > > > > > > I guess that would help. I'd be ok with a milder statement which > > > leaves birthday bounds to other documents. Surely, storage is not the > > > only upper layer which seeks to protect its messages at high data > > > rates, so others may have discussed? > > > > Nope, have a reference for 3DES birthday bound, but not AES. > > > > > > > > The requirement is basically correct as stated, AES in CBC mode wit= h > > > > 128-bit keys MUST be supported. Other key sizes for AES in CBC mod= e > > > > are OPTIONAL. > > > > I can rephrase in that form if it helps. > > > > > > I think that would clarify the intent, yes. If you choose OPTIONAL, > > > note that there are other places in the document which refer to key > > > size. And, instead of "other", would "longer" be better guidance? > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > Ah, ok. The text immediately prior to this paragraph reads "In > > > addition", which makes it appear to be a new requirement as are the > > > others. Stating that it is an existing requirement of RFC3723 would > suffice. > > > > Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll add t= ext > there to > > make that clear. > > > > > > > > Tom. > > > > > > > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:david.black@emc.com] > > > > Sent: Thursday, June 27, 2013 1:41 AM > > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > Tom, > > > > > > > > Thanks for the thorough review. > > > > > > > > Most of this is editorial - the one item that is a technical issue > > > > is that > > > the > > > > encryption algorithm requirement changes may not be backwards > > > > compatible, as 3DES is no longer appropriate for this use; AES CBC > > > > is the > > > new > > > > mandatory to implement encryption algorithm in this draft. I could > > > > leave 3DES as mandatory to implement for backwards compatibility if > > > > that helps, but AES CBC really has to be mandatory to implement due > > > > to the problems w/3DES at high data rates. If both AES CBC and 3DE= S > > > > are supported, AES CBC SHOULD be used in preference to 3DES. > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is > > > > > not > > > defined. > > > > > For example, it's not clear whether NFS or SMB are intended to > > > > > fall under this scope. And the document later refers to the > > > > > various iWARP specifications, which are not limited to transporti= ng > > storage. > > > > > Assuming that's not the intent, I suggest defining the term, or > > > > > restating it more generically. Technically speaking, this comment > > > > > applies > > > to > > > > the title of the document as well. > > > > > > > > I took another look at RFC 3723 - it's entitled "Securing Block > > > > Storage Protocols over IP" although, as you point out, its IPsec > > > > requirements have been applied to iWARP. I've referred to these > > > > requirements as the IP Storage IPsec requirements, in part due to > > > > the name of the working group that developed them. The draft title > > > > might be better restated to reference RFC 3723, and I'll see about > > > > changing the text from use of "IP Storage protocols" to talking > > > > about protocols that use the RFC 3723 IPsec requirements. The firs= t > > > > paragraph of the introduction will need to be expanded to explain t= his. > > > > > > > > > 2) In section 1 Introduction, the text in the following sentence = is > vague: > > > > > > > > > > ... IP storage protocols can > > > > > be expected to operate at high data rates (multiple > Gigabits/second); > > > > > the requirements in this document are strongly influenced by t= hat > > > > > expectation, and hence may not be appropriate for use of IPsec= with > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > It's not clear what requirements may not be appropriate, and why. > > > > > Indeed, later discussion makes specific requirements for >1Gb, an= d > > > > > is silent on lower speed. If the requirements are not applicable > > > > > in some cases, the cases should be named. > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement "...an= d > > > > > hence may not...high data rates". > > > > > > > > Sure. > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it'= s > > > > > not clear what is updated in the many affected documents. Are > > > > > there any required changes, outside of extending their RFC3723 > > references? > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for each > > > > protocol specification that uses RFC 3723" I think that > > > > sufficiently defines the > > > scope. > > > > > > > > > And presumably, it is > > > > > not the intention to retroactively make these requirements, > > > > > therefore any existing RFC3723-compliant security approach remain= s > > intact? > > > > > > > > Actually, that is the intention, particularly the 3DES to AES CBC > > > > change in mandatory encryption algorithm due to birthday problems > > > > with 3DES at high data rates. Older implementations may still clai= m > > > > compliance to RFC 3723 prior to this update, but the intent of this > > > > update is to move away from > > > 3DES > > > > in all cases. > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > unnecessary and should be deleted > > > > > > > > Ok. > > > > > > > > > Is there a reference for the 2^69 birthday bound of AES blocks? > > > > > Point the discussion there. > > > > > > > > The birthday bound calculation for AES is in an email message and > > > > hence I'll need to reproduce that in an added appendix. > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 form= : > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implement AE= S > > GCM > > > > > with 128-bit keys; other key sizes may be supported > > > > > > > > Ok. > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > whether AES in CBC mode MUST be supported, or whether any use of > > > > > AES in CBC mode MUST be implemented with a specific minimum key > > > > > size. It seems the statement is "AES in CBC mode SHOULD be > > > > > supported, with keys that MUST be at least 128 bits in length." > Correct? > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; othe= r > > key > > > > > sizes MAY be supported, and > > > > > > > > The requirement is basically correct as stated, AES in CBC mode wit= h > > > > 128-bit keys MUST be supported. Other key sizes for AES in CBC mod= e > > > > are OPTIONAL. > > > > I can rephrase in that form if it helps. > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This > > > > > would appear to introduce an incompatibility with RFC 3723. Is it= a > > SHOULD? > > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > > > Thanks, > > > > --David > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > I have the following comments from a review of the latest draft. > > > > > > > > > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" is > > > > > not > > > defined. > > > > > For example, it's not clear whether NFS or SMB are intended to > > > > > fall under this scope. And the document later refers to the > > > > > various iWARP specifications, which are not limited to transporti= ng > > storage. > > > > > Assuming that's not the intent, I suggest defining the term, or > > > > > restating it more generically. Technically speaking, this comment > > > > > applies > > > to > > > > the title of the document as well. > > > > > > > > > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following sentence = is > vague: > > > > > > > > > > ... IP storage protocols can > > > > > be expected to operate at high data rates (multiple > Gigabits/second); > > > > > the requirements in this document are strongly influenced by t= hat > > > > > expectation, and hence may not be appropriate for use of IPsec= with > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > It's not clear what requirements may not be appropriate, and why. > > > > > Indeed, later discussion makes specific requirements for >1Gb, an= d > > > > > is silent on lower speed. If the requirements are not applicable > > > > > in some cases, the cases should be named. > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement "...an= d > > > > > hence may not...high data rates". > > > > > > > > > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but it'= s > > > > > not clear what is updated in the many affected documents. Are > > > > > there any required changes, outside of extending their RFC3723 > > > > > references? And presumably, it is not the intention to > > > > > retroactively make these requirements, therefore any existing > > > > > RFC3723-compliant security approach remains intact? Perhaps the > > > > > statement would be more accurately "provides updated reference > > > > > guidance for IPsec security > > > > requirements beyond those of RFC3723." > > > > > > > > > > The requirements for IPsec usage with IP storage in RFC 3723 a= re > used > > > > > by a number of protocols. For that reason, beyond updating RF= C > 3723, > > > > > this document also updates the IPsec requirements for each pro= tocol > > > > > specification that uses RFC 3723, i.e., the following RFCs in > > > > > addition to RFC 3723: > > > > > > > > > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > unnecessary and should be deleted. Is there a reference for the > > > > > 2^69 birthday bound of AES blocks? Point the discussion there. > > > > > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128 b= it > > > > > block size, which results in an astronomical birthdaya bound (= 2^69 > > > > > bytes). AES CBC is the primary mandatory-to-implement > > > > > cryptographic > > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 form= : > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implement AE= S > > GCM > > > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > whether AES in CBC mode MUST be supported, or whether any use of > > > > > AES in CBC mode MUST be implemented with a specific minimum key > > > > > size. It seems the statement is "AES in CBC mode SHOULD be > > > > > supported, with keys that MUST be at least 128 bits in length." > Correct? > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; othe= r > > key > > > > > sizes MAY be supported, and > > > > > > > > > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. This > > > > > would appear to introduce an incompatibility with RFC 3723. Is it= a > > SHOULD? > > > > > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented to > > enable > > > > > use of SAs that provide data origin authentication and data > > > > > integrity, but not confidentiality. Other transforms MAY be > > > > > implemented in addition to those listed above. > > > > > > > > > > > > > > From ttalpey@microsoft.com Tue Jul 9 09:28:36 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0222821F9E66 for ; Tue, 9 Jul 2013 09:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkigHOiHcwVs for ; Tue, 9 Jul 2013 09:28:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id A8CCA21F9E3C for ; Tue, 9 Jul 2013 09:28:29 -0700 (PDT) Received: from BY2FFO11FD025.protection.gbl (10.1.15.204) by BY2FFO11HUB002.protection.gbl (10.1.14.144) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 9 Jul 2013 16:28:28 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD025.mail.protection.outlook.com (10.1.15.214) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 9 Jul 2013 16:28:28 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.79]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.03.0136.001; Tue, 9 Jul 2013 16:27:51 +0000 From: Tom Talpey To: "Black, David" , "Paul_Koning@Dell.com" Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7QAAG3MlAAAIbegA== Date: Tue, 9 Jul 2013 16:27:51 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914003)(377454003)(51704005)(31014004)(199002)(189002)(13464003)(164054003)(51444003)(33656001)(46406003)(63696002)(47446002)(44976004)(77982001)(50466002)(74366001)(76482001)(76796001)(77096001)(23726002)(79102001)(83072001)(54316002)(56776001)(53806001)(74706001)(31966008)(54356001)(81342001)(81542001)(59766001)(66066001)(47736001)(49866001)(6806003)(80022001)(74662001)(55846006)(50986001)(56816003)(47976001)(47776003)(76786001)(74876001)(46102001)(20776003)(4396001)(51856001)(16406001)(65816001)(69226001)(74502001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB002; H:TK5EX14HUBC104.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0902222726 Cc: "storm@ietf.org" Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:28:36 -0000 Sure, I'm ok with the new disambiguation. Editorially, I would suggest remo= ving the second use of "For brevity", to make a simple declarative statemen= t in 1.3. Tom. > -----Original Message----- > From: Black, David [mailto:david.black@emc.com] > Sent: Tuesday, July 9, 2013 12:22 PM > To: Tom Talpey; Paul_Koning@Dell.com > Cc: storm@ietf.org > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > Importance: High >=20 > Tom, >=20 > > I reviewed the updated draft-ietf-storm-ipsec-ips-update-02 and the > > changes address my earlier concerns, thanks. >=20 > Thank you for checking quickly. >=20 > > I did notice one new issue, the new text has a redundancy which is > > stated slightly differently in its two appearances. In section 1, I > > suggest deleting the last paragraph, which restates the second > > paragraph while adding the (imo > > risky) term "any future protocols". >=20 > I see the concern. I'd prefer to mention the term "block storage protoco= ls" > in the introduction, as that term is used there with its broader meaning,= but > you're correct about the duplication wrt Section 1.3. >=20 > Would the following two text changes suffice to address this? - >=20 > Section 1: >=20 > OLD > For brevity, this document uses the term "block storage protocols" to > refer to all protocols to which RFC 3723's requirements (as updated > by the requirements in this document) are applicable. > NEW > For brevity, this document uses the term "block storage protocols" to > refer to all protocols to which RFC 3723's requirements apply, see > Section 1.3 for details. >=20 > Section 1.3: >=20 > OLD > For brevity, this document uses the term "block storage protocols" to > refer to all of the above protocols (and any future protocols) to > which RFC 3723's requirements (as updated by the requirements in this > document) are applicable. > NEW > For brevity, this document uses the term "block storage protocols" to > refer to the protocols listed above to which RFC 3723's requirements > (as updated by the requirements in this document) apply. >=20 > If so, I'll submit a -03 version to make those changes >=20 > Thanks, > --David >=20 > > -----Original Message----- > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > Sent: Tuesday, July 09, 2013 11:26 AM > > To: Black, David; Paul_Koning@Dell.com > > Cc: storm@ietf.org > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > I reviewed the udated draft-ietf-storm-ipsec-ips-update-02 and the > > changes address my earlier concerns, thanks. > > > > I did notice one new issue, the new text has a redundancy which is > > stated slightly differently in its two appearances. In section 1, I > > suggest deleting the last paragraph, which restates the second > > paragraph while adding the (imo > > risky) term "any future protocols". > > > > For brevity, this document uses the term "block storage protocols= " to > > refer to all of the above protocols (and any future protocols) t= o > > which RFC 3723's requirements (as updated by the requirements in= this > > document) are applicable. > > > > > > > -----Original Message----- > > > From: Black, David [mailto:david.black@emc.com] > > > Sent: Friday, June 28, 2013 12:54 AM > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > Inline ... > > > > > > Thanks, > > > --David > > > > > > > > > > -----Original Message----- > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > Sent: Thursday, June 27, 2013 4:37 PM > > > > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > ... I could leave > > > > > 3DES as mandatory to implement for backwards compatibility if > > > > > that helps, but AES CBC really has to be mandatory to implement > > > > > due to the problems w/3DES at high data rates. If both AES CBC > > > > > and 3DES are supported, AES CBC SHOULD be used in preference to > 3DES. > > > > > > > > I'm ok with this, as long as these requirements are clearly stated. > > > > Any 3DES support seems to me an implementation choice - a target > > > > could validly refuse to do so based on data privacy requirements. > > > > So I would agree it is not a MUST. > > > > > > Good - in that case, I'll leave the requirements as they are - the > > > birthday effects on 3DES justify it becoming a MAY, with AES CBC as t= he > new MUST. > > > I'll add the "SHOULD be used in preference" sentence. > > > > > > > > that developed them. The draft title might be better restated > > > > > to reference RFC 3723, and I'll see about changing the text from > > > > > use of "IP Storage protocols" to talking about protocols that > > > > > use the RFC > > > > > 3723 IPsec requirements. The first paragraph of the > > > > > introduction will need to be expanded to explain this. > > > > > > > > Sounds good, I'll look for the new proposed text. > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > it's not clear what is updated in the many affected documents. > > > > > > Are there any required changes, outside of extending their > > > > > > RFC3723 > > > references? > > > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for > > > > > each protocol specification that uses RFC 3723" I think that > > > > > sufficiently defines the > > > > scope. > > > > > > > > Well, at least I was confused. Consider the reader of one of the > > > > original documents, who might follow the RFC3723 reference and be > > > > redirected to this new document. How would they read "updates"? It > > > > could mean "replaces" or "adds", and the difference will be > > > > important to an implementation. The text should strive for clarity. > > > > > > Sections 2 and 3 and their subsections are clear about what's going > > > on, but the introduction could use a summary of what is extended vs. > > > actually changed that section 1.2 could then refer to (the older > > > IPsec requirements are reproduced here so that everything is in one > place). I'll do that. > > > > > > > > Actually, that is the intention, particularly the 3DES to AES > > > > > CBC change in mandatory encryption algorithm due to birthday > > > > > problems with 3DES at high data rates. Older implementations > > > > > may still claim compliance to RFC 3723 prior to this update, but > > > > > the intent of this update is to move away from > > > > 3DES > > > > > in all cases. > > > > > > > > Absolutely. As long as it is clear that this document deprecates 3D= ES. > > > > > > Ok, I need to add text to say that the MUST for 3DES and the SHOULD > > > for AES CTR have each been replaced by a MAY. > > > > > > > > The birthday bound calculation for AES is in an email message > > > > > and hence I'll need to reproduce that in an added appendix. > > > > > > > > I guess that would help. I'd be ok with a milder statement which > > > > leaves birthday bounds to other documents. Surely, storage is not > > > > the only upper layer which seeks to protect its messages at high > > > > data rates, so others may have discussed? > > > > > > Nope, have a reference for 3DES birthday bound, but not AES. > > > > > > > > > > > The requirement is basically correct as stated, AES in CBC mode > > > > > with 128-bit keys MUST be supported. Other key sizes for AES in > > > > > CBC mode are OPTIONAL. > > > > > I can rephrase in that form if it helps. > > > > > > > > I think that would clarify the intent, yes. If you choose > > > > OPTIONAL, note that there are other places in the document which > > > > refer to key size. And, instead of "other", would "longer" be bette= r > guidance? > > > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > > > Ah, ok. The text immediately prior to this paragraph reads "In > > > > addition", which makes it appear to be a new requirement as are > > > > the others. Stating that it is an existing requirement of RFC3723 > > > > would > > suffice. > > > > > > Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll > > > add text > > there to > > > make that clear. > > > > > > > > > > > Tom. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > Sent: Thursday, June 27, 2013 1:41 AM > > > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > Tom, > > > > > > > > > > Thanks for the thorough review. > > > > > > > > > > Most of this is editorial - the one item that is a technical > > > > > issue is that > > > > the > > > > > encryption algorithm requirement changes may not be backwards > > > > > compatible, as 3DES is no longer appropriate for this use; AES > > > > > CBC is the > > > > new > > > > > mandatory to implement encryption algorithm in this draft. I > > > > > could leave 3DES as mandatory to implement for backwards > > > > > compatibility if that helps, but AES CBC really has to be > > > > > mandatory to implement due to the problems w/3DES at high data > > > > > rates. If both AES CBC and 3DES are supported, AES CBC SHOULD be > used in preference to 3DES. > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" > > > > > > is not > > > > defined. > > > > > > For example, it's not clear whether NFS or SMB are intended to > > > > > > fall under this scope. And the document later refers to the > > > > > > various iWARP specifications, which are not limited to > > > > > > transporting > > > storage. > > > > > > Assuming that's not the intent, I suggest defining the term, > > > > > > or restating it more generically. Technically speaking, this > > > > > > comment applies > > > > to > > > > > the title of the document as well. > > > > > > > > > > I took another look at RFC 3723 - it's entitled "Securing Block > > > > > Storage Protocols over IP" although, as you point out, its IPsec > > > > > requirements have been applied to iWARP. I've referred to these > > > > > requirements as the IP Storage IPsec requirements, in part due > > > > > to the name of the working group that developed them. The draft > > > > > title might be better restated to reference RFC 3723, and I'll > > > > > see about changing the text from use of "IP Storage protocols" > > > > > to talking about protocols that use the RFC 3723 IPsec > > > > > requirements. The first paragraph of the introduction will need = to be > expanded to explain this. > > > > > > > > > > > 2) In section 1 Introduction, the text in the following > > > > > > sentence is > > vague: > > > > > > > > > > > > ... IP storage protocols can > > > > > > be expected to operate at high data rates (multiple > > Gigabits/second); > > > > > > the requirements in this document are strongly influenced by= that > > > > > > expectation, and hence may not be appropriate for use of IPs= ec > with > > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > > > It's not clear what requirements may not be appropriate, and wh= y. > > > > > > Indeed, later discussion makes specific requirements for >1Gb, > > > > > > and is silent on lower speed. If the requirements are not > > > > > > applicable in some cases, the cases should be named. > > > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement > > > > > > "...and hence may not...high data rates". > > > > > > > > > > Sure. > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > it's not clear what is updated in the many affected documents. > > > > > > Are there any required changes, outside of extending their > > > > > > RFC3723 > > > references? > > > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for > > > > > each protocol specification that uses RFC 3723" I think that > > > > > sufficiently defines the > > > > scope. > > > > > > > > > > > And presumably, it is > > > > > > not the intention to retroactively make these requirements, > > > > > > therefore any existing RFC3723-compliant security approach > > > > > > remains > > > intact? > > > > > > > > > > Actually, that is the intention, particularly the 3DES to AES > > > > > CBC change in mandatory encryption algorithm due to birthday > > > > > problems with 3DES at high data rates. Older implementations > > > > > may still claim compliance to RFC 3723 prior to this update, but > > > > > the intent of this update is to move away from > > > > 3DES > > > > > in all cases. > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > > unnecessary and should be deleted > > > > > > > > > > Ok. > > > > > > > > > > > Is there a reference for the 2^69 birthday bound of AES blocks? > > > > > > Point the discussion there. > > > > > > > > > > The birthday bound calculation for AES is in an email message > > > > > and hence I'll need to reproduce that in an added appendix. > > > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 fo= rm: > > > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implement > > > > > > AES > > > GCM > > > > > > with 128-bit keys; other key sizes may be supported > > > > > > > > > > Ok. > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > > whether AES in CBC mode MUST be supported, or whether any use > > > > > > of AES in CBC mode MUST be implemented with a specific minimum > > > > > > key size. It seems the statement is "AES in CBC mode SHOULD be > > > > > > supported, with keys that MUST be at least 128 bits in length." > > Correct? > > > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; > > > > > > other > > > key > > > > > > sizes MAY be supported, and > > > > > > > > > > The requirement is basically correct as stated, AES in CBC mode > > > > > with 128-bit keys MUST be supported. Other key sizes for AES in > > > > > CBC mode are OPTIONAL. > > > > > I can rephrase in that form if it helps. > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. > > > > > > This would appear to introduce an incompatibility with RFC > > > > > > 3723. Is it a > > > SHOULD? > > > > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > > > ESP with NULL encryption MUST be supported for authentication. > > > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > > > > > Thanks, > > > > > --David > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > > > I have the following comments from a review of the latest draft= . > > > > > > > > > > > > > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" > > > > > > is not > > > > defined. > > > > > > For example, it's not clear whether NFS or SMB are intended to > > > > > > fall under this scope. And the document later refers to the > > > > > > various iWARP specifications, which are not limited to > > > > > > transporting > > > storage. > > > > > > Assuming that's not the intent, I suggest defining the term, > > > > > > or restating it more generically. Technically speaking, this > > > > > > comment applies > > > > to > > > > > the title of the document as well. > > > > > > > > > > > > > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following > > > > > > sentence is > > vague: > > > > > > > > > > > > ... IP storage protocols can > > > > > > be expected to operate at high data rates (multiple > > Gigabits/second); > > > > > > the requirements in this document are strongly influenced by= that > > > > > > expectation, and hence may not be appropriate for use of IPs= ec > with > > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > > > It's not clear what requirements may not be appropriate, and wh= y. > > > > > > Indeed, later discussion makes specific requirements for >1Gb, > > > > > > and is silent on lower speed. If the requirements are not > > > > > > applicable in some cases, the cases should be named. > > > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement > > > > > > "...and hence may not...high data rates". > > > > > > > > > > > > > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > it's not clear what is updated in the many affected documents. > > > > > > Are there any required changes, outside of extending their > > > > > > RFC3723 references? And presumably, it is not the intention to > > > > > > retroactively make these requirements, therefore any existing > > > > > > RFC3723-compliant security approach remains intact? Perhaps > > > > > > the statement would be more accurately "provides updated > > > > > > reference guidance for IPsec security > > > > > requirements beyond those of RFC3723." > > > > > > > > > > > > The requirements for IPsec usage with IP storage in RFC > > > > > > 3723 are > > used > > > > > > by a number of protocols. For that reason, beyond updating > > > > > > RFC > > 3723, > > > > > > this document also updates the IPsec requirements for each > protocol > > > > > > specification that uses RFC 3723, i.e., the following RFCs i= n > > > > > > addition to RFC 3723: > > > > > > > > > > > > > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > > unnecessary and should be deleted. Is there a reference for > > > > > > the > > > > > > 2^69 birthday bound of AES blocks? Point the discussion there. > > > > > > > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 128= bit > > > > > > block size, which results in an astronomical birthdaya bound= (2^69 > > > > > > bytes). AES CBC is the primary mandatory-to-implement > > > > > > cryptographic > > > > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 fo= rm: > > > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implement > > > > > > AES > > > GCM > > > > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > > whether AES in CBC mode MUST be supported, or whether any use > > > > > > of AES in CBC mode MUST be implemented with a specific minimum > > > > > > key size. It seems the statement is "AES in CBC mode SHOULD be > > > > > > supported, with keys that MUST be at least 128 bits in length." > > Correct? > > > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; > > > > > > other > > > key > > > > > > sizes MAY be supported, and > > > > > > > > > > > > > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. > > > > > > This would appear to introduce an incompatibility with RFC > > > > > > 3723. Is it a > > > SHOULD? > > > > > > > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented > > > > > > to > > > enable > > > > > > use of SAs that provide data origin authentication and data > > > > > > integrity, but not confidentiality. Other transforms MAY be > > > > > > implemented in addition to those listed above. > > > > > > > > > > > > > > > > > > From david.black@emc.com Tue Jul 9 09:54:20 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F97221F9E1D for ; Tue, 9 Jul 2013 09:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4k8asLz6iuJ for ; Tue, 9 Jul 2013 09:54:08 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 171EC21F9E32 for ; Tue, 9 Jul 2013 09:54:07 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69Gs0Hj014328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Jul 2013 12:54:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Tue, 9 Jul 2013 12:53:43 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r69GrhD6004479; Tue, 9 Jul 2013 12:53:43 -0400 Received: from mxhub37.corp.emc.com (128.222.70.104) by mxhub04.corp.emc.com (10.254.141.106) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 9 Jul 2013 12:53:43 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub37.corp.emc.com ([128.222.70.104]) with mapi; Tue, 9 Jul 2013 12:53:42 -0400 From: "Black, David" To: Tom Talpey , "Paul_Koning@Dell.com" Date: Tue, 9 Jul 2013 12:53:41 -0400 Thread-Topic: Comments on draft-ietf-storm-ipsec-ips-update Thread-Index: Ac5yqwuewpr4eeBIT2quJXY1BPmnxAASCVKwABICU1AAH1Nd4AI/1d7QAAG3MlAAAIbegAAA/D2w Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F2DAC@MX15A.corp.emc.com> References: <614F550557B82C44AC27C492ADA391AA0774F9A0@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332C1E@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA07750ACC@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE71298332DB8@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEABF7@TK5EX14MBXC284.redmond.corp.microsoft.com> <8D3D17ACE214DC429325B2B98F3AE712983F2DA1@MX15A.corp.emc.com> <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <614F550557B82C44AC27C492ADA391AA11EEAE54@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "storm@ietf.org" Subject: Re: [storm] Comments on draft-ietf-storm-ipsec-ips-update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 16:54:20 -0000 Great, I'll do that - the resulting -03 with these two changes should be co= ming later today. Thanks, --David > -----Original Message----- > From: Tom Talpey [mailto:ttalpey@microsoft.com] > Sent: Tuesday, July 09, 2013 12:28 PM > To: Black, David; Paul_Koning@Dell.com > Cc: storm@ietf.org > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > Sure, I'm ok with the new disambiguation. Editorially, I would suggest > removing the second use of "For brevity", to make a simple declarative > statement in 1.3. > > Tom. > > > -----Original Message----- > > From: Black, David [mailto:david.black@emc.com] > > Sent: Tuesday, July 9, 2013 12:22 PM > > To: Tom Talpey; Paul_Koning@Dell.com > > Cc: storm@ietf.org > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > Importance: High > > > > Tom, > > > > > I reviewed the updated draft-ietf-storm-ipsec-ips-update-02 and the > > > changes address my earlier concerns, thanks. > > > > Thank you for checking quickly. > > > > > I did notice one new issue, the new text has a redundancy which is > > > stated slightly differently in its two appearances. In section 1, I > > > suggest deleting the last paragraph, which restates the second > > > paragraph while adding the (imo > > > risky) term "any future protocols". > > > > I see the concern. I'd prefer to mention the term "block storage proto= cols" > > in the introduction, as that term is used there with its broader meanin= g, but > > you're correct about the duplication wrt Section 1.3. > > > > Would the following two text changes suffice to address this? - > > > > Section 1: > > > > OLD > > For brevity, this document uses the term "block storage protocols" t= o > > refer to all protocols to which RFC 3723's requirements (as updated > > by the requirements in this document) are applicable. > > NEW > > For brevity, this document uses the term "block storage protocols" t= o > > refer to all protocols to which RFC 3723's requirements apply, see > > Section 1.3 for details. > > > > Section 1.3: > > > > OLD > > For brevity, this document uses the term "block storage protocols" t= o > > refer to all of the above protocols (and any future protocols) to > > which RFC 3723's requirements (as updated by the requirements in thi= s > > document) are applicable. > > NEW > > For brevity, this document uses the term "block storage protocols" t= o > > refer to the protocols listed above to which RFC 3723's requirements > > (as updated by the requirements in this document) apply. > > > > If so, I'll submit a -03 version to make those changes > > > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > Sent: Tuesday, July 09, 2013 11:26 AM > > > To: Black, David; Paul_Koning@Dell.com > > > Cc: storm@ietf.org > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > I reviewed the udated draft-ietf-storm-ipsec-ips-update-02 and the > > > changes address my earlier concerns, thanks. > > > > > > I did notice one new issue, the new text has a redundancy which is > > > stated slightly differently in its two appearances. In section 1, I > > > suggest deleting the last paragraph, which restates the second > > > paragraph while adding the (imo > > > risky) term "any future protocols". > > > > > > For brevity, this document uses the term "block storage protoco= ls" > to > > > refer to all of the above protocols (and any future protocols)= to > > > which RFC 3723's requirements (as updated by the requirements = in > this > > > document) are applicable. > > > > > > > > > > -----Original Message----- > > > > From: Black, David [mailto:david.black@emc.com] > > > > Sent: Friday, June 28, 2013 12:54 AM > > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > Inline ... > > > > > > > > Thanks, > > > > --David > > > > > > > > > > > > > -----Original Message----- > > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > > Sent: Thursday, June 27, 2013 4:37 PM > > > > > To: Black, David; storm@ietf.org; Paul_Koning@Dell.com > > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > > ... I could leave > > > > > > 3DES as mandatory to implement for backwards compatibility if > > > > > > that helps, but AES CBC really has to be mandatory to implement > > > > > > due to the problems w/3DES at high data rates. If both AES CBC > > > > > > and 3DES are supported, AES CBC SHOULD be used in preference to > > 3DES. > > > > > > > > > > I'm ok with this, as long as these requirements are clearly state= d. > > > > > Any 3DES support seems to me an implementation choice - a target > > > > > could validly refuse to do so based on data privacy requirements. > > > > > So I would agree it is not a MUST. > > > > > > > > Good - in that case, I'll leave the requirements as they are - the > > > > birthday effects on 3DES justify it becoming a MAY, with AES CBC as= the > > new MUST. > > > > I'll add the "SHOULD be used in preference" sentence. > > > > > > > > > > that developed them. The draft title might be better restated > > > > > > to reference RFC 3723, and I'll see about changing the text fro= m > > > > > > use of "IP Storage protocols" to talking about protocols that > > > > > > use the RFC > > > > > > 3723 IPsec requirements. The first paragraph of the > > > > > > introduction will need to be expanded to explain this. > > > > > > > > > > Sounds good, I'll look for the new proposed text. > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > > it's not clear what is updated in the many affected documents= . > > > > > > > Are there any required changes, outside of extending their > > > > > > > RFC3723 > > > > references? > > > > > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for > > > > > > each protocol specification that uses RFC 3723" I think that > > > > > > sufficiently defines the > > > > > scope. > > > > > > > > > > Well, at least I was confused. Consider the reader of one of the > > > > > original documents, who might follow the RFC3723 reference and be > > > > > redirected to this new document. How would they read "updates"? I= t > > > > > could mean "replaces" or "adds", and the difference will be > > > > > important to an implementation. The text should strive for clarit= y. > > > > > > > > Sections 2 and 3 and their subsections are clear about what's going > > > > on, but the introduction could use a summary of what is extended vs= . > > > > actually changed that section 1.2 could then refer to (the older > > > > IPsec requirements are reproduced here so that everything is in one > > place). I'll do that. > > > > > > > > > > Actually, that is the intention, particularly the 3DES to AES > > > > > > CBC change in mandatory encryption algorithm due to birthday > > > > > > problems with 3DES at high data rates. Older implementations > > > > > > may still claim compliance to RFC 3723 prior to this update, bu= t > > > > > > the intent of this update is to move away from > > > > > 3DES > > > > > > in all cases. > > > > > > > > > > Absolutely. As long as it is clear that this document deprecates = 3DES. > > > > > > > > Ok, I need to add text to say that the MUST for 3DES and the SHOULD > > > > for AES CTR have each been replaced by a MAY. > > > > > > > > > > The birthday bound calculation for AES is in an email message > > > > > > and hence I'll need to reproduce that in an added appendix. > > > > > > > > > > I guess that would help. I'd be ok with a milder statement which > > > > > leaves birthday bounds to other documents. Surely, storage is not > > > > > the only upper layer which seeks to protect its messages at high > > > > > data rates, so others may have discussed? > > > > > > > > Nope, have a reference for 3DES birthday bound, but not AES. > > > > > > > > > > > > > > The requirement is basically correct as stated, AES in CBC mode > > > > > > with 128-bit keys MUST be supported. Other key sizes for AES i= n > > > > > > CBC mode are OPTIONAL. > > > > > > I can rephrase in that form if it helps. > > > > > > > > > > I think that would clarify the intent, yes. If you choose > > > > > OPTIONAL, note that there are other places in the document which > > > > > refer to key size. And, instead of "other", would "longer" be bet= ter > > guidance? > > > > > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > > > > > ESP with NULL encryption MUST be supported for authentication= . > > > > > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > > > > > Ah, ok. The text immediately prior to this paragraph reads "In > > > > > addition", which makes it appear to be a new requirement as are > > > > > the others. Stating that it is an existing requirement of RFC3723 > > > > > would > > > suffice. > > > > > > > > Ah, it's missing from the RFC3723 list at the start of 2.2 - I'll > > > > add text > > > there to > > > > make that clear. > > > > > > > > > > > > > > Tom. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Black, David [mailto:david.black@emc.com] > > > > > > Sent: Thursday, June 27, 2013 1:41 AM > > > > > > To: Tom Talpey; storm@ietf.org; Paul_Koning@Dell.com > > > > > > Subject: RE: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > > > Tom, > > > > > > > > > > > > Thanks for the thorough review. > > > > > > > > > > > > Most of this is editorial - the one item that is a technical > > > > > > issue is that > > > > > the > > > > > > encryption algorithm requirement changes may not be backwards > > > > > > compatible, as 3DES is no longer appropriate for this use; AES > > > > > > CBC is the > > > > > new > > > > > > mandatory to implement encryption algorithm in this draft. I > > > > > > could leave 3DES as mandatory to implement for backwards > > > > > > compatibility if that helps, but AES CBC really has to be > > > > > > mandatory to implement due to the problems w/3DES at high data > > > > > > rates. If both AES CBC and 3DES are supported, AES CBC SHOULD = be > > used in preference to 3DES. > > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" > > > > > > > is not > > > > > defined. > > > > > > > For example, it's not clear whether NFS or SMB are intended t= o > > > > > > > fall under this scope. And the document later refers to the > > > > > > > various iWARP specifications, which are not limited to > > > > > > > transporting > > > > storage. > > > > > > > Assuming that's not the intent, I suggest defining the term, > > > > > > > or restating it more generically. Technically speaking, this > > > > > > > comment applies > > > > > to > > > > > > the title of the document as well. > > > > > > > > > > > > I took another look at RFC 3723 - it's entitled "Securing Block > > > > > > Storage Protocols over IP" although, as you point out, its IPse= c > > > > > > requirements have been applied to iWARP. I've referred to thes= e > > > > > > requirements as the IP Storage IPsec requirements, in part due > > > > > > to the name of the working group that developed them. The draf= t > > > > > > title might be better restated to reference RFC 3723, and I'll > > > > > > see about changing the text from use of "IP Storage protocols" > > > > > > to talking about protocols that use the RFC 3723 IPsec > > > > > > requirements. The first paragraph of the introduction will nee= d to > be > > expanded to explain this. > > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following > > > > > > > sentence is > > > vague: > > > > > > > > > > > > > > ... IP storage protocols can > > > > > > > be expected to operate at high data rates (multiple > > > Gigabits/second); > > > > > > > the requirements in this document are strongly influenced = by > that > > > > > > > expectation, and hence may not be appropriate for use of I= Psec > > with > > > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > > > > > It's not clear what requirements may not be appropriate, and = why. > > > > > > > Indeed, later discussion makes specific requirements for >1Gb= , > > > > > > > and is silent on lower speed. If the requirements are not > > > > > > > applicable in some cases, the cases should be named. > > > > > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement > > > > > > > "...and hence may not...high data rates". > > > > > > > > > > > > Sure. > > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > > it's not clear what is updated in the many affected documents= . > > > > > > > Are there any required changes, outside of extending their > > > > > > > RFC3723 > > > > references? > > > > > > > > > > > > Section 1.2 says that it "updates the IPsec requirements for > > > > > > each protocol specification that uses RFC 3723" I think that > > > > > > sufficiently defines the > > > > > scope. > > > > > > > > > > > > > And presumably, it is > > > > > > > not the intention to retroactively make these requirements, > > > > > > > therefore any existing RFC3723-compliant security approach > > > > > > > remains > > > > intact? > > > > > > > > > > > > Actually, that is the intention, particularly the 3DES to AES > > > > > > CBC change in mandatory encryption algorithm due to birthday > > > > > > problems with 3DES at high data rates. Older implementations > > > > > > may still claim compliance to RFC 3723 prior to this update, bu= t > > > > > > the intent of this update is to move away from > > > > > 3DES > > > > > > in all cases. > > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > > > unnecessary and should be deleted > > > > > > > > > > > > Ok. > > > > > > > > > > > > > Is there a reference for the 2^69 birthday bound of AES block= s? > > > > > > > Point the discussion there. > > > > > > > > > > > > The birthday bound calculation for AES is in an email message > > > > > > and hence I'll need to reproduce that in an added appendix. > > > > > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 = form: > > > > > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implemen= t > > > > > > > AES > > > > GCM > > > > > > > with 128-bit keys; other key sizes may be supported > > > > > > > > > > > > Ok. > > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > > > whether AES in CBC mode MUST be supported, or whether any use > > > > > > > of AES in CBC mode MUST be implemented with a specific minimu= m > > > > > > > key size. It seems the statement is "AES in CBC mode SHOULD b= e > > > > > > > supported, with keys that MUST be at least 128 bits in length= ." > > > Correct? > > > > > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; > > > > > > > other > > > > key > > > > > > > sizes MAY be supported, and > > > > > > > > > > > > The requirement is basically correct as stated, AES in CBC mode > > > > > > with 128-bit keys MUST be supported. Other key sizes for AES i= n > > > > > > CBC mode are OPTIONAL. > > > > > > I can rephrase in that form if it helps. > > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. > > > > > > > This would appear to introduce an incompatibility with RFC > > > > > > > 3723. Is it a > > > > SHOULD? > > > > > > > > > > > > It's not new - the requirement exists in RFC 3723, as the last > > > > > > sentence in section 2.3.1 on Transforms: > > > > > > > > > > > > ESP with NULL encryption MUST be supported for authentication= . > > > > > > > > > > > > That is the same requirement expressed in a different fashion. > > > > > > > > > > > > Thanks, > > > > > > --David > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Tom Talpey [mailto:ttalpey@microsoft.com] > > > > > > > Sent: Wednesday, June 26, 2013 5:11 PM > > > > > > > To: storm@ietf.org; Black, David; Paul_Koning@Dell.com > > > > > > > Subject: Comments on draft-ietf-storm-ipsec-ips-update > > > > > > > > > > > > > > I have the following comments from a review of the latest dra= ft. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1) In section 1 Introduction, the term "IP Storage protocols" > > > > > > > is not > > > > > defined. > > > > > > > For example, it's not clear whether NFS or SMB are intended t= o > > > > > > > fall under this scope. And the document later refers to the > > > > > > > various iWARP specifications, which are not limited to > > > > > > > transporting > > > > storage. > > > > > > > Assuming that's not the intent, I suggest defining the term, > > > > > > > or restating it more generically. Technically speaking, this > > > > > > > comment applies > > > > > to > > > > > > the title of the document as well. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) In section 1 Introduction, the text in the following > > > > > > > sentence is > > > vague: > > > > > > > > > > > > > > ... IP storage protocols can > > > > > > > be expected to operate at high data rates (multiple > > > Gigabits/second); > > > > > > > the requirements in this document are strongly influenced = by > that > > > > > > > expectation, and hence may not be appropriate for use of I= Psec > > with > > > > > > > other protocols that do not operate at high data rates. > > > > > > > > > > > > > > It's not clear what requirements may not be appropriate, and = why. > > > > > > > Indeed, later discussion makes specific requirements for >1Gb= , > > > > > > > and is silent on lower speed. If the requirements are not > > > > > > > applicable in some cases, the cases should be named. > > > > > > > > > > > > > > Perhaps simply dropping the entire parenthetical statement > > > > > > > "...and hence may not...high data rates". > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3) In section 1.2 Updated RFCs, the word "update" appears but > > > > > > > it's not clear what is updated in the many affected documents= . > > > > > > > Are there any required changes, outside of extending their > > > > > > > RFC3723 references? And presumably, it is not the intention t= o > > > > > > > retroactively make these requirements, therefore any existing > > > > > > > RFC3723-compliant security approach remains intact? Perhaps > > > > > > > the statement would be more accurately "provides updated > > > > > > > reference guidance for IPsec security > > > > > > requirements beyond those of RFC3723." > > > > > > > > > > > > > > The requirements for IPsec usage with IP storage in RFC > > > > > > > 3723 are > > > used > > > > > > > by a number of protocols. For that reason, beyond updatin= g > > > > > > > RFC > > > 3723, > > > > > > > this document also updates the IPsec requirements for each > > protocol > > > > > > > specification that uses RFC 3723, i.e., the following RFCs= in > > > > > > > addition to RFC 3723: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 4) [editorial] In section 2.2 the word "astronomical" is > > > > > > > unnecessary and should be deleted. Is there a reference for > > > > > > > the > > > > > > > 2^69 birthday bound of AES blocks? Point the discussion there= . > > > > > > > > > > > > > > 3GB on a multi-gigabit/sec link. In contrast, AES has a 1= 28 > bit > > > > > > > block size, which results in an astronomical birthdaya bou= nd > (2^69 > > > > > > > bytes). AES CBC is the primary mandatory-to-implement > > > > > > > cryptographic > > > > > > > > > > > > > > The word "may" in the relevant requirement is not in RFC2119 = form: > > > > > > > > > > > > > > o Implementations that support IKEv2 SHOULD also implemen= t > > > > > > > AES > > > > GCM > > > > > > > with 128-bit keys; other key sizes may be supported. > > > > > > > > > > > > > > > > > > > > > > > > > > > > 5) Also in section 2.2, the following requirement is unclear > > > > > > > whether AES in CBC mode MUST be supported, or whether any use > > > > > > > of AES in CBC mode MUST be implemented with a specific minimu= m > > > > > > > key size. It seems the statement is "AES in CBC mode SHOULD b= e > > > > > > > supported, with keys that MUST be at least 128 bits in length= ." > > > Correct? > > > > > > > > > > > > > > o AES in CBC mode MUST be implemented with 128-bit keys; > > > > > > > other > > > > key > > > > > > > sizes MAY be supported, and > > > > > > > > > > > > > > > > > > > > > > > > > > > > 6) Finally, in section 2.2 there is a new MUST requirement. > > > > > > > This would appear to introduce an incompatibility with RFC > > > > > > > 3723. Is it a > > > > SHOULD? > > > > > > > > > > > > > > In addition, NULL encryption [RFC2410] MUST be implemented > > > > > > > to > > > > enable > > > > > > > use of SAs that provide data origin authentication and dat= a > > > > > > > integrity, but not confidentiality. Other transforms MAY = be > > > > > > > implemented in addition to those listed above. > > > > > > > > > > > > > > > > > > > > > > > From internet-drafts@ietf.org Tue Jul 9 16:00:05 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7292D11E819C; Tue, 9 Jul 2013 16:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMaCqGft2-7h; Tue, 9 Jul 2013 16:00:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1111021F9B31; Tue, 9 Jul 2013 16:00:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709230004.8540.68036.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 16:00:04 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iser-15.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 23:00:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Extensions for RDMA Specification Author(s) : Michael Ko Alexander Nezhinsky Filename : draft-ietf-storm-iser-15.txt Pages : 98 Date : 2013-07-09 Abstract: iSCSI Extensions for Remote Direct Memory Access (RDMA) provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA-Capable Protocol. This document obsoletes RFC 5046. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iser There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iser-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iser-15 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed Jul 10 07:06:29 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2385121F9E88; Wed, 10 Jul 2013 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skkcMEKexiJL; Wed, 10 Jul 2013 07:06:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8590721F9DF1; Wed, 10 Jul 2013 07:06:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710140628.17642.70371.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 07:06:28 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-ipsec-ips-update-03.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:06:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Securing Block Storage Protocols over IP: RFC 3723 Requi= rements Update for IPsec v3 Author(s) : David Black Paul Koning Filename : draft-ietf-storm-ipsec-ips-update-03.txt Pages : 16 Date : 2013-07-09 Abstract: RFC 3723 specifies IPsec requirements for block storage protocols over IP (e.g., iSCSI) based on IPsec v2 (RFC 2401 and related RFCs); those requirements have subsequently been applied to remote direct data placement protocols, e.g., RDMAP. This document updates RFC 3723's IPsec requirements to IPsec v3 (RFC 4301 and related RFCs) and makes some changes to required algorithms based on developments in cryptography since RFC 3723 was published. [RFC Editor: The "Updates:" list above has been truncated by xml2rfc. The complete list is - Updates: 3720, 3723, 3821, 3822, 4018, 4172, 4173, 4174, 5040, 5041, 5042, 5043, 5044, 5045, 5046, 5047, 5048 (if approved) ] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-ipsec-ips-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-ipsec-ips-update-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-ipsec-ips-update-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Wed Jul 10 07:46:49 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDE121F9E5E; Wed, 10 Jul 2013 07:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpoaxZplhfJO; Wed, 10 Jul 2013 07:46:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A455321F9F0E; Wed, 10 Jul 2013 07:46:45 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130710144645.31640.11941.idtracker@ietfa.amsl.com> Date: Wed, 10 Jul 2013 07:46:45 -0700 Cc: storm mailing list , storm chair , RFC Editor Subject: [storm] Protocol Action: 'iSCSI Extensions for RDMA Specification' to Proposed Standard (draft-ietf-storm-iser-15.txt) X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 14:46:49 -0000 The IESG has approved the following document: - 'iSCSI Extensions for RDMA Specification' (draft-ietf-storm-iser-15.txt) as Proposed Standard This document is the product of the STORage Maintenance Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-storm-iser/ Technical Summary iSCSI Extensions for RDMA provides the RDMA data transfer capability to iSCSI by layering iSCSI on top of an RDMA-Capable Protocol. An RDMA-Capable Protocol provides RDMA Read and Write services, which enable data to be transferred directly into SCSI I/O Buffers without intermediate data copies. This document describes the extensions to the iSCSI protocol to support RDMA services as provided by an RDMA- Capable Protocol. Working Group Summary This document is a minor update to RFC 5046, primarily to reflect what has actually been done in implementations. WG Last Call turned up several issues around relaxing RFC 5046's requirements based on what implementations have done. These issues involved use of Send message types that have side effects (implementations often do not use these) and the consequences of delayed resource allocation (implementations have run into a race condition that can terminate an iSER connection if measures to avoid it are not taken). All of these issues have been resolved in the current version of this document, although the race condition avoidance is not perfect due to the need to cope with current "running code" in implementations. Document Quality There are multiple implementations of the iSER protocol; the primary purpose of this document is to reflect implementation experience so that the iSER protocol specification matches the "running code". Hemal Shah's review of the document resulted in some important changes in the text describing use of versions of the Send message. Alexander Neshinsky reported the resource allocation problem seen in implmenetations and provided valuable help in working out an approach that encompasses boht the "right thing" to do going forward and necessary measures to cope with current "running code" in implementations. Personnel Document Shepherd: David Black (storm WG co-chair) Responsible Area Director: Martin Stiemerling (Transport) From ttalpey@microsoft.com Wed Jul 10 09:10:49 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9A121F9956 for ; Wed, 10 Jul 2013 09:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0+2uRgzZlfi for ; Wed, 10 Jul 2013 09:10:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB4F21F9B52 for ; Wed, 10 Jul 2013 09:10:42 -0700 (PDT) Received: from BY2FFO11FD010.protection.gbl (10.1.15.200) by BY2FFO11HUB018.protection.gbl (10.1.14.92) with Microsoft SMTP Server (TLS) id 15.0.717.3; Wed, 10 Jul 2013 16:10:35 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Wed, 10 Jul 2013 16:10:35 +0000 Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.149]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0136.001; Wed, 10 Jul 2013 16:10:30 +0000 From: Tom Talpey To: "storm@ietf.org" Thread-Topic: Review comments on draft-ietf-storm-rdmap-ext Thread-Index: Ac5865W+3+PDQi76TQWRLH3sDqnoew== Date: Wed, 10 Jul 2013 16:10:29 +0000 Message-ID: <614F550557B82C44AC27C492ADA391AA148BF8B1@TK5EX14MBXC285.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(199002)(189002)(74662001)(50466002)(81542001)(23726002)(4396001)(47446002)(56816003)(63696002)(50986001)(6806003)(76482001)(76786001)(31966008)(49866001)(47736001)(77982001)(74876001)(44976004)(76796001)(80022001)(81342001)(59766001)(54356001)(79102001)(47976001)(47776003)(53806001)(69226001)(20776003)(33656001)(74366001)(46102001)(65816001)(54316002)(74706001)(56776001)(51856001)(74502001)(16406001)(83072001)(66066001)(46406003)(55846006)(77096001)(76176001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB018; H:TK5EX14HUBC102.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0903DD1D85 Subject: [storm] Review comments on draft-ietf-storm-rdmap-ext X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:10:49 -0000 I've read and reviewed the latest RDMA Extensions draft (draft-ietf-storm-r= dmap-ext-04) and have the following comments. I have two high-level concerns. These extensions to the RDMAP protocol are = made without any versioning or capability detection between peers at the RD= MAP level. There is a statement deep in section 5 that "discovery" of Atomi= cs needs to be performed by the upper layer or application, and no similar = statement is made in section 6 regarding Immediate Data. This seems problematic, for two reasons. First, it imposes an interoperabil= ity burden on upper layers to perform this negotiation. That's perhaps acce= ptable, but more discussion as to this requirement needs to be made, and in= particular some discussion of why it is *not* being performed by the RDMAP= protocol in this extension. Second, there is no discussion of why the chosen set of operations is neces= sary, or sufficient. The Introduction states that (unspecified) application= s are able to use Atomics and Immediate Data on "other" (unspecified) RDMA = transports, but there is no discussion of whether the operations are suffic= ient. And, when comparing the Atomics in this document to, for example, Inf= iniband, there is an additional operation ("Swap") which is not part of the= IB specification. What other operations, or semantics, are possible? Are t= hose left for future work? In short, I would like to see a succinct Problem Statement, and a discussio= n of how the extension is to interoperate with existing implementations. Di= scussion of how the RDMAP protocol may be extended in the future would be g= ood to have, too. Specific issues on sections follow. + Section 1, paragraph 1 > The RDMA Protocol [RFC5040] provides capabilities for zero copy and > kernel bypass data communications. This document specifies the There is much more to RDMAP than zero copy, I think. And the concept of "ke= rnel bypass" is mentioned just once in RFC5040, and in the abstract; it see= ms irrelevant here and should be omitted. Paragraph 3 goes on to say: > Other RDMA transport protocols define the functionality added by > these extensions leading to differences in RDMA applications and/or which makes no specific reference for either the protocols or the applicati= ons. In other words, what is the detailed problem statement that the extens= ions are proposed to solve? It would be preferable to see specific reasons motivating these extensions,= to justify them individually. + Editorial in section 1, is "following" the right word? Since the Immediat= e Data is carried by a new message, it seems more like a tinygram-style mes= sage in itself. > o Immediate Data messages allow the ULP at the sender to provide a > small amount of data following an RDMA Message. + Section 3 "Atomic Operation" > Atomic Operation - is an operation that results in an execution of a > 64-bit operation at a specific address on a remote node. The The "64-bit" qualifier is not necessary for the glossary and can be removed= here. Also, isn't it a specific "registered" address? > consumer can use Atomic Operations to read, modify and write at the > destination address while at the same time guarantee that no other > read or write operation will occur across any other RDMAP Streams on > an RNIC at the Data Sink. Generalize the last sentence to "The consumer can use Atomic Operations to = perform operations on the contents of the destination address with certain = atomicity guarantees." I have other comments on the "across any other RDMAP= Streams" later. Even if you disagree with the prior sentence, the term "Data Sink" should b= e deleted. Atomics source and sink data at the same peer. In fact, the glos= sary goes on to define "Requester" and "Responder" just a few lines later. + Section 4 first paragraph > The control information of RDMA Messages is included in DDP protocol > [RFC5041] defined header fields, with the following new formats: This would appear to propose an extension to RFC5041, as written. This shou= ld be stated, or made more clear. Any requirements made of other protocols = are critical to capture. + Section 4.1, first paragraph > The RDMA Messages defined by this specification use all 8 bits of > the RDMAP Control Field. The first octet reserved for ULP use in the > DDP Protocol MUST be used by the RDMAP to carry the RDMAP Control This statement appears to have been imported from RFC5040, and therefore is= not part of the extension. This should be reworded to make it clear what i= s being extended and changed. + Section 4.1, second paragraph > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |T|L| Resrv | DV| RV|Rsv| Opcode| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Invalidate STag | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1 DDP Control and RDMAP Control Fields There are no differences in these fields from RFC5040. What is being extend= ed in them? (Just the Opcodes, right?) + Section 4.1, table > -------+-----------+------------------------------------------------- > 1011b | Atomic | 0 | N/A | 3 | N/A | Yes > | Response | | | | | > -------+-----------+------------------------------------------------- The newly-defined use of RDMAP queue #3 is quite surprising. What's the pur= pose of the assignment? What semantics are being enforced? The document is = silent on them, and as noted in later comments, possibly inconsistent. + Section 5 third paragraph > Atomic operations as specified in this document execute a 64-bit > operation at a specified destination address on a remote node. The It's much more than "specified", it's a _registered_ address, represented b= y an STag and thereby under the control of the RFC5042 security model. It i= s critical to state this, and make the reference. Also, the address has other possible restrictions, with respect to alignmen= t. The protocol should state whether these are required by the protocol its= elf, or if they are subject to local constraints imposed by the registratio= n. If they are protocol-imposed, then there will be implications for the "o= ffset" fields with regard to byte granularity, and how and where they will = be checked. Either way, discussion here is required. > operations atomically read, modify and write back the contents of Are read, modify and write the only actions possible in an atomic? It's not= clear how the proposed "swap" operations apply here. The R/M/W meaning sho= uld be made clear. > the destination address and guarantee that Atomic Operations on this > address by other RDMAP Streams on the same RNIC do not occur between > the read and the write.=20 This seems to be significantly less of an atomicity guarantee than expected= . Normally, atomics protect all concurrent modifications to the target loca= tion, including those from local access via the CPU at the responder, and o= ther RNICs. Is the scope intentionally narrowed to a single RNIC here? What= ever the guarantee, some statement of RNIC requirements to achieve this is = needed, because the proposed protocol itself does not address it. > document MAY be implemented. The discovery of whether the Atomic > Operations are implemented or not is outside the scope of this > specification and it should be handled by the ULPs or applications. This is the first mention in the document of this requirement, and it needs= quite a bit more discussion on exactly how an upper layer is to proceed. W= hy is the "should" not normative here, and is it a MUST? See earlier commen= t. + Section 5.2 first paragraph > The Atomic Operation Request and Response are RDMA Messages. An > Atomic Operation makes use of the DDP Untagged Buffer Model. Atomic > Operations use the same Queue Number as RDMA Read Requests (QN=3D1). Earlier, atomic *requests* are specified to use QN=3D1, but atomic *respons= es* used QN=3D3. Which is correct? Note, section 5.2.2 bullet #3 also makes= this statement. + Section 5.2.1 Atomic operation values > ---------+-----------+----------+----------+---------+--------- > 0011b | | > to | Reserved | Not Specified > 1111b | | > ---------+-----------+----------------------------------------- ... and > 4. At the Responder, when an invalid Atomic Operation Request > Message is delivered to the Remote Peer's RDMAP layer, an error > is surfaced. Are the "Reserved" fields invalid? + Section 5.2.2 points #5 and #7 > 5. The RDMAP layer MUST Deliver the Atomic Operation Response > Message to the ULP. > 7. The Responder RDMAP layer MUST pass Atomic Operation Response > Messages to the DDP layer, in the order that the Atomic Operation > Request Messages were received by the RDMAP layer, at the > Responder. These steps appear out of order. I suggest switching them, so the sending o= f the response precedes its processing by the receiver. + Section 5.3. Atomicity Guarantees > Atomicity of the Read-Modify-Write (RMW) on the Responder's node by > the Atomic Operation MUST be assured in the presence of concurrent > atomic accesses by other RDMAP Streams on the same RNIC.=20 Similar comment as earlier - are these the only types of concurrent access = guarantees? + Section 5.4 Atomic completion rules > 1. For an Atomic operation, the contents of the Tagged Buffer at the > Responder MAY be indeterminate until the Atomic Operation > Response Message has been Delivered at the Requester. I don't understand this statement. The protocol defines no means for the Re= quester to acknowledge the Delivery of the Atomic Response, so how can this= in any way influence the behavior at the Responder? > 4. Atomic Operation Response Message processing at the Responder > MUST be started only after the Atomic Operation Request Message > has been Delivered by the DDP layer (thus, all previous RDMA > Messages have been properly submitted for ordered Placement). Again, I don't understand. The DDP protocol uses Queue Numbers to enforce t= his ordering, and since the Atomic Request uses QN=3D1, the requirement for= "all previous RDMA Messages" is not sufficiently clear. Is this making a r= equirement that previous RDMA Writes to the Atomic location be Placed (ther= e's no mention of this in section 7)? Or, is the Atomic required to perform= some sort of memory barrier against all other access? + Section 6. Immediate Data > The Immediate Data operation is used in conjunction with an RDMA > Operation to improve ULP processing efficiency by allowing 8 bytes > of immediate data to be delivered with the completion of the > previous operation after the previous operation has been delivered > at the Remote Peer. I definitely do not understand this. The text appears to state that any imm= ediate data is added to some *prior* completion. How can an operation, whic= h has already been delivered, be modified by a later one? + Section 6.3 Immediate data handling > . The Remote Peer MUST check that Immediate Data and Immediate Data > with SE Messages include exactly 8 bytes of data from the DDP > layer. How does the receiver make this test? There is no length field in the Immed= iate Data message, it's a fixed 8-byte buffer. + Section 7 Ordering table >----------+------------+-------------+-------------+------------------- >Atomic | Atomic | No Placement| No Placement| Second Atomic > | | Guarantee | Guarantee | Response > | | between two | between two | Message will > | | Atomic | Atomic | not be > | | Requests | Responses | generated > | | | | until first > | | | | Atomic Response > | | | | has been > | | | | generated >----------+------------+-------------+-------------+------------------- This appears to be incorrect. Earlier, there are specific requirements that= the RMW operation be performed prior to replying to a previous Atomic, and= in fact all Atomic requests are serialized on a single QN (1). I'm not sur= e what application semantic would be satisfied by this rather weak guarante= e as stated. + Section 11.1 [RFC5042] (RDMA security model) is missing. Needed for discussion of Atomic= s steering tag protection. [RFC5226] is not a normative reference. Move to 11.2, if desired, but more = likely, just delete. + Section 11.2 Would like to see references to Infiniband specifications here, as relevant= for Atomics and other behavior. =20 From david.black@emc.com Wed Jul 10 17:46:29 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B8521F9A35 for ; Wed, 10 Jul 2013 17:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0tTiUSMJz2h for ; Wed, 10 Jul 2013 17:46:25 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2246F21F9B1B for ; Wed, 10 Jul 2013 17:46:24 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6B0kMPM003974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 Jul 2013 20:46:22 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Wed, 10 Jul 2013 20:46:04 -0400 Received: from mxhub04.corp.emc.com (mxhub04.corp.emc.com [10.254.141.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6B0k42s027523 for ; Wed, 10 Jul 2013 20:46:04 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Wed, 10 Jul 2013 20:46:03 -0400 From: "Black, David" To: "storm@ietf.org" Date: Wed, 10 Jul 2013 20:46:03 -0400 Thread-Topic: storm WG draft Status - July 10 Thread-Index: Ac53bgoHi8qvQhIoRT6lf3Q0+mOj6QGYO9aA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F3049@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_8D3D17ACE214DC429325B2B98F3AE712983F3049MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] storm WG draft Status - July 10 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 00:46:29 -0000 --_002_8D3D17ACE214DC429325B2B98F3AE712983F3049MX15Acorpemccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There's been some significant progress since last week. 1) iSCSI consolidated draft. Almost done! All of the IESG Evaluation comments have been resolved, and the Discuss positions cleared. A new version is needed to clean up a few things. The announcement of approval for RFC publication will be issued shortly after the new version is posted. 2) iSCSI SAM (new features) draft. In WG Last Call through this evening. primarily to check that the iSCSIProtocolLevel text key, and its associated new registry are specified correctly. The hope is to get the revised version submitted before the July 15 cutoff for the Berlin IETF meeting. This will go to the IESG along with the iSCSI MIB draft. 3) iSCSI MIB draft. The IETF Last Call and MIB Doctor review comments have been resolved in the latest version. It's waiting for the iSCSI SAM draft because the MIB's compliance provisions depend on the value of the iSCSIProtocolLevel text key. 4) iSER draft. Done! The publication approval announcement has appeared issued and the draft is now in the RFC Editor's Queue. Many thanks to Mike Ko (editor) and everyone else who contributed. 5) RFC 3723 IPsec requirements update draft. WG Last Call has completed, the comments have been resolved in the -03 version, which has been submitte= d to our AD for his review and IETF Last Call. The PROTO writeup is attached= . 6) That leaves the RDMA Extensions draft. There have now been multiple reviews of this draft, including by yours truly. Some of the review issues require WG discussion on the list. The authors expect to submit a revised version of the draft after the "window" for draft submission reopens on=20 July 28th, and I strongly encourage them to start discussion of whatever needs attention from the reviews on this list as soon as they are ready. Please feel free to send questions to the list or directly to me. Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- --_002_8D3D17ACE214DC429325B2B98F3AE712983F3049MX15Acorpemccom_ Content-Type: text/plain; name="IPS IPsec Update Writeup.txt" Content-Description: IPS IPsec Update Writeup.txt Content-Disposition: attachment; filename="IPS IPsec Update Writeup.txt"; size=8757; creation-date="Wed, 10 Jul 2013 23:44:18 GMT"; modification-date="Thu, 11 Jul 2013 00:19:45 GMT" Content-Transfer-Encoding: base64 DQpQUk9UTyB3cml0ZXVwOg0KDQogU2VjdXJpbmcgQmxvY2sgU3RvcmFnZSBQcm90b2NvbHMgb3Zl ciBJUDogUkZDIDM3MjMgUmVxdWlyZW1lbnRzIFVwZGF0ZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgZm9yIElQc2VjIHYzDQogICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLXN0b3Jt LWlwc2VjLWlwcy11cGRhdGUtMDMNCg0KUFJPVE8gc2hlcGhlcmQ6IERhdmlkIEwuIEJsYWNrIChT VE9STSBXRyBDby1DaGFpcikNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQooMSkgV2hhdCB0eXBlIG9mIFJG QyBpcyBiZWluZyByZXF1ZXN0ZWQgKEJDUCwgUHJvcG9zZWQgU3RhbmRhcmQsDQpJbnRlcm5ldCBT dGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBvciBIaXN0b3JpYyk/ICBXaHkN CmlzIHRoaXMgdGhlIHByb3BlciB0eXBlIG9mIFJGQz8gIElzIHRoaXMgdHlwZSBvZiBSRkMgaW5k aWNhdGVkIGluIHRoZQ0KdGl0bGUgcGFnZSBoZWFkZXI/DQoNCiAgIFByb3Bvc2VkIFN0YW5kYXJk IFJGQyBpcyByZXF1ZXN0ZWQgYmVjYXVzZSB0aGlzIGRvY3VtZW50IHVwZGF0ZXMNCiAgIFJGQyAz NzIzLCBhIFByb3Bvc2VkIFN0YW5kYXJkIFJGQyBhcyB3ZWxsIGFzIG11bHRpcGxlIGFkZGl0aW9u YWwNCiAgIFByb3Bvc2VkIFN0YW5kYXJkIFJGQ3MuICBTdGFuZGFyZHMgVHJhY2sgaXMgaW5kaWNh dGVkIGFzIHRoZQ0KICAgaW50ZW5kZWQgc3RhdHVzIGluIHRoZSB0aXRsZSBwYWdlIGhlYWRlci4N Cg0KKDIpIFRoZSBJRVNHIGFwcHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50 IEFubm91bmNlbWVudA0KV3JpdGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBB bm5vdW5jZW1lbnQgV3JpdGUtVXAuIFJlY2VudA0KZXhhbXBsZXMgY2FuIGJlIGZvdW5kIGluIHRo ZSAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZA0KZG9jdW1lbnRzLiBUaGUgYXBw cm92YWwgYW5ub3VuY2VtZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6DQoNClRl Y2huaWNhbCBTdW1tYXJ5DQoNCiAgIFJGQyAzNzIzIHNwZWNpZmllcyBJUHNlYyByZXF1aXJlbWVu dHMgZm9yIGJsb2NrIHN0b3JhZ2UgcHJvdG9jb2xzDQogICBvdmVyIElQIChlLmcuLCBpU0NTSSkg YmFzZWQgb24gSVBzZWMgdjIgKFJGQyAyNDAxIGFuZCByZWxhdGVkIFJGQ3MpOw0KICAgdGhvc2Ug cmVxdWlyZW1lbnRzIGhhdmUgc3Vic2VxdWVudGx5IGJlZW4gYXBwbGllZCB0byByZW1vdGUgZGly ZWN0DQogICBkYXRhIHBsYWNlbWVudCBwcm90b2NvbHMsIGUuZy4sIFJETUFQLiAgVGhpcyBkb2N1 bWVudCB1cGRhdGVzIFJGQw0KICAgMzcyMydzIElQc2VjIHJlcXVpcmVtZW50cyB0byBJUHNlYyB2 MyAoUkZDIDQzMDEgYW5kIHJlbGF0ZWQgUkZDcykgYW5kDQogICBtYWtlcyBzb21lIGNoYW5nZXMg dG8gcmVxdWlyZWQgYWxnb3JpdGhtcyBiYXNlZCBvbiBkZXZlbG9wbWVudHMgaW4NCiAgIGNyeXB0 b2dyYXBoeSBzaW5jZSBSRkMgMzcyMyB3YXMgcHVibGlzaGVkLg0KDQpXb3JraW5nIEdyb3VwIFN1 bW1hcnkNCg0KICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBJUHNlYyByZXF1aXJlbWVudHMg aW4gUkZDIDM3MjMgYW5kIGFsbCBSRkNzDQogICB0byB3aGljaCB0aG9zZSByZXF1aXJlbWVudHMg YXBwbHkuICBUaGUgaVNDU0kgbWFpbnRlbmFuY2Ugd29yayBpbg0KICAgdGhlIHN0b3JtIFdHIGhh ZCBvcmlnaW5hbGx5IGludGVuZGVkIHRvIG9ubHkgdXBkYXRlIHRoZSBJUHNlYw0KICAgcmVxdWly ZW1lbnRzIGZvciBpU0NTSS4gIFR3byBkZXZlbG9wbWVudHMgY2hhbmdlZCB0aGlzIGFwcHJvYWNo Og0KDQogICBvIENyeXB0b2dyYXBoaWMgZGV2ZWxvcG1lbnRzIHVwZW5kZWQgUkZDIDM3MjMncyBy ZXF1aXJlbWVudCBmb3IgM0RFUw0KICAgICBhcyB0aGUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBl bmNyeXB0aW9uIHRyYW5zZm9ybS4gIFRoZSBwcm90b2NvbHMNCiAgICAgdG8gd2hpY2ggUkZDIDM3 MjMgYXBwbGllcyBjYW4gYXBwcm9hY2ggM0RFUydzIGJpcnRoZGF5IGJvdW5kIGFuZA0KICAgICBu ZWVkIHRvIHJla2V5IGluIGxlc3MgdGhhbiBhIG1pbnV0ZSBvbiBoaWdoLXNwZWVkIGxpbmtzLg0K DQogICBvIGlTRVIgKGlTQ1NJIGV4dGVuc2lvbnMgZm9yIFJETUEpIHVzZXMgUkZDIDM3MjMgSVBz ZWMgcmVxdWlyZW1lbnRzDQogICAgIHR3aWNlLCBvbmNlIGZvciBpU0NTSSBhbmQgb25jZSBmb3Ig dGhlIHVuZGVybHlpbmcgcmRkcCAoaVdBUlApDQogICAgIFJETUEgcHJvdG9jb2wuICBBbiBSRkMg MzcyMyB1cGRhdGUgaXMgbmVlZGVkIGZvciB0aGUgbGF0dGVyIGluDQogICAgIG9yZGVyIHRvIGF2 b2lkIGluY29uc2lzdGVudCBJUHNlYyByZXF1aXJlbWVudHMgaW4gdGhlIHNhbWUgcHJvdG9jb2wN CiAgICAgc3RhY2suDQoNCiAgIERhdmlkIE1jR3JldyBhbmQgU3RldmUgS2VudCAocmVzcGVjdGl2 ZWx5KSBkZXNlcnZlIGNyZWRpdCBmb3Igc3VyZmFjaW5nDQogICB0aGUgYWJvdmUgdHdvIGNvbmNl cm5zIHRoYXQgbGVhZCB0byBjcmVhdGlvbiBvZiB0aGlzIGRvY3VtZW50LiAgVGhpcw0KICAgZG9j dW1lbnQgaGFzIG5vdCBiZWVuIGNvbnRyb3ZlcnNpYWwgaW4gdGhlIHN0b3JtIFdHLg0KDQpEb2N1 bWVudCBRdWFsaXR5DQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgcHJvZmlsZSBvZiB3 aWRlbHkgaW1wbGVtZW50ZWQgcHJvdG9jb2xzLA0KICAgSVBzZWMgdjIgYW5kIHYzLiAgVGhlIHNw ZWNpZmllZCBjcnlwdG9ncmFwaGljIHRyYW5zZm9ybXMgaGF2ZSBiZWVuDQogICBzZWxlY3RlZCBh cyBvbmVzIHRoYXQgYXJlIGNvbW1vbmx5IGF2YWlsYWJsZSBpbiBJUHNlYyBpbXBsZW1lbnRhdGlv bnMuDQoNCiAgIFNlYW4gVHVybmVyIChTRUMgQUQpIGFuZCBQYXVsIEhvZmZtYW4gKGlwc2VjbWUg V0cgY2hhaXIpIHdlcmUgYm90aA0KICAgbm90YWJseSBoZWxwZnVsIGluIHByb3ZpZGluZyBhZHZp Y2Ugb24gdHJhbnNmb3JtIHNlbGVjdGlvbi4gIFlhcm9uDQogICBTaGVmZmVyIChpcHNlY21lIFdH IGNoYWlyKSBwcm92aWRlZCBhIHRob3JvdWdoIHJldmlldyB0aGF0IHNpZ25pZmljYW50bHkNCiAg IGltcHJvdmVkIHRoZSBxdWFsaXR5IG9mIHRoaXMgZG9jdW1lbnQuICBUb20gVGFscGV5IChzdG9y bSBXRyBjaGFpcikNCiAgIHByb3ZpZGVkIGEgdGhvcm91Z2ggV0cgTGFzdCBDYWxsIHJldmlldy4N Cg0KICAgVGhlIGRvY3VtZW50IHNoZXBoZXJkIGlzIHZlcnkgcGxlYXNlZCB3aXRoIHRoZSBoZWxw IHJlY2VpdmVkIGZyb20NCiAgIGJvdGggaXBzZWNtZSBXRyBjby1jaGFpcnMgYW5kIHRoZSBBRCBy ZXNwb25zaWJsZSBmb3IgdGhlIGlwc2VjbWUgV0cuDQoNClBlcnNvbm5lbA0KDQogICBEb2N1bWVu dCBTaGVwaGVyZDogRGF2aWQgQmxhY2sgKHN0b3JtIFdHIGNvLWNoYWlyKQ0KICAgUmVzcG9uc2li bGUgQXJlYSBEaXJlY3RvcjogTWFydGluIFN0aWVtZXJsaW5nIChUcmFuc3BvcnQpDQoNCigzKSBC cmllZmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhpcyBkb2N1bWVudCB0aGF0IHdhcyBwZXJm b3JtZWQgYnkNCnRoZSBEb2N1bWVudCBTaGVwaGVyZC4gIElmIHRoaXMgdmVyc2lvbiBvZiB0aGUg ZG9jdW1lbnQgaXMgbm90IHJlYWR5DQpmb3IgcHVibGljYXRpb24sIHBsZWFzZSBleHBsYWluIHdo eSB0aGUgZG9jdW1lbnQgaXMgYmVpbmcgZm9yd2FyZGVkIHRvDQp0aGUgSUVTRy4NCg0KICBUaGUg RG9jdW1lbnQgU2hlcGhlcmQgaXMgdGhlIHByaW1hcnkgZWRpdG9yIG9mIHRoaXMgZG9jdW1lbnQs IGFuZA0KICBoYXMgcmV2aWV3ZWQgaXRzIHRleHQgaW4gZGV0YWlsLCBtb3N0IHJlY2VudGx5IGlu IGRlYWxpbmcgd2l0aCBXRw0KICBMYXN0IENhbGwgY29tbWVudHMuICBUaGUgRG9jdW1lbnQgU2hl cGhlcmQgYmVsaWV2ZXMgdGhhdCB0aGlzDQogIGRvY3VtZW50IGlzIHJlYWR5IGZvciBSRkMgcHVi bGljYXRpb24uDQoNCig0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBjb25j ZXJucyBhYm91dCB0aGUgZGVwdGggb3INCmJyZWFkdGggb2YgdGhlIHJldmlld3MgdGhhdCBoYXZl IGJlZW4gcGVyZm9ybWVkPyAgDQoNCiAgIE5vLg0KDQooNSkgRG8gcG9ydGlvbnMgb2YgdGhlIGRv Y3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9yIGZyb20NCmJyb2FkZXIgcGVy c3BlY3RpdmUsIGUuZy4sIHNlY3VyaXR5LCBvcGVyYXRpb25hbCBjb21wbGV4aXR5LCBBQUEsIERO UywNCkRIQ1AsIFhNTCwgb3IgaW50ZXJuYXRpb25hbGl6YXRpb24/IA0KDQogICBOby4gDQoNCig2 KSBEZXNjcmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3Vt ZW50IFNoZXBoZXJkDQpoYXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxl IEFyZWEgRGlyZWN0b3IgYW5kL29yIHRoZQ0KSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBl eGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlDQp3aXRoIGNlcnRhaW4g cGFydHMgb2YgdGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFs bHkNCmlzIGEgbmVlZCBmb3IgaXQuIEluIGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNz ZWQgdGhvc2UgaXNzdWVzIGFuZA0KaGFzIGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0 byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlDQpjb25jZXJucyBoZXJlLg0KDQog ICBOb25lLg0KDQooNykgSGFzIGVhY2ggYXV0aG9yIGNvbmZpcm1lZCB0aGF0IGFueSBhbmQgYWxs IGFwcHJvcHJpYXRlIElQUg0KZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFu Y2Ugd2l0aCB0aGUgcHJvdmlzaW9ucyBvZiBCQ1AgNzgNCmFuZCBCQ1AgNzkgaGF2ZSBhbHJlYWR5 IGJlZW4gZmlsZWQuIElmIG5vdCwgZXhwbGFpbiB3aHkuDQoNCiAgIFllcy4NCg0KKDgpIEhhcyBh biBJUFIgZGlzY2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50 Pw0KDQogICBOby4NCg0KKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0 aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KcmVwcmVzZW50IHRoZSBzdHJvbmcgY29uY3VycmVuY2Ug b2YgYSBmZXcgaW5kaXZpZHVhbHMsIHdpdGggb3RoZXJzDQpiZWluZyBzaWxlbnQsIG9yIGRvZXMg dGhlIFdHIGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQgYWdyZWUgd2l0aCBpdD8gICANCg0KICAg VGhlIHN0b3JtIChTVE9SYWdlIE1haW50ZW5hbmNlKSBXRyBpcyBhIG1haW50ZW5hbmNlIFdHIHRo YXQgd29ya3Mgb24NCiAgIGEgbnVtYmVyIG9mIHN0b3JhZ2UgdGVjaG5vbG9naWVzLCBhbmQgaGVu Y2Ugbm90IGV2ZXJ5IHBhcnRpY2lwYW50IGlzDQogICBpbnRlcmVzdGVkIGluIGV2ZXJ5IHRlY2hu b2xvZ3kuICBUaGUgbWVtYmVycyBvZiB0aGUgV0cgd2hvIGFyZQ0KICAgaW50ZXJlc3RlZCBpbiB0 aGUgYXBwbGljYXRpb24gb2YgSVBzZWMgdG8gdGhlIFdHJ3MgcHJvdG9jb2xzDQogICB1bmRlcnN0 YW5kIGFuZCBhZ3JlZSB3aXRoIHRoaXMgZG9jdW1lbnQuDQoNCigxMCkgSGFzIGFueW9uZSB0aHJl YXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJlbWUgDQpkaXNjb250 ZW50Pw0KDQogICBOby4NCg0KKDExKSBJZGVudGlmeSBhbnkgSUQgbml0cyB0aGUgRG9jdW1lbnQg U2hlcGhlcmQgaGFzIGZvdW5kIGluIHRoaXMNCmRvY3VtZW50LiAoU2VlIGh0dHA6Ly93d3cuaWV0 Zi5vcmcvdG9vbHMvaWRuaXRzLyBhbmQgdGhlIEludGVybmV0LURyYWZ0cw0KQ2hlY2tsaXN0KS4g Qm9pbGVycGxhdGUgY2hlY2tzIGFyZSBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJl DQp0aG9yb3VnaC4NCg0KICAgaWRuaXRzIDIuMTIuMTcgZmluZHMgYSBudW1iZXIgb2YgdGhpbmdz IHRvIGNvbXBsYWluIGFib3V0LCBub25lIG9mDQogICB3aGljaCBhcmUgYWN0dWFsIHByb2JsZW1z Og0KDQogICAtIFRoZSBJUHNlYyB2MiBSRkNzIGFyZSBuZWNlc3Nhcnkgbm9ybWF0aXZlIHJlZmVy ZW5jZXMsIGV2ZW4gdGhvdWdoDQoJdGhleSBoYXZlIG9ic29sZXRlIHN0YXR1cy4NCiAgIC0gVGhl cmUgaXMgbm8gcG9pbnQgaW4gcmVwZWF0aW5nIHRoZSBsb25nIGxpc3Qgb2YgdXBkYXRlZCBSRkNz DQogICAgICBpbiB0aGUgYWJzdHJhY3QuDQogICAtIGlkbml0cyB3YXJucyBhYm91dCBwb3NzaWJs ZSBjb250ZW50IGZyb20gYmVmb3JlIDEwIE5vdmVtYmVyIDIwMDg7DQogICAgICB0aGVyZSBpcyBu byBzdWNoIGNvbnRlbnQuDQoNCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBh bnkgcmVxdWlyZWQgZm9ybWFsIHJldmlldw0KY3JpdGVyaWEsIHN1Y2ggYXMgdGhlIE1JQiBEb2N0 b3IsIG1lZGlhIHR5cGUsIGFuZCBVUkkgdHlwZSByZXZpZXdzLg0KDQogICBOb3QgYXBwbGljYWJs ZS4NCg0KKDEzKSBIYXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4g aWRlbnRpZmllZCBhcw0KZWl0aGVyIG5vcm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8NCg0KICAgWWVz Lg0KDQooMTQpIEFyZSB0aGVyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhh dCBhcmUgbm90IHJlYWR5IGZvcg0KYWR2YW5jZW1lbnQgb3IgYXJlIG90aGVyd2lzZSBpbiBhbiB1 bmNsZWFyIHN0YXRlPw0KDQogICBOby4gIFRoZXJlIGFyZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0 byB0d28gSW50ZXJuZXQtRHJhZnRzLiAgT25lIG9mDQogICB0aGVtIChpU0VSKSBpcyBhbGVhZHkg aW4gdGhlIFJGQyBFZGl0b3IncyBRdWV1ZSBhbmQgdGhlIG90aGVyIChpU0NTSQ0KICAgQ29uc29s aWRhdGVkKSBpcyBleHBlY3RlZCB0byBqb2luIGl0IHRoZXJlIHNob3J0bHkuDQoNCigxNSkgQXJl IHRoZXJlIGRvd253YXJkIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHJlZmVyZW5jZXMgKHNlZSBSRkMg Mzk2Nyk/DQoNCiAgIE5vLg0KDQooMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVu dCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkNCmV4aXN0aW5nIFJGQ3M/IEFyZSB0aG9zZSBSRkNz IGxpc3RlZCBvbiB0aGUgdGl0bGUgcGFnZSBoZWFkZXIsIGxpc3RlZA0KaW4gdGhlIGFic3RyYWN0 LCBhbmQgZGlzY3Vzc2VkIGluIHRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3QN Cmxpc3RlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlvbiwgZXhwbGFpbiB3aHksIGFu ZCBwb2ludCB0byB0aGUNCnBhcnQgb2YgdGhlIGRvY3VtZW50IHdoZXJlIHRoZSByZWxhdGlvbnNo aXAgb2YgdGhpcyBkb2N1bWVudCB0byB0aGUNCm90aGVyIFJGQ3MgaXMgZGlzY3Vzc2VkLiBJZiB0 aGlzIGluZm9ybWF0aW9uIGlzIG5vdCBpbiB0aGUgZG9jdW1lbnQsDQpleHBsYWluIHdoeSB0aGUg V0cgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5Lg0KDQogICBUaGlzIGRvY3VtZW50IGRvZXMgbm90 IGNoYW5nZSB0aGUgc3RhdHVzIG9mIGFueSBSRkNzLiAgVGhlIHVwZGF0ZWQNCiAgIFJGQ3MgYXJl IGRpc2N1c3NlZCBpbiB0aGUgZG9jdW1lbnQuDQoNCigxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50 IFNoZXBoZXJkJ3MgcmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zDQpzZWN0aW9uLCBl c3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9m IHRoZQ0KZG9jdW1lbnQuIENvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0 IHRoZSBkb2N1bWVudCBtYWtlcw0KYXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUg cmVzZXJ2YXRpb25zIGluIElBTkEgcmVnaXN0cmllcy4NCkNvbmZpcm0gdGhhdCBhbnkgcmVmZXJl bmNlZCBJQU5BIHJlZ2lzdHJpZXMgaGF2ZSBiZWVuIGNsZWFybHkgaWRlbnRpZmllZC4gDQpDb25m aXJtIHRoYXQgbmV3bHkgY3JlYXRlZCBJQU5BIHJlZ2lzdHJpZXMgaW5jbHVkZSBhDQpkZXRhaWxl ZCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRzIGZvciB0aGUgcmVnaXN0cnks IHRoYXQNCmFsbG9jYXRpb25zIHByb2NlZHVyZXMgZm9yIGZ1dHVyZSByZWdpc3RyYXRpb25zIGFy ZSBkZWZpbmVkLCBhbmQgYQ0KcmVhc29uYWJsZSBuYW1lIGZvciB0aGUgbmV3IHJlZ2lzdHJ5IGhh cyBiZWVuIHN1Z2dlc3RlZCAoc2VlIFJGQyA1MjI2KS4NCg0KICAgTm90IGFwcGxpY2FibGU7IHRo aXMgZG9jdW1lbnQgaGFzIG5vIElBTkEgY29uc2lkZXJhdGlvbnMuDQoNCigxOCkgTGlzdCBhbnkg bmV3IElBTkEgcmVnaXN0cmllcyB0aGF0IHJlcXVpcmUgRXhwZXJ0IFJldmlldyBmb3IgZnV0dXJl DQphbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQgdGhlIElFU0cg d291bGQgZmluZA0KdXNlZnVsIGluIHNlbGVjdGluZyB0aGUgSUFOQSBFeHBlcnRzIGZvciB0aGVz ZSBuZXcgcmVnaXN0cmllcy4NCg0KICAgTm90IGFwcGxpY2FibGUuDQoNCigxOSkgRGVzY3JpYmUg cmV2aWV3cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJmb3JtZWQgYnkgdGhlIERvY3VtZW50DQpT aGVwaGVyZCB0byB2YWxpZGF0ZSBzZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBh IGZvcm1hbA0KbGFuZ3VhZ2UsIHN1Y2ggYXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmlu aXRpb25zLCBldGMuDQoNCiAgIE5vdCBhcHBsaWNhYmxlLg0K --_002_8D3D17ACE214DC429325B2B98F3AE712983F3049MX15Acorpemccom_-- From david.black@emc.com Thu Jul 11 16:36:26 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1ED521F9C20 for ; Thu, 11 Jul 2013 16:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNW8zYwQqWCq for ; Thu, 11 Jul 2013 16:36:22 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7DAD121F9B5F for ; Thu, 11 Jul 2013 16:36:22 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6BNaL7m026459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jul 2013 19:36:21 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Thu, 11 Jul 2013 19:36:08 -0400 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6BNa678018834 for ; Thu, 11 Jul 2013 19:36:07 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Thu, 11 Jul 2013 19:36:06 -0400 From: "Black, David" To: "storm@ietf.org" Importance: high X-Priority: 1 Date: Thu, 11 Jul 2013 19:36:05 -0400 Thread-Topic: Working Group Last Call - Internet Small Computer Systems Interface (iSCSI) SCSI Features Update Thread-Index: Ac5ygj3sWxaWDkFoRoC9kV90iexXtwMCDVDw Message-ID: <8D3D17ACE214DC429325B2B98F3AE712983F322F@MX15A.corp.emc.com> References: <8D3D17ACE214DC429325B2B98F3AE71298332AE9@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE71298332AE9@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [storm] Working Group Last Call - Internet Small Computer Systems Interface (iSCSI) SCSI Features Update X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 23:36:26 -0000 This Working Group Last Call on the iscsi-sam draft has concluded. The only comments that I saw were mine: http://www.ietf.org/mail-archive/web/storm/current/msg00744.html A new version of this draft should be prepared that reflects those comments and submitted quickly - the iSCSI MIB draft is being held back from IESG evaluation until there is a version of the iscsi-sam draft that has the correct IANA considerations for the values of the iSCSIProtocolLevel key. Keep in mind that the Berlin cutoff for Internet Draft submissions is 2400 GMT (Zulu time) on next Monday, July 15. Thanks, --David (storm WG co-chair) > -----Original Message----- > From: Black, David > Sent: Wednesday, June 26, 2013 11:32 AM > To: storm@ietf.org > Cc: Black, David > Subject: Working Group Last Call - Internet Small Computer Systems Interf= ace > (iSCSI) SCSI Features Update > Importance: High >=20 > This message is to announce the STORM working group Last Call on the foll= owing > document: >=20 > Internet Small Computer Systems Interface (iSCSI) SCSI Features Update > draft-ietf-storm-iscsi-sam-07.txt >=20 > https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ >=20 > This document defines enhancements to the iSCSI protocol to support certa= in > additional features of the SCSI > protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is = a > companion document to [draft-ietf-storm-iscsi-cons-xx]. >=20 > Last Call comments are due by Wednesday, July 10 at midnight Eastern time= (two > weeks from today). With luck, that'll leave just enough time to get a re= vised > version of the draft submitted before the July 15th cutoff for the Berlin > meetings. >=20 > Please send all technical comments to the storm mailing list: storm@ietf.= org . > Editorial comments may be sent directly to the draft authors: draft-ietf- > storm-iscsi-sam@tools.ietf.org . >=20 > The primary purpose of this second WG Last Call is to review the specific= ation > of the iSCSIProtocolLevel key and related behavior. I can already see th= at > some changes will be needed, as the new IANA registry for the values of t= hat > key has to be expanded to include a description string, so that we can pu= t the > magic words "no version claimed" into that new registry for the value. T= his > is necessary in order to use the values of that key in constructing versi= on > descriptor values for iSCSI in SCSI standard inquiry data (see subclause = 6.6.2 > of the current working draft revision of SPC-4). >=20 > The diff of the current -07 version of this draft against the -06 version= is > not easy to work with. If I can find the time next week, I'll try to pos= t a > diff against a reformatted -06 version that removes a lot of differences > caused by text movement. >=20 > -- David Black > STORM WG co-chair > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 > +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From internet-drafts@ietf.org Mon Jul 15 08:17:25 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3921E80A8; Mon, 15 Jul 2013 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFpk-+mtstxR; Mon, 15 Jul 2013 08:17:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A99AB21F9F5D; Mon, 15 Jul 2013 08:17:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715151724.23286.25042.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 08:17:24 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-cons-10.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 15:17:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : iSCSI Protocol (Consolidated) Author(s) : Mallikarjun Chadalapaka Julian Satran Kalman Meth David Black Filename : draft-ietf-storm-iscsi-cons-10.txt Pages : 344 Date : 2013-07-13 Abstract: This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-cons-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-cons-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Sun Jul 28 08:00:29 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56B921F9DAF; Sun, 28 Jul 2013 08:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1udVgik08Kb; Sun, 28 Jul 2013 08:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D7921F9DCB; Sun, 28 Jul 2013 08:00:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130728150027.22850.26679.idtracker@ietfa.amsl.com> Date: Sun, 28 Jul 2013 08:00:27 -0700 Cc: storm mailing list , storm chair , RFC Editor Subject: [storm] Protocol Action: 'iSCSI Protocol (Consolidated)' to Proposed Standard (draft-ietf-storm-iscsi-cons-10.txt) X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 15:00:30 -0000 The IESG has approved the following document: - 'iSCSI Protocol (Consolidated)' (draft-ietf-storm-iscsi-cons-10.txt) as Proposed Standard This document is the product of the STORage Maintenance Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ Technical Summary This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics. Working Group Summary There was very little dissent in the WG over the functionality in this document. Significant WG discussion was devoted to correctly specifying SCSI-related identifiers used by this draft. Rob Elliott and Ralph Weber (key members of the T10 SCSI standards organization) provided significant assistance in working through the identifier issues. Document Quality iSCSI implementers from Dell, EMC, Microsoft, NetApp, RedHat and VMware have reviewed this document for quality and consistency with existing implementations. The reviews indicate that the changes are clearly specified, and are not expected to be significantly disruptive to add to existing implementations. Personnel David L. Black (david.black@emc.com) is the Document Shepherd Martin Stiemerling (martin.stiemerling@neclab.eu) is the responsible AD. From david.black@emc.com Mon Jul 29 10:12:33 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9714911E8102 for ; Mon, 29 Jul 2013 10:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rX6+zMSTBQAv for ; Mon, 29 Jul 2013 10:12:26 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8DF11E80FF for ; Mon, 29 Jul 2013 10:06:31 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6TH6T5K012840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 29 Jul 2013 13:06:29 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Mon, 29 Jul 2013 13:06:21 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6TH6Ltw022583 for ; Mon, 29 Jul 2013 13:06:21 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Mon, 29 Jul 2013 13:06:21 -0400 From: "Black, David" To: "storm@ietf.org" Date: Mon, 29 Jul 2013 13:06:20 -0400 Thread-Topic: Protocol Action: 'iSCSI Protocol (Consolidated)' to Proposed Standard (draft-ietf-storm-iscsi-cons-10.txt) Thread-Index: Ac6Loz+/N9Ozk3RhRo+haBlCpr/4iwA2onZw Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129857DE13@MX15A.corp.emc.com> References: <20130728150027.22850.26679.idtracker@ietfa.amsl.com> In-Reply-To: <20130728150027.22850.26679.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] FW: Protocol Action: 'iSCSI Protocol (Consolidated)' to Proposed Standard (draft-ietf-storm-iscsi-cons-10.txt) X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:12:34 -0000 This is a major accomplishment - the Consolidated iSCSI draft has now been = approved and will shortly be in the RFC Editor's queue. It's taken a lot of time an= d effort to get here, and I want to thank everyone who's contributed to pulling it o= ff! Thanks, --David -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org]=20 Sent: Sunday, July 28, 2013 11:00 AM To: IETF-Announce Cc: RFC Editor; storm mailing list; storm chair Subject: Protocol Action: 'iSCSI Protocol (Consolidated)' to Proposed Stand= ard (draft-ietf-storm-iscsi-cons-10.txt) The IESG has approved the following document: - 'iSCSI Protocol (Consolidated)' (draft-ietf-storm-iscsi-cons-10.txt) as Proposed Standard This document is the product of the STORage Maintenance Working Group. The IESG contact persons are Martin Stiemerling and Spencer Dawkins. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ Technical Summary This document describes a transport protocol for SCSI that works on top of TCP. The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM-2). RFC 3720 defined the original iSCSI protocol. RFC 3721 discusses iSCSI Naming examples and discovery techniques. Subsequently, RFC 3980 added an additional naming format to iSCSI protocol. RFC 4850 followed up by adding a new public extension key to iSCSI. RFC 5048 offered a number of clarifications and a few improvements and corrections to the original iSCSI protocol. This document obsoletes RFCs 3720, 3980, 4850 and 5048 by consolidating them into a single document and making additional updates to the consolidated specification. This document also updates RFC 3721 and RFC 3723. The text in this document thus supersedes the text in all the noted RFCs wherever there is a difference in semantics.=20 Working Group Summary There was very little dissent in the WG over the functionality in this document. Significant WG discussion was devoted to correctly specifying SCSI-related identifiers used by this draft. Rob Elliott and Ralph Weber (key members of the T10 SCSI standards organization) provided significant assistance in working through the identifier issues.=20 Document Quality iSCSI implementers from Dell, EMC, Microsoft, NetApp, RedHat and VMware have reviewed this document for quality and consistency with existing implementations. The reviews indicate that the changes are clearly specified, and are not expected to be significantly disruptive to add to existing implementations.=20 Personnel David L. Black (david.black@emc.com) is the Document Shepherd=20 Martin Stiemerling (martin.stiemerling@neclab.eu) is the responsible AD.=20 From ietf-secretariat-reply@ietf.org Mon Jul 29 13:54:45 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9631121F9946 for ; Mon, 29 Jul 2013 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMywfOmM5H81 for ; Mon, 29 Jul 2013 13:54:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B6521F96A7 for ; Mon, 29 Jul 2013 13:54:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: storm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729205445.16911.95151.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 13:54:45 -0700 From: IETF Secretariat X-Mailman-Approved-At: Tue, 30 Jul 2013 08:20:44 -0700 Subject: [storm] Milestones changed for storm WG X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 20:54:45 -0000 Changed milestone "First version of iSER update draft", set due date to December 2009 from December 2009. Changed milestone "Working Group Last Call on FCIP protocol number and iFCP address change draft", set due date to January 2010 from January 2010. Changed milestone "Functionally complete iSCSI SAM-4 (and other) new features draft", set due date to January 2011 from January 2011. Changed milestone "Working Group Last Call on combined iSCSI draft (3720bis) plus iSCSI SAM-4 (and other) new features draft", set due date to July 2011 from July 2011. Changed milestone "First version of iSCSI MIB update draft", set due date to July 2011 from July 2011. Changed milestone "Working Group Last Call on RDDP registries draft", set due date to November 2011 from November 2011. Changed milestone "Submit RDDP registries draft to IESG for consideration as a Standards Track document", set due date to November 2011 from November 2011. Changed milestone "Submit combined iSCSI draft and iSCSI new features draft to IESG for consideration as Standards Track documents", set due date to December 2011 from December 2011. Changed milestone "Submit iSCSI MIB draft to IESG for consideration as a Standards Track document", set due date to February 2012 from February 2012. Changed milestone "Submit iSER draft to IESG for consideration as a Standards Track document", set due date to May 2012 from May 2012. Changed milestone "Working Group Last Call on RDMA Protocol Extensions draft", set due date to June 2012 from June 2012, resolved as "Done". URL: http://datatracker.ietf.org/wg/storm/charter/ From internet-drafts@ietf.org Tue Jul 30 09:19:06 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BE3121F9EB0; Tue, 30 Jul 2013 09:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5l5FJh1gu1A; Tue, 30 Jul 2013 09:19:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B7E21F95BD; Tue, 30 Jul 2013 09:19:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730161905.26902.2741.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 09:19:05 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-08.txt X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 16:19:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the STORage Maintenance Working Group of the = IETF. Title : Internet Small Computer Systems Interface (iSCSI) SCSI F= eatures Update Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-08.txt Pages : 1 Date : 2013-07-30 Abstract: Internet Small Computer Systems Interface (iSCSI) is a SCSI transport protocol that maps the SCSI family of protocols onto TCP/IP. The iSCSI protocol as specified in RFCxxx (and as previously specified by the combination of RFC 3720 and RFC 5048) is based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI family of protocols. This document defines enhancements to the iSCSI protocol to support certain additional features of the SCSI protocol that were defined in SAM-3, SAM-4, and SAM-5. This document is a companion document to RFCxxx. -------------------------------------------------------- RFC EDITORS NOTE: The above two references to RFCxxx should reference the RFC number assigned to the draft-ietf-storm- iscsi-cons-xx document, and this note should be removed. -------------------------------------------------------- The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-storm-iscsi-sam-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-storm-iscsi-sam-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From david.black@emc.com Wed Jul 31 02:05:59 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3A021F9702 for ; Wed, 31 Jul 2013 02:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1GCB4zZs93p for ; Wed, 31 Jul 2013 02:05:54 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E9A8021F9946 for ; Wed, 31 Jul 2013 01:51:00 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6V8opHu017031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 04:50:55 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Wed, 31 Jul 2013 04:50:35 -0400 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6V8oZnk006189 for ; Wed, 31 Jul 2013 04:50:35 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Wed, 31 Jul 2013 04:50:34 -0400 From: "Black, David" To: "storm@ietf.org" Date: Wed, 31 Jul 2013 04:50:34 -0400 Thread-Topic: iSCSI SAM draft publication request Thread-Index: Ac6NywVXxb+hU7WRSRaW+InL2XZZMA== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129857E19A@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_8D3D17ACE214DC429325B2B98F3AE7129857E19AMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] iSCSI SAM draft publication request X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:05:59 -0000 --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19AMX15Acorpemccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I just sent the -08 version of the iSCSI SAM draft back to our AD (Martin) for progress towards publication as an RFC. This will require another IETF Last Call (sorry). The publication request writeup is attached. There will be a draft status email covering all of the storm WG's drafts coming shortly. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19AMX15Acorpemccom_ Content-Type: text/plain; name="iSCSI SAM Proto Writeup v2.txt" Content-Description: iSCSI SAM Proto Writeup v2.txt Content-Disposition: attachment; filename="iSCSI SAM Proto Writeup v2.txt"; size=8157; creation-date="Wed, 31 Jul 2013 08:14:04 GMT"; modification-date="Wed, 31 Jul 2013 08:41:39 GMT" Content-Transfer-Encoding: base64 UFJPVE8gd3JpdGV1cDoNCg0KICBJbnRlcm5ldCBTbWFsbCBDb21wdXRlciBTeXN0ZW1zIEludGVy ZmFjZSAoaVNDU0kpIFNDU0kgRmVhdHVyZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBVcGRhdGUNCiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zdG9ybS1pc2NzaS1zYW0tMDgu dHh0DQoNClJlcXVlc3RlZCBQdWJsaWNhdGlvbiBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkDQpQ Uk9UTyBzaGVwaGVyZDogRGF2aWQgTC4gQmxhY2sgKFNUT1JNIFdHIENvLUNoYWlyKQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiAgKDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhp cyBkb2N1bWVudD8gSGFzIHRoZQ0KICAgICAgICBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5 IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUgDQogICAgICAgIGRvY3VtZW50IGFuZCwgaW4g cGFydGljdWxhciwgZG9lcyBoZSBvciBzaGUgYmVsaWV2ZSB0aGlzIA0KICAgICAgICB2ZXJzaW9u IGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8NCg0K RGF2aWQgTC4gQmxhY2sgKGRhdmlkLmJsYWNrQGVtYy5jb20pIGlzIHRoZSBEb2N1bWVudCBTaGVw aGVyZC4gIFRoZQ0KRG9jdW1lbnQgU2hlcGhlcmQgaGFzIHJldmlld2VkIHRoaXMgdmVyc2lvbiBv ZiB0aGUgZG9jdW1lbnQNCmFuZCBiZWxpZXZlcyB0aGF0IGl0IGlzIHJlYWR5IGZvciBmb3J3YXJk aW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4NCg0KICAoMS5iKSBIYXMgdGhlIGRvY3Vt ZW50IGhhZCBhZGVxdWF0ZSByZXZpZXcgYm90aCBmcm9tIGtleSBXRyBtZW1iZXJzIA0KICAgICAg ICBhbmQgZnJvbSBrZXkgbm9uLVdHIG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJk IGhhdmUgDQogICAgICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBv ZiB0aGUgcmV2aWV3cyB0aGF0IA0KICAgICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPw0KDQpUaGUg ZG9jdW1lbnQgaGFzIGhhZCBzdWZmaWNpZW50IHJldmlldyBmcm9tIGtleSBXRyBtZW1iZXJzLCBm cm9tIGltcGxlbWVudGVycw0Kd2hvIHdvcmsgb24gaW1wb3J0YW50IGlTQ1NJIGltcGxlbWVudGF0 aW9ucyAoYm90aCBpbml0aWF0b3IgYW5kIHRhcmdldA0KaW1wbGVtZW50YXRpb25zKSBvdXRzaWRl IHRoZSBXRyBhbmQgZnJvbSBrZXkgbWVtYmVycyBvZiBJTkNJVFMgVGVjaG5pY2FsDQpDb21taXR0 ZWUgVDEwLCB0aGUgb3JnYW5pemF0aW9uIHJlc3BvbnNpYmxlIGZvciBTQ1NJIHN0YW5kYXJkcy4N Cg0KICAoMS5jKSBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQg dGhlIGRvY3VtZW50IA0KICAgICAgICBuZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxh ciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLCANCiAgICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJh dGlvbmFsIGNvbXBsZXhpdHksIHNvbWVvbmUgZmFtaWxpYXIgd2l0aCANCiAgICAgICAgQUFBLCBp bnRlcm5hdGlvbmFsaXphdGlvbiBvciBYTUw/DQoNCk5vLg0KDQogICgxLmQpIERvZXMgdGhlIERv Y3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIA0KICAgICAgICBp c3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0 b3INCiAgICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4YW1w bGUsIHBlcmhhcHMgaGUgDQogICAgICAgIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2Vy dGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIA0KICAgICAgICBoYXMgY29uY2VybnMgd2hl dGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IA0KICAgICAgICBldmVu dCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVk IA0KICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwg ZGV0YWlsIHRob3NlIA0KICAgICAgICBjb25jZXJucyBoZXJlLiBIYXMgYW4gSVBSIGRpc2Nsb3N1 cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IA0KICAgICAgICBiZWVuIGZpbGVkPyBJZiBzbywg cGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlIA0KICAgICAgICBkaXNjbG9zdXJlIGFu ZCBzdW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24gDQogICAgICAg IHRoaXMgaXNzdWUuDQoNCk5vLg0KDQogICgxLmUpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vu c3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KICAgICAgICByZXByZXNlbnQgdGhl IHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCANCiAgICAgICAg b3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0YW5k IGFuZCANCiAgICAgICAgYWdyZWUgd2l0aCBpdD8gICANCg0KVGhlIFdHIGNvbnNlbnN1cyBiZWhp bmQgdGhpcyBkb2N1bWVudCBpcyBzb2xpZDsgdGhlIFdHIGFzIGEgd2hvbGUNCnVuZGVyc3RhbmRz IHRoaXMgZG9jdW1lbnQgYW5kIGFncmVlcyB3aXRoIHRoZSBuZWVkIGZvciB0aGVzZSBtaW5vcg0K dXBkYXRlcy4NCg0KICAoMS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90 aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSANCiAgICAgICAgZGlzY29udGVudD8gSWYgc28sIHBs ZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIA0KICAgICAgICBzZXBhcmF0 ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IA0K ICAgICAgICBzaG91bGQgYmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rp b25uYWlyZSBpcyANCiAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJRCBUcmFja2VyLikNCg0KTm8u DQoNCiAgKDEuZykgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHZlcmlmaWVk IHRoYXQgdGhlIA0KICAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChTZWUg dGhlIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QgDQogICAgICAgIGFuZCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvdG9vbHMvaWRuaXRzLykuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgDQogICAgICAg IG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUgdGhvcm91Z2guDQoNClllcy4gaWRu aXRzIDIuMTIuMTcgY29tcGxhaW5lZCBhYm91dCBzb21lIG1pc3NpbmcgcmVmZXJlbmNlcywgYWxs IG9mDQp3aGljaCBhcmUgY292ZXJlZCBieSBSRkMgRWRpdG9yIE5vdGVzIGluIHRoZSBkb2N1bWVu dCwgYW5kIGl0IGFsc28NCmZsYWdnZWQgYWxsIHJlZmVyZW5jZXMgdG8gU0NTSSBzdGFuZGFyZHMg YXMgcG9zc2libGUgZG93cmVmcyAodGhleSBhcmVuJ3QpLg0KDQogICAgICAgIEhhcyB0aGUgZG9j dW1lbnQgDQogICAgICAgIG1ldCBhbGwgZm9ybWFsIHJldmlldyBjcml0ZXJpYSBpdCBuZWVkcyB0 bywgc3VjaCBhcyB0aGUgTUlCIA0KICAgICAgICBEb2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0 eXBlIHJldmlld3M/DQoNCk4vQS4NCg0KICAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0 cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZCANCiAgICAgICAgaW5mb3JtYXRpdmU/DQoN Clllcy4NCg0KICAgICAgICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l bnRzIHRoYXQgDQogICAgICAgIGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBv dGhlcndpc2UgaW4gYW4gdW5jbGVhciANCiAgICAgICAgc3RhdGU/IElmIHN1Y2ggbm9ybWF0aXZl IHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIA0KICAgICAgICBzdHJhdGVneSBmb3IgdGhl aXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIA0KICAgICAgICB0 aGF0IGFyZSBkb3dud2FyZCByZWZlcmVuY2VzLCBhcyBkZXNjcmliZWQgaW4gW1JGQzM5NjddPyBJ ZiANCiAgICAgICAgc28sIGxpc3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0 IHRoZSBBcmVhIA0KICAgICAgICBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVyZSBm b3IgdGhlbSBbUkZDMzk2N10uDQoNClRoaXMgZG9jdW1lbnQgbm9ybWF0aXZlbHkgcmVmZXJlbmNl cyBkcmFmdC1pZXRmLXN0b3JtLWlzY3NpLWNvbnMteHgsDQp3aGljaCBpcyBpbiB0aGUgUkZDIEVk aXRvcidzIFF1ZXVlLg0KDQpJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBub3JtYXRpdmVseSBy ZWZlcmVuY2VzIHRocmVlIFNDU0kgc3RhbmRhcmRzDQp0aGF0IGFyZSBkZXZlbG9wZWQgYnkgSU5D SVRTIFRlY2huaWNhbCBDb21taXR0ZWUgVDEwICh3d3cudDEwLm9yZyksDQpuYW1lbHkgU0FNMiwg U0FNNSBhbmQgU1BDNC4gIEFzIGEgY29tcGxldGVkIHN0YW5kYXJkLCBTQU0yIGlzIG5vdCBhDQpw dWJsaWNseSBhdmFpbGFibGUgZG9jdW1lbnQsIGJlY2F1c2UgVDEwJ3MgcGFyZW50IHN0YW5kYXJk cw0Kb3JnYW5pemF0aW9ucyBmdW5kIHRoZWlyIG9wZXJhdGlvbnMgaW4gcGFydCBieSBjaGFyZ2lu ZyBmb3IgY29waWVzIG9mDQpzdGFuZGFyZHMuICBUaGUgZG9jdW1lbnQgc2hlcGhlcmQsIERhdmlk IEJsYWNrLCBpcyBhbHNvIHRoZSBvZmZpY2lhbA0KVDEwIExpYWlzb24gdG8gdGhlIElFVEYgYW5k IGluIHRoYXQgcm9sZSwgaGUgaGFzIGJlZW4gYXV0aG9yaXplZCBieSBUMTANCnRvIHByb3ZpZGUg Y29waWVzIG9mIHRoZXNlIHN0YW5kYXJkcyB0byBJRVRGIHBhcnRpY2lwYW50cyBmb3IgdGhlaXIN CnBlcnNvbmFsIHVzZSBpbiBJRVRGIGFjdGl2aXRpZXMuIElmIGNvcGllcyBvZiBTQU0yIGFyZSBk ZXNpcmVkLCBwbGVhc2UNCmNvbnRhY3QgdGhlIGRvY3VtZW50IHNoZXBoZXJkLCBEYXZpZCBCbGFj ayAoZGF2aWQuYmxhY2tAZW1jLmNvbSkuDQoNCiAgKDEuaSkgSGFzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCB2ZXJpZmllZCB0aGF0IHRoZSBkb2N1bWVudCBJQU5BIA0KICAgICAgICBjb25zaWRlcmF0 aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkgDQogICAg ICAgIG9mIHRoZSBkb2N1bWVudD8gSWYgdGhlIGRvY3VtZW50IHNwZWNpZmllcyBwcm90b2NvbCAN CiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9ucyByZXF1ZXN0ZWQgaW4gYXBwcm9w cmlhdGUgSUFOQSANCiAgICAgICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMg Y2xlYXJseSBpZGVudGlmaWVkPyBJZiANCiAgICAgICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBu ZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5lIHRoZSANCiAgICAgICAgcHJvcG9zZWQgaW5pdGlh bCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24gDQogICAgICAgIHBy b2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhIA0KICAg ICAgICByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnk/IFNlZSBbUkZDNTIyNl0u IElmIHRoZSANCiAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJv Y2VzcyBoYXMgU2hlcGhlcmQgDQogICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cgDQogICAgICAgIGNhbiBhcHBvaW50IHRo ZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0aW9uPw0KDQpUaGUgSUFOQSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGhhcyBiZWVuIGNoZWNrZWQgLSB0aGUgdGV4dCBkZXNjcmli aW5nDQp0aGUgYWRkaXRpb25zIHRvIGV4aXN0aW5nIHJlZ2lzdHJpZXMgYW5kIGNyZWF0aW9uIG9m IG9uZSBuZXcgcmVnaXN0cnkNCmlzIGNsZWFyLiAgVGhlIG5ldyByZWdpc3RyeSBkb2VzIG5vdCB1 c2UgdGhlIEV4cGVydCBSZXZpZXcgcHJvY2Vzcy4NCg0KICAoMS5qKSBIYXMgdGhlIERvY3VtZW50 IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlIA0KICAgICAgICBkb2N1bWVu dCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTCANCiAg ICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4sIHZhbGlkYXRlIGNv cnJlY3RseSBpbiANCiAgICAgICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/DQoNCk4vQS4NCg0KICAo MS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCAN CiAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9j dW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNh biBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBw cm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgDQogICAgICAgIGFubm91bmNlbWVudCBjb250 YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOiANCg0KICAgICBUZWNobmljYWwgU3VtbWFyeQ0K DQogICBUaGUgSW50ZXJuZXQgU21hbGwgQ29tcHV0ZXIgU3lzdGVtcyBJbnRlcmZhY2UgKGlTQ1NJ KSBpcyBhIFNDU0kNCiAgIHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IG1hcHMgdGhlIFNDU0kgZmFt aWx5IG9mIHByb3RvY29scyBvbnRvDQogICBUQ1AvSVAuIFRoZSBiYXNlIGlTQ1NJIHByb3RvY29s IGlzIGJhc2VkIG9uIHRoZSBTQU0tMiAoU0NTSQ0KICAgQXJjaGl0ZWN0dXJlIE1vZGVsIC0gMikg U0NTSSBzdGFuZGFyZC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzDQogICBlbmhhbmNlbWVudHMg dG8gdGhlIGlTQ1NJIHByb3RvY29sIHRvIHN1cHBvcnQgY2VydGFpbiBhZGRpdGlvbmFsDQogICBT Q1NJIGZlYXR1cmVzIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgaW4gc3Vic2VxdWVudCB2ZXJzaW9u cyBvZg0KICAgdGhlIFNDU0kgQXJjaGl0ZWN0dXJlIE1vZGVsLg0KDQogICAgIFdvcmtpbmcgR3Jv dXAgU3VtbWFyeSANCg0KICAgVGhlcmUgd2FzIHZlcnkgbGl0dGxlIGRpc3NlbnQgaW4gdGhlIFdH IG92ZXIgdGhlIGZ1bmN0aW9uYWxpdHkgaW4gdGhpcw0KICAgZG9jdW1lbnQuICBTaWduaWZpY2Fu dCBXRyBkaXNjdXNzaW9uIHdhcyBkZXZvdGVkIHRvIGNvcnJlY3RseSBzcGVjaWZ5aW5nDQogICBT Q1NJLXJlbGF0ZWQgaWRlbnRpZmllcnMgdXNlZCBieSB0aGlzIGRyYWZ0LiAgUm9iIEVsbGlvdHQg YW5kIFJhbHBoDQogICBXZWJlciAoa2V5IG1lbWJlcnMgb2YgdGhlIFQxMCBTQ1NJIHN0YW5kYXJk cyBvcmdhbml6YXRpb24pIHByb3ZpZGVkDQogICBzaWduaWZpY2FudCBhc3Npc3RhbmNlIGluIHdv cmtpbmcgdGhyb3VnaCB0aGUgaWRlbnRpZmllciBpc3N1ZXMuDQogICANCiAgIFRoaXMgZG9jdW1l bnQgd2FzIHJldHVybmVkIHRvIHRoZSBXRyBhZnRlciBJRVNHIGV2YWx1YXRpb24gcHJpbWFyaWx5 DQogICB0byBkZWFsIHdpdGggZnVuY3Rpb25hbGl0eSBuZWdvdGlhdGlvbiBjb25jZXJucyAoaVND U0lQcm90b2NvbExldmVsIGtleSkNCiAgIGFuZCByZWxhdGVkIElBTkEgQ29uc2lkZXJhdGlvbnMu ICBUaGUgV0cgaGFzIHJlc29sdmVkIHRob3NlIGNvbmNlcm5zLg0KICANCiAgICAgRG9jdW1lbnQg UXVhbGl0eSANCg0KICAgaVNDU0kgaW1wbGVtZW50ZXJzIGZyb20gRGVsbCwgRU1DLCBNaWNyb3Nv ZnQsIE5ldEFwcCwgUmVkSGF0IGFuZCBWTXdhcmUNCiAgIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBmb3IgcXVhbGl0eSBhbmQgY29uc2lzdGVuY3kgd2l0aCBleGlzdGluZw0KICAgaW1wbGVt ZW50YXRpb25zLiAgVGhlIHJldmlld3MgaW5kaWNhdGUgdGhhdCB0aGUgZW5oYW5jZW1lbnRzIGFy ZSBjbGVhcmx5DQogICBzcGVjaWZpZWQsIGFuZCBhcmUgbm90IGV4cGVjdGVkIHRvIGJlIHNpZ25p ZmljYW50bHkgZGlzcnVwdGl2ZSB0byBhZGQgdG8NCiAgIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cy4NCg0K --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19AMX15Acorpemccom_-- From david.black@emc.com Wed Jul 31 02:13:33 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECA321F8C9D for ; Wed, 31 Jul 2013 02:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8sogcB6EzG0 for ; Wed, 31 Jul 2013 02:13:28 -0700 (PDT) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7D32321F9BCA for ; Wed, 31 Jul 2013 02:08:18 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6V98G38007111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 31 Jul 2013 05:08:16 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 31 Jul 2013 05:08:02 -0400 Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r6V982RW012473 for ; Wed, 31 Jul 2013 05:08:02 -0400 Received: from mx15a.corp.emc.com ([169.254.1.184]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Wed, 31 Jul 2013 05:08:02 -0400 From: "Black, David" To: "storm@ietf.org" Date: Wed, 31 Jul 2013 05:08:02 -0400 Thread-Topic: storm WG draft Status - July 31 Thread-Index: Ac6NzXWfxe8QSrXaSvi7yVqFn9kqZw== Message-ID: <8D3D17ACE214DC429325B2B98F3AE7129857E19E@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_8D3D17ACE214DC429325B2B98F3AE7129857E19EMX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] storm WG draft Status - July 31 X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:13:33 -0000 --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19EMX15Acorpemccom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yet more progress to report from the IETF meetings in Berlin: 1) iSCSI consolidated draft. Done! The publication approval announcement has appeared issued and the draft is now in the RFC Editor's Queue. Many thanks to Mallikarjun Chadalapaka (editor) and everyone else who contribute= d. 2) iSCSI SAM (new features) draft. The -08 version has now been returned t= o our AD (Martin) with a revised publication request (new writeup is attached= ) A second IETF Last Call will be required, followed by IESG Evaluation. 3) iSCSI MIB draft. The IETF Last Call and MIB Doctor review comments have been resolved in the latest version. With the availability of the revised version of the iSCSI SAM draft, I've asked our AD (Martin) to send this MIB draft into IESG Evaluation. 4) iSER draft. Done, and in the RFC Editor's Queue! Many thanks to Mike K= o (editor) and everyone else who contributed. 5) RFC 3723 IPsec requirements update draft. WG Last Call has completed, a= nd the comments have been resolved in the -03 version, and that version has be= en submitted to our AD for his review and IETF Last Call. AD review is expect= ed in the next couple of weeks. 6) That leaves the RDMA Extensions draft. There have now been multiple reviews of this draft, including by yours truly. Some of the review issues require WG discussion on the list. I strongly encourage the authors to sta= rt discussion of whatever needs attention from the reviews on this list soon. The issues in those reviews need to be resolved to that satisfaction of the reviewers before WG Last Call can start on this draft. Please ignore the announcements that WG Last Call for this draft was "Done" - those were caused by pilot error (wishful thinking) on my part (sorry) - this is being corrected. Please feel free to send questions to the list or directly to me. Thanks, --David (storm WG co-chair) ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19EMX15Acorpemccom_ Content-Type: text/plain; name="iSCSI SAM Proto Writeup v2.txt" Content-Description: iSCSI SAM Proto Writeup v2.txt Content-Disposition: attachment; filename="iSCSI SAM Proto Writeup v2.txt"; size=8157; creation-date="Wed, 31 Jul 2013 08:14:04 GMT"; modification-date="Wed, 31 Jul 2013 08:41:39 GMT" Content-Transfer-Encoding: base64 UFJPVE8gd3JpdGV1cDoNCg0KICBJbnRlcm5ldCBTbWFsbCBDb21wdXRlciBTeXN0ZW1zIEludGVy ZmFjZSAoaVNDU0kpIFNDU0kgRmVhdHVyZXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBVcGRhdGUNCiAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1zdG9ybS1pc2NzaS1zYW0tMDgu dHh0DQoNClJlcXVlc3RlZCBQdWJsaWNhdGlvbiBTdGF0dXM6IFByb3Bvc2VkIFN0YW5kYXJkDQpQ Uk9UTyBzaGVwaGVyZDogRGF2aWQgTC4gQmxhY2sgKFNUT1JNIFdHIENvLUNoYWlyKQ0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQoNCiAgKDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBmb3IgdGhp cyBkb2N1bWVudD8gSGFzIHRoZQ0KICAgICAgICBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5 IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUgDQogICAgICAgIGRvY3VtZW50IGFuZCwgaW4g cGFydGljdWxhciwgZG9lcyBoZSBvciBzaGUgYmVsaWV2ZSB0aGlzIA0KICAgICAgICB2ZXJzaW9u IGlzIHJlYWR5IGZvciBmb3J3YXJkaW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbj8NCg0K RGF2aWQgTC4gQmxhY2sgKGRhdmlkLmJsYWNrQGVtYy5jb20pIGlzIHRoZSBEb2N1bWVudCBTaGVw aGVyZC4gIFRoZQ0KRG9jdW1lbnQgU2hlcGhlcmQgaGFzIHJldmlld2VkIHRoaXMgdmVyc2lvbiBv ZiB0aGUgZG9jdW1lbnQNCmFuZCBiZWxpZXZlcyB0aGF0IGl0IGlzIHJlYWR5IGZvciBmb3J3YXJk aW5nIHRvIHRoZSBJRVNHIGZvciBwdWJsaWNhdGlvbi4NCg0KICAoMS5iKSBIYXMgdGhlIGRvY3Vt ZW50IGhhZCBhZGVxdWF0ZSByZXZpZXcgYm90aCBmcm9tIGtleSBXRyBtZW1iZXJzIA0KICAgICAg ICBhbmQgZnJvbSBrZXkgbm9uLVdHIG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJk IGhhdmUgDQogICAgICAgIGFueSBjb25jZXJucyBhYm91dCB0aGUgZGVwdGggb3IgYnJlYWR0aCBv ZiB0aGUgcmV2aWV3cyB0aGF0IA0KICAgICAgICBoYXZlIGJlZW4gcGVyZm9ybWVkPw0KDQpUaGUg ZG9jdW1lbnQgaGFzIGhhZCBzdWZmaWNpZW50IHJldmlldyBmcm9tIGtleSBXRyBtZW1iZXJzLCBm cm9tIGltcGxlbWVudGVycw0Kd2hvIHdvcmsgb24gaW1wb3J0YW50IGlTQ1NJIGltcGxlbWVudGF0 aW9ucyAoYm90aCBpbml0aWF0b3IgYW5kIHRhcmdldA0KaW1wbGVtZW50YXRpb25zKSBvdXRzaWRl IHRoZSBXRyBhbmQgZnJvbSBrZXkgbWVtYmVycyBvZiBJTkNJVFMgVGVjaG5pY2FsDQpDb21taXR0 ZWUgVDEwLCB0aGUgb3JnYW5pemF0aW9uIHJlc3BvbnNpYmxlIGZvciBTQ1NJIHN0YW5kYXJkcy4N Cg0KICAoMS5jKSBEb2VzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXZlIGNvbmNlcm5zIHRoYXQg dGhlIGRvY3VtZW50IA0KICAgICAgICBuZWVkcyBtb3JlIHJldmlldyBmcm9tIGEgcGFydGljdWxh ciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLCANCiAgICAgICAgZS5nLiwgc2VjdXJpdHksIG9wZXJh dGlvbmFsIGNvbXBsZXhpdHksIHNvbWVvbmUgZmFtaWxpYXIgd2l0aCANCiAgICAgICAgQUFBLCBp bnRlcm5hdGlvbmFsaXphdGlvbiBvciBYTUw/DQoNCk5vLg0KDQogICgxLmQpIERvZXMgdGhlIERv Y3VtZW50IFNoZXBoZXJkIGhhdmUgYW55IHNwZWNpZmljIGNvbmNlcm5zIG9yIA0KICAgICAgICBp c3N1ZXMgd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0 b3INCiAgICAgICAgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSBhd2FyZSBvZj8gRm9yIGV4YW1w bGUsIHBlcmhhcHMgaGUgDQogICAgICAgIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2Vy dGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIA0KICAgICAgICBoYXMgY29uY2VybnMgd2hl dGhlciB0aGVyZSByZWFsbHkgaXMgYSBuZWVkIGZvciBpdC4gSW4gYW55IA0KICAgICAgICBldmVu dCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVk IA0KICAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwg ZGV0YWlsIHRob3NlIA0KICAgICAgICBjb25jZXJucyBoZXJlLiBIYXMgYW4gSVBSIGRpc2Nsb3N1 cmUgcmVsYXRlZCB0byB0aGlzIGRvY3VtZW50IA0KICAgICAgICBiZWVuIGZpbGVkPyBJZiBzbywg cGxlYXNlIGluY2x1ZGUgYSByZWZlcmVuY2UgdG8gdGhlIA0KICAgICAgICBkaXNjbG9zdXJlIGFu ZCBzdW1tYXJpemUgdGhlIFdHIGRpc2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24gDQogICAgICAg IHRoaXMgaXNzdWUuDQoNCk5vLg0KDQogICgxLmUpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vu c3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IA0KICAgICAgICByZXByZXNlbnQgdGhl IHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCANCiAgICAgICAg b3RoZXJzIGJlaW5nIHNpbGVudCwgb3IgZG9lcyB0aGUgV0cgYXMgYSB3aG9sZSB1bmRlcnN0YW5k IGFuZCANCiAgICAgICAgYWdyZWUgd2l0aCBpdD8gICANCg0KVGhlIFdHIGNvbnNlbnN1cyBiZWhp bmQgdGhpcyBkb2N1bWVudCBpcyBzb2xpZDsgdGhlIFdHIGFzIGEgd2hvbGUNCnVuZGVyc3RhbmRz IHRoaXMgZG9jdW1lbnQgYW5kIGFncmVlcyB3aXRoIHRoZSBuZWVkIGZvciB0aGVzZSBtaW5vcg0K dXBkYXRlcy4NCg0KICAoMS5mKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90 aGVyd2lzZSBpbmRpY2F0ZWQgZXh0cmVtZSANCiAgICAgICAgZGlzY29udGVudD8gSWYgc28sIHBs ZWFzZSBzdW1tYXJpc2UgdGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIA0KICAgICAgICBzZXBhcmF0 ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IA0K ICAgICAgICBzaG91bGQgYmUgaW4gYSBzZXBhcmF0ZSBlbWFpbCBiZWNhdXNlIHRoaXMgcXVlc3Rp b25uYWlyZSBpcyANCiAgICAgICAgZW50ZXJlZCBpbnRvIHRoZSBJRCBUcmFja2VyLikNCg0KTm8u DQoNCiAgKDEuZykgSGFzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBwZXJzb25hbGx5IHZlcmlmaWVk IHRoYXQgdGhlIA0KICAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChTZWUg dGhlIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QgDQogICAgICAgIGFuZCBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvdG9vbHMvaWRuaXRzLykuIEJvaWxlcnBsYXRlIGNoZWNrcyBhcmUgDQogICAgICAg IG5vdCBlbm91Z2g7IHRoaXMgY2hlY2sgbmVlZHMgdG8gYmUgdGhvcm91Z2guDQoNClllcy4gaWRu aXRzIDIuMTIuMTcgY29tcGxhaW5lZCBhYm91dCBzb21lIG1pc3NpbmcgcmVmZXJlbmNlcywgYWxs IG9mDQp3aGljaCBhcmUgY292ZXJlZCBieSBSRkMgRWRpdG9yIE5vdGVzIGluIHRoZSBkb2N1bWVu dCwgYW5kIGl0IGFsc28NCmZsYWdnZWQgYWxsIHJlZmVyZW5jZXMgdG8gU0NTSSBzdGFuZGFyZHMg YXMgcG9zc2libGUgZG93cmVmcyAodGhleSBhcmVuJ3QpLg0KDQogICAgICAgIEhhcyB0aGUgZG9j dW1lbnQgDQogICAgICAgIG1ldCBhbGwgZm9ybWFsIHJldmlldyBjcml0ZXJpYSBpdCBuZWVkcyB0 bywgc3VjaCBhcyB0aGUgTUlCIA0KICAgICAgICBEb2N0b3IsIG1lZGlhIHR5cGUgYW5kIFVSSSB0 eXBlIHJldmlld3M/DQoNCk4vQS4NCg0KICAoMS5oKSBIYXMgdGhlIGRvY3VtZW50IHNwbGl0IGl0 cyByZWZlcmVuY2VzIGludG8gbm9ybWF0aXZlIGFuZCANCiAgICAgICAgaW5mb3JtYXRpdmU/DQoN Clllcy4NCg0KICAgICAgICBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1l bnRzIHRoYXQgDQogICAgICAgIGFyZSBub3QgcmVhZHkgZm9yIGFkdmFuY2VtZW50IG9yIGFyZSBv dGhlcndpc2UgaW4gYW4gdW5jbGVhciANCiAgICAgICAgc3RhdGU/IElmIHN1Y2ggbm9ybWF0aXZl IHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhlIA0KICAgICAgICBzdHJhdGVneSBmb3IgdGhl aXIgY29tcGxldGlvbj8gQXJlIHRoZXJlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIA0KICAgICAgICB0 aGF0IGFyZSBkb3dud2FyZCByZWZlcmVuY2VzLCBhcyBkZXNjcmliZWQgaW4gW1JGQzM5NjddPyBJ ZiANCiAgICAgICAgc28sIGxpc3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0 IHRoZSBBcmVhIA0KICAgICAgICBEaXJlY3RvciBpbiB0aGUgTGFzdCBDYWxsIHByb2NlZHVyZSBm b3IgdGhlbSBbUkZDMzk2N10uDQoNClRoaXMgZG9jdW1lbnQgbm9ybWF0aXZlbHkgcmVmZXJlbmNl cyBkcmFmdC1pZXRmLXN0b3JtLWlzY3NpLWNvbnMteHgsDQp3aGljaCBpcyBpbiB0aGUgUkZDIEVk aXRvcidzIFF1ZXVlLg0KDQpJbiBhZGRpdGlvbiwgdGhpcyBkb2N1bWVudCBub3JtYXRpdmVseSBy ZWZlcmVuY2VzIHRocmVlIFNDU0kgc3RhbmRhcmRzDQp0aGF0IGFyZSBkZXZlbG9wZWQgYnkgSU5D SVRTIFRlY2huaWNhbCBDb21taXR0ZWUgVDEwICh3d3cudDEwLm9yZyksDQpuYW1lbHkgU0FNMiwg U0FNNSBhbmQgU1BDNC4gIEFzIGEgY29tcGxldGVkIHN0YW5kYXJkLCBTQU0yIGlzIG5vdCBhDQpw dWJsaWNseSBhdmFpbGFibGUgZG9jdW1lbnQsIGJlY2F1c2UgVDEwJ3MgcGFyZW50IHN0YW5kYXJk cw0Kb3JnYW5pemF0aW9ucyBmdW5kIHRoZWlyIG9wZXJhdGlvbnMgaW4gcGFydCBieSBjaGFyZ2lu ZyBmb3IgY29waWVzIG9mDQpzdGFuZGFyZHMuICBUaGUgZG9jdW1lbnQgc2hlcGhlcmQsIERhdmlk IEJsYWNrLCBpcyBhbHNvIHRoZSBvZmZpY2lhbA0KVDEwIExpYWlzb24gdG8gdGhlIElFVEYgYW5k IGluIHRoYXQgcm9sZSwgaGUgaGFzIGJlZW4gYXV0aG9yaXplZCBieSBUMTANCnRvIHByb3ZpZGUg Y29waWVzIG9mIHRoZXNlIHN0YW5kYXJkcyB0byBJRVRGIHBhcnRpY2lwYW50cyBmb3IgdGhlaXIN CnBlcnNvbmFsIHVzZSBpbiBJRVRGIGFjdGl2aXRpZXMuIElmIGNvcGllcyBvZiBTQU0yIGFyZSBk ZXNpcmVkLCBwbGVhc2UNCmNvbnRhY3QgdGhlIGRvY3VtZW50IHNoZXBoZXJkLCBEYXZpZCBCbGFj ayAoZGF2aWQuYmxhY2tAZW1jLmNvbSkuDQoNCiAgKDEuaSkgSGFzIHRoZSBEb2N1bWVudCBTaGVw aGVyZCB2ZXJpZmllZCB0aGF0IHRoZSBkb2N1bWVudCBJQU5BIA0KICAgICAgICBjb25zaWRlcmF0 aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkgDQogICAg ICAgIG9mIHRoZSBkb2N1bWVudD8gSWYgdGhlIGRvY3VtZW50IHNwZWNpZmllcyBwcm90b2NvbCAN CiAgICAgICAgZXh0ZW5zaW9ucywgYXJlIHJlc2VydmF0aW9ucyByZXF1ZXN0ZWQgaW4gYXBwcm9w cmlhdGUgSUFOQSANCiAgICAgICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMg Y2xlYXJseSBpZGVudGlmaWVkPyBJZiANCiAgICAgICAgdGhlIGRvY3VtZW50IGNyZWF0ZXMgYSBu ZXcgcmVnaXN0cnksIGRvZXMgaXQgZGVmaW5lIHRoZSANCiAgICAgICAgcHJvcG9zZWQgaW5pdGlh bCBjb250ZW50cyBvZiB0aGUgcmVnaXN0cnkgYW5kIGFuIGFsbG9jYXRpb24gDQogICAgICAgIHBy b2NlZHVyZSBmb3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhIA0KICAg ICAgICByZWFzb25hYmxlIG5hbWUgZm9yIHRoZSBuZXcgcmVnaXN0cnk/IFNlZSBbUkZDNTIyNl0u IElmIHRoZSANCiAgICAgICAgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIEV4cGVydCBSZXZpZXcgcHJv Y2VzcyBoYXMgU2hlcGhlcmQgDQogICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cgDQogICAgICAgIGNhbiBhcHBvaW50IHRo ZSBuZWVkZWQgRXhwZXJ0IGR1cmluZyB0aGUgSUVTRyBFdmFsdWF0aW9uPw0KDQpUaGUgSUFOQSBD b25zaWRlcmF0aW9ucyBzZWN0aW9uIGhhcyBiZWVuIGNoZWNrZWQgLSB0aGUgdGV4dCBkZXNjcmli aW5nDQp0aGUgYWRkaXRpb25zIHRvIGV4aXN0aW5nIHJlZ2lzdHJpZXMgYW5kIGNyZWF0aW9uIG9m IG9uZSBuZXcgcmVnaXN0cnkNCmlzIGNsZWFyLiAgVGhlIG5ldyByZWdpc3RyeSBkb2VzIG5vdCB1 c2UgdGhlIEV4cGVydCBSZXZpZXcgcHJvY2Vzcy4NCg0KICAoMS5qKSBIYXMgdGhlIERvY3VtZW50 IFNoZXBoZXJkIHZlcmlmaWVkIHRoYXQgc2VjdGlvbnMgb2YgdGhlIA0KICAgICAgICBkb2N1bWVu dCB0aGF0IGFyZSB3cml0dGVuIGluIGEgZm9ybWFsIGxhbmd1YWdlLCBzdWNoIGFzIFhNTCANCiAg ICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0Yy4sIHZhbGlkYXRlIGNv cnJlY3RseSBpbiANCiAgICAgICAgYW4gYXV0b21hdGVkIGNoZWNrZXI/DQoNCk4vQS4NCg0KICAo MS5rKSBUaGUgSUVTRyBhcHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCAN CiAgICAgICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9j dW1lbnQgDQogICAgICAgIEFubm91bmNlbWVudCBXcml0ZS1VcD8gUmVjZW50IGV4YW1wbGVzIGNh biBiZSBmb3VuZCBpbiB0aGUNCiAgICAgICAgIkFjdGlvbiIgYW5ub3VuY2VtZW50cyBmb3IgYXBw cm92ZWQgZG9jdW1lbnRzLiBUaGUgYXBwcm92YWwgDQogICAgICAgIGFubm91bmNlbWVudCBjb250 YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOiANCg0KICAgICBUZWNobmljYWwgU3VtbWFyeQ0K DQogICBUaGUgSW50ZXJuZXQgU21hbGwgQ29tcHV0ZXIgU3lzdGVtcyBJbnRlcmZhY2UgKGlTQ1NJ KSBpcyBhIFNDU0kNCiAgIHRyYW5zcG9ydCBwcm90b2NvbCB0aGF0IG1hcHMgdGhlIFNDU0kgZmFt aWx5IG9mIHByb3RvY29scyBvbnRvDQogICBUQ1AvSVAuIFRoZSBiYXNlIGlTQ1NJIHByb3RvY29s IGlzIGJhc2VkIG9uIHRoZSBTQU0tMiAoU0NTSQ0KICAgQXJjaGl0ZWN0dXJlIE1vZGVsIC0gMikg U0NTSSBzdGFuZGFyZC4gIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzDQogICBlbmhhbmNlbWVudHMg dG8gdGhlIGlTQ1NJIHByb3RvY29sIHRvIHN1cHBvcnQgY2VydGFpbiBhZGRpdGlvbmFsDQogICBT Q1NJIGZlYXR1cmVzIHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgaW4gc3Vic2VxdWVudCB2ZXJzaW9u cyBvZg0KICAgdGhlIFNDU0kgQXJjaGl0ZWN0dXJlIE1vZGVsLg0KDQogICAgIFdvcmtpbmcgR3Jv dXAgU3VtbWFyeSANCg0KICAgVGhlcmUgd2FzIHZlcnkgbGl0dGxlIGRpc3NlbnQgaW4gdGhlIFdH IG92ZXIgdGhlIGZ1bmN0aW9uYWxpdHkgaW4gdGhpcw0KICAgZG9jdW1lbnQuICBTaWduaWZpY2Fu dCBXRyBkaXNjdXNzaW9uIHdhcyBkZXZvdGVkIHRvIGNvcnJlY3RseSBzcGVjaWZ5aW5nDQogICBT Q1NJLXJlbGF0ZWQgaWRlbnRpZmllcnMgdXNlZCBieSB0aGlzIGRyYWZ0LiAgUm9iIEVsbGlvdHQg YW5kIFJhbHBoDQogICBXZWJlciAoa2V5IG1lbWJlcnMgb2YgdGhlIFQxMCBTQ1NJIHN0YW5kYXJk cyBvcmdhbml6YXRpb24pIHByb3ZpZGVkDQogICBzaWduaWZpY2FudCBhc3Npc3RhbmNlIGluIHdv cmtpbmcgdGhyb3VnaCB0aGUgaWRlbnRpZmllciBpc3N1ZXMuDQogICANCiAgIFRoaXMgZG9jdW1l bnQgd2FzIHJldHVybmVkIHRvIHRoZSBXRyBhZnRlciBJRVNHIGV2YWx1YXRpb24gcHJpbWFyaWx5 DQogICB0byBkZWFsIHdpdGggZnVuY3Rpb25hbGl0eSBuZWdvdGlhdGlvbiBjb25jZXJucyAoaVND U0lQcm90b2NvbExldmVsIGtleSkNCiAgIGFuZCByZWxhdGVkIElBTkEgQ29uc2lkZXJhdGlvbnMu ICBUaGUgV0cgaGFzIHJlc29sdmVkIHRob3NlIGNvbmNlcm5zLg0KICANCiAgICAgRG9jdW1lbnQg UXVhbGl0eSANCg0KICAgaVNDU0kgaW1wbGVtZW50ZXJzIGZyb20gRGVsbCwgRU1DLCBNaWNyb3Nv ZnQsIE5ldEFwcCwgUmVkSGF0IGFuZCBWTXdhcmUNCiAgIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1 bWVudCBmb3IgcXVhbGl0eSBhbmQgY29uc2lzdGVuY3kgd2l0aCBleGlzdGluZw0KICAgaW1wbGVt ZW50YXRpb25zLiAgVGhlIHJldmlld3MgaW5kaWNhdGUgdGhhdCB0aGUgZW5oYW5jZW1lbnRzIGFy ZSBjbGVhcmx5DQogICBzcGVjaWZpZWQsIGFuZCBhcmUgbm90IGV4cGVjdGVkIHRvIGJlIHNpZ25p ZmljYW50bHkgZGlzcnVwdGl2ZSB0byBhZGQgdG8NCiAgIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cy4NCg0K --_002_8D3D17ACE214DC429325B2B98F3AE7129857E19EMX15Acorpemccom_-- From ietf-secretariat-reply@ietf.org Wed Jul 31 05:46:54 2013 Return-Path: X-Original-To: storm@ietfa.amsl.com Delivered-To: storm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248A021F9EE9 for ; Wed, 31 Jul 2013 05:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlaOucvazS2E for ; Wed, 31 Jul 2013 05:46:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0521F88FB for ; Wed, 31 Jul 2013 05:46:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: storm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130731124643.15728.61263.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 05:46:43 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 31 Jul 2013 09:23:00 -0700 Subject: [storm] Milestones changed for storm WG X-BeenThere: storm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Storage Maintenance WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:46:54 -0000 Changed milestone "Working Group Last Call on RDMA Protocol Extensions draft", set due date to August 2013 from June 2012, reverted to not being resolved. Changed milestone "Submit RDMA Protocol Extensions draft to IESG for consideration as a Standards Track document", set due date to October 2013 from September 2012. URL: http://datatracker.ietf.org/wg/storm/charter/