Subject: Re: iSCSI Naming: iqn format specification

From: "John Hufferd" <[email-masked]>
Date: Thu, 12 Jul 2001 00:24:46 -0700

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: [email-masked]

Glen Turner <[email-masked]>@ece.cmu.edu on 07/11/2001 05:33:58
PM

Sent by:  [email-masked]

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

---

From: "John Hufferd" <[email-masked]>
Date: Thu, 19 Jul 2001 00:38:14 -0700

Every one can be their own authority with out have to work with some super
entity to get a simple number that is unique when combined with the reverse
DNS.  Dates are ideal for that.  Simple, straight forward and really no
problem.

I vote for Date qualifications instead of Enterprise numbers.  Perhaps a
DDDYY or DDDYYY type format.

.
.
.
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: [email-masked]

Mark Bakke <[email-masked]>@ece.cmu.edu on 07/18/2001 01:31:20 PM

To:   [email-masked], [email-masked]
cc:
Subject:  Re: iSCSI Naming: iqn format specification

To get the draft out, I am going to require the enterprise number.

A second possibility exists; the reversed DNS name could be qualified
by the date on which the iSCSI name was generated.  Since two entities
cannot own the same DNS name at the same time, the separate naming
authorities would not generate these using the same dates.

Anyone want dates instead of enterprise numbers?

--
Mark

Mark Bakke wrote:
>
> Works for me.  Anyone wanting to do their own naming schemes would
> fall into three categories:
>
> 1. iSCSI hardware and software manufacturers
>
>    Most iSCSI names would be generated by these folks; they would
>    make them up either statically (based on a chassis number or
>    something) or dynamically (based on user configuration, but not
>    explicitly configured by the user), or a combination of the two.
>
>    These have their own enterprise # anyway.
>
> 2. Service-minded end-users that want control over naming.
>
>    These are sophisticated enough to want an enterprise number; I
>    anticipate that only folks such as SSPs would want to do this
>    sort of thing; most will leave the manufacturer-assigned names
>    along.
>
> 3. Researchers building iSCSI experimental stuff
>
>    These would not be concerned with being "iSCSI-compliant"; they
>    would simply want to be reasonably sure that they won't conflict
>    with other equipment in a lab environment.  These folks could just
>    use enterprise # 0, along with their reversed domain name, and be
>    reasonably assured of this.
>
> We don't have to mention #3 in the spec, if that's a problem, since
> this decision of iSCSI-compliance would be up to the implementor
>
> --
> Mark
>
> [email-masked] wrote:
> >
> > That would work - REQUIRE the enterprise
> > number and possibly  RECOMMEND that it be
> > followed by the reverse DNS name for
> > human-friendliness.  --David
> >
> > > -----Original Message-----
> > > From: Mark Bakke [SMTP:[email-masked]]
> > > Sent: Monday, July 16, 2001 4:28 PM
> > > To:   [email-masked]
> > > Cc:   [email-masked]
> > > So, should we require the enterprise number?  It's a whole
> > > lot cheaper than getting an OUI.
> > >
> > > [email-masked] wrote:
> > > >
> > > > A couple of comments on this:
> > > >
> > > > > Anyone wanting to ensure that their names
> > > > > will never conflict with someone else's can add the enterprise
number.
> > > >
> > > > Nice try, but not good enough.  If this course is followed the
> > > > enterprise number has to be REQUIRED independent of the whims
> > > > of those who are creating the names so that this conflict can't
> > > > happen, period.
> > > >
> > > > > 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.
> > > >
> > > > What the IESG shot down was the notion of WWUI as a new URN
> > > > namespace into which other namespaces could be glued.  Anyone
> > > > whose reaction to this is "but it's functionally equivalent", has
missed
> > > > the point, and should be thankful that they don't spend all their
time
> > > > on naming issues ;-).  The issues here are syntax, intent, and
> > > > control; the IESG is not prepared to allow the IPS WG to define
> > > > a new global namespace into which the IPS WG could decide
> > > > to glue in other namespaces at its discretion.  AFAIK, the IESG
> > > > would be interested in things like an OUI URN definition (anyone
> > > > want to write a draft? - it should be good for at least 15 minutes
of
> > > > fame).
> > > >
> > > > --David
> > > >
> > > > ---------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > > [email-masked]       Mobile: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > [email-masked]
> > > 763.398.1054
>
> --
> Mark A. Bakke
> Cisco Systems
> [email-masked]
> 763.398.1054

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