- Test - lists.nanog.org

Re: critique of NANOG meeting
by Vincent J. Bono 19 Jun '96

19 Jun '96

Regarding our wonderful Mr. Metcalfe and his article at : http://www.infoworld.com/pageone/opinions/metcalfe/metcalfe.htm On again he has succeeded in generating a structured, well written article, that conjures up the image of a concerned parent shaking his head in dismay over a child that he had great expectations for. Of course, if had even the vaguest idea of what had been going on at NANOG he might feel a bit differently. It was funny, I'll admit, when we found that the projector didn't put out enough lumens to drive the LCD panel, and I know that I chuckled when I learned that there was no packet loss anywhere ;) But hey, if you spend 14 hours a day *every* day dealing with building even a minor backbone like mine, I feel that you kind of earn the right to chuckle. What Andrew, Curtis, Sean and the rest have earned, well, I don't want to inflate egos any more than they already are <grin>. Metcalfe feels that he was wrongly flamed for getting his facts wrong about who moderates NANOG. That isn't the case at all. He was flamed for being an ass and *printing* facts that were wrong. Oh he cited a URL that maybe contained bad info. And if we are not *real* engineers, well, how many *real* journalists don't verify their information with a couple of sources before they print it? Now don't get me wrong. Bob is a *real* engineer in my book. In fact, his article proves it. His petty attention to the bad points of NANOG and his omission of all of the good things that came out of it, well isn't that just what he accused *us* of? Oh sure Peter went off on a tangent during the DX.NET peering piece, but Peter *always* does this and we all would be worried if he didn't. What Mr. Metcalfe missed was the upwards of 50 (my estimate only) direct BGP peering sessions that were arranged at the CAIS party that evening and opened on various NAPs the next Monday. He also missed the fact the the RADB got updated and cleaned by an unprecedented number of ISPs (even if it is too much work for Sprint <grin>). In his years of "wearing a suit", I think Bob has forgotten that it is ultimately the results that count. We argue, whine, and moan, and it's amazing that the GW hall could hold all of the egos that were at NANOG, but after each event, how many bogus routes stop getting injected into the NAPs? How many fragmented announcements get aggregated more efficiently? Even the NIC listens and learns, Guardian is here (sort of). And Bob *has* an Internet to write on and about. Oh well. I spent quite a while designing interfaces that used a technology that Bob basically invented from scratch, and I actually *learned* about Ethernet before uttering my first complaint (well maybe not entirely true). Too bad he didn't pay NANOG (and the respective Internet backbones and NAPs) the same courtesy (I don't see him on the IAB). -vjb

1 0

Re: critique of NANOG meeting
by jbehrle＠noc.bbn.com 19 Jun '96

19 Jun '96

In the spirit of the article someone should have T-shirts made up... A ties could be silk-screened on the front, and the back could have something catchy, like... "Save the Internet, wear a tie..." or "Bob said I could save the Internet, and as it turns out all I got was this stupid tie^H^H^H T-shirt" -Jeremy On Jun 18, 9:01pm, Paul Ferguson wrote: > Subject: Re: critique of NANOG meeting > All-in-all, an entertaining article. :-) > > - paul > > At 04:35 PM 6/18/96 -0700, Michael Dillon wrote: > > > > >I don't know if you folks are following Metcalfe's columns but this week > >the topic is NANOG and he mentions some names. > > > >http://www.infoworld.com/pageone/opinions/metcalfe/metcalfe.htm > > > > > >Michael Dillon ISP & Internet Consulting > >Memra Software Inc. Fax: +1-604-546-3049 > >http://www.memra.com E-mail: michael(a)memra.com > > > > > > > >-- End of excerpt from Paul Ferguson

1 0

critique of NANOG meeting
by Michael Dillon 19 Jun '96

19 Jun '96

I don't know if you folks are following Metcalfe's columns but this week the topic is NANOG and he mentions some names. http://www.infoworld.com/pageone/opinions/metcalfe/metcalfe.htm Michael Dillon ISP & Internet Consulting Memra Software Inc. Fax: +1-604-546-3049 http://www.memra.com E-mail: michael(a)memra.com

2 2

Re: Sprint's route filters and Europe
by jones＠nsipo.arc.nasa.gov 19 Jun '96

19 Jun '96

Cool. Off-shore oil leases bring a tidy sum. Government is trying to emulate private enterprise these days. But careful when you open this box. It could ... argh#$%. Kent is right on. /bill jones, and chargeback afficianado nasa ames research center In referenace to: --- Forwarded mail from "Kent W. England" <kwe(a)6SigmaNets.com> >From nanog-owner(a)merit.edu Tue Jun 18 14:53:21 1996 Return-Path: <nanog-owner(a)merit.edu> Received: Tue, 18 Jun 1996 14:53:19 -0700 (PDT) from merit.edu (RFC1413 sender merit.edu [35.1.1.42]) by nsipo.arc.nasa.gov (8.7.1/1.5) id OAA09938 Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id NAA18345 for nanog-outgoing; Tue, 18 Jun 1996 13:48:51 -0400 (EDT) Received: from mailhub.cts.com (mailhub.cts.com [192.188.72.25]) by merit.edu (8.7.5/merit-2.0) with SMTP id NAA18340 for <nanog(a)merit.edu>; Tue, 18 Jun 1996 13:48:47 -0400 (EDT) Received: from netguru.cts.com(really [204.94.77.43]) by mailhub.cts.com via smail with smtp id <m0uW4sw-000V85C(a)mailhub.cts.com> for <nanog(a)merit.edu>; Tue, 18 Jun 96 10:48:14 -0700 (PDT) (Smail-3.1.92 1996-Mar-19 #3 built 1996-Apr-21) Message-Id: <2.2.32.19960618175326.00725468(a)mail.cts.com> X-Sender: kwe(a)mail.cts.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Jun 1996 10:53:26 -0700 To: gih(a)aarnet.edu.au (Geoff Huston) From: "Kent W. England" <kwe(a)6SigmaNets.com> Subject: Re: Sprint's route filters and Europe Cc: nanog(a)merit.edu Sender: owner-nanog(a)merit.edu Precedence: bulk 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 --- End of forwarded message from "Kent W. England" <kwe(a)6SigmaNets.com>

1 0

Re: critique of NANOG meeting
by Paul Ferguson 19 Jun '96

19 Jun '96

All-in-all, an entertaining article. :-) - paul At 04:35 PM 6/18/96 -0700, Michael Dillon wrote: > >I don't know if you folks are following Metcalfe's columns but this week >the topic is NANOG and he mentions some names. > >http://www.infoworld.com/pageone/opinions/metcalfe/metcalfe.htm > > >Michael Dillon ISP & Internet Consulting >Memra Software Inc. Fax: +1-604-546-3049 >http://www.memra.com E-mail: michael(a)memra.com > > >

1 0

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