Skip to main content

Last Call Review of draft-ietf-ippm-route-08
review-ietf-ippm-route-08-secdir-lc-ladd-2020-06-27-00

Request Review of draft-ietf-ippm-route
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-07-03
Requested 2020-06-19
Authors José Ignacio Alvarez-Hamelin , Al Morton , Joachim Fabini , Carlos Pignataro , Ruediger Geib
I-D last updated 2020-06-27
Completed reviews Rtgdir Last Call review of -08 by Stewart Bryant (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Assignment Reviewer Watson Ladd
State Completed
Request Last Call review on draft-ietf-ippm-route by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/wxQ8T7wUmlG3OKRCjkm9Za_NKD8
Reviewed revision 08 (document currently at 10)
Result Has nits
Completed 2020-06-27
review-ietf-ippm-route-08-secdir-lc-ladd-2020-06-27-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the security area directors.  Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is Has Nits.

One little thing: class C has a meaning already, and I think the authors meant a
class to be referred to by C, not the ancient term for a division of IP space
that fell out of use long before my birth. Later on this becomes clear, but in
the introduction it did throw me off.

The conclusion paragraph also seems to describe a much less comprehensive
document then the introduction pragraph. This does seem to have been an effect
of evolution, and is pretty easily fixed and mostly cosmetic.

Now for the meat: what about the security considerations? Since this draft is
describing enhancements to traceroute and ways to describe the measurements
taken by such enhanced traceroutes, the security impact is minimal and the
authors reference the existing RFCs describing the security impacts of
tracroutes on networks.

Sincerely,
Watson Ladd