Update device type and component template documentation

docs/models/dcim/consoleporttemplate.md

@@ -1,3 +1,3 @@
 ## Console Port Templates
 
-A template for a console port that will be created on all instantiations of the parent device type.
+A template for a console port that will be created on all instantiations of the parent device type. Each console port can be assigned a physical type.

docs/models/dcim/consoleserverporttemplate.md

@@ -1,3 +1,3 @@
 ## Console Server Port Templates
 
-A template for a console server port that will be created on all instantiations of the parent device type.
+A template for a console server port that will be created on all instantiations of the parent device type. Each console server port can be assigned a physical type.

docs/models/dcim/devicetype.md

@@ -1,18 +1,14 @@
 # Device Types
 
-A device type represents a particular make and model of hardware that exists in the real world. Device types define the physical attributes of a device (rack height and depth) and its individual components (console, power, and network interfaces).
+A device type represents a particular make and model of hardware that exists in the real world. Device types define the physical attributes of a device (rack height and depth) and its individual components (console, power, network interfaces, and so on).
 
-Device types are instantiated as devices installed within 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 devices of this type named "switch1," "switch2," and so on. Each device will 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.)
+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 functional independently from one another. 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 in a device bay)
+* 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.
-
-    For that application you should create a single Device for the chassis, and add Interfaces directly to it.  Interfaces can be created in bulk using range patterns, e.g. "Gi1/[1-24]".
-
-    Add Inventory Items if you want to record the line cards themselves as separate entities.  There is no explicit relationship between each interface and its line card, but it may be implied by the naming (e.g. interfaces "Gi1/x" are on line card 1)
+    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 inventory items within a device, with any associated interfaces or other components assigned directly to the device.

docs/models/dcim/frontporttemplate.md

@@ -1,3 +1,3 @@
 ## Front Port Templates
 
-A template for a front-facing pass-through port that will be created on all instantiations of the parent device type.
+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.

docs/models/dcim/interfacetemplate.md

@@ -1,3 +1,3 @@
 ## Interface Templates
 
-A template for an interface that will be created on all instantiations of the parent device type.
+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."

docs/models/dcim/manufacturer.md

@@ -1,3 +1,3 @@
 # Manufacturers
 
-Each device type must be assigned to a manufacturer. The model number of a device type must be unique to its manufacturer.
+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.

docs/models/dcim/poweroutlettemplate.md

@@ -1,3 +1,3 @@
 ## Power Outlet Templates
 
-A template for a power outlet that will be created on all instantiations of the parent device type.
+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.

docs/models/dcim/powerporttemplate.md

@@ -1,3 +1,3 @@
 ## Power Port Templates
 
-A template for a power port that will be created on all instantiations of the parent device type.
+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.

docs/models/dcim/rearporttemplate.md

@@ -1,3 +1,3 @@
 ## Rear Port Templates
 
-A template for a rear-facing pass-through port that will be created on all instantiations of the parent device type.
+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 64).