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

Julien =C3=89LIE <[email protected]> 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
> <[email protected]> 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.  :)

--=20
Russ Allbery ([email protected])              <http://www.eyrie.org/~eagle/>