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

From: Tim Hartrick <[email-masked]>
Date: Thu, 15 Apr 2004 12:08:44 -0700 (PDT)

All,

	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?

Tim Hartrick
Mentat Inc.

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

---

From: Alain Durand <[email-masked]>
Date: Thu, 15 Apr 2004 17:46:06 -0700

Ok, what would break if we were to declare the O & M bit historic
and issue a BCP recommending not to set them in RA?

It is unclear to me what part of existing code would break....

	- Alain.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 16 Apr 2004 11:44:25 +0900

>>>>> On Thu, 15 Apr 2004 12:08:44 -0700 (PDT), 
>>>>> Tim Hartrick <[email-masked]> said:

> code that makes use of these bits.  What, exactly, is the upside in breaking

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.

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

---

From: Tim Hartrick <[email-masked]>
Date: 15 Apr 2004 08:13:33 -0700

Jinmei,

> M/O flags.  Also, breaking existing code is the last thing I want to

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.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 16 Apr 2004 13:56:26 +0900

>>>>> On 15 Apr 2004 08:13:33 -0700, 

> DHCPv6 invocation or termination.

Okay, thanks.

> That doesn't mean that none exist. 

Of course not, I know.

> 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

(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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 14:15:57 +0200

> DHCPv6 invocation or termination.  That doesn't mean that none exist.

Also, the whole "other config" issue is still very much in a state of 
flux. Since those mechanisms haven't been defined yet, we can't be sure 
whether the M and especially O bits would be benificial to those 
mechanisms. So removing them *now* would be premature if nothing else.

(For instance, if we settle on well-known addresses for DNS + DHCPv6, 
then having the O bit will presumably be a good thing, as an unset O 
bit indicates that a host can just go to the WKA DNS immediately. 
Without the O bit it would either have query a DHCP server and time out 
if there are none available, or use the WKA DNS while querying the DHCP 
server and possibly the DNS query will time out if the well known 
addresses are unavailable.)

> at this late date?

I assert there is no upside. Just look at the whole ip6.int / ip6.arpa 
thing. Changing stuff that's out there in the real world just to make 
the specs look prettier is a very bad idea.

> Are we so short of other work that we need to waste time on breaking 
> things

Agree 100%.