- Test - lists.nanog.org

Plans
by johnr＠geo.net 20 Mar '95

20 Mar '95

>If not, you don't have an idea of what your business is going to be >doing. As I said above, you may plan wrong, but you sure as HELL should >have a plan that at least goes a year into the future. > >> No damn way. No ISP in the business can possibly do that and be telling the >> truth. > >I don't appreciate being called a liar, Karl. > >They asked for a PLAN, I supplied a PLAN. > >-abc > > Alan B. Clegg > Information Systems Manager > American Research Group He who fails to plan, plans to fail! Right on Alan! John A. Russo GeoNet Communications, Inc.

2 1

Additions to the NSFNET policy-based routing database
by smm＠twain.merit.edu 20 Mar '95

20 Mar '95

------------------------------------------------------------------------------ The PRDB and this "NWG report" will be retired very soon. Details below. ------------------------------------------------------------------------------ The following changes have been made to the NSFNET policy-based routing database and will be installed on the backbone by 08:00 EST : Total = As + Bs + Cs + Aggs Registered Networks 49445 = 30 5339 40912 3164 Configured Networks 46532 = 30 5282 38120 3100 Added Networks 140 = 0 4 118 18 Deleted Networks 4 = 0 2 1 1 IP address Net name Country Priority:AS ---------- -------- ------- ----------- 135.16/16 NNTEST.ATT.COM C:US 1:2386 2:1321 141.197/16 FLUORDANIEL C:US 1:3561(147) 2:3561(218) 3:3561(27) 4:3561(11) 5:3561(144) 158.51/16 ELECTRO C:CA 1:1240 2:1800 3:1239 165.103/16 NAICNET C:US 1:3561(27) 2:3561(218) 3:3561(147) 4:3561(11) 5:3561(144) 192.54.53/24 BINTEC-LAN C:DE 1:1800 2:1239(144) 3:1133 192.72.2/23 NET-HINET C:TW 1:1800 2:1239(218) 3:1239(144) 4:1321 192.86.154/23 ORACLE C:US 1:3561(11) 2:3561(144) 3:3561(218) 192.102.146/23 FHG-BLOCK-192.102.146 C:DE 1:1800 2:1239(144) 3:1133 192.102.148/22 FHG-BLOCK-192.102.148 C:DE 1:1800 2:1239(144) 3:1133 192.102.152/21 FHG-BLOCK-192.102.152 C:DE 1:1800 2:1239(144) 3:1133 192.102.160/20 FHG-BLOCK-192.102.160 C:DE 1:1800 2:1239(144) 3:1133 192.102.176/23 FHG-BLOCK-192.102.176 C:DE 1:1800 2:1239(144) 3:1133 192.198.151/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.198.152/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.198.153/24 NETBLK-CIS C:US 1:701(136) 2:701(134) 192.223.179/24 NETBLK-FIDELITYI C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 192.233.131/24 MGH-EXT1 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 192.233.132/24 MGH-EXT2 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 193.47.230/24 INFNET C:CH 1:1133 2:1674 3:1800 193.51.174/24 FR-ARCHITECTURE-ROUEN C:FR 1:1800 2:1240 3:1133 4:1674 193.52.202/24 FR-ARNAUD-VILLENEUVE C:FR 1:1800 2:1240 3:1133 4:1674 193.52.218/24 COMINFO-ROUEN C:FR 1:1800 2:1240 3:1133 4:1674 193.52.219/24 ESC-NORMANDIE C:FR 1:1800 2:1240 3:1133 4:1674 193.54.73/24 FR-PALAIS-DECOUVERTE C:FR 1:1800 2:1240 3:1133 4:1674 193.54.74/24 UNISYS-EEMO C:FR 1:1800 2:1240 3:1133 4:1674 193.54.255/24 FR-ENVA C:FR 1:1800 2:1240 3:1133 4:1674 193.55.145/24 FR-ENITIAA C:FR 1:1800 2:1240 3:1133 4:1674 194.8.1/24 LVNET-TEST-C-8-1 C:LV 1:1800 2:1133 3:1240 194.8.2/24 LVNET-TEST-C-8-2 C:LV 1:1800 2:1133 3:1240 194.8.3/24 LVNET-TEST-C-8-3 C:LV 1:1800 2:1133 3:1240 194.8.4/24 LVNET-TEST-C-8-4 C:LV 1:1800 2:1133 3:1240 194.8.16/24 LATTELEKOM-C-8-16 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.17/24 LATTELEKOM-C-8-17 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.18/24 LATTELEKOM-C-8-18 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.19/24 LATTELEKOM-C-8-19 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.20/24 LATTELEKOM-C-8-20 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.21/24 LATTELEKOM-C-8-21 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.22/24 LATTELEKOM-C-8-22 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.23/24 LATTELEKOM-C-8-23 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.24/24 LATTELEKOM-C-8-24 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.25/24 LATTELEKOM-C-8-25 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.26/24 LATTELEKOM-C-8-26 C:LV 1:1800 2:1879 3:1133 4:1240 194.8.27/24 LATTELEKOM-C-8-27 C:LV 1:1800 2:1879 3:1133 4:1240 194.57.125/24 FR-DRCNRS C:FR 1:1800 2:1240 3:1133 4:1674 198.160.164/22 TMCMB C:US 1:701(136) 2:701(134) 198.160.168/23 TMCMB C:US 1:701(136) 2:701(134) 198.168.253/24 FORTRESS-ORG C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 198.176.64/18 TMCMB2 C:US 1:701(136) 2:701(134) 198.180.131/24 BIOGEN C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.43.115/24 UNIVERSAL C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 199.60.222/24 FN-VICTORIA C:CA 1:1331 199.81.21/24 NETBLK-FEDEX101 C:US 1:1330 199.81.23/24 NETBLK-FEDEX101 C:US 1:1330 199.92.18/24 CAMDEN-LIB-ME C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.92.201/24 CALLNET-201 C:US 1:3561(218) 2:3561(11) 3:560 4:701(136) 5:701(134) 199.166.222/24 TERRAPORT-NET C:CA 1:2493(35) 2:2493(91) 199.166.223/24 TERRAPORT-NET C:CA 1:2493(35) 2:2493(91) 199.181.186/24 JJNET C:US 1:3561(218) 2:3561(147) 3:3561(27) 4:3561(11) 5:3561(144) 199.221.224/24 RRNET C:US 1:1323 199.222.29/24 ABQ-NET C:US 1:1334 200.10.212/24 COMCRED-1 C:MX 1:114 2:3561(11) 3:3561(218) 4:278 5:1328 202.6.100/23 ABAC C:TH 1:701(136) 2:701(134) 202.44.144/24 KSCNET-TH C:TH 1:701(136) 2:701(134) 203.250.114/23 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 203.250.116/23 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 203.250.184/21 APNIC-CIDR-BLK C:KR 1:1800 2:1239(144) 204.19.166/24 VARNET C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 204.19.167/24 VARNET C:CA 1:1324(36) 2:1324(32) 3:2493(35) 4:2493(91) 204.86.235/24 LIIK.NET C:US 1:1240 2:1800 3:1239 204.150.132/24 ANS-C-BLOCK3 C:US 1:1325 204.168.158/24 NET-JERICHO C:US 1:1239(218) 2:1800 3:1239(144) 204.168.248/21 NET-MONROE C:US 1:1239(218) 2:1800 3:1239(144) 204.187.49/24 HWC-CA C:CA 1:577(133) 2:577(137) 3:577(143) 4:3561(218) 5:3561(11) 204.236.0/19 MEDIO-NET C:US 1:3561(11) 2:3561(218) 3:685 4:73 5:101 6:1239(144) 7:1239(147) 8:1239(218) 9:1800 204.253.128/22 CONNECT C:US 1:701(136) 2:701(134) 205.136.0/24 CWI-NET-C-136-0 C:US 1:701 2:1239 3:1800 4:1240 205.136.1/24 CWI-NET-C-136-1 C:US 1:701 2:1239 3:1800 4:1240 205.136.2/24 CWI-NET-C-136-2 C:US 1:701 2:1239 3:1800 4:1240 205.136.3/24 CWI-NET-C-136-3 C:US 1:701 2:1239 3:1800 4:1240 205.136.4/24 CWI-NET-C-136-4 C:US 1:701 2:1239 3:1800 4:1240 205.136.5/24 CWI-NET-C-136-5 C:US 1:701 2:1239 3:1800 4:1240 205.136.6/24 CWI-NET-C-136-6 C:US 1:701 2:1239 3:1800 4:1240 205.136.7/24 CWI-NET-C-136-7 C:US 1:701 2:1239 3:1800 4:1240 205.136.8/24 CWI-NET-C-136-8 C:US 1:701 2:1239 3:1800 4:1240 205.136.9/24 CWI-NET-C-136-9 C:US 1:701 2:1239 3:1800 4:1240 205.136.10/24 CWI-NET-C-136-10 C:US 1:701 2:1239 3:1800 4:1240 205.136.11/24 CWI-NET-C-136-11 C:US 1:701 2:1239 3:1800 4:1240 205.136.12/24 CWI-NET-C-136-12 C:US 1:701 2:1239 3:1800 4:1240 205.136.13/24 CWI-NET-C-136-13 C:US 1:701 2:1239 3:1800 4:1240 205.136.14/24 CWI-NET-C-136-14 C:US 1:701 2:1239 3:1800 4:1240 205.136.15/24 CWI-NET-C-136-15 C:US 1:701 2:1239 3:1800 4:1240 205.136.16/24 CWI-NET-C-136-16 C:US 1:701 2:1239 3:1800 4:1240 205.136.17/24 CWI-NET-C-136-17 C:US 1:701 2:1239 3:1800 4:1240 205.136.18/24 CWI-NET-C-136-18 C:US 1:701 2:1239 3:1800 4:1240 205.136.19/24 CWI-NET-C-136-19 C:US 1:701 2:1239 3:1800 4:1240 205.136.20/24 CWI-NET-C-136-20 C:US 1:701 2:1239 3:1800 4:1240 205.136.21/24 CWI-NET-C-136-21 C:US 1:701 2:1239 3:1800 4:1240 205.136.22/24 CWI-NET-C-136-22 C:US 1:701 2:1239 3:1800 4:1240 205.136.23/24 CWI-NET-C-136-23 C:US 1:701 2:1239 3:1800 4:1240 205.136.24/24 CWI-NET-C-136-24 C:US 1:701 2:1239 3:1800 4:1240 205.136.25/24 CWI-NET-C-136-25 C:US 1:701 2:1239 3:1800 4:1240 205.136.26/24 CWI-NET-C-136-26 C:US 1:701 2:1239 3:1800 4:1240 205.136.27/24 CWI-NET-C-136-27 C:US 1:701 2:1239 3:1800 4:1240 205.136.28/24 CWI-NET-C-136-28 C:US 1:701 2:1239 3:1800 4:1240 205.136.29/24 CWI-NET-C-136-29 C:US 1:701 2:1239 3:1800 4:1240 205.136.30/24 CWI-NET-C-136-30 C:US 1:701 2:1239 3:1800 4:1240 205.136.31/24 CWI-NET-C-136-31 C:US 1:701 2:1239 3:1800 4:1240 205.136.32/24 CWI-NET-C-136-32 C:US 1:701 2:1239 3:1800 4:1240 205.136.33/24 CWI-NET-C-136-33 C:US 1:701 2:1239 3:1800 4:1240 205.136.34/24 CWI-NET-C-136-34 C:US 1:701 2:1239 3:1800 4:1240 205.136.35/24 CWI-NET-C-136-35 C:US 1:701 2:1239 3:1800 4:1240 205.136.36/24 CWI-NET-C-136-36 C:US 1:701 2:1239 3:1800 4:1240 205.136.37/24 CWI-NET-C-136-37 C:US 1:701 2:1239 3:1800 4:1240 205.136.38/24 CWI-NET-C-136-38 C:US 1:701 2:1239 3:1800 4:1240 205.136.39/24 CWI-NET-C-136-39 C:US 1:701 2:1239 3:1800 4:1240 205.136.40/24 CWI-NET-C-136-40 C:US 1:701 2:1239 3:1800 4:1240 205.136.41/24 CWI-NET-C-136-41 C:US 1:701 2:1239 3:1800 4:1240 205.136.42/24 CWI-NET-C-136-42 C:US 1:701 2:1239 3:1800 4:1240 205.136.43/24 CWI-NET-C-136-43 C:US 1:701 2:1239 3:1800 4:1240 205.136.44/24 CWI-NET-C-136-44 C:US 1:701 2:1239 3:1800 4:1240 205.136.45/24 CWI-NET-C-136-45 C:US 1:701 2:1239 3:1800 4:1240 205.136.46/24 CWI-NET-C-136-46 C:US 1:701 2:1239 3:1800 4:1240 205.136.47/24 CWI-NET-C-136-47 C:US 1:701 2:1239 3:1800 4:1240 205.136.48/24 CWI-NET-C-136-48 C:US 1:701 2:1239 3:1800 4:1240 205.136.49/24 CWI-NET-C-136-49 C:US 1:701 2:1239 3:1800 4:1240 205.136.50/24 CWI-NET-C-136-50 C:US 1:701 2:1239 3:1800 4:1240 205.136.51/24 CWI-NET-C-136-51 C:US 1:701 2:1239 3:1800 4:1240 205.136.52/24 CWI-NET-C-136-52 C:US 1:701 2:1239 3:1800 4:1240 205.136.53/24 CWI-NET-C-136-53 C:US 1:701 2:1239 3:1800 4:1240 205.136.54/24 CWI-NET-C-136-54 C:US 1:701 2:1239 3:1800 4:1240 205.136.55/24 CWI-NET-C-136-55 C:US 1:701 2:1239 3:1800 4:1240 205.136.56/24 CWI-NET-C-136-56 C:US 1:701 2:1239 3:1800 4:1240 205.136.57/24 CWI-NET-C-136-57 C:US 1:701 2:1239 3:1800 4:1240 205.136.58/24 CWI-NET-C-136-58 C:US 1:701 2:1239 3:1800 4:1240 205.136.59/24 CWI-NET-C-136-59 C:US 1:701 2:1239 3:1800 4:1240 205.136.60/24 CWI-NET-C-136-60 C:US 1:701 2:1239 3:1800 4:1240 205.136.61/24 CWI-NET-C-136-61 C:US 1:701 2:1239 3:1800 4:1240 205.136.62/24 CWI-NET-C-136-62 C:US 1:701 2:1239 3:1800 4:1240 205.136.63/24 CWI-NET-C-136-63 C:US 1:701 2:1239 3:1800 4:1240 205.155/16 NETBLK-CSUNET-NORTH2 C:US 1:3561(11) 2:3561(218) 3:200(128) 4:200(144) 5:2150(135) Deletions: --138.187/16 INFNET-PTT1 C:CH 1:1133 2:1674 3:1800 --138.190/16 INFNET-PTT3 C:CH 1:1133 2:1674 3:1800 --192.122.236/24 CORNELL-DMZ2 C:US 1:26 --199.221.224/19 RRNET-AGG C:US 1:1323 Expanded listing, sorted by country, then by organization: ========================================================== The "Expanded Listings" section of this NWG report has been retired since it is sorted by countries and network organization addresses. The replacement configuration generation system is based on the Internet Routing Registry (briefly called the "Global Routing Registry"). See the file ftp.ra.net:pub/radb/OVERVIEW for more information. The remainder of this report will also be retired shortly. AS690 CIDR Squeezings Report: 11310 Nets, 185 ASs, 3161 Aggregates ------------------------------------------------------------------- 11310 (84%) of the ever-announced more-specific routes within aggregates have been withdrawn. 1303 of those were withdrawn within the last week. 246 the week before that. 374 the week before that. 185 ASs have registered aggregates in the PRDB. 167 of those are announcing aggregates. 91 have withdrawn at least one more specific route. 3161 Aggregates are configured. 2132 of these were Top-Level Aggregates (not nested in another aggregate). 1663 of these are being announced to AS690. 1052 of those have at least one subnet configured (the other 611 may be saving the Internet future subnet announcements). 907 have stopped announcing at least one configured more specific route. 878 have stopped announcing half of their configured more specific routes. 842 have stopped announcing most (80%) of their more specific routes. See home.merit.edu:pub/nsfnet/cidr/cidr_savings for more detail. ----------------------------------------------------------- ========================================================== The configuration reports which reflect today's update will be available for anonymous ftp on nic.merit.edu by 08:00 EST : configuration reports -- nic.merit.edu:nsfnet/announced.networks: as-as.now as-gw.now ans_core.now country.now net-comp.now nets.doc nets.non-classful nets.tag.now nets.unl.now NSS routing software configuration files -- nic.merit.edu:nsfnet/backbone.configuration: gated.nss<NSS number>.t3p Information is also avaiable through the PRDB whois server. Type "whois -h prdb.merit.edu help" for details. -------------------------------------------------------------------------- PRDB CHANGES: (Updated January 19, 1994) As of 1/19/95, ACKs and NAKs will no loger be required (or even read) in the processing of NACRs. In early 1995, as part of the transition to the new Internet Routing Registry (IRR), the Policy Routing Database (PRDB) will be retired. Many of the functions of the PRDB (including generation of router configurations for NSFNET) will be produced based on data from the Global Routing Registry. This change to the NSFNET Backbone service will involve the following changes: - The method for submitting new nets to be routed over AS690 will change. Instead of submitting a NACR to nsfnet-admin(a)merit.edu, you will need to submit a "route template" to auto-dbm(a)ra.net . - Additions and entries to the new registry will be made by the Home AS which creates the route for each net, rather than being submitted by a AS690 peer AS. - Most of the PRDB reports (listed above) will no longer be produced. Equivalent information for most of these reports is available from the global Routing Registry. These are major changes to the system. These changes are being made in order to migrate NSFNET customers and the global user community to a global Internet Routing Registry system, which will be more capable of supporting user needs after the termination of the NSFNET Backbone services in April 1995. For more information, set your web browser to http://www.ra.net/rrinfo.html , or use anonymous ftp to obtain the files "OVERVIEW" and from the directory "ftp.ra.net:pub/radb". Merit would like to minimize the number of problems that this transition may cause you. In order to help us help you through the transition, please send your concerns, your needs, and suggestions on how we can make this happen smoothly to merit-ie(a)merit.edu. The archived discussion list "db-disc(a)merit.edu" also exists for discussion of PRDB and RADB issues. Send a message to "db-disc-request(a)merit.edu" to subscribe. --Dale Johnson (dsj(a)merit.edu) -------------------------------------------------------------------------- Please send all requests for configuration changes to nsfnet-admin(a)merit.edu using the NSFNET configuration forms. The forms are available on-line from the nic.merit.edu machine. Use ftp and the anonymous login to get on the machine. Do a "cd nsfnet/announced.networks" and get the files template.net, template.net.README, template.gate, and template.as. *** Note: As of March 1, 1994, NSFNET AUP NACRs must use the template.net *** (NACR) version 7.1, or the NACR will be returned unprocessed. ******************************* --Stephen McNutt Merit/NSFNET smm(a)merit.edu --Steven J. Richardson Merit/NSFNET sjr(a)merit.edu

