IETF Logo Mail Archive

Re: ietf-nntp Initial draft FINALLY available

"William H. Magill" <magill@isc.upenn.edu> Wed, 02 October 1996 21:39 UTC

Received: from cnri by ietf.org id ak08783; 2 Oct 96 17:39 EDT
Received: from PHEASANT.ACADEM.COM by CNRI.Reston.VA.US id aa20449; 2 Oct 96 16:20 EDT
Received: (from majordom@localhost) by pheasant.ACADEM.COM (8.7.5/8.7.3) id PAA25593 for ietf-nntp-outgoing; Wed, 2 Oct 1996 15:06:40 -0500
X-Authentication-Warning: pheasant.ACADEM.COM: majordom set sender to owner-ietf-nntp using -f
Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by pheasant.ACADEM.COM (8.7.5/8.7.3) with ESMTP id PAA25589 for <ietf-nntp@PHEASANT.ACADEM.COM>; Wed, 2 Oct 1996 15:06:37 -0500
Received: from staff.dccs.upenn.edu (STAFF.DCCS.UPENN.EDU [130.91.72.67]) by academ.com (8.7.6/8.7.1) with ESMTP id PAA00935 for <ietf-nntp@academ.com>; Wed, 2 Oct 1996 15:06:34 -0500 (CDT)
Received: (from magill@localhost) by staff.dccs.upenn.edu (8.7.4/8.7.3) id QAA19979; Wed, 2 Oct 1996 16:06:15 -0400
Date: Wed, 2 Oct 1996 16:06:15 -0400
From: "William H. Magill" <magill@isc.upenn.edu>
Message-Id: <199610022006.QAA19979@staff.dccs.upenn.edu>
to: ietf-nntp@academ.com
Subject: Re: ietf-nntp Initial draft FINALLY available
Sender: owner-ietf-nntp@academ.com
Precedence: bulk

>   > > >            12.4 NEWNEWS
>   > > 
>   > > Do we have to keep this?  It really doesn't work in a practical way in some 
>   > > of the widely used NNTP implementations.
>   > 
>   > Any other opinions about this.
>
>   NEWNEWS is used by sites using pull/slurp. Most ISPs who use INN have
>   some concerns allowing the NEWNEWS command. INN itself being a heavy
>   resource utilizing process, the way NEWNEWS is implemented causes several
>   thousand directory lookups and history file lookups. This adds to the
>   burden on the machine. Most people disable NEWNEWS if they dont support
>   pull/feed capabilities. 
>
>   Causing this command to be not there in RFC would force you to come up
>   with something else that will support pull feeders ? Or may be it is 
>   time for pull-feed software developers to use a better slurping mechanism
>   and they can help contribute to the RFC. Or even better, that you could
>   have it for now and we can have more discussion on this before removing
>   or keeping this command.

I believe that the general concensus of folks at the INN tutorial here  at
LISA this week is that "sucking feeds" are a bad thing.

For one thing, most "sucking feeds" are not legit feeds in the first place,
but rather people running readers, or pretending to be runing readers,
which are in fact servers. Usually, at least in my experience, "sucking
feeds" are created by people who really have no idea what they are doing or
how to do things the "correct" way - ie by signing up to receive a feed.

The bigest reason that sucking feeds are a bad thing for servers is that it
prevents the server operator from utilizing the little bit of control
capabilities which exist in the feeding side of news.

People who are running sucking feeds tend to believe that they have a right
to news right now, even though their actions are in direct conflict with
the desires and demands of others.

Until there are some major changes in the news database strcture, NEWNEWS
as an optional command is a tolerable evil, preferrably something which can
be commented out.

T.T.F.N.
William H. Magill                          Senior Systems Administrator
Information Services and Computing (ISC)   University of Pennsylvania
Internet: magill@isc.upenn.edu             magill@acm.org
          magill@upenn.edu                 http://pobox.upenn.edu/~magill/

v2.8.7 | Report a Bug | By Email