Re: [storm] iSCSI and SCSI error examples with the new key

<Black_David@emc.com> Mon, 08 March 2010 08:06 UTC

Return-Path: <Black_David@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 2DD843A63EB for <storm@core3.amsl.com>; Mon, 8 Mar 2010 00:06:46 -0800 (PST)
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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 GI4hw+Xgu6ZC for <storm@core3.amsl.com>; Mon, 8 Mar 2010 00:06:45 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id C9D393A677D for <storm@ietf.org>; Mon, 8 Mar 2010 00:06:44 -0800 (PST)
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.3.2/Switch-3.1.7) with ESMTP id o2886lr0001885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 03:06:47 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Mon, 8 Mar 2010 03:06:35 -0500
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.169.196]) by mailhub.lss.emc.com (Switch-3.4.2/Switch-3.3.2mp) with ESMTP id o2886ZAe013960; Mon, 8 Mar 2010 03:06:35 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.203]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Mar 2010 03:06:35 -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: Mon, 8 Mar 2010 03:06:33 -0500
Message-ID: <C2D311A6F086424F99E385949ECFEBCB01DBD1B8@CORPUSMX80B.corp.emc.com>
In-Reply-To: <SNT131-ds117BCEDF39D1082D0685E4A0350@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: iSCSI and SCSI error examples with the new key
Thread-Index: Acp9CvSVV8/I8P2bTk+b/IEubj9eOA4kNX0gAjqyArAAA+jBcA==
References: <20091214221501.45F933A6826@core3.amsl.com> <C2D311A6F086424F99E385949ECFEBCB01BCDFD5@CORPUSMX80B.corp.emc.com> <SNT131-ds117BCEDF39D1082D0685E4A0350@phx.gbl>
From: <Black_David@emc.com>
To: <cbm@chadalapaka.com>, <storm@ietf.org>
X-OriginalArrivalTime: 08 Mar 2010 08:06:35.0067 (UTC) FILETIME=[454F30B0:01CABE96]
X-EMM-EM: Active
Subject: Re: [storm] iSCSI and SCSI error examples with the new key
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, 08 Mar 2010 08:06:46 -0000

Aside from wondering about a better key name, I think that writeup is good.

Thanks,
--David


