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 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 |
review-alakuijala-brotli-08-opsdir-lc-romascanu-2016-04-10-00
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