June 1996 - Test - lists.nanog.org

Re: IP addresses for sale?
by Scott Bradner 18 Jun '96

18 Jun '96

options for charging for IP addresses & routing info will be the main agenda items for a BOF at the IETF meeting - if you have opinions on the topic please show up Scott

1 0

Re: Address allocation stats
by Daniel W. McRobb 18 Jun '96

18 Jun '96

> > I've just updated the graphs for the data through the end of May. > > These'll be the ones I'll be bringing to Montreal and are very > > similar to the ones from LA -- assuming no other changes. > > > > The postscript files can also be copied from: > > ftp://research.ftp.com/pub/cidr/current > > > > If I get a chance this week, I'll also look for a .ps->.gif converter.. > > You've just found one. Me. ;-) > > Seriously, you need GhostScript 2.6.1 with the following > modification to gdevgif.c: > > /* #define TABLE_SIZE 5123 /* this is max for 12-bit codes */ > #define TABLE_SIZE 5119 /* this is max for 12-bit codes (and prime) */ > > 5123 is nice, but not prime, and this will in certain > circumstances produce an infinite CPU-consuming loop. > > Second, uncomment the "30000 VM?" test in the PS files. > > Third you will need the ps-to-gif script (a one-liner in the > shell given the right gs) and the landscape.ps which is available > together with the already converted (gif) files in > > ftp://trane.uninett.no/tmp/pier/ > > Note that a newer version of GhostScript won't do, since they > removed the GIF driver in subsequent versions to 2.6.1 (you > probably know why...). > > Regards, > > - Havard However, newer versions of ghostscript have no problem creating ppm files (if you compile w/ ppm driver), and you can use them along with 'pstogif' to generate GIF files. 'pstogif' is just a perl script that runs gs to generate ppm, then pnmcrop, ppmquant and ppmtogif (from the netpbm package). Also, 'convert' in the ImageMagick package will work as well, and does something similar (i.e. I think you still need ghostscript with ppm). I don't normally use 'convert' for PostScript to GIF conversion though, since I've found it to be a lot slower than 'pstogif'. I don't remember where I got 'pstogif' (maybe the CTAN archive?), so here it is (albeit with my change to use a FIFO to speed things up a bit). Daniel ~~~~~~ #!/usr/local/bin/perl # # pstogif.pl v1.0, July 1994, by Nikos Drakos <nikos(a)cbl.leeds.ac.uk> # Computer Based Learning Unit, University of Leeds. # # Accompanies LaTeX2HTML Version 95 # # Script to convert an arbitrary PostScript image to a cropped GIF image # suitable for incorporation into HTML documents as inlined images to be # viewed with WWW browsers. # # This is based on the pstoepsi script # by Doug Crabill dgc(a)cs.purdue.edu # # Please note the following: # - The source PostScript file must end # in a .ps extention. This is a GhostScript requirement, not mine... # - The -density argument has no effect unless the # color depth (set with the -depth argument) is equal to 1. # - Valid arguments for -depth are 1,8, or 24. # # This software is provided as is without any guarantee. # # Nikos Drakos (ND), nikos(a)cbl.leeds.ac.uk # Computer Based Learning Unit, University of Leeds. # # 20 JUL 94 ND Converted to Perl and made several changes eg it now accepts # parameters from environment variables or from command line or will use # default ones. # # 1 APR 94 ND Changed the suffixes of multi-page files from xbm to gif (oops!) # # ##################################################################### $| =1; &read_args; ### You may need to specify some pathnames here if you want to ### run the script without LaTeX2HTML # Ghostscript $GS= $ENV{'GS'} || 'gs'; # Comes with LaTeX2HTML (For ghostscript versions greater than 3.0 # you need the newer pstoppm.ps) $PSTOPPM= $ENV{'PSTOPPM'} || '/usr/local/lib/ghostscript/pstoppm.ps'; # Available in the PBMPLUS libary $PNMCROP=$ENV{'PNMCROP'} || '/u/dwm/bin/pnmcrop' ; # Also in PBMPPLUS $PPMTOGIF=$ENV{'PPMTOGIF'} || '/u/dwm/bin/ppmtogif' ; # Also in PBMPPLUS $REDUCE_COLOR=$ENV{'PPMQUANT'} || '/u/dwm/bin/ppmquant 256' ; $OUTFILE = $ENV{'OUTFILE'} || $out; # Valid choices for $COLOR_DEPTH are 1, 8 or 24. $DEPTH = $ENV{'DEPTH'} || $depth || 24; #Default density is 72 $DENSITY = $ENV{'DENSITY'} || $density || 72; # Valid choices are any numbers greater than zero # Useful choices are numbers between 0.1 - 5 # Large numbers may generate very large intermediate files # and will take longer to process $SCALE = $ENV{'SCALE'} || $scale; # No default value $PAPERSIZE = $ENV{'PAPERSIZE'} || $papersize; # No default value; $DEBUG = $ENV{'DEBUG'} || $DEBUG || 0; ###################################################################### &main; sub read_args { local($_); while ($ARGV[0] =~ /^-/) { $_ = shift @ARGV; if (/^-h(elp)?$/) { &usage; exit;} elsif (/^-out$/) { $out = shift @ARGV; } elsif (/^-(.*)$/) { eval "\$$1 = shift \@ARGV;"; # Create and set a flag $<name> } } } sub main { local($base, $outfile, $i, $j); $base = &test_args; $outfile = $OUTFILE || "$base.gif"; open(STDERR, ">/dev/null") unless $DEBUG; system("/usr/bin/mkfifo $base.ppm"); &crop_scale_etc("$base.ppm", $outfile); &convert($base); &cleanup($base); } sub crop_scale_etc { local($in, $out) = @_; open(STDERR, ">/dev/null") unless $DEBUG; system("$PNMCROP $in |$REDUCE_COLOR |$PPMTOGIF - > $out &"); print "Writing $out\n"; } sub test_args { local($file) = $ARGV[0]; if (! ($file =~ s/\.ps$//)) { print "The name of the input file must end in '.ps'\n"; exit;} elsif (! ( -f "$file.ps")) { print "Cannot find file $file.ps\n."; exit;} elsif (! ($DEPTH =~ /^(1|8|24)$/)) { print "The color depth must be 1 or 8 or 24. You specified $DEPTH\n"; exit; } if (defined $SCALE) { if ($SCALE > 0) { $DENSITY = int($SCALE * 72);} else { print "Error: The scale must be greater than 0.\n" . "You specified $SCALE\n"; exit;} } $file; } sub convert { local($base) = @_; local($paperopt) = "-sPAPERSIZE=$PAPERSIZE" if $PAPERSIZE; local($ppmtype) = join('', "ppm",$DEPTH,"run"); open (GS, "|$GS -q $paperopt -dNODISPLAY $PSTOPPM -"); print GS "$DENSITY $DENSITY ppmsetdensity\n"; print GS "ppmsetsize2$PAPERSIZE % thanks to wsineric\(a)win.tue.nl (Eric Verbeek)\n" if $PAPERSIZE; print GS "($base) $ppmtype\n"; close GS; } sub cleanup { local($base) = @_; # unlink <$base[0-9.]*ppm>; } sub usage { print "Usage: pstogif [-h(elp)] [-out <output file>] [-depth <color depth 1, 8 or 24>] [-density <pixel density>] <file>.ps\n\n"; }

