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

[Clive D.W. Feather]

Russ Allbery said:
> I also do't believe that RFC2980 
> is an Informative reference: There is a degree of backwards 
> compatibility which makes RFC2980 Normative.

Here and later: my understanding of "normative reference" is that it
indicates documents which need to be understood to implement the document
making the reference. That isn't the case for 2980 - it helps to see *why*
certain decisions were made, but you can implement all the new NNTP
documents without knowing anything inside 2980.

> 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 disagree: it might be better swapped with 2.2, but it should come before
the commands defined in the specification.

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

And the TLS one. However, once again I disagree with your interpretation of
the rules. The Instructions to RFC Authors says:

    Normative references
    specify documents that must be read to understand or implement the
    technology in the new RFC, or whose technology must be present for
    the technology in the new RFC to work.

In the base document, the only purpose of these references is to say "this
entry in the registry is [reserved] for this document". That's informative
as I see it - you can implement all of NNTP without reading those documents.

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

I can sympathise with this viewpoint, but I wouldn't like it to hold us up.
Should we look at doing it as a separate document?

It is worth noting that you can always tie a response to the command that
caused it, so collisions aren't as big an issue as in a protocol that has
unsolicited responses. Ensuring consistency and uniqueness in responses just
allows for other program designs, but is not essential.

> S5: Security Considerations:  I suspect that pipelined commands 
> (espcially CHECK) offer an opportunity for DoS attacks on NNTP servers. 

I'm not sure why this is the case over and above any protocol that uses
TCP. The pipelined commands will simply sit in the receiver's buffer until
they are read. There is no requirement for the server to do its own
buffering of these commands while responding to them.

The base document does mention the danger of deadlock, but I'm not sure how
to turn that into an attack.

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

I still don't follow. A string of 431s won't necessarily cause the client
to stop doing CHECKs, particularly if it's a malicious one.

Can you explain how a string of (pipelined) CHECKs is a particular threat?
Compared with, say, a string of (pipelined) STATs?

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |