[NNTP] Fwd: Last Call: <draft-murchison-nntp-compress-05.txt> (Network News Transfer Protocol (NNTP) Extension for Compression) to Proposed Standard
Russ Allbery
eagle at eyrie.org
Sun Sep 18 12:39:47 PDT 2016
Julien ÉLIE <julien at 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 at 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 at eyrie.org) <http://www.eyrie.org/~eagle/>
More information about the ietf-nntp
mailing list