Skip to main content

Last Call Review of draft-ietf-bess-orf-covering-prefixes-03

Request Review of draft-ietf-bess-orf-covering-prefixes
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2015-02-18
Requested 2015-02-04
Authors Huajin Jeng , Luay Jalil , Ron Bonica , Keyur Patel , Lucy Yong
Draft last updated 2015-02-14
Completed reviews Genart Last Call review of -03 by David L. Black (diff)
Genart Telechat review of -04 by David L. Black (diff)
Secdir Last Call review of -03 by Brian Weis (diff)
Opsdir Last Call review of -03 by Carlos Pignataro (diff)
Assignment Reviewer David L. Black
State Completed
Review review-ietf-bess-orf-covering-prefixes-03-genart-lc-black-2015-02-14
Reviewed revision 03 (document currently at 06)
Result Not Ready
Completed 2015-02-14
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at:


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.

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786 at        Mobile: +1 (978) 394-7754