Re: [netmod] IANA registries

Ladislav Lhotka <> Mon, 21 October 2019 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E25D1200A3 for <>; Mon, 21 Oct 2019 06:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L5G0vXSc3vge for <>; Mon, 21 Oct 2019 06:46:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5BB7E120033 for <>; Mon, 21 Oct 2019 06:46:16 -0700 (PDT)
Received: by (Postfix, from userid 109) id 585CC18203E1; Mon, 21 Oct 2019 15:48:01 +0200 (CEST)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 72E141820046; Mon, 21 Oct 2019 15:47:59 +0200 (CEST)
From: Ladislav Lhotka <>
To: Kent Watsen <>
Cc: Martin Bjorklund <>, "" <>
In-Reply-To: <>
References: <> <> <> <>
Mail-Followup-To: Kent Watsen <>, Martin Bjorklund <>, "netmod\" <>
Date: Mon, 21 Oct 2019 15:46:12 +0200
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] IANA registries
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Oct 2019 13:46:19 -0000

Kent Watsen <> writes:

> 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.

Another option, also suggested in DNSOP WG, was to enable YANG to refer directly to the IANA registry.

> 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?

The problem with this is that we have no formalism for writing such templates.

> 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.

How about preparing an initial revision of the module, without writing any RFC, and hand it over to IANA to be published as a supplement to the registry?


> Kent // as co-chair

Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67