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

Ladislav Lhotka <lhotka@nic.cz> Tue, 08 October 2019 14: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 B9E0A120872 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 07:44:32 -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 nJUTWfXivaM4 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 07:44:28 -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 772AF12086D for <dnsop@ietf.org>; Tue, 8 Oct 2019 07:44:25 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:a744:2697:a0ec:a420]) by mail.nic.cz (Postfix) with ESMTPSA id 297DE140E2B; Tue, 8 Oct 2019 16:44:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1570545863; bh=C7cQxFMpb3HNKb0aRvkSnFD+raXltvFbW6+VjDdOxa0=; h=From:To:Date; b=WGwkVQ+Od40Jnaao+UJvR6lJp3KnPUszEKFGQNvRZtvWquYh4C0w4wFoUrZ+E6q/7 Ftu6t+u0Bw9eG9qrX9m0sT1eyij4sofCKl7L9H1Dize7cKv5MICQNOqCRnVRyVPa3l FhkBmexoHACy2DlV0n6VNRrICeZm1pnam9j7JnnQ=
Message-ID: <93dba67e7c86fe1679f9ca534740c93e7af1eabf.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Bob Harold <rharolde@umich.edu>, Normen Kowalewski <nbkowalewski@gmx.net>
Cc: Paul Wouters <paul@nohats.ca>, Benno Overeinder <benno@nlnetlabs.nl>, DNSOP WG <dnsop@ietf.org>
Date: Tue, 08 Oct 2019 16:44:23 +0200
In-Reply-To: <CA+nkc8BjHrCF7PO_0RKETcLWhNDDA2M66antFE=xusHcdsVHhA@mail.gmail.com>
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> <0A5478B0-BC32-46AA-A915-ABC026D247CA@gmx.net> <CA+nkc8BjHrCF7PO_0RKETcLWhNDDA2M66antFE=xusHcdsVHhA@mail.gmail.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.0
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/dnsop/phIjntX9jediGCCppOWs00l4Y-4>
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 14:44:33 -0000

On Tue, 2019-10-08 at 09:47 -0400, Bob Harold wrote:
> 
> On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski <nbkowalewski@gmx.net> wrote:
> > Dear Paul, Benno,
> > 
> > thanks for your replies.
> > 
> > > On 7. Oct 2019, at 19:31, Paul Wouters <paul@nohats.ca> wrote:
> > > 
> > > 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.
> > > 
> > 
> > We should IMHO be as close to the DNS experts as possible, to me that feels
> > rather like DNSOP than like OPSAWG.  
> > A "YANG doctors” expert review is part of the publication process, so this
> > will happen anyway. It’s also worth nothing that one author is one of these
> > experts himself.
> > 
> > 
> > >> 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)
> > > 
> > > Paul
> > 
> > In order for the IANA registry to be re-used by other YANG modules, a YANG
> > modelled version of the registry is needed. There is precedence for doing
> > this for other registries. e.g. The IANA ifType registry has a corresponding
> > YANG module in RFC8343. A number of other registries also have corresponding
> > YANG modules published or in draft (iana-identity-mib, bfd-parameters, smi-
> > numbers).
> > 
> > Updating and maintaining the contents of the IANA registry as a whole is an
> > orthogonal question to creating a YANG representation of an existing
> > registry and should be handled as a separate task.
> > 
> > Finally, one reason why we would like to see this draft adopted is because
> > we’d like to use it within a real world DNS server implementation.
> > 
> > BR, 
> > 
> > Normen
> 
> We don't want to have to update the RFC every time the registry is updated. 
> Could the RFC just describe exactly how to to convert the registry to YANG? 
>  Then it won't need updates.

Only the initial version of the YANG module will be published as an RFC, and
IANA will then handle all future updates on their own. This is explained in the
I-D itself (last paragraph of the Introduction) and has already been discussed
in this mailing list.

The IANA Considerations sections then gives details about converting new
registry entries into the corresponding YANG types.

Several years of experience with the interface type registry (RFC 7224) shows
that this process works quite smoothly.

Lada

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