From david.black@emc.com Tue Aug 2 16:06:23 2011 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 9EC0621F84FB for ; Tue, 2 Aug 2011 16:06:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.682 X-Spam-Level: X-Spam-Status: No, score=-105.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjJBdYyzi4tr for ; Tue, 2 Aug 2011 16:06:23 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE0F21F84FA for ; Tue, 2 Aug 2011 16:06: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 p72N6Vt4018834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Aug 2011 19:06:31 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor) for ; Tue, 2 Aug 2011 19:06:14 -0400 Received: from mxhub29.corp.emc.com (mxhub29.corp.emc.com [128.221.47.158]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p72N6EaX029624 for ; Tue, 2 Aug 2011 19:06:14 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub29.corp.emc.com ([128.221.47.158]) with mapi; Tue, 2 Aug 2011 19:06:13 -0400 From: To: Date: Tue, 2 Aug 2011 19:06:12 -0400 Thread-Topic: iSCSI MIB Compliance Groups Thread-Index: AcxRaMYdlyjjNJprTU2x1caA8uT1wQ== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05895140FA@MX14A.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 MIB Compliance Groups 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 Aug 2011 23:06:23 -0000 Our AD (Dave Harrington) raised a concern in the Quebec City meeting about = whether the updates to the compliance statement and conformance groups were= done correctly in the -00 iSCSI MIB update draft (i.e., by deprecating the= existing objects that should no longer be used, and defining new objects t= o replace them). I'm pleased to report that our talented MIB author team (Mark and Prakash) = got this right - there is a deprecated compliance statement plus multiple d= eprecated conformance groups in the -00 draft, accompanied by a V2 complian= ce statement and new V2 conformance groups corresponding to the deprecated = groups. Well done! 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 mbakke@cisco.com Wed Aug 3 09:34:22 2011 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 0079521F86A5 for ; Wed, 3 Aug 2011 09:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-df7B+Ka3eD for ; Wed, 3 Aug 2011 09:34:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id EDEC421F8678 for ; Wed, 3 Aug 2011 09:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbakke@cisco.com; l=1728; q=dns/txt; s=iport; t=1312389273; x=1313598873; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=1ByABibOcodrHc5xtTg2D2zNQfP0j9Vcj6NxXPVoxx0=; b=JgGJX8tJooYXAUNMtwGBiNPA/AAP9Qlsy2t5PnUSRLtCe87Fcm0NLwRw JhaSSqlW4iPyax7iSclKcWxiEsTh/5IvJwN6LTPUGhgz+UCMqKgRxrz2X 5XdvmPL+vxEXbTgZvmfhwqRXwZunSR9P+FyVZRD6B3X2LVih06aGLKZP6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AukAAHx3OU6tJV2b/2dsb2JhbAA/A5gGj1p3gUABAQEBAwEBAQ8BHT4XBAIBCBEEAQELBhcBBgEmHwkIAQEEARIIGodOohEBnmSDPoIlXwSHKy+QMYty X-IronPort-AV: E=Sophos;i="4.67,311,1309737600"; d="scan'208";a="9306177" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 03 Aug 2011 16:34:33 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p73GYXch015997; Wed, 3 Aug 2011 16:34:33 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 11:34:32 -0500 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Aug 2011 11:34:30 -0500 Message-ID: <97CC2D4896BE5D48825529CE9A168825064DCC99@XMB-RCD-105.cisco.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05895140FA@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] iSCSI MIB Compliance Groups Thread-Index: AcxRaMYdlyjjNJprTU2x1caA8uT1wQAkg9dQ References: <7C4DFCE962635144B8FAE8CA11D0BF1E05895140FA@MX14A.corp.emc.com> From: "Mark Bakke (mbakke)" To: , X-OriginalArrivalTime: 03 Aug 2011 16:34:32.0570 (UTC) FILETIME=[393AD5A0:01CC51FB] Subject: Re: [storm] iSCSI MIB Compliance Groups 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, 03 Aug 2011 16:34:22 -0000 Thanks, David! BTW, for the attributes we added -- InstXNodeArchitecture, = IntrLoginAuthorizeFails, SsnProtocolLevel, and SsnTaskReporting, we = simply added these to the appropriate AttributesEntry objects, and to = their conformance statements. We believe that's correct for adding new = attributes. Mark -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf = Of david.black@emc.com Sent: Tuesday, August 02, 2011 6:06 PM To: storm@ietf.org Subject: [storm] iSCSI MIB Compliance Groups Our AD (Dave Harrington) raised a concern in the Quebec City meeting = about whether the updates to the compliance statement and conformance = groups were done correctly in the -00 iSCSI MIB update draft (i.e., by = deprecating the existing objects that should no longer be used, and = defining new objects to replace them). I'm pleased to report that our talented MIB author team (Mark and = Prakash) got this right - there is a deprecated compliance statement = plus multiple deprecated conformance groups in the -00 draft, = accompanied by a V2 compliance statement and new V2 conformance groups = corresponding to the deprecated groups. Well done! 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-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Fri Aug 12 08:23:45 2011 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 B391321F8A64 for ; Fri, 12 Aug 2011 08:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.463 X-Spam-Level: X-Spam-Status: No, score=-106.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XG46sYmf-3+c for ; Fri, 12 Aug 2011 08:23:45 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 02A4B21F8A51 for ; Fri, 12 Aug 2011 08:23:44 -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 p7CFOKtk019780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 11:24:20 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Fri, 12 Aug 2011 11:21:09 -0400 Received: from mxhub18.corp.emc.com (mxhub18.corp.emc.com [10.254.93.47]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7CFL9rM002010 for ; Fri, 12 Aug 2011 11:21:09 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub18.corp.emc.com ([10.254.93.47]) with mapi; Fri, 12 Aug 2011 11:21:08 -0400 From: To: , Date: Fri, 12 Aug 2011 11:21:02 -0400 Thread-Topic: RDMA extensions of the work Thread-Index: AcxMjMyZDqKqpb3bQIaZLJxVw8PmdQMdm4lg Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589609F62@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E058951349B@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058951349B@MX14A.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 Subject: Re: [storm] RDMA extensions of the work 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, 12 Aug 2011 15:23:45 -0000 Having seen no objections, draft-ietf-storm-rdmap-ext-01 will be an officia= l WG draft; I need to get the necessary minor change to the WG charter approved and pos= ted before I can change the state of that draft in the draft tracker. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= david.black@emc.com > Sent: Wednesday, July 27, 2011 2:41 PM > To: storm@ietf.org > Subject: [storm] RDMA extensions of the work >=20 > The sense of the storm WG meeting in Quebec City was that the storm WG > should adopt draft-ietf-storm-rdmap-ext-01 as a WG draft, and work on > the RDMA protocol extensions proposed therein. >=20 > This new draft would progress behind our existing work - the iSCSI > drafts are in WG Last Call, with the iSCSI MIB and iSER drafts intended > to go to WG last Call in the next few months. >=20 > If there are any objections to this, please send them to the list > quickly. >=20 > 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-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Fri Aug 12 16:59:21 2011 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 0A46B21F8B22 for ; Fri, 12 Aug 2011 16:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.467 X-Spam-Level: X-Spam-Status: No, score=-106.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 kkgp+Jw9XdPz for ; Fri, 12 Aug 2011 16:59:20 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id A13FE21F8B20 for ; Fri, 12 Aug 2011 16:59: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 p7CNxq67002575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Aug 2011 19:59:52 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Fri, 12 Aug 2011 19:59:46 -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 p7CNxjx6030492 for ; Fri, 12 Aug 2011 19:59:45 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Fri, 12 Aug 2011 19:59:45 -0400 From: To: Importance: high X-Priority: 1 Date: Fri, 12 Aug 2011 19:59:44 -0400 Thread-Topic: iSCSI drafts - Last Call update and extension Thread-Index: AcxZS+g4qTFcwWpvSQumsqUsZ9Mpqg== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A0E7@MX14A.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 Subject: [storm] iSCSI drafts - Last Call update and extension 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, 12 Aug 2011 23:59:21 -0000 Reminder: the two iSCSI drafts are in WG Last Call: iSCSI Protocol (Consolidated) draft-ietf-storm-iscsi-cons-03.txt Internet Small Computer Systems Interface (iSCSI) SAM draft-ietf-storm-iscsi-sam-03.txt Please send all technical comments to the storm mailing list (storm@ietf.or= g). Editorial comments may be sent directly to the draft editors: - iSCSI Protocol (Consolidated): Mallikarjun Chadalapaka - iSCSI SAM (new features): Frederick Knight A new version of the SAM draft is expected sometime soon to correct problem= s in the title, abstract, and IANA registry text (the IANA changes were discu= ssed in Quebec City - they mostly affect the range of allocatable values, not th= e actual values used in these two drafts). I've been reaching out to a number of implementation groups at EMC, VMware and Dell, along with the Linux implementers. I have some feedback - one of the EMC implementation groups looked at the SAM draft and the changes that = the consolidated iSCSI draft makes to the existing RFCs and indicated that they saw no problems with the changes. August seems to be a slow month for everyone. Therefore the WG Last Call o= n these two drafts is EXTENDED to midnight, US Eastern Time on Tuesday, Septe= mber 6. 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 Frederick.Knight@netapp.com Mon Aug 15 21:22:03 2011 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 5718F21F8B22 for ; Mon, 15 Aug 2011 21:22:03 -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 Q4aZqX2GXBCt for ; Mon, 15 Aug 2011 21:22:01 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id B57F621F8B03 for ; Mon, 15 Aug 2011 21:22:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.67,378,1309762800"; d="scan'208,217";a="571071519" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 15 Aug 2011 21:22:48 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7G4MlTi020311 for ; Mon, 15 Aug 2011 21:22:48 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Aug 2011 21:22:47 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Aug 2011 00:22:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AkMd Awsu CGOG CIiO CxQn DxN9 FZJf Fulb GGbn IZwG ImnY Irtj J20O LW0n LfL6 LrPj; 1; cwB0AG8AcgBtAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {A1066528-30C8-42AC-95BD-0F9E1D4EC702}; ZgByAGUAZABlAHIAaQBjAGsALgBrAG4AaQBnAGgAdABAAG4AZQB0AGEAcABwAC4AYwBvAG0A; Tue, 16 Aug 2011 04:16:49 GMT; QwBvAG4AcwBvAGwAaQBkAGEAdABlAGQAIABkAHIAYQBmAHQA MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC5BCC.26469292" x-cr-puzzleid: {A1066528-30C8-42AC-95BD-0F9E1D4EC702} Content-class: urn:content-classes:message Date: Tue, 16 Aug 2011 00:22:46 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consolidated draft Thread-Index: Acxbnc1bmsgg0WazTlG/tEgLbqmqFQ== From: "Knight, Frederick" To: X-OriginalArrivalTime: 16 Aug 2011 04:22:46.0570 (UTC) FILETIME=[2695A8A0:01CC5BCC] Subject: [storm] Consolidated draft 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, 16 Aug 2011 04:22:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC5BCC.26469292 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are a couple of minor comments on the consolidated draft: =20 1) an observation in the abstract is the sentence: =20 The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM). =20 In fact, "SAM" is incorrect here. SAM is not a generic name; SAM is the name of the very first version of the SCSI Architecture Model. In fact, the original iSCSI was based on SAM-2, not SAM. Maybe it should leave out the use of a meaningful SCSI acronym (SAM) and just say: =20 The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture. =20 2) Last paragraph of abstract: =20 This document consolidates RFCs 3720, 3980, 4850 and 5048 into a single document and makes additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in RFCs 3720, 3721, 3980, 4850 and 5048 whenever there is such a question. =20 The first sentence does not list 3721 as part of the consolidation, but the last sentence says this document supersedes 3721. It seems that in order to supersede 3721, it must consolidate 3721 into this single document. The middle sentence ("This document also updates RFC3721.") adds confusion. Is it that just some of 3721 is consolidated, and other parts are not consolidated, so in fact, only some of 3721 is superseded? =20 The last sentence is also missing something ... "The text in this document supersedes the text in ... whenever there is such a question." - what question? Does this mean whenever there is a conflict?; or whenever they disagree?; or whenever there is a difference? =20 Fred =20 ------_=_NextPart_001_01CC5BCC.26469292 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are a couple of minor comments on the = consolidated draft:

 

1)      = an observation in the abstract is the sentence:

 

The iSCSI protocol aims to be fully compliant with

  the standardized SCSI = Architecture Model (SAM).

 

In fact, “SAM” is incorrect here.  SAM is not a generic name; SAM = is the name of the very first version of the SCSI Architecture Model.  In fact, the original iSCSI was = based on SAM-2, not SAM.  Maybe it = should leave out the use of a meaningful SCSI acronym (SAM) and just = say:

 

The iSCSI protocol aims to be fully compliant with = the standardized SCSI Architecture.

 

2)      = Last paragraph of abstract:

 

This document consolidates RFCs 3720, 3980, 4850 and 5048 into =
a
  =
single document and makes additional updates to the =
consolidated
  specification. This document =
also updates RFC 3721. The text in
  this document thus supersedes =
the text in RFCs 3720, 3721, 3980,
  4850 and 5048 whenever there is =
such a question.
 

The first sentence does not list 3721 as part of = the consolidation, but the last sentence says this document supersedes = 3721.  It seems that in order to = supersede 3721, it must consolidate 3721 into this single document.  The middle sentence = (“This document also updates RFC3721.”) adds confusion.  Is it that just some of 3721 is consolidated, and other parts are not consolidated, so in fact, only = some of 3721 is superseded?

 

The last sentence is also missing something … ”The text in this document supersedes the text in … whenever = there is such a question.” – what question?  Does this mean = whenever there is a conflict?; or whenever they disagree?; or whenever there is a difference?

 

        = ;        Fred

 

