<?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-02" 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="2025" month="July" 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-07'>
   <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='7' month='July' year='2025'/>
      <abstract>
	 <t>   This document defines a base YANG data model for 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-07'/>
   
</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:
H4sIAEwZbGgAA+0923YbN5LvPMf/gFUeLFls0vc4dCYxJUqOdnXxWPRkPPGc
OU02SHbc7Ob0RTITab9lv2W/bOsCoIG+UBdnz87DcjIWyQaqClWFqkKhAHqe
96AzTYIwng9Ekc+8Vw86Dzp5mEdyIIbi4/D0rRj5uS9OkkBGYpak4p2fZeGF
FKcyv0zSz+IovpBxnqRr7OlPJqm8GLQ3YpAE7UEnSKaxvwRMQerPcm89n3jh
xdpbcWcv5s5eqDt7j58+6OBX8zQpVgNx9JeP4mf4CNSLt/gVjMXP5RyaDkSW
Bw864SodiDwtsvzp48ffYfcHnSz34+AffpTEgHktswedVTgQv+TJtCuyJM1T
Ocvg3XrJb6bJcgnos7/T+Ip8kaSDBx0hPPxHCB7A/sKHIYmPBX+ZpMDOnwr/
Uob8hVz6YQTYiik1fLOgZz2AXQM1DOGheFskFqjDIi9SWYXmY8t5kfRCmc/e
zPHLRohHOQxW7BVZuJm6ENv1JtBuE30nycJfLv1A7CVpksQ2yHC+yIB9MnfA
LlWH3oQ6vFmYZl4up4s4iZJ5KLNGZOcynYdAu4ySPLfJP00+h76DJqOmvQk3
fRNjg0aY42Qp/uLHYt+XsZzL5UaoebLsXfjxP6aq8Qa455f+Moz9fAGwn/TE
eW8zuWXr3pNedku4e7cHOtkA8jScw2we+RdhZsHbD2XswosDbPJmig+alcEv
0kSMwyiZTn1bYcOJTPeTlasI2LiXc+M3M2wyTVa9MK+B3UtBv97JXKY2fad7
pw68CbRaUaM38SSeJkhhzy/q0MIYZib8Zyvrwfj9kQttvS7iNzJPw14qe5/T
GpiPxTQBQ3Mc2pN8fwH8hjkxCSPpgIvCYk0d1r+u30yx1ZIaNbLxow+A/wam
4TaQf4N2a/92gIcX8DxbiHP/sx/5k4X/OS8iW1Dv/SDM1pmDQHXquZ3epNyU
8ej/eZ4n/AlMZ3+a42eAMl6EmQDTXqDZFKtUZmg+hc+mP0BvsjTeBDuS/Qab
DAoS+3P8oDyAUB6AwBov0AMMUoGQMaj6VGYih68mfqa/T4o8CmMZQC/x++//
duSNeuxj0FSSk6k7F+Tp9TXhQmJgEGGcyzgAKEhpAcABGiKKwUssJkmBraBJ
OvOnUiQzGGKQAAtj8BlxniZRJFPhAy/kTNFCwIGe94f7r56/eHZ93RPwFXNx
GQYBSvpB5xtwl9A9KKZ5iAaWemmPGsaz1Ad+w0NwCQJ8FOg/mCkiDCiSabRG
FlbaEXW5jCS6syIOwU8CbM1g6OznOGJCFSe5AHECtmgNxIORzv1JBDBSlhB+
6IFXEfl6BYAiaBXG06gIQA5xEnur5FKmMujSBwsfUBXIixDFhQyGJyvwwaAb
XUKbgXNEdk39CbArR9eLmMgFxzEQkaTol1dRmOOc7wIQEA9oaleAYsK8nRQ0
Jhj3EnvJfNrr8sh84IAMgUOpWCRZDrIgjJfwFUgL7KoZLg0QnjOhOORArqJk
DV9hxDAnNq8W6wwHDnqaLy79tZgAG6XUYPQoe5sEB+7qAhmRldDUMGEMWRWi
lpOC3EWNXIaKHEIzgXk0AXaSrhqxJiv0rjBlhjgBp4A8JLLTHDWiUReyLsI0
0wLpBlw+qyIgolm7gElthAl640dZImSGMx0RYJsSAvMUrQFzRM+CO8xKVLAk
XSUphHc82Y32INumcpWD3MGxq8n17Pkr6ASzAtQXbBr1kP8swhXZJNS+RRLB
XLFHx3Pk9KDHFkzGiAKEBwghagMhovZBcNHPiomHb7pikvhpQJ/pXVcAhXmX
4INhi7OpBOGlxH1mWZjLZUbqmMJMnMfhb6BYkzXRd3oAfyCKnS/YqsQoqTSB
uDSJsi4rntIlzXlS7qkf44ydSJwG0+QC554FE5HliyKjaa3maaAtGVlLbX5j
KQMyJQDKD4IU5Rn0lP25rbzAuRM3gf1yuQK+wRBZYqmMfFJmxDWXyTz1V4tw
KnQPmLG9ec8SE0SLyy62BKAsIdQrFNCwwglUQTNPcUaLqUxztMQauIA4JkQj
phiTrCToUpIqYSF/gI9sTkHykhqZztqCQ+e788FSetc1zuANahcgMHKojst1
eiDeFdnyHAGxq7P9lJLdCmwk2U78whcXfhrma7TWiGxWTnSlDogXbCcpSBQu
w5wgdcXRu/7Ju+PzLjArJwPlT0HpsvIz6TiqPHvvcJoml35prZQBJG8tYd0E
yoUCjKSfxqRz4ELzii1BbQ2Xq4jMBTHQy1ZyGs5AURDJDNwNevcsDFhGLks0
bzXPvxEHX3wERwPfsHSF1vrbTM5pwQc8CaMcpROEM1ILINZasIhsgdSCdVuT
JYWGq2ZbX3o6YGGaZDwfIJYCawCCBcv5BXQ35QGtMJRidrMc2SHQCJFTltsU
l5K0Vn7BsF/SXxgr8ATi9TRMmN+u9Czp18XIJGXdNnkKzdZvDC+P3KHClDtT
YMcGrOJstskfQsc6PRqx5S050LN8HS4nvam/8qeo5BReEoBlCHiSuCf+Q65t
CSgTKGj9wThNoHEJ9miBPldjWqXh0kcXJoOwWKIQKAjAeMMnK+Fg0iO34xUI
EQDkyo9lpPiKEQx0BSsTJRkMnZVe+2Yc0q9JGNdiYqYXjATKYT8pQNBpZgBS
SESAwKRwwJqFc3QhTmyk4q4JwTfihH9+VqEQRiM0Bh1CSJ6KYvv0YAdZAhgQ
Czl8ju059tWqX3K6Jw6BCqWT3QZ+l+SCmVI8Y66D7Enjy4kHtq7ALipko/kD
YR4GaDpUKhsrdw0RmBgCY+LCZ1kk3DHhQBB40SUSVhHE7xDf5fwuM264lCPh
QXMAFt7QgkwGXwtyA/Fo5aXg14lzZuHcU1zwVCvPqDiGNlFU4AIKIxtfx9Rt
pgRxgpBAQXIvTzx60z5xekTFg85/wgtUehqGHoR+vNjb/HqXYLtdz3nt1tvt
NnxZ7fWgc0XfmZZX9da7/NcBdmU32RVXCAe+293Vra6+97x9VCV4/sOVTU/D
E9XxyoLzSEOuYe3D/z9VKdWjeGTDgQjr6pOGzCgF/bliKAyo8oRH0b+CYEbB
KSHDA6QeqKY/2E4TgHi+10/g7y41f2TzpxwEPLpClkJr5uxVKRLGp554V9DU
GqoFZ1fRY8PZ3f2kW/bhgwOHm9twiLS+5hh97xkSFaC+qD5h6XyqyP0RvD8b
HSo4/06qz10/aZlVnnBz7OjIfdeW+17ypZT7JyW0yhNuvluVu6My7odHSg/r
T+hNRe5NcO40L/bB7KVgAc5mEChJB45uWp+n1V43zXdK6tVBN8z3hkbWa2R5
pJvajiWuc/2IbdiDzu8D8c1Ggypo8+JPWy3xCdrP9gBl65ryL7eJboYcTTWG
NrqNfii2352dZjvsOI2Fx3gcnVxzfEaejnw4xr4+ZtIaPQIvDFq8BdALmMHx
zcAL8uImZXcL8Y2m0haHCYK3z0anO11cXDgJD00rOXMPE26Bm0NSLpO7aQzH
GJxqSQLo4/GOlTtSGRm1bGONTEgjdVqrwk/xIQ7zvgXv9EP/7NSBWSZtOKKA
KCN9mJkFHTMNhogDpAXnCtoSxzGsxERXEeUhxtJTcJs+rq00izULdNSlFo+p
5AyXb2WHtJdmYGSVOArSLDNZHtCr47EwSylamhsKmKVAghpoZgduOJAZLNwB
qlq4UB4jptG52UGMumitp7ASawGtxjgL0yw348JoGMIpFQg7UaSFKFd8xLAv
xZBLQcJRNuFjHBS1ShhYGbwKiKjnSpuDNFkZJC5kekTgM3ccp2NgzQczlmbo
LttgahDtC4phSzyOkptY1Qm0cblMITCt/vziSxiFuE6wF2cmn2mtBhikw8xc
6TFYicPReEe3UdbAfjrEp7ggi2Q8zzE8BTMIoIh8FaervKdjFKzFD4lUJUCU
GtMqAdNdgIoCWVqhX+jkosMMDtmJDX1eRoBWQgda1HqlolLOqWGCw1BCk9/l
dA9MUN4MBDLTmPK6wNNFQusxP8/96YItFnArwhXeih/hKG+KspmH9wmxW9bM
94+nm1+3ibDrLwj+RjANIALcHEFseFEc2hRPH7Ip4XD1B40N9bXn4ee+FUVC
TAFTbnM0XcVJ7/p2m11eILiBtGrslb1sxJ4HgdkVzJbGyBno7ItP/KaCS2CE
Zz5jb3ZGdrxcxrPel36No58ax69GYkXLNhSSy1S9amzZtRZIbqAMtOrQ/xOB
IDYIC0RzZCxMJK3GO2U2NHR0Q2ETOeuhTonRtY712FeHyvACsQjsQYhRCqir
SqFgOWN4dgu9nWoqqi/FMyW8zSCQnu+n1troJoz45zYhNbZTr1vO4322fNqC
tEez2vjfOpStRKO3iGNPTHavDGHHlD4OJHiYZKVS/9+owI32kcgLniacmM0U
jvcYQKXsfeyH6II+y7UA4EEmtk4+nI+3uvxXnJ7R+/cHf/5w9P5ghO/Pfxoe
H5s3HdXi/KezD8ej8l3Zc//s5OTgdMSd4VvhfNXZOhl+3OKE29bZu/HR2enw
eIu3PewcPHkqGjbtuaxSSf4r6wQym4KPZr+1t//uv//ryXO1u/T0yZPvwKmo
raYn3z6HD+BYY8aWxODy+CP4z3XHh9jSTym8jSJwfisss0Hfhgnk5DIW6JJ7
HcVMi9noVii6S6IouSR/DA/ZBZdbyoqMb7978RjIQALwOabyIdJXrRDDgPZx
PDGNQhg3vaWkakpv/YKCLXpf7tCXH2P4yBtBt6bo5dPnT25HURLDHChStdUC
6Jg6UCSpPsIXN+FFPJRLrIrYihI8Mx94u2FgBchW3K72XvTusLvACRKZqcGQ
2gv5Re/VYeYPQc2KeMobWhQ04nYGbYKGqyKiEETHXDrPuEoTnL7wJAo/u0nl
LpIYSQWPA1BgAEaJEQdsXQzAfJXmRA4i3bixYva00baEs7UK7uYyxq0vHd8x
Lb1yn0Tnx93Az9l4n6rss1J40zBS+/K4RTPTyXQrxxsAv6a5Gb5hMG87GMJx
H5L2wiiVWt/ss5Z5WhgLNGTlPnNZlpHpWo6GtSHhNnt8VIlS7pxqoeuNwp7S
oKG9xb9ZgfSCGDciMyAxDS4pA4BKASty8wG38nRdhZV7tvfmy/H0zCpYR/z3
2Z1Uu+pUF2FtkDn1Cz09ad4WIckDN0F8e8hmwLbG6qKIDOewWgI1rai6OIAp
rINox0R9xfsT/pfQfAdQeN6x7nCDeEbbXdQ/WfpzGGA4NXrFhRqgVnrjEDia
89ISC4RwFDjlLnAL0RdUxwPcmy58WL7wBkxtFwmIjbOC1kdqWwUlMsd91S6t
apbhb1x1g3LiLWQejYzVKpj2qYAkGVRkizv2uEdLE1TvLGWqCkHXs5oiC95p
BDX+HKPzAObOQTwAlMcFxF+GlOOxRULPeq4gaedwQukFRBL7vO1LlSW0ywVU
ze0OegbomINCOncG6JSW04/lV9RX1kC7apBocvPquhSmf7kxyHvaSLeaVbVs
jVKwJCVlQn4ZNvEjXAXGASofLCzJA1LSBs0ECA9MA26kgwFxR9CoE9Z+H2uq
Yijv79G6eMaWT03pXym6niRfpLX52lC6hMm3wx2y60z0r8USrFCmBXBQzpt7
yGApc96ixPoy3NraLhMVEKqk5E6iApS6WJIuYeISl81qDxT36vwUNNKavnrm
IZ8qyp0qv2iPE/cvab9cVp1Ofon5jMBb+aHJvBj69odj70X/JU2r0fmxer7T
ZDX0Vu5M+hTwgjEAXkCEjapRDr6cTTp0GJ3tnx+dE8STZH+oUpyTNPGDCYUy
1YTAQdWIWfNKZUO0/EkxyGPbKSHc71UBA+tGT4eCqZRiFPpzUApdWolfBfxV
1hzuqCBJ1Snmbv2KW4H47PnjsjoFFwugRuEXkgYX/Z9iTfspqqTCf1RB1qUy
U96q1WEie1zeY7WKPZPJr5gX5vJK3HRlZBi0mVAEC/PBS6pnIPIsmYZklyg1
C22oO8gQtHIFQsSeVFUKMVaSYkO1N2uF1xSQ5v7EUxgzGjMBulJDprf6YEKh
khSV1eJ7UxlkvmMY5aLvytv4anqsYIj4MtSIyGvXPHZJx+G++Cu8RJUOEYeR
CyM0RUjVsQCMj/ByYOBa1GaTWX3qzyjW/TrrmWVqyYmQD4IQpxasBDHEfxdJ
LMtNJe2tM+lamkQImBl2BmhE2AXdLYrp1ZDQ2P4oJE4hl0G0BK/NcwEmmVQr
5RNdxbUPC2BwymllnRzx50W4Yuoa6pDGe6PW5mNVzVm2sk7TiLMLdGby0lRh
y1rBtbEVOGa95svKQsDKIu4ukaThdrlGs0orB43Lr2yA8TcYfLt+RBeCEUBc
W1FwBusbch7wFoTMU10F6rWSa+0myTc6OJSBZtDo/1UYwbU25JITjO1M+0UY
BapXWVHG7HatM6dz2PgM1PS7DM1JJsOuDgBRfBd9aDGoMXRAyeRdz0svGfMj
8UsY/L3DM1c9CIOKfULfGs/dRrxL8GPZqIDw49lTt5HvAYP1V+ZbFoKHoYTV
H9BifW++BotQ67Jt/J1n9d750WrI4xpsK67suI+qyMNAo3YHZwHi5UoFjuFe
LD0g1KIf5u7MJd1ubnZJdK9Kc2712//z6w78SkRRlHTRC+3FAL91+YpxhNOu
SaM5J0ez9MfWRn4U+tmPN0CimWXLq0FUdkuwLDe21Mlb6lGTN++YY/jpgTNC
WO50rDS0VWmTGlmJH9U8gEXv0o9ePq+MA22ZZywKWNUvxqgYmdLX9BmJe1V/
3qJjom5z3NGJRnsj6lp8iylk97ppFglH/6sTqZWKDeNsn06iNkVumlH1HjdN
KtFoh2wId+KjuAMfTfNGPoq78tECV+ej/fx2fKz02MhHbqJ9M5NqeVlRarsL
2hqDaLNvrnkTbeatDqpu3ZraVI1bMxxXA6qiL5lUZHmy9HJ/nj1qA6ajX81H
WGQMrIWFVwOq2YpBmsvUVr5WMbcyt4G9rRxuAdrgRNoa1hxJW0McqjvhGlhu
Wrc5guqeoB0/YoGEXo/ZOQBKuFQOS5ZnRrauTcxqr9TU+mLT2f4RJ7CtdQnT
BtC+3z8bHYi9g7dHp+c/YM5fiq32ePfN08dPX3iPv4X/eii7LR0kb4iRxe8d
FrQHKxpKXz7pPXnd4SOt2QoXeFtFGg8QwmDlYypk8GUJapkNSD3aIW8hFJVc
sBrgt/Af5xDa1t+/kyDLzq/pszkvRJ+2YKmJC9y2qxNq670thtLvl+vmQcNS
GQxkAcuSciGreuGKvLoUhUfX1cFYiQB3GGHUNgxcQt96GOJYgd84nnJVfufx
dOi0sh+HvxEapvLoYHzYdsHENixWd9y7IYg2WvBNcwbw81vxs5wMUKkXeb7K
Bv0+LpZ5IyilWxV6gLZ/Oe8DuP4PPJWh1zGsD6Hb93hcOk8G7mL4je73Q4c7
aD6I8paIasHQ9w0XQ9S7m5shat1bboKogyivgqjBaLz94QfgWkfYNpNZR3sT
xGk1ndVeC9VXVY54q1nGCM0BVp3U1duL9g6QtmhZmMNXuqPatTOHdgNTAFg5
q5L1eNzlMfFZgRt/uG+U4L6xqofUunNS7htSP1R38IypFMMUwmY8/4w55O3T
k9Fwp0dN6J/9ZLVOw/kih/BpR4CleyZIJ8d434ipRMTMfRJnndIvAJsCSqnT
ZSL6aBeQF8geSDmKBEHNBB6vSS9koMbzXtbO8qhD6VlSpFPeTJyEMRYi0kC7
qqSV55feXgWWUEkxbymDHFdYc5BjSmVVpFmBtcZ4/I/2KQtK21J/xTXc3IgB
LW/BqwwK5Yz4jOp7kDAmpvfORzBRqC11zyTmptMcT7eKc97RFs97Uz38knUP
M3Es52Ag3uEmHXqATI0/UvvWCbceqTQ0P97Wk5jue5GynMCKZA8zUjtGOWDk
2sHo44O2RiNj1DlpnXN9DYPgwei8YphnMpqRmqOOQZiJdIPdovPfpRqWdTAP
sf7lYZf/YjULvtd1MPieyl/MG4KgWnEFTPmu7G0KX/BjpRbmIU+ghyfDjw9Z
qA91PczDO9TD8Bx0a2LEk+diG9mAFTE7/BbrYXYay2E049bidiUxbHr6fcHO
pHcrzygqPoQhUI62AqxYBVhgQilEfIMXx1yWeUz6Tsl+VUz0QUwG0uSoehxF
pJJVVpSRj3K6VSOKLiwO6by80sOtJm/M/lhsiitqYdssAeZqC19zkT2F5x6B
R1ezDf8xQOxD9BtiEuTdI3HEsTG6ikf9ThkrW4mPdobtYfa97GF2SOlsM4/r
2ob59uWLp0MFjq4HKZG8bhXK+IM3Fm971JXatwDeuz/gvY2A9+8PeH8j4NH9
AY82AX52b7jPNoF9fm+wzzeBfXFvsC82gX15b7AvN4H9dvjk3oCx70bQT78C
9NONoO8/Ob5tnxy8q3w3wGfUR1dFOJBt0GVG+C7WR92y0GJ9dEaYbZRFdoms
lezD6nHpBvhlBQYndu+Iolq60IBBVVXUwVdRtyLZt+sy2hmPCfa7Mx57NTHe
XBBQYwj2aKV1T3drY4c/n6cQ4Vkr6duCHlo9W6FzbckdAXOnNpgQC8ef7why
TH3aIDprkLsBdk4atsGfpH4MS8M7So47tSqZnZW88yTXy1E+Xtoy16mUbMoY
bOJrmFvHcM4QCE0DgjBeFflXgD/C/m3AYV34ddDPCEAb+NXT5eoPJd21UQ1b
F3eyJaZSqywwbpSxu2XgqGgTDa3jUfF6v4jd68YabUL+R2B0qpbVRUuVrMmm
aXNPxtbrthvZejY6bNKL24yr8QzzIVZRNuD5eXRyXzw/l6cuR6Fa4J2ootMv
jaHK4XB8X2Ts+pVh18ecm1CMvhKFw7UNiIbjvfsiqowCD4oZBB1aD1JyNozn
ajk4Vx/rCi5hZdmqfENdIJRVrr+qTW4Ao1ILvCso6sotOFy0dnHMg5tnH/Ou
mUx0rioQrdKlF+Xcmf6ZLpJw2oLLENSIZGSGKriAVd18k9+AXOBx9/LgcDlo
m1FhYD1QrOKdsdfW10vMgW4FMgVAgYd383lJ6mG2bLvX61sj6Vqd6PXQ2poZ
uLr2cGfLxtE0dhr/vhlf9T41nYBNexak64rgiAnqLESFB7wVXWeA2l92Hgg6
CiG2mgu9nG915nqryozdSnfVUH0HsnAYcv3HC8BxQLflvymWDUz26cC6R6qJ
94q/zsb9/zmbfzFs/tO0SPFuqe2dfq/X3J004+8Epjxx735sxVsO+19fotYx
fzuqeJiVwqsQQOEGhX+mRfv0u8Z/dCTS7g1KLfgab5AZV6A3MlIuUdpsX4fU
RNkUk641Q6JzFk3+S5v4Csbfbsb4t6/D2MRQPPnAi3fPL/nVylN1ZMNqWlbU
ukzWd43oBDEfcsszt57W8cGWT2nwJ40c4YsB6gb92gKrQjYHNFdbGMbFSNjW
Eq8R39qI75hh6c06xo5Hq/Ia7mZpgNR0ZGULwikbvJUkWrW7fsVeg3o7+Axr
cIemHGubjSmTSl3x0MlukR3ZKC5DwIzPq5ohVE55ELjSfjSORonXLaWxnEKD
oNts29Yp7xvp3CAfHrPvGbSSCizjGgVOQLYxeGxJW9pwWwnVkaMms9x4vZFM
+3hwhU5TLupQOaNLSME+BOEcJ8jTJjrV3An2tm5k8thcCmSTApQHe1WS8V+w
V46tus/UMNbJaI2alo1273XZAv0xSCmceqotC9JpXJqYWt74FouHSmr2tisG
W8DXNRKsDOptSShTajeQ8B5h10nAf0u+tRkyk1Yo5VnWIt/HzNlupLzfnc+x
0jFWTbg+zepMD+YbnvCwyDD8wY36LSqDNmoJC1cTOJYToZFPZ2lAt2+bAyT2
2dpG76f9HxVeNxiwVzdOrWGseqsNcH3YXnnGtaot0YRUIrsEKTZOrUKh1gw3
yNgwf64b/Nv9xVyJE0hkDcIqA+Zmv+0c/rEYz8NpHId+aOnpa6PsbKBcC1VJ
ifAFtncfcmW1SmBcBthJ0/vxQV2uS3f9OuhI4o5SBlWNrC7zW1TyHZUeNiy1
r23u3sbOWtRUU/eGqI2etiXJbBNzo8O18/8b44D/7UikiYCbtfHrFbFFB52k
9F21sAXB16pe26rg63SvKfF2F+1rSBLeQ/+quTpbAz02j2VF/335RxDoZykQ
itoqeH94NOqKP7+nGkXjcm0/Yt/UR+VTG2h1DhVU6Ww4YHAj0VZywhQ6q58p
uZF5pA5N5tvyaGT4O5StHvLhTcZBCWt9nLMl/7R1QyZB9a4V7/NiyKqsKgds
X1Bo3U7ZMKWsISov1j5qFaddW1X+B6ej8x82nUvAemd9LkHXTrpVv02nEgRf
oviNKrz1J3yxY/3QNDQc743U4epzOS3S9nb6uHOlHrnhggQ+5IyFyhlo7LK8
3YMA6V9CAmmZo+L4mxq0jwEfL8LyQijrwiHzQy1U2My3HGTi9GC8f3Z66N6I
BdjeH5zbD149ppsYeBRRcilhKuuukb+mO7qEvos3Qz5I6653atE19cZLvESB
qtHzxDM/paG68RBNVwB5zuDOFzKKxPb5+U87JbVPq0QZuh2qfhqP353fkgAX
+fj43PlJrOcvy8sZxvTzNYxOVUaoM95Ky8wtFshUdZ+POswuAQcIjuCAD8VC
lVwDYeVMYfoUkZ8aFLZU8LZgvk2FIKzwt3r4jjJJJdFYyoy3JQHH/As/jMjn
NAHSWkFg+CYp1Fl9i1Eu6XoyPVz90wo6kndv1bDO5tdqlbVF5l+1glmCFPXp
TmJ6B+yS/Bte22FP9rrqzjWsDpH6qhRWL4IAqPwiyndY+Jm0yVjSz10hAJqE
yBAJbykRDEO/KCK8XmyifrOOatOXpRWQ8UWYJjFX6QvxM5AqbcZso7sBpxOE
ucc07rDKJvp3YkpKdD07MBmvrUFeq6pyvIGFbgTDqTqnHx0iKHI2wzukrN89
K1H3RMWw2GXqr0AWtqJ++90LdXsW3TFUS3+GKaoJntrKrF9aQkkpKWrmVG+q
o+/PkWNqSQYiDAiwNfAmDaiJhX9SrVk0N4nlKGdtKPi6Fj5LxMcCzBxEwvSU
UlJD0ziXOf5kk5YeXm+jf1POHDrYaRLnvwr/vxFHw9Nhs5NhvqC+JWqRTW3p
OnX0FsDPS/Hh/VHGv0WGaPmU0l9PjgnAeznHLXcMCmggz16+wt8pw2MwdG1G
NijvBoXmAGog7nfUzUaHktvng08DMqtHB+dvqQHQNRCn/eFrpWv/LCRd1QyI
6cKxGFuU5+56mraGH7NKCRfZTecWEOdIBYvCvmlH3S5Edpp5o93P46ePlTMw
/ODftLxh0Ibar2Idn5Ab2McEFZUq1ByYUyElUzzPo9LDzv8A7adrKld5AAA=

-->

</rfc>