1 0

A fourth lawsuit against NSI by a domain name owner to try to keep from losing a domain name
by Carl Oppedahl 18 Jun '96

18 Jun '96

There is now a fourth case in which NSI wrote to a domain name owner saying that their domain name would get cut off in 30 days, and in which the domain name owner says it wasn't infringing anybody's trademarks (which is of course no defense under the present NSI policy), and finds itself suing NSI to avert loss of the domain name. First lawsuit - Roadrunner v. NSI background at: http://www.patents.com/nsi.sht complaint at: http://www.patents.com/nsicpt1.sht Second lawsuit - DCI v. DCI and NSI background at: http://www.patents.com/dci/dci.sht complaint at: http://infolawalert.com/source/src061496_dc_complaint.html Third lawsuit - Giacalone v. NSI et al. complaint at: http://zeus.bna.com/e-law/cases/giac.html Fourth lawsuit - Clue Computing v. NSI background at: http://www.clue.com/legal/index.html complaint at: http://www.clue.com/legal/complain.html --- Carl Oppedahl, oppedahl(a)patents.com Oppedahl & Larson, patent law firm http://www.patents.com/ is a web server with frequently asked questions and answers on patent law and other intellectual property subjects

1 0

Re: Sprint's route filters and Europe
by Kent W. England 18 Jun '96

18 Jun '96

At 08:40 PM 6/18/96 +1000, Geoff Huston wrote: >Of course this is not always the case, and typically a public resource distribution >space couples regulation with a tariff to achieve the ultimate outcome of fair >and equitable distribution. The radio spectrum is perhaps the best covered >territory here when looking at this space in relation to the policy debate over >IP address management. > In this debate we have to take care when we talk about charging for registration, whether we are intending to: a) cover the cost of administering a resource (such as .com) b) trying to let a market set prices c) trying to cover the national debt (as with spectrum auctions) Let's just be very sure that if and when fees or prices for addresses are agreed, that someone doesn't step up and claim the right to auction addresses to cover the US budget deficit. There might be a few people in DC that would think to do that. --Kent

2 1

Re: Sprint's route filters and Europe
by Peter Lothberg 18 Jun '96

18 Jun '96

> We charge *everyone* for registration services. That is how it should > be. There is no reason why governments (read: taxpayers) should be > footing the bill. This would be ok if there was a market for registry's. The current Ripe approach seems to build a large byracrazy, with lots and lots of paperworks, so you need more resources to process the paperworks, does not really support the part of the Internet we are where supposed to facilitate. If there is a finite resource that needs to be managed, it should be done in a fair way for all players, and right now i don't think that's not the case if we look at the globe as a whole. Fix the rules, open up more registrys wich all apply the same rules, maybe someone needs to audit the registrys to make sure that things are done correct, and have them compete on speed and effectiveness and cost. --Peter

7 12

Re: Sprint's route filters and Europe
by gih＠aarnet.edu.au 18 Jun '96

18 Jun '96

