From owner-operlist@cs.bu.edu Mon Jul 15 16:33 EDT 1991 Received: from CS.BU.EDU by chaos.cs.brandeis.edu Mon, 15 Jul 91 16:33:09 edt Received: by cs.bu.edu (5.61+++/SMI-4.0.3)
id AA03347; Mon, 15 Jul 91 15:21:01 -0400
Return-Path: jennifer@algol.astro.virginia.edu Received: from BU.EDU by cs.bu.edu (5.61+++/SMI-4.0.3)
id AA03341; Mon, 15 Jul 91 15:20:55 -0400
Received: from uvaarpa.Virginia.EDU by BU.EDU (1.99) Mon, 15 Jul 91 13:39:46 EDT Received: from algol.astro.Virginia.EDU by uvaarpa.Virginia.EDU id aa26499;
15 Jul 91 13:39 EDT
Received: by algol.astro.Virginia.EDU (5.61/1.34)
id AA06657; Mon, 15 Jul 91 13:36:10 -0400
Date: Mon, 15 Jul 91 13:36:10 -0400 From: jennifer@algol.astro.Virginia.EDU (Jennifer Wesp) Message-Id: 9107151736.AA06657@algol.astro.Virginia.EDU To: operlist@cs.bu.edu Subject: the.PLAN Status: RO
This is the set of rules for the.PLAN as they now stand. additional commentary would be appreciated.
Rules for Opers in the.PLAN
- Jennifer Wesp (July 1991)
The "enforcement" of these will continue much as it has been. Talk to the oper in question if there is an oper related problem, or mail the server admin if the trouble is with the server. (If the oper ignores you then also go to the server admin) The only "new" idea is that a stronger emphasis should be placed on the next server up the line, if the admin of the server that is a problem proves unhelpful. The last line of recourse is to request of the links to the "bad" server that the links be cut.
1) No kills.
- Exceptions:
Ghosts.
Evading Ignore. "Stealing" chanop.
2) No squits.
- Exceptions:
You can squit links to your own server, but if you
need to squit one you should probably rethink your Y: lines. You can squit to fix a routing that puts Europe in the middle of two groups of US servers. (or Japan, or Australia...)
3) No wallops.
- Exceptions:
Discussion of impending squits.
Discussion of impending Q: lines, suspected hacked servers, or other things that are prohibitted. The majority of the discussion should go to a channel, however.
4) No Walls.
- Exception:
War has broken out, the Big One hit California, or
there is a large meteor on it's way. There should be only one wall in such an event.
Commentary by Greg Lindahl:
1) KILL is fairly useless these days. With an autoreconnect
client, for example, it's impossible to keep someone off of IRC by killing them repeatedly. You'll piss off all the other operators long before you stop the bad guy. Likewise, if someone has a hacked server that allows them to steal channel op repeatedly, or evades /ignore of user@host repeatedly, killing them a bunch won't help. Killing them once might send a message, but if they persist, a complaint to a server or site administrator will be much more effective than other measures.
Other sorts of things (i.e. being rude on a channel) should be dealt with by channel operators. That's what they're for. We hope to add /disinvite soon.
2) With the new routing plan, SQUIT will not be needed as much.
An SQUIT of a major link causes a lot of network traffic, and inconveniences the users. Properly designed routing means that most of the time, routing will look good -- it becomes a statistical process, and we're using the connect frequencies as weights to bias the process towards the Right Answer. So, no squits.
3) There is a wide difference of opinion what wallops are for.
If you want to hold a conversation with a lot of operators, you're probably better off using a channel and issuing a single wallops advertising the disucssion. Remember that LOTS of silent operators are on-line at any one time and many of them won't be interested in what you have to say.
4) Think of WALL as the equivalent of posting to
news.announce.newgroups -- you don't want to abuse it because you don't want everyone to start ignoring all walls. Again, there is a difference of opinion about this. But I think that the vast majority think that walling birthdays, for example, is a bad idea. This doesn't even begin to address situations such as IRC users who don't speak english getting walls in english, or someone walling happy birthday in Swahili, Japanese, Russian, and 19 other languages to make sure that everyone can understand it.
######
Rules for servers
- Jennifer Wesp (Phaedrus) July, 1991
The "enforcement" of these will continue much as it has been. Talk to the oper in question if there is an oper related problem, or mail the server admin if the trouble is with the server. (If the oper ignores you then also go to the server admin) The only "new" idea is that a stronger emphasis should be placed on the next server up the line, if the admin of the server that is a problem proves unhelpful. The last line of recourse is to request of the links to the "bad" server that the links be cut.
1) No server-open servers.
*Consequently it is BAD to give links that are not for servers that are in constant use, because then anyone can set a server up that has access to that machine and connect to you, if the "right" server is not around. Also, infrequently used links should be passworded.
2) No "hacked" servers.
- This includes at least:
Servers that record messages in any way such that
anyone save the intended recipients can read them. Servers that give channel op to anyone other than the person who started the channel, or any subsequent people that were given channel op by other channel ops. Servers that generate any false message, ie fake server kills, squits, nick changes, etc.
3) All servers must be within one major version of current.
- This assumes (so far with reason) that major version
changes will cause incompatibility with old servers,
and that is to be minimised. Also that administration of a given server should be able to upgrade it every 4-5 months, or it can be considered defunct.
4) No destructive testing of the network.
- This includes at least:
KillBots that generate repeated kills
Any change to servers that disrupts traffic flow for any server other than the one in question. AutoReconnecting Clients without time delays. Q-lining without ALL superhubs doing it simultaneously, along with a majority of the hubs.
5) No more than one server per site.
- Assuming that one server can provide adequate coverage for
at least one site. If this is not so then adding a new
server or moving the old one can be discussed. Our first priority is serving users, not creating servers just so more people can be operators.
Commentary by Greg Lindahl:
1) This is a security issue we haven't dealt with much in the
past; however, someday someone is going to hack a nameserver just to use an unused, unpassworded link. An ounce of prevention, etc.
2) The major controversey here is whether or not it's "ok" in
some circumstances to create channel ops when none are present. I think not, for 3 reasons:
A) It's only appropriate when everyone on the channel agrees.
There are some users who don't like channel operators and avoid channels which have channel operators. So it's unfair for them to join (or even create) a channel with no channel operators, and see the rules changed before their very eyes.
B) It gets abused when it exists. This is an unfortunate
reality.
C) It's yet another special thing that an operator can do.
We're trying to make operators have as few special powers as possible.
3) We can't move forward unless people keep up. Running an IRC
server, unfortunately, takes a relatively large committment of time. Someday it won't, but for now... for example, the implementation of /disinvite that I have in mind won't work until everyone upgrades. The ^G bug won't be history until everyone patches or upgrades. Mode +n didn't work until everyone upgraded. And so on.
4) There is an alternative net for experiments, if you need to
do so. The main IRC net should be considered a "production" system, mainly here so people can talk to each other. Putting in some Q-lines in some places results in a network split, which means people can't talk. Bad.
5) Some people claim that everyone has the RIGHT to be an
operator, because it's a privledge. I think it's the other way around: being an operator is a burden, should be used for technical reasons, and should be open to individuals who have the technical knowledge to use it.
Likewise, it's not efficient for there to be one server per user. IRC has a large amount of overhead to support a server. Since we can serve people remotely, it's better to have fewer servers and more users per server.
######
Rules for Superhubs
- Jennifer Wesp (July 1991)
1) Superhubs work as a group.
This means that all policy decisions must be agreed upon by all Superhub admins. In case of an unresolvable problem that requires action the minority should resign if it finds it cannot agree with the action to be taken. I would assume, however, that this should never be required. (Refers to Q: lining, link cutting, adding new code, and anything else where inconsistency across a high traffic link will cause trouble.)
2) Superhubs are expected to be patched within 24hrs notice
as required.
This means that multiple people <must> be knowledgable enough and available enough to be around pretty much all of the time, and d owhat needs to be done. a suggested method for this would be to, if possible, give another active admin access to the server code and .conf of your server.
-jennifer