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

John C Klensin <john-ietf@jck.com> Mon, 26 March 2018 08:30 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002A1205F0; Mon, 26 Mar 2018 01:30:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo03YHFicdUg; Mon, 26 Mar 2018 01:30:22 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4089F1204DA; Mon, 26 Mar 2018 01:30:22 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) 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 <john-ietf@jck.com>
To: Paul Vixie <paul@redbarn.org>
cc: "John R. Levine" <johnl@iecc.com>, Dave Crocker <dcrocker@bbiw.net>, art@ietf.org, dnsop@ietf.org
Message-ID: <A67FF813D33C5CC02577B129@PSB>
In-Reply-To: <5AB8AD64.3040508@redbarn.org>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net> <5F44FA5B42805C52479DE491@PSB> <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.meeting.ietf.org> <1DF1564CC2B88726B2B54CF4@PSB> <5AB89C4C.7090300@redbarn.org> <4C79BE1080735A41C8697C8D@PSB> <5AB8AD64.3040508@redbarn.org>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gYPbp3OuLgMs4Qdb7pEWJw7hH0A>
Subject: Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Mar 2018 08:30:24 -0000


--On Monday, March 26, 2018 01:20 -0700 Paul Vixie
<paul@redbarn.org>; wrote:

> 
> 
> John C Klensin wrote:
>> 
>> --On Monday, March 26, 2018 00:07 -0700 Paul Vixie
>> <paul@redbarn.org>;  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.

    best,
      john