------_=_NextPart_001_01CC5BCC.26469292-- From cbm@chadalapaka.com Tue Aug 16 20:12:50 2011 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 3CEF921F87E2 for ; Tue, 16 Aug 2011 20:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_20=-0.74] 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 YtM6NWMGDesp for ; Tue, 16 Aug 2011 20:12:49 -0700 (PDT) Received: from snt0-omc1-s17.snt0.hotmail.com (snt0-omc1-s17.snt0.hotmail.com [65.55.90.28]) by ietfa.amsl.com (Postfix) with ESMTP id AEB2E21F8783 for ; Tue, 16 Aug 2011 20:12:49 -0700 (PDT) Received: from SNT131-DS10 ([65.55.90.9]) by snt0-omc1-s17.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 20:13:39 -0700 X-Originating-IP: [131.107.0.74] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: Date: Tue, 16 Aug 2011 20:13:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acxcirlk82lZzM1gTs6Zi3TFVeLecA== Content-Language: en-us X-OriginalArrivalTime: 17 Aug 2011 03:13:39.0877 (UTC) FILETIME=[A9604550:01CC5C8B] Subject: [storm] iSCSI Level and Version 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, 17 Aug 2011 03:12:50 -0000 In doing an internal review of the iSCSI Last Call drafts, someone asked me this. I want to run this response by the larger WG to see if we're all in agreement. Question: What is the difference between Version-max/Version-min/Version-active values exchanged during the iSCSI Login phase, and the negotiated value of iSCSIProtocolLevel key? Answer: The V-* values agreed to during the Login process determine the operating version of the iSCSI protocol, and announce if any other versions can be supported by either side. The operational iSCSIProtocolLevel key on the other hand determines the specific protocol features that may be used on an iSCSI session, within the "Version-active" versioned iSCSI protocol. If this sounds reasonable, it is worth capturing this clarification in the SAM-4 draft where this key is defined. Thanks. Mallikarjun From cbm@chadalapaka.com Tue Aug 16 20:23:37 2011 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 3E21311E80BF for ; Tue, 16 Aug 2011 20:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599] 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 yrPoIZrVtpBu for ; Tue, 16 Aug 2011 20:23:36 -0700 (PDT) Received: from snt0-omc1-s39.snt0.hotmail.com (snt0-omc1-s39.snt0.hotmail.com [65.54.61.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB0711E808B for ; Tue, 16 Aug 2011 20:23:36 -0700 (PDT) Received: from SNT131-DS17 ([65.55.90.7]) by snt0-omc1-s39.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Aug 2011 20:24:23 -0700 X-Originating-IP: [131.107.0.74] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: "'Knight, Frederick'" , References: In-Reply-To: Date: Tue, 16 Aug 2011 20:24:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHBoKWCTGl7RQbUoEuCbM1a57YeepU11haA Content-Language: en-us X-OriginalArrivalTime: 17 Aug 2011 03:24:23.0953 (UTC) FILETIME=[29467810:01CC5C8D] Subject: Re: [storm] Consolidated draft 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, 17 Aug 2011 03:23:37 -0000 Thanks Fred for the feedback. On #1, I will update the reference to SAM-2, as the rest of the spec is based on SAM-2 (and SAM-4 compliance is coming in the new other draft). On #2, RFC 3721 is an Informational RFC - while the consolidated draft adds a clarification that overrides some 3721 verbiage (SLP SHOULD requirement) to remove any implementer ambiguity, the consolidated draft does not consolidate that RFC. The reason was that this is a standards-track document, and we did not want to include all the informational text into this. That's the reason for the current Abstract wording that you cite below. To explain "whenever there is such a question", the answer is all of those you have listed (I think of Conflict/Disagreement/Difference as the same in this context), :) Thanks. Mallikarjun From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Knight, Frederick Sent: Monday, August 15, 2011 9:23 PM To: storm@ietf.org Subject: [storm] Consolidated draft Here are a couple of minor comments on the consolidated draft: 1) an observation in the abstract is the sentence: The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture Model (SAM). In fact, "SAM" is incorrect here. SAM is not a generic name; SAM is the name of the very first version of the SCSI Architecture Model. In fact, the original iSCSI was based on SAM-2, not SAM. Maybe it should leave out the use of a meaningful SCSI acronym (SAM) and just say: The iSCSI protocol aims to be fully compliant with the standardized SCSI Architecture. 2) Last paragraph of abstract: This document consolidates RFCs 3720, 3980, 4850 and 5048 into a single document and makes additional updates to the consolidated specification. This document also updates RFC 3721. The text in this document thus supersedes the text in RFCs 3720, 3721, 3980, 4850 and 5048 whenever there is such a question. The first sentence does not list 3721 as part of the consolidation, but the last sentence says this document supersedes 3721. It seems that in order to supersede 3721, it must consolidate 3721 into this single document. The middle sentence ("This document also updates RFC3721.") adds confusion. Is it that just some of 3721 is consolidated, and other parts are not consolidated, so in fact, only some of 3721 is superseded? The last sentence is also missing something . "The text in this document supersedes the text in . whenever there is such a question." - what question? Does this mean whenever there is a conflict?; or whenever they disagree?; or whenever there is a difference? Fred From Frederick.Knight@netapp.com Tue Aug 16 22:13:41 2011 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 E0DC521F86EA for ; Tue, 16 Aug 2011 22:13:41 -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=[AWL=0.000, 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 BpWUg31hpD47 for ; Tue, 16 Aug 2011 22:13:38 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id AE04721F8A4F for ; Tue, 16 Aug 2011 22:13:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,237,1312182000"; d="scan'208";a="571442333" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 16 Aug 2011 22:14:26 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7H5EQDX014836; Tue, 16 Aug 2011 22:14:26 -0700 (PDT) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Aug 2011 22:14:25 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Aug 2011 01:14:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Aug 2011 01:13:45 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] iSCSI Level and Version Thread-Index: Acxcirlk82lZzM1gTs6Zi3TFVeLecAADeY+g References: From: "Knight, Frederick" To: "Mallikarjun Chadalapaka" , X-OriginalArrivalTime: 17 Aug 2011 05:14:24.0008 (UTC) FILETIME=[8736F080:01CC5C9C] Subject: Re: [storm] iSCSI Level and Version 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, 17 Aug 2011 05:13:42 -0000 The new SAM features draft changes the format of some PDUs. The current Version-max/min/active are fields within a PDU. The iSCSIProtocolLevel tells the end points which format to use for the PDUs, so the end point can find the fields within the PDU. This lets us have different format PDUs AFTER the negotiation of this key. The creation of the iSCSIProtocolLevel key allows us to write future drafts that make changes more radical than what the new SAM features draft contains. You need to know the iSCSIProtocolLevel to know which PDU format to use. So this makes me wonder, if we should move the negotiation of iSCSIProtocolLevel from the full feature phase to the login phase (should the negotiation of iSCSIProtocolLevel come earlier)? Might we ever want to change the format of any of the PDUs used during login? Fred -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]=20 Sent: Tuesday, August 16, 2011 11:14 PM To: storm@ietf.org Subject: [storm] iSCSI Level and Version In doing an internal review of the iSCSI Last Call drafts, someone asked me this. I want to run this response by the larger WG to see if we're all in agreement. Question: What is the difference between Version-max/Version-min/Version-active values exchanged during the iSCSI Login phase, and the negotiated value of iSCSIProtocolLevel key? Answer: The V-* values agreed to during the Login process determine the operating version of the iSCSI protocol, and announce if any other versions can be supported by either side. The operational iSCSIProtocolLevel key on the other hand determines the specific protocol features that may be used on an iSCSI session, within the "Version-active" versioned iSCSI protocol. If this sounds reasonable, it is worth capturing this clarification in the SAM-4 draft where this key is defined. Thanks. Mallikarjun _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From cbm@chadalapaka.com Thu Aug 18 13:41:38 2011 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 541541F0C3C for ; Thu, 18 Aug 2011 13:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599] 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 4n7TNeQaIo4c for ; Thu, 18 Aug 2011 13:41:37 -0700 (PDT) Received: from snt0-omc3-s49.snt0.hotmail.com (snt0-omc3-s49.snt0.hotmail.com [65.54.51.86]) by ietfa.amsl.com (Postfix) with ESMTP id B2FD31F0C3E for ; Thu, 18 Aug 2011 13:41:37 -0700 (PDT) Received: from SNT131-DS7 ([65.55.90.135]) by snt0-omc3-s49.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 13:42:32 -0700 X-Originating-IP: [131.107.0.86] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: , References: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A0E7@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A0E7@MX14A.corp.emc.com> Date: Thu, 18 Aug 2011 13:42:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGxuxIQHKHR6VALYrelcKhnd3+5ypVYVraQ Content-Language: en-us X-OriginalArrivalTime: 18 Aug 2011 20:42:32.0635 (UTC) FILETIME=[5AA2D0B0:01CC5DE7] Subject: Re: [storm] iSCSI drafts - Last Call update and extension 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, 18 Aug 2011 20:41:38 -0000 As David says below, Last call implementer review feedback is very = welcome. I personally am reaching out to implementers in Microsoft, and so far haven't uncovered any major issues (barring a clarification that I sent = two days ago to the mailing list). I have now posted the iSCSI Last Call review slides that I used in = internal reviews. This covers both iSCSI drafts in Last Call. Given the size of = the consolidated draft, you may take advantage of the slides in speeding up = your reviews. Please drop me a note if you'd like to see something added/updated. http://www.chadalapaka.com/Documents/iSCSI%20Drafts%20=96%20Last%20Call%2= 0Revi ew.pdf=20 Thanks. Mallikarjun -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: Friday, August 12, 2011 5:00 PM To: storm@ietf.org Subject: [storm] iSCSI drafts - Last Call update and extension Importance: High =20 Reminder: the two iSCSI drafts are in WG Last Call: =20 iSCSI Protocol (Consolidated) draft-ietf-storm-iscsi-cons-03.txt =20 Internet Small Computer Systems Interface (iSCSI) SAM draft-ietf-storm-iscsi-sam-03.txt =20 Please send all technical comments to the storm mailing list (storm@ietf.org). Editorial comments may be sent directly to the draft editors: - iSCSI Protocol (Consolidated): Mallikarjun Chadalapaka - iSCSI SAM (new features): Frederick Knight =20 A new version of the SAM draft is expected sometime soon to correct problems in the title, abstract, and IANA registry text (the IANA = changes were discussed in Quebec City - they mostly affect the range of allocatable values, not the actual values used in these two drafts). =20 I've been reaching out to a number of implementation groups at EMC, VMware and Dell, along with the Linux implementers. I have some = feedback - one of the EMC implementation groups looked at the SAM draft and the changes that the consolidated iSCSI draft makes to the existing RFCs = and indicated that they saw no problems with the changes. =20 August seems to be a slow month for everyone. Therefore the WG Last = Call on these two drafts is EXTENDED to midnight, US Eastern Time on = Tuesday, September 6. =20 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-7786 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- =20 =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From cbm@chadalapaka.com Thu Aug 18 17:39:04 2011 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 4AA9421F85C6 for ; Thu, 18 Aug 2011 17:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] 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 mhDdL2ZIbmKM for ; Thu, 18 Aug 2011 17:39:03 -0700 (PDT) Received: from snt0-omc1-s51.snt0.hotmail.com (snt0-omc1-s51.snt0.hotmail.com [65.54.61.88]) by ietfa.amsl.com (Postfix) with ESMTP id 4739C21F85B9 for ; Thu, 18 Aug 2011 17:39:03 -0700 (PDT) Received: from SNT131-DS4 ([65.55.90.8]) by snt0-omc1-s51.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 17:39:58 -0700 X-Originating-IP: [131.107.0.86] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: "'Knight, Frederick'" , References: In-Reply-To: Date: Thu, 18 Aug 2011 17:39:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGDQs4lOePtW6vA+go7jeBrB4F7AKLt1BRlJuXTbA= Content-Language: en-us X-OriginalArrivalTime: 19 Aug 2011 00:39:58.0585 (UTC) FILETIME=[85E24690:01CC5E08] Subject: Re: [storm] iSCSI Level and Version 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, 19 Aug 2011 00:39:04 -0000 I agree with Fred. I think we should mark the key as IO (Initialize-Only) in terms of when it can be used. As far as what the iSCSIProtocolLevel indicates though, it may communicate changes in PDU format and/or end node semantics. IOW, there is no reason to limit this exclusively to signal PDU format changes. Hope that makes sense. Changing the format of the Login-related PDUs is an interesting question. I would think that Version number should be bumped up to cover that scenario. Thanks. Mallikarjun -----Original Message----- From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] Sent: Tuesday, August 16, 2011 10:14 PM To: Mallikarjun Chadalapaka; storm@ietf.org Subject: RE: [storm] iSCSI Level and Version The new SAM features draft changes the format of some PDUs. The current Version-max/min/active are fields within a PDU. The iSCSIProtocolLevel tells the end points which format to use for the PDUs, so the end point can find the fields within the PDU. This lets us have different format PDUs AFTER the negotiation of this key. The creation of the iSCSIProtocolLevel key allows us to write future drafts that make changes more radical than what the new SAM features draft contains. You need to know the iSCSIProtocolLevel to know which PDU format to use. So this makes me wonder, if we should move the negotiation of iSCSIProtocolLevel from the full feature phase to the login phase (should the negotiation of iSCSIProtocolLevel come earlier)? Might we ever want to change the format of any of the PDUs used during login? Fred -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] Sent: Tuesday, August 16, 2011 11:14 PM To: storm@ietf.org Subject: [storm] iSCSI Level and Version In doing an internal review of the iSCSI Last Call drafts, someone asked me this. I want to run this response by the larger WG to see if we're all in agreement. Question: What is the difference between Version-max/Version- min/Version-active values exchanged during the iSCSI Login phase, and the negotiated value of iSCSIProtocolLevel key? Answer: The V-* values agreed to during the Login process determine the operating version of the iSCSI protocol, and announce if any other versions can be supported by either side. The operational iSCSIProtocolLevel key on the other hand determines the specific protocol features that may be used on an iSCSI session, within the "Version-active" versioned iSCSI protocol. If this sounds reasonable, it is worth capturing this clarification in the SAM-4 draft where this key is defined. Thanks. Mallikarjun _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From Frederick.Knight@netapp.com Thu Aug 18 23:07:08 2011 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 48C8411E80A1 for ; Thu, 18 Aug 2011 23:07:08 -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=[AWL=0.000, 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 2CtWNZKX4i7B for ; Thu, 18 Aug 2011 23:07:07 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 624CC11E8090 for ; Thu, 18 Aug 2011 23:07:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,249,1312182000"; d="scan'208";a="572153018" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 18 Aug 2011 23:08:03 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7J681lF027970; Thu, 18 Aug 2011 23:08:02 -0700 (PDT) Received: from rtprsexc2-prd.hq.netapp.com ([10.100.161.115]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Aug 2011 23:08:02 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.112]) by rtprsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Aug 2011 02:08:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2011 02:05:38 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] iSCSI Level and Version Thread-Index: AQIGDQs4lOePtW6vA+go7jeBrB4F7AKLt1BRlJuXTbCAAFt6oA== References: From: "Knight, Frederick" To: "Mallikarjun Chadalapaka" , X-OriginalArrivalTime: 19 Aug 2011 06:08:01.0100 (UTC) FILETIME=[5993B8C0:01CC5E36] Subject: Re: [storm] iSCSI Level and Version 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, 19 Aug 2011 06:07:08 -0000 I'll change it to IO (Initialize-Only). Yes, the iSCSIProtocolLevel indicates something the implementation needs to know very early in the communication process (that includes PDU formats, or end node semantics, or maybe something else we haven't thought of yet). I just described PDU formats, because that is the case that we happen to have in front of us at this point in time. And the rest of this stuff is hypothetical. Changing the version number wouldn't do any good, if you couldn't find the version number field (because of a change to the PDU format). Maybe in that hypothetical situation, BOTH the version number and the iSCSIProtocolLevel would need to change. But, let's wait to cross that bridge until we have too. Fred -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]=20 Sent: Thursday, August 18, 2011 8:40 PM To: Knight, Frederick; storm@ietf.org Subject: RE: [storm] iSCSI Level and Version I agree with Fred. I think we should mark the key as IO (Initialize-Only) in terms of when it can be used. As far as what the iSCSIProtocolLevel indicates though, it may communicate changes in PDU format and/or end node semantics. IOW, there is no reason to limit this exclusively to signal PDU format changes. Hope that makes sense. Changing the format of the Login-related PDUs is an interesting question. I would think that Version number should be bumped up to cover that scenario. Thanks. Mallikarjun -----Original Message----- From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] Sent: Tuesday, August 16, 2011 10:14 PM To: Mallikarjun Chadalapaka; storm@ietf.org Subject: RE: [storm] iSCSI Level and Version =20 The new SAM features draft changes the format of some PDUs. =20 The current Version-max/min/active are fields within a PDU. =20 The iSCSIProtocolLevel tells the end points which format to use for the PDUs, so the end point can find the fields within the PDU. This lets us have different format PDUs AFTER the negotiation of this key. The creation of the iSCSIProtocolLevel key allows us to write future drafts that make changes more radical than what the new SAM features draft contains. =20 You need to know the iSCSIProtocolLevel to know which PDU format to use. So this makes me wonder, if we should move the negotiation of iSCSIProtocolLevel from the full feature phase to the login phase (should the negotiation of iSCSIProtocolLevel come earlier)? Might we ever want to change the format of any of the PDUs used during login? =20 Fred =20 -----Original Message----- From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] Sent: Tuesday, August 16, 2011 11:14 PM To: storm@ietf.org Subject: [storm] iSCSI Level and Version =20 In doing an internal review of the iSCSI Last Call drafts, someone asked me this. I want to run this response by the larger WG to see if we're all in agreement. =20 Question: What is the difference between Version-max/Version- min/Version-active values exchanged during the iSCSI Login phase, and the negotiated value of iSCSIProtocolLevel key? =20 Answer: The V-* values agreed to during the Login process determine the operating version of the iSCSI protocol, and announce if any other versions can be supported by either side. The operational iSCSIProtocolLevel key on the other hand determines the specific protocol features that may be used on an iSCSI session, within the "Version-active" versioned iSCSI protocol. =20 If this sounds reasonable, it is worth capturing this clarification in the SAM-4 draft where this key is defined. =20 Thanks. =20 Mallikarjun =20 =20 =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From swise@opengridcomputing.com Tue Aug 23 06:48:26 2011 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 04FF621F8B33 for ; Tue, 23 Aug 2011 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 MrZyXzbLiblH for ; Tue, 23 Aug 2011 06:48:25 -0700 (PDT) Received: from linode.aoot.com (linode.aoot.com [69.164.194.13]) by ietfa.amsl.com (Postfix) with ESMTP id E6A0321F8B2F for ; Tue, 23 Aug 2011 06:48:17 -0700 (PDT) Received: from [10.10.0.77] (unknown [209.198.142.3]) by linode.aoot.com (Postfix) with ESMTP id B9FBA821C; Tue, 23 Aug 2011 08:49:24 -0500 (CDT) Message-ID: <4E53AFD2.50108@opengridcomputing.com> Date: Tue, 23 Aug 2011 08:49:06 -0500 From: Steve Wise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: arkady kanevsky References: <95DEF288D9FA451B8C4BCA4ACAE1C6DA@davidPC> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Nikolova, Tatyana E" , "Latif, Faisal" , Kumar A S , storm@ietf.org Subject: [storm] draft-ietf-storm-mpa-peer-connect - review 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: Tue, 23 Aug 2011 13:48:26 -0000 Hey, I believe the ORD/IRD fields in the MPAv2 messages need to be in Network Byte Order. This is not mandated in the draft. I also think there is an oversight in RFC 5044 with regard to the PD_Length field in the MPAv1 messages. It should also be in Network Byte Order, but I don't see this requirement anywhere in the RFC. Or maybe NBO is a always assumed in IETF wire-protocol messages? Steve. From david.black@emc.com Wed Aug 24 16:09:09 2011 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 E896021F8CA5 for ; Wed, 24 Aug 2011 16:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 4sEji1kUh7oB for ; Wed, 24 Aug 2011 16:09:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA35421F8CAE for ; Wed, 24 Aug 2011 16:09:08 -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 p7ONAI4h011925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 19:10:18 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 19:10:05 -0400 Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ONA4es030119 for ; Wed, 24 Aug 2011 19:10:04 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Wed, 24 Aug 2011 19:10:04 -0400 From: To: , Date: Wed, 24 Aug 2011 19:10:02 -0400 Thread-Topic: Drafts of new iSCSI specs Thread-Index: AcxbbRUHmJTfdUS+ThepJzeK4W8f9wHRNjgA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413C60@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058959DA1E@MX14A.corp.emc.com> <20110815170044.GE1978@vmware.com> <20110815170212.GF1978@vmware.com> In-Reply-To: <20110815170212.GF1978@vmware.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 Cc: abanta@vmware.com, khuang@vmware.com, ntomar@vmware.com, ksreekanti@vmware.com, paithal@vmware.com, ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs 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, 24 Aug 2011 23:09:10 -0000 Andy, Many thanks for looking at the consolidated draft. > In section 9.2, authentication is now required (MUST rather than MAY). > I'm quite sure this isn't going to fly with everyone. CHAP is rarely > used in production environments, and until there's some distributed > key authentication method, I don't think many customers are going > to be interested. Indeed it does, good catch, thank you. The offending text in the consolidated draft is: 9.2. In-band Initiator-Target Authentication During login, the target MUST authenticate the initiator and the initiator MAY authenticate the target. RFC 3720 had this text instead: 8.2. In-band Initiator-Target Authentication During login, the target MAY authenticate the initiator and the initiator MAY authenticate the target. 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 ---------------------------------------------------- > -----Original Message----- > From: Andy Banta [mailto:abanta@vmware.com] > Sent: Monday, August 15, 2011 1:02 PM > To: Black, David; storm@ietf.org > Cc: Banta, Andy (VMWare); Sreekanti, Kumar (VMWare); Huang, Kun (VMWare);= Aithal, Prasanna (VMWare); > Tomar, Nagendra (VMWare) > Subject: Re: Drafts of new iSCSI specs >=20 > On Thu, Aug 04, 2011 at 12:08:38AM -0400, Black, David wrote: > > Andy, > > > > Can I interest you or anyone else at VMware in taking a look at these > > specs - it > > shouldn't involve a lot of time. I can extend the deadline for input > > past VMworld if that helps. >=20 > David, Folks, >=20 > I'm the vSphere iSCSI development tech lead at VMware. >=20 > I got a chance to look at the first one. A few comments: >=20 > In section 9.2, authentication is now required (MUST rather than MAY). > I'm quite sure this isn't going to fly with everyone. CHAP is rarely > used in production environments, and until there's some distributed > key authentication method, I don't think many customers are going > to be interested. >=20 > If this RFC gets approved as written, it will regularly be violated at > this clause. >=20 > We are interested in coming up with a pluggable authentication method, > but I don't think that will change the spec in any way. >=20 > I don't have any other specific comments based on the changes, but > have not gone through the spec in detail. I'll take a look at the > second spec in the next few days. >=20 > Thanks, > Andy > banta@vmware.com >=20 > > Thanks, > > --David > > > > > -----Original Message----- > > > From: Black, David > > > Sent: Friday, July 15, 2011 2:01 AM > > > To: Banta, Andy (VMWare) > > > Cc: Black, David > > > Subject: FW: Drafts of new iSCSI specs > > > Importance: High > > > > > > Hi Andy, > > > > > > It was good to see you at EMC World, even if only briefly. > > > > > > I'm one of the co-chairs of the IETF storm (STORage Maintenance), whe= re > > > new drafts of the iSCSI specifications are close to completion (they'= re > > > in Working Group Last Call). We're looking for review and feedback f= rom > > > iSCSI implementers, and I was hoping that you could take a look at th= is > > > on behalf of ESX's iSCSI implementation. > > > > > > There are two new iSCSI drafts: > > > > > > (1) iSCSI Protocol (Consolidated), draft-ietf-storm-iscsi-cons-03 > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ > > > > > > This draft consolidates several existing iSCSI RFCs, primarily RFC 37= 20 > > > and RFC 5048, and removes some unimplemented features - the result sh= ould be > > > backwards-compatible with existing implementations. As the draft is = several > > > hundred pages in length, I don't expect you to read it in its entiret= y, but > > > could you look at this summary of what's been changed and see whether= it's > > > reasonable?: > > > > > > 2.3. Summary of Changes > > > > > > 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the > > > necessary editorial changes > > > 2) iSCSIProtocolLevel is specified as "1" in section 13.24, an= d > > > added a related normative reference to [iSCSI-SAM] draft > > > 3) Markers and related keys were removed > > > 4) SPKM authentication and related keys were removed > > > 5) Added a new section 13.25 on responding to obsoleted keys > > > 6) Have explicitly allowed initiator+target implementations > > > throughout the text > > > 7) Clarified in section 4.2.7 that implementations SHOULD NOT > > > rely on SLP-based discovery > > > 8) Added UML diagrams, and related conventions in section 3 > > > 9) FastAbort implementation is made a "SHOULD" requirement in > > > section 4.2.3.4 from the previous "MUST" requirement. > > > 10) Clarified in section 6.2 that validity of NotUnderstood > > > response depends on iSCSIProtocolLevel > > > > > > (2) iSCSI SAM features, draft-ietf-storm-iscsi-sam-03 > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ > > > > > > iSCSI was originally based on version 2 of the SCSI architecture, SAM= -2. > > > This draft updates iSCSI to the current version of the SCSI architect= ure, > > > SAM-5, by adding additional features, and a text key to negotiate the= ir > > > usage, iSCSIProtocolLevel. The draft is only about 20 pages - please= take > > > a look at it from an implementer's standpoint. > > > > > > Finally, if there's anything you wish the iSCSI RFCs said, or functio= nality > > > that you think should be removed, please say so. > > > > > > Your comments can be sent directly to the mailing list - storm@ietf.o= rg, > > > or can be sent to me. Please identify yourself as a VMware iSCSI > > > implementer in your comments. The Working Group Last Call on these d= rafts > > > runs through August 21st - please let me know when you think you coul= d > > > have comments ready. > > > > > > 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) 2= 93-7786 > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > ---------------------------------------------------- > > From david.black@emc.com Wed Aug 24 16:12:02 2011 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 8737D21F8C07 for ; Wed, 24 Aug 2011 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.991 X-Spam-Level: X-Spam-Status: No, score=-105.991 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 J+xsT9R03g+H for ; Wed, 24 Aug 2011 16:12:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id C3ADE21F8BF8 for ; Wed, 24 Aug 2011 16:12:01 -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 p7ONDCoO014217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 19:13:12 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 19:12:59 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.221.56.109]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ONCxLP019897 for ; Wed, 24 Aug 2011 19:12:59 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub23.corp.emc.com ([128.221.56.109]) with mapi; Wed, 24 Aug 2011 19:12:59 -0400 From: To: Date: Wed, 24 Aug 2011 19:12:57 -0400 Thread-Topic: iSCSI drafts - EMC commentary Thread-Index: AQGxuxIQHKHR6VALYrelcKhnd3+5ypVYVraQgAmZcQA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5B@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E058960A0E7@MX14A.corp.emc.com> In-Reply-To: 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 drafts - EMC commentary 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, 24 Aug 2011 23:12:02 -0000 I have reached out to both the VNX and Symmetrix iSCSI implementation teams= inside EMC. Both teams have checked the changes in the consolidated draft and the= features in the SAM draft, and do not have any problems with what is being specified= . 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 ---------------------------------------------------- > -----Original Message----- > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] > Sent: Thursday, August 18, 2011 4:42 PM > To: Black, David; storm@ietf.org > Subject: RE: [storm] iSCSI drafts - Last Call update and extension >=20 > As David says below, Last call implementer review feedback is very welcom= e. >=20 > I personally am reaching out to implementers in Microsoft, and so far > haven't uncovered any major issues (barring a clarification that I sent t= wo > days ago to the mailing list). >=20 > I have now posted the iSCSI Last Call review slides that I used in intern= al > reviews. This covers both iSCSI drafts in Last Call. Given the size of = the > consolidated draft, you may take advantage of the slides in speeding up y= our > reviews. Please drop me a note if you'd like to see something > added/updated. >=20 > http://www.chadalapaka.com/Documents/iSCSI%20Drafts%20-%20Last%20Call%20R= eview.pdf >=20 >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of david.black@emc.com > Sent: Friday, August 12, 2011 5:00 PM > To: storm@ietf.org > Subject: [storm] iSCSI drafts - Last Call update and extension > Importance: High >=20 > Reminder: the two iSCSI drafts are in WG Last Call: >=20 > iSCSI Protocol (Consolidated) > draft-ietf-storm-iscsi-cons-03.txt >=20 > Internet Small Computer Systems Interface (iSCSI) SAM > draft-ietf-storm-iscsi-sam-03.txt >=20 > Please send all technical comments to the storm mailing list > (storm@ietf.org). > Editorial comments may be sent directly to the draft editors: > - iSCSI Protocol (Consolidated): Mallikarjun Chadalapaka > > - iSCSI SAM (new features): Frederick Knight >=20 > A new version of the SAM draft is expected sometime soon to correct > problems in the title, abstract, and IANA registry text (the IANA chang= es > were discussed in Quebec City - they mostly affect the range of > allocatable > values, not the actual values used in these two drafts). >=20 > I've been reaching out to a number of implementation groups at EMC, > VMware and Dell, along with the Linux implementers. I have some feedba= ck > - one of the EMC implementation groups looked at the SAM draft and the > changes that the consolidated iSCSI draft makes to the existing RFCs an= d > indicated that they saw no problems with the changes. >=20 > August seems to be a slow month for everyone. Therefore the WG Last Ca= ll > on these two drafts is EXTENDED to midnight, US Eastern Time on Tuesday= , > September 6. >=20 > 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= -7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm >=20 From david.black@emc.com Wed Aug 24 16:20:03 2011 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 A15E721F8C9A for ; Wed, 24 Aug 2011 16:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.01 X-Spam-Level: X-Spam-Status: No, score=-106.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 twDs8NZiO-qA for ; Wed, 24 Aug 2011 16:20:02 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8908821F8C74 for ; Wed, 24 Aug 2011 16:20:02 -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 p7ONLCHh015736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Aug 2011 19:21:12 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Wed, 24 Aug 2011 19:21:04 -0400 Received: from mxhub30.corp.emc.com (mxhub30.corp.emc.com [128.221.47.159]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7ONL3jb024075 for ; Wed, 24 Aug 2011 19:21:03 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub30.corp.emc.com ([128.221.47.159]) with mapi; Wed, 24 Aug 2011 19:21:03 -0400 From: To: , , Date: Wed, 24 Aug 2011 19:21:01 -0400 Thread-Topic: Drafts of new iSCSI specs Thread-Index: AcxbbRUHmJTfdUS+ThepJzeK4W8f9wHRNjgAAACeb6A= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5E@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413C60@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058959DA1E@MX14A.corp.emc.com> <20110815170044.GE1978@vmware.com> <20110815170212.GF1978@vmware.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.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 Cc: abanta@vmware.com, khuang@vmware.com, ntomar@vmware.com, ksreekanti@vmware.com, paithal@vmware.com, ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs 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, 24 Aug 2011 23:20:03 -0000 Follow-up on this - I believe that we should stick with the two MAY-use req= uirements that were in RFC 3720. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= david.black@emc.com > Sent: Wednesday, August 24, 2011 7:10 PM > To: Banta, Andy (VMWare); storm@ietf.org > Cc: Banta, Andy (VMWare); Huang, Kun (VMWare); Tomar, Nagendra (VMWare); = Sreekanti, Kumar (VMWare); > Aithal, Prasanna (VMWare); Goyal, Neeraj (VMWare) > Subject: Re: [storm] Drafts of new iSCSI specs >=20 > Andy, >=20 > Many thanks for looking at the consolidated draft. >=20 > > In section 9.2, authentication is now required (MUST rather than MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is rarely > > used in production environments, and until there's some distributed > > key authentication method, I don't think many customers are going > > to be interested. >=20 > Indeed it does, good catch, thank you. >=20 > The offending text in the consolidated draft is: >=20 > 9.2. In-band Initiator-Target Authentication >=20 > During login, the target MUST authenticate the initiator and the > initiator MAY authenticate the target. >=20 > RFC 3720 had this text instead: >=20 > 8.2. In-band Initiator-Target Authentication >=20 > During login, the target MAY authenticate the initiator and the > initiator MAY authenticate the target. >=20 > 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-7= 786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: Andy Banta [mailto:abanta@vmware.com] > > Sent: Monday, August 15, 2011 1:02 PM > > To: Black, David; storm@ietf.org > > Cc: Banta, Andy (VMWare); Sreekanti, Kumar (VMWare); Huang, Kun (VMWare= ); Aithal, Prasanna (VMWare); > > Tomar, Nagendra (VMWare) > > Subject: Re: Drafts of new iSCSI specs > > > > On Thu, Aug 04, 2011 at 12:08:38AM -0400, Black, David wrote: > > > Andy, > > > > > > Can I interest you or anyone else at VMware in taking a look at these > > > specs - it > > > shouldn't involve a lot of time. I can extend the deadline for input > > > past VMworld if that helps. > > > > David, Folks, > > > > I'm the vSphere iSCSI development tech lead at VMware. > > > > I got a chance to look at the first one. A few comments: > > > > In section 9.2, authentication is now required (MUST rather than MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is rarely > > used in production environments, and until there's some distributed > > key authentication method, I don't think many customers are going > > to be interested. > > > > If this RFC gets approved as written, it will regularly be violated at > > this clause. > > > > We are interested in coming up with a pluggable authentication method, > > but I don't think that will change the spec in any way. > > > > I don't have any other specific comments based on the changes, but > > have not gone through the spec in detail. I'll take a look at the > > second spec in the next few days. > > > > Thanks, > > Andy > > banta@vmware.com > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Black, David > > > > Sent: Friday, July 15, 2011 2:01 AM > > > > To: Banta, Andy (VMWare) > > > > Cc: Black, David > > > > Subject: FW: Drafts of new iSCSI specs > > > > Importance: High > > > > > > > > Hi Andy, > > > > > > > > It was good to see you at EMC World, even if only briefly. > > > > > > > > I'm one of the co-chairs of the IETF storm (STORage Maintenance), w= here > > > > new drafts of the iSCSI specifications are close to completion (the= y're > > > > in Working Group Last Call). We're looking for review and feedback= from > > > > iSCSI implementers, and I was hoping that you could take a look at = this > > > > on behalf of ESX's iSCSI implementation. > > > > > > > > There are two new iSCSI drafts: > > > > > > > > (1) iSCSI Protocol (Consolidated), draft-ietf-storm-iscsi-cons-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ > > > > > > > > This draft consolidates several existing iSCSI RFCs, primarily RFC = 3720 > > > > and RFC 5048, and removes some unimplemented features - the result = should be > > > > backwards-compatible with existing implementations. As the draft i= s several > > > > hundred pages in length, I don't expect you to read it in its entir= ety, but > > > > could you look at this summary of what's been changed and see wheth= er it's > > > > reasonable?: > > > > > > > > 2.3. Summary of Changes > > > > > > > > 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the > > > > necessary editorial changes > > > > 2) iSCSIProtocolLevel is specified as "1" in section 13.24, = and > > > > added a related normative reference to [iSCSI-SAM] draft > > > > 3) Markers and related keys were removed > > > > 4) SPKM authentication and related keys were removed > > > > 5) Added a new section 13.25 on responding to obsoleted keys > > > > 6) Have explicitly allowed initiator+target implementations > > > > throughout the text > > > > 7) Clarified in section 4.2.7 that implementations SHOULD NOT > > > > rely on SLP-based discovery > > > > 8) Added UML diagrams, and related conventions in section 3 > > > > 9) FastAbort implementation is made a "SHOULD" requirement in > > > > section 4.2.3.4 from the previous "MUST" requirement. > > > > 10) Clarified in section 6.2 that validity of NotUnderstood > > > > response depends on iSCSIProtocolLevel > > > > > > > > (2) iSCSI SAM features, draft-ietf-storm-iscsi-sam-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ > > > > > > > > iSCSI was originally based on version 2 of the SCSI architecture, S= AM-2. > > > > This draft updates iSCSI to the current version of the SCSI archite= cture, > > > > SAM-5, by adding additional features, and a text key to negotiate t= heir > > > > usage, iSCSIProtocolLevel. The draft is only about 20 pages - plea= se take > > > > a look at it from an implementer's standpoint. > > > > > > > > Finally, if there's anything you wish the iSCSI RFCs said, or funct= ionality > > > > that you think should be removed, please say so. > > > > > > > > Your comments can be sent directly to the mailing list - storm@ietf= .org, > > > > or can be sent to me. Please identify yourself as a VMware iSCSI > > > > implementer in your comments. The Working Group Last Call on these= drafts > > > > runs through August 21st - please let me know when you think you co= uld > > > > have comments ready. > > > > > > > > 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-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From Paul_Koning@Dell.com Wed Aug 24 17:47:48 2011 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 CB48921F8B8B for ; Wed, 24 Aug 2011 17:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 uT3xxSdQCz+6 for ; Wed, 24 Aug 2011 17:47:47 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id B705921F8B9F for ; Wed, 24 Aug 2011 17:47:47 -0700 (PDT) X-Loopcount0: from 10.170.28.40 From: To: , , Date: Wed, 24 Aug 2011 19:48:56 -0500 Thread-Topic: Drafts of new iSCSI specs Thread-Index: AcxbbRUHmJTfdUS+ThepJzeK4W8f9wHRNjgAAACeb6AAAxa6oA== Message-ID: <09787EF419216C41A903FD14EE5506DD01530AAA23@AUSX7MCPC103.AMER.DELL.COM> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413C60@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058959DA1E@MX14A.corp.emc.com> <20110815170044.GE1978@vmware.com> <20110815170212.GF1978@vmware.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5E@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5E@MX14A.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 Cc: abanta@vmware.com, khuang@vmware.com, ntomar@vmware.com, ksreekanti@vmware.com, paithal@vmware.com, ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs 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, 25 Aug 2011 00:47:48 -0000 Yes, absolutely. paul -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of d= avid.black@emc.com Sent: Wednesday, August 24, 2011 7:21 PM To: david.black@emc.com; abanta@vmware.com; storm@ietf.org Cc: abanta@vmware.com; khuang@vmware.com; ntomar@vmware.com; ksreekanti@vmw= are.com; paithal@vmware.com; ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs Follow-up on this - I believe that we should stick with the two MAY-use req= uirements that were in RFC 3720. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf=20 > Of david.black@emc.com > Sent: Wednesday, August 24, 2011 7:10 PM > To: Banta, Andy (VMWare); storm@ietf.org > Cc: Banta, Andy (VMWare); Huang, Kun (VMWare); Tomar, Nagendra=20 > (VMWare); Sreekanti, Kumar (VMWare); Aithal, Prasanna (VMWare); Goyal,=20 > Neeraj (VMWare) > Subject: Re: [storm] Drafts of new iSCSI specs >=20 > Andy, >=20 > Many thanks for looking at the consolidated draft. >=20 > > In section 9.2, authentication is now required (MUST rather than MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is=20 > > rarely used in production environments, and until there's some=20 > > distributed key authentication method, I don't think many customers=20 > > are going to be interested. >=20 > Indeed it does, good catch, thank you. >=20 > The offending text in the consolidated draft is: >=20 > 9.2. In-band Initiator-Target Authentication >=20 > During login, the target MUST authenticate the initiator and the > initiator MAY authenticate the target. >=20 > RFC 3720 had this text instead: >=20 > 8.2. In-band Initiator-Target Authentication >=20 > During login, the target MAY authenticate the initiator and the > initiator MAY authenticate the target. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer EMC Corporation, 176 South St.,=20 > 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 > ---------------------------------------------------- >=20 > > -----Original Message----- > > From: Andy Banta [mailto:abanta@vmware.com] > > Sent: Monday, August 15, 2011 1:02 PM > > To: Black, David; storm@ietf.org > > Cc: Banta, Andy (VMWare); Sreekanti, Kumar (VMWare); Huang, Kun=20 > > (VMWare); Aithal, Prasanna (VMWare); Tomar, Nagendra (VMWare) > > Subject: Re: Drafts of new iSCSI specs > > > > On Thu, Aug 04, 2011 at 12:08:38AM -0400, Black, David wrote: > > > Andy, > > > > > > Can I interest you or anyone else at VMware in taking a look at=20 > > > these specs - it shouldn't involve a lot of time. I can extend=20 > > > the deadline for input past VMworld if that helps. > > > > David, Folks, > > > > I'm the vSphere iSCSI development tech lead at VMware. > > > > I got a chance to look at the first one. A few comments: > > > > In section 9.2, authentication is now required (MUST rather than MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is=20 > > rarely used in production environments, and until there's some=20 > > distributed key authentication method, I don't think many customers=20 > > are going to be interested. > > > > If this RFC gets approved as written, it will regularly be violated=20 > > at this clause. > > > > We are interested in coming up with a pluggable authentication=20 > > method, but I don't think that will change the spec in any way. > > > > I don't have any other specific comments based on the changes, but=20 > > have not gone through the spec in detail. I'll take a look at the=20 > > second spec in the next few days. > > > > Thanks, > > Andy > > banta@vmware.com > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Black, David > > > > Sent: Friday, July 15, 2011 2:01 AM > > > > To: Banta, Andy (VMWare) > > > > Cc: Black, David > > > > Subject: FW: Drafts of new iSCSI specs > > > > Importance: High > > > > > > > > Hi Andy, > > > > > > > > It was good to see you at EMC World, even if only briefly. > > > > > > > > I'm one of the co-chairs of the IETF storm (STORage=20 > > > > Maintenance), where new drafts of the iSCSI specifications are=20 > > > > close to completion (they're in Working Group Last Call). We're=20 > > > > looking for review and feedback from iSCSI implementers, and I=20 > > > > was hoping that you could take a look at this on behalf of ESX's iS= CSI implementation. > > > > > > > > There are two new iSCSI drafts: > > > > > > > > (1) iSCSI Protocol (Consolidated), draft-ietf-storm-iscsi-cons-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ > > > > > > > > This draft consolidates several existing iSCSI RFCs, primarily=20 > > > > RFC 3720 and RFC 5048, and removes some unimplemented features -=20 > > > > the result should be backwards-compatible with existing=20 > > > > implementations. As the draft is several hundred pages in=20 > > > > length, I don't expect you to read it in its entirety, but could=20 > > > > you look at this summary of what's been changed and see whether=20 > > > > it's > > > > reasonable?: > > > > > > > > 2.3. Summary of Changes > > > > > > > > 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made the > > > > necessary editorial changes > > > > 2) iSCSIProtocolLevel is specified as "1" in section 13.24, = and > > > > added a related normative reference to [iSCSI-SAM] draft > > > > 3) Markers and related keys were removed > > > > 4) SPKM authentication and related keys were removed > > > > 5) Added a new section 13.25 on responding to obsoleted keys > > > > 6) Have explicitly allowed initiator+target implementations > > > > throughout the text > > > > 7) Clarified in section 4.2.7 that implementations SHOULD NOT > > > > rely on SLP-based discovery > > > > 8) Added UML diagrams, and related conventions in section 3 > > > > 9) FastAbort implementation is made a "SHOULD" requirement in > > > > section 4.2.3.4 from the previous "MUST" requirement. > > > > 10) Clarified in section 6.2 that validity of NotUnderstood > > > > response depends on iSCSIProtocolLevel > > > > > > > > (2) iSCSI SAM features, draft-ietf-storm-iscsi-sam-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ > > > > > > > > iSCSI was originally based on version 2 of the SCSI architecture, S= AM-2. > > > > This draft updates iSCSI to the current version of the SCSI=20 > > > > architecture, SAM-5, by adding additional features, and a text=20 > > > > key to negotiate their usage, iSCSIProtocolLevel. The draft is=20 > > > > only about 20 pages - please take a look at it from an implementer'= s standpoint. > > > > > > > > Finally, if there's anything you wish the iSCSI RFCs said, or=20 > > > > functionality that you think should be removed, please say so. > > > > > > > > Your comments can be sent directly to the mailing list -=20 > > > > storm@ietf.org, or can be sent to me. Please identify yourself=20 > > > > as a VMware iSCSI implementer in your comments. The Working=20 > > > > Group Last Call on these drafts runs through August 21st -=20 > > > > please let me know when you think you could have comments ready. > > > > > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer EMC Corporation, 176=20 > > > > 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-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Thu Aug 25 06:04:45 2011 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 5143D21F8581 for ; Thu, 25 Aug 2011 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 ccyXnOFlxC2W for ; Thu, 25 Aug 2011 06:04:44 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9EC21F855B for ; Thu, 25 Aug 2011 06:04:44 -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 p7PD5teI028734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Aug 2011 09:05:55 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for ; Thu, 25 Aug 2011 09:05:48 -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 p7PD5mw0015600 for ; Thu, 25 Aug 2011 09:05:48 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub04.corp.emc.com ([10.254.141.106]) with mapi; Thu, 25 Aug 2011 09:05:47 -0400 From: To: Date: Thu, 25 Aug 2011 09:05:46 -0400 Thread-Topic: Nomcom 2011-2012: Call for Nominations Thread-Index: AcxhHGNYZWGdUQH8TRqiV2DChYnCwgCC0m8Q Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672CD7@MX14A.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [storm] FW: Nomcom 2011-2012: Call for Nominations 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, 25 Aug 2011 13:04:45 -0000 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of NomCom Chair Sent: Monday, August 22, 2011 6:32 PM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Call for Nominations=20 Hi All, The 2011-2012 Nominating committee is seeking nominations from now=20 until October 2, 2011. The list of open positions can be found at: https://www.ietf.org/group/nomcom/2011/ Nominations may be made directly on the NomCom 2011-2012 pages by=20 selecting the Nominate link at the top of the page. The URL for NomCom 2011-2012 pages is:=20 https://www.ietf.org/group/nomcom/2011/ Nominations may also be made by email to nomcom11@ietf.org. If you do so, please include the word "Nominate" in the Subject and=20 indicate in the email who is being nominated, their email address (to confirm acceptance of the nomination), and the position for which you=20 are making the nomination. If you wish to nominate someone via email=20 for more than one position, please use separate emails to do so. Self nomination is welcome.=20 NomCom 2011-2012 will follow the policy for "Open Disclosure of Willing=20 Nominees" described in RFC 5680. As stated in RFC 5680: "The list of=20 nominees willing to be considered for positions under review in the=20 current NomCom cycle is not confidential". Willing Nominees for each=20 position will be publicly listed. The public nominee list will be=20 updated at least once a week and possibly more often as nominations are=20 received. With the exception of publicly listing willing nominees, the=20 confidentiality requirements of RFC 3777 remain in effect. All=20 feedback and NomCom deliberations will remain confidential and not=20 disclosed.=20 Because the list of nominees this year is public, we will accept=20 feedback on the nominees starting August 23, 2011. Per RFC 5680, we=20 will accept feedback from the entire IETF community on all the nominees.=20 If you wish to provide anonymous feedback, the chair or any of the=20 members will be happy to handle this for you. The Nominating Committee=20 chair can be reached at nomcom-chair@ietf.org and the entire nominating=20 committee can be reached at nomcom11@ietf.org. The email addresses of=20 individual NomCom members is also on the NomCom 2011-2012 pages. In addition to nominations, the Nominating Committee is actively seeking community input on the jobs that need to be filled. We have received the job descriptions from the IAB, IESG, and IAOC and they can be found at: https://www.ietf.org/group/nomcom/2011/iab-requirements https://www.ietf.org/group/nomcom/2011/iesg-requirements https://www.ietf.org/group/nomcom/2011/iaoc-requirements However, we also need the community's views and input on the jobs=20 within each organization. If you have ideas on job responsibilities=20 (more, less, different), please let us know. Please send suggestions=20 and feedback to nomcom11@ietf.org.=20 Thank you, Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From Frederick.Knight@netapp.com Thu Aug 25 06:46:58 2011 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 141C721F877B for ; Thu, 25 Aug 2011 06:46:58 -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=[AWL=-0.000, 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 0uGzS5+Z-VZ1 for ; Thu, 25 Aug 2011 06:46:57 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA6021F8772 for ; Thu, 25 Aug 2011 06:46:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,280,1312182000"; d="scan'208,217";a="574373231" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 25 Aug 2011 06:48:10 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7PDm9jL023057 for ; Thu, 25 Aug 2011 06:48:10 -0700 (PDT) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Aug 2011 06:48:10 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Aug 2011 09:48:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: VEM= AXjW BMow C22U DAFV D7Ms EhSZ Ezzf FIuP GQ35 GSl7 G1yb HGUY KVr+ K534 L77q; 1; cwB0AG8AcgBtAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {AECA6F38-88AB-4638-89DA-32E07D2A7838}; ZgByAGUAZABlAHIAaQBjAGsALgBrAG4AaQBnAGgAdABAAG4AZQB0AGEAcABwAC4AYwBvAG0A; Thu, 25 Aug 2011 13:38:16 GMT; TgBlAHcAIABTAEEATQAgAGQAcgBhAGYAdAAgAHIAZQB2ACAAdABlAGMAaABuAGkAYwBhAGwAIABjAGwAYQByAGkAZgBpAGMAYQB0AGkAbwBuACAAcgBlAHEAdQBlAHMAdAA= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC632D.9C22E515" x-cr-puzzleid: {AECA6F38-88AB-4638-89DA-32E07D2A7838} Content-class: urn:content-classes:message Date: Thu, 25 Aug 2011 09:48:03 -0400 Message-ID: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C54@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New SAM draft rev technical clarification request Thread-Index: AQHecZ+Kt7z6HaE76BiqvFwLiEc/M5UFGLOwgANkI6CAAOmMAA== References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C54@MX14A.corp.emc.com> From: "Knight, Frederick" To: X-OriginalArrivalTime: 25 Aug 2011 13:48:03.0233 (UTC) FILETIME=[9C357910:01CC632D] Subject: [storm] New SAM draft rev technical clarification 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: Thu, 25 Aug 2011 13:46:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC632D.9C22E515 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have received 1 technical change request (actually, a request to replace silence with explicit text): =20 For the new QUERY TASK, there is no stated requirement for command connection allegiance. Without that requirement being stated , the QUERY TASK can go down any connection of the session. =20 BUT, other TMFs like ABORT TASK do have such a requirement. =20 Could a QUERY TASK (down a different connection) get to the target BEFORE the command that it was querying? While not harmful, it would be undesirable/unexpected by an initiator. =20 The request was to explicitly state that QUERY TASK has the same command connection allegiance requirements that are associated with ABORT TASK. =20 Does anyone have any issue with explicitly stating that QUERY TASK also requires command connection allegiance? =20 Fred ------_=_NextPart_001_01CC632D.9C22E515 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have received 1 = technical change request (actually, a request to replace silence with explicit = text):

 

