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

[Russ Allbery]

Ken Murchison <ken at oceana.com> writes:

> I would think that any text we craft regarding CHECK would also apply to
> IHAVE (the first step).

> It would seem to me that TAKETHIS is more worrisome if the peer just
> starts flooding the pipe with articles that the server doesn't
> want. Should we say something along the lines like "if the number of
> rejected TAKETHIS commands exceeds an implementation specific threshold,
> the server SHOULD/MAY terminate the session with a 400 response".

The difference with CHECK, and the thing that it allows you to do that
IHAVE doesn't (and TAKETHIS doesn't) is that you can prevent a host from
ever receiving an article by repeatly claiming you're going to send it
with CHECK and then never sending it.  You can't really do that with IHAVE
since you can only offer one article at a time and then either need to
spit out an article or abort the connection.  With CHECK, though, you can
send a whole flood of message IDs without ever stopping.

Whether this is important enough to care about, I'm not sure.  I don't
think it really is, since a peer can also give you a corrupted or fake
article with IHAVE and prevent you from getting the real one.

I suppose the other concern is that CHECK makes the server do more work
per KB of bandwidth than TAKETHIS, since the server has to check each
message ID against the history database.  I think that's more what the
original review comment was about, but I agree with others who have said
that LISTGROUP and the like are even worse.

I'm not seeing anything here that's particularly compelling to comment
about, but if anyone else does, given the above, please speak up.

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