|
Julo,
I'm a bit confused as the issues list on your website does not have this
as issue 37, and all I see is issue 9 (where your comment appears to imply "no
change"?)
In any case, here's what I recommend:
In sec 1.1 Definitions change the following definitions
to:
I_T Nexus: the last sentence should be
The I_T nexus can be identified by the
conjunction of the SCSI port names; that is, the I_T nexus identifier is
the tuple (iSCSI Initiator Name + ',i,'+ ISID, iSCSI Target Name +
',t,'+ Portal Group Tag).
SCSI Port Name: definition should be
A name made up as UTF-8 characters and
includes the iSCSI Name + ',i,' or ',t,' + ISID or Portal Group
Tag
In sec 2.2.7, 1st paragraph, delete the comment in parenthesis starting
with "(for iSCSI,.." (or change it to point it to section 2.4.2, your
choice).
In sec 2.4.2, change the text to:
When
used in SCSI parameter data, the SCSI port name MUST be encoded
as:
- The iSCSI Name in UTF-8 format, followed
by
- a comma separator (1 byte), followed
by
- the ASCII character 'i' (for SCSI
Initiator Port) or the
ASCII character
't' (for SCSI Target Port), followed by
- a
comma separator (1 byte), followed by
- A string representation
(<numerical-value>, see section 4.1 Text
Format)
of
the ISID (for SCSI initiator port) or the portal group tag (for SCSI
target port).
SCSI port names have a
maximum length of 255 bytes.
The ASCII character
'i' or 't' is the label that identifies this port
as either a SCSI
Initiator Port or a SCSI Target Port.
The 255 max port name makes for a 237 max iSCSI node name (check my math
Jim :-) as the max character representation of an ISID is 15 characters for the
largest decimal representation (14 char for the largest hex), + 3 char (",i,") +
237 = 255
The change in max node name causes changes to:
sec 2.2.6.1, paragraph 2,
sec 2.2.6.2, 2nd p, 3rd bullet
I will see that a change is proposed to Annex A in whatever SAM doc
is currently under revision.
Thanks,
Marjorie Krueger
Networked Storage
Architecture
Networked Storage Solutions
Org.
Hewlett-Packard
Marjorie,
I'll list this as issue 37 and I think we can
settle on 249 :-)
I would appreciate if you let me know what
constants change (in 2.4.2?)
Julo
----- Original Message -----
Sent: Tuesday, July 09, 2002 4:04
AM
Subject: RE: iSCSI: DLB's Comment on
SCSI Port Names
I've just encountered this issue with regards to
iSCSI port name encoding in the SCSI MIB, and the currently specified port
name encoding causes inconvenience (at best). IMO, it makes sense to
be able to treat an iSCSI name field, be it device name or port name, the
same - as a string of display characters, portions of which may contain
ASCII-encoded numeric values.
I don't really see that it makes a difference
whether one views ISID and TPGT as numeric strings or values, since as Jim
says, there are no calculations performed using these things, and they are
basicly just "tags". The issue for me is that the rest of the "SCSI
port name" is a string and I see no value in "encoding" the ISID or TPGT as
a value for SCSI purposes, as SCSI should have no need to use the ISID or
TPGT values separately from the entire port name. And even if SCSI had
such a need, it's a simple matter to convert a numeric string representation
to a value.
The downside of a string-encoding is the increased maximum size of the SCSI
port name.
If strings over 256 characters are a problem for
some platforms, I'd be in favor of reducing the max iSCSI node name to 249
characters so the maximum SCSI port name would be 255 characters total (249
char name + ",i," + "0x0000")
Marjorie Krueger
Networked Storage
Architecture
Networked Storage Solutions
Org.
Hewlett-Packard
David,
I believe it will (may?) be used, so
I agree we're in the second case. However, this format is the
intended use in SCSI protocol stuff. Two places where SCSI ports
names are used now is in ALIAS, Access Controls and in third party
reservations -- see caveat below, however)
I don't see a need in this context to define these
as strings (that's not a SCSI way of thinking...).
However, I think the issue
comes down to a simple question: are the ISID and TPGT values or
numerical strings (Julian is calling them numerical strings, but I've
always thought of them as values, in spite of the fact that there is no
arithmetic done on them - there is precedent in SCSI for such thinking, so
I'm not completely out in the woods here).
If they are values, then I'd like to see them
formatted for SCSI in "value form"; if they are strings, then any
representation should be OK.
Does that at least get to the core of the issue?
Jim
Hafner
CAVEAT: I don't think
we'd use the iSCSI constructed port names in those contexts as device
names are better suited for those purposes, but these are examples where
specification of SCSI port name format is required.
To:
Jim
Hafner/Almaden/IBM@IBMUS
cc: ips@ece.cmu.edu
Subject:
RE: iSCSI: DLB's
Comment on SCSI Port Names
Jim,
My view of this is
that either:
- The SCSI Port Name is never going to be used, in which
case
it shouldn't be designed to this
level of detail. OR
- It's going to be used, and hence is worth
designing in a fashion
that is reasonable
to use.
I think we're in the second category, and turning the ISID
into
hex ASCII (well, UTF-8) so the SCSI port name is a string
is
worth doing now to avoid problems when people actually try
to use
it. I would have no problems if someone wanted to
pad the string,
but I'd make specifying the padding the
responsibility of the
protocol/API/situation in which it
was used rather than incorporating
the padding into the name.
Thanks,
--David
-----Original Message-----
From: Jim Hafner
[mailto:hafner@almaden.ibm.com]
Sent: Monday, July 08, 2002 11:42
AM
To: Black_David@emc.com
Cc: ips@ece.cmu.edu
Subject: Re:
iSCSI: DLB's Comment on SCSI Port Names
David,
You
wrote:
>[T.9] 2.4.2 SCSI
Architecture Model
>
> The SCSI Port Name is mandatory
in iSCSI. When used in SCSI
> parameter data, the SCSI port
name MUST be encoded as:
> - The iSCSI Name in UTF-8 format,
followed by
> - a comma separator (1 byte), followed
by
> - the ASCII character 'i' (for SCSI Initiator Port) or
the
> ASCII character 't' (for SCSI Target Port),
followed by
> - a comma separator (1 byte), followed
by
> - zero to 3 null pad bytes so that the complete format is
a
> multiple of four bytes long, followed by
>
- the 6byte value of the ISID (for SCSI initiator port) or
the
> 2byte value of the portal group tag (for SCSI
target port) in
> network byte order
(BigEndian).
> That's a peculiar
format with padding nulls in the middle and
> a number concatenated
after the padding - for example, it can't
> be passed in iSCSI login
without format conversion. How about
> converting the number
to 4 or 12 bytes of hex (ASCII characters)
> and moving the padding
to the end so the result is actually a
> string, and excluding the
padding from the definition of the name?
> This will increase the
maximum length of port names, but produce
> names that are easier to
deal with.
Admittedly that's an odd
format, however here was the reason for this
layout.
1) it's not
used directly in iSCSI "Text" strings; it's intended to be
a
description of how this information is packed into a byte array
for
representation in "SCSI parameter data" (as it says!) -- that is,
it's NEVER
"passed in iSCSI login" (in this form).
2) the padding
after the string was to force the binary values of the ISID
or PGT to
be better word aligned and can be more easily extracted as a
value
direct from the byte array without
conversion.
What do you
think?
Jim Hafner
|
