Re: [storm] iSCSI version descriptors

<david.black@emc.com> Mon, 25 October 2010 13:55 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 528B93A6A08 for <storm@core3.amsl.com>; Mon, 25 Oct 2010 06:55:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.497
X-Spam-Level:
X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 OCZZDdGuyi+A for <storm@core3.amsl.com>; Mon, 25 Oct 2010 06:55:12 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 34DAD3A683F for <storm@ietf.org>; Mon, 25 Oct 2010 06:55:11 -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.4.3/Switch-3.4.3) with ESMTP id o9PDut1f020798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Oct 2010 09:56:55 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 25 Oct 2010 09:56:42 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9PDtgcK029055; Mon, 25 Oct 2010 09:55:45 -0400
Received: from mxhub06.corp.emc.com ([128.221.46.114]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Oct 2010 09:55:42 -0400
Received: from mx14a.corp.emc.com ([169.254.1.11]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Mon, 25 Oct 2010 09:55:42 -0400
From: <david.black@emc.com>
To: <paul_koning@Dell.com>
Date: Mon, 25 Oct 2010 09:55:41 -0400
Thread-Topic: [storm] iSCSI version descriptors
Thread-Index: Actx/ItES/6IC2EMTIKn/VwgfEYPKgCT5r3g
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE2557@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com> <18622DB7-0E74-4FEF-863F-B4D936B14D78@dell.com>
In-Reply-To: <18622DB7-0E74-4FEF-863F-B4D936B14D78@dell.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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Oct 2010 13:55:42.0922 (UTC) FILETIME=[50A072A0:01CB744C]
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: Mon, 25 Oct 2010 13:55:13 -0000

> 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
>