Christian Huitema wrote:
>>> On receipt of a valid Router Advertisement (as defined in
>>> [DISCOVERY]), a host copies the value of the advertisement's M bit
>>> into ManagedFlag, which saves the mostly recently received value of
>>> the M bit. The details of how the host uses the ManagedFlag,
>>> including any use of the "on" and "off" transitions for this flag,
>>> to control
>>> the use of DHCPv6 for address assignment will be described in a
>>> separate document.
>>
> Well, I for one would rather leave the entire handling of the Managed flag
> to the to-be-written RFC. I see the point of assuming that the flag will be
> visible through some kind of API for the DHCPv6 process, but I would rather
> not build a dependency to another document.
Seems to me this goal could be satisfied via a minor change to
the trailing phrase of the proposed text, i.e.:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag, which saves the mostly recently received value of
the M bit. The details of how the host uses the ManagedFlag,
including any use of the "on" and "off" transitions for this flag,
to control the use of DHCPv6 for address assignment is out of scope.
I could also take or leave the phrase: "including any use of the "on"
and "off" transitions for this flag", i.e., if the goal is to keep it short.
Fred
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
