[Anima] Re: Comments on draft-ietf-anima-brski-discovery-09

[Esko Dijk <[e-mail]>]

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 [e-mail]
> To unsubscribe send an email [e-mail]

-- 
*IoTconsultancy.nl* | Email/Teams: [e-mail] | +31 6 
2385 8339