IETF Logo Mail Archive

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

Paul Wouters <paul@nohats.ca> Thu, 10 October 2019 13:16 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 D2B05120820 for <dnsop@ietfa.amsl.com>; Thu, 10 Oct 2019 06:16:45 -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 eoC3kICptzfE for <dnsop@ietfa.amsl.com>; Thu, 10 Oct 2019 06:16:44 -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 1AFB212010E for <dnsop@ietf.org>; Thu, 10 Oct 2019 06:16:44 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46ps6y2rdBzCw7; Thu, 10 Oct 2019 15:16:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570713402; bh=lV35I5GU5ciVMrif52h9g4IEzx9ejRpEB1tgSw3QgIc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cxNzdnx7KbuDUzbWWD+N4G8o1oyBnk0FPE8yQFUsOys3oK5czHSmgCChlOa/PncAr GTFvrZjKRJkAbHR5SrxDi6W8weylgZWquElol6bjItLPtqFwTC/9D6ZOabsqLQYNPp UD1BH02Klzt+VaOLL/x5U484XCXQP5o/J/peSx3g=
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 x-Mr9GZG1UMj; Thu, 10 Oct 2019 15:16:41 +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; Thu, 10 Oct 2019 15:16:41 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id EE33A606AA24; Thu, 10 Oct 2019 09:16:39 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ED41323FDDC; Thu, 10 Oct 2019 09:16:39 -0400 (EDT)
Date: Thu, 10 Oct 2019 09:16:39 -0400
From: Paul Wouters <paul@nohats.ca>
To: Ladislav Lhotka <lhotka@nic.cz>
cc: 'DNSOP WG' <dnsop@ietf.org>
In-Reply-To: <87woddq6cx.fsf@nic.cz>
Message-ID: <alpine.LRH.2.21.1910100912420.10011@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> <87v9sz8w4q.fsf@nic.cz> <alpine.LRH.2.21.1910091709540.11081@bofh.nohats.ca> <87woddq6cx.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/snTpMpSyIT_XSTp8jPRWLQuKehI>
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 13:16:51 -0000

On Thu, 10 Oct 2019, Ladislav Lhotka wrote:

>> Wouldn't this define what you need, without hardcoding all the valid
>> values from the snapshot of the IANA registry?
>>
>> This would instruct the implementor to go to the IANA registry, notice
>> there what is obsoleted/deprecated, and they will know they will have
>> to check IANA when doing a release update.
>>
>> Am I misunderstanding something?
>
> This may be acceptable for humans but tools cannot do much with it. One benefit of an explicit enumeration is that tools can generate sensible code from it, e.g. to provide the user with the list of available choices.

You can use tools to parse the IANA registry, but yes. The work _should
not_ be to blindly pick up an obsoleted/incomplete set of data that is
deemed valid a few years ago in time. People will read your enumeration
and start coding support for all those things because those are
"implemented" by you and then we see people implemented things like
the MD or MF or A6 RRTYPEs just because your yang model listed these
obsoleted record types.

So I would argue this is a feature, not a bug.

Paul

v2.23.0 | Report a Bug | By Email