Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

Paul Vixie <paul@redbarn.org> Wed, 21 March 2018 15:03 UTC

Return-Path: <paul@redbarn.org>
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 21C7C12D95C; Wed, 21 Mar 2018 08:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfT74tqdpJtT; Wed, 21 Mar 2018 08:03:22 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA5612DA51; Wed, 21 Mar 2018 08:03:22 -0700 (PDT)
Received: from [10.11.92.13] (wl-guest.labs.nic.at [83.136.33.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2C11A7594C; Wed, 21 Mar 2018 15:03:20 +0000 (UTC)
Message-ID: <5AB27439.40801@redbarn.org>
Date: Wed, 21 Mar 2018 08:03:21 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: dcrocker@bbiw.net
CC: "John R. Levine" <johnl@iecc.com>, art@ietf.org, dnsop@ietf.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>
In-Reply-To: <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/I_bDpMWTtqXbD1Xrqgxb_5qPcyQ>
Subject: Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.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: Wed, 21 Mar 2018 15:03:23 -0000

dave, i wasn't going to reply at all, since your snark is a turn-off. 
however, john decided to make this thing real, so now i'm stuck with it.

srv has a registry. that's working. that need not change.

adding another registry for other rr types who want to have well known 
underscored names will harm nobody and i'm unopposed.

paul

re:

Dave Crocker wrote:
> On 3/21/2018 4:05 AM, John R. Levine wrote:
>>>>  Harmonization for the sake of harmonization is bad, and very little
>>>>  Internet System technology gets it. Just do new stuff better.
>>>
>>> I agree completely. So please forgive my not understanding how your
>>> first and third comments are relevant to the current topic, which
>>> pertains to ensuring that new behaviors use the new model.
>>
>> I'm not Paul, but I'm guessing that he is referring to retroactively
>> changing the naming rules for SRV and other RRs, rather than
>> documenting existing practice.
>
>
> John,
>
> Your attempt at clarification is equally confusing to me, since it, too,
> seems to have nothing to do with the current effort.
>
> The effort is to create a registry -- which obviously differs from
> existing practice -- and to have that registry be used, going forward.
> Both the creation and the future use deviate fundamentally from
> 'existing practice'.
>
> d/
>
>

-- 
P Vixie