[secdir] Secdir last call review of draft-ietf-6lo-use-cases-12

Robert Sparks via Datatracker <noreply@ietf.org> Tue, 05 April 2022 21: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 175D63A11AA; Tue, 5 Apr 2022 14:04:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: 6lo@ietf.org, draft-ietf-6lo-use-cases.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164919269800.5647.13515861264060312018@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Tue, 05 Apr 2022 14:04:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/BDhtxVilF8J0y2eQg4P5a-xJx0E>
Subject: [secdir] Secdir last call review of draft-ietf-6lo-use-cases-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: Tue, 05 Apr 2022 21:04:58 -0000

Reviewer: Robert Sparks
Review result: Has Issues

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 document has issues to address before publication as an Informational RFC

Issues:

>From the abstract: "The document targets an audience who would like to
understand and evaluate running end-to-end IPv6 over the constrained node
networks for local or Internet connectivity."

Its security considerations section claims "Security considerations are not
directly applicable to this document". Yet the text of the draft has several
places that rightly call out thing like "there exist implications for privacy",
"privacy also becomes a serious issue", and "the assumption is that L2 security
must be present." A summary of these things in the security considerations
section seems prudent. At _least_ call out again the assumption about L2
security.

The "Security Requirement"A summary of these things in the security
considerations section seems prudent. At _least_ call out again the assumption
about L2 security.

The "Security Requirement" row in Table 2 is not well explained. The values in
that row are explained at all. (For instance, the word "Partially" appears
exactly once in the document - it is unclear what it means).

Nits/Comments:

Appendix A is neither introduced nor referenced from the body of the document.
Why is it here?

I'm a little concerned about some of the technology descriptions possibly
moving beyond simple facts into interpretation or even marketing. The last
paragraph of section 2.5 is a particularly strong example. Look for phrases
section 4 that include "targets" or "targeted by" and make sure that's what the
organizations ins that define those technologies say (consider references).

At 'superior "range"', why is range in quotes? Think about restructuring the
sentences that use 'superior' to avoid the connotation of "better than". All
this document really needs to acknowledge is "goes further".