Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments

[Puneet Sood <[e-mail]>]

On Mon, Jul 22, 2019 at 8:38 PM Normen Kowalewski <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop