nautobot 2.0.4__py3-none-any.whl → 2.1.0b1__py3-none-any.whl

nautobot/docs/user-guide/core-data-model/dcim/frontporttemplate.md

@@ -1,6 +0,0 @@
-# Front Port Templates
-
-A template for a front-facing pass-through port that will be created on all instantiations of the parent device type. Front ports may have a physical type assigned, and must be associated with a corresponding rear port and position. This association will be automatically replicated when the device type is instantiated.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/interface.md

@@ -1,34 +0,0 @@
-# Interfaces
-
-Interfaces in Nautobot represent network interfaces used to exchange data with connected devices. On modern networks, these are most commonly Ethernet, but other types are supported as well. Each interface must be assigned a type, an operational [`status`](../../platform-functionality/status.md) and may optionally be assigned a MAC address, MTU, and IEEE 802.1Q mode (tagged or access). Each interface can also be enabled or disabled, and optionally designated as management-only (for out-of-band management).
-
-The following operational statuses are available by default:
-
-* Planned
-* Maintenance
-* Active
-* Decommissioning
-* Failed
-
-+++ 1.4.0
-    - Added `bridge` field.
-    - Added `parent_interface` field.
-    - Added `status` field.
-
-Interfaces may be physical or virtual in nature, but only physical interfaces may be connected via cables. Cables can connect interfaces to pass-through ports, circuit terminations, or other interfaces.
-
-Physical interfaces may be arranged into a link aggregation group (LAG) and associated with a parent LAG (virtual) interface. LAG interfaces can be recursively nested to model bonding of trunk groups. Like all virtual interfaces, LAG interfaces cannot be connected physically.
-
-+/- 2.0.0
-    The relationship to IP addresses has been changed to a many-to-many relationship. This allows an IP address to be assigned to multiple interfaces, and an interface to have multiple IP addresses assigned to it.
-
-IP addresses can be assigned to interfaces. VLANs can also be assigned to each interface as either tagged or untagged. (An interface may have only one untagged VLAN.)
-
-!!! note
-    Although devices and virtual machines both can have interfaces, a separate model is used for each. Thus, device interfaces have some properties that are not present on virtual machine interfaces and vice versa.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).
-
-+++ 1.6.0
-    Interfaces can now be assigned to an [Interface Redundancy Group](./interfaceredundancygroup.md) to represent redundancy protocols such as HSRP or VRRP.

nautobot/docs/user-guide/core-data-model/dcim/interfaceredundancygroup.md

@@ -1,24 +0,0 @@
-# Interface Redundancy Groups
-
-+++ 1.6.0
-
-Interface Redundancy Groups represent groups of interfaces that share a single virtual address. This model is intended to represent redundancy protocols such as HSRP or VRRP that allow multiple devices to provide a fault-tolerant default gateway for a network.
-
-Interface Redundancy Groups must be created before interfaces can be assigned to the group.
-
-!!! note
-    While Interface Redundancy Groups were designed to represent first hop redundancy protocols, they may be used to represent any grouping of redundant interfaces.
-
-## Required Fields
-
-When adding Interfaces to the Interface Redundancy Group, a priority integer value must be set for each interface in the group. This value will depend on the redundancy protocol being used. For example, HSRP uses a priority value between 1 and 255.
-
-## Optional Fields
-
-An IP Address can be related to an Interface Redundancy Group, which will be used as the virtual address for the group.
-
-Redundancy protocol can be set on the group. Supported redundancy protocols are: HSRP, VRRP, GLBP and CARP.
-
-Secrets groups can be used to store secret information used by the redundancy protocol. An example use case would be an HSRP authentication key.
-
-Protocol group ID stores the group identifier (HSRP group ID or VRRP group ID, etc.) as an integer or text label up to 50 characters long.

nautobot/docs/user-guide/core-data-model/dcim/interfacetemplate.md

@@ -1,6 +0,0 @@
-# Interface Templates
-
-A template for a network interface that will be created on all instantiations of the parent device type. Each interface may be assigned a physical or virtual type, and may be designated as "management-only."
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/inventoryitem.md

@@ -1,10 +0,0 @@
-# Inventory Items
-
-Inventory items represent hardware components installed within a device, such as a power supply or CPU or line card. Inventory items are distinct from other device components in that they cannot be templatized on a device type, and cannot be connected by cables. They are intended to be used primarily for inventory purposes.
-
-Each inventory item can be assigned a manufacturer, part ID, serial number, and asset tag (all optional). A boolean toggle is also provided to indicate whether each item was entered manually or discovered automatically (by some process outside of Nautobot).
-
-Inventory items are hierarchical in nature, such that any individual item may be designated as the parent for other items. For example, an inventory item might be created to represent a line card which houses several SFP optics, each of which exists as a child item within the device.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/location.md

@@ -1,15 +0,0 @@
-# Locations
-
-+++ 1.4.0
-
-To locate network information more precisely than a Site defines, you can define a hierarchy of Locations within each Site. Data objects such as devices, prefixes, VLAN groups, etc. can thus be mapped or assigned to a specific building, wing, floor, room, etc. as appropriate to your needs.
-
-Once you have defined the hierarchy of Location Types that you wish to use, you can then define Locations. Any "top-level" Locations (those whose Location Type has no parent) belong directly to a Site, while "child" Locations belong to their immediate parent Location, rather than to the Site as a whole.
-
-!!! info
-    At present, Locations fill the conceptual space between the more abstract Region and Site models and the more concrete Rack Group model. In a future Nautobot release, some or all of these other models may be collapsed into Locations. That is to say, in the future you might not deal with Regions and Sites as distinct models, but instead your Location Type hierarchy might include these higher-level categories, becoming something like Country ← City ← Site ← Building ← Floor ← Room.
-
-Much like Sites, each Location must be assigned a name and operational [`status`](../../platform-functionality/status.md). The same default operational statuses are defined for Locations as for Sites, but as always, you can customize these to suit your needs. Locations can also be assigned to a tenant.
-
-+++ 2.0.0
-    Location now supports all properties previously present on the Site model, including the `asn`, `comments`, `contact_email` `contact_name`, `contact_phone`, `facility`, `latitude`, `longitude`, `physical_address`, `shipping_address` and `time_zone` fields.

nautobot/docs/user-guide/core-data-model/dcim/locationtype.md

