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

[Pete Resnick <[e-mail]>]

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 <[e-mail]>; General Area Review Team 
> <[e-mail]>
> 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:[e-mail]]
> Sent: Monday, March 21, 2016 12:28 PM
> To: General Area Review Team <[e-mail]>; [e-mail]; 
> [e-mail]; IETF 
> discussion list <[e-mail]>
> 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 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/%7Epresnick/
> Qualcomm Technologies, Inc. - [phone]


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