Gen-ART review of draft-ietf-bess-orf-covering-prefixes-04

["Black, David" <[e-mail]>]

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: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; Lucy yong ([e-mail]); General Area Review Team
> ([e-mail])
> Cc: [e-mail]; [e-mail]; 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------