Skip to main content

Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging
RFC 7041

Yes

(Stewart Bryant)

No Objection

(Adrian Farrel)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Sean Turner)
(Stephen Farrell)

Note: This ballot was opened for revision 07 and is now closed.

Stewart Bryant Former IESG member
Yes
Yes ()

                            
Adrian Farrel Former IESG member
No Objection
No Objection ()

                            
Barry Leiba Former IESG member
No Objection
No Objection (2013-07-02)
I found this to be an easy-to-read document that was informative for someone not immersed in this technology.  Good work.
Benoît Claise Former IESG member
No Objection
No Objection ()

                            
Brian Haberman Former IESG member
No Objection
No Objection ()

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
No Objection
No Objection ()

                            
Joel Jaeggli Former IESG member
No Objection
No Objection ()

                            
Martin Stiemerling Former IESG member
No Objection
No Objection ()

                            
Pete Resnick Former IESG member
No Objection
No Objection ()

                            
Richard Barnes Former IESG member
No Objection
No Objection ()

                            
Sean Turner Former IESG member
No Objection
No Objection ()

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-07-10)
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?
Stephen Farrell Former IESG member
No Objection
No Objection ()

                            
Ted Lemon Former IESG member
No Objection
No Objection (2013-07-11)
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.