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

From: Normen Kowalewski <[email-masked]>
Date: Tue, 23 Jul 2019 02:37:17 +0200

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 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

---

From: Rob Sayre <[email-masked]>
Date: Mon, 22 Jul 2019 17:55:05 -0700

> Daer Stephane, Paul and DNSOP WG,

I think the draft is generally very helpful in navigating the acronyms and
abbreviations associated with this space.

It should be pointed out that "Do53:  DNS over UDP or TCP as defined in
[RFC1035]..." is transmitted in the clear, even though I'm sure most
readers of this list know that.

>       calls to the operating system on the computer,
>

This part seemed a bit off to me, although I admit I don't have good
alternate text.

Don't a lot of clients and servers already have userland versions of this
functionality, even prior to DoH etc? Sometimes they call getaddrinfo or
equivalent, but lots of them have their own cache policies etc. It is true
that they usually use the OS-supplied DNS servers by default, though.

thanks,
Rob

---

From: Normen Kowalewski <[email-masked]>
Date: Tue, 23 Jul 2019 08:57:56 +0200

Rob,

i should have more clearly stated that I also consider this draft and generally agreements on commonly used terms very helpful.

Paul, thanks for writing it.

BR, 
Normen

> On 23. Jul 2019, at 02:55, Rob Sayre <[email-masked]> wrote:
> 
> 
> 
> On Mon, Jul 22, 2019 at 5:38 PM Normen Kowalewski <[email-masked] <mailto:[email-masked]>> wrote:
> I think the draft is generally very helpful in navigating the acronyms and abbreviations associated with this space.
> 
> It should be pointed out that "Do53:  DNS over UDP or TCP as defined in [RFC1035]..." is transmitted in the clear, even though I'm sure most readers of this list know that.
>  
> 
> This part seemed a bit off to me, although I admit I don't have good alternate text.
> 
> Don't a lot of clients and servers already have userland versions of this functionality, even prior to DoH etc? Sometimes they call getaddrinfo or equivalent, but lots of them have their own cache policies etc. It is true that they usually use the OS-supplied DNS servers by default, though.
> 
> thanks,
> Rob
>

---

From: Puneet Sood <[email-masked]>
Date: Tue, 23 Jul 2019 14:10:53 -0400

> 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.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 24 Jul 2019 08:32:24 +0200

On 23 Jul 2019, at 20:10, Puneet Sood wrote:

> 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).

First of all, the calls being used by applications are not system calls. Not the definition of system calls I know of at least.

The difference between traditional DNS and what we have here to be is that in traditional DNS the configuration and control of where to send the DNS packets is made by the operating system, while with ADD it is done by the application.

The rest of the stuff is very similar. Still RD flag set. Still not much clue on the client side etc.

Then, as others have said, discussion about other transport protocols have been sneaking in here, but that does not really matter for me when talking about traditional DNS or ADD. Do53 or DoT or whatever is just another transport.

Good to define the terms though! But if you have different DoT things for when RD flag is set or not, why not also for Do53?

   Patrik

---

From: Dan York <[email-masked]>
Date: Wed, 24 Jul 2019 09:44:23 +0000

> On Jul 22, 2019, at 8:37 PM, Normen Kowalewski <[email-masked]> wrote:
> 

I agree with the suggestion to remove “ADD” from the draft. “ADD” seems different than the other ones and, in my mind, not *yet* in common-enough usage where its definition would be warranted. I also agree with Norman that the longevity of using “ADD” isn’t clear. 

I’m fine with the draft being adopted with the other terms. (We can then discuss more details about those specific terms.)

My 2 cents,
Dan