1 0

Re: A slight call to order (Re: Internic address allocation policy )
by johnr＠geo.net 20 Mar '95

20 Mar '95

>I know of several >providers who are chopping things up on nybble boundaries (16 hosts/net, or >actually 14 with the subnet zero and broadcast taken out). We are having do to this with our Class B.

1 0

Internet address allocation policy
by Jerry Marsh 20 Mar '95

20 Mar '95

I too am having increasing difficulty getting address from Internic without tons of justification. One small point I would like to make: There is an implicit assumption here that the addresses requested are for immediate use on the Internet. Many State agencies here are moving to TCP/IP based networks. This is as much for interconnectivity among ourselves as anything else. They may initially not even connect to other State agencies, let alone the Internet. That does not reduce their need to have coordinated addresses. The last thing they need to do is deploy a network with bogus addresses and then have to change the addresses when they interconnect with others/Internet. They could request small blocks of "C" themselves, but it makes more sense to me to use sub-block of CIDRs that I manage when they have intent of eventually attaching to the Internet thru us. Jerry Marsh | State of Washington - DIS/TSD - MS 2450 jerrym(a)dis.wa.gov | Olympia, Wa 98504-2450 voice: 360-902-3311

1 0

Re: A slight call to order (Re: Internic address allocation policy ) (fwd)
by karl＠mcs.com 20 Mar '95

