Joe: It would be helpful to get it done by tomorrow. Jonathan Hardwick is out looking for reviewers for this document. Our steps after the shepherd's review are: 1) RTG-Directorate review, 2) Any revision based on the RTG-Directorate, 3) Send for publication.
I will be uploading the shepherds report tonight. I think I have everything we need. Sue -----Original Message----- From: Joe Clarke [mailto:[email protected]] Sent: Thursday, December 17, 2015 3:09 PM To: Susan Hares; [email protected]; [email protected] Cc: 'Carlos Pignataro (cpignata)'; 'Gonzalo Salgueiro (gsalguei)' Subject: Re: Shepherd review of draft-ietf-i2rs-traceability-04.txt 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
