RE: [dhcwg] Semantics of Stateful Bits for the Client

["Bound, Jim" <jim.bound at hp.com>]

> Does anyone really see any value in 1?
> 
> And this is always possible - just don't configure the DHCPv6 server
> with any configuration parameters to send out.

I don't and never did.  I think it odd too.  I will share my view of one
reason why this happened.  Realize my priority is always compromise and
move forward, unless it breaks major code base, or significant
architecture flaw for the Internet end-to-end model I just cannot
accept.  Thus, I did support the specs moving forward, and my last
statement below says the same thing if we do not change this set of
bits.

Early on work for IPv6 within the infrastructure driver individuals and
from the very first Addrconnf presentation discussion on IPv6 at the
IETF, the consenus of that then group was the Internet would be better
with stateless and not have go to stateful servers for anything.  But,
clearly dhc from v4 demonstrated how useful configuration parameters are
to a user on a link,and other basic services.  But, the consenus then
was ok lets make sure we add function to permit some form of stateful
configuration (dhc was not even considered at this time by most the
eventual mechanism which I never got) for parameters for the link, but
separate that option from configuration.  Thus, two bits for stateful.
One for obtaining addresses, another to obtain configuration parameters.
Another more noble reason was the idea to separate stateful address
semantics, becuase stateless is the default, from the need for other
configuration parameters, and break this perceived problem down into
multiple levels of indirection within the link architecture to obtain
addresses and configuration parameters as separate functions.

I think the entire notion should in theory be changed to just use dhc
for addresses+parameters, and let dhc determine, as suggested above with
one example. if addresses or parameters are to be provided to the nodes.
Prefix delegation is a new function I won't go into in this thread
(which I think is wonderful as a note).

But we must use caution by removing the ND m+o bits and the affect to ND
and Addrconf code base per my other email.

Getting  consenus on if we change the initial thinking model and a lot
of code base (servers, clients, routers etc.), from the non-dhc code
affect, on this list I think is key to moving forward.  Or we must make
the semantics work with the bit-space we have, which I will bet is what
we will have to do for multiple reasons and not all technical.

My .25 cents,
/jim

> > -----Original Message-----
> > From: dhcwg-bounces at ietf.org [mailto:dhcwg-bounces at ietf.org] 
> > On Behalf Of Bound, Jim
> > Sent: Friday, May 27, 2005 3:24 PM
> > To: ipv6 at ietf.org; dhcwg at ietf.org
> > Subject: [dhcwg] Semantics of Stateful Bits for the Client
> > 
> > If we believe we will inform clients to use or not use dhc and I am
> > going to guess all agree with that so we have to multitask here in
> > cyberspace.
> > 
> > What semantic conditions do we inform clients about when we 
> > inform them
> > to use dhc via ND packet.
> > 
> > Points from the many mails are as follows.
> > 
> > 1. use dhc only to obtain addresses
> > 
> > 2. use dhc only to obtain configuration parameters
> > 
> > 3. use dhc to do 1 and 2.
> > 
> > Does prefix delegation requires its own condidtion? 
> > 
> > Is prefix delegation covered by 1 and then is it dhc 
> process to decide
> > what is done?
> > 
> > /jim
> > 
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg at ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------