The review of the -03 version also applies to the -04 version of this draft. Thanks, --David > -----Original Message----- > From: Black, David > Sent: Friday, February 13, 2015 8:05 PM > To: hj2387@xxxxxxx; luay.jalil@xxxxxxxxxxx; rbonica@xxxxxxxxxxx; > keyupate@xxxxxxxxx; Lucy yong (lucy.yong@xxxxxxxxxx); General Area Review Team > (gen-art@xxxxxxxx) > Cc: ietf@xxxxxxxx; bess@xxxxxxxx; Black, David > Subject: Gen-ART review of draft-ietf-bess-orf-covering-prefixes-03 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at: > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-bess-orf-covering-prefixes-03 > Reviewer: David Black > Review Date: Feb 13, 2015 > IETF LC End Date: Feb 18, 2015 > > Summary: Unfortunately, I don't have the expertise to review this draft. > > This draft is esoteric - it's written by BGP/MPLS VPN experts for BGP/MPLS > experts and is effectively unintelligible in the absence of BGP/MPLS VPN > expertise. I'm not a BGP/MPLS expert, but this is the first time in my > many years of Gen-ART reviewing that I've had to use the "don't have the > expertise" summary status. > > The draft's writing style is inaccessible. A simple example is that one > would expect that a draft whose title is "Covering Prefixes Outbound > Route Filter for BGP-4" would explain what a "Covering Prefix" is - this > draft never does that. Much of the draft is nearly opaque lists of > requirements and processing rules, with little if any design explanation > or rationale for why they are that way and what they accomplish. This > is exacerbated by presence of a number of acronyms that are not expanded > on first use. > > Overall, I really can't figure out what's going on in this draft, so I > have to trust that the WG got it right, I hope. That's disappointing. > > I do have one minor editorial suggestion: > > The security considerations section cites BGP security considerations > in existing RFCs. It should also cite VPN security considerations in > existing RFCs, as those are more important for a draft that is only > applicable to VPNs. > > idnits 2.13.01 didn't find anything to complain about. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > david.black@xxxxxxx Mobile: +1 (978) 394-7754 > ----------------------------------------------------