home *** CD-ROM | disk | FTP | other *** search
/ PC Online 1996 October / PCO_10.ISO / filesbbs / virnet.arj / VIR-POL2.TXT < prev    next >
Encoding:
Text File  |  1992-10-09  |  7.8 KB  |  186 lines
  1.  
  2.                 VirNet Echomail/Netmail policy 92-Aug-03
  3.                 ========================================
  4.  
  5.                                 By
  6.            Jonny Bergdahl, International Coordinator (9:9/1)
  7.                                 and
  8.                     Mikael Larsson, ZoneHost (9:9/0)
  9.  
  10. 0. Preface
  11.  
  12.    This policy document is written in an informal way in
  13.    order to make it easy for anyone to understand what it is
  14.    intended to say. This policy is covering some of the more
  15.    important aspects of the net that applies to everyday use,
  16.    and leaves out some of the more boring things, like how
  17.    to excommunicate a node, legally sounding paragraphs etc.
  18.  
  19. 1. Echomail export.
  20.    When exporting echomail as a Host or HUB - ALWAYS use your
  21.    administrative AKA. If you are a Host - use net/0 as the
  22.    origin of ALL echomail. If you are a HUB - use net/x00 as
  23.    your origin.
  24.  
  25.    Use the highest administrative AKA you have. If you are a
  26.    Region host use 9:<country code>/0 instead of you net host AKA.
  27.  
  28.    The same goes for the nodes. They should export their
  29.    echomail to your administrative adress.
  30.  
  31.    The reason for this system is that this makes it VERY easy when
  32.    a host or HUB is changed. NO links has to be changed at
  33.    all once the change is reflected in the new nodelist.
  34.  
  35. 2. Your own nodenumber.
  36.    This need not be used at all in echomail by a Host/HUB. If
  37.    You are a host/HUB and You set up Your system so it will EXPORT
  38.    with the right adress (/*0), then You are free to do so. ie:
  39.    It's not wrong using any of your AKA:s in the origin of echomail,
  40.    just as long as You export it with the right nodenumber.
  41.  
  42.    All nodes will have it's own nodenumber, and for us with
  43.    administrative nodenumbers as well it's plainly there just
  44.    in case we resign to being just a mere node.
  45.  
  46. 3. Pvt Nodes and Points.
  47.    Points are not permitted in VirNet, but private nodes are.
  48.    Therefore, if anyone requests membership, he should be given
  49.    a nodenumber regardless of the reason for him not being a
  50.    "full" node.
  51.  
  52.    This means that if any of your own points wants to join -
  53.    give them their own nodenumber.
  54.  
  55.    Hosts or HUBS are not accepted as private systems since
  56.    all nodes under them are to poll them for their echo- and
  57.    netmail.
  58.  
  59.    Also - There should be no flags set in the nodelist for a
  60.    Pvt node. Since the phonenumber isn't published, there is
  61.    no use for them.
  62.  
  63. 4. Administrative nodenumbers.
  64.    These are to be treated right. They are not to be used to
  65.    extend your ego by having many AKA:s. Also - the only
  66.    Coordinator of VirNet is 9:9/1 - VirNet Zone Coordinator.
  67.    If things do not work the way it should we might have to
  68.    have Region Echo Coordinators as well, but this is not the
  69.    case at this time.
  70.  
  71. 4.0 International Coordinator.
  72.     The International Coordinator acts as a mediator and a
  73.     coordinator of net and echomail. Any disputes between nodes
  74.     in VirNet are processed by the International Coordinator
  75.     in cooperation with the ZoneHost. The International
  76.     Coordinator is the only true administrative node since he
  77.     is not forced to carry any mail and files of VirNet.
  78.  
  79. 4.1 ZoneHost.
  80.     There is ONE Zonehost only. He can also be a regionhost and
  81.     a nethost. With his own nodenumber, he can have a maximum of
  82.     4 AKA:s as follows: 9:9/0, 9:Country/0, 9:Country+net/0, and
  83.     9:Country+Net/node
  84.     A Zonehost can not be a HUB.
  85.  
  86. 4.2 Regionhost.
  87.     There is ONE Regionhost in every region. He can also be a
  88.     nethost. With his own nodenumber, he can have a maximum of
  89.     3 AKA:s as follows. 9:Country/0, 9:Country+Net/0 and
  90.     9:Country+Net/Node.
  91.     A RegionHost can not be a HUB.
  92.  
  93. 4.3 Nethost.
  94.     There is ONE Nethost in every net. With his own nodenumber,
  95.     he can have a maximum of 2 AKA:s as follows: 9:Country+Net
  96.     and 9:Country+Net/Node.
  97.     A Nethost can not be a HUB - se below.
  98.  
  99. 4.4 HUB.
  100.     There can be several HUB:s in every net. With his own
  101.     nodenumber he can have a maximum of 2 AKA:s as follows:
  102.     9:Country+Net/Hubnode and 9:Country+Net/node.
  103.  
  104.     The Nethost is effeciently treated as HUB 100,
  105.     even though all echo should be adressed to his Nethost
  106.     nodenumber. And if he happens to be the RegionHost all
  107.     echomail should be adressed to his Regionhost nodenumber.
  108.  
  109.     There will be no HUB 100, since that position is held by
  110.     the nethost. The nodes under this 'fictive' HUB 100 will
  111.     export to the nethost's nodenumber, or if the nethost is
  112.     also the regionhost - his regionhostnumber, ie 9:*/0.
  113.  
  114.     It is preferable to number the HUBS in order of hundreds,
  115.     starting from 200, but this is no rule. For instance if
  116.     one HUB is located in a region with a lot of nodes there
  117.     might be reason for skipping the next HUB-number and thus
  118.     efficiently reserve space for another HUB in the same
  119.     area. This is up to the Regionhost to decide. Note that
  120.     all HUB nodes will have a number ending in 00.
  121.  
  122. 4.5 Nodes.
  123.     A nodcan have a maximum of 2 AKA:s as follows:
  124.     9:Country+Net/Hubnode and 9:Country+Net/node.
  125.  
  126.     The Nethost is effeciently treated as HUB 100,
  127.     even though all echo should be adressed to his Nethost
  128.     nodenumber. And if he happens to be the RegionHost all
  129.     echomail should be adressed to his Regionhost nodenumber.
  130.  
  131.     There will be no HUB 100, since that position is held by
  132.     the nethost. The nodes under this 'fictive' HUB 100 will
  133.     export to the nethost's nodenumber, or if the nethost is
  134.     also the regionhost - his regionhostnumber, ie 9:*/0.
  135.  
  136.     It is preferable to number the HUBS in order of hundreds,
  137.     starting from 200, but this is no rule. For instance if
  138.     one HUB is located in a region with a lot of nodes there
  139.     might be reason for skipping the next HUB-number and thus
  140.     efficiently reserve space for another HUB in the same
  141.     area. This is up to the Regionhost to decide. Note that
  142.     all HUB nodes will have a number ending in 00.
  143.  
  144. 4.5 Nodes.
  145.     A node can have a maximum of ONE AKA - his nodenumber.
  146.     One person might have one nodenumber for each of his
  147.     systems - the only requirement is that there has to
  148.     be a mailer on the system. Multiline BBS:es for instance
  149.     can hold as many nodenumbers as there are lines.
  150.  
  151.     EVERY node - regardless of administrative numbers - should
  152.     have it's own nodenumber.
  153.  
  154.     It is prefered that the nodes is given a nodenumber that
  155.     reflects to which HUB they belong. Say a sysop wants a new
  156.     nodenumber and he is located in an area covered by HUB 300,
  157.     then he shall be given the next free number in the 300
  158.     series. This makes netmail routing alot easier to set up for
  159.     the hosts.
  160.  
  161.     Nodenumbers are personal. If one system quits VirNet, that
  162.     nodenumber will be reserved for that node for a full year.
  163.     This is not the case if a system switch to another nodenumber
  164.     due to changing nets and so on.
  165.  
  166.     Nodenumbers are assigned by the Region Host, whome optionally
  167.     mignsibility of the Region Host.
  168.  
  169. 6. Mail and files
  170.  
  171.     The files and mail distributed via VirNet are not to be
  172.     gated to non-VirNet nodes without clearance from both the ZC
  173.     and the IC. If a non-VirNet node wants access to VirNet files
  174.     and/or mail, he has to join VirNet. If a VirNet node is found
  175.     to be exporting files and/or mail, he will be excommunicated
  176.     from VirNet without further notice.
  177.  
  178.     Netmail destined to another node and routed via your system
  179.     is to be regarded as non-existant. That means that you are
  180.     not allowed to forward the message, or the contents of the
  181.     message in any way, to anyone. Treat it as you should always
  182.     do with other peoples mail - don't read it.
  183.  
  184. Keep up the good work! Get new nodes to join Virnet!
  185. Or as we say in Sweden - 'Simma lugnt'... (-:
  186.