Subject: [NNTP] Fwd: Last Call: <draft-murchison-nntp-compress-05.txt> (Network News Transfer Protocol (NNTP) Extension for Compression) to Proposed Standard

From: Julien ÉLIE <[email-masked]>
Date: Sun, 18 Sep 2016 15:51:28 +0200

Hi all,

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 
<[email-masked]> as explained in the mail below, retaining the Subject 
line of the mail.

Thanks beforehand for your review.

-- 
Julien ÉLIE

« Ça n'a été qu'un coup de glaive dans l'eau. » (Astérix)

-------- Message transféré --------
Sujet : Last Call: <draft-murchison-nntp-compress-05.txt> (Network News 
Transfer Protocol (NNTP) Extension for Compression) to Proposed Standard
Date : Mon, 12 Sep 2016 11:44:12 -0700
De : The IESG
Pour : IETF-Announce

The IESG has received a request from an individual submitter to consider
the following document:
- 'Network News Transfer Protocol (NNTP) Extension for Compression'
   <draft-murchison-nntp-compress-05.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2016-10-10. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

    This document defines an extension to the Network News Transport
    Protocol (NNTP) that allows a connection to be effectively and
    efficiently compressed between an NNTP client and server.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-murchison-nntp-compress/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-murchison-nntp-compress/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 18 Sep 2016 12:39:47 -0700

> <[email-masked]> 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 ([email-masked])              <http://www.eyrie.org/~eagle/>

---

From: Julien ÉLIE <[email-masked]>
Date: Sun, 18 Sep 2016 21:58:42 +0200

Hi Russ,

> points; I'll let Julien summarize that.

OK, I'll do that.  Thanks again for having taken time to read the document.

>   make it section 4 instead?

Yes, making it section 4 would be better.

>   layer, and I'm not sure why we would want to do that.

You're totally right that the MUST is not good here.
The point of the paragraph is to say that, to maximize security, 
compression should not be enabled by default when a security layer is 
active.
On second thoughts, I think either the whole paragraph you quote should 
be removed or reworded to something like:

       Implementations are encouraged to unconditionally allow
       compression when no security layer is active, and to support
       an option to enable or disable compression when a security layer
       is active.  Such an option could for instance be with global
       scope or server/connection based.

Would it sound good to you?  (or perhaps without the second sentence, 
that may be superfluous?)

>   protocol layer that adds a security feature.)

In fact, when we use "security layer" in the document, it refers to both 
TLS and SASL.  I'll try to reword it in a more understandable way.
Security considerations apply to the use of COMPRESS with TLS and also 
to the use of COMPRESS with a SASL security layer.
Moreover, we can have both TLS and a SASL security layer in place during 
the same NNTP session.

>   and security considerations.

Yep.  I confess not having given much importance to the sorting between 
normative/informative references.  I'll review that.

> more time than I have (which isn't much at the moment) volunteers.  :)

Thanks again for your comments, and the proposal to shepherd the 
document if no one else wishes to.

-- 
Julien ÉLIE