[i2rs] Shepherd review of draft-ietf-i2rs-traceability-04.txt

["Susan Hares" <[e-mail]>]

Joe, Carlos, Gonzalo: 

 

The is a Shepherd’s review of your document.  

 

Status: Needs Minor Changes, mostly editorial. Details are below.  

 

Let me know if you have any questions.  If you could get to these minor editorial changes this week, I would like to see if I can get Directorate Reviews over the next 3 weeks. 

 

Sue Hares 

 

===============

 

Technical changes:

1)      Remove section 5.4 – I2RS trace Log Extensibility and Optional fields 

 

Reason: In the document it is a TBD. If we need to extend these we will revise the traceability requirements and framework.

2)      Section 7.4.2/&.4.3 uses section 6.7 for notification pub/sub 

 

The sections in the I2RS architecture document have changed. Please change this document. 

 

3)      Section 7.4.3 – the draft [I-D.camwinget-i2rs-pubsub-sec] is no longer active.   Please determine if this work is included in the  <https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/> draft-ietf-i2rs-security-environment-reqs-00  or draft-ietf-i2rs-protocol-security-requirements <https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements> . 

 

If not, please determine if changes can be made to these documents, or

If we need to re-investigate making draft-camwinget-i2rs-pubsub-sec document an I2RS document. 

 

Editorial changes: 

 

1:  Page 4.  

Lists in section 4 – I suggest for list below you use “;” instead of “.” for ease of reading and grammatical correctness. 

 

  o  Automated event correlation, trend analysis, and anomaly

      detection.

 

   o  Trace log storage for offline (manual or tools) analysis.

 

   o  Improved accounting of routing system operations.

 

   o  Standardized structured data format for writing common tools.

 

   o  Common reference for automated testing and incident reporting.

 

   o  Real-time monitoring and troubleshooting.

 

   o  Enhanced network audit, management and forensic analysis

      capabilities.

 

2) Section 5.1 paragraph 1

 

s/highlighted herein/ to / in this section./ 

 

3) Figure 1: 

 

  Operation +

                Op Data 

                  V  

 

The “V” seems to not lead anyplace.  Probably needs to be deleted or fixed. 

 

4: Section 5.2 

 

    Request Timestamp: 

      The specific time, adhering to [RFC3339 <https://tools.ietf.org/html/rfc3339> ] format,
      at which the I2RS operation was received by the Agent.
 
   Result Timestamp:   
      The specific time, adhering to [RFC3339] format,
      at which the I2RS operation was completed by the Agent.

 

Proposed fix: Alternate for both timestamps 

The specific time at which the I2RS operation was received by the Agent.  The time is passed in the [RFC3339] format.

 

 

5: Change the RIB-Info model to draft-ietf-i2rs-rib-info-model in the text below. 

 

      Result Code:   This field holds the result of the operation.  In the

      case of RIB operations, this MUST be the return code as specified

      in Section 4 of [I-D.nitinb-i2rs-rib-info-model].  The operation

      may not complete with a result code in the case of a timeout.  If

      the operation fails to complete, it MUST still log the attempted

      operation with an appropriate result code (e.g., a result code

      indicating a timeout).

 

6:  Section 7.2, p. 9  

From 

/Another noteworthy consideration is that Client requests may not always be processed synchronously or within a bounded time/ 

To: 

/ Client requests may not always be processed synchronously or within a bounded time/

 

7. Section 7.2, p. 10, first full paragraph 

From 

/Section 7.3 talks about rotating the trace log in order to/.

To 

/Section 7.3 discusses rotating the trace log in order to /