<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.4.19 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc comments="yes"?>

<rfc ipr="trust200902" docName="draft-ygb-ivy-passive-network-inventory-03" category="std">

  <front>
    <title abbrev="Passive Network Inventory YANG Model">A YANG Data Model for Passive Network Inventory</title>

    <author initials="C." surname="Yu" fullname="Chaode Yu">
      <organization>Huawei</organization>
      <address>
        <email>yuchaode@huawei.com</email>
      </address>
    </author>
    <author initials="A." surname="Guo" fullname="Aihua Guo">
      <organization>Futurewei</organization>
      <address>
        <email>aihuaguo.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="I." surname="Busi" fullname="Italo Busi">
      <organization>Huawei</organization>
      <address>
        <email>italo.busi@huawei.com</email>
      </address>
    </author>
    <author initials="M." surname="Boroon" fullname="Mohammad Boroon">
      <organization>Highstreet</organization>
      <address>
        <email>mohammad.boroon@highstreet-technologies.com</email>
      </address>
    </author>
    <author initials="S." surname="Belotti" fullname="Sergio Belotti">
      <organization>Nokia</organization>
      <address>
        <email>sergio.belotti@nokia.com</email>
      </address>
    </author>
    <author initials="T.V." surname="Caenegem" fullname="Tom Van Caenegem">
      <organization>Nokia</organization>
      <address>
        <email>tom.van_caenegem@nokia.com</email>
      </address>
    </author>
    <author initials="S.1." surname="S." fullname="Swaminathan 1. S.">
      <organization>Nokia</organization>
      <address>
        <email>swaminathan.1.s@nokia.com</email>
      </address>
    </author>
    <author initials="S." surname="B." fullname="Swaminathan B.">
      <organization>Nokia</organization>
      <address>
        <email>swaminathan.b@nokia.com</email>
      </address>
    </author>
    <author initials="N." surname="Davis" fullname="Nigel Davis">
      <organization>Ciena</organization>
      <address>
        <email>ndavis@ciena.com</email>
      </address>
    </author>
    <author initials="M." surname="Tilocca" fullname="Mauro Tilocca">
      <organization>FiberCop</organization>
      <address>
        <email>mauro.tilocca@fibercop.it</email>
      </address>
    </author>
    <author initials="B." surname="Peters" fullname="Brad Peters">
      <organization>NBN</organization>
      <address>
        <email>bradpeters@nbnco.com.au</email>
      </address>
    </author>
    <author initials="B.Y." surname="Yun" fullname="Bin Yu Yun">
      <organization>ETRI</organization>
      <address>
        <email>byyun@etri.re.kr</email>
      </address>
    </author>
    <author initials="Y." surname="Liu" fullname="Yucong Liu">
      <organization>China Mobile</organization>
      <address>
        <email>liuyucongyjy@chinamobile.com</email>
      </address>
    </author>
    <author initials="Y." surname="Zhao" fullname="Yang Zhao">
      <organization>China Mobile</organization>
      <address>
        <email>zhaoyangyjy@chinamobile.com</email>
      </address>
    </author>
    <author initials="A." surname="Sakalabhaktula" fullname="Avinash Sakalabhaktula">
      <organization>Radisys</organization>
      <address>
        <email>Avinash.Sakalabhaktula@radisys.com</email>
      </address>
    </author>

    <date year="2026" month="January" day="08"/>

    
    <workgroup>IVY Working Group</workgroup>
    

    <abstract>


<t>This document presents a YANG data model for tracking and managing passive network
   inventory. The model enhances the base model outlined in <xref target="I-D.draft-ietf-ivy-network-inventory-yang"/>
   and is intended for use in the northbound interface of a domain controller as defined in
   <xref target="RFC8453"/>.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t>Passive infrastructure refers to the underlying infrastructure of a telecommunication network that is 
   not actively detectable or managable. It typically includes non-powered, non-communicating devices and components,
   such as cabinets, cables, connectors, splitters, antennas, distribution frames, etc., that are either hosted 
   within an actively managed device or deployed along the physical pathway between active devices.
   Passive infrastructure serves as physical connections between active network devices, forming the 
   backbone for network topology. As a crucial part of communication networks,the inventory information
   for these devices is also essential for inventory management.</t>

<t><xref target="I-D.draft-ietf-ivy-network-inventory-yang"/> incorporates the component concept from <xref target="RFC8348"/> to detail the equipment and holder information of a NE. This encompasses chassis, slot/sub-slot, board/sub-board, port, and transceiver. As these items are recognized by the NE through internal protocols, the passive devices that cannot be discovered by the NE are thus not included in the modeling and needs to be addressed.</t>

<t><xref target="I-D.draft-ietf-ivy-network-inventory-location"/> emphasizes the relative and geographic location, e.g. equipment room, geo-loation for NE. A passive device is deployed in a certain location visible by the operator, and thus can reference the location defined by <xref target="I-D.draft-ietf-ivy-network-inventory-location"/>.</t>

<t>This document focuses on modeling passive device inventory. The scope of this model is intended to be applicable to a varity types of networks, including but not limited to, IP/MPLS, optical access, optical transport and microwave networks.
   The methods for learning about these devices are implementation-specific and fall outside the scope of this document.</t>

</section>
<section anchor="examples-of-passive-network-inventory"><name>Examples of Passive Network Inventory</name>
<t>Network segments built on different technologies share many common passive infrastructure components across the system. To explore the practical applications of these components, we can examine example scenarios for optical access networks, optical transport systems, and microwave networks.</t>

<section anchor="passive-infrastructure-in-optical-transport-networks"><name>Passive Infrastructure in Optical Transport Networks</name>
<t>Passive infrastructure in optical transport networks serves as the backbone for high-capacity data transmission. Key components include fiber optic cables, which act as the primary medium of long distance transmission. Optical connectors, patch panels, and splice enclosures are crucial for joining and managing fiber links. Couplers and splitters are used for signal distribution and combining.</t>

<t>Within a phyical network element (NE) there are also presence of passive components. For example, fiber optic cables are used to connect the ports of different modules within the same or between different chassises. Attenuators, on the other hand, are placed at places through connectors or built-in modules for reducing optical power.</t>

<t><xref target="fig-example-optical-transport"/> illustrates a typical passive infrastructure for a point-to-point optical transport network.</t>

