ftp.wwiv.com/ftp.wwiv.com.zip/ftp.wwiv.com/pub/MISC/STNL0306.ZIQ/POLICY.009

Text File | 2005-04-29 | 20KB | 415 lines

Sysop's TechNet Policy Document revision 009                          04/01/98

--- Overview -----------------------------------------------------------------

This document establishes the policy for sysops who are members of the
Sysop's TechNet organization of Bulletin Board Systems and electronic mail
transportation.

Sysop's TechNet is an organization of sysops whom are interested and eagre
to pursue the development and support of Bulletin Board Software and related
programs.  To this extent, Sysop's TechNet is an organization of dilligent
systems operators who wish to keep their hobby alive and pursue the
development of the associated programs and standards.

Although primarily a FidoNet Technology network, Sysop's TechNet (also referred
to as STN) is not associated with nor in competition with the FidoNet network.
STN is simply another alternative network where sysop support is the primary
focus.

Portions new to any given revision are denoted at the beginning of the line
by the '|' character.

1.  Language

To facilitate the largest possible readership, all international STN documents
will be written in English.  Translation into other languages is encouraged.

The primary language of the network itself, however, will remain strictly
english.


2.  Introduction

Sysop's TechNet was founded on May 16, 1996 by founder Vincent Danen and co-
founder Kevin Nunn.  It was founded in an effort to provide support for
systems operators, and since there were no other sysop-oriented networks, that
were solely of that nature, STN is the first.

STN is a network that many felt was necessary among the BBS world.  There was
a lack of comraderie among the nodes of larger networks, and a power-struggle
that was egotistical in nature by iron-fisted moderators and coordinators.
STN was founded to remedy that sorry situation, and to provide an alternative
to the abuse sometimes found in other networks, yet at the same time provide
the support sysops around the world craved.  Within the first year of
existance, STN gathered over 80 individual nodes across the globe, making it
one of the fastest growing echomail networks available.

The goals of STN are to provide information and support to sysops, in an
honest and friendly fashion.  To provide opportunities for developers to
inform the public of their product and support it directly.  This benefits the
end user as well as the developer by providing a mutual relationship of
support and financial gain.  Although STN is not a commercial network in
nature, we do not oppose advertising and promotion of individual products.

To this end, Sysop's TechNet is a tool to be used by sysops who wish to learn
more about the hobby, strengthen their own systems as well as find
alternatives to software they use, as well as inform them of other products
available, and to provide support for those selfsame products.


3.  Organization

The STN network is fashioned after the typical FTN-style network.  In this,
STN consists of points, individual nodes, local hubs, hosts, regional
| coordinators, and finally the international coordinators.

STN is divided into nine major regions that cover the entire world.  Below
these regions are individual hosts which are split up based on areacode.  The
hosts maintain a specific areacode, and provide for the individual nodes
beneath.  Hubs may be used in networks to reduce the costs of long distance.

| The International Coordinator(s) have final say over all things.  Consider them
| the monarchs of the network.  All final decisions are his to make.  However, STN
is governed, more or less, by a Regional Council, made up of the nine regional
coordinators.  The Regional Council dictates the direction of the network,
accepts applications, and solves disputes on a regional basis.  If there are
ever any inter-regional conflicts, the regionals will attempt to mend the
| dispute, but the International Coordinator(s) have final say.

Echomail and netmail is distributed along these channels.  STN is not strict
in the method of obtaining an echomail feed, however it is desireable that one
remains within the region for obtaining their feed.  Inter-regional feeds are
possible, of course, however they are discouraged for simplicity's sake.
Inter-regional feeds can make the routing of netmail difficult, and delivery
cannot be ensured.

Within each region are the regional coordinators and the Regional Internet
Hubs.  The RIHs are individuals within a region who provide echomail feeds
via the internet to networks within that region.  RIHs can utilize any or all
of the following internet transport methods but is not limited to:

    Transx
    E-mail
    Fido2Internet
    Internet Rex
    AllFix
    WaterGate's MailTunnel
    FTP
    Vmodem/Telnet polls
    TCP/IP
    QWK

