Ray, > Suggested text for Section 4.2 > > s/When the information from the DHCP server goes stale, the policy > received form the DHCP server should be removed and the default policy > should be restored./When the information from the DHCP server goes > stale, the policy received from the DHCP server should be deprecated./
I think the text above looks reasonable. > > Optionally add to 4.2. /Which policy should then become active is a > matter for the local implementation./ I think we do not need this one. Thanks. 2012/10/22 Ray Hunter <[email protected]>: > Tim Chown wrote: >> On 22 Oct 2012, at 10:00, Arifumi Matsumoto <[email protected]> wrote: >> >>> 2012/10/17 Ray Hunter <[email protected]>: >>>> It's really a question of if we need to further clarify what is meant by >>>> "default policy" in Section 4.2 of draft-ietf-6man-addr-select-opt-06. >>>> >>>> Is it the manually configured node-specific default, or the RFC6724 section >>>> 2.1 default policy table, or is this behaviour simply implementation >>>> dependent and we should remain silent on an appropriate default? >>> IMHO, it should be complex to allow to receive distributed policy even >>> when the policy is manually configured. However, I agree that it should be >>> out-of-scope of this document. This document should just state the >>> requirements as in 4.1. >> >> The idea in the original discussions was that 'default policy' meant the >> default described in the RFC, rather than something local to the site. >> After all, the reason a site may be using this DHCPv6 option is to change >> that default. >> >> Tim > Not necessarily. In the days of highly mobile nodes, the concept of site > is going to become vague. > > Any manual configured policy on a node is likely to be node specific, > and not site specific. It might even be that the manual config detects > network settings before becoming active. e.g. based on local interface > address ranges. There's plenty examples of this today in e.g. Windows. > > The network operator may want to positively hint to the end node that it > should be running the RFC6724 defined default policy on this network > (and not some manually configured policy used by this node when > connected to other networks.) I agree that it is possible to implement > this behavior by the network operator configuring an explicit DHCPv6 > policy table that matches the RFC6724 default table, and the user > accepting this policy as defined in 4.1. > > > I believe in symmetry, so handling stale DHCPv6 information should > really be the reverse process of 4.1 > > For example, when the DHCPv6 policy expires (due to a timeout, or the > end node disconnecting from the network), you could get a situation > where the user has accepted a DHCPv6 distributed policy from network X, > but they may revert to a connection to another network Y that does not > support DHCPv6 distributed policy, but does require a manually > configured policy. Then it would make sense to install the manually > configured policy. Equally, they may also still be connected to network > X and it's just the DHCPv6 that has timed out. In which case keeping the > DHCPv6 policy active might be the correct thing to do. Or they might be > connected to a completely new network, in which case the RFC6724 default > is appropriate. > > I therefore think it probably should then be left to the end node > whether the end node should reactivate the manually configured (node > default) policy, or the RFC6724 defined default policy, or keep the > DHCPv6 learned policy active even though it has timed out. > > Suggested text for Section 4.2 > > s/When the information from the DHCP server goes stale, the policy > received form the DHCP server should be removed and the default policy > should be restored./When the information from the DHCP server goes > stale, the policy received from the DHCP server should be deprecated./ > > Optionally add to 4.2. /Which policy should then become active is a > matter for the local implementation./ > > regards, > RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
