===================================== == Zone 1 Backbone == == Service Level Agreement == ===================================== SLA_0004.Z1B - Apr 00 ========================= Table of Contents =================== 1.0 Introduction 1.1 Purpose of this Document 1.2 Definitions 1.3 Service Level Agreement 1.4 Z1B Relationship to FidoNet 1.5 Changes to this Document 2.0 Z1B Administration 2.1 Voting 2.2 Selection of Z1B Hubs 2.3 Selection of the Z1BC 2.4 Administrative Areas 3.0 Moderators 3.1 Moderator Identification 3.2 Moderator Responsibilities 3.3 Moderator Tools 3.4 Echo Addition 3.5 Echo Removal 3.6 Echo Name Change 4.0 Standard Operating Procedures 4.1 Technical Standards 4.2 Gateways 4.3 Encrypted Messages 4.4 Encoded Files in Echoes 4.5 Illegal Activities 4.6 Censorship of Messages 4.7 Anonymous Remailers 4.8 Emergency Plans (Items noted by the "|" are changes from the previous version.) 1.0 Introduction =================== 1.1 Purpose of this Document ------------------------------- This Service Level Agreement has been assembled as a means to provide information about the Zone 1 Backbone, how it operates, what it offers, what it expects in return, and to provide insight as to its internal administration. This document is updated as circumstances and practices change. Please ensure that you are referencing a current edition. 1.2 Definitions ------------------ Zone 1 Backbone - A group of volunteer FidoNet hubs who help distribute echomail and routed netmail in FidoNet Zone 1 (North America). The structure is customarily recognized as a set of tiers with the intention of distributing echomail in an accurate and expeditious manner. Hereafter in this document the Zone 1 Backbone is referred to simply as the Z1B. Echo or Conference - An echomail conference is a message base or forum, distributed under a specified echomail conference name or tag, dealing with a defined area of interest. Hereafter in this document echomail conferences are referred to simply as echoes. Zone 1 Backbone Hub - A hub who helps to distribute mail within the Zone 1 Backbone. Tier 1 Z1B Hubs, also known as ZHubs or Stars, distribute mail at the zone level. They are fully meshed with each other for speed and reliability. Tier 2 Z1B Hubs, also known as RHubs, distribute mail at the region level. Tier 3 Z1B Hubs distribute mail at the net level. Zone 1 Backbone Coordinator (Z1BC) - Person responsible for the day-to-day operation of the Zone 1 Backbone. He coordinates routing to ensure reliable and efficient transport of echomail and Z1B-routed netmail while avoiding creation of duplicate messages. He also serves as liaison to the ZEC and to other distribution systems. Echomail Coordinators (ECs) - Echomail Coordinators have been recognized by Fidonet since 1987. The Zone Echomail Coordinator (ZEC) functions at the zone level. Region Echomail Coordinators (RECs) function at the region level. Net Echomail Coordinators (NECs) function at the net level. BACKBONE.Z1B - A text file listing all echoes, and their descriptions, which are presently distributed by the Zone 1 Backbone. This text file is formatted in a manner which makes it easily readable by echomail distribution software to use as a "forward list". It is published weekly by the Z1BC and distributed in the BACKBONE file area. BACKSTAT.Z1B - A text file containing the Zone 1 Backbone status report which, among other things, itemizes echoes which are in the process of being added to or dropped from the Zone 1 Backbone, as well as listing the Tier 1 and 2 Z1B Hubs, and the Z1BC. It is published weekly by the Z1BC and distributed in the BACKBONE file area. It is advisable that those who rely on the Zone 1 Backbone get in the habit of reading this file. SLA_xxxx.Z1B (xxxx = yymm version) - This document. It is published monthly by the Z1BC and distributed in the BACKBONE file area. Moderator - Person(s) responsible for an echo and its liaison with the Zone 1 Backbone. EchoList - A database containing a list of echoes, published monthly by the EchoList Coordinator (1:1/21). It customarily contains echo names, moderator names and addresses, and descriptions of the echoes. 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, FidoNet zone gating, inter-distribution system gating, inter-network gating, and domain gating. 1.3 Service Level Agreement ------------------------------ The members of the Z1B agree to distribute mail in the most accurate and expeditious manner possible within their means. Although they agree to provide the best service possible, they do not have control over all of the factors thus some problems might occur occasionally. Netmail messages which are time critical or require sensitive handling should be sent direct. The Tier 1 and 2 Z1B Hubs agree to make available all echoes which are listed in BACKBONE.Z1B. Tier 3 Z1B Hubs are not obligated to distribute all listed echoes. In no case does any Z1B Hub agree to distribute any echo which, in their own opinion, could subject them to consequences which might have a negative effect on their well being. The Z1B encourages the use of "echo-path routed netmail" (ERN) as a means of keeping echo volume and off-topic posts at a reasonable level. Z1B Hubs agree to accept routed netmail from any node who connects with them. Any netmail message with a deliverable destination within FidoNet, regardless of its origin, is accepted. The Z1B Hubs agree to route ERN according to the wishes of the individual nets. The Z1B Hubs depend on regional routing maps provided by the RECs to represent these wishes. The Z1B encourages all nets to list every ERN connection path to the nearest Tier 1 (zone level) Hub, regardless of distribution system, in their region's chart. This will allow ERN to follow the best path available. When these paths are not known or are not available, Z1B Hubs agree to route ERN along echomail paths or to a ZC, RC, or NC who has agreed to handle such mail. The Z1B Hubs agree that ERN is for personal messages. It is not for commercial messages, echoes, tunneling, mailing lists, news groups, file-attaches, "encoded" files, pyramid letters, or chain letters. Thus, the Z1B Hubs do not agree to route such messages. The Z1B Hubs agree to treat all in-transit netmail as private mail. The Z1B Hubs agree to not read or disclose routed netmail which passes through their systems, except as required for technical or legal reasons. The Z1B consists of volunteers. It does not agree to handle any echo which could take the fun out of the hobby. Use of Z1B services should be viewed as a privilege, not a right. Any or all of these services may be terminated at any time, without any prior notice. All Z1B Hubs agree to the terms of this document. 1.4 Z1B Relationship to FidoNet ---------------------------------- The Z1B is indeed part of FidoNet. It's made up of a voluntary group of FidoNet members. It exists within FidoNet and must abide by FidoNet Policy, just as any other FidoNet node or group of FidoNet nodes. However, the Z1B is not an entity or sub-division of FidoNet in the sense that it is not mandated or defined by FidoNet Policy and is not operated by FidoNet officials. There is no requirement for the Z1B to offer services and there is no requirement for anyone to use the Z1B's services. This document is not a part of FidoNet Policy. Should any part of this document conflict with FidoNet Policy, then FidoNet Policy shall prevail. 1.5 Changes to this Document ------------------------------- This document is changed only as the result of a two-thirds vote. Anyone may propose a change by finding a Tier 1 or 2 Z1B Hub who is willing to sponsor it for them. 2.0 Z1B Administration ========================= 2.1 Voting ------------- Tier 1 and 2 Z1B Hubs, as listed in BACKSTAT.Z1B, get 1 vote each. Nobody else may vote. All voting is by public ballot in the Z1B_COORD echo. The standard voting period is 1 week. Unless specified otherwise, a majority vote (more than half of those voting) is the norm. Certain decisions, as noted, require a two-thirds vote (at least two-thirds of those voting). A recall vote can not be held until at least 4 months has elapsed since the prior selection or recall vote for the person holding that position. 2.2 Selection of Z1B Hubs ---------------------------- Tier 1 Z1B Hubs are selected by a majority vote. They are normally chosen from amongst the Tier 2 Z1B Hubs. They serve an indefinite term but are subject to recall by a two-thirds vote. Tier 2 Z1B Hubs are selected by a majority vote. Anyone may apply by finding a Tier 1 or 2 Z1B Hub who is willing to nominate them. The applicant should connect to either a Tier 1 or 2 Z1B Hub and route netmail and/or echomail for at least a few nets other than their own. They serve an indefinite term but are subject to recall by a two-thirds vote. Tier 3 Z1B Hub selection is left up to the individual nets. 2.3 Selection of the Z1BC ---------------------------- The Z1BC is selected by a majority vote. Anyone may apply by finding a Tier 1 or 2 Z1B Hub who is willing to nominate them. He serves a 1 year term but is subject to recall by a two-thirds vote. Note: The term of the current Z1BC expires on April 1, 2000. 2.4 Administrative Areas --------------------------- The Z1B uses two echoes of its own and two shared file areas to conduct its business. The Z1BACKBONE echo is open to any node having business with the Z1B. The moderator for this area is selected by a majority vote. He serves an indefinite term but is subject to recall by a two-thirds vote. The Z1B_COORD echo is restricted to Tier 1 and 2 Z1B Hubs, the Z1BC, and invited guests. Guests are invited by a majority vote. The moderator for this area is the Z1BC. The Z1B also makes use of the shared BACKBONE and Z1_REC file areas. 3.0 Moderators ================= 3.1 Moderator Identification ------------------------------- The Z1B refers to the current EchoList in order to identify an echo's moderator. As far as the Z1B is concerned, all individuals listed as moderators or co-moderators of a particular echo are equal. In case of disagreement, however, the moderator listed first has priority. Moderators are encouraged to appoint co-moderators to assist them in their duties and to stand in for them in their absence. This will ensure that the echo is properly maintained, especially in the case of a moderator who is frequently absent for long periods of time. 3.2 Moderator Responsibilities --------------------------------- The responsibilities of a moderator of an echo which the Z1B distributes are: 1) Seeing that messages in their echo correspond to the echo's theme. 2) Updating their echo's listing in the Echolist at least every six months. 3) Preventing the distribution of their echo from interfering with the operation of the Z1B. 4) Must be accessible via netmail through known channels. 5) Seeing that messages in their echo do not violate the standards set in Section 4. When moderators place their echoes on the Z1B they must realize that Z1B Hubs distribute publicly available echoes and that the job of enforcing any kind of access restrictions remains with the moderator. These restrictions, as well as the echo's rules, are usually available in the EchoList so that any Sysop interested in the echo may review them prior to actually carrying the echo on his or her system. 3.3 Moderator Tools ---------------------- The Z1B provides some "tools" to a moderator in order to help him/her carry out their responsibilities. If a moderator believes that a node is violating an echo rule, he/she may request the feed to that node be severed. This request is made in written form (netmail), to the Z1B 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 cut requests: 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. 3.4 Echo Addition -------------------- The Z1BC adds an echo to Z1B distribution when all of these requirements are met: 1) The moderator lists the echo in the EchoList. See the EchoList FAQ for information about how to do this. 2) The moderator requests that the echo be distributed by the Z1B. The request should be sent from one of the moderator addresses listed in the EchoList, via one of the following methods, preferably "A". A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" The body of the request should consist of a current copy of the EchoList listing for the echo. This could be taken from a recent message from the EchoList (netmail, email or echomail) or be an excerpt from the current EchoList itself. The echo is then listed in BACKSTAT.Z1B as requesting addition. 3) Within one month of being initially being listed in BACKSTAT.Z1B, two Tier 1 or 2 Z1B Hubs and/or RECs request that the Z1B distribute the echo. The requests should be sent via one of the following methods, preferably "A". A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" The requests are noted in BACKSTAT.Z1B. If two requests are not forthcoming, prior to the one month expiring the moderator may request a one month extension from the Z1BC. The echo is then added to BACKBONE.Z1B and this is noted in BACKSTAT.Z1B. A welcome message is sent in the echo to help establish links. At this time any private links to the echo should be switched to the Z1B. 3.5 Echo Removal ------------------- The Z1BC removes an echo from Z1B distribution when any of these situations occur: 1) The echo is not listed in the EchoList. The echo is first listed as "not in EchoList" in BACKSTAT.Z1B for up to 3 months, then it is dropped entirely. During these 3 months, bi-monthly warning messages are posted in the echo alerting the moderator and the users as to the echo's status. If at any time during these 3 months it is re-listed in the EchoList then it's status is restored. 2) Unconditionally when the moderator sends a direct request to the Z1BC that the echo be removed. The request should be sent from one of the moderator addresses listed in the EchoList, to one of the following: A) Echomail: To "Z1B", in the Z1BACKBONE echo B) Netmail: To "Z1B", at the Z1BC's FidoNet address C) Email: To the Z1BC's Internet address, subject "Z1B" 3) The moderator fails to properly carry out his responsibilities (see Section 3.2). 4) The traffic level in the echo falls below 2 messages for any month. The echo is first listed as "low traffic" in BACKSTAT.Z1B for up to 6 months, then it is dropped entirely. If at any time during these 6 months the traffic level rises to or above 5 messages for any month then it's status is restored. The Z1B drops echoes when the traffic level falls below a minimum: A) To encourage the formation of new echoes, like pruning dead branches off a tree. B) To save the SysOps and users from the frustration of setting up areas only to find that they are dead. 5) When it is decided by a two-thirds vote that the distribution of an echo is not in the best interest of the Z1B. All changes in status of echoes are noted in BACKSTAT.Z1B. 3.6 Echo Name Change ----------------------- In order to change the name of an echo which is currently distributed by the Z1B, without the necessity of reapproval, you should: 1) EchoList the new echo name. 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 Sunday. 3) Spread the word of the impending name change. Do so in the affected echo, the Z1BACKBONE echo, and via netmail or email to the Z1BC. 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 Z1BC. 6) The change occurs. The new echo name is added to BACKBONE.Z1B and the old echo name is removed. 4.0 Standard Operating Procedures ==================================== 4.1 Technical Standards -------------------------- The Z1B observes FTSC specifications FTS-0001 and FSC-0074. Notes: 1) All Z1B Hubs use the pathline. 2) The Z1B considers the "toUserName", "fromUserName" and "Origin Line" to be control information lines, thus character set restrictions apply. 3) The requirement that control information lines shall contain only ASCII characters, from 32 to 126, is extended to include hi-bit alphabetic characters, including 128 to 168, 173, and 224 to 240. 4) Echomail messages older than 30 days may considered to be dupes. This technique has undergone much testing and has proven its value in preventing dupes due to massive rescans without interfering with the flow of normal echomail. 5) Due to the limitations of some current software, the Z1B can not guarantee delivery of messages in excess of 30K bytes. Z1B Hubs are encouraged to use message processing software which allows larger messages, preferably up to 64K bytes, to be handled. Z1B Hubs may split large messages to ensure their safe passage. Z1B Hubs may delete messages which do not conform to these technical standards when such messages might be harmful to the technical operation of the Z1B. This includes duplicate messages and "grunged" messages. Such messages are generally not returned. Z1B Hubs operate in a secure fashion. They automatically process inbound messages only from those nodes with which prior agreements have been made. Normally this means that Z1B Hubs use session passwords and secure ("protected") inbound areas. However, any reasonable method of ensuring that non-secure messages do not enter the Z1B is acceptable. A Z1B Hub may choose not to provide services to a node which does not operate in a secure fashion. 4.2 Gateways --------------- Gateways must remove foreign distribution identifiers (including seen-bys) which might adversely affect the distribution of the echo on the Z1B. Pathlines, however, should be left intact. The origin line should be that of the Gateway. Gateways also pass netmail into the other network, unless it is technically impossible to do so. 4.3 Encrypted Messages ------------------------- Some Z1B Hubs do not allow encrypted messages to flow through their systems. Therefore, the Z1B does not agree to handle encrypted messages in routed netmail or in echoes, excepting digital signatures and occasional demonstration and/or test messages. 4.4 Encoded Files in Echoes ------------------------------ Echomail is not an efficient method of transporting files. There are many File Distribution Networks which can be used instead. Thus the Z1B does not distribute any echo which routinely contains large (multi-message) encoded files. The use of an echo for small or occasional encoded files is left up to the discretion of its moderator. 4.5 Illegal Activities ------------------------- The Z1B does not distribute any echo which routinely contains messages which 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. 4.6 Censorship of Messages ----------------------------- Z1B Hubs do not delete or alter messages as they are distributed, except for technical reasons. If a Z1B Hub feels that netmail messages may lead to legal action against him then he may decline to handle such messages, as per FidoNet Policy. If a Z1B Hub feels that echomail messages may lead to legal action against him then he may decline to handle that echo in its entirety, notifying the echo's moderator. The Z1B does not distribute any echo 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. 4.7 Anonymous Remailers -------------------------- An "Anonymous Remailer" (AR) is software which conceals the identity of a message's author. Use within an echo is up to the moderator of that echo. However, an AR should not be used in an echo until 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 carried by the operator of the AR. 4.8 Emergency Plans ---------------------- The Tier 1 Z1B Hubs maintain emergency backup plans should one of them experience problems. These plans include: 1) Quick availability of replacement equipment. 2) Adequate backups of necessary control information. 3) Standby nodes capable of assuming the load. 4) Alternate routing to bypass a down Tier 1 Z1B Hub. ================================== End ==================================