Skip to main content

Early Review of draft-ietf-i2rs-traceability-06

Request Review of draft-ietf-i2rs-traceability
Requested revision No specific revision (document currently at 11)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-04-28
Requested 2016-04-13
Authors Joe Clarke , Gonzalo Salgueiro , Carlos Pignataro
I-D last updated 2016-04-28
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 Les Ginsberg
State Completed
Review review-ietf-i2rs-traceability-06-rtgdir-early-ginsberg-2016-04-28
Reviewed revision 06 (document currently at 11)
Result Has issues
Completed 2016-04-28


I have been selected as the Routing Directorate reviewer for this draft. The
Routing Directorate seeks to review all routing or routing-related drafts as
they pass through IETF last call and IESG review, and sometimes on special
 The purpose of the review is to provide assistance to the Routing ADs. For
 more information about the Routing Directorate, please see

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other IETF Last Call
comments that you receive, and strive to resolve them through discussion or by
 the draft.



Reviewer: Les Ginsberg

Review Date: April 27, 2016

IETF LC End Date: April 29, 2016

Intended Status: Informational

Summary:  This document is a well written document - easy to understand. My
compliments to the authors. I believe there is one minor issue which I would
like to see addressed before publication.

Major Issues: None

Minor Issues:

In Section 5.2 there is a definition of the information which is required to be
kept by an I2RS Agent for each I2RS interaction. I would like to see the
addition of "Request State" into this list. Operationally each request could be
 in one of the following states:


Enqueued (or pending if you prefer)


In process



The lack of such a state seems to imply that both the queue time and the
processing time are insignificant. While I think this may be the case for many
requests, it will not always be the case. In queue time may be lengthy due to
 load on the Agent. Also, some requests - particularly destructive requests
 which involve cleanup of resources - may take a significant amount of time to

Along with this an additional timestamp - Processing Initiated - would be
useful to indicate when processing of the request actually began.


Section 5.1

s/Some notable elements on the architecture/ Some notable elements of the

Figure 1

Not clear to me why Application IDs start at 0 but Client IDs start at 1.

Figure 1

Is the text "Op Data V" between I2RS Agent box and Routing System box

Section 5.2

Secondary Identity

This is defined to be "opaque" yet if not provided the agent is supposed to
insert "an UNAVAILABLE value". This seems to be a contradiction unless we have
a publicly defined value that clients are prohibited from using. Absent that you
 would need a "Secondary Identity Valid" indicator.

Section 7.4

s/establish an vendor-agnostic/establish a vendor-agnostic