Re: [DNSOP] Fwd: IETF 103: Call for agenda items: draft-lhotka-dnsop-iana-class-type-yang-00

Bob Harold <rharolde@umich.edu> Mon, 05 November 2018 19:11 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 C5647130E10 for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 11:11:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_PASS=-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 7PqS3h_t8fEe for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 11:11:03 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 ABC9C12785F for <dnsop@ietf.org>; Mon, 5 Nov 2018 11:11:02 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id z80-v6so9094419ljb.8 for <dnsop@ietf.org>; Mon, 05 Nov 2018 11:11:02 -0800 (PST)
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=vVm7mgbR2SXasXs3gokH/9j2vzl3Q2eVTh1ddXNGFlw=; b=mUnVPDKrtckWQYtxsNViiLS5TeeHYXZyi6mI7eqo5j1DasUEi6xZl4AkqTEUbXvXtK MzrOdf75rwoNQ/X5ZWs27Tokjo/MdBdjs/F7VsbkjG20zKX0KuJFBleRtVRHe0AzWO0f 5vJXsSajyeFPLPaHeMRIaFEN2dSHhBs01cBOKjh/n1IyhDhUc4m9bqzH53ZPvI/KTybm LrUBcyH6xlWw05aVHdhF3HPQgCLc1oPAKSWABomqw34PRtKEtkH67Sn5uxNhkBH4knix tAAXfAbhoupYcgJ44OrWAfgYrggHcFHF5BWb3ruVG10nqNFRx64gi0JUMwtk922XFDe9 GQoA==
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=vVm7mgbR2SXasXs3gokH/9j2vzl3Q2eVTh1ddXNGFlw=; b=LgJr7uBbswcLoywwhn4hrsPrOpcYsbDvJz5EWu+NUqpC9TtW/tbs/AZpJb13YnjP3a jQCv33uP9+WpK7arR1juaL+6cKo7PDuv5u6wUUqg7ACy2N3Z1LsMNfACyCltTSD+SZNC AZuEtU8/yqcB2fn9iPWubFO24XHe1zOytgzre651m1+ygx4vfKAIMKwTMQiBczrVHKbI tR6xNxGxIZx1ExvyEo38cVc2KqGMwLbj9Vyg5znyh/8+3YvMYRLzmFCIvk/HwwJ6ibtL eZatIJ1UT/mgV3YIeg5WjvuC9z/qNb/FQDzBYV6AW79A4/SdZJZeVE4S4fHWb1EUhXwE q1EQ==
X-Gm-Message-State: AGRZ1gIoClzJAk9I6Lo6tf5+BQDv89ienE7RNch75bmSqqn1o06pNEo1 FK8DuaMIBvYWgGk5AaV+5LdkafYf29BZ+vjKaI6lQw==
X-Google-Smtp-Source: AJdET5d7XVR3hIetmCQl+VYQybjSLAd1jUYHAox60s8FTBjDevrgx103zBkYtO47y8QUQPjuMKvWAFlV+aXIStz8tF4=
X-Received: by 2002:a2e:5109:: with SMTP id f9-v6mr15313893ljb.52.1541445060556; Mon, 05 Nov 2018 11:11:00 -0800 (PST)
MIME-Version: 1.0
References: <523146AA-C695-462C-84CC-F9462CBF7E7F@gmx.net> <6E17826B-F4ED-43D8-8126-E61EC4DA957D@gmx.net> <cf49d660ac8a5a1bc0ec6c0794a443df83efce29.camel@nic.cz>
In-Reply-To: <cf49d660ac8a5a1bc0ec6c0794a443df83efce29.camel@nic.cz>
From: Bob Harold <rharolde@umich.edu>
Date: Mon, 5 Nov 2018 14:10:48 -0500
Message-ID: <CA+nkc8CzLHEBeX7h9RDbHYbvrx8vZS-eaFS9MF6XcTe7VNJG6A@mail.gmail.com>
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: nbkowalewski@gmx.net, IETF DNSOP WG <dnsop@ietf.org>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Content-Type: multipart/alternative; boundary="000000000000469f410579efa56e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/YhvgjaX4yLF3XvnKR-tYW4p0TtA>
Subject: Re: [DNSOP] Fwd: IETF 103: Call for agenda items: draft-lhotka-dnsop-iana-class-type-yang-00
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: Mon, 05 Nov 2018 19:11:07 -0000

On Mon, Nov 5, 2018 at 9:01 AM Ladislav Lhotka <lhotka@nic.cz> wrote:

> On Mon, 2018-11-05 at 14:44 +0100, Normen Kowalewski wrote:
> > Hi Bob,
> >
> >
> > > On 12. Oct 2018, at 15:48, Bob Harold <rharolde@umich.edu>  wrote:
> >
> > sorry for the very late reply; please allow two cents inline
> >
> > > In entries like:
> > >
> > > enum NSAP-PTR {
> > > value "23";
> > > description
> > > "Domain name pointer, NSAP style.";
> > > reference
> > > "- RFC 1348: DNS NSAP RRs
> > >
> > > - RFC 1637: DNS NSAP Resource Records
> > >
> > > - RFC 1706: DNS NSAP Resource Records";
> > > }
> > > It seems odd to me to create the reference field as a string  that
> > > contains what looks like YAML, except that it has extra  blank
> > > lines.
> >
> >
> > > Does YANG not have a standard way to represent a  list, and should
> > > the reference field always be a list, for consistency?
> >
> > Listing and enumerating stuff is AFAIK quite at the core of YANG, so it
> could
> > have been define as something like “reference-list”, if folks focus had
> been
> > programatic use.
> > Yet the respective chapter YANG RFC 6020 section-7.19.4, updated in YANG
> 1.1
> > RFC 7950. section-7.21.4, says:
> >
> >   The "reference" statement takes as an argument a string that is a
> >   human-readable cross-reference to an external document
> >
> > If we look at the content in the IANA “reference” field today, in the
> table at
> >
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4
> > it seems that it is quite varied:
> >
> > * one of more comma seperated RFC numbers
> > * name of an internet draft in edgy brackets,
> > * a footnote number in edgy brackets
> > * a name reference of an author
> > * a name reference of some underlying additional document
> > * a URL of some underlying additional document
> > * the IANA reservation statement, aka [IANA-Reserved]
> > as well as
> > * combinations of some of the before listed, assumedly with some implicit
> > hierarchy of records where such combinations are used.
> >
> > For this YANG draft, I don’t see a need to normalise types and structure
> > within this content beyond what is at IANA today. TO me its OK to just
> > reference the IANA content "as is” and formally maintain the YANG
> declaration
> > in "reference” as "human targeted”.
> >
> >
> > > Also, the "template" and "registration date" fields appear to  be
> missing.
> >
> > Do you see a need to replicate all the data fields of this IANA registry
> in
> > the YANG model, and if yes, what benefit at the YANG end could this add?
>
> This is my question, too. The "description" and "reference" strings make
> sense
> in the YANG module as human-readable documentation, and some user
> interfaces
> also use them as context-sensitive help messages. In contrast, I don't see
> any
> use for "template" and "registration date" - this is metadata intended for
> IANA
> internal use only.
>
> The YANG module isn't going to replace the IANA registry, so it is not
> necessary
> to replicate everything.
>
> Lada
>
> >
> >
> > Best Regards,
> >
> > Normen Kowalewski
> >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
Thanks for considering my questions and responding.  It sounds like there
are reasons for the way it is, so apparently no changes are required.

-- 
Bob Harold