On Mon, Jul 22, 2019 at 8:38 PM Normen Kowalewski <[email protected]> wrote: > > Daer Stephane, Paul and DNSOP WG, > > 1. it was noted in todays meeting that the the “add" is not based on any > underlying rfc, and thus might be somewhat too vague. > +1 on that > > draft-hoffman-dns-terminology-ter-01.txt says: > Applications Doing DNS (ADD): Applications that act as stub > resolvers. This is in contrast to the way that applications > traditionally have gotten DNS information, which is to use system > calls to the operating system on the computer, and have the > operating system act as the stub resolver. "Applications Doing > DNS" is not limited to particular transports: it applies equally > to DNS-over-TLS, DNS-over-HTTPS, Do53, and future DNS transports. > ( Temporary note, to be removed before publication as an RFC: > there is a mailing list discussing Applications Doing DNS at > https://www.ietf.org/mailman/listinfo/add ) > > While I agree that “add” today covers discussion around the case described in > here, but the reason that it covers it is because “add” acts as a "catch all > bucket" for “various DNS things not well defined”. > If we want to cover the case of an application acts as/embed a stub resolver, > we may want to define a term (and draft) that covers exactly that, instead of > using the much wider term.
I like this clarification of what people are using ADD to mean. As I am listening to the ADD BoF talks, I want to point out that applications *have* been doing - just using a system API. The discussion and activity is now around applications embedding stub resolver functionality. So I propose term like Embedded Application Resolver Stub (EARS). For Do53 alternate name suggestion - DoUT. > > I wonder if something meant by "add" today, might have to drop from being > meant by “add” tomorrow after that feature becomes a well defined RFC? > Terminology would for me have to be less prone to change its meaning over > time. > > Thus I propose to remove “add” from the draft. > > 2. Share the notion that not all terms are equally well aligned with the > names of their underlying transport. Given that Do53 flows via plain UDP/TCP, > one could argue that this just means: IP is the transport => “DoIP”, but > that feels really awkward to me, and why create something new… so keep is > simple and retain Do53, enough people use it already. > > 3. And then, as per Geoff "get on with it”, because the other terms are all > useful. > > > BR, > > Normen Kowalewski > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
