Hello Alvaro, Thanks for your comments. Answers inline.
Camilo C. > On 18 Aug 2015, at 22:03, Alvaro Retana <[email protected]> wrote: > > Alvaro Retana has entered the following ballot position for > draft-ietf-grow-filtering-threats-07: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-grow-filtering-threats/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I have a non-blocking comment related to the characterization of the > unexpected traffic flows (and a nit). > > Section 6. (Security Considerations) Throughout the document the > unexpected traffic flows were characterized as potential policy > violations, not as routing security issues as is done here. I know that > the text has gone around the point of malicious intent (or not) before, > but I think that if you’re going to mention that it could be a "potential > routing security issue”, then you should say something more about it > (even if it is the result of non-malicious intent) — or just leave it at > policy violations. > <JCC> The security section indeed mentions that the objective of the document is security, however, we stopped focusing on that aspect at an earlier version. We’ll correct that part to something along the next lines: OLD: The objective of this document is to inform on this potential routing security issue, and analyze ways for operators to defend against them. NEW: The document informed on the potential routing security issue, and analyzed ways for operators to defend against them. > > Nit: > > The example in Section 2.2.1. (Unexpected traffic flows caused by > remotely triggered filtering of more specific prefixes) didn’t look good > to me at first..then I re-read the text until I discovered that the other > ASes (including 64505) are peering with both 64502 and 64503. Because of > how Figure 4 is drawn, it looks like 64505 is only connected to 64502. > Maybe centering that AS will avoid confusion. > <JCC> We wanted to depict that AS 64505 is peering with 64502 and to other ASes (possibly, but not necessarily 64503). However, We could reformat the figure 4 and make 64505 peer directly with 64503 to make it more clear. > > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
