Re: [Ips] iSCSI-specific unit attention conditions

Black_David@emc.com Sat, 04 April 2009 03:18 UTC

Return-Path: <Black_David@emc.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 A7ADD3A6869 for <ips@core3.amsl.com>; Fri, 3 Apr 2009 20:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.55
X-Spam-Level:
X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 UrXXnoKvibCK for <ips@core3.amsl.com>; Fri, 3 Apr 2009 20:18:43 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7DA733A6805 for <ips@ietf.org>; Fri, 3 Apr 2009 20:18:43 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id n343Jgn9011060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 23:19:43 -0400 (EDT)
From: Black_David@emc.com
Received: from mailhub.lss.emc.com (numailhub.lss.emc.com [10.254.144.16]) by hop04-l1d11-si01.isus.emc.com (Tablus Interceptor); Fri, 3 Apr 2009 23:19:28 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2/Switch-3.3.2) with ESMTP id n343JR0X004479; Fri, 3 Apr 2009 23:19:27 -0400
Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 23:19:27 -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: Fri, 03 Apr 2009 23:19:26 -0400
Message-ID: <9FA859626025B64FBC2AF149D97C944A024FF25F@CORPUSMX80A.corp.emc.com>
In-reply-to: <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Ips] iSCSI-specific unit attention conditions
Thread-Index: Acmy4bP4cvpmWgG5S1GjUaf5wa5pJwAAfJEAAHl4VdAAAmH+cA==
References: <18899.36208.525150.683459@pkoning-laptop.equallogic.com><AC32D7C72530234288643DD5F1435D530445C9AB@RTPMVEXC1-PRD.hq.netapp.com> <1345AC4A6B8AB74BB5211396D84C746D01ADD77B@ausx3mpc109.aus.amer.dell.com>
To: Kevin_Marks@Dell.com
X-OriginalArrivalTime: 04 Apr 2009 03:19:27.0546 (UTC) FILETIME=[294899A0:01C9B4D4]
X-EMM-EM: Active
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: Sat, 04 Apr 2009 03:18:44 -0000

If retirement is in order, renaming the to-be-retired codes as
vendor-specific to protect their existing usage may suffice.

I believe the original proposer of these codes will be sending
a message to this list to explain what the codes were intended
for and why.

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

> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On 
> Behalf Of Kevin_Marks@Dell.com
> Sent: Friday, April 03, 2009 10:05 PM
> To: Frederick.Knight@netapp.com; Paul_Koning@Dell.com; 
> dcuddihy@attotech.com
> Cc: ips@ietf.org
> Subject: Re: [Ips] iSCSI-specific unit attention conditions
> 
> Fred, 
> 
> 	Whether in use or not, in my ten years of doing T10, I have
> never seen an ASC/Q go obsolete.
> 
> Kevin
> 
> 
> -----Original Message-----
> From: ips-bounces@ietf.org [mailto:ips-bounces@ietf.org] On Behalf Of
> Knight, Frederick
> Sent: Wednesday, April 01, 2009 11:23 AM
> To: Koning, Paul; dcuddihy@attotech.com
> Cc: ips@ietf.org
> Subject: Re: [Ips] iSCSI-specific unit attention conditions
> 
> I've tracked down the people involved in the original 2005 
> T10 proposal,
> and I will try to get them involved (if I can't, I'll at least share
> what I discover).
> 
> T10 will be reluctant to retire these values if they are in use. 
> 
> As mentioned, the use we see for the "ADDRESS CHANGED" event 
> is to cause
> a new discovery process to be initiated (to go find any changes).
> 
> 	Fred
> 
> -----Original Message-----
> From: Paul Koning [mailto:Paul_Koning@Dell.com] 
> Sent: Wednesday, April 01, 2009 11:51 AM
> To: dcuddihy@attotech.com
> Cc: Knight, Frederick; ips@ietf.org
> Subject: Re: [Ips] iSCSI-specific unit attention conditions
> 
> >>>>> "dcuddihy" == dcuddihy  <dcuddihy@attotech.com> writes:
> 
>  dcuddihy> It seems to me that the more important question is how
>  dcuddihy> useful these unit attention codes are.  (For example,
>  dcuddihy> ATTO's Xtend San initiator doesn't make use of them.)  If
>  dcuddihy> initiators don't care about this information, precisely
>  dcuddihy> defining these unit attention codes (instead of depricating
>  dcuddihy> them) will be a change for the worse.
> 
> That's one of my concerns.
> 
> It seems we're just speculating what purpose these codes were intended
> to serve.  Not only don't we know for sure what that purpose was, we
> also don't know if that purpose is actually achieved.
> 
> The other concern is that these codes could be interpreted to impose a
> new requirement on targets to generate them in certain situations.  Of
> course we don't know what those situations are, or why targets should
> do this, but clearly someone could argue that those numbers exist and
> therefore are supposed to be generated.
> 
> Unless there is a solid proposal that assigns a clear meaning, and
> that meaning is valuable to initiators, I believe that the only
> correct answer is to consider what happened as a glitch in the
> standards process and remove, to the extent possible, the debris left
> behind by that glitch.
> 
> I don't see anything in the recent discussion that gets us to this
> clear meaning and useful purpose.  In particular, I see absolutely NO
> trace of "rough consensus and running code" to support the notion that
> the iSCSI standard should support these new codes.
> 
> David, can we put in motion the deprecation of these codes?
> 
>        paul
> 
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www.ietf.org/mailman/listinfo/ips
> _______________________________________________
> Ips mailing list
> Ips@ietf.org
> https://www.ietf.org/mailman/listinfo/ips
> 
>