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 s/BGP MVPN-BGP]/BGP [MVPN-BGP]/ 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 router. 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. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/ >