|
Eddy,
I'm sorry,
but that's incorrect. If the target is running "behind a
NAT
box", it is
the responsibility of the administrator(s) of the NAT box
and the
target to assign a stable public-side (of NAT) IP address
to
the target
(which may be mapped to a different private-side IP
address
if the
NAT
is being used for something like renumbering), and
configure
that address
to be returned by SendTargets. Your proposed approach
to
NAT support
will not work for any configurations that have any
additional
complexity
that requires IP addresses to be returned.
If you want
to see iSCSI change to support access through NATs, write
an
Internet-Draft - NAT support changes that result in behavior
on
the wire
changes and potential breakage of initiator code are not
appropriate
for the final 24 hours editorial changes prior to RFC
publication.
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
----------------------------------------------------
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
>
----------------------------------------------------
|
