Finish refreshing DCIM models documentation

docs/models/dcim/cable.md

@@ -1,24 +1,42 @@
 # Cables
 
-All connections between device components in NetBox are represented using cables. A cable represents a direct physical connection between two termination points, such as between a console port and a patch panel port, or between two network interfaces.
+All connections between device components in NetBox are represented using cables. A cable represents a direct physical connection between two sets of endpoints (A and B), such as a console port and a patch panel port, or between two network interfaces. Cables may be connected to the following objects:
 
-Each cable must have two endpoints defined. These endpoints are sometimes referenced as A and B for clarity, however cables are direction-agnostic and the order in which terminations are made has no meaning. Cables may be connected to the following objects:
-
-* Circuit terminations
+* Network interfaces
 * Console ports
 * Console server ports
-* Interfaces
 * Pass-through ports (front and rear)
-* Power feeds
-* Power outlets
+* Circuit terminations
 * Power ports
+* Power outlets
+* Power feeds
 
-Each cable may be assigned a type, label, length, and color. Each cable is also assigned one of three operational statuses:
+## Fields
+
+### Status
+
+The cable's operational status. Choices include:
 
 * Active (default)
 * Planned
 * Decommissioning
 
+### Type
+
+The cable's physical medium or classification.
+
+### Label
+
+An arbitrary label used to identify the cable.
+
+### Color
+
+The color of the cable.
+
+### Length
+
+The numeric length of the cable, including a unit designation (e.g. 100 meters or 25 feet).
+
 ## Tracing Cables
 
-A cable may be traced from either of its endpoints by clicking the "trace" button. (A REST API endpoint also provides this functionality.) NetBox will follow the path of connected cables from this termination across the directly connected cable to the far-end termination. If the cable connects to a pass-through port, and the peer port has another cable connected, NetBox will continue following the cable path until it encounters a non-pass-through or unconnected termination point. The entire path will be displayed to the user.
+A cable may be traced from any of its endpoints by clicking the "trace" button. (A REST API endpoint also provides this functionality.) NetBox will follow the path of connected cables from this termination across the directly connected cable to the far-end termination. If the cable connects to a pass-through port, and the peer port has another cable connected, NetBox will continue following the cable path until it encounters a non-pass-through or unconnected termination point. The entire path will be displayed to the user.

docs/models/dcim/consoleserverport.md

@@ -33,4 +33,4 @@ Operating speed, in bits per second (bps).
 
 ### Mark Connected
 
-If selected, this component will be treated as if a cable has been connected.
+If selected, this component will be treated as if a cable has been connected.

docs/models/dcim/device.md

@@ -8,8 +8,86 @@ A device is said to be full-depth if its installation on one rack face prevents
 
 Each device must be instantiated from a pre-created device type, and its default components (console ports, power ports, interfaces, etc.) will be created automatically. (The device type associated with a device may be changed after its creation, however its components will not be updated retroactively.)
 
-Each device must be assigned a site, device role, and operational status, and may optionally be assigned to a specific location and/or rack within a site. A platform, serial number, and asset tag may optionally be assigned to each device.
-
 Device names must be unique within a site, unless the device has been assigned to a tenant. Devices may also be unnamed.
 
 When a device has one or more interfaces with IP addresses assigned, a primary IP for the device can be designated, for both IPv4 and IPv6.
