RE: iSCSI: Case-sensitivity in iSCSI names

["ERICKSON,SHAWN (HP-Roseville,ex1)" <[e-mail]>]

Have room for one more on that wagon..? Sounds like a good way to go.


-------------------------------------------------------
 Shawn Carl Erickson           [phone] [Telnet]
 Hewlett Packard Company         OV NSSO Joint Venture
  Storage Resource Management R&D Lab (Santa Barbara)
-------------------------------------------------------
            <http://ecardfile.com/id/shawnce>
-------------------------------------------------------


> -----Original Message-----
> From: John Hufferd [mailto:[e-mail]]
> Sent: Tuesday, July 24, 2001 3:34 PM
> To: Jim Hafner
> Cc: [e-mail]
> Subject: Re: iSCSI: Case-sensitivity in iSCSI names
> 
> 
> 
> 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 [phone], Tie: 276-0403,  eFax: [phone]
> Home Office [phone]
> Internet address: [e-mail]
> 
> 
> Jim Hafner/Almaden/IBM@[e-mail] on 07/24/2001 02:24:06 PM
> 
> Sent by:  [e-mail]
> 
> 
> To:   [e-mail]
> 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 <[e-mail]>@ece.cmu.edu on 07-24-2001 12:27:16 PM
> 
> Sent by:  [e-mail]
> 
> 
> To:   Robert Snively <[e-mail]>
> cc:   IPS <[e-mail]>
> 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:    [e-mail]
> > Brocade Communications Systems     phone:  [phone]
> > 1745 Technology Drive
> > San Jose, CA 95110
> 
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: Mark Bakke [mailto:[e-mail]]
> > 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
> > [e-mail]
> > 763.398.1054
> 
> --
> Mark A. Bakke
> Cisco Systems
> [e-mail]
> 763.398.1054
> 
> 
> 
> 
> 
>