F I D O N E W S -- Vol.11 No.37 (12-Sep-1994)
-----------------------------+-----------------------------------------
A newsletter of the | ISSN 1198-4589 Published by:
FidoNet BBS community | "FidoNews" BBS
_ | +1-519-570-4176
/ \ |
/|oo \ | Small animal psychology and
(_| /_) | Spiritual guidance Department:
_`@/_ \ _ | Rev. Richard Visage 1:163/409
| | \ \\ |
| (*) | \ )) | Editors:
|__U__| / \// | Donald Tees 1:221/192
_//|| _\ / | Sylvia Maxwell 1:221/194
(_/(_|(____/ | Tim
(jm) | Newspapers should have no friends.
| -- JOSEPH PULITZER
-----------------------------+------------------------------------------
Submission address: editors 1:1/23
------------------------------------------------------------------------
MORE addresses: submissions=>
[email protected]
Don --
[email protected]
Sylvia --
[email protected]
Tim Pozar --
[email protected]
David Deitch -- 1:133/411.411,
[email protected]
------------------------------------------------------------------------
For info about copyrights, article submissions, obtaining copies of
snooze or the internet gateway faq please refer to the end of this file.
========================================================================
Table of Contents
========================================================================
1. Editorial: why is this in my mailbox?......................... 2
2. Articles...................................................... 2
Backbone Echo Changes [Jul-Aug]............................. 2
Software Museum............................................. 3
Has the Structure of Fidonet Had Its Day?................... 4
Dear Reverend Visage,....................................... 6
Remote Access - False Security Promotion.................... 8
Gating from FidoNet, banned................................. 11
Election Announcement - Zone One Echomail Coordinator....... 12
Dear MADam emilia........................................... 14
FidoNet Excommunication - An interpretation................. 14
3. Fidonews Information.......................................... 18
FidoNews 11-37 Page: 2 12 Sep 1994
========================================================================
Editorial
========================================================================
A truly amazing bit of mail arrived this week. As i read the
first bit of it, which was erotic creative writing, i thought it
was an echo ad for the GAY_TEEN echo, and i thought, "oh well, here
we go again, this will provoke some controversy but it is interesting
and not at all offensive".
Then, i reached the bottom line. Someone had quoted pages of
a message from some echo, then tacked a few phrases on the end
complaining that they had had to read the echo message when they turned
on their computer and suggesting policy fru-fra. If someone doesn't
want to read something, why would they assume no-one else wants to read
it, then quote what they assume no-one wants to read and re-send it so
more people can read it? What happened to self-censorship and pressing
return keys?
Mind boggling.
On a less befuddled note, a FidoCon is going to happen "in"
South Western Obtario during the second week of August next year.
Please check upcoming snooze issues for more info.
I'm passing this file to Don's computer now to see if i can
induce him to explain geonets <Evil GrIN>...
... Max, geonets are inexplicable ...
========================================================================
Articles
========================================================================
Backbone Echo Changes [Jul-Aug]
by Lisa Gronke, 1:105/6
[email protected]
Summary of backbone & quasi-backbone echo changes during Jul & Aug.
Brought to you courtesy of (unix) diff.
diff (fidonet.na + fidonet.no) 03-Jul-94 (ditto) 04-Sep-94 [edited].
Added to the backbone
---------------------
> AIDS.DATA READ ONLY News Group Relating to AIDS/HIV
> APOGEE Apogee Support Conference
> CDOOR RBBS/CDOR Support, Development & Users
> CROSS_STITCH Cross Stitchers Conference
> DOOM Official DOOM Support Echo
> INK Desktop Publishing & Word Processing
> MICROCOM Microcom Modem Support Echo
> MUSE Muse Studio (Poetry Discussion)
FidoNews 11-37 Page: 3 12 Sep 1994
> OLDTRUCK Old Trucks and Related Topics
> REENACT Reenacting & Living History Echo
> STOP_SMOKING Stop Smoking
> TRIBBS_SUPPORT TriBBS Support - The Official Conference
Echotag changes
---------------
< HST US Robotics high speed modem disc. [old name]
> USR_MODEMS US Robotics high speed modem disc. [new name]
Removed from the backbone or quasi-backbone
-------------------------------------------
< CRASH (not in EchoList since 3/1/94)
< DBTECH (not in EchoList since 9/1/93)
< QNX QNX Software Systems LTD QNX OS
< SCIFOR VortexNet/c-128 Support conference
< USS_LIBERTY USS Liberty (AGTR-5) Incident of June 8, 1967
o There are 625 echos in fidonet.na [04-Sep-94] (up 3)
o There are 43 echos in fidonet.no [04-Sep-94] (up 6)
o for a total of 668 backbone & quasi-backbone echos (up 9)
o two echos, BIBLE & HOBBIES, are available from the Zone STARS but
not in the FidoNet bundles from Planet Connect.
----------------------------------------------------------------------
SOFTWARE MUSEUM
Dear all,
I have visited the Science Museum in London and in Manchester. Both
have an exhibition about computers. I find them boring, I mean there
is nothing exciting on an old black box or a dusty PCB. I think the
'soul' of the electronical computer is the software. Hey, here comes
my idea:
A SOFTWARE MUSEUM SHOULD BE ESTABLISHED
RATHER THAN A HARDWARE EXHIBITION.
Here you are my initial ideas:
* The museum should consist of ancient softwares (such as FORTRAN
compilers :-) and operating systems. These stuffs should be
emulated, allow the 'visitors' to pick up some experience about how
hard the life was before the invention of the high-level languages,
for instance.
* The exhibited items (simulators) should be public domain softwares,
written by computer enthusiasts.
* There is no need for a museum building. The whole exhibition can be
implemented 'virtually' via WWW, anonymous ftp, or on a CD ROM.
FidoNews 11-37 Page: 4 12 Sep 1994
* Furthermore, photos, animated diagrams, texts and multimedia objects
can be included, to describe the ancient hardware.
If you are interested in the software museum, have further ideas and
feel like helping to set up this 'museum', please contact me at my
private address rather than via this mailing list, as I am not a
subscriber of this newsgroup :-(
My e-mail address:
[email protected]
Regards,
Peter Mork
( 2:370/23.3 )
----------------------------------------------------------------------
HAS THE STRUCTURE OF FIDONET HAD ITS DAY?
Keith Jackson,
2:2503/105.0
[email protected]
I have been accessing Fidonet as a point and node for about three
years now and it seems to me that there is increasing dissatisfaction
with the way some things are being done. In R25, as elsewhere in
Z2,we had a period of upheaval last year while geonets were enforced.
There was a lot of heat generated by this most of which, I thought,
stemmed from the realisation that nodes have no influence beyond
accepting or rejecting a line in the nodelist. Any objections were
all too frequently countered by comments along the lines of "If you
don't like it feel free to leave.". I suppose we could have been
reconciled more quickly had there been a demonstrable improvement in
connectivity as a result of the upheaval but my impression is that
there was none. R25C has recently announced further changes to
improve the aesthetics of the boundaries . . . !
This is not intended as yet another Euro-node griping at all and
sundry in the *C chain, although the way in which geonets were imposed
illustrates some of the problems I see with the situation as we have
it now. I think that the existing structure is taking powers to
itself which were not envisaged by those who wrote Policy 4 and that
it is unresponsive to pressure from the nodes. They don't need to
listen to us because they don't have to and there's currently
precious little anyone can do about it, beyond writing to The Snooze!
When a new group gets going it is usual for those involved to sort
out things between themselves and not to bother with a formal
structure until things grow. The next state, which Fido seems stuck
in, is for people to be appointed without a vote to specific tasks.
Perhaps, in earlier times when the software was less friendly, it was
necessary for the newcomer to be known to the incumbent to ensure a
seamless changeover but that system can also be open to abuse. It
puts the influence into the hands of a small number of people who end
FidoNews 11-37 Page: 5 12 Sep 1994
up having a rather incestuous relationship as each selects the other.
As a small group they become more and more remote from the nodes as
the nodelist expands. In the UK we redefine electoral boundaries to
compensate for changes in the population. Is there any reason why
the Zones are inviolate? Could splitting them down make anything any
better?
There are plenty of people who don't want to see Fido as a democratic
institution but is what we have all that satisfactory? Is it right
that people can be ignored without redress? Fido now covers the world
and there are well over 30,000 lines in the nodelist. Comms is
increasingly coming to the attention of Joe Public so the expansion
isn't over yet. Can Fido evolve to the new situation or is it a
dinosaur, doomed to extinction?
Now, there is a place for international standards - would anyone want
to see FTSC spec's abolished? - but is it realistic to believe that a
single document will fit everyone equally? Do we *need* a global
policy beyond an acceptance that communication will be via
FTSC-compliant mailers? With so many people involved, there must be
thousands upon thousands of different ideas of the right way for the
future of Fidonet. In my experience you can't get two sysops to agree
as to who's turn it is to buy the beer but here's my idea for Fido,
for what it's worth! <grin>
I object to the remoteness of many of the things happening in Fido
not necessarily because they're wrong but because I can't be
guaranteed a proper hearing. The all-embracing (it feels like
all-constricting) Policy severely restricts what I can do. Let me try
an illustrate. This is *not* from my own experience and is intended
to be extreme!
Let's say I have a complaint so I take it to my NC. I believe the
complaint is valid but it's rejected. OK, take it up with the RC. The
RC appoints the NC and, again, is both judge and jury. He rejects it
so I go to the ZC but the same applies there. Would taking it to the IC
guarantee me any more of an even-handed approach? My theoretical problem
could remain unresolved not because it was invalid but because
the old-boys network allowed it to be smothered.
What I think we have is a self-sustaining oligarchy and other people
have described it as a benign dictatorship. It's a dictatorship,
certainly, but whether it's benign or malign depends on the
post-holders. We have to *hope* that we aren't saddled with the
wrong person because it is impossible for nodes to remove them
afterwards without the agreement of the person who made the original
appointment! I think that's an inversion of what we need. I want to
see the nodes selecting their NC's without the RC being able to
reject the candidate selected by those voting. Nor do I want to see a
situation where it is possible manipulate votes by moving nodes to
different Nets which, at present, can be done on the whim of one
person.
I don't believe that any organisation can be fully democratic. If
every decision has to be put to a full vote nothing would get done.
FidoNews 11-37 Page: 6 12 Sep 1994
Nevertheless, I want the NC to be aware all the time that the the
nodes will have their say and likewise for the RC. Beyond that it
gets tricky, because of the numbers of nodes involved, but something
along similar lines could be developed and each sub-division could
devise procedures to suit their own particular circumstances.
To summarise:
1) The various *C positions certainly have part to play but I believe
that some are exceeding their authority so that the duties
associated with these posts should be more closely defined. Power,
in Fidonet terms, is control of the nodelist. Who can control the
controllers?
2) At present, the nodes have no guaranteed voice in the selection of
*C's, giving the potential for the imposition of one person's view
against the wishes of a majority. This should be changed. A step
in this direction has been made in R25 with a Regional Policy but
it does not entirely remove the ZC's ability to interfere and so is
of limited effectiveness.
3) Policies should be of a local nature with global documents limited
to ensuring technical compliance between the local organisations.
4) I'd like to see a Fidonet where rules are at a minimum and
enforced once in a blue moon. A Fidonet where the basic aim is
communication, not control by confrontation. A Fidonet where we
have *fun* first and foremost and the freedom to enjoy it!
What kind of Fidonet do you want to see in the future?
Keith Jackson
----------------------------------------------------------------------
Samp Swine Magazine,
Shuckmagosh, Ohio
P1S 0RF
Dear Reverend Visage,
Thank god we sold our shares in a well-known deep fried
chicken franchise. You may not have noticed, but Calgary is
the ostrich ranching capital of Canada. I understand that
there are some foul (note to Eds: "foul" not "fowl")
tempered birds who will do almost anything to avoid ending
up bathed in grease and 7 secret herbs and spices. I realize
that Ms. LaBamba is fond of adorning herself with the
aforementioned condiments, but you can't reason with
ostriches Visage... they have the same lack of social graces
common to Australians, fergodsake.
FidoNews 11-37 Page: 7 12 Sep 1994
In Region 12, the internecine warfare continues unabated. It
seems that Net250 have rituals that involve eating their
young, resigning from Hub positions so as to maximize mail
disruption and a fondness for AntFarmMail that would make an
anteater look like a crack-crazed junkie. At Ladbrookes, the
odds of the current NC lasting to the end of his term are
astronomical. I placed your entire garageful of used diapers
on a bet that the NC-being would stay the course. The payoff
should be enormous, possibly equaling the entire message
output of Iann Grant.
I am disappointed that you were unable to pick up the spoor
of our missing RC. Rumours that he had been John Denver's
designated driver turned out to be false and alas, poor John
was charged with defoliating Aspen with his Porsche. I
suggest you look in the vicinity of Winnepeg for the
vapourous RC. I understand that there are agricultural test
plots of rye which, if Skippy's information can be relied
upon, are infected with some of the world's finest
ergotamine. You ought to bring the flintlock in case low
flying bats plague your visit.
Don't worry about your expense account problems with the
Snooze editors. Donald & Silvia hired a fellow named
Grimspam who worked his legal and accounting magic on the
invoices. The bills for large tubs of mazola that you
submitted turned into income after Grimspam had used
something fascinating called "attractor accounting." They
had some concern over the bill for eighteen cases of
Glenlivet but were calmed down after I explained that it was
used for purely medicinal purposes as a Chinook repellent.
Incidentally, a Chinook - being characterized as a warm, wet
wind which blows for days - is surely a perfect metaphor for
any meeting involving lawyers.
My sojourn in France to assist in the revival of the
International Dwarf Tossing Society was marred by strafing
runs from Harrier jump jets. It seems that the geopolitical
ambitions of the British RC have extended to the
sub-continent. I shall send him a life-sized photo of Sinead
O'Connor to ease his poor bovine suffering.
I noticed that the usual crop of Ace Ventura, Nodelist
Detectives, have graced the 'Snooz's pages with more
suggestions as to how to pare the nodelist down to a more
diminutive stature. It amazes me that they haven't
discovered the obvious - simply remove all of the telephone
numbers - surely this would solve all of their nightmares
about a nodelist looming out of the mists to swallow
Chicago.
I must go Visage, your secretary has unleashed a horde of
atrazine-crazed beavers which have me backed against the
wall. She has a feral-toothed scowl on her face and
FidoNews 11-37 Page: 8 12 Sep 1994
bloodlust in her eyes which has almost nothing to do with
the fact I suggested that she simulate a near-death
experience by moving to Mississauga. As a good and decent
gesture, I recommend that we suit her in a glow-in-the dark
body condom and turn her loose in Net250, The Planet of
Primal Screams.
Regards,
Doc Logger,
Trout-on-Trent,
FlinFlon, Manitoba
----------------------------------------------------------------------
REMOTE ACCESS - FALSE SECURITY PROMOTION
By: Andrew Leniart
3:633/106 @fidonet
[email protected] - Internet
Preamble:
The following article has been submitted to FidoNews due to the many
requests I've had from RA sysops since telling of it's publication in
my column "Online" in the Australian PC Review computer magazine.
Despite the many requests, it was not posted in the RA_SUPPORT
conference so as to comply with the wishes of the moderator.
Before you read the article, please keep in mind that I am an RA
system operator myself and overall, I continue to enjoy using the
software. It's never been my intention to put people 'off' from
running Remote Access. Indeed, I have promoted Remote Access heavily
on many occasions in the past and have invested considerable time and
expence in registering third party utilities to enhance it for my own
use.
Rather, the purpose of my little crusade is to bring to everyones
attention what I consider to be a "false sense of security" being
instilled in the averadge RA sysop regarding it's CRC32 password
storage method.
Since V2.0 of RA has been released, sysops have been given the
impression by many RA_SUPPORT participants that the CRC password
storage method has enhanced system security.
To my utter dismay, Sysops have even been encouraged to 'feel safe' in
using the same password on all RA systems because of the claim that
the sysop on the other end can no longer view thier password.
This article, along with an accompanying utility called CRC2PWD, has
been written to show people conclusive proof that the claims being
FidoNews 11-37 Page: 9 12 Sep 1994
made of enhanced system security are quite simply, false.
Don't fall for the trap. Always use different passwords on all systems
which you call, regardless of which software the sysop is using to run
his bbs with.
For those that may require further proof - CRC2PWD is freq'able at
3:633/106 at all times except zone mail hour. It is a utility which
will generate a set of characters that will produce an identical CRC
value to any users account in an RA2.0 users.bbs file. It requires a
386 or better processor to run.
The Article:
Warning to Prospective RA SysOps
I've been a RemoteAccess (RA from here on) die hard for many years
now, and despite many people trying to sway me to run other BBS
packages, I've stuck it out with RA and promoted it heavily for two
reasons.
One is that it's always been a highly configurable package which is
relatively easy to configure and use, even for beginners.
Secondly because it's developed by an Australian author, Andrew Milner
and I generally try and buy Australian when I see good value for
money.
Having said that though, it should go without saying that if I DID
choose to change from RA to another BBS package, I should be able to
do so with relative ease. This option has always been there with RA
until version 2.0 came out some months ago. With the release of V2.0
of RA, users passwords are no longer stored in RA in the conventional
sense.
Rather, what the software now does is change the users password to a
CRC32 and stores the CRC value in the user base instead. This
effectively makes the actual password non existant on the system and
it can no longer be viewed either by the SysOp or the account holder.
According to RA beta testers and support people, this password storage
method was introduced to enhance system security in the event of a
hacker managing to steal a BBS' user file. In my opinion though,
system security has been anything BUT enhanced with this method. Why?
The short of it is that CRC32 values are not secure. They are easily
cracked, so telling people that RA has greater security because it
stores it's passwords as CRC32 values is to simply instill a false
sense of security.
What's more, with previous versions of RA, only your actual password
would get you access to your account.
With the CRC32 password storage method, this is not necessarily the
case. To illustrate, a 7 character password can produce an identical
FidoNews 11-37 Page: 10 12 Sep 1994
CRC value to a say, alphanumeric 3 character password.
So in other words, if you happen to be unlucky enough to choose a
password which has a CRC value that can be duplicated by a different
password, then a hacker's chances of fluking access to your account by
simply guessing the password you use has just doubled.
This is an increase in system security? I don't think so and neither
do many other fellow RA sysops.
SWAPPING OVER
How does this prevent us from easily swapping over to another BBS
package? Well, it doesn't if you haven't been running a BBS for any
great length of time, but consider if you were running one for a few
months and had developed a user base with five or six hundred callers
on your system. If you charge money for access to your system, simply
wiping the user base and starting from scratch is certainly not
practicable..
It's relatively easy for most programmers to whip up a conversion
utility that transfers details from one BBS user file format over to
another. It's done all the time, and quite a lot of BBS software
packages come with such utilities bundled in with the main software.
Yet with RA, it's no longer possible, because the most critical part
of the user file, the password, no longer exists - only a CRC value.
It's impossible to retrieve the actual characters which originally
produced the CRC value, so all of a sudden you're stuck with RA unless
you want to go to all the trouble of voice calling each and every one
of your callers and manually enter thier password into the new BBS
software.
So what's the solution? I've asked Andrew Milner via direct netmail
for his comment on this issue but haven't yet recieved a reply. RA
beta testers have responded to questions though, confirming that Mr
Milner has stated that the encrypted password storage method in RA is
here to stay, whether we like it or not. My question is WHY?
Suggestions of making it an optional feature have been waved off and
discussion of the issue in the FidoNet RA_SUPPORT conference has been
declared off topic by the moderator. I've actually been threatened
with having my access to the support conference severed by Bruce
Bodger if I continued to discuss the issue in there. Great stuff huh?
So what's it all about then? System security or ensuring that RA
SysOps don't desert, unless they want to go through a heck of a lot of
heartache in changing over to another system? Make up your own mind.
In closing, I would like to say to all prospective sysops - think long
and hard before selecting RA as your BBS package.
RA is still in all other respects an excellent BBS package, but be
aware that you may end up stuck with it for a very long time. Be also
aware of the aparant reluctance of both Mr Milner and his Beta Support
FidoNews 11-37 Page: 11 12 Sep 1994
Team to take the loyal software users' wishes into account.
ONE SOLUTION
Some good news though.. At least one BBS software package has seen the
plight of RA system operators and has addressed the problem for us.
Philippe Leybaert, Belgian author of the shareware BBS package
Proboard v2.01, has redesigned his BBS to use the same user file RA2.0
does, with the exception that it also stores the users passwords in
the conventional form, so converting over from RA2.0 to ProBoard is
quite painless.
ProBoard gives you a choice of having hidden passwords or not, and if
you selelct that you don't want want hidden passwords, it stores them
in in the conventional form for you as your users log on and enter
thier password.
Let's hope that other shareware authors will see that this is the way
to go and incorporate a similar feature in thier BBS packages in
furture versions, I'm not holding my breath, though.
Till the next time...
----------------------------------------------------------------------
GATING FROM FIDONET, BANNED
Recently it has been brought to the attention of readers in TrekNet
(you guessed 'er, a Star Trek and Sci-Fi OtherNet) that some of the
TREK and related areas that are gated between FidoNet and TrekNet are
not going to be permitted to be gated any more.
At this time, those nets who are running CRP's (Cost Recovery
Programs) are probably jumping out of your seats and dancing around
their computer desk chanting "Yes, we finally got rid ofthe
moochers". No, I'm not here to defend those of us who pull those
echos through the OtherNets which the echos are being gated, but
rather to ask a simple question.
Now, the poop that we're being told (and I use the word 'poop' very
liberally) is that the order came from the "Higher Ups", which would
indicate ZC's and RC's, and the like. I've got just one thing to ask:
Isn't the moderator of the echo permitted to gate his or her echo
into any Network that he or she wishes?
Ultimately, it is the moderator who says "No, I don't want you using
my echo", and by all rights and priviledges the moderator does own
the echo, yes? So, what gives these people in the offices of ZC, RC
and NC the right to say "No, you can't gate these echos anymore, you
have to get them through a FidoNet Net in your area."
I'm just a little tired of the buracracy of FidoNet. I've watched
FidoNews 11-37 Page: 12 12 Sep 1994
good and honourable people turn into domineering bafoons after
they've been elected into the office of NC, or even a HUB.
If FidoNet keeps this up, I think that they may find fewer nodes
wishing to tolerate the crap and possibily a bit of Negative Growth.
----------------------------------------------------------------------
Election Announcement - Zone One Echomail Coordinator
by Adrian Walker
1:153/752
Interim Z1EC
ELECTION ANNOUNCEMENT
Position:
---------
Zone 1 Echomail Coordinator (1:1/200).
Customary Duties:
* Coordination of echomail distribution at the zone level.
* Recognition of echoes at the zone level.
* Maintenance of a list of recognized echoes and their
requirements as supplied by the Moderator.
* Making recognized echoes available to Zone 1 regions.
* Appointment of Zone Hubs to distribute echomail at the zone
level.
* Appointment of a Zone Echolist Coordinator.
Term of office is two years from date elected.
Election Schedule 1994:
-----------------------
Nominations are open from 19 September 00:01 PDT (07:01 UTC).
to 25 September 23:59 PDT (06:59 UTC).
Discussion follows from 26 September 00:01 PDT (07:01 UTC).
to 7 October 23:59 PDT (06:59 UTC).
Voting period will be from 10 October 00:01 PDT (07:01 UTC).
to 14 October 23:59 PDT (06:59 UTC).
Results announced by 17 October 23:59 PDT (06:59 UTC).
Eligibility:
------------
Any Zone 1 SysOp listed in the 16 September 1994 Nodelist
(NODELIST.259) is eligible to be nominated.
Nominations:
------------
FidoNews 11-37 Page: 13 12 Sep 1994
Nominations are to be sent by netmail to Adrian Walker at 1:153/752.
A nomination is only valid after a message from the nominee accepting
the nomination is included or posted.
Voting:
-------
Each Zone 1 Region Echomail Coordinator listed in the 16 September
1994 Nodelist (NODELIST.259) may cast one vote.
Each REC will consult his region to determine how to cast his vote.
Votes are to be sent by netmail to Dave James at 1:209/209, and to
ensure security of the vote, are to include a password selected by the
voting REC.
All votes will be tallied and the results forwarded by Dave James at
1:209/209 to the Zone Coordinator (Z1C) at the end of the voting
period.
The nominee having a simple majority (more than 50%) of the votes cast
will be declared the new Z1EC.
If no one candidate receives more than 50% of votes cast, the RECs
shall be presented with a ballot containing the names of the two
nominees having the most votes, and shall conduct a runoff election.
The nominee with the most votes in the runoff election will be
declared the new Z1EC.
Announcements:
--------------
The election announcement will be posted in FidoNews and the
Z1_ELECTION echo by 19 September 1994 by the Interim ZEC.
The nominees will be posted in Z1_ELECTION echo on 26 September 1994
and in FidoNews as quickly thereafter as possible by the Interim ZEC.
Results will be posted in FidoNews and Z1_ELECTION echo on 17 October
1994 by the Interim ZEC.
RECs are encouraged to cross post all such announcements into their
respective regional echos.
---ooo000ooo---
FidoNews 11-37 Page: 14 12 Sep 1994
Dear MADam emilia
A: There's been much gripeing lately over Fidonet "positions" being
passed on to friends rather than won in elections.
Q: What is the mechanism of power-mongering? How can popularity
contests result in the selection of the best person to laboriously
fulfill a purely technical position?
A: There seems to be the potential for egotistical zealotry and
corruption in both democratic and feudal models of management.
Maybe an optomistic laissez-faire eeks out the best of all
models, even though it's messy sometimes.
Q: Should the Fidonews editorship-hood-ness be an elected position,
for example? <cringe, fear, hey i like this job, woooo>
q: Why did the last page description of Fidonet as an "amateur"
network change to "volunteer" network and then back again?
a: Well, it started bugging me that the word "amateur" connotes
unsophisticated or unknowledgeable, and Fidonet chuggs along
amazingly seamlessly compared to some professionally done and
inflatedly expensive communications systems. But then i read the
dictionary, and one possible denotation of "volunteer" is "a person
who voluntarily undertakes a task or enters military or other
service". I'm not big on the military except when they're rescuing
people drowning at sea or building shelters and providing aid in
distasterous situations, so i changed it back to "amateur".
q: How do you feel about Steve Winter being kicked out of Fidonet?
a: Lousy. It contradicts the tolerant spirit of Fidonet in a bad
way. Excommunication smacks of religionism, like permanent
damnation. It's easy for me to talk this way, because i am
not a hub.
----------------------------------------------------------------------
Submitted by: Al Hays
1:363/89
[email protected]
FIDONET EXCOMMUNICATION - AN INTERPRETATION
A Debate is currently underway in HOST18 (which is READ-ONLY to R18
SysOps) between Region 18's Network *C and *ECs, and the RC & REC.
It is a civil, even-handed debate to all of the coordinator's credit.
POLICY debates: always such fun, and yet regardless of the outcome,
RC18 Larry Squire states that his "hands are tied" due to the current
consensus of the Zone 1 RC Council. Perhaps the council, or even Z1C,
has not considered the obvious. Sometimes it takes an outside
opinion to stimulate the thought process or to bring a previously
FidoNews 11-37 Page: 15 12 Sep 1994
unheard perspective to light which may change opinion. Am I right?
Who knows ... but I respectfully submit this as one man's opinion,
nonetheless.
..
What is excommunication?
Excommunication, as defined by POLICY4, has a dual meaning. First,
simply being dropped from the Nodelist for down time, non-compliance,
etc. is defined in section 2.1.12 as having been "excommunicated." As
such, section 2.1.12 also prescribes relief from inadvertent
excommunication by advising the node to "rectify the problem and
contact your coordinator."
Excommunication "for cause" is also defined in section 2.1.12. It
also refers to sections 4.3 and 5.2 both of which, paraphrased, state
that a coordinator may "excommunicate" a node for excessively annoying
behavior (XAB).
The pertinent sections of POLICY4 appear below:
> 2.1.12 Excommunication
>
> A system which has been dropped from the network is said to be
> excommunicated (i.e. denied communication). If you find that you
> have been excommunicated without warning, your coordinator was
> unable to contact you. You should rectify the problem and contact
> your coordinator.
>
> Systems may also be dropped from the nodelist for cause. See
> section 9, and sections 4.3 and 5.2.
>
> It is considered annoying behavior to assist a system which was
> excommunicated in circumventing that removal from the nodelist.
> For example, if you decide to provide an echomail feed to your
> friend who has been excommunicated, it is likely that your listing
> will also be removed.
>
>
> 4.3 Assigning Node Numbers
>
> ... unrelated text removed ..
>
> If a node in your network is acting in a sufficiently annoying
> manner, then you can take whatever action you deem fit, according
> to the circumstances of the case.
>
>
> 5.2 Assigning Node Numbers
>
> ... unrelated text removed ...
>
> If a node in your region is acting in a sufficiently annoying
> manner, then you can take whatever action you deem fit, according
FidoNews 11-37 Page: 16 12 Sep 1994
> to the circumstances of the case.
Let's examine, for a moment, the PURPOSE that POLICY4 conveys behind
excommunication due to XAB. The excommunicated node in question was
removed "for cause" meaning that he/she was intentionally a) causing
a disruption in FidoNet Operations, b) ignoring POLICY, and/or c)
repeatedly harassing or otherwise interfering with another node.
He/she was, therefore, excommunicated, or as POLICY defines it,
"denied communication." The purpose of this denial of communication
is not for retribution, but to take specific action to end the
activities which brought about the excommunication in the first
place. The PURPOSE of excommunication is to "deny communication."
What constitutes "denied communication?"
In this author's opinion excommunication, or "denied communication,"
indicates that the individual in question has purposely and defiantly
acted in a sufficient manner that the Network, through it's
coordinators, wishes to have no further communication with the
individual in *ANY* manner, be it as Node, Point, or User. Simply
removing an individual from the Nodelist does not "deny communication."
The denial must be complete or excommunication is a fruitless exercise
in futility.
Node, Point, or User ...
Providing a "feed" to an excommunicated FidoNet SysOp is clearly
defined by POLICY4 as XAB in section 2.1.12. The term "feed" is
ambiguous and, since it is covered in the very same section which
defines excommunication as "denied communication" can be easily
interpreted to mean "access" to any/all FidoNet areas. This would
cover Points and Users alike. Policy defines a point "in the same
manner as a user" and the converse may, therefore, be extricated. To
wit:
> 1.2.1.2 Points
>
> A point is a FidoNet-compatible system that is not in the nodelist,
> but communicates with FidoNet through a node referred to as a
> bossnode. A point is generally regarded in the same manner as a
> user ...
According to POLICY4, a point "communicates with FidoNet through a
node" and since POLICY4 defines excommunication as "denied
communication" then applied logic would dictate that acting as a
bossnode for an excommunicated node would constitute XAB (section
2.1.12, 1.2.1.2, 4.3 and 5.2). Conversely, therefore, an
excommunicated node may not access FidoNet communications as a point.
Again, from section 2.1.12:
> It is considered annoying behavior to assist a system which was
> excommunicated in circumventing that removal from the nodelist.
FidoNews 11-37 Page: 17 12 Sep 1994
> For example, if you decide to provide an echomail feed to your
> friend who has been excommunicated, it is likely that your listing
> will also be removed.
