Re: [Anima] ANI Autoconfiguration via DNS

[Esko Dijk <[e-mail]>]

Ok, this clarifies the concept further, thanks.

I see this as useful in a fully distributed ACP, for services to 'find each other' and also find nearest instances of particular services. All without having necessarily a central node that gets service registrations, keeps a database in memory of these, and serves service lookup requests.
(The latter concept of DNS service registration using an SRP Registrar as currently defined in the dnssd WG, is still possible - the Registrar itself can be advertised as a service in GRASP. But such thing may not be needed in ACP context. And it requires using the 'legacy' DNS-SD formats again.)

About using an ASA as a "proxy" to the classic DNS system, i.e. client sends GRASP service query and the proxy-ASA does the real DNS query, I had some doubts because the client might as well send its DNS queries in 'legacy' format directly to the GRASP-advertised DNS server.
But clearly the defined solution would enable both approaches.  So it could still be good to have this service encoding in GRASP available as a generic tool ; it may evolve over time how ASAs/ACP-nodes would use it in practice.

Regards
Esko
 
-----Original Message-----
From: Brian E Carpenter <[e-mail]> 
Sent: Tuesday, December 13, 2022 20:58
To: Esko Dijk <[e-mail]>; William Atwood <[e-mail]>; Anima WG <[e-mail]>
Subject: Re: [Anima] ANI Autoconfiguration via DNS

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
>