/
IETF Liaison Project

IETF Liaison Project

Welcome to IETF Liaison Project

Introduction

This project’s goal is to act as a liaison between OpenDaylight and IETF.

The primary goal is to package a reasonable subset of YANG models published by the IETF and IANA. IETF acts as the authority defining for a number of IANA-maintained namespace or YANG modules, with a split jurisdiction:

  • IANA maintains modules named iana-*, without an explicit IETF action – i.e. whenever the IANA registry re-generates

  • IETF maintains modules named ietf-*, with an explicit IETF action – e.g. when a new RFC is published

For this purpose, this project will receive the contents and inherit the custody of MD-SAL's model/iana and model/rfc directories. This includes utility classes, such as ietf-inet-util and feature repositories like odl-mdsal-model-rfc6022 (which will get suitably renamed).

 

The secondary goal is to provide Java integrations with key IETF models, such as:

For this purpose, this project will receive the contents and inherit the custody of (parts of) NETCONF’s keystore, truststore and transport directories. It will be up to this project to provide the direction of how the inherited APIs evolve and what integrations with external components are provided. Most notably, an integration with K8S secrets should be provided for keystore/truststore.

It should be noted that the there exists an integration surface between ietf-keystore and ietf-tls-common, which essentially expresses a secure-at-rest to secure-in transit transition. There are many ways to achieve a transition: Java-level-TLS is an obvious example, but in an K8S deployment that may boil down to the JVM making a TCP connection to an external system and the run-time environment wrapping it in a TLS connection.

In the latter scenario, transport-tlscomponents are expressing an invariant based on secure-at-rest configuration towards a secure-in-transit property – including certificate (in-)validation, key rotation et al. – which are completely handed off to implementations: the JVM should never see the keys/certificates, but it has to be able to verify that the invariant is provided by the environment or fail-fast.

Any network-facing functions must provide integration with Netty-4.2+, so that, for example. a transport-tlsimplementation relying on K8S-level encapsulation is reflected by that implementation validating all connections by providing the equivalent of SslHandler.


The tertiary goal is to provide a well-defined scope for interactions with the IETF as a Standards Definition Organization, with having an IETF-appointed liaison person to guide our interactions with IETF and its SDO-internal workings.

 

There are current (as of July 2025) tensions this project seeks to resolve:

  • not all OpenDaylight artifacts requiring IETF models also require MD-SAL Java APIs (like mdsal-dom-api), so those should be releaseable without a dependency on the MD-SAL project

  • there is a ton on Nettyepoll-or-nio code duplication between e.g. NETCONF and BGPCEP, for which BGPCEP should not depend on NETCONF, and having a shared equivelent of org.opendaylight.netconf.transport.spiwould go a long way

 

As such, this proposal seeks to allocate the following namespaces:

  • ietf as its repository name

  • IETF as its Jira project key

  • org.opendaylight.ietf.* Maven groupIds

  • org.opendaylight.iana as a Java package name, including all sub-packages

  • org.opendaylight.ietf as a Java package name, including all sub-packages

  • urn:ietf:params:xml:ns:yang:iana-* YANG (and by extension XML) namespaces and their corresponding YANG Tools codegen allocation, with other OpenDaylight needing to consult this project before packaging non-draft models in this namespace themselves

  • urn:ietf:params:xml:ns:yang:ietf-* YANG (and by extension XML) namespaces and their corresponding YANG Tools codegen allocation, with other OpenDaylight needing to consult this project before packaging non-draft models in this namespace themselves

Project Facts

Project Creation Date: 
Primary Contact: @Robert Varga
Project Lead:   @Robert Varga
Committers:  

  • MD-SAL committers for phase one

  • NETCONF committers for phase two

Mailing List:  
Meetings: See Community Meetings 
Repository: proposed
Jenkins: 
Open Bugs: 

Documentation

The following documentation will be provided

  • Getting Started for Developers, outlining how to use provided Java APIs

  • Getting Started for Users, outlining the integration surface configuration, e.g. what do I need to get the above TLS-over-wrapper configuration going

Release Planning

This project will follow Semantic Versioning from its inception. The following versions are envisioned:

  • 1.0.0 that includes things inherited from MD-SAL as outlined in the primary goal

  • (M = 1..).x.x versions provided as per the evolution on 1.0.0code and how the project sees fit

  • (N = M+1).x.x that includes things inherited from NETCONF as outlined in the secondary goal

  • M.x.xand any other releases as the project sees fit

Release Notes