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

Ladislav Lhotka <lhotka@nic.cz> Thu, 10 October 2019 09:48 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 BE75E120858 for <dnsop@ietfa.amsl.com>; Thu, 10 Oct 2019 02:48:04 -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 rysCNNS8pyPE for <dnsop@ietfa.amsl.com>; Thu, 10 Oct 2019 02:48:02 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1951E120BD7 for <dnsop@ietf.org>; Thu, 10 Oct 2019 02:48:01 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 58C7618204AA; Thu, 10 Oct 2019 11:50:56 +0200 (CEST)
Received: from localhost (nat-1.nic.cz [217.31.205.1]) by trail.lhotka.name (Postfix) with ESMTPSA id 170571820046; Thu, 10 Oct 2019 11:50:54 +0200 (CEST)
From: Ladislav Lhotka <lhotka@nic.cz>
To: Paul Wouters <paul@nohats.ca>
Cc: 'DNSOP WG' <dnsop@ietf.org>
In-Reply-To: <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> <alpine.LRH.2.21.1910091709540.11081@bofh.nohats.ca>
Date: Thu, 10 Oct 2019 11:47:58 +0200
Message-ID: <87woddq6cx.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FxCAA64QwcVY4i645ygWZGR6d7c>
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 09:48:05 -0000

Paul Wouters <paul@nohats.ca> writes:

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

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.  

Lada

>
> Paul

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