A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM) Integrity Protected Options

1.1. Editorial Note (to be removed by RFC Editor)

Note to the RFC Editor: this section is to be removed prior to publication.¶

This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document, except in Appendix A.¶

Please apply the following replacements:¶

• XXXX --> the assigned RFC number for this document¶
• YYYY --> the assigned RFC number for [I-D.ietf-ippm-ioam-data-integrity]¶
• 2025-11-30 --> the actual date of the publication of this document¶

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Abbreviations

Abbreviations used in this document:¶

OAM:

Operations, Administration, and Maintenance¶

IOAM:

In Situ OAM¶

POT:

Proof of Transit¶

E2E:

Edge to Edge¶

2.3. Terminology

The following terms are defined in [RFC7950] and are used in this specification:¶

• augment¶
• data model¶
• data node¶

The terminology for describing YANG data models is found in [RFC7950].¶

2.4. Tree Diagrams

Tree diagrams used in this document follow the notation defined in [RFC8340].¶

3.1. Overview

The IOAM Integrity model is organized as a list of profiles, as shown in Figure 1. In this model, the "int" prefix refers to "INTegrity protection".¶

module: ietf-ioam-integrity

  augment /ioam:ioam/ioam:profiles/ioam:profile:
    +--rw int-incremental-tracing-profile! {int-incremental-trace}?
    |  ...
    +--rw int-preallocated-tracing-profile! {int-preallocated-trace}?
    |  ...
    +--rw int-pot-profile! {int-proof-of-transit}?
    |  ...
    +--rw int-e2e-profile! {int-edge-to-edge}?

This document defines augmentations to the "ietf-ioam" YANG module [RFC9617] by adding integrity-related profiles. Each profile associates with one flow and the corresponding IOAM information. These integrity-related profiles are indicated by four defined features, i.e., "int-incremental-trace", "int-preallocated-trace", "int-proof-of-transit", and "int-edge-to-edge". The structures of the new profiles follow what is defined in [RFC9617], but for distinct purpose.¶

3.2. Integrity Protected Pre-allocated Tracing Profile

As illustrated in Figure 2, the "int-preallocated-tracing-profile" container provides the detailed information for the pre-allocated tracing data with integrity protection. This information has the same structure as the Pre-allocated Tracing Profile (Section 3.2 of [RFC9617]), but has the following additional data node:¶

int-method:

indicates which Integrity Protection Method is used, as defined in the "IOAM Integrity Protection Methods" IANA registry [IANA-IOAM].¶

+--rw int-preallocated-tracing-profile! {int-preallocated-trace}?
   +--rw node-action?   ioam-node-action
   +--rw trace-types
   |  +--rw use-namespace?   ioam-namespace
   |  +--rw trace-type*      ioam-trace-type
   +--rw max-length?    uint32
   +--rw int-method?    iana-ioam-ipm:method-id

3.3. Integrity Protected Incremental Tracing Profile

As illustrated in Figure 3, the "int-incremental-tracing-profile" container provides the detailed information for the incremental tracing data with integrity protection. This information has the same structure as the Incremental Tracing Profile (Section 3.3 of [RFC9617]), but has the following additional data node:¶

int-method:

indicates which Integrity Protection Method is used, as defined in the "IOAM Integrity Protection Methods" IANA registry [IANA-IOAM].¶

+--rw int-incremental-tracing-profile! {int-incremental-trace}?
   +--rw node-action?   ioam-node-action
   +--rw trace-types
   |  +--rw use-namespace?   ioam-namespace
   |  +--rw trace-type*      ioam-trace-type
   +--rw max-length?    uint32
   +--rw int-method?    iana-ioam-ipm:method-id

3.4. Integrity Protected Proof of Transit Profile

As illustrated in Figure 4, the "int-pot-profile" container is intended to provide the detailed information for the proof of transit data with integrity protection. This information has the same structure as the Proof of Transit Profile (Section 3.5 of [RFC9617]), but has the following additional data nodes:¶

node-action:

imported from the "ietf-ioam" YANG module [RFC9617] with the same definition.¶

int-method:

indicates which Integrity Protection Method is used, as defined in the "IOAM Integrity Protection Methods" IANA registry [IANA-IOAM].¶

+--rw int-pot-profile! {int-proof-of-transit}?
   +--rw use-namespace?   ioam:ioam-namespace
   +--rw pot-type?        ioam:ioam-pot-type
   +--rw node-action?     ioam:ioam-node-action
   +--rw int-method?      iana-ioam-ipm:method-id