+
+## Fields
+
+### Name
+
+The device's configured name. This field is optional; devices can be unnamed. However, if set, the name must be unique to the assigned site and tenant.
+
+### Device Role
+
+The functional [role](./devicerole.md) assigned to this device.
+
+### Device Type
+
+The hardware [device type](./devicetype.md) which defines the device's make & model. Upon creating, all templated components assigned to the device type will be replicated on the new device.
+
+### Airflow
+
+The direction in which air circulates through the device chassis for cooling.
+
+### Serial Number
+
+The unique physical serial number assigned to this device by its manufacturer.
+
+### Asset Tag
+
+A unique, locally-administered label used to identify hardware resources.
+
+### Site
+
+The [site](./site.md) in which this device is located.
+
+### Location
+
+A specific [location](./location.md) where this device resides within the assigned site (optional).
+
+### Rack
+
+The [rack](./rack.md) within which this device is installed (optional).
+
+### Rack Face
+
+If installed in a rack, this field denotes the primary face on which the device is mounted.
+
+### Position
+
+If installed in a rack, this field indicates the base rack unit in which the device is mounted.
+
+!!! tip
+    Devices with a height of more than one rack unit should be set to the lowest-numbered rack unit that they occupy.
+
+### Status
+
+The device's operational status.
+
+!!! tip
+    Additional statuses may be defined by setting `Device.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
+
+### Platform
+
+A device may be associated with a particular [platform](./platform.md) to indicate its operating system. Note that only platforms assigned to the associated manufacturer (or to no manufacturer) will be available for selection.
+
+### Cluster
+
+If this device will serve as a host for a virtualization [cluster](../virtualization/cluster.md), it can be assigned here. (Host devices can also be assigned by editing the cluster.)
+
+### Virtual Chassis
+
+The [virtual chassis](./virtualchassis.md) of which this device is a member, if any.
+
+### VC Position
+
+If assigned to a [virtual chassis](./virtualchassis.md), this field indicates the device's member position.
+
+### VC Priority
+
+If assigned to a [virtual chassis](./virtualchassis.md), this field indicates the device's priority for master election.
+
+### Local Config Context Data
+
+Any unique [context data](../../features/context-data.md) to be associated with the device.

docs/models/dcim/devicebay.md

@@ -7,6 +7,9 @@ Child devices are first-class Devices in their own right: That is, they are full
 !!! note
     Device bays are **not** suitable for modeling line cards (such as those commonly found in chassis-based routers and switches), as these components depend on the control plane of the parent device to operate. Instead, these should be modeled as [modules](./module.md) installed within [module bays](./modulebay.md).
 
+!!! tip
+    Like most device components, device bays are instantiated automatically from [device bay templates](./devicebaytemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/devicerole.md

@@ -1,3 +1,21 @@
 # Device Roles
 
 Devices can be organized by functional roles, which are fully customizable by the user. For example, you might create roles for core switches, distribution switches, and access switches within your network.
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Color
+
+The color used when displaying the role in the NetBox UI.
+
+### VM Role
+
+If selected, this role may be assigned to [virtual machines](../virtualization/virtualmachine.md)

docs/models/dcim/devicetype.md

@@ -4,13 +4,43 @@ A device type represents a particular make and model of hardware that exists in
 
 Device types are instantiated as devices installed within sites and/or equipment racks. For example, you might define a device type to represent a Juniper EX4300-48T network switch with 48 Ethernet interfaces. You can then create multiple _instances_ of this type named "switch1," "switch2," and so on. Each device will automatically inherit the components (such as interfaces) of its device type at the time of creation. However, changes made to a device type will **not** apply to instances of that device type retroactively.
 
-Some devices house child devices which share physical resources, like space and power, but which function independently. A common example of this is blade server chassis. Each device type is designated as one of the following:
-
-* A parent device (which has device bays)
-* A child device (which must be installed within a device bay)
-* Neither
-
 !!! note
     This parent/child relationship is **not** suitable for modeling chassis-based devices, wherein child members share a common control plane. Instead, line cards and similarly non-autonomous hardware should be modeled as modules or inventory items within a device.
 
-A device type may optionally specify an airflow direction, such as front-to-rear, rear-to-front, or passive. Airflow direction may also be set separately per device. If it is not defined for a device at the time of its creation, it will inherit the airflow setting of its device type.
+## Fields
+
+### Manufacturer
+
+The [manufacturer](./manufacturer.md) which produces this type of device.
+
+### Model
+
+The model number assigned to this device type by its manufacturer. Must be unique to the manufacturer.
+
+### Slug
+
+A unique URL-friendly representation of the model identifier. (This value can be used for filtering.)
+
+### Part Number
+
+An alternative part number to uniquely identify the device type.
+
+### Height
+
+The height of the physical device in rack units. (For device types that are not rack-mountable, this should be `0`.)
+
+### Is Full Depth
+
+If selected, this device type is considered to occupy both the front and rear faces of a rack, regardless of which face it is assigned.
+
+### Parent/Child Status
+
+Indicates whether this is a parent type (capable of housing child devices), a child type (which must be installed within a device bay), or neither.
+
+### Airflow
+
+The default direction in which airflow circulates within the device chassis. This may be configured differently for instantiated devices (e.g. because of different fan modules).
+
+### Front & Rear Images
+
+Users can upload illustrations of the device's front and rear panels. If present, these will be used to render the device in [rack](./rack.md) elevation diagrams.

docs/models/dcim/frontport.md

@@ -2,6 +2,9 @@
 
 Front ports are pass-through ports which represent physical cable connections that comprise part of a longer path. For example, the ports on the front face of a UTP patch panel would be modeled in NetBox as front ports. Each port is assigned a physical type, and must be mapped to a specific [rear port](./rearport.md) on the same device. A single rear port may be mapped to multiple front ports, using numeric positions to annotate the specific alignment of each.
 
+!!! tip
+    Like most device components, front ports are instantiated automatically from [front port templates](./frontporttemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/interface.md

@@ -2,6 +2,9 @@
 
 Interfaces in NetBox 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. IP addresses and VLANs can be assigned to interfaces.
 
+!!! tip
+    Like most device components, interfaces are instantiated automatically from [interface templates](./interfacetemplate.md) assigned to the selected device type when a device is created.
+
 !!! note
     Although both devices and virtual machines both can have interfaces assigned, a separate model is used for each. Thus, device interfaces have some properties that are not present on virtual machine interfaces and vice versa.
 

docs/models/dcim/inventoryitem.md

@@ -4,6 +4,9 @@ Inventory items represent hardware components installed within a device, such as
 
 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. An inventory item may also be associated with a specific component within the same device. For example, you may wish to associate a transceiver with an interface.
 
+!!! tip
+    Like most device components, inventory items can be instantiated automatically from [templates](./inventoryitemtemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/inventoryitemrole.md

@@ -1,3 +1,17 @@
 # Inventory Item Roles
 
 Inventory items can be organized by functional roles, which are fully customizable by the user. For example, you might create roles for power supplies, fans, interface optics, etc.
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Color
+
+The color used when displaying the role in the NetBox UI.

docs/models/dcim/location.md

@@ -1,5 +1,28 @@
 # Locations
 
-Racks and devices can be grouped by location within a site. A location may represent a floor, room, cage, or similar organizational unit. Locations can be nested to form a hierarchy. For example, you may have floors within a site, and rooms within a floor.
+[Racks](./rack.md) and [devices](./device.md) can be grouped by location within a [site](./site.md). A location may represent a floor, room, cage, or similar organizational unit. Locations can be nested to form a hierarchy. For example, you may have floors within a site, and rooms within a floor.
 
-Each location must have a name that is unique within its parent site and location, if any, and must be assigned an operational status. (The set of available statuses is configurable.)
+## Fields
+
+### Site
+
+The parent [site](./site.md) to which this location belongs.
+
+### Parent
+
+The parent location of which this location is a child (optional).
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Status
+
+The location's operational status.
+
+!!! tip
+    Additional statuses may be defined by setting `Location.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.

