Re: [storm] Consolidated iSCSI draft and TaskReporting

<david.black@emc.com> Tue, 05 July 2011 12:40 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 3ED2421F8730 for <storm@ietfa.amsl.com>; Tue, 5 Jul 2011 05:40:03 -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 Sg0aFTw5xysz for <storm@ietfa.amsl.com>; Tue, 5 Jul 2011 05:40:02 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8B21F8676 for <storm@ietf.org>; Tue, 5 Jul 2011 05:40:01 -0700 (PDT)
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 p65Cdwnx009417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2011 08:39:58 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.226]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 5 Jul 2011 08:39:47 -0400
Received: from mxhub27.corp.emc.com (mxhub27.corp.emc.com [10.254.110.183]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p65CdK75018769; Tue, 5 Jul 2011 08:39:20 -0400
Received: from mx14a.corp.emc.com ([169.254.1.245]) by mxhub27.corp.emc.com ([10.254.110.183]) with mapi; Tue, 5 Jul 2011 08:39:20 -0400
From: <david.black@emc.com>
To: <mbakke@cisco.com>, <cbm@chadalapaka.com>, <pmacarth@iol.unh.edu>, <storm@ietf.org>
Date: Tue, 5 Jul 2011 08:39:18 -0400
Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting
Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFQKxRZHdAgOPlpyWjMTOgIAFGOsggAImkaA=
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com>
References: <1308321497.3882.10.camel@chiron.ofa><SNT131-ds212BA8CFEE311B42259821A06C0@phx.gbl><7C4DFCE962635144B8FAE8CA11D0BF1E0589310372@MX14A.corp.emc.com> <SNT131-ds3915291A564FA2E77163FA0580@phx.gbl> <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.com>
In-Reply-To: <97CC2D4896BE5D48825529CE9A16882505E23845@XMB-RCD-105.cisco.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-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: Tue, 05 Jul 2011 12:40:03 -0000

Mark,

That will suffice for now.  The next version of the SAM draft will create an IANA registry for these values; I would reference the SAM draft for the definition of iSCSIProtocolLevel (as you've done) plus the registry for the values.

Thanks,
--David

> -----Original Message-----
> From: Mark Bakke (mbakke) [mailto:mbakke@cisco.com]
> Sent: Sunday, July 03, 2011 11:51 PM
> To: Mallikarjun Chadalapaka; Black, David; pmacarth@iol.unh.edu; storm@ietf.org
> Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting
> 
> Mallikarjun and David,
> 
> In the iSCSI MIB (draft-00 will be posted by tomorrow morning PST), we have added iSCSIProtocolLevel
> to the Session attributes:
> 
> iscsiSsnProtocolLevel OBJECT-TYPE
>     SYNTAX        Unsigned32 (1..65535)
>     MAX-ACCESS    read-only
>     STATUS        current
>     DESCRIPTION
>         "The iSCSI protocol level negotiated for this session."
>     REFERENCE
>         "[iSCSI-SAM], Section 7.1.1, iSCSIProtocolLevel"
>     DEFVAL        { 1 }
> ::= { iscsiSessionAttributesEntry 22 }
> 
> Instead of describing what the numbers mean as below, we are just referencing the SAM draft.  Is that
> the right thing, or is there more description we should be adding?
> 
> I'm fine with just referencing another spec, since that means we won't have to respin the MIB if
> another protocol level is added.
> 
> Thanks,
> 
> Mark
> 
> 
> -----Original Message-----
> From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of Mallikarjun Chadalapaka
> Sent: Thursday, June 30, 2011 5:07 PM
> To: david.black@emc.com; pmacarth@iol.unh.edu; storm@ietf.org
> Subject: Re: [storm] Consolidated iSCSI draft and TaskReporting
> 
> I'm OK with leaving out the phrase you point out - I meant it to cover the
> case of an acceptor in a key negotiation.  But I see your point.
> 
> I was thinking along the lines of each spec "claiming" a number for the
> iSCSIProtocolLevel key, so no one spec necessarily has a table of all the
> keys.  Currently, Consolidated draft claims  "1", and SAM draft claims "2".
> Sounds like you're thinking a table with currently claimed
> iSCSIProtocolLevel values in this spec?  I am fine with that too.
> 
> Thanks.
> 
> Mallikarjun
> 
> 
>   -----Original Message-----
>   From: david.black@emc.com [mailto:david.black@emc.com]
>   Sent: Thursday, June 30, 2011 1:31 PM
>   To: cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org
>   Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting
> 
>   <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
> 
> 
> _______________________________________________
> storm mailing list
> storm@ietf.org
> https://www.ietf.org/mailman/listinfo/storm