Shepherd writeup
rfc8054-06

Michael Bäuerle <michael.baeuerle@stz-e.de> is the document shepherd:

Shepherd writeup (Date: 2016-09-29)
draft-murchison-nntp-compress-05


1) Type of RFC
==============
The document describes a useful extension to NNTP, and has already been shown
to be interoperable (implemented in at least a news server and a news client).

The intended category of this document will be "Standards Track".
The intended status of this document will be "Proposed Standard".


2) Document Announcement Write-Up
=================================

Technical Summary
-----------------
Document Shepherd: Michael Baeuerle <mailto:michael.baeuerle@stz-e.de>
(The "ae" in "Baeuerle" is an ASCII transcription for the Umlaut U+00E4)
Area Director    : Alexey Melnikov <mailto:aamelnikov@fastmail.fm>

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.


Working Group Summary
---------------------
The draft was reviewed by a few people in <news:news.software.nntp> and the
UTA WG (but the document is not a work item of the UTA WG, because it is not
in the scope of his charter).


Document Quality
----------------
Server side implementations:
- flnews <http://micha.freeshell.org/flnews/> has already implemented
  general support in its 0.13 version (released 2015-12-14).
  Full support will be present in the 0.14 version (not yet released,
  but is scheduled to before the end of the year)

Server side implementations:
- INN, a wide-spread news server <https://www.isc.org/downloads/projects/>
  in its 2.6.1 version (not yet released, but is scheduled to before the
  end of the year)
- Cyrus NNTP <http://cyrusimap.web.cmu.edu/mediawiki/index.php/NNTP>
  already released in the 2.x series

Interoperability is proven.


3) Briefly describe the review of this document
===============================================
I have supported the creation of this document and I have written the
client side implementation for flnews.


4) Shepherd concerns
====================
No concerns.


5) Further document review
==========================
Perhaps the security team?

For security currently there are at least two relevant aspects defined:
- Compression must be enabled after authentication
- Compression defaults to "off" and the user must explicitly enable it.
  Example: If a program is updated from a version without support to
  a new version with support for compression, the compression should
  not become active automatically (maybe the user has not even noticed
  the new capability and should think about security first).


6) Document issues
==================
The document draft currently states in chapter 7.1:

   [...] private compression algorithms SHOULD begin with "X-".

Best Current Practice defined in RFC 6648 specify that the "X-" prefix
should no longer be used. Simply removing the wording about the special
meaning of "X-" names should be sufficient to match RFC 6648 requirements.

The informative section 3 maybe is too detailed.

Section 3 is marked as informative rather than normative, but section
3.1 uses normative keywords (MUST and SHOULD):
Section 3.1 should become normative because the windows size is relevant
for interoperability of Deflate compression even if the implementation is
not based on zlib.

Section 6 should explicitly note SASL and TLS as "security layers".


7) IPR disclosures
==================
Both authors confirmed that there is no IPR involved.


8) Has an IPR disclosure been filed that references this document?
==================================================================
Nothing known.


9) Consensus of the interested community behind this document?
==============================================================
Currently it is possible to use compression as part of TLS, but TLSv1.3 will
drop support for compression.
There is consensus that an option for NNTP compression should stay available
in the future. The NNTP extension defined in this document will provide
compression support with and without TLS. Potential authentication is done
before compression is activated to ensure that the compression cannot weaken
the security of the authentication steps if TLS is used.


10) Anyone threatened an appeal or otherwise indicated extreme discontent?
==========================================================================
No.


11) ID nits
===========
| == Missing Reference: 'C' is mentioned on line 436, but not defined
|    '[C] AUTHINFO USER fred...'

| == Missing Reference: 'S' is mentioned on line 437, but not defined
|    '[S] 502 DEFLATE compression already active...'

"C" and "S" are direction marks (whether the client "C" or the server "S"
sends the data).

| -- Looks like a reference, but probably isn't: '1' on line 232
|    '[1] If a compression layer is already active, COMPRESS is not a v...'

It's a reference to an internal note. If such references are not allowed,
the text can be reworded to "502 Command unavailable (see text below)".


12) Required formal review criteria
===================================
?


13) Have all references within this document been identified as either
======================================================================
    normative or informative?
    =========================
References that should be moved from informative (8.2) to normative (8.1)
section (Reasons explained at question 6):
- RFC 1951 "DEFLATE Compressed Data Format Specification version 1.3"

References that should be moved from normative (8.1) to informative (8.2)
section (Reason: TLS is optional, NNTP can be used without it):
- RFC 4642 "Using Transport Layer Security (TLS) with Network News Transfer
            Protocol (NNTP)"


14) Normative references to documents that are not ready for advancement?
=========================================================================
None.


15) Are there downward normative references references (see RFC 3967)?
======================================================================
RFC 1951 stated above has state "informational", but is important for
interoperability.


16) Will publication of this document change status of any existing RFCs?
=========================================================================
No.


17) Document Shepherd's review of the IANA considerations section
=================================================================
See question 6 for reserved namespace.

The protocol extension (COMPRESS) that the document makes is associated with
the appropriate reservation in IANA registries. Any referenced IANA registries
have been clearly identified.

Newly created IANA registry for NNTP compression algorithms include a detailed
specification of the initial contents for the registry. Allocations procedures
for future registrations are defined. A reasonable name for the new registry
has been suggested.


18) IANA registries that require Expert Review for future allocations
=====================================================================
None.


19) Reviews and automated checks performed by to validate sections of the
=========================================================================
    document written in a formal language
    =====================================
None.
Back