Last Call Review of draft-ietf-bess-ir-03
review-ietf-bess-ir-03-genart-lc-kyzivat-2016-08-15-00

Request Review of draft-ietf-bess-ir
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-08-16
Requested 2016-08-10
Authors Eric Rosen, Karthik Subramanian, Zhaohui Zhang
Draft last updated 2016-08-15
Completed reviews Genart Last Call review of -03 by Paul Kyzivat (diff)
Genart Last Call review of -03 by Paul Kyzivat (diff)
Secdir Last Call review of -03 by Magnus Nystrom (diff)
Opsdir Last Call review of -03 by Qin Wu (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Review review-ietf-bess-ir-03-genart-lc-kyzivat-2016-08-15
Reviewed rev. 03 (document currently at 05)
Review result Ready with Issues
Review completed: 2016-08-15

Review
review-ietf-bess-ir-03-genart-lc-kyzivat-2016-08-15

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 <‚Äč 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-bess-ir-05
Reviewer: Paul Kyzivat
Review Date: 2016-08-15
IETF LC End Date: 2016-08-10
IESG Telechat date: 2016-08-18

Summary:

Unfortunately, I don't have the expertise to review this draft.

(Of the review summaries available to me, the one I want to use is "This 
draft has serious issues, described in the review, and needs to be 
rethought." But I don't think I am in a position to make such a 
judgement given my lack of knowledge of the subject domain.)

Issues:

Major: 0
Minor: 1
Nits:  0

(1) MINOR (?!?):

Lacking any knowledge of the subject matter of this draft, I found it 
impossible to review in a meaningful way. But I tried!

I came to the tentative conclusion that this document is struggling to 
document an extremely complex system. In such a situation publishing the 
sort of documentation provided here is probably better than not doing 
so. But I fear it isn't sufficient - that it will be unlikely that a new 
implementer, schooled in the subject matter, will be able to create a 
correct implementation. The problem is with the system/algorithms, not 
with the document.

(NOTE: I've made this minor rather than major because I don't consider 
myself competent to say this is a real problem or if it is one that this 
draft should be expected to fix.)