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
