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

[Toerless Eckert <[e-mail]>]

Thanks a lot, Stuart, detailled answers inline, summary here:

- Added "Overview" section at the beginning to hopefully make it easier to get into the doc,
  also improved abstract and hopefully expanded all abbreviations on first use.

- Added section 2.3 "Discovery challenges" explaining the reasons why there is stuff in the text
  that only DNS-SD library developers need to know. As we discussed: expect this to be used
  where the libraries need to be written in networks where there is no DNS/DNS-SD yet

- Accordingly rewrote the DNS-SD signaling section 3.5.1.1. I especially elaborated my on the
  concerns i had in the back of my mind: Experiences with big service provider network whom i
  upsold into using a DNS feature in their netowrk routers (long time ago) and then they
  had to remove it because the DNS servers where not reliable enough and the impleemnttions
  where creating undesirable dependencies bringing down more than needed, and secondly the
  problem that discovery of DNS servers is really only automatic in specific networks like Thread,
  but otherwise done with good amount of per-router manual config.

- Used claude.ai twice for spell/sentence check. See prompt in changelog.
  I put the claude.ai fixes into separate revs so it is easy to recognize what changes where due to claude.ai
  (given the chicken apocalypse on ietf mailing list re. the risk of AI generated RFCs.) Once 09->10, and
  the second time 12-13.

- Fixed the DNS-SD key encoding as you proposed (var={variation,...}) (i had already reported that at IETF125
  after our discussion).

- Full diff by comparing 09->13.

Cheers
    Toerless


On Fri, Nov 28, 2025 at 07:58:25PM -0600, Stuart Cheshire wrote:
> Toerless Eckert asked me for feedback on draft-ietf-anima-brski-discovery-09.
> 

(1)

> 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.

Right. The abstract may be too long now, and if other reviewers complain about that, i will
move whatever they feel is too much into the first (overview) chapter, but i hope that
the abstract is now a lot easier to digest and make the document more interesting to
read for people more interested in discover in general instead of only those wanting
to use it directly with BRSKI. Last paragraph now:

| While this document is specific to BRSKI, many of the mechanisms specified in this document
| may serve as templates for other protocols: Resilience and failover with discovery protocols,
| signaling non-interoperable variations of a protocol, abstracting the data model from the
| encoding specifics of different discovery mechanisms, specifying discoverable entities, variations
| and discovery protocol specific encodings via IANA tables.

(2)

> 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].

a) I hope that by introducing the mystery words (BRSKI-foobar) already in the abstract
as non-interoperable variations of the BRSKI protocol, and then detailling their expansions
early on in chapter 1, that readers will be very familiar with these terms by the time 
they get to chapter 3 from which you are citing above.

b) re-reading the paragraph in question, i also improved the text to better define
roles from the assumed to be understood terms initiator/responder:

| In this document, a service is a specific functionality provided by a responder entity to an
| initiator entity over a network socket using a particular transport/security/session stack
| (such as TCP, UDP, COAP, DTLS). These functionalities are called roles and initiators are
| enabled by the functionality of this document to automatically discover responders and select one
| that is interoperable with it.
| 
| {{BRSKI}} defines the roles of pledge, Join Proxy, registrar and MASA. {{BRSKI-PRM}}
| adds the role Registrar-Agent. Trust anchor (CA) is a dependent role required by BRSKI, provided
| through {{EST}} or other protocols in {{BRSKI-AE}}.


(3)

> 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

Yes, using claude now as spell checker, but committing spell-checked versions separately
so it is easier to diff purely against what that "AI" changed. -10 was the first
run for example.

(4)

> 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.

Rewritten. See beginning of reply for the main reasons, but i hope this is
fine and i've tried to explain in our discuss how this is addressing also
networks and implementations with little or no pre-existing DNS/DNS-SD


>     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.

Indeed. When reading the SHOULD 9 character limitation i was ony thinking
about the robusness principle "Be conservative in what you send, be liberal
in what you accept.” - and i thought i was just violating the sender side
for what i assumed to be mostly newly written DNS-SD libraries. While you
where expecting mostly existing DNS-SD libraries and also pounded on not
expecting the robustness principle against receiver sides. Somewhere in
your logic there is another principle that i am not sure we've written
out as well as the robustness principle. And i wonder what reason there
could ever be to violate the SHOULD - and if there is none, why there is
no MUST (don't remember that you had an answer for that).

> 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

Yes, i have changed the text and encoding to be a comma separated list
of variations, now it should be perfectly complying to all rfc2119 language
of DNS-SD.

> In several places in the document lines exceed the 72-character maximum width for text-format RFCs.

In the IANA tables, yes. I have tried to do everything humanly sensible to
make it work, and it should even become better (shorter), when the column with
references will change from draft-ietf-foobar-2-long to RFCxxxx, but i can
not yet guarantee that it would still fit 72 characters. BUT: I will hold out
on making any further changes, because they would make the RFC tables start
to looks really ugly, and it's totally incomprehensible why that should be
necessary when the IETF and i think all RFC editors are on a crusade for many
years now to make HTTP now the preferred format - and the tables already
render well in HTTP.

So my next two defensive approaches are:

Let RFC editor deal with that formatting issue.

RFC Editor could simply replace the tables which are too wide
with a text saying "Please refer to the HTML rendering to see this table".
After all, we've been doing this repeatedly for graphics, so why not for
tables.

But of course, i am always open to any changes that would make 72 characters
work without totally making the table data become less well readable for humans
(which unfortunately are options other people have recommended - who i think have
 not been concerned enough about a human friendlty RFC).

Anyhow. Thanks a lot for your review. And i hope my fixes resolve the technical
issues.

Cheers
    Toerless
> 
> Stuart Cheshire
> 

-- 
---
[e-mail]