>>>>> On 23 May 2005 10:09:20 -0700,
>>>>> Tim Hartrick <[EMAIL PROTECTED]> said:
>> Part of me is starting to think that we might be better off waiting for
>> there to be more operational experience with deployments of DHCPv6 to see
>> how much confusion there really is. I agree it is good for vendors to
>> implement similar knobs, but I wonder how much of a problem there really is.
> More than part of me is thinking this. It seems to me that there is a
> continuing confusion about how these bits interact with local decisions
> by the administrator of a specific machine or network. People are
> asking questions like "What happens if the M and/or O bits are clear but
> there is a DHCP server?" or "What happens if the M and/or O bits are
> clear but the client wants to use DHCP anyway" or "What happens if the M
> and/or O bits are set and the client doesn't want to run DHCP". None of
> these questions are in the realm of protocol design. Clearly, local
> administrators will do as they please with their machines. In this
> respect the M and O bits have never been anything but strong hints as to
> what the client should do. The client is always free to ignore the
> hints. Further network administrators are free to misconfigure their
> networks as they please. The current text describing these bits is
> clear almost to the point of being infantile. This isn't an indictment
> of the authors. Rather it is an indictment of attempts to enforce
> system configuration and management rules via protocol specifications.
> This is impossible. We should stop trying.
First of all, as a part of the authors of the "infantile" document,
I'd like to emphasize once again that it's not our goal to *enforce*
system configuration issues through a protocol document. Perhaps the
current text is overacting, but the goal is to "clarify" (as the title
of the document shows) confusing points about the M/O flags. (You
seem to agree that there *is* confusion, but are saying that
clarifying those points is not IETF's work, correct?)
Anyway, regarding Bob's point, I can live with that. In fact, my
position of these bits has always been we don't have much experience
with these flags to be more specific about their usage. And that's
why I hesitated to describe more details about those flags in
rfc2462bis.
On top of this fact, I can live with the approach of leaving the
current confusion as is and waiting until we get enough operational
experience (then we may or may not need a separate document).
Before actually taking this approach, however, I'd like to make
a couple of additional notes beforehand:
- we removed from rfc2462bis some statements regarding the M/O flags
and the "stateful" protocol (=DHCPv6), such as this one:
If the value of ManagedFlag changes from FALSE to
TRUE, and the host is not already running the stateful address
autoconfiguration protocol, the host should invoke the stateful
address autoconfiguration protocol, requesting both address
information and other information.
or one even with an RFC2119 keyword:
In particular, a host MUST NOT reinvoke stateful address
configuration if it is already participating
with the intention of clarifying these points in the
ipv6-ra-mo-flags document. If we stop this work, it means these
statements will simply disappear.
- rfc2461bis will also need to remove the last sentence from the
description of the M/O flags:
M 1-bit "Managed address configuration" flag. When
set, it indicates that Dynamic Host Configuration
Protocol [DHCPv6] is available for address
configuration in addition to any addresses
autoconfigured using stateless address
autoconfiguration. The use of this flag is
further described in [ADDRCONF].
(this comment already applies regardless of the future of
ra-mo-flags, since [ADDRCONF](=rfc2462bis) does not talk about these
flags anymore)
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
--------------------------------------------------------------------
