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 <anima-boun...@ietf.org> On Behalf Of William Atwood
Sent: Monday, November 7, 2022 15:56
To: Anima WG <anima@ietf.org>
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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
