================================================ == North American Backbone Frequently == == Asked Questions and HELP file == 01 Apr 97 ================================================ BOFAQ704.TXT (Items preceded by a 'pipe' symbol (|) are changes since previous version.) Terms used throughout this file: Backbone.Na - A text file listing all echoes, and their descriptions, that are presently carried on the North American Backbone. This text file is formatted in a manner which makes it easily readable by EchoMail distribution software to use as a "forward list". The file is published weekly and distributed through the EchoMail Hubs. Formerly known as Fidonet.Na. Backbone.No - A file, distributed along with Backbone.Na, which acts as a buffer for conferences that are in the process of being removed from Backbone distribution for failing to maintain a listing in the Echolist. Conferences are customarily queued in this file for a period of 90 days. Formerly known as Fidonet.No. Backstat.Na - A North American Backbone newsletter published weekly which, among other things, itemizes echoes which are in the process of being added to the North American Backbone as well as listing the Zone and Region Hubs. Backstat.Na is distributed in much the same manner as Backbone.Na. It is advisable that those people who rely on the North American Backbone get in the habit of reading this file. Formerly known as Fidostat.Na. Echo (Conference) - An echomail conference is a message base or forum, distributed under a specified echomail conference name, dealing with a defined area of interest. Gateways - Echomail Gateways are nodes whose systems are used to exchange mail with other groups. The term Gateway, as used here, includes all forms of gating including, but not limited to, zone-gating, inter-network gating, intra-network gating, and domain-gating. Hub - Echomail Hubs are people who distribute echomail. Zone Hubs distribute echomail at the zone level: Region Hubs distribute echomail at the region level: Net Hubs distribute echomail at the net level. Moderator - Person(s) responsible for the echo and its liaison with the Backbone. North American Backbone - Group of volunteers who help distribute EchoMail and routed netmail, the structure of which is somewhat flexible. Customarily recognized as a set of tiers with the intention of distributing EchoMail in an accurate and expeditious manner. The North American Backbone tiers are identified by the use of Hubs who subdivide and distribute to lower tiers. From this point forward throughout this file, the North American Backbone will be referred to as, the "Backbone". O.B.O. - Overseer of Backbone Operations - Person responsible for maintenance of this help file and its associated distribution documents. The position has customarily been occupied by the Zone 1 EchoMail Coordinator (identified by the 1:1/200 address in the FidoNet nodelist). Ultimately responsible for all decisions regarding EchoMail distribution on the North American Backbone. O.B.O. Council - A group of people representing the EchoMail interests of the Zone, assembled for the purpose of providing input and perspective to the O.B.O. The Council consists of the 10 Region EchoMail Coordinators. Region EchoMail Coordinator - In respect to the Backbone, this person sits on the O.B.O. council representing his/her respective FidoNet Region. Each Region EchoMail Coordinator can be identified by an administrative address in the FidoNet nodelist in the form 1/2xx (where "xx" = the Region number.) Zone Echolist - As it relates to the Backbone, a database containing a list of echoes distributed by, or aspiring to be distributed by, the Backbone. The format of this monthly distributed database is at the discretion of the ZEC, however customarily contains echo names, moderator names and addresses, and descriptions of the echoes. Zone EchoList Coordinator - Person responsible for the maintenance and production of the Zone EchoList. Q1 =================================================================== What is the purpose of this help file? This help file has been assembled as a means to provide answers to frequently asked questions regarding how the Backbone operates and to provide an insight into its internal administration. Q2 =================================================================== Who appoints the Hubs? Hubs at the Zone level, commonly referred to as "Stars", are appointed by the O.B.O. Hubs at the Region level are appointed by their respective Region EchoMail Coordinators. The appointment of Hubs at the Net level is left up to local policy to decide. Q3 ================================================================== Are all of the echoes listed in Backbone.Na available from all of the Hubs? The Zone Hubs (Stars) make available all echoes which are listed in Backbone.Na. Region Hubs and Net Hubs are not obligated to carry all listed echoes. NO Hub is required to carry any echo that, in their opinion, could subject them to consequences which might have a negative effect on their well being. Q4 ================================================================== What are the responsibilities of a Moderator of an echo which the North American Backbone carries? 1) Seeing that messages in their conference(s) correspond to the conference's theme. 2) Updating their conference(s) listing in the Echolist at least every six months. 3) To prevent the distribution of their conference(s) from interfering with the operation of the Backbone. 4) Must be accessible via NetMail through known channels. Q5 ================================================================== What "tools" does the Backbone provide to a Moderator in order to help him/her carry out their responsibilities? If a Moderator believes that a node is violating a conference rule, he/she may request the feed to that node be severed. This authorization is made in direct written form (netmail), to the Hub feeding the offending node, with a copy to the offending node. It is recommended that a copy also be sent to the node's NEC so that he or she is aware of such problems in the Net and can provide information and assistance. Some important points to remember regarding feed cuts; 1) Feed cuts should be initiated with an effort to cause the least amount of disruption to the echo. 2) In most cases, the main goal of a feed cut is to remove a REPEAT offender who is likely to cause future echo disruption. 3) Echo rule offenders are, in most cases, PEOPLE.... not systems. 4) SYSTEMS should not be cut until efforts to remove the PERSON have failed. Moderators should attempt to resolve problems as close to the root of the problem as possible, i.e., User first, SysOp second, Hub third, etc. 5) Feed cuts at the Zone level are taken very seriously. Only use them as a last resort after all other means have failed. Have proper documentation ready to support a link cut request at the Zone level showing that all other efforts have failed. 6) Feed cut requests are just that... requests. Communications should be polite and not demanding as you are REQUESTING help from another system. Q6 =================================================================== What means does the Backbone use to recognize the Moderator of a conference? A Moderator is recognized as follows: 1) Upon formation of a conference, the person who forms the conference is the Moderator. 2) Upon resignation or replacement of an existing Moderator, the conference's rules define how the new Moderator is selected. 3) The Backbone refers to the current Zone EchoList in order to identify an echo's Moderator. As far as the Backbone is concerned, all individuals listed as Moderators of a particular echo are equal . Q7 ================================================================== I am the moderator of a conference, but I may be away from my computer for long periods of time. What does the Backbone suggest that I do to ensure that my conference is properly maintained? Moderators are encouraged to appoint Co-Moderators to assist them in their duties and to stand in for them in their absence. Q8 ================================================================== What is the Backbone's position on illegal activities conducted within EchoMail conferences? The Backbone does not distribute any conference which routinely contains messages which are encrypted, contain illegal information, or promote illegal activities. As used in this paragraph, "illegal activities" includes activities which are a violation of civil law as well as activities which could result in criminal prosecution. The Backbone does not distribute any conference which routinely contains counterfeit messages. A counterfeit message is any message entered using another person's name, handle, or node address with the intent of deceiving others about the true author of the message. Q9 ================================================================== What is the Backbone's position on the censorship of EchoMail messages as they pass through the distribution system? The Backbone does not permit the deletion or alteration of messages as they are distributed. The exceptions to this provision are the deletion of messages, by any node, which may lead to legal action against that node or which do not meet echomail message standards. Q10 ================================================================= Regarding echomail standards, what standards does the Backbone employ? FTSC specifications FTS-0001 and FTS-0004 are followed. All Backbone nodes use the pathline option. Q11 ================================================================= How does one go about getting an echo added to North American Backbone distribution? The O.B.O. generally adds a conference to the Backbone when all of these requirements are met: 1) The conference is listed in the Echolist. 2) The moderator sends a request to the O.B.O., or preferably posts a message in the Z1_BACKBONE echo addressed TO: BACKBONE, requesting that his/her echo be distributed by the Backbone. He/She should include a copy of the Echolist confirmation message which was received verifying that the echo is listed in the EchoList. 3) Two O.B.O council members recommend that the Backbone carry the conference to their regions. Q12 ================================================================= When does the Backbone remove an echo from its distribution system? The O.B.O. generally drops a conference when any of these situations occur: 1) The conference is not listed in the Echolist. 2) Unconditionally when the moderator requests that the echo be removed. 3) There are no longer two O.B.O. Council members requesting that the Backbone carry the conference to their regions. 4) The Moderator fails to properly carry out his responsibilities. 5) The conference is without a Moderator for over 30 days. 6) The traffic level in the conference falls below 5 messages per month. 7) When the O.B.O. considers that the distribution of an echo is no longer in the best interest of the Backbone. Q13 ================================================================= How do Backbone nodes handle NetMail that lands on their systems in the course of distributing EchoMail? The Backbone encourages the use of 'Echo routed NetMail' as a means of keeping echo volume and off-topic posts to a minimum. Backbone nodes accept routed netmail from any node who connects with them for conferences. Any netmail message with a deliverable destination within FidoNet, regardless of its origin, is accepted. Routed netmail may be routed along echomail paths or to a ZC, RC, or NC who has agreed to handle such mail. Routed netmail is for personal messages. It is not for commercial messages, conferences, mailing lists, news groups, file-attaches, "encoded" files, pyramid letters, or chain letters. Q14 ================================================================= What does the Backbone expect of nodes who operate as "Gateways" into and out of other domains? Gateways must remove foreign distribution identifiers (including seen-bys) which might adversely affect the distribution of the conference on the Backbone. Gateways also pass netmail into the other network, unless it is technically impossible to do so. Q15 ================================================================= What obligation does the Backbone have to those that desire to get their EchoMail feed from it? To strive to distribute EchoMail in the most accurate and expeditious manner possible within its means. Although the North American Backbone attempts to provide the best service possible, there is no guarantee of service provided. It is operated by volunteers and is not obligated to handle any conference that could take the fun out of the hobby. Use of Backbone services should be viewed as a privilege, not a right. Messages which require sensitive or timely handling should not be sent through the Backbone. Q16 ================================================================= What is the update procedure for this document? The O.B.O. may update this help file anytime that he/she feels that it would be in the best interest of the Backbone and those people it voluntarily serves in order to more accurately reflect its current operation. Q17: ================================================================ I need to change the name of my Backboned echo. Is it necessary for me to go through the entire "2 REC approval process" all over again? The current echo is well established on the Backbone. In order to change the name of an existing echo without the necessity of reapproval, you must do the following; 1) ELIST the new echo name. (See ELMOD) 2) Set a date for the change to occur. This date should give all concerned plenty of time to prepare. Generally, a 3-4 week notice should suffice. The proposed date for the change should fall on a Saturday. 3) Spread the word of the impending name change. Do so in the effected echo, the Z1_BACKBONE echo, and via netmail to the OBO and each Zone Hub. 4) Item 3 should be repeated at least once per week before the name change is to occur. 5) On the day before the change is to occur, send a NetMail reminder to the OBO. 6) The change occurs. (This requires manual intervention on the part of several people who maintain the Backbone data files.) The new echo name is added to Backbone.NA and the old echo name is removed. 7) Send a MOD DEL message to the EchoList software to delete the old echo from the EchoList. 8) If you follow this procedure, it is not necessary to get the (2) REC requests. The echo will be Backbone'd. Q18: ================================================================ What is the Backbone's position on the use of "Anonymous Remailers" (software which conceals the identity of a message poster) in echos that it distributes? If a moderator of an echo desires that an Anonymous Remailer be allowed to inject messages into his/her echo it is not for the Backbone administration to disallow it. AR messages are covered under our previously defined guidelines and there are provisions in place if its messages should cause a problem. However, an Anonymous Remailer is not to be used to inject messages into any echo distributed by the Backbone until such a time as the echo's moderator has informed the operator of the AR that such messages would be welcome. The burden of proof that such a request has been granted is to be carried by the operator of the Anonymous Remailer. Q19: ================================================================ I notice that an echo's description in the EchoList places limitations on those who are permitted to access the echo. Does the Backbone enforce those restrictions? No. When moderators place their echo(s) on the Backbone they must realize that Backbone Hubs distribute publicly available echos and that the job of enforcing any kind of access restrictions remains with the Moderator. These restrictions, as well as the echo rules, are usually available within the EchoList so that a Sysop that's interested in the echo may review them at his or her leisure prior to actually carrying the echo on his or her system. oOo END oOo