David,
The appendix change is necessary for this
reason:
Suppose the target is running behind a NAT
box. If the NAT box does not support UPnP, then the target has no way to
determine the actual IP address. If the initiator just logged in, then it must
already know the port and IP address.
Eddy
-----Original Message-----
From: Julian Satran
[mailto:Julian_Satran@il.ibm.com]
Sent: Wednesday, September 10,
2003 2:03 AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: 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
>
----------------------------------------------------
