Hi Tony, please see my in-line comments: >> I think the questions should be is there merit in the >> proposal? > >That is true, but your section 3 does not establish that merit.
Hi Tony, just a reminder from an earlier e-mail that we will be seeking to provide additional detail in section 3 in the future versions of our draft.** > >> Does it basically work? > >Probably. > >> What needs to be modified for it to work? > >The fundamental ND implementation in the CPE router. We believe the ND modifications we propose would make ICMPv6 PD work. Having reviewed the draft, how technically sound do you believe our proposal is? We also need to carefully consider the technical comments made by the group for inclusion in future revisions of our draft. Please let me/us know. > >> Our claim is that there are situations and configurations where >> DHCPv6 may not be enabled or available and hence PD process can not >> depend on dhcp protocol. > >You assert that without attribution. As Ole pointed out you end up >reinventing DHCP, but masking it behind an ICMP packet format. > >> If the PD mechanism can be run utilizing more >> basic and fundamental components of the ipv6 stack, why not? > >That would be fine if those components actually exist. They will exist if this draft is approved. >The ability to >receive RS and send RA is not the same as what this proposal calls for. > >> If it >> basically works, and if implementers believe that it is simpler and easy >> to implement and deploy, it will get used. It does not propose to >> replace the dhcpv6 based proposal. > >The state of DHCP-PD is somewhat irrelevant. A point we are trying to make is that we are not trying to prove DHCPv6 PD is inherently insufficient, thus calling for its replacement. We also believe that the two PD methods (DHCPv6 and ICMPv6) are not mutually exclusive. >The point is that multiple reviews of the document >will have to be done >before it makes it to RFC. Most definitely. While challenging at times, we do welcome the multiple reviews as we wish to present the best ICMPv6 PD solution possible. >You appear to be unwilling to expand on the >fundamental justification, and >would rather burn list >bandwidth arguing your right to build something >>different. My apologies for contributing to that mistaken impression, Tony. We will expand upon our justification, as noted **. If there are folks on the list who are fundamentally opposed to this proposal (regardless of justification), they would hopefully say so. We would like to address as many different (types of) concerns as possible. > >You need to explain why the DHCP-PD packet format is >insufficient In a case where (for example) SLAAC (or manual configuration) is used for RN addressing, and no other information is required except PD, it seems unnecessary (while perhaps sufficient) to enable/use DHCPv6 just for PD. >or explain how your state machine sitting behind ICMP >will be significantly >simpler than a light-weight >DHCP client. >'Significant customer demand' is an important metric, >but it is not the only >one. Agreed on both points here, and especially glad you recognize the importance of customer demand. >Start by showing some willingness to actually work >within the IETF process by >rev'ing the draft to >put substantive detail in section 3. Absolutely! ** It is also proper for the group to consider the technical soundness of our proposal. With group input on the philosophical, procedural, and technical front (these are not mutually exclusive, and should be processed in parallel, IMO), we are more likely to provide the community with the best ICMPv6 PD solution possible (which is our goal). > >Tony Tim Rom 8:28 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
