Hi, I received the following e-mail directly. Let me add Cc to the list.
2012/10/17 Ray Hunter <v6...@globis.net>: > inline. >> >> Arifumi Matsumoto <mailto:arif...@nttv6.net> >> 16 October 2012 10:53 >> >> Ray, >> thank you for review and comments. >> >> Responses below. >> >> 2012/10/10 Ray Hunter<v6...@globis.net>: >>> >>> I support this work. >>> >>> Discussion >>> ========== >>> >>> Section 4.2 >>> s/the default policy should be restored/the previously active policy >>> should >>> be restored/ ? >> >> >> It is assumed that the configuration will be either using distributed >> policy or >> using manually configured policy as described in 4.1. >> So, 4.2 is written like this. >> >> Do you propose to change the above assumption ? >> > It is more of a question than a proposal. > > Some implementations (e.g. Windows) make a distinction between a > manually-configured change to the policy table that will survive a reboot, > and other changes that are only valid for this user session, using the > concept of a "store". See "netsh interface ipv6 show prefixpolicy > [[store=]{active | persistent}]" > > If there's been a manually-configured persistent policy set, if an [active] > DHCPv6-derived policy table goes stale, it might be more appropriate to > (re)activate the manually-configured persistent policy that is specific to > this node, rather than the "default" policy table defined in section 2.1 of > RFC6724. > > 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. > Further clarification on section 2 /A address selection option contains zero > or more policy table options/: > > I think it would also be useful if we added one sentence after this: /An > Address Selection option containing zero Policy Table options SHOULD be > interpreted as the RFC6724 Section 2.1 default policy table./ > > This will allow administrators to easily and positively provide local nodes > with a hint that they should use the default table of RFC6724, without > having to redefine and transport this every time, or rely on time outs. The reason for allowing zero policy table options is to deliver only the A and P flags of the Address Selection option. If we want to do this, we should add another flag for it. However, IMHO, we should not add such a thing, to keep things simple. Thank you. > >> I really appreciate your reviewing and suggestions below. > > You're welcome. >>> >>> Nits& clarification >>> >>> ============= >>> >>> Section 2 >>> s/A address selection option contains/An Address Selection option >>> contains/ >>> >>> s/Multiple policy table options in a Policy Table option constitute a >>> single >>> policy table./ >>> Multiple Policy Table options in an Address Selection option constitute a >>> single policy table./ >>> >>> s/zero padded/left aligned, big-endian, and zero padded on the right/ >>> >>> Section 3 >>> s/in any messages other/in any DHCPv6 messages other/ >>> >>> Section 4.1 >>> s/his requirement/their own requirements/ >>> >>> s/a) It receives distributed policy table, and replaces the existing >>> policy tables with that. >>> b) It preserves the default policy table, or manually configured >>> policy./ >>> a) replace the existing active policy table with the DHCPv6 distributed >>> policy table . >>> b) preserve the existing active policy table, whether this be the default >>> policy table, or user configured policy./ >>> >>> >>> Section 4.3 >>> s/node-global information by its nature/node-global information by their >>> nature/ >>> >>> s/One of the reason is/One reason being/ >>> >>> s/multiple address selection policy/multiple address selection policies,/ >>> >>> s/the effect of both policy/the effect of both policies/ >>> >>> s/that absence of the distributed policy/that absence of a distributed >>> policy/ >>> a/mean preference/mean a preference/ >>> >>> s/deal with multiple received policy/deal with multiple received >>> policies/ >>> >>> s/DHCPv6 clients need to convert this label to a representation specified >>> by >>> each implementation/DHCPv6 clients SHOULD convert this label to a >>> representation appropriate for the local implementation/ >>> >>> s/So, the number of the options and the total size of the options should >>> be >>> taken care of. Since the number of selection rules could be large, an >>> administrator configuring the policy to be distributed should consider >>> the >>> resulting DHCPv6 message size/ >>> Network administrators SHOULD consider local limitations to the maximum >>> DHCPv6 message size that can be reliably transported via their specific >>> local infrastructure to end nodes; and therefore they SHOULD consider the >>> number of options, the total size of the options, and the resulting >>> DHCPv6 >>> message size, when defining their Policy Table./ >>> >>> Section 6: >>> >>> s/and the affected packets might be blocked at an outgoing ISP because of >>> ingress filtering/and the affected packets might be blocked at an >>> outgoing >>> ISP because of ingress filtering, incur additional network charges, or be >>> misdirected to an attacker's machine/ >>> >>> s/should be communicated through a secure/should communicate through a >>> secure/ >>> >>> s/This issue will not be degraded regardless of the introduction of this >>> option, or regardless/This issue will not be modified by the introduction >>> of >>> this option, regardless/ >>> >>> regards, >>> RayH >>> >>> Ole Trřan wrote: >>>> >>>> All, >>>> >>>> This message starts a two week 6MAN Working Group on advancing: >>>> >>>> Title : Distributing Address Selection Policy using >>>> DHCPv6 >>>> Author(s) : A. Matsumoto, T. Fujisaki, T. Chown >>>> Filename : draft-ietf-6man-addr-select-opt-06.txt >>>> Pages : 10 >>>> Date : 2012-09-21 >>>> >>>> http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-06 >>>> >>>> as Proposed Standard. Substantive comments and statements of support >>>> for >>>> advancing this document should be directed to the mailing list. >>>> Editorial >>>> suggestions can be sent to the authors. This last call will end on 24. >>>> October 2012. >>>> >>>> Regards, >>>> >>>> Ole Trřan& Bob Hinden >>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >> Ray Hunter <mailto:v6...@globis.net> >> 10 October 2012 12:00 >> >> I support this work. >> >> Discussion >> ========== >> >> Section 4.2 >> s/the default policy should be restored/the previously active policy >> should be restored/ ? >> >> Nits & clarification >> ============= >> >> Section 2 >> s/A address selection option contains/An Address Selection option >> contains/ >> >> s/Multiple policy table options in a Policy Table option constitute a >> single policy table./ >> Multiple Policy Table options in an Address Selection option constitute a >> single policy table./ >> >> s/zero padded/left aligned, big-endian, and zero padded on the right/ >> >> Section 3 >> s/in any messages other/in any DHCPv6 messages other/ >> >> Section 4.1 >> s/his requirement/their own requirements/ >> >> s/a) It receives distributed policy table, and replaces the existing >> policy tables with that. >> b) It preserves the default policy table, or manually configured >> policy./ >> a) replace the existing active policy table with the DHCPv6 distributed >> policy table . >> b) preserve the existing active policy table, whether this be the default >> policy table, or user configured policy./ >> >> >> Section 4.3 >> s/node-global information by its nature/node-global information by their >> nature/ >> >> s/One of the reason is/One reason being/ >> >> s/multiple address selection policy/multiple address selection policies,/ >> >> s/the effect of both policy/the effect of both policies/ >> >> s/that absence of the distributed policy/that absence of a distributed >> policy/ >> a/mean preference/mean a preference/ >> >> s/deal with multiple received policy/deal with multiple received policies/ >> >> s/DHCPv6 clients need to convert this label to a representation specified >> by each implementation/DHCPv6 clients SHOULD convert this label to a >> representation appropriate for the local implementation/ >> >> s/So, the number of the options and the total size of the options should >> be taken care of. Since the number of selection rules could be large, an >> administrator configuring the policy to be distributed should consider the >> resulting DHCPv6 message size/ >> Network administrators SHOULD consider local limitations to the maximum >> DHCPv6 message size that can be reliably transported via their specific >> local infrastructure to end nodes; and therefore they SHOULD consider the >> number of options, the total size of the options, and the resulting DHCPv6 >> message size, when defining their Policy Table./ >> >> Section 6: >> >> s/and the affected packets might be blocked at an outgoing ISP because of >> ingress filtering/and the affected packets might be blocked at an outgoing >> ISP because of ingress filtering, incur additional network charges, or be >> misdirected to an attacker's machine/ >> >> s/should be communicated through a secure/should communicate through a >> secure/ >> >> s/This issue will not be degraded regardless of the introduction of this >> option, or regardless/This issue will not be modified by the introduction of >> this option, regardless/ >> >> regards, >> RayH >> >> >> ------------------------------------------------------------------------ > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
