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

[Brian Hernacki]

Joe St Sauver wrote:
> 
> >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)

I'd like to deal with postivie and negative feed control. I realize
access control is an issue but I think it can be solved pretty neatly
with what's already in the protocol.

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

These are all good ideas. As I refine my work into an ID, I'll add
these.

--brian
Opinions are mine, not Netscape's