Sue, Thank you. I welcome the cross-review, assuming GROW WG chairs are OK with it.
Sriram >-----Original Message----- >From: Susan Hares [mailto:[email protected]] >Sent: Tuesday, August 25, 2015 5:07 PM >To: Sriram, Kotikalapudi <[email protected]>; 'George, Wes' ><[email protected]>; 'Christopher Morrow' ><[email protected]>; [email protected]; grow- >[email protected]; [email protected] >Cc: 'John G. Scudder' <[email protected]> >Subject: RE: [GROW] WGLC: draft-ietf-grow-route-leak-problem-definition >(ends: 8/24/2015 - Aug 24) > >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
