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

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

Jeff,

Thanks a lot for your comments and support. 
Just submitted a version-03 draft in which your suggestions/comments have been incorporated.
Also, please see responses below. 

>Please consider updating the "replaces-by" for the draft to the original
>draft-sriram...

I think that is a comment for the chairs. 

>In general, this document is clear and very well written.  It does an
>excellent job at summarizing the landscape for route-leaks and provides lots
>of citations (which I haven't validated for
>correctness vs. the issues) for study.  

Thank you for the kind compliments.

>The majority of my comments are minor terminology tweaks, some additional
>explanations which might or might not be useful content and one discussion
>point for re-organizing some of the types.

>I'm supportive of this document moving forward even if my comments were not
>immediately addressed. 

Thank you. Your comments have pretty much all been addressed
in the revised -03 version just submitted.


>In your section on "type 2", where you use the term "aggregates", consider
>normalizing your terminology on "more specific" and "less specific" routes.
>While aggregate is semantically clear in this section, aggregation is often
>considered in the context of taking multiple more-specific prefixes and
>generating a new, less specific prefix.

Done. I now use the "more specifics / less specifics" terminology per your suggestion 
(avoided using "aggregates" where ever not relevant). 

>Type 3 attacks may also be called a "re-origination" attack.  Consider
>working that into the text, please.  

Done.

>Similar to my comment on type 2, Type 4 is treating the matter as a
>"de-aggregation" rather than simply announcing internal more specific
>routes.  Some of this is perspective, as seen by a receiver, but
>understanding the issue is perhaps better done 
>from the perspective of the originator.

Done. Changes made in the document accordingly.

>One source of type 4 issues have included how some older vendor implementations
>handled its configuration, leading to a trasient announcement of the more
>specifics.  A related one may be related to intentional generation of less
>specifics from internal more specifics.  In this case, routes contributing
>to the aggregate are configured with policy that is intended to suppress
>contributing routes, but such policy is only effective after the less
>specific aggregate route is created; this creation may lag for various
>implementation reasons.

Thank you for sharing the insight. I understand 
it is not meant for making changes in the document.

>Consider s/prefix-routes/routes/.  The prefix- seems a bit redundant, at
>least in a BGP routing context.

The substitution has been made in the revised doc.

>Types 5,6 and 7 are effectively forms of type 1.  The only thing varying is
>the *context* of the leaked route source AS and destination AS roles.
>Perhaps it's worth considering re-grouping the four sections in a way that
>highlights that?

I have changed the Types list into Subsections (3.1. through 3.7) 
per Wes's suggestion. And then I reordered/regrouped
those sections (Types) per your suggestion.
Basically, I've put the types you noted above together
(now they are Sections 3.1 through 3.4).
Also, please see the related comment I have 
added in the 1st paragraph in Section 4.

Sriram