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

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