Last Call Review of draft-alakuijala-brotli-08
review-alakuijala-brotli-08-opsdir-lc-romascanu-2016-04-10-00

Request Review of draft-alakuijala-brotli
Requested rev. 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
Draft 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 rev. 08 (document currently at 11)
Review result Has Issues
Review completed: 2016-04-10

Review
review-alakuijala-brotli-08-opsdir-lc-romascanu-2016-04-10






Hi,




 




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 available?





 




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.





 




Regards,




 




Dan