@@ -1,43 +0,0 @@
-# Location Types
-
-+++ 1.4.0
-
-Before defining individual Locations, you must first define the hierarchy of Location Types that you wish to use for the organization of your network. An example hierarchy might be `Building ← Floor ← Room`, but you might have more or fewer distinct types depending on your specific organizational requirements.
-
-Each Location Type can define a set of "content types" that are permitted to associate to Locations of this type. For example, you might permit assigning Prefixes and VLAN Groups to an entire Building or Floor, but only allow Devices and Racks to be assigned to Rooms, never to a more abstract location. Doing so can help ensure consistency of your data.
-
-+++ 1.5.0
-    Location Types can now be marked as `nestable`. When this flag is set, Locations of this type may nest within one another, allowing for variable-depth hierarchies of Locations and reducing the number of distinct Location Types you may need to define. For example, with two Location Types, "Building Group" and "Building", by flagging "Building Group" as nestable, you could model the following hierarchy of Locations:
-
-    * Main Campus (Building Group)
-        * West Campus (Building Group)
-            * Building A (Building)
-            * Building B (Building)
-        * East Campus (Building Group)
-            * Building C (Building)
-            * Building D (Building)
-        * South Campus (Building Group)
-            * Western South Campus (Building Group)
-                * Building G (Building)
-            * Eastern South Campus (Building Group)
-                * Building H (Building)
-    * Satellite Campus (Building Group)
-        * Building Z (Building)
-
-!!! tip
-    Although it is possible to define a "tree" of Location Types with multiple "branches", in the majority of cases doing so adds more unnecessary complexity than it's worth. Consider the following hypothetical Location Type tree:
-
-    ```
-    Branch Office
-      ↳ Branch Floor
-          ↳ Branch Floor Room
-      ↳ Branch Basement
-          ↳ Branch Basement Room
-    Headquarters
-      ↳ Headquarters Floor
-          ↳ Headquarters Floor Room
-      ↳ Headquarters Basement
-          ↳ Headquarters Basement Room
-    ```
-
-    This would complicate your life significantly when constructing queries, filters, and so forth to actually work with your data - for example, if you wanted a list of all Prefixes that are mapped to floors rather than individual rooms, you would now need to construct a query for Prefixes that are mapped to (a `Branch Floor` OR a `Headquarters Floor` OR a `Branch Basement` OR a `Headquarters Basement`). In most cases you would be better served with a far simpler "linear" sequence of Location Types, such as `Building ← Floor ← Room`; you could then use tags or custom fields to distinguish whether a given Building is a Branch Office or a Headquarters, if that distinction is even important to your network model.

nautobot/docs/user-guide/core-data-model/dcim/manufacturer.md

@@ -1,3 +0,0 @@
-# Manufacturers
-
-A manufacturer represents the "make" of a device; e.g. Cisco or Dell. Each device type must be assigned to a manufacturer. (Inventory items and platforms may also be associated with manufacturers.) Each manufacturer must have a unique name and may have a description assigned to it.

nautobot/docs/user-guide/core-data-model/dcim/platform.md

@@ -1,19 +0,0 @@
-# Platforms
-
-A platform defines the type of software running on a device or virtual machine. This can be helpful to model when it is necessary to distinguish between different versions or feature sets. Note that two devices of the same type may be assigned different platforms: For example, one Juniper MX240 might run Junos 14 while another runs Junos 15.
-
-Platforms may optionally be limited by manufacturer: If a platform is assigned to a particular manufacturer, it can only be assigned to devices with a type belonging to that manufacturer.
-
-The platform model can be used to indicate which "network driver" Nautobot (and Jobs, Apps, etc.) should use when connecting to a remote device running this platform. This is a generic string corresponding loosely to a [Netmiko](https://github.com/ktbyers/netmiko) driver name. As there are many different libraries and applications for connecting to a device, rather than having a separate model field for each such connection type, Nautobot uses [netutils](https://netutils.readthedocs.io/en/latest/) to translate the generic network driver string into a variety of library-specific driver strings (Ansible "collection name", PyATS "OS" value, Scrapli "platform", etc.) which can be accessed via the UI, REST API, and GraphQL as needed. An administrator can extend or override the default translations provided by netutils by configuring the [`NETWORK_DRIVERS`](../../administration/configuration/optional-settings.md#network_drivers) dictionary appropriately. (If your extensions are generally applicable, please consider making a pull request against [netutils](https://github.com/networktocode/netutils) to update the package!)
-
-+++ 1.6.0
-    The `network_driver` database field and the `network_driver_mappings` derived property were added to the Platform data model. Support for the `NETWORK_DRIVERS` setting was added.
-
-+++ 2.0.0
-    Support for `netutils_parser` key was added to `network_driver_mappings`.
-
-For historical reasons, the [NAPALM](https://github.com/napalm-automation/napalm/) driver (`napalm_driver` field) and any associated arguments (`napalm_args` field) Nautobot should use when connecting to a remote device via NAPALM can (and must) be configured directly rather than being derived from the network driver. The name of the NAPALM driver along with optional parameters are stored with the platform.
-
-Apps and Jobs should transition to using the `network_driver_mappings["napalm"]` property when connecting to a device via NAPALM. Nautobot may deprecate the use of the `napalm_driver` and `napalm_args` fields in a future release.
-
-The assignment of platforms to devices is an optional feature, and may be disregarded if not desired.

nautobot/docs/user-guide/core-data-model/dcim/powerfeed.md

@@ -1,25 +0,0 @@
-# Power Feed
-
-A power feed represents the distribution of power from a power panel to a particular device, typically a power distribution unit (PDU). The power port (inlet) on a device can be connected via a cable to a power feed. A power feed may optionally be assigned to a rack to allow more easily tracking the distribution of power among racks.
-
-Each power feed is assigned an operational type (primary or redundant) and a [`status`](../../platform-functionality/status.md). The following statuses are available by default:
-
-* Offline
-* Active
-* Planned
-* Failed
-
-Each power feed also defines the electrical characteristics of the circuit which it represents. These include the following:
-
-* Supply type (AC or DC)
-* Phase (single or three-phase)
-* Voltage
-* Amperage
-* Maximum utilization (percentage)
-
-!!! info
-    The power utilization of a rack is calculated when one or more power feeds are assigned to the rack and connected to devices that draw power.
-
-## Example Power Topology
-
-![Power distribution model](../../../media/power_distribution.png)

nautobot/docs/user-guide/core-data-model/dcim/poweroutlet.md

@@ -1,14 +0,0 @@
-# Power Outlets
-
-Power outlets represent the outlets on a power distribution unit (PDU) or other device that supply power to dependent devices. Each power port may be assigned a physical type, and may be associated with a specific feed leg (where three-phase power is used) and/or a specific upstream power port. This association can be used to model the distribution of power within a device.
-
-For example, imagine a PDU with one power port which draws from a three-phase feed and 48 power outlets arranged into three banks of 16 outlets each. Outlets 1-16 would be associated with leg A on the port, and outlets 17-32 and 33-48 would be associated with legs B and C, respectively.
-
-Cables can connect power outlets only to downstream power ports. (Pass-through ports cannot be used to model power distribution.)
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).
-
-## Example Power Topology
-
-![Power distribution model](../../../media/power_distribution.png)

nautobot/docs/user-guide/core-data-model/dcim/poweroutlettemplate.md

@@ -1,6 +0,0 @@
-# Power Outlet Templates
-
-A template for a power outlet that will be created on all instantiations of the parent device type. Each power outlet can be assigned a physical type, and its power source may be mapped to a specific feed leg and power port template. This association will be automatically replicated when the device type is instantiated.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/powerpanel.md

@@ -1,12 +0,0 @@
-# Power Panel
-
-A power panel represents the origin point in Nautobot for electrical power being disseminated by one or more power feeds. In a data center environment, one power panel often serves a group of racks, with an individual power feed extending to each rack, though this is not always the case. It is common to have two sets of panels and feeds arranged in parallel to provide redundant power to each rack.
-
-Each power panel must be assigned to a location, and may optionally be assigned to a rack group.
-
-!!! note
-    Nautobot does not model the mechanism by which power is delivered to a power panel. Power panels define the root level of the power distribution hierarchy in Nautobot.
-
-## Example Power Topology
-
-![Power distribution model](../../../media/power_distribution.png)

nautobot/docs/user-guide/core-data-model/dcim/powerport.md

@@ -1,15 +0,0 @@
-# Power Ports
-
-A power port represents the inlet of a device where it draws its power, i.e. the connection port(s) on a device's power supply. Each power port may be assigned a physical type, as well as allocated and maximum draw values (in watts). These values can be used to calculate the overall utilization of an upstream power feed.
-
-!!! info
-    When creating a power port on a device which supplies power to downstream devices, the allocated and maximum draw numbers should be left blank. Utilization will be calculated by taking the sum of all power ports of devices connected downstream.
-
-Cables can connect power ports only to power outlets or power feeds. (Pass-through ports cannot be used to model power distribution.)
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).
-
-## Example Power Topology
-
-![Power distribution model](../../../media/power_distribution.png)

