Re: [storm] iSCSI SAM update: login key

<Black_David@emc.com> Thu, 01 April 2010 01:39 UTC

Return-Path: <Black_David@emc.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 923EC3A68F1 for <storm@core3.amsl.com>; Wed, 31 Mar 2010 18:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.819
X-Spam-Level:
X-Spam-Status: No, score=-4.819 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
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 8TUklX9jvE2q for <storm@core3.amsl.com>; Wed, 31 Mar 2010 18:39:52 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 260D43A681D for <storm@ietf.org>; Wed, 31 Mar 2010 18:39: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.3.2/Switch-3.1.7) with ESMTP id o311eLlx020439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 21:40:21 -0400
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 31 Mar 2010 21:40:16 -0400
Received: from corpussmtp5.corp.emc.com (corpussmtp5.corp.emc.com [128.221.166.229]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o311dtUK031762; Wed, 31 Mar 2010 21:40:16 -0400
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.201]) by corpussmtp5.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 21:39:28 -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, 31 Mar 2010 21:39:26 -0400
Message-ID: <C2D311A6F086424F99E385949ECFEBCB021F2A97@CORPUSMX80B.corp.emc.com>
In-Reply-To: <SNT131-ds17A17D8A2F5FEEC9234C6A01F0@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] iSCSI SAM update: login key
thread-index: AcrPw3Ow0rqhdNZxRTCeRCywxoqlsQAZIGHAAEUA15A=
References: <C2D311A6F086424F99E385949ECFEBCB021629C4@CORPUSMX80B.corp.emc.com> <SNT131-ds10A1204F54D78F9972EB8FA0220@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02162B43@CORPUSMX80B.corp.emc.com> <4BADAC54.10705@gmail.com> <SNT131-ds5790403C32823DD1AD5C9A01F0@phx.gbl> <C2D311A6F086424F99E385949ECFEBCB02163229@CORPUSMX80B.corp.emc.com> <9F004C34-312E-45D5-B868-8DAF62CBD43E@gmail.com> <SNT131-ds17A17D8A2F5FEEC9234C6A01F0@phx.gbl>
From: <Black_David@emc.com>
To: <cbm@chadalapaka.com>, <julian.satran@gmail.com>
X-OriginalArrivalTime: 01 Apr 2010 01:39:28.0887 (UTC) FILETIME=[2B576070:01CAD13C]
X-EMM-EM: Active
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: Thu, 01 Apr 2010 01:39:54 -0000

<WG chair hat on>

I believe I see agreement on "iSCSIProtocolLevel".

Fred should consider Mallikarjun's text as input to the text describing
this key in the iSCSI update draft.

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Tuesday, March 30, 2010 1:13 PM
> To: 'Julian Satran'; Black, David
> Cc: Black, David; storm@ietf.org
> Subject: RE: [storm] iSCSI SAM update: login key
> 
> I tend to agree with David that "iSCSIProtocolLevel" is a reasonable
name
> given the precedent.
> 
> To Julian's point, just like ErrorRecoveryLevel, I suggest each value
of
> iSCSIProtocolLevel to be a logical superset of prior values - any
deprecated
> features should be automatically covered in this scheme assuming that
each
> such RFC that deprecates a feature requests a protocol level
milestone.
> 
> I suggest the following verbiage to the new key description to make
this
> very clear:
> 
> 
> Negotiation of 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.
An
> operational value of iSCSIProtocolLevel=x on an iSCSI session requires
that
> the iSCSI protocol semantics on that iSCSI session be a logical
superset of
> the capabilities in all RFCs that have claimed values of
iSCSIProtocolLevel
> < x.
> 
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
Behalf Of
> > Julian Satran
> > Sent: Monday, March 29, 2010 9:43 PM
> > To: <Black_David@emc.com>
> > Cc: Black_David@emc.com; <storm@ietf.org>
> > Subject: Re: [storm] iSCSI SAM update: login key
> >
> > It was just cosmetics. Anyhow with error recovery level really meant
> > level. I wonder if with protocol we want every level to include all
> > the preceding levels (including some obsolition) - in which case
level
> > is appropriate or merely a combination of things in which case I
would
> > suggest bundle. Also if it level the negotiation is numeric while
for
> > a combination it is boolean.
> >
> > Regards,
> > Julo
> >
> > On 30/03/2010, at 04:59, <Black_David@emc.com> wrote:
> >
> > > <WG co-chair hat OFF>
> > >
> > > We already have ErrorRecoveryLevel, so I don't see a problem with
a
> > > second key that ends in "Level".
> > >
> > > Thanks,
> > > --David
> > >
> > >
> > >> -----Original Message-----
> > >> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> > >> Sent: Monday, March 29, 2010 8:15 PM
> > >> To: 'Julian Satran'; Black, David
> > >> Cc: storm@ietf.org
> > >> Subject: RE: [storm] iSCSI SAM update: login key
> > >>
> > >> 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
> > >>
> > >>
> > >
> > > _______________________________________________
> > > 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
>