Re: [Ips] iSCSI-specific unit attention conditions

Ralph Weber <> Sat, 04 April 2009 22:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2C723A6986 for <>; Sat, 4 Apr 2009 15:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c6RaBJ1lM4UY for <>; Sat, 4 Apr 2009 15:24:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DE2723A6964 for <>; Sat, 4 Apr 2009 15:24:19 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpa (Exim 4.69 (FreeBSD)) (envelope-from <>) id 1LqEIj-0001rP-M8 for; Sat, 04 Apr 2009 17:25:23 -0500
Message-ID: <>
Date: Sat, 04 Apr 2009 17:25:13 -0500
From: Ralph Weber <>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-SA-Exim-Version: 4.2
X-SA-Exim-Scanned: Yes (on
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: Sun, 05 Apr 2009 16:21:16 -0000


I suspect you will not see any ASC/Q codes going Obsolete
(or Vendor Specific) this time either.

My opinion is that the original assertion (i.e., that the
definition of an ASC/Q in SPC-x somehow obliges some standard
to define a usage for that value) will not pass muster with
the majority of the CAP working group.

I would not be surprised to find that more than 25% of the
currently defined ASC/Q values have no explicit mention in
any existing standard or working draft. I do not recall
Bill's proposal promising any such in-standard definition.
At the time Bill presented his request, the sense of CAP
favored defining ASC/Q values to provide useful information
(within reason, of course).

Clearly, CAP felt that Bill's request had merit. As of
yet, I have not heard (or read) sufficient justification
for reversing that action.

All the best,

.Ralph wrote:
> 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: [] On Behalf Of
> Knight, Frederick
> Sent: Wednesday, April 01, 2009 11:23 AM
> To: Koning, Paul;
> Cc:
> 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 [] 
> Sent: Wednesday, April 01, 2009 11:51 AM
> To:
> Cc: Knight, Frederick;
> Subject: Re: [Ips] iSCSI-specific unit attention conditions
>>>>>> "dcuddihy" == dcuddihy  <> 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 mailing list