[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: whether we need the M flag ??
From:       JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei () kame ! net>
Date:       2004-04-28 3:27:18
Message-ID: y7v1xm8aijt.wl () ocean ! jinmei ! org
[Download RAW message or body]

>>>>> On Tue, 27 Apr 2004 09:13:55 -0700, 
>>>>> Alain Durand <Alain.Durand@Sun.COM> said:

>>> The facts are:
>>> 
>>> 1. there is code that sets the M&O bits. (router implementations)
>>> 2. there are at least two implementations that read and
>>> act on the O
>>> bit.  These two implementations both invoke stateless DHCPv6 as
>>> the action.
>> 
>> => So based on 1) and 2) I suggest that people who want to continue
>> this discussion, despite the chairs' recommendation should limit the
>> discussion to the M flag. If there are implementations that support
>> the O flag then removing it should be out of the question.

> I disagree. There are only 2 known implementations of the O flag,
> and the author of one of them publicly said he was willing
> to deprecate it. He said:
> "Regarding KAME's implementation, at least the implementor (myself) is
> okay to deprecate the flags.  Also, it's just an experimental
> implementation to identify issues, so this feature (invoking an
> RFC3736 client) is disabled by default in the implementation and is
> not officially released in the BSD community.  In fact, I'm tempted to
> deprecate the flags based on my experiments with the implementation,
> identifying the issues described above."

> So I do not believe that the argument that say they are existing 
> implementations
> of 'O' thus we cannot deprecate it is very strong

Although my personal opinion on this does not change, this discussion
has become meaningless...the chairs said we could recycle rfc2462bis
at DS even without interoperable implementations regarding the M/O
flags, and that's apparently what we have in the standardization
process.  Since this (sub)thread focuses on the process side of the
issue, I think we should close the thread at this stage.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]