If this form of echomail distribution is undesirable or unfeasible for a
network, landline connections will be required.  Alternative methods of
transportation will be considered as well.


--- Network Information and Regulations --------------------------------------

1.   Nodelists

The nodelist is an ASCII file that is updated weekly containing the node
addresses of all the members of STN.  The nodelist does not contain point
information.

The IC releases the nodelist each Friday morning, therefore all regionals must
have their nodelist segment in to the IC prior to Thursday morning each week.
It is up to the individual regional whether or not they will require their
hosts to deliver similar nodelist segments to them in time enough to process
and send their own segment to the IC by the required time.


2.  Encryption of Mail

STN does not advocate the use of encrypted mail, however neither does it forbid
the use.  Encrypted mail may be used in netmail alone, whether routed or
direct.  Encrypted mail may not be used in echomail areas.  Use of PGP and
similar programs to provide digital signatures or fingerprints is, however,
encouraged to ensure the integrity of mail for those concerned.  The nodelist
flag NCR must be observed where encrypted mail is concerned, however.  The NCR
flag is placed on systems whom, by country law, may not receive or send any
encrypted mail.


3.  Routed Netmail

Netmail is private person to person mail.  It may be crashed direct or routed
through other systems to reduce costs for the sender.  However, routed netmail
must not be altered in any way by the systems it is being routed through.
Tampering with routed netmail is grounds for dismissal.

Disclosing the contents of routed netmail to other parties other than the
sender or recipient is also grounds for dismissal.  Netmail, whether direct or
routed, is considered private and the contents thereof must remain private.
This does not apply to echomail.


4.  Private Nodes

Private nodes do not, and will not, exist in STN.  Mail-only nodes are
admissable, however.  Do not ask to have private status in the network as you
will be refused.  This does not include points.
Unless a Pvt node have a *Telnet* bbs system behind his mailer, and can be
reach by this Telnet system to BBs.

5.  Dismissal

Nodes may be dismissed from the network for a number of reasons.  Foremost of
these is aggressive or overly annoying behaviour.  On the recommendation of
the Regional Council or of network moderators, an individual being blatantly
obnoxious, whether in private or publically in echomail, may be dismissed.
Complaints by other nodes may cause investigation as to the validity of the
complaints, and if severe enough, may cause dismissal.

Nodes may also be dismissed from the network due to failure to comply with
policy standards, or by being unresponsive.  From time to time, by the IC's
discretion, messages may be posted in the administrative echo (STN.ADMIN) that
requires responses from nodes.  If these responses are not forthcoming, a node
may be dismissed.


6.  Obtaining a Node Addresses

Currently, node addresses are issued by regional coordinators and the IC.
Hosts are not permitted to issue node addresses.  To obtain a node address,
you must fill out the included application form (STN.APP) and forward it to
the host in your area (who must then forward it to the RC or IC), or send it
directly to the RC or IC.  For quickest results, sending directly to the RC
of your area is desirable.

6.1  Finding your RC

The world has been divided into 9 regions for STN, numbering 1000, 2000, 3000,
4000, 5000, 6000, 7000, 8000, and 9000.  To find out which region you belong
in, observe the following:

  Region        Geographical Location
  ------------- ----------------------------------------------------------
  1000          Canada
  2000          Israel, India, Africa
  3000          Indonesia, Philippines, Asia
  4000          Eastern USA:  MI, IN, KY, TN, GA, FL, SC, NC, VA, WV, OH,
                  PA, NY, NJ, DE, MD, DC, CT, NH, VT, ME, RI, MN, IA, WI,
                  IL, AK
  6000          Western USA:  CA, NV, UT, AZ, CO, NM, KS, OK, TX, AR, LA,
                  MS, AL, FL, HI, WA, OR, ID, MT, WY, ND, SD, NE
  7000          Europe, Former Soviet Union
  8000          Australia, New Zealand
  9000          South America, Mexico

7.  Down Systems and Absenses

