Early Review of draft-ietf-i2rs-problem-statement-04
review-ietf-i2rs-problem-statement-04-rtgdir-early-gray-2014-12-17-00

Hello,

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 request. 

The purpose of the review is to provide assistance to the Routing ADs. 

For more information about the Routing Directorate, please see:

	​

http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



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 updating the draft.

Document: draft-ietf-i2rs-problem-statement
Reviewer: Eric Gray 
Review Date: 12/16/2014
Intended Status: Informational

Summary: I have some minor concerns about this document that I think 
should be resolved before before publication.  The document has nits 
that should also be considered prior to publication.

Minor Issues:
==========

Section 5 title is "Desired Aspects of ..." but the first sentence talks about
"required aspects ..."  I believe that the authors should be consistent.

The actual "key aspects needed" are a mixture or required and desired
behaviors.  Because the draft does not refer to RFC 2119 terminology,
it is not clear if this is intended or a result of narrative style choices.

If the terminology is meant to be interpreted according to RFC 2119,
then this should be added as a reference.  Otherwise, perhaps the title
of the section should be changed to: 

  "Aspects to be Considered in Designing Protocol for I2RS"

In this section, in addition to "Secure Control" we may want to suggest
similar "Secure Access."  Information about routing may be useful to an
attacker for other forms of attack than direct control.

Section 8 ("Security Considerations") - Minimally, this section should
point to security aspects mentioned in the preceding section.

Note that this section mentions "extraction of detailed router state"
which is one form of access that may both require that requests 
are authenticated and that information may not be intercepted.

NITS:
====

In the Introduction, second line of the first paragraph, "With scale ..."
should start a new paragraph to be consistent with the next paragraph.

In the appendix the first paragraph should probably end in much the
same way as the second paragraph, i.e. - 

   "CLI Standardization is not considered as a candidate solution for the 
     I2RS."

It is not clear what we are trying to say in saying "I2RS does not involve
CLI Standardization."