[storm] Comments on draft-ietf-storm-iscsi-sam-00.txt
<Black_David@emc.com> Wed, 24 February 2010 22:31 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 DEE993A67F0 for <storm@core3.amsl.com>; Wed, 24 Feb 2010 14:31:32 -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=[AWL=0.000, 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 hBeGfDugpv6X for <storm@core3.amsl.com>; Wed, 24 Feb 2010 14:31:32 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id CDE683A83F7 for <storm@ietf.org>; Wed, 24 Feb 2010 14:31:31 -0800 (PST)
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.3.2/Switch-3.1.7) with ESMTP id o1OMXd2t017325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <storm@ietf.org>; Wed, 24 Feb 2010 17:33:39 -0500
Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor) for <storm@ietf.org>; Wed, 24 Feb 2010 17:33:36 -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 o1OMXZL8003957 for <storm@ietf.org>; Wed, 24 Feb 2010 17:33:36 -0500
Received: from CORPUSMX80B.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 24 Feb 2010 17:33:36 -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: Wed, 24 Feb 2010 17:33:35 -0500
Message-ID: <C2D311A6F086424F99E385949ECFEBCB01BCDFD5@CORPUSMX80B.corp.emc.com>
In-Reply-To: <20091214221501.45F933A6826@core3.amsl.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Comments on draft-ietf-storm-iscsi-sam-00.txt
Thread-Index: Acp9CvSVV8/I8P2bTk+b/IEubj9eOA4kNX0g
References: <20091214221501.45F933A6826@core3.amsl.com>
From: Black_David@emc.com
To: storm@ietf.org
X-OriginalArrivalTime: 24 Feb 2010 22:33:36.0065 (UTC) FILETIME=[67488B10:01CAB5A1]
X-EMM-EM: Active
Cc: Black_David@emc.com
Subject: [storm] Comments on draft-ietf-storm-iscsi-sam-00.txt
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, 24 Feb 2010 22:31:33 -0000
<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] I-D ACTION:draft-ietf-storm-iscsi-sam-00.… Internet-Drafts
- [storm] Comments on draft-ietf-storm-iscsi-sam-00… Black_David
- [storm] iSCSI and SCSI error examples with the ne… Mallikarjun Chadalapaka
- [storm] UML, Model and Terminology Mallikarjun Chadalapaka
- Re: [storm] UML, Model and Terminology Black_David
- Re: [storm] iSCSI and SCSI error examples with th… Black_David