errrk - do we all really want to engage in this public resource economics discussion here yet for yet another round? Yes we apparently do! fair enuff. Public resource economics differs from normal market distribution economics in that the consideration that charging for a public resource can be an effective tool in ensuring equitable distribution and equitable exploitation opportunity as a premium to the cost of the production and distribution infrastructure associated with the public distribution of the resource. Of course this is not always the case, and typically a public resource distribution space couples regulation with a tariff to achieve the ultimate outcome of fair and equitable distribution. The radio spectrum is perhaps the best covered territory here when looking at this space in relation to the policy debate over IP address management. At the moment we are using the currently unallocated pool of IPV4 address space as the major policy lever here. as long as this pool is viewed as being sufficiently large to accomodate future demand modulo the current allocation practices then this is probably a workable policy application lever (after all that's the only lever we have left!). However a "once and forever" allocation policy of release of space from this pool effectively predicts an inevitable demise of this management mechanism given the nature of the rapacious demand the market is exerting on this resource of the unallocated space. My view is that moderation of the registries' policies to whatever extent we devise is at best a very interim measure which never addresses the nature of the problem in the long run. We are left with a scenario where the IPV4 address space will inevitably be a traded commodity, and the value of the space will be determined by the percieved value of the address modulo issues of routeability, alternative mechanisms of dynamic address translation and the perceived value of deployment of IPv6 as an alternative to securing V4 space. Thanks, Geoff (trying to keep a quite complex subject as short and pithy as possible)

1 0

Re: Sprint's route filters and Europe
by owen＠DeLong.SJ.CA.US 17 Jun '96

17 Jun '96

> >From my (admittedly biased) perspective, it would seem there are two > options: > > A) The socalist approach > B) The capitalist approach > And, generally, I would have to say that for a resource such as IP addresses and Internet registration services, option A is certainly better suited to the task at hand. > Right now, the registries use option A. Addresses are allocated "to > each according to need" and the regional registries that charge (APNIC > and RIPE-NCC) request "from each according to ability" (at least to > some extent). As a result, since the definition of "need" is hard to > pin down, a bureaucracy is created and (since there is no other > acceptible way of verifying needs and/or reducing the address > allocation rate), huge amounts of paperwork and oodles of tedious > forms are necessary to submit requests. > Agreed. There should be an effort to streamline the process while still recognizing that a certain amount of bureaucracy and forms goes with the territory. It would, however, be nice if the various registries could standardize on a user interface and make their modifications behind the scenes. I just received an announcement from the InterNIC that they have completely changed the form yet again. AAAARRRRRGGGGGGHHHH!!! Oh, well, at least this time, I found out _BEFORE_ I submitted something. > Every time someone (who me?) brings up option B, we go chasing merrily > down one or more of the following ratholes: > > 1) we need to conserve route table space, lets charge for that, > not addresses (irrelevant) Not irrelevant. Highly relevant, but not the right solution to that problem either. > 2) AT&T (or some other evil speculator) will buy up all the > address space (and ISPs are just going to sit idly by?) Depending on the situation, it might be difficult for them to do anything effective about it. It is a real danger, and could easily occur. > 3) if you charge, then poor organizations can't connect > to the Internet (so who's paying for their connectivity?) For one thing, I am. I provide free connections to a number of small non-profit organizations that have little or no money. Similarly, ConXioN does the same, and plans to expand the amount of that we do, as we become more profitable. Donating connectivity is easy. Donating NIC fees is significantly less attractive. (Especially in the case of InterNIC, where the level of service is low, the delays high, and the general attitude less than helpful, it is very unpalatable to donate CASH to them). > 4) you can't charge for addresses because they're just > numbers and have no value (tell that to the US Treasury) > Gladly. The IRS opinion that they could "auction off" a domain name as an asset is a clear cut example of the need for strong legislative relief to the contrary. Unfortunately, we are dealing with a government that doesn't even understand people, let alone the network we have built. This government is so backwards that it attempted to regulate content on a federal level for a network that is so thoroughly internation in nature that the concept is absurd. In so doing, it completely ignored the supreme law which it is sworn to uphold, the Constitution for the united States of America. > Regardless of the validity of any of these ratholes, they are missing > the point -- without some OBJECTIVELY VERIFIABLE CRITERIA, the > registries must rely on people being honest and forthright about their > requirements. Money (e.g., a charge per address) has proven to be a > pretty effective objectively verifiable criteria to determine whether > someone *really* needs the address space they are requesting. > Bull. Money has proven to be an effective weapon which allows the larger to smash the smaller. The internet is a great equalizer right now. If you apply this model to it, it will become the next great tool of domination used by large corporations. > However, since option B is theo-politically infeasible for whatever > reason, you get option A, with increasingly draconian rules and ever > growing mountains of paperwork. Life is harsh. > And on a balance, I will opt for the existing system. > >If there is a finite resource that needs to be managed, it should be > >done in a fair way for all players, and right now i don't think > >that's not the case if we look at the globe as a whole. > > What is "fair"? > > Is it fair early adopters have (mutliples of) /8s and will never need > to go through the registry hassle? Is it fair that the current > allocation policies are (statistically speaking) conserving address > space to the benefit of the large ISPs, most of which are in the US? > Would it be fairer if the registries allocated /14s (or /19s) to > everyone regardless of requirements? Should everyone who wants an IP > address be given one, regardless of what they'll use it for? Should > addresses only be given to ISPs? > Yes and no. However, that is certainly more "fair" than retroactively charging them for what they already have. To lease address space to people would require the lessor to "own" the address space. This is not a good solution. Address space cannot be owned. The real solution is to work as rapidly as possible to transform it from a finite resource into an abundant resource. This can be done with a protocol change. The design is already avaialble, and there are reference ports appearing for a multitude of platforms. When this transition is well underway, the issue of "limited" address space will be moot. > The registries try to be "fair", from their perspective. Presumably, > the concern you are expressing here is that the regional registries > have implemented the various policies somewhat differently. I believe > this was a specific goal of RFC 1466 which created the multiple > registries in the first place. The registries are trying to > coordinate policies, but we're somewhat constrained by the different > communities we serve (e.g., what is considered a "small ISP" in the US > is likely to be larger than most of the ISPs in the AP region). > True. However, the definition of small should be relatively irrelevant. Everyone should be treated the same, regardless of size. If you have a need for 8 class C's, then you need a /21. If you need 64, you need a /18. If you need 256, you need a /16. Etc. Number of addresses needed and rate of growth should be the primary parameters used to judge address allocation. Size of the company relative to others is irrelevant. > >Fix the rules, > > Not to pick on you in particular, but I didn't see a lot of comment > from you or other people on the registry guidelines draft. Please > indicate what rules need to be fixed (I have my own set, but I'd like > to see other people's). > I have not read the draft yet, so am unable to comment. > >open up more registrys wich all apply the same rules, > > Applying all the same rules would tend to imply ignoring the > differences in the development in the Internet throughout the world. > Is this what people really want (honest question -- there are > arguments on both sides)? > Why would it imply ignoring the differences? Why can we not come up with a standardized set of rules based on need (current and reasonable projected) which can be applied fairly. Those differences should result in different needs. If the rules are properly written, the differences in input will result in different output and the output will always be appropriate to the input. Realistically, I recognize that it won't be perfect, but I bet we could hit 90% if we tried. Also, and in my opinion more important that a consistent policy structure between registries, is a unified standardized user interface. Figure out what information you want/need from the users and put it all down. Ask for it all, and stabilize the template. Recognize that you are going to have to live with this template for many years to come, and put in place a policy that any errors made in the design of this template are the registries' problem that they are responsible for dealing with. Having a new template design come out of InterNIC every time I go to register a domain is getting really old. > Oh yeah, check out how many bits there are for registries in IPv6... > > >maybe someone needs to audit the registrys to make sure that things > >are done correct, > > Who and who would pay them? > I propose the ISOC and the IANA be jointly responsible for this process, and it should be funded by the fees the registries are collecting. > >and have them compete on speed and effectiveness and cost. > > I think we agree this should be the end goal. How do we get there? > > For those who are interested in this gunk, there will be 2 BOFs at > the Montreal IETF: > > Pricing of Internet Addresses and Route Advertisements (PIARA) > > and > > Internet Registry Evolution (IRE) > > I'm sure both BOFs will be non-controversial and quite sedate. Stop > on by if you want to catch up on your sleep... :-). > > Regards, > -drc > > P.S. So which rathole are we going to go down this time? 30 quatloos > on rathole #4 (it's my favorite 'cause it's so silly (Hi Brian!)). > It's not silly at all. All four of the "ratholes" you mentioned are legitimate issues. Whether you choose to agree or not is a different issue. Owen

