Subject: whether we need the M flag ??

From: "Soliman Hesham" <[email-masked]>
Date: Tue, 27 Apr 2004 04:50:00 -0400

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

Hesham

========================================================
This email may contain confidential and privileged material for the sole
use of the intended recipient.  Any review or distribution by others is 
strictly prohibited.  If you are not the intended recipient please contact
the sender and delete all copies.
========================================================

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 27 Apr 2004 18:28:38 +0900

>>>>> On Tue, 27 Apr 2004 04:50:00 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> the O flag then removing it should be out of the question.

Fair enough, in that this is the chair's recommendation.

But please note that these implementations assume what is not
described in RFC2462; they assume the protocol corresponding to the O
flag is stateless DHCPv6 (RFC3736).  So, *if* we need to remove the M
flag due to the lack of implementation process-wise but we can keep
the M flag because of these implementations, the description in
rfc2462bis regarding the O flag should be consistent with the
assumption, as a logical consequence.  We should probably clarify in
rfc2462bis that the protocol for the O flag is RFC3736, and nothing
else.  (For that matter, I'm happy with it.)

In any event, I'd first like to clarify the general point before going
to each detail to avoid further confusion.  The question is:

  We do not have an implementation on some part of RFC2462.  Can we
  still recycle rfc2462bis as DS (process-wise), keeping that part,
  despite the lack of implementation?

If the answer is yes, we can concentrate on technical aspects of the
discussion for both the M and O flags.

If the answer is no, we need to somehow deprecate/remove the M flag,
and then concentrate on issues about the O flag (as you suggested
above).

I simply do not understand the answer to the general question, and I
think it's too early to suggest something at the moment, assuming the
answer is "no".  (I'm not intending to say this as a deal for
"killing" the O flag as well.  Rather, I'm saying this because we can
even keep both flags if the answer is "yes".)

Again, I'd really like to hear the answer to the general question
from someone familiar with the process.  Thanks,

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Tue, 27 Apr 2004 14:32:25 +0300 (EEST)

> and then concentrate on issues about the O flag (as you suggested

This is a good question, and one for which you're not likely to get a 
definitive answers.

In the past the implementation & interoperability reports have been 
more or less half-assed, and you could not really get a good feel on 
what's actually implemented and tested to interoperate.  I've 
personally sensed a desire for a bit more detail, but not necessarily 
to all the gritty details.

On the other hand, in Robert Elz's appeal, at least in that case, the
IESG felt (or that's how I interpreted it at least) that it is
traditionally not been required to demonstrate implementation and
interoperability of even the smallest details of the spec:

http://www.ietf.org/IESG/APPEALS/kre-ipngwg-addr-appeal-withdraw.txt

[...]
 The IESG notes that the existing practice when advancing documents on
 the standards track has not involved having implementation reports
 include detailed verification that implementations enforce every
 statement as is implied above, in the absence of explicit text
 requiring that an implementation make such checks.
[...]

So, my personal feeling is, "yes, we should be stricter on what we 
accept as "implemented & interoperable", but whether that happens in 
practice is another thing.

Hope this helps..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ralph Droms <[email-masked]>
Date: Tue, 27 Apr 2004 08:01:15 -0400

I agree 100% with Pekka's assessment of the current state of
interoperability testing, reporting and requirements as applied to
advancement of protocol standards.

I also agree that we should be more precise in our acceptance of
"implemented and interoperable".  I fear that the current practice can be
(and has been) applied selectively to allow advancement of some standards
while holding back others.

- Ralph

At 02:32 PM 4/27/2004 +0300, Pekka Savola wrote:
>On Tue, 27 Apr 2004, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote:

---

From: Alain Durand <[email-masked]>
Date: Tue, 27 Apr 2004 09:13:55 -0700

> 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

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 28 Apr 2004 12:27:18 +0900

>>>>> On Tue, 27 Apr 2004 09:13:55 -0700, 
>>>>> Alain Durand <[email-masked]> said:

> 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