Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

2016-05-05 Thread Jari Arkko 
Many thanks for the review and changes, Sriram and Pete!

Jari

On 29 Apr 2016, at 13:02, Sriram, Kotikalapudi (Fed) 
<kotikalapudi.sri...@nist.gov> wrote:

> Pete,
> 
> Thank you very much for your careful reading and the detailed 
> comments/suggestions.
> I found them all very helpful, and the new version (-05) that I just uploaded 
> incorporates
> the changes you’ve recommended. Please take a look and let me know if I 
> missed anything important.
> 
> https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-05  
>  (new version)
> https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-problem-definition-05
>(diff)
> 
> Sriram
> 
> 
> From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
> Sent: Monday, March 21, 2016 12:28 PM
> To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; 
> draft-ietf-grow-route-leak-problem-definition....@ietf.org; IETF discussion 
> list <i...@ietf.org>
> Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04
> 
> 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].
>

Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

2016-04-29 Thread Sriram, Kotikalapudi (Fed) 
Pete,

Thank you very much for your careful reading and the detailed 
comments/suggestions.
I found them all very helpful, and the new version (-05) that I just uploaded 
incorporates
the changes you've recommended. Please take a look and let me know if I missed 
anything important.

https://tools.ietf.org/html/draft-ietf-grow-route-leak-problem-definition-05   
(new version)
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-route-leak-problem-definition-05
   (diff)

Sriram


From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: Monday, March 21, 2016 12:28 PM
To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; 
draft-ietf-grow-route-leak-problem-definition@ietf.org; IETF discussion 
list <i...@ietf.org>
Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04


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 whe

Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

2016-04-20 Thread Pete Resnick 

Sorry for not replying sooner:

Check with the WG chair and the AD. My comments are to be treated like 
anyone else in the WG or during Last Call who made comments on the 
document.


pr

On 20 Apr 2016, at 13:49, Sriram, Kotikalapudi (Fed) wrote:


Pete,

I am working on the revision. When I am done making the changes,
should I upload a new version using the IETF submission tool
or should I simply email the .txt or .xml only to you/Gen-art team?

Thanks.

Sriram

-Original Message-
From: Sriram, Kotikalapudi (Fed)
Sent: Wednesday, March 30, 2016 6:02 PM
To: Pete Resnick <presn...@qti.qualcomm.com>; General Area Review Team 
<gen-art@ietf.org>
Subject: RE: Gen-ART LC review of 
draft-ietf-grow-route-leak-problem-definition-04


Pete,

Thank you for your review and comments. I'll be happy to incorporate 
all the changes you've suggested.
I've been a bit swamped. What is a reasonable turnaround time for 
these?

OK if I get this done within the next week or two?
When I am done making the changes, should I upload a version -05 or 
should I email the .txt or .xml only to you/Gen-art team?


Sriram
---



From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: Monday, March 21, 2016 12:28 PM
To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; 
draft-ietf-grow-route-leak-problem-definition@ietf.org; IETF 
discussion list <i...@ietf.org>
Subject: Gen-ART LC review of 
draft-ietf-grow-route-leak-problem-definition-04


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] o

Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

2016-04-20 Thread Sriram, Kotikalapudi (Fed) 
Pete,

I am working on the revision. When I am done making the changes, 
should I upload a new version using the IETF submission tool 
or should I simply email the .txt or .xml only to you/Gen-art team?

Thanks.

Sriram

-Original Message-
From: Sriram, Kotikalapudi (Fed) 
Sent: Wednesday, March 30, 2016 6:02 PM
To: Pete Resnick <presn...@qti.qualcomm.com>; General Area Review Team 
<gen-art@ietf.org>
Subject: RE: Gen-ART LC review of 
draft-ietf-grow-route-leak-problem-definition-04

Pete,

Thank you for your review and comments. I'll be happy to incorporate all the 
changes you've suggested.
I've been a bit swamped. What is a reasonable turnaround time for these?
OK if I get this done within the next week or two?
When I am done making the changes, should I upload a version -05 or should I 
email the .txt or .xml only to you/Gen-art team? 

Sriram
---



From: Pete Resnick [mailto:presn...@qti.qualcomm.com]
Sent: Monday, March 21, 2016 12:28 PM
To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; 
draft-ietf-grow-route-leak-problem-definition@ietf.org; IETF discussion 
list <i...@ietf.org>
Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

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

Re: [Gen-art] Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

2016-03-30 Thread Sriram, Kotikalapudi (Fed) 
Pete,

Thank you for your review and comments. I'll be happy to incorporate all the 
changes you've suggested.
I've been a bit swamped. What is a reasonable turnaround time for these?
OK if I get this done within the next week or two?
When I am done making the changes, should I upload a version -05 
or should I email the .txt or .xml only to you/Gen-art team? 

Sriram
---



From: Pete Resnick [mailto:presn...@qti.qualcomm.com] 
Sent: Monday, March 21, 2016 12:28 PM
To: General Area Review Team <gen-art@ietf.org>; a...@ietf.org; 
draft-ietf-grow-route-leak-problem-definition@ietf.org; IETF discussion 
list <i...@ietf.org>
Subject: Gen-ART LC review of draft-ietf-grow-route-leak-problem-definition-04

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 alg

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

2016-03-21 Thread Pete Resnick 

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

.

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