If your system is going down for a prolonged period of time (more than two
days), inform your host or regional coordinator as quickly as possible.  This
will prevent unnecessary wasted calls to your system when down, as well as the
possibility of dismissal.  If you are going to be absent from your system and
it will be unattended for more than two days, inform your host or regional
coordinator as well, so that if problems do arise, or connections are not
obtained, they know ahead of time that you are gone.  This is simply a matter
of courtesy and respect to other members of the network.


8.  General Guidelines

There are very few guidelines in STN, and they are more common sense
guidelines than rules of the network.  However, they must be adhered to.
Failure to comply with these simple guidelines may be cause for dismissal.

1) This is a real-name only network.  Aliases are not permitted in the
   echomail areas.

2) Excessive use of vulgar language is not tolerated.  Minors may be using
   (and are encouraged) to use this network.  We don't want to offend them or
   their parents, and basically we don't want to offend anyone.  If you can
   say it without the extra "flair", please do so.

3) The excessive use of quoting is frowned upon.  It is considered
   exceptionally rude, and particularly useless.  People want to read your
   replies, not what 20 people previously said.

4) There is to be no software bashing without a legitimate reason.

5) All members of the network are equal.  The obvious structure of the network
   (in regards to hubs, hosts, RCs, etc.) implies power to certain positions.
|   The only true powers in the network are the moderators, the RCs, and the
|   ICs.

6) If there is a problem between sysops or systems, take it to netmail.  It
   doesn't belong in the echos.  If someone is creating a problem, chances are
   the administrators will pick up on it and deal with it.  Don't presume to
   take our place in the event that such action needs to be taken.  We won't
   like it.

7) On the above note, flaming, derogatory remarks, racial/ethnic/sexual slurs
   are not permitted.  If any of this is noted, the offending user will have
   ONE warning.  If it is not heeded, the sysop must remove their access.  If
   the sysop cannot or will not comply with this, their feed will be cut.
   This also includes any and all forms of harrassment, whether the originator
   sees it as such or not.

8) The File Announcements echo may be used to announce any files coming into
   your system, and all sysops in the net are encouraged to use the echo.
   However, announcements containing adult files and/or illegal (pirated)
   files are frowned upon.  Please keep this in mind when you announce your
   files.  It is also strongly suggested that you announce your files once
   per day. This is by no means mandatory, but it would be appreciated if done.

9) The administration echo, STN.ADMIN, is mandatory reading.  All nodes are
   required to read the information posted in that echo.  Browsing the
   messages is encouraged.  Ignoring messages or the echo itself is not.
   Important information vital to the network is often posted there.  A sysop
   may be inadvertantly dismissed because they do not read in that echo.


--- Requirements of Coordinators ---------------------------------------------

1.  Nodelist Availability

Each coordinator should have the STN nodelist available for download and file
request.  Along with this, each coordinator should also have the latest
informational package available.  This facilitates the growth of the network
by making information available.


2.  Nodelist Segments

Each RC is responsible for maintaining one working copy of MakeNL or a similar
program/method to provide the IC with a nodelist segment prior to Thursday
morning every week.  This segment is the make-up of the entire region.  This
is required of all RCs.  It is up to individual RCs as to whether they wish
their hosts to participate in this practice and send them nodelist segments of
each network.


3.  New Sysops

Coordinators are encouraged to freely provide information on STN, whether it
be verbally, through discussion or advertisements, or by having and spreading
the informational package.  The growth of STN depends on how free we are with
the information concerning it, and how much we are willing to bend to provide
an applying sysop every courtesy they deserve.  Alienating new nodes because
of lack of information or rude dispositions is frowned upon.

Also, when a host is assigned a new downlink, they must act as quickly as
possible to setup and provide a feed for the new sysop.  This will show the
new sysop the true spirit of STN as opposed to other networks.  It will also
show STN's efficiency as an organization and as a network.

In the event that a new sysop joins and becomes the second system of a
one-system network and the host of that network does not respond or is seen as
unfit to be a network coordinator, the existing NC may be demoted to simple
node status and the new node provided with NC status.  This will ensure that
the pro-active members of the network remain in positions to further the
network, instead of being hampered by those who propogate nothing.


4.  Technological Competence

