Subject: Re: iSCSI: Case-sensitivity in iSCSI names

From: "John Hufferd" <[email-masked]>
Date: Tue, 24 Jul 2001 15:34:08 -0700

I want to jump on this bandwagon too.  This seems to be exactly the right
approach.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Home Office (408) 997-6136
Internet address: [email-masked]

Jim Hafner/Almaden/IBM@[email-masked] on 07/24/2001 02:24:06 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: iSCSI: Case-sensitivity in iSCSI names

Mark and Bob,

This looks like exactly what we want.  In short, whatever rules should be
applied to domain names should be applied to iSCSI names.  This seems to be
a very clean way to express that principle.

Thanks Bob!

Jim Hafner

Mark Bakke <[email-masked]>@ece.cmu.edu on 07-24-2001 12:27:16 PM

Sent by:  [email-masked]

To:   Robert Snively <[email-masked]>
cc:   IPS <[email-masked]>
Subject:  Re: iSCSI: Case-sensitivity in iSCSI names

Bob-

Very useful comments.  I had not seen the idn-nameprep draft, and
am somewhat surprised that I missed it when I was looking for this
stuff before.  I just read through nameprep-05, and it looks like
the sort of thing that I had in mind by recommending that names
be generated in lower case of whatever character set was being used.

Anyway, if this is to be used for domain names, we ought to use it,
too.  Any idea when it will be an RFC?

More comments below.

--
Mark

Robert Snively wrote:
>
> I am concerned about this approach for two reasons.
>
> 1)  Name server programs do not allow case insensitivity.
>
> If I understand correctly from my admittedly incomplete experience
> in this area, the names must be entered through an appropriate
> application.  Different systems and applications allowed to enter
> such names may actually create different encodings for each character
> that is represented. As one example, three separate encodings are
> identified in draft-duerst-i18n-norm-04.txt for the character
> LATIN CAPITAL LETTER A WITH RING ABOVE.  Thus, what you typed
> into the system would not be able to be found in a "case-sensitive"
> international environment unless the original name happened to be
> made by a program that used the same encoding, even though the
> characters look identical.  The solution being proposed is that
> all names go through a "NAMEPREP" process described in
> draft-ietf-idn-nameprep-05.txt.  That process maps all
> permitted code points to a normalized code point, including
> forcing the names to be case insensitive.  That is (again if
> I understand it correctly), the character "B" will be mapped to
> the character "b" before it is ever used by a name service program.
> Thus, we are fooling ourselves if we expect a B to be differentiated
> from a b by any compliant name server.

I was hoping that nobody would generate both "B" and "b" anyway, but
the definition in NAMEPREP is much better.

> 2)  Name registration will become painful (and perhaps expensive)
>
> If I understand correctly how domain names are registered, they
> are presently registered by the case-insensitive character
> string.  If I make the name of a SCSI device case sensitive, it
> implies that a name must now be registered in all its case sensitive
> variations.  Thus a company like Cisco must register a minimum
> of three variations of the name, Cisco, CISCO, and cisco to be
> reasonably assured of correct resolution to the domain.  This
> strikes me as a significant complication of the registration
> process.

OK

> Assuming I have understood this environment correctly, I see two
> possible solutions to these problems.
>
> 1)  My original thought was to make the names using manufacturer
>     established invariant binary values, using an appropriate
>     World-Wide-Name like the EUI-64.  Those have the benefit
>     of being internationalized to all countries that use
>     binary or hexadecimal numbers.  They have the inconvenience
>     of requiring an installation process that maps them to
>     a locally assigned user-friendly name, but those installation
>     processes would normally be automated anyway.  The user-friendly
>     name would probably be the domain name of the local network
>     modified by appropriate locally assigned variables.
>
>     This is in some sense like the Ethernet MAC names which are
>     world-wide unique invariant formats that are mapped to
>     convenient IP addresses and domain names.

This is allowed in iSCSI names by using the "eui" format, for
those who can use EUI-64.

> 2)  Since my original thought has long ago been discarded by

This wasn't thrown out; it is still there, and fully supported.  It
just didn't meet everyone's requirements.  I would expect different
types of products to use EUI-64 than the other mechanisms.

>     the naming committee, then I think we must at least require
>     that the names be unique within the context of the NAMEPREP
>     character mappings, which include not only case insensitivity,
>     but the mapping of many specialized characters to normalized
>     characters.  This context also requires the prohibition of
>     certain characters.
>
>     This is equivalent to rewording Mark's stated rule:
>
>         - iSCSI names SHOULD be generated in a
>         case-insensitive manner.
>
>     to say instead:
>
>         - iSCSI names SHALL be generated using the normalized characters
>         that would be generated by processing through NAMEPREP.

I really like this; it is a much stronger statement, and NAMEPREP can
remove some of the ambiguity of "case-insensitive manner".

