     Volume 6, Number 17                                 24 April 1989
     +---------------------------------------------------------------+
     |                                                  _            |
     |                                                 /  \          |
     |                                                /|oo \         |
     |        - FidoNews -                           (_|  /_)        |
     |                                                _`@/_ \    _   |
     |        International                          |     | \   \\  |
     |     FidoNet Association                       | (*) |  \   )) |
     |         Newsletter               ______       |__U__| /  \//  |
     |                                 / FIDO \       _//|| _\   /   |
     |                                (________)     (_/(_|(____/    |
     |                                                     (jm)      |
     +---------------------------------------------------------------+
     Editor in Chief:                                  Vince Perriello
     Editors Emeritii:                                     Dale Lovell
                                                        Thom Henderson
     Chief Procrastinator Emeritus:                       Tom Jennings
     Contributing Editors:                                   Al Arango
     
     FidoNews  is  published  weekly  by  the  International   FidoNet
     Association  as  its  official newsletter.  You are encouraged to
     submit articles for publication in FidoNews.  Article  submission
     standards  are contained in the file ARTSPEC.DOC,  available from
     node 1:1/1.    1:1/1  is  a Continuous Mail system, available for
     network mail 24 hours a day.
     
     Copyright 1989 by  the  International  FidoNet  Association.  All
     rights  reserved.  Duplication  and/or distribution permitted for
     noncommercial purposes only.  For  use  in  other  circumstances,
     please contact IFNA at (314) 576-4067. IFNA may also be contacted
     at PO Box 41143, St. Louis, MO 63141.
     
     Fido  and FidoNet  are registered  trademarks of  Tom Jennings of
     Fido Software,  164 Shipley Avenue,  San Francisco, CA  94107 and
     are used with permission.
     
     We  don't necessarily agree with the contents  of  every  article
     published  here.  Most of these materials are  unsolicited.    No
     article will be rejected which is properly attributed and legally
     acceptable.    We   will  publish  every  responsible  submission
     received.


                        Table of Contents
     1. ARTICLES  .................................................  1
        Reflections on the new Policy  ............................  1
        POLICY4 Reaction  ......................................... 11
        Reflections on POLICY4  ................................... 14
     2. LETTERS TO THE EDITOR  .................................... 29
        Message Encryption  ....................................... 29
     3. LATEST VERSIONS  .......................................... 30
        Latest Software Versions  ................................. 30
     4. NOTICES  .................................................. 31
        The Interrupt Stack  ...................................... 31
     FidoNews 6-17                Page 1                   24 Apr 1989


     =================================================================
                                 ARTICLES
     =================================================================

     Vince Perriello
     Fidonet 1:141/491


               Reflections on the new Draft Policy document


     I believe  that  the  new Policy document is a good document.  I
     also believe that  it  has  some  important flaws and omissions.
     Most  of  these are  in  the  area  of  unnecessarily  rigid  or
     arbitrary text.  I've covered the areas I feel need to be either
     further explained or corrected below.

     This document should be corrected before  the ratification vote.
     But I feel that both the corrections  and  the  vote should take
     place as soon as possible.  The author(s) of Policy4 have done a
     good  job  addressing  problems  that have cropped up since  the
     prior  version  and  we  need  to have it in force  as  soon  as
     possible.


     [Beginning of quoted passages]

     > The  official  language  of FidoNet is English.  All documents
     > must exist  in  English.   Translation into other languages is
     > encouraged.

     I thought this somewhat  jingoistic until someone pointed out to
     me  that this had first  appeared  in  a  submission  from  Henk
     Wevers.  Maybe I have gotten too sensitive to the North American
     bias issue.  If Henk thought this  necessary,  then I'll go with
     it.   But why was  it  considered  so  important  that  it  even
     preceded the definition of Fidonet?

     > FidoNet is an amateur electronic mail system.  As such, all of
     > its  participants and operators are unpaid  volunteers.   From
     > its   early beginning as a few friends swapping messages  back
     > and forth (1984), it now (1989) includes over 5,000 systems on
     > six continents.

     What a difference five years makes.  It's too bad we don't  have
     5,000 FRIENDS swapping messages back and forth <sigh>.

     > FidoNet is not a  common  carrier  or  a  value-added  service
     > network  and is a public  network  only  in  as  much  as  the
     > independent, constituent nodes may individually provide public
     > access to the network on their system.

     Good.  Though I would prefer that we  also  said  something here
     like  "individual  nodes  providing  commercial  services  using
     Fidonet as a transport mechanism are acting solely for their own
     purposes and not as a member or agent of Fidonet as a whole".
     FidoNews 6-17                Page 2                   24 Apr 1989


     > FidoNet is large enough that it would quickly  fall  apart  of
     > its own weight unless some sort of structure and  control were
     > imposed on it.  Multinet  operation  provides  the  structure.
     > Decentralized management  provides the control.

     Now HERE's an interesting  paragraph.  You mean that the IC, the
     Z1C and the Z1RC's are  planning on relaxing the iron fist?  The
     use of the word "decentralized" seems  to  imply  this.    Good.
     More power to them, er, to the Nodes and NC's I mean.

     > In supporting points, the bossnode  makes use of a private net
     > number  which  should  not  be  visible    outside    of   the
     > bossnode-point relationship except as the first entry  in  the
     > ^aPATH line.

     What's a  ^aPATH  line?    Is this Echomail?  Why are we talking
     about specific Echomail implementation issues in Policy?

     > Unfortunately, should the point call another  system  directly
     > (to do  a  file  request,  for  example),  the private network
     > number will appear  as  the  caller's  address.   In this way,
     > points  are   different  from    users,   since  they  operate
     > FidoNet-compatible   mailers which are capable  of  contacting
     > systems other than the bossnode.

     May I infer from this that if  a point makes a file request from
     a node other than its bossnode that it  is operating in a manner
     which is consistent with Policy?  This issue nearly  brought the
     BINKLEY echomail  conference  to its knees recently.  Some clear
     statement on the issue would be a welcome relief.

     > A zone is a  large  geographic area  containing  many regions,
     > covering one or more countries and/or continents.

     This language is probably too restrictive.  How about "which MAY
     cover one  or  more  ..."?  I trust you agree that, for example,
     the Soviet Union  or  (Mainland)  China  are so large they might
     require multiple zones?

     > FidoNews is  a  weekly newsletter distributed throughout the
     > network by the coordinator structure.

     I  don't    believe    that   the  distribution  is  limited  to
     coordinators.

     > It is an important medium by which FidoNet sysops  communicate
     > with  each  other.    FidoNews   provides  a sense of being  a
     > community  of people with  common   interests.    Accordingly,
     > sysops and users are encouraged  to   contribute  to FidoNews.

     (Newsletter Editor hat on) Thank you very much. (hat off)

     > Contributions are submitted to node 1/1;  a  file  describing
     > the format to be used is available on many systems.

     Why  not  say  it's available on 1/1?  And why  not  say  1:1/1?
     FidoNews 6-17                Page 3                   24 Apr 1989


     There ARE other Zones, you know.

     > Network  boundaries  are based on calling  areas as defined by
     > the local telephone company.

     Not totally.  Check out Net 132 in  Zone  1,  for  example.   It
     includes at least two states and area codes.

     > Even in the case  of areas where node density is so great that
     > more than one network is  needed  to  serve  one local calling
     > area, a  geographic  guideline is  used  to decide which nodes
     > belong  to   what  network.  Network membership  is  based  on
     > geographic or  other  purely technical rationale.   It  is not
     > based on personal or social factors.

     This makes a lot more sense than the preceding sentence.   Maybe
     the  former  should  be  scrapped  or  rewritten in favor of the
     latter?  Seems  like what we really have is geography rightfully
     taking precedence over local  phone  companies  (which come in a
     close second).

     > Zone Mail Hour (ZMH) is a defined time during which all nodes in
     > a  zone are required to be able to accept netmail.

     Might I suggest here you add a sentence?  Such as " A given node
     may use any method preferred  by  its operator to transfer mail,
     but  all nodes must be capable  of  falling  back  to  the  base
     Fidonet  protocol  as  defined  in  FTSC document  FTS-0001"?

     > The  nodelist  is a  file updated weekly  which  contains  the
     > addresses  of  all   recognized FidoNet nodes.  This  file  is
     > currently  made  available  by  the Zone Coordinator not later
     > than    Zone  Mail  Hour  each  Saturday,  and  is  available
     > electronically for download or file request at no charge.

     Does this mean that 1:1/0 now allows file requests for this file
     starting immediately after ZMH on Saturday?

     > To be  included  in  the  nodelist,  a  system  must  meet the
     > standards defined by this  document. No other requirements may
     > be imposed.

     All the more reason to take FTS-0001's name  in vain above.  Did
     you  really  mean to shut FTSC out here or  was  this  just  bad
     language?    If  it was bad language, we'd best fix  it.    Like
     "standards  defined in  this  document  or  technical  standards
     ratified  by  the  FTSC    and  accepted  by  the  International
     Coordinator" in place of "standards defined in this document"?

     > In certain cases, the Zone Coordinators work  as  a council to
     > provide   advice   to  the  International  Coordinator.

     When does the Council meet?

     > The Network  Coordinator  is  not required to provide a source
     > for echomail.
     FidoNews 6-17                Page 4                   24 Apr 1989


     No such statements were  made about the IC, ZC or RC.  Does this
     mean that they ARE so required?

     > (in discussion of Hubs)
     > ...  a network  coordinator  cannot delegate responsibility to
     > mediate disputes.

     Why not, as long as the  NC  will step in if the decision of the
     Hub is not acceptable to all parties?

     > The  system  operator  (sysop) formulates a policy for running
     > his board and dealing with users.

     You meant "his or her", right?  Also,  how  about  cases where a
     Fidonet node isn't a BBS? Or are we phasing those nodes out?

     > The sysop must mesh with the rest of the FidoNet  system if he
     > is to  send and  receive  mail, and  the local policy must  be
     > consistent with other levels of FidoNet.

     Here you meant to say "He or She", didn't  you?  I'll assume you
     mean the policy of the board when you say "local  policy"  here.
     So, let me see if this works.  If the International  Coordinator
     states that messages about "foo" are considered annoying, then I
     can't allow messages  about  "foo" on my system even if they are
     in local-only message bases?  Balderdash.  Rewrite this part.

     > The sysop is responsible for the actions of any user when they
     > affect the rest of FidoNet.  (If a user is annoying, the sysop
     > is annoying.)

     Does  this  mean that any user may get his sysop thrown  out  of
     Fidonet with one  well-placed  message?    Seems  like the sysop
     should be given an  opportunity  to  correct,  limit  access, or
     remove a user before a  determination  is made that the sysop is
     being annoying due to the actions of a user.

     > Any traffic entering FidoNet via a given node, if not from the
     > sysop,  is   considered  to  be  from  a  user,   and  is  the
     > responsibility of the sysop.    This  includes  messages  from
     > point systems.

     Seems fair, but please  see  the previous point.  By the way, is
     there  any reason why this  logic  can't  include  BIDIRECTIONAL
     gateways with so-called "Alternative Networks" which use Fidonet
     technology?

     > These  levels act to distribute the administration and control
     > of FidoNet  to the lowest possible level, while still allowing
     > for coordinated action over the entire mail system.

     Exactly what we should have in Zone 1.  Low-level ADMINISTRATION
     and high-level COORDINATION.

     > The sysop  of  an  individual  node  can  generally  do  as he
     > pleases, as long  as  he  observes  the  mail  events,  is not
     FidoNews 6-17                Page 5                   24 Apr 1989


     > excessively annoying to other  nodes  on FidoNet, and does not
     > promote  or   participate  in  the   distribution  of  pirated
     > copyrighted software or other illegal behavior via FidoNet.

     How  about if the sysop decides to do something completely legal
     but blatantly commercial, and advertises access  to Fidonet as a
     valuable part of the service he or  she  (I  try  to stay gender
     neutral  myself) has to offer?  Then for  some  reason  a  legal
     proceeding  is initiated due to some action this person  has  or
     has not taken.  Are we protected?  Enquiring minds ...

     > In order to  understand the meaning of "excessively annoying",
     > it   is incumbent upon  all  sysops  to  occasionally  re-read
     > FidoNet policy.  New sysops  must  familiarize themselves with
     > policy before requesting a node number.

     Too bad we can't have some kind  of  exam  too, like they do for
     drivers'  licenses.    But just having this here  is  something.
     Please  don't  forget to make sure that NC's are  familiar  with
     this section and take some steps to determine that the  operator
     of  a new node has in fact read POLICY (though I  have  no  idea
     what those steps would be)

     > A  Sysop is responsible for all traffic entering  FidoNet  via
     > his   system.  This includes (but is not limited  to)  traffic
     > entered by his users, points, and any other networks for which
     > he  might   act  as  a  gateway.  If a sysop allows  "outside"
     > messages  to    enter   FidoNet  via  his  system,  he  has  a
     > responsibility to ensure  his  system is clearly identified by
     > FidoNet node number as  the  point  of origin of that message,
     > and a  responsibility to act  as  a  gateway  in  the  reverse
     > direction.   Should  such  traffic result  in  a violation  of
     > Policy, the sysop must rectify the situation.

     How come a Sysop can fix problems  with  gateways and points but
     is considered annoying if she has an annoying user?

     > FidoNet is an amateur system.  Our technology is such that the
     > privacy of messages  cannot be  guaranteed.  Any sysop has the
     > right to review traffic flowing through his system,  if for no
     > other reason than to ensure that the system is  not being used
     > for  illegal purposes.  Encryption obviously makes this review
     > impossible.  Therefore,  encrypted  and/or  commercial traffic
     > that is routed without the express permission of all the links
     > in the delivery system constitutes annoying behavior.

     I'm not saying that  something  doesn't  need  to  be said about
     routed encrypted messages.  But I have a problem with this black
     and white stuff.  No room  for  interpretation.  No room for any
     kind of mitigating circumstances, such as pilot error.    We may
     be judged by future generations on the quality of our mercy.

     > 2.1.6  Private Netmail

     This entire section makes a lot of sense.   Of  course  it reads
     more  like  something  out of a "guide to novice sysops"  rather
     FidoNews 6-17                Page 6                   24 Apr 1989


     than  a Fidonet Policy and Procedures document.  But I agree  it
     needs to be stated somewhere. Good show.

     > If a  sysop does  not forward a message when he had previously
     > agreed to perform  such  routing, the message must be returned
     > to the sysop of the node at  which  it entered FidoNet with an
     > explanation of why it was not forwarded.

     OK.  How about messages which are sent to a given node in error?
     Is the receiving node obligated to either forward or bounce?  It
     appears that there's nothing to cover this here.

     > Zone  Mail  Hour is the  heart of FidoNet,  as  this  is  when
     > network  mail  is  passed  between systems.  Any system  which
     > wishes to be a part of FidoNet must be able  to  receive  mail
     > from any node in the nodelist during this time.

     Sure wish you'd mention FTS-0001 somewhere.

     > Echomail  should  not  be transferred  during  ZMH.

     That's  a little stiff.  I don't see any problem with ultra  low
     volume Echomail.   Can  we  fix  the language to make individual
     interpretations possible for individual cases?

     > User (BBS) access to  a  system  is prohibited during ZMH.

     Yeah!

     > A system which is a  member  of a  local  network  may also be
     > required to observe additional mail events,  as defined by the
     > Network Coordinator.  Access restrictions during local network
     > periods are left to the discretion of the Network Coordinator.

     Why  not  let  the  NC judge whether  such  things  as  Echomail
     transfer constitute annoying behavior as well?  You  can  see  a
     problem better when you're in the same town with the guy than if
     you're a couple of states removed.  Though the exceptions should
     be few and far between.

     > The rare exception to ZMH compliance is Private Nodes. Persons
     > requesting  private  nodes  should  be supported as points  if
     > possible.  A private listing is justified when the system must
     > interface with many others, such as an  echomail  distributor.
     > In these cases,  the exact  manner and timing of mail delivery
     > is arranged between the  private node and other systems.  Such
     > an agreement between a private system and a hub is not binding
     > on any replacement for that hub. A private node must be a part
     > of a network (they cannot be  independents  in  the  region.)

     That all sounds good.  I can  think  of  other  applications  of
     Private nodes, but your example is adequate.

     > Private nodes are encouraged to honor ZMH.

     I'm not quite sure why.  As I  see  it,  the  main  purpose of a
     FidoNews 6-17                Page 7                   24 Apr 1989


     private  node  is  to  have  a  Fidonet mailbox with  restricted
     access.  Since other systems will be able to contact the private
     node  directly  only  by  prior arrangement, what's the point of
     having the private node honor ZMH?

     > 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.

     Hmmm.  Would I be presumptuous to call this the Lee Kemp Clause?
     You know, there are reasons other than what you envisioned.  How
     about this:   a  system  is  excommunicated  because  he doesn't
     observe ZMH.  So  he  decides to become a point off your system.
     Does that mean you're history in Fidonet?

     > Once you have located the network or region in your area, send
     > a message containing a request for a node  number to node zero
     > of   that  network  or region.  The request must  be  sent  by
     > netmail, use address -1/-1, and include the following:
     >
     >       1) Your name.
     >       2) The name of your system.
     >       3) The city and state where your system is located.
     >       4) The phone number to be used when calling your system.
     >       5) Your hours of operation, netmail and BBS.
     >       6) The maximum baud rate you can support.

     So far, so  good.    Though I don't understand the insistence on
     using -1/-1 for an address.  I'm aware of an old default address
     in Fido of -1/-1 and  of  an undocumented feature in one or more
     current  network  mailers.    But I'm  also  told  that  several
     nets already have a preferred address  other  than  -1/-1  which
     they use for the purpose of new node applications.

     > You must indicate that you have read, and agree to  abide  by,
     > this document  and  all  the  current and future  policies  of
     > FidoNet.

     Yeah, right.  Give me a break.   Who on earth is crazy enough to
     agree  to  abide  by some future nonexistent document?   Contact
     your legal eagle and see if she thinks that any  such  agreement
     is worth the oxide it's written on.

     > Using a node number other than  -1/-1  can  cause problems for
     > the  coordinator   involved.    Simply  assigning  yourself  a
     > net/node number can be annoying, and can be  grounds to reject
     > your request.

     See comment above regarding -1/-1.

     > Never put an answering machine or similar device on your phone
     > line while you  are down.  If you do, calling systems will get
     > the machine repeatedly, racking up large phone bills, which is
     > very annoying.
     FidoNews 6-17                Page 8                   24 Apr 1989


     Why is it you use the magic phrase "annoying behavior" elsewhere
     in cases where there are definite grey  areas,  and don't use it
     HERE?  A system that answers with a  machine  should  be  marked
     DOWN!   PERIOD!  Make some effort to reach  its  owner,  if  you
     can't then JUST MARK THAT SYSTEM DOWN!

     > 3.1  Make Available Nodelists, Difference Files, and FidoNews
     >
     > Any  Coordinator  is  responsible  for  obtaining  and  making
     > available, on a weekly  basis,  nodelist  difference files and
     > FidoNews.

     Well, which is it?  In the heading, nodelists are mentioned;  in
     the accompanying text, they are not.

     > In addition, a coordinator is  required to  forward  any local
     > policies he receives to  the  level  above, and to review such
     > policies.   Although not required,  common  courtesy  dictates
     > that when formulating a local policy, the participation of the
     > level above should be solicited.

     This appears to be the only mention of  local policy.  Does this
     mean that as long as it's not inconsistent with  general policy,
     that any local policy at all can be defined?   With  no  consent
     needed from the coordinators above?

     > In addition, a new  coordinator  has  the right to  review any
     > decision made by his predecessors  for compliance with Policy,
     > and  take  whatever  actions may be necessary to  rectify  any
     > situations not in compliance.

     Does this include excommunication for cause (or  refusal  to  do
     so)? If so, we need some kind of statute of limitations.

     >(From responsibilities of a Network Coordinator)
     > It is also recommended, though not required, that  you  call a
     > board which is applying for a node  number before assigning it
     > a node number.

     As a USER?  Why?  If there are acceptability issues, they should
     be documented here.  If not, then what purpose would be served?

     > You should  use network  mail to inform a new node of his node
     > number,  as  this  helps to  insure  that  he  is  capable  of
     > receiving network mail.

     That's the ticket.   So  why  does  an  NC need to call a system
     before granting a node number?

     > You should to implement name changes ...
                  ^^
     Did this word just creep in?

     > Policy, FidoNews, and the nodelist  are the glue that holds us
     > together.  Without them, we would cease to be a community, and
     > become just another random collection of bulletin boards.
     FidoNews 6-17                Page 9                   24 Apr 1989


     So why doesn't a host need to have a full nodelist available any
     more? Where does somebody get one if they need it?

     > A Zone Coordinator  is charged with the task of  ensuring  the
     > smooth operation of his Zone.  He does this by supervising the
     > Regional Coordinators.

     I  hate  that  word  "supervise".    What  place  does the  term
     "supervision"  have  in  an  "amateur"  network?  By the way, it
     doesn't seem  to  me  that  "coordinate" and "supervise" are the
     same thing.   So  where  can  I find the description of the Zone
     Supervisor?

     >(from the section relating to Policy votes)
     > Network  coordinators  are expected  to assess the opinions of
     > the members of their network, and to vote accordingly.

     And what if they don't?

     > If a number of alternatives are to be considered, they must be
     > presented as whole documents, from which one is chosen.

     What if more than one of them receives the requisite votes?

     > A Policy amendment is considered in  force  if,  at the end of
     > the balloting period, it has received a  majority of the votes
     > cast,  and has received a majority of the  network-coordinator
     > votes  cast,  and  has  received  a  majority of the regional-
     > coordinator votes cast.

     Let me get this straight.  If 100% of the NC's vote  in favor of
     something  but  only  49% of the RC's do, then it fails?  That's
     democracy for ya.  Can we at  least  make  it  a majority of one
     plus a plurality of the other?

     > In the case of multiple policy changes which are considered on
     > the same ballot,  a version must  receive more than 50% of the
     > votes cast to be  considered  ratified.  "Abstain" is a  valid
     > vote in this case,  effectively  being a vote for not changing
     > the current policy as it simply increases the number of  votes
     > required to ratify the proposed change.

     This  makes  me even more certain  that  majority  of  one  plus
     plurality of the other makes sense.   I  don't believe in sleazy
     voting tactics like this.

     >(From Statute of Limitations clause)
     > A complaint  may not be filed more than 60 days after the date
     > of discovery of  the  source  of  the  infraction,  either  by
     > admission or technical evidence.   Complaints may not be filed
     > more than 120 days after  the  incident  unless  they  involve
     > explicitly illegal behavior.

     That's fine.  Now let's say that  the Coordinator finds in favor
     of the person accused.  Then the Coordinator leaves office.  Can
     the  new  coordinator  reinitiate the proceedings, regardless of
     FidoNews 6-17                Page 10                  24 Apr 1989


     the amount of time which has passed?  Based on the earlier stuff
     I pointed out, I would say that  the  answer is YES.  That needs
     to be addressed.

     [End of quoted passages]

     Those are the  specific  areas  in  which  I saw problems in the
     document.  By and  large, it's a good one, as I said above.  I'd
     like to see most of  the  changes  proposed  above  in the final
     version,  though.   Particularly the areas concerning FTSC.    I
     trust  that  the  areas  where annoying behavior is defined  are
     meant  primarily to establish criteria for filing complaints and
     not to  lock  a  given  Coordinator into a set course of action.
     The reason I  highlighted  those  areas was to make certain that
     this was indeed the case.

     I look forward to seeing language corrections and clarifications
     added to the document, and to seeing it accepted by the *C's.  I
     can't encourage you enough to read this document yourself and to
     discuss it with your fellow Sysops and with your  respective Net
     or  Regional  Coordinator.   YOU are Fidonet.  It's YOUR Policy.
     Help make it the best Policy possible.

     -----------------------------------------------------------------
     FidoNews 6-17                Page 11                  24 Apr 1989


     Randall Greylock
     Fidonet 1:321/202

     Disclaimers

     I was involved in the process

     First off, I'm biased.  Much of the work on this Policy 4 was
     done while I was an RC, and I had some influence on the form of
     the document.

     However, I do not pretend to speak for the coordinator
     structure.

     I also have to apologize to the coordinators, for in making my
     comments to them when initially requested, I skimmed one big
     section (Policy ratification), and missed what I feel is one of
     the biggest flaws in the document.


     I've seen Vince's Article

     I've also seen a draft of Vince's article.  For the most part, I
     agree with his comments, although in some cases, what seemed
     obvious to me was not obvious to others.  (This is basically the
     same problem as exists in P3.)

     Oh, and I'm writing in extreme haste.  It's 22:45 right now, I
     have to have this sucker in by 23:00.  It hasn't been spell
     checked, grammar checked, or seriously logic checked.  Sorry.


     Original Design Goals

     Minimal Changes from P3

     One of the major goals of P4 (during my tenure, at least) was a
     minimal set of changes from P3.  The more changes there are, the
     more argument there will be.

     My feeling is this goal has largely been met.


     Clear Path to P(N+1)

     Another primary goal was the definition of how we get from P(n)
     to P(n+1).  While this goal has been met, I share the
     reservations Vince has on this section of the document.

     All in all, though, I can live with it.


     Casting In Policy The Learning From Precedent

     Finally, much of what was not so much to change Policy, but to
     refine it - taking things decided by dispute and putting them
     FidoNews 6-17                Page 12                  24 Apr 1989


     into clear Policy language.  Much of the new text is not new
     policy, but the application of Policy.


     Problems - Perceived and Otherwise

     Dual Majorities

     The democratic procedures have changed greatly since last I saw
     P4.  At that time, the concept of two kinds of majorities was in
     place in order to balance geography against population.  In order
     for Policy to be put in place, it had to be ratified by a
     majority of those voting, and a majority of the Zones.  The
     intention (which may or may not have been well served) was to
     ensure that a broad geographic consensus be reached for Policy
     changes.

     The concept of dual majorities applied to the levels of FidoNet
     does not seem to provide any protection against anything.  It
     leaves the system such that a very small number of sysops can
     dictate network philosophy - i.e., the RC's essentially have veto
     power over any Policy initiative.

     I do not necessarily believe democratic procedures are the best
     way to run a network.  But I do believe the majority of the
     network feels otherwise.  The language as it stands is an affront
     to that viewpoint.  An argument can (and will) be made that the
     RC's are in the best position to formulate and evaluate Policy.
     Further argument can and will be made that most people don't
     participate anyway.  While there is merit to both of these
     arguments, this is not a good reason to institionalize a caste
     system in the decision making process.


     Usage of the Word Annoying

     During my involvement in the P4 formulation, the word annoying
     and the phrase excessively annoying were used rather precisely.
     Annoying behaviour is not, in and of itself, excommunicatable.
     Excessively annoying behaviour is.  Annoying behaviour can
     CUMULATIVELY become excessively annoying if steps are not taken
     to rectify it.

     Unfortunately, given the lack of precision in the usage of other
     terms and phrases in the document, this distinction may have
     been lost.  Somewhere along the line, it would be nice to have
     some word other than annoying to describe the "lesser" mode of
     the term.


     References to Technical Standards Documents

     The biggest problem with Policy in all its incarnations is that
     what seemed obvious to the authors is not nearly so obvious to
     the readers.  This is particularly true in the case of technical
     standards and their relationship to this document.
     FidoNews 6-17                Page 13                  24 Apr 1989


     It seemed obvious that saying "One must be capable of receiving
     netmail during ZMH" implied FTS-0001 compliance.  There is a
     flip side of this problem Vince fails to mention, however - to
     the best of my knowledge, there is no official list of compliant
     software.  Further, there is a serious problem of existence.
     Does FidoNet exist?  Does a relationship between FidoNet and
     IFNA exist?  Does a relationship between IFNA and FTSC exist?
     Does a relationship between FidoNet and FTSC exist?  The answers
     to these questions are not clear to me, and I'm not sure
     hardening such relationships is the best way to clarify them.
     There was, during my involvement, a feeling on the part of many
     that we could not solve all the problems of the world, and we'd
     be better off clearly saying how we should go about addressing
     them than doing a bad job of addressing them in an environment
     where the right to do so was unclear.

     Also, there are some issues that are political as well as
     technical.  One of them is the appearance of "non-FidoNet"
     address information in traffic flowing through FidoNet's routing
     systems.  Is it fair to impose the burden of another network's
     routing information on nodes operating in an official FidoNet
     capacity?  Personally, I think not.  No matter what, I do not
     think this is a purely technical decision.

     Similar arguments can be made about the -1/-1 new node number
     request.  The goal was to make it possible for hosts to be able
     to honor requests for node numbers, while still being able to
     maintain control of their systems.  It is possible with many
     mailers to close out unidentified systems, and regulate the
     access of known ones.  The goal was to provide a known number
     for the request of a new node number to simplify the lives of
     those hosts that wish to otherwise exclude unknown systems.
     -1/-1 was chosen because of historical precedent.  I suggest
     that a single number like 1/32000 be used in its stead.  (We
     don't need yet another administrative entry in each net.)


     Overall Reaction

     Overall, I still urge any and all coordinators to ratify this
     document.  Even with the flaws, the existance of a clear
     ratification process provides a mechanism for other issues to be
     addressed in the future.  The process has taken much too long as
     it is, and has caused too much turmoil.  Let's get the sucker
     out the door, then take six months or a year to carefully
     address many of the perceived problems of the net.
     Specifically, I would leave aside the issue of commercialism
     that seems to be sweeping the net lately - the current Policy
     seems to have mostly worked, and rules should not be made in
     haste.  Many, many dates have been set and past for the
     implementation of this document; I believe that the credibility
     of the *C structure simply cannot take too many more election
     dates set, missed, voted on, then overturned, all of which is
     done with little public notice.

     -----------------------------------------------------------------
     FidoNews 6-17                Page 14                  24 Apr 1989


     Jack Decker
     Fidonet 1:154/8  LCRnet 77:1011/8  NetWork 8:70/8

     REFLECTIONS ON POLICY4

     After reading POLICY4, I have a few comments I'd like to share
     with you.  I haven't had access to the SYSOP or IFNA echoes for
     close to four months now (another result of ECHOPOL), so these
     thoughts are not repetitions of anything I've heard there
     recently.  First, I'll take some of the parts of POLICY4 and
     comment on them individually, then I'll close with some general
     comments.

     Starting near the beginning (a very good place to start!), we
     find this small but significant (and somewhat confusing)
     paragraph:

          FidoNet is large enough that it would quickly fall
          apart of its own weight unless some sort of structure
          and control were imposed on it.  Multinet operation
          provides the structure. Decentralized management
          provides the control.  This document describes the
          procedures which have been developed to manage the
          network.

     Highlight the words "unless some sort of structure and control
     were imposed on it."  The problem here is that most Fidonet
     sysops that I've spoken to don't want structure and control
     IMPOSED ON THEM from on high.  It's strange that in America,
     the land of democracy, the people in Fidonet would be forced to
     live under a document that sounds like something that the
     Russian government would issue (in pre-glastnost days, no
     less).

          1.2.3  Networks

          A network is a collection of nodes in a local
          geographic area.  Networks coordinate their mail
          activity to decrease cost.

     This is mention #1 of geography.  I'll get back to this later.

          1.2.3  Regions

          A region is a well-defined geographic area containing
          nodes which may or may not be combined into networks.
          A typical region will contain many nodes in networks,
          and a few independent nodes which are not a part of
          any network.

     Mention #2 of geography.  More later.

          1.2.5  Zones

          A zone is a large geographic area containing many
          regions, covering one or more countries and/or
     FidoNews 6-17                Page 15                  24 Apr 1989


          continents.

     Mention #3 of geography.  For those in other (non-Fidonet)
     networks it also ignores current usage of zones, but then I
     hear they're trying to come up with some spiffy new "Domain"
     proposal that will once again break all existing software, so
     the other nets won't have to (be allowed to?) use zones for
     this purpose.

          1.3.2  Geography

          Each level of FidoNet is geographically contained by
          the level immediately above it.  A given geographic
          location is covered by one zone and one region within
          that zone, and is either in one network or not in a
          network.  There are never two zones, two regions, or
          two networks which cover the same geographic area.

     Why?  Would the world come to an end if there were two nets in
     the same geographic area?  Maybe we ought to give AT&T the
     northern U.S., Sprint the Eastern seaboard, MCI the West and
     Southwest, and divide the rest of the U.S.  among the other
     long distance carriers.  What's that got to do with anything?
     Well, recent history should tell us that when you can only
     obtain a service from one provider, they can charge whatever
     they want, and often treat those they serve in any way they
     like.  When there is competition, or the ability to go to more
     than one source for a service, the providers of that service
     seem to be just a little nicer and more considerate.

     Even where real competition doesn't exist, the fact that
     competition is possible can make a big difference.  If I had
     the only gas station in a town and decided to charge $5 a
     gallon for gas, you can bet that somebody would soon get the
     idea that they would be a local hero if they opened a station
     and charged only $1.50 a gallon.  That thought would probably
     keep me from charging totally ridiculous prices for my gas.

     I know some are saying "That's fine for business, but what has
     it to do with Fidonet?" Simple, human nature being what it is,
     the same principles apply.  If you have a net coordinator or a
     regional coordinator who can tell people to do things his way
     or get out of the net, or to accept the few services he chooses
     to provide even though someone else might be willing to offer
     more services, that gives the *C structure the ability to "play
     dictator" to those under them.  Of course, MOST *C's wouldn't
     do that, but life can be no fun at all if YOU happen to be
     under a heavy-handed *C.

          If a node is in the area of a network, it should be
          listed in that network, not as an independent in the
          region.  (The primary exception to this is a node
          receiving inordinate amounts of host-routed mail; see
          section 4.2).  Network boundaries are based on calling
          areas as defined by the local telephone company.  Even
          in the case of areas where node density is so great
     FidoNews 6-17                Page 16                  24 Apr 1989


          that more than one network is needed to serve one
          local calling area, a geographic guideline is used to
          decide which nodes belong to what network.  Network
          membership is based on geographic or other purely
          technical rationale.  It is not based on personal or
          social factors.

     More geography.  Also, who determines "calling areas as defined
     by the local telephone company?"  Some cities have a metro area
     (where it's a free call to anywhere in that area from anywhere
     in that area), but in other places calling areas overlap (for
     example, everyone gets their home exchange plus all surrounding
     exchanges as part of their local calling area).  Some folks may
     live just outside a local calling area for a net, but may wish
     to participate in that net anyway, while others in the same
     situation may prefer to remain independent.

          There are cases in which the local calling areas lead
          to situations where logic dictates that a node
          physically in one FidoNet Region should be assigned to
          another.  In those cases, with the agreement of the
          Regional Coordinators and Zone Coordinator involved,
          exemptions may be granted.  Such exemptions are
          described in section 5.6.

     An admission that basing everything on geography is going to
     cause problems.  But wait 'til you see section 5.6!

          1.4.9  Summary

          These levels act to distribute the administration and
          control of FidoNet to the lowest possible level, while
          still allowing for coordinated action over the entire
          mail system.  Administration is made possible by
          operating in a top-down manner.  That is, a person at
          any given level is responsible to the level above, and
          responsible for the level below.

     This strikes me as being backward.  A coordinator SHOULD be
     responsible to those he governs.  "Government by the consent of
     the governed", it's called.  Seems I recall that the United
     States fought some wars to win this right a couple of hundred
     years ago.

          For example, a Regional Coordinator is responsible to
          the Zone Coordinator for anything that happens in the
          region.  From the point of view of the Zone
          Coordinator, the Regional Coordinator is completely
          responsible for the smooth operation of the region.
          Likewise, from the point of view of the Regional
          Coordinator, the Network Coordinator is completely
          responsible for the smooth operation of the network.

          If a person at any level above sysop is unable to
          properly perform their duties, the person at the next
          level may replace them.  For example, if a Regional
     FidoNews 6-17                Page 17                  24 Apr 1989


          Coordinator fails to perform, the Zone Coordinator can
          replace him.

     What this means, folks, is that if your NC decides to back you
     in a dispute against the Fidonet hierarchy, they can order him
     replaced.  You have no say as to who you want for your NC.
     Does any of this remind you of the government structure used in
     certain countries that don't have many Fidonet nodes?

          2.1.6.1  No Disclosure of in-transit mail

          Disclosing or in any way using information contained
          in private netmail traffic not addressed to you or
          written by you is considered annoying behavior,
          regardless of how you come upon that traffic.  This
          does not apply to echomail which is by definition a
          broadcast medium, and where private mail is often used
          to keep a sysop-only area restricted.

     There are several clauses in the proposed policy dealing with
     private mail.  My feeling is that this is an amateur network,
     and therefore we shouldn't handle mail for which any level of
     "security" is expected.  There are private commercial services
     intended for that purpose (e.g. MCI Mail, Compuserve, GEnie,
     etc.).  Given that, I would prefer not to see clauses like the
     one above, which could (under the right circumstances) subject
     a Fidonet sysop to litigation.

          2.1.9  Private Nodes

          The rare exception to ZMH compliance is Private Nodes.
          Persons requesting private nodes should be supported
          as points if possible.  A private listing is justified
          when the system must interface with many others, such
          as an echomail distributor.  In these cases, the exact
          manner and timing of mail delivery is arranged between
          the private node and other systems.  Such an agreement
          between a private system and a hub is not binding on
          any replacement for that hub.  A private node must be
          a part of a network (they cannot be independents in
          the region.)  Private nodes are encouraged to honor
          ZMH.

     What happens if a person needs to operate a private node (for
     whatever reason) but is not part of the geographical coverage
     area of any network?  The point may be a bit moot, because
     since a private node is by definition unlisted, it could be
     part of any net and nobody would be the wiser (so long as the
     real geographic location of the node was not given in the
     nodelist, and folks were careful not to reveal the real
     location).  But why force folks to go through that type of
     sham?

          2.2  How to obtain a node number

          [Regarding application for a new Fidonet node] .....
     FidoNews 6-17                Page 18                  24 Apr 1989


          You must indicate that you have read, and agree to
          abide by, this document and all the current and future
          policies of FidoNet.

     How can one "read and agree to abide by" all FUTURE policies of
     Fidonet?  Especially when they often seem to be imposed "at
     will" by power-hungry coordinators?

          2.4  How to Form a Network

          If there are several nodes in your area, but no
          network, a new network can be formed.  This has
          advantages to both you and to the rest of FidoNet.
          You receive better availability of nodelist difference
          files and FidoNews, and everyone else can take
          advantage of host-routing netmail to the new network.

          ....

          Granting a network number is not automatic.  Even if
          the request is granted, the network might not be
          structured exactly as you request.  Your Regional
          Coordinator will review your application and inform
          you of the decision.

     Does this now give the RC veto power over which nodes can and
     cannot be in a local network?  Again, it seems the power is
     flowing from the wrong direction here...

          3.5  Be a Member of the Area Administered

          A coordinator must be a member of the area
          administered. That is, a Network Coordinator must be a
          member of that network by virtue of geography.  A
          Regional Coordinator must be either a member of a
          network in his region, or an independent of the
          region.

     More geography (I've lost count by now...).

          4.3  Assigning Node Numbers

          ...

          You may not assign a node number to a node in an area
          covered by an existing network.  Further, if you have
          nodes in an area covered by a network in formation,
          those nodes must be transferred to the new network.

     Though perhaps not readily apparent, this is still more
     geography!

          5.1  Responsibilities

          A Regional Coordinator has the following
          responsibilities:
     FidoNews 6-17                Page 19                  24 Apr 1989


          ...

             3) To assign network numbers to networks in the
             region and define their boundaries."

     "...and define their boundaries???"  So the RC can come in and
     in one fell swoop, cut a bunch of nodes out of your net by
     changing the boundaries!  More geography!  More power flowing
     in the wrong direction!

          5.2  Assigning Node Numbers

          ...

          If a network forms in an area for which you have
          independent nodes, those nodes will be transferred to
          the local network as soon as is practical.

     Normally this would be desirable, but in certain cases it may
     not be.  Why not give the independent nodes the option of
     joining or not joining the new network?

     Let me give you one example of a potential problem.  There are,
     we'll say, ten independent nodes in a given area.  One of the
     local sysops reads Policy one day and decides to apply to form
     a net, listing all ten of the independent nodes in his area as
     part of the new net.  Unfortunately, this guy is well known to
     the local Sysop community (but NOT to the RC) as a real twit,
     someone that can't get along with anybody.  The RC approves the
     request, and these other nine sysops suddenly find themselves
     under the thumb of Mr. Twit.

          5.3  Encouraging the Formation and Growth of Networks

          One of your main duties as a Regional Coordinator is
          to promote the growth of networks in your region.

          You should avoid having independent nodes in your
          region which are within the coverage area of a
          network.  There are, however, certain cases where a
          node should not be a member of a network, such as a
          system with a large amount of inbound netmail; see
          section 4.2.

          If several independent nodes in your region are in a
          local area you should encourage them to form a
          network, and if necessary you may require them to form
          a network.  Refer to section 2.4.  Note that this is
          not intended to encourage the formation of trivial
          networks.  Obviously, one node does not make a
          network.  The exact number of nodes required for an
          effective network must be judged according to the
          circumstances of the situation, and is left to your
          discretion.

     This puts a lot of power... much TOO MUCH power in my
     FidoNews 6-17                Page 20                  24 Apr 1989


     opinion... into the hands of the RC.  Of course it goes without
     saying that we're still talking geography here.

          5.4  Assigning Network Numbers

          It is your responsibility to assign network numbers to
          new networks forming within your region.  You are
          assigned a pool of network numbers to use for this
          purpose by your Zone Coordinator.  As a part of this
          function, it is the responsibility of the Regional
          Coordinator to define the boundaries of the networks
          in the region.

     "define the boundaries of the networks???"  Here we go again
     (sorry if it's getting monotonous, I was getting pretty tired
     of it by the time I waded through the whole document!  I didn't
     agree with it the first time, and the endless repetition sure
     didn't win me over!).

          5.6  Geographic Exemptions

          There are cases where local calling geography does not
          follow FidoNet regions.  In exceptional cases,
          exemptions to normal geographic guidelines are agreed
          upon by the Regional Coordinators and Zone Coordinator
          involved.  Such an exemption is not a right, and is
          not permanent.  When a network is formed in the proper
          region that would provide local calling access to the
          exempted node, it is no longer exempt.  An exemption
          may be reviewed and revoked at any time by any of the
          coordinators involved.

     Finally we arrive at section 5.6.  Don't you love this?  They
     admit that in some cases there may be good reasons to bend the
     rules on the geography, but then they allow any of who knows
     how many coordinators to kill the arrangement on a whim (thus
     forcing some nodes to go long distance for services they should
     be able to get for free).  The way this clause is worded sucks
     eggs, in my opinion.  It allows the RC's to get much too
     involved in what should be a matter of concern only to a local
     net.

          5.7  Overseeing Network Operations

          ...

          If a network grows so large that it cannot reasonably
          accommodate traffic flow during the Zone Mail Hour,
          the Regional Coordinator can direct the creation of
          one or more new networks from that network.  These new
          networks, although they may be within a single
          local-calling area, must still conform to a
          geographical basis for determining membership.

     Not only is this getting confusing, it's getting ridiculous!
     Does this mean that in some cases a sysop may have to join a
     FidoNews 6-17                Page 21                  24 Apr 1989


     new net if he moves across town?  Would it be so awful terrible
     to give sysops a choice of which net they prefer to belong to?
     Oh, yeah, you did notice they mentioned geography again, didn't
     you?

          9.1  General

          The FidoNet judicial philosophy can be summed up in
          two rules:

               1) Thou shalt not excessively annoy others.

               2) Thou shalt not be too easily annoyed.

          In other words, there are no hard and fast rules of
          conduct, but reasonably polite behavior is expected.
          Also, in any dispute both sides are examined, and
          action could be taken against either or both parties.
          ("Judge not, lest ye be judged!")

          The coordinator structure has the responsibility for
          defining "excessively annoying".  Like a common
          definition of pornography ("I can't define it, but I
          know it when I see it."), a hard and fast definition
          of acceptable FidoNet behavior is not possible.  The
          guidelines in this policy are deliberately vague to
          provide the freedom that the coordinator structure
          requires to respond to the needs of a growing and
          changing community.

     I'm glad they used that example.  It makes the difference
     between the proposed policy and a democratic governing system
     fairly obvious.

     Pornography is supposed to be judged according to "prevailing
     community standards." In other words, it is NOT supposed to be
     the opinion of the judges hearing the case.  Suppose the judge
     were a closet Ted Bundy, or a straight-laced Puritan?  No
     matter, it's not HIS opinion that's supposed to count, rather
     the offense is to be measured against community standards...
     that is, what would most of the PEOPLE in the community think
     about this?

     But in Fidonet, "Excessively Annoying Behaviour" is judged not
     against the views of the common sysops of Fidonet, but rather
     against the values and ideals of the *C structure, which are
     often diametrically opposed to the views of the common sysop.

     For example, common sysops might find it very annoying that a
     Regional Coordinator would try to step in and say which nodes
     could or could not be in their net!  MANY sysops have found it
     VERY annoying that certain coordinators with very big egos (or
     worse?) have tried to prohibit cross-regional echo feeds.

          9.8  Return to Original Network

     FidoNews 6-17                Page 22                  24 Apr 1989


          Once a policy dispute is resolved, any nodes
          reinstated on appeal are returned to the local network
          or region to which they geographically or technically
          belong.

     Just one more mention of geography... but the "or technically"
     is interesting.  I wish there were a lot more "or
     technically"'s in this document, it might put things in a much
     different light.

          9.9  Echomail

          Echomail is an important and powerful force in
          FidoNet.  For the purposes of Policy Disputes,
          echomail is simply a different flavor of netmail, and
          is therefore covered by Policy.  By its nature,
          echomail places unique technical and social demands on
          the net over and above those covered by this version
          of Policy.  In recognition of this, an echomail policy
          which extends (and does not contradict) general
          Policy, maintained by the Echomail Coordinators, and
          ratified by a process similar to that of this
          document, is recognized by the FidoNet Coordinators as
          a valid structure for dispute resolution on matters
          pertaining to echomail.  At some future date the
          echomail policy document may be merged with this one.

     Well, that's a whole discussion unto itself.  Suffice it to say
     that the current echomail policy was formed by a small group of
     people who seemed to have specific goals in mind (inhibiting
     communications within the network!) and who were not very
     tolerant of dissenting views.  For example, one of the primary
     people involved in echomail policy described those who didn't
     agree with geographic echomail restrictions as "fools".  Many
     people felt that there was a real attempt to "railroad" this
     policy into place.

     The big problem  with the Echo Policy is that it really
     represents the views of only a few in Fidonet, rather than the
     many.  The average sysop was given NO real say in the formation
     of Echopol.

     \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

     You may wonder why I am so hung up on geography?  Basically,
     because it gives those in control the ability to suppress
     dissent.  It's the old "divide and conquer" routine.  I've seen
     some real efforts to keep those who disagree with Fidonet
     policies from talking to each other, or to the other Sysops in
     Fidonet.

     Besides, it doesn't make sense technically, at least not in
     North America.  I would estimate that out of those sysops who
     make a large number of long distance calls in a month, a fairly
     good percentage are using some type of calling plan that is not
     distance sensitive, whether on a packet switching network (e.g.
     FidoNews 6-17                Page 23                  24 Apr 1989


     PC Pursuit, Starlink) or a long distance service (e.g. Reach
     Out America, or Telecom Canada's "Between Friends").  Still
     other sysops have access to company tie lines, Foreign Exchange
     lines, or WATS lines that can give them access to other areas
     of the country at little or no cost.

     Many sysops have lost echo feeds in recent months, because they
     (or their feeds) were formerly able to get feeds from PC
     Pursuitable points (or even nearby points outside their
     region), but were cut off from those feeds when regional
     restrictions on echomail traffic started to be imposed IN
     ANTICIPATION of an Echomail policy allowing these restrictions.
     You heard me right.  Many of the *C's were so into their power
     trip that they went ahead and began enforcing a policy that was
     still in the draft stage!

     Now it may make some sense to base some things on geography,
     but Fidonet regions make no sense at all (as a matter of fact,
     I heard they were based on NFL football regions, or some such
     thing.  No one's yet been able to explain to me what football
     has to do with computer networks).

     The major problem is that Fidonet regions divide up the country
     and inhibit folks from talking to each other, yet they are too
     large to be meaningful in terms of reducing costs.  For
     example, a person living near the border of a region might know
     that a feed for an echo he wants exists only thirty miles away,
     but across a regional boundary.  The next nearest feed (and the
     only "legal" feed for him) is several hundred miles away in his
     own region.

     Now phone rates are a funny thing... even if you're on a
     distance-sensitive long distance service (and keep in mind that
     many sysops are not), most of the increases in phone rates are
     within the first 125 miles from your location.  After that, the
     rates taper off, and the cost of a call remains pretty uniform
     across the country (there's only a two or three cents per
     minute difference between a call to a point 125 miles away, and
     a call a couple of thousand miles distant).  Also, in many
     places, calls within your own state cost significantly more
     than calls going a similar distance to an out-of-state point.
     So, setting strict geographical boundaries for echomail can
     often increase costs for sysops.

     At the net level, basing net boundaries on a geographical
     factor can have several undesirable results.  It may keep those
     who live near the net, or who have strong emotional ties with
     the net, from getting into that net.  But the biggest problem,
     I think, it that it sets up a situation where the NC has too
     much power.  He can service nodes on a "take it or leave it"
     basis.  Nothing wrong with that IF there are other sources.  We
     don't require Standard Oil to put a gas station in every city,
     because if they don't someone else probably will, and if that
     firm charges too much, a competitor will no doubt appear sooner
     or later.  But, we do require Bell Telephone to serve every
     customer in their service area, and not only that, we have an
     FidoNews 6-17                Page 24                  24 Apr 1989


     body of people independent of the phone company (the Public
     Utilities Commission) who can step in and intervene on behalf
     of customers who have been overcharged, or otherwise wrongly
     treated.

     The trouble is that in Fidonet, all the "oversight" comes from
     above... from the very people who appointed the coordinator to
     his position.  Nowhere are those who receive any services from
     these coordinators given any say in the process.  Given that, I
     believe that the least we can do is to allow sysops some amount
     of choice in which net they will join.  That way, if you manage
     to get a real dictator as an NC or RC, and the RC or ZC refuses
     to replace him (thereby admitting that they made a mistake in
     appointing the guy in the first place), sysops don't have to
     leave Fidonet entirely to get out from under the guy.

     Now I have one more thing to say about geography.  Some people
     have come up with the bright idea that if cross-regional
     echomail feeds are prohibited, it will somehow cause dupe
     messages to magically disappear.  What these folks fail to
     understand is the difference between geography and topology.
     You can have faulty topology no matter where the individual
     nodes are geographically located, or you can have a "clean"
     topology even if nodes are spread across the country.  The
     physical location of a node makes no difference at all.

     For example, suppose you have a node that has been
     participating in a local net and not causing dupes.  Let's
     further suppose he polls his net host nightly for mail and
     echoes.  Now, one night he quietly packs up in the middle of
     the night and moves across the country, and begins polling his
     net host via long distance.  Does his computer contain a sensor
     that says, "oops, I've changed times zones, so I have to
     generate duplicate messages?"  Not hardly!  As long as the node
     maintains the same topology within his original net (connecting
     to the same node for his feeds), he isn't going to screw up
     echomail.  What does this prove?  Simply that whether the
     network topology is good or bad has nothing to do with
     geography.  You could draw a network topology map without ever
     knowing or caring where the nodes are geographically located.

     So, I have two major reason for not liking all the fuss about
     geography (and we must admit they've gone out of their way to
     get it into this document!) One is that these restrictions COST
     PEOPLE MONEY.  They are particularly unfair to those who live
     near the border of a geographic area, since they are often
     forced to make long distance calls to more distant points than
     would be necessary without the restrictions.  They other is
     that they provide a perfect spawning ground for petty dictators
     (and Fidonet has seen far too many of THOSE types already!).

     THESE RULES ARE UNENFORCEABLE

     There is a saying that when lawmakers create unenforceable
     laws, they create disrespect for the law in general.  There are
     generally two reasons that laws can be considered
     FidoNews 6-17                Page 25                  24 Apr 1989


     unenforceable.  One is that you can never catch the someone in
     the act in order to find out that the rules are being broken.
     The other is that such a high percentage of people consider the
     law ridiculous and/or unenforceable, so they make no attempt to
     comply with it.  If everyone is breaking a certain law, it is
     de facto unenforceable, and eventually the law is usually
     change to reflect reality.

     Policy documents are the "laws" of Fidonet.  If certain
     provisions are unenforceable, it can't help but create a
     climate of disrespect for Policy in general.  I believe that
     parts of the proposed Fidonet policy are unenforceable for both
     of the above-mentioned reasons.  First, because Fidonet is
     really a hobbyist organization, few sysops read Policy more
     than once, and a lot of those who do read it ignore it anyway,
     especially the parts that don't seem to make much sense.  Since
     BBS's come and go, this problem will ever be with us.  But,
     more importantly, sysops often conspire to "bend" certain rules
     in such a way that the higher-ups will never find out about it
     unless some fluke occurs.  Some examples I've heard of
     (actually, none of these refer to a specific situation, but are
     composites of many tales I've heard):

     * A node lets callers on during ZMH, but few callers call at
     that time of morning anyway.  If the NC or RC calls to deliver
     mail and the line's not busy, the mail gets through and they
     are none the wiser.  If the line IS busy, they have no way of
     knowing that it's a BBS caller rather than another mail call in
     progress.

     * A sysop wants to feed echomail to a node in another region.
     Since he doesn't normally communicate with anyone else in the
     distant node's net, he just defines the distant net as a
     "pointnet" in his software, and uses some other software to
     strip or change PATH lines and other information on incoming
     messages from that node, so that the messages appear to have
     originated on his board.  Of course, should a dupe loop occur
     in this setup, there is no easy way for anyone to track it down
     because all records of the "wild feed" have been expunged from
     the messages.  Sure, it's an intentional violation of the
     rules, but he feels justified because after all, he never had
     any vote in the rules!

     * Another sysop has moved to a different region, but he wants
     to keep in touch with the folks in his old home town.  So, his
     old net/node number is still in the nodelist, and he polls his
     net host every night for mail.  Right now his node is listed as
     private/unlisted, so nobody can call him, but should the RC
     ever decide to try and remove all private nodes from the
     nodelist, he knows a nice "permanently busy" official phone
     company number that he can place in the nodelist.

     * Then there is the guy who always wanted to be an echo hub, so
     he set up his own point net.  Since points are considered BBS
     users, they can be located just about anywhere, and his point
     users are (mostly because he's in a PC Pursuitable city).
     FidoNews 6-17                Page 26                  24 Apr 1989


     Strangely enough, some of his points also happen to be BBS
     sysops (who, coincidentally, seem to be getting their echo
     feeds from unknown sources), but as far as he is concerned,
     they are just users of his BBS, and entitled to get echoes just
     like any of his other point users...

     One other point... many sysops have come to realize that the
     ONLY possible sanction in Fidonet is excommunication, and while
     many RC's would be more than happy to excommunicate all of the
     "troublemakers" from their regions, most NC's (who generally
     know the "offenders" personally) are not usually so inclined,
     especially in the case of a policy regulation that nobody asked
     for in the first place.  So, the only way that the RC can get a
     node excommunicated is to replace the NC of the net, but that
     isn't always so easy, either.  One RC tried that and discovered
     that over 90% of the nodes in his region were ready to pull out
     of Fidonet and start their own network (the RC resigned
     instead).  In another case, the RC wanted to replace an NC, but
     out of about twenty sysops, only one even thought about taking
     the job...  and was gently but firmly persuaded not to by the
     other sysops of that net.   The NC stayed put.

     The fact that excommunication is the only sanction gives sysops
     a lot more power than many of them realize.  Suppose the only
     possible penalty for a crime were death?  How would you ever
     enforce littering laws?  You wouldn't...  you'd concentrate on
     the really important crimes and forget the small stuff.  But
     those in the Fidonet power structure like to issue a lot of
     proclamations regarding minor things, totally forgetting that
     they have no way short of excommunication to enforce these
     dictums... and you can't excommunicate too many nodes, or folks
     begin to suspect that maybe there's something wrong here!

     WHY THE POWER GRAB?

     The thing I can't understand is why such a small number of
     people have subjected themselves to such a large number of
     flames to try and bring about something that at least 90% of
     the sysops are either actively opposed to, or just don't care
     about.  Why are they so doggedly determined to push policies
     that have caused some of the brightest software developers in
     Fidonet to consider leaving the net? (some have done more than
     just consider it!)  Why are they trying to promote policies
     that will restrict the free flow of information and
     communications?

     These are questions you should be asking yourself, if you are a
     Fidonet sysop.

     There are probably a lot of entities that don't care much for
     our amateur network, both in the commercial and governmental
     spheres.  Commercial interests would rather you use their
     services (and pay the associated per-minute charges).  The
     government is probably a bit unsettled by the fact that we're
     moving massive amounts of data around containing all sorts of
     information, pretty much at will.  I'm sure that some in
     FidoNews 6-17                Page 27                  24 Apr 1989


     government would really appreciate a move to funnel all
     echomail through eight or ten central collection points, which
     could be more easily monitored.

     Now, some have said that this kind of thinking is just plain
     silly, even if some of the principal players in the creation of
     Fidonet policy don't live all that far from our nation's
     capitol.   Well, if that be the case, I apologize.  Only thing
     is, for months now, I've been trying to figure out why these
     people would subject themselves to flames, harrassment, and the
     generally negative comments about their motives, character, and
     integrity that have come from the many sysops who simply don't
     want the vision of Fidonet that they're trying to sell.

     IF I COULD CHANGE FIDONET...

     If I could change Fidonet any way I wanted, I'd only make two
     changes.

     First, I'd get rid of all geographic restrictions.  In most
     cases they aren't needed.  In most cases, folks will join the
     net nearest them.  If they don't, there may just be a good
     reason why they don't.

     Second, I'd get rid of Regions.  They aren't needed.  In fact,
     they aren't even used for mail routing purposes.  They just set
     up artificial barriers to communications.  If the ZC needs
     folks under him to divide the workload, then let's have
     "Coordinators at large".  Each NC would be assigned to a
     Coordinator at Large, and would sent his nodelist updates to
     that person and receive his Fidonews and Netdiff feeds from
     that person.  In the event of a personality conflict, the ZC
     could allow the NC to go through a different Coordinator at
     Large (and if all the NC's requested a transfer away from a
     certain coordinator, wouldn't that be a pretty good indicator
     that the guy has no business being a Coordinator?).

     I know some folks will quickly add that *C's should be elected,
     not appointed.  I believe that, too, but don't think that would
     be quite so important if people were not forced to deal only
     with a single *C (at any level), based strictly on where they
     happen to be physically located.

     Now, I've been saying all this for quite some time, and a lot
     of other good, sincere sysops have been saying some of the same
     things.  But the idea of taking the Geography out of Fidonet
     seems to scare the <insert favorite expletive> out of some of
     the current crop of Fidonet *C's.  Why?  Is it because some
     don't want to lose their Fiefdoms?  Or is there some other
     reason they want to keep bottleneck control over Fidonet, and
     inhibit communication between different geographical areas?

     Those of you in alternate networks shouldn't feel so smug
     because you're not having these problems.  Think about it...
     where do your echoes come from?  In most cases, are they either
     received from or passed to Fidonet through a gate?  That
     FidoNews 6-17                Page 28                  24 Apr 1989


     gateway connection could be easily monitored or disrupted.  And
     right now, none of the alternate nets are all that large.  If
     one of THEM grows to 4,000 nodes, we may see some occurrences
     in those networks that are difficult to understand.

     It's time for all sysops to wake up and see how our freedom to
     communicate is being gradually eroded by the added layers of
     Policy proclamations being foisted upon us.  Tell your *C's
     that you do not support restrictions upon our freedom to
     communicate!  Let the voice of the average sysop be heard!  Ask
     yourself... are things really better now than they were before
     we had "Echomail Coordinators"?  Do you really feel that
     restrictions based on artificial geographic boundaries have any
     merit?  If not, write a message to your *C's today, and let
     your voice be heard!


     -----------------------------------------------------------------
     FidoNews 6-17                Page 29                  24 Apr 1989


     =================================================================
                           LETTERS TO THE EDITOR
     =================================================================

     Garth Kidd
     Fidonet 3:680/809

     There is  currently  a  large discussion (argument?) going on in
     some echo areas  as to the legality of encrypting messages.  The
     draft FidoNet policy in  FidoNews 6.14 stated that encryption of
     any form was considered "annoying behaviour".

     In echo areas, this is  entirely fair.  People pay large sums of
     money  to  transport echo areas around  the  place,  and  people
     should not use them as an alternative to NetMail.

     The ruling, however, has one worrying aspect:

     It effectively bans encryption of messages, whether by DES means
     or  simply  by  rotating the message 13 characters  through  the
     alphabet.  Unfortunately, it also  prevents  the  only  means of
     keeping our privacy.  It is  a  simple matter for sysops to read
     "private" messages (most don't:  some might),  and  thus  people
     will want to encrypt.  Unfortunately, this makes  it  harder  to
     tell if people are using the Net for illegal  purposes (transfer
     of classified documents, etc).

     Discounting  the last point, it seems fair to ban encryption  in
     all  places  BUT private messages.  Including the last point, it
     seems that it should be totally banned, or performed in a simple
     matter that anyone  needing to check for illegal activity.  This
     seems to be a trivial exercise, as it removes the privacy aspect
     again!

     I suggest an open debate  in  an  echo area, or pehaps a vote of
     some kind by the participants in  FidoNet.   As voting by e-mail
     would be difficult, I suggest that it  be  restricted  to sysops
     only,  and the voting to be restricted to  one  vote  per  node.
     Comments on this method, please.

     Finally, I would like to point out that the  echo  area  I  have
     seen on some bulletin board, containing USENET and ACSNET jokes,
     have in  them  messages  encryped  with  ROT13 (rotating letters
     forward 13 characters), which is quite popular and necessary for
     legal reasons on potentially offensive jokes.  The ruling in the
     draft policy makes these messages  rather  illegal.   How should
     these be handled?

           Yours,
                     Garth Kidd.

     -----------------------------------------------------------------
     FidoNews 6-17                Page 30                  24 Apr 1989


     =================================================================
                              LATEST VERSIONS
     =================================================================

                          Latest Software Versions

                           Bulletin Board Software
     Name        Version    Name        Version    Name       Version

     Fido            12k    Opus          1.03b    TBBS           2.1
     QuickBBS       2.03    TPBoard         5.0    TComm/TCommNet 3.4
     Lynx           1.30*   Phoenix         1.3    RBBS         17.1D


     Network                Node List              Other
     Mailers     Version    Utilities   Version    Utilities  Version

     Dutchie       2.90C*   EditNL         4.00    ARC           6.01
     SEAdog         4.50    MakeNL         2.12    ARCmail        2.0
     BinkleyTerm    2.20*   Prune          1.40    ConfMail      4.00
     D'Bridge       1.18*   XlatList       2.90    TPB Editor    1.21
     FrontDoor       2.0    XlaxNode       2.32    TCOMMail       2.2*
     PRENM          1.40    XlaxDiff       2.32    TMail         8901
                            ParseList      1.30    UFGATE        1.03
                                                   GROUP         2.07*
                                                   EMM           1.40
                                                   MSGED         1.99
                                                   XRS            2.0*

     * Recently changed

     Utility authors:  Please help  keep  this  list  up  to  date  by
     reporting  new  versions  to 1:1/1.  It is not our intent to list
     all utilities here, only those which verge on necessity.

     -----------------------------------------------------------------
     FidoNews 6-17                Page 31                  24 Apr 1989


     =================================================================
                                  NOTICES
     =================================================================

                          The Interrupt Stack


     28 Apr 1989
        Start of Gateway '89 show at the Viscount Hotel in Queens,
        New York. Contact Gateway '89 at (516) 678-7180 for info.

      8 May 1989
        Digital Equipment Corporations User Society (DECUS) will be
        holding its semi-annual symposium in Atlanta, GA. Runs
        through May 12. As usual sysop's will get together and chat.

     15 May 1989
        Denmark changes telephone numbers from 7 to 8 digits.

     19 May 1989
        Start of EuroCon III at Eindhoven, The Netherlands. Contact
        Hans Ligthelm of 2:500/3 for details.

      5 Jun 1989
        David Dodell's 32nd Birthday

     24 Aug 1989
        Voyager 2 passes Neptune.

     24 Aug 1989
        FidoCon '89 starts at the Holiday Inn in San Jose,
        California.  Trade show, seminars, etc. Contact 1/89
        for info.

      5 Oct 1989
        20th Anniversary of "Monty Python's Flying Circus"

     11 Nov 1989
        A new area code forms in northern Illinois at 12:01 am.
        Chicago proper will remain area code 312; suburban areas
        formerly served with that code will become area code 708.

     If you have something which you would like to see on this
     calendar, please send a message to FidoNet node 1:1/1.

     -----------------------------------------------------------------

     FidoNews 6-17                Page 32                  24 Apr 1989


            OFFICERS OF THE INTERNATIONAL FIDONET ASSOCIATION

     Mort Sternheim 1:321/109  Chairman of the Board
     Bob Rudolph    1:261/628  President
     Matt Whelan    3:3/1      Vice President
     Bill Bolton    3:711/403  Vice President-Technical Coordinator
     Linda Grennan  1:147/1    Secretary
     Kris Veitch    1:147/30   Treasurer


            IFNA COMMITTEE AND BOARD CHAIRS

     Administration and Finance     Mark Grennan    1:147/1
     Board of Directors             Mort Sternheim  1:321/109
     Bylaws                         Don Daniels     1:107/210
     Ethics                         Vic Hill        1:147/4
     Executive Committee            Bob Rudolph     1:261/628
     International Affairs          Rob Gonsalves   2:500/1
     Membership Services            David Drexler   1:147/1
     Nominations & Elections        David Melnick   1:107/233
     Public Affairs                 David Drexler   1:147/1
     Publications                   Rick Siegel     1:107/27
     Security & Individual Rights   Jim Cannell     1:143/21
     Technical Standards            Rick Moore      1:115/333


                      IFNA BOARD OF DIRECTORS

         DIVISION                               AT-LARGE

     10  Courtney Harris   1:102/732    Don Daniels     1:107/210
     11  Bill Allbritten   1:11/301     Mort Sternheim  1:321/109
     12  Bill Bolton       3:711/403    Mark Grennan    1:147/1
     13  Irene Henderson   1:107/9       (vacant)
     14  Ken Kaplan        1:100/22     Ted Polczyinski 1:154/5
     15  Scott Miller      1:128/12     Matt Whelan     3:3/1
     16  Ivan Schaffel     1:141/390    Robert Rudolph  1:261/628
     17  Neal Curtin       1:343/1      Steve Jordan    1:206/2871
     18  Andrew Adler      1:135/47     Kris Veitch     1:147/30
     19  David Drexler     1:147/1       (vacant)
      2  Henk Wevers       2:500/1      David Melnik    1:107/233

     -----------------------------------------------------------------
     FidoNews 6-17                Page 33                  24 Apr 1989


                                      __
                 The World's First   /  \
                    BBS Network     /|oo \
                    * FidoNet *    (_|  /_)
                                    _`@/_ \    _
                                   |     | \   \\
                                   | (*) |  \   ))
                      ______       |__U__| /  \//
                     / Fido \       _//|| _\   /
                    (________)     (_/(_|(____/ (tm)

            Membership for the International FidoNet Association

     Membership in IFNA is open to any individual or organization that
     pays  a  specified  annual   membership  fee.   IFNA  serves  the
     international  FidoNet-compatible  electronic  mail  community to
     increase worldwide communications.

     Member Name _______________________________  Date _______________
     Address _________________________________________________________
     City ____________________________________________________________
     State ________________________________  Zip _____________________
     Country _________________________________________________________
     Home Phone (Voice) ______________________________________________
     Work Phone (Voice) ______________________________________________

     Zone:Net/Node Number ____________________________________________
     BBS Name ________________________________________________________
     BBS Phone Number ________________________________________________
     Baud Rates Supported ____________________________________________
     Board Restrictions ______________________________________________

     Your Special Interests __________________________________________
     _________________________________________________________________
     _________________________________________________________________
     In what areas would you be willing to help in FidoNet? __________
     _________________________________________________________________
     _________________________________________________________________
     Send this membership form and a check or money order for $25 in
     US Funds to:
                   International FidoNet Association
                   PO Box 41143
                   St Louis, Missouri 63141
                   USA

     Thank you for your membership!  Your participation will help to
     insure the future of FidoNet.

     Please NOTE that IFNA is a general not-for-profit organization
     and Articles of Association and By-Laws were adopted by the
     membership in January 1987.  The second elected Board of Directors
     was filled in August 1988.  The IFNA Echomail Conference has been
     established on FidoNet to assist the Board.  We welcome your
     input to this Conference.

     -----------------------------------------------------------------
