Re: [Ips] iSCSI-specific unit attention conditions

Paul Koning <> Tue, 31 March 2009 18:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 526833A6938 for <>; Tue, 31 Mar 2009 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.104
X-Spam-Status: No, score=-104.104 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_NJABL_RELAY=2.696, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6epF+xR34NAI for <>; Tue, 31 Mar 2009 11:55:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5EBCA3A6817 for <>; Tue, 31 Mar 2009 11:55:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,303,1235973600"; d="scan'208";a="392931410"
Received: from unknown (HELO ([]) by with SMTP; 31 Mar 2009 13:56:46 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <18898.26477.64898.577194@gargle.gargle.HOWL>
Date: Tue, 31 Mar 2009 14:56:45 -0400
From: Paul Koning <>
References: <>
X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid
X-OriginalArrivalTime: 31 Mar 2009 18:56:46.0008 (UTC) FILETIME=[705DE380:01C9B232]
Subject: Re: [Ips] iSCSI-specific unit attention conditions
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Mar 2009 18:55:49 -0000

>>>>> "Black" == Black David <>; writes:

 Black> Here's another piece of "housekeeping" for the new STORM
 Black> WG-to-be - I've been informed by a knowledgeable T10
 Black> participant that:

 >> T10 proposal 05-406 (from Bill Galloway, Pivot3) added 3
 >> iSCSI-specific unit attention condition additional sense codes in
 >> r0 used a more generic "DEVICE PORT ADDRESS" phrase, but r1
 >> changed that to "iSCSI IP ADDRESS" upon recommendation by the
 >> [T10] CAP WG.
 >> However, there is no mention in any standard of when these are
 >> used (unlike all the other unit attention conditions, whose causes
 >> are clearly defined).  With the accepted names, that belongs in
 >> iSCSI itself.
 Black> FWIW, these ASC/Q value pairs appear to have been added to
 Black> SPC-4 without any cross-checking with the IETF, which would
 Black> serve to explain why there is no documentation anywhere about
 Black> when or how to use them.  Since these ASC/Qs are
 Black> iSCSI-specific, that task falls to the iSCSI specification(s),
 Black> unless these ASC/Qs are removed or have their names changed to
 Black> no longer be iSCSI-specific.

 Black> Hence: - the "new features" STORM draft should explain how to
 Black> use these ASC/Qs --- AND/OR --- - discussion here and in the
 Black> to-be-formed storm WG should generate a proposal to T10 about
 Black> what should change and why.

I would suggest the following.

1. The person advocating these ASC/Q codes should propose a new work
   item for STORM to add this new feature.  It first needs to be added
   to the charter, then a new I-D needs to be generated to describe
   it.  It doesn't belong in the other work items because it's neither
   cleanup nor (as far as I can tell) SAM-4 support.

2. If #1 isn't done or the proposal doesn't receive WG consensus,
   STORM should generate a liaison request to T10 asking for these
   ASC/Q codes to be removed, or deprecated, or otherwise relabeled 
   to make it clear that they are not defined by the iSCSI standard.