Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Tony Finch <dot@dotat.at> Wed, 26 February 2020 17:24 UTC

Return-Path: <dot@dotat.at>
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 61B1E3A0D7C for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 09:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 DcgT-Iyzhr7M for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 09:24:35 -0800 (PST)
Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D110B3A0DBE for <dnsop@ietf.org>; Wed, 26 Feb 2020 09:24:34 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus
Received: from grey.csi.cam.ac.uk ([131.111.57.57]:38362) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1j70QD-000ClG-cx (Exim 4.92.3) (return-path <dot@dotat.at>); Wed, 26 Feb 2020 17:24:33 +0000
Date: Wed, 26 Feb 2020 17:24:32 +0000
From: Tony Finch <dot@dotat.at>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, "Andrew M. Hettinger" <AHettinger@Prominic.NET>
In-Reply-To: <f5f17c26-e673-119e-e7aa-bc88f8ef46a3@nic.cz>
Message-ID: <alpine.DEB.2.20.2002261657540.27562@grey.csi.cam.ac.uk>
References: <b34f1b0d-fa65-23d4-1b2b-761b965a2aae@knipp.de> <CAG8jCEzO7zrfL5G5CzdJ=c5wipJgqqHfyeA-a3-QjquoyPYgvg@mail.gmail.com> <3ead518d-f166-1c36-c3e9-18aeb355d160@pletterpet.nl> <20200220221517.GA16177@isc.org> <alpine.DEB.2.20.2002222349530.27562@grey.csi.cam.ac.uk> <CAH1iCiq+rOxs9c8zoJhAWbB6-0SP_WC5onF-DrbekwX=8iR49Q@mail.gmail.com> <CA+nkc8Coe8D1ECfrRwRUnzJ3azyJfXXUq3HMy63AL-4SOvmaaw@mail.gmail.com> <OF4062C1E9.B42128F1-ON86258519.006893C9-86258519.00690F29@prominic.net> <f5f17c26-e673-119e-e7aa-bc88f8ef46a3@nic.cz>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="1870870841-590449681-1582737873=:27562"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/QMXD6p3hjluM7_HjpK-BMGdwUZc>
Subject: Re: [DNSOP] status of the aname and svcb/httpsvc drafts
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Feb 2020 17:24:44 -0000

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> wrote:
>
> The current ANAME draft specifies new behavior for resolvers, and there
> I'd expect even slower overall upgrades/deployment than in browsers. 

From my point of view that was the least important part of it,
an optional extra that might help out CDNs some time in the future,
and not necessary for deployment. Existing ANAME implementations
work fine without it.

The ANAME draft is far too complicated. I tried to simplify it but in
retrospect I didn't go far enough.

There might still be some value in an ANAME draft that simply specifies
the syntax of the record, just to provide portability of zone files
between implementations that currently have non-standard ANAME or ALIAS
records. In this boiled-dry draft, ANAME would have absolutely no special
normative semantics, just an informative description of the relationship
between the sibling and target address records with no description of how
that should be achieved. (Note a domain might have more than one ANAME,
for existing implementations that support round-robin ANAMEs.) So the
codepoint could be allocated via expert review rather than standards
action.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government