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

Ladislav Lhotka <lhotka@nic.cz> Mon, 05 November 2018 14:01 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 27580130F3C for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 06:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 XnJ0f7j-LQ3b for <dnsop@ietfa.amsl.com>; Mon, 5 Nov 2018 06:00:59 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 E8B4E130F4C for <dnsop@ietf.org>; Mon, 5 Nov 2018 06:00:58 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:67c:1232:144:1a4f:a84b:2bfd:c611]) by mail.nic.cz (Postfix) with ESMTPSA id CAF2362DEA; Mon, 5 Nov 2018 15:00:54 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1541426457; bh=+ZVV9ByPxjTt4Hz7K/KKRCwHY1AI13xHTIr7Ly1kB34=; h=From:To:Date; b=nhGdsVp5gqnuFLihCkFfFSs6wyJgXvmpCu6hevz5vfM2JbYPmVVQ5KRaj8bTEb1RX IYIJPleJL76/kTbKMloh73y0sZbAiLqBdmrn9GBo6BqSyvNUYEscEFkcM9FPWR/3cx aWBTOzR8CCajklT7jqtjczvKmYBNNjmUMl3t6me0=
Message-ID: <cf49d660ac8a5a1bc0ec6c0794a443df83efce29.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Normen Kowalewski <nbkowalewski@gmx.net>, Bob Harold <rharolde@umich.edu>
Cc: DNSOP WG <dnsop@ietf.org>, Petr =?UTF-8?Q?=C5=A0pa=C4=8Dek?= <petr.spacek@nic.cz>
Date: Mon, 05 Nov 2018 21:00:51 +0700
In-Reply-To: <6E17826B-F4ED-43D8-8126-E61EC4DA957D@gmx.net>
References: <523146AA-C695-462C-84CC-F9462CBF7E7F@gmx.net> <6E17826B-F4ED-43D8-8126-E61EC4DA957D@gmx.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.30.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gOdNQZyRUrlkAkN6yP2elzBu-Gk>
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 14:01:13 -0000

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