Re: [NNTP] Fwd: Last Call: <draft-murchison-nntp-compress-05.txt> (Network News Transfer Protocol (NNTP) Extension for Compression) to Proposed Standard
Russ Allbery <eagle@eyrie.org> Sun, 18 September 2016 19:39 UTC
Return-Path: <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>
X-Original-To: ietfarch-nntpext-archive@ietfa.amsl.com
Delivered-To: ietfarch-nntpext-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B9B12B00D for <ietfarch-nntpext-archive@ietfa.amsl.com>; Sun, 18 Sep 2016 12:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 m4mCLhUuYB8O for <ietfarch-nntpext-archive@ietfa.amsl.com>; Sun, 18 Sep 2016 12:39:54 -0700 (PDT)
Received: from hope.eyrie.org (hope.eyrie.org [166.84.7.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2168812B14D for <nntpext-archive@ietf.org>; Sun, 18 Sep 2016 12:39:52 -0700 (PDT)
Received: from hope.eyrie.org (localhost [IPv6:::1]) by hope.eyrie.org (Postfix) with ESMTP id E4A7967D2C for <nntpext-archive@ietf.org>; Sun, 18 Sep 2016 12:39:50 -0700 (PDT)
X-Original-To: ietf-nntp@lists.eyrie.org
Delivered-To: ietf-nntp@lists.eyrie.org
Received: from haven.eyrie.org (haven.eyrie.org [166.84.7.159]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hope.eyrie.org (Postfix) with ESMTPS id 5780A67D08 for <ietf-nntp@lists.eyrie.org>; Sun, 18 Sep 2016 12:39:49 -0700 (PDT)
Received: from lothlorien.eyrie.org (96-90-234-101-static.hfc.comcastbusiness.net [96.90.234.101]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by haven.eyrie.org (Postfix) with ESMTPS id 2D5601181F4 for <ietf-nntp@lists.eyrie.org>; Sun, 18 Sep 2016 12:39:49 -0700 (PDT)
Received: by lothlorien.eyrie.org (Postfix, from userid 1000) id 1994FB412F7; Sun, 18 Sep 2016 12:39:48 -0700 (PDT)
From: Russ Allbery <eagle@eyrie.org>
To: ietf-nntp@lists.eyrie.org
In-Reply-To: <ac156e10-4a21-d3fc-4121-c8183fde0851@trigofacile.com> ("Julien ÉLIE"'s message of "Sun, 18 Sep 2016 15:51:28 +0200")
Organization: The Eyrie
References: <147370585231.3841.13116072033078869671.idtracker@ietfa.amsl.com> <ac156e10-4a21-d3fc-4121-c8183fde0851@trigofacile.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
Date: Sun, 18 Sep 2016 12:39:47 -0700
Message-ID: <87k2e980ak.fsf@hope.eyrie.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [NNTP] Fwd: Last Call: <draft-murchison-nntp-compress-05.txt> (Network News Transfer Protocol (NNTP) Extension for Compression) to Proposed Standard
X-BeenThere: ietf-nntp@lists.eyrie.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: NNTP protocol discussion <ietf-nntp.lists.eyrie.org>
List-Unsubscribe: <https://lists.eyrie.org/mailman/options/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=unsubscribe>
List-Archive: <https://lists.eyrie.org/pipermail/ietf-nntp/>
List-Post: <mailto:ietf-nntp@lists.eyrie.org>
List-Help: <mailto:ietf-nntp-request@lists.eyrie.org?subject=help>
List-Subscribe: <https://lists.eyrie.org/mailman/listinfo/ietf-nntp>, <mailto:ietf-nntp-request@lists.eyrie.org?subject=subscribe>
Errors-To: ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org
Sender: ietf-nntp <ietf-nntp-bounces+nntpext-archive=ietf.org@lists.eyrie.org>
Julien ÉLIE <julien@trigofacile.com> writes: > The NNTP COMPRESS extension is currently in IETF Last Call. > You can see the current document here: > https://tools.ietf.org/html/draft-murchison-nntp-compress-05 > In case you have any comments, please send them before October, 10th to > <ietf@ietf.org> as explained in the mail below, retaining the Subject line > of the mail. > Thanks beforehand for your review. Here are a few comments (which I had already sent to Julien privately). There was some follow-up discussion since I misunderstood a couple of points; I'll let Julien summarize that. - Section 3 is marked as informative rather than normative, but section 3.1 uses normative keywords (MUST and SHOULD). I think you can only do one or the other. If that section is supposed to be normative, maybe make it section 4 instead? - I don't understand what this bit in Security Considerations means: Implementations SHOULD use a default configuration with disabled compression when a security layer is active, and MUST support an option to allow compression to be enabled when a security layer is active. Such an option can be either with global scope or server/ connection based. Implementations MAY unconditionally allow compression to be enabled when no security layer is active. Generally, protocol specifications don't get to mandate what implementations MUST do in local configuration, but apart from that, I'm not sure what this is even driving at. You're trying to say that implementations SHOULD default to disabling compression when there's a security layer active but MUST support configuring the implementation to allow it? Why would that be something we would need to constrain? As written, this paragraph appears to declare noncompliant an implementation that only supports COMPRESS when there is no security layer, and I'm not sure why we would want to do that. - I think you want an explicit reference to RFC 4422 the first time you mention security layer in the Security Considerations section, since it's not otherwise obvious that you're specifically talking about a SASL security layer. (For instance, one might reasonably assume TLS is a security layer if the term was used in the general sense, since it's a protocol layer that adds a security feature.) - RFC 1951 definitely needs to be a normative reference. (It's already listed in DownrefRegistry, so shouldn't be a problem.) - I'm pretty sure RFC 4643 needs to be a normative reference, since you mention it in conjunction with normative requirements about sequencing and security considerations. I'm going to try to serve as the document shepherd unless someone with more time than I have (which isn't much at the moment) volunteers. :) -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>
- [NNTP] Fwd: Last Call: <draft-murchison-nntp-comp… Julien ÉLIE
- Re: [NNTP] Fwd: Last Call: <draft-murchison-nntp-… Russ Allbery
- Re: [NNTP] Fwd: Last Call: <draft-murchison-nntp-… Julien ÉLIE
- Re: [NNTP] Fwd: Last Call: <draft-murchison-nntp-… Julien ÉLIE