Continued work on feature docs

docs/features/facilities.md

@@ -40,19 +40,19 @@ Like regions, site groups can be arranged in a recursive hierarchy for grouping
 
 The use of both regions and site groups affords to independent but complementary dimensions across which sites can be organized.
 
-## Site
+## Sites
 
 A site typically represents a building within a region and/or site group. Each site is assigned an operational status (e.g. active or planned), and can have a discrete mailing address and GPS coordinates assigned to it.
 
-## Location
+## Locations
 
 A location can be any logical subdivision within a building, such as a floor or room. Like regions and site groups, locations can be nested into a self-recursive hierarchy for maximum flexibility. And like sites, each location has an operational status assigned to it.
 
-## Rack
+## Racks
 
 Finally, NetBox models each equipment rack as a discrete object within a site and location. These are physical objects into which devices are installed. Each rack can be assigned an operational status, type, facility ID, and other attributes related to inventory tracking. Each rack also must define a height (in rack units) and width, and may optionally specify its physical dimensions.
 
-Each rack must be associated to a site, but the assignment to a location within that site is optional. Users can also create custom roles to which racks can be assigned.
+Each rack must be associated to a site, but the assignment to a location within that site is optional. Users can also create custom roles to which racks can be assigned. NetBox supports tracking rack space in half-unit increments, so it's possible to mount devices at e.g. position 2.5 within a rack.
 
 !!! tip "Devices"
     You'll notice in the diagram above that a device can be installed within a site, location, or rack. This approach affords plenty of flexibility as not all sites need to define child locations, and not all devices reside in racks.

docs/features/ipam.md

@@ -1,3 +1,56 @@
 # IP Address Management
 
-TODO
+IP address management (IPAM) is one of NetBox's core features. It supports full parity for IP4 and IPv6, advanced VRF assignment, automatic hierarchy formation, and much more.
+
+## IP Hierarchy
+
+NetBox employs several object types to represent a hierarchy of IP resources:
+
+* **Aggregate** - A prefix which represents the root of an addressing hierarchy. This is typically a large swath of public or private address space allocated for use by your organization. Each aggregate is assigned to an authoritative RIR.
+* **Prefix** - A subnet defined within an aggregate. Prefixes extend the hierarchy by nesting within one another. (For example, 192.168.123.0/24 will appear within 192.168.0.0/16.) Each prefix can be assigned a functional role as well as an operational status.
+* **IP Range** - An arbitrary range of individual IP addresses within a prefix, all sharing the same mask. Ranges are commonly affiliated with DHCP scopes, but can be used for any similar purpose.
+* **IP Address** - An individual IP address along with its subnet mask, automatically arranged beneath its parent prefix.
+
+```mermaid
+flowchart TD
+    RIR --> Aggregate
+    Aggregate & Role --> Prefix
+    Prefix --> Prefix
+    Prefix --> IPRange & IPAddress
+```
+    
+!!! tip "Automatic Hierarchies"
+    IP objects in NetBox never need to be manually assigned to the parent objects. The construction of hierarchies is handled automatically by the application according to the inherent rules of IP addressing.
+
+An example hierarchy might look like this:
+
+* 100.64.0.0/10 (aggregate)
+    * 100.64.0.0/20 (prefix)
+    * 100.64.16.0/20 (prefix)
+        * 100.64.16.0/24 (prefix)
+            * 100.64.16.1/24 (address)
+            * 100.64.16.2/24 (address)
+            * 100.64.16.3/24 (address)
+        * 100.64.16.9/24 (prefix)
+    * 100.64.32.0/20 (prefix)
+        * 100.64.32.1/24 (address)
+        * 100.64.32.10-99/24 (range)
+
+## Utilization Stats
+
+The utilization rate for each prefix is calculated automatically depending on its status. _Container_ prefixes are those which house child prefixes; their utilization rate is determined based on how much of their available IP space is consumed by child prefixes. The utilization rate for any other type of prefix is determined by the aggregate usage of any child IP addresses and/or ranges defined.
+
+Similarly, utilization rates for aggregates is determined based on the space consumed by their child prefixes.
+
+## VRF Tracking
+
+NetBox supports the modeling of discrete virtual routing and forwarding (VRF) instances to represent multiple routing tables, including those with overlapping address space. Each type of IP object within an aggregate - prefix, IP range, and IP address - can be assigned to a particular VRF. Consequently, each VRF maintains its own isolated IP hierarchy. This makes it very easy to track overlapping IP space.
+
+VRF modeling in NetBox very closely follows what you find in real-world network configurations, with each VRF assigned a standards-compliant route distinguisher. You can even create route targets to manage the import and export of routing information among VRFs.
+
+!!! tip "Enforcing Unique IP Space"
+    Each VRF can be independently configured to permit or prohibit duplicate IP objects. For example, a VRF which has been configured to enforce unique IP space will not allow the creation of two 192.0.2.0/24 prefixes. The ability to toggle this restriction per VRF affords the user maximum flexibility in modeling their IP space.
+
+## AS Numbers
+
+An often overlooked component of IPAM, NetBox also tracks autonomous system (AS) numbers and their assignment to sites. Both 16- and 32-bit AS numbers are supported, and like aggregates each ASN is assigned to an authoritative RIR.

docs/features/power-tracking.md

@@ -1,3 +1,20 @@
 # Power Tracking
 
-TODO
+As part of its DCIM feature set, NetBox supports modeling facility power as discrete power panels and feeds. These are most commonly used to document power distribution within a data center, but can serve more traditional environments as well.
+
+![Power distribution model](../media/power_distribution.png)
+
+## Power Panels
+
+A power panel is the furthest upstream power element modeled in NetBox. It typically represents a power distribution panel (or breaker panel) where facility power is split into multiple discrete circuits, which are modeled as feeds.
+
+Each power panel is associated with a site, and may optionally be associated with a particular location within that site. There is no limit to how many power feeds a single panel can supply, however both of these object types should map to real-world objects.
+
+## Power Feeds
+
+A power feed represents a discrete power circuit originating from an upstream power panel. Each power feed can be assigned a name, operational status, and various electrical characteristics such as supply (AC or DC), voltage, amperage, and so on.
+
+A device power port can be connected to a power feed via a cable. Only one port can be connected to a feed: Where multiple devices draw power from the same feed, a power distribution unit (PDU) must be modeled as an individual device mapping a power port to multiple power outlets to which the downstream devices can connect (as in the example above).
+
+!!! tip "Primary and Redundant Power"
+    Each power feed in NetBox is assigned a type: primary or redundant. This allows easily modeling redundant power distribution topologies. In scenarios involving only a single, non-redundant power supply, mark all power feeds as primary.