Subject: DNS discovery thoughts

From: Erik Nordmark <[email-masked]>
Date: Tue, 4 Jun 2002 17:28:56 +0200 (CEST)

I've been thinking about the DNS discovery, as well as the larger 
"service discovery with no 3rd party dependencies" issue, for a while.

Just like Steve Deering and many others I'd like the IETF to explore 
the larger issue, since I'm very much interested in making the future
Internet more robust than what we have today.
But this effort needs to be done carefully to make sure that we
are solving a well-defined and well-constrained problem. Thus I think
it would make sense to hold a BoF on this topic (perhaps in Yokohama
if there are folks willing to work on putting such a BoF together
in the very short time that remains).

Level 1 of the current DNS discovery draft is likely to set a precedent 
that well-known unicast addresses will be allocated for services.
The IETF has never done that before - we've only allocated well-known 
*multicast* addresses for services.
Going down the path of allocating well-known unicast addresses,
even if they are site-local addresses, is something I would be
very uncomfortable doing, especially if it is done as a "quick fix"
for a short-term DNS discovery solution without knowing what a potential
future "service discovery with no 3rd party dependencies" scheme might
look like. This concern appears to be shared by some other IESG members
based on some discussions last week.

These concerns would probably be less strong if the fixed unicast 
address was one part of a larger architecture, in which the reservation 
of fixed address was limited and necessary as part of an overall solution. 
Instead, it appears that this particular choice is being driven by a 
particular short-term problem with no apparent relationship to future and 
more general work.

So if I was an implementor that wanted a DNS discovery solution as
soon as possible, I'd just go with DHCPv6 information-request for now,
while participating in the larger, and necessarily longer term, discussions
about "service discovery with no 3rd party dependencies".

Comments?
   Erik

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Jun 2002 17:18:59 -0700

Erik,

I know there is considerable prejudice against SLP as a solution to the
general problem, but it certainly is available. It supports discovery
without a 3rd party. The only definitive criticism that I've ever heard
about SLP is the coupling of a directory service function with service
discovery.

I think a place to start might be understanding what SLP does and why
its critics don't like it.

            jak

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Jun 2002 20:56:46 -0400

actually, SLP seems like a much better fit than DNS for the
problem of discovering hosts on an ad hoc network - not just  
because SLP is desinged to work without an third-party
server but also because "service discovery" seems to fit the
likely use model better than "host name lookup".  

in particular, you've got no good way of ensuring unique
and meaningful host names for hosts on an ad hoc network -
they can't assert their normal DNS names (even if they have 
such) because such assertions might conflict with DNS, 
or with one another - so it doesn't match DNS "one RRset
per name" semantics at all.  and the very notion of zero 
configuration seems to imply that such hosts don't know 
what their (human meaningful, user assigned) names are - 
they can at most advertise what service(s) they provide 
and their serial #s and let applications look for them.

Keith

---

From: [email-masked]
Date: Wed, 05 Jun 2002 10:02:15 +0900

>and their serial #s and let applications look for them.

	you seem to be mixing two things up...
	the former paragraph speaks about "discovery of DNS server", the
	latter paragraph speaks about "name resolution under environment
	without DNS server".

itojun

---

From: Keith Moore <[email-masked]>
Date: Tue, 04 Jun 2002 21:04:50 -0400

sorry, I was even more confused than that - I got two message
threads from different groups mixed up.  please disregard my 
previous message.

---

From: Robert Elz <[email-masked]>
Date: Wed, 05 Jun 2002 12:30:04 +0700

Date:        Tue, 4 Jun 2002 17:18:59 -0700
    From:        "James Kempf" <[email-masked]>
    Message-ID:  <007301c20c26$994df9b0$1e6015ac@T23KEMPF>

  | I think a place to start might be understanding what SLP does and why
  | its critics don't like it.

I agree.

Certainly SLP (or even if necessary, a SLP subset) looks like a much
better fit to the problem than anything depending upon well known
addresses (which seems to have as its prime benefit only that no new
code needs to be written to implement it, just pick the addresses and
stick them in the current configuration files - which as a design feature
is about the last consideration I'd be using in choosing a solution)

kre

ps: there's much more info to discover than where a DNS back end is located
(please everyone, stop calling this a DNS server, finding DNS servers isn't
what we need, it is the DNS back end resolver that we are seeking) - the one
which concerns me most is how a host auto-configures its hostname (when it
isn't using DHCP).   Though from Keith's messages it seems that someone else
somewhere else might be considering that question.  What list was that on
Keith?