Skip to main content
  • IETF 117 Highlights

    IETF 117 is a few weeks behind us and Dhruv Dhody, IAB Member and liaison to the IESG, took the opportunity to report on a few highlights and some impressions.

    • Dhruv DhodyIAB Member and liaison to the IESG
    21 Aug 2023
  • Proposed response to meeting venue consultations and the complex issues raised

    The IETF Administration LLC recently sought feedback from the community on the possibility of holding an IETF Meeting in the cities of Beijing, Istanbul, Kuala Lumpur and Shenzhen, with received feedback including views that were well expressed and well argued but strongly conflicting. The IETF LLC has considered this feedback in-depth and now seeks community feedback on its proposed response.

    • Jay DaleyIETF Executive Director
    21 Aug 2023
  • Submit Birds of a Feather session proposals for IETF 118

    Now's the time to submit Birds of a Feather session (BOFs) ideas for the IETF 118 meeting 4-10 November 2023, with proposals due by 8 September.

      16 Aug 2023
    • Applied Networking Research Workshop 2023 Review

      More than 250 participants gathered online and in person for ANRW 2023, the academic workshop that provides a forum for researchers, vendors, network operators, and the Internet standards community to present and discuss emerging results in applied networking research.

      • Maria ApostolakiANRW Program co-chair
      • Francis YanANRW Program co-chair
      16 Aug 2023
    • IETF 117 post-meeting survey

      IETF 117 San Francisco was held 22-28 July 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

      • Jay DaleyIETF Executive Director
      11 Aug 2023

    Filter by topic and date

    Filter by topic and date

    YANG Data Models in the Industry: Current State of Affairs (March 2018)

    • Benoît Claise

    4 Apr 2018

    Just after IETF 101 in London, let’s analyze the current state of affairs in the YANG Data Models world.

    During IETF 101, we published the new Network Management Datastore Architecture (NMDA) as RFC 8342 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 is working towards 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 are finally seeing 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).

    IETF YANG Modules and Submodules from RFCs

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

    Recently, the NETMOD working group 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 with RFC 6087, a key document that many should read.

    During the IETF meeting 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 quickly 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 IETF 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.



    (happy ex-OPS Area Director and now an individual IETF contributor)

    Benoît shoes in snow.

    This post was originally published on 27 March 2018 as: 

    "YANG Data Models in the Industry: Current State of Affairs (March 2018)"

    Note also the previous “YANG Data Models in the Industry: Current State of Affairs” published following  the IETF 100 meeting in Singapore.


    • [1]RFC 8342

      Network Management Datastore Architecture (NMDA)

      Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained …

    • [2]RFC 6087

      Guidelines for Authors and Reviewers of YANG Data Model Documents

      This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase inter…

    Share this page