Message-ID: <277DD60FB639D511AC0400B0D068B71E0564C823@corpmx14.us.dg.com>
From: Black_David@emc.com
To: cbm@rose.hp.com, ips@ece.cmu.edu
Subject: RE: iSCSI version 20 draft
Date: Fri, 24 Jan 2003 21:13:57 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ips@ece.cmu.edu
Precedence: bulk

> > I disagree, Section 5.9.1.2 of SAM-2 (sam2r24) says:
> > 
> >   When a device server terminates a command with a CHECK CONDITION
status,
> >   either an CA or ACA condition is established within the task set.
> > 
> > That's sufficient language to cause establishment of ACA.
> 
> Completely agreed wrt ACA.  But let's be careful wrt UA interlock,

Ok, that's progress - Rob's first paragraph on ACA is not needed.

> > This creation of a new unit attention to deal with this situation
> > (e.g., so that an initiator can control command ordering in these
> > implicit termination cases without resorting to ACA) is a functional
> > addition to iSCSI, complete with assignment of a new unit attention
> > code; it does not appear to fix anything that is broken. 
> 
> IMHO, a UA is *not* a "functional addition" to iSCSI, a UA has been 
> in the iSCSI spec for several months!
> 
> There are a couple of options I can think of to deal with this -
> 
> A. Rob's UA text with the original (rev19) ASC/ASCQ values.
> B. Rob's UA text with no ASC/ASCQ values.
> C. Rob's UA text with his proposed ASC/ASCQ values.
> 
> Perhaps your comment is specifically about Option.C.  I can agree with
> you on that procedural aspect.  Out of A and B, I have a mild preference
> for A (because I believe there's some value in consistency across
> all targets, for an initiator), but I'd be okay with Option.B.

I observe that option B is almost implied by the text in -20, which
refers to UA for the next command for the 3 cases in which the I_T
nexus stays up.  I have major problems with introducing new ASC/ASCQ
values at this juncture, even though T10 apparently intends to provide
them, making the -19 ASC/ASCQ values inappropriate to specify.

I will see about taking the first sentence of Rob's second paragraph,
stripping the ASC/ASCQ values, and seeing if it can be inserted via an
RFC Editor note after IESG approval to restore the unit attention
requirement situation that was present in -19, something like:

	In cases a), b), and c), after the tasks are terminated, the
	target MUST report a unit attention condition on the next command
	processed on any connection for each affected I_T_L nexus.

This would replace the UA text in parentheses:

	UA for the next command on the I_T nexus in cases a), b), and c)

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
black_david@emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------