Just after IETF 101 in London, let’s analyze the current state of affairs in the YANG Data Models world. Note also the previous “YANG Data Models in the Industry: Current State of Affairs” from the last IETF meeting in Singapore.

During the IETF week, we published the new Network Management Datastore Architecture (NMDA) RFC8342 and, along with that, some NMDA-compliant YANG modules. Three RFCs have been revised to produce NMDA-compliant YANG modules: interface, IP management, and routing. I’m also happy to report that an entire industry works toward adopting NMDA. As an example, Scott Mansfield mentioned to me, “I would like to note that IEEE (802.1, 802.3, and 802.11), ITU-T, and MEF have embraced NMDA.”

In total, since last week, we saw the publication of the following RFCs:

• RFC 8340, YANG Tree Diagrams
• RFC 8341, Network Configuration Access Control Model
• RFC 8342, Network Management Datastore Architecture (NMDA)
• RFC 8343, A YANG Data Model for Interface Management
• RFC 8344, A YANG Data Model for IP Management
• RFC 8345, A YANG Data Model for Network Topologies
• RFC 8346, A YANG Data Model for Layer 3 Topologies
• RFC 8347, A YANG Data Model for the Virtual Router Redundancy Protocol (VRRP)
• RFC 8348, A YANG Data Model for Hardware Management
• RFC 8349, A YANG Data Model for Routing Management (NMDA Version)

With RFC 8342 bottleneck removed, many YANG modules are now published. We finally seeing the exponential growth in the number of IETF YANG modules published, as can be seen in the recently updated figure below (most up-to-date figure here).

Some more YANG modules are in the RFC-editor queue, part of this edition cluster:

• draft-ietf-lime-yang-connectionless-oam-methods-13.txt,
• draft-ietf-lime-yang-connection-oriented-oam-model-07.txt, 
• draft-ietf-lime-yang-connectionless-oam-18.txt, 
• draft-ietf-rtgwg-yang-rip-10.txt, 
• draft-ietf-rtgwg-ni-model-12.txt,
• draft-ietf-rtgwg-lne-model-10.txt, 
• draft-ietf-netmod-syslog-model-26.txt.  

So plenty of YANG modules to be published soon to further improve the hockey stick figure. And some more in the pipe, for sure.

Recently, the NETMOD WG finalized the “Guidelines for Authors and Reviewers of YANG Data Model Documents”,  draft-ietf-netmod-rfc6087bis-20.txt. It’s a RFC bis document that incorporates an extra seven years of experience to RFC6087: A key document that many should read.

During this IETF in London, we found a way to escape from the schema mount impasse, an issue that lasted since the Working Group last call in November. As a quick reminder, the schema mount defines a mechanism to combine YANG modules into the schema defined in other YANG modules. Sometimes, magic happens when people speak to each others face to face. It did happen last week, when the version 9 of draft-ietf-netmod-schema-mount was posted: this version makes everybody a little bit happier! After the Working Group last call, it should move fast to RFC publication, unblocking two key YANG documents already in the RFC editor queue: the logical network element (LNE), an independently managed virtual device made up of resources allocated to it from the host or parent network device, and the network instance module, which can be used to manage the virtual resource partitioning that may be present on a network device such as VRF and VSI.

The NETCONF Working Group rechartered, with a more open ended charter.

The NETCONF Working Group, previously named after the NETCONF protocol,
now renamed as the NETwork CONFiguration Working Group, is responsible for the
development and maintenance of protocols such as NETCONF and RESTCONF for YANG
data model-driven management (for the purposes of, for example, configuration,
monitoring, telemetry, and zero-touch), their transports and encodings,
defining data models necessary to support the protocols, and defining
mechanisms supporting the operational deployment of systems using the protocols.

In NETCONF, the YANG push and event stream subscriptions have three drafts now in Working Group last call. YANG Push was referenced often by other drafts in the I2NSF & SACM Working Groups.

In the Hackathon, Joe Clarke and I dedicated our time to the maintenance of the YANG catalog, while Mahesh Jethanandani added the MEF YANG modules, and Vladimir Vassilev focused on the validating YANG examples. The YANG catalog now contains information about 3455 unique YANG modules from the entire industry: IETF, IEEE, Broadand Forum, MEF, cz.nic, sysrepo, openconfig, and some vendors (Cisco, Huawei).

Do we still have some issues in the world of YANG & data model-driven management? Absolutely, but we passed the advertisement phase (YANG is used), we are on the right track for the coordination phase (the YANG knowledge is spread across IETF Working Groups and the industry), and we should now focus on the optimization phase. To mention just a few problems to tackle next:

• Knowing that examples are key to help implementations, we should develop the toolchain to validate examples automatically. And we should have the ability to add more examples to existing published YANG modules.
• We should define a way to update YANG modules in a backward incompatible way. Indeed, because the RFC7950 update rules are so strict, the YANG module needs to perfect day one, which causes some delay in the specifications. It would also solve an important issue for generated YANG module, also known as native models.
• Publishing the RFC might be perceived as the end goal, however let’s not forget that the YANG module is really the useful part of the RFC, as it can generate code. IMO, IANA should be the source of truth for YANG modules. This is work-in-progress, with the goal to retrieve all YANG in a single rsync command: the latest IANA-maintained modules such as the iana-if-type.yang, the newly published modules from RFCs with potentially the inclusion of errata.
• Also, at some point in time, we might have to run our IETF process directly on the product of the RFCs (read the YANG modules), as opposed to the RFC itself.

Regards, Benoit (happy ex-OPS Area Director and now individual contributor)