Regarding breaking backward compatibility - this compatibility affects
only clients, right?  Can we answer the question: exactly how would
existing clients (and I'll bet we can enumerate all the available
clients) be affected by a change in definition?  How would the observed
behavior of the clients be out-of-spec relative to the new definition?

I ask because I'd be willing to bet the observed behavior of existing
clients will still be in compliance with the new definition: when the M
bit is set, the client will attempt HCB and when the O bit is set the
client will attempt ICB.  When both are set, I'll bet the client tries
HCB, which is still compliant with a new definition of M bit as a hint.

- Ralph

On Wed, 2005-05-25 at 10:47 +0900, JINMEI Tatuya / 神明達哉 wrote:
> >>>>> On Tue, 24 May 2005 10:46:06 -0400, 
> >>>>> Thomas Narten <[EMAIL PROTECTED]> said:
> 
> >> If we respect both the original sense of RFC2462 and our consensus
> >> about the semantics separation of the M/O flags, I believe the right
> >> solution is the following:
> 
> > I think we should be careful NOT to get hung up on what the original
> > intent of the M/O bits were, but focus on what the right behavior
> > should be, given what we know now/today, and given the DHC protocols
> > we actually have.
> 
> In general, I agree (if I sound self-conflicting, note the "If" in the
> cited part above).  In practice, however, it should also be noted that
> one major push back argument in the similar discussion for rfc2462bis
> a year ago was that we should not introduce incompatible changes to
> existing implementations that assume the "original intent".
> 
> It seems to me that this is a typical case of tradeoff between "it's
> never too late to do the right thing" vs "don't break compatibility".
> In the previous discussion, the latter was preferred, and so we are
> here.  If we can now prefer the former argument, I'm personally
> willing to take it.
> 
>                                       JINMEI, Tatuya
>                                       Communication Platform Lab.
>                                       Corporate R&D Center, Toshiba Corp.
>                                       [EMAIL PROTECTED]
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

Reply via email to