Re: [storm] iSCSI version descriptors

<david.black@emc.com> Tue, 08 March 2011 16:31 UTC

Return-Path: <david.black@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 D62703A6928 for <storm@core3.amsl.com>; Tue, 8 Mar 2011 08:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.394
X-Spam-Level:
X-Spam-Status: No, score=-106.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 6Jjaiwe0ohrG for <storm@core3.amsl.com>; Tue, 8 Mar 2011 08:31:50 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 40B723A6912 for <storm@ietf.org>; Tue, 8 Mar 2011 08:31:49 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p28GX3v1013951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2011 11:33:03 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 8 Mar 2011 11:32:54 -0500
Received: from mxhub17.corp.emc.com (mxhub17.corp.emc.com [10.254.93.46]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p28GWdW2016113; Tue, 8 Mar 2011 11:32:39 -0500
Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub17.corp.emc.com ([10.254.93.46]) with mapi; Tue, 8 Mar 2011 11:32:39 -0500
From: <david.black@emc.com>
To: <cbm@chadalapaka.com>
Date: Tue, 8 Mar 2011 11:32:33 -0500
Thread-Topic: [storm] iSCSI version descriptors
Thread-Index: AQNNzi+Ud0BWrbVV/rTxz5nboVM//AJIXXz5AbVQrK0Cs3o97pDpBEcQgAEwRvA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5D3D54E@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com><18622DB7-0E74-4FEF-863F-B4D936B14D78@dell.com> <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE2557@MX14A.corp.emc.com> <1AE01F323BF34FCAB706F2B01C107207@23FX1C1> <SNT131-ds11257A1C6379FF5D82B964A0C70@phx.gbl>
In-Reply-To: <SNT131-ds11257A1C6379FF5D82B964A0C70@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {15E369E0-98AE-4795-851B-6B5F7E317C96}
x-cr-hashedpuzzle: TEA= BX2x EPmB HC6P HRCs J2CQ KLYI NeVw Rj4+ SMDu T13V U7OL VXmk Va3D WBXd XDn1; 2; YwBiAG0AQABjAGgAYQBkAGEAbABhAHAAYQBrAGEALgBjAG8AbQA7AHMAdABvAHIAbQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {15E369E0-98AE-4795-851B-6B5F7E317C96}; ZABhAHYAaQBkAC4AYgBsAGEAYwBrAEAAZQBtAGMALgBjAG8AbQA=; Tue, 08 Mar 2011 16:32:33 GMT; UgBFADoAIABbAHMAdABvAHIAbQBdACAAaQBTAEMAUwBJACAAdgBlAHIAcwBpAG8AbgAgAGQAZQBzAGMAcgBpAHAAdABvAHIAcwA=
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Cc: storm@ietf.org
Subject: Re: [storm] iSCSI version descriptors
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, 08 Mar 2011 16:31:51 -0000

I've talked to Fred Knight (author of the iSCSI-SAM extensions draft), and the plan that seems to make the most sense is the following (which matches your views):

> So at the moment, IMO, there's only need for 3 version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048 through RFC-consolidated
> 2: RFC iSCSI-SAM

We should endeavor to get reviews of the new drafts from important iSCSI implementers, and for now, I would prefer to put anything that isn't backwards compatible into the extensions draft (uses the value "2" above).

I do believe that's "rough consensus" for 3 values (0, 1, 2).

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Monday, March 07, 2011 5:41 PM
> To: 'David Harrington'; Black, David; paul_koning@Dell.com
> Cc: storm@ietf.org
> Subject: RE: [storm] iSCSI version descriptors
> 
> Hi David (Harrington),
> 
> I agree with your summary, and I wanted to get your feedback on the
> following approach for the iSCSI Consolidated spec.
> 
> Unless I am seriously forgetting something, the nature of protocol changes
> in the iSCSI Consolidated spec so far fall roughly into three categories:
> 
> 1) Removing an optional feature
> 2) Removing non-mandatory negotiation options for a mandatory feature
> 3) Adding an optional feature
> 
> WG still has *not* come up with a need for the following:
> 4) Adding/Changing the mandatory behavior of protocol
> 5) Removing a previously mandatory feature
> 6) Removing previously mandatory negotiation options for a mandatory feature
> 
> 
> I do not believe changes of categories #1, #2 and #3 require a version
> number bump-up - consistent with your discussion below.   So at the moment,
> IMO, there's only need for 3 version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048 through RFC-consolidated
> 2: RFC iSCSI-SAM
> 
> However, *should* the WG decide to make any changes in categories #4, #5 or
> #6 down the road, I submit that (the eventual) RFC-consolidated will require
> its own version number because that will be a semantic change in a mandatory
> portion of the protocol.  So at that point, IMO, we should switch to 4
> version descriptors:
> 
> 0: no version claimed
> 1: RFC 3720+5048
> 2: RFC-consolidated
> 3: RFC iSCSI-SAM
> 
> Comments/corrections are welcome.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
>   -----Original Message-----
>   From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
>   Of David Harrington
>   Sent: Wednesday, December 08, 2010 7:01 AM
>   To: david.black@emc.com; paul_koning@Dell.com
>   Cc: storm@ietf.org
>   Subject: Re: [storm] iSCSI version descriptors
> 
>   Hi,
> 
>   Jumping in late ...
> 
>   I think compliance requirements are key here.
>   If you can be "compliant to version 1" if you implement mandatory feature
>   X AND if you do NOT implement mandatory feature X, then you don't have
>   a very good compliance requirement.
>   The purpose of a version # is to help identify the set of features that
> can be
>   expected to be supported by OTHER implementations, to ensure
>   interoperability.
>   (obviously, if the feature was originally, and continues to be, protocol-
>   negotiable that's not a problem within a version#)
> 
>   I think it could be a poor engineering choice to have version 1 refer to
>   multiple different possible sets of features. I disagree that "Yes, using
> the
>   same version should be a goal", if the set of features one implementation
>   can expect of another implementation changes; interoperability should be
>   the goal. You can ignore my engineering advice (I assume the WG knows the
>   technology better than me). But I would appreciate being educated why this
>   is OK.
> 
>   Interoperability is considered during IESG Evaluation
>   http://www.ietf.org/iesg/statement/discuss-criteria.html. If I question
> the
>   interoperability of using the same version #, others in the IESG also
> might
>   question this. So you should ***document in each
>   draft*** why using the same version # to identify the changes proposed in
>   that draft is OK technically from an interoperability standpoint.
> 
>   (p.s. "we've already implemented it that way from the draft" is NOT an
>   argument that holds much weight with the IESG).
> 
>   David Harrington
>   Director, IETF Transport Area
>   ietfdbh@comcast.net (preferred for ietf)
>   dbharrington@huaweisymantec.com
>   +1 603 828 1401 (cell)
> 
>   > -----Original Message-----
>   > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
>   Behalf
>   > Of david.black@emc.com
>   > Sent: Monday, October 25, 2010 9:56 AM
>   > To: paul_koning@Dell.com
>   > Cc: storm@ietf.org
>   > Subject: Re: [storm] iSCSI version descriptors
>   >
>   > > For now, I believe we should say 3270/5048 and not mention
>   > "new consolidated draft".  It doesn't
>   > > seem appropriate to reference a draft.  If we end up being
>   > able to reuse the code for the
>   > > consolidated spec, as intended, then at the time that spec
>   > comes out, the description of the code
>   > > points would be updated to say that it applies to that RFC as
>   well.
>   >
>   > Yes, the specifications of the version code values need to be in terms
>   > of RFC numbers, not references to Internet-Drafts.
>   >
>   > Thanks,
>   > --David
>   >
>   >
>   > > -----Original Message-----
>   > > From: Paul Koning [mailto:paul_koning@Dell.com]
>   > > Sent: Friday, October 22, 2010 11:14 AM
>   > > To: Black, David
>   > > Cc: storm@ietf.org
>   > > Subject: Re: [storm] iSCSI version descriptors
>   > >
>   > >
>   > > On Oct 22, 2010, at 1:14 AM, <david.black@emc.com>
>   > <david.black@emc.com> wrote:
>   > >
>   > > > One more time on this issue.  This is for discussion -
>   > it's not an announcement of a decision.
>   > > This is the only real issue that needs to be resolved to
>   > complete the new (SAM) features draft for
>   > > iSCSI.
>   > > >
>   > > > Reminder: we need to define a set of small positive
>   > integer values to describe the iSCSI version
>   > > starting with 0 = "no version claimed".  After some private
>   > discussions, it appears that we need two
>   > > additional version values beyond 0.
>   > > >
>   > > > The first observation is that the baseline should be at
>   > least RFC 3720 (original iSCSI) + RFC 5048
>   > > (Corrections and Clarifications).  That would be version value 1.
>   > > >
>   > > > The next observation is that taking features out of the
>   > consolidated iSCSI draft may allow a
>   > > visible behavior change.  RFC 3720 has this to say about
>   > text keys for negotiation:
>   > > >
>   > > >   All keys in this document, except for the X extension
>   > formats, MUST
>   > > >   be supported by iSCSI initiators and targets when used
>   > as specified
>   > > >   here.  If used as specified, these keys MUST NOT be
>   > answered with
>   > > >   NotUnderstood.
>   > > >
>   > > > When we take out a feature in the new iSCSI consolidated
>   > draft, the easiest thing to do is allow a
>   > > NotUnderstood response to the keys that negotiate that
>   > feature.  This should not pose a problem for
>   > > unimplemented features, but it would be a behavior change.
>   > The completely backwards-compatible
>   > > alternative is have the consolidated iSCSI draft list the
>   > keys used for removed features and
>   > > prohibit  a NotUnderstood response to those keys (Reject
>   > would be an acceptable alternative
>   > > response).
>   > >
>   > > That sounds right.  Does it cause problems for that to be
>   > the answer?
>   > >
>   > > > If we're careful about this, the same version value can
>   > apply to 3720/5048 and the consolidated
>   > > iSCSI draft.  I'd suggest that we be careful, and the
>   > details of how can be worked out as we
>   > > finalize the consolidated draft - I think we should have at
>   > least one more round of looking at
>   > > features to remove.
>   > >
>   > > Yes, using the same version should be a goal.
>   > >
>   > > > After that, we'll need a version value for the new (SAM)
>   > features draft additions.  The result
>   > > would be 3 version values:
>   > > > 	0 = no version claimed
>   > > > 	1 = 3720/5048 or new consolidated draft
>   > > > 	2 = (3720/5048 or new consolidated draft) + SAM 4/5
>   > features from the SAM draft.
>   > >
>   > > I assume these numbers will be handled by IANA, so they'll
>   > need an IANA Considerations section
>   > > spelling out how.
>   > >
>   > > For now, I believe we should say 3270/5048 and not mention
>   > "new consolidated draft".  It doesn't
>   > > seem appropriate to reference a draft.  If we end up being
>   > able to reuse the code for the
>   > > consolidated spec, as intended, then at the time that spec
>   > comes out, the description of the code
>   > > points would be updated to say that it applies to that RFC as
>   well.
>   > >
>   > > For the SAM draft, can we reference a specific draft?  I
>   > think it's quite absurd that drafts even
>   > > have standard status in the first place, but given that
>   > they do, we need to be precise about which
>   > > document we're talking about.  If we say "draft 2010/10/34"
>   > now, and then a followup draft comes out
>   > > for which the same code point is appropriate, we'd update
>   > the description of the code point to list
>   > > that one as well.  But we can't leave it unstated.
>   > >
>   > > 	paul
>   > >
>   >
>   > _______________________________________________
>   > 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
>