SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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


Home

Last updated: Wed Sep 10 05:19:29 2003
12880 messages in chronological order