Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

John C Klensin <> Mon, 26 March 2018 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B002A1205F0; Mon, 26 Mar 2018 01:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oo03YHFicdUg; Mon, 26 Mar 2018 01:30:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4089F1204DA; Mon, 26 Mar 2018 01:30:22 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1f0NWE-000F6k-Uv; Mon, 26 Mar 2018 04:30:18 -0400
Date: Mon, 26 Mar 2018 04:30:12 -0400
From: John C Klensin <>
To: Paul Vixie <>
cc: "John R. Levine" <>, Dave Crocker <>,,
Message-ID: <A67FF813D33C5CC02577B129@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <alpine.OSX.2.21.1803211104210.9553@ary.local> <> <5F44FA5B42805C52479DE491@PSB> <> <1DF1564CC2B88726B2B54CF4@PSB> <> <4C79BE1080735A41C8697C8D@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Mar 2018 08:30:24 -0000

--On Monday, March 26, 2018 01:20 -0700 Paul Vixie
<> wrote:

> John C Klensin wrote:
>> --On Monday, March 26, 2018 00:07 -0700 Paul Vixie
>> <>  wrote:
>>>> ... My impression has been that, while there is nothing we
>>>> can change about what is done and deployed, there has been
>>>> community consensus that it is a bad idea and that changes
>>>> have been made to the procedures for defining and
>>>> registering new RRTYPEs to reinforce the principle that new
>>>> RRTYPEs should be used and to make their use easier.
>>>> "Significantly challenging over the life of the DNS" is
>>>> undoubtedly correct, but that should not be, and presumably
>>>> is not, the situation today or in recent years. I believe
>>>> this document should not be advanced until that material is
>>>> changed to be clear that use of underscore or similar
>>>> conventions may be a reality but is not a desirable
>>>> substitute for separate RRTYPEs (with or without that
>>>> convention as appropriate).
>>> while i am sympathetic to this point of view, and even share
>>> it, i know that developers of new apps learned from the SPF
>>> RR example "never again" and that they can and have and will
>>> continue to create new apps based on TXT with or without the
>>> IETF's blessing. so i'm expecting your call for the stated
>>> clarification to not reach consensus in this WG.
>> If you are telling me I've fighting a losing battle, I
>> understand that. At the same time, as I trust people have
>> figured out from RFC 8324 and/or Bert's presentation in DNSOP
>> last week, I think there is reason for concern that
>> continuing to add features, especially features with either
>> high intrinsic complexity or significant kludge properties,
>> may eventually push things over some virtual cliff. That
>> makes the fight worth fighting even if most of the battles
>> are lost.
> i wish that reality as we will experience it was even halfway
> as cut or dried as you describe here. however, just as the
> worst abuser of "fake news" later became the most common
> accuser of that abuse in others, especially where the news
> _wasn't_ fake, so it is that your desire to create new RRTYPEs
> in preference to "just use TXT and allocate a new underbar'd
> name" will be called, wrongly and unfairly as i see it, but
> that won't matter, will be called, "unnec'y increase in system
> complexity." therefore, the battle you'll lose will be around
> who gets to call which thing by what name, and not around what
> problems should be avoided. the shape of this conference table
> has been decided -- your remaining decision is where you will
> allow yourself to be seated.

Again, Paul, I fear you are right, but that does not eliminate
my sense that trying to sound the alarm is worthwhile.