Document: draft-ietf-anima-brski-discovery Title: BRSKI discovery and variations Reviewer: Russ Housley Review result: Not Ready
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 _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
