> >Better. But how about also stating that it might be useful to detect
> >when the flag values change. For instance,
> > 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. If we write something, it should be short, e.g.:
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.
That is, don't speculate on possible usage.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
