Re: [DNSOP] New draft for consideration:

Martin Hoffmann <> Sun, 24 March 2019 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B0D51275F3 for <>; Sun, 24 Mar 2019 05:38:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.879
X-Spam-Status: No, score=-5.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UVRHTu4DdYVp for <>; Sun, 24 Mar 2019 05:38:09 -0700 (PDT)
Received: from ( [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3FEAD127981 for <>; Sun, 24 Mar 2019 05:38:09 -0700 (PDT)
Received: by (Postfix, from userid 58) id 4A4C0AA7F; Sun, 24 Mar 2019 13:38:07 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTPSA id AEF4CAA76 for <>; Sun, 24 Mar 2019 13:37:40 +0100 (CET)
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=none
Date: Sun, 24 Mar 2019 13:37:40 +0100
From: Martin Hoffmann <>
Cc: dnsop <>
Message-ID: <>
In-Reply-To: <>
References: <>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] New draft for consideration:
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 24 Mar 2019 12:38:11 -0000

Paul Hoffman wrote:

> Greetings again. As y'all have seen over the past few weeks, the
> discussion of where DNS resolution should happen and over what
> transports has caused some people to use conflicting terms. As a
> possible solution to the terminology problems, I am proposing a few
> abbreviations that people can use in these discussions. The draft
> below, if adopted by the DNSOP WG, would update RFC 8499 with a small
> set of abbreviations.

I would like to boldly suggest to not or at least not only define
abbreviations but proper names for the more general concepts instead.
The ship has probably sailed for the protocols itself and they will now
forever be DoH and DoT, but maybe we can agree on something more
meaningful such as "traditional [name] resolution" v. "alternative
[name] resolution" for the what the draft calls DaT and DaO.

The reasoning here is that proper terms are less confusing and, if
chosen wisely, can be understood by someone not intimately familiar
with the matter. When speaking, they aren’t much more bothersome than
the abbreviation. Writing will be a bit more work but then again, an
extra layer of clarity can help with avoiding misunderstanding.

I will spare you my aesthetic concerns around camel-case abbreviations.

Kind regards,