20 Mar '95

> From: Brett Watson <bwatson(a)diamond.cary.mci.net> > > It just seems to me that everyone is taking all of this way out > of bounds. The internic is strict and sometimes contradicts > itself, I agree. but all they ask for is a plan, or rather and > *estimate*. Karl, you say you can't possibly guess those > numbers? How do you do business then? You've got to be able to > estimate business and market growth (not bashing you, just don't > understand). > > -brett No, what I'm saying is that it is none of the NIC's concern what my growth plan looks like, or what my business plan looks like. If someone else is willing to turn over a business plan, that's their choice, but IMHO that's really, really stupid. As in possibly suicidally stupid. I would give my left nut (pardon the vernacular) for some of these business plans. They are absolutely golden in terms of their value to a competitor in the areas of the country you do business, and anyone who doesn't understand that really ought to be working for someone else rather than running a company in this, or any other, marketplace. There are all kinds of interesting pieces of information in our business plan, and many of them would be VERY useful to a competitor. For that reason that piece of paper is to be found only in our vault at the bank, and in an encrypted (strongly!) file on a PC in my home. The NIC can have a copy of ours if and when they take out an indeminty bond of about $10M and sign the contracts required by me of anyone who wants a peek at that for any other legitimate business purpose. Until then my answer to that request is "stuff it". I know what's in there, I know how much value it has to a potential or actual competitor, and that information simply will not be allowed to pass out of my control without the strongest of guarantees that it will remain secure. Even our *bank* doesn't have a copy of this document, and that relationship is traditionally one of the strongest between two firms. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 248-8649] | 6 POPs online through Chicago, all 28.8 Fax: [+1 312 248-9865] | Email to "info(a)mcs.net" for more information ISDN: Surf at Smokin' Speed | WWW: http://www.mcs.net, gopher: gopher.mcs.net

