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

[Ralph Droms <[e-mail]>]

Thomas - the VUID-DN format is useful for vendors that have a DNS name but 
do not have an enterprise number.  Whether or not there are enough vendors 
in that situation to warrant the definition of the VUID-DN is up for 
discussion.

I argue for the domain name representation to be in the base spec to cover 
all possible future uses of domain names in options, even if none of those 
options appear in the base spec.  With the definition in the base spec, we 
are guaranteed uniformity of domain name representation across all future 
options.

If there is a conflcit between the spec in section 8 and in the VUID-DN 
definition, we should fix (or drop) the VUID-DN definition.

- Ralph

At 10:07 AM 5/8/2002 -0400, Thomas Narten wrote:
>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.
>
>Rational:
>
>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
>appears.
>
>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.
>
>Thomas
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg