Skip to main content

Last Call Review of draft-ietf-i2rs-traceability-09

Request Review of draft-ietf-i2rs-traceability
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-29
Requested 2016-04-18
Authors Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro
I-D last updated 2016-05-05
Completed reviews Genart Last Call review of -09 by Elwyn B. Davies (diff)
Genart Last Call review of -08 by Elwyn B. Davies (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Opsdir Last Call review of -08 by Menachem Dodge (diff)
Rtgdir Early review of -06 by Mach Chen (diff)
Rtgdir Early review of -06 by Les Ginsberg (diff)
Assignment Reviewer Elwyn B. Davies
State Completed
Review review-ietf-i2rs-traceability-09-genart-lc-davies-2016-05-05
Reviewed revision 09 (document currently at 11)
Result Not ready
Completed 2016-05-05
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-i2rs-traceability-09.txt
Reviewer: Elwyn Davies
Review Date: 2016/05/05
IETF LC End Date: 2016/04/29
IESG Telechat date: 2016/05/05


I have concerns about the trace model used as explained below.  It may 

be that there is good reason and WG consensus for the model adopted, but 

it would be good to see some explanation of the rather curious hybrid 

model used.  There are also significant issues with the description of 

timestamps and a number of other nits/editorial matters to address.

Apologies for the last minute delivery.

Possibly Major issues:

Trace model:  The tracing model seems to be a curious hybrid of state 

recording and event logging.  The introduction seems to imply that the 

tracing model records events.  Indeed it does but state entry events do 

not appear to get recorded until the sequence transitions out of the 

state.  I can see that the COMPLETED entries record the total processing 

period, but this loses the detail of when actual processing of the event 

starts (as opposed to becoming PENDING).  I was somewhat surprised that 

a simple chained transition event model was not used (especially since 

the tracing entries are actually chained together already).

In particular if some sort of disaster occurs, it seems possible in this 

model that events in the PENDING queue might never appear in the trace 

log at all if the request hasn't started being processed. It also 

doesn't record any preprocessing time before the request becomes 

PENDING.  If there is a processing bottleneck this could be significant 


I was also wondering whether this model traces the arrival and departure 

of clients (and whether authoentication/authorisation worked or not).   

This may be covered by operation types in the architecture which I 

haven't had time to read in detail.

Minor issues:

Nits/editorial comments:

s1:  The Intro should also contain a description of the intention of the 

document - basically a slight reworking of the abstract.  It should also 

outline the association of the framework with the interface (i2rs 

client<->agent) to which the traceability applies.


    ability to automate and abstract even complex policy-based controls
    highlights the need for an equally scalable traceability function to
    provide event-level granularity of the routing system compliant with
    the requirements of I2RS (Section 5 of

The 'routing system' doesn't have an event-level granularity.  Maybe
provide event-level granularity of the routing system

provide recording at event-level granularity of the evolution of the 

routing system


s4:  The section ends with this list of 'use cases':

    As I2RS becomes increasingly pervasive in routing environments, a
    traceability model offers significant advantages and facilitates the
    following use cases:

    1  Automated event correlation, trend analysis, and anomaly

    2  Trace log storage for offline (manual or tools) analysis;

    3  Improved accounting of routing system operations;

    4  Standardized structured data format for writing common tools;

    5  Common reference for automated testing and incident reporting;

    6  Real-time monitoring and troubleshooting;

    7  Enhanced network audit, management and forensic analysis

I have added numbers to facilitate these comments:

IMO #2 and #4 are either not use cases or a not phrased as use cases.  

The automated testing is not really a use case as such. Having these 

characteristics supports the implementation of the actual use cases.  

Related to the data retention comment above, storing some or all of the 

trace log - and knowing which bits might be critical to control data 

retention - is a use case but the basic storage is just a necessary 

prerequisite of doing other things.  I also might suggest a reordering 

indicating importance perhaps.

Thus I would suggest replacing this with something like:

   As I2RS becomes increasingly pervasive in routing environments, a
   traceability model that supports controllable trace log retention

   using a standardized structured data format offers significant 


   such as the ability to create common tools and support automated 


   and facilitates the following use cases:

   o  Real-time monitoring and troubleshooting of router events;

   o  Automated event correlation, trend analysis, and anomaly

   o  Offline (manual or tools-based) analysis of router state evolution
       from the retained trace logs;

   o  Enhanced network audit, management and forensic analysis

   o  Improved accounting of routing system operations; and

   o Providing a standardized format for incident reporting and test 


s5: .. is empty: Empty sections are not desirable.  A brief overview of 

the following sub-sections should be added (or alternatively promote 

s5.1 which actually describes the framework).

s5.1, para 1:

Some notable elements of the architecture are in
    this section.

I don't understand this sentence.  If it implies that elements of the 

architecture are defined in this section then one has to ask 'Why aren't 

they defined in the architecture document?'  Since s5.1 contains the 

whole framework, what other elements than the 'some notable' ones are there?

s5.1, para 2: The term 'northbpund' is not defined (and isn't used in 

the architecture').

s5.2: The title is ' I2RS Trace Log Mandatory Fields'  - nothing that 

isn't mandatory is discussed.  Should there be some words about optional 

extra fields?

s5.2, timestamps:  The RFC3339 format doesn't tie up with 32 bit 

resolution - there are hours and minutes etc and decimal representation 

is used.  Things like origin for timestamps needs to be defined if they 

are to be truly useful for comparison outside an individual enterprise 

(as might be implied by the incident reporting use case).  If RFC 3339 

format is really used, then the timestamps need to include the date as 

well since logs will certainly run over more than one day.  I note that 

the example in s6 shows full RFC 3339 date/time format examples.

s5.2, Applied Operation Data:  Does the Operation Data Present flag 

apply to this field?  Can this be present even if there is no Requested 

Operation Data?

 s5.2, Result Code: Need to expand acronym RIB.

s7.2:  One key point about timestamping (motivated by bitter experience) 

is that timestamps need to be recorded at the point when the event 

actually happens and not when the event is (potentially significantly 

later) entered into the log.  Logging is (as indicated) often allocated 

a low priority and event log writing may end up being postponed for a 

considerable time.

s11: I would consider I-D.ietf-i2rs-problem-statement and 

I-D.ietf-i2rs-pub-sub-requirements to be Informative; and

I-D.ietf-i2rs-rib-info-model, RFC 3339 and possibly RFC 5424 to be