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

Bob Harold <rharolde@umich.edu> Tue, 08 October 2019 13:47 UTC

Return-Path: <rharolde@umich.edu>
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 7F046120170 for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 06:47:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 YQRKegdMoaHc for <dnsop@ietfa.amsl.com>; Tue, 8 Oct 2019 06:47:47 -0700 (PDT)
Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B1B12007C for <dnsop@ietf.org>; Tue, 8 Oct 2019 06:47:46 -0700 (PDT)
Received: by mail-lj1-x22f.google.com with SMTP id q64so17602764ljb.12 for <dnsop@ietf.org>; Tue, 08 Oct 2019 06:47:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2RwVh6VzgsBkIQ82uIkbQPSvQfjAK/o7+e5Ptp2wJgE=; b=M0z9WK1pUT9W9Onu5udqK0RWyuHHRs/+juIHgOmiPQNvEXtplv7bW+vpv+U8tbpiMa D2wI77xPuPJaVqCmIq4LHplYD5IW95rAhM2i0JWBhmtlTzgQZMssRhRwTDTtr9VemTo0 tY5vs/6N/6DaZYzlrx/eZMqYzj+S113/yNF/1hfhJgmSZsJxx7MieWhpjBpKOABGYp2+ 6pMWT3D3ZaCIRohWPR+E7LdnuTgwu9NHtpwzsucNloHght7MjXwXbOjm2Zx1tfEFDM/r CBgKVLxJb6k0hOTAgH+g+sbK1yvA4H9PCciP6BfaC591SB2YX4zfuSnCvCs/U/TxYoB0 liWA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2RwVh6VzgsBkIQ82uIkbQPSvQfjAK/o7+e5Ptp2wJgE=; b=lsoOJafKgzeocLk/1ZTZAtI5M2k4Z2sfoPzRtfMc58ZPndQaoTrL12RPaqWbJPofCb v3WKmqqhxG+UNBkaktPg4owkO4qJUMz5q4ZEnCgOUEeppXBkTllddrKLQnu7USREFL/s 7H/XrB0PdNCQb4ZuPB1rTdnkUcaki7afVAtH31TikLLQVaRNyA92OH9cySq/KknRjxky B8pvTXRFROtknQcx7v9D/mgKulVtxEukROsMcUQzE7FiX6WUGFyBSReTsYmhl+cGBZN9 /YPDZhYpzgEdWWTGFgiFEzNmPn1iaeA/jklwEGzlS7Mvck1+oFhCOW8ysbw/Y1GH7nyX QXdg==
X-Gm-Message-State: APjAAAX6+MfSu+7NIaBAbVGyrTXjzQNNMUKLqcF9eWeTEQD/splUv1DP 2U/ROVtGrQrhUrx9s+zHWWjCwa91pmkkSDBiniOw7w==
X-Google-Smtp-Source: APXvYqzWHTp/PlaIN8KzmyiRKuKdrGjtQRC78z9uMvhEcZZ5IDBcJC9JdA3gDhzj6ueAeDVoLbRSfjDZbiLka4MIcJU=
X-Received: by 2002:a2e:1648:: with SMTP id 8mr20121299ljw.194.1570542464793; Tue, 08 Oct 2019 06:47:44 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <0A5478B0-BC32-46AA-A915-ABC026D247CA@gmx.net>
From: Bob Harold <rharolde@umich.edu>
Date: Tue, 08 Oct 2019 09:47:33 -0400
Message-ID: <CA+nkc8BjHrCF7PO_0RKETcLWhNDDA2M66antFE=xusHcdsVHhA@mail.gmail.com>
To: Normen Kowalewski <nbkowalewski@gmx.net>
Cc: Paul Wouters <paul@nohats.ca>, Benno Overeinder <benno@nlnetlabs.nl>, DNSOP WG <dnsop@ietf.org>, Ladislav Lhotka <lhotka@nic.cz>
Content-Type: multipart/alternative; boundary="000000000000b816af0594666962"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/foOISNQKFzdTOpd3gcC41bt8we8>
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: Tue, 08 Oct 2019 13:47:50 -0000

On Tue, Oct 8, 2019 at 9:23 AM Normen Kowalewski <nbkowalewski@gmx.net>
wrote:

> Dear Paul, Benno,
>
> thanks for your replies.
>
> > On 7. Oct 2019, at 19:31, Paul Wouters <paul@nohats.ca> wrote:
> >
> > On Mon, 7 Oct 2019, Benno Overeinder wrote:
> >
> >> Questions to WG:
> >>
> >> 1) iana-class-type-yang document to OPSAWG?
> >
> > I would assume most people here will the same about the document,
> > wherever it is discussed ? So this option seems odd.
> >
>
> We should IMHO be as close to the DNS experts as possible, to me that
> feels rather like DNSOP than like OPSAWG.
> A "YANG doctors” expert review is part of the publication process, so this
> will happen anyway. It’s also worth nothing that one author is one of these
> experts himself.
>
>
> >> 2) follow-up work on YANG data models for DNS servers in DNSOP?
> >
> > 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)
> >
> > Paul
>
> In order for the IANA registry to be re-used by other YANG modules, a YANG
> modelled version of the registry is needed. There is precedence for doing
> this for other registries. e.g. The IANA ifType registry has a
> corresponding YANG module in RFC8343. A number of other registries also
> have corresponding YANG modules published or in draft (iana-identity-mib,
> bfd-parameters, smi-numbers).
>
> Updating and maintaining the contents of the IANA registry as a whole is
> an orthogonal question to creating a YANG representation of an existing
> registry and should be handled as a separate task.
>
> Finally, one reason why we would like to see this draft adopted is because
> we’d like to use it within a real world DNS server implementation.
>
> BR,
>
> Normen
>

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.

-- 
Bob Harold