Re: [netmod] IANA registries

Ladislav Lhotka <lhotka@nic.cz> Thu, 10 October 2019 12:34 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 7D4C5120C62 for <netmod@ietfa.amsl.com>; Thu, 10 Oct 2019 05:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 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, URIBL_BLOCKED=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 LwfwOexJzKmb for <netmod@ietfa.amsl.com>; Thu, 10 Oct 2019 05:34:13 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 DA57D120AEC for <netmod@ietf.org>; Thu, 10 Oct 2019 05:34:12 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a744:2697:a0ec:a420]) by mail.nic.cz (Postfix) with ESMTPSA id B0F90140E9C; Thu, 10 Oct 2019 14:34:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1570710850; bh=FC7NpdF0CIT4VYUOJUkQjYLvFXH/e+uVJ8wSv7nrtUI=; h=From:To:Date; b=aYFs19gLPmZNJHc8ueTJ4U8rlaKgUqSU5rNFOMQwRQotV66z4wI82/JnQqwov3+Ax LG5+RfEBzrnqHtgkXKxBe/faXdkiKwEtJfZK/gaKeZzqOJlA5J7Je5iozKMRP2aP1X oMC1LUVbizEfd2JMzutmTtJIc9qVhYB6UaZ9tXeQ=
Message-ID: <936c711b27bf9186d19210332eb4df9149e9c7c7.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Date: Thu, 10 Oct 2019 14:34:10 +0200
In-Reply-To: <20191010.140757.575758698470515713.mbj@tail-f.com>
References: <64c9cd72e94621afcff099e1cda69fdacd27b04a.camel@nic.cz> <20191010.140757.575758698470515713.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.1
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
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/0rwftHJPutNNLvQGTCd7kig8rPA>
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, 10 Oct 2019 12:34:16 -0000

On Thu, 2019-10-10 at 14:07 +0200, Martin Bjorklund wrote:
> Ladislav Lhotka <lhotka@nic.cz>; wrote:
> > Hi,
> > 
> > some of you have probably seen the discussions around
> > 
> > https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-02
> > 
> > We proposed to adopt it as a work item in the DNSOP WG, but despite
> > some support this is probably not going to happen. The substantial
> > objections are:
> > 
> > 1. It is not good to publish a YANG snapshot of an IANA registry as an RFC
> > because future implementors will use the module from that RFC and implement
> > registry entries that may have been deprecated in the mean time. 
> > 
> > 2. The meaning of "deprecated" and "obsolete" defined by IANA (RFC
> > 8126) differs from the definition in RFC 7950.
> > 
> > I already raised #2 in this mailing list, and I think it should be
> > addressed in the next version of YANG.
> > 
> > Regarding #1, I tried to explain that the RFC is only intended to contain an
> > initial revision of the corresponding YANG module, but it didn't help. One
> > suggestion was to avoid representing the registries as enumerations or sets
> of
> > identities, and use only integers.
> 
> 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.

My idea was to tag the RFC as historic as soon as IANA takes over the module
maintenance.

I think part of the problem is that the new revisions are available from a
rather obscure place - the YANG Parameters registry page:

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

Lada

> 
> 
> 
> /martin
> 
> 
> > I wonder if we can come up with a reasonable solution. Without
> > having the important registries as YANG modules, it is difficult to
> > work on other modules - for DNS, in this case, but it could apply to
> > other areas, too.
> > 
> > Thanks, Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67