> -----Original Message-----
> From: Mallikarjun Chadalapaka [mailto:cbm@chadalapaka.com]
> Sent: Monday, March 08, 2010 1:27 AM
> To: Black, David; storm@ietf.org
> Subject: iSCSI and SCSI error examples with the new key
> 
> Thanks David for the review.
> 
> > I strongly suggest moving the "Note that ..." paragraph from Section 9.1.1
> to
> > Section 6.
> 
> I agree, it's a good idea.  I also like the examples suggestion.  I just a
> wordsmithed yours a bit:
> 
> - An iSCSI implementation may negotiate PDUFormatForSAMUpdate to "Yes" but
> still may respond to the new task management functions with a "Task
> management function not supported" (that Response reports a SCSI error that
> prevents the function from being performed, and does not conflict with the
> negotiated "Yes" value for the iSCSI key).
> - In contrast, if PDUFormatForSAMUpdate key is negotiated to "Yes", an iSCSI
> implementation MUST NOT respond with a "Function rejected" response to any
> Task Management Function Request PDU that requests one of the new task
> management functions added in this document in Section 8.2 (that Response
> reports an iSCSI protocol error and thus conflicts with the operational
> value of "Yes" for the key).
> 
> 
> Mallikarjun
> 
> 
> 
> > -----Original Message-----
> > From: storm-bounces@ietf.org [mailto:storm-bounces@ietf.org] On Behalf Of
> > Black_David@emc.com
> > Sent: Wednesday, February 24, 2010 2:34 PM
> > To: storm@ietf.org
> > Cc: Black_David@emc.com
> > Subject: [storm] Comments on draft-ietf-storm-iscsi-sam-00.txt
> >
> > <WG Co-Chair hat OFF>
> >
> > With the WG last call on the iFCP-related drafts completed (summary message
> > coming soon from Tom), it's time to turn attention to this draft.  This draft
> > has been subject to significant review from a number of iSCSI-knowledgeable
> > people prior to submission, so it's in very good shape for a -00 draft.
> >
> > I have a few comments, mostly intended to start discussion.  To respond to
> > this message, please pick one of the comments below to respond to in a single
> > email message, and CHANGE THE SUBJECT LINE of the email.
> >
> > [1] UML, model and terminology mapping.
> >
> > The UML, model and terminology mapping in Sections 3-5 need to be done, and in
> > particular it's crucial to permit the device structure example shown at the
> > end of Section 5 (RFC 3720 does not permit this, but I suspect that to be an
> > oversight as opposed to intentional).  I wonder whether this material would be
> > better moved to the consolidated iSCSI draft, as that may be a more
> > appropriate home for it; that decision does not need to be made now.
> >
> > [2] RFC 3720 change summary
> >
> > I would like to see a "Summary of Changes to RFC 3720" section, this could be
> > accomplished by expanding Section 2.3 to list the specific changes, which are:
> >
> > - iSCSI Node may contain both initiator and target functionality (Section 5)
> >
> > - PRI field for SCSI Command Priority added to SCSI Command PDU (Section 7.1.1)
> > - Status Qualifier field added to SCSI Response PDU (Section 7.2.1)
> > - Sense data may be returned (via Autosense) for any SCSI status, not
> > 	just CHECK CONDITION (Section 7.2.2)
> > - Four new task management functions: QUERY TASK, QUERY TASK SET, I_T NEXUS RESET,
> > 	QUERY ASYNCHRONOUS EVENT (Section 8.2).
> > - New "function succeeded" response code for the new task management functions (Section 8.3.1)
> > - New PDUFormatForSAMUpdate text key to negotiate iSCSI support for the above
> > features (except for "iSCSI node may contain both initiator and target
> > functionality", which should be allowed no matter what, IMHO).
> >
> > [3] Section 9.1.1.  I don't like the phrase "RFC compliance level" and suggest
> > replacing the "This key ..." paragraph with
> >
> > 	This key is used to negotiate presence of iSCSI support for the features defined in this RFC.
> >
> > I strongly suggest moving the "Note that ..." paragraph from Section 9.1.1 to
> > Section 6.  I would also add an example. Here's a possible example that should
> > help illuminate the distinction between SCSI and iSCSI errors:
> > - An iSCSI implementation may negotiate this new key to "Yes" but respond to
> > the new task management functions with a "Task management function not
> > supported" (that response reports a SCSI error that prevents the function from
> > being performed).
> > - In contrast but if that key is negotiated to "Yes", an iSCSI implementation
> > must not reject a Task Management Function Request PDU that requests one of
> > the new task management functions (that reject reports an iSCSI protocol error).
> >
> > [4] Nit: "compliant"
> >
> > I don't like use of this word in RFCs, but this is an editorial matter of
> > taste.  Here are a couple of suggested rewordings that I think also improve
> > clarity:
> >
> > - Section 7.1.1
> > OLD
> >    As defined in Section 10, iSCSI PDU Formats of [RFC3720],
> >    compliant senders already set this field to zero.
> > NEW
> >    Section 10 of [RFC3720] requires that senders set this field to zero.
> >
> > - Section 8.2
> > OLD
> >    Any compliant sender MUST NOT send these task management function
> >    requests unless ...
> > NEW
> >    These task management function request MUST NOT be sent unless ...
> >
> > [5] Minor Nit: text key name
> >
> > While PDUFormatForSAMUpdate is not the key name I would have chosen, I didn't
> > put in all the time and effort to write this draft ;-).  That key name is ok
> > with me.
> >
> > I'll plan to review this draft again when it gets to WG Last Call ...
> >
> > Thanks,
> > --David
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> >
> > _______________________________________________
> > storm mailing list
> > storm@ietf.org
> > https://www.ietf.org/mailman/listinfo/storm
>