Subject: Martin Stiemerling's No Objection on draft-ietf-6man-dad-proxy-05: (with COMMENT)

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 09 Oct 2012 05:44:52 -0700

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?