[secdir] Secdir last call review of draft-ietf-ippm-route-08

Watson Ladd via Datatracker <noreply@ietf.org> Sat, 27 June 2020 14:09 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A5F3A092F; Sat, 27 Jun 2020 07:09:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Watson Ladd via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: ippm@ietf.org, draft-ietf-ippm-route.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159326696737.10306.5653213903966509356@ietfa.amsl.com>
Reply-To: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 27 Jun 2020 07:09:27 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wxQ8T7wUmlG3OKRCjkm9Za_NKD8>
Subject: [secdir] Secdir last call review of draft-ietf-ippm-route-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2020 14:09:28 -0000

Reviewer: Watson Ladd
Review result: Has Nits

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