Subject: Re: DNSEXT WGLC: IPv6 Name Auto Registration

From: Francis Dupont <[email-masked]>
Date: Wed, 05 Feb 2003 10:43:30 +0100

In your previous mail you wrote:

   This document is on experimental track and is available via following URL:
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-name-auto-reg-00.txt
   
=> I support this document.

Regards

[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: [email-masked]
Date: Thu, 06 Feb 2003 18:20:21 +0900

> This document defines a mechanism to register IPv6 auto configuration in DNS.
> This document does not change the DNS protocol in any way or add new
> requirements for DNS servers or resolvers.
> 

I think most people are missing some important points which described
in this document.

1. This document provides GOOD NEWS to administrators of DNS servers.

   Most administrators of DNS servers are meeting problems how to
   collect IPv6 address information that should be registered to the
   DNS and how to prepare IPv6 address Data Base files for DNS servers.

   Especially, IPv6 addresses are too long to remember and EUI64-based
   addresses are too complicated to remember. Collecting such IPv6
   address information by hand is a terribly hard work.

   By using proposed mechanism, such IPv6 address information is collected
   automatically. Since the mechanism has intelligent candidates check
   functions, only IPv6 address information that should be registered is
   collected (there are no noise).
   
   # Dynamic Update in the DNS is a final procedure of the mechanism.
   Under some situations, Dynamic Update can be omitted.
   Namely, this mechanism can be used only for the IPv6 addresses
   collection.

   Administrators of DNS servers can used the collected data for the hints
   to prepare IPv6 address Data Base files for DNS servers.
  
   This usage helps administrators of DNS servers very much.

2. This document is on experimental track (not standard track)

   This information helps people.
   At least, administrators of DNS servers will become happy with
   this information.

3. This document provides a solution that can be used right now.
   This is a current applicable solution (not future solution).

   This mechanism can be introduced without modifying the existing DNS
   nor other IPv6 related implementations.

   This mechanism is highly modularized, it dose not cause any bad
   effects to other current existing mechanisms.
   
   Only sites which introduced this mechanism can get rewards.
   Introduce or not introduce is decided by sites' policies.

4. This mechanism is based on detecting DAD (Duplicate Address Detection)
   packets.

   So, the mechanism does not care about IPv6 address setting methods
   to nodes (by DHCPv6 or IPv6 Stateless Address Autoconfiguration
   [RFC2462] etc.).

   Only DAD packets are issued, the mechanism works under such situations.

5. This document do NOT prevent a future DHCPv6-based solution.
   
   DAD detection based solution and DHCPv6-based solution are NOT
   alternative.

Please reconsider above issues.

Regards,
Hiroshi

---

From: Ralph Droms <[email-masked]>
Date: Thu, 06 Feb 2003 11:30:51 -0500

I do not support the publication of this specification on experimental
track, for the following reasons:

What, exactly, is being standardized as an experimental protocol in
this document; why is the IETF publishing it?  The detector function
is a set of heuristics which may be of use in detecting newly
connected nodes, but it's not a protocol.  The detector<->registrar
communication is only described as an example in Appendix A.  The
registrar then uses DDNS to change the information in DNS.  The
registrar function is a set of rules for generating names for nodes
and for managing information about nodes.  What is the protocol that
must be standardized for interoperability among different
implementations?

I don't understand the motivation for registering the information
collected by this mechanism.  Registering a binding between a name and
an address assigned to a device is of no value unless that name is
known to the entities that want to interact with the device.  My newly
connected device is assigned the FQDN 00-03-47-0F-2D-44.example.com,
that name is useless unless I can somehow discover it and use it
elsewhere.

Similarly, what is the "IP address information that should be
registered in the DNS"?  The information should go in the DNS only if
it's used as part of a name-address binding.  If the name is generated
automatically and isn't a name chosen to be associated with a device,
it's useless.

How do independent Registrars cooperate to resolve name conflicts?
(This is an issue we've spent a lot of time trying to resolve in
DHCP-DDNS interaction.)  Suppose I connect a device that indicates a
preference of "joe.example.com" that is registered by Registrar R1,
and you connect a device that also indicated a preference of
"joe.example.com" that is registered by Registrar R2.  Which device is
assigned joe.example.com, and how does the network administrator
control the resolution process?

- Ralph

---

From: [email-masked]
Date: Tue, 18 Feb 2003 11:31:22 +0900

Date: Thu, 06 Feb 2003 11:30:51 -0500
Message-ID: <[email-masked]>

> connected nodes, but it's not a protocol.  The detector<->registrar
                            ^^^^^^^^^^^^^^

Please read the I-D carefully.

Let me quote the beginning of the I-D.

   This document describes a scheme of "Domain Name Auto-Registration
                           ^^^^^^^^
   for Plugged-in IPv6 Nodes" mechanism that makes it possible to
   register both regular and inverse domain name information of plugged-
   in IPv6 nodes to DNS servers automatically.

The document describes a scheme (not a protocol).

Main goals of the document are:

  - to meet requirements to use logical names that are easy to remember
        to specify IPv6 nodes (even if they are just plugged-in).

  - to clarify problems that we meet when we apply the Dynamic Updates
        in the DNS [DYN-DNS] to automatic domain name information
        registration mechanisms.

  - to provide a scheme to solve above problems.

  - to provide a method to collect IPv6 address information that
        should be registered to DNS servers.
        (This will help administrators of DNS servers.)

  - ...

This document is on experimental track (not standard track), and 
the document describes enough information for it.

Regards,
Hiroshi

---

From: Ralph Droms <[email-masked]>
Date: Sat, 22 Feb 2003 11:04:06 -0500

Thanks for the clarification about the purpose of the document.

However, I still don't agree that the IETF should consider publishing
this document.  There are no parts of the scheme described in
the document that address or solve interoperability issues.

- Ralph

---

From: Edward Lewis <[email-masked]>
Date: Sun, 23 Feb 2003 14:23:11 +0800

>the document that address or solve interoperability issues.

FWIW - I had the same comment in :
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html

(Not meaning to say "I said it first," but to say, "I agree.")

My other problem with the document is in:
    http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01152.html

and this hasn't been addressed (i.e., no update to the WG charter to 
allow this).
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer