Re: iSCSI-specific unit attention conditions
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@xxxxxxx Mobile: +1 (978) 394-7754
----------------------------------------------------
> -----Original Message-----
> From: ips-bounces@xxxxxxxx [mailto:ips-bounces@xxxxxxxx] On
> Behalf Of Kevin_Marks@xxxxxxxx
> Sent: Friday, April 03, 2009 10:05 PM
> To: Frederick.Knight@xxxxxxxxxx; Paul_Koning@xxxxxxxx;
> dcuddihy@xxxxxxxxxxxx
> Cc: ips@xxxxxxxx
> Subject: Re: 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@xxxxxxxx [mailto:ips-bounces@xxxxxxxx] On Behalf Of
> Knight, Frederick
> Sent: Wednesday, April 01, 2009 11:23 AM
> To: Koning, Paul; dcuddihy@xxxxxxxxxxxx
> Cc: ips@xxxxxxxx
> Subject: Re: 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@xxxxxxxx]
> Sent: Wednesday, April 01, 2009 11:51 AM
> To: dcuddihy@xxxxxxxxxxxx
> Cc: Knight, Frederick; ips@xxxxxxxx
> Subject: Re: iSCSI-specific unit attention conditions
>
> >>>>> "dcuddihy" == dcuddihy <dcuddihy@xxxxxxxxxxxx> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ips
> _______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ips
>
>
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ips
[IETF]
[Linux iSCSI]
[Linux SCSI]
[Linux Resources]
[Yosemite News]
[IETF Announcements]
[IETF Discussion]
[SCSI]