Re: [storm] Drafts of new iSCSI specs

<david.black@emc.com> Wed, 24 August 2011 23:09 UTC

Return-Path: <david.black@emc.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 E896021F8CA5 for <storm@ietfa.amsl.com>; 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 <storm@ietfa.amsl.com>; 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 <storm@ietf.org>; 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 <storm@ietf.org>; 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 <storm@ietf.org>; 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 <storm@ietf.org>; 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: <david.black@emc.com>
To: <abanta@vmware.com>, <storm@ietf.org>
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 <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: 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  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
> > > ----------------------------------------------------
> >