review comment updates

docs/content/learn/tutorials/component/_index.md

@@ -20,7 +20,7 @@ This tutorial covers creating a basic OSCAL component definition. Before reading
 
 A component definition describes how a given implementation of a component or sets of components (e.g., hardware, software, service, policy, process, or procedure) can support specific controls.  Product and Service Vendors, Capability Owners, Policy and Process Owners, and others can create component definitions that readily serve as inputs for a System Security Plan (SSP), helping describe how components might satisfy controls.  It is important to note that component definitions do not describe actual implementations. Component definitions serve as references with content that can be used (e.g., in the SSP OSCAL model) to develop comprehensive and consistent control implementations within an SSP.
 
-In this tutorial, we will walk through the process of creating an [OSCAL component definition model](/documentation/schema/implementation-layer/component/) for MongoDB.  Our goal is to provide standard control implementations for the benefit of system owners and SSP authors. As potential components in systems that may need to meet the OMB A-130 Authorization to Operate requirements, the component definition in this tutorial will demonstrate proper implementation of a couple [NIST SP 800-53 rev 5 controls](https://github.com/usnistgov/oscal-content/tree/master/nist.gov/SP800-53/rev5/xml) deemed necessary for high / moderate / low impact systems. While this example focuses on NIST controls, the same approach could be used for any cybersecurity frameworks and their respective controls.  We'll presume the MongoDB component can partially or fully satisfy the following controls:
+In this tutorial, we will walk through the process of creating an [OSCAL component definition model](/documentation/schema/implementation-layer/component/) for [MongoDB](https://docs.mongodb.com/).  Our goal is to provide standard control implementations for the benefit of system owners and SSP authors. As potential components in systems that may need to meet the OMB A-130 Authorization to Operate requirements, the component definition in this tutorial will demonstrate proper implementation of a couple [NIST SP 800-53 rev 5 controls](https://github.com/usnistgov/oscal-content/tree/master/nist.gov/SP800-53/rev5/xml) deemed necessary for high / moderate / low impact systems. While this example focuses on NIST controls, the same approach could be used for any cybersecurity frameworks and their respective controls.  We'll presume the MongoDB component can partially or fully satisfy the following controls:
 
 | NIST 800-53 rev5 Control | Description |
 | -------- | -------- |
@@ -105,7 +105,7 @@ A `component-definition` contains:
 
 For simplicity of this tutorial, we will only discuss certain data structures in the sections that follow and identify how they can be used to represent our component definition.
 
-## Defining the Component Definition’s Metadata
+### Defining the Component Definition’s Metadata
 
 Most OSCAL models have a standard metadata syntax, therefore, this is not covered extensively in this tutorial.  There are a few considerations however when authoring metadata for a component definition, such as the `<role>`, `<location>`, and `<party>` elements illustrated in lines 9-18 below.
 
@@ -137,7 +137,7 @@ Most OSCAL models have a standard metadata syntax, therefore, this is not covere
 
 The `<role>` element defines a function assumed or expected to be assumed by a party in a specific situation.  Common examples include [component definition authors](/documentation/schema/implementation-layer/component/#component-definition-authors) (e.g., Product and Service Vendors, Capability Owners, Policy and Process Owners, Standards Bodies and Validation Bodies) and [component definition consumers](/documentation/schema/implementation-layer/component/#component-definition-consumers) (e.g., System Owners and SSP Authors).  This element has a required `@id` attribute which expects an [NCName data type](/documentation/schema/datatypes/#ncname).  The `<location>` element can be used to associate the metadata with a location, including physical addresses and urls.  The `<location>` element has a `@uuid` attribute which requires a UUID.  Lastly, the `<party>` element represents either a person or organization that serves as the responsible entity.  There are prescribed types, including *"prepared-for"*, *"prepared-by"*, and *"approved-by"*.
 
-## Component
+### Component
 
 Within the component definition model, components provide a way to describe parts of an information system and the associated potential control implementations that could be established when the system is implemented.  Components are optional, but this tutorial will demonstrate their use.  In this example, we'll demonstrate how a MongoDB software component is described within an OSCAL component definition model. The snippet below provides an example of the minimum data needed to define a component.
 
@@ -171,7 +171,7 @@ The optional `<responsible-role>` element can be used to reference one or more r
 {{% /tab %}}
 {{< /tabs >}}
 
-## Protocol
+### Protocol
 
 Another optional but valuable sub-element of `<component>` is `<protocol>`.  Generally, `<protocol>` elements are only applicable when dealing with a `<component>` of type *"service"*.  In our example, we'll assume that installations of MongoDB will result in an installation of mongod (Mongo Daemon) which runs the MongoDB database as a process and uses the following protocols:
 
@@ -207,7 +207,7 @@ The `<protocol>` element has a mandatory `@name` attribute.  In this example, we
 {{% /tab %}}
 {{< /tabs >}}
 
-## Control-Implementations
+### Control-Implementations
 
 The control implementations help define how the component can satisfy controls.  In this example, we document how MongoDB component may satisfy SC-8(1) which requires implementation of cryptographic mechanisms to prevent unauthorized disclosure of information and/or detect changes to information during transmission. To document this, we use the `<control-implementation>` element.  This element requires a unique identifier, which is provided using the `@uuid` attribute.  This element also has a `@source` attribute that is used to provide a URI reference to the appropriate OSCAL profile.  The URI reference can be either a URI or a relative reference.  The `<implemented-requirement>` element on line 12 is where we can specify the control (e.g., SC-8(1)) and the implementation description.  The `<implemented-requirement>` element also has its own unique identifier `@uuid`, and the control is specified in the `@control-id` attribute on line 14.  We then use the `<description>` element to describe how this component satisfies the specified control.
 
@@ -244,7 +244,7 @@ In the example above, we demonstrated how to use OSCAL to document the MongoDB s
 
 ## The Final Component Definition
 
-Combining all the content described in this tutorial, we can produce this final component definition model.  Having these implementation details readily available in an OSCAL component definition means they can be referenced in an OSCAL SSP and should give SSP authors helpful content for their control implementation statements.
+Combining all the content described in this tutorial, we can produce this final component definition model.  Provided below is a well-formed XML example.  Having these implementation details readily available in an OSCAL component definition means they can be used to populate an OSCAL SSP and should give SSP authors helpful content for their control implementation statements.
 
 {{< tabs XML >}}
 {{% tab %}}