Re: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition (ends: 8/24/2015 - Aug 24)

["Sriram, Kotikalapudi" <[e-mail]>]

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