1 0

Re: Internic address allocation policy
by Jeff.Ogden＠um.cc.umich.edu 20 Mar '95

20 Mar '95

I didn't think that the RS folks were asking for business plans. I have heard them ask for IP numbering plans or routing plans or other things that give them at least a feel that you will be putting the address to good use. Sounds like the sort of thing I'd want them to ask for. I don't want them to make too much of a judgement on what you submit, other than you seem to know enough to not waste the addresses. -Jeff Ogden Merit/MichNet

1 0

Re: Internic address allocation policy
by Jonathan Heiliger 20 Mar '95

20 Mar '95

On Mar 19, 8:36am, Karl Denninger wrote: > Yet, we were told to go stuff a year ago when we asked for the block, and > instead have had to get four different smaller blocks of space from other > sources. And we are not alone; I am personally involved with another > NATIONAL provider who has been told to stuff more than once by these folks, > and they consume addresses rather more quickly than we do. > > This sucks, and in addition, it is counter-productive. Announcing one > aggregate beats announcing 4. >-- End of excerpt from Karl Denninger I have to agree with Karl & Joe (is this a first? :) Dealing with the InterNIC for address space just takes more time than it should, IMHO. In order to get our address space out of them I had to write over 10 pages of justification and FAXed it to them, after our electronic requests were slammed immediately. This got us 1/4 of the requested space which we're now reaching the limits of only 2months after allocation. I was actually just tossing the idea around of using the RFC 1597 (it's 6am, if I'm wrong, I'm wrong) networks that "shouldn't be announced" to the outside world for parts of our infrastructure. The only downside I can see is that DNS will fail to function on that part of our network. The upside is that an outsider has no chance of directly reaching internal routers. :-) -jh

