Last Call Review of draft-alakuijala-brotli-08
review-alakuijala-brotli-08-genart-lc-kyzivat-2016-04-01-00

Request Review of draft-alakuijala-brotli
Requested rev. no specific revision (document currently at 11)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2016-04-08
Requested 2016-03-11
Draft last updated 2016-04-01
Completed reviews Genart Last Call review of -08 by Paul Kyzivat (diff)
Genart Last Call review of -08 by Paul Kyzivat (diff)
Genart Telechat review of -09 by Paul Kyzivat (diff)
Secdir Last Call review of -08 by Liang Xia (diff)
Opsdir Last Call review of -08 by Dan Romascanu (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Review review-alakuijala-brotli-08-genart-lc-kyzivat-2016-04-01
Reviewed rev. 08 (document currently at 11)
Review result Not Ready
Review completed: 2016-04-01

Review
review-alakuijala-brotli-08-genart-lc-kyzivat-2016-04-01

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 treat these comments just like any other 
last call comments. For more information, please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-alakuijala-brotli-08
Reviewer: Paul Kyzivat
Review Date: 2016-02-23
IETF LC End Date: 2016-04-08
IESG Telechat date: 2016-04-21

Summary:

This draft has serious issues, described in the review, and needs to be 
rethought.

Major: 1
Minor: 0
Nits:  0

==========

(1) Major:

In my opinion this document does not satisfy the purpose given in 
section 1.1 for the type of reader identified in section 1.2.

I spent many hours trying to decipher the document, but ultimately 
failed. (I have no experience in implementing compression/decompression 
algorithms, but I have many decades of programming experience including 
that involving detailed bit manipulation and data representation.)

If two expert programmers were asked to independently build 
encoder/decoders in accord with this document, IMO it would be 
incredibly unlikely (impossible) that the resulting programs would be 
interoperable. And given the complexity of the encoding it would also be 
extremely difficult to figure out *why* they didn't interoperate.

My sense from reading this document is that the format is operationally 
defined by an existing program (https://github.com/google/brotli) and 
that this document is an attempt to re-render the source code in 
English. However the algorithms being described are so complex that 
English (at least *this* English) is inadequate for the job.

I started out making notes about particular places where I found the 
language confusing or ambiguous. But there were so many that I 
ultimately gave up.

I have serious doubts that the goal of this document achievable using 
natural language text. I don't have much of an idea of what to try to 
achieve this. It will take much more than just patching the current 
document. If possible at all it will require a vastly different approach.

To achieve the goal of having a specification independent of a 
particular implementation it may be necessary to abandon backward 
compatibility with *this* implementation. (I recognize that doing so may 
be unacceptable.)