Re: [netmod] IANA registries

Ladislav Lhotka <lhotka@nic.cz> Mon, 21 October 2019 15:22 UTC

Return-Path: <lhotka@nic.cz>
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 37ADE120020 for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2019 08:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.998
X-Spam-Level:
X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=nic.cz
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 kqquz3iP6Hcr for <netmod@ietfa.amsl.com>; Mon, 21 Oct 2019 08:22:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 00D0812004A for <netmod@ietf.org>; Mon, 21 Oct 2019 08:22:46 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a88f:7eff:fed2:45f8]) by mail.nic.cz (Postfix) with ESMTPSA id 07B4B140E40; Mon, 21 Oct 2019 17:22:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1571671365; bh=rqueZ+h2c7YCqsK6aDkS5bL+Yyxrvuk9eEyxrpYWS54=; h=From:To:Date; b=Ml5uEfi2p7AsQFCDKdWKjafk0vbLwKgjP/HRbGCeicgM8LF4RAnZ0q94Yocn0o2g1 ERSLw+qgj76W3NWdKTs/+bndLZU+jz867spTIyoy8kH82udV/HSsBEsTi90aQLzuoA jeDay67O5PAB3ify0qRR8zKKwthlm51lXmRVKRqk=
Message-ID: <c4115746ee7fbed29b0b4be6f39f595fdb48bbcd.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: Martin Bjorklund <mbj@tail-f.com>, "netmod@ietf.org" <netmod@ietf.org>
Date: Mon, 21 Oct 2019 17:22:44 +0200
In-Reply-To: <0100016deecf90cd-bc034acb-20e8-41b8-add4-d3f117f0b806-000000@email.amazonses.com>
References: <87tv82rz2z.fsf@nic.cz> <0100016deecf90cd-bc034acb-20e8-41b8-add4-d3f117f0b806-000000@email.amazonses.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/pFpzi6uJFGCVaBvB6tea_RnmAEQ>
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: Mon, 21 Oct 2019 15:22:49 -0000

On Mon, 2019-10-21 at 14:54 +0000, Kent Watsen wrote:
> Hi Lada, 
> 
> > Another option, also suggested in DNSOP WG, was to enable YANG to refer
> > directly to the IANA registry.
> 
> For crypto types, I don’t know if this it possible, as there may be many
> registries involved. 
> 
> Regardless, what is it that is doing the referring?  an identityref?  there
> needs to be a module update, not just a ref, right?  or do you mean that the
> type is “string” and the values are documented to be from said IANA
> registries?

This is of course a good question. I think an implicit enumeration could be a
good fit for many registries.

> 
> 
> > The problem with this is that we have no formalism for writing such
> > templates.
> 
> True. 
> 
> > > 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?
> 
> I don’t understand.  Can you give a sketch of what you have in mind?

Just prepare the module and run it through some defined approval procedure. The
module will become official as soon as IANA publishes it on the "YANG
Parameters" page [1]. After that, IANA will update the module each time the
registry changes - the instructions for updates may be a part of the module
description. But there will be no RFC connected to the module.

Lada

[1] https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml

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