[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: iSCSI - Errata - to 20
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
> > 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
> 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).
> >-port numbers (default unchanged but can be overridden with the system port
> Text is a little unclear - see my separate response to Eddy.
> > Please have look and comment (before we say good bye :-))
> David L. Black, Senior Technologist
> EMC Corporation, 176 South St., Hopkinton, MA 01748
> +1 (508) 293-7953 FAX: +1 (508) 293-7786
> email@example.com Mobile: +1 (978) 394-7754
Last updated: Wed Sep 10 05:19:29 2003
12880 messages in chronological order