Ballot for draft-alakuijala-brotli
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
Note for IESG: The reason why IESG is reviewing this document is because the IANA registration requires IETF Consensus RFC. Thank you for addressing my DISCUSS points.
Agree with Stephen's point about the IPR declaration.
Has there been an answer to the question in Paul Kyzivat's Gen-ART review about whether this draft is the authoritative specification?
Two valid questions asked by Dan Romascanu in his OPS DIR review: 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?
For what it is worth, I do believe words in the document to the effect that the specification is intended to be complete and sufficient for implementing the format would be helpful.
dan romascanu performed the opsdir review.
I agree with Stephen's comment requesting more references in the security considerations section to help readers/implementers.
- The IPR declaration confused me a bit. Do we know if it is saying that any implementation of the RFC for any purpose is RF or if it only means that RF applies to W3C stuff? (What's confusing is the last bit where it says the company "provides a W3C RF commitment" which is just a bit of an odd thing to see in an IETF IPR declaration.) Note: I think this is ok, as-is, but it's not entirely clear to me. If the folks who made the IPR declaration wanted to clarify that might be good, but I don't think it's absolutely needed. - The security considerations could do with some more references, at least one to a zip bomb and one to the crime attack. I think those would help some readers/implementers get the issues better. - I think it'd have been good to add a section on when the authors think it's a good and bad idea to use this algorithm. For example, would it make sense to ever use this for arbitrary (but not random) binary data? I don't mean a full analysis, but just some basic guidance. Not a big deal, but including that might avoid some repetition later on, esp if there are places where we know now that one ought not use this. - I agree with Alexey's discuss point #1.