Subject: the.PLAN

From: [email-masked] (Jennifer Wesp)
Date: Mon, 15 Jul 91 13:36:10 -0400

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