Re: [Anima] ANI Autoconfiguration via DNS

[Brian E Carpenter <[e-mail]>]

On 13-Dec-22 23:53, Esko Dijk wrote:
> Hello Bill,
> 
> You mention "the advantages of using native CBOR encoding".  So this refers to the CBOR encoding of (DNS) service properties, which would avoid parsing of the old DNS format.
> As I understand there's a wish of people to avoid having a DNS data parser in devices in the ACP, since the already-present CBOR parser can then be used instead.
> 
> Now if we would have such DNS-in-CBOR format, it would be more generally useful in IETF and not just in ANIMA. Do you agree?

If it's a 1:1 encoding of DNS format into CBOR, yes, and it sounds like useful work in any case.

However, when making a toy implementation of Toerless's proposal when it first appeared, I found that it is something different. What he proposes is a great simplification of the complexities of DNS-SD, where the semantics are split up over SRV, AAAA (or A) and TXT records, all of which need to be parsed to extract the semantic content and then merged into a single JSON-like object. This complexity is much better done in a single autonomic service agent that doesn't need to be in a constrained node. That is the advantage of Toerless's proposal and it is really ANIMA scope, IMHO.

Code at https://github.com/becarpenter/graspy/blob/master/ASA-examples/GetDNSSD2.py , lines 199 through 281. You will see several calls to the DNS resolver and analysis of the results;
the client node will just see a single CBOR object (inside a GRASP objective) or an error return.

Regards
     Brian
  
> If the format is more generally useful it could be defined in either one of the CBOR, CoRE, or DNSSD WGs.  (Although the latter may not be willing to renew something that's "already good")
> And we need to keep in mind the effort of the CoRE WG (still ongoing draft-ietf-core-href) to define a better encoding of the URI -> the CRI, in CBOR. It isn't trivial to cover all properties of the URI correctly. It takes a lot of effort.
> 
> If we still decide to do this in ANIMA WG context I would just go for the simplest possible subset of DNS-SD that fulfills the use cases and not try to be complete.
> 
> Regards
> Esko
> 
> -----Original Message-----
> From: Anima <[e-mail]> On Behalf Of William Atwood
> Sent: Monday, November 7, 2022 15:56
> To: Anima WG <[e-mail]>
> Subject: [Anima] ANI Autoconfiguration via DNS
> 
> Item 08 in the ANIMA agenda for IETF 115.
> 
> draft-eckert-anima-grasp-dnssd presents standards for the data
> structures (GRASP objectives) that will be required to effect
> autoconfiguration of basic services such as syslog, NTP, and DNS, using
> GRASP.
> 
> draft-eckert-anima-services-dns-autoconfig presents standards for
> actually providing these services, using the objectives defined in
> draft-eckert-anima-grasp-dnssd.
> 
> A strong argument is given in section 1 of
> draft-eckert-anima-grasp-dnssd, showing that the reliability and
> security of GRASP, and the advantages of using native CBOR encoding and
> GRASP flooding, justify the effort to define a GRASP-specific approach,
> rather than just using GRASP to carry the packets of the needed services.
> 
> Clearly these services are essential to any running distributed system,
> and standardizing their on-the-wire representation will likely reduce
> potential problems with incompatible software in the future.
> 
> I therefore encourage the WG to adopt these two drafts as Working Group
> documents.
> 
>     Bill Atwood
>