nautobot/docs/user-guide/core-data-model/dcim/powerporttemplate.md

@@ -1,6 +0,0 @@
-# Power Port Templates
-
-A template for a power port that will be created on all instantiations of the parent device type. Each power port can be assigned a physical type, as well as a maximum and allocated draw in watts.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/rack.md

@@ -1,41 +0,0 @@
-# Racks
-
-The rack model represents a physical two- or four-post equipment rack in which devices can be installed. Each rack must be assigned to a location, and may optionally be assigned to a rack group and/or tenant. Racks can also be organized by user-defined functional roles.
-
-Rack height is measured in *rack units* (U); racks are commonly between 42U and 48U tall, but Nautobot allows you to define racks of arbitrary height. A toggle is provided to indicate whether rack units are in ascending (from the ground up) or descending order.
-
-Each rack is assigned a name and (optionally) a separate facility ID. This is helpful when leasing space in a data center your organization does not own: The facility will often assign a seemingly arbitrary ID to a rack (for example, "M204.313") whereas internally you refer to is simply as "R113." A unique serial number and asset tag may also be associated with each rack.
-
-A rack must be designated as one of the following types:
-
-* 2-post frame
-* 4-post frame
-* 4-post cabinet
-* Wall-mounted frame
-* Wall-mounted cabinet
-
-Similarly, each rack must be assigned an operational [`status`](../../platform-functionality/status.md). The following statuses are available by default:
-
-* Reserved
-* Available
-* Planned
-* Active
-* Deprecated
-
-Each rack has two faces (front and rear) on which devices can be mounted. Rail-to-rail width may be 10, 19, 21, or 23 inches. The outer width and depth of a rack or cabinet can also be annotated in millimeters or inches.
-
-## Rack Power Utilization
-
-The power utilization of a rack is calculated when one or more power feeds are assigned to the rack and connected to devices that draw power.
-
-Here are the typical instances required for the power utilization of a rack to be calculated and shown in the web UI:
-
-* **Power Panel** in the same location as the rack
-* **Power Feed** assigned to the power panel and to the rack
-* 1 **Device** (i.e. PDU)
-    * power port connected to the power feed
-    * power outlet(s) connected to the power port of itself
-* 1 or more **Devices**
-    * power port connected to a power outlet of the PDU
-
-The total power utilization for a rack is calculated as the sum of all allocated draw (from power ports of devices either directly connected to a power feed or connected to a power outlet of a device that is connected to a power feed) divided by the Total Power (Amps × Volts × Max Utilization %) for all power feeds.

nautobot/docs/user-guide/core-data-model/dcim/rackgroup.md

@@ -1,7 +0,0 @@
-# Rack Groups
-
-Racks can be organized into groups, which can be nested into themselves similar to locations. As with locations, how you choose to designate rack groups will depend on the nature of your organization.
-
-Each rack group must be assigned to a parent location. Rack groups may optionally be nested within one another to model a multi-level hierarchy.
-
-The name and facility ID of each rack within a group must be unique. (Racks not assigned to the same rack group may have identical names and/or facility IDs.)

nautobot/docs/user-guide/core-data-model/dcim/rackreservation.md

@@ -1,3 +0,0 @@
-# Rack Reservations
-
-Users can reserve specific units within a rack for future use. An arbitrary set of units within a rack can be associated with a single reservation, but reservations cannot span multiple racks. A description is required for each reservation, reservations may optionally be associated with a specific tenant.

nautobot/docs/user-guide/core-data-model/dcim/rearport.md

@@ -1,9 +0,0 @@
-# Rear Ports
-
-Like front ports, rear ports are pass-through ports which represent the continuation of a path from one cable to the next. Each rear port is defined with its physical type and a number of positions: Rear ports with more than one position can be mapped to multiple front ports. This can be useful for modeling instances where multiple paths share a common cable (for example, six discrete two-strand fiber connections sharing a 12-strand MPO cable).
-
-!!! note
-    Front and rear ports need not necessarily reside on the actual front or rear device face. This terminology is used primarily to distinguish between the two components in a pass-through port pairing.
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/rearporttemplate.md

@@ -1,6 +0,0 @@
-# Rear Port Templates
-
-A template for a rear-facing pass-through port that will be created on all instantiations of the parent device type. Each rear port may have a physical type and one or more front port templates assigned to it. The number of positions associated with a rear port determines how many front ports can be assigned to it (the maximum is 1024).
-
-+++ 1.4.5
-    The fields `created` and `last_updated` were added to all device component template models. If you upgraded from Nautobot 1.4.4 or earlier, the values for these fields will default to `None` (null).

nautobot/docs/user-guide/core-data-model/dcim/virtualchassis.md

@@ -1,8 +0,0 @@
-# Virtual Chassis
-
-A virtual chassis represents a set of devices which share a common control plane. A common example of this is a stack of switches which are connected and configured to operate as a single device. A virtual chassis must be assigned a name and may be assigned a domain.
-
-Each device in the virtual chassis is referred to as a VC member, and assigned a position and (optionally) a priority. VC member devices commonly reside within the same rack, though this is not a requirement. One of the devices may be designated as the VC master: This device will typically be assigned a name, services, and other attributes related to managing the VC.
-
-!!! note
-    It's important to recognize the distinction between a virtual chassis and a chassis-based device. A virtual chassis is **not** suitable for modeling a chassis-based switch with removable line cards (such as the Juniper EX9208), as its line cards are _not_ physically autonomous devices.

nautobot/docs/user-guide/core-data-model/extras/configcontext.md

