[NNTP] Fwd: Gen-art review of draft-ietf-nntpext-streaming-05

[Russ Allbery]

Elwyn,

Thank you very much for the comments.  I'm not sure who else on your cc
list would want to receive the ensuing discussion, so I've limited it to
just you; please feel free to forward these comments more widely.

> 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

> 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 may be worth noting that neither existing servers nor our work really
worked directly from RFC 2980 to a large degree.  RFC 2980 was a
retroactive description of a de facto situation (and is also quite brief
in its descriptions).  However, we could probably say more about the
history of this extension and the use of MODE STREAM in the introduction.

> It is also an interesting question as to whether the reference to
> RFC2980 should be normative: I feel it should be.

RFC 2980 is informational and this document is intended to be standards
track.  Wouldn't that rule out a normative reference?

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

This isn't a bad idea, particularly since NNTP has suffered from clashes
in the past (although mostly because NNTP has been developed for quite
some time outside the auspices of the IETF; this is an attempt to bring it
back into the fold).

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

Is this something that's mentioned in the SMTP documents on the same
topic?  Maybe we could just reuse existing text, since the issues should
be about the same.

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

The reference to [NNTP] is normative in the copy that I have.

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

Good point.

> 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 a very good point.

I'm not as sure about the other points you raise, but your message has
been passed along to the working group for further discussion.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>