[secdir] Secdir telechat review of draft-bchv-rfc6890bis-06

Brian Weis <bew@cisco.com> Fri, 14 April 2017 17:53 UTC

Return-Path: <bew@cisco.com>
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 AE8A4120725; Fri, 14 Apr 2017 10:53:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Brian Weis <bew@cisco.com>
To: secdir@ietf.org
Cc: draft-bchv-rfc6890bis.all@ietf.org, iesg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.49.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149219238158.15851.11445565927708323216@ietfa.amsl.com>
Date: Fri, 14 Apr 2017 10:53:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KldWYVftlJKzTtSL13dNPLRCCVE>
Subject: [secdir] Secdir telechat review of draft-bchv-rfc6890bis-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 14 Apr 2017 17:53:02 -0000

Reviewer: Brian Weis
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.

This five page document clarifies that the intent of the term "global"
in RFC 6809 is for a special-purpose address to be "globally
reachable". It also corrects some errors in the IANA Special-Purpose
Address Registries.

Since the scope of "global" is clarified rather than changed, there
does not seem to be any additional security considerations.  None of
the error corrections introduce additional security considerations
either.  The authors obviously came to the same conclusion since they
did not include a Security Considerations section. This does not
concern me personally, and I'll leave it for the Security ADs to
determine if they prefer one added that states "there are no security
considerations".

I consider the document Ready.

Brian Weis