Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

[Pete Resnick <[e-mail]>]

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-grow-route-leak-problem-definition-04
Reviewer: Pete Resnick
Review Date: 2016-03-21
IETF LC End Date: 2016-03-28

Summary: This draft is on the right track but has open issues, described 
in this review.

Major issues:

None.

Minor issues:

- Figure 1, along with the discussion of it in section 3, was confusing 
to me. First of all, am I correct that the example displays *two* leaks? 
That is, there's the leak from AS3 to ISP2, and then there are the 
propagated leaks from ISP2 to the rest of the world. Also, "(P)" seems 
to be used as both a leaked prefix (from ISP1 through AS3 to ISP2 and 
then propagated from there) as well as what looks to be a normal prefix 
update between ISP1 and ISP2. Are all of the occurrences of "(P)" in 
Figure 1 identical? Or is the prefix update between ISP1 and ISP2 also a 
leak? What leaks is Figure 1 intended to show?

- In 3.1: "The leak often succeeds because...". Do you really means 
"succeeds" and not "occurs"? If so, what does "succeeds" mean in this 
context?

- The description in section 3.5, starting from "However", really needs 
a complete rewrite. It's ungrammatical to the point that I'm not really 
sure I understand what it is trying to say.

Nits/editorial comments:

- I've mentioned before that I find the "academic research paper" style 
a bit jarring in IETF documents. I particularly don't like the use of 
"we" and "us", since it's not clear whether "we" is the authors (which 
is how it's used in academic papers, but is inappropriate for an IETF 
document), the WG, the IETF, etc. Instead, I would replace all instances 
of "we" with "this document", or simply re-word into the passive, since 
a subject is rarely needed for these sentences. For example, the 
abstract could be rewritten as such:

    A systemic vulnerability of the Border Gateway Protocol routing
    system, known as 'route leaks', has received significant attention 
in
    recent years.  Frequent incidents that result in significant
    disruptions to Internet routing are labeled "route leaks", but to
    date a common definition of the term has been lacking.  This 
document
    provides a working definition of route leaks, keeping in mind the
    real occurrences that have received significant attention. Further,
    this document attempts to enumerate (though not exhaustively)
    different types of route leaks based on observed events on the
    Internet.  The aim is to provide a taxonomy that covers several 
forms
    of route leaks that have been observed and are of concern to 
Internet
    user community as well as the network operator community.

Please do similar edits throughout.

Similarly, the referencing of authors by name seems like bad form for an 
IETF document.

OLD
    This document builds on and extends earlier work in the IETF by
    Dickson 
[draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-
    leak-reqts].
NEW
    This document builds on and extends earlier work in the IETF
    [draft-dickson-sidr-route-leak-def][draft-dickson-sidr-route-leak-
    reqts].
END

OLD
                              Mauch [Mauch] observes that these are
       anomalies and potentially route leaks because very large ISPs 
such
       as ATT, Sprint, Verizon, and Globalcrossing do not in general buy
       transit services from each other.  However, he also notes that
       there are exceptions when one very large ISP does indeed buy
       transit from another very large ISP, and accordingly exceptions
       are made in his detection algorithm for known cases.
NEW
                              [Mauch] observes that these are anomalies
       and potentially route leaks because very large ISPs such as ATT,
       Sprint, Verizon, and Globalcrossing do not in general buy transit
       services from each other.  However, it also notes that there are
       exceptions when one very large ISP does indeed buy transit from
       another very large ISP, and accordingly exceptions are made in 
its
       detection algorithm for known cases.
END

- Last paragraph in section 2: I'm left wondering what sorts of things 
that other folks might consider leaks *aren't* covered by the 
definition. Perhaps you want to mention that?

- In 3.6, when you say "more specifics", are you using that as a noun to 
mean "more specific prefixes"? It's very hard to read in its current 
form.

- Section 5 is superfluous. I'd delete it.

- On a side note, I must say that the writing style of the "Example 
incidents" caused me quite a bit of giggling. "Examples include 
symmetrical book stacking, just like the Philadelphia mass turbulence of 
1947, and the biggest interdimensional crossrip since the Tunguska blast 
of 1909 [GhostBusters1984]." Reading them aloud helps. :-) (No need for 
a change; they're fine as is. They just sound funny to a person not in 
the field.)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]