Re: [netmod] IANA registries

Kent Watsen <kent+ietf@watsen.net> Thu, 17 October 2019 22:02 UTC

Return-Path: <0100016ddbbe7a53-dc881230-0ee9-4809-ae79-491a7877d0be-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7F0120805 for <netmod@ietfa.amsl.com>; Thu, 17 Oct 2019 15:02:39 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 5rmZs_uoAPIg for <netmod@ietfa.amsl.com>; Thu, 17 Oct 2019 15:02:38 -0700 (PDT)
Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E921E120046 for <netmod@ietf.org>; Thu, 17 Oct 2019 15:02:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1571349756; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=h3xHqfQTuxlE6XV5VJWPrJf+3XGX3w+VUJ/xbTMjm/s=; b=LDYoI47N/Tj0XNqW7qlfZ5xbBZFG/6l4/+5w102Daqm18JvgxJFOVOPuvaPXVm4/ yL5TTaD4fTQhYC1ByEwYfMEB5TGKZhhr1yjSRUUK7nq0a6p5dT9LdK4hPnb+3a/Cu/C aALU1O3HFOnJ8TrNs8OnGN4exwdNbxkQMsmPLzug=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016ddbbe7a53-dc881230-0ee9-4809-ae79-491a7877d0be-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F57EC7D4-8928-4361-9DAE-2ED73EADEB8C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 17 Oct 2019 22:02:36 +0000
In-Reply-To: <936c711b27bf9186d19210332eb4df9149e9c7c7.camel@nic.cz>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
To: Ladislav Lhotka <lhotka@nic.cz>
References: <64c9cd72e94621afcff099e1cda69fdacd27b04a.camel@nic.cz> <20191010.140757.575758698470515713.mbj@tail-f.com> <936c711b27bf9186d19210332eb4df9149e9c7c7.camel@nic.cz>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.10.17-54.240.8.32
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nh-1g93miEtfiVnisE5UwIcQCaQ>
Subject: Re: [netmod] IANA registries
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 22:02:40 -0000

All,

>> That's a bit odd.  But perhaps it can be solved by actually not
>> filling in all values in this module, but rather make it a template
>> and instruct IANA to fill it in with the contents of the registry at
>> the time of publication.
> 
> OK, so the module template in the RFC couldn't be used at all - this might
> indeed help.

This is an interesting proposal indeed, and one that may help with the crypto-types "algorithm" discussion as well.

Having IANA be able to automatically publish revisions for select module is something that has been discussed in the past, partially in NETCONF wrt crypto-types, to eliminate the need for expensive RFC cycles, for updates that needed as a reaction to other RFCs being published, which should also have the effect of shortening the time it takes for those updates to be made.

AFAIK, no such relationship with IANA exists currently anywhere within the IETF.  To move this idea forward, the chairs need to discuss with the AD.  It might aid that discussion if there were an example template module...anyone want to a stab at one?   

Should there be an I-D that lays out the framework for the agreement with IANA, or would each draft (e.g., crypto-types) lay it out just for itself?  Actually, this sounds like what might come out of the discussion with the AD, but thoughts now are welcome to.

Kent // as co-chair