[Gen-art] Gen-ART Last Call review of draft-alakuijala-brotli-08

[Paul Kyzivat <[e-mail]>]

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