[Anima] services-dns-autoconfig

[Michael Richardson <[e-mail]>]

I tried to read https://datatracker.ietf.org/doc/html/draft-eckert-anima-services-dns-autoconfig-00
this afternoon between other appointments.

I think that the Introduction needs to tell me a lot more about the problem
space.

The Day-0/Day-1 stuff, I sort of understood, but not really.
Is it relevant how the device got onto the ACP, if it wasn't BRSKI?

I'm really unclear what the first sentence means:

   This document defines to support the autoconfiguration of Autonomic
   Control Plane (ACP, [RFC8994]) nodes for fundamental decentralized
   network services via DNS-SD GRASP, utilizing a new proposal mapping
   of DNS-SD ([RFC6763]) onto GRASP as its hop-by-hop multicast
   transport and encoding of messages.

I don't know what "DNS-SD GRASP" is, and I think I should know all the words
in the first sentence :-)

I'm not sure if this is document is providing for autoconfiguration *OF* the
ACP in nodes, or autoconfiguration of the nodes, once the ACP is configured.

I think that the goal of this document is to somehow gateway DNS-SD
requests/replies into GRASP M_FLOOD messages.  But, I'm having to reverse
engineer that.

A comment on:
}2.3.  DNS for operations
}
}   Availability of DNS names for network operations/troubleshooting is
}   today mostly an convenience in network operations, but with IPv6
}   evolving the need to use DNS names even in CLI based network
}   diagnostics is raising - because IPv6 addresses often are more
}   difficult to memorize by operators.  More and more network features
}   also support configurtion that instead of addresses include domain
}   names or URLs, and ultimately, any non-fully autoconfigured functions
}   should rather rely on domain-names and URLs instead of just addresses
}   for greater flexibility and relilability in the face of address
}   changes.

I think that there are three major reason why even CLI tools need to use
names:
1) because SSH, PKIX and other identities of the remote nodes are bound to
   the name.

2) because there are a multitude of IPv{4,6} addresses available for the
   destination, and the tools need to try them all.

3) because picking a source address (and protocol) is going to become more
   and more difficult as we get into new overlays, and MIF.
   Where you get the name->IP mapping will affect what source is really allowed.

We lack the right APIs... getaddrinfo(3) isn't enough.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-