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

[Julien ÉLIE <[e-mail]>]

Hi Russ,

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

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


> - 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?

Yes, making it section 4 would be better.


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

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


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

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.


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

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


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

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

-- 
Julien ÉLIE

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