nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt

[Jeff Garzik]

Brian Court wrote:
> > There are inherent security problems with being able to ADD groups to
> > a feed.  Because once your customers gain the capability to request
> > new groups from your feed, your customers also gain the ability to
> > define how much of YOUR resoruces (bandwidth, CPU, backlog disk, etc.)
> > they consume.

> Right.  Which means that the only sane default for an extension that
> allows that is "off".  Which means that it won't be used most places,
> which means that most places won't be able to take advantage of the
> "negative control" stuff.  

Thinking more about this and the problem domain itself (that you are
addressing), the more I like your approach.

The fundamental solution is sound.  Since you implemented it as an
extension, it can be easily superceded by a more complete extension at a
later time.

My only suggestion is that you name your extension something that
clearly indicates it is a negative-only dynamic feed adjustment
protocol.  Reasoning is that when a more complete dynafeed spec becomes
available, your extension won't conflict with it...


> > What I mean by this is the upstream (receiving the dynafeed commands) 
> > may store the feed update permanently, just for the current session,
> > until server restart...  the point is, you don't know how long it is
> > stored.  You may want to put some language into the spec addressing
> > that.
> 
> I was trying to say that with
> 
> Implementations MUST treat the restrictions requested by DONTSEND
> commands, as well as the response to the LIST DONTSEND command, as
> valid only for the duration of the NNTP session in which they were
> issued.
>  
> in section 9.  Maybe it could be said more clearly.

Doubt it, I should just read more slowly.

-- 
Jeff Garzik			    Typhoon, Cyclone, Diablo, and INN
http://www.spinne.com/usenet/	           News tuning and consulting