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 ? I really appreciate your reviewing and suggestions 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/ ? > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