<figure title="Passive Infrastructure for Optical Transport Networks" anchor="fig-example-optical-transport"><artwork type="ascii-art"><![CDATA[
                                  Port
+--------------+                  +-+                 +--------------+
| +---+        |            +-----+ +----+            |        +---+ |
| |  +++       |<--Cable--->|     +-+    |<--Cable--->|       +++  | |
| |  ++* +---+ |            |    /   \   |            | +---+ *++  | |
| |NE |\+++  | |Cable- Cable|  /      \  |Cable- Cable| |  +++/| NE| |
| +---+ *++ +++|<-->| |<-->+++/        \+++<->| |<--->|+++ ++* +---+ |
|        |  + +|----| |----+ |----------| +---| |-----|+ +  |        |
|       +++ +++|----| |----+++\        /+++---| |-----|+++ +++       |
| +---+/*++  | |     -      |  \      /  |     -      | |  ++*\+---+ |
| |  +*+ |ODF| |    Joint   |   \    /   |    Joint   | |ODF| +*+  | |
| |  +++ +---+ |    Box     |    \  /    |    Box     | +---+ +++  | |
| |NE |        |            |     *-+    |            |        | NE| |
| +---+        |            +-----+ +----+            |        +---+ |
|Central Office|                  +-+                 |Central Office|
+--------------+              Fiber                   +--------------+
                              Distribution
                              Terminal
]]></artwork></figure>

</section>
<section anchor="passive-infrastructure-in-optical-access-networks"><name>Passive Infrastructure in Optical Access Networks</name>
<t>Passive Optical Networks (PONs) are a typical type of optical access network with significant passive infrastructure. The passive infrastructure in PON, often referred to as Optical Distribution Network (ODN), is the physical optical fiber-based network that connects the Optical Line Terminal (OLT) typically hosted in a central office to the Optical Network Unit/Terminal (ONU/ONT) typically deployed at the user's location. The ODN is equipped with one or multiple cascaded passive optical splitter thus creating a physical point-to-multipoint fiber network between an OLT port and the multiple connected ONU/ONTs.</t>

<t>The feeder segment of an ODN refers to the cabling between the OLT and the first splitter, whereas the distribution segment of the ODN comprises the fiber cabling between the first and second splitter stage. The drop segment comprises the drop fibers between the ONT/ONU and the second splitter stage.</t>

<t>The PON ODN hence comprises optical fiber cables and splitters but also many auxiliary components, such as connectors, fiber distribution terminals (FDT), fiber access terminals (FAT), wavelength co-existence elements, etc. The passive components where the optical signals entering or leaving the optical fibers are split/combined or cross-connected are typically hosted in mini cabinets e.g. at street corners, manholes, attached to utility poles, etc.</t>

<t><xref target="fig-example-optical-access"/> illustrates a typical passive infrastructure for optical access networks.</t>

<figure title="Passive Infrastructure for Optical Access Networks" anchor="fig-example-optical-access"><artwork type="ascii-art"><![CDATA[
                                                        
+--------------+                                    <--Drop-->
| +---+        |                                       Cable
| |  +++       |<-Feeder Cable->    <--Distr.-->  /|----------+-+ONU
| |  ++* +---+ |                       Cable     / |          +-+
| |NE |\+++  | | Cable -  Cable   /|------------x  |FDT
| +---+ *++ +++|<---->/ \<---->  / |             \ |        
| (OLT)  |  + +|------| |------x/  |              \|----------+-+ONU
|       +++ +++|------| |------x   | cccccccc                 +-+
| +---+/*++  | |      \ /       \  | c   /| c          
| |  +*+ |ODF| |       -         \ | c  / | c          
| |  +++ +---+ |     Joint        \|-c-x  | c          
| |NE |        |     Box        FDT  c  \ | c<---Drop Cable-->+-+ONU
| +---+        |                     c   \|-c-----------------+-+
| (OLT)        |                     c FDT <c
|              |                     c      c
|Central Office|                     cccccccc
+--------------+                     Cabinet

]]></artwork></figure>

</section>
<section anchor="passive-infrastructure-in-microwave-networks"><name>Passive Infrastructure in Microwave Networks</name>
<t>To be developed.</t>

</section>
</section>
<section anchor="terminology-and-notations"><name>Terminology and Notations</name>

<section anchor="requirements-notations"><name>Requirements Notations</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>

</section>
<section anchor="terminology"><name>Terminology</name>
<t>The following terms are defined in <xref target="RFC7950"/> and are not redefined here:</t>

<t><list style="symbols">
  <t>client</t>
  <t>server</t>
  <t>augment</t>
  <t>data model</t>
  <t>data node</t>
</list></t>

<t>The following terms are defined in <xref target="RFC6241"/> and are not redefined here:</t>

<t><list style="symbols">
  <t>configuration data</t>
  <t>state data</t>
</list></t>

<t>The following terms are defined and used in this document.</t>

<t><list style="symbols">
  <t>Passive device: refers to a physical device within a network that does not require external power to function, and simply manipulates signals through processes like transmission, reflection, splitting, filtering, or attenuation without actively amplifying or generating the signal. Examples include optical fibers, splitters, couplers, and optical filters, all of which are used to direct signals within a system without needing power. A passive device typically does not have management interfaces and is typically deployed in a location tracked by the network operator.</t>
  <t>Active device: refers to a physical device that contains hardware and software and is managable through communication interfaces. Network elements defined by <xref target="I-D.draft-ietf-ivy-network-inventory-yang"/> are examples of active device.</t>
  <t>Guiding media: refers to physical transmission pathways - such as optical fiber cables, electrical cables, and coaxial cables - that direct and confine electromagnetic signals along a specific route. These media provide a bounded channel for data transmission, ensuring signal integrity, minimizing interference, and enabling high-speed communication over varying distances. This category is also commonly known as guided media or wired transmission media. Guiding media can be concatenated to form longer guiding media.</t>
  <t>Optical Cable: refers to a type of guiding media that uses optical fiber as media to transmit optical signals. An optical cable can contain one or multiple fiber cores, also known as fiber strands, each serving as an independent guiding media for data transmission. Optical cables can be spliced or fused through joint boxes, optical distribution frames (ODF), or fiber jumpers.</t>
  <t>Electrical Cable: refers to a type of guiding media that uses metal conductors (such as copper or aluminum wires) as a medium to carry electrical signals for communication or power distribution. Common examples include twisted-pair cables (such as CAT-5/6 and DSL cables), and coaxial cables, which feature a single-core conductor commonly used in DOCSIS and MoCA-based broadband access networks. Electrical cables can be connected through splicing, connectors, or junction boxes.</t>
</list></t>

</section>
<section anchor="tree-diagram"><name>Tree Diagram</name>

<t>Tree diagrams used in this document follow the notation defined in
   <xref target="RFC8340"/>.</t>

</section>
<section anchor="prefixes-in-data-node-names"><name>Prefixes in Data Node Names</name>

<t>In this document, names of data nodes and other data model objects
   are prefixed using the standard prefix associated with the
   corresponding YANG imported modules, as shown in <xref target="tab-prefixes"/>.</t>

<texttable title="Prefixes and Corresponding YANG Modules" anchor="tab-prefixes">
      <ttcol align='left'>Prefix</ttcol>
      <ttcol align='left'>YANG Module</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>nwi</c>
      <c>ietf-network-inventory</c>
      <c>RFC XXXX</c>
      <c>nil</c>
      <c>ietf-ni-location</c>
      <c>RFC YYYY</c>
</texttable>

<t>RFC Editor Note:
Please replace XXXX with the RFC number assigned to <xref target="I-D.draft-ietf-ivy-network-inventory-yang"/>.
Please replace YYYY with the RFC number assigned to <xref target="I-D.draft-ietf-ivy-network-inventory-location"/>.
Please remove this note.</t>

</section>
</section>
<section anchor="modeling-considerations"><name>Modeling Considerations</name>

<section anchor="relationship-with-network-inventory"><name>Relationship with Network Inventory</name>
<t>TBD</t>

</section>
<section anchor="relationship-with-topology"><name>Relationship with Topology</name>
<t>TBD</t>

</section>
</section>
<section anchor="yang-model-overview"><name>YANG Model Overview</name>

<t>The YANG data model in this draft augments the model defined in <xref target="I-D.draft-ietf-ivy-network-inventory-yang"/> with the following information:
   - Passive devices: a list of passive devices with extended attributed reported by the domain controller.
   - Cables: a list of cables with each containing an optional list of child cables.</t>

</section>
<section anchor="model-tree-diagram"><name>Model Tree Diagram</name>
<figure title="Tree diagram for passive network inventory" anchor="fig-nwi-passive-tree"><artwork><![CDATA[
module: ietf-nwi-passive-inventory

  augment /nwi:network-inventory:
    +--rw cable* [id]
    |  +--rw id               string
    |  +--rw length?          uint32
    |  +--rw a-end
    |  |  +--rw device-type?           identityref
    |  |  +--rw (connected-device-type)?
    |  |     +--:(passive)
    |  |     |  +--rw device-id?       string
    |  |     +--:(active)
    |  |        +--rw ne-ref?          leafref
    |  |        +--rw component-ref?   leafref
    |  +--rw z-end
    |  |  +--rw device-type?           identityref
    |  |  +--rw (connected-device-type)?
    |  |     +--:(passive)
    |  |     |  +--rw device-id?       string
    |  |     +--:(active)
    |  |        +--rw ne-ref?          leafref
    |  |        +--rw component-ref?   leafref
    |  +--ro uuid?            yang:uuid
    |  +--rw name?            string
    |  +--rw description?     string
    |  +--rw alias?           string
    |  +--rw cable-type?      identityref
    |  +--rw cable-role?      identityref
    |  +--rw optical-cable
    |  |  +--rw fiber-core-num?   uint32
    |  |  +--rw fiber-type?       identityref
    |  |  +--rw attenuation?      decimal64
    |  +--rw child-cable* [index]
    |     +--rw index     uint8
    |     +--rw id?       string
    |     +--rw length?   uint32
    |     +--rw a-end
    |     |  +--rw device-type?           identityref
    |     |  +--rw (connected-device-type)?
    |     |     +--:(passive)
    |     |     |  +--rw device-id?       string
    |     |     +--:(active)
    |     |        +--rw ne-ref?          leafref
    |     |        +--rw component-ref?   leafref
    |     +--rw z-end
    |        +--rw device-type?           identityref
    |        +--rw (connected-device-type)?
    |           +--:(passive)
    |           |  +--rw device-id?       string
    |           +--:(active)
    |              +--rw ne-ref?          leafref
    |              +--rw component-ref?   leafref
    +--rw passive-device* [id]
       +--rw id              string
       +--ro uuid?           yang:uuid
       +--rw name?           string
       +--rw description?    string
       +--rw alias?          string
       +--rw device-type?    identityref
       +--rw custom-tags*    string
       +--rw location-ref?   nil:ni-location-ref
       +--rw passive-port* [id]
          +--rw id                string
          +--ro uuid?             yang:uuid
          +--rw name?             string
          +--rw description?      string
          +--rw alias?            string
          +--rw port-type?        identityref
          +--rw fiber-core-num?   uint32
]]></artwork></figure>

</section>
<section anchor="yang-modules"><name>YANG Modules</name>

<section anchor="yang-data-model-for-passive-device-inventory"><name>YANG Data Model for Passive Device Inventory</name>
<figure title="YANG model for passive network inventory" anchor="fig-nwi-passive-yang"><artwork><![CDATA[
   <CODE BEGINS> file "ietf-nwi-passive-inventory@2025-07-07.yang"
module ietf-nwi-passive-inventory {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory";
  prefix nwi-passive;
  
  import ietf-network-inventory {
    prefix nwi;
    reference
    "RFCXXXX: A YANG Data Model for Network Inventory";
    //RFC Editor: replace XXXX with actual RFC number
    //and remove this note
  }
  import ietf-ni-location {
    prefix nil;
    reference
    "RFCYYYY: A YANG Data Model for Network Inventory Location";
    //RFC Editor: replace YYYY with actual RFC number
    //and remove this note
  }

  organization
    "IETF Network Inventory YANG (ivy) Working Group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/ivy/>
     WG List:  <mailto:inventory-yang@ietf.org>

     Editor:   Chaode Yu
               <yuchaode@huawei.com>

     Editor:   Aihua Guo
               <aihuaguo.ietf@gmail.com>

     Editor:   Italo Busi
               <italo.busi@huawei.com>";

  description
    "This YANG module specifies a data model for passive
     devices, such as fibers, cables, and passive sites,
     deployed within and between network elements.

    The model fully conforms to the Network Management 
    Datastore Architecture (NMDA).
    
    Copyright (c) 2023 IETF Trust and the persons
    identified as authors of the code.  All rights reserved.

    Redistribution and use in source and binary forms, with or
    without modification, is permitted pursuant to, and subject
    to the license terms contained in, the Revised BSD License
    set forth in Section 4.c of the IETF Trust's Legal Provisions
    Relating to IETF Documents
    (https://trustee.ietf.org/license-info).

    This version of this YANG module is part of RFC XXXX; see
    the RFC itself for full legal notices.

    The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
    NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
    'MAY', and 'OPTIONAL' in this document are to be interpreted as
    described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
    they appear in all capitals, as shown here.";

  // RFC Ed.: replace XXXX with actual RFC number and remove this
  // note.
  // RFC Ed.: update the date below with the date of RFC publication
  // and remove this note.
  
  revision 2025-07-07 {
    description
      "Initial version";
    reference
      "RFC XXXX: A YANG Data Model for Passive Device Info in
       Network Inventory.";
      //RFC Editor: replace XXXX with actual RFC number, update date
      //information and remove this note
  }
  
  /* Identities */
  identity fiber-type {
    description
      "Base identity for fiber types.";
  }
  identity G652A {
    base fiber-type;
    description
      "ITU-T G.652A fiber.";
  }
  identity G652B {
    base fiber-type;
    description
      "ITU-T G.652B fiber.";
  }
  identity G652C {
    base fiber-type;
    description
      "ITU-T G.652C fiber.";
  }
  identity G652D {
    base fiber-type;
    description
      "ITU-T G.652D fiber.";
  }
  identity G653 {
    base fiber-type;
    description
      "ITU-T G.653 fiber.";
  }
  identity G654 {
    base fiber-type;
    description
      "ITU-T G.654 fiber.";
  }
  identity G655 {
    base fiber-type;
    description
      "ITU-T G.655 fiber.";
  }
  identity G656 {
    base fiber-type;
    description
      "ITU-T G.656 fiber.";
  }
  identity G657A1 {
    base fiber-type;
    description
      "ITU-T G.657A1 fiber.";
  }
  identity G657A2 {
    base fiber-type;
    description
      "ITU-T G.657A2 fiber.";
  }
  identity G657B {
    base fiber-type;
    description
      "ITU-T G.657B fiber.";
  }
  identity other {
    base fiber-type;
    description
      "Other type of fiber.";
  }

  identity cable-type {
    description
      "Base identity for cable types.";
  }
  identity optical-fiber {
    base cable-type;
    description
      "Fiber optic cable.";
  }
  identity electrical-cable {
    base cable-type;
    description
      "Electrical cable.";
  }
  identity coaxial-cable {
    base electrical-cable;
    description
      "Coaxial cable.";
  }

  identity cable-role {
    description
      "Base identity for cable roles.";
  }
  identity backbone {
    base cable-role;
    description
      "Backbone cable.";
  }
  identity aggregation {
    base cable-role;
    description
      "Aggregation cable.";
  }
  identity access {
    base cable-role;
    description
      "Access cable.";
  }
  identity trunk {
    base cable-role;
    description
      "Trunk cable.";
  }
  identity distribution {
    base cable-role;
    description
      "Distribution cable.";
  }
  identity branch {
    base cable-role;
    description
      "Branch cable.";
  }

  identity passive-port-type {
    description
      "Base identity for passive port types.";
  }
  identity service-port {
    base passive-port-type;
    description
      "Service port.";
  }
  identity input-port {
    base passive-port-type;
    description
      "Input port.";
  }
  identity output-port {
    base passive-port-type;
    description
      "Output port.";
  }
  identity p2mp-port {
    base passive-port-type;
    description
      "Input port.";
  }

  identity connected-device-type {
    description
      "Base identity for connected device types.";
  }
  identity passive-device {
    base connected-device-type;
    description
      "Passive/unmanaged device.";
  }
  identity active-device {
    base connected-device-type;
    description
      "Active device, e.g. network element.";
  }

  identity passive-device-type {
    description
      "Base identity for passive device types.";
  }
  identity ODF {
    base passive-device-type;
    description
      "Optical Distribution Frame.";
  }
  identity WDM {
    base passive-device-type;
    description
      "Wavelength Division Multiplexer.";
  }
  identity FAT {
    base passive-device-type;
    description
      "Fiber Access Terminal.";
  }
  identity FDT {
    base passive-device-type;
    description
      "Fiber Distribution Terminal.";
  }
  identity ATB {
    base passive-device-type;
    description
      "Access Terminal Box.";
  }
 
  /* Groupings */
  grouping connected-device-end {
    description
      "Attributes applicable to connected device end.";

    leaf device-type {
      type identityref {
        base connected-device-type;
      }
      description
        "Type of connected device.";
    }
    
    choice connected-device-type {
      description
        "Device end based on the type of connected device.";
      case passive {
        leaf device-id {
          type string;
          must "derived-from-or-self(../device-type,
               'nwi-passive:passive-device')";
          description
            "Connected passive device identifier.";
        }
      }
      case active {
        leaf ne-ref {
          type leafref {
            path "/nwi:network-inventory/nwi:network-elements"
               + "/nwi:network-element/nwi:ne-id";
          }
          must "derived-from-or-self(../device-type,
               'nwi-passive:active-device')";
          description
            "Referenced Network Element (NE).";
        }
        leaf component-ref {
          type leafref {
            path "/nwi:network-inventory/nwi:network-elements"
               + "/nwi:network-element[nwi:ne-id=current()/.."
               + "/ne-ref]/nwi:components/nwi:component"
               + "/nwi:component-id";
          }
          must "derived-from-or-self(../device-type,
               'nwi-passive:active-device')";
          description
            "Referenced connected active device's component,
             e.g. port component.";
        }
      }
    }    
  }

  grouping connected-device-ref {
    description
      "Attributes applicable to connected devices.";

    container a-end {
      description
        "A-end device reference";
      uses connected-device-end;
    }

    container z-end {
      description
        "Z-end device reference";
      uses connected-device-end;
    } 
  }

  grouping common-cable-attributes {
    description
      "Common attributes of cables applicable to the cable
       and its child cables.";

    leaf id {
      type string;
      description
        "Cable identifier.";
    }

    leaf length {
      type uint32;
      units "meter";
      description
        "Length of the cable in meter.";
    }

    uses connected-device-ref;
  }
  
  grouping optical-cable-attributes {
    description
      "Attributes applicable to fiber optic cables.";

    container optical-cable {
      when
        "derived-from-or-self(../cable-type, 'optical-fiber')";

      description
        "Container for attributes associated with fiber
         optic cables.";

      leaf fiber-core-num {
        type uint32;
        description
          "Number of fiber cores within the cable.";
      }
      leaf fiber-type {
        type identityref {
          base fiber-type;
        }
        description
          "Type of fiber contained in the cable.";
      }
      leaf attenuation {
        type decimal64 {
          fraction-digits 2;
        }
        units "dB";
        description
          "The fiber attenuation in dB.";
      }
    }
  } 

  grouping cable-attributes {
    description
      "Attributes of cables.";

    uses common-cable-attributes;
    uses nwi:basic-common-entity-attributes;

    leaf cable-type {
      type identityref {
        base cable-type;
      }
      description
        "Type of cable.";
    }

    leaf cable-role {
      type identityref {
        base cable-role;
      }
      description
        "Role of cable.";
    }
    
    uses optical-cable-attributes;
  }

  grouping child-cables {
    description
      "Attributes applicable to child cables that are concatnated
       to form the cable.";

    list child-cable {
      key "index";
      min-elements 2;
      description
        "Ordered list of concatenated child cables.";

      leaf index {
        type uint8;
        description
          "An index number used to identify the concatenation
           order of the child cables.";
      }

      uses common-cable-attributes;
    }
  }
  
  grouping cables {
    description
      "Attributes applicable to cables.";

    list cable {
      key "id";
      description
        "List of cables.";

      uses cable-attributes;
      uses child-cables;    
    }
  }  

  grouping passive-device-ports {
    description
      "Attributes applicable to passive device ports.";

    list passive-port {
      key "id";
      description
        "List of ports on a passive device.";
 
      leaf id {
        type string;
        description
          "Port identifier.";
      }
      uses nwi:basic-common-entity-attributes;
      leaf port-type {
        type identityref {
          base passive-port-type;
        }
        description
          "Type of passive port.";
      }
      leaf fiber-core-num {
        type uint32;
        description
          "Number of fiber cores within the port.";
      }
    }
  }  

  grouping passive-devices {
    description
      "Attributes applicable to passive devices.";

    list passive-device {
      key "id";
      description
        "List of passive devices.";

      leaf id {
        type string;
        description
          "Cable identifier.";
      }
      uses nwi:basic-common-entity-attributes;
      leaf device-type {
        type identityref {
          base passive-device-type;
        }
        description
          "Type of passive device.";
      }
      leaf-list custom-tags {
        type string;
        description
          "Customized tags, e.g. RFID, QR code that are
           attached to the device.";
      }
      leaf location-ref {
        type nil:ni-location-ref;
        description
          "Referenced location for the passive device.";
      }
      uses passive-device-ports;
    }
  }  
  
  /* Augmentation */
  augment "/nwi:network-inventory" {
      description
        "Augment network inventory with information
         for optical cables and passive devices.";
      uses cables;
      uses passive-devices;
  }
}
   <CODE ENDS>
]]></artwork></figure>

