From sob at academ.com Mon Mar 2 12:08:30 1998 From: sob at academ.com (Stan Barber) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions I-D ACTION:draft-ietf-nntpext-dynfeed-00.txt Message-ID: <199803021808.MAA20310@academ.com> This is the first I have seen of this draft. I am not aware that it was a work item of the working group, so I am researching how that came about. In the meantime, you are welcome to comment it on it in the nntp-extensions mailing list where discussions of extensions belong. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From jeff.garzik at spinne.com Tue Mar 3 00:10:31 1998 From: jeff.garzik at spinne.com (Jeff Garzik) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions I-D ACTION:draft-ietf-nntpext-dynfeed-00.txt References: <199803021808.MAA20310@academ.com> Message-ID: <34FB4A77.76F35B7D@spinne.com> The corrected URL is ftp://ftp.ietf.org/internet-drafts/draft-court-dynfeed-00.txt Looks interesting, but the specification may complicate implementation somewhat. Possible security issues, but overall a good idea. Reading over it now... :) -- Jeff Garzik Typhoon, Cyclone, Diablo, and INN http://www.spinne.com/usenet/ News tuning and consulting From launch at LAUNCHMASTER.COM Mon Mar 2 21:43:30 1998 From: launch at LAUNCHMASTER.COM (launch@LAUNCHMASTER.COM) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions Your Web Site Re-Launch Message-ID: <199803030243.VAA22973@ns.LAUNCHMASTER.COM> To: nntp-extensions@academ.com Need a re-launch? Launchmaster will re-launch your web site to 50 search engines and indexes for $95. Satisfaction guaranteed! Millions of people use search engines to find web sites every day. But if your site isn't listed, no one will find it. Launchmaster will re-launch your site by submitting it to the top 50 search engines for $95. Here's how to do it: 1. Complete the form below and return it to us. 2. We'll post your site to 50 search engines within two business days, and we'll send you a complete report when we're finished. 3. Pay nothing now. We'll send you an invoice after we've completed the posting. Your satisfaction is guaranteed! These are permanent listings. The $95 is a one-time fee. WHICH SEARCH ENGINES? Here's the list: Excite, Alta Vista, Infoseek, Galaxy, HotBot, Lycos, Magellan, Open Text Web Index, Web Crawler, BizWeb, New Riders WWW Yellow Pages, LinkMonster, True North, Northern Light, YelloWWWeb, The Weekly Bookmark, Scrub The Web, Seven Wonders, Sserv, Starting Point, Web 100, Web Walker, Net-Announce, New Page List, One World Plaza, PageHost A-Z, PeekABoo, Project Cool, Where2Go, World Wide Business Yellow Pages, Wow! Web Wonders!, WWW Worm, JumpCity, The Galactic Galaxy, TurnPike, Unlock:The Information Exchange, Your WebScout, Manufacturers Information Network, Net Happenings, Net Mall, Web World Internet Directory, InfoSpace, Jayde Online Directory, BC Internet, BizCardz Business Directory, WebVenture, Hotlist, What's New, WhatUSeek, JumpLink, Linkcentre Directory. ORDER FORM Hit the REPLY button on your e-mail program and fill out the following information. (This information will be posted to the search engines/indexes): Contact name: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: Contact e-mail address (in case we have questions about this order): URL: http:// Site Title: Description (250 characters): Key words (250 characters, in descending order of importance): If billing a different address, please complete the following: Addressee: Company Name: Address: City: State/Prov: Zip/Postal Code: Telephone: Fax: Email address: TERMS Terms are net 15 days from date of invoice. ______________________________________________________________________ Launchmaster, Inc. 12 Godfrey Place Wilton CT 06897 Phone: (203) 834-5823 Fax: (203) 834-1897 E-mail: launch@launchmaster.com From bhern at netscape.com Wed Mar 4 09:15:10 1998 From: bhern at netscape.com (Brian Hernacki) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt References: <199803021808.MAA20310@academ.com> Message-ID: <34FD8C1E.877BFE50@netscape.com> Just a couple thoughts after a quick reading. While I think the idea of adding a dynamic feed control method to the protocol is long overdue, I'm not sure this is the way to do it. Maybe the draft just needs to be clarified. 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? Second, I think the lack of positive control ("just send me comp.*") is bad. Feeds are generally specified as positive patterns, not negative. I'd put some thought into dynamic feed control a little while ago and the notion I'd been settling on was an additional set of verbs which servers would use at some periodic interval (seperate from the feeds sessions) to communicate feed changes. Picture two servers A and B. A wants B to stop sending it the alt.* groups, so it opens up a connection and tells B that. It would go something (roughly) like: A: B: A: LIST EXTENSIONS B: 215 Extensions supported by server. FEEDCONTROL . A: FEEDCONTROL LIST B: XXX feed speciciation for server A GROUPS alt.*,comp.*,rec.* DIST !local . A: FEEDCONTROL GROUPS comp.*,rec.* B: XXX OK, change made At this point server A would stop queueing up articles from alt.* to send to B. This seems pretty lightweight since it would only be fired when changes need to be made. --brian From bac at csu.net Wed Mar 4 09:56:11 1998 From: bac at csu.net (Brian Court) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <34FD8C1E.877BFE50@netscape.com> from "Brian Hernacki" at Mar 4, 98 09:15:10 am Message-ID: <199803041756.JAA19247@mugwort.csu.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 1712 bytes Desc: not available Url : http://www.academ.com/pipermail/nntp-extensions/attachments/19980304/8d428dd6/attachment.ksh From JOE at oregon.uoregon.edu Wed Mar 4 10:04:44 1998 From: JOE at oregon.uoregon.edu (Joe St Sauver) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt Message-ID: <01IU9IVT2LME8WWGDW@OREGON.UOREGON.EDU> >Date: Wed, 04 Mar 1998 09:15:10 -0800 >From: Brian Hernacki >Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt >To: nntp-extensions@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 From mcr at sandelman.ottawa.on.ca Wed Mar 4 13:09:06 1998 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: Your message of "Wed, 04 Mar 1998 09:15:10 PST." <34FD8C1E.877BFE50@netscape.com> Message-ID: <199803041809.NAA01288@morden.sandelman.ottawa.on.ca> -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Brian" == Brian Hernacki writes: Brian> picture. Do two servers exchange feed information Brian> periodically? Is it done at the beginning of each feed Brian> session? The draft seems to suggest that it occurs whenever an article is received that doesn't meet the receiving site's criteria. One worry that I have is that it won't work very well with streaming. Brian> Second, I think the lack of positive control ("just send me Brian> comp.*") is bad. Feeds are generally specified as positive Brian> patterns, not negative. Agreed. Brian> wants B to stop sending it the alt.* groups, so it opens up Brian> a connection and tells B that. It would go something Brian> (roughly) like: The problem with a seperate connection is that feeds may not quite work that way. Right now, it isn't unusual to have things like: --> ispinfeed --> ispoutfeed ^ | | V customer news box Sometimes ispoutfeed is feed using the INN SLAVE feature. Now, which host does the customer news box connect to? Obviously, ispoutfeed. Sometimes the feeds are split based on hierarchies, so one winds up contacting multiple feed machines for cross posted articles. Not a big deal, but something that needs to be clear. ] IPsec testing workshop #5, Raleigh, NC. I love airports | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQBVAwUBNP2Yvh4XQavxnHg9AQEwagIAlXxEz+OXr85gnDemTdcrJpqDNDQZA22T iIyIZHumUuYbBn++Hc5rQqFFRauzqCFmJWzefi+KDFqCgaXkwqCn6g== =7u8X -----END PGP SIGNATURE----- From jeff.garzik at spinne.com Wed Mar 4 14:04:43 1998 From: jeff.garzik at spinne.com (Jeff Garzik) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <199803041756.JAA19247@mugwort.csu.net> from "Brian Court" at Mar 4, 98 09:56:11 am Message-ID: <199803041904.OAA05297@pretzel.normnet.org> > > > > Just a couple thoughts after a quick reading. While I think the idea of > > adding a dynamic feed control method to the protocol is long overdue, > > I'm not sure this is the way to do it. Maybe the draft just needs to be > > clarified. > > Could be. Maybe I should start by saying that I wasn't trying to > solve the whole dynamic feed control problem. I was just responding > to a problem that I as a news admin see, which is that many of my > downstream sites believe, deep in their souls, that the way to not > carry a group is "ctlinnd rmgroup". My attempts to educate them to > the contrary have not been successful. So I was just trying to deal > with the ugliness of having to send lots of /dev/null fodder, because > I have no good way to know what groups my downstream sites are > bitbucketing. It's a problem, but if you are going to update the official spec, may I suggest that solving the *whole* dynamic feed control problem is a better approach than fixing "point" problems with domain-specific solutions. However, there is one point implied in your solution that should be recognized as very important: 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. The current dynafeed proposal only allows the downstream to REMOVE groups from their feed, not add them, which is good. Another point: Dynafeed controls define NOTHING about upstream server state. 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. -- Jeff Garzik Typhoon, Cyclone, Diablo, and INN http://www.spinne.com/usenet/ News tuning and consulting From bac at csu.net Wed Mar 4 10:58:15 1998 From: bac at csu.net (Brian Court) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <199803041904.OAA05297@pretzel.normnet.org> from "Jeff Garzik" at Mar 4, 98 02:04:43 pm Message-ID: <199803041858.KAA19566@mugwort.csu.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 1238 bytes Desc: not available Url : http://www.academ.com/pipermail/nntp-extensions/attachments/19980304/545e378c/attachment.ksh From jeff.garzik at spinne.com Wed Mar 4 14:43:06 1998 From: jeff.garzik at spinne.com (Jeff Garzik) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <199803041858.KAA19566@mugwort.csu.net> from "Brian Court" at Mar 4, 98 10:58:15 am Message-ID: <199803041943.OAA05476@pretzel.normnet.org> 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 From mcr at sandelman.ottawa.on.ca Wed Mar 4 14:33:58 1998 From: mcr at sandelman.ottawa.on.ca (Michael Richardson) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: Your message of "Wed, 04 Mar 1998 10:58:15 PST." <199803041858.KAA19566@mugwort.csu.net> Message-ID: <199803041934.OAA01434@morden.sandelman.ottawa.on.ca> >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. That seems useless to me. a) I think we have some NNTP authentication stuff available. b) the truly paranoid can run NNTP over SSL (if you have enough CPU) c) we can use some kind of one-time password for the authentication ] IPsec testing workshop #5, Raleigh, NC. I love airports | SSH IPsec [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |international[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |strong crypto[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ From jeff.garzik at spinne.com Wed Mar 4 16:10:04 1998 From: jeff.garzik at spinne.com (Jeff Garzik) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <199803041934.OAA01434@morden.sandelman.ottawa.on.ca> from "Michael Richardson" at Mar 4, 98 02:33:58 pm Message-ID: <199803042110.QAA06000@pretzel.normnet.org> Michael Richardson wrote: > >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. > > That seems useless to me. > a) I think we have some NNTP authentication stuff available. > b) the truly paranoid can run NNTP over SSL (if you have enough > CPU) > c) we can use some kind of one-time password for the authentication hmmm, the reasons you give don't seem to have anything to do with the reasoning behind the "valid only for the duration".. This is an issue about whether the server implementation (on the upstream server) should maintain state with regards to the DONTSEND commands. ie. "Should I permanently update my newsfeeds file when a DONTSEND is received, or should I just make DONTSEND changes to the current session?" And I think the latter is the smarter way to go. -- Jeff Garzik Typhoon, Cyclone, Diablo, and INN http://www.spinne.com/usenet/ News tuning and consulting From bac at csu.net Wed Mar 4 14:01:06 1998 From: bac at csu.net (Brian Court) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt In-Reply-To: <199803042110.QAA06000@pretzel.normnet.org> from "Jeff Garzik" at Mar 4, 98 04:10:04 pm Message-ID: <199803042201.OAA20328@mugwort.csu.net> A non-text attachment was scrubbed... Name: not available Type: text Size: 779 bytes Desc: not available Url : http://www.academ.com/pipermail/nntp-extensions/attachments/19980304/7327c26b/attachment.ksh From jeff.garzik at spinne.com Thu Mar 5 01:11:28 1998 From: jeff.garzik at spinne.com (Jeff Garzik) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt References: <01IU9IVT2LME8WWGDW@OREGON.UOREGON.EDU> Message-ID: <34FDFBC0.BB8A2DE5@spinne.com> Joe St Sauver wrote: > >From: Brian Hernacki > >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 From bhern at netscape.com Thu Mar 5 14:18:52 1998 From: bhern at netscape.com (Brian Hernacki) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt References: <01IU9IVT2LME8WWGDW@OREGON.UOREGON.EDU> Message-ID: <34FF24CC.B0F2E0A3@netscape.com> Joe St Sauver wrote: > > >Date: Wed, 04 Mar 1998 09:15:10 -0800 > >From: Brian Hernacki > >Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt > >To: nntp-extensions@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 From JOE at oregon.uoregon.edu Thu Mar 5 14:43:02 1998 From: JOE at oregon.uoregon.edu (Joe St Sauver) Date: Sun Dec 7 20:19:22 2003 Subject: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt Message-ID: <01IUB6QO5J5U8WWGI9@OREGON.UOREGON.EDU> >Date: Thu, 05 Mar 1998 14:18:52 -0800 >From: Brian Hernacki >Subject: Re: nntp-extensions feedback on draft-ietf-nntpext-dynfeed-00.txt >To: Joe St Sauver >Cc: nntp-extensions@academ.com [deletions] >> 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. I concur. I really like the approach for this that Highwind takes -- i.e., you can create a DefaultAdditionalSubscription that applies AFTER any site specific subscription, and which serves the purpose of overriding any evil feed specification a peer might have given to you in a cut and pasteable feedpsec. For example, you might do: DefaultAdditionalSubscription !*binaries*,!clari.* or whatever you ALWAYS want to prevent from going downstream. That provides "policy insurance" against unanticipated leaks. Oh yes: ideally speaking, the remote peer would be told if a requested feed change clashed with the "DefaultAdditionalSubscription" so they don't wonder why their repeated requests to add clari.* and *binaries* (or whatever) don't result in any traffic. Regards, Joe