Wes, >I've reviewed the latest version, and generally think that it is ready to >proceed once the below comments are addressed.
Thank you for your comments and support. Just submitted a version-03 draft in which your suggestions/comments have been incorporated. Also, please see responses below. >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". Done. Replaced “attacker” with “offending AS” in all places except where malicious intent involved. >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. Done. >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. Hairpin seems to have a connotation that the turn is tight/constricted. So now I use the phrase “U-shaped turn” instead of “U-turn”. >Type 2 - "Update is crafted by the attacker...success of the attack" - >same comment here about attack vs leak vs offending AS Done. Changes made in the new version per your suggestion. >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. Done. I have added the wording that you have suggested above. >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. I have put in a definition of "lateral" and clarified that it means the same as "non-transit". I have used both names where relevant, like, "lateral (i.e. non-transit)". >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. I now use "transit provider" wherever I was using "provider" before. >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. Good idea. Done. I have also re-ordered the seven subsections (3.1 through 3.7) in accordance with a suggestion from Jeff. Thanks again. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
