Skip to main content

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