RE: iSCSI Naming: WWUIs, URNs, and namespaces

[Douglas Otis <dotis@sanlight.net>]

Mark,

No, I was not confused nor did I expect clients to turn a WWUI into an
address as obviously you already have an address to do the reverse DNS.  I
indicated the process as Name->IP->Reverse-Name and illustrated this process
by pointing to the technique that Microsoft used to obtain names from
machines.  Their technique is prone to errors and spoofing.  Secure
management and promulgation was my concern.  The level of effort to extract
secure information from DNS is not simpler than that from LDAP.  The mayhem
from each vendor finding a unique method of obtaining and promulgating
information would not be pleasant.

Doug

> 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
>