Re: [storm] iSCSI version descriptors

<david.black@emc.com> Wed, 09 March 2011 23:07 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 318063A6781 for <storm@core3.amsl.com>; Wed, 9 Mar 2011 15:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.114
X-Spam-Level:
X-Spam-Status: No, score=-106.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 PotP62wE+vOP for <storm@core3.amsl.com>; Wed, 9 Mar 2011 15:07:35 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id BB7663A6768 for <storm@ietf.org>; Wed, 9 Mar 2011 15:07:35 -0800 (PST)
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 p29N8krH010214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2011 18:08:46 -0500
Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Wed, 9 Mar 2011 18:08:41 -0500
Received: from mxhub28.corp.emc.com (mxhub28.corp.emc.com [10.254.110.184]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p29N8Ptm024985; Wed, 9 Mar 2011 18:08:25 -0500
Received: from mx14a.corp.emc.com ([169.254.1.143]) by mxhub28.corp.emc.com ([10.254.110.184]) with mapi; Wed, 9 Mar 2011 18:08:25 -0500
From: <david.black@emc.com>
To: <cbm@chadalapaka.com>, <storm@ietf.org>
Date: Wed, 9 Mar 2011 18:08:16 -0500
Thread-Topic: [storm] iSCSI version descriptors
Thread-Index: AQNNzi+Ud0BWrbVV/rTxz5nboVM//AGFluzAApiqDI2RAKTOEIAAKmBw
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5D3D987@MX14A.corp.emc.com>
References: <7C4DFCE962635144B8FAE8CA11D0BF1E03D1CE216E@MX14A.corp.emc.com> <SNT131-ds694BF19F46C40BA6595D7A0C70@phx.gbl> <7C4DFCE962635144B8FAE8CA11D0BF1E03E5D3D548@MX14A.corp.emc.com> <SNT131-ds212C6B0FA26A22200273EBA0C90@phx.gbl>
In-Reply-To: <SNT131-ds212C6B0FA26A22200273EBA0C90@phx.gbl>
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-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: Wed, 09 Mar 2011 23:07:37 -0000

Yes, we're in agreement, violent or otherwise ;-).

Thanks,
--David

> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Wednesday, March 09, 2011 3:51 PM
> To: Black, David; storm@ietf.org
> Subject: RE: [storm] iSCSI version descriptors
> 
> David,
> 
> I believe we are in general agreement.  Just a couple of comments.
> 
> >  My design preference is to recommend (SHOULD) a "Reject" value response,
> >  which is allowed by RFC 3720 and has the additional virtue of carrying a
> >  "What on earth do you think you're doing?" implication back to the clue-
> >  impaired implementation that tried to use the obsolete feature.
> 
> I am fine with:  SHOULD "Reject", MAY reply with "No", MUST NOT reply with a
> "NotUnderstood".
> 
> I have re-read the relevant RFC 3720 text and the formulation above is
> compliant with its semantics.
> 
> >  That covers half the cases - new initiator with new or old responder. With
> >  an old initiator, it is possible that obsolete options are offered.  If obsolete
> >  options are offered in combination with one or more supported options,
> >  everything should work fine.  If obsolete options are the only ones offered,
> >  "Reject" is an appropriate response.
> 
> We may be in violent agreement, :)  I agree with what you say, except I will
> point out that the relevant list negotiation semantics are already in RFC
> 3720 (and by extension, already in Consolidated draft).  So nothing new
> needs to be specified (which is what I meant by "nothing special"), consider
> the following text in section 5.2.1 of RFC 3720:
> 
>    If an acceptor does not understand any particular value in a list, it
>    MUST ignore it.  If an acceptor does not support, does not
>    understand, or is not allowed to use any of the proposed options with
>    a specific originator, it may use the constant "Reject" or terminate
>    the negotiation.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
> 
> 
> >-----Original Message-----
> >  From: david.black@emc.com [mailto:david.black@emc.com]
> >  Sent: Tuesday, March 08, 2011 8:22 AM
> >  To: cbm@chadalapaka.com; storm@ietf.org
> >  Subject: RE: [storm] iSCSI version descriptors
> >
> >  Mallikarjun,
> >
> >  While I think your option 1) is ok:
> >
> >  > 1) When a feature is completely obsoleted (e.g. markers) relative to
> >  > 3720, iSCSI consolidated spec requires that the corresponding keys be
> >  > negotiated to "No" (e.g. OFMarker=No).
> >
> >  My design preference is to recommend (SHOULD) a "Reject" value response,
> >  which is allowed by RFC 3720 and has the additional virtue of carrying a
> >  "What on earth do you think you're doing?" implication back to the clue-
> >  impaired implementation that tried to use the obsolete feature.  In any
> >  case, we're in clear agreement that a "NotUnderstood" response has to be
> >  prohibited.
> >
> >  > 2) When a feature *option* is obsoleted (e.g. SPKM1 & SPKM2 for
> >  AuthMethod),
> >  > the spec does nothing special.    The existing iSCSI negotiation
> semantics
> >  > are comprehensive enough that two spec-compliant implementations will
> >  > negotiate to the correct result because the obsoleted options for that
> >  > feature are not offered as negotiables.
> >
> >  That covers half the cases - new initiator with new or old responder.
> With
> >  an old initiator, it is possible that obsolete options are offered.  If
> obsolete
> >  options are offered in combination with one or more supported options,
> >  everything should work fine.  If obsolete options are the only ones
> offered,
> >  "Reject" is an appropriate response.
> >
> >  Thanks,
> >  --David
> >
> >  > -----Original Message-----
> >  > From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> >  > Sent: Monday, March 07, 2011 5:13 PM
> >  > To: Black, David; storm@ietf.org
> >  > Subject: RE: [storm] iSCSI version descriptors
> >  >
> >  > David,
> >  >
> >  > In trying to determine what if any text needs to change in the
> >  > consolidated spec after this discussion, I did a re-reading of this
> whole
> >  thread - up to
> >  > DavidH's most recent note.   I stumbled on the following:
> >  >
> >  > >  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).
> >  >
> >  > I do not believe the consolidated spec needs to change the current
> >  > negotiation semantics.  I suggest a third option:
> >  > 1) When a feature is completely obsoleted (e.g. markers) relative to
> >  > 3720, iSCSI consolidated spec requires that the corresponding keys be
> >  > negotiated to "No" (e.g. OFMarker=No).
> >  >
> >  > 2) When a feature *option* is obsoleted (e.g. SPKM1 & SPKM2 for
> >  AuthMethod),
> >  > the spec does nothing special.    The existing iSCSI negotiation
> semantics
> >  > are comprehensive enough that two spec-compliant implementations will
> >  > negotiate to the correct result because the obsoleted options for that
> >  > feature are not offered as negotiables.
> >  >
> >  >
> >  > This should minimize the core protocol changes, and related impacts to
> >  > existing interop tests.
> >  >
> >  > Comments are welcome.  With the fast-approaching Prague deadline, I
> >  > will go ahead with the spec'ing this option if I don't hear any
> >  > disagreement on this by this Wednesday.
> >  >
> >  > Thanks.
> >  >
> >  > Mallikarjun
> >  >
> >  >
> >  >
> >  >
> >  >   -----Original Message-----
> >  >   From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On
> >  Behalf
> >  >   Of david.black@emc.com
> >  >   Sent: Thursday, October 21, 2010 10:15 PM
> >  >   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
> >  >
> >
> >
>