RE: iSCSI - Errata - to 20

["Julian Satran" <Julian_Satran@il.ibm.com>]

Thanks - minor comments in text - Julo

Black_David@emc.com wrote on 10/09/2003 03:32:07:

> I've reviewed the set of changes on Julian's web site.
> Here are my comments, explanations, and instructions in some cases.
> 
> > -several editorial glitches (wording, typos)
> 
> One of these glitches was a mistake in the specification of TASK REASSIGN
in
> Section 10.5.1.  I suspect there are very few implementations
of this, as
> anyone who tried should have discovered that the wording was reflexive
-
> "Initiator Task Tag" refers to the Task Management Request
itself, making it
> only possible to reassign the TASK REASSIGN Request (oops).  That's
clearly
> broken, and the fix is to change to "Referenced Task Tag".
> 
> Section 10.17.3 adds a sentence to say that StatSN is advanced by
a Reject.
> I don't believe that changes behavior and it is a useful clarification.
> 
> The third paragraph in Appendix D relaxes the requirements on the
amount
> of info returned by SendTargets when there is only one target.  While
> reasonable in design intent, this may break initiator code that is
not
> expecting to be short-changed in this fashion, and hence I think this
> change should not be made (but I'll listen to strong counterarguments).
> 
I am sorry - I added inadvertently this text when
looking over and trying to digest all TargetPortalTag key and value usages.
I did no realize the "break scenario" you suggested.
> > -version raised to 0x01 (that was agreed/dictated on the list
to happen
> > when RFC is issued to distinguish RFC-level from pre RFC level).
> 
> As stated earlier, this change to Section 10.12.4 is NOT to be made.
> 
> > -IESG required text for CHAP administrative domains
> 
> Important catch, thanks.
> 
> > -clarifying that some chap keys that can have in theory an arbitrary
> number
> > of bits have in iSCSI a length that is a multiple of 8bits
> 
> This was done by disallowing keys that don't have an appropriate length.
 At
> this stage, I think this is ok vs. the alternative of requiring padding,
> esp. as a party who's confused enough to send a weird length key may
also
> be confused enough to get the padding wrong.  I think this falls
into the
> "clearly broken, needs to be fixed" category.
> 
> There are also a number of clarifications to the CHAP text in 11.1.4
that
> are ok as they make the required behavior more explicit.
> 
> > -clarifying that TargetPortalGroup does not have to be returned
in some
> cases
> 
> This does change on-the-wire behavior, but only by removing the requirement
> to return this value in cases where it is clearly of no use to the
party
> who receives it.  I believe this is ok, but will listen to objections.
> 
> > -the UA related text for abort (in both relevant places)
> 
> Once WG Last Call closes on the command ordering draft (assuming it
closes
> without objection to this point) a sentence saying which ASC/ASCQ
code T10
> has defined for this case needs to be added in both places.
> 

I think that the agreement reached at the time was
that we won't  give the codes (other SCSI documents do the same -
the argument being to minimize fixes needed in case of change).

> -references 
> >-port numbers (default unchanged but can be overridden with the
system port
> 860)
> 
> Text is a little unclear - see my separate response to Eddy.
> 
> > Please have look and comment (before we say good bye :-)) 
> 
> Done,
> --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
> ----------------------------------------------------