Re: iSCSI version 20 draft

["Mallikarjun C." <cbm@rose.hp.com>]

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

I'm agreeable to your resolution.  Please note it both for sections 6.5
and 10.14.5.  

Thanks!
--
Mallikarjun

Mallikarjun Chadalapaka
Networked Storage Architecture
Network Storage Solutions
Hewlett-Packard MS 5668 
Roseville CA 95747
cbm@rose.hp.com


----- Original Message ----- 
From: <Black_David@emc.com>
To: <cbm@rose.hp.com>; <ips@ece.cmu.edu>
Sent: Friday, January 24, 2003 6:13 PM
Subject: RE: iSCSI version 20 draft


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