2 1

FBOI apolpgy
by fboi＠netcom.com 20 Mar '95

20 Mar '95

We apologize for sending you our unsolicitated press release. We carefully screened who received our information. We could not, however, determine proper parties in all cases. Please understand our desire to inform the users of the Internet of our services. Thank You First Bank of Internet

1 0

Re: Internic address allocation policy
by ATM_Feel_the_Power 20 Mar '95

20 Mar '95

Sean, More than a few providers expressed concerns. The people present at that meeting deal with thses and other issues. I think that anything that could impact the operation of the net would be fair game for discussion. Who knows I could be wrong. At any point we are willing to work toward an imeadiate solution. As I said before, we had some of the best minds in the world present at that meeting. If we can't solve the problem shame on us. Joseph On Mon, 20 Mar 1995, Sean Donelan wrote: > >First off this is not about what Karl wants. All NSP's are involved in > >this matter. Karl does not have to prove that NET-99 is valid to the > >Nic. The Nic knows this. Their guidelines are in our opinion and the > >opinions of many outdated. What we were talking about is how to change > >this. Nothing more. Groups like NANOG are where these talks take > >place. > > I sat through the last NANOG meeting this came up. While a few providers > expressed concern about the current guidelines, they offered no hard > evidence of problems at the meeting. Since the mantra of the NANOG > is it is an operations group, not a policy group; in the absence of > any hard evidence of an current operational problem the NANOG didn't > seem to be the correct forum for changing policy guidelines. > > -- > Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > >

