[secdir] Secdir telechat review of draft-ietf-6lo-use-cases-14

Robert Sparks via Datatracker <noreply@ietf.org> Thu, 17 November 2022 16:36 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 9807CC14CF0A; Thu, 17 Nov 2022 08:36:10 -0800 (PST)
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: 9.1.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166870297061.63316.5675193722863739658@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Thu, 17 Nov 2022 08:36:10 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rfuTc6cxpG5lJHpCw5ynrqqxRAc>
Subject: [secdir] Secdir telechat review of draft-ietf-6lo-use-cases-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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, 17 Nov 2022 16:36:10 -0000

Reviewer: Robert Sparks
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 review
comments.

This document is ready for publication as an Informational RFC

Thanks for addressing my Last Call comments. The new Security Considerations
text is helpful (though I would have preferred even more).

I'll point to one last potential problem spot (as a nit) that you may wish to
reconsider. See Section 3 at:

"Encryption is important if the implementation can afford it."

>From the rest of the document, it's clear that Encryption is important even if
the implementation _can't_ afford it (and what does "afford it" even mean in
this context)?

Please try to find more specific text to convey what you are trying to say.