diff --git a/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-06-30.yang b/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-06-30.yang deleted file mode 100644 index b255aef1c..000000000 --- a/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-06-30.yang +++ /dev/null @@ -1,511 +0,0 @@ -module ietf-bmp-telemetry-message { - yang-version 1.1; - namespace "urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message"; - prefix bmptm; - - import ietf-inet-types { - prefix inet; - reference - "RFC 9911: Common YANG Data Types"; - } - import ietf-yang-types { - prefix yang; - reference - "RFC 9911: Common YANG Data Types"; - } - import ietf-yang-structure-ext { - prefix sx; - reference - "RFC 8791: YANG Data Structure Extensions"; - } - import ietf-routing-types { - prefix rt-types; - reference - "RFC 8294: Common YANG Data Types for the Routing Area."; - } - - import ietf-bgp-open { - prefix bgo; - reference - "RFC XXXX: YANG Model for a BGP OPEN Message."; - } - import ietf-bgp-rib-entry { - prefix bre; - reference - "RFC XXXX: YANG Model for a BGP RIB Entry."; - } - import ietf-bmp-tlv { - prefix btlv; - reference - "RFC XXXX: YANG Model for BMP TLVs."; - } - - organization - "IETF Draft"; - contact - "Author: Thomas Graf - - Paolo Lucente - - Leonardo Rodoni - "; - - description - "Adds BMP specific subscription metadata to the data collection - protocol provenance of the ietf-telemetry-message envelope. - - 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 (RFC 2119) - (RFC 8174) when, and only when, they appear in all - capitals, as shown here. - - Copyright (c) 2026 IETF Trust and the persons identified as - authors of the code. All rights reserved. - - Redistribution and use in source and binary forms, with or without - modification, is permitted pursuant to, and subject to the license - terms contained in, the Revised BSD License set forth in Section - 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents - (https://trustee.ietf.org/license-info). - - This version of this YANG module is part of RFC XXXX; see the RFC - itself for full legal notices."; - - revision 2026-06-30 { - description - "Initial revision."; - reference - "RFC XXXX"; - } - - typedef peer-type { - type enumeration { - enum global-instance-peer { - value 0; - description - "Global Instance Peer"; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - enum rd-instance-peer { - value 1; - description - "RD Instance Peer"; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - enum local-instance-peer { - value 2; - description - "Local Instance Peer"; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - enum loc-rib-instance-peer { - value 3; - description - "Loc-RIB Instance Peer"; - reference - "RFC 9069: Support for Local RIB in the BGP Monitoring - Protocol (BMP)"; - } - } - description - "BMP Peer Type."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - - grouping per-peer { - description - "BMP per-peer header."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - leaf peer-type { - type peer-type; - mandatory true; - description - "BMP peer type from per-peer header."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - container peer-flags { - when "not(../extended-flags)" { - description - "Present only when the Extended Flags TLV is absent. - When extended-flags is present it is authoritative - and peer-flags MUST NOT be emitted."; - } - description - "BMP Per-Peer Header Flags decoded from the Per-Peer Header - Flags field."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - uses btlv:peer-header-flags; - } - leaf peer-distinguisher { - type rt-types:route-distinguisher; - mandatory true; - description - "BMP peer distinguisher from per-peer header. - The routing instance on which the encapsulated PDU was - received."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - leaf peer-address { - type inet:ip-address; - mandatory true; - description - "BMP peer IP address from per-peer header."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2. The - remote IP address associated with the TCP session over which - the encapsulated PDU was received."; - } - leaf peer-as { - type uint32; - mandatory true; - description - "BMP peer autonomous system number from per-peer header. The - Autonomous System number of the peer from which the - encapsulated PDU was received."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - leaf peer-bgp-id { - type inet:ipv4-address; - mandatory true; - description - "BMP Peer BGP ID from per-peer header. The BGP Identifier of - the peer from which the encapsulated PDU was received."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2."; - } - leaf timestamp { - type yang:date-and-time; - description - "BMP timestamp from the Per-Peer Header (RFC 7854 Section 4.2). - Represents the time the encapsulated routes were received or - installed in the Adj-RIB-In. Absent when the value was zero - (unavailable) in the wire header. - - // TODO: check with bmp-tlv regarding authoritative timestamp - The Timestamp TLV (message-timestamp in btlv:common) MAY - also be present and carries a typed timestamp. When - message-timestamp with type 'adj-rib-in-time' is present, it - is the authoritative value for this same event; the other - Timestamp TLV types (trigger-time, message-export-time, - local-rib-time, adj-rib-out-time) carry additional timing - information with no Per-Peer Header equivalent."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.2.; - draft-ietf-grow-bmp-tlv: Section 5.6.1."; - } - } - - typedef peer-down-reason-code { - type enumeration { - enum local-system-closed-notification { - value 1; - description - "The local system closed the session. A BGP PDU containing - a BGP NOTIFICATION message that would have been sent to - the peer follows the reason code."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; - } - enum local-system-closed-fsm-event { - value 2; - description - "The local system closed the session. No NOTIFICATION - message was sent. A 2-byte field containing the FSM - Event code follows the reason code."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; - } - enum remote-system-closed-notification { - value 3; - description - "The remote system closed the session with a NOTIFICATION - message. The BGP PDU containing the NOTIFICATION follows - the reason code."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; - } - enum remote-system-closed-no-data { - value 4; - description - "The remote system closed the session without a NOTIFICATION - message. Includes any unexpected termination of the - transport session."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; - } - enum peer-de-configured { - value 5; - description - "Information for this peer will no longer be sent to the - monitoring station for configuration reasons."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9."; - } - enum local-system-closed-tlv-data-follows { - value 6; - description - "The local system closed the Loc-RIB instance peer session. - TLV data follows (see btlv:peer-down), including the - VRF/Table Name TLV if it was present in the Peer Up."; - reference - "RFC 9069: Support for Local RIB in BMP, Section 5.3."; - } - } - description - "BMP Peer Down reason codes."; - reference - "RFC 7854: Section 4.9; RFC 9069: Section 5.3."; - } - - grouping mirroring { - description - "BMP Route Mirroring Information TLV content (type 1 in the - Route Mirroring TLVs registry). Conveys a 2-byte information - code about the mirrored message or message stream."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.7."; - leaf information { - type enumeration { - enum error-pdu { - value 0; - description - "Errored PDU. The contained message was found to have - an error causing it to be treated-as-withdraw - (RFC 7606). A BGP Message TLV MUST also be present."; - } - enum message-lost { - value 1; - description - "Messages Lost. One or more messages may have been - lost, e.g., due to buffer exhaustion."; - } - } - description - "Route Mirroring Information code."; - } - } - - // TODO: design better grouping for statistics - grouping statistics { - description - "BMP Statistics."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.8."; - leaf statistics-type { - type string { - } - description - "BMP statistics type. Defines the type of the statistic carried - in the Stat Data field."; - } - leaf statistics-data { - type uint64; - description - "BMP statistics data. Defines the value of the statistic."; - } - } - - grouping peer-up { - description - "BMP Peer Up Notification fields."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - leaf local-address { - type inet:ip-address; - description - "Local address from the Peer Up Notification. Set to - '0::' for Loc-RIB Instance Peers."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - } - leaf local-port { - type inet:port-number; - description - "Local port from the Peer Up Notification. Set to 0 - for Loc-RIB Instance Peers."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - } - leaf remote-port { - type inet:port-number; - description - "Remote port from the Peer Up Notification. Set to 0 - for Loc-RIB Instance Peers."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - } - - container sent-open { - description - "BGP OPEN message sent by the local router to its peer."; - reference - "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2. - RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - uses bgo:bgp-open; - } - container received-open { - description - "BGP OPEN message received from the peer."; - reference - "RFC 4271: A Border Gateway Protocol 4 (BGP-4), Section 4.2. - RFC 7854: BGP Monitoring Protocol (BMP), Section 4.10."; - uses bgo:bgp-open; - } - } - - sx:structure message { - description - "Augments telemetry-message-metadata with BMP specific - subscription metadata"; - - leaf version { - type uint8; - mandatory true; - description - "BMP version from common header."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.1."; - } - - container session-metadata { - presence - "BMP Initiation message information cached by a collector - to enrich this message with router identity context."; - description - "Optional metadata derived from the BMP Initiation message - for this BMP session. A collector MAY populate sys-name, - sys-descr or a free-form string leaf-list to make this - message self-contained for consumers that did not process - or store the Initiation message directly."; - uses btlv:information; - } - - choice message-type { - description - "BMP message type from common header."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.1."; - case route-monitoring { - container route-monitoring { - description - "BMP Route Monitoring message. Used for initial - synchronization of Adj-RIBs-In and for ongoing - incremental route monitoring."; - uses per-peer; - uses bre:rib-entry; - uses btlv:route-monitoring; - uses btlv:common; - } - } - case statistics-report { - container statistics-report { - description - "BMP Statistics Report message. Carries one or more - counters reflecting activity on the monitored router."; - uses per-peer; - uses statistics; - uses btlv:common; - } - } - case peer-down-notification { - container peer-down-notification { - description - "BMP Peer Down Notification message. Indicates that a - peering session was terminated."; - uses per-peer; - leaf reason { - type peer-down-reason-code; - mandatory true; - description - "Reason why the peering session was closed."; - reference - "RFC 7854: BGP Monitoring Protocol (BMP), Section 4.9; - RFC 9069: Support for Local RIB in BMP, Section 5.3."; - } - container peer-down { - when "../reason = 'local-system-closed-tlv-data-follows'" { - description - "TLV data is present only when reason code 6 is - used (Loc-RIB instance peer session closed)."; - } - description - "Peer Down TLV data following reason code 6. Contains - the VRF/Table Name TLV if it was present in the - corresponding Peer Up notification."; - uses btlv:peer-down; - } - uses btlv:common; - } - } - case peer-up-notification { - container peer-up-notification { - description - "BMP Peer Up Notification message. Indicates that a - peering session has come up."; - uses per-peer; - uses peer-up; - container information { - presence - "Information TLVs are present in this Peer Up - notification"; - description - "Optional Information TLVs at the end of the Peer Up - message. For standard peers only the string type - (type 0) is defined; for Loc-RIB Instance Peers the - VRF/Table Name TLV (type 3, RFC 9069) MUST be - included when a name is configured."; - reference - "RFC 7854: Section 4.10; - RFC 9069: Section 5.2.1."; - uses btlv:information; - } - uses btlv:common; - } - } - case initiation-message { - container initiation-message { - description - "BMP Initiation Message. Provides information about the - monitored router. MUST be the first message sent after - the TCP session comes up. The sysDescr and sysName - TLVs MUST be present."; - uses btlv:information; - uses btlv:common; - } - } - case termination-message { - container termination-message { - description - "BMP Termination Message. Provides a reason why the - monitored router is closing the BMP session."; - uses btlv:termination; - uses btlv:common; - } - } - case route-mirroring-message { - container route-mirroring-message { - description - "BMP Route Mirroring Message. Used for verbatim - duplication of messages as received, e.g., for - full-fidelity monitoring or error reporting."; - uses per-peer; - uses bre:rib-entry; - uses mirroring; - uses btlv:common; - } - } - } - } -} - diff --git a/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-07-25.yang b/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-07-25.yang new file mode 100644 index 000000000..5a0b0ee99 --- /dev/null +++ b/experimental/ietf-extracted-YANG-modules/ietf-bmp-telemetry-message@2026-07-25.yang @@ -0,0 +1,237 @@ +module ietf-bmp-telemetry-message { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-bmp-telemetry-message"; + prefix bmp-tm; + + import ietf-telemetry-message { + prefix tm; + reference + "I-D.ietf-nmop-message-broker-telemetry-message: Extensible + YANG Model for Network Telemetry Messages"; + } + import ietf-bmp { + prefix bmp; + reference + "I-D.ietf-grow-bmp-yang: A YANG Data Model for BMP"; + } + import ietf-inet-types { + prefix inet; + reference "RFC 6991: Common YANG Data Types"; + } + import ietf-yang-types { + prefix yang; + reference "RFC 6991: Common YANG Data Types"; + } + import ietf-routing-types { + prefix rt-types; + reference "RFC 8294: Common YANG Data Types for the Routing + Area"; + } + import ietf-yang-structure-ext { + prefix sx; + reference "RFC 8791: YANG Data Structure Extensions"; + } + + organization "IETF NMOP Working Group (proposed)"; + contact + "Author: Saumya Dikshit + + Author: Mukul Srivastava + + Author: Changwang Lin + "; + description + "This module augments the 'ietf-telemetry-message' envelope + defined in I-D.ietf-nmop-message-broker-telemetry-message + with provenance metadata specific to data collected via the + BGP Monitoring Protocol (BMP), RFC 7854. + + Copyright (c) 2026 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Revised BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info)."; + + revision 2026-07-25 { + description + "Initial revision."; + reference + "RFC XXXX"; + } + + identity bmp { + base tm:session-protocol; + description + "BGP Monitoring Protocol (BMP) as defined in RFC 7854."; + reference + "RFC 7854: BGP Monitoring Protocol (BMP)."; + } + + identity bmp-message-type { + description + "Base identity for BMP message types, RFC 7854 Section 4."; + } + identity route-monitoring { + base bmp-message-type; + description "Route Monitoring message."; + } + identity statistics-report { + base bmp-message-type; + description "Statistics Report message."; + } + identity peer-down { + base bmp-message-type; + description "Peer Down Notification."; + } + identity peer-up { + base bmp-message-type; + description "Peer Up Notification."; + } + identity initiation { + base bmp-message-type; + description "Initiation Message."; + } + identity termination { + base bmp-message-type; + description "Termination Message."; + } + identity route-mirroring { + base bmp-message-type; + description "Route Mirroring Message."; + } + + identity bmp-stat-extension { + description + "Base identity for BMP Statistics Report Stat Type + registries/extensions."; + } + identity base-rfc7854 { + base bmp-stat-extension; + description "Base Stat Types defined in RFC 7854 Section 4.8."; + } + identity rfc9972-bgp-rib-stats { + base bmp-stat-extension; + description "Per-AFI/SAFI BGP RIB statistics, RFC 9972."; + } + identity informational-tlv { + base bmp-stat-extension; + description + "Min/max/avg/median informational TLV extension, + I-D.ietf-grow-bmp-stats-informational-tlv."; + } + identity afi-safi-evpn { + base bmp-stat-extension; + description + "Per-EVI EVPN BMP RIB statistics, + I-D.saum-grow-bmp-afi-safi-evpn."; + } + identity route-change-stats { + base bmp-stat-extension; + description + "Per-peer route-attribute-change statistics, + I-D.smc-grow-bmp-route-change-stats."; + } + identity rd-scoped-rib-stats { + base bmp-stat-extension; + description + "Address-family-agnostic RD-scoped statistics container, + I-D.dikshit-grow-bmp-rd-scoped-rib-stats."; + } + + sx:augment-structure "/tm:message/tm:telemetry-message-metadata" { + description + "Augments telemetry-message-metadata with BMP-specific + provenance metadata."; + container bmp-session { + when "../session-protocol = 'bmp-tm:bmp'"; + description + "BMP-specific provenance for this telemetry message."; + leaf monitoring-station-id { + type string; + description + "Identifier of the BMP monitoring station configuration + (RFC 7854 Section 3.1; see also the 'monitoring-station' + list in I-D.ietf-grow-bmp-yang) under which this message + was collected."; + } + leaf message-type { + type identityref { + base bmp-message-type; + } + mandatory true; + description + "BMP message type of the payload carried in this + telemetry message."; + reference "RFC 7854 Section 4."; + } + container peer-header { + description + "Fields from the BMP Per-Peer Header, RFC 7854 + Section 4.2, relevant to routing/filtering telemetry + messages without payload inspection."; + leaf peer-type { + type identityref { + base bmp:peer-type; + } + description "BMP peer type."; + } + leaf peer-distinguisher { + type rt-types:route-distinguisher; + description + "Route Distinguisher, present when the peer type + indicates an L3VPN peer."; + } + leaf peer-address { + type inet:ip-address; + description "BMP peer IP address."; + } + leaf peer-as { + type inet:as-number; + description "BMP peer Autonomous System number."; + } + leaf peer-bgp-id { + type yang:dotted-quad; + description "BMP peer BGP Identifier."; + } + } + container route-monitoring-scope { + description + "Scope of a Route Monitoring or Statistics Report + message, mirroring the network-instance / RIB-type / + address-family hierarchy of I-D.ietf-grow-bmp-yang."; + leaf network-instance { + type string; + description "Network instance name."; + } + leaf rib-type { + type identityref { + base bmp:afi-safi-type; + } + description + "Address family of the RIB this message concerns."; + } + leaf route-distinguisher { + type rt-types:route-distinguisher; + description + "Route Distinguisher, when this message is scoped to + a specific VRF/EVI/MVPN instance (see + I-D.saum-grow-bmp-afi-safi-evpn and + I-D.dikshit-grow-bmp-rd-scoped-rib-stats)."; + } + } + leaf stat-extension { + type identityref { + base bmp-stat-extension; + } + description + "For Statistics Report messages, identifies which Stat + Type registry/extension the payload's Stat Data belongs + to, without requiring payload inspection."; + } + } + } +} diff --git a/experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-02-27.yang b/experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-07-23.yang similarity index 64% rename from experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-02-27.yang rename to experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-07-23.yang index 8b169419b..8a242e3dd 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-02-27.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-fgotn-topology@2026-07-23.yang @@ -24,12 +24,6 @@ module ietf-fgotn-topology { reference "RFC YYYY: A YANG Data Model for Layer 1 Types"; } - import ietf-fgotn-types { - prefix fgotn-types; - reference - "RFC XXXX: YANG Data Models for fine grain Optical Transport - Network"; - } /* Note: The RFC Editor will replace YYYY with the number assigned to the RFC once draft-ietf-ccamp-layer1-types becomes an RFC.*/ @@ -85,7 +79,7 @@ module ietf-fgotn-topology { // RFC Ed.: update the date below with the date of RFC publication // and remove this note. - revision 2026-02-27 { + revision 2026-07-23 { description "initial version"; reference @@ -110,81 +104,13 @@ module ietf-fgotn-topology { of Evolving G.709 Optical Transport Networks"; } - augment "/nw:networks/nw:network/nt:link/tet:te" - + "/tet:te-link-attributes/tet:max-link-bandwidth" - + "/tet:te-bandwidth/otnt:otn-bandwidth/otnt:odulist" { - description - "specific augmentation of fgOTN link on maximum link - bandwidth"; - leaf fgotn-bandwidth { - when 'derived-from-or-self(../otnt:odu-type,' - + '"fgotn-types:fgODUflex")' { - description - "Applicable when odu-type is fgODUflex."; - } - type uint16; - units "megabits per second"; - description - "It is used to indicate how much of the bandwidth has been - allocated for the usage of fgOTN."; - } - } - - augment "/nw:networks/nw:network/nt:link/tet:te" - + "/tet:te-link-attributes/tet:unreserved-bandwidth" - + "/tet:te-bandwidth/otnt:otn-bandwidth/otnt:odulist" { - description - "specific augmentation of fgOTN link on unreserved link - bandwidth"; - leaf fgotn-bandwidth { - when 'derived-from-or-self(../otnt:odu-type,' - + '"fgotn-types:fgODUflex")' { - description - "Applicable when odu-type is fgODUflex."; - } - type uint16; - units "megabits per second"; - description - "The unreserved bandwidth of fgOTN before the server ODUk - is set up"; - } - } - - augment "/nw:networks/nw:network/nt:link/tet:te" - + "/tet:te-link-attributes/tet:unreserved-bandwidth" - + "/tet:te-bandwidth/otnt:otn-bandwidth" { - description - "specific augmentation of fgOTN link on unreserved link - bandwidth"; - list fgotnlist { - key "odu-type odu-ts-number"; - description - "This structure is used to describe the unsreserved - bandwidth of fgOTN in the server ODUk"; - leaf odu-type { - type identityref { - base l1-types:odu-type; - } - description - "The granularity of server ODUk"; - } - leaf odu-ts-number { - type fgotnt:ts-list; - description - "The index of server ODUk channel"; - } - leaf fgotn-bandwidth { - type uint16; - units "megabits per second"; - description - "The unreserved bandwidth of fgOTN in this server ODUk"; - } - } - } - augment "/nw:networks/nw:network/nt:link/tet:te" + "/tet:te-link-attributes/tet:label-restrictions" + "/tet:label-restriction" { + when "./otnt:otn-label-range/otnt:range-type = 'trib-slot'" { + description + "Valid only when range-type represented by trib-slot."; + } description "specific augmentation of fgOTN label"; list fgts-range { diff --git a/experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2025-10-20.yang b/experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2026-08-04.yang similarity index 98% rename from experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2025-10-20.yang rename to experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2026-08-04.yang index c93d30a63..17e607252 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2025-10-20.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-i2nsf-analytics-interface@2026-08-04.yang @@ -41,7 +41,7 @@ contact "; description - "This module is a YANG module for Analytics Interface. + "This module is a YANG module for I2NSF Analytics Interface. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', @@ -50,7 +50,7 @@ description (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. - Copyright (c) 2025 IETF Trust and the persons identified as + Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or @@ -66,10 +66,11 @@ description // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. -revision "2025-10-20" { +revision "2026-08-04" { description "Initial revision."; reference - "RFC XXXX: I2NSF Analytics Interface YANG Data Model"; + "RFC XXXX: A YANG Data Model for Analytics Interface in + Interface to Network Security Functions (I2NSF)"; // RFC Ed.: replace XXXX with an actual RFC number and remove // this note. diff --git a/experimental/ietf-extracted-YANG-modules/ietf-ipv6-nd@2026-04-20.yang b/experimental/ietf-extracted-YANG-modules/ietf-ipv6-nd@2026-04-20.yang index 908ed5d34..0d27c5d59 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-ipv6-nd@2026-04-20.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-ipv6-nd@2026-04-20.yang @@ -20,10 +20,11 @@ module ietf-ipv6-nd { } organization - "IETF IPv6 Maintenance Working Group (6man)"; + "IETF 6MAN (IPv6 Maintenance) Working Group"; + contact "WG Web: - WG List: + WG List: 6MAN Author: Fan Zhang @@ -33,6 +34,7 @@ module ietf-ipv6-nd { Author: Jiayuan Hu "; + description "This YANG module defines a YANG data model to configure and manage IPv6 Neighbor Discovery (ND) and related functions, @@ -40,27 +42,28 @@ module ietf-ipv6-nd { Advertisement, Neighbor Unreachability Detection (NUD), Duplicate Address Detection (DAD), and Enhanced DAD. - The model is based on YANG 1.1 as defined in RFC 7950 and - conforms to Network Management Datastore Architecture (NMDA) - as defined in RFC 8342. - - Copyright (c) 2026 IETF Trust and the persons identified as - authors of the code. All rights reserved. + Copyright (c) 2026 IETF Trust and the persons + identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or - without modification, is permitted pursuant to, and subject to - the license terms contained in, the Revised BSD License set - forth in Section 4.c of the IETF Trust's Legal Provisions + without modification, is permitted pursuant to, and subject + to the license terms contained in, the Revised BSD License + set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). - This version of this YANG module is part of RFC XXXX - (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself - for full legal notices."; - reference - "RFC4861: Neighbor Discovery for IP version 6 (IPv6) - RFC4862: IPv6 Stateless Address Autoconfiguration - RFC7527: Enhanced Duplicate Address Detection"; + All revisions of IETF and IANA published modules can be found + at the YANG Parameters registry group + (https://www.iana.org/assignments/yang-parameters). + + This version of this YANG module is part of RFC XXXX; see + the RFC itself for full legal notices."; + + // RFC Ed: replace '2026-04-20' with the module publication date + // the format is (YYYY-MM-DD) + + // replace XXXX with actual RFC number and remove + // this note revision 2026-04-20 { description diff --git a/experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-06-11.yang b/experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-07-29.yang similarity index 90% rename from experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-06-11.yang rename to experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-07-29.yang index 1e3af5877..34dffcf46 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-06-11.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-on-path-telemetry@2026-07-29.yang @@ -9,6 +9,7 @@ module ietf-on-path-telemetry { "RFC 8519: YANG Data Model for Network Access Control Lists (ACLs)"; } + import ietf-interfaces { prefix if; reference @@ -18,7 +19,7 @@ module ietf-on-path-telemetry { import ietf-yang-types { prefix yang; reference - "Section 3 of RFC 6991"; + "Section 3 of RFC 9911"; } import ietf-lime-time-types { @@ -77,7 +78,7 @@ module ietf-on-path-telemetry { (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; - revision 2026-06-11 { + revision 2026-07-29 { description "First revision."; reference "RFC XXXX: A YANG Data Model for On-path Telemetry"; } @@ -88,7 +89,7 @@ module ietf-on-path-telemetry { feature altmark { description - "This feature indicated that the Alternate-Marking Method is + "This feature indicates that the Alternate-Marking Method is supported."; reference "RFC 9341: Alternate-Marking Method; @@ -102,7 +103,7 @@ module ietf-on-path-telemetry { feature pathdelay { description - "This feature indicated that the Path Delay is + "This feature indicates that the Path Delay is supported."; reference "RFC 9951: Export of Delay Performance Metrics in IPFIX"; @@ -110,43 +111,42 @@ module ietf-on-path-telemetry { feature ioam { description - "This feature indicated that the Alternate-Marking Method is - supported."; + "This feature indicates that the IOAM Method is supported."; reference "RFC 9197: Data Fields for In-situ OAM"; } feature incremental-trace { description - "This feature indicated that the incremental tracing option is + "This feature indicates that the incremental tracing option is supported."; reference "RFC 9197: Data Fields for In-situ OAM"; } feature preallocated-trace { description - "This feature indicated that the preallocated tracing option is + "This feature indicates that the preallocated tracing option is supported."; reference "RFC 9197: Data Fields for In-situ OAM"; } feature direct-export { description - "This feature indicated that the direct export option is + "This feature indicates that the direct export option is supported."; reference "RFC 9326: In-situ OAM Direct Exporting"; } feature proof-of-transit { description - "This feature indicated that the proof of transit option is + "This feature indicates that the proof of transit option is supported"; reference "RFC 9197: Data Fields for In-situ OAM"; } feature edge-to-edge { description - "This feature indicated that the edge-to-edge option is + "This feature indicates that the edge-to-edge option is supported."; reference "RFC 9197: Data Fields for In-situ OAM"; } @@ -201,6 +201,7 @@ module ietf-on-path-telemetry { "RFC 9714: Application of the Alternate Marking Method to the MPLS Label Stack"; } + identity nsh { base protocol; description @@ -236,17 +237,17 @@ module ietf-on-path-telemetry { enum "ingress" { value 1; description - "Ingress of an AltMark flow."; + "Ingress of a flow."; } enum "transit" { value 2; description - "Transit of an AltMark flow."; + "Transit of a flow."; } enum "egress" { value 3; description - "Egress of an AltMark flow."; + "Egress of a flow."; } } description @@ -363,28 +364,28 @@ module ietf-on-path-telemetry { type yang:counter64; description "Total inbound packets of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; } leaf out-traffic-pkts { type yang:counter64; description "Total outbound packets of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; } leaf in-traffic-bytes { type uint64; description "Total inbound bytes of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; } leaf out-traffic-bytes { type uint64; description "Total outbound bytes of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; } } @@ -410,7 +411,7 @@ module ietf-on-path-telemetry { container in-pkts-timestamps { description "The list of timestamps of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; leaf in-pkt-timestamp { type yang:date-and-time; @@ -426,11 +427,10 @@ module ietf-on-path-telemetry { delay measurements"; } } - container out-pkts-timestamps { description "The list of timestamps of the period according to RFC 9341 - and RFC9342"; + and RFC 9342"; leaf out-pkt-timestamp { type yang:date-and-time; @@ -475,7 +475,6 @@ module ietf-on-path-telemetry { "sum of the path delay as per RFC 9951"; } } - grouping ioam-incremental-tracing-data-list { description "A grouping for incremental tracing data."; @@ -565,15 +564,6 @@ module ietf-on-path-telemetry { description "This is a reference to the Interface name."; } - container filter { - uses telemetry-filter; - description - "The filter which is used to indicate the flow where - the On-path Telemetry is applied."; - } - - uses telemetry-dir-prot; - container profiles { description "Contains On-path Telemetry profiles."; @@ -592,6 +582,15 @@ module ietf-on-path-telemetry { "Unique identifier for each AltMark profile."; } + container filter { + uses telemetry-filter; + description + "The filter which is used to indicate the flow where + the On-path Telemetry is applied."; + } + + uses telemetry-dir-prot; + uses altmark-telemetry; container altmark-loss-measurement { @@ -624,6 +623,15 @@ module ietf-on-path-telemetry { "Unique identifier for each path delay profile."; } + container filter { + uses telemetry-filter; + description + "The filter which is used to indicate the flow where + the On-path Telemetry is applied."; + } + + uses telemetry-dir-prot; + uses path-delay-metrics; } @@ -631,16 +639,25 @@ module ietf-on-path-telemetry { if-feature ioam; key "ioam-profile-name"; description - "It describes the list of the path delay profiles - configured on the node"; + "It describes the list of the IOAM profiles configured + on the node"; leaf ioam-profile-name { type string{ length "1..300"; } description - "Unique identifier for each path delay profile."; + "Unique identifier for each IOAM profile."; + } + + container filter { + uses telemetry-filter; + description + "The filter which is used to indicate the flow where + the On-path Telemetry is applied."; } + uses telemetry-dir-prot; + container ioam-incremental-tracing { if-feature incremental-trace; presence "Enables incremental tracing option."; diff --git a/experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-05-19.yang b/experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-07-29.yang similarity index 99% rename from experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-05-19.yang rename to experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-07-29.yang index a44106f73..857096033 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-05-19.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-otn-path-computation@2026-07-29.yang @@ -55,7 +55,7 @@ module ietf-otn-path-computation { This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2026-05-19 { + revision 2026-07-29 { description "Initial version."; reference @@ -250,7 +250,7 @@ module ietf-otn-path-computation { + "te-pc:label-restrictions/te-pc:label-restriction/" + "te-pc:label-step/te-pc:technology" { description - "Augment TE label range end for the egress segment + "Augment TE label range step for the egress segment of the requested path."; case otn { uses l1-types:otn-label-step; diff --git a/experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2025-06-04.yang b/experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2026-07-29.yang similarity index 94% rename from experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2025-06-04.yang rename to experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2026-07-29.yang index e1712e15b..0c61d8598 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2025-06-04.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-udp-notif-transport@2026-07-29.yang @@ -39,14 +39,14 @@ module ietf-udp-notif-transport { Pierre Francois Alex Huang Feng - + Paolo Lucente "; description "Defines a model for configuring UDP-Notif as a transport for configured subscriptions [RFC8639]. - Copyright (c) 2025 IETF Trust and the persons identified as + Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or @@ -66,7 +66,7 @@ module ietf-udp-notif-transport { described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here."; - revision 2025-06-04 { + revision 2026-07-29 { description "Initial revision"; reference @@ -87,8 +87,8 @@ module ietf-udp-notif-transport { feature dtls { description - "Indicates that DTLS encryption of UDP - packets is supported. UDP-Notif mandates that, in + "Indicates that DTLS encryption of UDP-Notif messages + is supported. UDP-Notif mandates that, in unsecured networks, DTLS 1.2 or later MUST be supported, and DTLS 1.3 SHOULD be supported."; reference @@ -106,7 +106,7 @@ module ietf-udp-notif-transport { base sn:configurable-encoding; description "UDP-Notif is used as transport for notification messages - and state change notifications."; + and state change notifications."; } identity encode-cbor { diff --git a/experimental/ietf-extracted-YANG-modules/ietf-voucher-request@2025-12-18.yang b/experimental/ietf-extracted-YANG-modules/ietf-voucher-request@2025-12-18.yang index 73740634b..94ecb75df 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-voucher-request@2025-12-18.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-voucher-request@2025-12-18.yang @@ -65,10 +65,16 @@ module ietf-voucher-request { // RFCEDITOR: please replace XXXX in this entire code fragment // with the RFC number assigned and remove this notice. + // Please also update references in the description {{}} to the + // RFC numbers for the documents. revision 2025-12-18 { description - "Updates and additions described by RFC XXXX"; + "Updates and additions described by RFC XXXX, + includes mechanism for constrained BRSKI + {{I-D.ietf-anima-constrained-voucher}}, + Pledge in Responder Mode {{I-D.ietf-anima-brski-prm}}, + and BRSKI-CLOUD {{I-D.ietf-anima-brski-cloud}}"; reference "RFC XXXX: A Voucher Artifact for Bootstrapping Protocols"; } diff --git a/experimental/ietf-extracted-YANG-modules/ietf-voucher@2025-12-18.yang b/experimental/ietf-extracted-YANG-modules/ietf-voucher@2025-12-18.yang index 5f36e1666..8661ffaa5 100644 --- a/experimental/ietf-extracted-YANG-modules/ietf-voucher@2025-12-18.yang +++ b/experimental/ietf-extracted-YANG-modules/ietf-voucher@2025-12-18.yang @@ -63,12 +63,18 @@ module ietf-voucher { // RFCEDITOR: please replace XXXX in this entire code fragment // with the RFC number assigned and remove this notice. + // Please also update references in the description {{}} to the + // RFC numbers for the documents. revision 2025-12-18 { description - "Updates and additions described by RFC XXXX"; + "Updates and additions described by RFC XXXX, + includes mechanism for constrained BRSKI + {{I-D.ietf-anima-constrained-voucher}}, + Pledge in Responder Mode {{I-D.ietf-anima-brski-prm}}, + and BRSKI-CLOUD {{I-D.ietf-anima-brski-cloud}}"; reference - "RFC XXXX: A Voucher Profile for Bootstrapping Protocols"; + "RFC XXXX: A Voucher Artifact for Bootstrapping Protocols"; } revision 2018-05-09 { description @@ -99,7 +105,7 @@ module ietf-voucher { extensions are described in an RFC, while vendor proprietary ones are not."; } - leaf manufacturer-private { + leaf manufacturer-proprietary { type binary; description "In CBOR serialization, this is a CBOR bstr containing any diff --git a/standard/iana/yang-parameters.xml b/standard/iana/yang-parameters.xml index e58ac4c43..b0e51ae39 100644 --- a/standard/iana/yang-parameters.xml +++ b/standard/iana/yang-parameters.xml @@ -4,7 +4,7 @@ YANG Parameters 2010-06-10 - 2026-07-13 + 2026-07-31 YANG Module Names @@ -139,6 +139,58 @@ Codes", and "DOTS Attack Status Codes" registr Interface types must not be directly added to the iana-if-type YANG module. They must instead be added to the Interface Types (ifType) registry. + + iana-igp-algo-types + Y + + urn:ietf:params:xml:ns:yang:iana-igp-algo-types + iana-algo-types + + + + 's module file will be posted upon the document's publication as an RFC. + New values must not be directly added to the "iana-igp-algo-types" YANG module. They must instead be added to the IGP Algorithm Types registry. + + + + iana-igp-link-attr-apps + Y + + urn:ietf:params:xml:ns:yang:iana-igp-link-attr-apps + iana-link-attr-apps + + + + 's module file will be posted upon the document's publication as an RFC. + New values must not be directly added to the "iana-igp-link-attr-apps" YANG module. They must instead be added to the Link Attribute Application Identifiers registry. + + + + iana-igp-metric-types + Y + + urn:ietf:params:xml:ns:yang:iana-igp-metric-types + iana-metric-types + + + + 's module file will be posted upon the document's publication as an RFC. + New values must not be directly added to the "iana-igp-metric-types" YANG module. They must instead be added to the IGP Metric-Type registry. + + + + iana-ioam-integrity-protection-methods + Y + + urn:ietf:params:xml:ns:yang:iana-ioam-integrity-protection-methods + iana-ioam-ipm + + + + 's module file will be posted upon the document's publication as an RFC. + 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. + + iana-ipv6-ext-types Y @@ -1136,6 +1188,16 @@ and Subsequent Address Family Identi + + ietf-ioam-integrity + N + + urn:ietf:params:xml:ns:yang:ietf-ioam-integrity + ioam-int + + + 's module file will be posted upon the document's publication as an RFC. + ietf-ip N @@ -1246,6 +1308,26 @@ and Subsequent Address Family Identi + + ietf-isis-flex-algo + N + + urn:ietf:params:xml:ns:yang:ietf-isis-flex-algo + isis-flex-algo + + + 's module file will be posted upon the document's publication as an RFC. + + + ietf-isis-link-attr + N + + urn:ietf:params:xml:ns:yang:ietf-isis-link-attr + isis-link-attr + + + 's module file will be posted upon the document's publication as an RFC. + ietf-isis-reverse-metric N @@ -1856,6 +1938,16 @@ and Subsequent Address Family Identi + + ietf-ospf-flex-algo + N + + urn:ietf:params:xml:ns:yang:ietf-ospf-flex-algo + ospf-flex-algo + + + 's module file will be posted upon the document's publication as an RFC. + ietf-ospf-functional-capability N @@ -1866,6 +1958,16 @@ and Subsequent Address Family Identi 's module file will be posted upon the document's publication as an RFC. + + ietf-ospf-link-attr + N + + urn:ietf:params:xml:ns:yang:ietf-ospf-link-attr + ospf-link-attr + + + 's module file will be posted upon the document's publication as an RFC. + ietf-ospf-sr-mpls N diff --git a/standard/ietf/RFC/ietf-sip-auto-peering.yang b/standard/ietf/RFC/ietf-sip-auto-peering.yang new file mode 120000 index 000000000..40ca2c3e1 --- /dev/null +++ b/standard/ietf/RFC/ietf-sip-auto-peering.yang @@ -0,0 +1 @@ +ietf-sip-auto-peering@2026-06-15.yang \ No newline at end of file diff --git a/standard/ietf/RFC/ietf-sip-auto-peering@2026-06-15.yang b/standard/ietf/RFC/ietf-sip-auto-peering@2026-06-15.yang new file mode 100644 index 000000000..444baf750 --- /dev/null +++ b/standard/ietf/RFC/ietf-sip-auto-peering@2026-06-15.yang @@ -0,0 +1,933 @@ +module ietf-sip-auto-peering { + yang-version 1.1; + namespace "urn:ietf:params:xml:ns:yang:ietf-sip-auto-peering"; + prefix sipap; + + import ietf-inet-types { + prefix inet; + reference + "RFC 9911: Common YANG Data Types."; + } + import ietf-yang-types { + prefix yang; + reference + "RFC 9911: Common YANG Data Types."; + } + import iana-crypt-hash { + prefix ianach; + reference + "https://www.iana.org/assignments/iana-crypt-hash/"; + } + import ietf-tls-common { + prefix tlscmn; + reference + "RFC 9645: YANG Groupings for TLS Clients and TLS Servers."; + } + import iana-sip-option-tags { + prefix iana-sip-option-tags; + reference + "https://www.iana.org/assignments/iana-sip-option-tags/"; + } + + organization + "IETF ASAP (Automatic SIP trunking And Peering) Working Group"; + contact + "WG Web: + WG List: + + Editor: Kaustubh Inamdar + + + Editor: Sreekanth Narayanan + + + Editor: Cullen Jennings + "; + description + "Data model for encoding SIP service provider capability set. + + This YANG module defines a read-only data model intended for + exchanging SIP service provider capabilities with enterprise + networks. The data is published by service providers and + consumed by enterprises via an out-of-band interface. + + This module does NOT provide configuration capabilities; it + serves purely as a standardized format for capability exchange. + Service providers generate and host capability documents based + on this schema, which enterprises retrieve and use to configure + their SIP equipment. + + 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 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. + + Copyright (c) 2026 IETF Trust and the persons identified as + authors of the code. All rights reserved. + + Redistribution and use in source and binary forms, with or + without modification, is permitted pursuant to, and subject to + the license terms contained in, the Revised BSD License set + forth in Section 4.c of the IETF Trust's Legal Provisions + Relating to IETF Documents + (https://trustee.ietf.org/license-info). + + All revisions of IETF and IANA published modules can be found + at the YANG Parameters registry group + (https://www.iana.org/assignments/yang-parameters). + + This version of this YANG module is part of RFC 10006; see the + RFC itself for full legal notices."; + + revision 2026-06-15 { + description + "Initial version"; + reference + "RFC 10006: Automatic SIP Trunking and Peering"; + } + + identity capability-doc-variant { + description + "Base for capability document variants."; + } + + identity v1-0 { + base capability-doc-variant; + description + "Variant 1.0 of the capability set document."; + } + + identity sip-transport-protocol { + description + "Base for transport protocols used to send SIP requests + across."; + } + + identity udp { + base sip-transport-protocol; + description + "UDP used for SIP requests and responses."; + } + + identity tcp { + base sip-transport-protocol; + description + "TCP used for SIP requests and responses."; + } + + identity codec-variant { + description + "Base for variants of codec supported by the service + provider."; + } + + identity pcmu { + base codec-variant; + description + "PCMU (G.711 μ-law) audio codec."; + } + + identity pcma { + base codec-variant; + description + "PCMA (G.711 A-law) audio codec."; + } + + identity opus { + base codec-variant; + description + "Opus audio codec."; + reference + "RFC 6716: Definition of the Opus Audio Codec."; + } + + identity g722 { + base codec-variant; + description + "G.722 audio codec."; + } + + identity g729 { + base codec-variant; + description + "G.729 codec."; + } + + grouping entity { + description + "Grouping that provides a reusable list named 'entity', with + each entry containing a host and a port."; + leaf host { + type union { + type inet:ip-address; + type inet:domain-name; + } + description + "IP address or host name of the entity."; + } + leaf port { + type inet:port-number; + description + "Entity's port number."; + } + } + + container sip-auto-peering { + config false; + description + "Root container for SIP service provider capability data. This + container holds read-only operational data that represents the + capabilities and requirements of a SIP service provider. + Enterprise networks retrieve this data to automatically + configure their SIP trunking parameters."; + leaf variant { + type identityref { + base capability-doc-variant; + } + mandatory true; + description + "A node that identifies the version number of the capability + set document. RFC 10006 defines the parameters for + variant 1.0; future specifications might define a richer + parameter set, in which case the variant must be changed + to 2.0, 3.0, and so on. Future extensions to the + capability set document MUST also ensure that the + corresponding YANG module is defined."; + reference + "RFC 10006: Automatic SIP Trunking and Peering"; + } + container revision { + description + "A container that encapsulates information regarding the + availability of a new version of the capability set document + for the enterprise."; + leaf not-before { + type yang:date-and-time; + mandatory true; + description + "A node that identifies the absolute UTC time at which the + parameters in this capability set document are activated + or considered valid. This node has been set to mandatory + as it is the service provider's responsibility to inform + when new peering settings take effect. Without being + aware of a start time, the enterprise network will + experience failures."; + } + leaf location { + type inet:uri; + mandatory true; + description + "A node that identifies the URL of a new revision of the + service provider capability set document. Without this + URL, an enterprise network would not be aware of changes + that have occurred in the service provider network."; + } + } + container transport-info { + description + "A container that encapsulates transport characteristics of + SIP sessions between enterprise and service provider + networks."; + leaf-list transport { + type identityref { + base sip-transport-protocol; + } + min-elements 1; + description + "A list that enumerates the different transport-layer + protocols supported by the SIP service provider. Valid + transport-layer protocols include UDP, TCP, and TLS."; + } + list registrar { + key "host port"; + uses entity; + max-elements 3; + description + "A list that specifies the transport address of one or more + registrar servers in the service provider network. The + transport address of the registrar can be provided using a + combination of a valid IP address and port number, a + subdomain of the SIP service provider network, or the + fully qualified domain name (FQDN) of the SIP service + provider network. If the transport address of a registrar + is specified using either a subdomain or a FQDN, the DNS + element must be populated with one or more valid DNS + server IP addresses."; + } + list realm { + key "name"; + description + "A container that encapsulates the set of realms or + protection domains the SIP service provider is responsible + for."; + leaf name { + type string; + description + "A node specifying the SIP service provider realm or + protection domain. This node is encoded as a string; + the value of this node must be identical to the value of + the 'realm' parameter in a WWW-Authenticate header field + that the SIP service provider might send in response to + requests that do not contain a valid Authorization + header field."; + } + leaf username { + type string; + description + "A node that encodes the username for the given realm. + The username is one of many inputs used by the + enterprise network in generating the response parameter + of the Authorization header field."; + } + leaf password { + type ianach:crypt-hash; + description + "A node that encodes the password for the given realm. + The password is one of many inputs used by the + enterprise network in generating the response parameter + of the Authorization header field. The password is + stored as a cryptographic hash."; + } + } + list call-control { + key "host port"; + uses entity; + max-elements 3; + description + "A list that specifies the transport address of the call + server(s) in the service provider network. The enterprise + network must use an applicable transport protocol in + conjunction with the call control server(s) transport + address when transmitting call setup requests. The + transport address of a call server(s) within the service + provider network can be specified using a combination of + a valid IP address and port number, a subdomain of the + SIP service provider network, or a FQDN of the SIP service + provider network. If the transport address of a call + control server(s) is specified using either a subdomain or + a FQDN, the DNS element must be populated with one or more + valid DNS server IP addresses. The transport address + specified in this element can also serve as the target for + non-call requests such as SIP OPTIONS."; + } + leaf-list dns-server { + type inet:ip-address; + max-elements 2; + description + "A list that encodes the IP address of one or more DNS + servers hosted by the SIP service provider. If the + enterprise network is unaware of the IP address, port + number, and transport protocol of servers within the + service provider network (for example, the registrar + and call control server), it must use DNS NAPTR and + SRV. Alternatively, if the enterprise network has the + FQDN of the SIP service provider network, it must use + DNS to resolve the said FQDN to an IP address. + The dns element encodes the IP address of one or more + DNS servers hosted in the service provider network. + If, however, either the registrar or call-control lists + or both are populated with a valid IP address and port + pair, the dns element can be omitted."; + } + list outbound-proxy { + key "host port"; + uses entity; + description + "A list that specifies the transport address of one or more + outbound proxies. The transport address can be specified + by using a combination of an IP address and a port number, + a subdomain of the SIP service provider network, or a FQDN + and port number of the SIP service provider network. + If the outbound-proxy list is populated with a valid + transport address, it represents the default destination + for all outbound SIP requests; therefore, the registrar + and call-control lists can be omitted."; + } + } + container call-spec { + description + "A container that encapsulates information about call + specifications, restrictions, and additional handling + criteria for SIP calls between the enterprise and service + provider network."; + leaf early-media { + type boolean; + description + "A node that specifies whether the service provider network + is expected to deliver in-band announcements/tones before + call connect. The P-Early-Media header field can be used + to indicate pre-connect delivery of tones and + announcements on a per-call basis. However, given that + signaling and media could traverse a large number of + intermediaries with varying capabilities (in terms of + handling of the P-Early-Media header field) within the + enterprise, such devices can be appropriately configured + for media cut through if it is known beforehand that + early media is expected for some or all of the outbound + calls. This element is a boolean type, where a value of + true signifies that the service provider is capable of + early media. A value of false signifies that the service + provider is not expected to generate early media."; + } + leaf signaling-forking { + type boolean; + description + "A node that specifies whether outbound call requests from + the enterprise might be forked on the service provider + network that MAY lead to multiple early dialogs. This + information would be useful to the enterprise network in + appropriately handling multiple early dialogs reliably + and in enforcing local policy. This element is a boolean + type, where a value of true signifies that the service + provider network can potentially fork outbound call + requests from the enterprise. A value of false indicates + that the service provider will not fork outbound call + requests."; + } + leaf-list supported-method { + type enumeration { + enum invite { + description + "Initiate a dialog or session."; + } + enum ack { + description + "Acknowledge final response to INVITE."; + } + enum bye { + description + "Terminate a dialog or session."; + } + enum cancel { + description + "Cancel a pending request."; + } + enum register { + description + "Register contact information."; + } + enum options { + description + "Query capabilities of a server."; + } + enum prack { + description + "Provisional acknowledgement."; + } + enum subscribe { + description + "Subscribe to an event."; + } + enum notify { + description + "Notify subscriber of an event."; + } + enum publish { + description + "Publish an event state."; + } + enum info { + description + "Send mid-session information."; + } + enum refer { + description + "Refer recipient to a third party."; + } + enum message { + description + "Instant message transport."; + } + enum update { + description + "Update session parameters within a dialog."; + } + } + description + "A list that specifies the various SIP methods supported by + the SIP service provider. The list of supported methods + help to appropriately configure various devices within the + enterprise network. For example, if the service provider + enumerates support for the OPTIONS method, the enterprise + network could periodically send OPTIONS requests as a + keep-alive mechanism."; + } + container caller-id { + description + "A container that encodes the preferences of SIP service + providers in terms of calling number presentation by the + enterprise network. Certain ITSPs require that the + calling number be formatted in E.164, whereas others place + no such restrictions. Additionally, some ITSPs require + that the calling number be included in a specific SIP + header field, for example, the P-Asserted-ID header field + or the From header field, whereas others place no + restrictions on the specific SIP header field used to + convey the calling number."; + leaf e164-format { + type boolean; + description + "A node that indicates whether the service provider + requires the enterprise network to normalize the calling + number into E.164 format. A value of true mandates the + enterprise network to format calling numbers to E.164 + format, while a value of false leaves the formatting + of the calling number up to the enterprise network."; + } + leaf preferred-method { + type enumeration { + enum p-asserted-identity { + description + "Use the P-Asserted-Identity header to determine + remote party identity."; + } + enum from { + description + "Use the From header to determine remote party + identity."; + } + } + description + "A node that specifies which SIP header MUST be used + by the enterprise network to communicate caller + information. The value of this node is a string that + contains the name of the SIP header required to + carry caller information."; + } + } + list number-range { + key "index"; + description + "A list that specifies the Direct Inward Dial (DID) number + range allocated to the enterprise network by the SIP + service provider. The DID number ranges allocated by the + service provider to the enterprise network might be a + contiguous or a non-contiguous block. The number ranges + allocated to an enterprise can be communicated as a value + or as a reference. For large enterprise networks, the + size of the DID range might run into several hundred + numbers. For situations in which the enterprise is + allocated a large DID number range or a non-contiguous + number range, it is RECOMMENDED that the SIP service + provider communicate this information by reference, that + is, through a URL. The enterprise network is required to + dereference this URL in order to obtain the DID number + ranges allocated by the SIP service provider."; + leaf index { + type uint16; + description + "Index for the number ranges."; + } + leaf type { + type enumeration { + enum range { + description + "Numbers specified as a range."; + } + enum collection { + description + "Numbers specified in the form of a collection."; + } + enum reference { + description + "Number range available at a URL."; + } + } + description + "A node that indicates whether the DID range + is communicated by value or by reference. It can have a + value of 'range', 'collection', or 'reference'."; + } + leaf count { + when "../type = 'range' or ../type = 'collection'"; + type uint16; + description + "Indicates the size of the DID number range. This leaf + MUST NOT be included when using the 'reference' + type."; + } + leaf-list value { + type string; + description + "A list that encapsulates the DID number range allocated + to the enterprise. If the num-ranges 'type' is set to + 'range' or 'collection', the 'count' node MUST have a + valid, non-zero, positive integer. If the number-range + 'type' value is set to 'range', then the number in this + field represents the first phone number of a DID range + allocated to the enterprise. The value of subsequent + numbers of the given DID range are obtained by adding + one to the value of this field. The number of times we + need to add one is indicated by the 'count' field."; + } + } + } + container media { + description + "A container that is used to collectively encapsulate the + characteristics of UDP-based audio streams. A future + extension to RFC 10006 may extend the media container + to describe other media types. The media container is + also used to encapsulate basic information about + Real-Time Transport Protocol (RTP) and Real-Time + Transport Control Protocol (RTCP) from the perspective + of the service provider network. At the time of writing + RFC 10006, video media streams are not exchanged + between enterprise and service provider SIP networks."; + reference + "RFC 10006: Automatic SIP Trunking and Peering"; + list media-type-audio { + key "media-format"; + description + "A list encoding the various audio media formats + supported by the SIP service provider. The relative + ordering of different media formats in the list indicates + preference from the perspective of the service provider. + Each element in the list begins with the encoding name + of the media format, which is the same encoding name as + used in the 'RTP/AVP' and 'RTP/SAVP' profiles. The + encoding name is followed by the sampling rate for the + encoding and the packetization time. Additionally, any + other required and optional parameters for the given media + format as specified when the media format is registered + are described the 'param' field. + Given that the parameters of media formats can vary from + one communication session to another (e.g., across two + separate communication sessions), the packetization + time (ptime) used for the PCMU media format might vary + from 10 to 30 ms, and the parameters included in the + format element must be the ones that are expected to be + invariant from the perspective of the service provider. + Providing information about supported media formats and + their respective parameters allows enterprise networks to + configure the media plane characteristics of various + devices such as endpoints and middleboxes."; + reference + "RFC 4855: Media Type Registration of RTP Payload Formats"; + leaf media-format { + type identityref { + base codec-variant; + } + description + "The audio media format."; + } + leaf rate { + type uint16; + units "Hz"; + description + "Sampling rate in Hz."; + } + leaf ptime { + type uint8; + units "milliseconds"; + description + "Packetization time in milliseconds."; + } + leaf parameter { + type string; + description + "Optional parameter for additional media details + regarding the encoding."; + } + } + container fax { + description + "A container that encapsulates the fax + protocol(s) supported by the SIP service provider. The + fax container encloses a list (protocol) that enumerates + whether the service provider supports T.38 relay, + protocol-based fax passthrough, or both. The relative + ordering of nodes within the lists indicates preference."; + leaf-list protocol { + type enumeration { + enum pass-through { + description + "Protocol-based fax passthrough."; + } + enum t38 { + description + "T.38 relay."; + } + } + max-elements 2; + description + "List indicating the different fax protocols supported by + the service provider."; + } + } + container rtp { + description + "A container that encapsulates generic characteristics of + RTP sessions between the enterprise and service provider + network."; + leaf rtp-trigger { + type boolean; + description + "A node indicating whether the SIP service + provider network always expects the enterprise network + to send the first RTP packet for an established + communication session. This information is useful in + scenarios such as 'hairpinned' calls, in which the + caller and callee are on the service provider network + and, because of sub-optimal media routing, an enterprise + device such as an SBC is retained in the media path. + Based on the encoding of this node, it is possible to + configure enterprise devices such as SBCs to start + streaming media (possibly filled with silence payloads) + toward the address:port tuples provided by caller and + callee. This node is a boolean type. A value of true + indicates that the service provider expects the + enterprise network to send the first RTP packet, whereas + a value of false indicates that the service provider + network does not require the enterprise network to send + the first media packet. While the practice of + preserving the enterprise network in a hairpinned call + flow is fairly common, it is recommended that SIP + service providers avoid this practice. In the context + of a hairpinned call, the enterprise device retained in + the call flow can easily eavesdrop on the conversation + between the offnet parties."; + } + leaf symmetric-rtp { + type boolean; + description + "A node indicating whether the SIP service provider + expects the enterprise network to use symmetric RTP. + Enforcement of this requirement by service providers + on enterprise networks is typically useful in scenarios + such as media latching. This node is a boolean type. A + value of true indicates that the service provider + expects the enterprise network to use symmetric RTP, + whereas a value of false indicates that the enterprise + network can use asymmetric RTP."; + reference + "RFC 4961: Symmetric RTP / RTP Control Protocol (RTCP), + RFC 7362: Latching: Hosted NAT Traversal (HNT) for Media + in Real-Time Communication"; + } + } + container rtcp { + description + "A container that encapsulates generic characteristics of + RTCP sessions between the enterprise and service provider + network."; + leaf symmetric-rtcp { + type boolean; + description + "A node indicating whether the SIP service + provider expects the enterprise network to use symmetric + RTCP. This node is a boolean type. A value of true + indicates that the service provider expects symmetric + RTCP reports, whereas a value of false indicates that + the enterprise can use asymmetric RTCP."; + reference + "RFC 4961: Symmetric RTP / RTP Control Protocol (RTCP)"; + } + leaf rtcp-feedback { + type boolean; + description + "A node that indicates whether the SIP service + provider supports the RTP profile extension for + RTCP-based feedback. Media sessions spanning + enterprise and service provider networks are rarely + made to flow directly between the caller and callee; + rather, it is often the case that media traffic flows + through network intermediaries such as SBCs. + As a result, RTCP traffic from the service provider + network is intercepted by these intermediaries, which + in turn can either pass across RTCP traffic unmodified + or modify RTCP traffic before it is forwarded to the + endpoint in the enterprise network. Modification of + RTCP traffic would be required, for example, if the + intermediary has performed media payload transformation + operations such as transcoding or transrating. + In a similar vein, for the RTCP-based feedback mechanism + as defined in RFC 4585 to be truly effective, + intermediaries must ensure that feedback messages are + passed reliably and with the correct formatting to + enterprise endpoints. + This might require additional configuration and + considerations that need to be dealt with at the time + of provisioning the intermediary device. This node + is a boolean type. A value of true indicates that the + service provider supports the RTP profile extension for + RTP-based feedback, and a value of false indicates that + the service provider does not support the RTP profile + extension for RTP-based feedback."; + reference + "RFC 4585: Extended RTP Profile for Real-time Transport + Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"; + } + } + } + container dtmf { + description + "A container that describes the various aspects of + DTMF relay via RTP Named Telephony Events. The dtmf + container allows SIP service providers to specify two facets + of DTMF relay via Named Telephony Events."; + leaf payload-number { + type uint8 { + range "96..127"; + } + description + "Indicates the payload type number."; + } + leaf iteration { + type boolean; + description + "A value of true indicates that the service provider + supports the newer standard while a value of false + indicates that the service provider prefers the + older standard"; + reference + "RFC 4733: RTP Payload for DTMF Digits, Telephony + Tones, and Telephony Signals, + RFC 2833: RTP Payload for DTMF Digits, Telephony + Tones and Telephony Signals"; + } + } + container security { + description + "A container that encapsulates characteristics about + encrypting signaling streams between the enterprise + and SIP service provider networks."; + container signaling { + description + "A container that encapsulates the type of security + protocol for the SIP communication between the + enterprise SBC and the service provider."; + leaf secure { + type boolean; + description + "A node that specifies whether the service provider + allows the use of TLS to secure SIP signaling + messages between the enterprise and service provider + network. This node is a boolean type. A value of + true indicates that the service provider supports + SIP sessions over TLS, whereas a value of false + indicates that the service provider does not support + SIP over TLS."; + } + leaf-list version { + when "../secure = 'true'"; + type identityref { + base tlscmn:tls-version-base; + } + description + "A list that specifies the version(s) of TLS supported."; + } + } + container media-security { + description + "A container that describes the various characteristics of + securing media streams between enterprise and service + provider networks."; + leaf-list key-management { + type enumeration { + enum sdes { + description + "Simplified Data Encryption Standard (SDES) + key management."; + } + enum dtls-srtp { + description + "Secure Real-time Transport Protocol (SRTP) keys + managed using DTLS."; + } + } + description + "A list that specifies the key management method(s) + used by the service provider. Possible values in this + list include 'SDES' and 'DTLS-SRTP'."; + reference + "RFC 4568: Session Description Protocol (SDP) Security + Descriptions for Media Streams, + RFC 5764: Datagram Transport Layer Security (DTLS) + Extension to Establish Keys for the Secure Real-time + Transport Protocol (SRTP)"; + } + } + leaf certificate-location { + type inet:uri; + description + "If the enterprise network is required to exchange SIP + traffic over TLS with the SIP service provider, and if the + SIP service provider is capable of accepting TLS + connections from the enterprise network, it may be + required for the SIP service provider certificates to be + pre-installed on the enterprise edge element. In such + situations, the certificate-location node is populated + with a URL, which when dereferenced, provides a single + Privacy-Enhanced Mail (PEM) encoded file that contains all + certificates in the chain of trust."; + } + container secure-telephony-identity { + description + "Encapsulates Secure Telephony Identity (STIR) + characteristics."; + leaf stir-compliance { + type boolean; + description + "A node that indicates whether the SIP service + provider is STIR compliant. This node is a boolean + type. A value of true indicates that the SIP service + provider is STIR compliant. A value of false indicates + that the SIP service provider is not STIR compliant. A + SIP service provider being STIR compliant has + implications for inbound and outbound calls, from the + perspective of the enterprise network."; + } + leaf certificate-delegation { + type boolean; + description + "A node that indicates whether a SIP service + provider that allocates one or more number ranges to an + enterprise network is willing to delegate authority to + the enterprise network over that number range(s). This + node is a boolean type. A value of true indicates that + the SIP service provider is willing to delegate + authority to the enterprise network over one or more + number ranges. A value of false indicates that the SIP + service provider is not willing to delegate authority to + the enterprise network over one or more number ranges. + This node MUST only be included in the capability set if + the value of the stir-compliance leaf node is set to + true. In order to obtain delegate certificates, the + enterprise network must be made aware of the scope of + delegation, i.e., the number or number range(s) over + which the SIP service provider is willing to delegate + authority. This information is included in the + num-ranges container."; + } + leaf acme-directory { + when "../certificate-delegation = 'true'"; + type inet:uri; + description + "A node that provides the URL of the directory object for + delegate certificates using Automatic Certificate + Management Environment (ACME). The directory object + URL, when dereferenced, provides a collection of field + name-value pairs. Certain field name-value pairs + provided in the response are used to bootstrap the + process of obtaining delegate certificates. + This node MUST only be included in the capability + set if the value of the certificate-delegation leaf node + is set to true."; + reference + "RFC 8555: Automatic Certificate Management Environment + (ACME)"; + } + } + } + leaf-list extension { + type iana-sip-option-tags:sip-option-tag; + description + "A list of SIP option tags (extensions) supported by the + service provider network."; + reference + "https://www.iana.org/assignments/iana-sip-option-tags/"; + } + } +}