>>>>> On 15 Apr 2004 08:13:33 -0700,
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
>> 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.
Okay, thanks.
> That doesn't mean that none exist.
Of course not, I know.
> There are multiple router implementations which allow these bits to be
> advertised.
True, but without having hosts depending on it, deprecating these
flags does not break anything (see a message from Alain).
(Just to avoid unnecessary flame) I'm not insisting we should
deprecate the flags, and in particular, not just because of this.
One thing we may have to care, however, is that the lack of
implementation might be a barrier of recycling the spec as a DS, since
we'd need to show interoperable implementations.
> 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.
(I still don't understand what you mean by "things which are already
working", but anyway) you're correct in that we do not deprecate the
flags unless we have a clear and strong reason to do so. In
particular, I understand we should not deprecate them just because
there is almost no implementation (especially at the host side)
depending on them.
I do not forget the original intention of the rfc2462bis work:
recycling the existing document as a draft standard. The default
decision on a controversial issue should thus be conservative.
Right now, I'm listening to opinions of others, collecting information
to decide whether this path makes sense or not. I've already known
yours and I understand the point.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