For the new QUERY = TASK, there is no stated requirement for command connection allegiance.  Without that requirement being = stated , the QUERY TASK can go down any connection of the = session.

 

BUT, other TMFs like = ABORT TASK do have such a requirement.

 

Could a QUERY TASK = (down a different connection) get to the target BEFORE the command that it was querying?  While not = harmful, it would be undesirable/unexpected by an initiator.

 

The request was to = explicitly state that QUERY TASK has the same command connection allegiance = requirements that are associated with ABORT TASK.

 

Does anyone have any = issue with explicitly stating that QUERY TASK also requires command connection = allegiance?

 

        = ;        = Fred

------_=_NextPart_001_01CC632D.9C22E515-- From david.black@emc.com Thu Aug 25 14:53:53 2011 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 C4C3F21F8CA4 for ; Thu, 25 Aug 2011 14:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.251 X-Spam-Level: X-Spam-Status: No, score=-106.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, 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 z9OLdyACaYbw for ; Thu, 25 Aug 2011 14:53:53 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F2EED21F8CA0 for ; Thu, 25 Aug 2011 14:53:52 -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 p7PLt5DB021709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Aug 2011 17:55:05 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.129]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Thu, 25 Aug 2011 17:54:59 -0400 Received: from mxhub19.corp.emc.com (mxhub19.corp.emc.com [10.254.93.48]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7PLssF2023835 for ; Thu, 25 Aug 2011 17:54:54 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub19.corp.emc.com ([10.254.93.48]) with mapi; Thu, 25 Aug 2011 17:54:53 -0400 From: To: Date: Thu, 25 Aug 2011 17:54:51 -0400 Thread-Topic: WG Last Call comments on consolidated iSCSI draft Thread-Index: AcxjcZ2N3riNUbfqTsqnC/4OBaAg1Q== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.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] WG Last Call comments on consolidated iSCSI draft 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, 25 Aug 2011 21:53:53 -0000 I managed to review this draft, although I didn't look at the Appendixes, a= nd a side-by-side diff against RFC 3720 was very helpful. These comments are for discussion, and hence are with WG chair hat off. Major issues: [A] I think the "Updates:" field in the header is wrong. I believe that th= e RFC published from the consolidated draft should be the one base reference for iSCSI. Therefo= re it needs to obsolete RFCs 3720, 3980, 4850 and 5048. The RFC Editor's database tracks "obsolete= d by" relationships, so anyone looking for any of those RFCs will find a reference to the new RF= C. The presence of RFC 3721 as updated by this draft is correct. [B] As noted previously on the list, the "MUST" requirement for use of auth= entication in the first line of Section 9.2 needs to be changed to a "MAY" (as it was in RFC = 3720). Implementation of CHAP authentication is still a "MUST" requirement. [C] The IPsec RFC references have been updated to the new version of IPsec,= but we haven't done anything to RFC 3723, which still references an older version of IPsec= . I had been hoping to avoid updating RFC 3723, but input on what to do here is welcome.= One possibility is to add just enough text to the consolidated draft to update the IPsec re= quirements material in RFC 3723 to the new version of IPsec, allow implementation of the old ve= rsion, and avoid a 3723bis draft. Thoughts? [D] Section 10.2 contains a "SHOULD" requirement for ACA (Auto-Contingent A= llegiance) support. As ACA support in SCSI initiators is not common, I suggest weakening this t= o a MAY requirement. [E] I didn't see any text to specify that the SPKM keys MUST NOT generate "= NotUnderstood" responses. OTOH, as I believe SPKM support for iSCSI was never implemented, I don't be= lieve that this is a serious problem. Minor Concerns: [1] There are a number of statements of the form "See SCSI for ...". Each = of these should cite a relevant SCSI standard. [2] In Section 4.4.2, somehow "15 bytes" was changed to "14 bytes" in this = bullet item: - a text encoding as a hex-constant (see Section 5.1 "Text Format") of the ISID (for SCSI initiator port) or the portal group tag (for SCSI target port) including the initial 0X or 0x and the terminating null (14 bytes). I believe 15 bytes is correct, as that's "0x" (2 bytes) + 48-bit ISID in he= x (12 bytes) + a null (1 byte). A portal group tag is shorter (16 bits), so 15 bytes in t= he maximum length, but only 7 bytes will be used for the portal group tag case. [2] In Section 6.3, on p.99, remove at least the second sentence from this = paragraph (it's incorrect), or remove the entire paragraph: The initiator and target MAY want to negotiate iSCSI authentication parameters. Once this negotiation is completed, the channel is considered secure. [3] In section 6.3.2, change "security mechanism" to "authentication method= " in the first line of the first paragraph for clarity: The security exchange sets the security mechanism and authenticates the initiator user and the target to each other. The exchange proceeds according to the authentication method chosen in the negotiation phase and is conducted using the login requests' and responses' key=3Dvalue parameters. [4] Also in Section 6.3.2, remove "It should be noted that" from the last p= aragraph: It should be noted that the negotiation might also be directed by the target if the initiator does support security, but is not ready to direct the negotiation (propose options). Nits: There are an enormous number of section number cross-references that either= point to the wrong place (because they still need to be updated) or are incomplete (cont= ain no section number). In 11.4.5.3, 3rd paragraph: at theS CSI layer -> at the SCSI layer 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 Thu Aug 25 15:47:52 2011 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 9FA7F21F8BB1 for ; Thu, 25 Aug 2011 15:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.545 X-Spam-Level: X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 KXBSFnN-4XDc for ; Thu, 25 Aug 2011 15:47:52 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0554E21F8BB0 for ; Thu, 25 Aug 2011 15:47:51 -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 p7PMn4Xs011948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 25 Aug 2011 18:49:04 -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 ; Thu, 25 Aug 2011 18:48:56 -0400 Received: from mxhub25.corp.emc.com (mxhub25.corp.emc.com [10.254.110.181]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7PMmuvj029492 for ; Thu, 25 Aug 2011 18:48:56 -0400 Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub25.corp.emc.com ([10.254.110.181]) with mapi; Thu, 25 Aug 2011 18:48:56 -0400 From: To: Date: Thu, 25 Aug 2011 18:48:54 -0400 Thread-Topic: WG Last Call comments on iSCSI SAM features draft Thread-Index: AcxjeSqvnot3l3lGSCGpr+++JYemEw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6D0B@MX14A.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] WG Last Call comments on iSCSI SAM features draft 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, 25 Aug 2011 22:47:52 -0000 This is mostly with , as the technical contents of this dr= aft have been stable for a while now. The Updates header and the second paragraph of the Introduction need to be = removed. This draft and the iSCSI consolidated draft will be issued as RFC= s simultaneously, hence no Updates pointers are needed - each draft normati= vely references the other, and that suffices. The title of this draft needs to change to something more descriptive - onl= y people like Fred, Mallikarjun and yours truly who spend too much time on = SCSI know what SAM stands for. The filename should not change. As discussed in Quebec City and on the list, the specification of allowed v= alues needs to change for the new iSCSIProtocolLevel key, and there will be= some associated changes to allocation policy to get an expert review done = by a T10 reviewer before IESG approval of a document that allocates a value= for that key. Also in that text, a minor editorial nit - change "claim= ed by" to "corresponding to" in the following text: Negotiation of the iSCSIProtocolLevel key to a value claimed by an RFC indicates that both negotiating parties are compliant to the RFC in question, and agree to support the corresponding semantics on that iSCSI session. There should be a new version of the draft coming soon wi= th the above changes - it may be necessary to run a short second WG Last Ca= ll to make sure that we have the iSCSIProtocolLevel key specified correctly= , including its IANA Considerations. 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 cbm@chadalapaka.com Thu Aug 25 19:26:35 2011 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 133D121F85B9 for ; Thu, 25 Aug 2011 19:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599] 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 tZWUeNsZ2Q9F for ; Thu, 25 Aug 2011 19:26:34 -0700 (PDT) Received: from snt0-omc3-s28.snt0.hotmail.com (snt0-omc3-s28.snt0.hotmail.com [65.55.90.167]) by ietfa.amsl.com (Postfix) with ESMTP id E71E121F85B5 for ; Thu, 25 Aug 2011 19:26:33 -0700 (PDT) Received: from SNT131-DS15 ([65.55.90.136]) by snt0-omc3-s28.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 19:27:49 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: , , , References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413C60@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058959DA1E@MX14A.corp.emc.com> <20110815170044.GE1978@vmware.com> <20110815170212.GF1978@vmware.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5E@MX14A.corp.emc.com> <09787EF419216C41A903FD14EE5506DD01530AAA23@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: <09787EF419216C41A903FD14EE5506DD01530AAA23@AUSX7MCPC103.AMER.DELL.COM> Date: Thu, 25 Aug 2011 19:27:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH7v8ARP0hsqeEhD1s2AMfkEXJUyAJlXAxrAvnL6fgCRDjnowFagJh5AhvFOJcCkQOyOJRiVp7w Content-Language: en-us X-OriginalArrivalTime: 26 Aug 2011 02:27:49.0166 (UTC) FILETIME=[BF8AD4E0:01CC6397] Cc: abanta@vmware.com, khuang@vmware.com, ntomar@vmware.com, ksreekanti@vmware.com, paithal@vmware.com, ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs 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, 26 Aug 2011 02:26:35 -0000 Thanks Andy and David for surfacing the feedback. It is indeed a good catch. =20 I just searched through my available iSCSI email archives, and did not = see how/why this had changed. I do not know of an easy way to search = through ips and storm archives (and I know I lost some archives last year). = Please let this thread know if you have requested this change and would like to continue to argue for it, or have the email trail that resulted in this change. My default plan is to flip this back to MAY as proposed below = in the next revision. I was not tracking this as changed so it didn't even figure in my change list. Sorry about that. Mallikarjun -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Paul_Koning@Dell.com Sent: Wednesday, August 24, 2011 5:49 PM To: david.black@emc.com; abanta@vmware.com; storm@ietf.org Cc: abanta@vmware.com; khuang@vmware.com; ntomar@vmware.com; ksreekanti@vmware.com; paithal@vmware.com; ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs =20 Yes, absolutely. =20 paul =20 -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of david.black@emc.com Sent: Wednesday, August 24, 2011 7:21 PM To: david.black@emc.com; abanta@vmware.com; storm@ietf.org Cc: abanta@vmware.com; khuang@vmware.com; ntomar@vmware.com; ksreekanti@vmware.com; paithal@vmware.com; ngoyal@vmware.com Subject: Re: [storm] Drafts of new iSCSI specs =20 Follow-up on this - I believe that we should stick with the two = MAY-use requirements that were in RFC 3720. =20 Thanks, --David =20 =20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of david.black@emc.com > Sent: Wednesday, August 24, 2011 7:10 PM > To: Banta, Andy (VMWare); storm@ietf.org > Cc: Banta, Andy (VMWare); Huang, Kun (VMWare); Tomar, Nagendra > (VMWare); Sreekanti, Kumar (VMWare); Aithal, Prasanna (VMWare); Goyal, > Neeraj (VMWare) > Subject: Re: [storm] Drafts of new iSCSI specs > > Andy, > > Many thanks for looking at the consolidated draft. > > > In section 9.2, authentication is now required (MUST rather than = MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is > > rarely used in production environments, and until there's some > > distributed key authentication method, I don't think many = customers > > are going to be interested. > > Indeed it does, good catch, thank you. > > The offending text in the consolidated draft is: > > 9.2. In-band Initiator-Target Authentication > > During login, the target MUST authenticate the initiator and the > initiator MAY authenticate the target. > > RFC 3720 had this text instead: > > 8.2. In-band Initiator-Target Authentication > > During login, the target MAY authenticate the initiator and the > initiator MAY authenticate the target. > > 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-7786 > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > -----Original Message----- > > From: Andy Banta [mailto:abanta@vmware.com] > > Sent: Monday, August 15, 2011 1:02 PM > > To: Black, David; storm@ietf.org > > Cc: Banta, Andy (VMWare); Sreekanti, Kumar (VMWare); Huang, Kun > > (VMWare); Aithal, Prasanna (VMWare); Tomar, Nagendra (VMWare) > > Subject: Re: Drafts of new iSCSI specs > > > > On Thu, Aug 04, 2011 at 12:08:38AM -0400, Black, David wrote: > > > Andy, > > > > > > Can I interest you or anyone else at VMware in taking a look at > > > these specs - it shouldn't involve a lot of time. I can extend > > > the deadline for input past VMworld if that helps. > > > > David, Folks, > > > > I'm the vSphere iSCSI development tech lead at VMware. > > > > I got a chance to look at the first one. A few comments: > > > > In section 9.2, authentication is now required (MUST rather than = MAY). > > I'm quite sure this isn't going to fly with everyone. CHAP is > > rarely used in production environments, and until there's some > > distributed key authentication method, I don't think many = customers > > are going to be interested. > > > > If this RFC gets approved as written, it will regularly be = violated > > at this clause. > > > > We are interested in coming up with a pluggable authentication > > method, but I don't think that will change the spec in any way. > > > > I don't have any other specific comments based on the changes, but > > have not gone through the spec in detail. I'll take a look at the > > second spec in the next few days. > > > > Thanks, > > Andy > > banta@vmware.com > > > > > Thanks, > > > --David > > > > > > > -----Original Message----- > > > > From: Black, David > > > > Sent: Friday, July 15, 2011 2:01 AM > > > > To: Banta, Andy (VMWare) > > > > Cc: Black, David > > > > Subject: FW: Drafts of new iSCSI specs > > > > Importance: High > > > > > > > > Hi Andy, > > > > > > > > It was good to see you at EMC World, even if only briefly. > > > > > > > > I'm one of the co-chairs of the IETF storm (STORage > > > > Maintenance), where new drafts of the iSCSI specifications are > > > > close to completion (they're in Working Group Last Call). = We're > > > > looking for review and feedback from iSCSI implementers, and I > > > > was hoping that you could take a look at this on behalf of = ESX's iSCSI implementation. > > > > > > > > There are two new iSCSI drafts: > > > > > > > > (1) iSCSI Protocol (Consolidated), = draft-ietf-storm-iscsi-cons-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ > > > > > > > > This draft consolidates several existing iSCSI RFCs, primarily > > > > RFC 3720 and RFC 5048, and removes some unimplemented features - > > > > the result should be backwards-compatible with existing > > > > implementations. As the draft is several hundred pages in > > > > length, I don't expect you to read it in its entirety, but = could > > > > you look at this summary of what's been changed and see = whether > > > > it's > > > > reasonable?: > > > > > > > > 2.3. Summary of Changes > > > > > > > > 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and = made the > > > > necessary editorial changes > > > > 2) iSCSIProtocolLevel is specified as "1" in section = 13.24, and > > > > added a related normative reference to [iSCSI-SAM] draft > > > > 3) Markers and related keys were removed > > > > 4) SPKM authentication and related keys were removed > > > > 5) Added a new section 13.25 on responding to obsoleted keys > > > > 6) Have explicitly allowed initiator+target = implementations > > > > throughout the text > > > > 7) Clarified in section 4.2.7 that implementations SHOULD = NOT > > > > rely on SLP-based discovery > > > > 8) Added UML diagrams, and related conventions in section = 3 > > > > 9) FastAbort implementation is made a "SHOULD" = requirement in > > > > section 4.2.3.4 from the previous "MUST" requirement. > > > > 10) Clarified in section 6.2 that validity of NotUnderstood > > > > response depends on iSCSIProtocolLevel > > > > > > > > (2) iSCSI SAM features, draft-ietf-storm-iscsi-sam-03 > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ > > > > > > > > iSCSI was originally based on version 2 of the SCSI = architecture, SAM-2. > > > > This draft updates iSCSI to the current version of the SCSI > > > > architecture, SAM-5, by adding additional features, and a text > > > > key to negotiate their usage, iSCSIProtocolLevel. The draft = is > > > > only about 20 pages - please take a look at it from an implementer's standpoint. > > > > > > > > Finally, if there's anything you wish the iSCSI RFCs said, or > > > > functionality that you think should be removed, please say so. > > > > > > > > Your comments can be sent directly to the mailing list - > > > > storm@ietf.org, or can be sent to me. Please identify = yourself > > > > as a VMware iSCSI implementer in your comments. The Working > > > > Group Last Call on these drafts runs through August 21st - > > > > please let me know when you think you could have comments ready. > > > > > > > > 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-7786 > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) = 394-7754 > > > > ---------------------------------------------------- > > > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm =20 _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From Frederick.Knight@netapp.com Fri Aug 26 05:50:18 2011 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 39C6621F8B56 for ; Fri, 26 Aug 2011 05:50:18 -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=[AWL=0.000, 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 vvvsQxjRuKJV for ; Fri, 26 Aug 2011 05:50:17 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id BA32221F8B51 for ; Fri, 26 Aug 2011 05:50:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,285,1312182000"; d="scan'208";a="574842679" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 26 Aug 2011 05:51:34 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p7QCpXXs001374; Fri, 26 Aug 2011 05:51:34 -0700 (PDT) Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Aug 2011 05:51:27 -0700 Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Aug 2011 08:51:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Aug 2011 08:51:23 -0400 Message-ID: In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [storm] WG Last Call comments on consolidated iSCSI draft Thread-Index: AcxjcZ2N3riNUbfqTsqnC/4OBaAg1QAeazXw References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> From: "Knight, Frederick" To: X-OriginalArrivalTime: 26 Aug 2011 12:51:24.0118 (UTC) FILETIME=[DC976F60:01CC63EE] Cc: storm@ietf.org Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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, 26 Aug 2011 12:50:18 -0000 I disagree. 1) while not common, the hosts that use it, do need it; 2) the original 3720 text contains a SHOULD; and 3) there is no good reason for us to be weakening this statement. Fred Knight NetApp -----Original Message----- From: david.black@emc.com [mailto:david.black@emc.com]=20 Sent: Thursday, August 25, 2011 5:55 PM To: storm@ietf.org Subject: [storm] WG Last Call comments on consolidated iSCSI draft <...text removed...> [D] Section 10.2 contains a "SHOULD" requirement for ACA (Auto-Contingent Allegiance) support. As ACA support in SCSI initiators is not common, I suggest weakening this to a MAY requirement. From david.black@emc.com Fri Aug 26 08:06:41 2011 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 3372321F8B47 for ; Fri, 26 Aug 2011 08:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.087 X-Spam-Level: X-Spam-Status: No, score=-106.087 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 XkFR2eGUdSl6 for ; Fri, 26 Aug 2011 08:06:40 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 058E821F8B36 for ; Fri, 26 Aug 2011 08:06:39 -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 p7QF7sg7007317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Aug 2011 11:07:54 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 26 Aug 2011 11:07:46 -0400 Received: from mxhub22.corp.emc.com (mxhub22.corp.emc.com [128.221.56.108]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7QF7kTg009852; Fri, 26 Aug 2011 11:07:46 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub22.corp.emc.com ([128.221.56.108]) with mapi; Fri, 26 Aug 2011 11:07:46 -0400 From: To: , Date: Fri, 26 Aug 2011 11:07:44 -0400 Thread-Topic: [storm] Drafts of new iSCSI specs Thread-Index: AQH7v8ARP0hsqeEhD1s2AMfkEXJUyAJlXAxrAvnL6fgCRDjnowFagJh5AhvFOJcCkQOyOJRiVp7wgADUVeA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B12FDE2@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E0589413C60@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058959DA1E@MX14A.corp.emc.com> <20110815170044.GE1978@vmware.com> <20110815170212.GF1978@vmware.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C59@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E0589672C5E@MX14A.corp.emc.com> <09787EF419216C41A903FD14EE5506DD01530AAA23@AUSX7MCPC103.AMER.DELL.COM> In-Reply-To: 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] Drafts of new iSCSI specs 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, 26 Aug 2011 15:06:41 -0000 I do not recall making any such request - if I did (my memory's far from pe= rfect), I hereby withdraw that request ;-). Please change that back to "MAY". Thanks, --David > -----Original Message----- > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com] > Sent: Thursday, August 25, 2011 10:28 PM > To: Paul_Koning@Dell.com; Black, David; Banta, Andy (VMWare); storm@ietf.= org > Cc: Banta, Andy (VMWare); Huang, Kun (VMWare); Tomar, Nagendra (VMWare); = Sreekanti, Kumar (VMWare); > Aithal, Prasanna (VMWare); Goyal, Neeraj (VMWare) > Subject: RE: [storm] Drafts of new iSCSI specs >=20 > Thanks Andy and David for surfacing the feedback. It is indeed a good > catch. >=20 > I just searched through my available iSCSI email archives, and did not se= e > how/why this had changed. I do not know of an easy way to search through > ips and storm archives (and I know I lost some archives last year). Plea= se > let this thread know if you have requested this change and would like to > continue to argue for it, or have the email trail that resulted in this > change. My default plan is to flip this back to MAY as proposed below in > the next revision. >=20 > I was not tracking this as changed so it didn't even figure in my change > list. Sorry about that. >=20 > Mallikarjun >=20 >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of Paul_Koning@Dell.com > Sent: Wednesday, August 24, 2011 5:49 PM > To: david.black@emc.com; abanta@vmware.com; storm@ietf.org > Cc: abanta@vmware.com; khuang@vmware.com; ntomar@vmware.com; > ksreekanti@vmware.com; paithal@vmware.com; ngoyal@vmware.com > Subject: Re: [storm] Drafts of new iSCSI specs >=20 > Yes, absolutely. >=20 > paul >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of david.black@emc.com > Sent: Wednesday, August 24, 2011 7:21 PM > To: david.black@emc.com; abanta@vmware.com; storm@ietf.org > Cc: abanta@vmware.com; khuang@vmware.com; ntomar@vmware.com; > ksreekanti@vmware.com; paithal@vmware.com; ngoyal@vmware.com > Subject: Re: [storm] Drafts of new iSCSI specs >=20 > Follow-up on this - I believe that we should stick with the two MAY-use > requirements that were in RFC 3720. >=20 > Thanks, > --David >=20 >=20 > > -----Original Message----- > > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > Behalf > > Of david.black@emc.com > > Sent: Wednesday, August 24, 2011 7:10 PM > > To: Banta, Andy (VMWare); storm@ietf.org > > Cc: Banta, Andy (VMWare); Huang, Kun (VMWare); Tomar, Nagendra > > (VMWare); Sreekanti, Kumar (VMWare); Aithal, Prasanna (VMWare); > Goyal, > > Neeraj (VMWare) > > Subject: Re: [storm] Drafts of new iSCSI specs > > > > Andy, > > > > Many thanks for looking at the consolidated draft. > > > > > In section 9.2, authentication is now required (MUST rather than MA= Y). > > > I'm quite sure this isn't going to fly with everyone. CHAP is > > > rarely used in production environments, and until there's some > > > distributed key authentication method, I don't think many customers > > > are going to be interested. > > > > Indeed it does, good catch, thank you. > > > > The offending text in the consolidated draft is: > > > > 9.2. In-band Initiator-Target Authentication > > > > During login, the target MUST authenticate the initiator and the > > initiator MAY authenticate the target. > > > > RFC 3720 had this text instead: > > > > 8.2. In-band Initiator-Target Authentication > > > > During login, the target MAY authenticate the initiator and the > > initiator MAY authenticate the target. > > > > 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) 2= 93-7786 > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > -----Original Message----- > > > From: Andy Banta [mailto:abanta@vmware.com] > > > Sent: Monday, August 15, 2011 1:02 PM > > > To: Black, David; storm@ietf.org > > > Cc: Banta, Andy (VMWare); Sreekanti, Kumar (VMWare); Huang, Kun > > > (VMWare); Aithal, Prasanna (VMWare); Tomar, Nagendra (VMWare) > > > Subject: Re: Drafts of new iSCSI specs > > > > > > On Thu, Aug 04, 2011 at 12:08:38AM -0400, Black, David wrote: > > > > Andy, > > > > > > > > Can I interest you or anyone else at VMware in taking a look at > > > > these specs - it shouldn't involve a lot of time. I can extend > > > > the deadline for input past VMworld if that helps. > > > > > > David, Folks, > > > > > > I'm the vSphere iSCSI development tech lead at VMware. > > > > > > I got a chance to look at the first one. A few comments: > > > > > > In section 9.2, authentication is now required (MUST rather than MA= Y). > > > I'm quite sure this isn't going to fly with everyone. CHAP is > > > rarely used in production environments, and until there's some > > > distributed key authentication method, I don't think many customers > > > are going to be interested. > > > > > > If this RFC gets approved as written, it will regularly be violated > > > at this clause. > > > > > > We are interested in coming up with a pluggable authentication > > > method, but I don't think that will change the spec in any way. > > > > > > I don't have any other specific comments based on the changes, but > > > have not gone through the spec in detail. I'll take a look at the > > > second spec in the next few days. > > > > > > Thanks, > > > Andy > > > banta@vmware.com > > > > > > > Thanks, > > > > --David > > > > > > > > > -----Original Message----- > > > > > From: Black, David > > > > > Sent: Friday, July 15, 2011 2:01 AM > > > > > To: Banta, Andy (VMWare) > > > > > Cc: Black, David > > > > > Subject: FW: Drafts of new iSCSI specs > > > > > Importance: High > > > > > > > > > > Hi Andy, > > > > > > > > > > It was good to see you at EMC World, even if only briefly. > > > > > > > > > > I'm one of the co-chairs of the IETF storm (STORage > > > > > Maintenance), where new drafts of the iSCSI specifications are > > > > > close to completion (they're in Working Group Last Call). We'r= e > > > > > looking for review and feedback from iSCSI implementers, and I > > > > > was hoping that you could take a look at this on behalf of ESX'= s > iSCSI > implementation. > > > > > > > > > > There are two new iSCSI drafts: > > > > > > > > > > (1) iSCSI Protocol (Consolidated), draft-ietf-storm-iscsi-cons-= 03 > > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-cons/ > > > > > > > > > > This draft consolidates several existing iSCSI RFCs, primarily > > > > > RFC 3720 and RFC 5048, and removes some unimplemented > features - > > > > > the result should be backwards-compatible with existing > > > > > implementations. As the draft is several hundred pages in > > > > > length, I don't expect you to read it in its entirety, but coul= d > > > > > you look at this summary of what's been changed and see whether > > > > > it's > > > > > reasonable?: > > > > > > > > > > 2.3. Summary of Changes > > > > > > > > > > 1) Consolidated RFCs 3720, 3980, 4850 and 5048, and made > the > > > > > necessary editorial changes > > > > > 2) iSCSIProtocolLevel is specified as "1" in section 13.= 24, > and > > > > > added a related normative reference to [iSCSI-SAM] > draft > > > > > 3) Markers and related keys were removed > > > > > 4) SPKM authentication and related keys were removed > > > > > 5) Added a new section 13.25 on responding to obsoleted > keys > > > > > 6) Have explicitly allowed initiator+target implementati= ons > > > > > throughout the text > > > > > 7) Clarified in section 4.2.7 that implementations SHOULD = NOT > > > > > rely on SLP-based discovery > > > > > 8) Added UML diagrams, and related conventions in section = 3 > > > > > 9) FastAbort implementation is made a "SHOULD" requirement= in > > > > > section 4.2.3.4 from the previous "MUST" requirement. > > > > > 10) Clarified in section 6.2 that validity of NotUnderstood > > > > > response depends on iSCSIProtocolLevel > > > > > > > > > > (2) iSCSI SAM features, draft-ietf-storm-iscsi-sam-03 > > > > > http://datatracker.ietf.org/doc/draft-ietf-storm-iscsi-sam/ > > > > > > > > > > iSCSI was originally based on version 2 of the SCSI architectur= e, > SAM-2. > > > > > This draft updates iSCSI to the current version of the SCSI > > > > > architecture, SAM-5, by adding additional features, and a text > > > > > key to negotiate their usage, iSCSIProtocolLevel. The draft is > > > > > only about 20 pages - please take a look at it from an > implementer's > standpoint. > > > > > > > > > > Finally, if there's anything you wish the iSCSI RFCs said, or > > > > > functionality that you think should be removed, please say so. > > > > > > > > > > Your comments can be sent directly to the mailing list - > > > > > storm@ietf.org, or can be sent to me. Please identify yourself > > > > > as a VMware iSCSI implementer in your comments. The Working > > > > > Group Last Call on these drafts runs through August 21st - > > > > > please let me know when you think you could have comments > ready. > > > > > > > > > > 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-7786 > > > > > david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7= 754 > > > > > ---------------------------------------------------- > > > > > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm >=20 From internet-drafts@ietf.org Fri Aug 26 12:26:36 2011 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 B27F021F8CA6; Fri, 26 Aug 2011 12:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 pBbItL3dSaE5; Fri, 26 Aug 2011 12:26:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37421F8C7B; Fri, 26 Aug 2011 12:26:36 -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: 3.59 Message-ID: <20110826192636.32371.41116.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2011 12:26:36 -0700 Cc: storm@ietf.org Subject: [storm] I-D Action: draft-ietf-storm-iscsi-sam-04.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: Fri, 26 Aug 2011 19:26:36 -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 A= rchitecture Features Update Author(s) : Frederick Knight Mallikarjun Chadalapaka Filename : draft-ietf-storm-iscsi-sam-04.txt Pages : 1 Date : 2011-08-26 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 [draft-ietf-storm- iscsi-cons-xx] (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 [draft-ietf-storm- iscsi-cons-xx]. -------------------------------------------------------- RFC EDITORS NOTE: The above references to [draft-ietf-storm- iscsi-cons-xx] should reference the RFC number assigned to that document, and this note should be removed. -------------------------------------------------------- A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-storm-iscsi-sam-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-storm-iscsi-sam-04.txt From david.black@emc.com Sat Aug 27 15:35:25 2011 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 083D521F8B2F for ; Sat, 27 Aug 2011 15:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.098 X-Spam-Level: X-Spam-Status: No, score=-106.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 IoNeoxcPXeUM for ; Sat, 27 Aug 2011 15:35:24 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6514121F8B2A for ; Sat, 27 Aug 2011 15:35:23 -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 p7RMagsQ007125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2011 18:36:42 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 27 Aug 2011 18:36:31 -0400 Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com [128.221.56.102]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7RMaV6k011076; Sat, 27 Aug 2011 18:36:31 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub13.corp.emc.com ([128.221.56.102]) with mapi; Sat, 27 Aug 2011 18:36:31 -0400 From: To: Date: Sat, 27 Aug 2011 18:36:30 -0400 Thread-Topic: [storm] WG Last Call comments on consolidated iSCSI draft Thread-Index: AcxjcZ2N3riNUbfqTsqnC/4OBaAg1QAeazXwAEeC1YA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> In-Reply-To: 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] WG Last Call comments on consolidated iSCSI draft 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, 27 Aug 2011 22:35:25 -0000 In that case, let's at least get the explanation for the SHOULD right ;-). Here's a suggestion ... OLD ACA helps preserve ordered command execution in the presence of errors. As iSCSI can have many commands in-flight between initiator and target, iSCSI initiators and targets SHOULD support ACA. NEW Some SCSI initiator implementations use ACA to enforce ordered command execution during recovery from errors. In order to support error recovery in such SCSI initiators, iSCSI initiators and targets SHOULD support ACA. Thanks, --David > -----Original Message----- > From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] > Sent: Friday, August 26, 2011 8:51 AM > To: Black, David > Cc: storm@ietf.org > Subject: RE: [storm] WG Last Call comments on consolidated iSCSI draft >=20 > I disagree. >=20 > 1) while not common, the hosts that use it, do need it; > 2) the original 3720 text contains a SHOULD; and > 3) there is no good reason for us to be weakening this statement. >=20 > Fred Knight > NetApp >=20 > -----Original Message----- > From: david.black@emc.com [mailto:david.black@emc.com] > Sent: Thursday, August 25, 2011 5:55 PM > To: storm@ietf.org > Subject: [storm] WG Last Call comments on consolidated iSCSI draft >=20 > <...text removed...> >=20 > [D] Section 10.2 contains a "SHOULD" requirement for ACA > (Auto-Contingent Allegiance) support. > As ACA support in SCSI initiators is not common, I suggest weakening > this to a MAY requirement. >=20 >=20 From david.black@emc.com Sat Aug 27 15:36:27 2011 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 E65D621F8B73 for ; Sat, 27 Aug 2011 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.11 X-Spam-Level: X-Spam-Status: No, score=-106.11 tagged_above=-999 required=5 tests=[AWL=0.489, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 q+Wv8IS84INB for ; Sat, 27 Aug 2011 15:36:27 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 54A2621F8B72 for ; Sat, 27 Aug 2011 15:36: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 p7RMbhhn012805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 27 Aug 2011 18:37:43 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sat, 27 Aug 2011 18:37:31 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.221.56.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7RMbTCa026633; Sat, 27 Aug 2011 18:37:29 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub16.corp.emc.com ([128.221.56.105]) with mapi; Sat, 27 Aug 2011 18:37:29 -0400 From: To: , Date: Sat, 27 Aug 2011 18:37:28 -0400 Thread-Topic: [storm] draft-ietf-storm-mpa-peer-connect - review comment Thread-Index: Acxhm7WBvHRtWAkhQnauv2sp5ojSKQDbh6/A Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130027@MX14A.corp.emc.com> References: <95DEF288D9FA451B8C4BCA4ACAE1C6DA@davidPC> <4E53AFD2.50108@opengridcomputing.com> In-Reply-To: <4E53AFD2.50108@opengridcomputing.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: tatyana.e.nikolova@intel.com, storm@ietf.org, kumaras@chelsio.com, faisal.latif@intel.com Subject: Re: [storm] draft-ietf-storm-mpa-peer-connect - review 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: Sat, 27 Aug 2011 22:36:28 -0000 Network byte order is the usual default, but it doesn't hurt to say so. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= Steve Wise > Sent: Tuesday, August 23, 2011 9:49 AM > To: arkady kanevsky > Cc: Nikolova, Tatyana E; Latif, Faisal; Kumar A S; storm@ietf.org > Subject: [storm] draft-ietf-storm-mpa-peer-connect - review comment >=20 > Hey, >=20 > I believe the ORD/IRD fields in the MPAv2 messages need to be in Network > Byte Order. This is not mandated in the draft. >=20 > I also think there is an oversight in RFC 5044 with regard to the > PD_Length field in the MPAv1 messages. It should also be in Network > Byte Order, but I don't see this requirement anywhere in the RFC. >=20 > Or maybe NBO is a always assumed in IETF wire-protocol messages? >=20 >=20 > Steve. >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From roweber@ieee.org Sat Aug 27 19:17:28 2011 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 9D7D421F8B56 for ; Sat, 27 Aug 2011 19:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.797 X-Spam-Level: X-Spam-Status: No, score=-101.797 tagged_above=-999 required=5 tests=[AWL=0.803, 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 LvinjJK9o-mL for ; Sat, 27 Aug 2011 19:17:27 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by ietfa.amsl.com (Postfix) with ESMTP id 3293321F8B54 for ; Sat, 27 Aug 2011 19:17:27 -0700 (PDT) Received: from [192.168.1.5] ([unknown] [71.170.249.51]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LQM00M4K92UHX20@vms173003.mailsrvcs.net> for storm@ietf.org; Sat, 27 Aug 2011 21:18:35 -0500 (CDT) Message-id: <4E59A574.8040602@ieee.org> Date: Sat, 27 Aug 2011 21:18:28 -0500 From: Ralph Weber User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-version: 1.0 To: storm@ietf.org References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> In-reply-to: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 02:17:28 -0000 I am having a little bit of difficulty following the logic of the proposed new text. First it says that some initiator implementations use ACA (which implies that some do not). Then, it says that iSCSI initiators (presumably all iSCSI initiators) ... SHOULD support ACA. I can understand why initiators that need ACA SHOULD support it, but why should the others bear the burden? All the best, .Ralph On 8/27/2011 5:36 PM, david.black@emc.com wrote: > > > In that case, let's at least get the explanation for the SHOULD right ;-). > > Here's a suggestion ... > > OLD > ACA helps preserve ordered command execution in the presence of > errors. As iSCSI can have many commands in-flight between > initiator and target, iSCSI initiators and targets SHOULD support > ACA. > NEW > Some SCSI initiator implementations use ACA to enforce ordered > command execution during recovery from errors. In order to support > error recovery in such SCSI initiators, iSCSI initiators and targets > SHOULD support ACA. > > Thanks, > --David > >> -----Original Message----- >> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] >> Sent: Friday, August 26, 2011 8:51 AM >> To: Black, David >> Cc: storm@ietf.org >> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI draft >> >> I disagree. >> >> 1) while not common, the hosts that use it, do need it; >> 2) the original 3720 text contains a SHOULD; and >> 3) there is no good reason for us to be weakening this statement. >> >> Fred Knight >> NetApp >> >> -----Original Message----- >> From: david.black@emc.com [mailto:david.black@emc.com] >> Sent: Thursday, August 25, 2011 5:55 PM >> To: storm@ietf.org >> Subject: [storm] WG Last Call comments on consolidated iSCSI draft >> >> <...text removed...> >> >> [D] Section 10.2 contains a "SHOULD" requirement for ACA >> (Auto-Contingent Allegiance) support. >> As ACA support in SCSI initiators is not common, I suggest weakening >> this to a MAY requirement. >> >> > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > > From julian@satran.net Sat Aug 27 22:13:57 2011 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 5AC3421F8BAC for ; Sat, 27 Aug 2011 22:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RECV_BEZEQINT_B=0.763] 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 gfGu94ZPQVa8 for ; Sat, 27 Aug 2011 22:13:56 -0700 (PDT) Received: from eu1sys200aog113.obsmtp.com (eu1sys200aog113.obsmtp.com [207.126.144.135]) by ietfa.amsl.com (Postfix) with SMTP id 4191921F8BAA for ; Sat, 27 Aug 2011 22:13:55 -0700 (PDT) Received: from mail-ww0-f46.google.com ([74.125.82.46]) (using TLSv1) by eu1sys200aob113.postini.com ([207.126.147.11]) with SMTP ID DSNKTlnO1ZHwRuGF6Z3oqRBZq0Z7+upspkIC@postini.com; Sun, 28 Aug 2011 05:15:17 UTC Received: by mail-ww0-f46.google.com with SMTP id 7so4682010wwg.15 for ; Sat, 27 Aug 2011 22:15:01 -0700 (PDT) Received: by 10.216.167.5 with SMTP id h5mr3257106wel.96.1314508500847; Sat, 27 Aug 2011 22:15:00 -0700 (PDT) Received: from julo-mbp.xsignnet.local (mail.xsignnet.com [62.219.159.68]) by mx.google.com with ESMTPS id ej15sm2626169wbb.65.2011.08.27.22.14.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 27 Aug 2011 22:14:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Julian Satran In-Reply-To: <4E59A574.8040602@ieee.org> Date: Sun, 28 Aug 2011 08:14:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> To: Ralph Weber X-Mailer: Apple Mail (2.1244.3) Cc: storm@ietf.org Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 05:13:57 -0000 Ralph, I think you caught a nit. Your point is correct - WRT initiators. The SHOULD statement should refer to targets only. Initiators that are = not supporting ACA may have a hard time surviving in the same = environment with initiators that require and support ACA but will cause = no harm to those that require and support it. Julo On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: > I am having a little bit of difficulty following the logic of the > proposed new text. >=20 > First it says that some initiator implementations use ACA (which > implies that some do not). Then, it says that iSCSI initiators > (presumably all iSCSI initiators) ... SHOULD support ACA. >=20 > I can understand why initiators that need ACA SHOULD support it, > but why should the others bear the burden? >=20 > All the best, >=20 > .Ralph >=20 > On 8/27/2011 5:36 PM, david.black@emc.com wrote: >> >>=20 >> In that case, let's at least get the explanation for the SHOULD right = ;-). >>=20 >> Here's a suggestion ... >>=20 >> OLD >> ACA helps preserve ordered command execution in the presence of >> errors. As iSCSI can have many commands in-flight between >> initiator and target, iSCSI initiators and targets SHOULD support >> ACA. >> NEW >> Some SCSI initiator implementations use ACA to enforce ordered >> command execution during recovery from errors. In order to support >> error recovery in such SCSI initiators, iSCSI initiators and = targets >> SHOULD support ACA. >>=20 >> Thanks, >> --David >>=20 >>> -----Original Message----- >>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] >>> Sent: Friday, August 26, 2011 8:51 AM >>> To: Black, David >>> Cc: storm@ietf.org >>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI = draft >>>=20 >>> I disagree. >>>=20 >>> 1) while not common, the hosts that use it, do need it; >>> 2) the original 3720 text contains a SHOULD; and >>> 3) there is no good reason for us to be weakening this statement. >>>=20 >>> Fred Knight >>> NetApp >>>=20 >>> -----Original Message----- >>> From: david.black@emc.com [mailto:david.black@emc.com] >>> Sent: Thursday, August 25, 2011 5:55 PM >>> To: storm@ietf.org >>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft >>>=20 >>> <...text removed...> >>>=20 >>> [D] Section 10.2 contains a "SHOULD" requirement for ACA >>> (Auto-Contingent Allegiance) support. >>> As ACA support in SCSI initiators is not common, I suggest weakening >>> this to a MAY requirement. >>>=20 >>>=20 >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm >>=20 >>=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Sun Aug 28 10:26:35 2011 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 17F0E21F85F7 for ; Sun, 28 Aug 2011 10:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.122 X-Spam-Level: X-Spam-Status: No, score=-106.122 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zXHaAlJ6dx+q for ; Sun, 28 Aug 2011 10:26:34 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2D21E21F85F2 for ; Sun, 28 Aug 2011 10:26:33 -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 p7SHRraY022178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Aug 2011 13:27:53 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Sun, 28 Aug 2011 13:27:36 -0400 Received: from mxhub21.corp.emc.com (mxhub21.corp.emc.com [128.221.56.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7SHRYI8028996; Sun, 28 Aug 2011 13:27:34 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub21.corp.emc.com ([128.221.56.107]) with mapi; Sun, 28 Aug 2011 13:27:34 -0400 From: To: , Date: Sun, 28 Aug 2011 13:27:28 -0400 Thread-Topic: [storm] WG Last Call comments on consolidated iSCSI draft Thread-Index: AcxlQabr/vS5kl+3QAOJOFqzIl4QoAAZBo7Q Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> In-Reply-To: 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] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 17:26:35 -0000 I agree - second try at text: OLD ACA helps preserve ordered command execution in the presence of errors. As iSCSI can have many commands in-flight between initiator and target, iSCSI initiators and targets SHOULD support ACA. NEW Some SCSI initiators use ACA to enforce ordered command execution during error recovery, and hence iSCSI initiator implementations for those SCSI initiators need to support ACA. In order to support error recovery for these SCSI and iSCSI initiators, iSCSI targets SHOULD support ACA. As Ralph noted, an implementer of an iSCSI initiator that needs ACA will kn= ow it, or learn quickly when error recovery doesn't work right wrt the SCSI cl= ass driver :-), so the primary purpose of the SHOULD in this text is to tell target implementers about the need for ACA support. FWIW, this is a "SHOULD" and not a "MUST" because a target implementer may choose not to support initiators that use ACA - that absence of ACA support will be detected quickly at the SCSI level, as the first SCSI command that sets the NACA bit in the CONTROL byte in the CDB will get hit with a CHECK CONDITION for having done so. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= Julian Satran > Sent: Sunday, August 28, 2011 1:15 AM > To: Ralph Weber > Cc: storm@ietf.org > Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >=20 > Ralph, >=20 > I think you caught a nit. Your point is correct - WRT initiators. > The SHOULD statement should refer to targets only. Initiators that are n= ot supporting ACA may have a > hard time surviving in the same environment with initiators that require = and support ACA but will > cause no harm to those that require and support it. >=20 > Julo > On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: >=20 > > I am having a little bit of difficulty following the logic of the > > proposed new text. > > > > First it says that some initiator implementations use ACA (which > > implies that some do not). Then, it says that iSCSI initiators > > (presumably all iSCSI initiators) ... SHOULD support ACA. > > > > I can understand why initiators that need ACA SHOULD support it, > > but why should the others bear the burden? > > > > All the best, > > > > .Ralph > > > > On 8/27/2011 5:36 PM, david.black@emc.com wrote: > >> > >> > >> In that case, let's at least get the explanation for the SHOULD right = ;-). > >> > >> Here's a suggestion ... > >> > >> OLD > >> ACA helps preserve ordered command execution in the presence of > >> errors. As iSCSI can have many commands in-flight between > >> initiator and target, iSCSI initiators and targets SHOULD support > >> ACA. > >> NEW > >> Some SCSI initiator implementations use ACA to enforce ordered > >> command execution during recovery from errors. In order to support > >> error recovery in such SCSI initiators, iSCSI initiators and targets > >> SHOULD support ACA. > >> > >> Thanks, > >> --David > >> > >>> -----Original Message----- > >>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] > >>> Sent: Friday, August 26, 2011 8:51 AM > >>> To: Black, David > >>> Cc: storm@ietf.org > >>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI draf= t > >>> > >>> I disagree. > >>> > >>> 1) while not common, the hosts that use it, do need it; > >>> 2) the original 3720 text contains a SHOULD; and > >>> 3) there is no good reason for us to be weakening this statement. > >>> > >>> Fred Knight > >>> NetApp > >>> > >>> -----Original Message----- > >>> From: david.black@emc.com [mailto:david.black@emc.com] > >>> Sent: Thursday, August 25, 2011 5:55 PM > >>> To: storm@ietf.org > >>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft > >>> > >>> <...text removed...> > >>> > >>> [D] Section 10.2 contains a "SHOULD" requirement for ACA > >>> (Auto-Contingent Allegiance) support. > >>> As ACA support in SCSI initiators is not common, I suggest weakening > >>> this to a MAY requirement. > >>> > >>> > >> _______________________________________________ > >> storm mailing list > >> storm@ietf.org > >> https://www.ietf.org/mailman/listinfo/storm > >> > >> > > _______________________________________________ > > storm mailing list > > storm@ietf.org > > https://www.ietf.org/mailman/listinfo/storm >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From roweber@ieee.org Mon Aug 29 12:35:33 2011 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 DB39F21F8D14 for ; Mon, 29 Aug 2011 12:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.198 X-Spam-Level: X-Spam-Status: No, score=-102.198 tagged_above=-999 required=5 tests=[AWL=0.401, 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 y-l4G1YOQG4J for ; Mon, 29 Aug 2011 12:35:33 -0700 (PDT) Received: from vms173007pub.verizon.net (vms173007pub.verizon.net [206.46.173.7]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0321F8CEF for ; Mon, 29 Aug 2011 12:35:33 -0700 (PDT) Received: from [192.168.1.5] ([unknown] [71.170.249.51]) by vms173007.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LQP008ITFT2LQ40@vms173007.mailsrvcs.net> for storm@ietf.org; Mon, 29 Aug 2011 14:36:38 -0500 (CDT) Message-id: <4E5BEA43.5050404@ieee.org> Date: Mon, 29 Aug 2011 14:36:35 -0500 From: Ralph Weber User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-version: 1.0 To: storm@ietf.org References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> In-reply-to: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 19:35:34 -0000 A necessary nuance between Operating Systems and initiator products is missing in the rewrite. How about: Some operating systems depend on SCSI ACA to enforce ordered command execution during error recovery, and hence iSCSI initiator implementations for those operating systems need to support ACA. In order to support error recovery for these operating systems and iSCSI initiators, iSCSI targets SHOULD support ACA. All the best, .Ralph On 8/28/2011 12:27 PM, david.black@emc.com wrote: > I agree - second try at text: > > OLD > ACA helps preserve ordered command execution in the presence of > errors. As iSCSI can have many commands in-flight between > initiator and target, iSCSI initiators and targets SHOULD support > ACA. > NEW > Some SCSI initiators use ACA to enforce ordered command execution > during error recovery, and hence iSCSI initiator implementations > for those SCSI initiators need to support ACA. In order to support > error recovery for these SCSI and iSCSI initiators, iSCSI targets > SHOULD support ACA. > > As Ralph noted, an implementer of an iSCSI initiator that needs ACA will know > it, or learn quickly when error recovery doesn't work right wrt the SCSI class > driver :-), so the primary purpose of the SHOULD in this text is to tell > target implementers about the need for ACA support. > > FWIW, this is a "SHOULD" and not a "MUST" because a target implementer may > choose not to support initiators that use ACA - that absence of ACA support > will be detected quickly at the SCSI level, as the first SCSI command that > sets the NACA bit in the CONTROL byte in the CDB will get hit with a > CHECK CONDITION for having done so. > > Thanks, > --David > >> -----Original Message----- >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Julian Satran >> Sent: Sunday, August 28, 2011 1:15 AM >> To: Ralph Weber >> Cc: storm@ietf.org >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >> >> Ralph, >> >> I think you caught a nit. Your point is correct - WRT initiators. >> The SHOULD statement should refer to targets only. Initiators that are not supporting ACA may have a >> hard time surviving in the same environment with initiators that require and support ACA but will >> cause no harm to those that require and support it. >> >> Julo >> On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: >> >>> I am having a little bit of difficulty following the logic of the >>> proposed new text. >>> >>> First it says that some initiator implementations use ACA (which >>> implies that some do not). Then, it says that iSCSI initiators >>> (presumably all iSCSI initiators) ... SHOULD support ACA. >>> >>> I can understand why initiators that need ACA SHOULD support it, >>> but why should the others bear the burden? >>> >>> All the best, >>> >>> .Ralph >>> >>> On 8/27/2011 5:36 PM, david.black@emc.com wrote: >>>> >>>> >>>> In that case, let's at least get the explanation for the SHOULD right ;-). >>>> >>>> Here's a suggestion ... >>>> >>>> OLD >>>> ACA helps preserve ordered command execution in the presence of >>>> errors. As iSCSI can have many commands in-flight between >>>> initiator and target, iSCSI initiators and targets SHOULD support >>>> ACA. >>>> NEW >>>> Some SCSI initiator implementations use ACA to enforce ordered >>>> command execution during recovery from errors. In order to support >>>> error recovery in such SCSI initiators, iSCSI initiators and targets >>>> SHOULD support ACA. >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] >>>>> Sent: Friday, August 26, 2011 8:51 AM >>>>> To: Black, David >>>>> Cc: storm@ietf.org >>>>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI draft >>>>> >>>>> I disagree. >>>>> >>>>> 1) while not common, the hosts that use it, do need it; >>>>> 2) the original 3720 text contains a SHOULD; and >>>>> 3) there is no good reason for us to be weakening this statement. >>>>> >>>>> Fred Knight >>>>> NetApp >>>>> >>>>> -----Original Message----- >>>>> From: david.black@emc.com [mailto:david.black@emc.com] >>>>> Sent: Thursday, August 25, 2011 5:55 PM >>>>> To: storm@ietf.org >>>>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft >>>>> >>>>> <...text removed...> >>>>> >>>>> [D] Section 10.2 contains a "SHOULD" requirement for ACA >>>>> (Auto-Contingent Allegiance) support. >>>>> As ACA support in SCSI initiators is not common, I suggest weakening >>>>> this to a MAY requirement. >>>>> >>>>> >>>> _______________________________________________ >>>> storm mailing list >>>> storm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storm >>>> >>>> >>> _______________________________________________ >>> storm mailing list >>> storm@ietf.org >>> https://www.ietf.org/mailman/listinfo/storm >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm > > From wwwrun@ietfa.amsl.com Tue Aug 30 09:46:22 2011 Return-Path: X-Original-To: storm@ietf.org Delivered-To: storm@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 811FC21F89BA; Tue, 30 Aug 2011 09:46:22 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20110830164622.811FC21F89BA@ietfa.amsl.com> Date: Tue, 30 Aug 2011 09:46:22 -0700 (PDT) Cc: black_david@emc.com, storm@ietf.org Subject: [storm] WG Action: RECHARTER: STORage Maintenance (storm) 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 Aug 2011 16:46:22 -0000 The STORage Maintenance (storm) working group in the Transport Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. STORage Maintenance (storm) ---------------------------------------- Last updated: 2011-08-18 Current Status: Active Working Group Chairs: Tom Talpey David Black Transport Area Directors: Wesley Eddy David Harrington Transport Area Advisor: David Harrington Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/ Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior. List of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but the Working Group has decided not to advance it to Draft Standard status. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group has documented the deployed pre-standard use of this protocol number in RFC 6172, and IANA has updated the registry entry to reference RFC 6172. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. The Working Group has deprecated iFCP Address Translation mode in RFC 6172 and made the corresponding changes to the iFCP MIB (originally RFC 4369) in RFC 6173. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. (7) RDMA Protocol: Experience with the rddp (iWARP) RDMA Protocol (RFC 5040) suggests that some minor extensions are needed, specifically, the addition of immediate data support and remote atomic operations. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones: Done First version of combined iSCSI draft (3720bis) Done First version of iSCSI SAM-4 (and other) new features draft Done First version of RDDP MPA startup change draft Done First version of FCIP protocol number and iFCP Address Translation mode draft Done First version of iSER update draft Done Working Group Last Call on FCIP protocol number and iFCP address change draft Done Working Group Last Call on RDDP MPA startup change draft Done Functionally complete iSCSI SAM-4 (and other) new features draft Done Working Group decision on whether to seek Draft Standard RFC status for the combined iSCSI draft (3720bis). [Note: decision may be made significantly before this date.] Jul 2011 Working Group Last Call on combined iSCSI draft (3720bis) plus iSCSI SAM-4 (and other) new features draft Done First version of iSCSI MIB update draft Sep 2011 Working Group Last Call on iSCSI MIB update draft Oct 2011 Working Group Last Call on iSER update draft Feb 2012 Working Group Last Call on RDMA Protocol Extensions draft From cbm@chadalapaka.com Tue Aug 30 10:47:17 2011 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 B67A521F8DA2 for ; Tue, 30 Aug 2011 10:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599] 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 ua3Z1wfggBWk for ; Tue, 30 Aug 2011 10:47:17 -0700 (PDT) Received: from snt0-omc1-s12.snt0.hotmail.com (snt0-omc1-s12.snt0.hotmail.com [65.55.90.23]) by ietfa.amsl.com (Postfix) with ESMTP id D59A121F8D98 for ; Tue, 30 Aug 2011 10:47:16 -0700 (PDT) Received: from SNT131-DS21 ([65.55.90.9]) by snt0-omc1-s12.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Aug 2011 10:48:45 -0700 X-Originating-IP: [131.107.0.94] X-Originating-Email: [cbm@chadalapaka.com] Message-ID: From: Mallikarjun Chadalapaka To: References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> <4E5BEA43.5050404@ieee.org> In-Reply-To: <4E5BEA43.5050404@ieee.org> Date: Tue, 30 Aug 2011 10:48:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJAVYkkLWavS0oHYUWDAKL4T48HuQDIn2D4AdO1VzkC8WT0eQIKnvcMAoUTTtIBQStMhJPy10yA Content-Language: en-us X-OriginalArrivalTime: 30 Aug 2011 17:48:45.0203 (UTC) FILETIME=[105BF630:01CC673D] Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 17:47:17 -0000 I am catching up on this thread after a vacation. I agree in general with the consensus on this thread that we should leave ACA as SHOULD. Specifically, I like David's last rewrite, which succinctly states the rationale in SCSI initiator terms, as appropriate for this spec. I plan to get that into the next rev. David, thanks for your Last Call review. I will address your all other comments as well in the next revision. Thanks. Mallikarjun -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Ralph Weber Sent: Monday, August 29, 2011 12:37 PM To: storm@ietf.org Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft A necessary nuance between Operating Systems and initiator products is missing in the rewrite. How about: Some operating systems depend on SCSI ACA to enforce ordered command execution during error recovery, and hence iSCSI initiator implementations for those operating systems need to support ACA. In order to support error recovery for these operating systems and iSCSI initiators, iSCSI targets SHOULD support ACA. All the best, .Ralph On 8/28/2011 12:27 PM, david.black@emc.com wrote: > I agree - second try at text: > > OLD > ACA helps preserve ordered command execution in the presence of > errors. As iSCSI can have many commands in-flight between > initiator and target, iSCSI initiators and targets SHOULD support > ACA. > NEW > Some SCSI initiators use ACA to enforce ordered command execution > during error recovery, and hence iSCSI initiator implementations > for those SCSI initiators need to support ACA. In order to support > error recovery for these SCSI and iSCSI initiators, iSCSI targets > SHOULD support ACA. > > As Ralph noted, an implementer of an iSCSI initiator that needs ACA > will know it, or learn quickly when error recovery doesn't work right > wrt the SCSI class driver :-), so the primary purpose of the SHOULD in > this text is to tell target implementers about the need for ACA support. > > FWIW, this is a "SHOULD" and not a "MUST" because a target implementer > may choose not to support initiators that use ACA - that absence of > ACA support will be detected quickly at the SCSI level, as the first > SCSI command that sets the NACA bit in the CONTROL byte in the CDB > will get hit with a CHECK CONDITION for having done so. > > Thanks, > --David > >> -----Original Message----- >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On >> Behalf Of Julian Satran >> Sent: Sunday, August 28, 2011 1:15 AM >> To: Ralph Weber >> Cc: storm@ietf.org >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI >> draft >> >> Ralph, >> >> I think you caught a nit. Your point is correct - WRT initiators. >> The SHOULD statement should refer to targets only. Initiators that >> are not supporting ACA may have a hard time surviving in the same >> environment with initiators that require and support ACA but will cause no harm to those that require and support it. >> >> Julo >> On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: >> >>> I am having a little bit of difficulty following the logic of the >>> proposed new text. >>> >>> First it says that some initiator implementations use ACA (which >>> implies that some do not). Then, it says that iSCSI initiators >>> (presumably all iSCSI initiators) ... SHOULD support ACA. >>> >>> I can understand why initiators that need ACA SHOULD support it, but >>> why should the others bear the burden? >>> >>> All the best, >>> >>> .Ralph >>> >>> On 8/27/2011 5:36 PM, david.black@emc.com wrote: >>>> >>>> >>>> In that case, let's at least get the explanation for the SHOULD right ;-). >>>> >>>> Here's a suggestion ... >>>> >>>> OLD >>>> ACA helps preserve ordered command execution in the presence of >>>> errors. As iSCSI can have many commands in-flight between >>>> initiator and target, iSCSI initiators and targets SHOULD support >>>> ACA. >>>> NEW >>>> Some SCSI initiator implementations use ACA to enforce ordered >>>> command execution during recovery from errors. In order to support >>>> error recovery in such SCSI initiators, iSCSI initiators and targets >>>> SHOULD support ACA. >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] >>>>> Sent: Friday, August 26, 2011 8:51 AM >>>>> To: Black, David >>>>> Cc: storm@ietf.org >>>>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI >>>>> draft >>>>> >>>>> I disagree. >>>>> >>>>> 1) while not common, the hosts that use it, do need it; >>>>> 2) the original 3720 text contains a SHOULD; and >>>>> 3) there is no good reason for us to be weakening this statement. >>>>> >>>>> Fred Knight >>>>> NetApp >>>>> >>>>> -----Original Message----- >>>>> From: david.black@emc.com [mailto:david.black@emc.com] >>>>> Sent: Thursday, August 25, 2011 5:55 PM >>>>> To: storm@ietf.org >>>>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft >>>>> >>>>> <...text removed...> >>>>> >>>>> [D] Section 10.2 contains a "SHOULD" requirement for ACA >>>>> (Auto-Contingent Allegiance) support. >>>>> As ACA support in SCSI initiators is not common, I suggest >>>>> weakening this to a MAY requirement. >>>>> >>>>> >>>> _______________________________________________ >>>> storm mailing list >>>> storm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/storm >>>> >>>> >>> _______________________________________________ >>> storm mailing list >>> storm@ietf.org >>> https://www.ietf.org/mailman/listinfo/storm >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm > > _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Tue Aug 30 16:08:21 2011 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 0A44A21F8EA7 for ; Tue, 30 Aug 2011 16:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.549 X-Spam-Level: X-Spam-Status: No, score=-106.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 kljw5Q6gRUL1 for ; Tue, 30 Aug 2011 16:08:20 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 129A921F8EA5 for ; Tue, 30 Aug 2011 16:08:19 -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 p7UN9keW021732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Aug 2011 19:09:46 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Tue, 30 Aug 2011 19:09:38 -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 p7UN9Zos005045; Tue, 30 Aug 2011 19:09:35 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Tue, 30 Aug 2011 19:09:35 -0400 From: To: , Date: Tue, 30 Aug 2011 19:09:33 -0400 Thread-Topic: [storm] WG Last Call comments on consolidated iSCSI draft Thread-Index: AQJAVYkkLWavS0oHYUWDAKL4T48HuQDIn2D4AdO1VzkC8WT0eQIKnvcMAoUTTtIBQStMhJPy10yAgABb6vA= Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130618@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> <4E5BEA43.5050404@ieee.org> In-Reply-To: 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] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 23:08:21 -0000 I like Ralph's suggestion to include a mention of operating systems in the = new test, but I have some further tweaks to his words to suggest: SCSI initiator functionality in some operating systems depends on ACA to en= force ordered command execution during error recovery, and hence iSCSI initiator implementations for those operating systems need to support ACA. In order to support error recovery for these operating systems and iSCSI initiators, iSCSI targets SHOULD support ACA. Thanks, --David > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of= Mallikarjun Chadalapaka > Sent: Tuesday, August 30, 2011 1:49 PM > To: storm@ietf.org > Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >=20 > I am catching up on this thread after a vacation. >=20 > I agree in general with the consensus on this thread that we should leave > ACA as SHOULD. >=20 > Specifically, I like David's last rewrite, which succinctly states the > rationale in SCSI initiator terms, as appropriate for this spec. I plan = to > get that into the next rev. >=20 > David, thanks for your Last Call review. I will address your all other > comments as well in the next revision. >=20 > Thanks. >=20 > Mallikarjun >=20 >=20 >=20 > -----Original Message----- > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf > Of Ralph Weber > Sent: Monday, August 29, 2011 12:37 PM > To: storm@ietf.org > Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >=20 > A necessary nuance between Operating Systems and initiator products is > missing in the rewrite. How about: >=20 > Some operating systems depend on SCSI ACA to enforce ordered command > execution during error recovery, and hence iSCSI initiator implementati= ons > for those operating systems need to support ACA. In order to support > error > recovery for these operating systems and iSCSI initiators, iSCSI target= s > SHOULD support ACA. >=20 > All the best, >=20 > .Ralph >=20 > On 8/28/2011 12:27 PM, david.black@emc.com wrote: > > I agree - second try at text: > > > > OLD > > ACA helps preserve ordered command execution in the presence of > > errors. As iSCSI can have many commands in-flight between > > initiator and target, iSCSI initiators and targets SHOULD support > > ACA. > > NEW > > Some SCSI initiators use ACA to enforce ordered command execution > > during error recovery, and hence iSCSI initiator implementations > > for those SCSI initiators need to support ACA. In order to suppor= t > > error recovery for these SCSI and iSCSI initiators, iSCSI targets > > SHOULD support ACA. > > > > As Ralph noted, an implementer of an iSCSI initiator that needs ACA > > will know it, or learn quickly when error recovery doesn't work right > > wrt the SCSI class driver :-), so the primary purpose of the SHOULD i= n > > this text is to tell target implementers about the need for ACA suppo= rt. > > > > FWIW, this is a "SHOULD" and not a "MUST" because a target > implementer > > may choose not to support initiators that use ACA - that absence of > > ACA support will be detected quickly at the SCSI level, as the first > > SCSI command that sets the NACA bit in the CONTROL byte in the CDB > > will get hit with a CHECK CONDITION for having done so. > > > > Thanks, > > --David > > > >> -----Original Message----- > >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On > >> Behalf Of Julian Satran > >> Sent: Sunday, August 28, 2011 1:15 AM > >> To: Ralph Weber > >> Cc: storm@ietf.org > >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI > >> draft > >> > >> Ralph, > >> > >> I think you caught a nit. Your point is correct - WRT initiators. > >> The SHOULD statement should refer to targets only. Initiators that > >> are not supporting ACA may have a hard time surviving in the same > >> environment with initiators that require and support ACA but will > cause > no harm to those that require and support it. > >> > >> Julo > >> On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: > >> > >>> I am having a little bit of difficulty following the logic of the > >>> proposed new text. > >>> > >>> First it says that some initiator implementations use ACA (which > >>> implies that some do not). Then, it says that iSCSI initiators > >>> (presumably all iSCSI initiators) ... SHOULD support ACA. > >>> > >>> I can understand why initiators that need ACA SHOULD support it, bu= t > >>> why should the others bear the burden? > >>> > >>> All the best, > >>> > >>> .Ralph > >>> > >>> On 8/27/2011 5:36 PM, david.black@emc.com wrote: > >>>> > >>>> > >>>> In that case, let's at least get the explanation for the SHOULD ri= ght > ;-). > >>>> > >>>> Here's a suggestion ... > >>>> > >>>> OLD > >>>> ACA helps preserve ordered command execution in the presence of > >>>> errors. As iSCSI can have many commands in-flight between > >>>> initiator and target, iSCSI initiators and targets SHOULD suppo= rt > >>>> ACA. > >>>> NEW > >>>> Some SCSI initiator implementations use ACA to enforce ordered > >>>> command execution during recovery from errors. In order to > support > >>>> error recovery in such SCSI initiators, iSCSI initiators and > targets > >>>> SHOULD support ACA. > >>>> > >>>> Thanks, > >>>> --David > >>>> > >>>>> -----Original Message----- > >>>>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] > >>>>> Sent: Friday, August 26, 2011 8:51 AM > >>>>> To: Black, David > >>>>> Cc: storm@ietf.org > >>>>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI > >>>>> draft > >>>>> > >>>>> I disagree. > >>>>> > >>>>> 1) while not common, the hosts that use it, do need it; > >>>>> 2) the original 3720 text contains a SHOULD; and > >>>>> 3) there is no good reason for us to be weakening this statement. > >>>>> > >>>>> Fred Knight > >>>>> NetApp > >>>>> > >>>>> -----Original Message----- > >>>>> From: david.black@emc.com [mailto:david.black@emc.com] > >>>>> Sent: Thursday, August 25, 2011 5:55 PM > >>>>> To: storm@ietf.org > >>>>> Subject: [storm] WG Last Call comments on consolidated iSCSI draf= t > >>>>> > >>>>> <...text removed...> > >>>>> > >>>>> [D] Section 10.2 contains a "SHOULD" requirement for ACA > >>>>> (Auto-Contingent Allegiance) support. > >>>>> As ACA support in SCSI initiators is not common, I suggest > >>>>> weakening this to a MAY requirement. > >>>>> > >>>>> > >>>> _______________________________________________ > >>>> storm mailing list > >>>> storm@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/storm > >>>> > >>>> > >>> _______________________________________________ > >>> storm mailing list > >>> storm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/storm > >> _______________________________________________ > >> storm mailing list > >> storm@ietf.org > >> https://www.ietf.org/mailman/listinfo/storm > > > > > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm >=20 > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm From david.black@emc.com Tue Aug 30 16:12:29 2011 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 679FD21F8B33 for ; Tue, 30 Aug 2011 16:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.143 X-Spam-Level: X-Spam-Status: No, score=-106.143 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 OIiqOh4n824G for ; Tue, 30 Aug 2011 16:12:28 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id DA61221F8B32 for ; Tue, 30 Aug 2011 16:12:27 -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 p7UNDuL2025889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Aug 2011 19:13:56 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor) for ; Tue, 30 Aug 2011 19:13:42 -0400 Received: from mxhub31.corp.emc.com (mxhub31.corp.emc.com [128.221.47.160]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p7UNDflt013562 for ; Tue, 30 Aug 2011 19:13:41 -0400 Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub31.corp.emc.com ([128.221.47.160]) with mapi; Tue, 30 Aug 2011 19:13:41 -0400 From: To: Date: Tue, 30 Aug 2011 19:13:39 -0400 Thread-Topic: [storm] WG Action: RECHARTER: STORage Maintenance (storm) Thread-Index: AcxnNJuVSC4djDVRQruzZle7AvFxMAANWcyA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130619@MX14A.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] FW: WG Action: RECHARTER: STORage Maintenance (storm) 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 Aug 2011 23:12:29 -0000 This new WG charter adds the RDMAP extensions work discussed in Quebec City= , plus updates the description to reflect the WG's accomplishments to date. FYI, --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 ---------------------------------------------------- -----Original Message----- From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of I= ESG Secretary Sent: Tuesday, August 30, 2011 12:46 PM To: IETF Announcement list Cc: Black, David; storm@ietf.org Subject: [storm] WG Action: RECHARTER: STORage Maintenance (storm) The STORage Maintenance (storm) working group in the Transport Area of=20 the IETF has been rechartered. For additional information, please=20 contact the Area Directors or the working group Chairs. STORage Maintenance (storm) ---------------------------------------- Last updated: 2011-08-18 Current Status: Active Working Group Chairs: Tom Talpey David Black Transport Area Directors: Wesley Eddy David Harrington Transport Area Advisor: David Harrington Mailing Lists: General Discussion: storm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/storm Archive: http://www.ietf.org/mail-archive/web/storm/ Description of Working Group: The IETF IPS (IP Storage) and RDDP (Remote Direct Data Placement) working groups have produced a significant number of storage protocols (e.g., iSCSI, iSER and FCIP) for which there is significant usage. The time has come to reflect feedback from implementation and usage into updated RFCs; this work may include: - Implementation-driven revisions and updates to existing protocols (i.e., updated RFCs that match the "running code"). - Interoperability reports as needed for the resulting revised protocols that are appropriate for Draft Standard RFC status. - Minor protocol changes or additions. Backwards compatibility is required. Significant changes to the existing protocol standards are out of scope, including any work on version 2 of any of these protocols. Security for these protocols is based on the functionality specified in RFC 3723 (Securing Block Storage Protocols over IP); the working group does not intend to make major changes or updates to that RFC. Stability is critical to the usage of these protocols, so backwards compatibility with existing implementations will be a requirement imposed on for all protocol changes and additions. Note that this is a requirement for implementation compatibility - if it is the case that all implementations of a protocol have done something different than what the RFC specifies, it is appropriate for a new RFC to document what the "running code" actually does and deprecate the unused original behavior= . List of work items: (1) iSCSI: Combine RFCs 3720 (iSCSI), 3980 (NAA names), 4850 (node architecture key) and 5048 (corrections/clarifications) into one draft (3720bis), removing features that are not implemented in practice. This draft should be prepared so that it could become a Draft Standard RFC, but the Working Group has decided not to advance it to Draft Standard status. (2) iSCSI: Add features to support at least SAM-4 (4th version of the SCSI architecture) in a backwards-compatible fashion, as iSCSI is currently based on SAM-2. This will be a separate draft from the iSCSI update in the previous item. The Working Group may add additional minor useful iSCSI features to this draft, including features from draft versions of SAM-5. The iSCSI MIB (RFC 4544) should be updated to provide SNMP support for new features as appropriate. (3) FCIP: IP Protocol number 133 was allocated to a precursor of the FCIP protocol in 2000, but this allocated number is not used by FCIP. The Working Group has documented the deployed pre-standard use of this protocol number in RFC 6172, and IANA has updated the registry entry to reference RFC 6172. (4) iFCP: The Address Translation mode of iFCP needs to be deprecated (SHOULD NOT implement or use), as there are significant technical problems with its specification, and moreover, only the Address Transparent mode of iFCP is in use. This will be done via a short draft that updates RFC 4172, and not via a complete rewrite of RFC 4172. The Working Group has deprecated iFCP Address Translation mode in RFC 6172 and made the corresponding changes to the iFCP MIB (originally RFC 4369) in RFC 6173. (5) RDDP MPA: Good support for MPI applications requires a small update to the startup functionality to allow either end of the connection to initiate. In addition, a couple of minor changes to RDDP connection setup are needed based on implementation experience. (6) iSER: Experience with Infiniband implementations suggest a few minor updates to reflect what has been done in practice. (7) RDMA Protocol: Experience with the rddp (iWARP) RDMA Protocol (RFC 5040) suggests that some minor extensions are needed, specifically, the addition of immediate data support and remote atomic operations. The Working Group is expected to maintain good working relationships with INCITS Technical Committee T10 (SCSI standards) and INCITS Technical Committee T11 (Fibre Channel standards) via overlaps in membership as opposed to appointment of formal liaisons. The liaison process (including IAB appointment of a liaison or liaisons) remains available for use if needed. Recent changes in INCITS rules have removed public access to some T10 and T11 standards documents that are expected to be needed for the WG's program of work. Arrangements have been made with T10 and T11 for IETF participants to obtain copies of specific standards their personal use in IETF work as needed; contact the WG chair(s) for details. Goals and Milestones:=20 Done First version of combined iSCSI draft (3720bis) Done First version of iSCSI SAM-4 (and other) new features draft Done First version of RDDP MPA startup change draft Done First version of FCIP protocol number and iFCP Address=20 Translation mode draft Done First version of iSER update draft Done Working Group Last Call on FCIP protocol number and iFCP=20 address change draft Done Working Group Last Call on RDDP MPA startup change draft Done Functionally complete iSCSI SAM-4 (and other) new features=20 draft Done Working Group decision on whether to seek Draft Standard RFC=20 status for the combined iSCSI draft (3720bis). [Note: decision=20 may be made significantly before this date.] Jul 2011 Working Group Last Call on combined iSCSI draft (3720bis) plus=20 iSCSI SAM-4 (and other) new features draft Done First version of iSCSI MIB update draft Sep 2011 Working Group Last Call on iSCSI MIB update draft Oct 2011 Working Group Last Call on iSER update draft Feb 2012 Working Group Last Call on RDMA Protocol Extensions draft _______________________________________________ storm mailing list storm@ietf.org https://www.ietf.org/mailman/listinfo/storm From roweber@ieee.org Tue Aug 30 19:07:13 2011 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 07C8821F8D7A for ; Tue, 30 Aug 2011 19:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.332 X-Spam-Level: X-Spam-Status: No, score=-102.332 tagged_above=-999 required=5 tests=[AWL=0.268, 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 pIhWKdgsRZCy for ; Tue, 30 Aug 2011 19:07:12 -0700 (PDT) Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED71521F8D79 for ; Tue, 30 Aug 2011 19:07:11 -0700 (PDT) Received: from [192.168.1.5] ([unknown] [71.170.249.51]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0LQR00622SM0XV80@vms173001.mailsrvcs.net> for storm@ietf.org; Tue, 30 Aug 2011 21:08:24 -0500 (CDT) Message-id: <4E5D9793.3020704@ieee.org> Date: Tue, 30 Aug 2011 21:08:19 -0500 From: Ralph Weber User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-version: 1.0 To: storm@ietf.org References: <7C4DFCE962635144B8FAE8CA11D0BF1E05896E6CF8@MX14A.corp.emc.com> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130026@MX14A.corp.emc.com> <4E59A574.8040602@ieee.org> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130046@MX14A.corp.emc.com> <4E5BEA43.5050404@ieee.org> <7C4DFCE962635144B8FAE8CA11D0BF1E058B130618@MX14A.corp.emc.com> In-reply-to: <7C4DFCE962635144B8FAE8CA11D0BF1E058B130618@MX14A.corp.emc.com> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft 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 Aug 2011 02:07:13 -0000 David, If agreement between the two of us counts as consensus, then pop open the bubbly. All the best, .Ralph On 8/30/2011 6:09 PM, david.black@emc.com wrote: > I like Ralph's suggestion to include a mention of operating systems in the new test, > but I have some further tweaks to his words to suggest: > > SCSI initiator functionality in some operating systems depends on ACA to enforce > ordered command execution during error recovery, and hence iSCSI initiator > implementations for those operating systems need to support ACA. In order > to support error recovery for these operating systems and iSCSI initiators, > iSCSI targets SHOULD support ACA. > > Thanks, > --David > >> -----Original Message----- >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka >> Sent: Tuesday, August 30, 2011 1:49 PM >> To: storm@ietf.org >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >> >> I am catching up on this thread after a vacation. >> >> I agree in general with the consensus on this thread that we should leave >> ACA as SHOULD. >> >> Specifically, I like David's last rewrite, which succinctly states the >> rationale in SCSI initiator terms, as appropriate for this spec. I plan to >> get that into the next rev. >> >> David, thanks for your Last Call review. I will address your all other >> comments as well in the next revision. >> >> Thanks. >> >> Mallikarjun >> >> >> >> -----Original Message----- >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf >> Of Ralph Weber >> Sent: Monday, August 29, 2011 12:37 PM >> To: storm@ietf.org >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI draft >> >> A necessary nuance between Operating Systems and initiator products is >> missing in the rewrite. How about: >> >> Some operating systems depend on SCSI ACA to enforce ordered command >> execution during error recovery, and hence iSCSI initiator implementations >> for those operating systems need to support ACA. In order to support >> error >> recovery for these operating systems and iSCSI initiators, iSCSI targets >> SHOULD support ACA. >> >> All the best, >> >> .Ralph >> >> On 8/28/2011 12:27 PM, david.black@emc.com wrote: >> > I agree - second try at text: >> > >> > OLD >> > ACA helps preserve ordered command execution in the presence of >> > errors. As iSCSI can have many commands in-flight between >> > initiator and target, iSCSI initiators and targets SHOULD support >> > ACA. >> > NEW >> > Some SCSI initiators use ACA to enforce ordered command execution >> > during error recovery, and hence iSCSI initiator implementations >> > for those SCSI initiators need to support ACA. In order to support >> > error recovery for these SCSI and iSCSI initiators, iSCSI targets >> > SHOULD support ACA. >> > >> > As Ralph noted, an implementer of an iSCSI initiator that needs ACA >> > will know it, or learn quickly when error recovery doesn't work right >> > wrt the SCSI class driver :-), so the primary purpose of the SHOULD in >> > this text is to tell target implementers about the need for ACA support. >> > >> > FWIW, this is a "SHOULD" and not a "MUST" because a target >> implementer >> > may choose not to support initiators that use ACA - that absence of >> > ACA support will be detected quickly at the SCSI level, as the first >> > SCSI command that sets the NACA bit in the CONTROL byte in the CDB >> > will get hit with a CHECK CONDITION for having done so. >> > >> > Thanks, >> > --David >> > >> >> -----Original Message----- >> >> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On >> >> Behalf Of Julian Satran >> >> Sent: Sunday, August 28, 2011 1:15 AM >> >> To: Ralph Weber >> >> Cc: storm@ietf.org >> >> Subject: Re: [storm] WG Last Call comments on consolidated iSCSI >> >> draft >> >> >> >> Ralph, >> >> >> >> I think you caught a nit. Your point is correct - WRT initiators. >> >> The SHOULD statement should refer to targets only. Initiators that >> >> are not supporting ACA may have a hard time surviving in the same >> >> environment with initiators that require and support ACA but will >> cause >> no harm to those that require and support it. >> >> >> >> Julo >> >> On Aug 28, 2011, at 5:18 AM, Ralph Weber wrote: >> >> >> >>> I am having a little bit of difficulty following the logic of the >> >>> proposed new text. >> >>> >> >>> First it says that some initiator implementations use ACA (which >> >>> implies that some do not). Then, it says that iSCSI initiators >> >>> (presumably all iSCSI initiators) ... SHOULD support ACA. >> >>> >> >>> I can understand why initiators that need ACA SHOULD support it, but >> >>> why should the others bear the burden? >> >>> >> >>> All the best, >> >>> >> >>> .Ralph >> >>> >> >>> On 8/27/2011 5:36 PM, david.black@emc.com wrote: >> >>>> >> >>>> >> >>>> In that case, let's at least get the explanation for the SHOULD right >> ;-). >> >>>> >> >>>> Here's a suggestion ... >> >>>> >> >>>> OLD >> >>>> ACA helps preserve ordered command execution in the presence of >> >>>> errors. As iSCSI can have many commands in-flight between >> >>>> initiator and target, iSCSI initiators and targets SHOULD support >> >>>> ACA. >> >>>> NEW >> >>>> Some SCSI initiator implementations use ACA to enforce ordered >> >>>> command execution during recovery from errors. In order to >> support >> >>>> error recovery in such SCSI initiators, iSCSI initiators and >> targets >> >>>> SHOULD support ACA. >> >>>> >> >>>> Thanks, >> >>>> --David >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com] >> >>>>> Sent: Friday, August 26, 2011 8:51 AM >> >>>>> To: Black, David >> >>>>> Cc: storm@ietf.org >> >>>>> Subject: RE: [storm] WG Last Call comments on consolidated iSCSI >> >>>>> draft >> >>>>> >> >>>>> I disagree. >> >>>>> >> >>>>> 1) while not common, the hosts that use it, do need it; >> >>>>> 2) the original 3720 text contains a SHOULD; and >> >>>>> 3) there is no good reason for us to be weakening this statement. >> >>>>> >> >>>>> Fred Knight >> >>>>> NetApp >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: david.black@emc.com [mailto:david.black@emc.com] >> >>>>> Sent: Thursday, August 25, 2011 5:55 PM >> >>>>> To: storm@ietf.org >> >>>>> Subject: [storm] WG Last Call comments on consolidated iSCSI draft >> >>>>> >> >>>>> <...text removed...> >> >>>>> >> >>>>> [D] Section 10.2 contains a "SHOULD" requirement for ACA >> >>>>> (Auto-Contingent Allegiance) support. >> >>>>> As ACA support in SCSI initiators is not common, I suggest >> >>>>> weakening this to a MAY requirement. >> >>>>> >> >>>>> >> >>>> _______________________________________________ >> >>>> storm mailing list >> >>>> storm@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/storm >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> storm mailing list >> >>> storm@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/storm >> >> _______________________________________________ >> >> storm mailing list >> >> storm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/storm >> > >> > >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm >> >> _______________________________________________ >> storm mailing list >> storm@ietf.org >> https://www.ietf.org/mailman/listinfo/storm > _______________________________________________ > storm mailing list > storm@ietf.org > https://www.ietf.org/mailman/listinfo/storm > >