<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.21 (Ruby 3.3.6) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-teas-common-ac-15" number="9833" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.25.0 -->version="3" xml:lang="en" updates="" obsoletes=""> <front> <title abbrev="Common Attachment Circuit YANG">A Common YANG Data Model for Attachment Circuits</title> <seriesInfoname="Internet-Draft" value="draft-ietf-opsawg-teas-common-ac-15"/>name="RFC" value="9833"/> <author fullname="Mohamed Boucadair"role="editor">role="editor" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="Richard Roberts"role="editor">role="editor" initials="R." surname="Roberts"> <organization>Juniper</organization> <address> <email>rroberts@juniper.net</email> </address> </author> <author fullname="Oscar Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"> <organization>Telefonica</organization> <address> <email>oscar.gonzalezdedios@telefonica.com</email> </address> </author> <author fullname="Samier Barguil Giraldo" initials="S." surname="Barguil Giraldo"> <organization>Nokia</organization> <address> <email>samier.barguil_giraldo@nokia.com</email> </address> </author> <author fullname="BoWu">Wu" initials="B." surname="Wu"> <organization>Huawei Technologies</organization> <address> <email>lana.wubo@huawei.com</email> </address> </author> <date year="2025"month="January" day="23"/> <area>Operations and Management</area> <workgroup>Operations and Management Area Working Group</workgroup>month="August"/> <area>OPS</area> <workgroup>opsawg</workgroup> <keyword>Slice Service</keyword> <keyword>L3VPN</keyword> <keyword>L2VPN</keyword> <keyword>Automation</keyword> <keyword>Network Automation</keyword> <keyword>Orchestration</keyword> <keyword>service delivery</keyword> <keyword>Service provisioning</keyword> <keyword>service segmentation</keyword> <keyword>service flexibility</keyword> <keyword>service simplification</keyword> <keyword>Network Service</keyword> <keyword>3GPP</keyword> <keyword>Network Slicing</keyword> <abstract><?line 106?><t>The document specifies a common attachment circuits (ACs) YANG data model, which is designed to be reusable by other models. This design is meant to ensure consistent AC structures among models that manipulate ACs. For example, this common model can be reused by service models to expose ACs as a service, service models that require binding a service to a set of ACs, network and device models to provision ACs, etc.</t> </abstract><note removeInRFC="true"> <name>Discussion Venues</name> <t>Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org), which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/boucadair/attachment-circuit-model"/>.</t> </note></front> <middle> <?line 110?> <section anchor="introduction"> <name>Introduction</name> <t>Connectivity services are provided by networks to customers via dedicated terminating points (e.g., Service Functions (SFs), Customer Premises Equipment(CPEs),(CPE), Autonomous System Border Routers (ASBRs), datacenterscenter gateways, or Internet ExchangePoints).Points (IXPs)). A connectivity service ensures data transfer from (or destined to) a given terminating point to (ororiginateoriginating from) other terminating points. Objectives for such a connectivity service may be negotiated and agreed upon between a customer and a network provider.</t> <t>For that data transfer to take place within the provider network, it is assumed that adequate setup is provisioned over the links connecting the customer's terminating points to the provider network (typically, a Provider Edge (PE)), thereby enabling successful data exchange. This necessary provisioning is referred to in this document as an "attachment circuit" (AC), while the underlying link is referred to as the "bearer".</t> <t>When a customer requests a new service, that service can be associated with existing attachment circuits or may require the instantiation of new attachment circuits. Whether these attachment circuits are dedicated to a particular service or shared among multiple services depends on the specific deployment.</t> <t>Examples of attachment circuits are depicted in <xref target="uc"/>. A Customer Edge (CE) may be realized as a physical node or a logical entity. From the network's perspective, a CE is treated as a peer Service Attachment Point (SAP) <xref target="RFC9408"/>. CEs can be dedicated to a single service (e.g., Layer 3 Virtual Private Network (VPN) or Layer 2 VPN) or can host multiple services (e.g., Service Functions <xref target="RFC7665"/>). A single AC, as viewed by the network provider, may be bound to one or more peer SAPs (e.g., "CE1" and "CE2"). For instance, as discussed in <xref target="RFC4364"/>, multiple CEs can attach to a PE over the same attachment circuit. This approach is typically deployed when the Layer 2 infrastructure between the CE and the network supports a multipoint service. A single CE may also terminate multiple ACs (e.g., "CE3" and "CE4"), which may be carried over the same or distinct bearers.</t> <figure anchor="uc"> <name>Examples of ACs</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="304" width="512" viewBox="0 0 512 304" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,80 L 8,112" fill="none" stroke="black"/> <path d="M 8,160 L 8,192" fill="none" stroke="black"/> <path d="M 72,64 L 72,96" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 112,80 L 112,176" fill="none" stroke="black"/> <path d="M 176,112 L 176,144" fill="none" stroke="black"/> <path d="M 192,32 L 192,104" fill="none" stroke="black"/> <path d="M 192,152 L 192,224" fill="none" stroke="black"/> <path d="M 200,112 L 200,144" fill="none" stroke="black"/> <path d="M 280,208 L 280,240" fill="none" stroke="black"/> <path d="M 288,248 L 288,272" fill="none" stroke="black"/> <path d="M 304,208 L 304,240" fill="none" stroke="black"/> <path d="M 352,64 L 352,112" fill="none" stroke="black"/> <path d="M 352,144 L 352,192" fill="none" stroke="black"/> <path d="M 360,32 L 360,56" fill="none" stroke="black"/> <path d="M 360,200 L 360,224" fill="none" stroke="black"/> <path d="M 376,64 L 376,112" fill="none" stroke="black"/> <path d="M 376,144 L 376,192" fill="none" stroke="black"/> <path d="M 448,80 L 448,112" fill="none" stroke="black"/> <path d="M 448,160 L 448,192" fill="none" stroke="black"/> <path d="M 480,192 L 480,272" fill="none" stroke="black"/> <path d="M 504,64 L 504,96" fill="none" stroke="black"/> <path d="M 504,144 L 504,176" fill="none" stroke="black"/> <path d="M 192,32 L 360,32" fill="none" stroke="black"/> <path d="M 24,64 L 72,64" fill="none" stroke="black"/> <path d="M 352,64 L 376,64" fill="none" stroke="black"/> <path d="M 464,64 L 504,64" fill="none" stroke="black"/> <path d="M 72,80 L 112,80" fill="none" stroke="black"/> <path d="M 376,80 L 400,80" fill="none" stroke="black"/> <path d="M 424,80 L 448,80" fill="none" stroke="black"/> <path d="M 376,96 L 400,96" fill="none" stroke="black"/> <path d="M 424,96 L 448,96" fill="none" stroke="black"/> <path d="M 8,112 L 56,112" fill="none" stroke="black"/> <path d="M 176,112 L 200,112" fill="none" stroke="black"/> <path d="M 352,112 L 376,112" fill="none" stroke="black"/> <path d="M 448,112 L 488,112" fill="none" stroke="black"/> <path d="M 112,128 L 136,128" fill="none" stroke="black"/> <path d="M 160,128 L 176,128" fill="none" stroke="black"/> <path d="M 24,144 L 72,144" fill="none" stroke="black"/> <path d="M 176,144 L 200,144" fill="none" stroke="black"/> <path d="M 352,144 L 376,144" fill="none" stroke="black"/> <path d="M 464,144 L 504,144" fill="none" stroke="black"/> <path d="M 376,160 L 400,160" fill="none" stroke="black"/> <path d="M 424,160 L 448,160" fill="none" stroke="black"/> <path d="M 72,176 L 112,176" fill="none" stroke="black"/> <path d="M 376,176 L 400,176" fill="none" stroke="black"/> <path d="M 424,176 L 448,176" fill="none" stroke="black"/> <path d="M 8,192 L 56,192" fill="none" stroke="black"/> <path d="M 352,192 L 376,192" fill="none" stroke="black"/> <path d="M 448,192 L 488,192" fill="none" stroke="black"/> <path d="M 280,208 L 304,208" fill="none" stroke="black"/> <path d="M 192,224 L 280,224" fill="none" stroke="black"/> <path d="M 304,224 L 360,224" fill="none" stroke="black"/> <path d="M 280,240 L 304,240" fill="none" stroke="black"/> <path d="M 288,272 L 376,272" fill="none" stroke="black"/> <path d="M 400,272 L 480,272" fill="none" stroke="black"/> <path d="M 24,64 C 15.16936,64 8,71.16936 8,80" fill="none" stroke="black"/> <path d="M 464,64 C 455.16936,64 448,71.16936 448,80" fill="none" stroke="black"/> <path d="M 56,112 C 64.83064,112 72,104.83064 72,96" fill="none" stroke="black"/> <path d="M 488,112 C 496.83064,112 504,104.83064 504,96" fill="none" stroke="black"/> <path d="M 24,144 C 15.16936,144 8,151.16936 8,160" fill="none" stroke="black"/> <path d="M 464,144 C 455.16936,144 448,151.16936 448,160" fill="none" stroke="black"/> <path d="M 56,192 C 64.83064,192 72,184.83064 72,176" fill="none" stroke="black"/> <path d="M 488,192 C 496.83064,192 504,184.83064 504,176" fill="none" stroke="black"/> <g class="text"> <text x="412" y="68">(b1)</text> <text x="412" y="84">AC</text> <text x="40" y="100">CE1</text> <text x="364" y="100">PE</text> <text x="412" y="100">AC</text> <text x="480" y="100">CE3</text> <text x="412" y="116">(b2)</text> <text x="148" y="132">AC</text> <text x="188" y="132">PE</text> <text x="272" y="132">Network</text> <text x="360" y="132">|</text> <text x="412" y="148">(b3)</text> <text x="412" y="164">AC</text> <text x="40" y="180">CE2</text> <text x="364" y="180">PE</text> <text x="412" y="180">AC</text> <text x="480" y="180">CE4</text> <text x="412" y="196">(b3)</text> <text x="292" y="228">PE</text> <text x="388" y="276">AC</text> <text x="20" y="292">(bx)</text> <text x="48" y="292">=</text> <text x="84" y="292">bearer</text> <text x="124" y="292">Id</text> <text x="144" y="292">x</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ .--------------------. | | .------. | .--. (b1) .-----. | +----. | | +---AC---+ | | CE1 | | | |PE+---AC---+ CE3 | '------' | .--. '--' (b2) '-----' +---AC--+PE| Network | .------. | '--' .--. (b3) .-----. | | | | | +---AC---+ | | CE2 +----' | |PE+---AC---+ CE4 | '------' | '--' (b3) '---+-' | .--. | | '----------+PE+------' | '--' | | | '-----------AC----------' (bx) = bearer Id x ]]></artwork> </artset> </figure> <t>This document specifies a common module ("ietf-ac-common") for attachment circuits (<xref target="sec-module"/>). The module is designed to be reusable by other models, thereby ensuring consistent AC structures among modules that manipulate ACs. For example, the common module can be reused by service models to expose AC-as-a-Service (ACaaS) (e.g., <xreftarget="I-D.ietf-opsawg-teas-attachment-circuit"/>)target="RFC9834"/>) or by service models that require binding a service to a set of ACs (e.g., Network Slice Service <xref target="I-D.ietf-teas-ietf-network-slice-nbi-yang"/>)). It can also be used by network models to provision ACs (e.g., <xreftarget="I-D.ietf-opsawg-ntw-attachment-circuit"/>)target="RFC9835"/>) and device models, among others.</t> <t>The common AC module eases data inheritance between modules (e.g., from service to network models as per <xref target="RFC8969"/>).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t><section anchor="editorial-note-to-be-removed-by-rfc-editor"> <name>Editorial Note (To be removed by RFC Editor)</name> <t>Note to the RFC Editor: This section is to be removed prior to publication.</t> <t>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.</t> <t>Please apply the following replacements:</t> <ul spacing="normal"> <li> <t>XXXX --> the assigned RFC number for this I-D</t> </li> <li> <t>2025-01-07 --> the actual date of the publication of this document</t> </li> </ul> </section></section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name> <t>The meanings of the symbols in the YANG tree diagrams are defined in <xref target="RFC8340"/>.</t> <t>LxSM refers to both the Layer 2 Service Model (L2SM) <xref target="RFC8466"/> and the Layer 3 Service Model (L3SM) <xref target="RFC8299"/>.</t> <t>LxNM refers to both the Layer 2 Network Model (L2NM) <xref target="RFC9291"/> and the Layer 3 Network Model (L3NM) <xref target="RFC9182"/>.</t> <t>This document uses the following term:</t><dl><dl spacing="normal" newline="false"> <dt>Bearer:</dt> <dd> <t>A physical or logical link that connects a CE (or site) to a provider network.</t></dd> <dt/> <dd><t>A bearer can be a wireless or wired link. One or multiple technologies can be used to build a bearer. The bearer type can be specified by a customer.</t></dd> <dt/> <dd><t>The operator allocates a unique bearer reference to identify a bearer within its network (e.g., customer line identifier). Such a reference can be retrieved by a customer and then used in subsequent service placement requests to unambiguously identify where a service is to be bound.</t></dd> <dt/> <dd><t>The concept of bearer can be generalized to refer to the required underlying connection for the provisioning of an attachment circuit.</t></dd> <dt/> <dd><t>One or multiple attachment circuits may be hosted over the same bearer (e.g., multiple Virtual Local Area Networks (VLANs) on the same bearer that is provided by a physical link).</t> </dd> </dl> <t>The names of data nodes are prefixed using the prefix associated with the corresponding imported YANG module as shown in <xref target="pref"/>.</t> <table anchor="pref"> <name>Modules and Their Associated Prefixes</name> <thead> <tr> <th align="left">Prefix</th> <th align="left">Module</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">inet</td> <td align="left">ietf-inet-types</td> <td align="left"> <xref section="4" sectionFormat="of" target="RFC6991"/></td> </tr> <tr> <td align="left">key-chain</td> <td align="left">ietf-key-chain</td> <td align="left"> <xref target="RFC8177"/></td> </tr> <tr> <td align="left">nacm</td> <td align="left">ietf-netconf-acm</td> <td align="left"> <xref target="RFC8341"/></td> </tr> <tr> <td align="left">vpn-common</td> <td align="left">ietf-vpn-common</td> <td align="left"> <xref target="RFC9181"/></td> </tr> <tr> <td align="left">yang</td> <td align="left">ietf-yang-types</td> <td align="left"> <xref section="3" sectionFormat="of" target="RFC6991"/></td> </tr> </tbody> </table> </section> <section anchor="relationship-to-other-ac-data-models"> <name>Relationship to Other AC Data Models</name> <t><xref target="ac-overview"/> depicts the relationship between the various AC data models:</t> <ul spacing="normal"> <li> <t>"ietf-ac-common" (<xref target="sec-module"/>)</t> </li> <li> <t>"ietf-bearer-svc" (<xrefsection="5.1"section="6.1" sectionFormat="of"target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t>target="RFC9834"/>)</t> </li> <li> <t>"ietf-ac-svc" (<xrefsection="5.2"section="6.2" sectionFormat="of"target="I-D.ietf-opsawg-teas-attachment-circuit"/>)</t>target="RFC9834"/>)</t> </li> <li> <t>"ietf-ac-ntw"(<xref target="I-D.ietf-opsawg-ntw-attachment-circuit"/>)</t><xref target="RFC9835"/></t> </li> <li> <t>"ietf-ac-glue"(<xref target="I-D.ietf-opsawg-ac-lxsm-lxnm-glue"/>)</t><xref target="RFC9836"/></t> </li> </ul> <figure anchor="ac-overview"> <name>AC Data Models</name> <artset> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="288" width="368" viewBox="0 0 368 288" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 32,144 L 32,240" fill="none" stroke="black"/> <path d="M 56,80 L 56,112" fill="none" stroke="black"/> <path d="M 72,144 L 72,176" fill="none" stroke="black"/> <path d="M 144,48 L 144,80" fill="none" stroke="black"/> <path d="M 192,40 L 192,112" fill="none" stroke="black"/> <path d="M 240,48 L 240,80" fill="none" stroke="black"/> <path d="M 328,80 L 328,160" fill="none" stroke="black"/> <path d="M 328,192 L 328,240" fill="none" stroke="black"/> <path d="M 56,80 L 144,80" fill="none" stroke="black"/> <path d="M 240,80 L 328,80" fill="none" stroke="black"/> <path d="M 104,128 L 128,128" fill="none" stroke="black"/> <path d="M 72,176 L 264,176" fill="none" stroke="black"/> <path d="M 32,240 L 128,240" fill="none" stroke="black"/> <path d="M 248,240 L 328,240" fill="none" stroke="black"/> <path d="M 24,272 L 40,272" fill="none" stroke="black"/> <polygon class="arrowhead" points="336,192 324,186.4 324,197.6" fill="black" transform="rotate(270,328,192)"/> <polygon class="arrowhead" points="248,48 236,42.4 236,53.6" fill="black" transform="rotate(270,240,48)"/> <polygon class="arrowhead" points="200,40 188,34.4 188,45.6" fill="black" transform="rotate(270,192,40)"/> <polygon class="arrowhead" points="152,48 140,42.4 140,53.6" fill="black" transform="rotate(270,144,48)"/> <polygon class="arrowhead" points="112,128 100,122.4 100,133.6" fill="black" transform="rotate(180,104,128)"/> <polygon class="arrowhead" points="80,144 68,138.4 68,149.6" fill="black" transform="rotate(270,72,144)"/> <polygon class="arrowhead" points="48,272 36,266.4 36,277.6" fill="black" transform="rotate(0,40,272)"/> <polygon class="arrowhead" points="40,144 28,138.4 28,149.6" fill="black" transform="rotate(270,32,144)"/> <g class="text"> <text x="188" y="36">ietf-ac-common</text> <text x="48" y="132">ietf-ac-svc</text> <text x="200" y="132">ietf-bearer-svc</text> <text x="320" y="180">ietf-ac-ntw</text> <text x="188" y="244">ietf-ac-glue</text> <text x="8" y="276">X</text> <text x="60" y="276">Y:</text> <text x="80" y="276">X</text> <text x="120" y="276">imports</text> <text x="160" y="276">Y</text> </g> </svg> </artwork> <artwork type="ascii-art" align="center"><![CDATA[ ietf-ac-common ^ ^ ^ | | | .----------' | '----------. | | | | | | ietf-ac-svc <--- ietf-bearer-svc | ^ ^ | | | | | '------------------------ ietf-ac-ntw | ^ | | | | '------------ ietf-ac-glue ----------' X --> Y: X imports Y ]]></artwork> </artset> </figure> <t>The "ietf-ac-common" module is imported by the "ietf-bearer-svc", "ietf-ac-svc", and "ietf-ac-ntw" modules. Bearers managed using the "ietf-bearer-svc" module may be referenced by service ACs managed using the "ietf-ac-svc" module. Similarly, a bearer managed using the "ietf-bearer-svc" module may list the set of ACs that use that bearer. To facilitate correlation between an AC service request and the actual AC provisioned in the network, "ietf-ac-ntw" leverages the AC references exposed by the "ietf-ac-svc" module. Furthermore, to bind Layer 2 VPN or Layer 3 VPN services with ACs, the "ietf-ac-glue" module augments the LxSM and LxNM with AC service references exposed by the "ietf-ac-svc" module and AC network references exposed by the "ietf-ac-ntw" module.</t> </section> <section anchor="description-of-the-ac-common-yang-module"> <name>Description of the AC Common YANG Module</name> <t>The full tree diagram of the module is provided in <xref target="AC-Common-Tree"/>. Subtrees are provided in the following subsections for the reader's convenience.</t> <section anchor="features"> <name>Features</name> <t>The module defines the following features:</t><dl><dl spacing="normal" newline="false"> <dt>'layer2-ac':</dt> <dd> <t>Used to indicate support of ACs with Layer 2 properties.</t> </dd> <dt>'layer3-ac':</dt> <dd> <t>Used to indicate support of ACs with Layer 3 properties.</t> </dd> <dt>'server-assigned-reference':</dt> <dd> <!--[rfced] To avoid back-to-back use of "For example", may we update the second occurrence as follows? Original: For example, a server can be a network controller or a router in a provider network. For example, a bearer request is first created using a name which is assigned by the client, but if this feature is supported, the request will also include a server-generated reference. Perhaps: For example, a server can be a network controller or a router in a provider network. As another example, a bearer request is first created using a name that is assigned by the client, but if this feature is supported, the request will also include a server-generated reference. --> <t>Used to indicate support of server-generated references to access relevant resources. For example, a server can be a network controller or a router in a provider network.</t></dd> <dt/> <dd><t>For example, a bearer request is first created using a namewhichthat is assigned by the client, but if this feature is supported, the request will also include a server-generated reference. That reference can be used when requesting thecreatingcreation of an AC over the existing bearer.</t> </dd> </dl> </section> <section anchor="identities"> <name>Identities</name> <t>The module defines a set of identities, including the following:</t> <dl> <dt>'address-allocation-type':</dt> <dd> <t>Used to specify the IP address allocation type in an AC. For example, this identity is used to indicate whether the provider network provides DHCP service, DHCP relay, or static addressing. Note that for the IPv6 case, Stateless Address Autoconfiguration (SLAAC) <xref target="RFC4862"/> can be used.</t> </dd> <dt>'local-defined-next-hop':</dt> <dd> <t>Used to specifynext hopnext-hop actions. For example, this identity can be used to indicate an action to discard traffic for a given destination or treat traffic towards addresses within the specified next-hop prefix as though they are connected to a local link.</t> </dd> <dt>'l2-tunnel-type':</dt> <dd> <t>Used to control the Layer 2 tunnel selection for an AC. The current version supports indicating pseudowire, Virtual Private LAN Service (VPLS), and Virtual eXtensible Local Area Network (VXLAN).</t> </dd> <dt>'l3-tunnel-type':</dt> <dd> <t>Used to control the Layer 3 tunnel selection for an AC. Examples of such type are: IP-in-IP <xref target="RFC2003"/>, IPsec <xref target="RFC4301"/>, and Generic Routing Encapsulation (GRE) <xref target="RFC1701"/><xref target="RFC1702"/><xref target="RFC7676"/>.</t> </dd> <dt>'precedence-type':</dt> <dd> <t>Used to indicate the redundancy type when requesting ACs. For example, this identity can be used to tag primary and secondary ACs.</t> </dd> <dt>'role':</dt> <dd> <t>Used to indicate the type of an AC: User-to-Network Interface (UNI), Network-to-Network Interface (NNI), or public NNI.</t></dd> <dt/> <dd><t>The reader may refer to <xref target="MEF6"/>, <xref target="MEF17"/>, <xref target="RFC6004"/>, or <xref target="RFC6215"/> for examples of discussions regarding the use of UNI and NNI reference points.</t> </dd> <dt>New administrative status types:</dt> <dd> <t>In addition to the status types already defined in <xref target="RFC9181"/>, this documentdefines: </t>defines:</t> <ul spacing="normal"> <li> <t>'awaiting-validation' to report that a request is pending anadiministratoradministrator approval.</t> </li> <li> <t>'awaiting-processing' to report that a request was approved andvalidated,validated but is awaiting more processing before activation.</t> </li> <li> <t>'admin-prohibited' to report that a request cannot be handled because of administrative policies.</t> </li> <li> <t>'rejected' to report that a request was rejected due to reasons not covered by the other status types.</t> </li> </ul> </dd> <dt>'bgp-role':</dt> <dd> <t>Used to indicate the BGP role when establishing a BGP session per <xref target="RFC9234"/>.</t> </dd> </dl> </section> <section anchor="reusable-groupings"> <name>Reusable Groupings</name> <t>The module also defines a set of reusable groupings, including the following:</t> <dl> <dt>'service-status' (<xref target="op-full-tree"/>):</dt> <dd> <t>Controls the administrative service status and reports the operational service status.</t> </dd> <dt>'ac-profile-cfg' (<xref target="op-full-tree"/>):</dt> <dd> <t>A grouping with a set of valid provider profile identifiers. The following profiles aresupported: </t>supported:</t> <dl> <dt>'encryption-profile-identifier':</dt> <dd> <t>Refers to a set of policies related to the encryption setup that can be applied when provisioning an AC.</t> </dd> <dt>'qos-profile-identifier':</dt> <dd> <t>Refers to a set of policies, such as classification, marking, and actions (e.g., <xref target="RFC3644"/>).</t> </dd> <dt>'failure-detection-profile-identifier':</dt> <dd> <t>Refers to a set of failure detection policies (e.g., Bidirectional Forwarding Detection (BFD) policies <xref target="RFC5880"/>) that can be invoked when building an AC.</t> </dd> <dt>'forwarding-profile-identifier':</dt> <dd> <t>Refers to the policies that apply to the forwarding of packets conveyed within an AC. Such policies may consist, for example, of applying Access Control Lists (ACLs).</t> </dd> <dt>'routing-profile-identifier':</dt> <dd> <t>Refers to a set of routing policies that will be invoked (e.g., BGP policies) when building an AC.</t> </dd> </dl> </dd> <dt>'op-instructions' (<xref target="op-full-tree"/>):</dt> <dd> <t>Defines a set of parameters to specify basic scheduling instructions and report related events for a service request (e.g., AC or bearer) ('service-status'). Advanced scheduling groupings are defined in <xref target="I-D.ietf-netmod-schedule-yang"/>.</t></dd> </dl><figure anchor="op-full-tree"> <name>Service Status, Profiles, and Operational Instructions Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping service-status: +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping ac-profile-cfg: +-- valid-provider-identifiers +-- encryption-profile-identifier* [id] | +-- id string +-- qos-profile-identifier* [id] | +-- id string +-- failure-detection-profile-identifier* [id] | +-- id string +-- forwarding-profile-identifier* [id] | +-- id string +-- routing-profile-identifier* [id] +-- id string grouping op-instructions: +-- requested-start? yang:date-and-time +-- requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time]]></artwork>]]></sourcecode> </figure><dl></dd> <dt>Layer 2 encapsulations (<xref target="l2-full-tree"/>):</dt> <dd> <t>Groupings for the following encapsulation schemes are supported: dot1Q, QinQ, and priority-tagged.</t> </dd> <dt>Layer 2 tunnel services (<xref target="l2-full-tree"/>):</dt> <dd> <t>These groupings are used to define Layer 2 tunnel services that may be needed for the activation of an AC. Examples of supported Layer 2 services are the pseudowire (<xref section="6.1" sectionFormat="of" target="RFC8077"/>), VPLS, or VXLAN <xref target="RFC7348"/>.</t></dd> </dl><figure anchor="l2-full-tree"> <name>Layer 2 Connection Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping dot1q: +-- tag-type? identityref +-- cvlan-id? uint16 grouping priority-tagged: +-- tag-type? identityref grouping qinq: +-- tag-type? identityref +-- svlan-id? uint16 +-- cvlan-id? uint16 grouping pseudowire: +-- vcid? uint32 +-- far-end? union grouping vpls: +-- vcid? uint32 +-- far-end* union grouping vxlan: +-- vni-id? uint32 +-- peer-mode? identityref +-- peer-ip-address* inet:ip-address grouping l2-tunnel-service: +-- type? identityref +-- pseudowire | +-- vcid? uint32 | +-- far-end? union +-- vpls | +-- vcid? uint32 | +-- far-end* union +-- vxlan +-- vni-id? uint32 +-- peer-mode? identityref +-- peer-ip-address* inet:ip-address]]></artwork>]]></sourcecode> </figure><dl></dd> <dt>Layer 3 address allocation (<xref target="l3-full-tree"/>):</dt> <dd> <t>Defines both IPv4 and IPv6 groupings to specify IP address allocation over an AC. Both dynamic and static address schemes are supported.</t></dd> <dt/> <dd><t>For both IPv4 and IPv6, 'address-allocation-type' is used to indicate the IP address allocation mode to activate. When 'address-allocation-type' is set to 'provider-dhcp', DHCP assignments can be made locally or by an external DHCP server. Such behavior is controlled by setting 'dhcp-service-type'.</t></dd> <dt/> <dd><t>Note that if 'address-allocation-type' is set to 'slaac', the Prefix Information option of Router Advertisements that will be issued for SLAAC purposes will carry the IPv6 prefix that is determined by 'local-address' and 'prefix-length'.</t> </dd> <dt>IP connections (<xref target="l3-full-tree"/>):</dt> <dd> <t>Defines IPv4 and IPv6 groupings for managing Layer 3 connectivity over an AC. Both basic and more elaborated IP connection groupings are supported.</t></dd> </dl><figure anchor="l3-full-tree"> <name>Layer 3 Connection Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping ipv4-allocation-type: +-- prefix-length? uint8 +-- address-allocation-type? identityref grouping ipv6-allocation-type: +-- prefix-length? uint8 +-- address-allocation-type? identityref grouping ipv4-connection-basic: +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) +-- (provider-dhcp)? | +--:(dhcp-service-type) | +-- dhcp-service-type? enumeration +-- (dhcp-relay)? +--:(customer-dhcp-servers) +-- customer-dhcp-servers +-- server-ip-address* inet:ipv4-address grouping ipv6-connection-basic: +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) +-- (provider-dhcp)? | +--:(dhcp-service-type) | +-- dhcp-service-type? enumeration +-- (dhcp-relay)? +--:(customer-dhcp-servers) +-- customer-dhcp-servers +-- server-ip-address* inet:ipv6-address grouping ipv4-connection: +-- local-address? inet:ipv4-address +-- virtual-address? inet:ipv4-address +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) | +-- (address-assign)? | | +--:(number) | | | +-- number-of-dynamic-address? uint16 | | +--:(explicit) | | +-- customer-addresses | | +-- address-pool* [pool-id] | | +-- pool-id string | | +-- start-address inet:ipv4-address | | +-- end-address? inet:ipv4-address | +-- (provider-dhcp)? | | +--:(dhcp-service-type) | | +-- dhcp-service-type? enumeration | +-- (dhcp-relay)? | +--:(customer-dhcp-servers) | +-- customer-dhcp-servers | +-- server-ip-address* inet:ipv4-address +--:(static-addresses) +-- address* [address-id] +-- address-id string +-- customer-address? inet:ipv4-address grouping ipv6-connection: +-- local-address? inet:ipv6-address +-- virtual-address? inet:ipv6-address +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) | +-- (address-assign)? | | +--:(number) | | | +-- number-of-dynamic-address? uint16 | | +--:(explicit) | | +-- customer-addresses | | +-- address-pool* [pool-id] | | +-- pool-id string | | +-- start-address inet:ipv6-address | | +-- end-address? inet:ipv6-address | +-- (provider-dhcp)? | | +--:(dhcp-service-type) | | +-- dhcp-service-type? enumeration | +-- (dhcp-relay)? | +--:(customer-dhcp-servers) | +-- customer-dhcp-servers | +-- server-ip-address* inet:ipv6-address +--:(static-addresses) +-- address* [address-id] +-- address-id string +-- customer-address? inet:ipv6-address]]></artwork>]]></sourcecode> </figure><dl></dd> <dt>Routing parameters &OAMOperations, Administration, and Maintenance (OAM) (<xref target="rtg-full-tree"/>):</dt> <dd> <t>In addition to static routing, the module supports the following routing protocols: BGP <xref target="RFC4271"/>, OSPF <xref target="RFC4577"/>or<xref target="RFC6565"/>, IS-IS <xref target="ISO10589"/><xref target="RFC1195"/><xref target="RFC5308"/>, and RIP <xref target="RFC2453"/>. For all supported routing protocols, 'address-family' indicates whether IPv4, IPv6, or both address families are to be activated. For example, this parameter is used to determine whether RIPv2 <xref target="RFC2453"/>, RIP Next Generation (RIPng), or both are to be enabled <xref target="RFC2080"/>. More details about supported routing groupings are providedhereafter: </t> <ul spacing="normal"> <li> <dl>hereafter:</t> <dl spacing="normal" newline="false"> <dt>Authentication:</dt> <dd> <t>These groupings include the required information to manage the authentication of OSPF, IS-IS, BGP, and RIP. The groupings support local specification of authentication keys and the associated authentication algorithm toaccomodateaccommodate legacy implementations that do not support key chains <xref target="RFC8177"/>.</t></dd> <dt/> <dd><t>Note that this version of the common AC model covers authentication options that are common to both OSPFv2 <xref target="RFC4577"/> and OSPFv3 <xref target="RFC6565"/>; as such, the model does not support <xref target="RFC4552"/>.</t></dd> <dt/> <dd><t>Similar to <xref target="RFC9182"/>, this version of the common AC model assumes that parameters specific to theTCP-AOTCP Authentication Option (TCP-AO) are preconfigured as part of the key chain that is referenced in the model. No assumption is made about how such a key chain is preconfigured. However, the structure of the key chain should cover data nodes beyond those in <xref target="RFC8177"/>, mainly SendID and RecvID(Section 3.1 of <xref target="RFC5925"/>).</t>(<xref target="RFC5925" sectionFormat="of" section="3.1"/>).</t> </dd></dl> </li> <li> <t>BGP<dt>BGP peer groups ('bgp-peer-group-without-name' and'bgp-peer-group-with-name'): Includes'bgp-peer-group-with-name'):</dt> <dd>Includes a set of parameters to identify a BGP peer group. Such a group can be defined by providing a localASAutonomous System Number (ASN), a customer's ASN, and the address families to be activated for this group. BGP peer groups can be identified by a name('bgp-peer-group-with-name').</t> </li> <li> <t>Basic('bgp-peer-group-with-name').</dd> <dt>Basic OSPF and IS-IS parameters ('ospf-basic' and'isis-basic'): These'isis-basic'):</dt> <dd>These groupings include the minimal set of routing configuration that is required for the activation of OSPF andIS-IS.</t> </li> <li> <t>Static routing: ParametersIS-IS.</dd> <dt>Static routing:</dt> <dd>Parameters to configure an entry or a list of IP static routingentries.</t> </li> </ul> </dd> <dt/> <dd>entries.</dd> </dl> <t>The 'redundancy-group' grouping lists the groups to which an AC belongs <xref target="RFC9181"/>. For example, the 'group-id' is used to associate redundancy or protection constraints of ACs.</t></dd> </dl><!--[rfxed] In Figure 6, is it intentional that the first item (grouping bgp-authentication) is indented one space less than each of the groupings that follow? In the original XML (and current XML), it's one space for grouping bgp-authentication vs. two spaces for the others. --> <figure anchor="rtg-full-tree"> <name>Routing & OAM Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping bgp-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(ao) | +-- enable-ao? boolean | +-- ao-keychain? key-chain:key-chain-ref +--:(md5) | +-- md5-keychain? key-chain:key-chain-ref +--:(explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping ospf-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping isis-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping rip-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key? string +-- crypto-algorithm? identityref grouping bgp-peer-group-without-name: +-- local-as? inet:as-number +-- peer-as? inet:as-number +-- address-family? identityref +-- role? identityref grouping bgp-peer-group-with-name: +-- name? string +-- local-as? inet:as-number +-- peer-as? inet:as-number +-- address-family? identityref +-- role? identityref grouping ospf-basic: +-- address-family? identityref +-- area-id yang:dotted-quad +-- metric? uint16 grouping isis-basic: +-- address-family? identityref +-- area-address area-address grouping ipv4-static-rtg-entry: +-- lan? inet:ipv4-prefix +-- lan-tag? string +-- next-hop? union +-- metric? uint32 grouping ipv4-static-rtg: +-- ipv4-lan-prefixes* [lan next-hop] {vpn-common:ipv4}? +-- lan inet:ipv4-prefix +-- lan-tag? string +-- next-hop union +-- metric? uint32 +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping ipv6-static-rtg-entry: +-- lan? inet:ipv6-prefix +-- lan-tag? string +-- next-hop? union +-- metric? uint32 grouping ipv6-static-rtg: +-- ipv6-lan-prefixes* [lan next-hop] {vpn-common:ipv6}? +-- lan inet:ipv6-prefix +-- lan-tag? string +-- next-hop union +-- metric? uint32 +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping bfd: +-- holdtime? uint32 grouping redundancy-group: +-- group* [group-id] +-- group-id? string +-- precedence? identityref]]></artwork>]]></sourcecode> </figure><dl></dd> <dt>Bandwidth parameters (<xref target="bw-full-tree"/>):</dt><dd> <t>Bandwidth<dd><t>Bandwidth parameters can be represented using the Committed Information Rate (CIR), the Excess Information Rate (EIR), or the Peak Information Rate (PIR).</t></dd> <dt/> <dd><t>These parameters can be provided per bandwidth type. Type values are taken from <xref target="RFC9181"/>. For example, the following values can be used:</t><ul spacing="normal"> <li> <dl><dl spacing="normal" newline="false"> <dt>'bw-per-cos':</dt><dd> <t>The<dd>The bandwidth is per Class of Service(CoS).</t> </dd> </dl> </li> <li> <dl>(CoS).</dd> <!--[rfced] To improve readability, may we update "to" to "for"? Original: * 'bw-per-site': The bandwidth is to all ACs that belong to the same site. Perhaps: 'bw-per-site': The bandwidth is for all ACs that belong to the same site. --> <dt>'bw-per-site':</dt><dd> <t>The<dd>The bandwidth is to all ACs that belong to the samesite.</t> </dd> </dl> </li> </ul> </dd>site.</dd> </dl> <figure anchor="bw-full-tree"> <name>Bandwidth Groupings</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ grouping bandwidth-parameters: +-- cir? uint64 +-- cbs? uint64 +-- eir? uint64 +-- ebs? uint64 +-- pir? uint64 +-- pbs? uint64 grouping bandwidth-per-type: +-- bandwidth* [bw-type] +-- bw-type identityref +-- (type)? +--:(per-cos) | +-- cos* [cos-id] | +-- cos-id uint8 | +-- cir? uint64 | +-- cbs? uint64 | +-- eir? uint64 | +-- ebs? uint64 | +-- pir? uint64 | +-- pbs? uint64 +--:(other) +-- cir? uint64 +-- cbs? uint64 +-- eir? uint64 +-- ebs? uint64 +-- pir? uint64 +-- pbs? uint64]]></artwork>]]></sourcecode> </figure> </dd> </dl> </section> </section> <section anchor="sec-module"> <name>Common Attachment Circuit YANG Module</name> <!-- [rfced] We note that the following reference is cited only in the YANG module. In order to have a 1:1 matchup between the references section and the text, may we add the following reference entry to the Normative References and add it to the list of citations preceding the YANG module? Original: This module uses types defined in [RFC6991], [RFC8177], and [RFC9181]. Perhaps: This module uses types defined in [RFC6991], [RFC8177], [RFC9181], and [IEEE_802.1Q]. ... [IEEE_802.1Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks-Bridges and Bridged Networks", IEEE Std 802.1Q- 2022, DOI 10.1109/IEEESTD.2022.10004498, December 2022, <https://doi.org/10.1109/IEEESTD.2022.10004498>. --> <!--[rfced] FYI, the YANG module has been updated per the formatting option of pyang. Please let us know any concerns. --> <t>This module uses types defined in <xref target="RFC6991"/>, <xref target="RFC8177"/>, and <xref target="RFC9181"/>.</t> <sourcecode markers="true"name="ietf-ac-common@2025-01-07.yang"><![CDATA[name="ietf-ac-common@2025-08-11.yang" type="yang"><![CDATA[ module ietf-ac-common { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ac-common"; prefix ac-common; import ietf-vpn-common { prefix vpn-common; reference "RFC 9181: A Common YANG Data Model for Layer 2 and Layer 3 VPNs"; } import ietf-netconf-acm { prefix nacm; reference "RFC 8341: Network Configuration Access Control Model"; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types, Section 4"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types, Section 3"; } import ietf-key-chain { prefix key-chain; reference "RFC 8177: YANG Data Model for Key Chains"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: <https://datatracker.ietf.org/wg/opsawg/> WG List: <mailto:opsawg@ietf.org> Editor: Mohamed Boucadair <mailto:mohamed.boucadair@orange.com> Author: Richard Roberts <mailto:rroberts@juniper.net> Author: Oscar Gonzalez de Dios <mailto:oscar.gonzalezdedios@telefonica.com> Author: Samier Barguil <mailto:ssamier.barguil_giraldo@nokia.com> Author: Bo Wu <mailto:lana.wubo@huawei.com>"; description "This YANG module defines a common attachment circuit (AC) YANGmodelmodule with a set of reusable features, types, identities, and groupings. Copyright (c) 2025 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 RFCXXXX;9833; see the RFC itself for full legal notices."; revision2025-01-072025-08-11 { description "Initial revision."; reference "RFCXXXX:9833: A Common YANG Data Model for Attachment Circuits"; } /****************************Features************************/ feature layer2-ac { description "Indicates support of Layer 2 ACs."; } feature layer3-ac { description "Indicates support of Layer 3 ACs."; } feature server-assigned-reference { description "Indicates support for server-generated references and use of such references to access related resources."; } /****************************Identities************************/ // IP address allocation types identity address-allocation-type { description "Base identity for address allocation type on the AC."; } identity provider-dhcp { base address-allocation-type; description "The provider's network provides a DHCP service to the customer."; } identity provider-dhcp-relay { base address-allocation-type; description "The provider's network provides a DHCP relay service to the customer."; } identity provider-dhcp-slaac { if-feature "vpn-common:ipv6"; base address-allocation-type; description "The provider's network provides a DHCP service to the customer as well as IPv6 Stateless Address Autoconfiguration (SLAAC)."; reference "RFC 4862: IPv6 Stateless Address Autoconfiguration"; } identity static-address { base address-allocation-type; description "The provider's network provides static IP addressing to the customer."; } identity slaac { if-feature "vpn-common:ipv6"; base address-allocation-type; description "The provider's network uses IPv6 SLAAC to provide addressing to the customer."; reference "RFC 4862: IPv6 Stateless Address Autoconfiguration"; } identity dynamic-infra { base address-allocation-type; description "The IP address is dynamically allocated by the hosting infrastructure."; } // next-hop actions identity local-defined-next-hop { description "Base identity of local defined next hops."; } identity discard { base local-defined-next-hop; description "Indicates an action to discard traffic for the corresponding destination. For example, this can be used to black-hole traffic."; } identity local-link { base local-defined-next-hop; description "Treat traffic towards addresses within the specified next-hop prefix as though they are connected to a local link."; } // Layer 2 tunnel types identity l2-tunnel-type { description "Base identity for Layer 2 tunnel selection for an AC."; } identity pseudowire { base l2-tunnel-type; description "Pseudowire tunnel termination for the AC."; } identity vpls { base l2-tunnel-type; description "Virtual Private LAN Service (VPLS) tunnel termination for the AC."; } identity vxlan { base l2-tunnel-type; description "Virtual eXtensible Local Area Network (VXLAN) tunnel termination for the AC."; } // Layer 3 tunnel types identity l3-tunnel-type { description "Base identity for Layer 3 tunnel selection for an AC."; } identity ip-in-ip { base l3-tunnel-type; description"IP in IP Tunneling.";"IP-in-IP tunneling."; reference "RFC 2003: IP Encapsulation within IP"; } identity ipsec { base l3-tunnel-type; description "IP Security (IPsec)."; reference "RFC 4301: Security Architecture for the Internet Protocol"; } identity gre { base l3-tunnel-type; description "Generic Routing Encapsulation (GRE)."; reference "RFC 1701: Generic Routing Encapsulation (GRE) RFC 1702: Generic Routing Encapsulation over IPv4 networks RFC 7676: IPv6 Support for Generic Routing Encapsulation (GRE)"; } // Tagging precedence identity precedence-type { description "Redundancy type. Attachment to a network can be created with primary and secondary tagging."; } identity primary { base precedence-type; description "Identifies the main attachment circuit."; } identity secondary { base precedence-type; description "Identifies a secondary attachment circuit."; } // AC type identity role { description "Base identity for the network role of an AC."; } identity uni { base role; description "User-to-Network Interface (UNI)."; } identity nni { base role; description "Network-to-Network Interface (NNI)."; } identity public-nni { base role; description "Public peering. This is typically set using a shared network, such as an Internet Exchange Point (IXP)."; } // More Admin status types identity awaiting-validation { base vpn-common:administrative-status; description "This administrative status reflects that a request is pending an administrator approval."; } identity awaiting-processing { base vpn-common:administrative-status; description "This administrative status reflects that a request was approved andvalidated,validated but is awaiting more processing before activation."; } identity admin-prohibited { base vpn-common:administrative-status; description "This administrative status reflects that a request cannot be handled because of administrative policies."; } identity rejected { base vpn-common:administrative-status; description "This administrative status reflects that a request was rejected because, e.g., there are no sufficient resources or other reasons not covered by the other status types."; } // BGP role identity bgp-role { description "Used to indicate the BGP role when establishing a BGP session."; reference "RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, Section 4"; } identity provider { base bgp-role; description "The local AS is a transit provider of the remote AS."; } identity client { base bgp-role; description "The local AS is a transit customer of the remote AS."; } identity rs { base bgp-role; description "The local AS is a Route Server (RS)."; } identity rs-client { base bgp-role; description "The local AS is a client of anRSRS, and the RS is the remote AS."; } identity peer { base bgp-role; description "The local and remote ASes have a peering relationship."; } /****************************Typedefs************************/ typedef predefined-next-hop { type identityref { base local-defined-next-hop; } description "Predefined next-hop designation for locally generated routes."; } typedef area-address { type string { pattern '[0-9A-Fa-f]{2}(\.[0-9A-Fa-f]{4}){0,6}'; } description "This type defines the area address format."; } /************************Reusable groupings********************/ /**** Service Status ****/ grouping service-status { description "Service status grouping."; container status { description "Service status."; container admin-status { description "Administrative service status."; leaf status { type identityref { base vpn-common:administrative-status; } description "Administrative service status."; } leaf last-change { type yang:date-and-time; config false; description "Indicates the actual date and time of the service status change."; } } container oper-status { config false; description "Operational service status."; uses vpn-common:oper-status-timestamp; } } } /**** A set of profiles ****/ grouping ac-profile-cfg { description "Grouping for AC profile configuration."; container valid-provider-identifiers { description "Container for valid provider profile identifiers. The profiles only have significance within the service provider's administrative domain."; list encryption-profile-identifier { key "id"; description "List of encryption profile identifiers."; leaf id { type string; description "Identification of the encryption profile to be used."; } } list qos-profile-identifier { key "id"; description "List of QoS profile identifiers."; leaf id { type string; description "Identification of the QoS profile to be used."; } } list failure-detection-profile-identifier { key "id"; description "List of BFD profile identifiers."; leaf id { type string; description "Identification of the failure detection (e.g., BFD) profile to be used."; } } list forwarding-profile-identifier { key "id"; description "List of forwarding profile identifiers."; leaf id { type string; description "Identification of the forwarding profile to be used."; } } list routing-profile-identifier { key "id"; description "List of routing profile identifiers."; leaf id { type string; description "Identification of the routing profile to be used by the routing protocols over an AC."; } } nacm:default-deny-write; } } /**** Operational instructions ****/ grouping op-instructions { description "Scheduling instructions."; leaf requested-start { type yang:date-and-time; description "Indicates the requested date and time when the service is expected to be active."; } leaf requested-stop { type yang:date-and-time; description "Indicates the requested date and time when the service is expected to be disabled."; } leaf actual-start { type yang:date-and-time; config false; description "Indicates the actual date and time when the service actually was enabled."; } leaf actual-stop { type yang:date-and-time; config false; description "Indicates the actual date and time when the service actually was disabled."; } } /**** Layer 2 encapsulations ****/ // Dot1q grouping dot1q { description "Defines a grouping for tagged interfaces."; leaf tag-type { type identityref { base vpn-common:tag-type; } description "Tag type."; } leaf cvlan-id { type uint16 { range "1..4094"; } description "VLAN identifier."; } } // priority-tagged grouping priority-tagged { description "Priority tagged."; leaf tag-type { type identityref { base vpn-common:tag-type; } description "Tag type."; } } // QinQ grouping qinq { description "Includes QinQ parameters."; leaf tag-type { type identityref { base vpn-common:tag-type; } description "Tag type."; } leaf svlan-id { type uint16 { range "1..4094"; } description "Service VLAN (S-VLAN) identifier."; } leaf cvlan-id { type uint16 { range "1..4094"; } description "Customer VLAN (C-VLAN) identifier."; } } /**** Layer 2 tunnel services ****/ // pseudowire (PW) grouping pseudowire { description "Includes pseudowire termination parameters."; leaf vcid { type uint32; description "Indicates a PW or virtual circuit (VC) identifier."; } leaf far-end { type union { type uint32; type inet:ip-address; } description "Neighbor reference."; reference "RFC 8077: Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), Section 6.1"; } } // VPLS grouping vpls { description "VPLS termination parameters."; leaf vcid { type uint32; description "VC identifier."; } leaf-list far-end { type union { type uint32; type inet:ip-address; } description "Neighbor reference."; } } // VXLAN grouping vxlan { description "VXLAN termination parameters."; leaf vni-id { type uint32; description "VXLAN Network Identifier (VNI)."; } leaf peer-mode { type identityref { base vpn-common:vxlan-peer-mode; } description "Specifies the VXLAN access mode. By default, the peer mode is set to 'static-mode'."; } leaf-list peer-ip-address { type inet:ip-address; description "List of a peer's IP addresses."; } } // Layer 2 Tunnel service grouping l2-tunnel-service { description "Defines a Layer 2 tunnel termination."; leaf type { type identityref { base l2-tunnel-type; } description "Selects the tunnel termination type for an AC."; } container pseudowire { when "derived-from-or-self(../type, 'ac-common:pseudowire')" { description "Only applies when the Layer 2 service type is 'pseudowire'."; } description "Includes pseudowire termination parameters."; uses pseudowire; } container vpls { when "derived-from-or-self(../type, 'ac-common:vpls')" { description "Only applies when the Layer 2 service type is 'vpls'."; } description "VPLS termination parameters."; uses vpls; } container vxlan { when "derived-from-or-self(../type, 'ac-common:vxlan')" { description "Only applies when the Layer 2 service type is 'vxlan'."; } description "VXLAN termination parameters."; uses vxlan; } } /**** Layer 3 connection *****/ // IPv4 allocation type grouping ipv4-allocation-type { description "IPv4-specific parameters."; leaf prefix-length { type uint8 { range "0..32"; } description "Subnet prefix length expressed in bits. It is applied to both local and customer addresses."; } leaf address-allocation-type { type identityref { base address-allocation-type; } must "not(derived-from-or-self(current(), 'ac-common:slaac') " + "or derived-from-or-self(current(), " + "'ac-common:provider-dhcp-slaac'))" { error-message "SLAAC is only applicable to IPv6."; } description "Defines how IPv4 addresses are allocated to the peer termination points."; } } // IPv6 allocation type grouping ipv6-allocation-type { description "IPv6-specific parameters."; leaf prefix-length { type uint8 { range "0..128"; } description "Subnet prefix length expressed in bits. It is applied to both local and customer addresses."; } leaf address-allocation-type { type identityref { base address-allocation-type; } description "Defines how IPv6 addresses are allocated to the peer termination points."; } } // Basic parameters for an IPv4 connection grouping ipv4-connection-basic { description "Basic set for IPv4-specific parameters for the connection."; uses ipv4-allocation-type; choice allocation-type { description "Choice of the IPv4 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP,thatwhich is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on an AC."; } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv4-address; description "IPv4 addresses of the customer's DHCP server."; } } } } } } // Basic parameters for an IPv6 connection grouping ipv6-connection-basic { description "Basic set for IPv6-specific parameters for the connection."; uses ipv6-allocation-type; choice allocation-type { description "Choice of the IPv6 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP,thatwhich is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on the AC."; } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv6-address; description "IPv6 addresses of the customer's DHCP server."; } } } } } } // Full parameters for the IPv4 connection grouping ipv4-connection { description "IPv4-specific connection parameters."; leaf local-address { type inet:ipv4-address; description "The IP address used at the provider's interface."; } leaf virtual-address { type inet:ipv4-address; description "This address may be used for redundancy purposes."; } uses ipv4-allocation-type; choice allocation-type { description "Choice of the IPv4 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice address-assign { description "A choice for how IPv4 addresses are assigned."; case number { leaf number-of-dynamic-address { type uint16; description "Specifies the number of IP addresses to be assigned to the customer on the AC."; } } case explicit { container customer-addresses { description "Container for customer addresses to be allocated using DHCP."; list address-pool { key "pool-id"; description "Describes IP addresses to be dynamically allocated. When only 'start-address' is present, it represents a single address. When both 'start-address' and 'end-address' are specified, it implies a range inclusive of both addresses."; leaf pool-id { type string; description "A pool identifier for the address range from 'start-address' to 'end-address'."; } leaf start-address { type inet:ipv4-address; mandatory true; description "Indicates the first address in the pool."; } leaf end-address { type inet:ipv4-address; description "Indicates the last address in the pool."; } } } } } choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP, which is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on this AC."; } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv4-address; description "IPv4 addresses of the customer's DHCP server."; } } } } case static-addresses { description "Lists the IPv4 addresses that are used."; list address { key "address-id"; ordered-by user; description "Lists the IPv4 addresses that are used. The first address of the list is the primary address of the connection."; leaf address-id { type string; description "An identifier of the static IPv4 address."; } leaf customer-address { type inet:ipv4-address; description "An IPv4 address of the customer side."; } } } } } // Full parameters for the IPv6 connection grouping ipv6-connection { description "IPv6-specific connection parameters."; leaf local-address { type inet:ipv6-address; description "IPv6 address of the provider side."; } leaf virtual-address { type inet:ipv6-address; description "This address may be used for redundancy purposes."; } uses ipv6-allocation-type; choice allocation-type { description "Choice of the IPv6 address allocation."; case dynamic { description "When the addresses are allocated by DHCP or other dynamic means local to the infrastructure."; choice address-assign { description "A choice for how IPv6 addresses are assigned."; case number { leaf number-of-dynamic-address { type uint16; description "Specifies the number of IP addresses to be assigned to the customer on this access."; } } case explicit { container customer-addresses { description "Container for customer addresses to be allocated using DHCP."; list address-pool { key "pool-id"; description "Describes IP addresses to be dynamically allocated. When only 'start-address' is present, it represents a single address. When both 'start-address' and 'end-address' are specified, it implies a range inclusive of both addresses."; leaf pool-id { type string; description "A pool identifier for the address range from 'start-address' to 'end-address'."; } leaf start-address { type inet:ipv6-address; mandatory true; description "Indicates the first address in the pool."; } leaf end-address { type inet:ipv6-address; description "Indicates the last address in the pool."; } } } } } choice provider-dhcp { description "Parameters related to DHCP-allocated addresses. IP addresses are allocated by DHCP, which is provided by the operator."; leaf dhcp-service-type { type enumeration { enum server { description "Local DHCP server."; } enum relay { description "Local DHCP relay. DHCP requests are relayed to a provider's server."; } } description "Indicates the type of DHCP service to be enabled on this access."; } } choice dhcp-relay { description "The DHCP relay is provided by the operator."; container customer-dhcp-servers { description "Container for a list of the customer's DHCP servers."; leaf-list server-ip-address { type inet:ipv6-address; description "IPv6 addresses of the customer's DHCP server."; } } } } case static-addresses { description "Lists the IPv6 addresses that are used by the customer."; list address { key "address-id"; ordered-by user; description "Lists the IPv6 addresses that are used. The first address of the list is the primary IP address of the connection."; leaf address-id { type string; description "An identifier of the static IPv6 address."; } leaf customer-address { type inet:ipv6-address; description "An IPv6 address of the customer side."; } } } } } /**** Routing ****/ // Routing authentication grouping bgp-authentication { description "Grouping for BGP authentication parameters."; container authentication { description "Container for BGP authentication parameters."; leaf enabled { type boolean; description "Enables or disables authentication."; } container keying-material { when "../enabled = 'true'"; description "Container for describing how a BGP routing session is to be secured on an AC."; choice option { description "Choice of authentication options."; case ao { description "Uses the TCP Authentication Option (TCP-AO)."; reference "RFC 5925: The TCP Authentication Option"; leaf enable-ao { type boolean; description "Enables the TCP-AO."; } leaf ao-keychain { type key-chain:key-chain-ref; description "Reference to the TCP-AO key chain."; reference "RFC 8177: YANG Data Model for Key Chains"; } } case md5 { description "Uses MD5 to secure the session."; reference "RFC 4364: BGP/MPLS IP Virtual Private Networks (VPNs), Section 13.2"; leaf md5-keychain { type key-chain:key-chain-ref; description "Specifies a reference to the MD5 key chain."; reference "RFC 8177: YANG Data Model for Key Chains"; } } case explicit { leaf key-id { type uint32; description "Specifies a key identifier."; } leaf key { type string; description "BGP authentication key. This model only supports the subset of keys that are representable as ASCII strings."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Indicates the cryptographic algorithm associated with the key."; } } } } } } grouping ospf-authentication { description "Authentication configuration."; container authentication { description "Container for OSPF authentication parameters."; leaf enabled { type boolean; description "Enables or disables authentication."; } container keying-material { when "../enabled = 'true'"; description "Container for describing how an OSPF session is to be secured for an AC."; choice option { description "Options for OSPF authentication."; case auth-key-chain { leaf key-chain { type key-chain:key-chain-ref; description "Specifies the name of the key chain."; } } case auth-key-explicit { leaf key-id { type uint32; description "Specifies a key identifier."; } leaf key { type string; description "OSPF authentication key. This model only supports the subset of keys that are representable as ASCII strings."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Indicates the cryptographic algorithm associated with the key."; } } } } } } grouping isis-authentication { description "IS-IS authentication configuration."; container authentication { description "Container for IS-IS authentication parameters."; leaf enabled { type boolean; description "Enables or disables authentication."; } container keying-material { when "../enabled = 'true'"; description "Describes how an IS-IS session is secured over an AC."; choice option { description "Options for IS-IS authentication."; case auth-key-chain { leaf key-chain { type key-chain:key-chain-ref; description "Specifies the name of the key chain."; } } case auth-key-explicit { leaf key-id { type uint32; description "Indicates a key identifier."; } leaf key { type string; description "IS-IS authentication key. This model only supports the subset of keys that are representable as ASCII strings."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Indicates the cryptographic algorithm associated with the key."; } } } } } } grouping rip-authentication { description "RIP authentication configuration."; container authentication { description "Includes RIP authentication parameters."; leaf enabled { type boolean; description "Enables or disables authentication."; } container keying-material { when "../enabled = 'true'"; description "Describes how a RIP session is to be secured on an AC."; choice option { description "Specifies the authentication scheme."; case auth-key-chain { leaf key-chain { type key-chain:key-chain-ref; description "Indicates the name of the key chain."; } } case auth-key-explicit { leaf key { type string; description "Specifies a RIP authentication key. This model only supports the subset of keys that are representable as ASCII strings."; } leaf crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Indicates the cryptographic algorithm associated with the key."; } } } } } } // Basic routing parameters grouping bgp-peer-group-without-name { description "Identifies a BGP peer-group configured on the local system."; leaf local-as { type inet:as-number; description "Indicates a localASAutonomous System Number (ASN). This ASN is exposed to a customer so that it knows which ASN to use to set up a BGP session."; } leaf peer-as { type inet:as-number; description "Indicates the customer's ASN when the customer requests BGP routing."; } leaf address-family { type identityref { base vpn-common:address-family; } description "This node contains the address families to be activated. 'dual-stack' means that both IPv4 and IPv6 will be activated."; } leaf role { type identityref { base ac-common:bgp-role; } description "Specifies the BGP role (provider, customer, peer, etc.)."; reference "RFC 9234: Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, Section 4"; } } grouping bgp-peer-group-with-name { description "Identifies a BGP peer-group configured on the localsystem -system, identified by a peer-group name."; leaf name { type string; description "Specifies the name of the BGP peer-group."; } uses bgp-peer-group-without-name; } grouping ospf-basic { description "Includes configuration specific to OSPF."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both are to be activated."; } leaf area-id { type yang:dotted-quad; mandatory true; description "Specifies an area ID."; reference "RFC 4577: OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs), Section 4.2.3 RFC 6565: OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol, Section 4.2"; } leaf metric { type uint16; description "Metric of the AC. It is used in the routing state calculation and path selection."; } } grouping isis-basic { description "Basic configuration specific to IS-IS."; leaf address-family { type identityref { base vpn-common:address-family; } description "Indicates whether IPv4, IPv6, or both are to be activated."; } leaf area-address { type area-address; mandatory true; description "Specifies an area address."; } } // Static routing grouping ipv4-static-rtg-entry { description "Parameters to configure a specific IPv4 static routing entry."; leaf lan { type inet:ipv4-prefix; description "Indicates an IPv4 LAN prefix."; } leaf lan-tag { type string; description "Internal tag to be used in service policies."; } leaf next-hop { type union { type inet:ip-address; type predefined-next-hop; } description "The next hop that is to be used for the static route. This may be specified as an IP address or a predefined next-hop type (e.g., 'discard' or 'local-link')."; } leaf metric { type uint32; description "Indicates the metric associated with the static route."; } } grouping ipv4-static-rtg { description "A set of parameters specific to IPv4 static routing."; list ipv4-lan-prefixes { if-feature "vpn-common:ipv4"; key "lan next-hop"; description "List of LAN prefixes for the site."; uses ipv4-static-rtg-entry; uses ac-common:service-status; } } grouping ipv6-static-rtg-entry { description "Parameters to configure a specific IPv6 static routing entry."; leaf lan { type inet:ipv6-prefix; description "Indicates an IPv6 LAN prefix."; } leaf lan-tag { type string; description "Internal tag to be used in service (e.g., VPN) policies."; } leaf next-hop { type union { type inet:ip-address; type predefined-next-hop; } description "The next hop that is to be used for the static route. This may be specified as an IP address or a predefined next-hop type (e.g., 'discard' or 'local-link')."; } leaf metric { type uint32; description "Indicates the metric associated with the static route."; } } grouping ipv6-static-rtg { description "A set of parameters specific to IPv6 static routing."; list ipv6-lan-prefixes { if-feature "vpn-common:ipv6"; key "lan next-hop"; description "List of LAN prefixes for thecustomer terminatingcustomer-terminating points."; uses ipv6-static-rtg-entry; uses ac-common:service-status; } } // OAM grouping bfd { description "Groups a set of basic BFD parameters."; leaf holdtime { type uint32; units "milliseconds"; description "Specifies the expected BFD holdtime. The customer may impose some fixed values for the holdtime period if the provider allows the customer to use this function. If the provider doesn't allow the customer to use this function, fixed values will not be set."; reference "RFC 5880: Bidirectional Forwarding Detection (BFD), Section 6.8.18"; } } // redundancy grouping redundancy-group { description "A grouping for redundancy group."; list group { key "group-id"; description "Specifies a list of group identifiers."; leaf group-id { type string; description "Indicates the group-id to which an AC belongs."; } leaf precedence { type identityref { base ac-common:precedence-type; } description "Defines redundancy of an AC."; } } } // QoS grouping bandwidth-parameters { description "A grouping for bandwidth parameters."; leaf cir { type uint64; units "bps"; description "Committed Information Rate (CIR). The maximum number of bits that a port can receive or send during one second over an interface."; } leaf cbs { type uint64; units "bytes"; description "Committed Burst Size (CBS). CBS controls the bursty nature of the traffic. Traffic that does not use the configured CIR accumulates credits until the credits reach the configured CBS."; } leaf eir { type uint64; units "bps"; description "Excess Information Rate (EIR), i.e., excess frame delivery allowed not subject to a Service Level Agreement (SLA). The traffic rate can be limited by EIR."; } leaf ebs { type uint64; units "bytes"; description "Excess Burst Size (EBS). The bandwidth available for burst traffic from the EBS is subject to the amount of bandwidth that is accumulated during periods when traffic allocated by the EIR policy is not used."; } leaf pir { type uint64; units "bps"; description "Peak Information Rate (PIR), i.e., maximum frame delivery allowed. It is equal to or less than the sum of the CIR and EIR."; } leaf pbs { type uint64; units "bytes"; description "Peak Burst Size (PBS)."; } } grouping bandwidth-per-type { description "Grouping for bandwidth per type."; list bandwidth { key "bw-type"; description "List for bandwidth per type parameters."; leaf bw-type { type identityref { base vpn-common:bw-type; } description "Indicates the bandwidth type."; } choice type { description "Choice based upon bandwidth type."; case per-cos { description "Bandwidth per Class of Service (CoS)."; list cos { key "cos-id"; description "List of CoSes."; leaf cos-id { type uint8; description "Identifier of the CoS, indicated by a Differentiated Services Code Point (DSCP) or a CE-CLAN CoS (802.1p) value in the service frame."; reference "IEEE Std 802.1Q: Bridges and Bridged Networks"; } uses bandwidth-parameters; } } case other { description "Other bandwidth types."; uses bandwidth-parameters; } } } } } ]]></sourcecode> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <!--[rfced] *AD - We note that there is some text in the Security Considerations that differs from the template on <https://wiki.ietf.org/group/ops/yang-security-guidelines>. Please review and let us know if the text is acceptable. Specifically: - Paragraph 5 matches the template except for the last sentence is an addition. Paragraph 6 does not seem to correspond to the template. - This sentence is not present, although the template says to include it. "There are no particularly sensitive RPC or action operations." If it should be added, should it be at the end of the section? --> <t>This section is modeled after the template described in <xref section="3.7" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t> <t>The "ietf-ac-common" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>. These protocols have to use a secure transport layer (e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref target="RFC9000"/>) and have to use mutual authentication.</t> <t>The Network Configuration Access Control Model (NACM) <xref target="RFC8341"/> provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.</t> <t>The YANG module defines a set of identities, types, and groupings. These nodes are intended to be reused by other YANG modules. The module by itself does not expose any data nodes that are writable, data nodes that contain read-only state, or RPCs. As such, there are no additional security issues related to the YANG module that need to be considered.</t> <t>Modules that use the groupings that are defined in this document should identify the corresponding security considerations. For example, reusing some of these groupings will expose privacy-related information (e.g., 'ipv6-lan-prefixes' or 'ipv4-lan-prefixes'). Disclosing such information may be considered a violation of the customer-provider trust relationship.</t> <t>Several groupings ('bgp-authentication', 'ospf-authentication', 'isis-authentication', and 'rip-authentication') rely upon <xref target="RFC8177"/> for authentication purposes. As such, modules that will reuse these groupings will inherit the security considerations discussed in <xref section="5" sectionFormat="of" target="RFC8177"/>. Also, these groupings support supplying explicit keys as strings in ASCII format. The use of keys in hexadecimal string format would afford greater key entropy with the same number of key-string octets. However, such a format is not included in this version of the common AC model, because it is not supported by the underlying device modules (e.g., <xref target="RFC8695"/>).</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <t>IANAis requested to registerhas registered the following URI in the "ns" subregistry within the "IETF XML Registry" <xref target="RFC3688"/>:</t><artwork><![CDATA[ URI: urn:ietf:params:xml:ns:yang:ietf-ac-common Registrant Contact: The IESG. XML: N/A;<dl spacing="compact" newline="false"> <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-common</dd> <dt>Registrant Contact:</dt><dd>The IESG.</dd> <dt>XML:</dt><dd>N/A; the requested URI is an XMLnamespace. ]]></artwork>namespace.</dd> </dl> <t>IANAis requested to registerhas registered the following YANG module in the "YANG Module Names" subregistry <xref target="RFC6020"/> within the "YANG Parameters" registry:</t><artwork><![CDATA[ Name: ietf-ac-common Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-common Prefix: ac-common Maintained by IANA? N Reference: RFC XXXX ]]></artwork><dl spacing="compact" newline="false"> <dt>Name:</dt><dd>ietf-ac-common</dd> <dt>Maintained by IANA?</dt><dd>N</dd> <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-ac-common</dd> <dt>Prefix:</dt><dd>ac-common</dd> <dt>Reference:</dt><dd>RFC 9833</dd> </dl> </section> </middle> <back> <displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/> <displayreference target="I-D.ietf-teas-ietf-network-slice-nbi-yang" to="YANG-NSS"/> <displayreference target="I-D.ietf-netmod-schedule-yang" to="YANG-SCHEDULE"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <reference anchor="ISO10589" target="https://www.iso.org/standard/30932.html"> <front> <title>Information technology - Telecommunications and information exchange between systems - Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO8473)</title> <author><organization>ISO</organization><organization>ISO/IEC</organization> </author> <dateyear="2002"/> </front> </reference> <reference anchor="RFC8342"> <front> <title>Network Management Datastore Architecture (NMDA)</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/> <author fullname="P. Shafer" initials="P." surname="Shafer"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <author fullname="R. Wilton" initials="R." surname="Wilton"/> <date month="March" year="2018"/> <abstract> <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t> </abstract> </front> <seriesInfo name="RFC" value="8342"/> <seriesInfo name="DOI" value="10.17487/RFC8342"/> </reference> <reference anchor="RFC6991"> <front> <title>Common YANG Data Types</title> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <date month="July" year="2013"/> <abstract> <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t> </abstract>year="2002" month="November"/> </front> <seriesInfoname="RFC" value="6991"/> <seriesInfo name="DOI" value="10.17487/RFC6991"/> </reference> <reference anchor="RFC8177"> <front> <title>YANG Data Model for Key Chains</title> <author fullname="A. Lindem" initials="A." role="editor" surname="Lindem"/> <author fullname="Y. Qu" initials="Y." surname="Qu"/> <author fullname="D. Yeung" initials="D." surname="Yeung"/> <author fullname="I. Chen" initials="I." surname="Chen"/> <author fullname="J. Zhang" initials="J." surname="Zhang"/> <date month="June" year="2017"/> <abstract> <t>This document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.</t> </abstract> </front> <seriesInfo name="RFC" value="8177"/> <seriesInfo name="DOI" value="10.17487/RFC8177"/> </reference> <reference anchor="RFC8341"> <front> <title>Network Configuration Access Control Model</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <date month="March" year="2018"/> <abstract> <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t> <t>This document obsoletes RFC 6536.</t> </abstract> </front> <seriesInfo name="STD" value="91"/> <seriesInfo name="RFC" value="8341"/> <seriesInfo name="DOI" value="10.17487/RFC8341"/> </reference> <reference anchor="RFC9181"> <front> <title>A Common YANG Data Model for Layer 2 and Layer 3 VPNs</title> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <date month="February" year="2022"/> <abstract> <t>This document defines a common YANG module that is meant to be reused by various VPN-related modules such as Layer 3 VPN and Layer 2 VPN network models.</t> </abstract> </front> <seriesInfo name="RFC" value="9181"/> <seriesInfo name="DOI" value="10.17487/RFC9181"/> </reference> <reference anchor="RFC8077"> <front> <title>Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)</title> <author fullname="L. Martini" initials="L." role="editor" surname="Martini"/> <author fullname="G. Heron" initials="G." role="editor" surname="Heron"/> <date month="February" year="2017"/> <abstract> <t>Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode, and Ethernet) can be emulated over an MPLS backbone by encapsulating the Layer 2 Protocol Data Units (PDUs) and then transmitting them over pseudowires (PWs). It is also possible to use pseudowires to provide low-rate Time-Division Multiplexed and Synchronous Optical NETworking circuit emulation over an MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in other documents.</t> <t>This document is a rewrite of RFC 4447 for publication as an Internet Standard.</t> </abstract> </front> <seriesInfo name="STD" value="84"/> <seriesInfo name="RFC" value="8077"/> <seriesInfo name="DOI" value="10.17487/RFC8077"/> </reference> <reference anchor="RFC7348"> <front> <title>Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks</title> <author fullname="M. Mahalingam" initials="M." surname="Mahalingam"/> <author fullname="D. Dutt" initials="D." surname="Dutt"/> <author fullname="K. Duda" initials="K." surname="Duda"/> <author fullname="P. Agarwal" initials="P." surname="Agarwal"/> <author fullname="L. Kreeger" initials="L." surname="Kreeger"/> <author fullname="T. Sridhar" initials="T." surname="Sridhar"/> <author fullname="M. Bursell" initials="M." surname="Bursell"/> <author fullname="C. Wright" initials="C." surname="Wright"/> <date month="August" year="2014"/> <abstract> <t>This document describes Virtual eXtensible Local Area Network (VXLAN), which is used to address the need for overlay networks within virtualized data centers accommodating multiple tenants. The scheme and the related protocols can be used in networks for cloud service providers and enterprise data centers. This memo documents the deployed VXLAN protocol for the benefit of the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="7348"/> <seriesInfo name="DOI" value="10.17487/RFC7348"/> </reference> <reference anchor="RFC4271"> <front> <title>A Border Gateway Protocol 4 (BGP-4)</title> <author fullname="Y. Rekhter" initials="Y." role="editor" surname="Rekhter"/> <author fullname="T. Li" initials="T." role="editor" surname="Li"/> <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/> <date month="January" year="2006"/> <abstract> <t>This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.</t> <t>The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.</t> <t>BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.</t> <t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4271"/> <seriesInfo name="DOI" value="10.17487/RFC4271"/> </reference> <reference anchor="RFC4577"> <front> <title>OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)</title> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <author fullname="P. Psenak" initials="P." surname="Psenak"/> <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/> <date month="June" year="2006"/> <abstract> <t>Many Service Providers offer Virtual Private Network (VPN) services to their customers, using a technique in which customer edge routers (CE routers) are routing peers of provider edge routers (PE routers). The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. This is known as a "BGP/MPLS IP VPN". The base specification for BGP/MPLS IP VPNs presumes that the routing protocol on the interface between a PE router and a CE router is BGP. This document extends that specification by allowing the routing protocol on the PE/CE interface to be the Open Shortest Path First (OSPF) protocol.</t> <t>This document updates RFC 4364. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4577"/> <seriesInfo name="DOI" value="10.17487/RFC4577"/> </reference> <reference anchor="RFC6565"> <front> <title>OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol</title> <author fullname="P. Pillay-Esnault" initials="P." surname="Pillay-Esnault"/> <author fullname="P. Moyer" initials="P." surname="Moyer"/> <author fullname="J. Doyle" initials="J." surname="Doyle"/> <author fullname="E. Ertekin" initials="E." surname="Ertekin"/> <author fullname="M. Lundberg" initials="M." surname="Lundberg"/> <date month="June" year="2012"/> <abstract> <t>Many Service Providers (SPs) offer Virtual Private Network (VPN) services to their customers using a technique in which Customer Edge (CE) routers are routing peers of Provider Edge (PE) routers. The Border Gateway Protocol (BGP) is used to distribute the customer's routes across the provider's IP backbone network, and Multiprotocol Label Switching (MPLS) is used to tunnel customer packets across the provider's backbone. Support currently exists for both IPv4 and IPv6 VPNs; however, only Open Shortest Path First version 2 (OSPFv2) as PE-CE protocol is specified. This document extends those specifications to support OSPF version 3 (OSPFv3) as a PE-CE routing protocol. The OSPFv3 PE-CE functionality is identical to that of OSPFv2 except for the differences described in this document. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6565"/> <seriesInfo name="DOI" value="10.17487/RFC6565"/> </reference> <reference anchor="RFC1195"> <front> <title>Use of OSI IS-IS for routing in TCP/IP and dual environments</title> <author fullname="R. Callon" initials="R." surname="Callon"/> <date month="December" year="1990"/> <abstract> <t>This memo specifies an integrated routing protocol, based on the OSI Intra-Domain IS-IS Routing Protocol, which may be used as an interior gateway protocol (IGP) to support TCP/IP as well as OSI. This allows a single routing protocol to be used to support pure IP environments, pure OSI environments, and dual environments. This specification was developed by the IS-IS working group of the Internet Engineering Task Force. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="1195"/> <seriesInfo name="DOI" value="10.17487/RFC1195"/> </reference> <reference anchor="RFC5308"> <front> <title>Routing IPv6 with IS-IS</title> <author fullname="C. Hopps" initials="C." surname="Hopps"/> <date month="October" year="2008"/> <abstract> <t>This document specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol. The described method utilizes two new TLVs: a reachability TLV and an interface address TLV to distribute the necessary IPv6 information throughout a routing domain. Using this method, one can route IPv6 along with IPv4 and OSI using a single intra-domain routing protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5308"/> <seriesInfo name="DOI" value="10.17487/RFC5308"/> </reference> <reference anchor="RFC2453"> <front> <title>RIP Version 2</title> <author fullname="G. Malkin" initials="G." surname="Malkin"/> <date month="November" year="1998"/> <abstract> <t>This document specifies an extension of the Routing Information Protocol (RIP) to expand the amount of useful information carried in RIP messages and to add a measure of security. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="56"/> <seriesInfo name="RFC" value="2453"/> <seriesInfo name="DOI" value="10.17487/RFC2453"/> </reference> <reference anchor="RFC2080"> <front> <title>RIPng for IPv6</title> <author fullname="G. Malkin" initials="G." surname="Malkin"/> <author fullname="R. Minnear" initials="R." surname="Minnear"/> <date month="January" year="1997"/> <abstract> <t>This document specifies a routing protocol for an IPv6 internet. It is based on protocols and algorithms currently in wide use in the IPv4 Internet [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2080"/> <seriesInfo name="DOI" value="10.17487/RFC2080"/> </reference> <reference anchor="RFC5925"> <front> <title>The TCP Authentication Option</title> <author fullname="J. Touch" initials="J." surname="Touch"/> <author fullname="A. Mankin" initials="A." surname="Mankin"/> <author fullname="R. Bonica" initials="R." surname="Bonica"/> <date month="June" year="2010"/> <abstract> <t>This document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5925"/> <seriesInfo name="DOI" value="10.17487/RFC5925"/> </reference> <reference anchor="RFC3688"> <front> <title>The IETF XML Registry</title> <author fullname="M. Mealling" initials="M." surname="Mealling"/> <date month="January" year="2004"/> <abstract> <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t> </abstract> </front> <seriesInfo name="BCP" value="81"/> <seriesInfo name="RFC" value="3688"/> <seriesInfo name="DOI" value="10.17487/RFC3688"/> </reference> <reference anchor="RFC6020"> <front> <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <date month="October" year="2010"/> <abstract> <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6020"/> <seriesInfo name="DOI" value="10.17487/RFC6020"/>name="ISO/IEC" value="10589:2002"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9181.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8077.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7348.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4577.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6565.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5308.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2453.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2080.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <reference anchor="MEF6" target="https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.pdf"> <front><title>Technical Specification MEF 6, Ethernet<title>Ethernet Services Definitions - Phase I</title> <author> <organization>The Metro Ethernet Forum</organization> </author> <date year="2004"month="June"/>month="August"/> </front> <seriesInfo name="MEF" value="6"/> <refcontent>MEF Technical Specification</refcontent> </reference> <reference anchor="MEF17" target="https://www.mef.net/wp-content/uploads/2015/04/MEF-17.pdf"> <front><title>Technical Specification MEF 17, Service<title>Service OAM Requirements & Framework - Phase 1</title> <author> <organization>The Metro Ethernet Forum</organization> </author> <date year="2007" month="April"/> </front></reference> <reference anchor="RFC9408"> <front> <title>A YANG Network Data Model for Service Attachment Points (SAPs)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="O. Gonzalez de Dios" initials="O." surname="Gonzalez de Dios"/> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="Q. Wu" initials="Q." surname="Wu"/> <author fullname="V. Lopez" initials="V." surname="Lopez"/> <date month="June" year="2023"/> <abstract> <t>This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks).</t> <t>This document augments the 'ietf-network' data model defined in<seriesInfo name="MEF" value="17"/> <refcontent>MEF Technical Specification</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9408.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7665.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/> <!-- [RFC9834] draft-ietf-opsawg-teas-attachment-circuit-20 IESG State: RFC8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, suchEd Queue asLayer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model.</t> </abstract> </front> <seriesInfo name="RFC" value="9408"/> <seriesInfo name="DOI" value="10.17487/RFC9408"/> </reference> <reference anchor="RFC7665"> <front> <title>Service Function Chaining (SFC) Architecture</title> <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/> <author fullname="C. Pignataro" initials="C." role="editor" surname="Pignataro"/> <date month="October" year="2015"/> <abstract> <t>This document describes an architecture for the specification, creation, and ongoing maintenanceofService Function Chains (SFCs) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols.</t> </abstract> </front> <seriesInfo name="RFC" value="7665"/> <seriesInfo name="DOI" value="10.17487/RFC7665"/> </reference> <reference anchor="RFC4364"> <front> <title>BGP/MPLS IP Virtual Private Networks (VPNs)</title> <author fullname="E. Rosen" initials="E." surname="Rosen"/> <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/> <date month="February" year="2006"/> <abstract> <t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4364"/> <seriesInfo name="DOI" value="10.17487/RFC4364"/> </reference>03/04/25. --> <referenceanchor="I-D.ietf-opsawg-teas-attachment-circuit">anchor="RFC9834" target="https://www.rfc-editor.org/info/rfc9834"> <front> <title>YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS)</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <author initials="R." surname="Roberts" fullname="Richard Roberts"initials="R." surname="Roberts">role="editor"> <organization>Juniper</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil Giraldo" fullname="Samier Barguil Giraldo"> <organization>Nokia</organization> </author> <authorfullname="Bo Wu"initials="B."surname="Wu"> <organization>Huawei Technologies</organization> </author> <date day="9" month="January" year="2025"/> <abstract> <t> Delivery of network services assumes that appropriate setup is provisioned over the links that connect customer termination points and a provider network. The required setup to allow successful data exchange over these links is referred to as an attachment circuit (AC), while the underlying link is referred to as "bearer". This document specifies a YANG service data model for ACs. This model can be used for the provisioning of ACs before or during service provisioning (e.g., Network Slice Service). The document also specifies a YANG service model for managing bearers over which ACs are established. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-teas-attachment-circuit-19"/> </reference> <reference anchor="I-D.ietf-teas-ietf-network-slice-nbi-yang"> <front> <title>A YANG Data Model for the RFC 9543 Network Slice Service</title> <authorsurname="Wu" fullname="BoWu" initials="B." surname="Wu"> <organization>Huawei Technologies</organization> </author> <author fullname="Dhruv Dhody" initials="D." surname="Dhody">Wu"> <organization>Huawei Technologies</organization> </author><author fullname="Reza Rokui" initials="R." surname="Rokui"> <organization>Ciena</organization> </author> <author fullname="Tarek Saad" initials="T." surname="Saad"> <organization>Cisco Systems, Inc</organization> </author> <author fullname="John Mullooly" initials="J." surname="Mullooly"> <organization>Cisco Systems, Inc</organization> </author><dateday="21" month="January" year="2025"/> <abstract> <t> This document defines a YANG data model for RFC 9543 Network Slice Service. The model can be used in the Network Slice Service interface between a customer and a provider that offers RFC 9543 Network Slice Services. </t> </abstract>month="August" year="2025" /> </front> <seriesInfoname="Internet-Draft" value="draft-ietf-teas-ietf-network-slice-nbi-yang-18"/>name="RFC" value="9834"/> </reference> <!-- [I-D.ietf-teas-ietf-network-slice-nbi-yang] draft-ietf-teas-ietf-network-slice-nbi-yang-22 IESG State: IESG Evaluation as of 03/04/25. --> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-teas-ietf-network-slice-nbi-yang.xml"/> <!-- [RFC9835] draft-ietf-opsawg-ntw-attachment-circuit-16 IESG State: RFC Ed Queue as of 03/04/25. --> <referenceanchor="I-D.ietf-opsawg-ntw-attachment-circuit">anchor="RFC9835" target="https://www.rfc-editor.org/info/rfc9835"> <front> <title>A Network YANG Data Model for Attachment Circuits</title> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> </author> <author fullname="Richard Roberts" initials="R." surname="Roberts"> <organization>Juniper</organization> </author> <author fullname="Oscar Gonzalez de Dios"initials="O. G." surname="deinitials="O." surname="Gonzalez de Dios"> <organization>Telefonica</organization> </author> <author fullname="SamierBarguil"Barguil Giraldo" initials="S."surname="Barguil">surname="Barguil Giraldo"> <organization>Nokia</organization> </author> <author fullname="Bo Wu" initials="B." surname="Wu"> <organization>Huawei Technologies</organization> </author> <dateday="9" month="January"month="August" year="2025"/><abstract> <t> This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ntw-attachment-circuit-15"/> </reference> <reference anchor="RFC8969"> <front> <title>A Framework for Automating Service and Network Management with YANG</title> <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="D. Lopez" initials="D." surname="Lopez"/> <author fullname="C. Xie" initials="C." surname="Xie"/> <author fullname="L. Geng" initials="L." surname="Geng"/> <date month="January" year="2021"/> <abstract> <t>Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance.</t> <t>This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF.</t> </abstract> </front> <seriesInfo name="RFC" value="8969"/> <seriesInfo name="DOI" value="10.17487/RFC8969"/> </reference> <reference anchor="RFC8340"> <front> <title>YANG Tree Diagrams</title> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/> <date month="March" year="2018"/> <abstract> <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t> </abstract></front> <seriesInfoname="BCP" value="215"/> <seriesInfoname="RFC"value="8340"/> <seriesInfo name="DOI" value="10.17487/RFC8340"/>value="9835"/> </reference><reference anchor="RFC8466"> <front> <title>A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery</title> <author fullname="B. Wen" initials="B." surname="Wen"/> <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/> <author fullname="C. Xie" initials="C." surname="Xie"/> <author fullname="L. Jalil" initials="L." surname="Jalil"/> <date month="October" year="2018"/> <abstract> <t>This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document.</t> <t>The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624.</t> <t>The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8969.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8466.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8299.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9291.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9182.xml"/> <!-- [RFC9836] draft-ietf-opsawg-ac-lxsm-lxnm-glue-14 IESG State: RFC8342.</t> </abstract> </front> <seriesInfo name="RFC" value="8466"/> <seriesInfo name="DOI" value="10.17487/RFC8466"/> </reference> <reference anchor="RFC8299"> <front> <title>YANG Data Model for L3VPN Service Delivery</title> <author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/> <author fullname="S. Litkowski" initials="S." surname="Litkowski"/> <author fullname="L. Tomotaki" initials="L." surname="Tomotaki"/> <author fullname="K. Ogaki" initials="K." surname="Ogaki"/> <date month="January" year="2018"/> <abstract> <t>This document defines a YANG data model that can be used for communication between customers and network operators and to deliver a Layer 3 provider-provisioned VPN service. This document is limited to BGP PE-based VPNsEd Queue asdescribed in RFCs 4026, 4110, and 4364. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of the Layer 3 IP VPN service configuration components. It will be up to the management system to take this model as input and use specific configuration models to configure the different network elements to deliver the service. How the configurationofnetwork elements is done is out of scope for this document.</t> <t>This document obsoletes RFC 8049; it replaces the unimplementable module in that RFC with a new module with the same name that is not backward compatible. The changes are a series of small fixes to the YANG module and some clarifications to the text.</t> </abstract> </front> <seriesInfo name="RFC" value="8299"/> <seriesInfo name="DOI" value="10.17487/RFC8299"/> </reference> <reference anchor="RFC9291"> <front> <title>A YANG Network Data Model for Layer 2 VPNs</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="L. Munoz" initials="L." surname="Munoz"/> <date month="September" year="2022"/> <abstract> <t>This document defines an L2VPN Network Model (L2NM) that can be used to manage the provisioning of Layer 2 Virtual Private Network (L2VPN) services within a network (e.g., a service provider network). The L2NM complements the L2VPN Service Model (L2SM) by providing a network-centric view of the service that is internal to a service provider. The L2NM is particularly meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices.</t> <t>Also, this document defines a YANG module to manage Ethernet segments and the initial versions of two IANA-maintained modules that include a set of identities of BGP Layer 2 encapsulation types and pseudowire types.</t> </abstract> </front> <seriesInfo name="RFC" value="9291"/> <seriesInfo name="DOI" value="10.17487/RFC9291"/> </reference> <reference anchor="RFC9182"> <front> <title>A YANG Network Data Model for Layer 3 VPNs</title> <author fullname="S. Barguil" initials="S." surname="Barguil"/> <author fullname="O. Gonzalez de Dios" initials="O." role="editor" surname="Gonzalez de Dios"/> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="L. Munoz" initials="L." surname="Munoz"/> <author fullname="A. Aguado" initials="A." surname="Aguado"/> <date month="February" year="2022"/> <abstract> <t>As a complement to the Layer 3 Virtual Private Network Service Model (L3SM), which is used for communication between customers and service providers, this document defines an L3VPN Network Model (L3NM) that can be used for the provisioning of Layer 3 Virtual Private Network (L3VPN) services within a service provider network. The model provides a network-centric view of L3VPN services.</t> <t>The L3NM is meant to be used by a network controller to derive the configuration information that will be sent to relevant network devices. The model can also facilitate communication between a service orchestrator and a network controller/orchestrator.</t> </abstract> </front> <seriesInfo name="RFC" value="9182"/> <seriesInfo name="DOI" value="10.17487/RFC9182"/> </reference>03/04/25. --> <referenceanchor="I-D.ietf-opsawg-ac-lxsm-lxnm-glue">anchor="RFC9836" target="https://www.rfc-editor.org/info/rfc9836"> <front> <title>A YANG Data Model for Augmenting VPN Service and Network Models with Attachment Circuits</title> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Richard Roberts"initials="R."surname="Roberts">surname="Roberts" fullname="Richard Roberts"> <organization>Juniper</organization> </author> <authorfullname="Samier Barguil"initials="S."surname="Barguil">surname="Barguil Giraldo" fullname="Samier Barguil Giraldo"> <organization>Nokia</organization> </author> <author initials="O." surname="Gonzalez de Dios" fullname="Oscar Gonzalez deDios" initials="O. G." surname="deDios"> <organization>Telefonica</organization> </author> <dateday="9" month="January" year="2025"/> <abstract> <t> The document specifies a module that updates existing service (i.e., the Layer 2 Service Model (L2SM) and the Layer 3 Service Model (L3SM)) and network (i.e., the Layer 2 Network Model (L2NM) and the Layer 3 Network Model (L3NM)) Virtual Private Network (VPN) modules with the required information to bind specific VPN services to attachment circuits (ACs) that are created using the AC service ("ietf-ac-svc") and network ("ietf-ac-ntw") models. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ac-lxsm-lxnm-glue-13"/> </reference> <reference anchor="RFC4862"> <front> <title>IPv6 Stateless Address Autoconfiguration</title> <author fullname="S. Thomson" initials="S." surname="Thomson"/> <author fullname="T. Narten" initials="T." surname="Narten"/> <author fullname="T. Jinmei" initials="T." surname="Jinmei"/> <date month="September" year="2007"/> <abstract> <t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4862"/> <seriesInfo name="DOI" value="10.17487/RFC4862"/> </reference> <reference anchor="RFC2003"> <front> <title>IP Encapsulation within IP</title> <author fullname="C. Perkins" initials="C." surname="Perkins"/> <date month="October" year="1996"/> <abstract> <t>This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="2003"/> <seriesInfo name="DOI" value="10.17487/RFC2003"/> </reference> <reference anchor="RFC4301"> <front> <title>Security Architecture for the Internet Protocol</title> <author fullname="S. Kent" initials="S." surname="Kent"/> <author fullname="K. Seo" initials="K." surname="Seo"/> <date month="December" year="2005"/> <abstract> <t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4301"/> <seriesInfo name="DOI" value="10.17487/RFC4301"/> </reference> <reference anchor="RFC1701"> <front> <title>Generic Routing Encapsulation (GRE)</title> <author fullname="S. Hanks" initials="S." surname="Hanks"/> <author fullname="T. Li" initials="T." surname="Li"/> <author fullname="D. Farinacci" initials="D." surname="Farinacci"/> <author fullname="P. Traina" initials="P." surname="Traina"/> <date month="October" year="1994"/> <abstract> <t>This document specifies a protocol for performing encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract> </front> <seriesInfo name="RFC" value="1701"/> <seriesInfo name="DOI" value="10.17487/RFC1701"/> </reference> <reference anchor="RFC1702"> <front> <title>Generic Routing Encapsulation over IPv4 networks</title> <author fullname="S. Hanks" initials="S." surname="Hanks"/> <author fullname="T. Li" initials="T." surname="Li"/> <author fullname="D. Farinacci" initials="D." surname="Farinacci"/> <author fullname="P. Traina" initials="P." surname="Traina"/> <date month="October" year="1994"/> <abstract> <t>This memo addresses the case of using IP as the delivery protocol or the payload protocol and the special case of IP as both the delivery and payload. This memo also describes using IP addresses and autonomous system numbers as part of a GRE source route. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t> </abstract>month="August" year="2025" /> </front> <seriesInfo name="RFC"value="1702"/> <seriesInfo name="DOI" value="10.17487/RFC1702"/>value="9836" /> </reference><reference anchor="RFC7676"> <front> <title>IPv6 Support for Generic Routing Encapsulation (GRE)</title> <author fullname="C. Pignataro" initials="C." surname="Pignataro"/> <author fullname="R. Bonica" initials="R." surname="Bonica"/> <author fullname="S. Krishnan" initials="S." surname="Krishnan"/> <date month="October" year="2015"/> <abstract> <t>Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.</t> <t>This document specifies GRE procedures for IPv6, used<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2003.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1701.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1702.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6004.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6215.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3644.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/> <!-- [I-D.ietf-netmod-schedule-yang] draft-ietf-netmod-schedule-yang-04 IESG State: I-D Exists aseither the payload or delivery protocol.</t> </abstract> </front> <seriesInfo name="RFC" value="7676"/> <seriesInfo name="DOI" value="10.17487/RFC7676"/> </reference> <reference anchor="RFC6004"> <front> <title>Generalized MPLS (GMPLS) Support for Metro Ethernet Forum and G.8011 Ethernet Service Switching</title> <author fullname="L. Berger" initials="L." surname="Berger"/> <author fullname="D. Fedyk" initials="D." surname="Fedyk"/> <date month="October" year="2010"/> <abstract> <t>This document describes a method for controlling two specific types of Ethernet switching via Generalized Multi-Protocol Label Switching (GMPLS). This document supports the typesofswitching corresponding to the Ethernet services that have been defined in the context of the Metro Ethernet Forum (MEF) and International Telecommunication Union (ITU) G.8011. Specifically, switching in support of Ethernet private line and Ethernet virtual private line services are covered. Support for MEF- and ITU-defined parameters is also covered.</t> </abstract> </front> <seriesInfo name="RFC" value="6004"/> <seriesInfo name="DOI" value="10.17487/RFC6004"/> </reference> <reference anchor="RFC6215"> <front> <title>MPLS Transport Profile User-to-Network and Network-to-Network Interfaces</title> <author fullname="M. Bocci" initials="M." surname="Bocci"/> <author fullname="L. Levrau" initials="L." surname="Levrau"/> <author fullname="D. Frost" initials="D." surname="Frost"/> <date month="April" year="2011"/> <abstract> <t>The framework for MPLS in transport networks (RFC 5921) provides reference models for the MPLS Transport Profile (MPLS-TP) Transport Service Interfaces, which are a User-to-Network Interface (UNI), and a Network-to-Network Interface (NNI). This document updates those reference models to show detailed reference points for these interfaces, along with further clarification of the functional architecture of MPLS-TP at a UNI and NNI.</t> <t>This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes.</t> </abstract> </front> <seriesInfo name="RFC" value="6215"/> <seriesInfo name="DOI" value="10.17487/RFC6215"/> </reference> <reference anchor="RFC9234"> <front> <title>Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages</title> <author fullname="A. Azimov" initials="A." surname="Azimov"/> <author fullname="E. Bogomazov" initials="E." surname="Bogomazov"/> <author fullname="R. Bush" initials="R." surname="Bush"/> <author fullname="K. Patel" initials="K." surname="Patel"/> <author fullname="K. Sriram" initials="K." surname="Sriram"/> <date month="May" year="2022"/> <abstract> <t>Route leaks are the propagation of BGP prefixes that violate assumptions of BGP topology relationships, e.g., announcing a route learned from one transit provider to another transit provider or a lateral (i.e., non-transit) peer or announcing a route learned from one lateral peer to another lateral peer or a transit provider. These are usually the result of misconfigured or absent BGP route filtering or lack of coordination between autonomous systems (ASes). Existing approaches to leak prevention rely on marking routes by operator configuration, with no check that the configuration corresponds to that of the External BGP (eBGP) neighbor, or enforcement of the two eBGP speakers agreeing on the peering relationship. This document enhances the BGP OPEN message to establish an agreement of the peering relationship on each eBGP session between autonomous systems in order to enforce appropriate configuration on both sides. Propagated routes are then marked according to the agreed relationship, allowing both prevention and detection of route leaks.</t> </abstract> </front> <seriesInfo name="RFC" value="9234"/> <seriesInfo name="DOI" value="10.17487/RFC9234"/> </reference> <reference anchor="RFC3644"> <front> <title>Policy Quality of Service (QoS) Information Model</title> <author fullname="Y. Snir" initials="Y." surname="Snir"/> <author fullname="Y. Ramberg" initials="Y." surname="Ramberg"/> <author fullname="J. Strassner" initials="J." surname="Strassner"/> <author fullname="R. Cohen" initials="R." surname="Cohen"/> <author fullname="B. Moore" initials="B." surname="Moore"/> <date month="November" year="2003"/> <abstract> <t>This document presents an object-oriented information model for representing Quality of Service (QoS) network management policies. This document is based on the IETF Policy Core Information Model and its extensions. It defines an information model for QoS enforcement for differentiated and integrated services using policy. It is important to note that this document defines an information model, which by definition is independent of any particular data storage mechanism and access protocol.</t> </abstract> </front> <seriesInfo name="RFC" value="3644"/> <seriesInfo name="DOI" value="10.17487/RFC3644"/> </reference> <reference anchor="RFC5880"> <front> <title>Bidirectional Forwarding Detection (BFD)</title> <author fullname="D. Katz" initials="D." surname="Katz"/> <author fullname="D. Ward" initials="D." surname="Ward"/> <date month="June" year="2010"/> <abstract> <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="5880"/> <seriesInfo name="DOI" value="10.17487/RFC5880"/> </reference>03/04/25. --> <referenceanchor="I-D.ietf-netmod-schedule-yang">anchor="I-D.ietf-netmod-schedule-yang" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-schedule-yang-04"> <front> <title>A Common YANG Data Model for Scheduling</title> <author initials="Q." surname="Ma" fullname="Qiufang Ma"initials="Q." surname="Ma">role="editor"> <organization>Huawei</organization> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu">surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Daniel King"initials="D."surname="King">surname="King" fullname="Daniel King"> <organization>Lancaster University</organization> </author> <dateday="10" month="October" year="2024"/> <abstract> <t> This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes a set of recurrence related groupings with varying granularity levels (i.e., from basic to advanced). </t> </abstract>month="February" day="7" year="2025" /> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-netmod-schedule-yang-03"/> </reference> <reference anchor="RFC4552"> <front> <title>Authentication/Confidentiality for OSPFv3</title> <author fullname="M. Gupta" initials="M." surname="Gupta"/> <author fullname="N. Melam" initials="N." surname="Melam"/> <date month="June" year="2006"/> <abstract> <t>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4552"/> <seriesInfo name="DOI" value="10.17487/RFC4552"/>value="draft-ietf-netmod-schedule-yang-04" /> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/> <!-- [I-D.ietf-netmod-rfc8407bis] draft-ietf-netmod-rfc8407bis-22 IESG State: Publication Requested as of 03/04/25. --> <referenceanchor="I-D.ietf-netmod-rfc8407bis">anchor="I-D.ietf-netmod-rfc8407bis" target="https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-22"> <front> <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title> <authorfullname="Andy Bierman"initials="A."surname="Bierman">surname="Bierman" fullname="Andy Bierman"> <organization>YumaWorks</organization> </author> <author initials="M." surname="Boucadair" fullname="Mohamed Boucadair"initials="M." surname="Boucadair">role="editor"> <organization>Orange</organization> </author> <authorfullname="Qin Wu"initials="Q."surname="Wu">surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> </author> <dateday="14"month="January"year="2025"/> <abstract> <t> This memo provides guidelines for authors and reviewers of specifications containing YANG modules, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. The document also updates RFC 6020 by clarifying how modules and their revisions are handled by IANA. </t> </abstract>day="14" year="2025" /> </front> <seriesInfo name="Internet-Draft"value="draft-ietf-netmod-rfc8407bis-22"/> </reference> <reference anchor="RFC6241"> <front> <title>Network Configuration Protocol (NETCONF)</title> <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/> <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/> <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/> <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/> <date month="June" year="2011"/> <abstract> <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="6241"/> <seriesInfo name="DOI" value="10.17487/RFC6241"/> </reference> <reference anchor="RFC8040"> <front> <title>RESTCONF Protocol</title> <author fullname="A. Bierman" initials="A." surname="Bierman"/> <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/> <author fullname="K. Watsen" initials="K." surname="Watsen"/> <date month="January" year="2017"/> <abstract> <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t> </abstract> </front> <seriesInfo name="RFC" value="8040"/> <seriesInfo name="DOI" value="10.17487/RFC8040"/> </reference> <reference anchor="RFC4252"> <front> <title>The Secure Shell (SSH) Authentication Protocol</title> <author fullname="T. Ylonen" initials="T." surname="Ylonen"/> <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/> <date month="January" year="2006"/> <abstract> <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="RFC" value="4252"/> <seriesInfo name="DOI" value="10.17487/RFC4252"/> </reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t> </abstract> </front> <seriesInfo name="RFC" value="8446"/> <seriesInfo name="DOI" value="10.17487/RFC8446"/> </reference> <reference anchor="RFC9000"> <front> <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title> <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/> <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/> <date month="May" year="2021"/> <abstract> <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t> </abstract> </front> <seriesInfo name="RFC" value="9000"/> <seriesInfo name="DOI" value="10.17487/RFC9000"/> </reference> <reference anchor="RFC8695"> <front> <title>A YANG Data Model for the Routing Information Protocol (RIP)</title> <author fullname="X. Liu" initials="X." surname="Liu"/> <author fullname="P. Sarda" initials="P." surname="Sarda"/> <author fullname="V. Choudhary" initials="V." surname="Choudhary"/> <date month="February" year="2020"/> <abstract> <t>This document describes a data model for the management of the Routing Information Protocol (RIP). Both RIP version 2 and RIPng are covered. The data model includes definitions for configuration, operational state, and Remote Procedure Calls (RPCs).</t> <t>The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA).</t> </abstract> </front> <seriesInfo name="RFC" value="8695"/> <seriesInfo name="DOI" value="10.17487/RFC8695"/>value="draft-ietf-netmod-rfc8407bis-22" /> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8695.xml"/> </references> </references> <?line 2410?> <section anchor="AC-Common-Tree"> <name>Full Tree</name><artwork><![CDATA[<sourcecode type="yangtree"><![CDATA[ module: ietf-ac-common grouping service-status: +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping ac-profile-cfg: +-- valid-provider-identifiers +-- encryption-profile-identifier* [id] | +-- id string +-- qos-profile-identifier* [id] | +-- id string +-- failure-detection-profile-identifier* [id] | +-- id string +-- forwarding-profile-identifier* [id] | +-- id string +-- routing-profile-identifier* [id] +-- id string grouping op-instructions: +-- requested-start? yang:date-and-time +-- requested-stop? yang:date-and-time +--ro actual-start? yang:date-and-time +--ro actual-stop? yang:date-and-time grouping dot1q: +-- tag-type? identityref +-- cvlan-id? uint16 grouping priority-tagged: +-- tag-type? identityref grouping qinq: +-- tag-type? identityref +-- svlan-id uint16 +-- cvlan-id uint16 grouping pseudowire: +-- vcid? uint32 +-- far-end? union grouping vpls: +-- vcid? uint32 +-- far-end* union grouping vxlan: +-- vni-id uint32 +-- peer-mode? identityref +-- peer-ip-address* inet:ip-address grouping l2-tunnel-service: +-- type? identityref +-- pseudowire | +-- vcid? uint32 | +-- far-end? union +-- vpls | +-- vcid? uint32 | +-- far-end* union +-- vxlan +-- vni-id uint32 +-- peer-mode? identityref +-- peer-ip-address* inet:ip-address grouping ipv4-allocation-type: +-- prefix-length? uint8 +-- address-allocation-type? identityref grouping ipv6-allocation-type: +-- prefix-length? uint8 +-- address-allocation-type? identityref grouping ipv4-connection-basic: +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) +-- (provider-dhcp)? | +--:(dhcp-service-type) | +-- dhcp-service-type? enumeration +-- (dhcp-relay)? +--:(customer-dhcp-servers) +-- customer-dhcp-servers +-- server-ip-address* inet:ipv4-address grouping ipv6-connection-basic: +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) +-- (provider-dhcp)? | +--:(dhcp-service-type) | +-- dhcp-service-type? enumeration +-- (dhcp-relay)? +--:(customer-dhcp-servers) +-- customer-dhcp-servers +-- server-ip-address* inet:ipv6-address grouping ipv4-connection: +-- local-address? inet:ipv4-address +-- virtual-address? inet:ipv4-address +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) | +-- (address-assign)? | | +--:(number) | | | +-- number-of-dynamic-address? uint16 | | +--:(explicit) | | +-- customer-addresses | | +-- address-pool* [pool-id] | | +-- pool-id string | | +-- start-address inet:ipv4-address | | +-- end-address? inet:ipv4-address | +-- (provider-dhcp)? | | +--:(dhcp-service-type) | | +-- dhcp-service-type? enumeration | +-- (dhcp-relay)? | +--:(customer-dhcp-servers) | +-- customer-dhcp-servers | +-- server-ip-address* inet:ipv4-address +--:(static-addresses) +-- address* [address-id] +-- address-id string +-- customer-address? inet:ipv4-address grouping ipv6-connection: +-- local-address? inet:ipv6-address +-- virtual-address? inet:ipv6-address +-- prefix-length? uint8 +-- address-allocation-type? identityref +-- (allocation-type)? +--:(dynamic) | +-- (address-assign)? | | +--:(number) | | | +-- number-of-dynamic-address? uint16 | | +--:(explicit) | | +-- customer-addresses | | +-- address-pool* [pool-id] | | +-- pool-id string | | +-- start-address inet:ipv6-address | | +-- end-address? inet:ipv6-address | +-- (provider-dhcp)? | | +--:(dhcp-service-type) | | +-- dhcp-service-type? enumeration | +-- (dhcp-relay)? | +--:(customer-dhcp-servers) | +-- customer-dhcp-servers | +-- server-ip-address* inet:ipv6-address +--:(static-addresses) +-- address* [address-id] +-- address-id string +-- customer-address? inet:ipv6-address grouping bgp-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(ao) | +-- enable-ao? boolean | +-- ao-keychain? key-chain:key-chain-ref +--:(md5) | +-- md5-keychain? key-chain:key-chain-ref +--:(explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping ospf-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping isis-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key-id? uint32 +-- key? string +-- crypto-algorithm? identityref grouping rip-authentication: +-- authentication +-- enabled? boolean +-- keying-material +-- (option)? +--:(auth-key-chain) | +-- key-chain? key-chain:key-chain-ref +--:(auth-key-explicit) +-- key? string +-- crypto-algorithm? identityref grouping bgp-peer-group-without-name: +-- local-as? inet:as-number +-- peer-as? inet:as-number +-- address-family? identityref +-- role? identityref grouping bgp-peer-group-with-name: +-- name? string +-- local-as? inet:as-number +-- peer-as? inet:as-number +-- address-family? identityref +-- role? identityref grouping ospf-basic: +-- address-family? identityref +-- area-id yang:dotted-quad +-- metric? uint16 grouping isis-basic: +-- address-family? identityref +-- area-address area-address grouping ipv4-static-rtg-entry: +-- lan? inet:ipv4-prefix +-- lan-tag? string +-- next-hop? union +-- metric? uint32 grouping ipv4-static-rtg: +-- ipv4-lan-prefixes* [lan next-hop] {vpn-common:ipv4}? +-- lan inet:ipv4-prefix +-- lan-tag? string +-- next-hop union +-- metric? uint32 +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping ipv6-static-rtg-entry: +-- lan? inet:ipv6-prefix +-- lan-tag? string +-- next-hop? union +-- metric? uint32 grouping ipv6-static-rtg: +-- ipv6-lan-prefixes* [lan next-hop] {vpn-common:ipv6}? +-- lan inet:ipv6-prefix +-- lan-tag? string +-- next-hop union +-- metric? uint32 +-- status +-- admin-status | +-- status? identityref | +--ro last-change? yang:date-and-time +--ro oper-status +--ro status? identityref +--ro last-change? yang:date-and-time grouping bfd: +-- holdtime? uint32 grouping redundancy-group: +-- group* [group-id] +-- group-id string +-- precedence? identityref grouping bandwidth-parameters: +-- cir? uint64 +-- cbs? uint64 +-- eir? uint64 +-- ebs? uint64 +-- pir? uint64 +-- pbs? uint64 grouping bandwidth-per-type: +-- bandwidth* [bw-type] +-- bw-type identityref +-- (type)? +--:(per-cos) | +-- cos* [cos-id] | +-- cos-id uint8 | +-- cir? uint64 | +-- cbs? uint64 | +-- eir? uint64 | +-- ebs? uint64 | +-- pir? uint64 | +-- pbs? uint64 +--:(other) +-- cir? uint64 +-- cbs? uint64 +-- eir? uint64 +-- ebs? uint64 +-- pir? uint64 +-- pbs? uint64]]></artwork>]]></sourcecode> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The document reuses many of the structures that were defined in <xref target="RFC9181"/> and <xref target="RFC9182"/>.</t> <t>Thanks toEbben Aries<contact fullname="Ebben Aries"/> for the YANG Doctors review,Andy Smith<contact fullname="Andy Smith"/> andGyanh Mishra<contact fullname="Gyanh Mishra"/> for thertg-dirRTGDIR reviews,Watson Ladd<contact fullname="Watson Ladd"/> for thesec-dirSECDIR review, andBehcet Sarikaya<contact fullname="Behcet Sarikaya"/> for thegenartGENART review.</t> <t>Thanks toReza Rokui<contact fullname="Reza Rokui"/> for theShepherdshepherd review.</t> <t>Thanks toMahesh Jethanandani<contact fullname="Mahesh Jethanandani"/> for the AD review.</t> <t>Thanks toÉric Vyncke, Gunter<contact fullname="Éric Vyncke"/>, <contact fullname="Gunter Van deVelde, Orie Steele,Velde"/>, <contact fullname="Orie Steele"/>, andPaul Wouters<contact fullname="Paul Wouters"/> for the IESG review.</t> </section> <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> <name>Contributors</name> <contact initials="V." surname="Lopez" fullname="Victor Lopez"> <organization>Nokia</organization> <address> <email>victor.lopez@nokia.com</email> </address> </contact> <contact initials="I." surname="Bykov" fullname="Ivan Bykov"> <organization>Ribbon Communications</organization> <address> <email>Ivan.Bykov@rbbn.com</email> </address> </contact> <contact initials="Q." surname="Wu" fullname="Qin Wu"> <organization>Huawei</organization> <address> <email>bill.wu@huawei.com</email> </address> </contact> <contact initials="K." surname="Ogaki" fullname="Kenichi Ogaki"> <organization>KDDI</organization> <address> <email>ke-oogaki@kddi.com</email> </address> </contact> <contact initials="L. A." surname="Munoz" fullname="Luis Angel Munoz"> <organization>Vodafone</organization> <address> <email>luis-angel.munoz@vodafone.com</email> </address> </contact> </section> </back> <!--##markdown-source: H4sIAAAAAAAAA+19a3PbRrLod1bd/zBHqboSE4LWy7St7K4jS3JW59iyVnKS PbU35xRIgBTWJMAAoGStrfP9/q77x24/5gkMQNJyYm/WrK2sTM709PT09HT3 9HQHQdApk3IaH4iNQ3GUzWZZKv7z8Ox7cRyWoXiZRfFUjLNcHJZlOLqaxWkp jpJ8tEjKYqMTDod5fA1dZcd6I4K10RmFZTzJ8tsDUZRRpxNlozScwZhRHo7L IInLcZDNi/BmEpRxWAQjAheEo2DnYadYDGdJUSRZWt7Ooc/pyevnnXQxG8b5 QScCwAedUZYWcVosigNR5ou4AyjtdcI8DgG1V/M4D0voXYgwjcTLMA0nMaK4 0bnJ8jeTPFvM25qJQ4AjfoKmSToR32Pzjc6b+BY6RwcdEYjLaTKKxWWcX8P/ 4xcv9n48P6M/duUfh4symxF0/NdZXOLIlW9f5aOruChz/UXBEAWsQHId57c0 lvxunmfXCZIEcLLbFvEEca7BGE/jt8kwmSblrdM8mc2nyTgZ1XCzprP3/fm5 8xPMF4cNF+VVliMJOgI+48V0yov6MruC/4/Es2wxCqMwyen3LJ+EafIPGukA Zhumk5h+yDPkvjhKyoxbxrMwmR6IGYPpDxWY7zLq1Afu6NRHvUhGV2EeiYsM GKMsPGP++yJNYJVbB81z7v7d37lxP41Lz2CvilGYi++z9B/hNP4HLJE4TjLf mK/jaTyGZRqF9igZdu9PZPcI0MiK70rdtGGGl+EsiXPxLMwni2Qqvk/ycBpl nkHPsjeJM15BPftD7vnfE+75XYrtGgZ7lomfFh7Yf16EN3EC8xpdpdk0myRx YY80hX3Tv1kMs++uqCFDh/1Z5skQ+B35RY7F4/yYjOBb8SKbx/9Qw3lmcE3N +lNs5uDtADu9DlPx7PZNdm1AXSTDIYgmlFCLVHK6gzJ26lOn7/LhMPXB/UuS WtRQRLCBwN6awrydWbsw/iOG0a8S8WoSvkkMqP84Pj61Ab2JgyzDJt+9iSIv oBeLpBCHsBGm4uUizSyq/ZhFIXBQ7CwItA5w20z7M2z93bVsxKDTLEcRdB3j upxevtrZfvj4yQEBkMfCaTrmNkDEUq36LcgDZO2RQ1WSnInVPn4LexLGFkOQ HXGciuK2KONZAb1P0zLOYXsnIMDFJX0tysz7dQLMEwYRyEpYBpC/ZYyS2DsO yMUyG2V8ZC2KGFoJYD7YzCNqeJOUV6K8qjQkaRohUPwJ2qcxNZ/GRRHM4AgU qZR9SnBuAake7z/a6xKltCQUeingd/onnU9id3t7l2kKOzAuD8RVWc6LgwcP bm5u+kmR9aHPg6IE8oEEe7C3/WRvt39Vzqadjp4lr9DLk+cDZ3VoHwL9p+Jy Ho+0KMeGYtATJzChHJBX8rwQx/E4SRNerkCcX4VApNOmWbwGcryMyzwzgJ5n +WJmTQ2Eaozz22+c3yweoxR9cFgUcVk80Bj/t4Nx8eD8+PkDQPu/B/15NO7w ZHcerTzbnUc9fTy+OnwpLuJfFklOR3gh/rd4nsPmoTVUs965x6zF4TwHEQzz frR03jfzAOUf4PFgMZ9mYVQ82N3eefhgex+nG+w84vkGQSDCISoAIzhxEAfQ khakgRQ8WVi9ULBqJEKjaY2kOia2Do+KLitvyLTTnri5ApEjQFxEcZFMUjiT YYsNY5HHiyIcTmFf3ooM58gdij7MXbfGfrM4hBGgE2pXOe2NIilKUouOQJfL F6MSvgfEAKmJhAK7KCzFDA6N+WKK+xjw6iMJYZ+GoHDEPWgBwOVUqJMYgeSW mAGagJfaagom4PB2nhUETYRICtmiV2uKw+e8/CCYU9rZujlCwn+UIhsjrJ7e 3Ci9orgyqNa0uG1cjvq8VrMkiqZxp/MVyqw8ixYkMjqdIyk+rkHXUmMCtrlU 2iKenRyThhgtClAE47yAUy4UqA2gugxrBZIwSYHDAf15liAfb8X9Sd/w+XMp 1+CHy+dFtyeOJChxDpyfFDDwCZBhTnyydXR+gm1Q7UyzWbYolIB9Bqos9LlA 0ZojH10+u8CWEZoAozilbyeA0014CzSAhSQxjRvjREnec0Kw2xeHWoDaFJAM VDBMYPK0GMOQ4zybiS0ACCwH8yQG7cLyTEDepXUCILWwdZYnE/whJgBdycN1 evXFq+HfCRUYGSV9sYD9EPoxnIW3yIEpGCplQguADBFO8hj+XMyzVJ9ioV4y bqI5SK5wDiyC7E6M6E4YJlCGb4AXpiEMiccRnFDyQKKuClZPgPGUIKcXC1Sm CVYYAVfjtIF9F3P8WbMnNMmucQCANU3SN4WepDrWJMqbhU2ojmQsxMuDhdgC mwsF7vS2B/M8Vz+fRLDkW+cn3S7u5TiPh7edOAWRgqMBkYHlC9AlefLqdJbS BZCCX8P81rFicDJ5DCTKiQk6RBaURUoIwpbfqEu9DZR6XZJ0IM5wCosUEJze IkikQ8eFi2Cw1cYwhi2Zb8BK/XTlLilKDuDGgtb1xkgZWgHFLFJcwepkI2YW Ui3AyiqIrD75DByBPKYkE6KRpHjqI7uhhAGBhCN6+vYRS2ZyMBJjr/hHEWMJ D5Ry8zAvkxEI4VwjjpsA7KQ46kiRvZiWCchkI6qieB6nEaDLjCkPnxF+P81u cUwg2glL8gJxbkYGWAdxgbV8924xurtD6aBFFPPQ0Um3I3ce2NnT5B+475D2 86vbgo76FBUwQDsUaG7gNzASbFw4UlB6II6SWzeLDphsiDDueGTYoxPkqxIg lxpuDGMrAWo5LEiAgRw9PO8Ctk8vnh892d9+DDh3jk4Ktd4V+haw1IZ0Sjq/ CG9hiD0wbfJyAeie58k1blplQG/9eH7W7aDRQw13Bf4bZ4iDXGVF6VmURsHP qD4aDB7e3XX7nUOF0+FRD+d7ncQ3fOJYdNLbvKeEHtjYKc0JBAnxaYbnFVCq A/TQo28cnexskMiDv3Y3unyoMw/jDoHxoqSAjVSoRUfc9vcG+3d3PT0pTU/m G6bk+YkRX2Ct+jhcio9wDtiHpNZ0tHCSzInbEHczQlHEBQ06D7WmomU4NgHu wMnAnx2t4C/m8yynzc/4ElfIZUD2leSFrki6cFpkWpzGZoqooxii7Wmi7W90 lVYmKT8K8zyxhTfNHk9EkiSjUrCkAhHQ+R/4iDAsridSXa19+oHn0/9fTc3f e7+E5hJOf3nzPrXaGu509fAwnmr5jQvFB+A9tzo8gv98ozGAb4HZZI/37QDO T2wAQG4EsMkz2HS69WtTws8mNdsa7nbpb+xVoZiC/835CYNSW1nj61DsvQO4 iWJ7XoqtMuFmiu1Kkm+2A6hSbL9GMdEKQFFsT1LsmxrFvP0N+StA3zf23jRs /A1jXUexuXcNZR9+q/T275SVe1uzYKrLD1Bta/i2K/4oN7k4jcRb2uaddwfi q8WIDd8/btrHLciWTThfiQEDODEn6R83WEnfuEPD0VaaPJYjmDYLEGBbG+R1 D0fS2b7RJQXZa1e+e1fEo4A74ilDFrKEs7px2RNKVWRjADW05fbkAme9ikEZ Vya4jkEZhEUQBupwBY0yDC+7SoDDKXYaHPdrlxSGVIEkFdAGJbdnrLUsUjWw 7XDXFwwOOoQH/SXPr6DAtkE6TIJbULkBIVit05KPWzyrgCKKHurIa7B1W6af ljcNs6+Z0D25ksQIeIa9NgsFKy7XCqahTMMkhYYJKRT6rFZsIDEio9GiXWUi oIWAFiiVj8dPBk9IMaKByTdCw7DToWZkAD+iv03bQ2oJrOsgvBcDDRYW8jAf XSVlzHrF1tnL48MuTH5MZixpP/+GCOzt76IS2fnqK9B48bohAZXwLAMu3not 98sMDn9aEmgvG3U7HWoj8TA/HLAWVLCHkrRbB8o8TzIyM+cLsMbYP9avigX0 R4Wgt7EZepVN0aa7DqcLtdfS2NrO1EgaODA7qaTL5tAYESwT1FrGzqjS3MNp gA07C3PoBx2mU2xIqs5iCDpOuWBNli3cPKbB4wiQPp8iY6DGN2X9dZxNp9kN bh6JFXn3Djqdr8Vf4SOC4E/UDswylkhIN74qJOlGiw3cDO13t3cfBts7wfYj 02tE6jp6+BSG1nT4K4uK6Po5ytJrtEaU89vyrjLHoQMN8C30lG9nwwyYVFr9 xJBgnoBlkYSTPJwpy8nioqfMRdvERS/eXr5ke5YXPpP+bKXtKinBF7dbL3Yv Xypz5vH+YHB3pzRebaVUe+xZPXafPJGjnrWOqreJGvVMw3iy+2THM2q1x57V Y+cx7xiXZxdFXFSYABVvWPxndHYedA5APddWI6y2MhfRDcDcJV0iBVuG6Ekq YAN3pbFc8X30CaA8mJW9D7sgj/FeAAfAvyMC3xevpOGkLLfSuiBTvUnyIv0W yRTdRgybj1M5Dl5xq+bq8CbRYBwUiBf2yOjGGs9soAcapTitRZr8stDQaMni lMUkzA04dXyrB1buJzzjtb+HRax2hsDkYtUziXM4TS7ZhWZA64O2BEPmuoqt WvmUZw/D4a5HF4uxq4Tey8b5Aggv0nA2TCaLbFHA/tfo36ASYZ2eWgSSEauo A0s9iud0pLpLOIlToBvLMOhH81BiVh7Rke1EMtdBUoS4t+/kAPH54xGRKlP4 tCtpB6LdXzMDJeZyUTQY5Vh4kSF7U3zCmfInb/344vCs6GrvjQWGtoDyGUZq ofSOQT5WByXeNJLMosMSPTDKhQ2S6S0SqFB+Rf6q5gljhSwHXW6esb6TzNCy ht/VDQWe/HBYF1fZTcqiDmHR1n9/TlC11v2SWr8XF5rr3oPBA7xZvifFBP8K cO8U7wHMpVyvfZwBHsKDJyiEsMub+DYYXcHZx/3MP9VxvfPoEbdMw9HsvdKt UC8I8At9qEt41/NUKtDc1vo3NwVpJpuiQsaN8K86tntVbNEEQIpII2DjpVSD cEfBIiW5ODREZ4LFBdoAXwGdpnyrdpXMkblfkR4OCpeJ6oED6t07UP+R49BL BEKaHXaF3AoWBNtpcg3nON4dADCjSfEZXDUpapaDbsMcGRTXI2qkSPCwv4NE WEPftketQ9u9BzRQcgna6tqv3XsCypG/O/w4fVvM4D/pjJphzzbXjkvUurn5 X/Z/6z+/t/8rf7bcRLaDxDJT+x27dw2c/cUaLa2VEn/AS7QKMzgw/8tMq/lD LSs+k2UtbWvc+Qhr7XXrZZ//Wrnl+/VabnpRQ44R1vJ1Oqz2/ueB+KsUsYX4 T+NDsHa4kiOuGNho8yXE9T1t7H4t0KV3uba1e+7e7LEX1Nlg0rTrSyUOj0O0 tOwDpi4xJAr62kCeCY6VjxZsEywlKxhOv3OZzJJpmPMdlzws18RjmhRsCFlm PJ23GIRCf0hlrwNG3zgcYSge2hl0RLKkNdeLZBqriUiNSGvQ0kqBFvbdn7Qn 9OWhS+Up6GU5TIdFO3TVNCukE6SyiFUKPV/keILgtUCPtK0EsLGuL4S+zdij f+p7C9IF6ObcAc7iUekAiwlHaZCBgAYOzpVsDtndIsY6eBMc6K2U2xV6W0yJ NjsYdMUoT+bGACTy2XGyfCrzZsHwOcecU33MptHKFyk8h0cBwwpeQy+8IAP9 eogQKiEDcn2N7UNaNN8BdZReCopgRBe8IzJLE5wqex6exyH51aRRytiwlVk1 qsayKZzom1Nc0l2gyyZaVz9I8wX9VyO6hebLEsXvtFiKKQBzsE/KBPe2BLT3 AYD2KoCQEWD7KQM/0Eu6FLDsyeo/Si2LG9D+oztrVHvi65AMkSJb5PBdxdEY SkDGIlTcRUGOQMY459tKilTD67EG27ICVptsvN2BVcZJDn+M5OUlC6KQVHMT 2KM9HZKRR1NY9bIHJiaAkA4LuaLYXNIjjnra3sHBbhLgW/IPJulouohiPU0f vdBgJX9mxQIkA4/u3yRcHXqAUzC2EmwgbeaoC3MtHpFbT8nUwyX38qv2lSa6 XU8irkbU7IxcHEZRjpF80k6GLUPKt8MxbGszDU/PhewiTBe2zBMpnX3hTBKb W6TzosqIN+b6vh5kIb8oxPGfj85NwAH9C0+HW4q5KTCse6RQg7n12Y1Ip4sS Aafn1wNYjwK6X+IBQ66KQzkbjPxBSwZsag4zF1uXLw4Pj5TnZf/xYBfMAGs5 ae+ilRlIlxQYQ2/L4Cqbe6mHP4IlO8dDCiVTK5kqThFNKrSmWYGHb/E+GaO6 yzwcYxAC3VHI8CCOGZLOuZxv+XXDMruBfoUilzyKEiemAQZW0zFmLDTIFhMy YG9JBksHgLrzJ3Kw0weJsxuUC/h9WmcpKQ8cRxm3hSWeWi4FyVHktViAOgDS B7YH+eH1dbSkDoU2FfEiytD31KuFGIDtrx16Wz+ev7jsstKl2sV/LeO0SPB2 pu48gB5/BQBdmtfeGvPaa52XfXdF8Ve0k4CyB8CtYLkHsN+Y/3a3t/cwUuD0 HI42HT2wvYPf4Sy+R1kEa4uBakiJk3QUzouFVJ+2vr84UZy88wh76b931d+P Bo8G5GDYhPUGjRHFV32GmhVZRkaLNArT0S0jXhVwDcGNTWxehhP00c8w/gnn BDPNMOz3lgABYvgyoRkbQkGJUWqTB2UWqBWkuLwxhpZt/XB22tV3SA1tzqgN RkCTn1vAv5X/jHUJGbAkXWTv3mH8Ma4G/bXziP9Ewg62tynII1MXL4PdnYcg S8aGMOxP4vgQcpjn8QS2qBLZqChDA0Cb6AKoWCeMDOfrdM4wPiqaJWnCT2Wu Y5KLi4IoUyDdTlPc9ImSILTfrSYg03Fut/WrGnbV9CpXQvLUOcCIZPGN2Axv wgQXPrgGeyki1ttkRyJpGnyLYR/jGE1FRzfilWjUcYNgKAuA6VdBw9cjlvEt oG9CGQxzLUMVJUJ4uNPxDz9LgDKeR0MFhhzjNyhnr+UVkUQBaYvjXyXDBEC1 jA+MnWYl+S5h9CnqIPEolMtYWaN5ho+GUIXjYfL47yRSl0xPNUNuLJBlcMAR Kg9G4+ErZnuFcRcNJ/OgeSc9+/6cXgDxZobRMHKxuGIFC38sYuJR6yLxye7e vrrHu1A33PQaDK93HD2FFKmasqKvxSeqU6vSIrWAgCe2ia6kbB6ggRGUZCp0 cWZHLItZh6/uC/XIi0mDHMKU5taZevAWTitNkX5gCgETjJNpHIzGk6bhD/Vk WGfXkyVWNIqOBGVdJBR83hmzQzZhs0erqbzrNkEG5LdkhGmsDKhNCt4/EOwc LpzbdMV37M6MI+mrkmLBgJUBtXxJJBX7+XyaKIXW8fjzucaY/ZIVH4hSTwYj FxKn0RR1efWkASPz6MUhn3yhCvPWd/LAknuD/X2+20ZMxmEyBS0fFLWSz+A1 8ZL9JTYaiiGhHPtZEoHqMZKcAwffjRTix7rL1rPnx13TkbF9+PjxNoYIWDSW YyXpdfZGUZruxqpUHutRVpsUadlqeJYreIfsrr4BSssSjt7EpTSdb+UthlH3 +dpLwZSA8HCUESw9+6TrkQTEEUlBYMtSblXxIin4rcaLQi1dzvrMmgsme1WR oumSQTeMNWnV2oFoU827DfTehH2OIZ05P2hoFD3HVQE3D/GJTSnRVCbBMCxA sShGV6BGTfndloFtCSW1Q0V8Tb4gVvSrTjA5D7Qgc2kydsVWVVjiK4ToOiSX oDWyFryeO3btpQebDMR4ILvFMoxGBl8CibXAc8fkB0TfBIGUocoPj9/wmep+ /95u/FT5fZXSCIqP2zDPBIiHMuBAemyPeB3gaR8ADQMMv7CGhOYo3itj6t+W jyrWGVWTxD00DEnoNAjUaWCxt0OmViH/tfhbEv1coR4cMQKDxugRtAHkl8nr QFhFlq4Fr01+rQOoWVK4UIQPil6nyg43CyW3GZj5wCJ52cJn1dbZnNipuXWe Sc+1Ab1yewnc395cddhCSt11KGP4kli+hy9YSM3gY/WVpQOd2nJJK3Z4DaKM 99g2NyksEqz/qljUPbVLxug4DgCSTLOawgOGR7nzlx4+Of4LI0kRXbA9AzAd J+SSqXkTpLO9ASXUtIq4Iv6UPcpisO6gkCBl5KV8GYVxWXpexnjQBmnV2JeT 0tCd53B0SGtfBq67dXc74Jtgumzfxit5sFPRn0EWJrkppNH2aG//sVc+Ix1/ MawNxCND/6lH4OHvo+tpmMJ+wt8XYGzuDGxglTVYBazu+0uSroFH4cNjJRQ1 KS3BO+LWssPerv5lHOYB2KUEKqXcDwbS9XxarAHjay+Mt4CrBSRNAg3GCwwf m9Bba9PIRx5qlswD6dbDsTH248B8ZWNhvHOS86x1kGvQMpTDm0ow+8nxvpGq sheQdF0oX9ehIFHt46CdrKtTdnXiamFryxklbNU2PzIhUx5BuufzrqPk2mvU MSng8PT8ep8EIvm4jTSzlE2/554uG6R8eoaQots0nKErHf1vjlfdL5TVbU0d jZ5ovF3wXgM0Xy9QmgG6hyKpGvcFvUtsBY+KN3TZ1JpVdDWab8qLA74Z4otV adLOQhiD/NfTWxmoHmLyBHzLCyegvn3AmESyd4bxVXiN8cT0Wlteb8lr9pKM j00cUu0uxgypZS4mkvFqcyimYTja5GspjmVyMk9k+gqWXymjgo+3gkWsro5t q6coFvKgovsNMV/keN1bcAt8cqVueoCTpOdfRcehzofvuXie8vZDzmCTFn6T ewTTOJ2UVzDfDiypCRMsljBzEx+PMxl1gHRVW8V5qVxjZDauEBY5+MCCGmZ8 WedgVDn6Lb6unZrJ/Hq/uk5GaDoTd8QOyZ3HumHDireckjDw4FMNvB8YWgVE 05VG/gAczMd34mxVenSfWtL5YEuKrW5Fyd9ytr/pow8U6FndpF23kYRUa6ZQ jtPFLFaZqdzBqQ9dUjojK5xVGHCgYYPV13UbSlDepr7XVaQm8e2097BCDq7r AsRgX9b597TOg4Z1tvezWWFHkjetsBB+NpL6Fl+jLgfSDGIlPsPPB/AajXx/ fnuveqkxSZMwnd4bhuO3NV33F9mffwuycSAHsMlmmTYuxPjtHP2TZQWmqPCO vtavNasQbJ5l06/F3/D/AtfNYkdi0spwE/Ol637x9CBPhkKFiO9ddn9n0PBd Pmrr3Lb/36+y/9+vtP/x45EB71tkgIa6TAY4q9MqA2pkXlXWG1RYqzdcUpWl GtDfFJ+4zjO3WQtXeKZkLeo6B9I9BNXg/oKqDuKLoPoXEFSD+wgqX+cvgmoV ZcWg8pkJKoOkcfTsNTl69hodPSpAy7oS/N+UlA8s47yc1EzjSsiO9MnIy46e HUGtA+Iqz4HVgDKtY3FAd53sIt7ffURxPa8uz5+rrx6iT5mjlejJ1UPMn9MT p5fB6SV8pzJhYtwY/r6z8+Sh+vvhHqYFYt/8xakaZHf/4R7Gbz/nB5mW87uG m+U0GoO4md5uagdRoQNF0UvQkz4m5XpSG5h6JcqNTm8fldso8sWi6WWwfVLa z6GHhMlc7zrT6dEEzzCq83uOAyZfHXyZTroWXhoNygEG8CWQbbzy74uXGd23 lmGCz/OHQA8PeVwfhQ58x8ee4bjE973Ayl9jDOsVHhx8SuCheVC731BBzM6T TjtfKCDL7zv4IsMBiT4m5BTJDHRprhebo1bMSCq+nINCCycpJV6KuJDfxLeF ecdh3u5VmoXTCV42XM1kXHoGvI/Ow2k8CUe3+OxmGussz9L1FWUUG6XwgZEE vWssnHeNfSKXcc4Rd6hYU/lUwUnOgIkZ0etU1Ig0rzzal93U63CkoGYmudvo xg2/33N23bf0CHQxutIbHUaNsrhwZiSjQR8+3FXTkK92ODDRPBzvrTQrTqsn 8bfElM52JoNEXh+dB4ev1NtXFTzNucQwu5qCrwmu/YjWsyQZdUwjY9A2jz5X CRzILcvb4iq7UTkKDUR6NWKN3Rd/zm7wRU9PBjeq3FY1XIqrbDGNeAntp7zD +DYjNsw4Ra7NIxh5lKTTW3EJB//pMXN+PLqGP7f0U1W+nZPy8MnuQxWG9DWH mGCKNdokhdiiUDy6WaBvAoyrgakG+I5B+lM9LfjnLh4NtJcb40ysV+3u0Pql Ov3LJHAbK9euyfqrgroPL8UZJ4vYOrw8w9BpO2sifNUzu7cqiiti2KSbkMhU 6SLx0Rf48jU2ve7w0kxSpM9UJscvHWjkSaZjyyLM1mZWzMfs45JEToqkkF90 20UmRhHOKCrQiTNyXw4YNpfy1X8t7KLIyF86x/uBOHcWVPM53U2kZX4rk//h CzuACAeSqx9QI34exKHLmyZkm+m3ad0IUvRVqYQ4jciPafhhyjCeZkgPOyLY k2pok9cliZxrHi3S7aBxzi+tQuMwXKzMQ8q5ya+dtBNe44iLH9aOOanoOd/b l3fy6LU15CEYCrF7YwiyAeNH4ByMMRFN1cvHYt3r4QuzijvvvT1uEGbWyJWB nfZhhq/uST7pHvoZ/oH+K3CjkRQWs+ihHw34oQZ3dbA1Y84hC/auXLNW7lmr zWvmrk8Zl80p6ikL9KnfcldBm/ozZA0Y2aRS8K+P/tnCYvX10SP8kywUCdsv C/X5L1SefJay9jNap1+J8C1aYc0TavkvyVERFgH77IyzMqZHwRauDQ1dw7sp CAvfhrRd47XNojIF/JcLyqLfP8UcjSZ5sOYQWIHJcUnJ+M2sxKDRXxZhpJvO MHvUyManHuFmNNgPQsRyfwrnm9rtoXTKoaeKFFCLIUOz3Yxzn13ldiOME3zq WWz13LQeIWYTQEvCJrQMQvQDDigzM6GnEP6pB/pZvDMpiQjbO9unjriK1gm1 z6kyLeFMq21m+ldfiLo3Yl6sETSv264TNy9UD3/ovP55peHFOsO7V0Lrcd/g t+G+QRP3DdbivsFy7ht84b5PxH3DsRXYjElBsYG6A3M5omphm370T2ADZSD/ bJNbfcno11fSPMquSnJ9HeFcH6j7CHXfwJcMzlXEM5jpTRKVV4575N274U3t FsLbVGc3BNwKzIxkpwTC3C1Jye8K7WjFC/QBbB2dXnB5DKySgidPvckJNZGe k/M4fOMFdA6tlHejiD3YaW85vlcd6mngjVlfvMYn4ypbKwUzYwWSlNPoLvFz mBsWCcB6zc5vM8XXYhNoiUw7ygp+ryb4zYGFScI5eY/wjSP6PXSOgqPsUr6C swBhUs4WSOhpmU5NiiX22ei33uhBQwie6EYNJjA0NKw7SnLF7YN98+2w8Hwb e9vG3rZzb9t5pa0PSXzc78RB6t9ghwGx8Edng8nvGmUDGR7uzbqQFoFcwW5d 4sG3MBz8t3L3aN12Z+rq0QQD1NowFVxC1BoNi+WN4lUgxatAmq8Cad4MiQhH D9Ar5pOfndyfa7zi/FxnMPfn9t51lnN/dnpr2WrLRCVajVB0xOpXKgdWQ8lX mRZLvPvKSgApU/rKq1xO6EspGWqpGDgFZq9yMYF+ZFdi8RbnT+cPR6+OT8Sz k+9Pzy7/JOjBeSV73Xcm63Mfz8KNjkrM5TQT7zp8VgbqFmmnv/NthwswFnNM nbGxyEGhgV4HJEmKg7ez6UFaHNAJW0mZhz1Vehn15bco8ziBnqgkDqXRdQ/z /bf0tb5Wkqu6gSmukRr4Gr+lfq96mxHqxG17NRMeU7cVhO5dBTsrBaqLHmZJ bUEME6Ue6PwyR84NQuVdNKHqHdwkd3XHxu9bxkYeOqiTBI/DAivpyByx3iFN hlZ3SPz+3kPueYfUHht3RP11G5Vhfxx4V/0/4ltxRPfAcsyOW8+VoGxgRWXx 6vzy8KfvxdY6hZC7BJWyyY9KhgUgfoqHcGyLP6hiiHjxiGUN38Q5vbGmapc3 kwecEPXBn3gq0BGfxkPPP2Dl0jI74N+/U13+xGqCzoMvGgoNWx8Fqa2UsBz+ kOtAwl++QsIemL5KwTVYLXWCPSBXKAtcG8EtCtwEuVhWAbgG19T/9YDzVfn9 E/FCZPIlMj+QxLczPpvEKI2lLKmmG49tqllWMozodCoqX2GPz5Ie97NTwyEb 65tOqWzCJp3f5snkCgYbdakaABUWF6/zhZVsE8uJ4U6wrmlVwg4uHFqYAIMI 60OBXkpQ8WKUwsEiNeBFjBWdqAoyBXmkkSpQy4kG6ZthkmIqKKpB0eMZy/rU QnpIkRhWlhBWrNkIwWdOxYILdvKsiwWVP2QAUj/GAiEpJiWNsc6FrARBZy+r /BfxdYL3mc8uj2FDUlvuj4QHxFAHT4347I8UBQz5NgvxIp5QWjKZNqVQNJhy DjOs9IvNj2WWJfn7lhIZJYKJYyMuJNYBRvEog4HrSziBHhVeS0yQBspJrBHx LcyDrrklRvB1UhbxdEzykhJ4Tgn3NCvxqXJ/g47qPJaVUay6ESynqxyP8hRL QAAI1am/0SK8EaklZ3ddx7LE+YOvWz4q72fT7w8AAPxPZYjU+T7b5qYi1azc mkq5wOtsg5kDde9Doe41QG3MBLrOKFQTtCUxqNylSg6qDHZNqUNld5U5dMVF Muku25bpwYOWxJQFqZMq5VxDDHYzYZ5hmRXdnVKvNCTAlGUFDo+syemOTtyv HG1IFVz8CH3bhM9rK0vmZlHPkxk6mTKlZFOLpOtkLMOQI4R/Azx5nPtiSy9k JbbJOFD7YKPiYZWy5reju56CmlJYiJsYE8oW/MR1jUSkrZIS05MerAzSQ083 2PrXXHgZoWQ2bKIdVKss/KdbajLKmcT0clpVBYtiayZqCpX1/3UXT73NoHqe 9107S5Lik28GTc/iVTEdnV8QC7NYc3bLidoi/oG5iFDp2pwJ+PPoriqU4ejh IEXlK1G5dgsfA6m0uRaZ/MM3UsmclUvz8ZbVUi+KVlaCXm/990pVpCmYiIDT VG8ROYhvgjwbquz04XN8fZ+MwQrJD0kc7HBNJfVO/Th3cwyvc4qvkHbYd+zo xCcObR0sGml6bjqrCalq41YFJf/AmCXlA4ZcngS5ARXNZ80YYcaVe6C0Ur5l iZ3GZhm9NM/stfDM3v14pjWls4dQCaYUCxJH63NxaJY052hQwn9fU2NMbN52 kGCSaDxIKtmf5V49PfciR/mkPwQzsHMXmPhJbFFS6iUKyt72zoHp4tSH1Ana MfsynLZqtc3nXL4P8kxgUtmKq6G/Qrrs1ulgEu2DVZJuq7nITrvLOtFzBEqD ItWOwoaAObqVpmCZaa0g69QkxJw98zqcTPgdlrpkrijbTkLw5i1z4SYE79vm OQl6XRCCzzdZwEGhSE4dfwbwkjH0mwLcweKCCsLNXKx8Vxz3jq87fOXqfGqo xux+w4YWpNaRYZVQ5wSwDh6UqnkNEWZVwuG+Oj+dZ5KLNLGnh+2/laDrg8Fw S1Ku+4ZIm4bwzGZ5wnYve1D+9mCdgc455TtGFSLPsTMtoRs5qQqjw09VHSmu QKPRPKzLDMkUxkhdJdgw2IECTsQ5Jm0HwfnX8667xvQe8BCjbJy83a4Po55m 3Z6aZQm5aa9l6EyL9o950b0Z5EEITuORSiZl53DXup6dyt2byd2zNp6s7p9q Jjc62/SHZo5X3esJ5H0zryST/1TT5kz1BvV1EtZ7pqWz0n/6VdSoyJn0BCdI LrlGKhZTzmCTon2DdYGMb1IBAN7lBPrrZdh3trPKpu8QSSXgb5bbH5yVv1Vp wTz9B5wkTryIwzeYTE6WaJYVmtVTrB9oJ9Y1h4sM85eCbPrh/Pjw9Qk/Wz0/ ORMvYXgsola/PO54nHY2dyhitPok9BtEZAi0SsFwKA04ecuCdb5haoeXPs7k 6k8faWRdwXeVkfPinqPyil1yba2ti0vvMZcXwUeZogTCasHFpb7uu6DfLSdd 65zpOeeHIcJ5zyVs4Lar8BprbsnD2Cm+uuotAgYZRPG45Q4BIJTcCJW4BkcU l7kykWPy6xUcLHeNmoYezHjIoFkysYxclZVS38LoFUC+sAWOmoIT02/hzlGl Gu05KJygl4jNv20HTw6D52Ew/vnd7t3W/+nbX+zfdd9t9wZ3m0umQtKahrGL 5yEq5kUwBW+usmoXtYogjXc/+If2aXAua6EXtSElfbPkVYBkO9VfyVV1J6xl vqKlVx92gSkYNhQ7nlrD8kMDeIdtVUwMeCGmcTiuYtjKwRYfr3Zc8+fO+tuP 8zpY37n4WwHa9UnUw7VtvNhhLsbhtHC+b8TRuHRLU0c04pJrIP8AvBL1Lvru EcnI+qZ0V1t5K5bdmp0f8QZ2eNVcpsZCga4trEW1Bia6wZ+z+bcOnnfO/hSH Or2AKkRT319ufYPm/aUiJfny/kiXv3GuOOq7rblMQvsOPNIQcLwVSu8Y+spb IJ5whlkf6CRC2UxBJnidbnvBeQFMf+sGqaLDRhk6Gswa0fP91hIPFodgBouN JNpYyh0vZFIAq5KPb8JVqZFE9c3G58ZqG0mCNoleKtWEFA6cFIIKKbbsFyKN v2jFfWjyl+zy0xHDHnwNKqxSeOM+NHn2/PjT0UROzqqtpMryPD+uxI9/COna aozch2ZWnaRPR7o6DmuQprlqyn3oYuX1+jREqSJgKAKWu8tPleach8zOJ95C QgzxPgB1N1xMS9iY6W1wkydlbDRl6xS1T2un0FP9MK0UoWnRVv21oxTKRN9K 4RpN7CVqlPc4ddUkDbmiKZGPwtaVEktPit/O9cWvygqkVaY7P9raAvtcsI4S sk4iD952JZ9VsfZpfSvMxKumVqdh5sDNQY/B8pEyTUPbBFan+ifA37cC1mZr qEtkBQweYw0cZ9dRVZzmvWaKuk1sHZar3sD2kxcR7uZTJW1cSvotsKr1pfq6 unkDZV+HE75yqy+oqo3j4sA5BKzhKepfbOz0+/vbT/Y3Vhr1R4wnMMK9vhgP quWBHIpXfmum/blsKKn9+ZBYzRJLUjlTw8pGzfPRmduwn/Vo9fOZmPIh/Hq8 o5wjxENbl8GPFO/hZ6Zfn5OPlEeX0TlqRccjaKrFwSxJY8UMbZ3/1HV3QDWe qI1ZrMZ2IEwD+2AdpTqh9nZXFNChOP8Jr0Bkumzz/uTHoyWrJGs0VcZOzS1l A0KKwd2ySiut3lmcTK6GWW7uPYzWVr0KUQ/DtvFhmBWSdUllbvldF0rzlCz8 H/SD9hfhMK49IsLPsf12RUWqiK0Xx+ddcx0y6O94xAZGYDn8YIV5+UKnoPmv tvQ/HrUuayCN0M9obR1KYriYS0orPs1HSyqUtwoxqZDY+uQk+DpOwZhVWz/q QAVn2+haZB8i72mygQaxmgCWcZusjDG+8r3GjF5sPaNC8Gjb9OSLL6x6Dz+Z XWBXqeIIcvx9s4l9KlXUKjP1M4cXd2Vo8r3QZmFFLRsNzOYPJadfO3LaYZha RbxVdMFqhKrhJ/csX+cc9wVSLj1M1XW4N7aURqwEKSqIxslaO4wEa+MbUZyD kRYFmBYjyPIA34Rt9fsPECxm7FYvtw8MhM3uxvL7jFfoVeVi4oVR/CsVMSW5 HFf7pjWQkfStFFr/FJWuc9PeTzVLZK9NL+z78SklNgnuioRZ4VDRlwjTooEG lqxdnwjY+VehAgFelQwrnAeKDgi3RRvcs+vLuY/UsLyd+2zMEUG+EnMtiuE5 Zj5TWbkbji+nVkn9FHtc15u3+/293RV1+MUQw9pknL8cI347JzlMOSuGSVn0 xSkHTtHKoQ/FLCplRDcX/zqwwivMlYei9Q3fcvna+irGzHiGr5030qzc8rLy aJGDNlJudR1m5lqNXbFhpviN2ADJuwyG28GWqfWXbptdZ7fEeQ4AZxyCA4tC r5MSeWlFRB/RXTq+LD6/Hqy4IdQZh3nXmXH14w8MnjKPgeRTJzyIzRycjYTB jt5TmSKZl2yIWunD1g0x+HU2xM7u4y87YiU+GfwafMI53a3kXlKXIb60hG1d mFarGjYzD48hX/KLJtlqvepSgBXCdDb4JDj/PLrK8HRqWiK/V4L7qCwC1i60 4FhxJbiWqoLv0tP0J3WANi3Y8JbftOpASAna1sRmcZgWkl3lAvueAUr8eDq+ t9BtmKID0CyAeksOoyF2gcHX7BAgldN/2RR7Ome/ThfnuybK6Aony+05yR1Y K8fkzEvuQKssU+VnLtkk39vXfmsmjCQPP6CyixQ7GOLnzjee/cr7w4YjCH31 N92sMI3ph4poM5/QDo9YDWX3X80YVi4Z+Gn+uPY626rIU59k7eLPHv6uys+1 B/PtKFKso/X43eW6FkYz+ra39FZlHVso5EbFmPoR9otlWBeLn4rq6hibvlbZ q8ZPtnVv6v1VV7uN5zYqCkgrrlVU71pXsRrx1HrYDCyxX9dT7nHWeNWWFc6a mnL0Ec+awZezZpWzxmVW2w+16lnjQmgVAV/OmvazRoS+0+azPmvsN8z18b8c NuIeh83gQw+bwW912DzHrFoekV+xbNoMm1UdRFaPBtPYqa7rdc7Xj2//jbKb R4TirqimnpNYRcdMeCzaSpXe+yGT6MwVYgZ7QEWCjelSSb9Yni/yeVazr3/3 Vp3NvmqUDzlp3UrDqwmnQ9UZl6LJ0SSzmFXEExKFi3tURACxT2PdYr+84BCC tYSEe3smMeEabAZ/GeMmZ1A/mipZgqopxMzHL1YkGVSdmsrcPBLcYFYlQ+tc XRFe90ipeSoeq0+U30oj39WPXhLsdqlnj5JAEaiyuHMNwFId4ph+HsaFb3Ws DEdeS1VNSmVWdD+03cjRuulUkt6UpSkxL35PJJ6cFsIkzqc0AECgqd5FLYOR f7A6GJUxtKpRb8p09rWPTtaDSFG9VM5CwK5OKnVY4BsF4GQcyEuRqiPS/rCL VVbhrq9jY3yv+rSvJIkMYhErTllXV5Q7nKeCfnYvhBrt8PLaJp1vWlWN1jyx soqHN053qe2LnxmsIaphoJTli/iDaONqo+MkNxtLFVpF4q0xQYsu95zemsjj 468Pxb1Zl2/Rqz9HpyRX3/zilVx7uN+nV5Iyw30xFf+V/JJSw3Ozc8YrPBV+ oYv5VlDUVcmrz4NsNcwhFeleSj+rqF9ZHmE6jAD4A+Dl367CZiuiRg8w6Qzz Sk1Fa0KbMxOY1FFOE7d73Zcqp2/fo9Z0l0atpYWbD1NbS1HPh1X2UzPzpv2s gp4ryrsPsyVM3I6kY4BWOBjU0iheJnDW8mqs6kJf9Zb/o3g1an4ifwiZ7ROX hNKPiW1CrevHWG34j+PH+N3eGNic/Tn4MWqBEP/sfoy6xqSm5PdjILdSOPEX Z4b7+eLM0IN9cWb80zozGu9W8PPP78xond4XZ4aL5Sq33jVnhgviy7V303DL nBk+DqRku5+PM6OKYpt+8MWhUVMDf0d33x/HoTFo8hqoda3W3SBKfhIHRyOq 93FwWHfrWaW4tT9eTFLgt/ZxDH4FH0cDXy/1cdRM93v5OOi5j8q3bj3xUV9h CTykCxvBjqMDc2G6Pzf7Opx0aZjntdKx7vKwcgv6xlgpT9pKA2mlit3VZsVo tYag3sTqlVTz+mycUPcCrXiZ0qOoDF1/rmKmCDsXkxfN4CjKsaqcQYLfoPX7 DxR+fxSbqIpubixFyaUFNxriGqBhH8pUvLzKMusuV9622W6I+UtGi5z8+PVw YnmeZfOantIoVIyzpbIyDKTwuBXCbPWT6odCHuavQbwfuiO8YjS34Kfg8FW3 KvbrD+wlTHxm//DJ7kMqzt4M2HPgSa4KajNo4q5l87M4TU4SZtJ2filhmWHx Wbv2bAUTXYP2QP+F5fbWwuxCl+eTfhRGj84lgljX25poLtaseuuffM0pM4se rslKL48f4mx4E8h8Pk6G6mUzkVVDBvsHuOMevMRXqnDsVQvanFWqZNQ/W1i5 2crEsLPX3/WxHMzxN1hr424LzdTVuiPRPp9Fb/DEEbGQAB6fiDfzw5pUQQLU E1H4sDS4+BHxO2ZaEfGcfADe58BS5dqBxOQxk2UzWb4Ui6FMmQq9We+rQ2AT TnrN6IFmWIjDy6PTU4l5q+NUaU6YVzMDE32CCZKuZn5KNKf8xQ89ATTMXQW5 zMxttyccS5FBT/JwfgUKokE6LIpslPi9rVQUBjvjQnyAxaF1NpNer5iPV9bA KkfWkjy1H65zvbo8f/5F6WpQulImj6NuVW4klLpVy3JByK+vb7FuUjStjU/d gga1UvXqo6Xmb3a+0HVOaBJXNx4srYeAntS/4mng25NfjoPf23GQFEmx8nFw ehmcXlZ54lc7FLyj/QudCuauUx4DTBDrHJBi32YDf+reex4BvpX4cgZU5vUR zwA7EeEnPQO8W/DLIfB7OwTyZHWn7MVpzUj8iCeATlTmGeZfV/QTNar6v1f6 fxx3qytDK8tQjK7iWfy5in93e/124v+jiVxb//dsgi/C93cifHWuDV1+QYu3 2oUZZQ6lbwIcHzoExNnNirpdYxfdegaCltZ8O0OXrBRuUdwWZTzzBQ/7AnfD IuBwSUWCBnFuFBldae+Mwyy3Di/PurK8LPyJcg32WFZUHqiE1lVlJrNHlOJN mt0UMqoGO4NExHqd5HQvxWJu9/dUiLRilIkyH2WKlVgBREunadRzUDEsBkHr Ss2DnrqwHoezZHpbwXKl7LguhOpB1hxsnWI2XnnOFU5YHkFKTLAo13rFuEo9 qc1I1oEYvdmUgci0dBTyyDH3acQX0zfJdIpgrCXTAOv0sEqHrpDZTecRdEsw Lpm+e/zp6qNbKqSop5ezR+zTE3E56ltXgw1Zt+9fgvQDipD69D2PTPnVBIoI 1DS0FUOBKqENAgd3JI+FjfcoXWHd7LPfxdjzNqBFyn5bIx+50JckOdKKrKMc C/1yA7YOOticSX+SvW7kFwgrfEpA27NHe7OHOjFtWdQOqrvdI6yw9GY1XThX TslKrGbzyyKMFFb+KNklC4sFtrGo5unx0t22/xBvBNmLyRxxLvfvA13v4CSa xDprvW+7yYCQD7qBrd697vd3+3umIeI4eDh4yDhe71G5dI0jowYkd3D1DnN+ EhyddHXwjZqOM3B9rUDVyK2nKJ4XFN6leMnd5L4CS0Mm81zIBJ+lVVAKQ6Es lEEmjGQxGhJb8xAYq6Dc3ZWj2eOiXCmnWPNeI0fG73CzeV9W2b98lN1WiWOz ddhLDndTS15P1SODHfNyEgBR89vmNbSCsGH2+lTBFxVqJUlzKJwhFd4E3NVe razclYeCnKF2VdVVvhLEFNnc0bMaWIGgDCdrn1mnmAYIq6JhZ6tQG2wlFUzs lpx3Rq3UaG4rSdFQYED+6qn7vKKmGBMSApFQqd2saagXHdaaxZaayGYrv+bT 71lIEKZOmGdOAd0KRdNfz58mIasmbkZJMQrzaBP7bbINM03SN5u+whNNYnDl UjE4OwnE2I3GTHQm3izi3J3SciGvq9GazeLIufoG0XuCQmlxIKqWQYxsxR4n 42Ach/gsUGxYQg476JOWYoVxWym6b7QSSdWpMBsnNq9hi6S0nEgm0VRVXjgt rFTjTknrFroOProEGtxfAg0+RAINPpkEkhsL9JnuF2n0LyGNBh9LGlU3S1Ua DdaVRoNfRRpp/4xOyY4eOSclu/2K/GMIKVCeXh2+dO3ycUsZQIqGp/elTHPW iKlwsf/p/1U2jaiqZAs7weYsC7EBCiwsSAwSLyraqeja2LoyKKKhxrP9069t 2uLWSmbo4hMFfCFwCSKsS74wK2G6avTncZ5kII8qOQfwld2N63UznZU/EHf0 eJGyhWHhdVoBFmVxkW6WDLTCEQTKAm3D7LmTIF9WmpV8PVMutVEfPn68fSCe JVGSsxUEYvi5KWlsHEJbWAq65zP/TI21x/2dx9U9DUxmkiO4d376a+mDadnl Ts1PK9mC402hHW2DUluUXSr20yKvj965+VBvxRiev4IyMbkCbl8k+K9eGi4G KsJTw4NlZ/cyXajBgk4z9w7kzsEDJMoIToR0FNcwabzuqPgoDQin/oQ9VPMs VCEKa3XwtUTlMlACov/T1TsztwrfECzFmyQqrwJLqq/KHLpzk1AaJXldHg32 K/JoOF8iho6AZAm6lMRpCuPO2OK/QJfM1tHpRZffl83Ct8lsMbMSO2D9EXsr 45M0gTdlYgS0wgWgJ/M57N40EtEiJ39fSpetIBwpvMb0hy5taVxHw2KVud4C 760622cLfAl+mfwD5/nsEuYJ/yUvfY6Fu5GDh9jkVqR0ehpcpcemzMMxnM5A H/6DaYDij+QWC83Y8ukaCEBXfLO6mKETBz2b8CvOYAHcPZUXavxNHoejK1ea W05iwNhDrPjjMMbJW6rhV+eKE+CKnkj6MehkMTcaI4cCmCmseW6ljKBDABBF ghSL4d9BwvKbYlW19UV8HU/F4SSP4xnsbbF1+eKw6yiSmtAix9GRuYb4mhGW kd3fgI6PCB+LYyQZbHY5IXZB1MwmDa/DZEqXvbR5F85zTDUDzL9AywsQKOrM kIRuhWYZcABrJBJuZYfxW2fJN3pX8bGuSpnJsTyJR+SjViAY2x70lFnyqs8v Nv84jHSOFzR1Njq32EiJlyV8pFyk8S8LzsQDpJ7i6gBxwMYCAEA72lwgYPx8 Mf9YfEGzsrniHLmi+aLInAVxvqT+1PcN5wCqULemvjKd7OZnNSvSFIY3NMYK erx/jOYQIQm5ZoY2HM1VV6/sbo5kcyI3RPC4WoVB1SaFFU7EMToVFJteC3Bj xDESizmwZhN4GcOCazfK3HfFjbE/zxyqHk1DfjOsRN/WUXZZeQRJK1qFL1cU vq7n+Wl5PqeMNBilnpWGD9XM83rbLmH2beWX9oCQ2vttGBn2t1w9eVN5nIxJ fS8bgkIuVeHrI7wzP0ezUWwdXx6dd9lZcHQSHKHZCbDF1uPt3f7OvFuHQjaE ukNRrheSLWu9hjs9OTkRl2UkaKC/gHmRJ9GEvEiR/DvS91atIT18M+pRB+1O 3owVyHVcyWQlnntFTV0urqz+Crj4Am3uOn84enV8Ik7Oji//1Pkf/el0vkLL CU4iUJWOshRfwfO1UdHpkB+okHaViqtCT9C4jNldUMazOR5m6q0Ou8vevVPG 2F7/EfLT09PguJ/E5ThI4xKgBPl49Hh/+9EwKe7u+jhQLDbod20FbPAbRmi8 mCJ4VWo3wkeNHOAlz9QOjK0TkNFdER75aIsmIQEJWELMwjScsJ4yl1eDRQ+O HTRtis7ZyeujV2fPAfenYJAOdvd37u6IUy5OLu1fHm/vbwPOqD8UsQEkrsJr vKzqoOIY6heveZgWpFVPqSaodIVdXv5ZQtvffbh7d9cTr19cKvj7+wP8Bobu /OWH0yP59ZPtbRi2SxjJoUhHnS3oGrYSpskUVWWnj5zbwEMu7nzEqrJ8H7p1 dnj0sgtj/RuisIeT70ifgPKlUehKBhsODUrQemSRaDyAgAlhaNBqcqHImOUd TThMmVGoZDSxpQCbeDzQECwdzAdEUVoma6GQfKqMmGGV9lJO2c8zchB5yCUY G0I7i6msDvlCLSoG/HBuHaoAH2nOymOVXYT3NI7W4dEKaWjx0NACFJF4OjYG BYd0wYC3zMI8CIUg4kg3sAFx7r3qryryCG2JKOCYRrxOplvSi/Ojot85LIiL qTx3Tree0B+9tIn0pBRqgydFsYjt1E6dskI0GjKN9ZRHUiRQsriXPFVupCwk TT6T2EQ6hFmEg9yIMlB6gfad4ipbTCPlxpBJWrIceApO74hzKUhUR44s6qM3 CMVZ/DYEiQOzx7WgDpmObilsZMgDJYk+xyCF0W0g541wEkuhVQ7qmheWXdW1 q6JNMB/gKCxG04xRQBFiA5yFpPw65AM2vE4yeetfyT0SaPdbmS/Y8iBUceZX yRwofwmGVg4raea3tVnPILIJk/A8a8WvPc+bNnucY68e9L7ZxfFpDqRWSbGw 8+gRyER6WlkJSFe5RoXQvDizeYUWg3ZPdZ1wDPo1SYF5k1Ke+V4mwKh0IBnf yWBHc848RJIaJBGRaZH1alwhw4Hp/6cYr27et1NIcEgIyThf5F8O/OWl7bNB i7NQIcTQ4gpYMopHyQw3GnVEENxD3BC/g0mX5RGgEWNwPCmE6C3P5rfWjQSa Tto/gyAw9JcBimxUxlgvVvwZ7KhrDLTjY0sNIw3BhGOt9MZDKJhNymY5OlzR kUdnaA+YdBTijBINRdLIpFFagAjMiVodUl5IH1PrKzePPLwGTx7CKdVHreL0 8OywplFAf/o+KVQAKEuaPJ6AwiuVinGG9iLO+4eLU6UHbqTFBh4Y3DJnyjEb 0M+nJ6+fi7++fCEuZIMNybZ7g8eP7+4OOqT0YHMAegCMnacHqHEckAZVHLyd TQ/S4oCCtFxNBPtIoCHoDvQ2b1QeMDOcnlx+Tw4PGBq+Ontw+C2H/ujZ0Rzo 6gyxw0C6Yo5uMsZnXYrYslpRhr5j2YzgznAIl1ZMicH2LugQknBWV3PbuyFU F4teCA+mVifKmZrL2uQ8J0l6IITz7Us45ugxCXEeUuUpDMLkl1r+AYeL/RU+ kn5BEIA6PHqDLEcJp1/nMdiOXx0eBUcEOcAv7jq2zsv0O6hOyTb43RurA9Kk v4Gh+N9K1cZvwmiWpIH7/Xu78VOll1tGttswzyg5JAb6p5MY23OsIEiLAER0 gLc/1pDQHJWgypj6t+WjinVG1SQBQsE5NU6mcTAaTwxJwFxLIn2EBdYdhU0m WD18ZQBiQEMxLb8Wf0uinyvUA+NWWBJVAfoF7N77QRiDngn6ZxCpW6X7wtMX VfcEJK+Gl0IRPigmKnceJCnntkahaxZKy5eAkry28Fm1dTYndmpuDbwEMlGG ujPoldtL4Ev5L8rKnV/MbMpwQr6opx4ex99H16izJRH+zvGcNjBQCfGRyy1G ikziaBWwuu8vSboGHoXEQ9h4uCgKP4pFvIhA6uextddGPCHZYW9X/zIO8wBs FZptyo4FDel6Pi3WgPG1F8ZbwNUCkiYScf2pAKMoclQytCTykoeamQAYHLsS E2NjMd0NykWaxlOVAtZaB7kGLUNpgnasvegnx/tGqspeQNJ1oXxdh4JEtSVA O1lXp+wHEddX39DQl62fYBqnk/LqaQ3Fx7qhTp3vQmrZUL6CBL/VwPu1gs0r jfwBOJiPjzm3Kj26T62FPNiSKd1tbyn1cnI8mz6a96BnNWFy120kIdWaKZSt XMrVwU0mXmdkhbM3bW7d30uS0Ne07hmWErWaAtfia1P8pMZgX9b597TOg0YJ ZtbZrLBT/aVphYXws5EUzW4Nl2YgzSBW4jP8fACv0cj357f3qpdT/8R0em8Y jp0VXfcX2b+xYomjjVUhKl9MBaao8I5OpVxrViEYZtcHzVnWbvjZ11ytjCzv oD+ucu7p4dZJEE3L7u9s1SDgVWzr3Lb/36+y/9+vtP/x45EB71tkgIa6TAY4 q9MqA2pkXlXWG1SqWcWrslQD+ptJgv1zTazZGbL1x+UKz5SsRV3nQLqHoBrc X1DVQXwRVP8CgmpwH0Hl6/xFUK2irBhUPjNB5dWo6pdMRlZVsts7bEOJfuwV k0mI7FaVjEFVrZMT9Xg1zjCrqJfv7XGDMLNGrgzstLcSe+seDcl3PFjMood+ NOwk0k/XBlsTLg5ZOMNa3Qw2LoJq85r49TGHbF5NMtNiO3suGj8L1nCSL/nX R/9sYbH6+tQyIX3mC+W5+v2yUO4UPo+Fql/Ef1mn34TwLUlPapq5pU+7yZGM 8syJlCxcGxq6eROa7g8w5U6bW2lpMhszBfyXC8qi3z/FHE3GmYM1h1ApWcyn mo9FN+V3ozY+9csZk4vjgxCx1HHhfFPzZlVfWFoMGZrtVs3oYDfCK66nnsVW r0Xrlxs2AbQkbELLIFQLlALN1X6W+rN4V3lQf2fbePRKvHVC7XOqTEs402qb mf7Vd6Huvd8Xa1zx67br3PIL1cN/0a9/Xml4sc7w7SkD2rlv8Ntw36CJ+wZr cd9gOfcNvnDfJ+K+4di6k1cvoJVPxuWI6gNe04/+CWyg3rL+bJNbP3AV/pU0 r1DbNAdPIL4Zf5TkCuXBvvl2WHi+jb1tY2/bubftvNK25fGSQVH/BmSSj3sc Kqn3Qk0LTNqj664TUq2Tr226dbaFb2E4fsDys/uz0C2suIjH/jZMBZcQtUbD YnmjeBVI8SqQ5qtAmjdDIsJRcHm3toU87OT+XOMV5+c6g7k/t/eus5z7s9Pb fV5yOMIkpWCiTDAGvOi8O2AdMY7+uDEOp0W8ccfB+ypMnCOFMQNJemuqSWI8 0yLXEcWxiTPvJCpE+cnOY/VsQz6b2Hm8K1+YhOkbeoRwMhzGqTjMEyvrBZfL ykZlRoWPr5P4picO0+hWXM4wQBcBfg8C60q8TIqrPNRJGvBgjJJc9il64qew LLJUvAB1zmRZiUdWI466fhZfjeJSXIZ58ia81QDFBMy5vJRNHbwv4n+E4iJ7 s0h048ureA6sEvmavwyv4uJK/HuMjysx51lq+h0e+3r8v/+L2VJ+vE1Hb+Ke +H6BD7rFj3AqRrH4MZ5G8OUroJq4LOMYI/BxGufhYip+wiwquaEmxsTqAf4/ 0iSZKkBfAQA=[rfced] Please review the "type" attribute of each sourcecode element in the XML file to ensure correctness. If the current list of preferred values for "type" (https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not contain an applicable type, then feel free to let us know. Also, it is acceptable to leave the "type" attribute not set. --> <!--[rfced] Abbreviation a) FYI - We have added expansions for the following abbreviation per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Operations, Administration, and Maintenance (OAM) b) Both the expansion and the acronym for the following terms are used throughout the document. Would you like to update to using the expansion upon first usage and the acronym for the rest of the document? Attachment Circuit (AC) Service Function (SF) --> <!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether the following should be updated: black-hole --> </rfc>