[dhcwg] dhcpv6-24: use of DNS names in DUIDs

Thomas Narten <narten@us.ibm.com> Wed, 08 May 2002 14:11 UTC

Received: from optimus.ietf.org (ietf.org [] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08130 for <dhcwg-archive@odin.ietf.org>; Wed, 8 May 2002 10:11:17 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29535 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 10:11:26 -0400 (EDT)
Received: from optimus.ietf.org (localhost []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29282; Wed, 8 May 2002 10:06:53 -0400 (EDT)
Received: from ietf.org (odin []) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29254 for <dhcwg@optimus.ietf.org>; Wed, 8 May 2002 10:06:52 -0400 (EDT)
Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07857 for <dhcwg@ietf.org>; Wed, 8 May 2002 10:06:42 -0400 (EDT)
Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com []) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48E6o64141372 for <dhcwg@ietf.org>; Wed, 8 May 2002 10:06:50 -0400
Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com []) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48E6mQ54380 for <dhcwg@ietf.org>; Wed, 8 May 2002 10:06:48 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48E7BI18794 for <dhcwg@ietf.org>; Wed, 8 May 2002 10:07:11 -0400
Message-Id: <200205081407.g48E7BI18794@rotala.raleigh.ibm.com>
To: dhcwg@ietf.org
Date: Wed, 08 May 2002 10:07:11 -0400
From: Thomas Narten <narten@us.ibm.com>
Subject: [dhcwg] dhcpv6-24: use of DNS names in DUIDs
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

The document makes references to DNS names in two places:

> 9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN)
>    The vendor-assigned unique ID based on the domain name consists of a
>    two-octet value giving the length of the identifier, the value of the
>    identifier and the vendor's registered domain name.

I don't think VUID-DN format is needed and would suggest simply
removing it. 


DNS names are NOT permanent identifiers. For example, registrars
can reclaim DNS names if the renewal fees are not paid, if there
disputes of trademark, etc. Thus, these may be less permanent than

Second, they don't seem to provide any additional
benefits/functionality compared with VUID-EN. In those DUIDs, an
enterprise number provides the global uniqueness. Enterprise numbers
were defined precisely for this purpose, are permanent, and are easy
to get.

> 8. Representation and use of domain names
>    So that domain names may be encoded uniformly and compactly, a
>    domain name or a list of domain names is encoded using the technique
>    described in sections 3.1 and 4.1.4 of RFC1035 [12].  Section 4.1.4
>    of RFC1035 describes how more than one domain name can be represented
>    in a list of domain names.  For use in this specification, in a
>    list of domain names, the compression pointer (see section 4.1.4 of
>    RFC1035) refers to the offset within the list.

I don't think this needs to be in the base document. Nowhere does the
base spec use DNS names according to this format. Thus, there is
nothing to implement. Note that VUID-DN mentioned above doesn't use
this format (is that a bug?) -- it seems to use an ascii string
(which, BTW, is probably not really what is needed, given a future
with I18N DNS names).

When an option gets defined that encodes a DNS name, that is where the
above text needs to be specified.


dhcwg mailing list