Re: [storm] Consolidated iSCSI draft and TaskReporting

"Mark Bakke (mbakke)" <mbakke@cisco.com> Tue, 05 July 2011 17:54 UTC

Return-Path: <mbakke@cisco.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 C5D1321F88EF for <storm@ietfa.amsl.com>; Tue, 5 Jul 2011 10:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 trB2P2aEGfcO for <storm@ietfa.amsl.com>; Tue, 5 Jul 2011 10:54:10 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id BB9E721F88C1 for <storm@ietf.org>; Tue, 5 Jul 2011 10:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbakke@cisco.com; l=8568; q=dns/txt; s=iport; t=1309888450; x=1311098050; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=LCQdlz9VKhVnluYu0hds/EAPYICc9cM/mhzg3TZ4QOk=; b=lFTkofWKLqqx1uimZtDG6l5ZzytbUmZ2QyuKGnjdK7VafamyxXp2KfSO FDbOlM5AcZoNnTQviBN2xap94+1WiaacFKGAoG7PbV/mLGlUwn7mdLsE4 nrNUxnLLEAps0fInsfuK30ouRrKCa5+3T80MLxlCoP+vSLCEyb3edCF9C k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvIAAFhPE06rRDoI/2dsb2JhbABNBhCYQY84d604nXaCP3yCewSHP494in5V
X-IronPort-AV: E=Sophos;i="4.65,480,1304294400"; d="scan'208";a="290486815"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2011 17:53:04 +0000
Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p65Hr4iu013846; Tue, 5 Jul 2011 17:53:04 GMT
Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Jul 2011 12:53:04 -0500
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 5 Jul 2011 12:53:02 -0500
Message-ID: <97CC2D4896BE5D48825529CE9A16882505F688E1@XMB-RCD-105.cisco.com>
In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [storm] Consolidated iSCSI draft and TaskReporting
Thread-Index: AQDeOsqbPwyi4a8ddBcbQxUWgjUBFQKxRZHdAgOPlpyWjMTOgIAFGOsggAImkaCAAFgpsA==
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> <7C4DFCE962635144B8FAE8CA11D0BF1E0589392435@MX14A.corp.emc.com>
From: "Mark Bakke (mbakke)" <mbakke@cisco.com>
To: <david.black@emc.com>, <cbm@chadalapaka.com>, <pmacarth@iol.unh.edu>, <storm@ietf.org>
X-OriginalArrivalTime: 05 Jul 2011 17:53:04.0115 (UTC) FILETIME=[638CCC30:01CC3B3C]
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 17:54:11 -0000

Great; thanks, David.

Mark

-----Original Message-----
From: david.black@emc.com [mailto:david.black@emc.com] 
Sent: Tuesday, July 05, 2011 7:39 AM
To: Mark Bakke (mbakke); cbm@chadalapaka.com; pmacarth@iol.unh.edu; storm@ietf.org
Subject: RE: [storm] Consolidated iSCSI draft and TaskReporting

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