[NNTP] Fwd: Gen-art review of draft-ietf-nntpext-streaming-05
Russ Allbery
rra at stanford.edu
Thu Jun 2 09:43:48 PDT 2005
Date: Thu, 02 Jun 2005 10:41:19 +0100
From: Elwyn Davies <elwynd at dial.pipex.com>
To: gen-art at alvestrand.no
CC: Mary Barnes <mary.barnes at nortel.com>, vinocur at cs.cornell.edu,
ken at oceana.com, Russ Allbery <rra at stanford.edu>,
Scott Hollenbeck <sah at 428cobrajet.net>
Subject: Gen-art review of draft-ietf-nntpext-streaming-05
Document: draft-ietf-nntpext-streaming-05.txt
Trigger: IETF Last call, ending 7 June 2005
Reviewer: Elwyn Davies
AD: Scott Hollenbeck
Document Shepherd: Russ Allbery
Review Date: 2 June 2005
Intended status: Proposed Standard
Review Parameters: This is a review by a member of the General Area
Reviewing team, supporting the IETF General Area Director. As the
submission is from an IETF WG, the review should focus on these
questions: "Is this document a reasonable contribution to the area of
Internet engineering which it covers? If not, what changes would make it
so?"
Summary: This document is almost ready for submission to the IESG. An
interesting case of turning a de facto situation (RFC2980) into a de
jure standard. I think the document could do with a little more, and
earlier, explanation of and connection to RFC2980 since it is presumably
intended that it should interoperate with legacy clients/servers that
implement the extensions. The idea of deprecating MODE STREAMING and
then stating that it was defined in this document boggled me for a
moment! It is also an interesting question as to whether the reference
to RFC2980 should be normative: I feel it should be.
On the matter of reponse codes: There appears to be a wider question of
whether these should be registered with IANA (as with SIP response
codes). The definitions are (or are about to be) spread across several
documents and ensuring that there is no clash may become more difficult
if further extensions are made.
I noted that the potentiality for pipelined commands to be used fos DoS
attacks was not mentioned in the Security Considerations of this or the
base document (draft-ietf-nntpext-base-26).
Review:
Generally a well written , well thought out document, which is almost
ready for IESG review.
As I read the document, I got the sneaking suspicion that the document
was almost ashamed of its ancestry in Sections 1.1 to 1.3 of RFC2980 (a
*mere* informational document relating to some extensions that don't
have the dignity of standardisation)! Providing a short section in the
introduction (either as part of S1 or a new sub-section) to explain the
relationship to RFC2980 would reduce the crogglement when MODE STREAM is
deprecated almost before it has been defined. It would also help to
confirm and/or limit the extent to which the current specification is
expected to interoperate with legacy implementations that 'conform' to
the corresponding RFC2980 capabilities. I also do't believe that RFC2980
is an Informative reference: There is a degree of backwards
compatibility which makes RFC2980 Normative.
Detailed Comments:
S1: Last sentence: I think 'effective' would be better word than
'consistent'.
S2.1: Advertising Capability: This section might be more easily
understood if placed after the definition of MODE STREAMING (i.e.,
reorder (2.1, 2.2, 2.3) -> (2.2, 2.3, 2.1)). I note that the capability
STREAMING is actually noted as being in the inital IANA registry of
NNTP capabilities in the base document, but this document contains the
definition: I think that means there should be a NORMATIVE reference to
this document in draft-ietf-nntpext-base-26, rather than the informative
one there is at present (applies to the authentication document also).
S2.2: Streaming Article Transfer: A pointer to the section in the base
spec defining pipelining in this context would be useful: pipelining
has a generic meaning and to the naive reader it might not be obvious
that it has a specific meaning in these documents. Specifically it has
implications for how responses should be associated with commands which
makes some of the later stuff more comprehensible.
S2.3: Defn of MODE STREAM: It would be worth emphasising that MODE
STREAM does not actually cause the server to 'change mode' (a good and
sufficient reason for deprecating it!). The IANA regsitartion mentions
that MODE STREAM can be pipelined - it would be worth mentioning that
here too, since it is perhaps not obvious that something which sounds
like a mode switch could be pipelined - because of course it doesn't
actually do anything! Also, presumably (for consistency with the
CAPABILITY advertising), the repsonse to MODE STREAM, after MODE READER
has been issued, should match whether the server would advertise
STREAMING in this state.
S4: Summary of Response Codes: This section in itself is fine. However
with the current standards for NNTP spread across several documents, it
would make it easier to check that there was not a clash between
response codes in documents (and to enforce the rules in S3.2 of
draft-ietf-nntpext-base-26) if there was an IANA registry for the
reponse codes. Incidentally, I note that 23x and 43x are already rather
crowded! (It seems this could have been postponed by reusing some of the
existing response codes that have identical meanings, e.g, using 436
instead of 431, but backwards comaptibility ties your hands here).
S5: Security Considerations: I suspect that pipelined commands
(espcially CHECK) offer an opportunity for DoS attacks on NNTP servers.
This is not discussed either in this document or the base
specification to which it refers. Maybe some notes about rate limiting
generation of CHECK requests by clients (over and above the requirement
to consider buffer sizes), and possibly the use of 431 responses as a
way to control overloading by servers, might help.
More information about the ietf-nntp
mailing list