informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
278a90f7ce
textfiles/bbs/FIDONET/FIDONEWS/fido1124.nws
root@procul 278a90f7ce Initial commit
2021-04-15 13:31:59 -05:00

1669 lines
75 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

F I D O N E W S -- Vol.11 No.24 (13-Jun-1994)
+----------------------------+-----------------------------------------+
| A newsletter of the | ISSN 1198-4589 |
| FidoNet BBS community | Published by: |
| _ | |
| / \ | "FidoNews" BBS |
| /|oo \ | +1-519-570-4176 1:1/23 |
| (_| /_) | |
| _`@/_ \ _ | Editors: |
| | | \ \\ | Sylvia Maxwell 1:221/194 |
| | (*) | \ )) | Donald Tees 1:221/192 |
| |__U__| / \// | Tim Pozar 1:125/555 |
| _//|| _\ / | |
| (_/(_|(____/ | |
| (jm) | Newspapers should have no friends. |
| | -- JOSEPH PULITZER |
+----------------------------+-----------------------------------------+
| Submission address: editors 1:1/23 |
+----------------------------------------------------------------------+
| Internet addresses: |
| |
| Sylvia -- max@exlibris.tdkcs.waterloo.on.ca |
| Donald -- donald@exlibris.tdkcs.waterloo.on.ca |
| Tim -- pozar@kumr.lns.com |
| Both Don & Sylvia (submission address) |
| editor@exlibris.tdkcs.waterloo.on.ca |
+----------------------------------------------------------------------+
| For information, copyrights, article submissions, |
| obtaining copies and other boring but important details, |
| please refer to the end of this file. |
+----------------------------------------------------------------------+
========================================================================
Table of Contents
========================================================================
1. Editorial..................................................... 2
2. Articles...................................................... 2
D R A F T P R O P O S A L................................. 2
Please Tell Congress........................................ 8
Our E-MAIL can be trouble................................... 11
Some Observations........................................... 12
Suggested amendment to POLICY4.............................. 14
This is a serious proposal:................................. 15
To Madam Emilia............................................. 16
Creating an Online Civil Liberties Organisation............. 17
Nodelist review............................................. 21
The use of e-mail........................................... 28
3. Fidonews Information.......................................... 29
FidoNews 11-24 Page: 2 13 Jun 1994
========================================================================
Editorial
========================================================================
What is the difference between "place" and "space"? It's wonderful
to see EFF-type organizations sproinging up with enthusiasm. It
bothers me a bit that they are arranged according to countries. I
guess it makes sense to organize legal-aid stuff by country, because
particular beaurocratic/political situations will have problems
requiring local resources, but... I hope the limitations of
boundaries are not imposed upon the net out of historical habits.
Occasionally habits are useful, but if they are not continually
reviewed and revised to jive with changing reality, they turn into
rules, which is boring.
Sure, people can think in terms of borders if they want to, but not
everyone should *have* to. Also, borders, do not have to be based
upon history. They could be based upon science fiction, or
anything at all, if they have to exist.
I still haven't heard any more about nodes disappearing in Italy,
despite trying to find information. This makes me curious.
========================================================================
Articles
========================================================================
D R A F T P R O P O S A L
June 6, 1994
Zone One Mail Backbone Policy
===============================
Revision: 1.0 Effective Date: xxxx x, 1994
Table of Contents
===================
1.0 Introduction
1.1 Purpose of this Document
1.2 Definitions
2.0 Zone Level Operations
2.1 Zone Backbone Coordinator
2.2 Zone Hubs
3.0 Conference Moderators
3.1 Recognition of Moderators
3.2 Responsibilities of Moderators
4.0 Other Operating Procedures
4.1 Administrative Areas
4.2 Message Technical Standards
4.3 Adding Conferences to the Backbone
4.4 Removing Conferences from the Backbone
4.5 Routed Netmail
5.0 Changes to this Document
1.0 Introduction
FidoNews 11-24 Page: 3 13 Jun 1994
=================
1.1 Purpose of this Document
-----------------------------
This document sets forth the operating procedures used, and defines the
services offered, by the Zone One Mail Backbone at the zone level. It
describes how the Zone Backbone Coordinator is selected. It also
describes how the Zone Hubs operate. The operation of the Backbone
within regions and nets is not covered by this document.
Participation in the Zone One Mail Backbone is voluntary. Those
Coordinators, Hubs, Nodes and Moderators who participate, agree to
operate by the procedures, and offer the services, as described in this
document.
The services offered by the Zone One Mail Backbone are in addition to
any which are required of, or due to, members of FidoNet by FidoNet
Policy. Use of these services should be viewed as a privilege, not a
right.
Although the Zone One Mail Backbone attempts to provide the best service
possible, there is no guarantee provided. Specifically, messages which
require sensitive or timely handling should not be sent through the Zone
One Mail Backbone.
This document is not a part of FidoNet Policy. Should any part of this
document conflict with FidoNet Policy then FidoNet Policy shall prevail.
1.2 Definitions
----------------
The Zone One Mail Backbone consists of the Coordinators, Hubs and Nodes
who agree to operate by the procedures, and offer the services, as
described in this document, to help distribute the Zone One Mail
Backbone echomail conferences and routed netmail to end users, other
distribution services and other networks. The Zone One Mail Backbone is
hereafter referred to simply as the Backbone.
An echomail conference is a message base or forum, distributed under a
specified echomail conference name, dealing with a defined area of
interest. Echomail conferences are hereafter referred to simply as
conferences.
The Zone Backbone Coordinator (ZBC) functions at the zone level. It is
assumed that Backbone Coordinators of some sort exist at the region
level. Hence this document refers to them as Region Backbone
Coordinators (RBCs) with the understanding that this might vary within
any given region. Regions select their RBCs however they choose. RBCs
function at the regional level, providing regional input and direction
to the operation of the Backbone at the zone level, as described
elsewhere in this document.
Hubs are Nodes who distribute mail to other Nodes. Zone Hubs (ZHubs)
distribute mail at the zone level. It is assumed that Hubs of some sort
FidoNews 11-24 Page: 4 13 Jun 1994
exist at the region level. Hence this document refers to them as Region
Hubs (RHubs) with the understanding that this might vary within any
given region.
2.0 Zone Level Operations
==========================
2.1 Zone Backbone Coordinator
------------------------------
The Zone Backbone Coordinator (ZBC) oversees the operation of the
Backbone at the zone level. The ZBC coordinates routing and schedules
to ensure reliable and efficient availability of Backbone mail while
avoiding creation of duplicate messages. The current ZBC can be
identified from his[her] listing in the FIDOSTAT.NA file.
The ZBC maintains a list of Backbone conferences in a text file called
FIDONET.NA. He[she] also maintains a list of temporary Backbone
conferences, in a text file called FIDONET.NO. These files are
formatted so that they can be used as forward-lists by programs such as
AreaFix. The ZBC distributes these files on a weekly basis via the
BACKBONE file area.
The ZBC maintains a text file called FIDOSTAT.NA. This file contains a
list of conferences seeking to be added to the Backbone. It also
contains a list of the ZBC, ZHubs, RBCs and RHubs. The ZBC distributes
this file on a weekly basis via the BACKBONE file area.
The ZBC is selected by a vote of the RBCs. A mutually agreeable RBC
serves as the election chairman. An election is held when any of the
following occur:
1) The ZBC position becomes vacant.
2) More than one-fourth of the RBCs request that an election be
held and it has been more than six months since the last
election.
3) It has been more than 2 years since the last election.
2.2 Zone Hubs
--------------
The ZBC appoints Zone Hubs (ZHubs) to distribute Backbone mail at the
zone level. The ZBC may also serve as a ZHub if [s]he so desires.
Each ZHub offers a minimum of one connection to each region.
Each ZHub makes available all of the Backbone conferences, routed
netmail and the BACKBONE file area. Nothing in this provision requires
that a ZHub carry any conference to the extent of adverse economic
impact.
The ZHubs maintain an emergency backup plan should one of them
experience problems.
FidoNews 11-24 Page: 5 13 Jun 1994
3.0 Conference Moderators
==========================
Conference Moderators (Moderators) preside over conferences. The
Backbone has no desire to interfere with the internal affairs of a
conference in so much as they do not disturb the operation of the
Backbone.
A Moderator need not be either a SysOp or a member of FidoNet.
3.1 Recognition of Moderators
------------------------------
A Moderator is recognized as follows:
1) Upon formation of a conference, the person who forms the
conference is the Moderator.
2) Upon resignation or replacement of an existing Moderator, the
conference's rules define how the new Moderator is selected.
3) The Moderator and Co-Moderators, if any, are listed in the
Echolist entry for the conference since it serves as the guide
for Hubs needing this information.
Moderators are encouraged to appoint Co-Moderators to assist them in
their responsibilities and to stand in for them in their absence.
3.2 Responsibilities of Moderators
-----------------------------------
Moderators are responsible for:
1) Maintaining a netmail address in the Echolist, at which they can
be reached from FidoNet.
2) Seeing that messages in their conference correspond to the
conference's theme.
3) Seeing that messages in their conference do not contain illegal
information or promote illegal activities.
4) Posting the conference rules or policies in the conference at
least every month.
5) Updating their conference listing in the Echolist at least every
six months.
If a Moderator determines that a Node persists in violating a conference
rule, [s]he may direct the feed to that Node be severed. Such a
directive, listing the conference rule violated, is made in a netmail
message to the Hub feeding the offending Node, with a copy to the
offending Node. After verifying the Moderator in the Echolist, the Hub
severs the feed.
FidoNews 11-24 Page: 6 13 Jun 1994
Should the Hub not comply with the Moderator's directive then the
Moderator may direct the feed to that Hub be severed, and so on. Such a
directive, listing the procedure followed, is made in a netmail message
to the Hub feeding the offending Hub, with a copy to the offending Hub.
After verifying the information, the Hub severs the feed of the
offending Hub.
4.0 Other Operating Procedures
===============================
4.1 Administrative Areas
-------------------------
The Z1_BACKBONE and Z1_RBC conferences are used to conduct Backbone
business. Z1_BACKBONE is open to any Node having business with the
Backbone. Z1_RBC is restricted for use by region and zone level
Backbone Coordinators and Hubs. The ZBC serves as Moderator for both
conferences.
4.2 Message Technical Standards
--------------------------------
FTSC specification FTS-0001 is followed.
Only ASCII characters are used in a message's control fields.
Pathlines are used.
Due to the limitations of some current software, the Backbone can not
guarantee delivery of messages in excess of 13,000 bytes. Hubs are
encouraged to use message processing software which allows larger
messages, preferably up to 64K bytes, to be handled.
The Backbone does not agree to handle encrypted messages in conferences,
excepting digital signatures and occasional demonstration and/or test
messages.
Hubs may delete messages which do not conform to the technical standards
set forth in this Section when such messages might be harmful to the
technical operation of the Backbone. This includes duplicate messages,
"grunged" messages and echomail messages over 20 days old. Such
messages are generally not returned.
Hubs operate in a secure fashion. They automatically process inbound
messages only from those nodes with which prior agreements have been
made. Normally this means that Hubs use session passwords and secure
("protected") inbound areas. However, any reasonable method of ensuring
that non-secure messages do not enter the Backbone is acceptable.
A Hub may choose not to provide services to a Node which does not
operate in a secure fashion if this Node has a history of causing
problems due to this lack of security.
4.3 Adding Conferences to the Backbone
FidoNews 11-24 Page: 7 13 Jun 1994
---------------------------------------
A conference is added to the Backbone and listed in the FIDONET.NA file
when all of these requirements are met:
1) The conference is listed in the published Echolist.
2) The Moderator either sends a netmail request to the ZBC or an
echomail request, addressed to "Backbone", in the Z1_BACKBONE
conference. The ZBC normally requires that the conference has
achieved some degree of distribution before accepting this
request. See the FIDOSTAT.NA file for current limits.
3) At least three RBCs request that the Backbone distribute the
conference to their regions.
Also, any conference removed temporarily from the Backbone is restored
to regular Backbone distribution when the situation which caused it to
be removed is corrected.
4.4 Removing Conferences from the Backbone
-------------------------------------------
A conference is removed temporarily from the Backbone, with its listing
moved from the FIDONET.NA file to the FIDONET.NO file, when any of these
situations occur:
1) The conference is no longer listed in the published Echolist.
2) The conference is without a Moderator.
3) There are no longer three RBCs requesting that the Backbone
distribute the conference to their regions.
A conference is removed entirely from the Backbone, with its listing
removed from both the FIDONET.NA file and the FIDONET.NO file, when any
of these situations occur:
1) The Moderator either sends a netmail request to the ZBC or an
echomail request, addressed to "Backbone", in the Z1_BACKBONE
conference.
2) The Moderator does not carry out his[her] responsibilities, as
described in Section 3.2 and determined by the ZBC.
3) The traffic level in the conference falls below ten messages
over a two month period.
4) A conference which was removed temporarily from the Backbone
does not qualify to be restored to regular Backbone distribution
within two months of being removed.
4.5 Routed Netmail
-------------------
FidoNews 11-24 Page: 8 13 Jun 1994
Hubs accept routed netmail from any Node who connects with them for
Backbone conferences. Any netmail message with a valid FidoNet
destination, regardless of its origin, is accepted. Routed netmail may
be routed along Backbone paths or to a ZC, RC, or NC who has agreed to
handle such messages.
Routed netmail is for personal messages. It is not for commercial
messages, conferences, mailing lists, news groups, file-attaches, or
"encoded" files.
Some Hubs do not allow encrypted messages to flow through their systems.
Therefore, the Backbone does not agree to handle encrypted routed
netmail messages, excepting digital signatures.
5.0 Changes to this Document
=============================
A change to this document may be proposed by any RBC. If a second RBC
concurs, the proposed change is voted on by all of the RBCs. Notice of
such a vote, including the proposed change, is posted in the Z1_RBC
conference, the Z1_BACKBONE conference and the FIDOSTAT.NA file, at
least fourteen days prior to the start of the voting period.
The RBCs are expected to assess the opinions of the Backbone
Coordinators, Hubs and Nodes in their regions, and to vote accordingly.
More than fifty percent of those voting must vote for a change for it to
be accepted.
- end -
~ ~ ~ D R A F T P R O P O S A L ~ ~ ~
----------------------------------------------------------------------
Please Tell Congress to Allow Encryption Export
- - - - - - - - - - - - - - - -
cc: GK Pace
Please "print" in FidoNews! No time to lose!
From: Stanton McCandlish (1:109/1108)
From: gnu@eff.org (John Gilmore - 1:109/1108)
Subject: URGENT: Please Tell Congress to Allow Encryption Export
Reply-To: ask@eff.org (rather than send us email
please fax +1 202 225 1991)
House Intelligence Committee holds key to Crypto Export
ask@eff.org June 9, 1994 *DISTRIBUTE WIDELY*
Today, the U.S. State Department controls the export of most
encryption, working closely with the National Security Agency (NSA) to
limit products that provide real privacy, from cell-phones to PC
software. A bill introduced by Rep. Maria Cantwell would instead give
FidoNews 11-24 Page: 9 13 Jun 1994
authority over non-military crypto exports to the Commerce Department.
Commerce has much more reasonable regulations, with "First
Amendment"-style unlimited publishing of publicly available software,
including PGP, Kerberos, RIPEM, RSAREF, and mass-market commercial
software. The bill also prevents the Commerce Dept. from tightening
the regulations even if NSA somehow gets its tentacles into Commerce.
A few months ago, you-all sent over 5600 messages to Rep. Cantwell in
support of her bill, H.R. 3627. As a result, on May 18, the bill
passed the House Foreign Affairs Committee by being incorporated into
the Export Administration Act of 1994, H.R. 3937.
Now the battle has become more intense. This portion of H.R. 3937 has
been referred to the House Intelligence Committee with the intent to
kill or severely maim it. We need your help again, to urge the
Intelligence Committee to keep crypto export liberalization intact.
The House and Senate Intelligence Committees, the only watchdogs for
the NSA, tend to follow the agency's wishes when they wave the magic
"national security" wand. They need plenty of input from the public
that tells them that the nation will be *more* secure with good
encryption, even though the NSA will be less happy.
Not just computer users, but all users of telephones, cable TV, health
care, and credit information systems would benefit from this change.
The security of these applications is built on the foundation laid by
the operating systems and network protocols on which they run. If
this bill is passed, you will see high quality encryption built into
Microsoft Windows, into the MacOS, into major Unix workstations, into
the Internet, into cellular phones, into interactive television. The
software already exists for confidentiality, privacy, and security of
local and networked information, but it's not built-in to these
systems because of the export ban. Today, each company could build
two operating systems, one gutted for international use, but this
would be costly and confusing for them and their customers, and would
not allow international networks such as the Internet or telephones to
be made secure and private. With this bill, these limits disappear.
Furthermore, the Clinton Administration plans to permit high volume
exports of Clipper products, while continuing to require tedious
paperwork for truly secure encryption products. The bill would give
Clipper and other crypto software more even-handed treatment.
The bill also eliminates a senseless situation on the Internet.
Today, crypto software can only be freely distributed from non-U.S.
archive sites. It would eliminate that problem as well as the threat
of prosecution against U.S. freeware authors of crypto software.
This is the dream we've all been working toward. Here's how you can
help to make this dream a reality. The Intelligence Committee must
make its decision on the bill before June 17, so time is critical:
1) Fax a short letter TODAY to the chair of the Intelligence
Committee, Representative Dan Glickman (D-KS). Ask him in your own
words to leave the encryption provisions of H.R. 3937 intact. Use a
FidoNews 11-24 Page: 10 13 Jun 1994
positive tone ("Please support...") rather than a flame or a rant.
One paragraph is fine. State your title and organization if you will
look more important or better informed than the average citizen. Rep.
Glickman's committee fax number is +1 202 225 1991. This is the best
option, since individual letters are given the most weight by members
of Congress, particularly when sent on letterhead paper.
2) If you are unable to fax a letter, send an e-mail message to Rep.
Glickman at glickman@eff.org. Software or staff at the Electronic
Frontier Foundation will either fax it in, or print it out and
hand-deliver it for you.
3) Send a copy of this message to everyone you know in Kansas, and
personally urge them to write to Rep. Glickman today. Letters from
constituents get a lot more weight, since they are from people who
could actually vote for or against him in the next election.
4) If your own Representative is on the Intelligence Committee, send
him or her a copy of what you sent Rep. Glickman. There's a list of all
such Reps. below. Even if we lose this battle, you will have started
educating your own Rep. about crypto policy.
5) Become a member of EFF. Our strength comes from our members'
strength. Send a note to membership@eff.org asking how to join.
Thanks again for your help! You can check at any time on the current
status of the campaign at the location below. Send any comments on
this campaign to campaign@eff.org.
John Gilmore
Chairman, EFF Crypto Committee
EFF Board of Directors
Member of Computer Professionals for Social Responsibility
Member of International Association for Cryptologic Research
House Intelligence Committee Members
------------------------------------
Subcommittee phone: +1 202 225 4121
Subcommittee fax: +1 202 225 1991 <== send your fax HERE <==
p st name phone fax
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D KS Glickman, Daniel +1 202 225 6216 private Chair
D WA Dicks, Norman D. +1 202 225 5916 +1 202 226 1176
D CA Dixon, Julian C. +1 202 225 7084 +1 202 225 4091
D NJ Torricelli, Robert +1 202 224 5061 +1 202 225 0843
D TX Coleman, Ronald D. +1 202 225 4831 +1 202 225 4831
D CO Skaggs, David E. +1 202 225 2161 +1 202 225 9127
D NV Bilbray, James H. +1 202 225 5965 +1 202 225 8808
D CA Pelosi, Nancy +1 202 225 4965 +1 202 225 8259
D TX Laughlin, Gregory H. +1 202 225 2831 +1 202 225 1108
D AL Cramer Jr, Robert (Bud) +1 202 225 4801 private
D RI Reed, John F. +1 202 225 2735 +1 202 225 9580
D MO Gephardt, Richard A. +1 202 225 2671 +1 202 225 7452
FidoNews 11-24 Page: 11 13 Jun 1994
R TX Combest, Larry +1 202 225 4005 +1 202 225 9615
R NE Bereuter, Douglas +1 202 225 4806 +1 202 226 1148
R CA Dornan, Robert K. +1 202 225 2965 +1 202 225 3694
R FL Young, C. W. (Bill) +1 202 225 5961 +1 202 225 9764
R PA Gekas, George W. +1 202 225 4315 +1 202 225 8440
R UT Hansen, James V. +1 202 225 0453 +1 202 225 5857
R CA Lewis, Jerry +1 202 225 5861 +1 202 225 6498
R IL Michel, Robert H. +1 202 225 6201 +1 202 225 9249
The full text of this alert is stored at:
ftp.eff.org, /pub/Alerts/export.alert
gopher.eff.org, 1/Alerts, export.alert
http://www.eff.org/pub/Alerts/export.alert
BBS (+1 202 638 6120, 8N1): "Alerts" file area, export.alt
FREQ 1:109/1108: (any system, no need to be nodelisted): export.alt
The actual text of this part of H.R. 3937 is at:
ftp: ftp.eff.org,
/pub/EFF/Policy/Crypto/ITAR_export/hr3937_crypto.excerpt
gopher.eff.org,
1/EFF/Policy/Crypto/ITAR_export, hr3937_crypto.excerpt
http:
//www.eff.org/pub/EFF/Policy/Crypto/ITAR_export/hr3937_crypto.excerpt
BBS: "Privacy--Crypto" file area, hr3937.crp
FREQ 1:109/1108: hr3937.crp
For current status on the bill:
ftp.eff.org, /pub/Alerts/export_alert.update
gopher.eff.org, 1/Alerts, export_alert.update
http://www.eff.org/pub/Alerts/export_alert.update
BBS: "Alerts" file area, export.upd
FREQ 1:109/1108: export.upd
A general Web page on crypto export policy is at:
http://www.cygnus.com/~gnu/export.html
----------------------------------------------------------------------
Our E-MAIL can be trouble
by RICK LITHGOW (1:2601/574)
Hey
Lastnight I watched the news here in Pa. and lo and behold another
ISH lawsuit...Seems that former Miss. Kentuckey(I believe it was Miss
Kentuckey) Is suing two unnamed persons for slander and libel due to
some open correspondance in email. Seems a couple of ex-friends had
called her mean, insensitive, permiscuous and a few other things. She
is claiming her reputation is ruined and it has caused her
grievious(proper spelling?) emotional and professional harm. She is
FidoNews 11-24 Page: 12 13 Jun 1994
these people for 2.3 million dollars.
What does this mean for people who bicker and kvetch in all the
FIDO echoes, USENET groups, and other on-line services? What does
this mean for FLAME? If someone calls me an idiot or something
worse, can I get rich? Hmmm.....If a lawsuit like this is won in
the courts then we all all in serious trouble....IMHO something
like this could set us back 100 years in terms of free speech and
open opinions. Hopefully they will have a follow up... Watch your
local news or CNN for this story...
Regards
Rick Lithgow
... If we don't stop censorship now, we're ***ked.
^
|
high bit chars here censored }|->
----------------------------------------------------------------------
Some Observations
Shawn McMahon
1:19/34
smcmahon@vwp2.infomail.com
Some Observations on Recent Events.
I'm not gonna quote, if I can help it; presumably, you know how to
download back issues of the 'snooze if you were foolish enough to delete
them.
To all people who write long letters of frustration over acts their *Cs
commit, ending with the plea "what is the Fidonet policy concerning
this:"
Your article was written in English. POLICY4.DOC is written in English.
Why are you asking that question in the 'snooze? Read your copy of
Policy 4. If you don't have one, why did you certify to your *C that
you *DID* have (and had read and understood) the document when you
applied for your node listing? If it ain't in Policy 4.07, Fidonet
doesn't have a policy on it. If your English isn't very good and you
have trouble interpreting specific paragraphs, then say so; many of us
will be glad to send you snippets with translations into plainer
English, if possible. You won't learn much from our interpretations,
which may all be different, but perhaps you'll learn enough to translate
the thing yourself.
To all people who are overly concerned with the machinations of the
Backbone:
Nobody has the obligation to bring you your mail except your NC, and he
only is obligated to bring you your netmail. Policy does treat echomail
FidoNews 11-24 Page: 13 13 Jun 1994
like netmail in some ways, but remember; names mean nothing. Mail
"addressed to you" means "mail addressed to your listed node number."
Echomail isn't addressed to the intended recipient's node number; it's
addressed in bulk to each system it goes through. When that bundle of
echomail hits your uplink's system, it's all *HIS* mail, not yours.
By the same token, nobody has the right to prevent you from getting your
echomail somewhere else. Unless, of course, you enter into a contract
giving him that right. If you don't like the service your hub is
providing, go get your echomail somewhere else. I used a capital "B"
in "Backbone" above for a reason; it's the main one, but it ain't the
ONLY one. Find somebody who'll give you a feed, and feed anyone who
you want; voila, you're part of a new backbone.
I do wholeheartedly recommend that you accede to Elisted Moderator
requests to cut a feed, and worry about why it's being cut later; but
that's my opinion, not Fidonet Policy. Do it because it's right, not
because anyone says you have to.
BTW, nothing says you have to get your echomail from someone in your
Net, or your Region, or even your Zone. Hell, you don't even have to
get it from a Fidonet system; subscribe to Planet Connect.
The Backbone is a voluntary organization; if they wanna drop an echo,
tough noogies. Nothing obligates them to keep passing it, unless they
enter into a contract saying they'll do so.
If you don't agree with all the duties of a position, then don't agree
to accept the position. If you are a part of the official Backbone, and
decide you don't want to carry an echo that hasn't been dropped, then
resign your Backbone position. This means that others might not want to
feed you the mail, but oh well; you can always go elsewhere for your
feed, too. That's part of the delicious anarchy that makes this Net
work so well. (And it DOES work well, contrary to popular opinion. The
fact that people like Steve Winter still have a voice here is proof that
it works, as is the fact that we don't have to listen to the idiot
unless we choose to.)
Bottom line; nobody owes you the mail, and nobody can prevent you from
receiving it. Doesn't matter if your name is Shawn McMahon, Bob
Moravsik, Steve Winter, or Tom Jennings. If your *C, *EC, Hub, or
whatever you call him is acting like a child, then don't play at his
house any more.
PGP public key available upon request; FREQ "PGPKEY" during Z1MH only.
FidoNews 11-24 Page: 14 13 Jun 1994
Suggested amendment to POLICY4
by Dylan Harris, dylan@xenakis.demon.co.uk.
Suggested amendment to POLICY4
My work is likely to send me on trips to various parts of the world
over the next few years. I very much want to keep in touch, so I'm
going to purchase a laptop and mobile phone on the global GSM network
to do so.
I'll keep on the Internet by transferring my Internet server to the
laptop. The only consequence will be higher phone bills when I'm
abroad.
The problem is Fido. If I spend some time in another part of the
country, my geographic location has changed. Since POLICY4 defines
"a network is a collection of nodes in a local geographic area", I
would clearly have to change address, despite retaining the same
telephone number. This would screw up mail delivery completely.
But what happens if I get on a train and travel to Paris, and visit a
friend whose BBS's Internet address ends in demon.co.uk? My machine
doesn't change; my telephone number doesn't change. But, by the
rules, my Fido address has to change.
Ok, so now I travel to Estonia. My machine doesn't change; my phone
number doesn't change - but, by the Fido rules, I have to get a new
address.
Things start to get really silly when I tour the Commonwealth (an
association of some of the countries that were once or still are
occupied by the empire) and visit, say, Hong Kong, Australia and
South Africa. In each case, my machine doesn't change, my phone
number doesn't change, yet according to the Fido rules, I have to
change net address, zone and everything just because I happen to have
a job on the move.
The cheapest GSM telephone would cost me roughly $200 - the
connection fee is about $75, and I'd have to pay another $40 a month
to keep the service. Phone calls are not cheap, but they're not much
higher than normal mobile charges. In other words, prices mean it
won't be too long before there could be a number of sysops on the
move.
So in practical terms, the POLICY4 definition of net is faulty, and I
suggest it is changed to:
"a network is a collection of nodes"
by getting rid of the reference to geography. How should a node
determine which net to join? In the same way as the Internet - by
deciding for itself. Most of us are grown up.
After all, one on the main benefits of networking is to overcome
FidoNews 11-24 Page: 15 13 Jun 1994
the tyranny of distance, so it does seem a little silly to organise
networks to destroy that advantage. But that is another matter.
But, in the meantime, there is little benefit in going through the
whole mess of of finding a local node, getting connected to the net
and sending out many change of address messages everytime I travel,
especially since I'm unlikely to stay in once place for that much
time. I don't think its particularly practical to be proactive and
apply to every network in the world and ask for a provisional
address, just in case I happen to travel there one day. So I fear
that my new job and new machine means I have to leave Fido.
--
+---------------------------+----------------------------+
| Dylan Harris | dylan@xenakis.demon.co.uk |
| +44 933 460034 [Voice] | dylan@cix.compulink.co.uk |
| +44 933 460744 [Data] | dylan@Nag's Head, Hargrave |
+---------------------------+----------------------------+
----------------------------------------------------------------------
This is a serious proposal:
A long time I've tried to follow the content of Fidonews. It's not
allways possible. The file echos over here in Europe does sometimes
fail for long times, and this echo is surely not the highest on the
priority list.
It is no problem for us to just pass all that stuff that is of minor
to nil interest outside of zone 1, but I do seriously think you
would gain much better spread if you really did select between what
is of interest in other parts of the world and what is probably not.
A Fidonews with _no_ articles of exclusive interest for readers
here, would surely be much higher prioritized both by the
coordinators being responsible for the file echos, and by the nodes
who are expected to read it. If the result would be that the
international edition came only twice a month, or was only a few
pages long, then I think that's another reason why more people would
try to read it.
It is now and then discussed if there should be zonal or (more
likely) regional complement to your paper, but as long as the
distribution of Fidonews is mandatory, most people I have heard
(hmmm, ... seen writing) do think the need for such non-global
informations would be greatest in Zone-1 where Fidonews allready is
used as if it were your zonal publication.
kind regards!
/ Johan
jo@magnus.ct.se
FidoNews 11-24 Page: 16 13 Jun 1994
Dear Madam Emilia
Q: There's this goof in my favorite echo who goes around telling
everyone that he likes gooseberry jam. I like normal strawberry jam
like everyone else. I'm not prejeudiced, I don't mind what people
do in the privacy of their own homes, but he shouldn't go around in
everyone's face proselytizing his peculiar tastes. Children may
read what he writes, and want to try gooseberry jam. Restaurants
and supermarkets rarely have gooseberry jam, and children will be
marked for life as "different" if they falsely believe there is
nothing inconvenient about gooseberry jam. Unlike this ball of
slime, i am holy and righteous because i want to protect children.
Why can't this idiot keep his tastes to himself?
A: You are giving me a headache. How are you "protecting" children
if you are denying them the right to live their own lives? How are
you protecting children, or anyone, if you insist upon limiting their
choices, thereby curtailing the development of their facility to
reason? What if they discover that they *like* other forms of jam?
When concensus is understood to imply "rightness", society is
utterly prone to propoganda and doomed to inertia.
Q: My friend likes to play with spam<tm>. She thinks spam<TM> is a
fun addition to social encounters. This embarasses me. What can i
do?
A: You are lucky your friend does not bop you on the head for
insulting her by being embarassed by her. If you openly revere
sticks, is she embarrassed by you? To demand that everyone appear
to be the same as yourself will limit your ability to enjoy others,
because then you will not be able to know who they really are.
Q: I have a mail buddy in Europe. He is concerned that FidoNews
is representative only of North America because most its contents
are relevent only to Zone 1 issues. He's my mail buddy. I
empathize with his feelings of ostracisation, and this is
uncomfortable. I know that some people in Zones other than Zone 1
resent being obliged to carry FidoNews when most of its contents are
irrelevent to other Zones. How should I feel about this?
A: Why are you asking me what *you* should feel? I can not know
what you should feel, and if I pretended to know what you should
feel I am insulting you, and hope you would take some of your
valuable time to elighten me. It seems to me that happenings
"anywhere" in FidoNet are relevent to all "areas" of FidoNet because
FidoNet is global, and ideas are not tied to geography unless people
voluntarily limit their minds. Everything is analogous to
everything else, while hunting for ideas.
Q: I called the FidoNews BBS and it crashed on me. Why? Don't they
like me? I am very hurt by this experience. What is going on?
A: The BBS crashed because the Fidonews editrix thinks she knows
something about hardware, and is trying to help editor Don Tees
FidoNews 11-24 Page: 17 13 Jun 1994
maintain his system. She was trying to swap the BBS machine for one
that had a functional screen because she likes chatting with people
online. I hope you weren't trying to upload an article about the
pressingly time-relevent new BOP proposal. She tried to call ld to
the two callers who did not get a chance to leave messages, but she
still deserves to be spliced, flayed, then salted.
o o o O O O o o o h
----------------------------------------------------------------------
Creating an Online Civil Liberties Organisation
(in Australia)
by Michael Baker, 3:800/838 - mbaker@apanix.apana.org.au
PO Box 5, Flaxley SA 5153, Australia. Phone +61(8) 388 8439
I first wrote this article in January 1994 and have since updated it. It
is for two separate audiences: those who live in Australia, and those
who live elsewhere. It is about setting up organisations which will
promote the use of, and protect the rights or freedoms of users of
electronic communications. The model we are using for such an
organisation is the Electronic Frontier Foundation (EFF) in the States.
I and many others have set up an association which was incorporated
recently, Electronic Frontiers Australia Inc. (EFA). Primarily I have
written this article to encourage those of you who live in Australia to
take part in EFA. I am also keen to encourage those who don't live in
Australia to set up your own thing. To this end I will pass on our
experience so far and some of the advice I have been given on how to
proceed.
I first used BBS's over 8 years ago. More recently I started to access
the Internet. Some of the others initially involved included: Tom
Koltai, sysop of Kakadu Konnection BBS in Darwin; Michael Malone in
Perth who had recently setup iinet.com.au (the home of our mailing
list); Bill Holder also in Perth who was planning to set up a FidoNet
echo for us; and Dwayne Jones-Evans who is studying social aspects of
electronic networks at Latrobe University. We had become concerned with
potential threats to BBS's and the Internet, particularly here in
Australia. When we started there was a proposal here to censor computer
games which might have adversely affected BBS's. (Censorship of
computer games has now been introduced but it excludes BBS's.)
When I started to ask in BBS and Internet/Usenet conferences if anything
was being done to organise to fight that threat I also asked if there
was an organisation like the EFF in Australia. The answer was no but
several people said they were interested in forming one. In our
estimation what was needed was a proactive organisation which would
define, promote and defend online civil liberties, rather than a one off
reactive campaign. The specific issue of censorship of computer games
is simply one symptom of a larger malaise. It is EFA's goal to deal
with this bigger picture. I'll return to this later. First some
general background.
FidoNews 11-24 Page: 18 13 Jun 1994
The opportunities, the threats and what to do about it
======================================================
Networks like FidoNet and the Internet with their online conferences and
virtual communities and email have opened up a new medium for the
exchange of ideas and information. With the continuing fall in cost and
increase in power and capabilities of computers and networking
technology, these empowering and rapidly expanding media are becoming
more and more accessible, and more and more vital. So far users of such
technology have been able to utilize it's capacity for "many-to-many"
communication, in which anyone can be a creator and distributor as well
as a reader or consumer, with very few restrictions on what they say, or
who they say it to. It is as if each person has access to their own
printing press.
So the opportunities are there talk to anyone and listen to what anyone
wishes to announce. However there are those who have a tendency to
oppose such opportunities. In Australia we call such people wowsers.
{wowser (wou'z3r) n. [Aust. Slang] an extremely puritanical person, esp.
a killjoy or teetotaller - Collins Australian Pocket English Dictionary,
5th reprint of first edition, Australian Editor: W.A. Krebs, 1985,
William Collins Sons & Co. Ltd. Sydney.}
Wowsers have allies in the press and government. They tend to want to
restrict or control what others can and cannot do, and they often have
respectable-sounding reasons for wanting to control others. However if
they do achieve their end, then we shall all be the poorer - we shall
have lost some of our most cherished and guarded fundamental freedoms -
privacy, freedom of expression... etc.
There are two basic ways to handle such threats, one is to react to them
when they occur. The other is to go out and promote the type of future
you want. It is the latter that I favour. By actively promoting what
we want we have more chance of setting the agenda.
Australia
=========
Since my initial posts many people have expressed an interest in helping
set up EFA. We have a FidoNet echo (EFA, distributed via OZLINK) set up
to help us in our deliberations over the details of what EFA will do,
its objectives and how it will be run. We also have a Usenet newsgroup
(aus.org.efa) and a mailing list which allows you to send messages to
one place and have them automatically sent to everyone on the list. The
echo, newsgroup and mailing list are gated so that a message entered on
one appears on all three. To join the mailing list send email to
efa-request@iinet.com.au.
If you would like to be sent details on membership and a membership form
contact Brenda Aynsley, 3:620/243, send email to info@efa.iinet.com.au,
write to Electronic Frontiers Australia Inc., PO Box 382, North Adelaide
SA 5006, or call (08) 384 7316.
Elsewhere
=========
FidoNews 11-24 Page: 19 13 Jun 1994
For those of you who live else where who would also like to form an
online civil liberties organisation I have these suggestions:
o If you possibly can, get and use email addresses on Fidonet _and_
Internet, and any other widely used net in your country.
o Find other like minded people. Post messages in likely Fidonet echo
conferences stating what you want to do and ask who wants to do it
with you. It's just like voting (grin): "Post early, Post often."
o Get access to UseNet newsgroups and post articles there also. If you
can't get access to any of them yourself then find someone who does
and get them to post articles.
o If you have access to it read comp.org.eff.talk and post messages
there. comp.org.eff.talk is gated to the INET.EFF.TALK fidonet echo,
and the eff-talk@eff.org mailing list (ask eff@eff.org to join).
o Find a BBS sysop who is willing to set up an echo, and someone on the
Internet who can set up a mailing list, and soneone else who can set
up a Usenet newsgroup, for coordinating your activities. Get the
mailing list gated to the echo and the newsgroup.
o Find a volunteer coordinator, membership coordinator, public/press
relations officer, newsletter editor.
o Set a target date for the establishment of your organisation. (In
December 1993 I set a target of having EFA incorporated in February
1994. EFA was incorporated in May 1994. If the situataion in your
country is anything like Australia there will be issues to be dealt
with now. Don't take to long to get set up.)
o Via the echo/mailing list/newsgroup agree on the objectives of your
new organisation.
o Similarly agree on its (legal) structure, how it will operate, what
activities it will engage in, and what categories and costs of
membership it will have.
o Try and avoid having all of your discussions on one *net (like Fidonet
or Internet) to the exclusion of the other(s).
o If progress is too slow form a working group to move the action
forward. Invite those who are actively doing something (like setting
up the mailing list/echo/newsgroup, membership coordinator, newsletter
editor, etc.)
o Decide if it will be a volunteer supported organization, or if it will
be staffed (and where the funding for this will come from and how to
get it.)
o Agree on who will be the first office holders in your new
organisation, and ways of raising money and other forms of support,
educating people about the missions and issues of the organization,
FidoNews 11-24 Page: 20 13 Jun 1994
how to encourage participation, if and when to start or participate in
events such as conferences and conventions, etc.
o Keep Stanton McCandlish <mech@eff.org>, of the Electronic Frontier
Foundation, informed of your progress. (Several people now active in
setting up EFA first heard of it from Stanton's activities, and he is
maintaining a list of like minded organizations, the Outposts FAQ.)
o Announce the formation of your new organisation on echos and
newsgroups and ask people to join it.
International Contacts
======================
Some organisations like EFF already exist or are being formed:
US EFF Stanton McCandlish <mech@eff.org>
UK CommUnity Malcolm Arnold <marnold@cix.compulink.co.uk>
Australia EFA EFA, 3:632/552 <secretary@efa.iinet.com.au>
Japan EFJ efj-admin@twics.com
Norway EFN Micha Reisel <mreisel@oslonett.no>
Ireland EFI Tom Murphy <EFI@maths.tcd.ie>
Canada EFC D. Jones/J. Shallit <efc@graceland.uwaterloo.ca>
To contact someone with an Internet address from Fidonet, send netmail
to the nearest UUCP gate (GUUCP nodelist flag), addressed like so:
From: <you>
To: uucp, <uucpgate's nodenumber>
Subject: <subject here>
______________<body of message starts here>_________________
To: <internet address, e.g. user@site.domain>
<message here; note that the blank line after the second "To:" line,
the one in the body of the message, is MANDATORY.>
Why not form a local chapter of the EFF?
========================================
One of the first things I did was to contact EFF. Part of the advice I
received was that EFF doesn't have chapters due to the administrative
overhead involved. However, their board is encouraging others all over
the place to use Electronic Frontier in local organization names, to
make this as recognizable as possible and to foster a sense of united
purpose.
Acknowledgements
================
I would like to thank everyone who is working with me on establishing
EFA, and also Vicki Crawford, sysop of Computer Connection BBS,
3:800/838, and Stanton McCandlish <mech@eff.org>, for their continuing
support.
Metaphysical footnote
FidoNews 11-24 Page: 21 13 Jun 1994
=====================
Let us dwell on what could go right. The more we think of the future we
want, the more likely it is to come about, particularly when there are
many of us thinking about it. That is not to say that we should ignore
dangers and threats. We should be aware of them but not dwell on them.
This is just another way of saying that we should go out and say what
future we want, rather than just react and fight proposals which will
lead to futures we don't want.
----------------------------------------------------------------------
Nodelist review
-=> Note:
Forwarded (from: NETCON) by Barry Redwood using timEd.
Originally from Rick Johnston (1:229/2.0) to all.
Original dated: Jun 04 '94, 10:47
* Originally by Richard Bash, 1:105/68
* Originally to Rick Johnston, 1:12/0
* Originally dated 1 Jun 1994, 10:36
* Forwarded from 1:105/68, Combat Arms BBS in Portland OR
* Originally to Dallas Hinton on 1:17/0
Combat Arms BBS
P.O. Box 913
Portland, Oregon 97207-0913
Voice: (503) 223-3160
BBS: (503) 221-1777
Fido 1:105/68
June 1, 1994
A REVIEW OF THE FIDONET NODELIST
This material was originally prepared using NLSTATS.EXE, version
1.34. The statistics were compiled using Lotus 1-2-3 and MYSTAT. Here
is an analysis of the results of my review of this material. All
references to nodelist size mean the "raw," complete Fidonet nodelist.
This report was written at the request of Lisa Gronke, Net 105 Net Echo
Coordinator (NEC). The Combat Arms BBS has been a member of Net 105
since arriving in Portland. Explanatory notes are provided. They are
referenced by numbers in brackets (such as [1]). The notes appear at
the end of the file.
Regards,
Richard Bash
Combat Arms BBS SysOp
1:105/68
-=-=-=-=-=-=-
Generally this material indicates that each additional node[1]
FidoNews 11-24 Page: 22 13 Jun 1994
added to the nodelist[2] increases the size of the nodelist by about
84 bytes. Between June 6, 1993 and June 1, 1994 the nodelist grew
from 24,677 nodes (2,019,570 bytes) to 32,691 nodes (2,702,607
bytes). This reflects an average growth over this one year period of
about 668 nodes per month (averaging a growth in the size of the
nodelist of 56,920 bytes per month).
Zone 1[3] represents North America (the United States and
Canada), zone 2 is Europe, zone 3 is Australia and New Zealand, zone
4 encompasses all of Mexico, Central and South America, zone 5 is
Africa (most nodes are in southern Africa), and zone 6 represents
Asia. Zones 4 and 5 currently have fewer than 1,000 nodes each.
The principle growth, as expected, was in zones 1 and 2. Here
are the average node growths per month for each zone:
Z O N E
1 2 3 4 5 6
6/94 18127 11065 1243 554 172 1530
6/93 14333 7674 1067 394 127 1082
----- ----- ---- --- --- ----
Average 316 283 15 13 4 37
Lisa Gronke correctly pointed out that 32,768 (the number 2 raised
to the 15th power) nodes is the upper limit for some software[4]. That
should logically occur on Friday, June 3, 1994. Therefore some BBS
software (more technically, some BBS mailer programs) may experience
problems on that date. Hopefully the Combat Arms BBS will not be one of
them, since D'Bridge version 1.58 is in use here.
It is possible that this current crisis will result in addressing
the following issues:
a. Removal of duplicated nodes.
b. Removal of private nodes.
c. More rapid removal of "excessively" downed[5]
nodes (e.g.; there are presently 15 nodes
marked as "Down" in Net 105; the time period
they have been marked as Down is unknown).
d. Removal of nodes designated as "Hold"[6]
(e.g.; there is one node listed as Hold for
Net 105 at the time of this writing).
These recommendations will not ultimately avert the problems and
limitations of software with 2^15 limit on node handling capability.
That can only be addressed by farseeing coders, seemingly in short
supply in Fidonet.
-= DATA =-
Statistics for: NODELIST.147
Wed Jun 01 23:01:56 1994
Total nodes listed: 32691
FidoNews 11-24 Page: 23 13 Jun 1994
Total size in bytes: 2702607
- Node Summary - - Administrative Summary -
CM Nodes: 27518 (84.18 %) Admin. Nodes: 2310 ( 7.07 %)
MO Nodes: 3674 (11.24 %) --------------
LO Nodes: 717 ( 2.19 %) Zones: 6 ( 0.26 %)
Downed Nodes: 556 ( 1.70 %) Regions: 71 ( 3.07 %)
Private Nodes: 609 ( 1.86 %) Hosts: 718 (31.08 %)
Hold Nodes: 225 ( 0.69 %) Hubs: 1515 (65.58 %)
- Zone Node Usage Summary -
1: 18127 (55.45 %) 2: 11065 (33.85 %) 3: 1243 ( 3.80 %)
4: 554 ( 1.69 %) 5: 172 ( 0.53 %) 6: 1530 ( 4.68 %)
Statistics for: NODELIST.119
Sun May 01 19:23:12 1994
Total nodes listed: 32085
Total size in bytes: 2649031
- Node Summary - - Administrative Summary -
CM Nodes: 27029 (84.24 %) Admin. Nodes: 2274 ( 7.09 %)
MO Nodes: 3571 (11.13 %) --------------
LO Nodes: 690 ( 2.15 %) Zones: 6 ( 0.26 %)
Downed Nodes: 552 ( 1.72 %) Regions: 71 ( 3.12 %)
Private Nodes: 581 ( 1.81 %) Hosts: 713 (31.35 %)
Hold Nodes: 184 ( 0.57 %) Hubs: 1484 (65.26 %)
- Zone Node Usage Summary -
1: 17928 (55.88 %) 2: 10722 (33.42 %) 3: 1243 ( 3.87 %)
4: 542 ( 1.69 %) 5: 172 ( 0.54 %) 6: 1478 ( 4.61 %)
Statistics for: NODELIST.091
Sun Apr 03 19:03:00 1994
Total nodes listed: 31323
Total size in bytes: 2584313
- Node Summary - - Administrative Summary -
CM Nodes: 26393 (84.26 %) Admin. Nodes: 2237 ( 7.14 %)
MO Nodes: 3492 (11.15 %) --------------
LO Nodes: 658 ( 2.10 %) Zones: 6 ( 0.27 %)
Downed Nodes: 528 ( 1.69 %) Regions: 71 ( 3.17 %)
Private Nodes: 585 ( 1.87 %) Hosts: 706 (31.56 %)
Hold Nodes: 255 ( 0.81 %) Hubs: 1454 (65.00 %)
- Zone Node Usage Summary -
1: 17649 (56.35 %) 2: 10449 (33.36 %) 3: 1243 ( 3.97 %)
4: 502 ( 1.60 %) 5: 172 ( 0.55 %) 6: 1308 ( 4.18 %)
FidoNews 11-24 Page: 24 13 Jun 1994
Statistics for: NODELIST.063
Sun Mar 06 19:15:18 1994
Total nodes listed: 29949
Total size in bytes: 2469238
- Node Summary - - Administrative Summary -
CM Nodes: 25206 (84.16 %) Admin. Nodes: 2181 ( 7.28 %)
MO Nodes: 3256 (10.87 %) --------------
LO Nodes: 620 ( 2.07 %) Zones: 6 ( 0.28 %)
Downed Nodes: 515 ( 1.72 %) Regions: 70 ( 3.21 %)
Private Nodes: 586 ( 1.96 %) Hosts: 684 (31.36 %)
Hold Nodes: 214 ( 0.71 %) Hubs: 1421 (65.15 %)
- Zone Node Usage Summary -
1: 17235 (57.55 %) 2: 9514 (31.77 %) 3: 1198 ( 4.00 %)
4: 522 ( 1.74 %) 5: 172 ( 0.57 %) 6: 1308 ( 4.37 %)
Statistics for: NODELIST.035
Sun Feb 06 22:41:17 1994
Total nodes listed: 29574
Total size in bytes: 2433288
- Node Summary - - Administrative Summary -
CM Nodes: 24835 (83.98 %) Admin. Nodes: 2152 ( 7.28 %)
MO Nodes: 3235 (10.94 %) --------------
LO Nodes: 594 ( 2.01 %) Zones: 6 ( 0.28 %)
Downed Nodes: 484 ( 1.64 %) Regions: 71 ( 3.30 %)
Private Nodes: 601 ( 2.03 %) Hosts: 677 (31.46 %)
Hold Nodes: 237 ( 0.80 %) Hubs: 1398 (64.96 %)
- Zone Node Usage Summary -
1: 16903 (57.15 %) 2: 9514 (32.17 %) 3: 1199 ( 4.05 %)
4: 478 ( 1.62 %) 5: 172 ( 0.58 %) 6: 1308 ( 4.42 %)
Statistics for: NODELIST.365
Fri Dec 31 14:11:47 1993
Total nodes listed: 28825
Total size in bytes: 2369306
- Node Summary - - Administrative Summary -
CM Nodes: 24124 (83.69 %) Admin. Nodes: 2124 ( 7.37 %)
MO Nodes: 3145 (10.91 %) --------------
LO Nodes: 578 ( 2.01 %) Zones: 6 ( 0.28 %)
Downed Nodes: 524 ( 1.82 %) Regions: 71 ( 3.34 %)
Private Nodes: 588 ( 2.04 %) Hosts: 669 (31.50 %)
Hold Nodes: 283 ( 0.98 %) Hubs: 1378 (64.88 %)
FidoNews 11-24 Page: 25 13 Jun 1994
- Zone Node Usage Summary -
1: 16460 (57.10 %) 2: 9231 (32.02 %) 3: 1196 ( 4.15 %)
4: 458 ( 1.59 %) 5: 172 ( 0.60 %) 6: 1308 ( 4.54 %)
Statistics for: NODELIST.330
Sun Nov 28 12:30:01 1993
Total nodes listed: 27217
Total size in bytes: 2241340
- Node Summary - - Administrative Summary -
CM Nodes: 22796 (83.76 %) Admin. Nodes: 2011 ( 7.39 %)
MO Nodes: 2847 (10.46 %) --------------
LO Nodes: 513 ( 1.88 %) Zones: 6 ( 0.30 %)
Downed Nodes: 450 ( 1.65 %) Regions: 70 ( 3.48 %)
Private Nodes: 568 ( 2.09 %) Hosts: 644 (32.02 %)
Hold Nodes: 177 ( 0.65 %) Hubs: 1291 (64.20 %)
- Zone Node Usage Summary -
1: 16014 (58.84 %) 2: 8146 (29.93 %) 3: 1196 ( 4.39 %)
4: 435 ( 1.60 %) 5: 172 ( 0.63 %) 6: 1254 ( 4.61 %)
Statistics for: NODELIST.302
Thu Nov 04 06:13:17 1993
Total nodes listed: 25469
Total size in bytes: 2101107
- Node Summary - - Administrative Summary -
CM Nodes: 21253 (83.45 %) Admin. Nodes: 1898 ( 7.45 %)
MO Nodes: 2559 (10.05 %) --------------
LO Nodes: 461 ( 1.81 %) Zones: 6 ( 0.32 %)
Downed Nodes: 448 ( 1.76 %) Regions: 69 ( 3.64 %)
Private Nodes: 561 ( 2.20 %) Hosts: 636 (33.51 %)
Hold Nodes: 177 ( 0.69 %) Hubs: 1187 (62.54 %)
- Zone Node Usage Summary -
1: 15811 (62.08 %) 2: 6655 (26.13 %) 3: 1182 ( 4.64 %)
4: 423 ( 1.66 %) 5: 172 ( 0.68 %) 6: 1226 ( 4.81 %)
Statistics for: NODELIST.274
Fri Oct 01 12:41:25 1993
Total nodes listed: 25998
Total size in bytes: 2138908
- Node Summary - - Administrative Summary -
CM Nodes: 21834 (83.98 %) Admin. Nodes: 1955 ( 7.52 %)
FidoNews 11-24 Page: 26 13 Jun 1994
MO Nodes: 2656 (10.22 %) --------------
LO Nodes: 2656 ( 1.82 %) Zones: 6 ( 0.31 %)
Downed Nodes: 481 ( 1.85 %) Regions: 69 ( 3.53 %)
Private Nodes: 520 ( 2.00 %) Hosts: 633 (32.38 %)
Hold Nodes: 217 ( 0.83 %) Hubs: 1247 (63.79 %)
- Zone Node Usage Summary -
1: 15423 (59.32 %) 2: 7614 (29.29 %) 3: 1159 ( 4.46 %)
4: 417 ( 1.60 %) 5: 172 ( 0.66 %) 6: 1213 ( 4.67 %)
Statistics for: NODELIST.246
Fri Sep 03 10:04:10 1993
Total nodes listed: 25182
Total size in bytes: 2069460
- Node Summary - - Administrative Summary -
CM Nodes: 21133 (83.92 %) Admin. Nodes: 1886 ( 7.49 %)
MO Nodes: 2506 ( 9.95 %) --------------
LO Nodes: 2506 ( 1.84 %) Zones: 6 ( 0.32 %)
Downed Nodes: 497 ( 1.97 %) Regions: 69 ( 3.66 %)
Private Nodes: 527 ( 2.09 %) Hosts: 620 (32.87 %)
Hold Nodes: 246 ( 0.98 %) Hubs: 1191 (63.15 %)
- Zone Node Usage Summary -
1: 15114 (60.02 %) 2: 7160 (28.43 %) 3: 1138 ( 4.52 %)
4: 417 ( 1.66 %) 5: 172 ( 0.68 %) 6: 1181 ( 4.69 %)
Statistics for: NODELIST.211
Fri Aug 06 12:25:22 1993
Total nodes listed: 24805
Total size in bytes: 2036008
- Node Summary - - Administrative Summary -
CM Nodes: 20792 (83.82 %) Admin. Nodes: 1857 ( 7.49 %)
MO Nodes: 2474 ( 9.97 %) --------------
LO Nodes: 2474 ( 1.79 %) Zones: 6 ( 0.32 %)
Downed Nodes: 481 ( 1.94 %) Regions: 68 ( 3.66 %)
Private Nodes: 530 ( 2.14 %) Hosts: 611 (32.90 %)
Hold Nodes: 231 ( 0.93 %) Hubs: 1172 (63.11 %)
- Zone Node Usage Summary -
1: 14846 (59.85 %) 2: 7160 (28.87 %) 3: 1105 ( 4.45 %)
4: 404 ( 1.63 %) 5: 127 ( 0.51 %) 6: 1163 ( 4.69 %)
Statistics for: NODELIST.169
Tue Jun 29 09:36:17 1993
Total nodes listed: 24819
FidoNews 11-24 Page: 27 13 Jun 1994
Total size in bytes: 2034163
- Node Summary - - Administrative Summary -
CM Nodes: 20850 (84.01 %) Admin. Nodes: 1862 ( 7.50 %)
MO Nodes: 2461 ( 9.92 %) --------------
LO Nodes: 2461 ( 1.84 %) Zones: 6 ( 0.32 %)
Downed Nodes: 462 ( 1.86 %) Regions: 67 ( 3.60 %)
Private Nodes: 533 ( 2.15 %) Hosts: 611 (32.81 %)
Hold Nodes: 145 ( 0.58 %) Hubs: 1178 (63.27 %)
- Zone Node Usage Summary -
1: 14435 (58.16 %) 2: 7674 (30.92 %) 3: 1071 ( 4.32 %)
4: 394 ( 1.59 %) 5: 127 ( 0.51 %) 6: 1118 ( 4.50 %)
Statistics for: NODELIST.155
Sun Jun 06 09:23:23 1993
Total nodes listed: 24677
Total size in bytes: 2019570
- Node Summary - - Administrative Summary -
CM Nodes: 20692 (83.85 %) Admin. Nodes: 1860 ( 7.54 %)
MO Nodes: 2482 (10.06 %) --------------
LO Nodes: 2482 ( 1.80 %) Zones: 6 ( 0.32 %)
Downed Nodes: 403 ( 1.63 %) Regions: 67 ( 3.60 %)
Private Nodes: 546 ( 2.21 %) Hosts: 609 (32.74 %)
Hold Nodes: 148 ( 0.60 %) Hubs: 1178 (63.33 %)
- Zone Node Usage Summary -
1: 14333 (58.08 %) 2: 7674 (31.10 %) 3: 1067 ( 4.32 %)
4: 394 ( 1.60 %) 5: 127 ( 0.51 %) 6: 1082 ( 4.38 %)
-= REFERENCES =-
[1] A "node" is the designation given to a BBS system which is a
member of Fidonet. Fidonet is a worldwide organization of
bulletin board systems (BBS).
[2] A "nodelist" is a document used by Fidonet that acts as a
telephone directory. It contains the Fidonet designation for
the member bulletin board system (its "node" number), the name
of the BBS, the name of the system operator (SysOp) of the BBS,
the telephone number of the BBS, the city and state (or city
and country if outside the U.S.) where the BBS is located, and
some codes relating to the type of modem and software in use by
the BBS. The Fidonet nodelist is updated each Friday. It may be
downloaded from the Combat Arms BBS by downloading NODELIST.ZIP.
At the time of this writing on June 1, 1994 there were 33,739
lines in the nodelist and the nodelist size (unZIPped) was
2,702,607 bytes.
FidoNews 11-24 Page: 28 13 Jun 1994
[3] The world is divided into "zones" by Fidonet. There are six such
zones. The United States is in Zone 1.
[4] By "software" I am referring to the software that bulletin board
systems use to answer the telephone, transfer messages between
each other, etc. This is referred to as a "mailer." There are a
variety of such mailer packages available. The Combat Arms BBS
uses one called D'Bridge (version 1.58).
[5] Fidonet member bulletin boards which are experiencing software
problems, etc. have a label in front of the listing in the
nodelist called "Down." There are presently 556 such designated
nodes. The problem is that these notations often remain for
lengthy periods. The Down label is for temporary conditions. If
the problems persist, the node should be removed from the
nodelist by the applicable Fidonet Net Coordinator (NC).
[6] Another designator label for some nodes in the nodelist is "Hold."
There are 225 of them currently in the nodelist. Why are they
so listed? I have no idea and could not get a satisfactory answer
when I made inquiries about it. It seems to be another way, like
Down, of designating a node temporarily inactive. One objection
is that such designations should not be used at all. In point of
fact, a node is either available to receive calls or it is not.
Some object that if the node is not available to receive calls,
then the nodelist entry for that node should be removed from the
nodelist. When the node is available to receive calls again, it
should be re-entered into the nodelist. As I stated earlier, the
Down and Hold labels seem to be attempts to temporarily designate
some nodes as incapable of receiving mail. An ongoing problem is
that often such labels remain for more than a week or two.
Generally the nodelist seems to be in need of some serious review.
There are instances of duplications in the nodelist. There are the
arguments against nodes labelled "Private" that should be considered,
as with nodes labelled Hold or Down. While removing all such Private,
Hold and Down designated nodes would only remove 1,317 nodes in the
Nodelist at the time of this writing, it would have another advantage:
it would indicate that attention was being paid to the nodelist. There
are an unknown number of duplications and surely some other listings
that should be deleted. It is the responsibility of each NC to
regularly review the listings for his net and to purge listings as
needed. It would seem that few NC's routinely complete this laborious
housekeeping task. Possible solutions include designating another node
in the net to regularly review the particular net's entries and to send
reports to the NC containing discrepancies.
-= END OF REPORT =-
----------------------------------------------------------------------
the use of e-mail
Alexander Lange (2:2487/8014.169)
Dear Editors,
FidoNews 11-24 Page: 29 13 Jun 1994
I am participating in FidoNet for some years now I and today I read the
article about Fluff in FNews 21/94: It strikes the point!
Sometimes I think about the use of e-mail and I always wonder what use
I have from it. Most of the mails I read are a waste of time. I spend
hours for reading mails and when I go to bed, one thought comes to my
mind: "_Again_ -- you didn't get any valuable information at all today."
But I still participate in FidoNet and I don't know why. :-/
The best thing is the Newsletter. It's *nearly* the *only* piece of
information in this net. I just want to THANK you for it.
I think the problem is that everybody think s/he has got something
important to say but has not. :-(
Bless! ALex
P.S.: And again I produced another useless msg that is send around the
world...
----------------------------------------------------------------------
========================================================================
Fidonews Information
========================================================================
------- FIDONEWS MASTHEAD AND CONTACT INFORMATION ----------------
Editors: Sylvia Maxwell, Donald Tees
Editors Emeritii: Thom Henderson, Dale Lovell,
Vince Perriello, Tim Pozar
Tom Jennings
"FidoNews" BBS
FidoNet 1:1/23
BBS +1-519-570-4176, 300/1200/2400/14400/V.32bis/HST(DS)
Internet addresses:
Don & Sylvia (submission address)
editor@exlibris.tdkcs.waterloo.on.ca
Sylvia -- max@exlibris.tdkcs.waterloo.on.ca
Donald -- donald@exlibris.tdkcs.waterloo.on.ca
Tim -- pozar@kumr.lns.com
(Postal Service mailing address)
FidoNews
128 Church St.
Kitchener, Ontario
Canada
N2H 2S4
Voice: (519) 570-3137
Published weekly by and for the members of the FidoNet international
amateur electronic mail system. It is a compilation of individual
articles contributed by their authors or their authorized agents. The
FidoNews 11-24 Page: 30 13 Jun 1994
contribution of articles to this compilation does not diminish the
rights of the authors. Opinions expressed in these articles are those
of the authors and not necessarily those of FidoNews.
Authors retain copyright on individual works; otherwise FidoNews is
Copyright 1994 Sylvia Maxwell. All rights reserved. Duplication and/or
distribution permitted for noncommercial purposes only. For use in
other circumstances, please contact the original authors, or FidoNews
(we're easy).
OBTAINING COPIES: The-most-recent-issue-ONLY of FidoNews in electronic
form may be obtained from the FidoNews BBS via manual download or
Wazoo FileRequest, or from various sites in the FidoNet and Internet.
PRINTED COPIES may be obtained from Fido Software for $10.00US each
PostPaid First Class within North America, or $13.00US elsewhere,
mailed Air Mail. (US funds drawn upon a US bank only.)
INTERNET USERS: FidoNews is available via FTP from ftp.fidonet.org,
in directory ~ftp/pub/fidonet/fidonews. If you would like a FAQ, or
have questions regarding FidoNet, or UUCP<==>FidoNet gateways, please
direct them to David Deitch (1:133/411@fidonet) at
deitch@gisatl.fidonet.org.
SUBMISSIONS: You are encouraged to submit articles for publication in
FidoNews. Article submission requirements are contained in the file
ARTSPEC.DOC, available from the FidoNews BBS, or Wazoo filerequestable
from 1:1/23 as file "ARTSPEC.DOC". Please read it.
"Fido", "FidoNet" and the dog-with-diskette are U.S. registered
trademarks of Tom Jennings, and are used with permission.
Asked what he thought of Western civilization,
M.K. Gandhi said, "I think it would be an excellent idea".
-- END
----------------------------------------------------------------------

Reference in New Issue View Git Blame Copy Permalink