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.
>
> 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.
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 PROTECTED]
--------------------------------------------------------------------
