On 12/17/15 14:58, Susan Hares wrote:
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.
Thanks, Sue. We will work to have these done by tomorrow.
Joe
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
draft-ietf-i2rs-security-environment-reqs-00
<https://datatracker.ietf.org/doc/draft-ietf-i2rs-security-environment-reqs/>
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
