Re: [DNSOP] request for adoption

Ladislav Lhotka <lhotka@nic.cz> Wed, 14 November 2018 10:02 UTC

Return-Path: <lhotka@nic.cz>
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 C69AC1293FB for <dnsop@ietfa.amsl.com>; Wed, 14 Nov 2018 02:02:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f4Msb_QWIz-k for <dnsop@ietfa.amsl.com>; Wed, 14 Nov 2018 02:02:24 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4C21D124BE5 for <dnsop@ietf.org>; Wed, 14 Nov 2018 02:02:24 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id EB729182113C; Wed, 14 Nov 2018 11:10:40 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id A64A01820059; Wed, 14 Nov 2018 11:10:38 +0100 (CET)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Joe Abley <jabley@hopcount.ca>
Cc: Paul Wouters <paul@nohats.ca>, DNSOP WG <dnsop@ietf.org>
In-Reply-To: <79789BA2-0A27-42EE-8A65-FB5D32F5319A@hopcount.ca>
References: <87a7mefuz6.fsf@nic.cz> <alpine.LRH.2.21.1811130101010.9026@bofh.nohats.ca> <87pnv9ji3o.fsf@nic.cz> <79789BA2-0A27-42EE-8A65-FB5D32F5319A@hopcount.ca>
Date: Wed, 14 Nov 2018 11:02:19 +0100
Message-ID: <87d0r8q8no.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zam-qLRQsZSF03VkB7bkQBXx5ls>
Subject: Re: [DNSOP] request for adoption
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: Wed, 14 Nov 2018 10:02:29 -0000

Joe Abley <jabley@hopcount.ca> writes:

> On 13 Nov 2018, at 14:07, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
>> Paul Wouters <paul@nohats.ca> writes:
>> 
>>> On Mon, 12 Nov 2018, Ladislav Lhotka wrote:
>>> 
>>>> we would like to ask the working group to adopt the following I-D as a
>>>> WG item:
>>>> 
>>>> https://tools.ietf.org/html/draft-lhotka-dnsop-iana-class-type-yang-00
>>> 
>>> I'll leave that call up to the chairs bit it sounds like a good idea.
>>> 
>>> I have reviewed the document.
>>> 
>>> First, the yand model is correct in the draft. But unfortunately, the
>>> IANA registry itself has flaws.
>> 
>> Hmm, I think the module should only reflect the registry contents, so
>> any problems should be fixed in the registry first.
>
> I don't agree that that ordering is necessary (or desirable). If the
> YANG type definitions plus change processes are sufficient for a
> consistent representation of the registries concerned in YANG, and if
> the YANG continues to track the registry as I understand is intended,
> then fixes to the registry can happen at any time after the goals of
> this document have been achieved.
>
> If accuracy of the registries is a prerequisite for progress on this
> document, we may as well pour concrete over it. Better to treat
> registry quality and the representation of the registry in YANG as
> orthogonal, I think.

The thing is that we want IANA to perform further updates on their own,
and the instructions in the "IANA Considerations" section are intended
to be one way: if the registry changes, update the module so and so. It
would become more complicated if IANA was expected to figure out what
changes had already been applied to the module.

But I guess it also depends on the character of the changes. For
example, adding new enums that are not in the registry should certainly
be avoided.

Lada

>
>
> Joe
>

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