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
- [DNSOP] status of the aname and svcb/httpsvc draf… Klaus Malorny
- Re: [DNSOP] status of the aname and svcb/httpsvc … Olli Vanhoja
- Re: [DNSOP] status of the aname and svcb/httpsvc … Eric Orth
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tommy Pauly
- Re: [DNSOP] status of the aname and svcb/httpsvc … Rob Sayre
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tommy Pauly
- Re: [DNSOP] status of the aname and svcb/httpsvc … Warren Kumari
- Re: [DNSOP] status of the aname and svcb/httpsvc … Erik Kline
- Re: [DNSOP] status of the aname and svcb/httpsvc … Erik Nygren
- Re: [DNSOP] status of the aname and svcb/httpsvc … Matthijs Mekking
- Re: [DNSOP] status of the aname and svcb/httpsvc … Klaus Malorny
- Re: [DNSOP] status of the aname and svcb/httpsvc … Shane Kerr
- Re: [DNSOP] status of the aname and svcb/httpsvc … Matthijs Mekking
- Re: [DNSOP] status of the aname and svcb/httpsvc … Evan Hunt
- Re: [DNSOP] status of the aname and svcb/httpsvc … Paul Vixie
- Re: [DNSOP] status of the aname and svcb/httpsvc … Benno Overeinder
- Re: [DNSOP] status of the aname and svcb/httpsvc … Klaus Malorny
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Dan York
- Re: [DNSOP] status of the aname and svcb/httpsvc … Klaus Malorny
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tim Wicinski
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Klaus Malorny
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Erik Nygren
- Re: [DNSOP] status of the aname and svcb/httpsvc … Ben Schwartz
- Re: [DNSOP] status of the aname and svcb/httpsvc … Brian Dickson
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tony Finch
- Re: [DNSOP] status of the aname and svcb/httpsvc … Brian Dickson
- Re: [DNSOP] status of the aname and svcb/httpsvc … Bob Harold
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tony Finch
- Re: [DNSOP] status of the aname and svcb/httpsvc … Andrew M. Hettinger
- Re: [DNSOP] status of the aname and svcb/httpsvc … Joe Abley
- Re: [DNSOP] status of the aname and svcb/httpsvc … Joe Abley
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tony Finch
- Re: [DNSOP] status of the aname and svcb/httpsvc … Evan Hunt
- Re: [DNSOP] status of the aname and svcb/httpsvc … Olli Vanhoja
- Re: [DNSOP] status of the aname and svcb/httpsvc … Lanlan Pan
- Re: [DNSOP] status of the aname and svcb/httpsvc … Paul Vixie
- Re: [DNSOP] status of the aname and svcb/httpsvc … Erik Nygren
- Re: [DNSOP] status of the aname and svcb/httpsvc … Andrew M. Hettinger
- Re: [DNSOP] status of the aname and svcb/httpsvc … Dan York
- Re: [DNSOP] status of the aname and svcb/httpsvc … Joe Abley
- Re: [DNSOP] status of the aname and svcb/httpsvc … Lanlan Pan
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Vladimír Čunát
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tony Finch
- Re: [DNSOP] status of the aname and svcb/httpsvc … Anthony Eden
- Re: [DNSOP] status of the aname and svcb/httpsvc … Matthijs Mekking
- Re: [DNSOP] [External] status of the aname and sv… Andrew M. Hettinger
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tim Wicinski
- Re: [DNSOP] status of the aname and svcb/httpsvc … Tony Finch