[yang-doctors] [IANA #1208742] YANG modules and XML-based registries

[Amanda Baber via RT <[e-mail]>]

Hi all,

On Fri Sep 10 23:53:40 2021, [e-mail] wrote:
> Sending the follow-up conversation to a ticket for tracking.
> 
> On 9/10/21, 4:11 AM, "Ladislav Lhotka" <[e-mail]>
> wrote:
> 
> On 10. 09. 21 11:41, Jürgen Schönwälder wrote:
> > Lada,
> >
> > I think it is highly desirable to have an automated workflow that
> > avoids manual work as much as possible. Creating such a workflow,
> > however, may not be easy and might require a couple of hackathons in
> > order to weed out the corner cases that will show up (and I expect
> > there to be quite a few of them if you look at the larger universe of
> > IANA registries).
> 
> Technically, the biggest problem is that I haven't been able to find
> any
> schema or other definition of the XML format used, so one doesn't
> really
> know what to expect in the next registry. Somebody also told me that
> IANA is considering an upgrade of this XML format. If it is so, then
> it
> might be worthwhile to prepare an interface to YANG along with it.

Our development team is currently working on a move to a database- rather than XML-based registry system, but we don't have an ETA. 

Once the new system is in place, we will continue to make the current XML files available. 

The XML and RNG files use this naming scheme:

https://www.iana.org/assignments/dns-parameters/dns-parameters.xml
https://www.iana.org/assignments/dns-parameters/dns-parameters.rng

If you have any questions, just let us know.

Best regards,

Amanda Baber
IANA Operations Manager

> > So it boils down to who brings up the energy for working on this. If
> > you have time for it, you have my ideological support but I may not
> > be
> > able to contribute much to it (and I am not good at xslt transforms
> > in
> > particular). Back in a day, I would likely have contributed to such
> > an
> > activity during IETF meetings, but in the modern times with meetings
> > that tend to do not get me anymore out of my everyday life,
> > activities
> > like this tend to find no time anymore.
> 
> Everything needn't be done at once, and addressing one or a few
> registries at a time doesn't mean a terrible aount of work. In any
> case,
> after the experience with RFC 9108 I am not much motivated to continue
> in the same way with other registries that are necessary for DNS (or
> whatever).
> 
> It could be a topic for an IETF hackathon, but I was thinking simply
> about starting a new Github repo. I also know that XSLT language is a
> bit obscure but, on the other hand, it is a perfect fit for this use
> case, and xsltproc is a ubiquitous tool across all platforms.
> 
> Thanks, Lada
> 
> >
> > /js
> >
> > On Fri, Sep 10, 2021 at 10:03:31AM +0200, Ladislav Lhotka wrote:
> >> Hi,
> >>
> >> this is unrelated to Michelle's question but...
> >>
> >> It seems it is somewhat complicated for IANA to maintain YANG
> >> modules mirroring IANA registries. I am thinking about using the
> >> approach of RFC 9108 on a larger scale - specifically, developing
> >> XSLT stylesheets that would take the online XML format of an IANA
> >> registry and transform it to a YANG module. This way, IANA would
> >> only maintain the registries, but YANG modellers can always obtain a
> >> YANG module corresponding to the up-to-date revision of the
> >> registry.
> >>
> >> Moreover, there would be some hope that important IANA registries
> >> can be made available to YANG before the end of the universe - it
> >> took three years to finish RFC 9108 in DNSOP WG.
> >>
> >> What do you think?
> >>
> >> Lada
> >>
> >> Michelle Cotton <[e-mail]> writes:
> >>
> >>> Hello Yang Doctors!
> >>>
> >>>
> >>>
> >>> Quick question about implementation of RFC 9132.
> >>>
> >>>
> >>>
> >>> For the IANA maintained Yang, iana-dots-signal-channel, the RFC-
> >>> Editor sent us a replacement yang file.
> >>>
> >>>
> >>>
> >>> In this case, do we just delete the older yang file and completely
> >>> replace it with the new one?
> >>>
> >>>
> >>>
> >>> At https://www.iana.org/assignments/yang-parameters we point the
> >>> iana-dots-signal-channel entry to the newer yang file.
> >>>
> >>>
> >>>
> >>> Then we’ll update https://www.iana.org/assignments/iana-dots-
> >>> signal-channel/iana-dots-signal-channel.xhtml so that it points to
> >>> the newer yang file and update the RFC.
> >>>
> >>>
> >>>
> >>> Do we have that correct?
> >>>
> >>>
> >>>
> >>> For the ietf-dots-signal-channel yang, an additional entry was
> >>> added since it is not IANA maintained (per previous instructions
> >>> from Benoit).
> >>>
> >>>
> >>>
> >>> Thanks for any confirmation you can provide!
> >>>
> >>>
> >>>
> >>> --Michelle
> >>>
> >>>
> >>>
> >>> Michelle Cotton
> >>>
> >>> Protocol Parameters Engagement Sr. Manger
> >>>
> >>> IANA Services
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> yang-doctors mailing list
> >>> [e-mail]
> >>>  https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang-
> >>> doctors__;!!PtGJab4!suPziUKOfyykv0Qhj5r9en1nZ4hyHyBETXrSXpt2j4KRdQAQwZVIDsCiraSEwF1E0lbPE0COcxY$
> >>
> >> --
> >> Ladislav Lhotka
> >> Head, CZ.NIC Labs
> >> PGP Key ID: 0xB8F92B08A9F76C67
> >>
> >> _______________________________________________
> >> yang-doctors mailing list
> >> [e-mail]
> >>  https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/yang-
> >> doctors__;!!PtGJab4!suPziUKOfyykv0Qhj5r9en1nZ4hyHyBETXrSXpt2j4KRdQAQwZVIDsCiraSEwF1E0lbPE0COcxY$
> >
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67