</section>
</section>
<section anchor="manageability-considerations"><name>Manageability Considerations</name>

<t>TBD.</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>The YANG module specified in this document defines a schema for data
   that is designed to be accessed via network management protocols such
   as NETCONF <xref target="RFC6241"/> or RESTCONF <xref target="RFC8040"/>.  The lowest NETCONF layer
   is the secure transport layer, and the mandatory-to-implement secure
   transport is Secure Shell (SSH) <xref target="RFC6242"/>.  The lowest RESTCONF layer
   is HTTPS, and the mandatory-to-implement secure transport is TLS
   <xref target="RFC8446"/>.</t>

<t>The NETCONF access control model <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>There are a number of data nodes defined in this YANG module that are
   writable/creatable/deletable (i.e., config true, which is the
   default).  These data nodes may be considered sensitive or vulnerable
   in some network environments.  Write operations (e.g., edit-config)
   to these data nodes without proper protection can have a negative
   effect on network operations.  Considerations in Section 8 of
   <xref target="RFC8795"/> are also applicable to their subtrees in the module defined
   in this document.</t>

<t>Some of the readable data nodes in this YANG module may be considered
   sensitive or vulnerable in some network environments.  It is thus
   important to control read access (e.g., via get, get-config, or
   notification) to these data nodes.  Considerations in Section 8 of
   <xref target="RFC8795"/> are also applicable to their subtrees in the module defined
   in this document.</t>

