IETF Logo Mail Archive

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

Paul Hoffman <paul.hoffman@icann.org> Wed, 30 December 2020 22:50 UTC

Return-Path: <paul.hoffman@icann.org>
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 887F13A0AC4 for <dnsop@ietfa.amsl.com>; Wed, 30 Dec 2020 14:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 fcwOJBvH7tV9 for <dnsop@ietfa.amsl.com>; Wed, 30 Dec 2020 14:50:41 -0800 (PST)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 DA4893A0AC1 for <dnsop@ietf.org>; Wed, 30 Dec 2020 14:50:40 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 0BUMobY0012394 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Dec 2020 22:50:37 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.721.2; Wed, 30 Dec 2020 14:50:36 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0721.006; Wed, 30 Dec 2020 14:50:36 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Tim Wicinski <tjw.ietf@gmail.com>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons
Thread-Index: AQHW2iK2rfUUDm/KeUelowK7yn3CSKoIyneAgAB8ioCAAopEgIAE/PCA
Date: Wed, 30 Dec 2020 22:50:36 +0000
Message-ID: <87FA768C-53D3-4A66-BB40-8873DAFE9D85@icann.org>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_417AD412-DA16-41CE-A363-E525318E6098"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2020-12-30_14:2020-12-30, 2020-12-30 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PMsQi4t5hJ79S8e-irspyu36x6M>
Subject: Re: [DNSOP] [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: Wed, 30 Dec 2020 22:50:43 -0000

On 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 NOT REQUIRED (or NO ONE WILL IMPLEMENT THESE FOR YOU).
> 
> That would leave the registry with the strict requirements and allow items to get code points. 
> 
> Too simple an answer?

Yes, but it is close. I agree with Valery and others that allocation in this set of values needs to be "RFC required" to avoid losing track of the actual algorithms. Also, it can't be "the top 64 values" because some of them are already in use. And it really doesn't need to be 64 values: the WG will want to revisit this decision well before then. Making 100-122 be RFC Required, and updating RFC 8624 to show these values with "MAY" in each column, makes the intention clear.

--Paul Hoffman

v2.23.0 | Report a Bug | By Email