Re: iSCSI: Case-sensitivity in iSCSI names

["Jim Hafner" <hafner@almaden.ibm.com>]

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 <mbakke@cisco.com>@ece.cmu.edu on 07-24-2001 12:27:16 PM

Sent by:  owner-ips@ece.cmu.edu


To:   Robert Snively <rsnively@Brocade.COM>
cc:   IPS <ips@ece.cmu.edu>
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:    rsnively@brocade.com
> Brocade Communications Systems     phone:  408 487 8135
> 1745 Technology Drive
> San Jose, CA 95110






> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> 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
> mbakke@cisco.com
> 763.398.1054

--
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054