</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>It is proposed to IANA to assign new URIs from the "IETF XML
   Registry" <xref target="RFC3688"/> as follows:</t>

<figure><artwork><![CDATA[
   URI: urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory
   Registrant Contact: The IESG
   XML: N/A; the requested URI is an XML namespace.
]]></artwork></figure>

<t>This document registers the following YANG module in the YANG Module Names
   registry <xref target="RFC6020"/>.</t>

<figure><artwork><![CDATA[
   name: ietf-nwi-passive-inventory
   namespace: urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory
   prefix: nwi-passive
   reference: RFC XXXX
]]></artwork></figure>

</section>


  </middle>

  <back>

    <references title='Normative References'>




<reference anchor='I-D.draft-ietf-ivy-network-inventory-yang' target='https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-yang-12'>
   <front>
      <title>A Base YANG Data Model for Network Inventory</title>
      <author fullname='Chaode Yu' initials='C.' surname='Yu'>
         <organization>Huawei Technologies</organization>
      </author>
      <author fullname='Sergio Belotti' initials='S.' surname='Belotti'>
         <organization>Nokia</organization>
      </author>
      <author fullname='Jean-Francois Bouquier' initials='J.' surname='Bouquier'>
         <organization>Vodafone</organization>
      </author>
      <author fullname='Fabio Peruzzini' initials='F.' surname='Peruzzini'>
         <organization>FiberCop</organization>
      </author>
      <author fullname='Phil Bedard' initials='P.' surname='Bedard'>
         <organization>Cisco</organization>
      </author>
      <date day='22' month='December' year='2025'/>
      <abstract>
	 <t>   This document defines a base YANG data model for reporting network
   inventory.  The scope of this base model is set to be application-
   and technology-agnostic.  The base data model can be augmented with
   application- and technology-specific details.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-ivy-network-inventory-yang-12'/>
   
</reference>

<reference anchor='RFC8453' target='https://www.rfc-editor.org/info/rfc8453'>
  <front>
    <title>Framework for Abstraction and Control of TE Networks (ACTN)</title>
    <author fullname='D. Ceccarelli' initials='D.' role='editor' surname='Ceccarelli'/>
    <author fullname='Y. Lee' initials='Y.' role='editor' surname='Lee'/>
    <date month='August' year='2018'/>
    <abstract>
      <t>Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity.</t>
      <t>Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources.</t>
      <t>This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8453'/>
  <seriesInfo name='DOI' value='10.17487/RFC8453'/>
