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

Paul Vixie <> Mon, 26 March 2018 08:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FB961205F0; Mon, 26 Mar 2018 01:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gFRc-yeguFrU; Mon, 26 Mar 2018 01:20:53 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 751671204DA; Mon, 26 Mar 2018 01:20:53 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427] (unknown [IPv6:2001:559:8000:c9:4ca8:bd4c:848b:7427]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 533737594C; Mon, 26 Mar 2018 08:20:53 +0000 (UTC)
Message-ID: <>
Date: Mon, 26 Mar 2018 01:20:52 -0700
From: Paul Vixie <>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: John C Klensin <>
CC: "John R. Levine" <>, Dave Crocker <>,,
References: <> <> <> <> <> <alpine.OSX.2.21.1803211104210.9553@ary.local> <> <5F44FA5B42805C52479DE491@PSB> <> <1DF1564CC2B88726B2B54CF4@PSB> <> <4C79BE1080735A41C8697C8D@PSB>
In-Reply-To: <4C79BE1080735A41C8697C8D@PSB>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:20:55 -0000

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.

P Vixie