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

Ladislav Lhotka <lhotka@nic.cz> Thu, 10 October 2019 07:31 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 6219E120046; Thu, 10 Oct 2019 00:31:19 -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 8xZuo5xeXV4y; Thu, 10 Oct 2019 00:31:17 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3B2120033; Thu, 10 Oct 2019 00:31:16 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id CB0D218204A9; Thu, 10 Oct 2019 09:34:10 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id AB0A11820046; Thu, 10 Oct 2019 09:34:08 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Paul Wouters <paul@nohats.ca>, iesg@ietf.org
Cc: DNSOP WG <dnsop@ietf.org>
In-Reply-To: <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> <alpine.LRH.2.21.1910091628450.11081@bofh.nohats.ca>
Date: Thu, 10 Oct 2019 09:31:11 +0200
Message-ID: <874l0hrr9c.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qN3fIg52YPd62JP3n1qwhrtIDRU>
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: Thu, 10 Oct 2019 07:31:20 -0000

Paul Wouters <paul@nohats.ca> writes:

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

They should not actually be reading the RFC but get the latest revision of the module from this page:

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

Along with every update to the ifTypes registry, IANA also updates the iana-if-type module, the current revision date is 2019-07-16.

I do admit that this may not be clear to everybody. What we are really missing is a well-known and authoritative repository of YANG modules, at least those produced by IETF and managed by IANA.

Would it help to reclassify the RFC as historic as soon as IANA takes over the responsibility for such a module?

>
>> 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 really don't understand. What DNS Yang RFC are you referring to? I am not aware of any.

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

We are open to all reasonable suggestions.

Thanks, Lada

>
> Paul

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