woods@hao.UUCP (07/08/87)
>In article <6948@shemp.UCLA.EDU>, dgreen@CS.UCLA.EDU writes: >> It really is time for a USENET constitution, or at least a set of clearly >> specified rules. I think the problem with this is that it is impossible to come up with a set of rules that could cover every possible situation. For example, one of the biggest problems right now is when to create/delete newsgroups. One rule that we'd all like to see is that groups with a large amount of popular support have a better chance of getting created than those that do not. Good, makes sense. Then along comes something like net.rec.drugs. That group had a good deal of popular support, but there was no set of rules in the world that could have forced me to carry it on my machine no matter how much support it had, simply because I would be risking possibly my very livelihood and certainly my site's access to USENET by having a "red flag" like rec.drugs appear in the newsgroup list. Many of the backbone admins felt the same way, and so we refused to create and carry the group despite the fact that it should have been created according to the rules that were in use at the time. The problem was, those rules did not address this situation. OK, we could make a rule that the name can't be controversial, or that newsgroups for popssibly controversial subjects should have "hidden" names (like motss). Fine, assuming everyone agreed to follow such a rule (another debate entirely; in this case that was in fact suggested but refused by those pushing the group). But what about the next unpredicted situation that comes along? The bottom line is, it is the responsibility and duty of the site admin to decide the policies of the net as they apply to his machine. No set of "rules" can force me to do something that is against my better judgment. My decisions, unfortunately, affect a lot of sites downstream from us, but as long as they depend on us for access to the net they have little choice (they are, of course, free to arrange alternate feeds; some of them have done so for groups that we don't carry and just to increase their connectivity -- more power to them). If the backbone admins as a group decide to go against the "official" rules in a given case, it is still going to raise a flame debate, and will still effectively kill a group. Nothing changes. I don't think you can get any site admin in his right mind (backbone or otherwise) to agree to let a committee tell him what groups to carry and not carry on his machine. Don't get me wrong, I'm all for having the rules more clearly stated, and I welcome suggestions, but I can never agree to ALWAYS abide by them. --Greg -- UUCP: {hplabs, seismo, nbires, noao}!hao!woods CSNET: woods@ncar.csnet ARPA: woods%ncar@CSNET-RELAY.ARPA INTERNET: woods@hao.ucar.edu
dgreen@CS.UCLA.EDU (07/08/87)
All followups to "news.groups" please. Let's localize this discussion. In article <772@hao.UCAR.EDU> woods@hao.UUCP (Greg Woods) writes: >>In article <6948@shemp.UCLA.EDU>, dgreen@CS.UCLA.EDU writes: >>> It really is time for a USENET constitution, or at least a set of clearly >>> specified rules. Greg has now flamed this idea three times. My eyebrows are singed. ------------------ CONSTITUTION OBLIGATIONS? ------------------------ A viable USENET Constitution would not obligate a site to do anything. Indeed, like USENET itself, all sites always have the option of backing out: either from backbone responsibility, or from receiving net news at all. USENET has some unstated rules, even now, which if a site doesn't accept, they have little choice but to leave the backbone cabal. The big rule: if you can't carry the load, you can't be a backbone site. Moreover, a viable USENET Constitution would not create a system much different from what we have now. It would create accountability. It would publicize a known structure. The present structure is both unaccountable and unknown, but a structure exists nonetheless. Public knowledge of the USENET structure helps it "make sense" to people. Readers would know who to talk to, and why things happen a particular way. ----------------- WHAT IS KNOWN ABOUT THE CABAL -------------------- This is what *I* know from asking some questions: 1. I don't know whether there is an exact written criteria stating how one joins the "backbone cabal." I know the cabal includes: a. Net administrators from sites well-connected to the rest of the backbone, strategically located, and well-run by a responsive network administrator who wants to be part of the backbone. b. Old backbone cabal people, who used to fall in the above category. 2. Technically, there are three semi-official spokespeople for the backbone cabal who monitor news.groups for newsgroup proposals, speak for the backbone, etc. Unfortunately, it appears that the associated administrative burdens have fallen solely to Gene Spafford, who is not one of the three, but does a good job. Unfortunately, with one person doing the administrative part of this job, periodic lapses were inevitable. Few people outside the backbone know who these "spokespeople" are. They do not speak with "one voice," so what we see from backbone people can appear inconsistent. Sometimes those comments are flame-ridden. Both factors disturb people. 3. There is no stable "backbone chair"; someone who tries to bring the backbone cabal to a consensus. Some people have taken on that role, ad hoc. 4. Some decisions are made at USENIX conferences, but are "ratified" by the backbone cabal since not every backbone site is represented at USENIX. 5. Most cabal decisions are made by e-mail; all decisions by consensus. I know this because I offered to construct a draft USENET Constitution, and started asking Mark Horton questions. Other backbone people I've asked haven't responded. I don't get to watch it work, so this is all I know. Sorry if I got some of it wrong. Is there a place to find this information? Not really. One kind of USENET Constitution simply formalizes what exists. It makes the structure clear. Few people anticipate a USENET revolution, so starting with a writeup of the existing structure makes perfect sense. ------------------- A MUDDY RULE (GROUP CREATION) -------------------- With a Constitution, we can keep "the rules" in one place, and clarify those that are muddy. For example, creation of newsgroups requires: 1. A vote of affected groups, requiring approximately 100 respondents with a clear majority desiring the new group. 2. The backbone cabal retains veto power. Basically it vetoes any group which might endanger the backbone status of any site. We don't know for how long the poll must be taken (and polls have varied from 2 days to 3 weeks), whether there are prohibitions against stating PRO/CON opinions in poll announcements (most have included PRO opinions), we don't really know how many people are required to start one (this also varies widely). We don't know how to kill an unused group (like soc.culture.something). We don't know whether some "controversial" groups should be forced to be moderated. [Personally, I wonder why the backbone doesn't make moderation the RULE rather than the exception, through incentives or whatnot.] -------------------- REPRESENTATIVE DEMOCRACY? ---------------------- Suggested democratizing modifications to USENET: 1. Set up a moderated news.backbone newsgroup, within which backbone discussions occur. Allow only backbone cabal members to post (made more secure by C news). Watching the backbone in action demystifies the backbone, and makes even the unofficial structure more clear. 2. Set up two parallel unmoderated/moderated newsgroups, called news.structure where people discuss the USENET physical and political structure, and news.elections where elections are officially announced. Allow the backbone to call a poll on any idea it wants to, always in news.elections and presumably discussed beforehand in news.structure. Nothing makes it to news.elections without the prior approval of the backbone. 3. Designate a backbone "chair" who would moderate news.backbone for "external" postings from normal folks, and moderate news.elections. 4. Allow two members of the USENET population to run for one year positions on the backbone cabal. Candidates hash it out in news.structure. The election is announced in news.elections. The backbone designates one of its members to count votes. Votes are public, to ensure correct counting. This give "the people" a voice, but not much clout, in the cabal. -------------------- RESPONSES TO GREG ------------------------- > I think the problem with this is that it is impossible to come up with >a set of rules that could cover every possible situation. Agreed, but this isn't a new problem. No government has rules to address every problem. That isn't a reason to embrace anarchy. > The bottom > line is, it is the responsibility and duty of the site admin to decide > the policies of the net as they apply to his machine. I don't exactly agree with this statement, for there are some accepted things about being a backbone site that force a site administrator to choose between remaining in the backbone or leaving, based on net policy. For example, if seismo decided it was unwilling to carry 50% of the USENET standard newsgroups, seismo would not remain in the backbone. Any new seismo administrator would probably not be in the cabal. On the other hand, day-to-day operation of an individual site is exactly as you say. Backbone sites have a little lee-way, but not as much as non-backbone sites. >Nothing changes. This is NOT true. USENET decisions have suffered from: 1. A lack of user knowledge of USENET structure. 2. A lack of diplomacy on the part of some backbone representatives. 3. A lack of input from accountable user representatives. 4. A lack of guidelines for people who want to create a group. 5. A lack of accountability on the part of backbone representatives. (i.e., who ARE they?) 6. A lack of user respect for backbone members because of 1-5. I think I've suggested ways to solve some of those problems. Dan Greening Internet dgreen@CS.UCLA.EDU UUCP ..!{sdcrdcf,ihnp4,trwspp,ucbvax}!ucla-cs!dgreen
mc68020@nonvon.UUCP (07/09/87)
in article <772@hao.UCAR.EDU>, woods@hao.UCAR.EDU (Greg Woods) says: I don't think you can get any > site admin in his right mind (backbone or otherwise) to agree to let a > committee tell him what groups to carry and not carry on his machine. > Don't get me wrong, I'm all for having the rules more clearly stated, and > I welcome suggestions, but I can never agree to ALWAYS abide by them. True enough, in as much as the current news botch (uhm, er...software) doesn't offer adequate flexibility to handle such problems in a reasonable fashion. I think the news software should offer a site newsadmin several levels of options in handling newsgroups (examples:) NULL don't carry it, won' forward it FEED don't carry it for local readers, but WILL forward it CARRY carry it for local readers AND will forward it Isn't all that difficult to cobble up now, is it? (oh, sorry...except for the fact that the almost total lack of documentation in the news software, combined with the unGHODly mess it has become through Ghu only knows how many generations of patching, makes the damned package virtually solid as concrete. Only those who've been playing with the sources for YEARS have any hope of making any sense of it) (separate issue, sorry... see my flamage in lang.c about coding style and documentation) Seriously, I see why the admins at certain sites could run into considerable difficulty carrying certain types, or names, of newsgroups, due to organizational biases. By simply passing them through, without processing them to the local user base, this problem is alleviated, while still making the groups available to the downstream sites. UUCP:{ihnp4,ames,qantel,sun,seismo,amdahl,lll-crg,pyramid}!ptsfa!nonvon!mc68020
sns@tybalt.caltech.edu (Samuel N. Southard) (07/10/87)
In article <604@nonvon.UUCP> mc68020@nonvon.UUCP (root) writes: > Seriously, I see why the admins at certain sites could run into considerable >difficulty carrying certain types, or names, of newsgroups, due to >organizational biases. By simply passing them through, without processing >them to the local user base, this problem is alleviated, while still making >the groups available to the downstream sites. Except for the fact that while they are "passing through" the system they take up disk space. What if a link goes down for a while? The company who ownes the site that is just "passing it along" is using disk space in the days (weeks, months, years?) between times that it can successfully connect. If the owners and/or operators have decided not to carry a group it is probably because either they don't have the disk space, or they simpy don't want that group on their machine. In either case, having it sitting on the disk for who knows how long would be considered unacceptable (at least I would consider it so, if I cansidered it unacceptable to carry the group in the first place). If they are passing it along, then they have to carry it for a while. As has been said before, if the downstream site wants the group bad enough it will make other arrangements. My cat can quack, can yours? genghis!sns@csvax.Caltech.Edu
ahby@meccts.MECC.MN.ORG (Shane P. McCarron) (07/10/87)
In article <604@nonvon.UUCP> mc68020@nonvon.UUCP (root) writes: >Seriously, I see why the admins at certain sites could run into considerable >difficulty carrying certain types, or names, of newsgroups, due to >organizational biases. By simply passing them through, without processing >them to the local user base, this problem is alleviated, while still making >the groups available to the downstream sites. At this site, we have NO available spool space. However, we do feed a number of downstream sites. There are whole classes of groups that we don't "receive" here, but do forward. The way we handle it is this: 1. Our "ME" line in the sys file does not include the groups we don't want. 2. The systems who want those groups do have the groups in their lines in the sys file. 3. We stop unbatching news at 7:00 AM for 2 hours. 4. At 8:00 AM we do our last set of sendbatches (actually, multibatches). 5. At 8:30, I remove all the files in /usr/spool/news/junk. This makes sure that all the downstream sites get all the articles they wanted queued up before I remove them. Of course, this presumes that you are not using the "=" option of uux that news provides. In article <3181@cit-vax.Caltech.Edu> sns@tybalt.caltech.edu.UUCP (Samuel N. Southard) writes: >Except for the fact that while they are "passing through" the system they take up >disk space. What if a link goes down for a while? The company who ownes the >site that is just "passing it along" is using disk space in the days (weeks, months, >years?) between times that it can successfully connect. If the owners and/or >operators have decided not to carry a group it is probably because either they >don't have the disk space, or they simpy don't want that group on their machine. In >either case, having it sitting on the disk for who knows how long would be >considered unacceptable (at least I would consider it so, if I cansidered it >unacceptable to carry the group in the first place). If they are passing it along, >then they have to carry it for a while. To solve this problem, we have a rule. If a site does not pick up its queued stuff by 6:00 PM (we don't queue new downstream news from 8:00 AM to 7:00 PM), it gets thrown away. A site can make special arrangements, but normally it is just removed. I know it sounds a little cold, but with 3 meg of spool space and 6 downstream sites to feed, it needs to be harsh. -- Shane P. McCarron UUCP ihnp4!meccts!ahby, ahby@MECC.MN.ORG MECC Technical Services ATT (612) 481-3589