Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging
draft-ietf-l2vpn-pbb-vpls-pe-model-07

I found this to be an easy-to-read document that was informative for someone not immersed in this technology.  Good work.

Like Barry, I thought this was very readable (especially given the long strings of hyphenated uppercase letters that are in every spec in this space :-)

I had a couple of non-blocking comments for readability, and one question for the ADs (again, not blocking, just checking my own understanding of How Things Are Done).

In Abstract

   IEEE 802.1 Provider Backbone Bridges (PBB) [IEEE.802.1Q-2011] defines
   an architecture and bridge protocols for interconnection of multiple
   Provider Bridge Networks (PBNs). PBB was defined in IEEE as a
   connectionless technology based on multipoint VLAN tunnels.  PBB can
   be used to attain better scalability in terms of number of customer
   MAC addresses and number of service instances that can be supported.

Did I miss where you said "better than $WHAT"? I'm sure you had something in mind ...

4. Packet Walkthrough

   Because of text-based graphics, the Figure 3 only shows PWs on the
   core-facing side; however, in case of MPLS access with spoke PWs, the
   PE reference model is simply extended to include the same PW
   Forwarder function on the access-facing side. To avoid cluttering the
   figure, the access-side PW Forwarder (Fwdr) is not depicted without
   loss of any generality.

I don't think the last sentence in this paragraph means what it was likely intended to mean, (double negatives don't work well in English) but rather than try to fix it, I would suggest something like 

   Because of text-based graphics, the Figure 3 only shows PWs on the
   core-facing side; however, in case of MPLS access with spoke PWs, the
   PE reference model is simply extended to include the same PW
   Forwarder function on the access-facing side. To avoid cluttering the
   figure, the access-side PW Forwarder (Fwdr) is not depicted.
                                                              ^
                                    ending the sentence here


FOR THE ADs: in 11. Contributors

   The following authors contributed to this document: John Hoffmans
   (KPN), Geraldine Calvignac (France Telecom), Olen Stokes (Extreme
   Networks), Raymond Zhang and Matthew Bocci (Alcatel-Lucent).

We're including the organization names because they would have been on the front page anyway, right?

I think the authors should consider whether the density of acronyms in this document is something that should be continued going forward. I am impressed that Barry found this document easy to read.

I am not proposing that any changes be made to this particular document at this late date, but I would like to encourage the authors to consider a different balance in future documents. For instance, why is pseudowire abbreviated PW?  SA is used twice in the document; why not write "source address"?

Generally speaking you should abbreviate things that are used so frequently that it's clunky to spell it out each time, and spell everything else out so that the reader doesn't spend more time flipping back and forth between the text and the glossary than actually reading.

It's possible that all these terms are used so frequently by practitioners that there's no problem, so maybe I am making too much of this, but I found that the excessive use of acronyms in this document had a really negative impact on readability.