Skip to main content

Last Call Review of draft-alakuijala-brotli-08

Request Review of draft-alakuijala-brotli
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-04-19
Requested 2016-03-11
Authors Jyrki Alakuijala , Zoltan Szabadka
I-D last updated 2016-04-10
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 Dan Romascanu
State Completed
Review review-alakuijala-brotli-08-opsdir-lc-romascanu-2016-04-10
Reviewed revision 08 (document currently at 11)
Result Has issues
Completed 2016-04-10


I have reviewed draft-alakuijala-brotli-08 as part of the Operational
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written with the intent of improving the
operational aspects
 of the IETF drafts. Comments that are not addressed in last call may be
 included in AD reviews during the IESG review.  Document editors and WG chairs
 should treat these comments just like any other last call comments.

This I-D defines a lossless compressed data format that compresses data using a
combination of the LZ77 algorithm and Huffman coding, and the Abstract claims
that this is performed with an efficiency comparable to the best currently
 available general-purpose compression methods.

An RFC 5706 review does not apply, as this is not a new protocol or extension
of an existing protocol.

I believe the document is 'Almost Ready' for publication. I am no expert in
compression, but my impression is that the document is clear and precise in
defining the algorithm and the flow of operations on compression or
decompression. From
 an operational point of view I have however two reservations:


There is no justification of any kind (mathematical proof, measurement results,
etc.) that supports the claims that the performance resulting from the
application of the algorithms results in ‘with an efficiency
 comparable to the best currently available general-purpose compression
 methods’. Even so, if the resulting performance is only ‘comparable’ with
 existing methods, why define a new one and publish it in an RFC?


There is no information or recommendations about the applicability of this
format (what type of platforms, or network protocols) or documented results of
its deployment – when should a software developer use it?
 Where should a network operator or IT manager apply it or activate it if

I believe that for publication as an AD-sponsored RFC (even Informational) such
information should be available and included in the document. Otherwise, it can
also be published in the Independent Stream.