Re: iSCSI Naming: WWUIs, URNs, and namespaces

[Mark Bakke <mbakke@cisco.com>]

Doug-

We are using a reversed domain name as a naming authority -- something
that you "own" that you can use to guarantee that your locally-generated
names are world-wide unique.

Users of a WWUI will under no circumstances attempt to turn one of these
into an address.

Please re-read the naming & discovery draft section on this format; it
spells this out quite clearly, since we realized early that this would
be a source of confusion.

--
Mark


Douglas Otis wrote:
> 
> David,
> 
> If Microsoft responds by using a NetBIOS node-status query see:
> http://support.microsoft.com/support/kb/articles/Q154/5/53.ASP
> perhaps you can see why dependence on reverse DNS is prone to errors and
> spoofing in general.
> 
> You have stated at the IETF meeting there is no need for configuration
> management tools to be interoperable and as such there is no need for there
> to be any defined schema to support these naming conventions or
> configuration structures.
> 
> Rather than using Name->IP->Reverse-Name as a means of getting the desired
> result, an LDAP schema will allow these types of associations without the
> need to invent new or modified name servers.  Unless a schema is defined,
> each required utility will be based on proprietary schema that will not
> interoperate with other pieces of equipment from other vendors.  The ability
> of this equipment to interoperate without proprietary intervention should be
> a requirement and of course LDAP already provides the means of promulgating
> changes across multi-vendor environments.  Insisting such vital components
> remain vendor unique is a major disservice to the needs of all affected
> parties.  With this schema defined, the naming issues are cleanly closed
> where SLP as example can then leverage this information and changes emerge
> as LDAP slave notifications.  LDAP does not need to be large, can be
> embedded, and allowed to contain only a portion of the information relevant
> to a switch.
> 
> Doug
> 
> > Mark,
> >
> > I need to read your note in more detail before
> > I can respond completely, but we may be close
> > to a solution here.  At a high level, the notion
> > of the WWUI as yet another globally unique
> > namespace (which is what it is, even if it's
> > assembled by gluing in existing namespaces)
> > needs to go away.  The set of {canonical
> > iSCSI, eui[WWN], reverse-dns} as usable namespaces
> > may be the right way forward, especially as it
> > looks like you've made a good start on the
> > rationale required to justify reverse DNS.
> >
> > We need to describe how to uniquely identify
> > Initiators and Targets without introducing
> > the notion of a WWUI as a new first-class
> > global unique identifier abstraction (e.g.,
> > that some other set of people may try to
> > use and/or extend).  In other words, we
> > need to scrap the current WWUI structure
> > without losing the important functionality
> > that iSCSI needs in this area.  Some amount
> > of this may just be word-smithing to avoid
> > unnecessarily waving red flags ...
> >
> > More to come ...
> >
> > --David
> >
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > black_david@emc.com       Mobile: +1 (978) 394-7754
> > ---------------------------------------------------
> >
> > > -----Original Message-----
> > > From:       Mark Bakke [SMTP:mbakke@cisco.com]
> > > Sent:       Friday, March 23, 2001 9:36 AM
> > > To: Black_David@emc.com
> > > Cc: ips@ece.cmu.edu
> > > Subject:    Re: iSCSI Naming: WWUIs, URNs, and namespaces
> > >
> > >
> > > David-
> > >
> > > This is starting to seem like work.  In case they help,
> > > please see my comments below.  We can take this up in
> > > more detail in the N&D team.
> > >
> > > --
> > > Mark
> > >
> > > Black_David@emc.com wrote:
> > > >
> > > > <RANT> I don't like naming issues. </RANT> :-) :-)
> > > >
> > > > After suitable consulting with some members of
> > > > the IESG and IAB, I have some news to convey about
> > > > the current approach to iSCSI naming.
> > > >
> > > > The IESG will not approve another global namespace
> > > > for iSCSI's use - this means that WWUIs as currently
> > >
> > > So I take it that WWUIs are fine, as long as they use
> > > existing global name spaces.
> > >
> > > > designed will need to be revised out of the
> > > > naming and discovery draft, and that it will not be
> > > > possible to proceed with the WWUI URN draft
> > > > as an official IPS WG work item.  The best course of
> > > > action would probably be to allow the WWUI URN draft
> > > > to expire without further revision.
> > > >
> > > > To a first approximation, WWUIs are/were a "grand
> > > > unified theory" of naming, in that any namespace could
> > > > be glued into the WWUI world (as several were).
> > >
> > > The reason we glued these in was to avoid creating a new
> > > global name space.  We allowed the use of a few currently
> > > available global name spaces.  How can this be a problem?
> > >
> > > > The WG is being directed to instead focus on the
> > > > individual namespaces and make sure that the ones that
> > > > are used are in fact necessary.  iSCSI can use text
> > > > keys to identify which sort of name is being used
> > > > (one key for each sort of format, for each instance
> > > > in which a name is used), and it may be possible
> > > > to encode the name format in the parse rules for the
> > > > values of iSCSI keys to avoid proliferation of keys.
> > > >
> > > > Taking a look at the namespaces in the current iSCSI
> > > > naming and discovery draft, here's some initial
> > > > guidance from this WG co-chair:
> > > >   iscsi - canonical target -- This should be fine.
> > > >   eui - WWNs -- The use of these for storage makes eminent
> > > >         sense.  I don't see a problem here.
> > >
> > > So far, so good.  Does that mean that we can keep the above
> > > two, in the current WWUI, as we have it formatted?
> > >
> > > EUI, although it's not that flexible (see later), is required
> > > for interoperating with and adding iSCSI to existing devices.
> > >
> > > >   dns - hostnames -- Use of these should be abandoned as
> > > >         not only are they not really URNs (as indicated
> > > >         in the draft), but their intended usage is straying
> > > >         into the tarpit known as "URN resolution".  Faster
> > > >         progress will made by staying out.  A DNS hostname
> > > >         can be put into an Alias or something new can be
> > > >         invented to carry it as a Location Hint, BUT the
> > > >         relevant URN WG RFCs and drafts on URN resolution
> > > >         should be reviewed before proceeding too far in this
> > > >         direction.
> > >
> > > I don't like this one that much, either, for the same reasons.
> > >
> > > >   iscsi - Reverse DNS and oui - Org. Unique Identifier --
> > > >         The rationale for these is not clear to me.
> > > >         Assuming that WWNs are going to be available for
> > > >         use in naming iSCSI Initiators and Targets, what
> > > >         are the problems that these sorts of names solve
> > > >         that WWNs don't?  It appears that one of the problems
> > > >         may be who can get/create them.  Discussion of this
> > > >         on the list would be appropriate.
> > >
> > > These two formats use existing global name spaces, and allow
> > > the implementor or end user to take a more flexible approach
> > > to naming than is offered by the EUI-64.  When dealing with
> > > a large number of logical targets, burning WWNs (essentially,
> > > MAC addresses), and attempting to keep them tied to a logical
> > > entity without tying them to hardware is not practical.
> > >
> > > Both of these formats accomplish the same thing, and we could
> > > make do with just one of them.  The only real differences are:
> > >
> > > - OUI is a fixed length naming authority; reverse DNS is variable
> > >   and could result in longer names.
> > >
> > > - A human looking at a reverse DNS-based name can easily determine
> > >   who the naming authority is; a human looking at an OUI-based
> > >   name will usually have to go look it up at IEEE.
> > >
> > > - Only a hardware manufacturer (and a few software manufacters)
> > >   will already have an OUI.  Others, such as storage service
> > >   providers, large end customers, or software driver providers,
> > >   would either be out-of-luck for naming their devices, or would
> > >   have to register for an OUI, which would otherwise be a waste
> > >   of IEEE resources.  OTOH, a storage service provider could
> > >   provide its own names by using the reverse-DNS authority.
> > >   Everyone has a DNS name.  This would enable the SSP to provide
> > >   its customers with a WWUI that would not change if the back-end
> > >   storage device was replaced.  After all, it's not the device
> > >   that's important to this customer, it's the DATA.
> > >
> > > - If we had to pick one or the other, I would pick the reverse
> > >   DNS, since it offers the ability to generate unique names to
> > >   a wider variety of users.
> > >
> > > > In any case, the fewer name formats we have to deal with,
> > > > the better.
> > >
> > > Although I probably should have discussed this with the rest
> > > of the NDT first, I would personally be happy with:
> > >
> > > - iscsi - The canonical name.
> > > - eui - For compatibility with existing device naming schemes.
> > > - reverse-dns - For better naming flexibility moving forward.
> > >
> > > Perhaps the IESG would accept the WWUI with just these three.
> > > Or perhaps we could just make the WWUI into a URN?  I don't
> > > know if that would help, but perhaps...
> > >
> > > The main point is that we are NOT creating any new name
> > > spaces; we really are just using what's already there.  Maybe
> > > by specifying fewer of the options that are already there, we
> > > would be in better shape.
> > >
> > > > I want to try to anticipate an objection to this, which
> > > > would note that from a functional viewpoint the basic
> > > > impact of this is to move some characters from one text
> > > > string to another (e.g., from a WWUI type designator
> > > > to part of an iSCSI text key), and wonder if this is
> > > > a distinction without a difference.  One of the reasons
> > > > for the <RANT> that started this post is that a functional
> > > > view is not sufficient for naming - how things are named,
> > > > the intended usage of names and their scope matter a lot.
> > >
> > > So that leads to the question: Has any other WG come up with
> > > a world-wide-unique-identifier for something else that the
> > > IESG folks deems acceptable?  If we can see a few examples,
> > > we would be better able to anticipate what they want.
> > >
> > > > This is particularly true when considering the structure
> > > > of a namespace and how that structure may be extended.
> > > > The upshot is that avoiding introduction of something
> > > > claiming to be yet another global namespace is important
> > > > (i.e., use existing namespaces with global scope in preference
> > > > to inventing new ones).  The resulting need to define
> > > > the name spaces/formats in the main iSCSI spec. is
> > > > probably a "feature" as it forces us to pay more
> > > > attention to the sorts of names we use and raises the
> > > > bar for adding additional sorts of names in the future.
> > >
> > > > I will be working with
> > > > the naming and discovery team in my "copious spare time"
> > > > to make sure that we don't lose the valuable work and
> > > > progress they've made to date as a consequence of this
> > > > change.  Discussion on the list about what sort
> > > > of names are important (e.g., the Reverse DNS and OUI
> > > > namespaces) and why would be useful.
> > >
> > > From a requirements point of view, please respond if any
> > > of the types of names are important to you (plural).
> > >
> > > Hopefully, we can get this out of the way quickly.
> > >
> > >
> > >
> > > > Thanks,
> > > > --David
> > > >
> > > > ---------------------------------------------------
> > > > David L. Black, Senior Technologist
> > > > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > > > +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> > > > black_david@emc.com       Mobile: +1 (978) 394-7754
> > > > ---------------------------------------------------
> > >
> > > --
> > > Mark A. Bakke
> > > Cisco Systems
> > > mbakke@cisco.com
> > > 763.398.1054
> >

-- 
Mark A. Bakke
Cisco Systems
mbakke@cisco.com
763.398.1054