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. Summary: With the exception of the minor editorial issues below, I believe this document is ready to publish This is an informational document that describes how to use Hierarchical Virtual Private LAN Service (H-VPLS) [RFC 4762] with the IEEE's 802.1ah specification for Provider Backbone Bridging. In particular, the document lays out four deployment scenarios and describes how the two technologies inter-operate in each scenario (to achieve better scaling propertires than one would get without use of 802.1ah). The authors claim that the use of 802.1ah introduces no security concerns beyond the general considerations in any H-VPLS deployment, which are documented in RFC 4762 (and RFC 4111). I am inclined to agree. Although I don't have a deep enough knowledge of H-VPLS to be certain, I think that some of the security concerns documents in RFC 4762 (e.g., traffic isolation and certain kinds of denial of service attacks) are actually somewhat alleviated through the use of Provider Backbone Bridging.  EDITORIAL COMMENTS: As someone who does not ordinarily read L2VPN documents, I would find it very helpful if you could expand each acronym the first time it is used. In particular, I would have found it very helpful if you had expanded VPLS when it appears in the first sentence of the introduction. (I also would have found it quite helpful to include a reference to 4762 early in the introduction as well.) Additionally, In understanding the security considerations for this document, I personally found it very useful to read portions of RFC 4111. RFC 4111 is referenced by RFC 4762, but I think it would be helpful to provide a direct reference to RFC 4111 in the security considerations for this document. (As opposed to just referencing RFC 4762.) This is a small editorial point, but as a reader, I would prefer a direct link to a document that is likely to be of interest, as opposed to following a sequence of references.