VNFRQTS - Updating requirements to new structure

Updating the requirements to use the newly developed RST directive
Removing Chapter 7 updates to see if build would work.

Change-Id: I43bffa2b6c0a15e6f2e179c00d39f4ee46c5a046
Issue-ID: VNFRQTS-245
Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>

1 files changed, 270 insertions, 128 deletions

diff --git a/docs/Chapter7/Monitoring-And-Management.rst b/docs/Chapter7/Monitoring-And-Management.rst
index a54671f..d8ec148 100644
--- a/docs/Chapter7/Monitoring-And-Management.rst
+++ b/docs/Chapter7/Monitoring-And-Management.rst
@@ -345,9 +345,15 @@ Monitoring & Management Requirements
 VNF telemetry via standardized interface
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-51910 The xNF **MUST** provide all telemetry (e.g., fault event
-  records, syslog records, performance records etc.) to ONAP using the
-  model, format and mechanisms described in this section.
+
+.. req::
+    :id: R-51910    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** provide all telemetry (e.g., fault event
+    records, syslog records, performance records etc.) to ONAP using the
+    model, format and mechanisms described in this section.
 
 Encoding and Serialization
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -357,33 +363,40 @@ Content delivered from VNFs to ONAP is to be encoded and serialized using JSON:
 JSON
 ~~~~~~~~~~~~~~~~~~
 
