[secdir] Secdir telechat review of draft-ietf-sacm-coswid-20

Robert Sparks via Datatracker <noreply@ietf.org> Tue, 01 February 2022 18:50 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 A598E3A19EF; Tue, 1 Feb 2022 10:50:29 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Robert Sparks via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-sacm-coswid.all@ietf.org, last-call@ietf.org, sacm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164374142964.30506.5747811489693066422@ietfa.amsl.com>
Reply-To: Robert Sparks <rjsparks@nostrum.com>
Date: Tue, 01 Feb 2022 10:50:29 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MRZJMP91_hLkTHA2Wbdk--gmKiI>
Subject: [secdir] Secdir telechat review of draft-ietf-sacm-coswid-20
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, 01 Feb 2022 18:50:30 -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 last call
comments.

This document is ready publication as a Proposed Standard RFC.

Thanks for addressing my last call comments.

I still think you are missing an opportunity to avoid real implementation and
registry trouble by not further constraining the characters that can appear in
a name that will be registered. NMTOKEN, especially as defined in the
references you point to here, has a big expansion set.

Do you really want someone to be able to register the name "'̀·_·-·_·́'"?
(fwiw, that's b'\xcc\x80\xc2\xb7_\xc2\xb7-\xc2\xb7_\xc2\xb7\xcc\x81')

)