Martin Stiemerling has entered the following ballot position for draft-ietf-6man-dad-proxy-05: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 1) I have no general concern about the publication of the draft, but I doubt that it is for the Internet in general. It is more adding support for a very specific set of deployments, e.g., DSL access networks. This is somehow stated in the abstract "point-to-multipoint architecture with "split-horizon" forwarding scheme." but it is hard to understand and the proposed solution probably does not work in other settings that use the same description or claim similar ground. Can we add a more specific wording right upfront that this is primarly for "Digital Subscriber Line (DSL) and Fiber access architectures" as noted in Section 2? This would also be inline with the rest of the document which uses very specific terminology out of broadband access networks, e.g., BNG. The Internet itself does not has BNGs, but routers or first hop routers (AKA BNG in this context) Also in this context: Section 3.2., paragraph 3: > As the BNG must not forward link-local scoped messages sent from a > CPE to other CPEs, ND Proxy cannot be implemented in the BNG. This seems to be the restriction of a very specific deployment scenario, but is not a limitation per se. Other people could allow this in their architecture. 2) Section 4.1., paragraph 1: > A BNG needs to store in a Binding Table information related to the > IPv6 addresses generated by any CPE. This Binding Table MAY be > distinct from the Neighbor Cache. This must be done per point to This 'MAY' does not look correct here, but a 'can' would just do the job, as this is implementation specific, isn't it? 3) Appendix A., paragraph 1: > This appendix contains a summary (cf. Table 1) of the actions done by > the BNG when it receives a DAD based NS (DAD-NS) message. The > tentative address in this message is IPv6-CPE1 and the associated > Link-layer address is Link-layer-CPE2. The actions are precisely > specified in Section 4.2. Is this appendix normative or not? What takes precedence: the text or the table? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------