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

[Ladislav Lhotka <[e-mail]>]

On Mon, 2018-11-05 at 14:44 +0100, Normen Kowalewski wrote:
> Hi Bob,
> 
> 
> > On 12. Oct 2018, at 15:48, Bob Harold <[e-mail]>  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