[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ips] iSCSI-specific unit attention conditions

Kevin,

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

Kevin_Marks at Dell.com 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: ips-bounces at ietf.org [mailto:ips-bounces at ietf.org] On Behalf Of
Knight, Frederick
Sent: Wednesday, April 01, 2009 11:23 AM
To: Koning, Paul; dcuddihy at attotech.com
Cc: ips at 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 at Dell.com] Sent: Wednesday, April 01, 2009 11:51 AM 
To: dcuddihy at attotech.com
Cc: Knight, Frederick; ips at ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions


"dcuddihy" == dcuddihy  <dcuddihy at 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 at ietf.org
https://www.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips at ietf.org
https://www.ietf.org/mailman/listinfo/ips