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