Subject: RE: [rfc2462bis] whether we need the M/O flags

From: "Christian Huitema" <[email-masked]>
Date: Sat, 24 Apr 2004 22:08:28 -0700

> >> Some people commented that we needed to clarify what's bad with the
> >> M/O flags if we want to deprecate (or remove) them.

The normal IETF practice is that when a document progresses from PS do DS and then to standard, parts of the specification that are not actually present in implementations get removed from the spec. As much as I can tell, we don't have much actual implementation of the M/O bits. If we follow the logic of the process, we should remove the corresponding sections from the spec.

-- Christian Huitema

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 25 Apr 2004 14:39:09 +0900

>>>>> On Sat, 24 Apr 2004 22:08:28 -0700, 
>>>>> "Christian Huitema" <[email-masked]> said:

>> >> M/O flags if we want to deprecate (or remove) them.

(folding a long line)

> The normal IETF practice is that when a document progresses from PS
> do DS and then to standard, parts of the specification that are not
> actually present in implementations get removed from the spec. As
> much as I can tell, we don't have much actual implementation of the
> M/O bits. If we follow the logic of the process, we should remove
> the corresponding sections from the spec.

Wearing 2462bis editor's hat, I'd really like to know what we should
do with this, process wise (i.e. whether I prefer or not prefer to
deprecate the M/O flags in a technical sense).

We first need to know if we really do not have much actual
implementation of these flags (particularly at the host side), but
it's quite likely the case (again, trying to be fair as a 2462bis
editor).

Then, where can I ask the correct behavior, process-wise?  Working
group chairs?  Internet area directors?

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

---

From: Brian Haberman <[email-masked]>
Date: Mon, 26 Apr 2004 17:50:03 -0400

> group chairs?  Internet area directors?

The current goal of 2462bis is to clean-up the specification, not make
major changes.  At this time, the chairs believe that there is code that
sets the M&O bits and at least one implementation that reads and acts
on these bits.  In addition, DHCPv6 is now in the early stages of
deployment and we expect people to begin taking more advantage of these
bits.  It seems to us to be the wrong time to remove them.

We also do not sense a consensus for or see a benefit of making changes
to 2462 with respect to the M&O bits.  There may be work needed at the
system level to clarify issues with their use, but that is outside the
scope of 2462bis.

So, the chairs do not see a need for removing the M&O bits from 2462 at
this time and request that Jinmei proceed without this change.

Regards,
Bob & Brian
IPv6 WG co-chairs

---

From: Alain Durand <[email-masked]>
Date: Mon, 26 Apr 2004 17:28:02 -0700

On Apr 26, 2004, at 2:50 PM, Brian Haberman wrote:

>  At this time, the chairs believe that there is code that
> on these bits.

This is certainly not enough to claim interoperability.

	- Alain.

---

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

>>>>> On Mon, 26 Apr 2004 17:28:02 -0700, 
>>>>> Alain Durand <[email-masked]> said:

> This is certainly not enough to claim interoperability.

Moreover, this (what Brian said) is not correct, as far as I know.

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.
  3. there is no known implementation that reads and acts on the M
     bit.

As I repeatedly said, I don't stick to deprecating these bits.
However, we at least need to discuss things on the correct
information.

My biggest question is: can we recycle rfc2462bis as DS despite fact
3?

					JINMEI, Tatuya

---

From: Alain Durand <[email-masked]>
Date: Mon, 26 Apr 2004 22:28:05 -0700

> My biggest question is: can we recycle rfc2462bis as DS despite fact

I failed to see what is wrong with the unused feature elimination 
Christian described
when moving along the standard track.

	- Alain.

---

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

>>>>> On Mon, 26 Apr 2004 22:28:05 -0700, 

> when moving along the standard track.

Not sure if you're making an objection to what I said, so please let
me clarify my point.

I would first like to be sure if it is okay to recycle the document as
DS even with the lack of implementation on a part of the protocol
description (in this case, the receiving side of the M flag),
*process-wise*.

If it's not okay, all the discussion we are having is meaningless;
Regardless of whether we prefer the idea of deprecating the flag, or
whether what Christian said is valid or not, we have no other choice
than deprecating/removing the feature (though there may be some
compromise on the details of "deprecate").

If it's okay, then we can continue the discussion.

I've been asking for an answer (if any), not an opinion, from someone
very familiar to the standardization process, but unfortunately, I've
never seen an answer.  The wg chairs are probably the "someone", but
as I pointed out, their answer based on incorrect information.  Thus,
I first corrected the information and then asked the same question.

					JINMEI, Tatuya

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Apr 2004 06:17:24 -0400

