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

[Joe St Sauver]

>Date: Wed, 04 Mar 1998 09:15:10 -0800
>From: Brian Hernacki <bhern at netscape.com>
>Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt
>To: nntp-extensions at academ.com

[deletions]

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

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

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.

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

Regards,

Joe