[secdir] Secdir last call review of draft-ietf-6lo-ap-nd-12
Adam Montville via Datatracker <noreply@ietf.org> Fri, 03 January 2020 16:04 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 8F85B12008D; Fri, 3 Jan 2020 08:04:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Montville via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, draft-ietf-6lo-ap-nd.all@ietf.org, 6lo@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.115.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Adam Montville <adam.montville.sdo@gmail.com>
Message-ID: <157806749349.9008.754513854275764571@ietfa.amsl.com>
Date: Fri, 03 Jan 2020 08:04:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/-VhQE-KhgDkonpusgk4rDmRHBEM>
Subject: [secdir] Secdir last call review of draft-ietf-6lo-ap-nd-12
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: Fri, 03 Jan 2020 16:04:54 -0000
Reviewer: Adam Montville Review result: Ready Address Protected Neighbor Discovery for Low-power and Lossy Networks, which guards against address theft, is almost ready for publication. There are two points that may warrant attention by the ADs: 1. In the first exchange with a 6LR: "When a 6LR receives a NS(EARO) registration with a new Crypto-ID as a ROVR, it SHOULD challenge by responding with a NA(EARO) with a status of "Validation Requested"". Under what circumstances would a challenge not be warranted? In other words, could this SHOULD be a MUST? 2. The following sentence in 7.1 reads, "The 6LR must protect itself against overflows and reject excessive registration with a status 2 "Neighbor Cache Full"". Does that need to be a MUST instead of a must?
- [secdir] Secdir last call review of draft-ietf-6l… Adam Montville via Datatracker
- Re: [secdir] [6lo] Secdir last call review of dra… Pascal Thubert (pthubert)