>     This has the advantage of allowing direct comparison,
>     but requires some thought during the generation of the names.
>
> It seems to me that these are the only two approaches that do not
> require the installation of the NAMEPREP pre-processing in the
> compare function.

The thing I really like about this is that anyone comparing iSCSI
names does not have to worry about any of this stuff; a byte-compare
is all that's needed.  Anyone generating the names only needs to
put in NAMEPREP if the names are based on a source that might need
to be mapped.  Anyone building user interfaces for this stuff has
the option to put in NAMEPREP to make things easier for their users,
but can decide this on their own.

> References that I found useful in this include:
>
>         draft-duerst-i18n-norm-04.txt
>         draft-ietf-idn-idne-02.txt
>         draft-ietf-idn-nameprep-05.txt
>         draft-skwan-utf8-dns-06.txt

Anyway, thanks for the reference.

--
Mark

> Bob Snively                        e-mail:    [email-masked]
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110

> -----Original Message-----
> From: Mark Bakke [mailto:[email-masked]]
> Sent: Tuesday, July 17, 2001 1:29 PM
> To: IPS
> Subject: iSCSI: Case-sensitivity in iSCSI names
>
> We are attempting to wrap up all of the issues surrounding
> the creation and comparison of iSCSI initiator and target
> names.  One of these is whether the names are case-sensitive.
>
> The last naming & discovery draft stated that the names are
> case-insensitive; this was to allow better transcribability
> in cases where names were communicated outside the automated
> discovery processes.
>
> This comes at some expense, particularly since these names
> are defined to allow UTF-8 encoding of international character
> sets.  Initiators and targets would have to include code to
> compare these sets.
>
> To simplify implementation and interoperability, it has been
> recommended that we make iSCSI names case-sensitive instead.
>
> I am fine with doing this, and I think that we could even
> get some of the usability back by adding these rules:
>
> - iSCSI names MUST be case-sensitive, and compared strictly
>   byte-for-byte.
>
> - iSCSI names SHOULD be generated in a case-insensitive
>   manner.
>
> I'm not sure how to properly word the latter, but the intent
> is that someone generating the names would not produce both:
>
>   iqn.9.com.cisco.myiscsithing
>
> and
>
>   iqn.9.com.cisco.MyIscsiThing
>
> since a user would be likely to confuse these.  Again, it doesn't
> affect the protocol itself, just its usability.
>
> Any thoughts?  Will it hurt anyone's plans if iSCSI names were
> case-sensitive?
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

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

---

From: Glen Turner <[email-masked]>
Date: Wed, 25 Jul 2001 17:33:40 +0930

> I want to jump on this bandwagon too.  This seems to be exactly the right

I'm showing some caution.

It seems that NAMEPREP still requires casing tables.  Where
and how are these maintained?

Does the proposal lead to language-based variants of
iSCSI products.  At the moment I can safely buy a
hard disk drive from the USA and use it anywhere in
the world: IDE, FC or SCSI.  That should be so for
iSCSI.

Mark wrote:
> too.

Except that no-one is suggesting embedding DNS in a platform
that won't be maintained after sale.

Before support one way or the other I'd like to be
clearer about the boundaries of iSCSI naming.

Regards,
Glen

-- 
 Glen Turner                                 Network Engineer
 (08) 8303 3936      Australian Academic and Research Network
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised

---

From: Mark Bakke <[email-masked]>
Date: Thu, 26 Jul 2001 08:32:16 -0500

> and how are these maintained?

NAMEPREP casing only needs to be done when the iSCSI name 
is assigned, and it can be simplified in some cases, such
as when names are generated using only ASCII.  Since the
assignor of the names completely controls which character
sets are used, it can include the appropriate normalization
code:

- If the names are just generated using lower-case (in any
  character set) plus digits, no normalization is required.

- If the names are generated from some other all-ASCII string,
  tolower() normalizes and isalnum() verifies.

- If the names are generated from more general, internationalized
  text, either the equivalent of tolower() and isalnum() appropriate
  to the character set may be used, or the NAMEPREP procedure
  that Bob sent in his last email can be used.

In any case, it is at the complete discretion of the naming
authority that generates the name whether to use one of the
above methods.  It can be kept very simple (first or second
method), or include case tables to make it more user-friendly.

User-friendly naming conventions are an option, and they always
cost something.
 
> the world: IDE, FC or SCSI.  That should be so for

That's still the case.  An iSCSI name that is not in the
NAMEPREP-normalized form MUST NOT be used within the iSCSI
protocol.  Therefore, all compares on iSCSI names are opaque
and byte-for-byte, so it doesn't matter where the device
is manufactured, or in what locale it is used.

--
Mark7

> clearer about the boundaries of iSCSI naming.

Hopefully, the above helps.

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