Re: [Ips] iSCSI-specific unit attention conditions

Paul Koning <Paul_Koning@dell.com> Tue, 31 March 2009 18:55 UTC

Return-Path: <Paul_Koning@Dell.com>
X-Original-To: ips@core3.amsl.com
Delivered-To: ips@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526833A6938 for <ips@core3.amsl.com>; Tue, 31 Mar 2009 11:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.104
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6epF+xR34NAI for <ips@core3.amsl.com>; Tue, 31 Mar 2009 11:55:48 -0700 (PDT)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id 5EBCA3A6817 for <ips@ietf.org>; 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 M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com 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 <Paul_Koning@dell.com>
To: Black_David@emc.com
References: <9FA859626025B64FBC2AF149D97C944A023F8427@CORPUSMX80A.corp.emc.com>
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]
Cc: ips@ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ips>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2009 18:55:49 -0000

>>>>> "Black" == Black David <Black_David@emc.com>; 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
 >> SPC-4: - 3Fh/12h iSCSI IP ADDRESS ADDED - 3Fh/13h iSCSI IP ADDRESS
 >> REMOVED - 3Fh/14h iSCSI IP ADDRESS CHANGED
 >> 
 >> 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.

       paul