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 /
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
