IETF Logo Mail Archive

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

Jim Reid <jim@rfc1035.com> Thu, 18 June 2020 15:36 UTC

Return-Path: <jim@rfc1035.com>
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 E41373A093E for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 08:36:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 QdWm6UhurDVU for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 08:36:52 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61283A0854 for <dnsop@ietf.org>; Thu, 18 Jun 2020 08:36:52 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 9487124205EC; Thu, 18 Jun 2020 15:36:51 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <F4857DCC-D623-41A5-8B02-575A0FBE3D1A@hopcount.ca>
Date: Thu, 18 Jun 2020 16:36:50 +0100
Cc: dnsop WG <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DA0E1657-D590-4FF1-8E2E-7944F33E7395@rfc1035.com>
References: <C2C9BDB4-AA7B-47B8-8735-2A529B37B4BA@icann.org> <F4857DCC-D623-41A5-8B02-575A0FBE3D1A@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>
X-Mailer: Apple Mail (2.3445.9.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/0qlEapSSeM1j04tlf6dUlc64aN8>
Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis
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: Thu, 18 Jun 2020 15:36:54 -0000


> On 18 Jun 2020, at 16:01, Joe Abley <jabley@hopcount.ca> wrote:
> 
> On Jun 18, 2020, at 16:48, Paul Hoffman <paul.hoffman@icann.org> wrote:
> 
>> Why is this WG considering making this document Standards Track instead of Informational? Also, why is the WG considering putting the document in our work stream at all? Can the WG can bring much value to the document itself? We do have lots of other things we are working on.
> 
> I think the question of the value the wg can bring is the important one.

I think we’re over-thinking this. Just issue new code point(s) for the new algorithm(s) and be done with it.

IMO there’s no need for the WG or the IETF to make any statements about the suitability of the underlying crypto used for optional signing and validation. That’s largely a matter for those who use these algorithms. Higher-level concerns about the crypto’s suitability should only come into play whenever an algorithm is a MUST/SHOULD recommendation in a standards-track RFC.

Maybe we need an RFC6895-like process for maintaining this IANA registry, like we have for RRtype codes?

v2.23.0 | Report a Bug | By Email