Re: [DNSOP] A conversational description of sentinel.

Joe Abley <jabley@hopcount.ca> Tue, 06 February 2018 16:31 UTC

Return-Path: <jabley@hopcount.ca>
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 5176112D82E for <dnsop@ietfa.amsl.com>; Tue, 6 Feb 2018 08:31:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 AwIY2neVDG4q for <dnsop@ietfa.amsl.com>; Tue, 6 Feb 2018 08:31:46 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECAF12D94A for <dnsop@ietf.org>; Tue, 6 Feb 2018 08:31:46 -0800 (PST)
Received: by mail-io0-x234.google.com with SMTP id t22so3098751ioa.7 for <dnsop@ietf.org>; Tue, 06 Feb 2018 08:31:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbuO69doLPHuxZioRStuyGG0MaJ8+SzeCyV2U5yWhlQ=; b=UjU+VplYEzE0eJY4zM9yoDnD81eO3nqbrIzKMTx3UrVdEnc6LY7mVUs/VZhADP8KmO u4ypnyMRt/rJVl1T/i57rVGrxWd+RNtJ6M5GqkTR+5Jjn9rtRKhrYYOeG9AfIgN9LjuC AOf9c04/Vis661TwrXUMvpbtzJvh3FckmZcSw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FbuO69doLPHuxZioRStuyGG0MaJ8+SzeCyV2U5yWhlQ=; b=FcsvnDlI6c0lwQSEQEqiqXYaQYUBAseKiRk1ybXxDlK8ZAQsMRwnZRwNaaaPfYH803 /QPVt9MSMSsmrfmscf++SCzhHK0cJlBErZGETRYbHCK6klB0aSwx2td7DPBJb9+AbGUN vp1A7S+VlCqVhPP0AOFlOl5wVGTFJnyFDVqQMSlAZN2z5Pd6L6AD0G8k8qNlDlm3BYSJ 8zgeb/LwBxlaocK+ycRL9UZevuWIrdKjt0PJTo0g6VG3d8VqcZqR9mF38RBChSdgAS8K tFEmw3E5+Vm8O8n7qNDO0rQYuP5FAEeNnt53XjA8XMIEJtsGKreH3VrqwlOxoK3N/qRV PVwQ==
X-Gm-Message-State: APf1xPAH9o0/O6o0cDqwOd5FVKI66I2mviOYkeTsePrB3aKaXg+T8w/Y M2ttA60+1aPYuMe7J5o5AEz6WQ==
X-Google-Smtp-Source: AH8x224gScFfSDexE9b2Yu52vPZXzhL2BLxIduTefUhvBCRyu9oIFDo5scDr8nQ+8wB6G6s/Z1vYIQ==
X-Received: by 10.107.174.85 with SMTP id x82mr3534845ioe.27.1517934705827; Tue, 06 Feb 2018 08:31:45 -0800 (PST)
Received: from [199.212.92.9] (135-23-173-35.cpe.pppoe.ca. [135.23.173.35]) by smtp.gmail.com with ESMTPSA id c9sm7431861iod.5.2018.02.06.08.31.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 08:31:44 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <2ffeba22-5cf1-4eb0-b45c-fefb7cf1d8f7@nic.cz>
Date: Tue, 06 Feb 2018 11:31:39 -0500
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE99B8A6-F3EC-4E96-A81F-78C7276726D9@hopcount.ca>
References: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com> <FDCED4D6-A7CE-465B-8344-CA89753ADF19@vpnc.org> <74C0CA59-6D53-4A60-ACBA-4AF5B51FE3FF@apnic.net> <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>
To: Petr Špaček <petr.spacek@nic.cz>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tcNka9NLPcG6IE8VfwBKxFTPKFM>
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: Tue, 06 Feb 2018 16:31:48 -0000

On 6 Feb 2018, at 11:04, Petr Špaček <petr.spacek@nic.cz> 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.
> 
> Is something like RFC number pre-allocation possible?

You can include instructions to the RFC editor to replace some token in the document by the assigned RFC number. I've done this before in IANA Considerations sections where it is necessary to specify a reference; I've included something like "<this document>" in a table and specified in a note to be removed before publication that that text be replaced by the RFC number.

This seems perfectly possible for this document, but it doesn't help early implementers, and presumably runs the risk of having resolvers deployed that handle different magic sentinel labels depending on when they were released (unless, perhaps, the resolver handling is based on a pattern and not a specific label that has to be matched exactly).

Some other RFC numbers were clearly reserved for specific documents in the past (e.g. see RFC 2821/2, obsoleting RFC 821/2) but perhaps those were special cases.


Joe