-* R-19624 The xNF **MUST** encode and serialize content delivered to
-  ONAP using JSON (RFC 7159) plain text format. High-volume data
-  is to be encoded and serialized using `Avro <http://avro.apache.org/>`_, where the Avro [1]_ data format are described using JSON.
-
-  Note:
-
-  - JSON plain text format is preferred for moderate volume data sets
-    (option 1), as JSON has the advantage of having well-understood simple
-    processing and being human-readable without additional decoding. Examples
-    of moderate volume data sets include the fault alarms and performance
-    alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
-  - Binary format using Avro is preferred for high volume data sets
-    (option 2) such as mobility flow measurements and other high-volume
-    streaming events (such as mobility signaling events or SIP signaling)
-    or bulk data, as this will significantly reduce the volume of data
-    to be transmitted. As of the date of this document, all events are
-    reported using plain text JSON and REST.
-  - Avro content is self-documented, using a JSON schema. The JSON schema is
-    delivered along with the data content
-    (http://avro.apache.org/docs/current/ ). This means the presence and
-    position of data fields can be recognized automatically, as well as the
-    data format, definition and other attributes. Avro content can be
-    serialized as JSON tagged text or as binary. In binary format, the
-    JSON schema is included as a separate data block, so the content is
-    not tagged, further compressing the volume. For streaming data, Avro
-    will read the schema when the stream is established and apply the
-    schema to the received content.
+
+.. req::
+    :id: R-19624    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** encode and serialize content delivered to
+    ONAP using JSON (RFC 7159) plain text format. High-volume data
+    is to be encoded and serialized using `Avro <http://avro.apache.org/>`_,
+    where the Avro [1]_ data format are described using JSON.
+
+    Note:
+
+        - JSON plain text format is preferred for moderate volume data sets
+          (option 1), as JSON has the advantage of having well-understood simple
+          processing and being human-readable without additional decoding. Examples
+          of moderate volume data sets include the fault alarms and performance
+          alerts, heartbeat messages, measurements used for xNF scaling and syslogs.
+        - Binary format using Avro is preferred for high volume data sets
+          (option 2) such as mobility flow measurements and other high-volume
+          streaming events (such as mobility signaling events or SIP signaling)
+          or bulk data, as this will significantly reduce the volume of data
+          to be transmitted. As of the date of this document, all events are
+          reported using plain text JSON and REST.
+        - Avro content is self-documented, using a JSON schema. The JSON schema is
+          delivered along with the data content
+          (http://avro.apache.org/docs/current/ ). This means the presence and
+          position of data fields can be recognized automatically, as well as the
+          data format, definition and other attributes. Avro content can be
+          serialized as JSON tagged text or as binary. In binary format, the
+          JSON schema is included as a separate data block, so the content is
+          not tagged, further compressing the volume. For streaming data, Avro
+          will read the schema when the stream is established and apply the
+          schema to the received content.
 
 In addition to the preferred method (JSON), content can be delivered
 from xNFs to ONAP can be encoded and serialized using Google Protocol
@@ -426,30 +439,37 @@ can be serialized in one of the following methods:
 Reporting Frequency
 ~~~~~~~~~~~~~~~~~~~~~
 
-* R-98191 The xNF **MUST** vary the frequency that asynchronous data
-  is delivered based on the content and how data may be aggregated or
-  grouped together.
-
-  Note:
-
-  - For example, alarms and alerts are expected to be delivered as
-    soon as they appear. In contrast, other content, such as
-    performance measurements, KPIs or reported network signaling may have
-    various ways of packaging and delivering content. Some content should
-    be streamed immediately; or content may be monitored over a time interval,
-    then packaged as collection of records and delivered as block; or data
-    may be collected until a package of a certain size has been collected;
-    or content may be summarized statistically over a time interval, or
-    computed as a KPI, with the summary or KPI being delivered.
-  - We expect the reporting frequency to be configurable depending
-    on the virtual network function’s needs for management. For example,
-    Service Provider may choose to vary the frequency of collection between
-    normal and trouble-shooting scenarios.
-  - Decisions about the frequency of data reporting will affect the
-    size of delivered data sets, recommended delivery method, and how the
-    data will be interpreted by ONAP. These considerations should not
-    affect deserialization and decoding of the data, which will be guided
-    by the accompanying JSON schema or GPB definition files.
+.. req::
+    :id: R-98191    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** vary the frequency that asynchronous data
+    is delivered based on the content and how data may be aggregated or
+    grouped together.
+
+        Note:
+
+        - For example, alarms and alerts are expected to be delivered as
+          soon as they appear. In contrast, other content, such as performance
+          measurements, KPIs or reported network signaling may have various
+          ways of packaging and delivering content. Some content should be
+          streamed immediately; or content may be monitored over a time
+          interval, then packaged as collection of records and delivered
+          as block; or data may be collected until a package of a certain
+          size has been collected; or content may be summarized statistically
+          over a time interval, or computed as a KPI, with the summary or KPI
+          being delivered.
+        - We expect the reporting frequency to be configurable depending on
+          the virtual network functions needs for management. For example,
+          Service Provider may choose to vary the frequency of collection
+          between normal and trouble-shooting scenarios.
+        - Decisions about the frequency of data reporting will affect
+          the size of delivered data sets, recommended delivery method,
+          and how the data will be interpreted by ONAP. These considerations
+          should not affect deserialization and decoding of the data, which
+          will be guided by the accompanying JSON schema or GPB definition
+          files.
 
 Addressing and Delivery Protocol
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -459,87 +479,210 @@ data sets may also be addressed by host name and port number for TCP
 streaming, or by host name and landing zone directory for SFTP transfer
 of bulk files.
 
-* R-88482 The xNF **SHOULD** use REST using HTTPS delivery of plain
-  text JSON for moderate sized asynchronous data sets, and for high
-  volume data sets when feasible.
-* R-84879 The xNF **MUST** have the capability of maintaining a primary
-  and backup DNS name (URL) for connecting to ONAP collectors, with the
-  ability to switch between addresses based on conditions defined by policy
-  such as time-outs, and buffering to store messages until they can be
-  delivered. At its discretion, the service provider may choose to populate
-  only one collector address for a xNF. In this case, the network will
-  promptly resolve connectivity problems caused by a collector or network
-  failure transparently to the xNF.
-* R-81777 The xNF **MUST** be configured with initial address(es) to use
-  at deployment time. Subsequently, address(es) may be changed through
-  ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
-  RESTful API, in the same manner that other controls over data reporting
-  will be controlled by policy.
-* R-08312 The xNF **MAY** use another option which is expected to include REST
-  delivery of binary encoded data sets.
-* R-79412 The xNF **MAY** use another option which is expected to include TCP
-  for high volume streaming asynchronous data sets and for other high volume
-  data sets. TCP delivery can be used for either JSON or binary encoded data
-  sets.
-* R-01033 The xNF **MAY** use another option which is expected to include SFTP
-  for asynchronous bulk files, such as bulk files that contain large volumes of
-  data collected over a long time interval or data collected across many xNFs.
-  (Preferred is to reorganize the data into more frequent or more focused data
-  sets, and deliver these by REST or TCP as appropriate.)
-* R-63229 The xNF **MAY** use another option which is expected to include REST
-  for synchronous data, using RESTCONF (e.g., for xNF state polling).
-* R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
-  as data destinations for each xNF, and may be changed by Policy while
-  the xNF is in operation. We expect the xNF to be capable of redirecting
-  traffic to changed destinations with no loss of data, for example from
-  one REST URL to another, or from one TCP host and port to another.
+.. req::
+    :id: R-88482    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use REST using HTTPS delivery of plain
+    text JSON for moderate sized asynchronous data sets, and for high
+    volume data sets when feasible.
+
+.. req::
+    :id: R-84879    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** have the capability of maintaining a primary
+    and backup DNS name (URL) for connecting to ONAP collectors, with the
+    ability to switch between addresses based on conditions defined by policy
+    such as time-outs, and buffering to store messages until they can be
+    delivered. At its discretion, the service provider may choose to populate
+    only one collector address for a xNF. In this case, the network will
+    promptly resolve connectivity problems caused by a collector or network
+    failure transparently to the xNF.
+
+.. req::
+    :id: R-81777    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** be configured with initial address(es) to use
+    at deployment time. Subsequently, address(es) may be changed through
+    ONAP-defined policies delivered from ONAP to the xNF using PUTs to a
+    RESTful API, in the same manner that other controls over data reporting
+    will be controlled by policy.
+
+.. req::
+    :id: R-08312    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include REST
+    delivery of binary encoded data sets.
+
+.. req::
+    :id: R-79412    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include TCP
+    for high volume streaming asynchronous data sets and for other high volume
+    data sets. TCP delivery can be used for either JSON or binary encoded data
+    sets.
+
+.. req::
+    :id: R-01033    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include SFTP
+    for asynchronous bulk files, such as bulk files that contain large volumes
+    of data collected over a long time interval or data collected across many
+    xNFs. (Preferred is to reorganize the data into more frequent or more focused
+    data sets, and deliver these by REST or TCP as appropriate.)
+
+.. req::
+    :id: R-63229    
+    :target: XNF
+    :keyword: MAY
+
+    The xNF **MAY** use another option which is expected to include REST
+    for synchronous data, using RESTCONF (e.g., for xNF state polling).
+
+.. req::
+    :id: R-03070    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST**, by ONAP Policy, provide the ONAP addresses
+    as data destinations for each xNF, and may be changed by Policy while
+    the xNF is in operation. We expect the xNF to be capable of redirecting
+    traffic to changed destinations with no loss of data, for example from
+    one REST URL to another, or from one TCP host and port to another.
 
 Asynchronous and Synchronous Data Delivery
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-* R-06924 The xNF **MUST** deliver asynchronous data as data becomes
-  available, or according to the configured frequency.
-* R-73285 The xNF **MUST** must encode, address and deliver the data
-  as described in the previous paragraphs.
-* R-42140 The xNF **MUST** respond to data requests from ONAP as soon
-  as those requests are received, as a synchronous response.
-* R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by
-  the ONAP configuration subsystem for synchronous communication.
-* R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF
-  [RFC8040] (https://tools.ietf.org/html/rfc8040).
-* R-11240 The xNF **MUST** respond with content encoded in JSON, as
-  described in the RESTCONF specification. This way the encoding of a
-  synchronous communication will be consistent with Avro.
-* R-70266 The xNF **MUST** respond to an ONAP request to deliver the
-  current data for any of the record types defined in
-  `Event Records - Data Structure Description`_ by returning the requested
-  record, populated with the current field values. (Currently the defined
-  record types include fault fields, mobile flow fields, measurements for
-  xNF scaling fields, and syslog fields. Other record types will be added
-  in the future as they become standardized and are made available.)
-* R-46290 The xNF **MUST** respond to an ONAP request to deliver granular
-  data on device or subsystem status or performance, referencing the YANG
-  configuration model for the xNF by returning the requested data elements.
-* R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG
-  <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
-  translated to and from JSON{RFC7951]. YANG configuration and content can
-  be represented via JSON, consistent with Avro, as described in “Encoding
-  and Serialization” section.
+.. req::
+    :id: R-06924    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** deliver asynchronous data as data becomes
+    available, or according to the configured frequency.
+
+.. req::
+    :id: R-73285    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** must encode, address and deliver the data
+    as described in the previous paragraphs.
+
+.. req::
+    :id: R-42140    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to data requests from ONAP as soon
+    as those requests are received, as a synchronous response.
+
+.. req::
+    :id: R-34660    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** use the RESTCONF/NETCONF framework used by
+    the ONAP configuration subsystem for synchronous communication.
+
+.. req::
+    :id: R-86586    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** use the YANG configuration models and RESTCONF
+    [RFC8040] (https://tools.ietf.org/html/rfc8040).
+
+.. req::
+    :id: R-11240    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond with content encoded in JSON, as
+    described in the RESTCONF specification. This way the encoding of a
+    synchronous communication will be consistent with Avro.
+
+.. req::
+    :id: R-70266    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to an ONAP request to deliver the
+    current data for any of the record types defined in
+    `Event Records - Data Structure Description`_ by returning the requested
+    record, populated with the current field values. (Currently the defined
+    record types include fault fields, mobile flow fields, measurements for
+    xNF scaling fields, and syslog fields. Other record types will be added
+    in the future as they become standardized and are made available.)
+
+.. req::
+    :id: R-46290    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** respond to an ONAP request to deliver granular
+    data on device or subsystem status or performance, referencing the YANG
+    configuration model for the xNF by returning the requested data elements.
+
+.. req::
+    :id: R-43327    
+    :target: XNF
+    :keyword: SHOULD
+
+    The xNF **SHOULD** use `Modeling JSON text with YANG
+    <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
+    translated to and from JSON{RFC7951]. YANG configuration and content can
+    be represented via JSON, consistent with Avro, as described in "Encoding
+    and Serialization" section.
 
 Security
 ~~~~~~~~~~
 
-* R-42366 The xNF **MUST** support secure connections and transports such as
-  Transport Layer Security (TLS) protocol
-  [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
-  the best current practices outlined in
-  `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
-* R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation
-  of connections, through secure credentials, log-on and exchange mechanisms.
-* R-47597 The xNF **MUST** carry data in motion only over secure connections.
-* R-68165 The xNF **MUST** encrypt any content containing Sensitive Personal
-  Information (SPI) or certain proprietary data, in addition to applying the
-  regular procedures for securing access and delivery.
+.. req::
+    :id: R-42366    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** support secure connections and transports such as
+    Transport Layer Security (TLS) protocol
+    [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
+    the best current practices outlined in
+    `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
+
+.. req::
+    :id: R-44290    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** control access to ONAP and to xNFs, and creation
+    of connections, through secure credentials, log-on and exchange mechanisms.
+
+.. req::
+    :id: R-47597    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** carry data in motion only over secure connections.
+
+.. req::
+    :id: R-68165    
+    :target: XNF
+    :keyword: MUST
+
+    The xNF **MUST** encrypt any content containing Sensitive Personal
+    Information (SPI) or certain proprietary data, in addition to applying the
+    regular procedures for securing access and delivery.
 
 .. [1]
    This option is not currently supported in ONAP and it is currently
@@ -560,4 +703,3 @@ Security
 .. |image3| image:: Protocol_Buffers_Driven_Model.png
       :width: 4.74in
       :height: 3.3in
-