💾 Archived View for spam.works › mirrors › textfiles › internet › the-plan captured on 2023-06-16 at 18:52:00.
-=-=-=-=-=-=-
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