Re: [storm] Drafts of new iSCSI specs

Mallikarjun Chadalapaka <cbm@chadalapaka.com> Fri, 26 August 2011 02:26 UTC

Return-Path: <cbm@chadalapaka.com>
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 <storm@ietfa.amsl.com>; 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 <storm@ietfa.amsl.com>; 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 <storm@ietf.org>; 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: <SNT131-ds15CEA2ECE6B8A2F8701837A0130@phx.gbl>
From: Mallikarjun Chadalapaka <cbm@chadalapaka.com>
To: <Paul_Koning@Dell.com>, <david.black@emc.com>, <abanta@vmware.com>, <storm@ietf.org>
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 <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=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.  

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
  
  Yes, absolutely.
  
  	paul
  
  -----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
  
  Follow-up on this - I believe that we should stick with the two MAY-use
  requirements 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
  >
  > 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  01748
  > +1 (508) 293-7953             FAX: +1 (508) 293-7786
  > david.black@emc.com        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  01748
  > > > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
  > > > > david.black@emc.com        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
  _______________________________________________
  storm mailing list
  storm@ietf.org
  https://www.ietf.org/mailman/listinfo/storm