Re: [storm] iSCSI SAM update: login key

"Mallikarjun Chadalapaka" <cbm@chadalapaka.com> Tue, 30 March 2010 00:15 UTC

Return-Path: <cbm@chadalapaka.com>
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 88AD93A6996 for <storm@core3.amsl.com>; Mon, 29 Mar 2010 17:15:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
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 9maJ-kt2u2BR for <storm@core3.amsl.com>; Mon, 29 Mar 2010 17:15:19 -0700 (PDT)
Received: from snt0-omc1-s12.snt0.hotmail.com (snt0-omc1-s12.snt0.hotmail.com [65.55.90.23]) by core3.amsl.com (Postfix) with ESMTP id 0D68A3A659A for <storm@ietf.org>; Mon, 29 Mar 2010 17:15:18 -0700 (PDT)
Received: from SNT131-DS5 ([65.55.90.8]) by snt0-omc1-s12.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Mar 2010 17:15:07 -0700
X-Originating-IP: [15.251.201.73]
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds5790403C32823DD1AD5C9A01F0@phx.gbl>
From: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>
To: "'Julian Satran'" <julian.satran@gmail.com>, <Black_David@emc.com>
References: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com> <SNT131-ds10A1204F54D78F9972EB8FA0220@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com> <4BADAC54.10705@gmail.com>
In-Reply-To: <4BADAC54.10705@gmail.com>
Date: Mon, 29 Mar 2010 17:15:05 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrNesNQXBi4mNKZSGyZtPIVDXtYAACIdeFg
Content-Language: en-us
X-OriginalArrivalTime: 30 Mar 2010 00:15:07.0045 (UTC) FILETIME=[0D6C1550:01CACF9E]
Cc: storm@ietf.org
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: Tue, 30 Mar 2010 00:15:20 -0000

OK, I then suggest iSCSIProtocolTier

I would be OK with iSCSIProtocolLevel as well.

Glad to see the consensus, thanks.

Mallikarjun

> -----Original Message-----
> From: Julian Satran [mailto:julian.satran@gmail.com]
> Sent: Friday, March 26, 2010 11:57 PM
> To: Black_David@emc.com
> Cc: cbm@chadalapaka.com; storm@ietf.org
> Subject: Re: [storm] iSCSI SAM update: login key
> 
>   I would suggest gen instead of level (level has too much of a value
> connotation - at least it my part of the world :-))
> 
> Julo
> 
> 
> On 27/03/10 08:52, Black_David@emc.com wrote:
> > 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