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

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

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:[e-mail]] 
Sent: Thursday, December 17, 2015 3:09 PM
To: Susan Hares; [e-mail]; [e-mail]
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/
>