[secdir] Secdir last call review of draft-ietf-cbor-update-8610-grammar-05

Yaron Sheffer via Datatracker <noreply@ietf.org> Sun, 26 May 2024 21:37 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 2FC6FC14F610; Sun, 26 May 2024 14:37:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171675947518.43268.3899139067632039091@ietfa.amsl.com>
Date: Sun, 26 May 2024 14:37:55 -0700
Message-ID-Hash: IYKSXZN2RMMYIMF3HBBBFDNMPAPGSTYX
X-Message-ID-Hash: IYKSXZN2RMMYIMF3HBBBFDNMPAPGSTYX
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: cbor@ietf.org, draft-ietf-cbor-update-8610-grammar.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Yaron Sheffer <yaronf.ietf@gmail.com>
Subject: [secdir] Secdir last call review of draft-ietf-cbor-update-8610-grammar-05
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/q2xPfbzchXFBcADTnJl_4FMhmT0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Reviewer: Yaron Sheffer
Review result: Ready

This document describes the results of applying several errata to the CDDL
specification.

I concur with the Security Considerations section that the current document
likely has zero security implications beyond what's in RFC 8610.

I am clearly in the rough, but I'll say it anyway: from an implementer's
perspective, a document that repeats all of RFC 8610 with the errata
implemented (and clearly marked) would have been far superior to this one.
Instead, we now require an implementer to read and keep in sync RFC 8610, RFC
9165 as well as the current document.

Quoting from RFC 8610 itself: "Writers of CDDL specifications are strongly
encouraged to value clarity and transparency of the specification over its
elegance. Keep it as simple as possible while still expressing the needed data
model."

This reviewer is of the opinion that having to juggle three documents is
neither clear nor transparent.