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

[Bob Harold <[e-mail]>]

On Mon, Nov 5, 2018 at 9:01 AM Ladislav Lhotka <[e-mail]> wrote:

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