244 lines
9.5 KiB
Plaintext
244 lines
9.5 KiB
Plaintext
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
|
|
|