</reference>

<reference anchor='RFC8348' target='https://www.rfc-editor.org/info/rfc8348'>
  <front>
    <title>A YANG Data Model for Hardware Management</title>
    <author fullname='A. Bierman' initials='A.' surname='Bierman'/>
    <author fullname='M. Bjorklund' initials='M.' surname='Bjorklund'/>
    <author fullname='J. Dong' initials='J.' surname='Dong'/>
    <author fullname='D. Romascanu' initials='D.' surname='Romascanu'/>
    <date month='March' year='2018'/>
    <abstract>
      <t>This document defines a YANG data model for the management of hardware on a single server.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8348'/>
  <seriesInfo name='DOI' value='10.17487/RFC8348'/>
</reference>


<reference anchor='I-D.draft-ietf-ivy-network-inventory-location' target='https://datatracker.ietf.org/doc/html/draft-ietf-ivy-network-inventory-location-03'>
   <front>
      <title>A YANG Data Model for Network Inventory Location</title>
      <author fullname='Bo Wu' initials='B.' surname='Wu'>
         <organization>Huawei</organization>
      </author>
      <author fullname='Sergio Belotti' initials='S.' surname='Belotti'>
         <organization>Nokia</organization>
      </author>
      <author fullname='Jean-Francois Bouquier' initials='J.' surname='Bouquier'>
         <organization>Vodafone</organization>
      </author>
      <author fullname='Fabio Peruzzini' initials='F.' surname='Peruzzini'>
         <organization>FiberCop</organization>
      </author>
      <author fullname='Phil Bedard' initials='P.' surname='Bedard'>
         <organization>Cisco</organization>
      </author>
      <date day='7' month='July' year='2025'/>
      <abstract>
	 <t>   This document defines a YANG data model for Network Inventory
   location (e.g., site, room, rack, geo-location data), which provides
   location information with different granularity levels for
   inventoried network elements.

   Accurate location information is useful for network planning,
   deployment, and maintenance.  However, such information cannot be
   obtained or verified from the Network Elements themselves.  This
   document defines a location model for network inventory that extends
   the base inventory with comprehensive location data.

	 </t>
      </abstract>
   </front>
   <seriesInfo name='Internet-Draft' value='draft-ietf-ivy-network-inventory-location-03'/>
   
</reference>

<reference anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
  <front>
    <title>Key words for use in RFCs to Indicate Requirement Levels</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='March' year='1997'/>
    <abstract>
      <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='2119'/>
  <seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
  <front>
    <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
    <author fullname='B. Leiba' initials='B.' surname='Leiba'/>
    <date month='May' year='2017'/>
    <abstract>
      <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='14'/>
  <seriesInfo name='RFC' value='8174'/>
  <seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>

<reference anchor='RFC7950' target='https://www.rfc-editor.org/info/rfc7950'>
  <front>
    <title>The YANG 1.1 Data Modeling Language</title>
    <author fullname='M. Bjorklund' initials='M.' role='editor' surname='Bjorklund'/>
    <date month='August' year='2016'/>
    <abstract>
      <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='7950'/>
  <seriesInfo name='DOI' value='10.17487/RFC7950'/>
</reference>

<reference anchor='RFC6241' target='https://www.rfc-editor.org/info/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='RFC8340' target='https://www.rfc-editor.org/info/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>
  <seriesInfo name='BCP' value='215'/>
  <seriesInfo name='RFC' value='8340'/>
  <seriesInfo name='DOI' value='10.17487/RFC8340'/>
</reference>

<reference anchor='RFC8040' target='https://www.rfc-editor.org/info/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='RFC6242' target='https://www.rfc-editor.org/info/rfc6242'>
  <front>
    <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
    <author fullname='M. Wasserman' initials='M.' surname='Wasserman'/>
    <date month='June' year='2011'/>
    <abstract>
      <t>This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK]</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='6242'/>
  <seriesInfo name='DOI' value='10.17487/RFC6242'/>
</reference>

<reference anchor='RFC8446' target='https://www.rfc-editor.org/info/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='RFC8341' target='https://www.rfc-editor.org/info/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='RFC8795' target='https://www.rfc-editor.org/info/rfc8795'>
  <front>
    <title>YANG Data Model for Traffic Engineering (TE) Topologies</title>
    <author fullname='X. Liu' initials='X.' surname='Liu'/>
    <author fullname='I. Bryskin' initials='I.' surname='Bryskin'/>
    <author fullname='V. Beeram' initials='V.' surname='Beeram'/>
    <author fullname='T. Saad' initials='T.' surname='Saad'/>
    <author fullname='H. Shah' initials='H.' surname='Shah'/>
    <author fullname='O. Gonzalez de Dios' initials='O.' surname='Gonzalez de Dios'/>
    <date month='August' year='2020'/>
    <abstract>
      <t>This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='8795'/>
  <seriesInfo name='DOI' value='10.17487/RFC8795'/>
</reference>

