[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') )
- [secdir] Secdir telechat review of draft-ietf-sac… Robert Sparks via Datatracker