Esko, On your example:
Example: if an Ethernet Join Proxy tries mDNS to discover a Registrar, but the Registrar is only announced via the site DNS infrastructure (unicast), then discovery would fail.
Isn't that entirely dependent on whether the name is in .local or not? In any case it's an issue about what sort of resolver the pledge has, surely? And isn't this something that DNS-SD is supposed to take care of? BTW, the reason that GRASP has its own discovery mechanism via link-local IPv6 is to avoid any dependency on DNS or mDNS, so that it can run on bare metal. Thus, GRASP runs on bare 802.3 if you want it to; it doesn't really *need* an ACP except for security. I have no idea whether it could run on Thread and 6TiSCH. That said, I see a role for profiles.
Each "profile" would probably need to be a standard (defined outside IETF) or an RFC.
I think they could be less formally defined than that, at least initially. Regards/Ngā mihi Brian Carpenter On 11-Dec-25 03:13, Esko Dijk wrote:
Hi Stuart, thanks for the feedback on this draft. At IETF 124 I also voiced some similar comments on the current text - it's pretty difficult reading all in all. And most of the complex parts are not even needed for the average reader who just maybe wants to implement BRSKI discovery of a specific kind. The complex parts are intended for a narrow audience: developers of new BRSKI variations, to know how to construct and IANA-register the unique string that identifies their new variation. And even there I feel some things could be simplified. My suggestion was to split into a first "simple" part, and a second "complex" part that makes clear what the reader audience is. Most readers could then skip that part. Based on your comment "This is inventing problems that don’t really exist. ..." we can try to assume some defaults i.e. that particular link technologies support particular DNS-SD methods and base our text on that. There are some pitfalls however: - Thread mesh networks support unicast DNS-SD discovery queries, once a node is already part of the mesh; while mDNS is not supported. - However, for Pledge nodes, that are by definition *not* yet part of the mesh, only unsecured link-local communication is available for discovery which excludes (in Thread) using unicast DNS-SD. - Link-local mDNS *could* be used there, however in Thread this is not currently done, because it already defines a custom link-local node discovery protocol. - Other kinds of 6LoWPAN mesh network technologies do not use the Thread-specific method, so these may either use their custom method or use mDNS. - 6TiSCH defined by IETF is an example of such technology and it uses a custom protocol CoJP RFC 9031 to both discover and join. - You mention that Wi-Fi and Ethernet imply that mDNS is used: however, for the case of a Join Proxy discovering a Registrar we don't expect this would work. The Registrar is a central server/node that may be located several IP hops away from the current link, somewhere on the corporate network. - mDNS won't work then because it only finds link-local nodes. - The author's assumption in this case is that either unicast DNS-SD discovery is used, or GRASP discovery for the case of the ACP networks defined by the ANIMA WG in RFC 8995. - If it's unicast DNS-SD then a node sends the DNS request messages to whatever is configured as "the DNS server" in the network. This information is usually communicated in one of the known ways, e.g. in IPv6 an ND RA message option, or via DHCP. - Note that this unicast DNS-SD discovery is the same as in the Thread case for Thread-radio Join Proxy nodes. The only difference is how the DNS server is configured. It seems to me that we still need "profiles" to define how it works per network technology: for the Pledges (trying to discover Join Proxies), and also for the Join Proxies (trying to discover Registrars). Right now I can identify "profiles" would be needed for Wi-Fi, Ethernet, Ethernet-in-ACP-network, Thread and 6TiSCH. The current document leaves these "profiles" out of scope but does mention that without such a profile there's no interoperability. Example: if an Ethernet Join Proxy tries mDNS to discover a Registrar, but the Registrar is only announced via the site DNS infrastructure (unicast), then discovery would fail. And vice versa too! Each "profile" would probably need to be a standard (defined outside IETF) or an RFC. We could try to say all this in a simpler way than in the current text? regards Esko On 29-11-2025 02:58, Stuart Cheshire wrote:Toerless Eckert asked me for feedback on draft-ietf-anima-brski-discovery-09. I will confess that I did not read the whole thing thoroughly from start to finish. I did skim the parts related to DNS-SD as Toerless requested. As somebody who is not thoroughly immersed in this work, I found the document quite difficult reading. Just beginning with the abstract, it leaps into lots of acronyms that I don’t know: This document specifies how to make BRSKI communications autoconfiguring, extensible and resilient in the face of simultaneous use of different variations of the BRSKI protocol (BRSKI, BRSKI-AE, BRSKI-PRM, constrained BRSKI, stateless constrained BRSKI proxies). It would be helpful for people new to this work if the abstract at least began it with a sentence explaining what BRSKI is for and what it does. Reducing use of reference-as-noun would also help readability. If a reader doesn’t already know what all the references are, the use of unknown references as substitutes for English words makes reading the document feel like reading Clockwork Orange where you have to keep guessing what the mystery words mean. To anyone who doesn’t know the secret code, the text reads like this: In this document, a role is functionality performed by a BRSKI entity either as an initiator or responder. [SomeDocument] defines the roles of pledge, Join Proxy, registrar, MASA. [SomeDocument] adds the role Registrar-Agent. Trust anchor is a dependent role required by BRSKI, provided through [SomeDocument] or other protocols in [SomeDocument]. I suggest running the document through an AI proofreading tool, or at least a spell-checker. The first paragraph of the Overview has three mistakes in two sentences: BRKI was designed to support multi-vendor deployments ideally with zero additional provisioning in the network just to support BRSKI. In recent years, multiple variations of the BRSKI protocol *where* specified, *sich* as [BRSKI-PRM], [BRSKI-AE], [cBRSKI] and [cPROXY]; within these documents *that* are multiple options that need to be supported by all BRSKI entities involved in a BRSKI enrollment, such as pledge, proxy and registrar. where -> were sich -> such that -> there There seems to be some unnecessary editorializing about why simply using DNS-Based Service Discovery would not work: Because of the different options of how to run DNS-SD, the requirements in this document do not guarantee interoperability when using DNS-SD. One side could use unicast DNS-SD, the other mDNS, and there may be no mapping between the two. ... Hence, a mandatory to implement (MTI) profile is not feasible because of the wide range of variations to deploy DNS-SD. This is inventing problems that don’t really exist. For devices on Ethernet or Wi-Fi, simply use DNS-SD over Multicast DNS, and everything will work. For devices on Thread, use unicast DNS using Service Registration Protocol (SRP). Work is underway for defining zero-configuration SRP for Ethernet and Wi-Fi, with forward/backward-compatibility so that new devices use SRP when it is available while still working with older devices that only support Multicast DNS. Thread is new, so it avoided the backward-compatibility issue by just going straight to using unicast SRP for everything (multicast capacity is especially scarce with the limited throughput on Thread networks). In any case, these details are out of scope for this document. Just use DNS-SD as defined for the interface hardware the device has, and as DNS-SD evolves and develops new capabilities for various link types, devices using DNS-SD will inherit those improvements transparently as they become available. Variation Strings from the IANA registry Table 8 are encoded as DNS- SD Keys with a value of 1 in the DNS-SD service instances TXT RR using the shortened encoding of "key" instead of "key=1". In result, the value of the TXT RR is a sequence of zero terminated strings, each one indicating a single supported variation type choice. A variation may have the option of being represented by the empty string "". This is not allowed in the DNS-SD encoding, and instead the alternative variation string MUST always be used for DNS-SD. Variation strings in DNS-SD are case insensitive as required by DNS- SD. It is RECOMMENDED to only announce lowercase variation strings in DNS-SD. The use of variation strings can easily break the DNS-SD rule that they keys should be no more than 9 characters long. This is justified by the absence of value fields to keep the total length of the TXT RR reasonably short. This seems confused. I don’t know what “value of 1” means. It sounds like you are just defining boolean attributes. Why are your strings zero terminated? Why do you choose to not allow empty strings? If you choose to break the DNS-SD rule that keys should be no more than 9 characters long then this is not DNS-SD. You should expect that client libraries for DNS-SD might define a ten-character array as a stack variable to hold the key name as a C string, and any key names that don’t fit in this are rightly ignored as invalid. This is the whole point of defining limits in protocol specifications -- so that implementers know what they have to support. If you want to express a list of supported variation strings, I suggest you define a key “vars” where the value is a comma-separated list of supported variation strings, similar to how printers express their list of supported page description languages as a comma-separated list of MIME types: pdl=image/urf,image/jpeg, application/octet-stream,application/pdf,application/postscript, application/PCLm,application/vnd.hp-PCL,application/vnd.hp-PCLXL In several places in the document lines exceed the 72-character maximum width for text-format RFCs. Stuart Cheshire _______________________________________________ Anima mailing list [email protected] To unsubscribe send an email [email protected]-- *IoTconsultancy.nl* | Email/Teams: [email protected] | +31 6 2385 8339 _______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
