Draft:  draft-ietf-nntpext-streaming-05.txt
Reviewer: Elwyn Davies
Date: 2 June 2005

Trigger: IETF Last call, ending 7 June 2005
AD: Scott Hollenbeck
Document Shepherd: Russ Allbery

Intended status: Proposed Standard

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.