Subject: iSCSI Naming: iqn format specification

From: Mark Bakke <[email-masked]>
Date: Wed, 11 Jul 2001 16:13:35 -0500

During the interim meeting, the following problem with the
iqn (iSCSI qualified name) format was brought up.  From
David's draft notes:

   There is a problem with domain names changing ownership
   without record of what iSCSI names iqns were created by
   the old owner.  This risks unacceptable duplication.
   Suggestions for using IANA private enterprise identifier,
   date, and some sort of existing vendor identifier were made.
   The simple approach of using WWNs runs into administrative
   difficulties like a $1500 fee to get initial allocation.

Anyway, the basic point of the iqn format is to allow hardware
and software vendors, service providers, and possibly end users
to manage their own iSCSI name spaces as they see fit.  To do
so, some sort of naming authority must be used.  To avoid having
to administer naming authorities, we may consider only existing
schemes that are already widely used and understood.  It would
be beneficial to select a scheme where entities in all of the
categories mentioned above (hw, sw, services) will already own
a name or number suitable for use as a naming authority.

Possible schemes include:

1. OUI-based schemes (including EUI-64) - These schemes are all
   based on using the IEEE organizationally unique idenfier.  These
   cost $1250 each, and are 24-bit numbers (22 bits, if also used
   for MAC addresses) assigned for use within MAC addresses and
   similar binary addresses such as EUI-64 WWNs.

   + Works fine for hardware vendors
   + Cannot be re-assigned
   - Most software vendors do not already have OUIs
   - Service providers and end users will not (and probably should
     not) be allocating OUIs.
   - Wastes part of the available MAC address space
   - 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.
   - Companies are not required to make their OUI public;  comparison
     of an OUI with a list of assigned OUIs is not guaranteed to
     determine the naming authority's true identity.

   iSCSI already does provide a way to use EUI-64 addresses as
   an iSCSI name, so this functionality is already there for those
   who wish to use it.  In the end, OUIs are really meant to be
   used for lower-level, hardware-based addresses; iSCSI names identify
   higher-level software entities.  While the hardware-based scheme
   is definitely useful, it is not the most appropriate scheme in
   all cases.

2. Enterprise number

   + They don't cost anything.
   + They are easily obtained from IANA.
   + Some software vendors and service providers already have them.
   + Cannot be re-assigned.
   + Normally expressed as four (soon to be five) digit numbers.
   + Enterprise numbers are public; it is possible to look one up
     in an easily available list to determine a naming authority's
     identity.
   - Less transcribable than a DNS name (but better than an OUI).
   - 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.

3. DNS name

   + Everyone has one; even researchers and universities can create
     their own unique names.
   + More human-friendly; a quick look at an iSCSI name reveals who
     assigned it.
   + More transcribable; it's easier to write down a name than
     a number.
   - Can expire and be re-assigned.

Choice #2 and #3 seem the most useful for naming things that are not
tied strictly to hardware.  The current method is to use the DNS name,
and to reverse it as the Java class hierarchy did to avoid confusion
with an address.  We had not seriously considered enterprise numbers
before the interim meeting.  In our last conference call, we considered
three possibilities for the iqn format:

a. Just keep the DNS name and live with the consequences

   This is what we currently have; the only issue with it is the
   fact that it can expire and be re-assigned, and name collisions
   can result.

b. Ditch the DNS name in favor of an enterprise number

   This might place an unnecessary load on the allocation of
   enterprise numbers by IANA.

c. Use the DNS name format for the best flexibility, but allow the
   inclusion of the enterprise number to eliminate the uniqueness-
   over-time issue.

   This format would look like:

          Ent   Naming      Defined by
    Type   #    Auth       Naming Authority
     +-+ +--+  +------+ +--------------------+
     | | |  |  |      | |                    |

     iqn.5886.com.acme.diskarrays-sn-a8675309

   The optional enterprise number is expressed in decimal between the
   iqn and the DNS naming authority.  Hardware or software companies
   shipping products will generally have an enterprise number, and can
   prefix their reversed DNS name with it; others creating their name-
   spaces can leave out the enterprise number.  Since a component of a
   DNS name cannot start with a digit, there is no risk of confusing
   the two.

So basically, anyone wanting to use an OUI can already do so, using the
EUI-64 format.  Anyone needing to define iSCSI names using the DNS name
format can do so as well.  Anyone wanting to ensure that their names
will never conflict with someone else's can add the enterprise number.

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

---

From: Glen Turner <[email-masked]>
Date: Thu, 12 Jul 2001 10:03:58 +0930

>      In the past year, IANA has assigned about 3,000 enterprise

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

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.

>    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
 [email-masked]          http://www.aarnet.edu.au/
--
 The revolution will not be televised, it will be digitised

---

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

> This also fixes the "load on IANA" problem.

Actually, the load on IANA problem is probably not all that
bad.  Most companies, particularly hardware or software manufacturers,
that want to protect themselves in this way already have an enterprise
number to use in their MIB.

> in universities' private LDAP schema and any private SNMP MIBs.

I agree that OIDs would in theory be more flexible, since they
include enterprise numbers, but in practise most everyone who will
care about this has an enterprise number anyway, and they are
easy to obtain.  I would rather leave it simple.

> Not so, this requirement was removed some time ago.  Consider

I'll fix my text; I meant to say that the first component (com, org, ...)
cannot start with a digit.  The 3com example is still OK, as John
had shown.

> or forbidden to prevent confusion.

OUIs have been removed as a possibility; anyone wanting to use
an OUI should use the eui. format.

>    oid:1.32.43.5.3.2.43.2.2.34

I had suggested this before, in my draft on iSCSI URNs; the IESG
completely shot this down, and I'm still not sure why.  Anyway,
I don't have the energy to push the URN/URI thing any further.

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