I'm the designated dnsdir reviewer for this draft (-14) building upon my
earlier review of the -09 draft.

While the specification of the client names has been significantly improved,
the core issue described in the previous review (conflict with RFC8552
underscored node name registration requirements) is still present in -14, and I
could not find any related discussion or explanation to support the unchanged
state. As such I believe this draft remains not ready. One additional DNS
related nit has been introduced in new text in section 7.

Underscored Name Issue
======================

Recapping the core issue: Section 2 describes three (non-exhaustive) formats
for client names, each of which is the "owner name of the client's TLSA
record, that is, the exact DNS name the server queries". As such, these names
need to comply with all RFC/BCP requirements for DNS names.

Format 1 (S2.1) and Format 2 (S2.2) do not comply with the RFC8552
underscored node name registration requirement:
- S2.1 specifies a name of the form [_service].[client-domain-name], where
  the _service label could be a custom string or, more commonly, a service
  name from the IANA Service Name Registry [SRVREG].
- S2.2 specifies a name of the form [devicename]._device.[org-domain-name].

In both formats the [_service] / _device label is the underscored label
closest to the DNS root, which makes it the global underscored node name,
and per RFC8552 S2: "If a public specification calls for use of an
underscored node name, the global underscored node name -- the underscored
name that is closest to the DNS root -- MUST be entered into this registry."

Section 13 of this draft does not request any such registry entries. The
registry is keyed on RR type, and its current TLSA entries are only _dane,
_sctp, _tcp and _udp.

Adding a registration would be straightforward for _device (S2.2), but it
appears structurally impossible for the [_service] format (S2.1), given
the label may be any SRVREG entry or a custom application-specific value!

S2.1 could be made compliant by placing a fixed, registered label between
the service label and the client domain name, e.g.
[_service]._application.[client-domain-name], with _application registered
alongside _device. RFC8552 S2 would then allow the custom values in the 
subordinate name to be defined in this document (e.g. SRVREG, app specific)
as S2.1 currently attempts to do.

Section 10 has gained an extended discussion of the challenges of the S2.1
and S2.2 name formats, in particular noting that they are incompatible with
RFC5280 S4.2.1.6 and therefore cannot appear in certificates issued by
commercial certification authorities, while remaining usable with DANE-EE,
raw public keys, or organisation-managed CAs.

None of this removes the need to comply with RFC8552 S2: the requirement
applies to any public specification calling for an underscored name,
regardless of which CA issues the certificate, and Section 2 clearly expects
these names to be looked up in the global DNS.


Nit
=====

Section 7 has gained several paragraphs of text discussing the format of the
ClientName TLS extension value, specifically that it be in DNS textual
presentation format with specific restrictions of octet content and length
which seem to confuse the issue of whether it's the DNS wire format length or the
TLS extension length that it's concerned about. It seems like the extension
value has been defined at 255 octets to match DNS wire format length, but then
specified to contain presentation format values, which are not guaranteed to be
255 octets or less, and therefore a bunch of extra text has been required to
try and clarify... - which at least for me actually made it harder to understand
what the section was trying to convey.

I would suggest the entire 3 paragraphs could be more clearly expressed in a
few sentences along the lines of: 

"The ClientName field contains the full owner name of the client's TLSA
record in common display format (RFC9499 S2), without the trailing dot. The
name MUST be convertible to a valid wire-format domain name and MUST NOT
use escape sequences; a name that cannot be expressed within 255 octets
cannot be used with this extension. Internationalized labels MUST be in
A-label form (RFC5890), consistent with Section 7.2 of RFC5280; U-labels
MUST NOT be used."