I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG.  These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.

Document: draft-ietf-anima-brski-discovery-13
Reviewer: Russ Housley
Review Date: 2026-07-03
Review Due Date: 2023-07-19


Summary: Not Ready


Major Concerns:

Section 2.2 and Section 2.3 are challenging. I think the reader would
be better served by a section or even an appendix that captures the
design rationale. In my view, the challenge discussion does not help
implementers nor does it help protocol designers avoid the same mistakes
in different protocol contexts in the future.

Section 3.4.4: Please seek review of this idea from the CA/Browser Forum
before publication as an RFC.

Section 3.5.1.1: This sections is about signaling.  The discussion od
DNS resolver dependencies has nothing to do with this topic.  The vast
bulk of this section is about implementation considerations.


Minor Concerns:

Throughout: Authors should ask someone to make an editorial paas through
the entire document.

Abstract: The abstract seems too long. The last sentence of the first
paragraph and the whole second paragraph can easily be merged. The last
paragraph can be dropped from the Abstract; it is covered in the
Introduction.

Section 2.1 says:

   This document specifies how to support these requirements by defining
   the discovery, selection and proxy machineries independent of the
   encoding used by specific discovery mechanisms and by defining a
   cross-discovery mechanism data model to represent protocol variations
   and discoverable entities via a set of IANA tables.  These IANA
   tables allow adding new variations, discoverable device types and
   discovery mechanisms.

This is very difficult to follow.  Perhaps you can turn it around and say
what IANA registries are defined and how they enable discovery and so on.
I suspect that cross-discovery will end up being a separate paragraph.
In fact, Section 2.4 comes close to doing what I am suggesting.  Perhaps
that is a better staring point for this text.

Section 3.1: This whole section is confusing. It is not a data model
(see https://en.wikipedia.org/wiki/Data_model). It is a mix of design
rationale and incomplete specification.  For example, there is a list
values for the variation type ("mode". "cmsj", "cose" or "jose"), but
none of them are explained (neither text nor pointers).

Section 3.1.1: I'm not sure "socket" is the right term. You mean that a
particular stack of protocols is used, and that often involves a "port",
but there can be more to it, like QUIC over UDP, or TLS over TCP.  In the
next section, IP Address, IP transport protocol, and IP transport protocol
port are listed, which is partially an improvement. You may need to also
know versions (IPv4 vs IPv6). The term "socket" is used many other places
in the document, not just this section.

Section 3.5.1.3: The text includes:

   If such a DNS RR does not exist, but a DNS host name for a different
   DNS method, or a different set of addresses than used by the
   registrar, then the registrar MAY be able to use a target domain name
   derived from that primary domain name by appending a unique name
   element.  This requirement exist to avoid the creation of
   unnecessarily inconsistent host names.

What requirement? A MAY statement is not a requirement.

Section 4: The use of "in this document" is confusing. Using the NEW:
convention for updates would resolve this problem.  Please write the new
text to refer to Section x.y of [ThisRFC].

Section 6: What assistance is DoT or DoQ offer?


Nits:

Many places: s/SHOULD not/SHOULD NOT/

Many places: s/MUST not/MUST NOT/

Section 2.1: s/Certificate Authorities (CA)/Certification Authorities (CAs)/

Section 2.2: s/constrained BRSKI [cPROXY]/constrained BRSKI with a join Proxy[cPROXY]/

Section 3.1.1: s/socket/port/

Section 3.1.3: s/select responders/select a responder/

Section 3.4.2: s/document a scheme how/document how/

Section 3.4.2: s/across all IDevID of/across all IDevIDs from/

Section 3.4.2: s/are recommended/are RECOMMENDED/

Section 3.5.1.2: s/a comma separated Values/comma separated values (CSV)/

Section 3.5.1.3.s/(priority weight)/(priority and weight)/

Figure 10 and Figure 11: Perhaps something other that square brackets
could be used so that IDnits does not get confused.  It thinks they are
references.

Section 4.1: s/[BRSKI-AE], section 5.1/Section 5.1 of [BRSKI-AE]/

Section 4.1: Correct the markdown? {#subreg-service-names}

Plese resolve these IDnits complaints:

  ** There are 142 instances of too long lines in the document, the longest
     one being 10 characters in excess of 72.

  == There are 9 instances of lines with non-RFC2606-compliant FQDNs in the
     document.

  == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be changed.

  -- The draft header indicates that this document updates
     draft-ietf-anima-brski-prm, but the abstract doesn't seem to mention
     this, which it should.

  == Unused Reference: 'RFC8368' is defined on line 3369, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC9148' is defined on line 3375, but no explicit
     reference was found in the text