Re: [storm] iSCSI SAM update: login key

"David Harrington" <ietfdbh@comcast.net> Sun, 11 April 2010 14:52 UTC

Return-Path: <ietfdbh@comcast.net>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD5F3A68BD for <storm@core3.amsl.com>; Sun, 11 Apr 2010 07:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.24
X-Spam-Level:
X-Spam-Status: No, score=-0.24 tagged_above=-999 required=5 tests=[AWL=-0.841, BAYES_50=0.001, J_CHICKENPOX_31=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGtKmOQHOoRB for <storm@core3.amsl.com>; Sun, 11 Apr 2010 07:52:43 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id 1D2133A687B for <storm@ietf.org>; Sun, 11 Apr 2010 07:52:42 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id 4BQ51e00A1c6gX85AEsfDZ; Sun, 11 Apr 2010 14:52:39 +0000
Received: from Harrington73653 ([67.189.235.106]) by omta23.westchester.pa.mail.comcast.net with comcast id 4Ewl1e0052JQnJT3jEwlPu; Sun, 11 Apr 2010 14:56:45 +0000
From: "David Harrington" <ietfdbh@comcast.net>
To: <storm@ietf.org>
References: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com><SNT131-ds10A1204F54D78F9972EB8FA0220@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com>
Date: Sun, 11 Apr 2010 10:52:37 -0400
Message-ID: <0beb01cad986$a0f0ef70$0600a8c0@china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcrNFN17PQ3xD5CNTO+maRmCN0ae/gARsz8AAAVitKADBP1YwA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com>
Subject: Re: [storm] iSCSI SAM update: login key
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 11 Apr 2010 14:52:44 -0000

<as individual contributor>

Level seems to imply that anything earlier is supported, so (using
rfc#s as levels for my example):
if there existed (independent) features in rfc 7501, 7522, and 7599, 
then level=rfc7599 would imply that 7501 and 7522 MUST be supported as
well?
And nothing could ever be not-backwards-compatible.
Maybe that is what the WG wants.

I wonder if it might be more flexible to define an approach, such as
bits in a bit string, so different combinations could be supported:
	bit 1: 7501
	bit 2: 7522
	bit 3: 7599

so an implementation could support, for example, rfcs 7501 and 7599
but not 7522.
Many IETF protocols allow for this type of RFC mix-and-match
compliance flexibility.

Or does the WG consider this flexibility undesirable?

dbh

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] 
> On Behalf Of Black_David@emc.com
> Sent: Saturday, March 27, 2010 1:52 AM
> To: cbm@chadalapaka.com; storm@ietf.org
> Subject: Re: [storm] iSCSI SAM update: login key
> 
> Mallikarjun,
> 
> That makes sense (decouple from PDU structure changes), and 
> suggests that we need a key name that doesn't use "PDUFormat" ...
> ... How about iSCSIProtocolLevel ?
> 
> It will be necessary to be conservative in defining new 
> values - the requirement to publish a standards track RFC to 
> define a new value should help with that.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > Sent: Saturday, March 27, 2010 12:28 AM
> > To: Black, David; storm@ietf.org
> > Subject: RE: [storm] iSCSI SAM update: login key
> > 
> > > This will be an IETF key whose values are assigned by 
> IETF standards action
> > > (standards-track RFC); it is not linked to SAM versions 
> (e.g., a new version
> > > of SAM is not a prerequisite to assigning the value 3).
> > 
> > Decoupling this key from SAM numbering space is a good idea.
> > 
> > I also suggest decoupling it from PDU structure changes.  
> Any new iSCSI standards track RFC, whether
> > or not it extends/changes PDU format, should be able to 
> claim a number by WG consensus.  Reasons for
> > claiming a new number could include things like:
> > 1) New feature introduction (e.g. new Opcodes, new TMF 
> Codes, new Async codes)
> > 2) Major bug fix to the iSCSI protocol that affects end 
> node processing
> > 3) Change in semantics to keep up with changing SCSI semantics
> > 4) A PDU Format enhancement
> > 5) TBD reason by WG consensus
> > 
> > Reasons 1-3 may not have associated PDU format changes, 
> unlike 4.  I suggest these should all be
> > grounds for the WG to consider assigning a number.
> > 
> > Doing this allows implementations to negotiate a shared 
> milestone at an RFC granularity (if that RFC
> > has a number), as opposed to feature-by-feature negotiation 
> (e.g. TaskReporting="FastAbort") with some
> > gray areas that we had to resort to so far.
> > 
> > Thanks.
> > 
> > Mallikarjun
> > 
> > > -----Original Message-----
> > > From: storm-bounces@ietf.org 
> [mailto:storm-bounces@ietf.org] On Behalf Of
> > > Black_David@emc.com
> > > Sent: Friday, March 26, 2010 11:48 AM
> > > To: storm@ietf.org
> > > Cc: Black_David@emc.com
> > > Subject: [storm] iSCSI SAM update: login key
> > >
> > > Based on discussion in the Anaheim meeting, here's the 
> proposal that emerged
> > > for the login key to negotiate usage of the new features 
> in the iSCSI SAM
> > > update draft (draft-ietf-storm-iscsi-sam-00).
> > >
> > > Past concerns (that I can recall) about this have been:
> > > - Key needs to negotiate iSCSI PDU format/content changes only.
> > > - Detecting device support or lack thereof for SCSI features
> > > 	should be handled at the SCSI level (e.g., via SCSI commands).
> > > - Using a SAM version number in this iSCSI key is not a good
idea.
> > > - Would like something that can accommodate future changes.
> > > - Changing the key name from what's in the draft may be desired.
> > >
> > > The proposal that emerged is:
> > >
> > > The key name will be PDUFormatLevel.  It's a numeric (not 
> boolean) key with
> > > two defined values:
> > > 	- 1 = Current iSCSI (all four RFCs - 3720, 3980, 4850 and
5048,
> > > 		but no change to required vs. optional features).
> > > 	- 2 = Current iSCSI plus features in update draft.
> > > Usage is Leading Only (LO), scope is Session Wide (SW).
> > > Default value is 1, result function is Minimum.
> > >
> > > This will be an IETF key whose values are assigned by 
> IETF standards action
> > > (standards-track RFC); it is not linked to SAM versions 
> (e.g., a new version
> > > of SAM is not a prerequisite to assigning the value 3).
> > >
> > > This key also provides a clean way to handle definition 
> of iSCSI version
> > > descriptors in SPC-4:
> > > - 0960h would remain "iSCSI (no version claimed)"
> > > - The range 0961h-097Fh would be defined as 0960h + value
> > > 	of PDUFormatLevel key used by the device.
> > > That results in one place (IANA registry) covering both 
> definitions (key &
> > > version descriptor).
> > >
> > > In order to support iSCSI version descriptors, we would 
> ask IANA to put the
> > > values of the PDUFormatLevel key into a separate registry 
> with its own URL,
> > > and then ask T10 to modify SPC-4.  The latter is not an 
> immediate action - I
> > > would not anticipate bringing the SPC-4 proposal for that 
> to T10 until after
> > > the RFC is published and the IANA registry is created.
> > >
> > > This was the sense of the room + WebEx in Anaheim.  
> Absence of objection on
> > > the list will confirm the above as the approach to be 
> taken (rough consensus
> > > of the storm WG).
> > >
> > > Thanks,
> > > --David
> > > ----------------------------------------------------
> > > David L. Black, Distinguished Engineer
> > > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > > black_david@emc.com        Mobile: +1 (978) 394-7754
> > > ----------------------------------------------------
> > >
> > >
> > > _______________________________________________
> > > 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
>