3 2

Re: Sprint NAP
by Peter Lothberg 17 Jun '96

17 Jun '96

SPRINT NETWORK ACCESS POINT (NAP) TERMS AND CONDITIONS The following terms and conditions govern Sprint's provision of network connectivity Products and Services ("Products and Services") to _____________________ ("Customer"). Products and Services include equipment, facilities, programming or software provided by Sprint, but do not include certain third party access lines which may be utilized with the Products and Services. If Products and Services are or become subject to a tariff filed with the Federal Communications Commission or any other regulatory institution ("Tariff"), the terms and conditions of such Tariff, including rates, shall govern Customer's use of the Products and Services. Sprint will provide a Type I/II connection to Sprint's Network Access Point ("NAP") in conjunction with NSF Cooperative Agreement No. NCR-9321072. See Attachment A for definitions of Sprint NAP Access Types. To be eligible for connection to the Sprint NAP, the Customer must have the following: o at least one bilateral peering (routing) agreement with another ISP/NSP currently peering at the NAP o 24 x 7 network operations center o the capability to dispatch a customer provided technician to install or replace failed components o a WAN connection into the NAP with an aggregate bandwidth no less than 45 Mbps (DS3) 1. Term The initial one year term ("Initial Term") for Products and Services shall begin on the first day of the month following the date of Sprint's notice of service availability. Upon expiration, the Initial Term shall be automatically extended for successive one (1) year periods ("Term"), unless thirty (30) days prior to the end of the Initial Term or each such extension, either (a)Customer or Sprint provides written notice to the other that it does not want such extension, or (b) Customer executes a new Agreement for Products and Services with a term longer than one (1) year 2. Rates Rates for Products and Services provided hereunder are set forth in Attachment B. Rates are fixed for 90 days after the first day of the Initial Term. Thereafter Sprint will provide sixty (60) days advance written notice of increased rates. In the event of such changes to rates, Customer may terminate the Agreement without termination liability by providing written notice to Sprint no later than thirty (30) days prior to the effective date of such change. Otherwise, Customer will be billed according to the new rates beginning on the effective date of such new rates. 3. Payment Customer agrees to pay all charges incurred beginning on the date of service availability. Recurring charges shall be invoiced monthly in advance and payment in U.S. currency shall be due upon receipt. Interest charges of 1 3/4 percent per month or the highest rate permitted by law, whichever is less, will accrue daily on all amounts not paid within thirty (30) days of the date of the invoice. Customer will pay all sales and use taxes, as well as duties or levies, on Products and Services. The Agreement is subject to Sprint's policies and procedures. 4. Termination To terminate Products and Services, Customer must provide Sprint with thirty (30) days prior written notice. In the event of early termination of any Agreement, Customer will pay a lump sum Termination Charge equal to: (a) one hundred percent (100%) of the monthly price for each Product and Service terminated multiplied by the number of months remaining in the Term. In addition to this Termination Charge, Customer shall pay a pro-rata amount of any waived installation charges based on the number of months remaining in the Initial Term. Customer will not be liable for the Termination Charge if another Sprint product and service of the same or greater monthly price with a term no less than the remaining months in the Term is ordered at the same time as the notice of termination is received. 5. Rights and Obligations of Customer A. Customer shall: (i) at its own expense provide all necessary preparations required to comply with Sprint's installation and maintenance specifications, (ii) be responsible for the costs of relocation of Products and Services once installed, and (iii) provide to Sprint and to suppliers of communications lines reasonable access to Customer's premises to perform any acts required by the Agreement. The Customer shall conform to the Sprint's requirements set forth in Attachment C (Collocated Equipment). B. Customer shall properly use equipment provided by Sprint and shall surrender such equipment to Sprint upon expiration or termination of the Agreement. Customer shall be liable for any and all damages to Products and Services located on Customer's premises excluding reasonable wear and tear, and damages caused by Sprint. C. Customer shall not nor shall it permit or assist others to: (i) use Products and Services for any purpose other than that for which they are intended, (ii) fail to maintain a suitable environment as specified by Sprint, or (iii) alter, tamper with, adjust or repair the Products and Services. Upon the occurrence of any of the above, Sprint shall be completely released from any liability or obligation (including any warranty or indemnity obligation) to Customer relative to the Products and Services; and Customer shall be liable to Sprint for costs or damages incurred by Sprint resulting therefrom. D. Customer shall not nor shall it permit or assist others to abuse or fraudulently use Products and Services, including but not limited to the following: 1. Obtaining or attempting to obtain service by any means or device with intent to avoid payment; or 2. Unauthorized access, alteration, destruction, or any attempt thereof, of any information of another Sprint customer by any means or device; or 3. Using Products and Services in violation of the law or in aid of any unlawful act; or 4. Using Products and Services so as to interfere with the use of the ' Sprint network by other customers or authorized users or in a manner which, in the sole opinion of Sprint, is not in accordance with generally accepted standards of Internet access and use; or 5. Resell or redistribute any portion of the IP address space associated with the NAP. Upon the occurrence of any of the above, Sprint may suspend its performance and/or terminate the Agreement with no further obligation to Customer. 6. Equipment or Software Not Provided by Sprint A. Sprint shall not be responsible for the installation, operation, or maintenance of equipment or software not provided by Sprint; nor shall Sprint be responsible for the transmission or reception of information by such equipment or software. B. Customer shall be responsible for the selection, use and compatibility of equipment or software not provided by Sprint. In the event that such equipment or software impairs Customer's use of the Products and Services, Customer shall nonetheless be liable for payment for Products and Services. Upon notice from Sprint that the equipment or software not provided by Sprint is causing or is likely to cause hazard, interference, or service obstruction Customer shall eliminate such hazard, interference, or service obstruction. Sprint reserves the right to disconnect the Products and Services until such hazard, interference, or service obstruction is corrected. If requested by Customer, Sprint may, at its then-current rates, troubleshoot difficulties caused by equipment or software not provided by Sprint. C. Sprint shall not be responsible if any changes in Products and Services cause equipment or software not provided by Sprint to become obsolete, require modification or alteration, or otherwise affect performance of such equipment or software. D. If Customer provides its own router to interface with the Products and Services, then (i) Customer is fully responsible for the installation, maintenance, and configuration of such Customer-provided router; (ii) Sprint must approve in advance the make, model and/or software revision of a Customer provided router; and (iii) Sprint shall have the right, in cooperation with Customer, to set the initial configuration for the router's interface into the Products and Services. 7. Rights and Obligations of Sprint A. Sprint shall install, operate and maintain the Products and Services as required herein. B. Sprint warrants that Products and Services will be in good working order and will conform to the Sprint's Specifications set forth in Attachment C (Collocated Equipment). Customer's sole remedy for performance or non-performance of Products and Services shall be repair or replacement of the Products and Services. THE FOREGOING WARRANTIES ARE IN LIEU OF ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. C. In no event shall Sprint be liable, either in contract or in tort, for protection from unauthorized access of Customer's transmission facilities or Customer premise equipment; or for unauthorized access to or alteration, theft, or destruction of Customer's data files, programs, procedure, or information through accident, fraudulent means or devices, or any other method, even if Sprint has assisted Customer with access management functionality including, but not limited to, access lists and firewalls. D. Except to the extent caused by the negligence of Sprint, Sprint shall not be liable for claims or damages resulting from or caused by: (i) Customer's fault, negligence or failure to perform Customer's responsibilities; (ii) claims against Customer by any other party (except for claims of copyright or patent infringement as specified herein); (iii) any act or omission of any other party; or (iv) equipment or services furnished by a third party. E. For any claim arising under or related to this Agreement, Customer's damages, if any, shall be limited to those actually proven as directly attributable to Sprint, subject to the following limitation: Sprint will not be liable under any circumstances for any lost profits or other consequential damages, even if Sprint has been advised of the possibility of such damages. Sprint's liability for damages to Customer for any cause whatsoever, regardless of the form of action, and whether in contract or in tort, including negligence, shall be limited to the lesser of $100,000 or the monthly charges paid for the affected Products and Services during the preceding twelve (12) months. F. Upon default by Customer, Sprint may terminate and retake possession of Products and Services (before, during, or after other actions to recover sums hereunder), in which case Customer shall provide Sprint full and free access to Products and Services for this purpose. Sprint's actions above shall not waive Customer's obligation to pay for all charges due Sprint hereunder as well as any other damages Sprint may have sustained because of Customer's default. "Default" shall mean where Customer becomes subject of a voluntary or involuntary bankruptcy, insolvency, reorganization or liquidation proceeding; makes an assignment for the benefit of creditors; admits in writing its inability to pay debts when due; or fails within fourteen (14) days after written notice to remedy any breach of these terms and conditions. 8. Proprietary Rights and Information Protection A. Sprint grants to Customer a non-exclusive and non-transferable license to use programming or software which may be provided with or included in the Products and Services for the sole purpose of enabling Customer to use such Products and Services. B. Title and property rights to Products and Services are and shall remain with Sprint, whether or not embedded in or attached to realty. C. Customer recognizes that Products and Services provided hereunder constitute valuable trade secrets of Sprint or its suppliers. Customer shall protect and keep confidential any programming and software used by Customer which is provided with or included in the Products and Services, and shall make no attempt to examine, copy, alter, reverse engineer, tamper with, or otherwise misuse such programming and software. D. Information that is identified as proprietary to either party which is delivered or disclosed to the other party shall, for a period ending one (1) year from the expiration or termination date of the Agreement, (i) be held in confidence by the receiving party; (ii) be disclosed only to those employees or authorized representatives on a need-to-know basis, and (iii) be used only in fulfillment of the receiving party's obligations under the Agreement. Neither party shall be liable for the disclosure or use of such data or proprietary information which: (a) is, or becomes, publicly known, other than by breach of this Agreement; (b) is obtained by the receiving party form a third party without restriction, (c) is previously known by the receiving party; (d) is, at any time, developed by the receiving party completely independent of any disclosures hereunder; or (e) is required to be released by law. 9. Indemnities A. If promptly notified of any action brought against Customer based on a claim that Sprint provided Products and Services used by Customer infringe a United States patent or copyright, Sprint will defend such action at its expense and will pay any and all fees, costs, or damages that may be finally awarded in such action or resulting settlement. In the event that a final injunction is obtained against Customer prohibiting use of Products and Services by reason of infringement of a United States patent or copyright, Sprint will at its option either: 1. At its expense, procure the right for Customer to continue using the Products and Services; or 2. Procure alternative Products and Services which furnish equivalent functionality; or 3. Direct Customer to return such Products and Services to Sprint. The agreement relating to such returned Products and Services shall terminate. B. Sprint will be indemnified and saved harmless by Customer from and against all loss, liability, damage and expense, including reasonable counsel fees, caused by: 1. Negligent acts or omissions of officers, employees, agents, or contractors of Customer which arise out of or are caused by the construction, installation, maintenance, presence, use or removal of equipment or software not provided by Sprint which are connected or are to be connected to the Products and Services; and which result in claims and demands for damages to property or for injury or death to persons, including payments made under any Worker's Compensation Law or under any plan for employee's disability or death benefits; 2. Any claims arising from information, data, or messages transmitted over the network by Customer including, but not limited to, claims for libel, slander, invasion of privacy, infringement of copyright, and invasion and/or alteration of private records or data; and 3. Claims for infringement of patents arising from the use of equipment and software not provided by Sprint in connection with Products and Services. 10. General A. Customer shall not assign or transfer the Agreement without the prior written consent of Sprint. Sprint may, however, assign the Agreement to its parent company or an affiliate with thirty (30) days notice. B. Sprint will not be responsible for performance of its obligations hereunder where delayed or hindered by war, riots, embargoes, strikes (whether of Sprint or others), casualties, accidents, or other occurrences beyond Sprint's control. Sprint shall notify Customer in the event of any of the foregoing occurrences. Should such occurrence continue for more than sixty (60) days, Sprint or Customer may cancel the affected Products and Services with no further liability. C. The provision of Products and Services hereunder is subject to Sprint's continuing approval of Customer's credit-worthiness. Customer shall furnish financial information as Sprint may from time to time reasonably request to determine Customer's credit-worthiness. D. Any disputes or claims arising out of or related to the Agreement shall be brought within one (1) year of the occurrence. E. These terms and conditions may not be modified except by written amendment by the parties. No agent, employee, or representative of Sprint or Customer has authority to bind the parties to any representation or warranty unless such is specifically included in these terms and conditions, the Agreement, or written amendments thereto. F. Notice to the parties of disputes arising under the Agreement shall be sent by registered mail to the parties to the address shown on the most recent Agreement. All other notices may be sent by regular mail. Notice to Sprint shall be to: Sprint 13221 Woodland Park Rd. Herndon, VA 22071 Attn.: Contract Administration, VAHRNA0608 G. The parties shall attempt to resolve all disputes arising out of or related to this Agreement through good faith negotiations. In the event that the parties cannot reach an agreement, any dispute arising out of or relating to this Agreement will be finally settled by arbitration in accordance with the rules of the American Arbitration Association. The arbitration will be governed by the United States Arbitration Act, 9 U.S.C. Sec. 1, et. seq., and judgment upon the award rendered by the arbitrator(s) may be entered by any court with jurisdiction. The arbitration will be held in the Kansas City, MO metropolitan area. H. The Agreement, including these terms and conditions, shall be construed and enforced in accordance with, and the validity and performance hereof shall be governed by, the laws of the state of Kansas. IN WITNESS WHEREOF, the parties hereto, each by a duly authorized officer, have caused this Agreement to be executed as of the last date written below. SPRINT COMMUNICATIONS COMPANY LIMITED PARTNERSHIP ______________________________ _________________________ Signature Signature ______________________________ _________________________ Name Name ______________________________ _________________________ Title Title ______________________________ _________________________ Date Date Attachment A Sprint NAP Access Types *(pictures in original document omitted)* To promote a variety of access methods Sprint has established two options for customer connectivity to the NAP. These are outlined below. Type I The NSP terminates a WAN connection to an NSP-provided router collocated at the Sprint NAP. This connection type allows the placement of a customer-owned router in the NAP with direct attachment to the NAP LAN via an FDDI interface currently supported by the NAP. The WAN service provider is of the NSP's selection. The minimum transmission rate is DS3. Customer must provide the DS3 CSU/DSU and router interface cable. Sprint will provide the FDDI DAS (dual-attached station) multimode fiber cabling to connect the customer's router to the NAP LAN. Figure 1. Type I NAP Access Method Note: For reasons of space planning and configuration control, each collocated router is permitted to terminate only one (1) serial WAN connection. T here is no limit to the number of WAN connections a customer can bring into the NAP, except that each WAN connection must terminate to a separate router. Separate collocation and NAP attachment fees may apply. Type II The NSP-provided router terminates a network connection using Sprint's ATM User-to-Network Interface (UNI) at the Sprint NAP. This connection type allows the placement of a customer-owned router in the NAP with direct attachment to the LAN via an FDDI interface currently supported by the NAP. Sprint will provide two options for the customer-provided router to connect to the local Sprint ATM switch: Option 1 o Customer provides an ATM CSU/DSU to connect to a HSSI router port provided by the customer. The service demarcation point shall be on the router side of the CSU/DSU. Customer shall also provide the HSSI interface cable to the router. Option 2 o Sprint provides a direct connection to a compatible ATM router interface provided by the customer (e.g., Cisco AIP). The service demarcation point shall be at the end of the multimode fiber cable provided by Sprint. Figure 2. Type II NAP Access Method Note: For reasons of space planning and configuration control, each collocated router is permitted to terminate only one (1) serial WAN connection. There is no limit to the number of WAN connections a customer can bring into the NAP, except that each WAN connection must terminate to a separate router. Separate collocation and NAP attachment fees may apply. Attachment B Products, Services and Prices Except where designated, all charges below are monthly fees. The physical connection can be provided by Sprint or another carrier. Connection Facility Port Total Install Fee Type Fee Fee Monthly NRC ----------------------------------------------------------------------------- TYPE I DS3 $550 $5,200 $5,750 $1,400 TYPE II DS3 $550 $5,200 $5,750 $1,400 Attachment C NAP Collocated Equipment 1. Installation Specifications The Customer is responsible for installing their equipment at the Sprint NAP in accordance with the following specifications: o Equipment must support 120Vac power o Equipment must have rack-mount ears for flush mounting to rack face o Equipment must have manufacturer-supplied cable management brackets o Equipment chassis width must be no more than 17.72 inches o No open chassis slots are permitted (e.g., vacant slots must be covered) In addition, the Customer is responsible for ensuring that the standards by which the equipment is installed are consistent with industry standards and practices. 2. Facility Access The Customer will be granted access into the Sprint NAP facility during normal business hours. Access for emergency repairs only on a 24 x 7 basis are also available. In both cases, prior arrangements must be made by contacting the NAP Manager. The NAP Manager will coordinate customer technician access into the Sprint facility. Sprint will endeavor to accommodate requests for after hours or weekend upgrades to existing equipment. No installation, maintenance or non-emergency repair of equipment after hours or on weekends/holidays will be allowed without prior special arrangements having been made. 3. Specifications of Customer Collocated Equipment The customer is required to submit his desired equipment configuration to the NAP Manager and receive approval before collocation can proceed. Equipment specifications such as chassis dimensions, power requirements, heat dissipation and other pertinent information are required by the NAP Manager so as to ascertain customer equipment rack mounting configuration and bay mounting assignments. NAP Engineering will provide customer with an installation specification document prior to the scheduled installation date at the NAP. 4. Rack Mounting Sprint will provide standard open relay racks, EIA 19-inch mount spacing. (Open relay racks are center mount, standard front mount "ear flaps" will not work.) Chassis dimensions must not exceed 17.72" in width. Sprint will provide UPS-protected 120Vac power for the customer's equipment. 5. Management Port Access If the Customer supplies their own modem(s) for access to their equipment's management port(s), they will need to supply the equipment and to order the necessary dialup circuit(s) for access. The Customer will be responsible for all expenses associated with the use of the business lines. For other remote management requirements, such as private network links, Sprint will cooperate with the Customer. All costs will be born by the Customer. The installed equipment will need to meet the same requirements as those set out here for similar equipment. 6. IP Address Assignment The customer shall receive his IP address assignment(s) from Sprint. Any address(es) provided by Sprint shall remain the property of Sprint and must be relinquished upon customer disconnect of NAP services. Sprint will maintain the INADDR.ARPA DNS space for the NAP. 7. NAP Trouble Reporting /Resolution Procedures The Customer and Sprint will follow the established trouble reporting and resolution procedures described in the Sprint NAP handbook. 8. Demarcation Points TYPE I Demarc: NSP-provided Router The service demarcation point is the FDDI connectors on the Customer-provided router. Sprint will provide two FDDI multimode fiber cables with standard MIC connectors. Although the NAP will support a SAS (single attached station) connection the customer is encouraged, but not required, to use a DAS connection to the NAP. TYPE II Demarc: Sprint ATM Service The service demarcation point is either the router-side of the Sprint-provided ATM CSU/DSU or the customer-end of the multimode fiber cable provided by Sprint. 9. Security While Sprint makes no requirements in the area of security management for NAP clients, it recommends that the Customer develop a policy that addresses the traditional information system security issues of acceptable use, accountability, and incident handling and recovery for their equipment. 10. Access to NAP Premises The Customer and Sprint will follow the established NAP facilities access policy described in the Sprint NAP handbook.

