Re: [storm] Consolidated iSCSI draft and TaskReporting

<david.black@emc.com> Thu, 30 June 2011 20:55 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BD911E80AA for <storm@ietfa.amsl.com>; Thu, 30 Jun 2011 13:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCIjVBYxSKgq for <storm@ietfa.amsl.com>; Thu, 30 Jun 2011 13:55:16 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED9011E80A7 for <storm@ietf.org>; Thu, 30 Jun 2011 13:55:15 -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 p5UKt1Jl019803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Jun 2011 16:55:14 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 30 Jun 2011 16:46:30 -0400
Received: from mxhub02.corp.emc.com (mxhub02.corp.emc.com [10.254.141.104]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p5UKUe9d014637; Thu, 30 Jun 2011 16:30:41 -0400
Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub02.corp.emc.com ([10.254.141.104]) with mapi; Thu, 30 Jun 2011 16:30:41 -0400
From: <david.black@emc.com>
To: <cbm@chadalapaka.com>, <pmacarth@iol.unh.edu>, <storm@ietf.org>
Date: Thu, 30 Jun 2011 16:30:39 -0400
Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting
Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFZaeCrnwgBRHMXA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589310372@MX14A.corp.emc.com>
References: <1308321497.3882.10.camel@chiron.ofa> <SNT131-ds212BA8CFEE311B42259821A06C0@phx.gbl>
In-Reply-To: <SNT131-ds212BA8CFEE311B42259821A06C0@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EMM-MHVC: 1
Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Jun 2011 20:55:17 -0000

<WG chair hat on>

We should do what Mallikarjun proposes.  A table will be needed that lists the RFCs for each value of the iSCSIProtocolLevel key.

One change - "(or would have offered)" should be removed from Mallikarjun's proposed text.  Hypothetical requirements tend to be difficult to test and moreover are usually pointless - the values that are actually used in negotiation are what should govern protocol behavior.

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

> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
> Sent: Friday, June 17, 2011 8:24 PM
> To: 'Patrick MacArthur'; storm@ietf.org
> Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting
> 
> Hi Patrick,
> 
> I tend to agree with you, you raise a valid point.
> 
> The problem lies in special-casing RFC 3720.  I think the right way to
> address your comment is to require that an implementation's "NotUnderstood"
> response should correlate to the highest protocol version that it has
> offered (or would have offered) for the iSCSIProtocolLevel key in a
> negotiation.   E.g., let's say if an iSCSI implementation has *offered* a
> value of 2 in a negotiation (even though the other side has negotiated it
> down to 1), it means that the offering implementation can comprehend all
> text keys defined through the spec with iSCSIProtocolLevel=2.  So it must
> not respond to any of those text keys with a "NotUnderstood".
> 
> So the formal verbiage would look something like the following:
> 
> An iSCSI implementation MUST comprehend all text keys defined in iSCSI
> Protocol specifications from [RFC3720] through the RFC keyed to the highest
> protocol version that the implementation has offered (or would have offered)
> for the iSCSIProtocolLevel key in a negotiation.  Returning a NotUnderstood
> response on any of these text keys therefore MUST be considered a protocol
> error and handled accordingly.  For all other "later" keys, i.e. text keys
> defined in specifications keyed to higher values of iSCSIProtocolLevel, a
> NotUnderstood  answer concludes the negotiation for a negotiated key whereas
> for a declarative key, a NotUnderstood answer simply informs the declarer of
> a lack of comprehension by the receiver.
> 
> Please let me know if you have comments or questions.  Thanks.
> 
> Mallikarjun
> 
> 
> 
>   -----Original Message-----
>   From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf
>   Of Patrick MacArthur
>   Sent: Friday, June 17, 2011 7:38 AM
>   To: storm@ietf.org
>   Subject: [storm] Consolidated iSCSI draft and TaskReporting
> 
>   Hi,
> 
>   I wanted to ask for clarification on an item appearing in the consolidated
>   iSCSI draft.
> 
>       "All keys defined in [RFC3720] MUST be supported by all
>       compliant implementations; a NotUnderstood answer on any of the
>       [RFC3720] keys therefore MUST be considered a protocol error and
>       handled accordingly. For all other later keys, a NotUnderstood
>       answer concludes the negotiation for a negotiated key whereas for
>       a declarative key, a NotUnderstood answer simply informs the
>       declarer of a lack of comprehension by the receiver."
> 
>   I would like to request that the references to RFC3720 above be changed to
>   RFC3720 and RFC5048.  The comments on this list seem to indicate that the
>   baseline for the iSCSI work is on the combination of RFC 3720 and RFC
>   5048, which I interpret to mean that it would be applicable only to
>   implementations compliant with both RFCs.  An implementation that
>   claims to be RFC 5048-compliant and responds with
>   TaskReporting=NotUnderstood is broken IMHO. In that case, is there a
>   reason that we allow a NotUnderstood response on an RFC 5048 key
>   (TaskReporting)?
> 
>   If the STORM WG is trying to ensure compatibility with the requirements of
>   RFC 3720 and RFC 5048 combined, it seems strange to be allowing
>   implementers not to implement the key requirement of RFC 5048.
> 
>   Thanks,
> 
>   --
>   Patrick MacArthur
>   Research and Development
>   iSCSI/OFA/IPv6 Consortia
>   UNH InterOperability Laboratory
> 
>   _______________________________________________
>   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