Last Call Review of draft-ietf-l3vpn-2547bis-mcast-

Request Review of draft-ietf-l3vpn-2547bis-mcast
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-09-08
Requested 2009-08-27
Draft last updated 2009-09-18
Completed reviews Secdir Last Call review of -?? by Jürgen Schönwälder
Secdir Telechat review of -?? by Jürgen Schönwälder
Assignment Reviewer Jürgen Schönwälder
State Completed
Review review-ietf-l3vpn-2547bis-mcast-secdir-lc-schoenwaelder-2009-09-18
Review completed: 2009-09-18


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

First of all, let me state that I did not do a detailed review of the
document. The ID is ~90 pages and depends on another twin ID (~60
pages)and they again depend on some other RFCs of some 30 pages each
and since I am not deeply involved in BGP/MPLS VPNs it would have
taken me days to do a detailed review. So I ended up trying to
understand what the document is about and then making sense of the
security considerations section. Here is what I found:

a) p90: I assume 2547 means RFC 2547, so

   s/of 2547 VPNs/of RFC 2547 VPNs/

   but then I checked and RFC 2547 has been obsoleted by RFC 4364
   so probably this should be

   s/of 2547 VPNs/of RFC 4364 VPNs/

b) p91: missing opening bracket


c) p91: double "as"

   s/techniques as as/techniques as/

d) The paragraph talking about P-tunnel construction should probably
   be using stronger MUST language, e.g.

   [...] P or PE router receiving a control MUST ensure that the
   control message comes from another P or PE router, not from a CE

   Right now, I find the message of the paragraph somewhat unclear.

e) I am wondering why "should not allow" is used in the discussion of
   extending multicast distribution trees. Perhaps some text can be
   added under which circumstances it makes sense to configure the
   ASBR to allow this and which risks this involves. (Perhaps this
   just shows my ignorance. ;-)


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <