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

Paul Wouters <paul@nohats.ca> Wed, 09 October 2019 20:44 UTC

Return-Path: <paul@nohats.ca>
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 C2EF5120B24; Wed, 9 Oct 2019 13:44:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nohats.ca
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 LaKNNEArCbNJ; Wed, 9 Oct 2019 13:44:06 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 4CA50120B22; Wed, 9 Oct 2019 13:44:06 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pR5c1PPCzFbJ; Wed, 9 Oct 2019 22:44:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570653844; bh=5RO0wv4OGTef9W8zwvwISz6Wru3zkScHT28N9Guz/6U=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=t5BlCstQDUPMP8Ip4eQlTD1/3e5jb4Hd38Yq9cK1oG+1HmiUQ4FrqeF1EffLxQX2p YIKSCWi7BvJivfZ6PcuWbGXXIBSnmGg9Lm4UjFL691ccW1xwe3VM++FCQQyin1vsyU Wthr5vEQ7MoMqecmpur7nwHPgfvDP4P0+ntMy/KM=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HDMnR2Bb0rRM; Wed, 9 Oct 2019 22:44:02 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 9 Oct 2019 22:44:02 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 2AE72607F2CB; Wed, 9 Oct 2019 16:44:01 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 29A3823FE47; Wed, 9 Oct 2019 16:44:01 -0400 (EDT)
Date: Wed, 09 Oct 2019 16:44:01 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ladislav Lhotka <lhotka@nic.cz>, iesg@ietf.org
cc: DNSOP WG <dnsop@ietf.org>
In-Reply-To: <93dba67e7c86fe1679f9ca534740c93e7af1eabf.camel@nic.cz>
Message-ID: <alpine.LRH.2.21.1910091628450.11081@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> <0A5478B0-BC32-46AA-A915-ABC026D247CA@gmx.net> <CA+nkc8BjHrCF7PO_0RKETcLWhNDDA2M66antFE=xusHcdsVHhA@mail.gmail.com> <93dba67e7c86fe1679f9ca534740c93e7af1eabf.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/xwIh-3HKUG9r2Kx_0QnU6kzfD48>
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: Wed, 09 Oct 2019 20:44:08 -0000

On Tue, 8 Oct 2019, Ladislav Lhotka wrote:

(added IESG to CC:)

>> 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.

What is "future updates on its own"? How are implementors reading the
this (now old) RFC to know what they are missing or what obsoleted and
deprecated options listed in the RFC should not be implemented?

> 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.

I think this claim is both an unquantifed appeal to authority and unfair. The
technical debt of doing this happens 10+ years from now, when people are
implementing obsolete record types because a modern DNS Yang RFC references
these record types, and might be missing new record types because the
modern DNS Yang RFC did not yet have this new record type listed.

I have brought this issue of putting IANA snapshots in RFC's up on a
number of occasions and WGs now, including at IETF Plenaries. I was told
the IESG is working on it. Can the IESG tell me what is being done here,
and what the IESG believes should happen to drafts suggesting to do this
meanwhile?

Paul