docs/models/dcim/manufacturer.md

@@ -1,3 +1,13 @@
 # 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.
+A manufacturer represents the "make" of a device; e.g. Cisco or Dell. Each [device type](./devicetype.md) must be assigned to a manufacturer. ([Inventory items](./inventoryitem.md) and [platforms](./platform.md) may also be associated with manufacturers.)
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)

docs/models/dcim/module.md

@@ -2,4 +2,34 @@
 
 A module is a field-replaceable hardware component installed within a device which houses its own child components. The most common example is a chassis-based router or switch.
 
-Similar to devices, modules are instantiated from module types, and any components associated with the module type are automatically instantiated on the new model. Each module must be installed within a module bay on a device, and each module bay may have only one module installed in it. A module may optionally be assigned a serial number and asset tag.
+Similar to devices, modules are instantiated from [module types](./moduletype.md), and any components associated with the module type are automatically instantiated on the new model. Each module must be installed within a [module bay](./modulebay.md) on a [device](./device.md), and each module bay may have only one module installed in it.
+
+## Fields
+
+### Device
+
+The parent [device](./device.md) into which the module is installed.
+
+### Module Bay
+
+The [module bay](./modulebay.md) into which the module is installed.
+
+### Module Type
+
+The [module type](./moduletype.md) which represents the physical make & model of hardware. By default, module components will be instantiated automatically from the module type when creating a new module.
+
+### Serial Number
+
+The unique physical serial number assigned to this module by its manufacturer.
+
+### Asset Tag
+
+A unique, locally-administered label used to identify hardware resources.
+
+### Replicate Components
+
+Controls whether templates module type components are automatically added when creating a new module.
+
+### Adopt Components
+
+Controls whether pre-existing components assigned to the device with the same names as components that would be created automatically will be assigned to the new module.