2 1

Address allocation stats
by Paul Ferguson 16 Jun '96

16 Jun '96

Would anyone have a pointer for recent v4 address allocation statistics? I'm aware of the Frank's [solensky(a)ftp.com] presentation material which he talked about in Los Angeles, but I was looking for something a bit more recent, and perhaps HTML'ized. Raw figures welcome. For what its worth, links to Frank's .ps files are located at: http://research.ftp.com/~solensky/cidr.html Thanks, - paul

3 2

The FCC wants you!!!
by Michael Dillon 15 Jun '96

15 Jun '96

If you know American ISP's who don't normally hang out on ISP mailing lists or if you have any contacts in the educational system who are concerned with the cost of technology, then please forward this message to them. Here is the opportunity for direct political action that really can make a difference without requiring well-funded intermediaries and lobbiests... Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com ---------- Forwarded message ---------- Date: Fri, 14 Jun 1996 22:13:01 -0600 (MDT) From: Dave Hughes <dave(a)oldcolo.com> Reply-To: inet-access(a)earth.com To: inet-access(a)earth.com Subject: Re: Accuracies of My Own Resent-Date: Fri, 14 Jun 1996 23:14:53 -0500 (CDT) Resent-From: inet-access(a)earth.com Jack Rickard says: > > In any event, my perception is that Dave is always early to the table, and > by the time the world is ready to buy something, he's already moved on. I > was vaguely aware of his wireless activities, and somewhat more interested > in them with the recent NIIBand proposals. There ARE some issues and I do > hope Dave is successful in steering this toward the 15 km version as > opposed to the limited range Wireless LAN version some of the big guys seem > to be determined to push through. > > In fact, this is actually a rather key issue specifically for Internet > Service Providers and more specifically for those in rural areas. As a > newbie to the mailing list, I may be reintroducing something that has > already been done to death. But this NIIBand could be a huge advantage for > small ISP's in rural areas (not JUST academia and K-12 Dave) if done right, > and another fiasco if done wrong. The FCC has this open for comment now. > If Mr. Hughes would provide info on docket numbers and where to write, you > all could have a significant impact. On the one hand, you can offer 24 > Mbps links by radio at 10-15 km. On the other, 3COM can do wireless LAN > inside a building for about 1000 feet. All from a stroke of the FCC pen. > > Yes, this is a far more significant issue than most ISPs realize - whether the FCC, in both responding to the Apple-WINForum proposal to allocate 350Mhz of spectrum in the 5Ghz bands for what the FCC dubbed the "NII/SUPERNET" Band for 'no licence' wireless - will do that in BOTH the 'wireless lan' segment AS WELL AS the requested '15 km' segments and thus permit anyone, including ISPs to have no-comm cost bandwidth up to 2Mbps between two points, or, with relay, 1Mbps (above and below T-1) for the cost of the radios. Spread spectrum technology which is a revolution in radio communications (wide band, digital processor controlled low power - with no practical interference versus traditional narrow frequency band high power - with so much interferecne, the frquencies have to be licenced and highly controlled). And yes I, and a too-small handful of others are deep into the issues at the FCC level as the decision hangs in the balance. Because I am the Principal Investigator on the $375,700 'Wireless Field Test for Education Project' I was invited to a roundtable with FCC Commissioners nominally debating 'wireless for education' two weeks ago, and, using our real-world wireless project going on in the San Luis Valley (one school being relaibaly connected now 15 miles at 115kbs, bypassing US West, from NT-Lan router to Cisco Router at the POP. Zero local loop cost) and reporting on the other projects we have examined (8 Belen, New Mexico Schools, conected T-1 between each other in a WAN - up to 10 miles across the district. Zero local loop cost (which would normally run $84,000 a year wiht telco T-1 between schools). We made an impression, but know what giant forces we are up against. Some FCC staffers want to 'auction' the longer range (even 15km) stuff. Some big communications companies, led by the Cellular Telecommunications Industry Assn - CTIA, would like all 'no-licence' that can compete with them to be killed. Our arguements, that got a few thinking anyway, was that IF the FCC rules permit radios to be made which go 15-45 miles, no licence, no interference, and solve the problem of the 16,000 school districts whose biggest problem is the cost of bandwidth *between* school building of a district first, then the cost from the main hub to the POP, second, then between the student and/or teacher at home to the school, at 56kbs or above, THEN the problem of 'community' networking will also be solved. For school districts are coincident where people live and log on from. (ditto ISPs) We turned a few heads when I showed my calcuations that, if the 14 School Districts of the SanLuis Valley are connected to the one central POP at T-1 by US West, it will cost $1.2 million over 10 years. If by T-1 25mile radios (yeas they exist now) it will cost $173,000 for the same 10 years. Now if ISPs want to strike a blow for economic telecom freedom, you can start by accessing our NSF Wireless Field Test web site, http://wireless.oldcolo.com and go into the Regulatory section where you will find direct documents, links to the FCC, the Belen Paper, and my long but piercing piece 'The Case for Public Spectrum' (and if you are a skeptic about the technology, read the Paul Baran short papers - the invetor of packet switching) Then all you have to do to sumbit public comments o the NIIBand matter is to email: 96-102(a)fcc.gov and that is the email address for the Docket Item. You *must* comment before July 15th, or yours will not be considered. (but under the law and regulation, if you *do* comment, your comments must be summarized by the staff and presented to the COmmissioners with the staff views. You do NOT have to comment on all the heavy duty technical issues. Right from the chief FCC Engineer who drafts the rules, and was the father of the original Spread Spectrum rules in 1985 he says that your statemnt of what you NEED, and why, would be much appreciated. As simple as 'I am an ISP who needs T-1 from my site, 8 miles to the nearest POP, no licence/cost wirless, with a radio I can afford' is to the point. (of course the more you show your technical economic need in sophisticated terms the better it will be received. The FCC engineers are no dummies and political handwaving doesn't impress them (it only impresses the COmmissioners whenthe handwavers are called AT&T or Congress) I can just about assure you the FCC staff doesn't even know you exist, as a class, (small ISPs) or what function you serve in the food chain, or why you shouldn't just pay $650 a month for your local loop T-1 like anybody else. And unless you email them (and they now have a policy that email must be taken as seriously as formal paper mail filings), your colective case won't even be mentioned when the likes of Motorola, AT&T, CTIA, the NSA (who gets gas pains when secure wireless is mentioned) are testifying. All will not be totally lost if this NPRM does not fly (new spectrum) for we still have the more congested Part 15, 1 watt bands. And the 4 NSF types who attended the FCC rountable were impressed enough with our case that we spent a day with them and they are about to fund a 'developmental' project that will be done by TAPR, that may bring you that $500 T-1 plug and play radio, with range. (by licencing the guts to mfgrs). Matter of fact I will be in Washington DC at the NSF Monday on this (being carrie dby my sidekick in radio engineering matters) and two other matters. One of which will (their idea, not ours) see part of our team in Ulaanbaatar, Mongolia in August, linking 8 sites to the satellite Spintlink downlink site run by Mongolian engineers in an old Soviet lab. (web page at www.magic.mn already - but they can't get the signal across town, so crappy is their phone system). So by September you willbe pinging systems in Mongolia, the last 10km of which will be wireless. I always wanted to help set up the Ghengis Khan BBS in a Mongolian yurt, running OS2 (cause IBM is everywhere), with NAPLPS character sets (Chinese, Cyrilli Russian, and Mongolian - none of which are ascii), solar powered, and with spread spectrum radios linking China to Russia. With nary a Telco in a hundred miles. And I got a hunch I will have that done before ISPs in NYC do it. Dave Hughes dave(a)oldcolo.com Oh yeah, if you http://192.160.122.3 you will reach, by wireless, the OS2 system in my home. Not blazingly fast beacause I am trying out a different set of radios. And teh wired 56kbs frame relay to which it is attached is actuallythe slowest link in the chain. But its been running 160kbs for almost a year now, for $0 cost from me to my own Internet service.

1 0