Subject: Stateless DNS discovery draft

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 4 Apr 2002 17:36:39 +0200

Hi, 

During the last meeting a question was raised 
on whether the scenarios for which the stateless
DNS discovery draft can be used, were clear to
everyone. 
I think that on a very high level we could basically
say that this draft is useful when a host desires
to discover a DNS located in the same site for the
purpose of address resolution. 

Examples of where this can be useful:

- Corporate networks
- Cellular networks: 3GPP is one case where this
  would be useful for all those who complain 
  about how small the devices are and that the
  less code the better ;)

- ISPs which host a DNS server for customers 
  connected via DSL for example. Of course in 
  this case they would have to define a site
  accordingly. 

Any other scenarios ? I think there is a reasonable
case for this draft based on the scenarios 
above. 

Comments?

Cheers,
Hesham

--------------------------------------------------------------------
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: Rob Austein <[email-masked]>
Date: Sun, 14 Apr 2002 14:51:28 -0400

Somewhat late reply, but the topic doesn't seem to have gotten much
discussion.

At Thu, 4 Apr 2002 17:36:39 +0200, Hesham Soliman wrote:
> 
> During the last meeting a question was raised on whether the
> scenarios for which the stateless DNS discovery draft can be used,
> were clear to everyone.
> >
> I think that on a very high level we could basically say that this
> draft is useful when a host desires to discover a DNS located in the
> same site for the purpose of address resolution.
> 

I still don't see the point of this mechanism in the first place.  Any
general implementation is going to need to support something that
configure DNS when the special conditions needed for this mechanism
don't apply, and the total size of the minimal DHCP client one would
need to solve the general case (and the general NTP case, and the
general XYZ-server case) just is not that big.  There's a slight code
size saving if one only considers DNS, but once one starts thinking
about other services, the code size costs start tipping the other way,
even in specialized cases such Hesham's 3GPP example.

I am also concerned about the operational implications of either

(a) needing two different mechanisms to configure DNS, one for the
    simple case, the other for the general case, or 

(b) reimplementing the entire general case for each protocol that
    needs configuration (DNS, NTP, ...) just to avoid (a).

I think that Randy Bush pegged the basic issue back in Salt Lake City:
there's a basic philosphical disagreement here between viewpoints, one
of which holds that it's better to use a single generalized
lightweight config mechanism for all services and the other of which
holds that it's better to make each config mechanism independent.

I think the single generalized protocol approach both is likely to
scale better and is likely to require less protocol work and code
space in the long run, particularly given that such a protocol already
exists.

Which brings me back to my original point: I don't understand why the
IPv6 WG needs to reinvent the wheel here.
--------------------------------------------------------------------
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: Aidan Williams <[email-masked]>
Date: Mon, 15 Apr 2002 10:58:20 +1000

> IPv6 WG needs to reinvent the wheel here.

Amen.
- aidan

---

From: Randy Bush <[email-masked]>
Date: Mon, 15 Apr 2002 17:59:42 +0900

> holds that it's better to make each config mechanism independent.

credit where due department: i was paraphrasing erik nordmark

but i certainly agree with it.  and i am on the single, simple, general,
motherhood, and mochi side.

randy