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]. > 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. - +1 (858)651-4478 > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
