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
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