<reference anchor='RFC3688' target='https://www.rfc-editor.org/info/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' target='https://www.rfc-editor.org/info/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'/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIALjxXmkAA+0923YbN5LvOsf/gJUfLFls0vc4dCYxJUqOdnXxSPR4PPGc
OU02SHbc7Ob0RTITab9lv2W/bOsCoIG+UBdnz87DcjIWyQaqClWFqkKhAHqe
92BjkgRhPOuLIp96rx9sPNjIwzySfTEQnwYn78TQz31xnAQyEtMkFe/9LAsv
pDiR+WWSfhGH8YWM8yRdYU9/PE7lRb+9EYMkaA82gmQS+wvAFKT+NPdWs7EX
Xqy8JXf2Yu7shbqz9+T5gw38apYmxbIvDv/ySXyEj0C9eIdfwVj8XM6gaV9k
efBgI1ymfZGnRZY/e/Lk+yfPkMYs9+PgH36UxIB5JbMHG8uwL37Jk0lHZEma
p3KawbvVgt9MksUC0Gd/p/EV+TxJ+w82hPDwHyF4AHtzH4YkPhX8ZZICO38u
/EsZ8hdy4YcRYCsm1PDtnJ51AXYN1CCEh+JdkVigDoq8SGUVmo8tZ0XSDWU+
fTvDLxshHuYwWLFbZOF66kJs1x1Du3X0HSdzf7HwA7GbpEkS2yDD2TwD9snc
AbtQHbpj6vB2bpp5uZzM4yRKZqHMGpGdy3QWAu0ySvLcJv8k+RL6DpqMmnbH
3PRtjA0aYY6ShfiLH4s9X8ZyJhdroebJonvhx/+YqMZr4J5f+osw9vM5wH7a
Fefd9eSWrbtPu9kt4e7eHuh4DciTcAazeehfhJkFby+UsQsvDrDJ2wk+aFYG
v0gTMQqjZDLxbYUNxzLdS5auImDjbs6N306xySRZdsO8BnY3Bf16L3OZ2vSd
7J448MbQakmN3sbjeJIghV2/qEMLY5iZ8J+trPujs0MX2mpVxG9lnobdVHa/
pDUwn4pJAobmKLQn+d4c+A1zYhxG0gEXhcWKOqx+Xb2dYKsFNWpk4ycfAP8N
TMNtIP8G7Vb+7QAPLuB5Nhfn/hc/8sdz/0teRLagzvwgzFaZg0B16rqd3qbc
lPHo/3meJ/wxTGd/kuNngDKah5kA016g2RTLVGZoPoXPpj9Ab7Iw3gQ7kv0G
mwwKEvsz/KA8gFAegMAaL9AFDFKBkDGo+kRmIoevxn6mv0+KPApjGUAv8fvv
/3boDbvsY9BUkpOpOxfk6fU14UJiYBBhnMs4AChIaQHAARoiisFLzMdJga2g
STr1J1IkUxhikAALY/AZcZ4mUSRT4QMv5FTRQsCBnrODvdcvXj6/vu4K+Iq5
uAiDACX9YOMhuEvoHhSTPEQDS720Rw3jaeoDv+EhuAQBPgr0H8wUEQYUyTRa
IQsr7Yi6XEYS3VkRh+AnAbZmMHT2cxwxoYqTXIA4AVu0AuLBSOf+OAIYKUsI
P3TBq4h8tQRAEbQK40lUBCCHOIm9ZXIpUxl06IOFD6gK5EWI4kIGw5Ml+GDQ
jQ6hzcA5Irsm/hjYlaPrRUzkguMYiEhS9MvLKMxxzncACIgHNLUjQDFh3o4L
GhOMe4G9ZD7pdnhkPnBAhsChVMyTLAdZEMZL+AqkBXbVDJcGCM+ZUBxyIJdR
soKvMGKYEZuX81WGAwc9zeeX/kqMgY1SajB6lN11ggN3dYGMyEpoapgwhqwK
UctJQe6gRi5CRQ6hGcM8GgM7SVeNWJMleleYMgOcgBNAHhLZaY4a0agLWQdh
mmmBdAMun1URENGsncOkNsIEvfGjLBEyw5mOCLBNCYF5itaAOaJnwR1mJSpY
ki6TFMI7nuxGe5BtE7nMQe7g2NXkev7iNXSCWQHqCzaNesh/FuGSbBJq3zyJ
YK7Yo+M5crLfZQsmY0QBwgOEELWBEFH7ILjoZcXYwzcdMU78NKDP9K4jgMK8
Q/DBsMXZRILwUuI+syzM5SIjdUxhJs7i8DdQrPGK6DvZhz8Qxc7mbFVilFSa
QFyaRFmHFU/pkuY8KffEj3HGjiVOg0lygXPPgonI8nmR0bRW8zTQloyspTa/
sZQBmRIA5QdBivIMusr+3FZe4NyJm8B+uVgC32CILLFURj4pM+KayWSW+st5
OBG6B8zY7qxriQmixUUHWwJQlhDqFQpoUOEEqqCZpzijxUSmOVpiDVxAHBOi
EVOMSZYSdClJlbCQP8BHNqcgeUmNTGdtwaHz3flgKb3rGqfwBrULEBg5VMfl
Oj0Q75JseY6A2NXZfkrJbgk2kmwnfuGLCz8N8xVaa0Q2LSe6UgfEC7aTFCQK
F2FOkDri8H3v+P3ReQeYlZOB8iegdFn5mXQcVZ69dzhJk0u/tFbKAJK3lrBu
AuVCAUbST2PSOXChecWWoLaGi2VE5oIY6GVLOQmnoCiIZAruBr17FgYsI5cl
mrea5w/F/lcfwdHA1yxdobX+NpMzWvABT8IoR+kE4ZTUAoi1FiwimyO1YN1W
ZEmh4bLZ1peeDliYJhnPB4ilwBqAYMFyfgXdTXlASwylmN0sR3YINELklOU2
xaUkrZVfMeyX9BfGCjyBeD0NE+a3Kz1L+nUxMklZp02eQrP1oeHloTtUmHKn
CuzIgFWczdb5Q+hYp0cjtrwlB3qWr8PlpDfxl/4ElZzCSwKwCAFPEnfFf8iV
LQFlAgWtPxinCTQuwR7N0edqTMs0XPjowmQQFgsUAgUBGG/4ZCUcTHrkdrwC
IQKAXPqxjBRfMYKBrmBloiSDobPSa9+MQ/o1CeNaTMz0gpFAOewlBQg6zQxA
CokIEJgUDlizcIYuxImNVNw1JvhGnPDPRxUKYTRCY9AhhOSpKLZO9reRJYAB
sZDD59ieY1+t+iWnu+IAqFA62Wngd0kumCnFM+Y6yJ40vpx4YOsK7KJCNpo/
EOZhgKZDpbKxctcQgYkBMCYufJZFwh0TDgSBFx0iYRlB/A7xXc7vMuOGSzkS
HjQHYOENLchk8LUgNxCPVl4Kfp04ZxrOPMUFT7XyjIpjaBNFBS6gMLLxdUzd
ZkoQJwgJFCT38sSjN+0Tp0tUPNj4T3iBSk/C0IPQjxd761/vE2y34zmvnXq7
nYYvq70ebFzRd6blVb31Dv91gF3ZTXbEFcKB73Z2dKurHzxvD1UJnv94ZdPT
8ER1vLLgPNaQa1h78P/PVUr1KB7bcCDCuvqsITNKQX+uGAoDqjzhUfSuIJhR
cErI8ACpB6rpD7bTBCCeH/QT+LtDzR/b/CkHAY+ukKXQmjl7VYqE8akn3hU0
tYZqwdlR9NhwdnY+65Y9+ODA4eY2HCKtpzlG33uGRAWoJ6pPWDqfK3J/DO9P
hwcKzr+T6nPXz1pmlSfcHDs6ct+x5b6bfC3l/lkJrfKEm+9U5e6ojPvhsdLD
+hN6U5F7E5w7zYs9MHspWIDTKQRK0oGjm9bnabXXTfOdknp10A3zvaGR9Rpa
HummtiOJ61w/Yhv2YOP3vni41qAK2rz402ZLfIL2sz1A2bym/MttopsBR1ON
oY1uox+KrfenJ9k2O05j4TEeRyfXHJ+RpyMfjrGvj5m0Ro/AC4MWbwH0AmZw
fFPwgry4SdndQnyjqbTFYYLgrdPhyXYHFxdOwkPTSs7cw4Rb4OaQlMvkbhrD
EQanWpIA+mi0beWOVEZGLdtYIxPSSJ3WqvBTfIjDvGfBO/nQOz1xYJZJG44o
IMpIH2VmQcdMgyHiAGnBuYS2xHEMKzHRVUR5iLH0BNymj2srzWLNAh11qcVj
KjnD5VvZIe2lGRhZJY6CNMtMlgf06mgkzFKKluaGAmYpkKAGmtmBGw5kCgt3
gKoWLpTHiGl0bnYQoy5a6ymsxFpAqzFOwzTLzbgwGoZwSgXCThRpIcoVHzHs
SzHkUpBwlE34GAdFrRIGVgavAiLqmdLmIE2WBokLmR4R+Mwdx8kIWPPBjKUZ
uss2mBpE+5xi2BKPo+QmVnUCbVwuUwhMqz+/+BpGIa4T7MWZyWdaqwEG6TAz
V3oMVuJgONrWbZQ1sJ8O8CkuyCIZz3IMT8EMAigiX8XpKu/pGAVr8UMiVQkQ
pca0SsB0F6CiQJZW6Bc6uegwg0N2YkOPlxGgldCBFrVeqaiUc2qY4DCU0OR3
Od0DE5Q3A4HMNKa8LvB0ntB6zM9zfzJniwXcinCFt+RHOMqbomzm4X1C7JY1
8/3j6ebXbSLs+guCvyFMA4gA10cQa14UhzbF0wdsSjhc/VFjQ33tevi5Z0WR
EFPAlFsfTVdx0rue3WaHFwhuIK0ae2UvG7HnQWB2BbOlMXIGOnviM7+p4BIY
4ZnP2JudkR0vl/Gs97VX4+jnxvGrkVjRsg2F5DJRrxpbdqwFkhsoA6069P9M
IIgNwgLRHBkLE0mr8U6YDQ0d3VDYRM56qBNidK1jPfbVoTK8QCwCexBilALq
qlIoWM4Ynt1CbyeaiupL8UwJbz0IpOeHibU2ugkj/rlNSI3t1OuW83iPLZ+2
IO3RrDb+tw5lK9HoLeLYY5PdK0PYEaWPAwkeJlmq1P9DFbjRPhJ5wZOEE7OZ
wnGGAVTK3sd+iC7oi1wJAB5kYvP4w/los8N/xckpvT/b//OHw7P9Ib4//3lw
dGTebKgW5z+ffjgalu/Knnunx8f7J0PuDN8K56uNzePBp01OuG2evh8dnp4M
jjZ528POwZOnomHTnssyleS/so1AZhPw0ey3dvfe//d/PX2hdpeePX36PTgV
tdX09LsX8AEca8zYkhhcHn8E/7na8CG29FMKb6MInN8Sy2zQt2ECObmMBbrk
7oZipsVsdCsU3SVRlFySP4aH7ILLLWVFxnffv3wCZCAB+BxT+RDpq1aIoU/7
OJ6YRCGMm95SUjWlt35BwRa9L3foy48xfOSNoFtT9OrZi6e3oyiJYQ4Uqdpq
AXRMHSiSVB/hi5vwIh7KJVZFbEUJnpkPvN3QtwJkK25Xey96d9hd4ASJzNRg
SO2F/Kr36jDzh6CmRTzhDS0KGnE7gzZBw2URUQiiYy6dZ1ymCU5feBKFX9yk
cgdJjKSCxwEoMACjxIgDtg4GYL5KcyIHkW7cWDF72mhbwulKBXczGePWl47v
mJZuuU+i8+Nu4OdsvE9U9lkpvGkYqX153KKZ6mS6leMNgF+T3AzfMJi3HQzh
uA9Je2GUSq1v9lnLPC2MORqycp+5LMvIdC1Hw9qQcJs9PqpEKXdOtdD1RmFX
adDA3uJfr0B6QYwbkRmQmAaXlAFApYAVufmAW3m6rsLKPdt78+V4umYVrCP+
++xOql11qouwNsic+oWunjTvipDkgZsgvj1kM2BbY3VRRIZzWC2BmlZUHRzA
BNZBtGOivuL9Cf9raL4DKDzvWHe4QTyl7S7qnyz8GQwwnBi94kINUCu9cQgc
zXlpiQVCOAqcche4hegLquMB7k3mPixfeAOmtosExMZZQesjta2CEpnhvmqH
VjWL8DeuukE58RYyj0bGahVM+1RAkgwqssUde9yjpQmqd5YyVYWg61lNkQXv
NIIaf4nReQBzZyAeAMrjAuIvQ8rx2CKhZ11XkLRzOKb0AiKJfd72pcoS2uUC
qmZ2Bz0DdMxBIZ07A3RKy+nH8ivqK2ugXTVINLl5dV0K07/cGOQ9baRbzapa
tkYpWJKSMiG/DJv4Ea4C4wCVDxaW5AEpaYNmAoQHpgE30sGAuCNo1Alrv481
VTGU9/doXTxly6em9K8UXY+Tr9LafG0oXcLk28E22XUm+tdiAVYo0wLYL+fN
PWSwkDlvUWJ9GW5tbZWJCghVUnInUQFKXSxIlzBxictmtQeKe3V+ChppTV89
85BPFeVOlV+0x4n7l7RfLqtOJ7/EfEbgLf3QZF4MfXuDkfey94qm1fD8SD3f
brIaeit3Kn0KeMEYAC8gwkbVKAdfziYdOgxP984PzwnicbI3UCnOcZr4wZhC
mWpCYL9qxKx5pbIhWv6kGOSx7ZQQ7veqgIF1o6tDwVRKMQz9GSiFLq3ErwL+
KmsOd1SQpOoUc7d+xa1AfP7iSVmdgosFUKPwK0mDi/5PsKb9BFVS4T+sIOtQ
mSlv1eowkT0u77FaxZ7J+FfMC3N5JW66MjIM2kwogoX54CXVMxB5lkxCskuU
moU21B1kCFq5BCFiT6oqhRgrSbGh2pu1wmsKSHN/7CmMGY2ZAF2pIdNbfTCh
UEmKymrxzFQGme8YRrnou/LWvpoeKxgivgw1IvLaNY9d0nGwJ/4KL1GlQ8Rh
5MIITRFSdSwA4xO8HBi4FrXZZFaf+jOKda/OemaZWnIi5P0gxKkFK0EM8d9H
EstyU0l760y6liYRAmaGnQEaEXZBd4tiujUkNLY/ColTyGUQLcBr81yASSbV
SvlYV3HtwQIYnHJaWSdH/HkeLpm6hjqk0e6wtflIVXOWrazTNOL0Ap2ZvDRV
2LJWcG1sBY5Zr/myshCwsoi7SyRpuF2u0azSyn7j8ivrY/wNBt+uH9GFYAQQ
11YUnMH6hpwHvAUh81RXgXqt5Fq7SfKNDg5loBk0+n8VRnCtDbnkBGM7034e
RoHqVVaUMbtd68zpHDY+fTX9LkNzksmwawOAKL6LHrTo1xjap2Tyjuell4z5
sfglDP6+wTNXPQiDin1C3xrP3Ea8S/BT2aiA8OP5M7eR7wGD9VfmWxaCh6GE
1R/QYn1vvgKLUOuyZfydZ/Xe/slqyOPqbymubLuPqsjDQKN2B2cB4uVKBY7h
Xiw9INSiH+bu1CXdbm52SXSvSnNu9dv/8+sO/EpEUZR00QvtRR+/dfmKcYTT
rkmjOSdHs/Sn1kZ+FPrZTzdAoplly6tBVHZLsCw3ttTJW+pRkzfvmGP46YEz
QljudKw0tFVpnRpZiR/VPIBF78KPXr2ojANtmWcsCljVr8aoGJnS1/QZiXtd
f96iY6Juc9zRiUZ7I+pafIspZPe6aRYJR/+rE6mVijXjbJ9OojZFbppR9R43
TSrRaIdsCHfio7gDH03zRj6Ku/LRAlfno/38dnys9FjLR26ifTOTanlZUWq7
C9oag2izb655E23mrQ6qbt2a2lSNWzMcVwOqoi+ZVGR5svByf5Y9bgOmo1/N
R1hk9K2FhVcDqtmKQZrL1Fa+VjG3MreBva0cbgHa4ETaGtYcSVtDHKo74RpY
blq3OYLqnqAdP2KBhF6P2TkASrhUDkuWZ0Y2r03Maq/U1Ppi3dn+ISewrXUJ
0wbQftg7He6L3f13hyfnP2LOX4rN9nj37bMnz156T76D/7oou00dJK+JkcXv
GyxoD1Y0lL582n36ZoOPtGZLXOBtFmncRwj9pY+pkP7XBahl1if1aIe8iVBU
csFqgN/Cf5xDaFt//06CLDu/oc/mvBB92oSlJi5w265OqK33NhlKr1eum/sN
S2UwkAUsS8qFrOqFK/LqUhQeXVcHYyUC3GGEUdswcAl962GIIwV+7XjKVfmd
x7NBp5X9OPyN0DCVh/ujg7YLJrZgsbrt3g1BtNGCb5IzgI/vxEc57qNSz/N8
mfV7PVws80ZQSrcqdAFt73LWA3C9H3kqQ68jWB9Ctx/wuHSe9N3F8Fvd78cN
7qD5IMpbIqoFQz80XAxR725uhqh1b7kJog6ivAqiBqPx9ocfgWsbwraZzDra
myBOq+ms9lqovqpyxFvNMkZoDrDqpK7eXrR3gLRFy8IcvtId1a6dObQbmALA
ylmVrMvjLo+JTwvc+MN9owT3jVU9pNad43LfkPqhuoNnTKUYpBA24/lnzCFv
nRwPB9tdakL/7CXLVRrO5jmET9sCLN1zQTo5wvtGTCUiZu6TONso/QKwKaCU
Ol0moo92AXmB7IKUo0gQ1Ezg8Zr0QgZqPGeydpZHHUrPkiKd8GbiOIyxEJEG
2lElrTy/9PYqsIRKinlLGeS4xJqDHFMqyyLNCqw1xuN/tE9ZUNqW+iuu4eZG
DGh5C15lUChnxGdUz0DCmJjePR/CRKG21D2TmJtOczzdKs55R1u86E708EvW
PcrEkZyBgXiPm3ToATI1/kjtWyfceqjS0Px4S09iuu9FynICK5I9zEhtG+WA
kWsHo48P2hqNjFHnpHXO9Q0Mggej84phnsloSmqOOgZhJtINdovOf5dqWNbB
PML6l0cd/ovVLPhe18Hgeyp/MW8IgmrFFTDlu7K3KXzBj5VamEc8gR4dDz49
YqE+0vUwj+5QD8Nz0K2JEU9fiC1kA1bEbPNbrIfZbiyH0YxbiduVxLDp6fUE
O5PurTyjqPgQhkA52gqwYhlggQmlEPENXhxzWeYx6Tsl+2Ux1gcxGUiTo+py
FJFKVllRRj7K6VaNKLqwOKTz8koPN5u8MftjsS6uqIVt0wSYqy18zUV2FZ57
BB4dzTb8xwCxD9GviUmQd4/FIcfG6Coe9zbKWNlKfLQzbBez72UPs0NKZ5t5
XNc2zHevXj4bKHB0PUiJ5E2rUEYfvJF416Wu1L4F8O79Ae+uBbx3f8B7awEP
7w94uA7w83vDfb4O7It7g32xDuzLe4N9uQ7sq3uDfbUO7HeDp/cGjH3Xgn72
DaCfrQV9/8nxXfvk4F3luwE+pT66KsKBbIMuM8J3sT7qloUW66MzwmyjLLJL
ZK1kH1SPSzfALyswOLF7RxTV0oUGDKqqog6+iroVyZ5dl9HOeEyw353x2KuJ
8eaCgBpDsEcrrbu6Wxs7/NkshQjPWknfFvTA6tkKnWtL7giYO7XBhFg4/nJH
kCPq0wbRWYPcDbBz0rAN/jj1Y1ga3lFy3KlVyeys5J0nuV6O8vHSlrlOpWQT
xmATX8PcOoZzhkBoGhCE8bLIvwH8IfZvAw7rwm+DfkoA2sAvny2Wfyjpro1q
2Lq4ky0xlVplgXGjjN0tA0dFm2hoHY+K13tF7F431mgT8j8Co1O1rC5aqmRN
1k2bezK2XrfdyNbT4UGTXtxmXI1nmA+wirIBz8fh8X3xfCxPXQ5DtcA7VkWn
XxtDlYPB6L7I2PUrw66POTehGH4jCodraxANRrv3RVQZBR4UMwg2aD1Iydkw
nqnl4Ex9rCu4hJVlq/INdIFQVrn+qja5AYxKLfCuoKgrt+Bw0drFMQ9unn3M
u2Yy0bmqQLRKl16Uc2f6ZzJPwkkLLkNQI5KhGargAlZ1801+A3KBx93Lg8Pl
oG1GhYH1QLGKd8beWF8vMAe6GcgUAAUe3s3nJamH2bKtbrdnjaRjdaLXI2tr
pu/q2qPtTRtH09hp/HtmfNX71HQCNu1akK4rgiMmqLMQFR7wVnSdAWp/2Xkg
6CiE2Gwu9HK+1ZnrzSozdirdVUP1HcjCYcj1Hy8AxwHdlv+mWDYw2ad96x6p
Jt4r/job9//nbP7FsPlPkyLFu6W2tnvdbnN30oy/E5jyxL37sRVvOex/fYla
x/ztqOJRVgqvQgCFGxT+mRbt0+8a/9GRSLs3KLXgW7xBZlyB3shIuURpvX0d
UBNlU0y61gyJzlk0+S9t4isYf7sZ49++DWMTQ/HkAy/ePb/kVytP1ZENq2lZ
UesyWd81ohPEfMgtz9x6WscHWz6lwZ80coQvBqgb9GsLrArZHNBcbWEYFyNh
mwu8RnxzLb4jhqU36xg7Hq3Ka7ibpQFS05GVLQinbPBWkmjV7voVew3q7eAz
rMEdmnKsbTamTCp1xCMnu0V2ZK24DAFTPq9qhlA55UHgSvvROBolXreUxnIK
DYJus22bJ7xvpHODfHjMvmfQSiqwjGsUOAHZ2uCxJW1pw20lVEeOmsxy4/VG
Mu3jwRU6TbmoQ+WULiEF+xCEM5wgz5roVHMn2N28kckjcymQTQpQHuxWScZ/
wV45tuo+U8NYJ6M1alo22r03ZQv0xyClcOKptixIp3FpYmp541ssHiqp2duu
GGwBX9dIsDKotyWhTKndQMIZwq6TgP+WfGszZCatUMqzrEW+j5mz3Uh5vzuf
Y6VjrJpwfZrVmR7MNzzhYZFh+IMb9ZtUBm3UEhauJnAsJ0Ijn07TgG7fNgdI
7LO1jd5P+z8qvG4wYK9vnFqDWPVWG+D6sL3yjCtVW6IJqUR2CVJsnFqFQq0Z
bpCxZv5cN/i3+4u5EieQyBqEVQbMzX7bOfxjMZ6H0zgO/dDS0zdG2dlAuRaq
khLhC2zvPuTKapXAuAywk6b344O6XJfu+nXQkcQdpQyqGlld5reo5HsqPWxY
al/b3L2NnbWoqabuDVFrPW1Lktkm5kaHa+f/18YB/9uRSBMBN2vjtytiiw46
Sem7amELgm9VvbZVwbfpXlPi7S7a15AkvIf+VXN1tgZ6bB7Liv778o8g0M9S
IBS1VXB2cDjsiD+fUY2icbm2H7Fv6qPyqTW0OocKqnQ2HDC4kWgrOWEKndXP
lNzIPFKHJvNteTQy/BuUrR7w4U3GQQlrfZyzJf+0eUMmQfWuFe/zYsiqrCoH
bF9QaN1O2TClrCEqL9Y+ahWnXVtV/vsnw/Mf151LwHpnfS5B1066Vb9NpxIE
X6L4UBXe+mO+2LF+aBoajnaH6nD1uZwUaXs7fdy5Uo/ccEECH3LGQuUMNHZR
3u5BgPQvIYG0zFFx/E0N2seAjxdheSGUdeGQ+aEWKmzmWw4ycbI/2js9OXBv
xAJsZ/vn9oPXT+gmBh5FlFxKmMq6a+Sv6I4uoe/izZAP0rrrnVp0TL3xAi9R
oGr0PPHMT2mobjxE0xVAnjO487mMIrF1fv7zdkntsypRhm6Hqp9Ho/fntyTA
RT46Ond+EuvFq/JyhhH9fA2jU5UR6oy30jJziwUyVd3now6zS8ABgiM44EOx
UCXXQFg5U5g+ReSnBoUtFbwtmG9TIQhL/K0evqNMUkk0ljLjbUnAMf/CDyPy
OU2AtFYQGL5JCnVW32KUS7qeTA9X/7SCjuTdWzWss/m1WmVtkflXrWCWIEU9
upOY3gG7JP+G11bYld2OunMNq0OkviqF1YsgACq/iPJtFn4mbTIW9HNXCIAm
ITJEwltKBMPQL4oIrxcbq9+so9r0RWkFZHwRpknMVfpCfARSpc2YLXQ34HSC
MPeYxm1W2UT/TkxJia5nBybjtTXIa1VVjjew0I1gOFVn9KNDBEVOp3iHlPW7
ZyXqrqgYFrtM/TXIwlbU775/qW7PojuGaunPMEU1wVNbmfVLSygpJUXNnOpN
dfT9OXJMLclAhAEBtgbepAE1sfBPqjWL5iaxHOasDQVf18JnifhYgJmDSJie
UkpqaBpnMsefbNLSw+tt9G/KmUMH203i/Ffh/0NxODgZNDsZ5gvqW6IW2dSW
rlNHbwH8vBQfzg4z/i0yRMunlP56fEQAzuQMt9wxKKCBPH/1Gn+nDI/B0LUZ
Wb+8GxSaA6i+uN9RNxsdSm6PDz71yawe7p+/owZAV1+c9AZvlK79s5B0VTMg
pgvHYmxRnrvratoafswqJVxkN51bQJwjFSwK+6YddbsQ2WnmjXY/T549Uc7A
8IN/0/KGQRtqv4l1fEKubx8TVFSqULNvToWUTPE8j0oPN/4Hc55RhVd5AAA=

-->

</rfc>

