Subject: RE: Definition of DUID

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Tue, 17 Jul 2001 18:17:52 -0500

>...there doesn't seem to be a good answer to this one -- on the one hand, we
>should encourage vendors to select as short an identifier string as possible
>to identify the vendor, but not so long as to be burdensome.  Is there any
>value to specifying the "domain name" part as an opaque, vendor-selected
>octet string (permitting, for example, UTF-8) with the strong suggestion
>that it be a (registered) trade-mark, domain name, or legal business name,
>but without burdening either IANA or a domain registrar?

While domain names could be long, I think they are a reasonable identifier.
There could be issues if a domain name used as a vendor id is sold (since the
new vendor might have no idea what vendor IDs were used previously). However,
mergers and the like don't create problems since if a domain name is switched,
the previously shipped devices will continue to use the old values (burned in
prom). The combined corporation hopefully knows what values were assigned in
the past.

The only issue that concerns me with domain names is that its one thing is
someone uses nominum.com, but what about subdomains or even internationalized
domains. Given that some internationalized domain names might go 3 or 4 levels,
each that could be up to 63 characters, the DUID could easily end up at 100s
of bytes.

I don't have a solution other than to discourage use of this DUID type or, if
used, reasonable length domain names are used (dell.com, compaq.com, intel.com,
toshiba.com, gateway.com, etc are luckily all fairly short names).

Depending on what character set is used for the domain names, another option
is to allow something like @<SNMP-Enterprise-ID> (since @ is an invalid domain
name character) - the ID would be in ASCII. Other characters could be used for
other identifiers (of course, we could simply define new DUID types as well).

Anyway, I think the domain name is a decent solution.

Do we want to indicate some maximum limit to the length of the DUID? I'd like
there to be one. I had suggested 32 bytes a while ago, but that is too short
considering the types. I would recommend we consider something like 128? Perhaps
we make this servers MUST be able to support DUIDs up to 128 bytes (longer
ones would be truncated under the assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths (64, 256).

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:[email-masked]]
Sent: Tuesday, July 17, 2001 6:36 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID 

my responses are inline...

--Barr

> > Also, given that we can reasonably expect to be moving very
> soon to 64-bit
> > time values, is a four-octet value an appropriate choice?
>
> Yes.   I would say a two-octet value would be fine, frankly.   There's
> no need to add an extra four bytes to the identifier, and keeping it
> small is a virtue.   The time from the beginning to the end of the
> epoch is long enough that the likelihood of a collision caused by this
> particular problem seems remote.   :')
>
...agreed, 68 years does seem long enough...  but I thought I should ask....

> > ...   this assumes that the link-layer address lengths are
> well-known, which
> > I'm not quite sure is universally correct.  While most of us know that
> > Ethernet addresses are 48-bits, how many of us know the length of every
> > other hardware address?  I would propose generalizing this by adding a
> > length  octet immediately following the hardware type.
>
> That's not necessary.   We already know how long the DUID is, because
> it's an option.
>
...oops!  forgot that!

> > ...   given that domain names are changed as frequently as corporate
> > identity makeovers or marketing department changes of direction I'd like
> > some other sort of "registered" identify, but I'm not sure what
> to propose
> > in place of domain name.
>
> That's just it.  We can't make the IANA do it.  Short of that, making
> the domain registrars do it seems like the easiest thing.  I can
> definitely conceive of this becoming a problem once in a while, but
> it's a problem that the manufacturer will have some interest in
> avoiding, so I'm not *too* worried about it.
>
...there doesn't seem to be a good answer to this one -- on the one hand, we
should encourage vendors to select as short an identifier string as possible
to identify the vendor, but not so long as to be burdensome.  Is there any
value to specifying the "domain name" part as an opaque, vendor-selected
octet string (permitting, for example, UTF-8) with the strong suggestion
that it be a (registered) trade-mark, domain name, or legal business name,
but without burdening either IANA or a domain registrar?

> >       Is an 8-octet identifier sufficient as the number of
> networked devices
> > increases?
>
> There aren't that many atoms in the universe, so yes, I think this
> will do.   :')
>
...so much for my knowledge of cosmology!

