I don't have any issues if we wanted to keep 2 bits - just figured
simpler is better.

Note that if we drop one of those bits, we would not want to reuse if
for another purpose for a long time -- that would allow backward
compatibility for those environments that need it.

But again, I really don't care if it is two bits.

- Bernie 

> -----Original Message-----
> From: Soohong Daniel [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, May 24, 2005 11:15 PM
> To: Bernie Volz (volz); 'Bound, Jim'; 'Thomas Narten'; 
> ipv6@ietf.org; dhcwg@ietf.org
> Subject: RE: purpose of m/o bit
> 
> > But if the client supports both (really this means it is a 
> "full" 3315
> > client), does it do both in parallel, initiate stateful 
> (Solicits) and
> > failover to stateless at some point (and does it continue to 
> > do stateful in the background), or? These areas that are not well 
> > documented in the DHCPv6 specifications (3315 + 3736) and we 
> > need to clarify. We've discussed several proposals but I 
> don't think 
> > we've closed that discussion.
> 
> Exactly,
> 
> > Thus, I would suggest we:
> > - Have one bit that says "run DHCPv6". If the client is stateful, it
> > does "full" 3315". If the client is stateless (3736), it 
> does stateless
> > only.
> > - Have the DHC WG publish a draft to properly define the behavior of
> > clients (and servers) when stateful service is not 
> available and only
> > stateless is available. IE, when should a client switch to using
> > Information-Request or should all servers support Solicit and 
> > should an Advertise be able to carry "other configuration" options 
> > when addresses are not available. (Or perhaps there are 
> other options 
> > to be considered.)
> 
> As Jinmei pointed out, we should consider *backward-incompatibility*
> proir to saying any alternatives. We should make sure that is 
> not a trivial 
> consideration. 
> 
> 
> 
> ---------------------------------------------
> Daniel (Soohong Daniel Park)
> Mobile Platform Laboratory, SAMSUNG Electronics.
> 

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

Reply via email to