> 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.
=> OK, but we still have two options in IPv6 for address
autoconfiguration: Stateless and Stateful. I don't understand
why we shouldn't allow the option for _real_ stateless
autoconfig in IPv6. By 'real' I mean, we can't claim true
stateless autoconfig when a crucial service like the
DNS still requires a server.
> 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).
>
=> So would you support a generic mechanism that does
not require a third party server? I mean if the
DNS discovery was not limited to the DNS, would
that be a better approach?
I'm just trying to understand if the argument is:
a. Just use DHCP, we don't want anything else, or
b. Let's not have a separate mechanism for each
server.
If a) then I disagree, there has been good steps
taken towards stateless autoconfig in IPv6. I
don't think we should mandate a server-based
discovery all the time.
If b) then I can understand.
FWIW, we have deployment cases where this draft makes
a lot of sense and there is no alternative to it.
And it just happens that DNS is the one server
that needs to be discovered. Maybe that's not
a good enough justification for the draft, but
I'm failing to see any concrete side effects
that would result from using this extremely simple
draft. Which is a usual problem with philosophical
arguments. Not that I'm underestimating the
value of philosophical arguments.
Hesham
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
