Re: [Gen-art] Gen-ART Last Call review of draft-alakuijala-brotli-08

Zoltan Szabadka <szabadka@google.com> Tue, 12 April 2016 13:17 UTC

Return-Path: <szabadka@google.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F3712EE05 for <gen-art@ietfa.amsl.com>; Tue, 12 Apr 2016 06:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.696
X-Spam-Level:
X-Spam-Status: No, score=-3.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgZm94xGxwAY for <gen-art@ietfa.amsl.com>; Tue, 12 Apr 2016 06:17:55 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF8112EDE8 for <gen-art@ietf.org>; Tue, 12 Apr 2016 06:17:53 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id g184so24627270lfb.3 for <gen-art@ietf.org>; Tue, 12 Apr 2016 06:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n8fMXqlu1hegEi0inOLNTW4xl8J7SjIvCDJmH0aHn5c=; b=Gpn5W20GANSC21tkfZ5xCAK9n1EbRf4GlVLkzprieoYzS9fCzrvBJTdFdvxkRNTDKM 6qOSN7EItxUsrUO4J3nnSM1hoeYANw5hwH/jF5woPaSiPAgwrMVe8CBO5x+ay4v7pQ9a IN79CaCqpGMHh+4CvG309e1drlkNeNywmm52uuby0tF3TBxKhjmJhgfIIlSVstYHuzZK nOZxRe9YNfDioF5MN9qDTMey3j0DU0HRtB0KuNzhuDSvHnhAjuXPFAckcgccWojblrlE bVTt4At+qKZ2GGP1/sFydsvIcwZAUNYqeS8r7F8GJrnF1h0FCcHLq4yXMT7iU4LC/nc1 5Ycg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n8fMXqlu1hegEi0inOLNTW4xl8J7SjIvCDJmH0aHn5c=; b=gw0gU/b/BSqMwEhaw4PgzJXq9OFSalL+HeMyZWf9qBvzx5XfBTB4Xsy8EYCCx7UU50 N9HCCP06cPVKsLO9ZR63+M5MMTnvI+NCtLXwxQpBKUMNYS2v8t5zWf6u+KiBBkhvx01l vke3+Sec9M9yAJP3RNmBqy0iiyuvhHavr+Z673BBW6iEmawDwt6gPArkwgvezDREO93P FvDMfQwJOqT3vMBYxwMJVy+v01UGRplnLuq3Fyx0nCtIwjunpB3uzf0evr54jsrTwXEk TqONJwZxhX2cp/pHh0w6bJmByTEflCE6rAiXlwMF6fS0uLliSBHDcusDHlmftInjs1Kf 7Pbg==
X-Gm-Message-State: AOPr4FWOMs4I7sGRVjXeHrQxze9ONH1Q+G5PJsrD3jMD2SmOuO7iQO4cMUEgVQi8XhJmpJo/y3yMnvIHA9t4xn71
MIME-Version: 1.0
X-Received: by 10.25.85.210 with SMTP id j201mr1178029lfb.132.1460467071638; Tue, 12 Apr 2016 06:17:51 -0700 (PDT)
Received: by 10.112.15.42 with HTTP; Tue, 12 Apr 2016 06:17:51 -0700 (PDT)
In-Reply-To: <56FEC5D3.5080504@alum.mit.edu>
References: <56818AED.8090909@alum.mit.edu> <56FEC5D3.5080504@alum.mit.edu>
Date: Tue, 12 Apr 2016 15:17:51 +0200
Message-ID: <CAErD28_LcK0gVtwWqB-pw+fHbA6abKs-qkiwxhfHzinAk0PUPw@mail.gmail.com>
From: Zoltan Szabadka <szabadka@google.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="001a1141d826033faa0530497dd0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/oyT9e3_U8bc2B6FhIraySO6NTzw>
Cc: aamelnikov@fastmail.fm, General Area Review Team <gen-art@ietf.org>, n.brownlee@auckland.ac.nz, Nevil Brownlee <rfc-ise@rfc-editor.org>, barryleiba@computer.org, draft-alakuijala-brotli.all@ietf.org
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-alakuijala-brotli-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Apr 2016 13:17:57 -0000

Thank you for reviewing this internet draft.

We do share your concern that it is very difficult to fully specify a
compressed data format of this complexity using natural language text alone.

To address this concern, the language and style of this internet draft
follows that of RFC 1951, which specifies a compression format closely
related to this one, to the extent that some common parts were taken over
verbatim. Moreover, we worked with three independent software implementers,
who agreed to use only the text of this draft to implement a brotli decoder
and provide feedback on where the text was ambiguous or unclear.

These independent implementations are the following:

    1) C language implementation of Mark Adler:
https://github.com/madler/brotli
    2) Rust language implementation of Thomas Pickert:
https://github.com/ende76/brotli-rs
    3) Go language implementation of Joe Tsai:
https://github.com/dsnet/compress/tree/brotli

The current -08 version of this internet draft addresses the findings of
these reviews, and we believe that it is possible to decide based on this
draft whether or not an arbitrary sequence of bytes is a valid brotli
stream; and what is the uncompressed sequence of bytes that a valid brotli
stream represents.

As the next step, we plan to update the draft with a section about
considerations for compressor implementations. In this, we will address:
    1) Jean-Loup Gailly’s review comment about how it is possible, if
desired, to make a sequence of blocks self-contained in a way that they can
be decompressed independently of previous blocks.
    2) The secdir review comments about CRIME and DoS attacks.

We expect to be ready with the next version of the draft in one week.

Kind Regards,
Zoltan

On Fri, Apr 1, 2016 at 9:02 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

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