Re: [DNSOP] A conversational description of sentinel.

Petr Špaček <petr.spacek@nic.cz> Wed, 07 February 2018 07:15 UTC

Return-Path: <petr.spacek@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 0FE6A1205D3 for <dnsop@ietfa.amsl.com>; Tue, 6 Feb 2018 23:15:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 tCeMzyvpWgx7 for <dnsop@ietfa.amsl.com>; Tue, 6 Feb 2018 23:15:39 -0800 (PST)
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 DDCC21204DA for <dnsop@ietf.org>; Tue, 6 Feb 2018 23:15:38 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:284e:2aff:fe7a:10d6] (unknown [IPv6:2001:1488:fffe:6:284e:2aff:fe7a:10d6]) by mail.nic.cz (Postfix) with ESMTPSA id 4DBD562516 for <dnsop@ietf.org>; Wed, 7 Feb 2018 08:15:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1517987735; bh=QM2LjguntyJM50Uxa5pHuavbX6mzuaVtVWPwXVjiah0=; h=To:From:Date; b=uxT5HAzuX5RwlOKM9dVY/+NIHeNsg1NgLDogggfTNNVUfFHGzERBjr9Fq0lu/4Uk1 6I7U6tRgraWa495H1szKyMS7dVOar7il1kAiUgP0nGokVwumEuNwrqvv2K/+Thxmzk CtlZrHOJjT7KC+lfwTJO8Qs0Y0jNf1rim8CADSX8=
References: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com> <D5D013D4-1EAD-434B-863A-29CB1BBEF4E4@vpnc.org> <496EFA88-BA70-460B-BFB2-69B2C7BC905D@apnic.net> <4540A279-4A37-4245-AE61-BEE5342E3F72@vpnc.org> <20180202075530.Horde.UWaxe9eenZ7PyxWYFHCFGdN@andreasschulze.de> <e8ac7bd0-26e6-cf97-e2ef-0ead50dc18ce@nic.cz> <88E7D27C-048E-44CB-B317-C892EA603D31@isc.org> <0c2a4a38-49d7-2b46-1ac8-1dda0812e217@nic.cz> <CAHw9_iJ6yL12OaGW5+fm8M3YUkrj46CvC2-ob7Xrc5HEaA_Z1Q@mail.gmail.com> <f9861a96-a930-bd08-7cf5-5c6b003f706e@nic.cz> <24C74B01-FC08-41CD-BB16-FD122F9EB61A@apnic.net> <alpine.DEB.2.11.1802051246230.30577@grey.csi.cam.ac.uk> <FDFE42D8-B805-4336-A9A5-B81F416B3251@apnic.net> <D07FE583-06F7-436D-97EF-4747B815AD3F@vpnc.org> <20180206094215.Horde.m4xt1lsOwvQ28hAbN1r_Tg4@andreasschulze.de> <alpine.DEB.2.11.1802061221510.30577@grey.csi.cam.ac.uk> <2ffeba22-5cf1-4eb0-b45c-fefb7cf1d8f7@nic.cz> <CBB24E6D-D20D-42CC-95D3-82A37C26BC31@vpnc.org>
To: dnsop@ietf.org
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <fdbd881c-d778-cd0f-a002-f1dd441f519b@nic.cz>
Date: Wed, 07 Feb 2018 08:15:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CBB24E6D-D20D-42CC-95D3-82A37C26BC31@vpnc.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/km5MMSREjFZ_hmc47AGJAnYg_QA>
Subject: Re: [DNSOP] A conversational description of sentinel.
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, 07 Feb 2018 07:15:41 -0000


On 6.2.2018 17:13, Paul Hoffman wrote:
> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
> 
>> On 6.2.2018 13:22, Tony Finch wrote:
>>> A. Schulze <sca@andreasschulze.de> wrote:
>>>>
>>>> Yes, "kskroll-sentinel-is-ta-NNNN" is more descriptive and specific.
>>>> I also prefer that longer variant.
>>>
>>> Yes, more friendly for web searches if someone is wondering about weird
>>> queries.
>>
>> Bonus points if we can get a number reserved by RFC editor, it would
>> allow us to use name like
>> test-rfc0000-is-ta-NNNN
>> test-rfc0000-not-ta-NNNN
>>
>> That would be super awesome.
> 
> ...and super-unlikely, given the history of the RFC Series.
> 
>> Is something like RFC number pre-allocation possible?
> 
> Sometimes (rarely), after Working Group Last Call. That's why I
> suggested "kskroll-sentinel" since those words are in the WG draft name,
> and will probably appear in the IETF Datatracker forever.

Fine. Now we need to have something actionable, e.g. set of names for
Geoff to test.

Can we have couple proposals and test them in one go, so results are
comparable?

I've gathered these:

kskroll-sentinel-is-ta-NNNN
kskroll-sentinel-not-ta-NNNN
is-ta--NNNN
not-ta--NNNN

I propose longer but more descriptive variant:
kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN
kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-no-NNNN

(I imagine that real meaning of name "kskroll-sentinel" will be known by
dozen people but hunders or thousands people will encounter it in
tcpdump, so why not make life easier for them. It costs almost nothing...)

Do we have other proposals?

-- 
Petr Špaček  @  CZ.NIC