> This is certainly not enough to claim interoperability.

No one is claiming interoperability.  We are suggesting that there are
implementations that use the bits and they need to be given the
opportunity to do interoperability testing.

Of interest is the IESG web page on interoperability for 2462/2461:
http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt

Please note that the report does not get down to the granularity of
bits in messages.  It concentrates on the behavior of each message
(i.e. RA, RS, NA, NS).

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 27 Apr 2004 06:21:24 -0400

> I first corrected the information and then asked the same question.

As a I stated in an earlier message, I believe it is okay to recycle
at DS given the granularity of detail in the interoperability reports.
http://www.ietf.org/IESG/Implementations/nd-auto-implementations.txt
clearly shows that the interoperation is being measured at the message
level and not at the bit level.

Regards,
Brian

---

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

>>>>> On Tue, 27 Apr 2004 06:21:24 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

> level and not at the bit level.

Okay, thanks.  Then it is probably okay to keep these flags in terms
of the standardization process, even if we don't have the
corresponding implementations at all.  I personally would like to have
a closer review process, but as Pekka said, this is apparently what we
have, and I'm not intending to fight against it (at least for
rfc2462bis).

(wearing an editor's hat) through the discussion so far, it seems to
me that we should keep both the flags.  The reasons are:

- there seems to be no process issue (about interoperable
  implementations)
- the other points I raised to deprecate the flags were (apparently)
  not convincing enough
- we may need some additional consideration for security concerns
  Alain raised, but I think we can deal with them without deprecating
  the flags:
  + as (implicitly?) described in the node requirements draft, it's
    optional to implement DHCPv6 in the first place, and the node req
    document warns administrators about the implication about turning
    on the M flag.  Perhaps the node req draft could also add the
    security concerns, and/or rfc2462bis can describe the issues in
    its security consideration section.
  + after all, the entire autoconfiguration mechanism using RA
    (without SEND) is vulnerable to attacks from a malicious party in
    the same link.  It might be true that the concerns raised by Alain
    increases the vulnerability, but I guess we can accept it by noting
    the concerns in the security consideration section.

I hope this is acceptable for everyone.

					JINMEI, Tatuya

---

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

> If it's okay, then we can continue the discussion.

Ok, thanks for the clarification. IMHO, it is not OK to keep
the document as DS with O&M given the general lack of implementation.

	- Alain.

---

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

>>>>> On Tue, 27 Apr 2004 09:06:06 -0700, 

> the document as DS with O&M given the general lack of implementation.

Hmm, this message of yours seems to have been sent just after my
latest one...so, please let me confirm your intention.  Can you or
can't you live with my revised proposal (attached below)?

Regarding the process issue, I personally share your view.  But I
understood the current practice of the IETF is much more generous than
I'd want to see, and I'd accept that for now.

					JINMEI, Tatuya

Subject: Re: [rfc2462bis] whether we need the M/O flags
From: JINMEI Tatuya / 神明達哉 <[email-masked]>
To: Brian Haberman <[email-masked]>
Cc: IETF IPv6 Mailing List <[email-masked]>
Date: Wed, 28 Apr 2004 01:01:56 +0900
List-Id: IP Version 6 Working Group (ipv6) <ipv6.ietf.org>

					JINMEI, Tatuya

---

From: Alain Durand <[email-masked]>
Date: Wed, 28 Apr 2004 11:11:11 -0700

> can't you live with my revised proposal (attached below)?

see proposal inline.

> I'd want to see, and I'd accept that for now.

I'm not sure how the chairs can substantiate this position, as it is in 
violation
of RFC2026.

4.1.2  Draft Standard

   [...[

    The requirement for at least two independent and interoperable
    implementations applies to all of the options and features of the
    specification.  In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

>     the concerns in the security consideration section.

I think the document should at minimum:
- have text that analyze the security aspects of O&M
- make it very clear that those bits only provide hints that
   there may be a DHCPv6 server and hosts MAY want to use it.

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 29 Apr 2004 15:07:31 +0900

>>>>> On Wed, 28 Apr 2004 11:11:11 -0700, 

> I'm not sure how the chairs can substantiate this position, as it is
> in violation
> of RFC2026.

Again, I'm personally not sure either.  But I think the "process"
discussion was over anyway, so I won't mention this point in the scope
of this discussion.

>   there may be a DHCPv6 server and hosts MAY want to use it.

I read this to mean you can accept the decision of keeping the flags
if the text is reasonable for you.  At the moment, I'm not sure if the
result will be acceptable for you (since opinions still seem to vary
on details), but I think we can at least move forward for now.  Thanks
for your patience.

					JINMEI, Tatuya