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

[Jeff Garzik]

Joe St Sauver wrote:
> >From: Brian Hernacki <bhern at netscape.com>

> >First, it's not clear how this concept fits into the whole picture. Do
> >two servers exchange feed information periodically? Is it done at the
> >beginning of each feed session?

> In the traditional dynamic feed model, the change would typically be
> instituted by the remote peer in response to a local user request ("Can you
> see if we can get the tw.* hierarchy?") or in response to a local policy
> change ("Bang out binaries; the transit bandwidth is getting smoked.").
> 
> >Second, I think the lack of positive control ("just send me comp.*") is
> >bad. Feeds are generally specified as positive patterns, not negative.
> 
> My experience has been that !*,foo.*,bar.* is far less common than
> patterns like *,!*foo*,!*bar*,!*baz* (with the exclusions most often being
> targeted at high byte volume groups, foreign language hierarchies, or
> leaking corporate/local hierarchies)

It depends on the local policy quite often.   On my news service, in my
Web signup form I specified the default feed as
"!*,alt.*,comp.*,rec.*,..."  All but two of my customers settled with
feed, or added a couple hierarchies besides...


> >A: FEEDCONTROL LIST
> >B: XXX feed speciciation for server A
> >   GROUPS alt.*,comp.*,rec.*
> >   DIST !local
> 
> I think this should also show maxcrosspost (INN's G parameter) and
> any article maximum or minimum size limits (< or > parameters) and
> the list of host names that are aliased out of the outbound stream.

Seconded.

Perhaps a sub-extension should be added here that allows various feed
controls to be defined as the need arises.

For example, it would be nice if a site could request that their feed be
spam-filtered, or not.  (yeah, yeah, I know, all feeds "should" be
filtering.... :))


> It should also explicitly anticipate that a given server might be fed by
> more than one explicitly configured stream, i.e., there might be seperate
> feed objects for small articles and large articles, or seperate feed objects
> for alt groups and for everything else, say. Each of those seperate feed
> objects should ideally be individually identified and adjustable.

Seconded.  This is common practice (several feeds to one site, split by
article size) in the Cyclone world.


> >A: FEEDCONTROL GROUPS comp.*,rec.*
> >B: XXX OK, change made
> 
> I'd suggest also permitting a return code indicating that the changes have
> been accepted, but will not take effect until some future time (i.e., I don't
> want a remote peer forcing reloads on a busy feed-only host at random times
> and at unpredictable/frequent intervals).

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