[art] Re: [Last-Call] draft-ietf-lamps-macaddress-on-05 ietf last call Artart review

Russ Housley <housley@vigilsec.com> Wed, 11 February 2026 15:39 UTC

Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.300.41.1.7\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <177081812125.1482130.7462275831221735992@dt-datatracker-6bcfd44575-g5gjh>
Date: Wed, 11 Feb 2026 10:39:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <916B6236-1E23-4C44-9F05-D689D84C9F0D@vigilsec.com>
References: <177081812125.1482130.7462275831221735992@dt-datatracker-6bcfd44575-g5gjh>
To: Murray Kucherawy <superuser@gmail.com>
Message-ID-Hash: FDQJHITE3TGFJ7DDAL7VW3E26R3NZ3XQ
CC: art@ietf.org, draft-ietf-lamps-macaddress-on.all@ietf.org, last-call@ietf.org, spasm@ietf.org
Precedence: list
Subject: [art] Re: [Last-Call] draft-ietf-lamps-macaddress-on-05 ietf last call Artart review
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/F3saoO-w5pN4418Rt1JfbMNj2e0>

Murray:

Thanks for the review.

> 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.)

OCTET STRING is defined in ASN.1.  RFC 5280 and many other RFCs use it.  I think we should add references to:

   [X680]     ITU-T, "Information technology -- Abstract Syntax Notation
              One (ASN.1): Specification of basic notation", ITU-T
              Recommendation X.680, ISO/IEC 8824-1:2021, February 2021,
              <https://www.itu.int/rec/T-REC-X.680>.

   [X690]     ITU-T, "Information technology -- ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1-2021,
              February 2021, <https://www.itu.int/rec/T-REC-X.690>.

> (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.

I would not object to making this 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.

I think you are suggesting *all*.  That is fine with me.

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

It depends on the kind of device.  For example, access points need s stable MAC Address.  In this case, I'd be fine with a lower case should.

Russ

[art] draft-ietf-lamps-macaddress-on-05 ietf last… Murray Kucherawy via Datatracker
[art] Re: [Last-Call] draft-ietf-lamps-macaddress… Russ Housley