[art] draft-ietf-lamps-macaddress-on-05 ietf last call Artart review

Murray Kucherawy via Datatracker <noreply@ietf.org> Wed, 11 February 2026 13:55 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: art@ietf.org
Delivered-To: art@mail2.ietf.org
Received: from [10.244.6.212] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 57AE6B566454; Wed, 11 Feb 2026 05:55:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <177081812125.1482130.7462275831221735992@dt-datatracker-6bcfd44575-g5gjh>
Date: Wed, 11 Feb 2026 05:55:21 -0800
Message-ID-Hash: 5JGWCHKSM775UVZJJZGHRTAJV7JGNRRD
X-Message-ID-Hash: 5JGWCHKSM775UVZJJZGHRTAJV7JGNRRD
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-art.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-lamps-macaddress-on.all@ietf.org, last-call@ietf.org, spasm@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Murray Kucherawy <superuser@gmail.com>
Subject: [art] draft-ietf-lamps-macaddress-on-05 ietf last call Artart review
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/fU0P64BONThOCWoqzc9ZrHrxBJQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Owner: <mailto:art-owner@ietf.org>
List-Post: <mailto:art@ietf.org>
List-Subscribe: <mailto:art-join@ietf.org>
List-Unsubscribe: <mailto:art-leave@ietf.org>

Document: draft-ietf-lamps-macaddress-on
Title: Media Access Control (MAC) Addresses in X.509 Certificates
Reviewer: Murray Kucherawy
Review result: Ready with Nits

This document appears to be ready for publication.  It was straightforward to
understand, and I found no major or minor concerns from ART's perspective.

A couple of nits:

(1) "OCTET STRING" is defined in RFC 5280.  I suggest saying so in Section 2,
as that's a convention/definition used throughout.  (Or, more generally, refer
to RFC 5280 in that section as a source for some conventions used in this
document.)

(2) At the end of Section 3.3, there's a naked "SHOULD".  I suggest including a
sentence about why this advice is there and/or why it's not a MUST.

(3) In Section 3.4.2, I imagine "ALL" is in all-caps for emphasis, but this
makes it look kind of like a BCP 14 key word, and I suggest not doing that.

(4) The "SHOULD" in Section 4 could also use some "why not MUST?" sort of prose.