Brian, thank you for your review. I posted a revision to reflect your suggestions.
Regarding the section 3, I changed several sentences, to reduce implementors' confusion, and to serve better for uniform implementation behavior. Best regards, ---- A new version of I-D, draft-ietf-6man-addr-select-opt-10.txt has been successfully submitted by Arifumi Matsumoto and posted to the IETF repository. Filename: draft-ietf-6man-addr-select-opt Revision: 10 Title: Distributing Address Selection Policy using DHCPv6 Creation date: 2013-04-30 Group: 6man Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-ietf-6man-addr-select-opt-10.txt Status: http://datatracker.ietf.org/doc/draft-ietf-6man-addr-select-opt Htmlized: http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-10 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-6man-addr-select-opt-10 Abstract: RFC 6724 defines default address selection mechanisms for IPv6 that allow nodes to select an appropriate address when faced with multiple source and/or destination addresses to choose between. The RFC 6724 allowed for the future definition of methods to administratively configure the address selection policy information. This document defines a new DHCPv6 option for such configuration, allowing a site administrator to distribute address selection policy overriding the default address selection parameters and policy table, and thus control the address selection behavior of nodes in their site. 2013/4/27 Brian Haberman <br...@innovationslab.net> > Hi all, > I have performed my usual AD review of draft-ietf-6man-addr-select-**opt > prior to it moving towards IETF Last Call. The document is well-written > and I only have a few comments. Once we have resolved these, we can move > the document along in the publication process... > > 1. Section 2 > > * The beginning of this section indicates that the Address Selection > option contains zero or more policy table options. It would be good to > clarify that sending an Address Selection option with zero policy table > options allows the operator to convey the values of the A & P flags. > > * The descriptions of "precedence" and "label" should probably indicate > their direct relationship to the policy table structure in RFC 6724. > > 2. In section 3, I was expecting better detail in *how* the information in > the DHCP options is handled. I am not aware of any other DHCP-provided > information that is conditional based on the user's whim. This seems like > it could lead to hard to diagnose brokenness. > > 3. In section 6, I think it is better to point to the actual IANA registry > where the options will be documented, rather than the RFC that created the > registry. > > Regards, > Brian >
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
