An Experiment: Mapping IETF Device YANG Models to Vendors
draft-fl-nmop-device-yang-vendor-mapping-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ian Farrer , Kris Lambrechts | ||
| Last updated | 2026-10-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-fl-nmop-device-yang-vendor-mapping-00
NMOP I. Farrer
Internet-Draft Deutsche Telekom AG
Intended status: Experimental K. Lambrechts
Expires: 30 April 2027 Intwine
27 October 2026
An Experiment: Mapping IETF Device YANG Models to Vendors
draft-fl-nmop-device-yang-vendor-mapping-00
Abstract
This document describes an experimental implementation of a YANG to
YANG translation function layer providing a northbound interface for
configuring networking devices using a set of IETF 'device' YANG
modules. The southbound interface of the function implements the
proprietary, vendor YANG modules which are implemented natively on
devices to be configured. The expected benefits of such an approach
are the ability to provide a stable, standardised, and vendor/device
agnostic interface for the configuration and maintenance of devices.
The main purposes for this experiment is to validate the overall
approach, and to identify, and describe the different YANG-to-YANG
translation techniques that can be used.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 30 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Farrer & Lambrechts Expires 30 April 2027 [Page 1]
Internet-Draft ietf-mapping-vendors October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Status of this document . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Advantages of the Approach . . . . . . . . . . . . . . . 6
5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Declarative Configuration Mapping . . . . . . . . . . . . 8
5.2. Extending the Models with Augments . . . . . . . . . . . 8
5.3. Supporting Additional Vendors and Releases . . . . . . . 9
5.4. Offbox Translation and Shared Implementation . . . . . . 9
5.5. Standalone Translation Function . . . . . . . . . . . . . 10
6. Implementation Considerations . . . . . . . . . . . . . . . . 10
6.1. Handling Multiple Versions . . . . . . . . . . . . . . . 10
6.2. Complete Configuration Generation . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
IETF device YANG models provide a standardized interface for
configuring network devices. However, devices may implement vendor-
specific YANG models natively, requiring management systems to
accommodate differences between vendors. A translation layer between
these models could allow management systems to use IETF device models
while interacting with devices through their native models.
The need for tooling to support this approach was highlighted at the
IAB Workshop on the Next Era of Network Management Operations
(NEMOPS). Section 3.1.1 of the workshop report [RFC9968] notes:
| Additionally, the lack of open-source Network Management System
| (NMS) implementations, tools, and device model implementations was
| identified as a significant barrier to advancing standardization
Farrer & Lambrechts Expires 30 April 2027 [Page 2]
Internet-Draft ietf-mapping-vendors October 2026
| efforts. The IETF could play a key role in fostering and enabling
| collaborations to address these challenges. While the IETF does
| not itself build tools, it was suggested that having a translation
| tool that runs outside the network device to map IETF device
| models to vendor-specific ones would be beneficial.
This document explores the suggested approach through an experimental
implementation of a YANG-to-YANG translation layer. The layer runs
outside the network device and exposes a northbound interface based
on IETF device YANG modules. Its southbound interface uses the
vendor-specific YANG modules implemented natively on the device.
The experiment aims to assess whether this approach can provide a
stable, standardized configuration interface across vendors and
devices, and to identify and describe the YANG-to-YANG translation
techniques needed to support it.
2. Status of this document
This document is experimental. Its main goal is to evaluate a
translation layer between IETF device YANG models and vendor-specific
YANG models implemented natively on network devices, and to identify
and describe the YANG-to-YANG translation techniques needed to
support this approach.
The experiment consists of verifying whether the translation layer
can support device configuration through an interface based on IETF
device YANG models in operational use cases. The experiment can be
deemed successful if at least one open-source implementation
demonstrates correct translation and application of configuration on
network devices from multiple vendors.
3. Terminology
Layer: A logical abstraction representing a level of interaction
between the management system and the network device, typically used
to describe the northbound and southbound interfaces in the YANG-to-
YANG translation experiment.
Northbound interface: The interface exposed by the translation layer
to the management system, based on IETF device YANG modules.
Southbound interface: The interface used by the translation layer to
interact with the network device, based on vendor-specific YANG
modules.
Device model: TBD RFC8969
Farrer & Lambrechts Expires 30 April 2027 [Page 3]
Internet-Draft ietf-mapping-vendors October 2026
4. Problem Statement
Since the publication of the original YANG modeling language
[RFC6020] in 2010, the IETF has standardized a large number of
'device' YANG modules. [RFC8969] defines device models as follows:
| Refers to the Network Element YANG data model described in
| [RFC8199] or the device configuration model disucssed in
| [RFC8309].
|
| Device models are also used to refer to model a function embedded
| in a device (e.g., Network Address Translation (NAT) [RFC8512],
| Access Control Lists (ACLs) [RFC8519]).
The experiment described in this document is specifically concerned
with model implementations that are separate from the device being
managed.
These models cover the configuration and management of a very diverse
set of protocols and technologies, and generally take the approach of
modelling the necessary parameters and options for a particular
technology as defined by the relevant the technical specification
which defines that technology. Therefore, the IETF's YANG device
models contain a common set of configuration and mangement nodes that
are relevant for any standard compliant implementation.
Despite the number of available device YANG models, there has been a
low rate of implementation in devices and software either available
commercially, or as open-source. In many cases, no publically
available implementations exist.
However, native implementations of NETCONF/YANG management in
commercially available networking devices have become commonplace.
These implementations are generally based on proprietary YANG modules
defined by the vendor and supplied as part of a software release.
The structures of such YANG modules differ vastly from the IETF's
device models, from vendor to vendor, and often across different
platforms and device families from the same vendor.
Vendors' proprietary YANG implementations tend to be comprehensive,
in that they expose configuration and state for all of the
functionality that a given device offers. This may be a superset of
the functions defined in the IETF's device YANG models for any given
technolgy. Unique functionality offered by one vendor's
implementation of a technology versus another's is often a key factor
in a customer's decision to purchase. The chosen vendor's native
YANG models contain the necessary nodes for this functionality, so it
is ready to use on delivery of the device.
Farrer & Lambrechts Expires 30 April 2027 [Page 4]
Internet-Draft ietf-mapping-vendors October 2026
This does not easily align with the IETF's processes for publishing
and updating YANG models, which may take a number of years. In
addition, a vendor's proprietary features or extensions to a given
technology that are not standardized are unlikely to be included in
an IETF device model.
The work which is necessary to integrate vendor's proprietary models
into an automation system is significant. Multiple vendors and
platforms, each with their own disparate proprietary models make this
problem significantly worse. Vendor's model also change quite
regularly with each release of the device's operating software as
features and capabilites are added and removed bringing a high
maintenance overhead.
From the perspective of the automation implementer, this presents a
dichotomy: the IETF's device models present a stable, device and
vendor agnostic interface, but they are not widely implemented and do
not offer differentiating, vendor specific functionality. Vendor
proprietary models are comprehensive in their nature, but have a high
cost for implementation and maintainance.
The solution which proposed by this document is to produce an
abstraction layer, implementing the applicable IETF device YANG
models at its northbound interface, and integrating with vendor's
proprietary YANG models at the southbound side. The abstraction
layer is implemented as a software function using a 'middle-box'
approach, which is separated from the device(s) which it is
responsible for managing.
Farrer & Lambrechts Expires 30 April 2027 [Page 5]
Internet-Draft ietf-mapping-vendors October 2026
+----------------------------------------------+
| Orchestrator |
| (IETF device models) |
+----------------------------+-----------------+
|
| Northbound
| (IETF device YANG)
v
+----------------------------------------------+
| Offbox Translation Function |
| (YANG -> YANG) |
+----------------------------+-----------------+
|
| Southbound
| (Vendor YANG)
v
+----------------------------------------------+
| Network Device (Native) |
| (Vendor-specific YANG modules) |
+----------------------------------------------+
Figure 1: Offbox YANG Translation Function Between Orchestrator
and Device
4.1. Advantages of the Approach
A common, IETF defined northbound interface provides a stable
interface which higher layers in the automation architecture can
interface with. This interface is vendor and device agnostic.
The common, YANG northbound interface simplifies the integration of
layered implementations.
Using a middle-box approach, combined with open-source
implementations gives the integrator control and flexibility to adapt
the implemenation according to their requirements. If an integration
requires proprietary
5. Overview
The experiment selects a representative set of IETF device YANG
modules for an MPLS Label Edge Router (LER) providing Layer 3 VPN
services. Its service logic produces device configuration expressed
using the IETF models. A translation layer, running as part of the
orchestration system, converts this configuration into instance data
for the native YANG models used by each device. The resulting native
configuration is applied through the existing NETCONF southbound
interface. The current implementation targets Cisco IOS XR and
Farrer & Lambrechts Expires 30 April 2027 [Page 6]
Internet-Draft ietf-mapping-vendors October 2026
Juniper Junos (cRPD).
+====================+============================+===============+
| Technology | IETF YANG Module | Specification |
+====================+============================+===============+
| System management | ietf-system | [RFC7317] |
+--------------------+----------------------------+---------------+
| Interfaces | ietf-interfaces | [RFC8343] |
+--------------------+----------------------------+---------------+
| IPv4 addressing | ietf-ip | [RFC8344] |
+--------------------+----------------------------+---------------+
| Subinterfaces | ietf-if-extensions | [IF-EXT] |
+--------------------+----------------------------+---------------+
| VLAN encapsulation | ietf-if-vlan-encapsulation | [IF-VLAN] |
+--------------------+----------------------------+---------------+
| Network instances | ietf-network-instance | [RFC8529] |
+--------------------+----------------------------+---------------+
| Routing framework | ietf-routing | [RFC8349] |
+--------------------+----------------------------+---------------+
| MPLS interfaces | ietf-mpls | [RFC8960] |
+--------------------+----------------------------+---------------+
| IS-IS | ietf-isis | [RFC9130] |
+--------------------+----------------------------+---------------+
| LDP | ietf-mpls-ldp | [RFC9070] |
+--------------------+----------------------------+---------------+
| BGP | ietf-bgp | [BGP-MODEL] |
+--------------------+----------------------------+---------------+
| Key chains | ietf-key-chain | [RFC8177] |
+--------------------+----------------------------+---------------+
| Routing policy | ietf-routing-policy | [RFC9067] |
+--------------------+----------------------------+---------------+
| BGP policy | ietf-bgp-policy | [BGP-MODEL] |
+--------------------+----------------------------+---------------+
Table 1: IETF Device Modules with Implemented Configuration
Mappings
Table 1 lists the main modules whose configuration data is consumed
by the mappings. Supporting imports used only for types, identities,
or groupings, and the constituent BGP submodules, are not listed
separately. The implementation uses the latest available revisions
of the respective modules at the time of implementation. The
implementation is suffciently complete to configure the involved
devices to perform their role in the network. Further work may be
needed to cover the full mapping of each module.
Farrer & Lambrechts Expires 30 April 2027 [Page 7]
Internet-Draft ietf-mapping-vendors October 2026
5.1. Declarative Configuration Mapping
The mapping expresses the native configuration that corresponds to a
desired IETF configuration. YANG schemas provide typed data bindings
for both sides, and mapping functions written in Acton construct
native configuration trees from the source trees. These functions
are deterministic and retain no state between evaluations. Device
sessions, persistence, and the calculation and application of
configuration changes are handled by the surrounding orchestration
system. A mapping therefore describes the required configuration
without prescribing a sequence of device commands.
The translation runs after the configuration contributions from
resource-facing services have been merged for a device. Related
source trees are processed together: interfaces, routing protocols,
network instances, and key chains can refer to one another. For
example, a BGP neighbour can reference a peer group and a key chain,
while a VPN interface references its network instance. Resolving
these relationships against the combined input avoids making the
result depend on the order in which individual services contribute
their configuration.
Mapping can involve renaming and restructuring nodes, converting
values, or producing several native objects from one source object.
For example, an IPv4 address and prefix length become an address and
dotted-decimal netmask in the IOS XR model, and an address with a
prefix length on a logical interface in the Junos model. IETF
routing policy statements become structured Junos policy
configuration or routing policy language text carried in IOS XR YANG
leaves. These differences are contained in the vendor mappings,
allowing the service logic to use the common IETF models.
5.2. Extending the Models with Augments
A standard model may lack a node needed to express a particular
deployment requirement or a vendor-specific behaviour. The YANG
augment mechanism [RFC7950] allows a separate module to add nodes to
an existing schema. This makes it possible to keep the published
IETF modules unchanged while providing the additional inputs required
by the translation.
Farrer & Lambrechts Expires 30 April 2027 [Page 8]
Internet-Draft ietf-mapping-vendors October 2026
The current implementation uses augmentations to add BGP/MPLS L3VPN
attributes to the IETF network instance model. It also illustrates
the use of augmentations to handle vendor behaviour. It adds ios-xr-
policy-type to select regular, hierarchical, or both forms of a
policy on IOS XR, and Junos-match-type to select regular, inverted,
or both forms of a community set on Junos. These are implementation
extensions, not IETF-standardised nodes. Augments preserve access to
such capabilities while keeping the common policy structure.
5.3. Supporting Additional Vendors and Releases
Each supported device type registers mappings from the common IETF
models to its native schema. Adding a vendor, platform, or software
release consists of providing the appropriate target schema and
implementing and testing the mappings for the required configuration
subset. Shared source bindings and value conversion helpers can be
reused. The existing IOS XR and Junos mappings demonstrate how the
same device model can support different native hierarchies without
duplicating the service logic.
This separation confines many changes in vendor models to the
translation layer. It also permits gradual adoption: translated
configuration can coexist with contributions expressed directly in
native models, provided that thee results are mergeable. Common
service logic can move to the IETF models as mappings become
available, while vendor-specific configuration remains accessible.
5.4. Offbox Translation and Shared Implementation
Running the translation offbox allows operators to use IETF device
models with equipment that exposes only native YANG models. Mapping
fixes, additional model coverage, and local augments can be deployed
independently of the device software release cycle. The operator
controls the translation code and can inspect and test the generated
native configuration before deployment. Higher layers gain a common
interface through the IETF device models, reducing their dependence
on individual vendor model revisions.
The StratoWeave implementation is published as open source
[STRATOWEAVE-TRANSLATE], with the vendor mapping modules carrying a
BSD-3-Clause licence. Operators can inspect, adapt, and contribute
mappings and tests, including fixes for differences discovered in
actual deployments. Sharing this work allows operators using the
same platforms to build on a common implementation instead of each
maintaining an independent integration. We intend to make the
mapping functions useable independently of the orchestration runtime,
making them reusable in other integrations.
Farrer & Lambrechts Expires 30 April 2027 [Page 9]
Internet-Draft ietf-mapping-vendors October 2026
A shared implementation can provide executable examples of how IETF
models apply to real devices. Comparing mappings and test cases
across operators and vendors helps expose ambiguous semantics,
missing nodes, and differences in feature support. That evidence can
inform both improvements to the mappings and further development of
the IETF models.
5.5. Standalone Translation Function
Under the current experimental implementation, the tranlation logic
can only usefully be executed as part of a StratoWeave orchestrator
runtime. It is the author's explicit intention to make the
translation logic reusable with other orchestration / automation
solutions and tools.
The standalone translation function we propose would be realized in
the form of a standalone binary that accepts a complete device
configuration as input. That configuration would be according to the
IETF device models, possibly combined with with vendor-modeled YANG
modules where desired. The output would be a device-specific
configuration suitable for direct application to the target device.
We welcome feedback and contributions from the community on how they
would want make us of and integrate it in their own automation
solutions and tools.
6. Implementation Considerations
This section discusses various considerations for implementing the
translation logic in a reusable manner.
6.1. Handling Multiple Versions
The current Acton YANG framework compiles a set of vendor YANG
modules into a device type built around named Acton classes that
represent each schema node in the YANG source. The resulting nominal
type equivalence means that for another device adapter with a near-
identical YANG schema, the compiled Acton classes would be distinct,
even if the source YANG schemas were 99% identical.
For a translation framework to easily handle the translation of IETF
Device models to dozens of versions of vendor YANG modules,
structural type equivalence is required. It then becomes trivial to
express minor mapping adjustments between different versions of the
vendor YANG modules.
Farrer & Lambrechts Expires 30 April 2027 [Page 10]
Internet-Draft ietf-mapping-vendors October 2026
6.2. Complete Configuration Generation
The output of the translation function is always a complete device
configuration that represents the desired state of the device.
Inside of a StratoWeave-based orchestrator, the diff engine can take
this as input and efficiently compute the necessary changes to apply
to the running configuration of the device. In other integration
scenarios, this complete configuration can be applied directly to the
target device using e.g. a NETCONF <replace> operation.
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
This document should not affect the security of the Internet.
9. References
9.1. Informative References
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for
System Management", RFC 7317, DOI 10.17487/RFC7317, August
2014, <https://www.rfc-editor.org/info/rfc7317>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J.
Zhang, "YANG Data Model for Key Chains", RFC 8177,
DOI 10.17487/RFC8177, June 2017,
<https://www.rfc-editor.org/info/rfc8177>.
[RFC8199] Bogdanovic, D., Claise, B., and C. Moberg, "YANG Module
Classification", RFC 8199, DOI 10.17487/RFC8199, July
2017, <https://www.rfc-editor.org/info/rfc8199>.
[RFC8309] Wu, Q., Liu, W., and A. Farrel, "Service Models
Explained", RFC 8309, DOI 10.17487/RFC8309, January 2018,
<https://www.rfc-editor.org/info/rfc8309>.
Farrer & Lambrechts Expires 30 April 2027 [Page 11]
Internet-Draft ietf-mapping-vendors October 2026
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349,
DOI 10.17487/RFC8349, March 2018,
<https://www.rfc-editor.org/info/rfc8349>.
[RFC8512] Boucadair, M., Ed., Sivakumar, S., Jacquenet, C.,
Vinapamula, S., and Q. Wu, "A YANG Module for Network
Address Translation (NAT) and Network Prefix Translation
(NPT)", RFC 8512, DOI 10.17487/RFC8512, January 2019,
<https://www.rfc-editor.org/info/rfc8512>.
[RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair,
"YANG Data Model for Network Access Control Lists (ACLs)",
RFC 8519, DOI 10.17487/RFC8519, March 2019,
<https://www.rfc-editor.org/info/rfc8519>.
[RFC8529] Berger, L., Hopps, C., Lindem, A., Bogdanovic, D., and X.
Liu, "YANG Data Model for Network Instances", RFC 8529,
DOI 10.17487/RFC8529, March 2019,
<https://www.rfc-editor.org/info/rfc8529>.
[RFC8960] Saad, T., Raza, K., Gandhi, R., Liu, X., and V. Beeram, "A
YANG Data Model for MPLS Base", RFC 8960,
DOI 10.17487/RFC8960, December 2020,
<https://www.rfc-editor.org/info/rfc8960>.
[RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and
L. Geng, "A Framework for Automating Service and Network
Management with YANG", RFC 8969, DOI 10.17487/RFC8969,
January 2021, <https://www.rfc-editor.org/info/rfc8969>.
[RFC9067] Qu, Y., Tantsura, J., Lindem, A., and X. Liu, "A YANG Data
Model for Routing Policy", RFC 9067, DOI 10.17487/RFC9067,
October 2021, <https://www.rfc-editor.org/info/rfc9067>.
[RFC9070] Raza, K., Ed., Asati, R., Liu, X., Esale, S., Chen, X.,
and H. Shah, "YANG Data Model for MPLS LDP", RFC 9070,
DOI 10.17487/RFC9070, March 2022,
<https://www.rfc-editor.org/info/rfc9070>.
Farrer & Lambrechts Expires 30 April 2027 [Page 12]
Internet-Draft ietf-mapping-vendors October 2026
[RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and
L. Lhotka, "YANG Data Model for the IS-IS Protocol",
RFC 9130, DOI 10.17487/RFC9130, October 2022,
<https://www.rfc-editor.org/info/rfc9130>.
[RFC9968] Hardaker, W. and D. Dhody, "Report from the IAB Workshop
on the Next Era of Network Management Operations
(NEMOPS)", RFC 9968, DOI 10.17487/RFC9968, May 2026,
<https://www.rfc-editor.org/info/rfc9968>.
[IF-EXT] Wilton, R. and S. Mansfield, "Common Interface Extension
YANG Data Models", Work in Progress, Internet-Draft,
draft-ietf-netmod-intf-ext-yang-18, 19 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
intf-ext-yang-18>.
[IF-VLAN] Wilton, R. and S. Mansfield, "Sub-interface VLAN YANG Data
Models", Work in Progress, Internet-Draft, draft-ietf-
netmod-sub-intf-vlan-model-18, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
sub-intf-vlan-model-18>.
[BGP-MODEL]
Jethanandani, M., Patel, K., Hares, S., and J. Haas, "YANG
Model for Border Gateway Protocol (BGP-4)", Work in
Progress, Internet-Draft, draft-ietf-idr-bgp-model-21, 14
August 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-idr-bgp-model-21>.
[STRATOWEAVE-TRANSLATE]
Lambrechts, K., "StratoWeave: IETF Device Model
Translation Experiment",
<https://github.com/stratoweave/sorespo/tree/translate>.
Acknowledgements
The authors would like to thank Alex Huang Feng for his review and
valuable comments.
Authors' Addresses
Ian Farrer
Deutsche Telekom AG
53227 Bonn
Germany
Email: ian.farrer@telekom.de
Farrer & Lambrechts Expires 30 April 2027 [Page 13]
Internet-Draft ietf-mapping-vendors October 2026
Kris Lambrechts
Intwine
Email: kris@intwine.net
URI: https://www.intwine.net
Farrer & Lambrechts Expires 30 April 2027 [Page 14]