Re: [Ips] iSCSI-specific unit attention conditions

"Knight, Frederick" <Frederick.Knight@netapp.com> Tue, 31 March 2009 19:17 UTC

Return-Path: <Frederick.Knight@netapp.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 760D328C199 for <ips@core3.amsl.com>; Tue, 31 Mar 2009 12:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.995
X-Spam-Level:
X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, 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 M2+OWnnN+rFy for <ips@core3.amsl.com>; Tue, 31 Mar 2009 12:17:39 -0700 (PDT)
Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by core3.amsl.com (Postfix) with ESMTP id 8C3353A6DCC for <ips@ietf.org>; Tue, 31 Mar 2009 12:17:39 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,303,1235980800"; d="scan'208";a="148385170"
Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 31 Mar 2009 12:18:39 -0700
Received: from sacrsexc1-prd.hq.netapp.com (sacrsexc1-prd.hq.netapp.com [10.99.115.27]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id n2VJIaSr024480; Tue, 31 Mar 2009 12:18:38 -0700 (PDT)
Received: from rtprsexc1-prd.hq.netapp.com ([10.100.161.114]) by sacrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 12:18:37 -0700
Received: from RTPMVEXC1-PRD.hq.netapp.com ([10.100.161.111]) by rtprsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 31 Mar 2009 15:18:32 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 31 Mar 2009 15:17:35 -0400
Message-ID: <AC32D7C72530234288643DD5F1435D530445C53C@RTPMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <18898.26477.64898.577194@gargle.gargle.HOWL>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ips] iSCSI-specific unit attention conditions
Thread-Index: AcmyMnYPeHHqZjA+QBCYa8sO8ECKJQAAPBNQ
From: "Knight, Frederick" <Frederick.Knight@netapp.com>
To: "Paul Koning" <Paul_Koning@dell.com>, <Black_David@emc.com>
X-OriginalArrivalTime: 31 Mar 2009 19:18:32.0203 (UTC) FILETIME=[7AEB6DB0:01C9B235]
X-Mailman-Approved-At: Wed, 01 Apr 2009 08:01:43 -0700
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 19:17:40 -0000

My interpretation of the "update" part of the agenda was that SAM-4 was
an example (and that we should also include SAM-3 and SAM-5 as part of
the update list).  Therefore, to add SPC to the update list is (in my
opinion) within the scope for the SCSI Update portion of this project.

Yes, it should be included in the charter (either specifically, or by
making clear the broader interpretation of the "update").

There is no person advocating these ASC/Q codes.  These are ALREADY
APPROVED ASC/Q codes, and the person that caused them to become approved
is no longer part of T10, nor is that company a part of T10 at this
time, so it will be hard to find them and get them to do anything.

In my opinion, we should define their use, and let the e-mail reviews
make sure we get it right (or as good as we can).  Partly because,
contrary to the statement below, the causes of all unit attention
conditions are not "clearly defined".

	Fred Knight


-----Original Message-----
From: Paul Koning [mailto:Paul_Koning@dell.com] 
Sent: Tuesday, March 31, 2009 2:57 PM
To: Black_David@emc.com
Cc: ips@ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions

>>>>> "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

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www.ietf.org/mailman/listinfo/ips