[DNSOP] Code Point Assignment Suggestion - was Re: [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Brian Dickson <brian.peter.dickson@gmail.com> Mon, 04 January 2021 18:43 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BEF963A0F3A for <dnsop@ietfa.amsl.com>; Mon, 4 Jan 2021 10:43:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id h--CkfqwVuVB for <dnsop@ietfa.amsl.com>; Mon, 4 Jan 2021 10:43:11 -0800 (PST)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 B11743A0F39 for <dnsop@ietf.org>; Mon, 4 Jan 2021 10:43:11 -0800 (PST)
Received: by mail-ua1-x933.google.com with SMTP id t15so9406213ual.6 for <dnsop@ietf.org>; Mon, 04 Jan 2021 10:43:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k6UocZ+6ahHdwEnF3h+wXkJ9VCYVsqWACWZrZFt/82Q=; b=K3GOjUSomgILQYQ5bIAhqhEOh+/DBPrAWYhjeqOyRfQQhi2bDC2D1NN/NPaxChF0a4 VNzm4b6zLLS6yo+YXnEXVdEH3N8lDil9YsLQBx1Is4HLq2mt1dzz3VP/AU7Q65C7X0mG /WsftG1dADyeK54KAFmHK25/157dT+WUFW9D8ifEMgWd3mnfTTsWvZBI55smihnWo0Dl 8i666B0+TVM2WyhyOMZBwvJgIRBsXxaZKfAKDA82NeL3wwcFqDd2v1ujsY/AVySnvYev HXeNmhioA3nq19GTkpanKTTMqET5zGJVnrrTZJKaHHO4esBuGKmx01+0dSqc+5641xAT +2Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=k6UocZ+6ahHdwEnF3h+wXkJ9VCYVsqWACWZrZFt/82Q=; b=RVWu5HMjvSTsU8f2Ms1YtlgOTeh8rNkxHNCXb7PJU92N9R301mbqI9IJu7661bE1jl j3hfs0wMcXnU6KXU6XajubdrQAXQLUE0CE3o7/eeK1clI/jf4cPUa6qIWu1ONosnzsqK J/OcVoibXdzyJPhusdOKRNFwZI99s8M4D3/G34+IpXPIihnMwQaVYPrE3aGkKYsX1KLL /ApzSn1xpE57AjnrxxedPFbGkrcjzfgqAtc1KndHl4JJswTi3U9o2wgfE272aocIiHSh P71AGcYYZUO4AraCyG12aUYnHOLdGpbGTzbm4l2+iU010gHADXK6zOANq1WY5ANMR1tg ENcg==
X-Gm-Message-State: AOAM533/G6VN2MA05fG2PVR2hQh0PzPCB15v2rYShdd+oJon7J75byUC e9puhLpB9Vu/4w57zA5J2CvjUWLpyF+OxTr7U0U=
X-Google-Smtp-Source: ABdhPJz4hLPkvSvB0xHz/UUSlFscxCFB+g1rddVv6/U3zwDkuXVvzZIz/ZAue3+ESXTeELbbx/oGuYsbbek47rPdE08=
X-Received: by 2002:ab0:3b59:: with SMTP id o25mr47386807uaw.62.1609785790427; Mon, 04 Jan 2021 10:43:10 -0800 (PST)
MIME-Version: 1.0
References: <CADyWQ+FpwL=MBbBU=QrAGeDT+j2Jm3aE5fFkYm+VbH-up6mdgg@mail.gmail.com> <1CA7153F-2D70-466E-9DB5-216D3118030C@icann.org> <CADZyTkngFzo2fzpVxbYFo=eXCcYzraVcvb5DFZzSDpGVWOUe=Q@mail.gmail.com> <9774B325-FD8E-416F-B553-4EDB058FF98B@icann.org> <44FC25E1-A0AF-4726-8B3F-0520DD7A5D0F@ogud.com> <CADyWQ+Fq2YvHQeq_k9ntnJMdhpmUtu_ainuR1pNCcXDpJ0yc_A@mail.gmail.com>
In-Reply-To: <CADyWQ+Fq2YvHQeq_k9ntnJMdhpmUtu_ainuR1pNCcXDpJ0yc_A@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 04 Jan 2021 10:42:59 -0800
Message-ID: <CAH1iCipfPj0mVvjg7Ya+v5zjMcTgf4j+jHHNn7odKLGWUBDa+w@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
Cc: Olafur Gudmundsson <ogud@ogud.com>, Paul Hoffman <paul.hoffman@icann.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000033f41b05b8177643"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jak73h_Y-28RMJevW2MFrS4fT48>
Subject: [DNSOP] Code Point Assignment Suggestion - was Re: [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
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: Mon, 04 Jan 2021 18:43:14 -0000

Without going into the original discussion (whether or not to reserve some
sub-range of code points for some purpose or another), I'd like to suggest
a method to use that conserves values better.
This would apply to any very limited resource (such as code points) within
a linear range.
It would basically only work when there are two consumers of the resource.

The method is:
Assign values from the bottom up, for one consumer of the resource.
Assign values from the top down, for the other consumer of the resource.

This has the benefit of allowing the "set point" for the allocation
boundary to be moved without requiring renumbering.

It also has the benefit of potentially using all of the resource without
any unnecessary waste owing to inefficient allocation strategies.

This is much more of an issue where the range is 8 bits in size (such as
DNSSEC algorithms), which is why I raise it in this context.

This is probably moot at this point, and probably doesn't need any
However, if there is a desire to have the ability to distinguish such
allocations (e.g. standard track vs informational track, or similar), this
method could be used for algorithm code points.


On Sun, Dec 27, 2020 at 10:40 AM Tim Wicinski <tjw.ietf@gmail.com> wrote:

> (Speaking without my chairs hat here)
> How about instead of loosening the requirement, we take the top 64 values,
> allocate them as either Experimental or FCFS, and it is explicitly noted
> That would leave the registry with the strict requirements and allow items
> to get code points.
> Too simple an answer?
> tim
> On Fri, Dec 25, 2020 at 10:53 PM Olafur Gudmundsson <ogud@ogud.com> wrote:
>> On Dec 25, 2020, at 3:27 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:
>> On Dec 24, 2020, at 10:28 AM, Daniel Migault <mglt.ietf@gmail.com> wrote:
>> Hi,
>> As the DNS is a global shared resource and its reliability is based on
>> **all** pieces of software adhering a common standard, I am inclined to
>> believe that new cryptographic algorithms introduced with anything less
>> restrictive than "IETF Review" - such as "Specification Required" and "RFC
>> Required" - does not sufficiently prevent altering the interoperability of
>> the DNS.
>> Why do you feel that DNSSEC has requirements stronger than other IETF
>> security prot0cols such as TLS, IPsec, S/MIME, and so on?
>> DNS is a fire-and-forget protocol, all the ones you mention include a
>> handshake that can be used to agree on algorithms. Such facility does not
>> exist in DNS.
>> I oppose any relaxation of thresholds to add algorithms to DNSSEC, as
>> there is no need.
>>   Ólafur
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop