Subject: RE: iSCSI: DLB's Comment on SCSI Port Names

From: "Jim Hafner" <[email-masked]>
Date: Tue, 9 Jul 2002 08:13:41 -0700

Marj, David,

After this discussion, I don't have any problem with converting the entire 
SCSI port name to a string.  It's opaque as far as SCSI is concerned in 
any case, so it really doesn't matter.

As for restricting the length of iSCSI Names so iSCS's SCSI port names fit 
256 limit (including null), I have no opinion.
Oh, and Marj: did you get the math right if the ISID is 6 bytes (so 12 hex 
characters)?

Whatever change we make here needs to propogate to Annex A of SAM2 where 
information about these names are specified (for informational purposes 
only). 

As in that Blind Faith song: "do what you like"...

Jim Hafner

To:     Jim Hafner/Almaden/IBM@IBMUS, [email-masked]
cc:     [email-masked] 
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

-----Original Message-----
From: Jim Hafner  [mailto:[email-masked]]
Sent: Monday, July 08, 2002 9:08  AM
To: [email-masked]
Cc:  [email-masked]
Subject: RE: iSCSI: DLB's Comment on SCSI Port  Names

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:         [email-masked] 
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:[email-masked]]
Sent: Monday, July 08, 2002 11:42 AM
To:  [email-masked]
Cc: [email-masked]
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

---

From: Mark Bakke <[email-masked]>
Date: Wed, 10 Jul 2002 13:40:24 -0500

This sounds fine to me as well.  If we are talking about reducing the
max iSCSI name to 249, why not make it an even 240, so we don't have
to fuss with it if ISID turns into 8 bytes someday :-)?

--
Mark

Jim Hafner wrote:
> 
> Marj, David,
> 
> After this discussion, I don't have any problem with converting the entire SCSI port name to a
> string.  It's opaque as far as SCSI is concerned in any case, so it really doesn't matter.
> 
> As for restricting the length of iSCSI Names so iSCS's SCSI port names fit 256 limit (including
> null), I have no opinion.
> Oh, and Marj: did you get the math right if the ISID is 6 bytes (so 12 hex characters)?
> 
> Whatever change we make here needs to propogate to Annex A of SAM2 where information about these
> names are specified (for informational purposes only).
> 
> 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
> 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.
> 
> 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.
> 
> representation in "SCSI  parameter data" (as it says!) -- that is, it's NEVER
> 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

-- 
Mark A. Bakke
Cisco Systems
[email-masked]
763.398.1054