Started on feature docs

docs/features/contacts.md

@@ -1,3 +1,24 @@
 # Contacts
 
-TODO
+Much like [tenancy](./tenancy.md), contact assignment enables you to track ownership of resources modeled in NetBox. A contact represents an individual responsible for a resource within the context of its assigned role.
+
+```mermaid
+flowchart TD
+    ContactGroup --> ContactGroup & Contact
+    ContactRole & Contact --> assignment([Assignment])
+    assignment --> Object
+```
+
+## Contact Groups
+
+Contacts can be grouped arbitrarily into a recursive hierarchy, and a contact can be assigned to a group at any level within the hierarchy.
+
+## Contact Roles
+
+A contact role defines the relationship of a contact to an assigned object. For example, you might define roles for administrative, operational, and emergency contacts.
+
+## Contacts
+
+A contact should represent an individual or permanent point of contact. Each contact must define a name, and may optionally include a title, phone number, email address, and related details.
+
+Contacts are reused for assignments, so each unique contact must be created only once and can be assigned to any number of NetBox objects, and there is no limit to the number of assigned contacts an object may have. Most core objects in NetBox can have contacts assigned to them.

docs/features/devices-cabling.md

@@ -1,3 +1,79 @@
 # Devices & Cabling
 
-TODO
+At its heart, NetBox is a tool for modeling your network infrastructure, and the device object is pivotal to that function. A device can be any piece of physical hardware installed within your network, such as server, router, or switch, and may optionally be mounted within a rack. Within each device, resources such as network interfaces and console ports are modeled as discrete components, which may optionally be grouped into modules.
+
+NetBox uses device types to represent unique real-world device models. This allows a user to define a device type and all its components once, and easily replicate an unlimited number of device instances from it.
+
+```mermaid
+flowchart TD
+    Manufacturer -.-> Platform & DeviceType & ModuleType
+    Manufacturer --> DeviceType & ModuleType
+    DeviceRole & Platform & DeviceType --> Device
+    Device & ModuleType ---> Module
+    Device & Module --> Interface & ConsolePort & PowerPort & ...
+```
+
+## Manufacturers
+
+A manufacturer generally represents an organization which produces hardware devices. These can be defined by users, however they should represent an actual entity rather than some abstract idea.
+
+## Device Types
+
+A device type represents a unique combination of manufacturer and hardware model which maps to discrete make and model of device which exists in the real world. Each device type typically has a number of components created on it, representing network interfaces, device bays, and so on. New devices of this type can then be created in NetBox, and any associated components will be automatically replicated from the device type. This avoids needing to tediously recreate components for each device as it is added in NetBox.
+
+!!! tip "The Device Type Library"
+    While users are always free to create their own device types in NetBox, many find it convenient to draw from our [community library](https://github.com/netbox-community/devicetype-library) of pre-defined device types. This is possible because a particular make and model of device is applicable universally and never changes.
+
+All the following can be modeled as components:
+
+* Interfaces
+* Console ports
+* Console server ports
+* Power ports
+* Power outlets
+* Pass-through ports (front and rear)
+* Module bays (which house modules)
+* Device bays (which house child devices)
+
+For example, a Juniper EX4300-48T device type might have the following component templates defined:
+
+* One template for a console port ("Console")
+* Two templates for power ports ("PSU0" and "PSU1")
+* 48 templates for 1GE interfaces ("ge-0/0/0" through "ge-0/0/47")
+* Four templates for 10GE interfaces ("xe-0/2/0" through "xe-0/2/3")
+
+Once component templates have been created, every new device that you create as an instance of this type will automatically be assigned each of the components listed above.
+
+!!! note "Component Instantiation is not Retroactive"
+    The instantiation of components from a device type definition occurs only at the time of device creation. If you modify the components assigned to a device type, it will not affect devices which have already been created. This guards against any inadvertent changes to existing devices. However, you always have the option of adding, modifying, or deleting components on existing devices. (These changes can easily be applied to multiple devices at once using the bulk operations available in the UI.)
+
+## Devices
+
+Whereas a device type defines the make and model of a device, a device itself represents an actual piece of installed hardware somewhere in the real world. A device can be installed at a particular position within an equipment rack, or simply associated with a site (and optionally with a location within that site).
+
+Each device can have an operational status, functional role, and software platform assigned. Device components are instantiated automatically from the assigned device type upon creation.
+
+### Virtual Chassis
+
+Sometimes it is necessary to model a set of physical devices as sharing a single management plane. Perhaps the most common example of such a scenario is stackable switches. These can be modeled as virtual chassis in NetBox, with one device acting as the chassis master and the rest as members. All components of member devices will appear on the master.
+
+## Module Types & Modules
+
+Much like device types and devices, module types can instantiate discrete modules, which are hardware components installed within devices. Modules often have their own child components, which become available to the parent device. For example, when modeling a chassis-based switch with multiple line cards in NetBox, the chassis would be created (from a device type) as a device, and each of its line cards would be instantiated from a module type as a module installed in one of the device's module bays.
+
+!!! tip "Device Bays vs. Module Bays"
+    What's the difference between device bays and module bays? Device bays are appropriate when the installed hardware has its own management plane, isolated from the parent device. A common example is a blade server chassis in which the blades share power but operate independently. In contrast, a module bay holds a module which does _not_ operate independently of its parent device, as with the chassis switch line card example mentioned above.
+
+One especially nice feature of modules is that templated components can be automatically renamed according to the module bay into which the parent module is installed. For example, if we create a module type with interfaces named `Gi{module}/0/1-48` and install a module of this type into module bay 7 of a device, NetBox will create interfaces named `Gi7/0/1-48`.
+
+## Cables
+
+NetBox models cables as connections among certain types of device components and other objects. Each cable can be assigned a type, color, length, and label. NetBox will enforce basic sanity checks to prevent invalid connections. (For example, a network interface cannot be connected to a power outlet.)
+
+Either end of a cable may terminate to multiple objects of the same type. For example, a network interface can be connected via a fiber optic cable to two discrete ports on a patch panel (each port attaching to an individual fiber strand in the patch cable).
+
+```mermaid
+flowchart LR
+    Interface --> Cable
+    Cable --> fp1[Front Port] & fp2[Front Port]
+```

docs/features/facilities.md

@@ -1,3 +1,58 @@
 # Facilities
 
-TODO
+From global regions down to individual equipment racks, NetBox allows you to model your network's entire presence. This is accomplished through the use of several purpose-built models. The graph below illustrates these models and their relationships.
+
+```mermaid
+flowchart TD
+    Region --> Region
+    SiteGroup --> SiteGroup
+    Region & SiteGroup --> Site
+    Site --> Location & Device
+    Location --> Location
+    Location --> Rack & Device
+    Rack --> Device
+    Site --> Rack
+    RackRole --> Rack
+```
+
+## Regions
+
+Regions represent geographic domains in which your network or its customers have a presence. These are typically used to model countries, states, and cities, although NetBox does not prescribe any precise uses and your needs may differ.
+
+Regions are self-nesting, so you can define child regions within a parent, and grandchildren within each child. For example, you might create a hierarchy like this:
+
+* Europe
+    * France
+    * Germany
+    * Spain
+* North America
+    * Canada
+    * United States
+        * California
+        * New York
+        * Texas
+
+Regions will always be listed alphabetically by name within each parent, and there is no maximum depth for the hierarchy.
+
+## Site Groups
+
+Like regions, site groups can be arranged in a recursive hierarchy for grouping sites. However, whereas regions are intended for geographic organization, site groups may be used for functional grouping. For example, you might classify sites as corporate, branch, or customer sites in addition to where they are physically located.
+
+The use of both regions and site groups affords to independent but complementary dimensions across which sites can be organized.
+
+## Site
+
+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
+
+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
+
+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.
+
+!!! 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/tenancy.md

@@ -1,3 +1,19 @@
 # Tenancy
 
-TODO
+Most core objects within NetBox's data model support _tenancy_. This is the association of an object with a particular tenant to convey ownership or dependency. For example, an enterprise might represent its internal business units as tenants, whereas a managed services provider might create a tenant in NetBox to represent each of its customers.
+
+```mermaid
+flowchart TD
+    TenantGroup --> TenantGroup & Tenant
+    Tenant --> Site & Device & Prefix & Circuit & ...
+```
+
+## Tenant Groups
+
+Tenants can be grouped by any logic that your use case demands, and groups can nested recursively for maximum flexibility. For example, You might define a parent "Customers" group with child groups "Current" and "Past" within it. A tenant can be assigned to a group at any level within the hierarchy.
+
+## Tenants
+
+Typically, the tenant model is used to represent a customer or internal organization, however it can be used for whatever purpose meets your needs.
+
+Most core objects within NetBox can be assigned to particular tenant, so this model provides a very convenient way to correlate ownership across object types. For example, each of your customers might have its own racks, devices, IP addresses, circuits and so on: These can all be easily tracked via tenant assignment.