Early Review of draft-ietf-i2rs-problem-statement-04
review-ietf-i2rs-problem-statement-04-genart-early-housley-2014-12-12-00

Request Review of draft-ietf-i2rs-problem-statement
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-02-16
Requested 2014-12-05
Authors Alia Atlas, Thomas Nadeau, David Ward
Draft last updated 2014-12-12
Completed reviews Genart Early review of -04 by Russ Housley (diff)
Genart Last Call review of -09 by Russ Housley (diff)
Rtgdir Early review of -06 by Nabil Bitar (diff)
Secdir Early review of -04 by Stephen Kent (diff)
Secdir Last Call review of -09 by Stephen Kent (diff)
Opsdir Early review of -06 by Sarah Banks (diff)
Rtgdir Early review of -04 by Eric Gray (diff)
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-i2rs-problem-statement-04-genart-early-housley-2014-12-12
Reviewed rev. 04 (document currently at 11)
Review result Almost Ready
Review completed: 2014-12-12

Review
review-ietf-i2rs-problem-statement-04-genart-early-housley-2014-12-12

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This review is in response to a request for early Gen-ART review.

Document: draft-ietf-i2rs-problem-statement-04
Reviewer: Russ Housley
Review Date: 2014-12-11
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Almost Ready.

Major Concerns:

Section 5 says, "Data written can be owned by different I2RS clients."
The intended consequences are unclear.  I assume that the data written
by one client cannot be rewritten by another client.  However, I can
imagine some situations where the same data object might be written by
more than one client at different times.  Please add some language to
say whether this situation is within scope or not.

Section 5 includes a requirement for multi-channel.  I would expect
policy to dictate that some requests, especially ones that impact the
whole router, come from a specific source.  This might require that
the request arrive on a particular port or that it be authenticated in
a particular manner.  Can more be said about the policy controls here?

Section 8 seems very thin to me.  There are some lessons from MIBs
documented here: www.ops.ietf.org/mib-security.html.  I think that
some of this extrapolates to this document, but I do not think that
a pointer to those guidelines is the best way forward.

Minor Concerns:

The document talks about the IESG statement issued on 2 March 2014.
Please add a reference, which is probably best done with a URL.

Section 5 says that the ability to manipulate routing controls is
"subject to authentication and authorization."  This is highly desirable.
Can we go a little bit further?  Is it like root on a Unix box, or is
the authorization more granular?  Are there known roles that must be
supported?

Other Comments:

Section 5 says: "Such communications must also have its integrity
protected."  I do not know how to do authentication without also
providing integrity, so this is really implied by the previous
sentence.  That said, I suggest the following wording: "Such
communications must be integrity protected."