Greg, thanks your comments and see my comments (inline)
>I was concerned that M|O could be used to
>invoke DHCP information-requests
>(rather than just O).
rather than just O ?
This draft wrote as below;
[RFC3736] is just a subset of full DHCPv6. So, a host
implementing [RFC3315] can do both or either Stateful DHCPv6 for
configuring the IPv6 address and Stateless DHCPv6 for the other
information. A host implementing only [RFC3736] can only do
Stateless DHCPv6.
>If we only mean 'managed addressing' with M, and
>Other config with O then each flag is aligned
>with a particular flag.
Also this draft wrote as below;
This document defines an internal (conceptual) variable for DHCPv6
policy. The value of this variable in conjunction with the
"ManagedFlag" and the "OtherConfigFlag" of ND protocol [RFC2461]
will be used for invoking the DHCPv6 for autoconfiguration.
And
Particularly, both "ManagedFlag" and "OtherConfigFlag" which were
implementation-internal variables were removed during [2462bis]
work based on the WG consensus with ambiguous operational
experiences, thus new variables (or similar approaches) is
required to treat M/O flags of IPv6 RA on the host.
>If we have flags which can be used for both
>purposes (like if M=1,O=0 allows hosts to send
>information-requests) then our policy names need
>to be adjusted.
It depends on what configuration is configured. As I indicated above
host which is only available stateful DHCP at its network can configure
other configuration informations via stateful DHCP.
>I think that hosts SHOULD NOT use policy 1 by
>default though. If they do, it should be by
>explicit configuration.
So, we tried to define the default values of the policies as below;
If the node implementes [RFC3315], the default value of M-Policy
is 2. If the node does not implement [RFC3315], the default (and
only) policy value is 3. When assuming [RFC3637] will be
implemented much wider that [RFC3315] in terms of other
configuration information, the default value of O-Policy is either
1 or 2. Perhaps value 1 is better since this service might be
crucial for the node (i.e., there may be no alternative to get the
other configuration information.)
I believe above mention considers what you worry...
Hope this helps...
Regards
Daniel (Soohong Daniel Park)
Mobile Platform Laboratory. SAMSUNG Electronics
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
