Re: [DNSOP] Minimum viable ANAME

Vladimír Čunát <vladimir.cunat@nic.cz> Tue, 26 March 2019 17:17 UTC

Return-Path: <vladimir.cunat@nic.cz>
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 94622120592 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 10:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.02
X-Spam-Level:
X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 aY6LEfHvCgt9 for <dnsop@ietfa.amsl.com>; Tue, 26 Mar 2019 10:17:53 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 62AAD1206E3 for <dnsop@ietf.org>; Tue, 26 Mar 2019 10:17:45 -0700 (PDT)
Received: from [IPv6:2001:67c:1232:144:4e0f:6eff:fe44:5c48] (unknown [IPv6:2001:67c:1232:144:4e0f:6eff:fe44:5c48]) by mail.nic.cz (Postfix) with ESMTPSA id BB8236333F; Tue, 26 Mar 2019 18:17:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1553620663; bh=vuKa8DdQa8rzkOU8vMVvBiKIa3Sna/p0bY+vtekiWZA=; h=To:From:Date; b=g5bGHKBXfj3XFMuj63OxRAd84+ADGK+8o1Z0GFQ4CgzpmiUjOz74GSPHGHUTuz4Ij 0SSfm/+CQ/td2Ua5Sblbl9U0tdX1gCn92YBsRLaC3QVuKCOcSokdQ7SCTA2OeiCl8D bZOPumZh+c6x2j7ggHe8i15YNqmwpMBRdpRBmeno=
To: Olli Vanhoja <olli@zeit.co>
Cc: dnsop <dnsop@ietf.org>
References: <20180919201401.8E0C220051382A@ary.qy> <08C8A740-D09B-4577-AF2A-79225EDB526B@dotat.at> <20180920061343.GA754@jurassic> <E944887D-51ED-41A0-AC5A-3076743620D8@isoc.org> <acef1f69-8e4f-52cc-dca5-3ada9446e0ee@bellis.me.uk> <CABrJZ5HmCoSsGe2L-JkAsPywhcxyyVkvMmXCvQyJMjWHnMeT_w@mail.gmail.com> <alpine.DEB.2.20.1903261521290.13313@grey.csi.cam.ac.uk> <104ec4ea-296f-1657-5633-f6c1f2684274@pletterpet.nl> <alpine.DEB.2.20.1903261540330.13313@grey.csi.cam.ac.uk> <ec8e6848-c962-56b4-50d5-a7bd4b6d48e6@nic.cz> <CABrJZ5H=Ltora2m6_Gyk=O6+UqT-F704hvoKt5=U-TY7fx8JqA@mail.gmail.com>
From: Vladimír Čunát <vladimir.cunat@nic.cz>
Message-ID: <5dc745e4-0642-f013-6b85-bd7b5508c8fc@nic.cz>
Date: Tue, 26 Mar 2019 18:17:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CABrJZ5H=Ltora2m6_Gyk=O6+UqT-F704hvoKt5=U-TY7fx8JqA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------12615EBE8C1DC4B70DE2E827"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GHrTYVp3_NuVHyH2x0Yx9G-lUjg>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Tue, 26 Mar 2019 17:17:57 -0000

On 3/26/19 6:01 PM, Olli Vanhoja wrote:
> I think it's totally wrong to*choose*  here what we think is the best
> method to solve the issue.

I think it goes the direction you'll like.  My understanding of the 
current plan (of open-source implementors) is to have an RFC specifying 
*as little* as possible, so that it can go through more easily while 
improving interoperability of different (authoritative-only) 
implementations.  In the first RFC at least. After we (dnsop) see 
experience from that, it may be clearer where to go next, if anywhere at 
all.

Please correct me if I'm wrong; I know there are people who know "the 
plan" in more detail.

--Vladimir