Re: iSCSI Naming: iqn format specification

["John Hufferd" <hufferd@us.ibm.com>]

Glen,  I think you missed the simplicities of the name format stuff.

The iqn name begins with the com, or org, etc.  It never begins with a
number.   Example "iqn:com.3com.good.stuff"  With the proposal from the
Naming and Discovery team (that Mark sent to the full list) the item that
makes the String Guaranteed to be unique is adding the enterprise number.
And Mark is right the rest of the name (he meant the reverse DNS format),
never begins with a number so the above example might become
"iqn:1234.com.3com.good.stuff"  however there was/is never a problem of the
reverse DNS ever conflicting with the Enterprise number.  99.999% of the
time the iqn name, without the Enterprise number, will never be a problem.
However, the Naming and Discovery team was requested, at the last
Face-to-Face Meeting, to enhance the approach and come up with a 100%
method for those folks that need/want it.  None of us wanted to give up on
the simplicity of the iqn approach, so a minor extension using Enterprise
number was chosen.  Mark was speaking for the whole Naming and Discovery
team, and stated what we all support.    Most of us will never mess around
with a iSCSI name that needs number, and IMHO that is the right answer.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


Glen Turner <glen.turner@aarnet.edu.au>@ece.cmu.edu on 07/11/2001 05:33:58
PM

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


To:   Mark Bakke <mbakke@cisco.com>
cc:   IPS <ips@ece.cmu.edu>
Subject:  Re: iSCSI Naming: iqn format specification



Mark Bakke wrote:
>
>    - Not everyone has or needs one for other purposes; might cause
>      extra load on IANA-assigned name space, especially if end users,
>      researchers, or university projects start applying for them.
>      In the past year, IANA has assigned about 3,000 enterprise
>      numbers.

I'd suggest altering the syntax to allow for OIDs, not just
IANA-assigned enterprise numbers.  Otherwise people with ISO-
assigned numbers are going to end up holding multiple OID
allocations, which begins to be administratively nightmareish.

This also fixes the "load on IANA" problem.

As a real example, OIDs are required for LDAP schema and each
organisation can be expected to have a unique LDAP scehema (such
as Example Corp having an examplePerson schema).  To reduce the
load on allocation bodies, AARNet already sub-allocates OIDs to
Australian universities out of its ISO allocated space for use
in universities' private LDAP schema and any private SNMP MIBs.

Because of the OID/LDAP linkage, I'd expect DNS registries to
be the ultimate allocators of OIDs.

>    ... Since a component of a
>    DNS name cannot start with a digit, there is no risk of confusing
>    the two.

Not so, this requirement was removed some time ago.  Consider
http://www.3com.com/.

It would thus be better to list the namespace explicitly rather
than make any assumptions about DNS names.  Especially as DNS
naming is going to go through some major changes to allow for
multilingual names.

>  - Less transcribable - OUI normally expressed as six-digit hex
>    number; schemes such as MAC address and EUI-64 are expressed
>    as 12 to 16-digit numbers.

OUIs have a OID form, so the OID form should should be either be required
or forbidden to prevent confusion.

It probably best to treat the OUI as a 12 or 16 hexdigit number.
Using just the OUI is problematic for huge organisations, as they
then need to track iSCSI namespace use internally.  Assigning
a "MAC address" (OUI + 3 octets) to the iSCSI team is easy
administratively.

Finally, we should use the URI name and format for the namespace
where a URI format exists.  This is simply for consistency.

For example:
   backwardsdns:au.edu.example.faculty
   oid:1.32.43.5.3.2.43.2.2.34
   oui:2e319c65786e

Regards,
Glen

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