Coordinators are required to have previous knowledge of FTN networks and their
own software.  This facilitates efficiency when helping inexperienced sysops
join the network, as well it provides a solid backbone for network operations.
An inept coordinator is not one who can do their job, nor who can do their
best in a position granted them.  Therefore, some competence with FTN networks
and FTN technology is required.


5.  NCs

Network Coordinators are hosts who maintain individual areacode-assigned
networks.  It is their responsibility to ensure the smooth maintenance of the
network, and to keep abreast of any problems within the network.  It is also
highly desirable of NCs to promote STN in their local area and bring new
nodes into their network.

On the discretion of the RC, NCs may be required to submit a nodelist segment
each week for their network.  NCs are required to forward the full nodelist,
weekly, to their downlinks.


6.  RCs

Regional Coordinators maintain a group of networks within their assigned
region.  It is their responsibility to ensure smooth maintenance of their
region, and to keep abreast of any problems within the region, or individual
networks.  In a network or regional scenario, the RC's decision supercedes
all others with the exception of the ICs.  RCs should also be promoting STN in
their local areas and region-wide if possible.  This can be done through
advertising in other networks, providing and spreading informational packages,
and other means.

RCs are required to submit a regional nodelist segment to the IC prior to
Thursday morning each week.  RCs are required to forward the full nodelist,
weekly, to their downlinks.


7.  RIHs

Regional Internet Hubs are required to provide a full echomail backbone feed,
including the alternate backbone, and a full fileecho feed to networks within
| their region.  RIHs receive their feed from the ICs and forward mail down to
those networks within their region who may require it.  RIHs are free to
choose whichever internet transport method they prefer and are able to
provide.  In the event that a network requires a transport method the RIH
cannot provide, RIHs in other regions, or the ICs, may be required to provide
the feed.


| 8.  ICs

| The International Coordinators maintain the entire nodelist and must keep
| abreast of all things in the network.  The ICs maintain the echomail backbone,
| as well as the alternate backbone, and the fileecho system.  The ICs have final
| say on all matters of the network, and their primary function is to ensure the
| network is smoothly run.  Every Friday morning, the ICs release a full
| nodelist to all downlinks and regionals.

| The ICs are also responsible for maintaing all documents pertaining to STN, as
| well as a timely release of informational packages as required.

| If there are ever conflicts in the network, as human nature dictates there
| must, the ICs have final say over all things.  The ICs will fairly consider
| appeals and requests, and will weigh the opinions and recommendations of the
| Regional Council, moderators, and individual NCs.  In all cases, the
| offending node(s) have the right to defend themselves.  The ICs will fairly
| consider their defense, and make any judgements on them.  The ICs will always
| try to be fair, yet will consider the good of the entire network over the good
| of individual node(s).


9.  Moderators

Moderators are necessary to the network to ensure that echomail traffic is not
polluted with off-topic conversation, illegal discussions, or otherwise
messages that do not conform to the ideals of the network.  There will be no
more than two moderators per echomail area.  Any individual interested in
becoming a moderator in a specific echomail area(s) must send a message of
request to the ICs.

--- Credits and Acknowledgments ----------------------------------------------

1.  FidoNet Technical Standards (FTS)

The Fidonet Technical Standards Committee (FTSC) is a deliberative body
charged with developing and maintaining technical standards for operations
in a Fidonet Technology Network (FTN).  All software used in Sysop's TechNet
communications must be in compliance with the appropriate standards, which
include:

     FTS-0001  A basic Fidonet technical standard, R Bush
     FTS-0004  Echomail specifications, B Hartman
     FTS-0005  The distribution nodelist, B Baker, R Moore
     FTS-0006  YOOHOO and YOOHOO/2U2, V Periello
     FTS-0007  SEAlink protocol extension, P Becker
     FTS-0008  Bark file-request protocol extension, P Becker
     FTS-0009  Message identification and reply linkage, j nutt

Relating to FTS-0009, use of the MSGID kludge in echomail messages is strongly
encouraged to prevent duplicates of echomail messages in the network.

Sysop's TechNet may optionally use standards that have not yet been approved
by the FTSC.  This includes, but is not limited to, nodelist flags.


Fido and FidoNet are registered trademarks of Fido Software, Inc.