|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: Case-sensitivity in iSCSI namesHave room for one more on that wagon..? Sounds like a good way to go. ------------------------------------------------------- Shawn Carl Erickson (805) 883-4319 [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:hufferd@us.ibm.com] > Sent: Tuesday, July 24, 2001 3:34 PM > To: Jim Hafner > Cc: ips@ece.cmu.edu > 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 (408) 256-0403, Tie: 276-0403, eFax: (408) 904-4688 > Home Office (408) 997-6136 > Internet address: hufferd@us.ibm.com > > > Jim Hafner/Almaden/IBM@IBMUS@ece.cmu.edu on 07/24/2001 02:24:06 PM > > Sent by: owner-ips@ece.cmu.edu > > > To: ips@ece.cmu.edu > 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 <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 > > > > > >
Home Last updated: Tue Sep 04 01:04:13 2001 6315 messages in chronological order |