Subject: [Ips] iSCSI-specific unit attention conditions

From: [email-masked]
Date: Mon, 30 Mar 2009 10:25:12 -0400

Here's another piece of "housekeeping" for the new STORM WG-to-be
- I've been informed by a knowledgeable T10 participant that:

> T10 proposal 05-406 (from Bill Galloway, Pivot3) added 3
> iSCSI-specific unit attention condition additional sense codes
> in SPC-4:
> 	- 3Fh/12h iSCSI IP ADDRESS ADDED
> 	- 3Fh/13h iSCSI IP ADDRESS REMOVED
> 	- 3Fh/14h iSCSI IP ADDRESS CHANGED
> 
> r0 used a more generic "DEVICE PORT ADDRESS" phrase, but r1
> changed that to "iSCSI IP ADDRESS" upon recommendation by the
> [T10] CAP WG.
> 
> However, there is no mention in any standard of when these are
> used (unlike all the other unit attention conditions, whose causes
> are clearly defined).  With the accepted names, that belongs in
> iSCSI itself.
 
FWIW, these ASC/Q value pairs appear to have been added to SPC-4
without any cross-checking with the IETF, which would serve to
explain why there is no documentation anywhere about when or how
to use them.  Since these ASC/Qs are iSCSI-specific, that task
falls to the iSCSI specification(s), unless these ASC/Qs are
removed or have their names changed to no longer be iSCSI-specific.

Hence: 
- the "new features" STORM draft should explain how to use these
	ASC/Qs
--- AND/OR ---
- discussion here and in the to-be-formed storm WG should generate
	a proposal to T10 about what should change and why.

If these ASC/Q pairs remain and remain iSCSI-specific, they may be
the first feature beyond SAM-4 that goes into the "new features"
STORM draft.

This situation was originally pointed out to me about a year ago,
and there was some private discussion at that time.  This is an
opportunity for the participants in that discussion to express
their views on what should be done and why (as we now have a vehicle
to document their use with iSCSI *if* we choose to do so). 

FYI,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: Paul Koning <[email-masked]>
Date: Mon, 30 Mar 2009 11:39:08 -0400

I am somewhat puzzled by the notion of T10 defining iSCSI things.  Did
these things receive any discussion on the IPS list?  If not,
shouldn't that happen first?

It seems to me that IPS should ask T10 for iSCSI related changes, not
the other way around.  And nothing should be added without a
description of how it is supposed to be used.

    paul

---

From: [email-masked]
Date: Mon, 30 Mar 2009 12:35:39 -0400

Paul,

> I am somewhat puzzled by the notion of T10 defining iSCSI things.
> Did these things receive any discussion on the IPS list?  If not,

Not to my knowledge, and (IMHO) yes.  The proposer of these ASC/Qs
to T10 appears to have dropped the ball in that regard.

In T10's defense, they do try to be accommodating, as there are SCSI
transport-related conditions and errors that can only realistically
be made visible as SCSI errors or unit attentions.  

> It seems to me that IPS should ask T10 for iSCSI related changes,
> not The other way around.  And nothing should be added without a

I agree that this is how it should work, but these ASC/Qs seem to
have slipped by and now need to be cleaned up one way or another.

FWIW, there's one more iSCSI-specific ASC/Q:

	47h 7Fh SOME COMMANDS CLEARED BY ISCSI PROTOCOL EVENT

This ASC/Q was added to deal with task side effects of some iSCSI
error handling; use of this ASC/Q is documented in Sections 6.5
and 10.14.5 of RFC 3720.

Thanks,
--David

---

From: Paul Koning <[email-masked]>
Date: Tue, 31 Mar 2009 14:56:45 -0400

>>>>> "Black" == Black David <[email-masked]> writes:

 Black> Here's another piece of "housekeeping" for the new STORM
 Black> WG-to-be - I've been informed by a knowledgeable T10
 Black> participant that:

 >> iSCSI-specific unit attention condition additional sense codes in
 >> SPC-4: - 3Fh/12h iSCSI IP ADDRESS ADDED - 3Fh/13h iSCSI IP ADDRESS
 >> REMOVED - 3Fh/14h iSCSI IP ADDRESS CHANGED
 >> 
 
 Black> FWIW, these ASC/Q value pairs appear to have been added to
 Black> SPC-4 without any cross-checking with the IETF, which would
 Black> serve to explain why there is no documentation anywhere about
 Black> when or how to use them.  Since these ASC/Qs are
 Black> iSCSI-specific, that task falls to the iSCSI specification(s),
 Black> unless these ASC/Qs are removed or have their names changed to
 Black> no longer be iSCSI-specific.

 Black> Hence: - the "new features" STORM draft should explain how to
 Black> use these ASC/Qs --- AND/OR --- - discussion here and in the
 Black> to-be-formed storm WG should generate a proposal to T10 about
 Black> what should change and why.

I would suggest the following.

1. The person advocating these ASC/Q codes should propose a new work
   item for STORM to add this new feature.  It first needs to be added
   to the charter, then a new I-D needs to be generated to describe
   it.  It doesn't belong in the other work items because it's neither
   cleanup nor (as far as I can tell) SAM-4 support.

2. If #1 isn't done or the proposal doesn't receive WG consensus,
   STORM should generate a liaison request to T10 asking for these
   ASC/Q codes to be removed, or deprecated, or otherwise relabeled 
   to make it clear that they are not defined by the iSCSI standard.

       paul

---

From: Paul Koning <[email-masked]>
Date: Tue, 31 Mar 2009 15:32:29 -0400

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

---

From: [email-masked]
Date: Tue, 31 Mar 2009 16:11:34 -0400

Maybe this is obvious to the T10 folks in the audience, but . . . Since
these unit attentions use an ASC of 3F, they indicate a change to the
operating state of the device.  No commands are affected.  From the
concise wording of the 05-406 proposal, it's hard to be sure what the
author intended, but it sounds to me like the target is telling the
initiator about a change in the membership of the portal group.

Might be caused by a configuration change, possibly by hot-plugging
another network interface card into the target system. 

DJ Brown

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Koning
Sent: Tuesday, March 31, 2009 3:32 PM
To: [email-masked]
Cc: [email-masked]; Black, David
Subject: Re: [Ips] iSCSI-specific unit attention conditions

Ok, that sounds good.

	paul

_______________________________________________
Ips mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ips

---

From: "Knight, Frederick" <[email-masked]>
Date: Tue, 31 Mar 2009 17:38:12 -0400

"No commands are affected."

The command which receives this response is NOT executed, and must be
reissued by the initiator.  True, no command other than the one that
receives this response is affected.

My guess from reading 05-406 is that the target is simply telling the
initiator that it is time to reissue a SendTargets (redo discovery).  My
guess is that all 3 ASC/Qs would be handled by the host in the same way
- something change (ala RSCN), so go find out what.  I can't tell from
the proposal why there needs to be 3 different reports
(add/remove/change); it seems that "change" is really all that might be
needed.  So, it's possible my guess about the original intent is missing
something.

	Fred 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, March 31, 2009 4:12 PM
To: [email-masked]; Knight, Frederick
Cc: [email-masked]; [email-masked]
Subject: RE: [Ips] iSCSI-specific unit attention conditions

DJ Brown

-----Original Message-----

 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.

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.

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