[secdir] Secdir last call review of draft-ietf-v6ops-slaac-renum-03

Klaas Wierenga via Datatracker <noreply@ietf.org> Thu, 24 September 2020 12:16 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 CCC283A0A16; Thu, 24 Sep 2020 05:16:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Klaas Wierenga via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: v6ops@ietf.org, draft-ietf-v6ops-slaac-renum.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160094977880.10661.1204066741049367981@ietfa.amsl.com>
Reply-To: Klaas Wierenga <klaas@wierenga.net>
Date: Thu, 24 Sep 2020 05:16:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/g7vIhq6uSe8_79up_gsILOXI1hg>
Subject: [secdir] Secdir last call review of draft-ietf-v6ops-slaac-renum-03
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: Thu, 24 Sep 2020 12:16:19 -0000

Reviewer: Klaas Wierenga
Review result: Ready

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 document is clear and well-written. I believe that the workarounds
presented are a bit weak, but I guess the future work will address the issue in
a more fundamental manner. From a security considerations point of view, I
agree with the authors that the document does not introduce any new security
concerns.

The summary of the review is: Ready