1 0

ANNOUNCE:FBOI Opens
by fboi＠netcom.com 20 Mar '95

20 Mar '95

___/\___ _|_()_|_ A N N O U C E M E N T For immediate release: Contact: fboi(a)netcom.com Monday, March 20, 1995 Subject of 'info' for details Direct questions to Vinn K. Beigh The First Bank of Internet, FBOI, is announcing the initiation of transaction processing services for Internet electronic commerce. Purchases over the Internet can now be made without exposing personal credit card information. Vendors can now sell products on the Internet without the restrictions imposed by credit card use. Other Internet purchase procedures require personal credit card information. Those proceedings will be monitored by thousands of people all over the world. Some will attempt to either decode the credit card information or impersonate the customer in future transactions. The alternative to personal credit cards for electronic commerce is based on an FBOI procured Visa (tm) Automated Teller Machine (ATM) card. The card is prepaid, PIN protected, replaceable, disposable, and good at over 200,000 Visa/PLUS (tm) ATMs in 83 countries. The safety of FBOI is ensured because access to ATM funds without possession of both the ATM card and the Personal Identification Number (PIN) is not possible. ATM cards are also better than credit cards because their purchase does not require the personal, financial, and employment background of the consumer. The Visa ATM card is not a credit card. It is cash. The ATM card will be used as a checking account. Using an ATM card allows consumers to set aside dedicated funds for Internet data purchases. It provides a safe, secure way to transfer cash from consumers to producers. In addition, consumers can reclaim their funds at any time using an ATM. A check/invoice procedure is used that consumers will find familiar. The consumer first places an order with a vendor. The consumer then sends to the vendor or FBOI an e-mail 'check' for the purchase of the program/file/data product. The vendor sends FBOI an e-mail 'invoice'. FBOI will reconcile the transaction and send e-mail transaction receipts to both the vendor and customer. Cash will be taken from the customer ATM account and credited to the vendor for later payment. FBOI charges a 5% vendor commission per transaction. Producers of software, information collections, newsletters, graphics, and other data products can use FBOI services for the sale of their products. These vendors can sell their products for prices that would be too low for credit card transactions. Subscription services that charge an up-front fee for one time access to data depositories and services also can participate. Vendors will benefit from a very large consumer base because this global solution works just as well outside the U.S. as within the U.S.. The Visa ATM network is worldwide. Consumers will benefit from a very large vendor base because software produced in non-North American countries can be offered for sale much easier than now. The worldwide producers on the Internet can use FBOI services without the expense of owning or renting a dedicated Internet server or a World-Wide Web site. E-mail is the cheapest and simplest of all Internet services. Large Internet commercial services will soon be starting that provide only for the on-line purchase of catalog products. It will not be possible for the individual producer to sell a data product using those services. Those services will collect the consumers credit card information in advance because of Internet security problems. FBOI transmits no sensitive information over the Internet and prevents forgery and impersonation by using Pretty Good Privacy, PGP (tm), software for all transactions. This freeware provides excellent authentication and anti-alteration security. In addition to the unsecured nature of the Internet, consumers should be hesitant giving out their credit card information to vendors of unknown credibility. Tracking is much harder on the Internet than magazine direct marketing. Also, it is not the same as mail order merchandise since U.S. Postal Service and Federal Trade Commission mail order laws do not apply to the Internet. For high volume, low cost, transactions directly between producers and consumers on the Internet contact FBOI. Further information can be obtained from The First Bank of Internet by sending an e-mail message with the subject "info" to <fboi(a)netcom.com>. Visa is a trademark of Visa International Service Association. PLUS is a trademark of Plus System, Inc. PGP and Pretty Good Privacy are trademarks of Philip Zimmermann. The First Bank of Internet (tm) is not a lending institution. The First Bank of Internet (tm) is not a chartered.

1 0