Re: [Ips] iSCSI-specific unit attention conditions
Paul Koning <Paul_Koning@dell.com> Tue, 31 March 2009 19:31 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 BCF763A6899 for <ips@core3.amsl.com>; Tue, 31 Mar 2009 12:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.054
X-Spam-Level:
X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-0.151, 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 BSX-qEMtQthX for <ips@core3.amsl.com>; Tue, 31 Mar 2009 12:31:33 -0700 (PDT)
Received: from aussmtpmrkps320.us.dell.com (aussmtpmrkps320.us.dell.com [143.166.224.254]) by core3.amsl.com (Postfix) with ESMTP id C5D153A6817 for <ips@ietf.org>; Tue, 31 Mar 2009 12:31:32 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.39,303,1235973600"; d="scan'208";a="392934856"
Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 31 Mar 2009 14:32:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <18898.28621.87089.387064@gargle.gargle.HOWL>
Date: Tue, 31 Mar 2009 15:32:29 -0400
From: Paul Koning <Paul_Koning@dell.com>
To: Frederick.Knight@netapp.com
References: <18898.26477.64898.577194@gargle.gargle.HOWL> <AC32D7C72530234288643DD5F1435D530445C53C@RTPMVEXC1-PRD.hq.netapp.com>
X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid
X-OriginalArrivalTime: 31 Mar 2009 19:32:30.0272 (UTC) FILETIME=[6E729C00:01C9B237]
Cc: ips@ietf.org, Black_David@emc.com
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:31:33 -0000
>>>>> "Frederick" == Frederick Knight <Knight> writes: Frederick> My interpretation of the "update" part of the agenda was Frederick> that SAM-4 was an example (and that we should also include Frederick> SAM-3 and SAM-5 as part of the update list). Therefore, Frederick> to add SPC to the update list is (in my opinion) within Frederick> the scope for the SCSI Update portion of this project. Frederick> Yes, it should be included in the charter (either Frederick> specifically, or by making clear the broader Frederick> interpretation of the "update"). Ok, that sounds good. Frederick> There is no person advocating these ASC/Q codes. These Frederick> are ALREADY APPROVED ASC/Q codes, and the person that Frederick> caused them to become approved is no longer part of T10, Frederick> nor is that company a part of T10 at this time, so it will Frederick> be hard to find them and get them to do anything. Frederick> In my opinion, we should define their use, and let the Frederick> e-mail reviews make sure we get it right (or as good as we Frederick> can). Partly because, contrary to the statement below, Frederick> the causes of all unit attention conditions are not Frederick> "clearly defined". I was assuming the person doing the advocating would be the appropriate one to do the defining. If that person isn't around but someone else wants to do the defining, that is fine, too. Part of what bothers me is that I can't fathom what these codes are intended for, or what the scenarios are when they might be generated, or what conclusion an initiator is supposed to draw when it sees one. The names vaguely suggest that they have something to do with asynchronous logout, but that is already fully covered in the iSCSI spec. Itdoesn't require any unit attentions in the first place, certainly not any iSCSI specific ones. I would rather see these things go away, unless there is a good argument made that there is something missing in iSCSI that needs to be added, and these codes are part of the solution. The fact that T10 already approved them isn't a reason to add them to iSCSI. paul
- [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions brown_David1
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions dcuddihy
- Re: [Ips] iSCSI-specific unit attention conditions Paul Koning
- Re: [Ips] iSCSI-specific unit attention conditions Knight, Frederick
- Re: [Ips] iSCSI-specific unit attention conditions Kevin_Marks
- Re: [Ips] iSCSI-specific unit attention conditions Black_David
- Re: [Ips] iSCSI-specific unit attention conditions Bill Galloway
- Re: [Ips] iSCSI-specific unit attention conditions Julian Satran
- Re: [Ips] iSCSI-specific unit attention conditions Ralph Weber