Last Call Review of draft-ietf-grow-filtering-threats-06
review-ietf-grow-filtering-threats-06-opsdir-lc-pignataro-2015-06-30-00
Request | Review of | draft-ietf-grow-filtering-threats |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | IETF Last Call Review | |
Team | Ops Directorate (opsdir) | |
Deadline | 2015-07-02 | |
Requested | 2015-06-23 | |
Authors | Camilo Cardona , Pierre Francois , Paolo Lucente | |
I-D last updated | 2016-04-06 (Latest revision 2015-11-07) | |
Completed reviews |
Genart IETF Last Call review of -06
by Robert Sparks
(diff)
Genart Telechat review of -07 by Robert Sparks (diff) Secdir IETF Last Call review of -06 by Taylor Yu (diff) Opsdir IETF Last Call review of -06 by Carlos Pignataro (diff) |
|
Assignment | Reviewer | Carlos Pignataro |
State | Completed | |
Request | IETF Last Call review on draft-ietf-grow-filtering-threats by Ops Directorate Assigned | |
Reviewed revision | 06 (document currently at 08) | |
Result | Has issues | |
Completed | 2015-06-30 |
review-ietf-grow-filtering-threats-06-opsdir-lc-pignataro-2015-06-30-00
Hi! I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document is on the Informational Track, and describes the impact (unexpected traffic flow in remote AS because of filtering more-specific prefixes) of AS filtering, including detection and mitigations. This document is quite comprehensive but it is weak on manageability considerations. Summary: (Almost) Ready with minor issues Major: None. Minor: CMP: Generally, this document does not include specifics about manageability considerations of the detection and mitigation mechanisms. I believe this is potentially a lost opportunity, and thus recommend that some more specifics are included. CMP: For example, there are mention of tools [4], which include implications on manageability of the system. Are there models? Are there CLIs? Are there logs, informs, or other constructs available that need mention? I believe so. CMP: Further, the security considerations briefly talks about this in the second paragraph — this topic should be expanded a bit. 9.1. Informative References [1] Donnet, B. and O. Bonaventure, "On BGP Communities", ACM SIGCOMM Computer Communication Review vol. 38, no. 2, pp. 55-59, April 2008. ... 9.2. URIs [1] http://www.ietf.org/rfc/rfc1812.txt CMP: I believe the way in which references are included is confusing. There are effectively duplicate citations (see above e.g., “[1]”.) I recommend moving the RFC References from “URIs” to “References” (either Normative or Informative). Nits: CMP: idnits passess successfully. No other nits identified. Hope these help, — Carlos. Attachment: signature.asc Description: Message signed with OpenPGP using GPGMail