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 --------------------------------------------------------------------