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

Paul Wouters <paul@nohats.ca> Wed, 09 October 2019 21:15 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 1D5E9120834 for <dnsop@ietfa.amsl.com>; Wed, 9 Oct 2019 14:15:01 -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 kUjvUM-xb4aq for <dnsop@ietfa.amsl.com>; Wed, 9 Oct 2019 14:14:59 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 15ED7120043 for <dnsop@ietf.org>; Wed, 9 Oct 2019 14:14:59 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46pRnD5r8LzFbC; Wed, 9 Oct 2019 23:14:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570655696; bh=WIf11euOjdIgi57V3yv82G4pibVxM1cno1DaMx8JTXE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GOWVoaP/tJlfW++aqgYK9Z/yWUN7HBz91D8ruhL7xRlZvqrD/fJTggcciNItSCGls v+btrPKzw8FyXYu4TYHwRYb8n860WgSUI3cAOHSY/4NCwyYmkY2KutfprSZZIpnl3S SVqQH8ojJwZD7vx+Ch8Nh3llA0bsYS57XR+STIUg=
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 1QgsuJipLzEr; Wed, 9 Oct 2019 23:14:54 +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 23:14:54 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B9219607F2CB; Wed, 9 Oct 2019 17:14:53 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B547B23FE47; Wed, 9 Oct 2019 17:14:53 -0400 (EDT)
Date: Wed, 9 Oct 2019 17:14:53 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Ladislav Lhotka <lhotka@nic.cz>
cc: 'DNSOP WG' <dnsop@ietf.org>
In-Reply-To: <87v9sz8w4q.fsf@nic.cz>
Message-ID: <alpine.LRH.2.21.1910091709540.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> <87v9sz8w4q.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/TeuY0HV9mIIz54xFMwouH81wrYE>
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 21:15:01 -0000

On Tue, 8 Oct 2019, Ladislav Lhotka wrote:

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

What I meant was something like this:

https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07https://tools.ietf.org/html/draft-ietf-i2nsf-sdn-ipsec-flow-protection-07



            typedef encryption-algorithm-type {
                type uint16;
                description
                    "The encryption algorithm is specified with a 16-bit
                    number extracted from IANA Registry. The acceptable
                    values MUST follow the requirement levels for
                    encryption algorithms for ESP and IKEv2.";
                reference
                     "IANA Registry- Transform Type 1 - Encryption
                     Algorithm Transform IDs. RFC 8221 - Cryptographic
                     Algorithm Implementation Requirements and Usage
                     Guidance for Encapsulating Security Payload (ESP)
                     and Authentication Header (AH) and RFC 8247 -
                     Algorithm Implementation Requirements and Usage
                     Guidance for the Internet Key Exchange Protocol
                     Version 2 (IKEv2).";
            }


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?

Paul