@@ -1,78 +0,0 @@
-# Configuration Contexts
-
-Sometimes it is desirable to associate additional data with a group of devices or virtual machines to aid in automated configuration. For example, you might want to associate a set of syslog servers for all devices within a particular region. Context data enables the association of extra user-defined data with devices and virtual machines grouped by one or more of the following assignments:
-
-* Location
-* Role
-* Device type
-* Platform
-* Cluster group
-* Cluster
-* Tenant group
-* Tenant
-* Tag
-
-+++ 1.5.0
-    * Device redundancy group
-
-+++ 1.5.12
-    * Dynamic group - Need to set `settings.CONFIG_CONTEXT_DYNAMIC_GROUPS_ENABLED` to `True`. [See notes here](../../administration/configuration/optional-settings.md#config_context_dynamic_groups_enabled)
-
-Context data not specifically assigned to one or more of the above groups is by default associated with **all** devices and virtual machines.
-
-Configuration contexts may be managed within Nautobot via the UI and/or API; they may also be managed externally to Nautobot in a Git repository if desired.
-
-## Hierarchical Rendering
-
-Context data is arranged hierarchically, so that data with a higher weight can be entered to override lower-weight data. Multiple instances of data are automatically merged by Nautobot to present a single dictionary for each object.
-
-For example, suppose we want to specify a set of syslog and NTP servers for all devices within a region. We could create a config context instance with a weight of 1000 assigned to the region, with the following JSON data:
-
-```json
-{
-    "ntp-servers": [
-        "172.16.10.22",
-        "172.16.10.33"
-    ],
-    "syslog-servers": [
-        "172.16.9.100",
-        "172.16.9.101"
-    ]
-}
-```
-
-But suppose there's a problem at one particular location preventing traffic from reaching the regional syslog server. Devices there need to use a local syslog server instead of the two defined above. We'll create a second config context assigned only to that site with a weight of 2000 and the following data:
-
-```json
-{
-    "syslog-servers": [
-        "192.168.43.107"
-    ]
-}
-```
-
-When the context data for a device at this location is rendered, the second, higher-weight data overwrite the first, resulting in the following:
-
-```json
-{
-    "ntp-servers": [
-        "172.16.10.22",
-        "172.16.10.33"
-    ],
-    "syslog-servers": [
-        "192.168.43.107"
-    ]
-}
-```
-
-Data from the higher-weight context overwrites conflicting data from the lower-weight context, while the non-conflicting portion of the lower-weight context (the list of NTP servers) is preserved.
-
-!!! warning
-    ConfigContexts can be applied to parents and descendants of TreeModels such as Locations and RackGroups. The inheritance of ConfigContext will always be determined by the value of the weight attribute. You may see unexpected behavior if you have ConfigContexts of the same weight applied to TreeModel parents and their descendants.
-
-## Local Context Data
-
-Devices and virtual machines may also have a local config context defined. This local context will _always_ take precedence over any separate config context objects which apply to the device/VM. This is useful in situations where we need to call out a specific deviation in the data for a particular object.
-
-!!! warning
-    If you find that you're routinely defining local context data for many individual devices or virtual machines, custom fields may offer a more effective solution.

nautobot/docs/user-guide/core-data-model/extras/configcontextschema.md

@@ -1,73 +0,0 @@
-# Config Context Schemas
-
-+++ 1.1.0
-
-While config contexts allow for arbitrary data structures to be stored within Nautobot, at scale it is desirable to apply validation constraints to that data to ensure its consistency and to avoid data entry errors. To service this need, Nautobot supports optionally backing config contexts with [JSON Schemas](https://json-schema.org/) for validation. These schema are managed via the config context schema model and are optionally linked to config context instances, in addition to devices and virtual machines for the purpose of validating their local context data.
-
-A JSON Schema is capable of validating the structure, format, and type of your data, and acts as a form of documentation useful in a number of automation use cases.
-
-A config context is linked to a single schema object and thus they are meant to model individual units of the overall context. In this way, they validate each config context object, not the fully rendered context as viewed on a particular device or virtual machine.
-
-When a config context schema is employed on a config or local context, the data therein is validated when the object in question is saved. Should validation against the schema fail, a relevant error message is returned to the user and they are prevented from saving the data until the validation issue has been resolved.
-
-Here is an example JSON Schema which can be used to validate an NTP server config context:
-
-```json
-{
-    "type": "object",
-    "properties": {
-        "ntp-servers": {
-            "type": "array",
-            "minItems": 2,
-            "maxItems": 2,
-            "items": {
-                "type": "string",
-                "format": "ipv4"
-            }
-        }
-    },
-    "additionalProperties": false
-}
-```
-
-This schema would allow a config context with this data to pass:
-
-```json
-{
-    "ntp-servers": [
-        "172.16.10.22",
-        "172.16.10.33"
-    ]
-}
-```
-
-However it would not allow any of these examples to be saved:
-
-```json
-{
-    "ntp-servers": [
-        "172.16.10.22"
-    ]
-}
-```
-
-```json
-{
-    "ntp": "172.16.10.22,172.16.10.22"
-}
-```
-
-```json
-{
-    "ntp-servers": [
-        "172.16.10.22",
-        "172.16.10.33",
-        "5.5.4"
-    ]
-}
-```
-
-For more information on JSON Schemas and specifically type formats for specialized objects like IP addresses, hostnames, and more see the JSON Schema [docs](https://json-schema.org/understanding-json-schema/reference/string.html#format).
-
-!!! note
-    Config Context Schemas currently support the JSON Schema draft 7 specification.

nautobot/docs/user-guide/core-data-model/ipam/ipaddress.md

@@ -1,69 +0,0 @@
-# IP Addresses
-
-An IP address comprises a single host address (either IPv4 or IPv6) and its subnet mask. Its mask should match exactly how the IP address is configured on an interface in the real world.
-
-IP addresses are automatically arranged under parent prefixes according to the IP hierarchy. IP addresses are not directly assigned to namespaces or VRFs on an individual basis, but instead derive their namespace and VRF(s) from their parent prefix.
-
-+/- 2.0.0
-    In Nautobot 1.x, IP addresses were only loosely associated to prefixes, and it was possible to create "orphan" IP addresses that had no corresponding prefix record. In Nautobot 2.0 this is no longer the case; each IP address has a parent prefix, and you can no longer create IP addresses that do not belong to a defined prefix and namespace. When migrating existing data from Nautobot 1.x, parent prefixes will be automatically created where needed, but you may need to do some additional cleanup of your IPAM data after the migration in order to ensure its accuracy and correctness.
-
-Each IP address can also be assigned an operational [`status`](../../platform-functionality/status.md) and a functional role.  The following statuses are available by default:
-
-* Active
-* Reserved
-* Deprecated
-
-Roles are used to indicate some special attribute of an IP address; for example, use as a loopback or as the the virtual IP for a VRRP group. (Note that functional roles are conceptual in nature, and thus cannot be customized by the user.) Available roles include:
-
-* Loopback
-* Secondary
-* Anycast
-* VIP
-* VRRP
-* HSRP
-* GLBP
-
-Types are used to indicate special functions of an IP address such as DHCP or SLAAC. The default is "host":
-
-* Host
-* DHCP
-* SLAAC (IPv6 Stateless Address Autoconfiguration)
-
-+/- 2.0.0
-    The relationship to device and virtual machine interfaces has been changed to a many-to-many relationship. This allows an IP address to be assigned to multiple interfaces, and an interface to have multiple IP addresses assigned to it.
-
-An IP address can be assigned to device or virtual machine interfaces, and an interface may have multiple IP addresses assigned to it. Further, each device and virtual machine may have one of its interface IPs designated as its primary IP per address family (one for IPv4 and one for IPv6).
-
-!!! note
-    When primary IPs are set for both IPv4 and IPv6, Nautobot will prefer IPv6. This can be changed by setting the `PREFER_IPV4` configuration parameter.
-
-+/- 2.0.0
-    `prefix_length` becomes `mask_length` and is intended to describe the desired subnet mask of the IP addresses when configured on interface(s).
-
-## Network Address Translation (NAT)
-
-An IP address can be designated as the network address translation (NAT) inside IP address for one or more other IP addresses. This is useful primarily to denote a translation between public and private IP addresses. This relationship is followed in both directions: For example, if 10.0.0.1 is assigned as the inside IP for 192.0.2.1, 192.0.2.1 will be displayed as the outside IP for 10.0.0.1.
-
-+++ 1.3.0
-    Support for multiple outside NAT IP addresses was added.
-
-## IPAddress Parenting Concrete Relationship
-
-+++ 2.0.0
-
-The `ipam.IPAddress` model has been modified to have a foreign key to `ipam.Prefix` as the `parent` field. Parenting of IP addresses is now automatically managed at the database level to greatly improve performance especially when calculating tree hierarchy and utilization.
-
-The following guidance has been added for the `IPAddress.parent` field:
-
-* An `IPAddress` should have a parent `Prefix` of type `Network`
-* An `IPAddress` should not be created if a suitable parent `Prefix` of type `Network` does not exist
-* An `IPAddress` can be a member of a `Pool` but only if the `Pool` is a child of a `Network` prefix
-
-!!! warning
-    In a future Nautobot release, this guidance will become an enforced constraint on `IPAddress` creation and modification.
-
-## De-duplicating IPAddresses
-
-+++ 2.0.0
-
-After upgrading to Nautobot v2.0, in order to satisfy new uniqueness constraints, the data migrations may duplicate `IP Addresses` across different `Namespaces`. Check out this [IP Address Merge tool](../../feature-guides/ip-address-merge-tool.md) to collapse unnecessarily duplicated `IP Addresses`.

nautobot/docs/user-guide/core-data-model/ipam/media/ipam_namespace_documentation.drawio

@@ -1 +0,0 @@
-<mxfile host="app.diagrams.net" modified="2023-09-20T20:34:49.612Z" agent="5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/116.0.0.0 Safari/537.36" etag="263LmEapV4TFOOYiD1uO" version="20.8.23" type="device"><diagram name="Page-1" id="HMSZJAy41G0naUgyjOcL">7V1Xl5vKsv41XuveB3uRwyMggYQECggkeLmLnHOUfv2FmdHYCmPP9p5gn4M9toYGNVChq7rq6+ovMBN3XKFnnpBadvQFAqzuCzz5AkEQjgP9x9ByfGqBkKcWt/Ctxzbwe4Pkn+ynxvNltW/Z5cWFVZpGlZ9dNpppkthmddGmF0XaXl7mpNHlXTPdtW8aJFOPblv3vlV5j60ECnxvn9m+653vDAJPZ2L9fPFTQ+npVtr+0ARPv8BMkabV429xx9jRQL0zXR6/x75w9vnBCjupXvMFb1n8H8bZ7aGSmM4IoTBd7b7i+GM3jR7VT2/89LTV8UyCIq0Tyx56Ab7AdOv5lS1lujmcbXuu921eFUf9Edj/WlZFGj6TCu5bnDSpnvgKQsOxH0VMGqVF32DZjl5H/ePTemE+XTRc8/RQdlHZ3YuvCz4TsRc/O43tqjj2lzx94Sv8RPcnyft65kP7nY0gQj41ehc8PAuf/iQ87nPv3+nb//JE4n9AbvCNqf0jLb9AsA1aqI0/c+GHMySGwzr2cZSFsY8lLHRDWFGP7fKBcMPjYXk96BnNpEX2/eiG+D1RqnvyfKZkkib2FdmfmvTId5P+0OyJaPft9EBivx9HqKcTsW9Zw23usvSS6T9oDPxO2oC/kmXYezEMvmHYRK/0R+qVPYceBgWjuGDPmW0Dfb6WDwSi+gtALOseqPSdrZg7fILANxAivgHf+pdgyRtml6Fdmd4TzdO6ivykZ/TZjJwZ8YMS9X/Z4RVpt9At3/5+7o5YnC+fvCRDll56zxw/C8tSN+xonZZ+5aeD0BhpVaXxHWmq0uye0P04NPww7GLn46eXH87rZfb4oo7fDc9BZ6k/9DJt+s7Ks/R7ejZ8oazsxPSj/zkpJ8+ohXQ6w/SeplO5VSc9C9gdDuEkEkgknVkilkg4B8P4/gtEmyDtcnGQT3wlr9gVgMxq1fCaREBJt2cu60ygZoZbRcjUMIjBMSku+lY8ZGwxJ42u/72bEvCaRZrCM3ZkZ2ydgZeeXfDNhHCU9sD3d+GI4cpDdlL6A2NpDNLNakh/YC8N7BAgVn9cFSQcYMRyaax7QaDXNbmOsP5u9LKwRMY6pC1mkHvCJQhhfdpN0GbipASNb3C8wteVAS8J7DAx+44Sgej/F9v+P951GMSCl8fhvq0ZuCtBG+59wlbVppcBerjxEenkpRNApumx0sRZHh0aNev+RDioEESLiFkCOxIEO0BUD11bb4/w2iFtq8Gw2ZYzZ10p9FdOGrLiwYnOWEDUzts9GB3FgRi7XqarWZK2MhgKhYKCzECFDFJOcf/Z/2gItERsGNccR2oEftts61jdMkuAQZUcQxgJoAy+2tImP29kV1cY29zvtSPTn+OezhmqIoshNEn4mjsNNAg6zcFMUeUzB45OMwcp6cRDKUtsVpWLEZ3q+qlDOs6sllUeE4wG20+KNVMic3jb9PpNT7jAm7Bslk+ZUMQAZgNMhQyfetnqEBCFWC0OO1E/bCZBUzM+PuM2lBPLXDjTIhgzW0DXq13M+adDsZxwWE5rXt5lExfJUtM9iYzrO3S8jyJvRQlGf7eZB0/DFpN2ghUqXRoIjaKmuxhp9iHFs/Egyhh1ymnXXSJYFKpQ1CVl7TJHwNjuzGPBNDLlGcW26tQ23ujW4RQIh0iOUmoqswLtxKoWOvIgZPoqnVQ2kOYbMwXnQM2uDDlc9MpCr3jEGNwN2oK6zITjoJyrkgBZG3q+aCN4G1UQ1UjWghZXVe7sQWGGCJtip/I7ewX2r1aV5HGx1oROJ0OP2mxmRKRE6a4j+bXMeEYiecJqeJFZfwuaBbEI4KqASHW53cwiyU+QEpsyMpPGxxNCQahLmMouwiLdjneyLMPGblvT4iDT3HpPhCbDuIVbAN2DyKNzzJ0uLF1Yek5c9TeYih6Ud2sUKcQZkPmNG1t2PS11pbP307DWtfzkdQ63oDMNWiliKANGc6q23qA5cByfYp9m6aBpTuTSTgLDFVKWquqIWVnQXEQ1esYc4tN+s+r1h1YRBj/Mmu0RhQFL15xZo8QTpVUYy2IjYLPLlykfzKJdftwGbLLk3DBdzAerJLiwuJdWGY0EuVdp8wPvdjrKKHbSn9wfp4pZCguBUMz82NYY4GpWa0O1mZxOawkI5WR1kllmz8I7drd3aVWsBTbYmoaXLo7NgikKV1tu6DImOUaag/h6spJgB5xiSSCXG8V31AOecsJyy9fbZgE4e+zA9aMDxC+1lTQN0xkHuyzIZYImQiexsBQuNau1PfWMfkSle1IcNC4o0EUHljm9CAzNDhFAEZPdDrApf48pi/Uwuiihn4GUmy6QRZWksh6tK3MSrgK/rjiYbZjDojkQirEPpQwqcSx0dgfIrb3hm0dxy2vdMfBPdXqKQTjUExRlp4GMm0nQ5VYdKCQ72+brgV4yJu4qRt9yGYSLc2pvxSXhirsMtFs9A/TIEACPzgZ2nXpqrGANpfV0l+PE1KV1Tj8daSI1UtLBGQWrjDCUGsVZoe6CPFS+LjL5Hhe5dh/1vRqi3PdKYv3LZAYBaHRuG6dtCkqwhsB6/tCnUWu7gra8CF0dojU3yHwrLKsi4QHiBFQ8uzmFILWJUOfUTcGEUnDDoTX5wKl7ploezQwbrIN0onS0WbuhV6GQ5kkqgHHJtnRkfx1ER16VCjnZKLmHc1LLn1J2P+MOfrD3/GyXodNhGOSWA2myY9/Q/5KFJOVDSbteyEXkKToBk8EJ3Ie9FSwWfsLrU2Sq8PtByVhr+AatY3tlYe5klqIOJ2Ap2hkgu+QmpytSb3vjwOYyvj5E26VfrTvExQtnn9KVCqXbLF5x0DINlbUBLm0Ih5RQ32kWuAikwI79bcbXkueya61YcxMFs2bNIhe5YA+L3EYdXDYT0MVZBdkCVACYqJuyxQSQ1m3ngAmjaasvndQwpxrtc9qJjoZB1Chb1aA5bKHAIRNIztJyF9asznOWcfcnkd2os1gA9iLV97rYp73EaIKsMC4kD71SsJamOumEhjDd9wxj1Z1ZbEKpt1u4JNmlcOxm0AEXmZY5opOcj1omLAkbMtkyCh4ewJ5jYWJrp1oojxgRT9nVtJ3R0yoRWFQr2tnGbTLHVvnVvL+4Y2TZ2XoOR5hSeVT2COLNbEDfzsjdchW1ND9L60UWzpw9dRQ4H5eTeCf0LgntEbXHt21waDqQVFVJUrB5A6BCeOSDuT7wm/JBryObMFJFqc5ZHhUwDNgdClEvdQmZiRNLNZASPlDL48LYeJXFAFqzKm2Yq+xQ3GvNdo9Z9YYMvGUWlE2Jr6c0p5YS7OLrteGrgUXzStVxMYsuO0pLCk8xdrYN6mKXY/4yq6yVLy0XpAST9iahJ3N2xTXkoTf77PAC7qxK8OMeq1YHVQPXxwhvrH70OEQaJDbt+n/fZkYBYpczCgK4nVKg8O2MAifeaUaB3MwoVo7jm/YbziaAcS7xdnOJSissMyvb6XzvdIU5zCc2M7/MBAgfBht9xc3yDaXigbOGInPGpCKIqMtmoTFGwG87YB1GuN6PafaunykMPkkRaIYBwDW4GiRJOCHwfjBzmYQ74PoAI9ai0hc7vvZA7uTk+UyfuTiIJ8UJ70WHxephLmAM48z0sKvtwUFXRBLsfRTcxjBbh7D+VNAN7tC2yyE33pFqEYPA4F8StF3Dg6udgad+VAUCS8zt/pj0OmuNby3SWoAzAhycv5gjDvTD/KPvyFCtBg+I5eB3QaFuoIOvVXBToeT6S/DaMsrCg7l+BCOpxaQiGqp1YGeSYbDRlU4GGtTKsOT1pr9438678silK22C0MGE7IYhc7AgB2RqD7fC8OOEGSh7HAxQDdcpaQ9+6Qw4zTmlaZabrUJhYAnKR13bCVkyb8tjPyFY1pHfVEEND/YKSBhdzySdtSiGT1uLV6S8tDeFZjETBjvMvRmoE1wnszS68uXjrqZqQQaiCW1OQ3CxmNAbfTctARZTlCW9NTe+nO9qt17KA8um64XpydxenkeLKZ4tpU7k1wPRuvU8EbJaOuRH8BjEnVOUkozvN3OJmZwkhaPnrrqbIodsi0kUP1kYUy9MTL43BR5PKpQ3n69FPlR7MwXF/LyOZtmcCoWslFipn0yhahwm6JQOXb88Rltd5mF9H/qYZvJbOCw224W2A0I+BvvZm5EZhXC+N3WSPI5WXWM3TZ/v7Uw9ObF4e/9874m4kNWpT2eCtLUWa4li+Z5H0TzEpwdloUvrdMtJDH9aWNNsHiMSkO6yjDy2XsLAR9SdB0K+37OnDp1VR3SvlhkgUBv1mHX9k3Fqu1S4jRNtFgI/1SLdRVKjBkRuBoTSjNqsdDl1eXbCqBFTrdaSO42FXJCmkuMv/UiMZ6hMB8yW0/ZzkWbh/FAlC30tptOtx4DLpXT0oi0drpLFqUziTaQ3vcvsIXM+l+VIcnraSYkxTH5hFZjBw8Q32JG4OMtBtJvmfooN83Ksl6LcO9CRpOx0p5/TzbeKXptgneJFKtNFtGx1ufG2BMqbtg7qnBXj3EqyNUugQt7xlqo0SMdxxq8FG+OVclJJvf0nNoa9rxAn3zIQl4UTYlDAJVOFxQJUFeMgxra5VaalXbfUqVuoCRPqGjb39jEUkoWRLzKyWjkeTJIenkAuasXrSjmuy1oq89kRExQwlL0y7xg2oDNu4lX9v5oLqE5c87mSr0RYEqmVbwxzc86k80wLduBgg6eSiWjHXexgeu966UjsD7O/wUM9iBN7EssCJAxHm/yErzzXYNp+Ij/l0VPvAwCqvKozG4DWVGsdgarg8c4Ew3q7U2v1MC/jIKmTCp7xDZBNDCyZFZI/s0/s4KGHAMT2szAWoyZYkgU7wPAYiIlilYsSSmsOgwe1dT20TA7NKVyu6bbbxnhltPysWTe5yTLk4N20kzfyEOBXOAh3Qo7v5iCgbx18v7aKlybbgYa/g4WP9LJ86vLSfH9Pf2R24fdvaRfD7fzEfbr8Lbjwimg9gn9stB77WbT+u7P26Hd998SE9VLqv0brZmgMjs9/YRz/mZu/4h75Xrx7RcLwvZ1hZALhFPUnOMPQlTMM/K4zXChBVebzdjIDBkcYNvTeoqH1YQ3jSd36rBMvAm/wcdcTiAGllrGZ3gStBKDbrnboYlfNVHaGWZVZevu9rycbVLcHW0TjmSPHBc6DBFmrFYH6AV3ujzv0FDXb4ypzcFx01QblT1YI5iSxyxymlxG2hOrBR61I+6RWlVWe1kZj5C0xS6QGzYMVcFhXi+OCTjlbic1VVTpCQ8CS8RBxZoN6H+0XK95J8h0Oa73nVhmbGoP3UByplkjC61SuEgIf4vDwsT2Gxgo+sS2Ritm2UfSJFMOsF+8nFnGE1pB7Ktf9hQKK66SKSdlyBnuYJAZx4B9Q7DDkC5Z4gegLQwKOHFdtJSnYQg0gL2uCWFDulFapDaAw+xKihHKR9u41O3fbisLyaMpN0z2FBYgFbGYGt6FsgU0bg+lUX0z6G0rHeaDiaKqHpL7rHyJMe7JZfCVTbO4avpyuRQ8220ihDbys8rmqBP3QYxcUK7bV5gjweyncTjKy91MVb7lnYk/t3I4BdAKPOk83ty3ByqkaH5wwtCJ6w2xp1rKwAMS6E2Me42YyxY/CNG2o0McpfBrtc54GRAgLWJYtYxEyMK/UN5vFvhqIyRBqAZuurKhJCG+3k0GWiphvE7c68LDLqb1LHnPJEDeU99KO3eRLzfEgDxXkOSE7WlXQHsEn2TY+kVwZUU6jNk0u5RomQpPZErA0bVI5stNVAdcsm9TF8CnPRkvc3DSxF1fEMmbikO7kmF/4/FHlQj0+ca0VO3wRRg085TTH6D3rFRz20rIoGjJptx0YOEdK3fkALm8DcMsNM6+pseviYfpG+jrTNe0xc3lZNgFJ8HIFLpUhebSSl4KbLQ2ZV9RTu9tsKi3e5Q4pBHZyiNc4s7aqk166OLKfz1lgPpEPZbZM1WnvzxnM5rRgEs71/P3Cllzs6EwTNlBDUdp3YjfH5/jUgZu6oRXNnwZYUxuUnqq98qSqOXi1RbcpFfRIK3ThBkd5nof1kYYKIF7hq3gOy13ZX7TcuZVotB6bYz46zA9XnQZbtlAfJZWqI2umACsLVGDZUnvVYf/3PFo8DNoo3f8A38D+iwzwjYCGj+d/aD8QMg/niZfOo5O3sTnPtuSM4SHAb+iNFTq7bR/iyhH/xJUD/7UrZ+k24Zj3cBWYSdiGc4FfId6G6s/u8pnqd9xnDLlj+SEEfCeqkz9z234EWdRlb1ztIdxG/Tc6aSBAXPEOhG54BxF3ePducIuzKz+6baPbNrpto9s2um1v7La9gdnArzJqMIx/rpcF3qbUzuGZrLC/58WAbxjyDfg23A0Gz1cMmZfvF90YGzuxqAGePYzWQ3zMf3Sv9KK6bf5hFH/Rdj+4bdFgLobwkPtw3ZWFeTybFpZdXBuqq3yWbbn2+TgtKi9100SPpt9bn95nuO7nzO7fOa0L0/51QKV/ddeufmnCX0Z4At8QBCIvY33g60Ku57bCjvTKby7f6Z5YPT3FejCRPwgwdCnAGHDVxSMtnr71XThvO8IvO0LRq44eiXXTUS86+vGHy57mUi8+MIpe0uscXXvpuW6ux7ErJXt8gqtvnx8ndZzSrr5cq+UzL/+Fpr4itv0uGvehmnKW5l+rCnxfVT5GDUDgSg9g4jf1AATwa5PwOkV4M7m6F+19HN+9S/E6z/KGScPXM1EHPMUwzUHvAirWhT342uUPFmPo9Dnq/93Q/LP7ANeIDuIFRMdzruHuHV6+fuj/VVCSl278A5SE+OHtH/u9vNeQub/TdmFa/5MpRULfQOyM4e+HnH9PrTeLQpTPqTr0+9FumIhOhiTb/eBD2ruITvQw3Hq+ZdnJL4fYyxVV4BuFKEAEvRxZgNsQBXhvkCTfy9uEbrOCY4hiDFGMIYoxRDGGKN4ls3TOHKEflTlCMeCzM0fwaGVGKzNamdHKjFbmo/AL5IOVAV+CL2AfbIQI5NPhC/A9/MIYVvn3YZWnTMRDrAD42yIrb0yNr8PJHylykZv5r6fITbbqr6DIxyrUQLDeFf72mVR6kRjFGOh7hfWDMeLC+p2N4Y9hvntFkJ7rdL19Vvm29MtlPPyDZ2P/gUsrxzItX8YyLWOZlrFMy1imZSzTMpZpGcu0jGVa/lvLtJBX0a97oNIPLdOC364iuXH5x5zLmHMZcy5jzmXMubwu5/JcWvyNakZcr0SAIORzEybntXLvjm/+VysIfhjgv7zh+oAng/lr1DN0n6kfg3omr2QGvF7L+HrQM3jV03UdkvcGPUO3AcobGOoYpBzrv43138b6b2P9t7H+21j/7YXQwzPQ5id+5IeWgCNuTfvPVrTeoCbefUXrW/if9yz0H7mi9dGz/fmKVgS69AU/dEErdl3HA/hNnxa/KsL3vLLmvRe0gv9sQSuEwVc69kkLWolXwLTftMIPahMWcuNf92cIyICx4RvvXuEHOc/0Pq/CD3G73vOXJX4uMDpvhrn520r8ICR4w7yPLfFDvKIo1riyYYyyj1H2Mco+Rtn/jBI/2DmU+GmB9VdkY//+wiFn0/jLGQn5Avs+qXAI9vsxdPxa0D42hn72hkaQ7wjyHUG+I8h3BPmOIN8R5DuCfEeQ7wjyHUG+7w3yvTet/FCQL3kvzzbGIsdY5BiLHGORYyzyj4xFogD8ubFI8nZh+PvEIv9AkO/ZYP46Qol8ZoTyGuSLwOTvBiivQL4wcdXTewcob2vbg/gA8j1jfD/eYfkPjFGOGN8R4ztifEeM74jx/RMxvsazC7R6tGZf3mwF2S329557+aHYX/If7f/87yGFjmNj5t1NAy2cNADgIyCFzz7+J24a+NPNnu9DCpkRUjgwD4dumPexkEJy3Ox5DOONYbwxjDeG8f6aMB5BfvKugeQrcOh/P6SQfP22fS/s2/dJmELy2tP7bUwhQV719N7r8s/O7YsL8yF4DNqNwMIRWDgCC0dg4QgsHIGFI7BwBBaOwMIRWPhmwMJ7k8sPBRaCwO3CojEkOYYkx5DkGJIcQ5J/aEgSJz65fCh43tz6vxFa+GwyXxGqhD8zVHkNLsShq7zmb4MLMfyqp3ePVN7Z4+gpUgmNkcoRXjjCC0d44QgvHOGF/9HwwjeJP1zDCO/5kh8KI4TvwQjHvXv/9d69N4nccWPWX1MLejtqvRnM8m/eLRUEkcvhhsBuMZjgvfGGJN9pvIHG8eZdNOiiGtU41vyEUtfL4sah5l2GGvSOZ3N/qHm/MNnLY8298ujgWB/9tyJyMPbKgNxjtu2nBdKx80LVJyn6+rEV0p/7OdvL60jba2N28NXKFeI6+PdOFdIJ8p9VSCefmPfpFdJB4N7ijJeVlfhrdfXXunmpzZ+gqE8x9p9q6p+1lcFZ7v/1VgYE8kGKiv8zRSWgP2QrAxC4B4gfPfjRg/8oSn0dTn6nFjlS6xXUAiHib6XXvYjaUBFunKH9oxna1cKZ3kU9x6J/nKFhd2w2SFzZxLebokG3Xp+wXkp9i7Jln2WgOLNyWFRN3bp3UeRn5QN/njKqZpTW1gvseNHBu9h21h0cwvOJH1PZl6Ji2Y5ePzzkJc/ge5O0ywQ2+/DnbXgLI5fMhVHyHnPP+4VdMBeG3ou54C1sQOCEXd8i2lWbFuGPDH7FEIe9Ktg+bmf6FliEQks8IxfaiWA7Xk5sS1mYz4CHFHxPYzvdJ9oEJNhpDVYDEqutI1farlYdr++0zPczyCFgey4hapPhjrVFQboJKhJcVycvIE6u6MTyAEUAnEGy6fjYMnsJn2pcBuMPCwTg7YA9qANwDVYrdGjD9wcC9pxlHenWADJvimj41AorYmU0buhD1AyICZYYoOKOGMGGXgciCOJ1NSTqbdJyanxAUgCw7eAmhwosWQelRVpDQh1ba6f+84CJkTus5zqcTpsZjEFo3fXNaHSMGapFcy7C4rlGcu5phaGwbypxYRIhq7J848MluXcagLAarOM6Wz1MmAOMV4PN3fFNuw0bgE+IzfB03BFns2GcY6mMCXpxbB+gCTQUDuTltWmXKfziNGBUl7Ur9KJOIyvViBw4PCKn1clTU4k2XZNjhSqK5YVcnzbQXFzK8B5jfE/Z1Jyvlih/iggI6kyKBZMjuUDJjU7Rp4xgTTHjWABXNZkyF1RDqTFMrME5ouUbh9F3Iu3SwORoK3KEYTWNtFkEiXBeDK/C5lETpnwoWs0K9bpWqXf5QMBTmlNLag9V7HYPG1UM0tgJRhOBphQJiW1WWSILf2PYjLhJjXKxTbmASBhnSRlLi9BhbiMYwRwyQq5oqI1c6+6a8gt2Q8cItPVSMZ87Mz9WfDXNEAkp9cyXteV8seXTIBwWpXGe1oiAtoc7JY5tyXKoLCP0yEnRw8pcCMYJctiaAVetnIfyhi5nzGQteXTeSawuNzG/oJteUDTfZxbhXklK36P3u/kEnia93M8l2Nhx4XazoUyVXDeMJa84KeTTaGMwm2XKTd0qI+fTRcwIS30xxXySiUNsO0kUOVsB/ioaVnsgwWkNQDnSTYTVyiSYFtvMlruILdY2UGt1tyEgDGRyE1LblkH1ZMazRxpoD1NWU5goqDc5WOjNxs/NxaQccvsnjp/oYoakYFFhWrQONtMpNYvXpyGLBu5KENkMMt3lMy5iNsJcPciztX6YSJEBRa3Fbo/Iol51MrLrBATWir1NFiYycd0pNbEXPSNm/LFEsc2Kbvc7b7B1XamUoYfnc8neYZW1NtaBqVMuNbhcpDuN8/0MPApd2mEaUy5pAXNRquj2myg88cXKEFcRv98e4aNfrDcLaQDfnKIdKtnN3jNMvnCZbqfM5FQJ82YrPmATfI5PdySkZBpTZMaBg076fFi1ViQaXToq71AtrjFd6zOm6AlTaMJt9id0tnX6AYR1GVDNdoM67xb5dFkG2x0mJZvlCsZogVmVGpUe6AVNsW3AYoyHlnQTB3hyMHdW7ybT8wNH+Diq12Adg5B4aGeDe9D/3OxSf2v9nwIC/eUo3f8A34aUGtObKGT4eP6H9vaD6c+DDyfRn5wbKs9cnkQnb+M9gOevnEP3GHTHe7gLccXezTG8XRz9h4f1Or86DH0OjH48VB8Oe4Y/Hk66p1s+HBx/OFjbhd/TbTDsj21JT8PHzkD0fPzYGwGdj79393B0/PHousM3DCI+e3W/3g/1vtB9TIDwK3TlEiO/C7/9Cl6tGoI/Gn57fvu/RxfO8gteCi/6ybILvToADn4qdPzrdR4KhX9XeKHrXVmv5/LvLryv2Pr2rxBeEvsd6f1uFsBLswD+Y6vwhorw+kzQ5yoCdJWd+e01FF/B69UYH7yDHAjc04OX85vImN98v+H9sTz5z9Ob6CWc5YPTm1e1idDrUfvV6U3oF4bkndKb6D/EIaBP2eQ/IL15W0n9Z3qK/bV6+qmYoVer6uNepz9X1XPE93MwQ+DVROO3MUPX84yPwgydN1N9ra5iT0Pj5+sq9FG1+d4+SECgF97g47T+d4ME0FWQAPrsidarqwlCnxokgK/3/7h2Cl8N97uCI8HXcKR3n2Xdbnz9qzwqc6sqYx4VRi74SIJ/Qh717LP9A+be8T1G5l4Zagwm/gTm/rXBvbeyOy8bxfPhp8RIXh8shD+1JC4M/iKy8WojdmUNsetC/O9txM5K9jeqAoFdqgLxL1UBulQF6FNV4dm9+KUuPAYWP0sVwKuwCYn+pipcg+VI4K1UYchcpwN66fvlvcX1hNSyhyv+Hw==</diagram></mxfile>