docs/models/dcim/modulebay.md

@@ -5,6 +5,9 @@ Module bays represent a space or slot within a device in which a field-replaceab
 !!! note
     If you need to model child devices rather than modules, use a [device bay](./devicebay.md) instead.
 
+!!! tip
+    Like most device components, module bays are instantiated automatically from [module bay templates](./modulebaytemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/moduletype.md

@@ -1,8 +1,8 @@
 # Module Types
 
-A module type represent a specific make and model of hardware component which is installable within a device and has its own child components. For example, consider a chassis-based switch or router with a number of field-replaceable line cards. Each line card has its own model number and includes a certain set of components such as interfaces. Each module type may have a manufacturer, model number, and part number assigned to it.
+A module type represents a specific make and model of hardware component which is installable within a device's [module bay](./modulebay.md) and has its own child components. For example, consider a chassis-based switch or router with a number of field-replaceable line cards. Each line card has its own model number and includes a certain set of components such as interfaces. Each module type may have a manufacturer, model number, and part number assigned to it.
 
-Similar to device types, each module type can have any of the following component templates associated with it:
+Similar to [device types](./devicetype.md), each module type can have any of the following component templates associated with it:
 
 * Interfaces
 * Console ports
@@ -21,3 +21,17 @@ When adding component templates to a module type, the string `{module}` can be u
 For example, you can create a module type with interface templates named `Gi{module}/0/[1-48]`. When a new module of this type is "installed" to a module bay with a position of "3", NetBox will automatically name these interfaces `Gi3/0/[1-48]`.
 
 Automatic renaming is supported for all modular component types (those listed above).
+
+## Fields
+
+### Manufacturer
+
+The [manufacturer](./manufacturer.md) which produces this type of module.
+
+### Model
+
+The model number assigned to this module type by its manufacturer. Must be unique to the manufacturer.
+
+### Part Number
+
+An alternative part number to uniquely identify the module type.

docs/models/dcim/platform.md

@@ -1,9 +1,31 @@
 # 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.
+A platform defines the type of software running on a [device](./device.md) or [virtual machine](../virtualization/virtualmachine.md). 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.
+Platforms may optionally be limited by [manufacturer](./manufacturer.md): 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 is also used to indicate which NAPALM driver (if any) and any associated arguments NetBox should use when connecting to a remote device. The name of the driver along with optional parameters are stored with the platform.
+The platform model is also used to indicate which [NAPALM driver](../../integrations/napalm.md) (if any) and any associated arguments NetBox should use when connecting to a remote device. The name of the driver along with optional parameters are stored with the platform.
 
 The assignment of platforms to devices is an optional feature, and may be disregarded if not desired.
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Manufacturer
+
+If designated, this platform will be available for use only to devices assigned to this [manufacturer](./manufacturer.md). This can be handy e.g. for limiting network operating systems to use on hardware produced by the relevant vendor. However, it should not be used when defining general-purpose software platforms.
+
+### NAPALM Driver
+
+The [NAPALM driver](https://napalm.readthedocs.io/en/latest/support/index.html) associated with this platform.
+
+### NAPALM Arguments
+
+Any additional arguments to send when invoking the NAPALM driver assigned to this platform.

docs/models/dcim/powerfeed.md

@@ -1,21 +1,55 @@
 # 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.
+A power feed represents the distribution of power from a [power panel](./powerpanel.md) to a particular [device](./device.md), typically a power distribution unit (PDU). The [power port](./powerport.md) (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 one of the following statuses:
+## Fields
 
-* Offline
-* Active
-* Planned
-* Failed
+### Power Panel
 
-Each power feed also defines the electrical characteristics of the circuit which it represents. These include the following:
+The [power panel](./powerpanel.md) which supplies upstream power to this feed.
 
-* Supply type (AC or DC)
-* Phase (single or three-phase)
-* Voltage
-* Amperage
-* Maximum utilization (percentage)
+### Rack
+
+The [rack](./rack.md) within which this feed delivers power (optional).
+
+### Name
+
+The feed's name or other identifier. Must be unique to the assigned power panel.
+
+### Status
+
+The feed's operational status.
+
+!!! tip
+    Additional statuses may be defined by setting `PowerFeed.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
+
+### Type
+
+In redundant environments, each power feed can be designated as providing either primary or redundant power. (In environment with only one power source, all power feeds should be designated as primary.)
+
+### Mark Connected
+
+If selected, the power feed will be treated as if a cable has been connected.
+
+### Supply
+
+Electrical current type (AC or DC).
+
+### Voltage
+
+Operating circuit voltage, in volts.
+
+### Amperage
+
+Operation circuit amperage, in amperes.
+
+### Phase
+
+Indicates whether the circuit provides single- or three-phase power.
+
+### Max Utilization
+
+The maximum safe utilization of the feed, expressed as a percentage of the total available power. (Typically this will be set to around 80%, to avoid tripping a breaker during heaving spikes in current draw.)
 
 !!! 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.

docs/models/dcim/poweroutlet.md

@@ -4,6 +4,9 @@ Power outlets represent the outlets on a power distribution unit (PDU) or other
 
 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.
 
+!!! tip
+    Like most device components, power outlets are instantiated automatically from [power outlet templates](./poweroutlettemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/powerpanel.md

@@ -1,8 +1,20 @@
 # Power Panel
 
-A power panel represents the origin point in NetBox 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 site, and may optionally be assigned to a particular location within that site.
+A power panel represents the origin point in NetBox for electrical power being disseminated by one or more [power feeds](./powerfeed.md). 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.
 
 !!! note
     NetBox 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 NetBox.
+
+## Fields
+
+### Site
+
+The [site](./site.md) in which the power panel resides.
+
+### Location
+
+A specific [location](./location.md) within the assigned site where the power panel is installed.
+
+### Name
+
+The power panel's name. Must be unique to the assigned site.

docs/models/dcim/powerport.md

@@ -2,6 +2,9 @@
 
 A power port is a device component which draws power from some external source (e.g. an upstream [power outlet](./poweroutlet.md)), and generally represents a power supply internal to a device.
 
+!!! tip
+    Like most device components, power ports are instantiated automatically from [power port templates](./powerporttemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/rack.md

@@ -1,12 +1,51 @@
 # 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 site, and may optionally be assigned to a location and/or tenant. Racks can also be organized by user-defined functional roles. The name and facility ID of each rack within a location must be unique.
+The rack model represents a physical two- or four-post equipment rack in which [devices](./device.md) can be installed. Each rack must be assigned to a [site](./site.md), and may optionally be assigned to a [location](./location.md) within that site. Racks can also be organized by user-defined functional roles. The name and facility ID of each rack within a location must be unique.
 
 Rack height is measured in *rack units* (U); racks are commonly between 42U and 48U tall, but NetBox 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:
+## Fields
+
+### Site
+
+The [site](./site.md) to which the rack is assigned.
+
+### Location
+
+The [location](./location.md) within a site where the rack has been installed (optional).
+
+### Name
+
+The rack's name or identifier. Must be unique to the rack's location, if assigned.
+
+### Status
+
+Operational status.
+
+!!! tip
+    Additional statuses may be defined by setting `Rack.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
+
+### Role
+
+The functional [role](./rackrole.md) fulfilled by the rack.
+
+### Facility ID
+
+An alternative identifier assigned to the rack e.g. by the facility operator. This is helpful for tracking datacenter rack designations in a colocation facility.
+
+### Serial Number
+
+The unique physical serial number assigned to this rack.
+
+### Asset Tag
+
+A unique, locally-administered label used to identify hardware resources.
+
+### Type
+
+A rack can be designated as one of the following types:
 
 * 2-post frame
 * 4-post frame
@@ -14,12 +53,18 @@ A rack must be designated as one of the following types:
 * Wall-mounted frame
 * Wall-mounted cabinet
 
-Similarly, each rack must be assigned an operational status, which is one of the following:
+### Width
 
-* Reserved
-* Available
-* Planned
-* Active
-* Deprecated
+The canonical distance between the two vertical rails on a face. (This is typically 19 inches, however other standard widths exist.)
 
-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.
+### Height
+
+The height of the rack, measured in units.
+
+### Outer Dimensions
+
+The external width and depth of the rack can be tracked to aid in floorplan calculations. These measurements must be designated in either millimeters or inches.
+
+### Descending Units
+
+If selected, the rack's elevation will display unit 1 at the top of the rack. (Most racks use asceneding numbering, with unit 1 assigned to the bottommost position.)

docs/models/dcim/rackreservation.md

@@ -1,3 +1,21 @@
 # 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.
+Users can reserve specific units within a [rack](./rackreservation.md) 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.
+
+## Fields
+
+### Rack
+
+The [rack](./rack.md) being reserved.
+
+### Units
+
+The rack unit or units being reserved. Multiple units can be expressed using commas and/or hyphens. For example, `1,3,5-7` specifies units 1, 3, 5, 6, and 7.
+
+### User
+
+The NetBox user account associated with the reservation. Note that users with sufficient permission can make rack reservations for other users.
+
+### Description
+
+Every rack reservation must include a description of its purpose.

docs/models/dcim/rackrole.md

@@ -1,3 +1,17 @@
 # Rack Roles
 
-Each rack can optionally be assigned a user-defined functional role. For example, you might designate a rack for compute or storage resources, or to house colocated customer devices. Rack roles are fully customizable and may be color-coded.
+Each rack can optionally be assigned a user-defined functional role. For example, you might designate a rack for compute or storage resources, or to house colocated customer devices.
+
+## Fields
+
+### Name
+
+A unique human-friendly name.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Color
+
+The color used when displaying the role in the NetBox UI.

docs/models/dcim/rearport.md

@@ -5,6 +5,9 @@ Like [front ports](./frontport.md), rear ports are pass-through ports which repr
 !!! 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.
 
+!!! tip
+    Like most device components, rear ports are instantiated automatically from [rear port templates](./rearporttemplate.md) assigned to the selected device type when a device is created.
+
 ## Fields
 
 ### Device

docs/models/dcim/region.md

@@ -1,5 +1,17 @@
 # Regions
 
-Sites can be arranged geographically using regions. A region might represent a continent, country, city, campus, or other area depending on your use case. Regions can be nested recursively to construct a hierarchy. For example, you might define several country regions, and within each of those several state or city regions to which sites are assigned.
+[Sites](./site.md) can be arranged geographically using regions. A region might represent a continent, country, city, campus, or other area depending on your use case. Regions can be nested recursively to construct a hierarchy. For example, you might define several country regions, and within each of those several state or city regions to which sites are assigned.
 
-Each region must have a name that is unique within its parent region, if any.
+## Fields
+
+### Parent
+
+The parent region, if any.
+
+### Name
+
+The region's name. Must be unique to the parent region, if one is assigned.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)

docs/models/dcim/site.md

@@ -2,14 +2,50 @@
 
 How you choose to employ sites when modeling your network may vary depending on the nature of your organization, but generally a site will equate to a building or campus. For example, a chain of banks might create a site to represent each of its branches, a site for its corporate headquarters, and two additional sites for its presence in two colocation facilities.
 
-Each site must be assigned a unique name and may optionally be assigned to a region and/or tenant. The following operational statuses are available:
+## Fields
 
-* Planned
-* Staging
-* Active
-* Decommissioning
-* Retired
+### Name
 
-The site model also provides a facility ID field which can be used to annotate a facility ID (such as a datacenter name) associated with the site. Each site may also have an autonomous system (AS) number and time zone associated with it. (Time zones are provided by the [pytz](https://pypi.org/project/pytz/) package.)
+The site's unique name.
 
-The site model also includes several fields for storing contact and address information as well as geolocation data (GPS coordinates).
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)
+
+### Status
+
+The site's operational status.
+
+!!! tip
+    Additional statuses may be defined by setting `Site.status` under the [`FIELD_CHOICES`](../../configuration/data-validation.md#field_choices) configuration parameter.
+
+### Region
+
+The parent [region](./region.md) to which the site belongs, if any.
+
+### Facility
+
+Data center or facility designation for identifying the site.
+
+### ASNs
+
+Each site can have multiple [AS numbers](../ipam/asn.md) assigned to it.
+
+### Time Zone
+
+The site's local time zone. (Time zones are provided by the [pytz](https://pypi.org/project/pytz/) package.)
+
+### Physical Address
+
+The site's physical address, used for mapping.
+
+### Shipping Address
+
+The address to use for deliveries destined for the site.
+
+!!! tip
+    You can also designate [points of contact](../../features/contacts.md) for each site to provide additional contact details.
+
+### Latitude & Longitude
+
+GPS coordinates of the site for geolocation.

docs/models/dcim/sitegroup.md

@@ -1,5 +1,17 @@
 # Site Groups
 
-Like regions, site groups can be used to organize sites. Whereas regions are intended to provide geographic organization, site groups can be used to classify sites by role or function. Also like regions, site groups can be nested to form a hierarchy. Sites which belong to a child group are also considered to be members of any of its parent groups.
+Like [regions](./region.md), site groups can be used to organize [sites](./site.md). Whereas regions are intended to provide geographic organization, site groups can be used to classify sites by role or function. Also like regions, site groups can be nested to form a hierarchy. Sites which belong to a child group are also considered to be members of all its parent groups.
 
-Each site group must have a name that is unique within its parent group, if any.
+## Fields
+
+### Parent
+
+The parent site group, if any.
+
+### Name
+
+The site group's name. Must be unique to the parent group, if one is assigned.
+
+### Slug
+
+A unique URL-friendly identifier. (This value can be used for filtering.)

docs/models/dcim/virtualchassis.md

@@ -1,9 +1,22 @@
 # 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.
+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 managed device. 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.
 
-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, virtual interfaces, and other attributes related to managing the VC.
-If a VC master is defined, interfaces from all VC members are displayed when navigating to its device interfaces view. This does not include other members interfaces declared as management-only.
+One of the member devices may be designated as the VC master: This device will typically be assigned a name, services, virtual interfaces, and other attributes related to managing the VC.  If a VC master is defined, interfaces from all VC members are displayed when navigating to its device interfaces view. This does not include management-only interfaces belonging to other members.
 
 !!! 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.
+    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. Instead, use [modules](./module.md) for these.
+
+## Fields
+
+### Name
+
+The virtual chassis' name.
+
+### Domain
+
+The domain assigned for VC member devices.
+
+### Master
+
+The member device which has been designated as the chassis master (optional).