that seems like a good idea, thanks! On Tue, Aug 25, 2015 at 5:06 PM, Susan Hares <[email protected]> wrote: > Siram: > > Do you want me to post this for a cross-review in IDR? > > Sue Hares > > -----Original Message----- > From: GROW [mailto:[email protected]] On Behalf Of Sriram, Kotikalapudi > Sent: Tuesday, August 18, 2015 8:18 AM > To: George, Wes; Christopher Morrow; [email protected]; > [email protected]; [email protected] [email protected] > Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition > (ends: 8/24/2015 - Aug 24) > > Thank you, Wes. > The comments you've offered are greatly helpful for improving accuracy as > well as clarity in what is being said. > I plan to incorporate them in the next revision (v. -03) soon. > > Sriram > ________________________________________ > From: GROW <[email protected]> on behalf of George, Wes > <[email protected]> > Sent: Monday, August 17, 2015 2:45 PM > To: Christopher Morrow; [email protected]; [email protected]; > [email protected] [email protected] > Subject: Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition > (ends: 8/24/2015 - Aug 24) > > I've reviewed the latest version, and generally think that it is ready to > proceed once the below comments are addressed. A cross-review from IDR might > also be useful before it goes to IETF LC. > > There are several areas in Section 3 where you use attack and leak > interchangeably in a way that adds a bit of confusion. I think it'd be > better to pick one and stick with it, probably leak rather than attack, and > only use attack if you are describing something that is almost always > malicious rather than accidental. > I.e. > attack type 1 - "The update basically makes a > U-turn at the attacker's multi-homed AS. The attack (accidental > or deliberate) often succeeds" > Previously, you say that you refer to the leaking AS as the "offending AS". > I'd suggest using that here instead of "the attacker's". Similarly, you've > already said that most leaks are unintentional, so it might be better to > simplify that next sentence by saying "the leak often succeeds" > and eliminate the parenthetical. It is also unclear from the text exactly > what you mean by U-Turn (it's not going back the way it came, so actually > hairpin might be a better term), so a few words to clarify might be useful. > Type 2 - "Update is crafted by the attacker...success of the attack" - same > comment here about attack vs leak vs offending AS > > Type 4 - While often the increase in prefixes causes its own problems > (dramatically increased routing table size, exceeded max prefix limit, > etc) you may want to add some text to the effect of "these more specifics > may cause the routes to be preferred over other aggregate announcements, > thus redirecting traffic from its normal best path" as that makes it clearer > what the impact of the leak is in this case. > > Type 5 - I'm not sure that the terms "lateral" or "non-hierarchically > peering" really add a lot to the explanation. The rest of your text sounds > more like you're describing a non-transit relationship (typically only > announce their customer routes to each other), which I think would be an > easier term to define and more likely to be something readers would be > familiar with. Either way, the explanation in this section could benefit > from a good editing pass for clarity. > > Type 6/7- "its provider" - do you mean its transit provider? Otherwise it's > unclear what distinguishes this from type 5, and again would be useful to > use transit/non-transit to clarify. > > Also, an editorial nit/personal preference: since there are so few sections > to this document, it might be useful to take each of the subtypes and make > it a subsection of section 3 (e.g. 3.1 3.2, 3.3...), so that it's easier to > refer to it in text and reviews - subsections can have HTML anchors so that > you can link right to them, and they show up in the table of contents as > well. > > Thanks, > > Wes > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
