Minutes from 2025-12-15 pyang-workers meeting

[mcr]

WHEN: Dec. 15, 1400UTC
(6am Pacific. 9am Eastern. 15:00
WHERE: https://meet.credil.org/pyang-workers
Notes at: https://pad.riot-os.org/jo-WmKcwSZerY2IQDnQCeg [login with github]

WHAT/WHY:

• Carsten Bormann
• Laurent Toutain
• Esko Dijk
• Andy Bierman
• Michael Richardson
• Martin mbj
• Henk Birkholz (listening)
• Joe Clarke

Agenda.

1. Who is who/introductions.

*mbj, using YANG, but not PYANG.
*andy bierman, implementations of much of this. Want sid files generated, not hand-crafted.
*carsten bormann, know nothing of YANG, came to this because netmod approaches to IoT. Wound up because of YANGCBOR. Like to have efficient way, so SID. Laurent might want a more manual approach. PYANG sid.py is taking us 95% of the way, but the other 5% is a problem. Like schema-nodes for choices.

• Laurent, learnt enough about YANG to do SCHC.... then working with CORECONF to implement it with SCHC. Needs CORECONF to create new (compression) rules. Have developed SID-extensions to map between CORECONF and JSON(RESTCONF)... without knowing about the YANG data model.
• Esko Dijk, worked in ANIMA WG, constrained BRSKI, implementing the draft and implementing the voucher. RFC8366bis model contributions.
• Henk Birkholz, IETF participant, YANG is relevant to him for MUD files (RFC8520), and then we have some Remote Attestation protocols (CHARRA), and want to do this via YANG/RESTCONF. Would like to simplify subscriptions. Not YANG expert, but a plumber, "magical" RPCs. Was working on a CoAP SUBSCRIPTION to a CoAP data model, but was looking for a subscription sub-tree. coap-subscribe to a sid.

2. Picking 3 times for 2026.

CB: Yes, we should meet, but would be a good thing to talk. Who wants to do what? Be responsible for what? And has time. Ambivalent about timing. IETF vs not-IETF week. Maybe "three weeks" after an IETF.
LT: might too noisy at IETF.

3. Planning a release cycle.

AB: uses pyang a lot, it is the most correct for the things that it checks. Do not know anything else that needs to be fixed, other than sid generation. Not sure we need so regular releases. Have to use both yanglint and pyang.
mbj: more than happy for someone to take responsability for sid plugin. If someone did that, then we could pass on commit responsability, and we can do more regular releases. Someone else wants to join, that would be great.
AB: might be only one using 2.7.1, others are using a different fork?
MCR: yes, some work on-top of 2.7.1 now.
AB: sid kicks ass on json, and very tight... (glowing reviews), with libcbor.
MCR talks about choice... and case has to be in the schema identifier.

LT: is YANG totally stable?
CB: there is versioning work that will have an impact on how we manage SIDs in the future.
JC: this versioning is what I have been working on, in pyang... is the language stable? "YANGNEXT", but, given how long versioning took,... is PYANG stable? I use it regularly. Somewhat easy to plug things in. Looked at SID stuff recently. Easy to work with at a code level.
MCR describes moving to choice in YANG and then back out. ED describes that 2.7.1 worked in the end.
CB: the other thing that is changing is the viewpoint on backwards compatibility.. that will impact how we use/allocate SIDs.

4. Do we have any security/emergency release concerns?

Are we expecting to ever be in a situation where we have some "0-day" exploit against pyang/..
CB: one that shields us against attacks is that someone has to authoritatively generate SID files and publish them. If PYANG does not work, then that hurts all the progress of modules that process are being used via SIDs.
CB: sid maintainer... plugin maintenance, but then we might also need to do a new release. But, we might want a different division of work where sid implementation is thrown over the wall occasionally.

MCR: Let the PYANG sid plugin live in a separate space?
Martin: Let's work from the current situation where sid.py is released with PYANG
ED: Isn't the release in form of a Python package: https://pypi.org/project/pyang/ ?
CB: have to install pyang from working copy. That releases the pressure to have a pyang release for really hard core development.
MCR uses ". ./env.sh"...

CB recently CB,MCR and LT have been sharing responsability this core-wg/pyang called "core",

This branch is 33 commits ahead of mbj4668/pyang:master 

CB is there any resource that would help us understand the internals better?
mbj: except for the source?
JC: Looks like someone has already DeepWiki'd pyang: https://deepwiki.com/mbj4668/pyang an AI tool that deep-dives.

5. Do we need/want a mailing list? (vs.. Discourse?)

Is there a yang-of-things?
AB: sphinx docs? best tool for documentation.
AB: would like the IETF to have a YANG tooling mailing list. netmod/netconf do not seem to want to deal with tools.
CB: (ACTION) so let's ask med to create a ML for this. Detailed discussion about how it should work. Nominate AB and CB as maintainers of list.

Discussion how to move tooling up to support all the extensions, vs YANGNEXT.

CB -> there is already a yang-sid-logistics@ietf.org ML, which is about interacting with IANA.
Carsten Bormann points to https://mailarchive.ietf.org/arch/browse/yang-sid-logistics/
(this is not the maint list)

JC: Yang-modules github repo which has a few vendors + a few SDOs. https://github.com/YangModels/yang

6. How do we do pull request reviews?

mbj: will provide write access to our elected sid maintainer.

7. Triage of any outstanding non-SID related issues.
   N/A.

8. Finish SID issues, RFC9254 vs choice ?

9. AOB

Forward Agenda for 2026:

1. Any troublesome PRs.
   2. Generating/pre-populating SIDs for existing RFC YANG modules.
2. Should there be a web site (, or join some other one.
3. Funding for maintenance.
4. Upcoming/Latent YANG features that need implementing, funding for that.
5. Has github enshittified too much? gitlab?codeberg?other?