Re: [storm] iSCSI version descriptors

<david.black@emc.com> Sun, 24 October 2010 19:30 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 47F2F3A68ED for <storm@core3.amsl.com>; Sun, 24 Oct 2010 12:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.772
X-Spam-Level:
X-Spam-Status: No, score=-105.772 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_05=-1.11, 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 z+qg03EGJO8F for <storm@core3.amsl.com>; Sun, 24 Oct 2010 12:30:43 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E7E373A68D6 for <storm@ietf.org>; Sun, 24 Oct 2010 12:30:42 -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 o9OJWOg3029672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2010 15:32:24 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Sun, 24 Oct 2010 15:32:21 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9OJVtFr024505; Sun, 24 Oct 2010 15:31:55 -0400
Received: from mxhub06.corp.emc.com ([128.221.46.114]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Oct 2010 15:31:55 -0400
Received: from mx14a.corp.emc.com ([169.254.1.11]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Sun, 24 Oct 2010 15:31:54 -0400
From: david.black@emc.com
To: Frederick.Knight@netapp.com, storm@ietf.org
Date: Sun, 24 Oct 2010 15:31:53 -0400
Thread-Topic: [storm] iSCSI version descriptors
Thread-Index: ActxqAcvYVzq/KykR8+kppRKAwXZcwAbkHhwAGbMCiA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE2424@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com> <AC32D7C72530234288643DD5F1435D530C50B7C6@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <AC32D7C72530234288643DD5F1435D530C50B7C6@RTPMVEXC1-PRD.hq.netapp.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-OriginalArrivalTime: 24 Oct 2010 19:31:55.0240 (UTC) FILETIME=[1DDA2680:01CB73B2]
X-EMM-MHVC: 1
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: Sun, 24 Oct 2010 19:30:44 -0000

> Due to RFC4850, the consolidated draft is different than just 3720+5048 (4850 created the
> "X#NodeArchitecture" key).

That's an X extension format key, for which a NotUnderstood response is possible (RFC 4850 explicitly says so), and the key is only announced, not negotiated.

> How should we handle this?  Do we need:
> 	0 = no version claimed
> 	1 = 3720/5048
> 	2 = 3720/4850/5048 or new consolidated draft
> 	3 = (3720/4850/5048 or new consolidated draft) + SAM 4/5 features from the SAM draft.

I don't think 4850's presence/absence makes a sufficient difference, so I'd combine 1 and 2 above, plus rephrase the description of 3 (which would then become the new 2).

Thanks,
--David

> -----Original Message-----
> From: Knight, Frederick [mailto:Frederick.Knight@netapp.com]
> Sent: Friday, October 22, 2010 3:02 PM
> To: Black, David; storm@ietf.org
> Subject: RE: [storm] iSCSI version descriptors
> 
> The consolidated draft incorporates:
> 
> Updates: RFC 3720, 3721, 3980, 4850, 5048
> 
> Due to RFC4850, the consolidated draft is different than just 3720+5048 (4850 created the
> "X#NodeArchitecture" key).
> 
> How should we handle this?  Do we need:
> 	0 = no version claimed
> 	1 = 3720/5048
> 	2 = 3720/4850/5048 or new consolidated draft
> 	3 = (3720/4850/5048 or new consolidated draft) + SAM 4/5 features from the SAM draft.
> 
> 	Fred Knight
> 
> -----Original Message-----
> From: david.black@emc.com [mailto:david.black@emc.com]
> Sent: Friday, October 22, 2010 1:15 AM
> To: storm@ietf.org
> Subject: [storm] iSCSI version descriptors
> 
> 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).
> 
> 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.
> 
> 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.
> 
> Comments?
> 
> The SAM 4/5 features draft will expire while draft submission is closed for the Beijing meeting - if
> we can resolve this issue, the next version of that draft could be submitted shortly after draft
> submission opens again, and would probably go to WG Last Call shortly thereafter.
> 
> 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
> ----------------------------------------------------
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm