[storm] UML, Model and Terminology

"Mallikarjun Chadalapaka" <cbm@chadalapaka.com> Mon, 08 March 2010 06:44 UTC

Return-Path: <cbm@chadalapaka.com>
X-Original-To: storm@core3.amsl.com
Delivered-To: storm@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A59303A686E for <storm@core3.amsl.com>; Sun, 7 Mar 2010 22:44:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Wa7QBe7MvMgD for <storm@core3.amsl.com>; Sun, 7 Mar 2010 22:44:13 -0800 (PST)
Received: from snt0-omc2-s34.snt0.hotmail.com (snt0-omc2-s34.snt0.hotmail.com []) by core3.amsl.com (Postfix) with ESMTP id A7D093A68A8 for <storm@ietf.org>; Sun, 7 Mar 2010 22:44:11 -0800 (PST)
Received: from SNT131-DS1 ([]) by snt0-omc2-s34.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 7 Mar 2010 22:44:15 -0800
X-Originating-IP: []
X-Originating-Email: [cbm@chadalapaka.com]
Message-ID: <SNT131-ds1ED272E4CFA4B364CD604A0350@phx.gbl>
From: "Mallikarjun Chadalapaka" <cbm@chadalapaka.com>
To: <Black_David@emc.com>, <storm@ietf.org>
References: <20091214221501.45F933A6826@core3.amsl.com> <C2D311A6F086424F99E385949ECFEBCB01BCDFD5@CORPUSMX80B.corp.emc.com>
In-Reply-To: <C2D311A6F086424F99E385949ECFEBCB01BCDFD5@CORPUSMX80B.corp.emc.com>
Date: Sun, 7 Mar 2010 22:44:14 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acp9CvSVV8/I8P2bTk+b/IEubj9eOA4kNX0gAjtE8rA=
Content-Language: en-us
X-OriginalArrivalTime: 08 Mar 2010 06:44:15.0373 (UTC) FILETIME=[C505B3D0:01CABE8A]
Subject: [storm] UML, Model and Terminology
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 06:44:17 -0000

Hi David,

> The UML, model and terminology mapping in Sections 3-5 need to be done

I am not 100% sure about what you mean - are you saying there's more work
that needs to be done here?  If so, can you please call it out?

>(RFC 3720 does not permit this, but I suspect that to be an
> oversight as opposed to intentional).  

Yes, I believe that to be the case - we had not planned to disallow
initiator+target implementations.  I will take the action item to address it
in the next revision of the consolidated draft.

> I wonder whether this material would be
> better moved to the consolidated iSCSI draft

The authors' original rationale for including the iSCSI UML modeling,
including aligning the iSCSI concepts to SAM UML classes, in this draft was
that it's appropriately tackled in a SAM-4/5 mapping draft as IIRC SCSI UML
modeling didn't exist in pre-SAM-4.  But OTOH, as you note, the modeling
here is really generic with no SAM-4-specific content on the iSCSI side.  So
I guess I'm OK to move it to the consolidated draft.



> -----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
> coming soon from Tom), it's time to turn attention to this draft.  This
> has been subject to significant review from a number of
> 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
> 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
> end of Section 5 (RFC 3720 does not permit this, but I suspect that to be
> 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
> accomplished by expanding Section 2.3 to list the specific changes, which
> - iSCSI Node may contain both initiator and target functionality (Section
> - 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
> - New "function succeeded" response code for the new task management
> (Section 8.3.1)
> - New PDUFormatForSAMUpdate text key to negotiate iSCSI support for the
> 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
> replacing the "This key ..." paragraph with
> 	This key is used to negotiate presence of iSCSI support for the
> defined in this RFC.
> I strongly suggest moving the "Note that ..." paragraph from Section 9.1.1
> Section 6.  I would also add an example. Here's a possible example that
> help illuminate the distinction between SCSI and iSCSI errors:
> - An iSCSI implementation may negotiate this new key to "Yes" but respond
> the new task management functions with a "Task management function not
> supported" (that response reports a SCSI error that prevents the function
> being performed).
> - In contrast but if that key is negotiated to "Yes", an iSCSI
> must not reject a Task Management Function Request PDU that requests one
> 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
> clarity:
> - Section 7.1.1
>    As defined in Section 10, iSCSI PDU Formats of [RFC3720],
>    compliant senders already set this field to zero.
>    Section 10 of [RFC3720] requires that senders set this field to zero.
> - Section 8.2
>    Any compliant sender MUST NOT send these task management function
>    requests unless ...
>    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
> put in all the time and effort to write this draft ;-).  That key name is
> 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