3.5. Integrity Protected Edge-to-Edge Profile

As illustrated in Figure 5, the "int-e2e-profile" container provides the detailed information for the edge-to-edge data with integrity protection. This information has the same structure as the Edge-to-Edge Profile (Section 3.6 of [RFC9617]), but has the following additional data node:¶

int-method:

indicates which Integrity Protection Method is used, as defined in the "IOAM Integrity Protection Methods" IANA registry [IANA-IOAM].¶

+--rw int-e2e-profile! {int-edge-to-edge}?
   +--rw node-action?   ioam-node-action
   +--rw e2e-types
   |  +--rw use-namespace?   ioam-namespace
   |  +--rw e2e-type*        ioam-e2e-type
   +--rw int-method?    iana-ioam-ipm:method-id

6.1. IANA-Maintained "iana-ioam-integrity-protection-methods" Module

This document defines the initial version of the IANA-maintained "iana-ioam-integrity-protection-methods" YANG module. The most recent version of the YANG module is available from the "YANG Parameters" registry group [IANA-YANG-PARAMETERS].¶

IANA is requested to add this note to the registry:¶

New values must not be directly added to the "iana-ioam-integrity-protection-methods" YANG module. They must instead be added to the "IOAM Integrity Protection Methods" registry.¶

When a value is added to the "IOAM Integrity Protection Methods" registry, a new "enum" statement must be added to the "iana-ioam-integrity-protection-methods" YANG module. The "enum" statement, and sub-statements thereof, should be defined:¶

"enum":

Replicates a name from the registry.¶

"value":

Contains the decimal value of the IANA-assigned value.¶

"status":

Is included only if a registration has been deprecated or obsoleted. IANA "deprecated" maps to YANG status "deprecated", and IANA "obsolete" maps to YANG status "obsolete".¶

"description":

Replicates the description from the registry.¶

"reference":

Replicates the reference(s) from the registry with the title of the document(s) added.¶

Unassigned or reserved values are not present in the module.¶

When the "iana-ioam-integrity-protection-methods" YANG module is updated, a new "revision" statement with a unique revision date needs to be added in front of the existing revision statements. The "revision" statement MUST contain both "description" and "reference" substatements as follows.¶

The "description" substatement captures what changed in the revised version. Typically, the description enumerates the changes such as udpates to existing entries (e.g., update a description or a reference) or notes which "enums" were added or had their status changed (e.g., deprecated, discouraged, or obsoleted).¶

The "description" substatement should include this text: "Applied updates as specified by RFC number.".¶

The "reference" substatement points specifically to the published module (i.e., IANA_FOO_URL_With_REV). It may also point to an authoritative event triggering the update to the YANG module. In all cases, this event is cited from the underlying IANA registry. If the update is triggered by an RFC, that RFC must also be included in the "reference" substatement.¶

IANA is requested to add this note to [reference-to-the-iana-foo-registry]:¶

When this registry is modified, the YANG module "iana-ioam-integrity-protection-methods" [IANA_FOO_URL] must be updated as defined in RFC XXXX.¶

8.1. Normative References

[I-D.ietf-ippm-ioam-data-integrity]

Brockners, F., Bhandari, S., Mizrahi, T., and J. Iurman, "Integrity Protection of In Situ Operations, Administration, and Maintenance (IOAM) Data Fields", Work in Progress, Internet-Draft, draft-ietf-ippm-ioam-data-integrity-15, 1 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-integrity-15>.

[IANA-IOAM]

"In Situ OAM (IOAM)", n.d., <https://www.iana.org/assignments/ioam/ioam.xhtml>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688]

Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[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>.

[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>.

[RFC7951]

Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8341]

Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC9617]

Zhou, T., Ed., Guichard, J., Brockners, F., and S. Raghavan, "A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9617, DOI 10.17487/RFC9617, August 2024, <https://www.rfc-editor.org/info/rfc9617>.

8.2. Informative References

[I-D.ietf-netmod-rfc8407bis]

Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", Work in Progress, Internet-Draft, draft-ietf-netmod-rfc8407bis-28, 5 June 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28>.

[IANA-YANG-PARAMETERS]

"YANG Parameters", n.d., <https://www.iana.org/assignments/yang-parameters>.

[RFC4252]

Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, <https://www.rfc-editor.org/info/rfc4252>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7799]

Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8040]

Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

[RFC8340]

Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.