> > ...   would the vendor ID include some numeric encoding of the vendor's
> > identity, or is it intended that the domain name portion do
> that, leaving
> > VUID to be, essentially, an equipment serial number?  If the vendor's
> > identity is encoded in the VUID then registration/assignment of
> vendor IDs
> > become a task for IANA, would we expand the IEEE codes as used
> in Ethernet
> > addresses, or use some other identifier that is widely available such as
> > SIC/NMIC?
>
> This is precisely what I am trying to avoid by using the domain name.
>
...good point

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 17 Jul 2001 17:10:16 -0700

RE: Definition of DUIDBernie--

we'll probably just have to live with old, out-of-date domain names, but
other than vanity issues (suppose IBM changed it's name to Ascentia, for
example) there is probably no harm at all in allowing existing equipment to
continue using an obsolete [but still, presumably, unique!] registered name.

Domain name length and encoding *are* an issue, however.  While there is a
decided tendency for businesses to choose compact names, as you indicated,
there are a few with larger names (nortelnetworks.com, for instance), and
some for whom the preferred name coding might *not* be NVT-ASCII (?? --
Toshiba, is an example) when IDNs are finally supported.

As far as second and third-level names are concerned, perhaps the
description of this item option ought to strongly discourage use of anything
but the base domain name?

Your idea about encoding the SNMP Enterprise ID as ASCII digits prefixed by
the "@" character is quite a good suggestion.  I would argue that a vendor
who would be supplying a DHCPv6 client is highly likely to also supply an
SNMP agent or sub-agent, and Enterprise IDs are nicely compact.

--Barr

  There could be issues if a domain name used as a vendor id is sold (since
the
  new vendor might have no idea what vendor IDs were used previously).
However,
  mergers and the like don't create problems since if a domain name is
switched,
  the previously shipped devices will continue to use the old values (burned
in
  prom). The combined corporation hopefully knows what values were assigned
in
  the past.
  The only issue that concerns me with domain names is that its one thing is
  someone uses nominum.com, but what about subdomains or even
internationalized
  domains. Given that some internationalized domain names might go 3 or 4
levels,
  each that could be up to 63 characters, the DUID could easily end up at
100s
  of bytes.

  I don't have a solution other than to discourage use of this DUID type or,
if
  used, reasonable length domain names are used (dell.com, compaq.com,
intel.com,
  toshiba.com, gateway.com, etc are luckily all fairly short names).

  Depending on what character set is used for the domain names, another
option
  is to allow something like @<SNMP-Enterprise-ID> (since @ is an invalid
domain
  name character) - the ID would be in ASCII. Other characters could be used
for
  other identifiers (of course, we could simply define new DUID types as
well).

  Do we want to indicate some maximum limit to the length of the DUID? I'd
like
  there to be one. I had suggested 32 bytes a while ago, but that is too
short
  considering the types. I would recommend we consider something like 128?
Perhaps
  we make this servers MUST be able to support DUIDs up to 128 bytes (longer
  ones would be truncated under the assumption that the first 128 bytes is
unique).

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jul 2001 18:04:36 -0700

> Toshiba, is an example) when IDNs are finally supported.

I really don't think this is a big issue.  In the cases where we
really care about size, an option that uses an identifier registry is
the way to go.  For example, a cell phone can just send its own ID,
and there's a registry for those already.  Likewise, a device with an
embedded 802.11 controller that's permanently attached can use that
identifier.

I put this in here because it's a good, easy way to come up with a
private identifier registry in cases where you need a quick solution
and where it doesn't make sense to go through a special standards
process.  One drawback of this is that in theory we need to be able to
handle an arbitrarily long identifier, but actually there's a limit to
the length of a domain name, and I really don't think this is going to
produce a very long identifier in most cases.

If IBM changes its name to ascentia, they will probably keep the
ibm.com domain anyway.   I think www.dec.com still works, and DEC has
been part of Compaq for a longish time now.

Toshiba's domain name is toshiba.com.  Until the IDN folks comes up
with a way for toshiba.com to be represented in kanji, I would propose
that we table this issue.  When IDN comes out with a solution, we can
come out with a standard describing how that applies to the generation
of identifiers.

> but the base domain name?

I think we should assume that the reader will be intelligent about
this.   Third-level names are quite common outside of the U.S., so
specifying this carefully would be a lot of unnecessary work.   I am
all in favor of being careful in standards documents, but I think that
the level of carefulness I used here was the right one, and getting
more careful would actually be counterproductive.

			       _MelloN_