Re: [Ips] iSCSI-specific unit attention conditions

["Knight, Frederick" <Frederick.Knight at netapp.com>]

My interpretation of the "update" part of the agenda was that SAM-4 was
an example (and that we should also include SAM-3 and SAM-5 as part of
the update list).  Therefore, to add SPC to the update list is (in my
opinion) within the scope for the SCSI Update portion of this project.

Yes, it should be included in the charter (either specifically, or by
making clear the broader interpretation of the "update").

There is no person advocating these ASC/Q codes.  These are ALREADY
APPROVED ASC/Q codes, and the person that caused them to become approved
is no longer part of T10, nor is that company a part of T10 at this
time, so it will be hard to find them and get them to do anything.

In my opinion, we should define their use, and let the e-mail reviews
make sure we get it right (or as good as we can).  Partly because,
contrary to the statement below, the causes of all unit attention
conditions are not "clearly defined".

	Fred Knight


-----Original Message-----
From: Paul Koning [mailto:Paul_Koning at dell.com] 
Sent: Tuesday, March 31, 2009 2:57 PM
To: Black_David at emc.com
Cc: ips at ietf.org
Subject: Re: [Ips] iSCSI-specific unit attention conditions

>>>>> "Black" == Black David <Black_David at emc.com> 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:

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

_______________________________________________
Ips mailing list
Ips at ietf.org
https://www.ietf.org/mailman/listinfo/ips