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

Paul Vixie <paul@redbarn.org> Wed, 21 March 2018 15:13 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 944091270AE; Wed, 21 Mar 2018 08:13:55 -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 t1srhLJDZplI; Wed, 21 Mar 2018 08:13:54 -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 974DD1242F5; Wed, 21 Mar 2018 08:13:54 -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 82A647594C; Wed, 21 Mar 2018 15:13:53 +0000 (UTC)
Message-ID: <5AB276B1.4070902@redbarn.org>
Date: Wed, 21 Mar 2018 08:13:53 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.24 (Windows/20180302)
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>
CC: dcrocker@bbiw.net, "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> <5F44FA5B42805C52479DE491@PSB>
In-Reply-To: <5F44FA5B42805C52479DE491@PSB>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qUJnDqx4nLi4YePVBM2ZWk0jr-s>
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:13:56 -0000


John C Klensin wrote:
> ...
>
> There is a strong case to be made that the introduction of the
> underscore convention was a kludge that violated fundamental
> design assumptions of the DNS and that it was added without
> considering, much less acting on, what other changes would be
> needed to support it smoothly.  ...

jon postel raised the same point (as the rfc editor when SRV was 
published.) i'll tell you what i told him: we needed only one thing, 
which was an identifier that could never conflict with a "host name". to 
do that, we added a character (_) to the front of these service and 
transport names which was not in the syntax of the old HOSTS.TXT definition.

it was minimal, and not intended to be generalizable, but it violated 
_no_ design assumption, fundamental or otherwise, of the DNS.

where SRV was a process violation is that it tried to cover existing 
systems like the then-young "world wide web" with some load balancing 
logic but without any geo-ip logic which has since been shown to be 
widely desired.

however, SRV works for the people and protocols who use it, and the 
experience we gained from "names that pass in the night" underscoring 
has informed the community's long term understanding of what we need.

jon didn't love it but he understood it and he withdrew his objection.

i support creating a real registry for future reserved-word DNS labels.

i just don't want to apply it to SRV.

-- 
P Vixie