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]
