Jinmei,

> 
> >     I believe that it is entirely too late in the life of this protocol
> > to be removing these bits.  If there is in fact confusion over their usage
> > then the usage should be clarified.  The original intent of this revision was
> > to clarify portions of the specification which were not clear, not to open every
> > feature for the full-scale debate and revision.  There is running, shipping
> > code that makes use of these bits.  What, exactly, is the upside in breaking
> > that code?
> 
> Just out of curiosity, what exactly do you mean by "running, shipping
> code that makes use of these bits."  In particular, are you referring
> to particular implementations that
> 
>   - invoke DHCPv6 on the reception of an RA with the M flag being set
>   - invoke DHCPv6 or (so called) stateless-DHCPv6 on the reception of
>     an RA with the O flag being set
> 
> ?  If so, could you tell me which implementations do?
> 
> Once again, I'm not necessarily pushing the idea of "deprecating" the
> M/O flags.  Also, breaking existing code is the last thing I want to
> do.

I don't know of any implementations which depend on these bits for
DHCPv6 invocation or termination.  That doesn't mean that none exist. 
There are multiple router implementations which allow these bits to be
advertised.  What is the upside in making these implementations obsolete
at this late date?  Unless we are planning on doing a complete survey of
all implementations to make sure that there is no dependency on these
bits I just don't see why we need or even want to deprecate them.  Are
we so short of other work that we need to waste time on breaking things
which are already working?  I don't get it.


Tim Hartrick
Mentat Inc.


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to