IETF Logo Mail Archive

Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang

Ladislav Lhotka <lhotka@nic.cz> Tue, 08 October 2019 08:44 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 3BC5B1200F3 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 01:44:14 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 CJiDlzbSdOdd for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 01:44:12 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0353C120098 for <dnsop@ietf.org>; Tue, 8 Oct 2019 01:44:12 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id C15C918204AA; Tue, 8 Oct 2019 10:46:49 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id 4315A1820046; Tue, 8 Oct 2019 10:46:45 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Paul Wouters <paul@nohats.ca>, Benno Overeinder <benno@NLnetLabs.nl>
Cc: "Normen B. Kowalewski" <nbkowalewski@gmx.net>, 'DNSOP WG' <dnsop@ietf.org>
In-Reply-To: <alpine.LRH.2.21.1910071329420.19930@bofh.nohats.ca>
References: <820fe3a1-9d54-15c1-8194-8a607bdf6a31@NLnetLabs.nl> <87sgqy2azd.fsf@nic.cz> <920E9418-4440-46F6-87B7-68CF8B03C408@gmx.net> <C66220A931BC4753B6818DAF898AE2E8@T1650> <426d8bf2-cf28-11f6-4435-08fcaa37e7f5@NLnetLabs.nl> <alpine.LRH.2.21.1910071329420.19930@bofh.nohats.ca>
Date: Tue, 08 Oct 2019 10:44:05 +0200
Message-ID: <87v9sz8w4q.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CT1UxpzyFNfQqZ7JmIg11oGUpAc>
Subject: Re: [DNSOP] Call for Adoptions: draft-lhotka-dnsop-iana-class-type-yang
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: Tue, 08 Oct 2019 08:44:14 -0000

Paul Wouters <paul@nohats.ca> writes:

> On Mon, 7 Oct 2019, Benno Overeinder wrote:
>
>> Questions to WG:
>>
>> 1) iana-class-type-yang document to OPSAWG?
>
> I would assume most people here will the same about the document,
> wherever it is discussed ? So this option seems odd.
>
>> 2) follow-up work on YANG data models for DNS servers in DNSOP?
>
> Speaking for myself, as long as we are not populating RFCs with
> obsoleted DNS data or just create RFC with copies of IANA registries,
> I'm fine with helping on a document. But not if it is a blind copy
> and paste from IANA (whether at DNSOP or OPSAWG)

I still have difficulties to understand this objection. IANA registries (presumably) serve some purpose, and the only way for using them in YANG data models currently is to translate them to YANG.

If something is felt to be broken in IANA registries, then it should be corrected there in the first place. Making a YANG module as an improved version of an IANA registry sounds like a bad idea to me, also because it would be difficult to coordinate future updates.

Or do you have another suggestion?

Lada

>
> Paul

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

v2.23.0 | Report a Bug | By Email