From jdp at cyberramp.net  Sat Mar  1 00:16:55 1997
From: jdp at cyberramp.net (Janet Pippin)
Date: Fri, 28 Feb 1997 18:16:55 -0600 (CST)
Subject: Note from a tiny node.
In-Reply-To: <199702282356.SAA12770@jekyll.piermont.com> from "Perry E. Metzger" at "Feb 28, 97 06:56:37 pm"
Message-ID: <199703010016.SAA10768@mailhost.cyberramp.net>

I second that!!!

/jdp

Perry E. Metzger wrote:
> 
> Will someone please start moderating this mailing list? Pretty please?
> 
> Perry
> 
> Carol Anne Cypherpunk writes:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > 
> > Greetings from 206.165.50.95!
> > It's snowing here.
> > I'm on a 14th floor.
> > In Minneapolis, Minnesota
> > At 1707 3rd Ave to be precise.
> > You can even know my phone #,
> > all you need is a whois.
> > 
> > I know how many packets were made,
> > how many lookups were caused,
> > how many different traceroutes needed,
> > 
> > to get this message to YOU at your little xxx.xxx.xxx.xxx
> > 
> > No IT WASN'T EASY.
> > 
> > But I do know it can be made simpler.
> > So the average jill or joe can understand it.
> > They will want it that way.
> > Or they will rout around you,
> > for you are causing a bottleneck.
> > 
> > Meanwhile, have a nice weekend,
> > once all the packets are put back together.
> > 
> > Carol Anne Cypherpunk
> > from the mighty 206.165.50.96
> > home of heavily.censored.org!!!
> > 
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: 2.6.2
> > Comment: Uncensored from heavily.censored.org
> > 
> > iQCVAwUBMxdjpIrpjEWs1wBlAQGsFAP/X/i2g/qT49l1GxMQ2ja002LdvKuD7VDy
> > Q5pZc///wUwM376+2wMC2rRf88P/BU8BdS+6kVcIu4uerq2D1SXV0tL9m74d8X5A
> > 4sTgUWjH+TznPW2IjO3pYq0hUBsSyN1BSJm++GoBTK7KWMLpQ5gNfdO+EZ69eWf+
> > KkeS1XF4aHE=
> > =4JOE
> > -----END PGP SIGNATURE-----
> > 
> > Member Internet Society  - Certified BETSI Programmer  -  Webmistress
> > ***********************************************************************
> > Carol Anne Braddock (cab8)  carolann at censored.org   206.165.50.96
> > <a href="http://www.primenet.com/~carolab">My Homepage</a>
> > <a href="http://www.winternet.com/~drozone">The Cyberdoc</a>
> > ***********************************************************************
> > Will lobby Congress for Food & Expenses!!!


-- 
        Janet Pippin           *        CyberRamp Internet Services
   Network Administrator      ***           11350 Hillguard Road
     jdp at cyberramp.net         *         Dallas, Texas  75243-8311
  http://www.cyberramp.net      *      (214) 340-2020  (817) 226-2020




From JimFleming at unety.net  Sat Mar  1 17:56:33 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 1 Mar 1997 11:56:33 -0600
Subject: root update message
Message-ID: <01BC2637.9C9FB3E0@webster.unety.net>


Mr. Jon Postel
University of Southern California
California, USA



Jon,

As I am sure you are aware, TRUE Root Name Servers are intended to
provide stability to the Internet. RFC 2010 has many good ideas about
how to harden these servers. All of the other TRUE Root Name Servers
that I am aware of are following RFC 2010 to the letter. Are the new
servers you describe, 2010 compliant ?

In your note below you point out that these four machines are temporarily
housed at ISI, which I assume means the University of Southern California.
In the U.S. Government's InterNIC file [shown below], it indicates that
two of the machines are at NSI which I assume is Network Solutions, Inc.
Can you be more specific ?

A traceroute to one of the machines goes via LN.NET, an ISP that you run.
The leg before that is via "genuity" where you are on the Board of Directors
of this Bechtel funded company <http://www.genuity.net>. Are LN.NET
or Bechtel involved in this project ?

As more TLD Registries come on line, they will depend on the various
confederations of TRUE Root Name Servers for service. There will be
many reasons why ISPs and companies select the confederation they
use. As long as each confederation refers users to the proper TLD
Name Servers, downstream caching is coherent because the TLD
name servers do most of the real work.

Having said this, I am curious whether you view your NEW Root Name
Servers to be purely for researchers to use or whether you intend
broader use? I note that you mention this is an "experiment". Are
you concerned that ISPs might use these servers and experience
operational integrity problems ? Should ISPs be cautious about that ?
Have you been following the discussions on the NANOG list regarding
some of the problems they have had with the legacy Root Name Servers ?

Since everyone's goal is to make sure the Internet remains
stable and grows in an organized way that does not deny service
to people around the world, I think that actions taken in the
arena of TRUE Root Name Servers need to be done carefully.
As I am sure you are aware, once ISPs adopt certain servers
they rarely change and they follow the U.S. Government's lead.

I also note that you are using the U.S. Government's InterNIC
file distribution system to easily facilitate the wide-spread adoption
of these  "experimental" servers. Can you explain who at the
National Science Foundation (NSF) authorized that action ?

In light of the fact that some mail lists seem to filter information
and some now appear to be deleting postings from their archives.
I am posting this to several groups that I feel will be interested
and involved in these discussions.

Thanks for your time.



Jim Fleming
Unir Corporation


====================
[1]
 4  sprint-nap.WestOrange.mci.net (204.70.1.210)  208.143 ms  220.508 ms  203.63 ms
 5  genuity.sprintnap.net (192.157.69.49)  39.077 ms  25.241 ms  25.688 ms
 6  core1.lax1.genuity.net (207.240.0.5)  86.219 ms  75.991 ms *
 7  mla.ln.net (198.32.146.10)  78.953 ms  73.345 ms  73.039 ms
 8  l.root-servers.net (198.32.64.12)  114.668 ms  111.243 ms *                

[2] On Friday, February 28, 1997 4:44 PM, postel at ISI.EDU wrote:
@ 
@ Hello:
@ 
@ There are now two more root servers root servers serving ".". The names of 
@ these two machines are:
@ 
@   l.root-servers.net 198.32.64.12
@   m.root-servers.net 198.32.65.12
@ 
@ The latest root servers list will be found at:
@   ftp://rs.internic.net/domain/named.ca
@ 
@ Checksum:
@   MD5 (named.ca) c6411a337311264bfb2c3edc7726e19c
@ 
@ These machines are temporarily housed at ISI till their suitable home 
@ is found. All four (j, k, l, & m) will eventually be moved to various 
@ international locations that are "close" to the center of the internet and
@ will only run "." in a non-recursive mode.  This is being done as an 
@ experiment with running "." on separate machines from the existing iTLD's.
@ 
@ ;       This file holds the information on root name servers needed to
@ ;       initialize cache of Internet domain name servers
@ ;       (e.g. reference this file in the "cache  .  <file>"
@ ;       configuration file of BIND domain name servers).
@ ;
@ ;       This file is made available by InterNIC registration services
@ ;       under anonymous FTP as
@ ;           file                /domain/named.root
@ ;           on server           FTP.RS.INTERNIC.NET
@ ;       -OR- under Gopher at    RS.INTERNIC.NET
@ ;           under menu          InterNIC Registration Services (NSI)
@ ;              submenu          InterNIC Registration Archives
@ ;           file                named.root
@ ;
@ ;       last update:    Feb 28, 1997
@ ;       related version of root zone:   1997022800
@ ;
@ ;
@ ; formerly NS.INTERNIC.NET
@ ;
@ .                        3600000  IN  NS    A.ROOT-SERVERS.NET.
@ A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
@ ;
@ ; formerly NS1.ISI.EDU
@ ;
@ .                        3600000      NS    B.ROOT-SERVERS.NET.
@ B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107
@ ;
@ ; formerly C.PSI.NET
@ ;
@ .                        3600000      NS    C.ROOT-SERVERS.NET.
@ C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
@ ;
@ ; formerly TERP.UMD.EDU
@ ;
@ .                        3600000      NS    D.ROOT-SERVERS.NET.
@ D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90
@ ;
@ ; formerly NS.NASA.GOV
@ ;
@ .                        3600000      NS    E.ROOT-SERVERS.NET.
@ E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
@ ;
@ ; formerly NS.ISC.ORG
@ ;
@ .                        3600000      NS    F.ROOT-SERVERS.NET.
@ F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
@ ;
@ ; formerly NS.NIC.DDN.MIL
@ ;
@ .                        3600000      NS    G.ROOT-SERVERS.NET.
@ G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
@ ;
@ ; formerly AOS.ARL.ARMY.MIL
@ ;
@ .                        3600000      NS    H.ROOT-SERVERS.NET.
@ H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53
@ ;
@ ; formerly NIC.NORDU.NET
@ ;
@ .                        3600000      NS    I.ROOT-SERVERS.NET.
@ I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
@ ;
@ ; temporarily housed at NSI (InterNIC)
@ ;
@ .                        3600000      NS    J.ROOT-SERVERS.NET.
@ J.ROOT-SERVERS.NET.      3600000      A     198.41.0.10
@ ;
@ ; temporarily housed at NSI (InterNIC)
@ ;
@ .                        3600000      NS    K.ROOT-SERVERS.NET.
@ K.ROOT-SERVERS.NET.      3600000      A     198.41.0.11
@ ;
@ ; temporarily housed at ISI (IANA)
@ ;
@ .                        3600000      NS    L.ROOT-SERVERS.NET.
@ L.ROOT-SERVERS.NET.      3600000      A     198.32.64.12
@ ;
@ ; temporarily housed at ISI (IANA)
@ ;
@ .                        3600000      NS    M.ROOT-SERVERS.NET.
@ M.ROOT-SERVERS.NET.      3600000      A     198.32.65.12
@ ; End of File
@ 
@ -- 
@ 
@ --jon.
@ 
@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ 
@ 

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From huddle at mci.net  Sun Mar  2 04:33:41 1997
From: huddle at mci.net (Scott Huddle)
Date: Sat, 01 Mar 1997 22:33:41 -0600
Subject: The Big Squeeze
Message-ID: <3.0.32.19970301092544.00d52400@mci.net>

At 07:31 PM 2/26/97 -0600, Karl Denninger wrote:
>As long as a provider can get their own /19 I have no problem with
>prefix filtering at the /19 level.
>
>The problem comes about when big ISPs filter at /19s *AND* the allocators 
>of space refuse to give ISPs /19s.

These two goals seem to be at odds in the current system for
address allocation.  How would you change the system to allow
people to aquire address space that they need and get it 
routed?

The address allocation scheme is geared towards trying to promote
utilization of IP space, thus the sorta "take just what you
need" methodology.

The filters that you talk of seem to me to be crude
proxies for controlling routing space on a particular 
providers network, this seems to me to be a reasonable
thing (i.e. they have to make their network work).  

If different providers were to sell routing "slots"
on their network such that an ISP could guarantee that
their announcements would be accepted (regardless of 
address length) this would seem to solve the problems
of both those that can't "justify" a big block and
those of the providers that want to control the use
of their resources on their network as well.

It appears that you're primary argument is one of 
fairness and level playing field for all comers
regardless of size, and I think this is a worthy
goal if it can be done technically.  

-scott




From cnordin at vni.net  Sun Mar  2 04:13:46 1997
From: cnordin at vni.net (Craig Nordin)
Date: Sat, 1 Mar 1997 23:13:46 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <3.0.32.19970301092544.00d52400@mci.net> from "Scott Huddle" at Mar 1, 97 10:33:41 pm
Message-ID: <199703020413.XAA17360@hq.vni.net>



Shouldn't the big boys (the ones who started all of this filtering)
and the InterNIC be forced to come up with a fairer solution?  At 
least if they don't do so voluntarily?



> 
> At 07:31 PM 2/26/97 -0600, Karl Denninger wrote:
> >As long as a provider can get their own /19 I have no problem with
> >prefix filtering at the /19 level.
> >
> >The problem comes about when big ISPs filter at /19s *AND* the allocators 
> >of space refuse to give ISPs /19s.
> 
> These two goals seem to be at odds in the current system for
> address allocation.  How would you change the system to allow
> people to aquire address space that they need and get it 
> routed?
> 
> The address allocation scheme is geared towards trying to promote
> utilization of IP space, thus the sorta "take just what you
> need" methodology.
> 
> The filters that you talk of seem to me to be crude
> proxies for controlling routing space on a particular 
> providers network, this seems to me to be a reasonable
> thing (i.e. they have to make their network work).  
> 
> If different providers were to sell routing "slots"
> on their network such that an ISP could guarantee that
> their announcements would be accepted (regardless of 
> address length) this would seem to solve the problems
> of both those that can't "justify" a big block and
> those of the providers that want to control the use
> of their resources on their network as well.
> 
> It appears that you're primary argument is one of 
> fairness and level playing field for all comers
> regardless of size, and I think this is a worthy
> goal if it can be done technically.  
> 
> -scott
> 


-- 

Craig Nordin -- cnordin at vni.net  Virtual Networks  http://www.vni.net





From sob at newdev.harvard.edu  Sun Mar  2 04:27:05 1997
From: sob at newdev.harvard.edu (Scott Bradner)
Date: Sat, 1 Mar 1997 23:27:05 -0500 (EST)
Subject: The Big Squeeze
Message-ID: <199703020427.XAA02523@newdev.harvard.edu>

> Shouldn't the big boys ... be forced to come up with a fairer solution?

by who?


Scott




From pjnesser at martigny.ai.mit.edu  Sun Mar  2 04:40:08 1997
From: pjnesser at martigny.ai.mit.edu (Philip J. Nesser II)
Date: Sat, 1 Mar 1997 23:40:08 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703020427.XAA02523@newdev.harvard.edu> from "Scott Bradner" at Mar 1, 97 11:27:05 pm
Message-ID: <199703020440.AA247097610@martigny.ai.mit.edu>

Scott Bradner supposedly said:
> 
> > Shouldn't the big boys ... be forced to come up with a fairer solution?
> 
> by who?
> 
> 
> Scott
> 



More importantly I would like to know who the big boys are.   I would would
really like to meet them someday :-}

--->  Phil




From michael at memra.com  Sun Mar  2 04:40:09 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 1 Mar 1997 20:40:09 -0800 (PST)
Subject: The Big Squeeze
In-Reply-To: <3.0.32.19970301092544.00d52400@mci.net>
Message-ID: <Pine.BSI.3.93.970301201902.342J-100000@sidhe.memra.com>

On Sat, 1 Mar 1997, Scott Huddle wrote:

> If different providers were to sell routing "slots"
> on their network such that an ISP could guarantee that
> their announcements would be accepted (regardless of 
> address length) this would seem to solve the problems
> of both those that can't "justify" a big block and
> those of the providers that want to control the use
> of their resources on their network as well.
> 
> It appears that you're primary argument is one of 
> fairness and level playing field for all comers
> regardless of size, and I think this is a worthy
> goal if it can be done technically.  

I think this is more than a technical problem. It also impacts
relationships (i.e. peering) and it becomes a business issue since
money is changing hands. For this to work a core network provider would
have to do several things.

1. set a fee schedule for routing slots and determine what the conditions
   of sale will be so that every Tom, Dick and Jane doesn't try to
   buy a /24 slot for their PowerMAC webserver with ISDN TA attached.
2. negotiate the peering relationships with at least the other
   core network providers such that they can provide a reasonably
   certain guarantee that the announcements will be accepted by their
   peers. Note that this does *NOT* neccessarily require settlements.
3. set up a feedback loop so that routing table growth does not go crazy.
   IMHO this would need to involve some sort of a quota system whereby
   the group of core network providers who have agreed to listen to
   purchased announcements will also agree how many such slots per month
   can be sold based solely on technical considerations. The sales
   force would then be given an inventory of routing table slots that
   they can sell and when they are gone, they are gone.
4. deal with antitrust issues. Because of the close coordination needed
   by the core network providers to make this work, as soon as prices
   for routing slots stabilize there will be charges of price-fixing. 
   This needs to be dealt with up-front, and IMHO, it is the single
   most important issue because a) failure to do it properly will cause
   severe financial penalties to hit the providers and b) doing it 
   properly will cost significant dollars in lawyers fees.

Also, this becomes an international trade issue. North America covers more
than one country and, as you are all well aware, most major European and
Asian and Australian providers do peer at North American IXP's or are 
planning to do so in the near future.

I wouldn't expect to see any quick solution to this problem but it is
probably a good idea to start looking at the technical and other issues
right now. It looks like the next generation of routers will be upon us
by the middle of the year and the limits on routing table size will be
significantly increased. The question is, what happens next?

Simply loosening up the filters to allow /20's or /21's will not create as
many problems as it solves. People whose equipment cannot handle routing
tables with 80,000 - 90,000 routes will not be happy and their could be
some serious antitrust implications as a result.

The bottom line is that we need to have a consensus on how to take the
next step and this mailing list is probably not the best place to work it
out. The business and legal issues really belong on PIARA. Send

subscribe

to the address piara-request at apnic.net

Note that in the past, PIARA has been focussed on the idea of selling IP
allocations but that idea really never caught on and is basically dead for
now. But the idea of selling routing table slots was never discussed much
on PIARA so there is really no point in reading the list archives. Just
join the list and start posting.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From cnordin at vni.net  Sun Mar  2 04:58:32 1997
From: cnordin at vni.net (Craig Nordin)
Date: Sat, 1 Mar 1997 23:58:32 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703020427.XAA02523@newdev.harvard.edu> from "Scott Bradner" at Mar 1, 97 11:27:05 pm
Message-ID: <199703020458.XAA20990@hq.vni.net>


> > Shouldn't the big boys ... be forced to come up with a fairer solution?

> by who?

An even playing field where those who can only get a few class C addresses
are not excluded from multiple peering points.  I think that this is fairer
to *everyone*.

So far, we have two unilateral decisions by those powerful enough to 
make it stick.  InterNIC protects address space, and Sprint (and others)
protect router memory.

Isn't there a way, if the InterNIC and the larger backbone operators 
cooperated, that organizations having smaller armounts of address space
would not be filtered out?

Or is it technically impossible?








From pjnesser at martigny.ai.mit.edu  Sun Mar  2 06:12:50 1997
From: pjnesser at martigny.ai.mit.edu (Philip J. Nesser II)
Date: Sun, 2 Mar 1997 01:12:50 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703020458.XAA20990@hq.vni.net> from "Craig  Nordin" at Mar 1, 97 11:58:32 pm
Message-ID: <199703020612.AA263733172@martigny.ai.mit.edu>

Craig  Nordin supposedly said:
> 
> 
> > > Shouldn't the big boys ... be forced to come up with a fairer solution?
> 
> > by who?
> 
> An even playing field where those who can only get a few class C addresses
> are not excluded from multiple peering points.  I think that this is fairer
> to *everyone*.
> 
> So far, we have two unilateral decisions by those powerful enough to 

> 

Under current routing protocols, and current router hardware, the current
"wisdom" is that there will be a meltdown somewhere between 60 & 100,000
routes depending on who you ask.   The /19 filtering is basically a defense
mechanism to protect current infrastructure.  

There are a number of vendors who claim equipment either just becoming
available or will be available shortly that can double or triple these
limits.  As to how long such an upgrade will take to hit the major backbone
providers and be field tested,  I would suspect 18 months or so.


--->  Phil




From SEAN at SDG.DRA.COM  Sun Mar  2 06:12:05 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Sun, 2 Mar 1997 0:12:05 -0600 (CST)
Subject: The Big Squeeze
Message-ID: <970302001205.a25a@SDG.DRA.COM>

X-News: sdg.dra.com dra.mail.nanog:7843

>The address allocation scheme is geared towards trying to promote
>utilization of IP space, thus the sorta "take just what you
>need" methodology.
>
>The filters that you talk of seem to me to be crude
>proxies for controlling routing space on a particular 
>providers network, this seems to me to be a reasonable
>thing (i.e. they have to make their network work).  

Except the current allocation practices seem at odds with the
goal of minimizing route table growth.  Why is it better to
allocate several non-agregatable blocks that are 'just' the
right size rather than one aggregatable block the next size
larger?  

So which do providers really want to minimize, the number
of route entries or the size of individual route entries?
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation




From michael at memra.com  Sun Mar  2 06:34:07 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 1 Mar 1997 22:34:07 -0800 (PST)
Subject: The Big Squeeze
In-Reply-To: <199703020458.XAA20990@hq.vni.net>
Message-ID: <Pine.BSI.3.93.970301222325.342O-100000@sidhe.memra.com>

On Sat, 1 Mar 1997, Craig  Nordin wrote:

> > > Shouldn't the big boys ... be forced to come up with a fairer solution?
> > by who?
> 
> An even playing field where those who can only get a few class C addresses
                                                           ^^^^^^^^^^^^^^^^^
No such thing. Or did you mean "... where those with longer prefixes are...)

> are not excluded from multiple peering points.  I think that this is fairer
> to *everyone*.

Check the dictionary definition of the word "peer" as used in Canada, the
USA and Australia, *NOT* Britain. Although the British use of the word
does have some relevance if you understand the history behind the House of
Lords.

> So far, we have two unilateral decisions by those powerful enough to 
> make it stick.  InterNIC protects address space, and Sprint (and others)
> protect router memory.

The Internic hasn't made any unilateral decisions. You might want to check
RFC2050 which can be found at http://www.arin.net in the "Recommended
Reading" section.

> Isn't there a way, if the InterNIC and the larger backbone operators 
> cooperated, that organizations having smaller armounts of address space
> would not be filtered out?

If you simply want to avoid the filters, use address space in your
upstream provider's aggregate.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From kimh at internic.net  Sun Mar  2 06:56:42 1997
From: kimh at internic.net (Kim Hubbard)
Date: Sun, 2 Mar 1997 01:56:42 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <970302001205.a25a@SDG.DRA.COM> from "Sean Donelan" at Mar 2, 97 00:12:05 am
Message-ID: <199703020656.BAA01894@moses.internic.net>

> 
> Except the current allocation practices seem at odds with the
> goal of minimizing route table growth.  Why is it better to
> allocate several non-agregatable blocks that are 'just' the
> right size rather than one aggregatable block the next size
> larger?  

Actually, the current allocation practices do exactly that since
the InterNIC, in almost all cases, allocates blocks of addresses
to ISPs from larger reserved blocks.

Kim Hubbard

 
> 
> So which do providers really want to minimize, the number
> of route entries or the size of individual route entries?
> -- 
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
>   Affiliation given for identification not representation
> 





From paul at vix.com  Sun Mar  2 07:14:32 1997
From: paul at vix.com (Paul A Vixie)
Date: Sat, 01 Mar 1997 23:14:32 -0800
Subject: The Big Squeeze 
Message-ID: <199703020714.XAA22364@wisdom.home.vix.com>

The goal here is a working network.  If every 192.* "C" network that had
been allocated in the long ago were to be advertised tomorrow, that would
add 2**16 routes to the global table and a lot of the net would fall apart.

If every wants-to-be-ISP got a /19, address space wastage would be immense
and we would be into the n>=224 "E" multicast space already, with the end
clearly in sight.  Previously allocated blocks are not reclaimed when an
ISP goes out of business, they usually pass on with the technical folks
and they soon show up as part of some garage-band ISP elsewhere.

Market and technical pressures have established an equilibrium.  It is a
damned shame that a group of people with lots of money and technical savvy
in the data communications field cannot just start up and compete head to
head with more established players, competing on the basis of price and
service levels and so on.  Peering and address space have become barriers
to entry and this has been universally bad in the history of communications.

As the existing players discover the horizon effects on growth, such that
an ISP over a certain size can no longer simply grow in order to add
customers, they will start spinning things off rather than integrating them
vertically.  That's the point where newcomers will next have an opportunity
to enter the market without severe barriers.

It is also dimly possible that ubiquitous ATM, and IPv6, and NIMROD will all
bear fruit and the market will enter a healthier period of total chaos.  For
now the barriers to entry are real, and the people whose participation is
needed for changing them, are too busy growing, buying eachother, and making
tons of money to be bothered levelling out the playing field.  We'd already
be reading about a Consent Decree if the problem weren't so international in
scope.




From michael at memra.com  Sun Mar  2 07:12:58 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 1 Mar 1997 23:12:58 -0800 (PST)
Subject: The Big Squeeze
In-Reply-To: <Pine.BSI.3.93.970301222325.342O-100000@sidhe.memra.com>
Message-ID: <Pine.BSI.3.93.970301231215.342U-100000@sidhe.memra.com>

On Sat, 1 Mar 1997, Michael Dillon wrote:

> The Internic hasn't made any unilateral decisions. You might want to check
> RFC2050 which can be found at http://www.arin.net in the "Recommended
> Reading" section.

Unfortunately, the HTML for that link is wrong. Here is the right place

http://www.internic.net/rfc/rfc2050.txt


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From snpf at netscape.com  Sun Mar  2 11:54:49 1997
From: snpf at netscape.com (Sarah Noelle Pratt Ferguson)
Date: Sun, 2 Mar 1997 03:54:49 -0800 (PST)
Subject: more to add to the list
Message-ID: <199703021154.DAA02137@switchblade.actracorp.com>

Greetings.  

My apologies, I don't know if this is appropriate
or not.  I read vix.com/spam, and didn't see
how to report rogue sites.

I've gotten spam from worldnet.att.com four times in the
last four days.

I've received no response from postmaster, and any mail
I send back to the site says that the mailbox is full,
so the message won't be delivered.

So, in future, how do I report a rogue site?  Should
I simply mail scott mueller?

Have fun.
-s-

> FOR INFORMATION ON BULLETPROOF,  RENEGADE,  
> RESULT ORIENTED MASS ADVERTISING
> CONTACT MREMAIL AT        714-825-4815




From snpf at netscape.com  Sun Mar  2 12:09:30 1997
From: snpf at netscape.com (Sarah Noelle Pratt Ferguson)
Date: Sun, 2 Mar 1997 04:09:30 -0800 (PST)
Subject: oops
Message-ID: <199703021209.EAA02198@switchblade.actracorp.com>


worldnet.att.net is the correct domain.

-s-




From pferguso at cisco.com  Sun Mar  2 15:00:26 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 10:00:26 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302100021.006c5ddc@lint.cisco.com>

At 11:58 PM 3/1/97 -0500, Craig  Nordin wrote:

>
>Isn't there a way, if the InterNIC and the larger backbone operators 
>cooperated, that organizations having smaller armounts of address space
>would not be filtered out?
>
>Or is it technically impossible?
>

This isn't so much an issue of warm-fuzzy technical fairness, more than
it is one of provider (interior) network stability, and when it comes
to the latter, the providers who are filtering on prefix length are
doing so because they feel that it is in their best interest. I would
suggest that the largest percentage of flapping prefixes in the global
routing system belong to prefixes longer than /19.

This is not to say that they could be economical incentivized to
accept routes for arbitrarily long prefixes.

US$.02,

- paul





From nathan at netrail.net  Sun Mar  2 15:09:07 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 2 Mar 1997 10:09:07 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703020413.XAA17360@hq.vni.net>
Message-ID: <Pine.LNX.3.95.970302100029.15813A-100000@netrail.net>

On Sat, 1 Mar 1997, Craig  Nordin wrote:

> Shouldn't the big boys (the ones who started all of this filtering)
> and the InterNIC be forced to come up with a fairer solution?  At 
> least if they don't do so voluntarily?

It is a fair solution, I did not like it. I started a few years ago with a
Sprint T1 and IP space, we then renumbered into some MCI space. After that 
we got some space from the NIC. We then had to renumber that into a larger
block from the nic. When I started I wanted my small amounts of address
space to come from internic, but now that we have a nationwide network and
are connected to 8 NAPs I know why I had to wait.

The internic is not out to get the small guys, and if you get larger they
will give you space. You will just need to get your space from your
transit provider and then if you get big, renumber. I know there are a few
provider out to get the small guys, but most just want to make the net
better. Things like only peering with providers who are connected to all
NSF NAPs and filtering are things they need to do.


Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From nathan at netrail.net  Sun Mar  2 15:15:42 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 2 Mar 1997 10:15:42 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <970302001205.a25a@SDG.DRA.COM>
Message-ID: <Pine.LNX.3.95.970302101046.15813B-100000@netrail.net>

On Sun, 2 Mar 1997, Sean Donelan wrote:

> Except the current allocation practices seem at odds with the
> goal of minimizing route table growth.  Why is it better to
> allocate several non-agregatable blocks that are 'just' the
> right size rather than one aggregatable block the next size
> larger?  

Because a very large number of people who get space from the nic cant cut
it and don't grow. Then the block is fine, or needs to be taken back. It
is not fun to renumber a /19, but it can be done. Yes, this is more work
then a lot of the large backbone providers have to deal with as far as IP
apace, but they have been around longer and went through many other
problems.

> So which do providers really want to minimize, the number
> of route entries or the size of individual route entries?

Number of routes, I know of 2 ISPs that we provided access to that were
mad because the nic gave them /19 and not /18. The providers are now out
of business and there are 2 /19 not being used, but at least they are not
/18. If the provider did get larger the nic would have gladly taken back
the /19 and given them a /18.

Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From randy at psg.com  Sun Mar  2 15:36:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 2 Mar 97 07:36 PST
Subject: The Big Squeeze
References: <3.0.32.19970302100021.006c5ddc@lint.cisco.com>
Message-ID: <m0w1DJK-0007zZC@rip.psg.com>

> I would suggest that the largest percentage of flapping prefixes in the
> global routing system belong to prefixes longer than /19.

Hence the convention to damp differently for different lengths.  See one of
the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we
over here start following the European lead on this.

randy




From pferguso at cisco.com  Sun Mar  2 15:40:04 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 10:40:04 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302104002.006cbf2c@lint.cisco.com>

At 07:36 AM 3/2/97 PST, Randy Bush wrote:

>> I would suggest that the largest percentage of flapping prefixes in the
>> global routing system belong to prefixes longer than /19.
>
>Hence the convention to damp differently for different lengths.  See one of
>the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we
>over here start following the European lead on this.
>

This appears reasonable to me.

- paul

>randy
>
>




From jim at jaguNET.com  Sun Mar  2 15:48:10 1997
From: jim at jaguNET.com (Jim Jagielski)
Date: Sun, 2 Mar 1997 10:48:10 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <Pine.LNX.3.95.970302100029.15813A-100000@netrail.net> from "Nathan Stratton" at Mar 2, 97 10:09:07 am
Message-ID: <199703021548.KAA19048@shado.jaguNET.com>

Nathan Stratton wrote:
> 
> The internic is not out to get the small guys, and if you get larger they
> will give you space. You will just need to get your space from your
> transit provider and then if you get big, renumber.
> 

It's the renumbering part that I think gives people the most
heartburn... By the time you get "big enough" to warrent your
own block, you've got at least 32 ClassCs of which, I'm betting,
at least 28 are "given" to LAN-connected customers. This is
a _major_ headache not only for the ISP to go thru but also a
major headache to force your customers to go thru. That is, what
I think, is what really is most painful; that by the time you
are big enough to have your own block, you're too big to want
to renumber: Catch 22

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim at jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"




From randy at psg.com  Sun Mar  2 15:51:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 2 Mar 97 07:51 PST
Subject: The Big Squeeze
References: <3.0.32.19970302104742.006d59f0@lint.cisco.com>
Message-ID: <m0w1DYL-0007zZC@rip.psg.com>

>>> I would suggest that the largest percentage of flapping prefixes in the
>>> global routing system belong to prefixes longer than /19.
>>
>> Hence the convention to damp differently for different lengths.  See one of
>> the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we
>> over here start following the European lead on this.
> 
> Also, the dampening defaults:
> 
> bgp dampening <halflife-time> <reuse> <suppress> <maximum-suppress-time>
>
> <halflife-time>     default is 15 minutes
> <reuse-value>       default is 750
> <suppress-value>    default is 2000 (I thought it was 1000, but docs indicate
>                     otherwise)
> <max-suppress-time> default 4 times halflife-time

Wellllll.  To be tactless .....

If the ops are heading toward the above-described convention, would it not
be cool if the router vendors made it the default?

randy




From pferguso at cisco.com  Sun Mar  2 15:54:52 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 10:54:52 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302105450.006cbd3c@lint.cisco.com>

At 07:51 AM 3/2/97 PST, Randy Bush wrote:

>
>If the ops are heading toward the above-described convention, would it not
>be cool if the router vendors made it the default?
>

Paradigm shifts can happen anytime. Best to make it user-definable. :-)

- paul





From pferguso at cisco.com  Sun Mar  2 15:47:48 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 10:47:48 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302104742.006d59f0@lint.cisco.com>

At 07:36 AM 3/2/97 PST, Randy Bush wrote:

>> I would suggest that the largest percentage of flapping prefixes in the
>> global routing system belong to prefixes longer than /19.
>
>Hence the convention to damp differently for different lengths.  See one of
>the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we
>over here start following the European lead on this.
>


Also, the dampening defaults:

 bgp dampening <halflife-time> <reuse> <suppress> <maximum-suppress-time>

 <halflife-time>     default is 15 minutes
 <reuse-value>       default is 750
 <suppress-value>    default is 2000 (I thought it was 1000, but docs indicate
                     otherwise)
 <max-suppress-time> default 4 times halflife-time
 
- paul





From pferguso at cisco.com  Sun Mar  2 16:00:17 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 11:00:17 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302110015.006a02a8@lint.cisco.com>

At 10:48 AM 3/2/97 -0500, Jim Jagielski wrote:

>
>It's the renumbering part that I think gives people the most
>heartburn... By the time you get "big enough" to warrent your
>own block, you've got at least 32 ClassCs of which, I'm betting,
>at least 28 are "given" to LAN-connected customers. This is
>a _major_ headache not only for the ISP to go thru but also a
>major headache to force your customers to go thru. That is, what
>I think, is what really is most painful; that by the time you
>are big enough to have your own block, you're too big to want
>to renumber: Catch 22
>

Que sera, sera. Renumbering is a fact of life.

See: RFC1900, RFC2008, RFC2071.

- paul





From randy at psg.com  Sun Mar  2 16:14:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 2 Mar 97 08:14 PST
Subject: The Big Squeeze
References: <3.0.32.19970302105450.006cbd3c@lint.cisco.com>
Message-ID: <m0w1Du8-0007zZC@rip.psg.com>

>> If the ops are heading toward the above-described convention, would it not
>> be cool if the router vendors made it the default?
> Paradigm shifts can happen anytime. Best to make it user-definable. :-)

User-defined paradigm shifts.  I bet that is what the Loony Sociopaths for
Demagoguery (acronym intended) are trying to achieve on a number of these
lists.  I suspect it may require more experienced and rational users.  One
shifts paradgms with experience and consensus, not volume.

randy




From jim at jaguNET.com  Sun Mar  2 16:33:50 1997
From: jim at jaguNET.com (Jim Jagielski)
Date: Sun, 2 Mar 1997 11:33:50 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <3.0.32.19970302110015.006a02a8@lint.cisco.com> from "Paul Ferguson" at Mar 2, 97 11:00:17 am
Message-ID: <199703021633.LAA19873@shado.jaguNET.com>

Paul Ferguson wrote:
> 
> At 10:48 AM 3/2/97 -0500, Jim Jagielski wrote:
> 
> >
> >It's the renumbering part that I think gives people the most
> >heartburn... By the time you get "big enough" to warrent your
> >own block, you've got at least 32 ClassCs of which, I'm betting,
> >at least 28 are "given" to LAN-connected customers. This is
> >a _major_ headache not only for the ISP to go thru but also a
> >major headache to force your customers to go thru. That is, what
> >I think, is what really is most painful; that by the time you
> >are big enough to have your own block, you're too big to want
> >to renumber: Catch 22
> >
> 
> Que sera, sera. Renumbering is a fact of life.
> 
> See: RFC1900, RFC2008, RFC2071.
> 

Never said it wasn't a fact a life, just that it's a painful
one... And a disruptive one. Imagine the heartburn if a group with
simply one ClassB was required to totally renumber to another...

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim at jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"




From pferguso at cisco.com  Sun Mar  2 16:46:58 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 11:46:58 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302114654.006c06b8@lint.cisco.com>

At 11:33 AM 3/2/97 -0500, Jim Jagielski wrote:

>> 
>> Que sera, sera. Renumbering is a fact of life.
>> 
>> See: RFC1900, RFC2008, RFC2071.
>> 
>
>Never said it wasn't a fact a life, just that it's a painful
>one... And a disruptive one. Imagine the heartburn if a group with
>simply one ClassB was required to totally renumber to another...
>

I never meant to imply that it wasn't disliked and painful.

One also might suggest that address portability is very much dependent
on the prefix size and it's ability to aggregated (or not) elsewhere in
the global topology. Having said that, a /16 is generally considered
portable.

- paul





From pferguso at cisco.com  Sun Mar  2 16:44:20 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 11:44:20 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302114418.006c3b40@lint.cisco.com>

At 08:14 AM 3/2/97 PST, Randy Bush wrote:

>User-defined paradigm shifts.  I bet that is what the Loony Sociopaths for
>Demagoguery (acronym intended) are trying to achieve on a number of these
>lists.  I suspect it may require more experienced and rational users.  One
>shifts paradgms with experience and consensus, not volume.
>

'Rational' being the operative word here. ;-)

- paul





From mo at UU.NET  Sun Mar  2 17:09:54 1997
From: mo at UU.NET (Mike O'Dell)
Date: Sun, 2 Mar 1997 12:09:54 -0500 (EST)
Subject: "routing table slots" and the real problem
Message-ID: <QQcfds07529.199703021709@rodan.UU.NET>


Yet again people keep talking about "the size of the routing tables"
as being the deep problem, and this makes people say  silly things
like "FOO is protecting router memory".

Thinking about it this way is funamentally and fatally incorrect.

The REAL problem is the growing complexity of the ROUTING COMPUTATION,
not the size of the resulting forwarding table.  even if routers
had infinite memory, we would still be crushed by the routing
computation if allowed to grow unchecked.

	-mo




From michael at memra.com  Sun Mar  2 17:30:53 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 2 Mar 1997 09:30:53 -0800 (PST)
Subject: The Big Squeeze
In-Reply-To: <199703021633.LAA19873@shado.jaguNET.com>
Message-ID: <Pine.BSI.3.93.970302092733.7039D-100000@sidhe.memra.com>

On Sun, 2 Mar 1997, Jim Jagielski wrote:

> > Que sera, sera. Renumbering is a fact of life.
> > 
> > See: RFC1900, RFC2008, RFC2071.
> 
> Never said it wasn't a fact a life, just that it's a painful
> one... And a disruptive one. Imagine the heartburn if a group with
> simply one ClassB was required to totally renumber to another...

Do you mean a /16 network prefix? This would not be disruptive if the
group would wake up to the facts of life and start renumbering NOW!
Don't wait until your address allocation changes, start working on it
today and make it a part of regular maintenance and administrative
procedures. Deploy DHCP, document where IP numbers are configured,
build and test renumbering scripts, beat on vendors to make it fast, easy
and painless to renumber. 

Renumbering is not an event, it's a state of mind.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From pferguso at cisco.com  Sun Mar  2 17:55:16 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 12:55:16 -0500
Subject: "routing table slots" and the real problem
Message-ID: <3.0.32.19970302125513.0069af8c@lint.cisco.com>

At 12:09 PM 3/2/97 -0500, Mike O'Dell wrote:

>
>The REAL problem is the growing complexity of the ROUTING COMPUTATION,
>not the size of the resulting forwarding table.  even if routers
>had infinite memory, we would still be crushed by the routing
>computation if allowed to grow unchecked.
>

I have always subscribed to this fundamental concept; memory to
accommodate N number of routes has never been an operational
issue. As you have stated, it's the computational resources
required to calculate optimal paths when path information
changes. There is a linear relationship between the number of
paths & routes that must be parsed, and the amount of time it
takes to compute install the best one(s).

- paul





From sob at newdev.harvard.edu  Sun Mar  2 18:33:29 1997
From: sob at newdev.harvard.edu (Scott Bradner)
Date: Sun, 2 Mar 1997 13:33:29 -0500 (EST)
Subject: "routing table slots" and the real problem
Message-ID: <199703021833.NAA03364@newdev.harvard.edu>


Mike says
--
The REAL problem is the growing complexity of the ROUTING COMPUTATION,
not the size of the resulting forwarding table.  even if routers
had infinite memory, we would still be crushed by the routing
computation if allowed to grow unchecked.
--

and the frequency at which the computation must be done

Scott




From perry at piermont.com  Sun Mar  2 18:39:33 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Sun, 02 Mar 1997 13:39:33 -0500
Subject: "routing table slots" and the real problem 
In-Reply-To: Your message of "Sun, 02 Mar 1997 12:09:54 EST."
             <QQcfds07529.199703021709@rodan.UU.NET> 
Message-ID: <199703021839.NAA08043@jekyll.piermont.com>


Mike O'Dell writes:
> Yet again people keep talking about "the size of the routing tables"
> as being the deep problem, and this makes people say  silly things
> like "FOO is protecting router memory".
> 
> Thinking about it this way is funamentally and fatally incorrect.
> 
> The REAL problem is the growing complexity of the ROUTING COMPUTATION,
> not the size of the resulting forwarding table.  even if routers
> had infinite memory, we would still be crushed by the routing
> computation if allowed to grow unchecked.

True enough. Of course, this doesn't mean that we can't have routing
table growth, as we will have processor capacity growth, but it does
mean that the growth of the routing tables must be kept in line with
what the router processors can do.

Perry




From pferguso at cisco.com  Sun Mar  2 18:48:46 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 13:48:46 -0500
Subject: "routing table slots" and the real problem 
Message-ID: <3.0.32.19970302134843.006942ec@lint.cisco.com>

At 01:39 PM 3/2/97 -0500, Perry E. Metzger wrote:

>
>True enough. Of course, this doesn't mean that we can't have routing
>table growth, as we will have processor capacity growth, but it does
>mean that the growth of the routing tables must be kept in line with
>what the router processors can do.
>

True enough. However, it might also be novel to keep the cost
down to a level that people can actually afford.

- paul





From pferguso at cisco.com  Sun Mar  2 18:46:48 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 02 Mar 1997 13:46:48 -0500
Subject: "routing table slots" and the real problem
Message-ID: <3.0.32.19970302134643.006a1c90@lint.cisco.com>

At 01:33 PM 3/2/97 -0500, Scott Bradner wrote:

>
>Mike says
>--
>The REAL problem is the growing complexity of the ROUTING COMPUTATION,
>not the size of the resulting forwarding table.  even if routers
>had infinite memory, we would still be crushed by the routing
>computation if allowed to grow unchecked.
>--
>
>and the frequency at which the computation must be done
>
>Scott
>

Ah, yes. Absolutely.

- paul





From nathan at netrail.net  Sun Mar  2 19:44:47 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 2 Mar 1997 14:44:47 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703021633.LAA19873@shado.jaguNET.com>
Message-ID: <Pine.LNX.3.95.970302144355.21447B-100000@netrail.net>

On Sun, 2 Mar 1997, Jim Jagielski wrote:

> Never said it wasn't a fact a life, just that it's a painful
> one... And a disruptive one. Imagine the heartburn if a group with
> simply one ClassB was required to totally renumber to another...

When I was a contractor for USPS, we had to runumber large chunks of
class A space. Yes it was a MAJOR pain, but we did it.

Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From nathan at netrail.net  Sun Mar  2 19:42:51 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 2 Mar 1997 14:42:51 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <199703021548.KAA19048@shado.jaguNET.com>
Message-ID: <Pine.LNX.3.95.970302144012.21447A-100000@netrail.net>

On Sun, 2 Mar 1997, Jim Jagielski wrote:

> It's the renumbering part that I think gives people the most
> heartburn... By the time you get "big enough" to warrent your
> own block, you've got at least 32 ClassCs of which, I'm betting,
> at least 28 are "given" to LAN-connected customers. This is
> a _major_ headache not only for the ISP to go thru but also a
> major headache to force your customers to go thru. That is, what
> I think, is what really is most painful; that by the time you
> are big enough to have your own block, you're too big to want
> to renumber: Catch 22

Yes, but as a smaller ISP you can offer much better service, and help you
customers renumber. Yes I of all people know it is a _major_ headache, but
it can be done, and there are ways to do it. 

Just because it is a "_major_ headache", is not a good reason to add a
route to the global table, or have the nic give you a bigger block then
you need at that time.



Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From pete at inquo.net  Sun Mar  2 20:04:08 1997
From: pete at inquo.net (Pete Kruckenberg)
Date: Sun, 2 Mar 1997 13:04:08 -0700 (MST)
Subject: The Big Squeeze
In-Reply-To: <Pine.LNX.3.95.970302144012.21447A-100000@netrail.net> from "Nathan Stratton" at Mar 2, 97 02:42:51 pm
Message-ID: <199703022004.NAA15200@inquo.net>

> On Sun, 2 Mar 1997, Jim Jagielski wrote:
> 
> > It's the renumbering part that I think gives people the most
> > heartburn... By the time you get "big enough" to warrent your
> > own block, you've got at least 32 ClassCs of which, I'm betting,
> > at least 28 are "given" to LAN-connected customers. This is
> > a _major_ headache not only for the ISP to go thru but also a
> > major headache to force your customers to go thru. That is, what
> > I think, is what really is most painful; that by the time you
> > are big enough to have your own block, you're too big to want
> > to renumber: Catch 22
> 
> Yes, but as a smaller ISP you can offer much better service, and help you
> customers renumber. Yes I of all people know it is a _major_ headache, but
> it can be done, and there are ways to do it. 

I think there are some technologies available now that would drastically
reduce this headache, as well as strech out a block of assigned addresses.

For example, what about offering DHCP/BOOTP service for your customers? 
You provide a common DHCP/BOOTP server for your customers, configure their
routers to forward DHCP/BOOTP packets. It makes configuration for them a
whole lot easier and more standard (with almost every platform), plus you
can assign them a block based on what they actually need *at the moment*.
Should they need a larger block in the future, or should you renumber,
just reconfigure the DHCP/BOOTP server and their router, and you're done.

NAT is also a cool technology for this type of thing. Only assign real IP
addresses to machines that provide IP services. Put everything else on
10.0.0.0/8 (or something else that won't conflict with real addresses).
There are few reasons (if any) why the client side of the Internet would
not work with NAT. Then, you can dynamically adjust your NAT pool of real
addresses based on how many are actually needed for real usage. Plus, a
renumber of every single client is a matter of adjusting your NAT tables,
and having them renumber whatever Web/FTP/IP-service machines they have. 

There are probably other cool ways to reduce the headache of IP
management, but these are a few I thought the group might be interested
in.

Pete Kruckenberg
inQuo Internet Services
pete at inquo.net






From jim at jaguNET.com  Sun Mar  2 20:15:57 1997
From: jim at jaguNET.com (Jim Jagielski)
Date: Sun, 2 Mar 1997 15:15:57 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <Pine.LNX.3.95.970302144012.21447A-100000@netrail.net> from "Nathan Stratton" at Mar 2, 97 02:42:51 pm
Message-ID: <199703022015.PAA23914@shado.jaguNET.com>

Nathan Stratton wrote:
> 
> On Sun, 2 Mar 1997, Jim Jagielski wrote:
> 
> > It's the renumbering part that I think gives people the most
> > heartburn... By the time you get "big enough" to warrent your
> > own block, you've got at least 32 ClassCs of which, I'm betting,
> > at least 28 are "given" to LAN-connected customers. This is
> > a _major_ headache not only for the ISP to go thru but also a
> > major headache to force your customers to go thru. That is, what
> > I think, is what really is most painful; that by the time you
> > are big enough to have your own block, you're too big to want
> > to renumber: Catch 22
> 
> Yes, but as a smaller ISP you can offer much better service, and help you
> customers renumber. Yes I of all people know it is a _major_ headache, but
> it can be done, and there are ways to do it. 
> 
> Just because it is a "_major_ headache", is not a good reason to add a
> route to the global table, or have the nic give you a bigger block then
> you need at that time.
> 

Oh I agree... It's just that I know of more than a few ISPs
who have done things like keep their current NSP, but with
something like a 56k line (so they don't have to renumber) and
then get a bigger pipe from somebody else and just use BGP to
make everything work... 

-- 
====================================================================
      Jim Jagielski            |       jaguNET Access Services
     jim at jaguNET.com           |       http://www.jaguNET.com/
                  "Not the Craw... the CRAW!"




From freedman at netaxs.com  Sun Mar  2 20:19:30 1997
From: freedman at netaxs.com (Avi Freedman)
Date: Sun, 2 Mar 1997 15:19:30 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <Pine.LNX.3.95.970302144012.21447A-100000@netrail.net> from "Nathan Stratton" at Mar 2, 97 02:42:51 pm
Message-ID: <199703022019.PAA05416@access.netaxs.com>

> Yes, but as a smaller ISP you can offer much better service, and help you
> customers renumber. Yes I of all people know it is a _major_ headache, but
> it can be done, and there are ways to do it. 
> 
> Just because it is a "_major_ headache", is not a good reason to add a
> route to the global table, or have the nic give you a bigger block then
> you need at that time.

Look.  I think Kim's point is true.  They *do* allocate more space
*than* you actually need so that when you need it, you can actually
get it *then*.

If you're growing fast enough, you'll have to renumber *once*.
If you choose poorly your upstream providers, you'll have to
renumber more than once.

> Nathan Stratton                                President, NetRail,Inc.

Avi





From paul at vix.com  Sun Mar  2 20:39:28 1997
From: paul at vix.com (Paul A Vixie)
Date: Sun, 02 Mar 1997 12:39:28 -0800
Subject: more to add to the list 
In-Reply-To: Your message of "Sun, 02 Mar 1997 03:54:49 PST."
             <199703021154.DAA02137@switchblade.actracorp.com> 
Message-ID: <199703022039.MAA21278@wisdom.home.vix.com>

> My apologies, I don't know if this is appropriate
> or not.  I read vix.com/spam, and didn't see
> how to report rogue sites.

For now you just mail to scott at zorch.sf-bay.org.  I'll recommend to him
that he set up a more permanent reporting address -- we registered the
abuse.net domain just for this kind of thing, but it's not being used
much yet.

> I've gotten spam from worldnet.att.com four times in the last four days.

Worldnet doesn't run Sendmail, which makes it harder for them to just
upgrade to 8.8.5 (or even 8.8.4) and then to implement the recommendations
in http://www.sendmail.org/antispam.html.  However, they are working hard
on turning off outside-to-outside relay support, which unfortunately happens
to be an automated feature of most SMTP server software.  Unofficial reports
suggest that some time in mid-March they will be out of the spam relay biz.

Note that in spite of this, I have blackholed their main mail server.  I was
getting 10 spams a day through them at one point.  I guess the spammers
figured that Worldnet was to big to block.  (I guess they were wrong.)

> I've received no response from postmaster, and any mail
> I send back to the site says that the mailbox is full,
> so the message won't be delivered.

Indeed.  They're aware of the problem, their mailbox is full of other
complaints.

> So, in future, how do I report a rogue site?  Should
> I simply mail scott mueller?

For now, yes.  It'll probably show up as report at abuse.net soon, though.

NANOG is not the right place to discuss this.  See the usenet newsgroups
related to network abuse.




From huddle at mci.net  Sun Mar  2 22:03:36 1997
From: huddle at mci.net (Scott Huddle)
Date: Sun, 02 Mar 1997 16:03:36 -0600
Subject: The real problem
Message-ID: <3.0.32.19970302152102.00e9354c@mci.net>

Mike,

If I follow your observation, routing computation growth is
non-linearly related to number of routes.  Or is it
orthogonal?  If the growth is related to the announcement,
this infers that costs incurred for the announcement of routes by 
ISP FOO to ISP BAR would be non-linear with the quantity,
correct?  

If those costs are non-zero, then BAR needs to be compensated
by FOO for the announcement.  One way for BAR to recoup its 
costs would be for it to collect a payment from FOO.  Thus
FOO "buys" a routing slot from BAR.  From your observation, 
these payments may be non-linear related to quantity.  Note
that BAR may owe a similar payment to FOO for consumption
of the same resources on FOO's network.  Without the payments  
you have market failure -- consumption of the resource
is unchecked ("tragedy of the commons") and people who "want" 
or "need" to make a route announcement, and who *could pay*
for the resources that they consume, cannot do so.  

Thus the REAL problem is that we don't have markets for
the determination and allocation of these scarce resources
whether you call them "routing slots" or "routing complexity".

Redirected to piara.

-scott


At 12:09 PM 3/2/97 -0500, Mike O'Dell wrote:
>
>Yet again people keep talking about "the size of the routing tables"
>as being the deep problem, and this makes people say  silly things
>like "FOO is protecting router memory".
>
>Thinking about it this way is funamentally and fatally incorrect.
>
>The REAL problem is the growing complexity of the ROUTING COMPUTATION,
>not the size of the resulting forwarding table.  even if routers
>had infinite memory, we would still be crushed by the routing
>computation if allowed to grow unchecked.
>
>	-mo
>
>




From huddle at mci.net  Sun Mar  2 22:03:38 1997
From: huddle at mci.net (Scott Huddle)
Date: Sun, 02 Mar 1997 16:03:38 -0600
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302153243.00e93ebc@mci.net>

At 10:00 AM 3/2/97 -0500, Paul Ferguson wrote:
>This is not to say that [ISPs] could be economical incentivized to
>accept routes for arbitrarily long prefixes.

I'll assert that if the costs of accepting a route announcement are
non-zero that this can only happen if there is a market for
announcements and a system of settlements between providers.

If the costs are zero, then why have the filters?  

Redirected to piara.

-scott
 




From mo at UU.NET  Sun Mar  2 22:16:22 1997
From: mo at UU.NET (Mike O'Dell)
Date: Sun, 02 Mar 1997 17:16:22 -0500
Subject: "routing table slots" and the real problem 
In-Reply-To: Your message of "Sun, 02 Mar 1997 13:39:33 EST."
             <199703021839.NAA08043@jekyll.piermont.com> 
Message-ID: <QQcfen16766.199703022216@rodan.UU.NET>


processors can't be relied upon to solve the problem.  
the computational cost grows faster than Moore's law

managing the complexity of the graph is the only alternative,
and generally the only way to manage tne complexity is through
aggregation.  at the moment, the only way to manage aggregation
is through address assignment.  whether we have other alternatives
over time is an open question.

	-mo




From jtk at titania.net  Sun Mar  2 13:25:09 1997
From: jtk at titania.net (Joseph T. Klein)
Date: Sun,  2 Mar 97 13:25:09    
Subject: "routing table slots" and the real problem 
References: <3.0.32.19970302134843.006942ec@lint.cisco.com> 
Message-ID: <Chameleon.857340708.jtk@monet.titania.net>

Warning -- I feel a diatribe emerging. ;-)

Afordability is primarily a question of how large your existing
base of legacy routers is and your cash flow.

You can build a box using a free versionof Unix (FreeBSD, NetBSD,
Linux, or whatever your religion of the day), off the shelf
hardware, and gated to route a full backbone routing table
(memory and CPU are cheap) for less than $3K. This is less
than the cost of a single interface card for a Cisco 7xxx!

Kids; do not try this at your gateway without adult supervision.
:-)

We are re-designing the Internet to make up for the fact the 
largest manufacturers of routers has been slow to develop and
deploy systems that can keep up with the growth curve. A lot of
this comes down to size of the memory bus on low cost systems.

If port density was not so poor on general purpose hardware, we
would have been far better off deploying "open systems" for routers
rather than what exists today.

I have always liked my Ciscos, but I truly love routing with my Unix
systems running gated. ... now If I could find some cheap channelized
DS-3 cards for a DEC AlphaStation 500. ;-)

I may be talking out of my hat here, but I suspect a DEC AlphaStation
500 with 256M of RAM ranks pretty well against a 75xx.

Somebody, dig up the stats for me ...

If router manufacturers worked on hardware and all used an open
software standard ... such as gated ... we would all be better off.
Open standards allow all of us to benefit from the work of others.
The old Unix Guru's mantra is 'build on the works of others.'

Let us not make the mistakes of the 1890s and associate domination
of the market by oligopolies as good capitalism. Big corporations,
like big government, tend to move slowly.

Open markets NOT dominated by a single large player is GOOD
capitalism. It increases the pace of innovation and prevents
price fixing. It makes for a healthy, dynamic, marketplace.

This holds true for routers, backbone providers, toasters
and operating systems (sorry Bill)

open standards = open markets

Open standards prevent the failures of a single market
player from inhibiting the growth of the industry.

Open standards lower the cost to upgrade large installed
systems.

Reductions in the federal budget are squeezing R&D expenditures in
the US to an all time low. Large corporate downsizing and corporate
mergers have done the same for most large corporations. The bulk
of innovation in the US will come from small companies and
development consortiums.

It is from these that the next generations of routers will
come. Open standards make the rapid utilization of new
technologies possible and fuel the growth of small companies.

The Internet is a great place for consorting on standards.
This is what is cool about the IETF!

Standards do not keep the big boys from playing ...
Cisco and Bay could easily join in an open standard
for router software. It would not be hard to have interoperability
between the IP portions of IOS and gated.

IOS is the PL-1 of routers. Bay's management reminds me of CICS. ;-)

Back to the subject ...

You CAN also use the RA (where available) to reduce your routing
overhead, save memory and reduce CPU usage. (The RA runs a hacked
version of gated that calculates large routing tables quite well.)

Hmm ...

router $100,000 amortized over 3 years =  2,800/month
going DS-3 price at a NAP with line    =  7,000/month
engineer $70,000 per year min.         =  5,900/month
overhead for a small company           = 20,000/month

$50+/month/mile for OC-3 lines ... don't even talk about
local loop costs!

Routers connect customers.
customers = cash flow.

The highest cost of running a national network is not buying routers,
it is bandwidth, staff, and administrative overhead.

Router cost is primarily a factor for smaller networks with limited
cash flow.

I contend ...

It is the ISPs who try to be dual homed with 'routing tricks' rather
than using edge routers that can process a core routing table, who
contribute most to routing instability.

Boardwatch stated that 14% of ISPs are dual homed. I would bet
that 70% of those do not use routers capable of processing a core
routing table.

Anybody have any stats?

We need cheap routers that run BGP4 and can eat a core routing table.
2501s just don't hack it in dual homed configurations ... and most
small guys just don't wish to blow $50,000 on putting 7505s at the
edges of their networks.


--- On Sun, 02 Mar 1997 13:48:46 -0500  Paul Ferguson <pferguso at cisco.com> wrote:
> At 01:39 PM 3/2/97 -0500, Perry E. Metzger wrote:
> 
> >
> >True enough. Of course, this doesn't mean that we can't have routing
> >table growth, as we will have processor capacity growth, but it does
> >mean that the growth of the routing tables must be kept in line with
> >what the router processors can do.
> >
> 
> True enough. However, it might also be novel to keep the cost
> down to a level that people can actually afford.
> 
> - paul
> 

---------------End of Original Message-----------------

--
From:   Joseph T. Klein, Titania Corporation http://www.titania.net
E-mail: jtk at titania.net  Sent:   13:25:09 CST/CDT 03/02/97

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
                -- Benjamin Franklin, 1759




From JimFleming at unety.net  Sun Mar  2 22:21:02 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 2 Mar 1997 16:21:02 -0600
Subject: The Big Squeeze
Message-ID: <01BC2725.B9942BE0@webster.unety.net>

On Sunday, March 02, 1997 4:15 AM, Nathan Stratton[SMTP:nathan at netrail.net] wrote:
@ On Sun, 2 Mar 1997, Sean Donelan wrote:
@ 
@ Number of routes, I know of 2 ISPs that we provided access to that were
@ mad because the nic gave them /19 and not /18. The providers are now out
@ of business and there are 2 /19 not being used, but at least they are not
@ /18. If the provider did get larger the nic would have gladly taken back
@ the /19 and given them a /18.
@ 

If there were regional IP registries that had an economic incentive
to reclaim those 2 /19s, then those would be recycled and reused.

If you accept that people are going to fail, then you have to plan
in advance for taking allocations back, or better yet, not renewing
the lease. This happens in real estate with office space all the
time.

Many buildings do not fragment their space because they have
a hard time leasing small spaces. Again, there are economic
and market-based reasons for this. It would be nice if the same
could be said for IP addresses.

The ARIN discussions (http://www.arin.net) focus on some
of these topics.

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From avg at pluris.com  Sun Mar  2 22:37:26 1997
From: avg at pluris.com (Vadim Antonov)
Date: Sun, 2 Mar 1997 14:37:26 -0800
Subject: "routing table slots" and the real problem
Message-ID: <199703022237.OAA29721@quest.pluris.com>

>I have always subscribed to this fundamental concept; memory to
>accommodate N number of routes has never been an operational
>issue.

Not the case with one vendor's boxes.  Memory _was_ the issue
after introducing CIDR.  AGS/+s and early 7000s  were running out
of memory, not out of CPU cycles.

--vadim

This message is brought to you by the society for history preservation :)




From michael at memra.com  Sun Mar  2 22:44:02 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 2 Mar 1997 14:44:02 -0800 (PST)
Subject: "routing table slots" and the real problem 
In-Reply-To: <QQcfen16766.199703022216@rodan.UU.NET>
Message-ID: <Pine.BSI.3.93.970302143755.12086H-100000@sidhe.memra.com>

On Sun, 2 Mar 1997, Mike O'Dell wrote:

> managing the complexity of the graph is the only alternative,
> and generally the only way to manage tne complexity is through
> aggregation.

In this case aggregation is a way of building a tree structure in the same
way the Route reflectors are used to build a tree structure in the iBGP
and route servers are used to build a tree structure in the eBGP. However,
when you look at the details of actual route computations over time you
should see a significant occurence of the identical calculation producing
the identical results. In a reasonably stable network this should be
amenable to some sort of caching system that can shortcut the route
computations and provide a more linear characteristic as the route table
grows. 

Is anyone doing any work on this whether in the vendor or the academic
community?

> whether we have other alternatives
> over time is an open question.

Time has a tendency to create alternatives; we should never discount the
possibility even if we choose not to rely on it happening.


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From mo at UU.NET  Sun Mar  2 22:58:28 1997
From: mo at UU.NET (Mike O'Dell)
Date: Sun, 02 Mar 1997 17:58:28 -0500
Subject: "routing table slots" and the real problem 
In-Reply-To: Your message of "Sun, 02 Mar 1997 14:37:26 PST."
             <199703022237.OAA29721@quest.pluris.com> 
Message-ID: <QQcfep22765.199703022258@rodan.UU.NET>


yes vadim, i was there too.

various inadequate hardware has contributed more than its share to the
belief that the problem was "memory" (and on those boxes it certainly
was).

however, to the degree this has caused people to conclude that the real
problem is "just" memory it is a red herring and a grave disservice.  this
topic has caused more witch-hunting and suspension of reason by otherwise
smart people than anything in recent memory.

	-mo




From avg at pluris.com  Sun Mar  2 23:48:48 1997
From: avg at pluris.com (Vadim Antonov)
Date: Sun, 2 Mar 1997 15:48:48 -0800
Subject: "routing table slots" and the real problem
Message-ID: <199703022348.PAA29809@quest.pluris.com>

>however, to the degree this has caused people to conclude that the real
>problem is "just" memory it is a red herring and a grave disservice.  this
>topic has caused more witch-hunting and suspension of reason by otherwise
>smart people than anything in recent memory.

Yes, the level of confusion (pun intended) surrounding these issues is
very high.

BTW, i agree with your conclusion (that scarcity of cycles is the issue)
completely.

I'd like to point out that flap dampening is a band-aid; the real solutions
are in eliminating sources of flap, rather than easying symptoms.

--vadim




From kimh at internic.net  Mon Mar  3 00:03:34 1997
From: kimh at internic.net (Kim Hubbard)
Date: Sun, 2 Mar 1997 19:03:34 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <01BC2725.B9942BE0@webster.unety.net> from "Jim Fleming" at Mar 2, 97 04:21:02 pm
Message-ID: <199703030003.TAA02634@moses.internic.net>

> 
> On Sunday, March 02, 1997 4:15 AM, Nathan Stratton[SMTP:nathan at netrail.net] wrote:
> @ On Sun, 2 Mar 1997, Sean Donelan wrote:
> @ 
> @ Number of routes, I know of 2 ISPs that we provided access to that were
> @ mad because the nic gave them /19 and not /18. The providers are now out
> @ of business and there are 2 /19 not being used, but at least they are not
> @ /18. If the provider did get larger the nic would have gladly taken back
> @ the /19 and given them a /18.
> @ 
> 
> If there were regional IP registries that had an economic incentive
> to reclaim those 2 /19s, then those would be recycled and reused.
> 
> If you accept that people are going to fail, then you have to plan
> in advance for taking allocations back, or better yet, not renewing
> the lease. This happens in real estate with office space all the
> time.
> 
> Many buildings do not fragment their space because they have
> a hard time leasing small spaces. Again, there are economic
> and market-based reasons for this. It would be nice if the same
> could be said for IP addresses.
> 
> The ARIN discussions (http://www.arin.net) focus on some
> of these topics.
>
Actually, the ARIN mailing list is not the place to discuss this, the
PAGAN list is.  I do agree that something needs to be done to begin
recapturing unused space, especially from those organizations no longer
in business.  This issue was raised in the IRE/PAGAN BOF at the last
IETF and needs to continue being seriously discussed.

Kim

 
> --
> Jim Fleming
> Unir Corporation
> 
> e-mail:
> JimFleming at unety.net
> JimFleming at unety.s0.g0 (EDNS/IPv8)
> 





From shields at crosslink.net  Mon Mar  3 00:44:14 1997
From: shields at crosslink.net (Michael Shields)
Date: Sun, 2 Mar 1997 19:44:14 -0500
Subject: The Big Squeeze
In-Reply-To: <Pine.BSI.3.93.970301201902.342J-100000@sidhe.memra.com>
References: <3.0.32.19970301092544.00d52400@mci.net>
	<Pine.BSI.3.93.970301201902.342J-100000@sidhe.memra.com>
Message-ID: <199703030044.TAA31355@daedalus.crosslink.net>

> 1. set a fee schedule for routing slots and determine what the conditions
>    of sale will be so that every Tom, Dick and Jane doesn't try to
>    buy a /24 slot for their PowerMAC webserver with ISDN TA attached.

Is there really a problem with that, as long as Tom, Dick, and Jane
are willing to pay the $x-thousand annual cost of the routing slot for
their /24?  (Or /28?)
-- 
Shields, CrossLink.




From JimFleming at unety.net  Mon Mar  3 01:06:28 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 2 Mar 1997 19:06:28 -0600
Subject: The Big Squeeze
Message-ID: <01BC273C.D5C96D40@webster.unety.net>

On Sunday, March 02, 1997 1:03 PM, Kim Hubbard[SMTP:kimh at internic.net] wrote:
<snip>

@ Actually, the ARIN mailing list is not the place to discuss this, the
@ PAGAN list is.  I do agree that something needs to be done to begin
@ recapturing unused space, especially from those organizations no longer
@ in business.  This issue was raised in the IRE/PAGAN BOF at the last
@ IETF and needs to continue being seriously discussed.
@ 

I will remind the NANOG readers that I suggested "neighbor net"[1]...
...there is no time like tomorrow...

[1] Neighbor net is a simple concept where adjacent binary space
neighbors check above and below and file periodic reports or
essentially knock on the virtual door and say..."anyone home?"

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Mon Mar  3 01:17:18 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 2 Mar 1997 19:17:18 -0600
Subject: The Big Squeeze
Message-ID: <01BC273E.593DA8C0@webster.unety.net>

On Sunday, March 02, 1997 6:44 PM, Michael Shields[SMTP:shields at crosslink.net] wrote:
@ > 1. set a fee schedule for routing slots and determine what the conditions
@ >    of sale will be so that every Tom, Dick and Jane doesn't try to
@ >    buy a /24 slot for their PowerMAC webserver with ISDN TA attached.
@ 
@ Is there really a problem with that, as long as Tom, Dick, and Jane
@ are willing to pay the $x-thousand annual cost of the routing slot for
@ their /24?  (Or /28?)
@ -- 
@ Shields, CrossLink.
@ 
@ 

What if that slot costs the same as the slot for a /18 ?

I bet some would renumber and some would not....

Let's let the market decide...

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From mo at UU.NET  Mon Mar  3 02:12:57 1997
From: mo at UU.NET (Mike O'Dell)
Date: Sun, 02 Mar 1997 21:12:57 -0500
Subject: "routing table slots" and the real problem 
In-Reply-To: Your message of "Sun, 02 Mar 1997 15:48:48 PST."
             <199703022348.PAA29809@quest.pluris.com> 
Message-ID: <QQcffc15705.199703030212@rodan.UU.NET>


we agree completely - controlling route noise at the source
is the optimal approach.  low-pass-filtering downstream is not
the solution.

	cheers,
	-mo




From SEAN at SDG.DRA.COM  Mon Mar  3 04:23:33 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Sun, 2 Mar 1997 22:23:33 -0600 (CST)
Subject: The Big Squeeze
Message-ID: <970302222333.9d19@SDG.DRA.COM>

>> I would suggest that the largest percentage of flapping prefixes in the
>> global routing system belong to prefixes longer than /19.
>
>Hence the convention to damp differently for different lengths.  See one of
>the foils in http://www.psg.com/~randy/970210.nanog/, which suggests that we
>over here start following the European lead on this.

Is the route computation of a /8 prefix flapping once a second any
different than a /24 flapping once a second?  If /8's are "naturally"
more stable, then why allow them to flap more before dampening them?

When dampening was first being rolled out I remember one of the early
networks that got hit was PSI's net 38/8.  Treating flapping prefixes
differently based on length has more to do with how many people scream
when prefixes covering a large amount of address space get dampened
than the impact of the route flap of an individual prefix on the router.

Although most folks have permanently filtered it, isn't 1/8 still the
flappiest prefix of all.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation




From randy at psg.com  Mon Mar  3 04:44:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 2 Mar 97 20:44 PST
Subject: The Big Squeeze
References: <970302222333.9d19@SDG.DRA.COM>
Message-ID: <m0w1Pba-0007zYC@rip.psg.com>

> When dampening was first being rolled out I remember one of the early
> networks that got hit was PSI's net 38/8.  Treating flapping prefixes
> differently based on length has more to do with how many people scream
> when prefixes covering a large amount of address space get dampened
> than the impact of the route flap of an individual prefix on the router.

Also, it is thought that longer prefixes tend to flap more than shorter.

randy




From pferguso at cisco.com  Mon Mar  3 05:28:12 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 00:28:12 -0500
Subject: "routing table slots" and the real problem 
Message-ID: <3.0.32.19970302231838.0069c05c@lint.cisco.com>

At 01:25 PM 3/2/97, Joseph T. Klein wrote:

>We are re-designing the Internet to make up for the fact the 
>largest manufacturers of routers has been slow to develop and
>deploy systems that can keep up with the growth curve. A lot of
>this comes down to size of the memory bus on low cost systems.
>

Without launching into a long, tiresome response here, I would
suggest that this is correct, yet incorrect. The statistics
that I have seen indicates that we (collectively) are not
behind the curve here. Of course, there are extraneous issues
which do not relate to the router vendors (availability of
fiber, etc.), but let's not go down that rat hole.


>
>If router manufacturers worked on hardware and all used an open
>software standard ... such as gated ... we would all be better off.
>Open standards allow all of us to benefit from the work of others.

I like open standards just as much as the next guy, but let's
be realistic here. There is a difference between 'open standards'
with regards to getting bits from point a to point b (the protocols
developed within the IETF and elsewhere) and operating systems.

I would suggest that the former is much more important than the
latter.

- paul





From pferguso at cisco.com  Mon Mar  3 05:28:19 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 00:28:19 -0500
Subject: "routing table slots" and the real problem
Message-ID: <3.0.32.19970302232724.0069c05c@lint.cisco.com>

At 03:48 PM 3/2/97 -0800, Vadim Antonov wrote:

>
>I'd like to point out that flap dampening is a band-aid; the real solutions
>are in eliminating sources of flap, rather than easying symptoms.
>

Vadim, I'd love to hear your suggestions on this one.  ;-)

- paul





From pferguso at cisco.com  Mon Mar  3 05:28:10 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 00:28:10 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970302230724.0069c05c@lint.cisco.com>

At 04:03 PM 3/2/97 -0600, Scott Huddle wrote:

>
>I'll assert that if the costs of accepting a route announcement are
>non-zero that this can only happen if there is a market for
>announcements and a system of settlements between providers.
>
>If the costs are zero, then why have the filters?  
>

I'd suggest that costs are non-zero, and they cannot be quantified
by dollars, at least today. Since the majority of instability in
the global Internet is originated by prefixes longer than /19's,
the amount of resources consumed is an exercise left for the reader.

- paul





From pferguso at cisco.com  Mon Mar  3 05:28:05 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 00:28:05 -0500
Subject: The real problem
Message-ID: <3.0.32.19970302230032.0069c05c@lint.cisco.com>

At 04:03 PM 3/2/97 -0600, Scott Huddle wrote:

>Mike,
>
>If I follow your observation, routing computation growth is
>non-linearly related to number of routes.  Or is it
>orthogonal?  If the growth is related to the announcement,
>this infers that costs incurred for the announcement of routes by 
>ISP FOO to ISP BAR would be non-linear with the quantity,
>correct?  
>

I would suggest that the number of prefixes in the global
routing table *is* linearly related to the amount of
computational overhead.

- paul





From pferguso at cisco.com  Mon Mar  3 05:28:15 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 00:28:15 -0500
Subject: "routing table slots" and the real problem
Message-ID: <3.0.32.19970302232123.0069c05c@lint.cisco.com>

At 02:37 PM 3/2/97 -0800, Vadim Antonov wrote:

>
>Not the case with one vendor's boxes.  Memory _was_ the issue
>after introducing CIDR.  AGS/+s and early 7000s  were running out
>of memory, not out of CPU cycles.
>

Witness the birth of boxes which have 32Mb, 64Mb, 128Mb, etc.,
memory.


>--vadim
>
>This message is brought to you by the society for history preservation :)
>

Yes, I know. I was there.  :-)

- paul





From JimFleming at unety.net  Mon Mar  3 05:41:58 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 2 Mar 1997 23:41:58 -0600
Subject: The Big Squeeze
Message-ID: <01BC2763.52D270E0@webster.unety.net>

On Sunday, March 02, 1997 11:28 PM, Paul Ferguson[SMTP:pferguso at cisco.com] wrote:
@ At 04:03 PM 3/2/97 -0600, Scott Huddle wrote:
@ 
@ >
@ >I'll assert that if the costs of accepting a route announcement are
@ >non-zero that this can only happen if there is a market for
@ >announcements and a system of settlements between providers.
@ >
@ >If the costs are zero, then why have the filters?  
@ >
@ 
@ I'd suggest that costs are non-zero, and they cannot be quantified
@ by dollars, at least today. Since the majority of instability in
@ the global Internet is originated by prefixes longer than /19's,
@ the amount of resources consumed is an exercise left for the reader.
@ 

Would you support charging $$$ for circuits that go in and out of service
beyond some reasonable amount ?

Car insurance companies charge people more that have more accidents...:-)

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From pferguso at cisco.com  Mon Mar  3 06:28:43 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 01:28:43 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970303012840.006a64a8@lint.cisco.com>

At 10:23 PM 3/2/97 -0600, Sean Donelan wrote:

>
>Is the route computation of a /8 prefix flapping once a second any
>different than a /24 flapping once a second?  If /8's are "naturally"
>more stable, then why allow them to flap more before dampening them?
>

How many /8's are in the global routing system v. /24's?

- paul





From apb at iafrica.com  Mon Mar  3 11:07:42 1997
From: apb at iafrica.com (Alan Barrett)
Date: Mon, 3 Mar 1997 13:07:42 +0200 (GMT+0200)
Subject: The Big Squeeze
In-Reply-To: <m0w1Pba-0007zYC@rip.psg.com>
Message-ID: <Pine.NEB.3.95.970303130538.137A-100000@apb.iafrica.com>

> Also, it is thought that longer prefixes tend to flap more than shorter.

That's not because of the prefix length per se; it's because shorter
prefixes tend to be associated with a greater number of reachable
destinations per prefix, and that tends to imply better infrastructure
and more opportunities for aggregation and hold-ups.

--apb (Alan Barrett)







From bradley at dunn.org  Mon Mar  3 11:59:32 1997
From: bradley at dunn.org (Bradley Dunn)
Date: Mon, 3 Mar 1997 06:59:32 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <970302222333.9d19@SDG.DRA.COM>
Message-ID: <Pine.BSF.3.95.970303065637.26617A-100000@ns2.harborcom.net>

On Sun, 2 Mar 1997, Sean Donelan wrote:

> Is the route computation of a /8 prefix flapping once a second any
> different than a /24 flapping once a second?  If /8's are "naturally"
> more stable, then why allow them to flap more before dampening them?

It's just another incentive to renumber into larger aggregate blocks. A
provider can say to a customer:

"If your /24 flaps you're going to be unreachable from some parts of the
net for longer than you would if you renumber into our block."


pbd





From sherk at uunet.uu.net  Mon Mar  3 14:05:17 1997
From: sherk at uunet.uu.net (Erik Sherk)
Date: Mon, 03 Mar 1997 09:05:17 -0500
Subject: The Big Squeeze 
In-Reply-To: Your message of "Sun, 02 Mar 1997 20:44:00 PST."
             <m0w1Pba-0007zYC@rip.psg.com> 
Message-ID: <QQcfgy23209.199703031405@aotearoa.UU.NET>

> > When dampening was first being rolled out I remember one of the early
> > networks that got hit was PSI's net 38/8.  Treating flapping prefixes
> > differently based on length has more to do with how many people scream
> > when prefixes covering a large amount of address space get dampened
> > than the impact of the route flap of an individual prefix on the router.
> 
> Also, it is thought that longer prefixes tend to flap more than shorter.
> 
> randy

Sean has a good point here. A flap of a /8 is the same as a flap of a /24
from a computational point of view. There is clearly some social engineering
going on here. If you want your long prefix to be golbally visable and you
allow it to flap, then you will be subject to dampening. On the other hand
if you renumber into a larger aggregate, then you are protected from dampening 
(to a greater degree). Kind of a 'carrot and stick' approch. :-)

Erik





From ahp at hilander.com  Mon Mar  3 14:21:12 1997
From: ahp at hilander.com (Alec H. Peterson)
Date: Mon, 3 Mar 1997 09:21:12 -0500
Subject: The Big Squeeze
In-Reply-To: <QQcfgy23209.199703031405@aotearoa.UU.NET>; from "Erik Sherk" on Mar 3, 1997 09:05:17 -0500
References: <m0w1Pba-0007zYC@rip.psg.com> <QQcfgy23209.199703031405@aotearoa.UU.NET>
Message-ID: <19970303092112.IS17510@kurgan.erols.com>

On Mar 3, 1997, Erik Sherk wrote:
> 
> Sean has a good point here. A flap of a /8 is the same as a flap of
> a /24 from a computational point of view. There is clearly some
> social engineering going on here. If you want your long prefix to be
> golbally visable and you allow it to flap, then you will be subject
> to dampening. On the other hand if you renumber into a larger
> aggregate, then you are protected from dampening (to a greater
> degree). Kind of a 'carrot and stick' approch. :-)

Computational power required for a route flap is not the issue here.

Many people have stated that, statistically longer prefixes flap
more.  Unfortunately, they have then said that because of this shorter
prefixes should have looser dampening parameters put on them, when
what they really meant was that the longer prefixes should have more
strict dampening parameters put on them.  Yes it is exactly the same
thing, but it is an important semantic distinction.  If a group of
prefixes categorized by a its length tends to flap more than the
average, then said group should have more strict dampening parameters
placed on it.

Alec

-- 
+------------------------------------+--------------------------------------+
|Alec Peterson - ahp at hilander.com    | Erols Internet Services, INC.        |
|Network Engineer                    | Springfield, VA.                     |
+------------------------------------+--------------------------------------+




From garyz at savvis.com  Mon Mar  3 16:29:44 1997
From: garyz at savvis.com (Gary Zimmerman)
Date: Mon, 3 Mar 1997 08:29:44 -0800
Subject: "routing table slots" and the real problem 
Message-ID: <19970303143708.AAA26482@rock>

Has anyone looked at Ascend's (NetStar Gigarouter).  We have and like the
direction.  If they continue to deliver, I think they are going in the
right direction.  Still some parts missing, I hope we can hold on until
they get here, but the direction is right.  I think the open idea is the
only way to go on this issue.

Gary Zimmerman
Savvis Communications    http://www.savvis.com
email:  garyz at savvis.com

"The only limits are those of vision."

----------
> From: Joseph T. Klein <jtk at titania.net>
> To: nanog at merit.edu; Paul Ferguson   <pferguso at cisco.com>
> Subject: Re: "routing table slots" and the real problem 
> Date: Sunday, March 02, 1997 5:25 AM
> 
> Warning -- I feel a diatribe emerging. ;-)
> 
> Afordability is primarily a question of how large your existing
> base of legacy routers is and your cash flow.
> 
> You can build a box using a free versionof Unix (FreeBSD, NetBSD,
> Linux, or whatever your religion of the day), off the shelf
> hardware, and gated to route a full backbone routing table
> (memory and CPU are cheap) for less than $3K. This is less
> than the cost of a single interface card for a Cisco 7xxx!
> 
> Kids; do not try this at your gateway without adult supervision.
> :-)
> 
> We are re-designing the Internet to make up for the fact the 
> largest manufacturers of routers has been slow to develop and
> deploy systems that can keep up with the growth curve. A lot of
> this comes down to size of the memory bus on low cost systems.
> 
> If port density was not so poor on general purpose hardware, we
> would have been far better off deploying "open systems" for routers
> rather than what exists today.
> 
> I have always liked my Ciscos, but I truly love routing with my Unix
> systems running gated. ... now If I could find some cheap channelized
> DS-3 cards for a DEC AlphaStation 500. ;-)
> 
> I may be talking out of my hat here, but I suspect a DEC AlphaStation
> 500 with 256M of RAM ranks pretty well against a 75xx.
> 
> Somebody, dig up the stats for me ...
> 
> If router manufacturers worked on hardware and all used an open
> software standard ... such as gated ... we would all be better off.
> Open standards allow all of us to benefit from the work of others.
> The old Unix Guru's mantra is 'build on the works of others.'
> 
> Let us not make the mistakes of the 1890s and associate domination
> of the market by oligopolies as good capitalism. Big corporations,
> like big government, tend to move slowly.
> 
> Open markets NOT dominated by a single large player is GOOD
> capitalism. It increases the pace of innovation and prevents
> price fixing. It makes for a healthy, dynamic, marketplace.
> 
> This holds true for routers, backbone providers, toasters
> and operating systems (sorry Bill)
> 
> open standards = open markets
> 
> Open standards prevent the failures of a single market
> player from inhibiting the growth of the industry.
> 
> Open standards lower the cost to upgrade large installed
> systems.
> 
> Reductions in the federal budget are squeezing R&D expenditures in
> the US to an all time low. Large corporate downsizing and corporate
> mergers have done the same for most large corporations. The bulk
> of innovation in the US will come from small companies and
> development consortiums.
> 
> It is from these that the next generations of routers will
> come. Open standards make the rapid utilization of new
> technologies possible and fuel the growth of small companies.
> 
> The Internet is a great place for consorting on standards.
> This is what is cool about the IETF!
> 
> Standards do not keep the big boys from playing ...
> Cisco and Bay could easily join in an open standard
> for router software. It would not be hard to have interoperability
> between the IP portions of IOS and gated.
> 
> IOS is the PL-1 of routers. Bay's management reminds me of CICS. ;-)
> 
> Back to the subject ...
> 
> You CAN also use the RA (where available) to reduce your routing
> overhead, save memory and reduce CPU usage. (The RA runs a hacked
> version of gated that calculates large routing tables quite well.)
> 
> Hmm ...
> 
> router $100,000 amortized over 3 years =  2,800/month
> going DS-3 price at a NAP with line    =  7,000/month
> engineer $70,000 per year min.         =  5,900/month
> overhead for a small company           = 20,000/month
> 
> $50+/month/mile for OC-3 lines ... don't even talk about
> local loop costs!
> 
> Routers connect customers.
> customers = cash flow.
> 
> The highest cost of running a national network is not buying routers,
> it is bandwidth, staff, and administrative overhead.
> 
> Router cost is primarily a factor for smaller networks with limited
> cash flow.
> 
> I contend ...
> 
> It is the ISPs who try to be dual homed with 'routing tricks' rather
> than using edge routers that can process a core routing table, who
> contribute most to routing instability.
> 
> Boardwatch stated that 14% of ISPs are dual homed. I would bet
> that 70% of those do not use routers capable of processing a core
> routing table.
> 
> Anybody have any stats?
> 
> We need cheap routers that run BGP4 and can eat a core routing table.
> 2501s just don't hack it in dual homed configurations ... and most
> small guys just don't wish to blow $50,000 on putting 7505s at the
> edges of their networks.
> 
> 
> --- On Sun, 02 Mar 1997 13:48:46 -0500  Paul Ferguson
<pferguso at cisco.com> wrote:
> > At 01:39 PM 3/2/97 -0500, Perry E. Metzger wrote:
> > 
> > >
> > >True enough. Of course, this doesn't mean that we can't have routing
> > >table growth, as we will have processor capacity growth, but it does
> > >mean that the growth of the routing tables must be kept in line with
> > >what the router processors can do.
> > >
> > 
> > True enough. However, it might also be novel to keep the cost
> > down to a level that people can actually afford.
> > 
> > - paul
> > 
> 
> ---------------End of Original Message-----------------
> 
> --
> From:   Joseph T. Klein, Titania Corporation http://www.titania.net
> E-mail: jtk at titania.net  Sent:   13:25:09 CST/CDT 03/02/97
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>                 -- Benjamin Franklin, 1759




From freedman at netaxs.com  Mon Mar  3 14:53:45 1997
From: freedman at netaxs.com (Avi Freedman)
Date: Mon, 3 Mar 1997 09:53:45 -0500 (EST)
Subject: The Big Squeeze
In-Reply-To: <19970303092112.IS17510@kurgan.erols.com> from "Alec H. Peterson" at Mar 3, 97 09:21:12 am
Message-ID: <199703031453.JAA20110@access.netaxs.com>

> Computational power required for a route flap is not the issue here.
> 
> Many people have stated that, statistically longer prefixes flap
> more.  Unfortunately, they have then said that because of this shorter
> prefixes should have looser dampening parameters put on them, when
> what they really meant was that the longer prefixes should have more
> strict dampening parameters put on them.  Yes it is exactly the same
> thing, but it is an important semantic distinction.  If a group of
> prefixes categorized by a its length tends to flap more than the
> average, then said group should have more strict dampening parameters
> placed on it.
> 
> Alec

You're right - what you propose makes some sense.  The reason people
have proposed and are damnening on longer prefixes is:

1) To encourage people to renumber into larger (P and/or PI) space, and
2) To lessen the percentage of the net which will be temporarily
   unreachable by the aggressive dampener.

Avi





From dhudes at graphnet.com  Mon Mar  3 15:13:15 1997
From: dhudes at graphnet.com (Mr. Dana Hudes)
Date: Mon, 03 Mar 1997 10:13:15 -0500
Subject: "routing table slots" and the real problem
References: <3.0.32.19970302134843.006942ec@lint.cisco.com> <Chameleon.857340708.jtk@monet.titania.net>
Message-ID: <331AEA8A.5437@graphnet.com>

I hear you but the problem in 'open systems' is not memory or cpu speed:
it's the backplane.
I worked on the end of the NSFnet NSS project and with it forward to
where we had later versions
of software (including gated) and new cards intended for the 6611 but
with software rewritten
by clever people and fixes to the AIX kernal by a very smart programmer.
We had port density
-- 8 sync ports on a card, 2 sync +?LAN?(ether or tokenring your choice)
-- and we had high
end cards (FDDI and T3 from the NSFnet days, ATM over T3 and over TAXI
at the very end).
But an Rs/6000 is not a gigabit router. The theoretical max on the
backplane was 622Mbit and that
includes IP forwarding and disk I/O. I assure we did not hit 620Mbit
even going T3 <->T3.
Then there is the small point that an RS/6K is not exactly cheap like a
PC.

I have no idea whatsoever of the throughput capacity of PCI bus on a PC
but everyone in the
gigabit game is using switched backplanes rather than a shared bus. The
nature of the switch
is different in different vendors of course (Netstar is a 16way
crosspoint switch, for example,
while I heard someone was building a router with an ATM OC3 backplane).

The issue is not only whether open systems can take full routing and do
the route computations
because I'm sure they can (the Route Arbiter does). The question is
whether they can do that AND forward packets in today's (multi)gigabit
core on a normal shared bus architecture.
Noone I know is selling ATM backplanes for PC's .....

Dana
Joseph T. Klein wrote:

  Warning -- I feel a diatribe emerging. ;-)

  Afordability is primarily a question of how large your existing
  base of legacy routers is and your cash flow.

  You can build a box using a free versionof Unix (FreeBSD, NetBSD,
  Linux, or whatever your religion of the day), off the shelf
  hardware, and gated to route a full backbone routing table
  (memory and CPU are cheap) for less than $3K. This is less
  than the cost of a single interface card for a Cisco 7xxx!

  Kids; do not try this at your gateway without adult supervision.
  :-)

  We are re-designing the Internet to make up for the fact the
  largest manufacturers of routers has been slow to develop and
  deploy systems that can keep up with the growth curve. A lot of
  this comes down to size of the memory bus on low cost systems.

  If port density was not so poor on general purpose hardware, we
  would have been far better off deploying "open systems" for routers
  rather than what exists today.

  I have always liked my Ciscos, but I truly love routing with my Unix

  systems running gated. ... now If I could find some cheap
  channelized
  DS-3 cards for a DEC AlphaStation 500. ;-)

  I may be talking out of my hat here, but I suspect a DEC
  AlphaStation
  500 with 256M of RAM ranks pretty well against a 75xx.

  Somebody, dig up the stats for me ...

  If router manufacturers worked on hardware and all used an open
  software standard ... such as gated ... we would all be better off.
  Open standards allow all of us to benefit from the work of others.
  The old Unix Guru's mantra is 'build on the works of others.'

  Let us not make the mistakes of the 1890s and associate domination
  of the market by oligopolies as good capitalism. Big corporations,
  like big government, tend to move slowly.

  Open markets NOT dominated by a single large player is GOOD
  capitalism. It increases the pace of innovation and prevents
  price fixing. It makes for a healthy, dynamic, marketplace.

  This holds true for routers, backbone providers, toasters
  and operating systems (sorry Bill)

  open standards = open markets

  Open standards prevent the failures of a single market
  player from inhibiting the growth of the industry.

  Open standards lower the cost to upgrade large installed
  systems.

  Reductions in the federal budget are squeezing R&D expenditures in
  the US to an all time low. Large corporate downsizing and corporate
  mergers have done the same for most large corporations. The bulk
  of innovation in the US will come from small companies and
  development consortiums.

  It is from these that the next generations of routers will
  come. Open standards make the rapid utilization of new
  technologies possible and fuel the growth of small companies.

  The Internet is a great place for consorting on standards.
  This is what is cool about the IETF!

  Standards do not keep the big boys from playing ...
  Cisco and Bay could easily join in an open standard
  for router software. It would not be hard to have interoperability
  between the IP portions of IOS and gated.

  IOS is the PL-1 of routers. Bay's management reminds me of CICS. ;-)

  Back to the subject ...

  You CAN also use the RA (where available) to reduce your routing
  overhead, save memory and reduce CPU usage. (The RA runs a hacked
  version of gated that calculates large routing tables quite well.)

  Hmm ...

  router $100,000 amortized over 3 years =  2,800/month
  going DS-3 price at a NAP with line    =  7,000/month
  engineer $70,000 per year min.         =  5,900/month
  overhead for a small company           = 20,000/month

  $50+/month/mile for OC-3 lines ... don't even talk about
  local loop costs!

  Routers connect customers.
  customers = cash flow.

  The highest cost of running a national network is not buying
  routers,
  it is bandwidth, staff, and administrative overhead.

  Router cost is primarily a factor for smaller networks with limited
  cash flow.

  I contend ...

  It is the ISPs who try to be dual homed with 'routing tricks' rather

  than using edge routers that can process a core routing table, who
  contribute most to routing instability.

  Boardwatch stated that 14% of ISPs are dual homed. I would bet
  that 70% of those do not use routers capable of processing a core
  routing table.

  Anybody have any stats?

  We need cheap routers that run BGP4 and can eat a core routing
  table.
  2501s just don't hack it in dual homed configurations ... and most
  small guys just don't wish to blow $50,000 on putting 7505s at the
  edges of their networks.

  --- On Sun, 02 Mar 1997 13:48:46 -0500  Paul Ferguson
  <pferguso at cisco.com> wrote:
  > At 01:39 PM 3/2/97 -0500, Perry E. Metzger wrote:
  >
  > >
  > >True enough. Of course, this doesn't mean that we can't have
  routing
  > >table growth, as we will have processor capacity growth, but it
  does
  > >mean that the growth of the routing tables must be kept in line
  with
  > >what the router processors can do.
  > >
  >
  > True enough. However, it might also be novel to keep the cost
  > down to a level that people can actually afford.
  >
  > - paul
  >

  ---------------End of Original Message-----------------

  --
  From:   Joseph T. Klein, Titania Corporation http://www.titania.net
  E-mail: jtk at titania.net  Sent:   13:25:09 CST/CDT 03/02/97

  "They that can give up essential liberty to obtain a little
  temporary
  safety deserve neither liberty nor safety."
                  -- Benjamin Franklin, 1759







From neal_castagnoli at novell.com  Sat Mar  1 05:46:40 1997
From: neal_castagnoli at novell.com (neal castagnoli)
Date: Fri, 28 Feb 1997 21:46:40 -0800
Subject: Push's Tutorial -Reply
Message-ID: <s31aaa44.003@novell.com>


The subject is that content providers should pay for "free" ISPs.

My attitude is that there are lots of consumers out there that haven't
figured out that they need to pay for services.  The reason is the
government has subsidized the Internet, and it has a "free" aura
associated with it.  The end result is advertising, which I hate.

I personally would rather pay for no advertising than have "free"
programming, and until the masses really adopt the interet, I'd bet that a
lot of people agree.

  --Neal

>>> Steve Kann <stevek at SteveK.COM> 01/29/97 07:26am >>>





From neal_castagnoli at novell.com  Mon Mar  3 02:33:10 1997
From: neal_castagnoli at novell.com (neal castagnoli)
Date: Sun, 02 Mar 1997 18:33:10 -0800
Subject: Routing Protocol Simulators -Reply
Message-ID: <s31aaf32.058@novell.com>


Craig,

Novell built one for NLSP.  NLSP models the IS - IS protocol for IPX.  The
simulator creates a variety of topologies, allows you to specify change
rates in those topologies, and also allows you to create your own.  Some
of the topologies are a cube, one that models what an ISP deploying IPX
might look like, and one that models RIP.  I'm not sure whether additional
topologies have been added.

You can contact AE Natarajan for more information (he is copied on this
email message).

  --Neal

>>> "Craig A. Haney" <craig at seamless.kludge.net> 02/28/97 03:43pm
>>>
At 18:02 -0500 2/28/97, Daniel O Awduche wrote:
>I am in need of routing protocol simulators, and would be
>most appreciative if information can be provided on
>available packages (commercial and/or public domain).
>In particular, packages that can provide realistic
>simulation of the ISIS and/or OSPF protocols would be
>most ideal.
>
>Thank you for your time.
>
>Daniel Awduche.
>awduche at zonker.ecs.umass.edu

Try calling Prof. Ranbir Sidu. Their product may be of interest.


TeleniX Corporation (TELENIX-DOM)
   3982 White Rose Way
   Ellicott City, MD 21042-5822
   USA

   Domain Name: TELENIX.COM

   Administrative Contact:
      Sidhu, Ranbir  (RS2941)  telenix at ACCESS.DIGEX.NET
      (410)750-3213
   Technical Contact, Zone Contact:
      Clark Internet Services, Inc.  (CIS5-ORG)  dns at CLARK.NET
      (410) 995-0550
Fax- (410) 995-0495
   Billing Contact:
      Sidhu, Ranbir  (RS2941)  telenix at ACCESS.DIGEX.NET
      (410)750-3213

   Record last updated on 20-Jan-97.
   Record created on 01-Aug-96.


-craig


--------------------------------------------------------------------
Craig A. Haney            Cando Consulting - The Internetwork People
703.448.9826 :Tel         2031 Madrillon Springs Court
703.448.9786 :Fax         Vienna, VA 22182-3764
                          http://seamless.kludge.net







From dhudes at graphnet.com  Mon Mar  3 19:27:32 1997
From: dhudes at graphnet.com (Mr. Dana Hudes)
Date: Mon, 03 Mar 1997 14:27:32 -0500
Subject: Routing Protocol Simulators -Reply
References: <s31aaf32.058@novell.com>
Message-ID: <331B2623.76CB@graphnet.com>

I once ran across something called the Maryland Routing Simulator (MARS)

when I was looking into the Routing Arbiter.  I looked around and found
it again.
http://www.isi.edu:80/div7/ra/index.html has a link to the aformentioned
and more.

Enjoy





From tcrowell at gte.net  Mon Mar  3 19:58:17 1997
From: tcrowell at gte.net (Tim Crowell)
Date: Mon, 03 Mar 1997 13:58:17 -0600
Subject: Firewall in Routers??
Message-ID: <331B2D59.7C26@gte.net>

With all of the recent attacks against ISP services, has anybody
considered implementing Checkpoint Firewalls into the CISCO 7513s to
front end all traffic from the Internet?

Although in theory this sounds feasible from a security standpoint I'm
not sure I am comfortable with the processing power that would be
required and having anything looking at every packet.  It seems that
this would introduce a significant latency into the routing of the
traffic (which is the function of a router or at least it used to be). I
prefer to let my routers route.

Interested in any and all ideas on the subject.

-- 
Tim Crowell - GTE Intelligent Network Services
tcrowell at gte.net		Voice: 214.751.3881




From pknight at BayNetworks.COM  Mon Mar  3 21:57:59 1997
From: pknight at BayNetworks.COM (Paul Knight)
Date: Mon, 03 Mar 1997 16:57:59 -0500
Subject: Firewall in Routers??
References: <331B2D59.7C26@gte.net>
Message-ID: <331B4967.2620D7A2@BayNetworks.com>

Hmm, yes.   

At least one router vendor (with sufficient processing power) is doing
this...  Here is a pointer to some basic info on Bay Networks'
implementation, dating from last September.  

http://www.baynetworks.com/Products/Briefs/baysecrs.html

Tim Crowell wrote:
> 
> With all of the recent attacks against ISP services, has anybody
> considered implementing Checkpoint Firewalls into the CISCO 7513s to
> front end all traffic from the Internet?
> 
> Although in theory this sounds feasible from a security standpoint I'm
> not sure I am comfortable with the processing power that would be
> required and having anything looking at every packet.  It seems that
> this would introduce a significant latency into the routing of the
> traffic (which is the function of a router or at least it used to be). I
> prefer to let my routers route.
> 
> Interested in any and all ideas on the subject.
> 
> --
> Tim Crowell - GTE Intelligent Network Services
> tcrowell at gte.net                Voice: 214.751.3881

-- 
Paul Knight 			     mailto:pknight at BayNetworks.com
IP Engineering, Systems Test	     Office: (508) 916-7087
Bay Networks, Inc.	M/S BL2-02	Lab: (508) 670-8888, x-65404
2 Federal St., Billerica, MA 01821	Fax: (508) 670-4004




From awsmith at rip.ops.neosoft.com  Mon Mar  3 22:43:21 1997
From: awsmith at rip.ops.neosoft.com (Andrew Smith)
Date: Mon, 3 Mar 1997 16:43:21 -0600 (CST)
Subject: Firewall in Routers??
In-Reply-To: <331B2D59.7C26@gte.net> from "Tim Crowell" at Mar 3, 97 01:58:17 pm
Message-ID: <199703032243.QAA11049@rip.ops.neosoft.com>

> 
> With all of the recent attacks against ISP services, has anybody
> considered implementing Checkpoint Firewalls into the CISCO 7513s to
> front end all traffic from the Internet?
> 
> -- 
> Tim Crowell - GTE Intelligent Network Services
> tcrowell at gte.net		Voice: 214.751.3881

I know that Bay is doing this with Checkpoint when (or soon after)
FW-1 3.0 is released. I assume this would make a deal with cisco
rather difficult, especially considering the way cisco has been
pushing the PIX box against FW-1.
 
---------------------------------------------------------------------------
Andrew Smith ** awsmith at neosoft.com ** Network Engineer ** 1-888-NEOSOFT
       ** "Opportunities multiply as they are seized" - Sun Tzu **
            ** http://www.neosoft.com/neosoft/staff/andrew ** 
---------------------------------------------------------------------------




From nathan at netrail.net  Mon Mar  3 23:16:43 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Mon, 3 Mar 1997 18:16:43 -0500 (EST)
Subject: "routing table slots" and the real problem 
In-Reply-To: <19970303143708.AAA26482@rock>
Message-ID: <Pine.LNX.3.95.970303181205.5556B-100000@netrail.net>

On Mon, 3 Mar 1997, Gary Zimmerman wrote:

> Has anyone looked at Ascend's (NetStar Gigarouter).  We have and like the
> direction.  If they continue to deliver, I think they are going in the
> right direction.  Still some parts missing, I hope we can hold on until
> they get here, but the direction is right.  I think the open idea is the
> only way to go on this issue.

We have been using them for about 5 months now, and I like them a lot. We
have worked with Ascend to fix a large numbers of problems. They are very
stable now, and have a lot of people working to make them better. 


Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34






From justin at erols.com  Mon Mar  3 23:50:03 1997
From: justin at erols.com (Justin W. Newton)
Date: Mon, 03 Mar 1997 18:50:03 -0500
Subject: "routing table slots" and the real problem
Message-ID: <3.0.32.19970303185001.00c2b3ac@justin.erols.com>

At 06:16 PM 3/3/97 -0500, Nathan Stratton wrote:
>On Mon, 3 Mar 1997, Gary Zimmerman wrote:
>
>> Has anyone looked at Ascend's (NetStar Gigarouter).  We have and like the
>> direction.  If they continue to deliver, I think they are going in the
>> right direction.  Still some parts missing, I hope we can hold on until
>> they get here, but the direction is right.  I think the open idea is the
>> only way to go on this issue.
>
>We have been using them for about 5 months now, and I like them a lot. We
>have worked with Ascend to fix a large numbers of problems. They are very
>stable now, and have a lot of people working to make them better. 

Out of curiosity, where in your network are you using them?  What kind of
traffic loads are they seeing, etc etc?

Justin Newton				
Network Architect					
Erol's Internet Services
ISP/C Director at Large




From tli at jnx.com  Mon Mar  3 23:54:45 1997
From: tli at jnx.com (Tony Li)
Date: Mon, 3 Mar 1997 15:54:45 -0800 (PST)
Subject: Caveat Emptor....
Message-ID: <199703032354.PAA24256@chimp.jnx.com>


This is somewhat off topic, but there's no better place...

It has come to my attention that a certain significant router vendor's
representatives have told some of their prospects that I've worked on their
system.  Just to set the matter straight, my total employment for the past
6 years has been either at Juniper Networks or at Cisco Systems (or at
cisco Systems ;-).

If you've heard otherwise, I would very much appreciate hearing from you as
I'm contemplating legal action...

So far, I have no reason to believe that this is the policy of the
aforementioned vendor.  In fact, I suspect that it's an overzealous
salesdroid.  Caveat Emptor.

Thank you for your attention.  We now return you to your regularly
scheduled drivel.  ;-)

Tony




From sreubelt at whistle.com  Mon Mar  3 16:37:45 1997
From: sreubelt at whistle.com (Scott Reubelt)
Date: Mon, 03 Mar 1997 16:37:45 +0000
Subject: Frame Relay Question
Message-ID: <331AFE3B.616D@whistle.com>

I have a question that could or should be able to be answered by this
group.

I'm looking to simulate a Frame Relay Internet environment between a
couple of routers.  This will be internal and not connected to the
internet, yet.  I will also need the ability to add nodes to this
simulated WAN.  Does someone have a quick and dirty HW & SW list that I
will need to purchase??

Thanks,
-- 

Scott F. Reubelt
sreubelt at whistle.com  (http://www.whistle.com)




From glynn at nol.co.uk  Tue Mar  4 02:12:24 1997
From: glynn at nol.co.uk (Glynn Stanton)
Date: Tue, 4 Mar 1997 02:12:24 +0000 (GMT)
Subject: Firewall in Routers??
In-Reply-To: <199703032243.QAA11049@rip.ops.neosoft.com>
Message-ID: <Pine.LNX.3.93.970304020246.31653B-100000@obewan.n-e-t.co.uk>


> I know that Bay is doing this with Checkpoint when (or soon after)
> FW-1 3.0 is released. I assume this would make a deal with cisco
> rather difficult, especially considering the way cisco has been
> pushing the PIX box against FW-1.

Just to throw in a little bit more info..

Theres little comparrison between the two.
PIX is more of an address translation unit with firewalling
capabilities.
Firewall-1 is a fully functional Firewall with limited address
translation. 

i.e. PIX has a pool of IP addresses.. true address translation.
Firewall-1 does address 'hiding' making it look to the external world
like all connects come from a single IP.

I tend to prefer to keep routers as routers and firewalls as firewalls,
it reduces the CPU overhead, Problem Determination is easier, and 
configurations are kept in a distinct logical box.
Of course this is at the expense of cost, and space.

Glynn Stanton.






From awsmith at rip.ops.neosoft.com  Tue Mar  4 02:37:58 1997
From: awsmith at rip.ops.neosoft.com (Andrew Smith)
Date: Mon, 3 Mar 1997 20:37:58 -0600 (CST)
Subject: Firewall in Routers??
In-Reply-To: <Pine.LNX.3.93.970304020246.31653B-100000@obewan.n-e-t.co.uk> from "Glynn Stanton" at Mar 4, 97 02:12:24 am
Message-ID: <199703040237.UAA11416@rip.ops.neosoft.com>

> Just to throw in a little bit more info..
> 
> Theres little comparrison between the two.
> PIX is more of an address translation unit with firewalling
> capabilities.
> Firewall-1 is a fully functional Firewall with limited address
> translation. 
> 
> i.e. PIX has a pool of IP addresses.. true address translation.
> Firewall-1 does address 'hiding' making it look to the external world
> like all connects come from a single IP.

Actually, hide mode is only one of the options in FW-1. You can do
a static one-to-one allocation (but not dynamically).

> I tend to prefer to keep routers as routers and firewalls as firewalls,
> it reduces the CPU overhead, Problem Determination is easier, and 
> configurations are kept in a distinct logical box.
> Of course this is at the expense of cost, and space.

Agreed...but in certain situations, ie a widely diverse network,
to follow this purist paradigm, you really need a separate firewall/
uniquely routed subnet. If someone has a 75XX with a T1 Internet
connection, why not let the extra CPU go towards firewall functions.
Granted, you are very limited in logging, authentication, and
proxies or content monitoring, but such capabilities could be made
with proprietary communication to a central firewall/management
server...but then you are really straying away from IOS/whatever OS
each router uses.  In short, if it's built, someone will buy it.
Is it enough people to pay for the development/political maneuvering?
 
---------------------------------------------------------------------------
Andrew Smith ** awsmith at neosoft.com ** Network Engineer ** 1-888-NEOSOFT
       ** "Opportunities multiply as they are seized" - Sun Tzu **
            ** http://www.neosoft.com/neosoft/staff/andrew ** 
---------------------------------------------------------------------------




From michael at memra.com  Tue Mar  4 03:10:09 1997
From: michael at memra.com (Michael Dillon)
Date: Mon, 3 Mar 1997 19:10:09 -0800 (PST)
Subject: Firewall in Routers??
In-Reply-To: <199703040237.UAA11416@rip.ops.neosoft.com>
Message-ID: <Pine.BSI.3.93.970303190324.25640E-100000@sidhe.memra.com>

On Mon, 3 Mar 1997, Andrew Smith wrote:

> > PIX is more of an address translation unit with firewalling
> > capabilities.
> > Firewall-1 is a fully functional Firewall with limited address
> > translation. 

What about Gauntlet? Or Juniper? Or the TIS FWTK? Or Borderware?
Or the Livingston IRX 112? Or KarlBrouter? Or the Norman Firewall?
Or Sidewinder? 

And these are only a few of the dozens of commercial firewalls with
features out the wazoo. Read LAN magazine and Network Computing for
product tests and reviews. Hire a security consultant.

I know what you're asking... What does all this stuff have to do with
running a continent-spanning public network? Nothing at all, of course.

So send one of the following two messages to majordomo at greatcircle.com

subscribe firewalls
subscribe firewalls-digest

Hey, if you're *REALLY* interested you could send both of them!

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From SEAN at SDG.DRA.COM  Tue Mar  4 04:30:51 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Mon, 3 Mar 1997 22:30:51 -0600 (CST)
Subject: The Big Squeeze
Message-ID: <970303223051.a11c@SDG.DRA.COM>

>Computational power required for a route flap is not the issue here.
>
>Many people have stated that, statistically longer prefixes flap
>more.  Unfortunately, they have then said that because of this shorter
>prefixes should have looser dampening parameters put on them, when
>what they really meant was that the longer prefixes should have more
>strict dampening parameters put on them.  Yes it is exactly the same
>thing, but it is an important semantic distinction.  If a group of
>prefixes categorized by a its length tends to flap more than the
>average, then said group should have more strict dampening parameters
>placed on it.

Statistics are soo much fun.

>From a single data point on my router, /24's currently account for 64% of
the routing table entries and for 65% of the flapping prefixes.  /16's
account for 12% of the routing table entries, and 10% of the flapping
prefixes.  It doesn't appear to me there is a significant difference
between flap behaivor of long prefixes and short prefixes.  There are
more long prefixes than short prefixes.  But as a group they both tend
to flap the same proportion of 2% of the routes within the group.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation




From pferguso at cisco.com  Tue Mar  4 04:42:20 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Mon, 03 Mar 1997 23:42:20 -0500
Subject: The Big Squeeze
Message-ID: <3.0.32.19970303234216.006978f4@lint.cisco.com>

At 10:30 PM 3/3/97 -0600, Sean Donelan wrote:

>From a single data point on my router, /24's currently account for 64% of
>the routing table entries and for 65% of the flapping prefixes.  /16's
>account for 12% of the routing table entries, and 10% of the flapping
>prefixes.  It doesn't appear to me there is a significant difference
>between flap behaivor of long prefixes and short prefixes.  There are
>more long prefixes than short prefixes.  But as a group they both tend
>to flap the same proportion of 2% of the routes within the group.

Sorry, I'm not convinced this is the case. There is not enough
empirical evidence.

- paul





From kozowski at structured.net  Tue Mar  4 07:37:48 1997
From: kozowski at structured.net (Eric Kozowski)
Date: Mon, 3 Mar 1997 23:37:48 -0800 (PST)
Subject: The Big Squeeze
Message-ID: <199703040737.XAA16812@teufel.structured.net.>

>>From a single data point on my router, /24's currently account for 64% of
>>the routing table entries and for 65% of the flapping prefixes.  /16's
>>account for 12% of the routing table entries, and 10% of the flapping
>>prefixes.  It doesn't appear to me there is a significant difference
>>between flap behaivor of long prefixes and short prefixes.  There are
>>more long prefixes than short prefixes.  But as a group they both tend
>>to flap the same proportion of 2% of the routes within the group.
>
>Sorry, I'm not convinced this is the case. There is not enough
>empirical evidence.

Is there any empirical evidence to show otherwise?  Id' be interested in
seeing it.


-- 
Eric Kozowski              Senior Network Engineer
eric at structured.net        Structured Network Systems, Inc.
(503)525-9375 FAX          http://www.structured.net/
(800)881-0962 Voice        
PGP Key fingerprint =  2E 5F 3E 6D AA 61 AA 14  D8 FB A4 15 CE 2C D8 8C
'They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759




From tonyb at uunet.pipex.com  Tue Mar  4 08:53:29 1997
From: tonyb at uunet.pipex.com (Tony Barber)
Date: Tue, 4 Mar 1997 08:53:29 +0000 (GMT)
Subject: The Big Squeeze
In-Reply-To: <3.0.32.19970303234216.006978f4@lint.cisco.com> from "Paul Ferguson" at Mar 3, 97 11:42:20 pm
Message-ID: <19970304085329.10934.qmail@pool.pipex.net>

Paul Ferguson wrote:
>
>At 10:30 PM 3/3/97 -0600, Sean Donelan wrote:
>
>>>From a single data point on my router, /24's currently account for 64% of
>>the routing table entries and for 65% of the flapping prefixes.  /16's
>>account for 12% of the routing table entries, and 10% of the flapping
>>prefixes.  It doesn't appear to me there is a significant difference
>>between flap behaivor of long prefixes and short prefixes.  There are
>>more long prefixes than short prefixes.  But as a group they both tend
>>to flap the same proportion of 2% of the routes within the group.
>
>Sorry, I'm not convinced this is the case. There is not enough
>empirical evidence.
>

To back Paul up here..
Tests we have run would indicate that this is not _generally_ the case.
I guess it depends on your point of viewing but we certainly see an
inordinate amount of oscillation in the longer prefix ranges.
(It also depends on the parameters you associate with certain prefixes of 
course ;-)
(Sorry - no facts and figures to back that up)

For instance, take this snapshot and note the /24 from within the 153.96 
network.  The flap column is the interesting one compared with other class Bs.
This is not representative but gives a flavour of what we have been seeing.

They are all from the same originator and it would not take a great amount 
of effort to apply a null0 tie down !


   Network          From            Flaps Duration Reuse    Path

*> 143.222.116.0/24 146.188.31.193  4     01:21:32          702 701 3407 
*d 146.1.0.0        146.188.31.193  10    00:32:21 00:23:20 702 701 3561 6196 6066 
 h 146.103.0.0      146.188.31.193  4     00:17:40          702 701 701 1239 4004 2611 
*> 147.110.0.0      146.188.31.193  2     00:19:12          702 701 1280 2914 2905 
*d 149.209.0.0      146.188.31.193  4     00:02:28 00:28:30 702 701 1800 1755 1273 5539 5430 
*  150.61.0.0       146.188.31.193  1     00:00:26          702 701 3561 2521 4678 
 h 153.96.11.0/24   146.188.31.193  11    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.96.0/22   146.188.31.193  12    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.101.0/24  146.188.31.193  11    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.104.0/22  146.188.31.193  12    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.110.0/24  146.188.31.193  11    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.120.0/23  146.188.31.193  12    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.149.0/24  146.188.31.193  11    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.176.0/22  146.188.31.193  12    02:34:44          702 701 701 1800 1755 517 5501 
 h 153.96.236.0/22  146.188.31.193  12    02:34:51          702 701 701 1800 1755 517 5501 
 h 153.96.243.0/24  146.188.31.193  11    02:34:51          702 701 701 1800 1755 517 5501 
*> 155.141.0.0      146.188.31.193  3     00:14:46          702 701 1800 668 
*> 155.148.0.0      146.188.31.193  3     00:14:46          702 701 1800 668 
*> 156.6.0.0        146.188.31.193  3     00:14:48          702 701 1800 668 
*> 156.36.0.0       146.188.31.193  2     00:19:21          702 701 1280 2914 

--Tony       




From peter at wonderland.org  Tue Mar  4 09:06:15 1997
From: peter at wonderland.org (Peter Galbavy)
Date: Tue, 4 Mar 1997 09:06:15 +0000 (GMT)
Subject: The Big Squeeze
In-Reply-To: <01BC2763.52D270E0@webster.unety.net> from "Jim Fleming" at Mar 2, 97 11:41:58 pm
Message-ID: <199703040906.JAA25028@alice.wonderland.org>

> Would you support charging $$$ for circuits that go in and out of service
> beyond some reasonable amount ?
> 
> Car insurance companies charge people more that have more accidents...:-)

Yes, but car insurance companies don't mandate that they supply the driver.
Poor analogy, but ...

Regards,
-- 
Peter Galbavy
@ Home in Wonderland
http://www.wonderland.org/ http://www.whirl-y-gig.org.uk/ http://www.demon.net
     Be remembered not for your final destination, but for your journey.




From sob at academ.com  Tue Mar  4 09:24:32 1997
From: sob at academ.com (Stan Barber)
Date: Tue, 4 Mar 1997 03:24:32 CST
Subject: Firewall in Routers??
Message-ID: <199703040924.DAA20568@academ.com>

Glynn writes:
> Firewall-1 does address 'hiding' making it look to the external world
> like all connects come from a single IP.

This should go to the "firewalls" list, I think. Anyway, Firewall-1
version 2.1 and later can do single ip to another ip address translation as
well as "hiding" many addresses on one side to make the all look like one
on the other. I have done this for my customers who have needed it and
wanted to use that product.

-- 
Stan   | Academ Consulting Services        |internet: sob at academ.com
Olan   | For more info on academ, see this |uucp: {mcsun|amdahl}!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.




From kegray at cisco.com  Mon Mar  3 13:42:44 1997
From: kegray at cisco.com (Kenneth E. Gray)
Date: Mon, 03 Mar 1997 08:42:44 -0500
Subject: Frame Relay Question
Message-ID: <2.2.32.19970303134244.009c70a0@lint.cisco.com>

Depends on how you want to simulate the frame.  A cisco router can act as a
switch, but it doesn't FECN or BECN...so, if you're actually testing newer
features like Frame Relay Traffic Shaping you would be hard pressed to see
any benefit 8^).  However, quick and dirty emulation can be done with an old
cisco router (I personally use an AGS+ running 10.3 - the highest it can go
- with a ton of serial ports).  

At 04:37 PM 3/3/97 +0000, Scott Reubelt wrote:
>I have a question that could or should be able to be answered by this
>group.
>
>I'm looking to simulate a Frame Relay Internet environment between a
>couple of routers.  This will be internal and not connected to the
>internet, yet.  I will also need the ability to add nodes to this
>simulated WAN.  Does someone have a quick and dirty HW & SW list that I
>will need to purchase??
>
>Thanks,
>-- 
>
>Scott F. Reubelt
>sreubelt at whistle.com  (http://www.whistle.com)
>
>
Ken Gray                                                 ||        ||
ISP Systems Engineer                                     ||        ||
Reston, Virginia   USA                                  ||||      ||||
tel: +1.703.397.5942                             ..:||||||:..:||||||:..
e-mail: kegray at cisco.com                           c i s c o S y s t e m s
fax: +1.703.397.5999





From SEAN at SDG.DRA.COM  Tue Mar  4 16:22:33 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Tue, 4 Mar 1997 10:22:33 -0600 (CST)
Subject: The Big Squeeze
Message-ID: <970304102233.aa73@SDG.DRA.COM>

>To back Paul up here..
>Tests we have run would indicate that this is not _generally_ the case.
>I guess it depends on your point of viewing but we certainly see an
>inordinate amount of oscillation in the longer prefix ranges.
>(It also depends on the parameters you associate with certain prefixes of 
>course ;-)
>(Sorry - no facts and figures to back that up)

It also depends on how you mentally group things.  I agree, there are a
few prefixes that have an inordinate amount of oscillation.   But what
group membership would I assign them?  I've noticed more recently assigned
network numbers seem to flap more than older network numbers.  Perhaps
more importantly, networks in more recently assigned AS numbers seem to
flap more.  Again, this is just raw observations, no real numbers to back
up my feelings.  Don't let the way "show ip bgp flap" happens to group
networks by prefix control your mental schema.

I would much rather see the decision based on how any individual route
behaves rather than the 'neighborhood' the network happens to be located
in.  We might be willing to give a network that has been stable for a
long time a few extra flaps.  While brand new networks that flap would be
better off being 'covered' by a shorter, more stable prefix.

Is the goal to encourage stable routes? or encourage short prefixes?

>For instance, take this snapshot and note the /24 from within the 153.96 
>network.  The flap column is the interesting one compared with other class Bs.
>This is not representative but gives a flavour of what we have been seeing.
>
>They are all from the same originator and it would not take a great amount 
>of effort to apply a null0 tie down !

Or even aggregate them.  But you bring up an important point.  Often all
the routes from the same originator flap together, irregardless of their
prefix length.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation




From cym at acrux.net  Tue Mar  4 16:48:07 1997
From: cym at acrux.net (Brian Tackett)
Date: Tue, 4 Mar 1997 10:48:07 -0600 (CST)
Subject: Firewall in Routers??
In-Reply-To: <199703040237.UAA11416@rip.ops.neosoft.com>
Message-ID: <Pine.GSO.3.93.970304104701.10389E-100000@pluto>

On Mon, 3 Mar 1997, Andrew Smith wrote:

> Agreed...but in certain situations, ie a widely diverse network,
> to follow this purist paradigm, you really need a separate firewall/
> uniquely routed subnet. If someone has a 75XX with a T1 Internet
> connection, why not let the extra CPU go towards firewall functions.

Anyone who has a 75XX and a single T1 needs to be taken out back and shot
by their overly generous accounts payable division ;)






From robert at portal.dx.net  Tue Mar  4 17:47:17 1997
From: robert at portal.dx.net (Robert Laughlin)
Date: Tue, 4 Mar 1997 12:47:17 -0500 (EST)
Subject: Firewall in Routers??
In-Reply-To: <Pine.GSO.3.93.970304104701.10389E-100000@pluto>
Message-ID: <Pine.3.89.9703041252.F24158-0100000@portal>

> On Mon, 3 Mar 1997, Andrew Smith wrote:
> Anyone who has a 75XX and a single T1 needs to be taken out back and shot
> by their overly generous accounts payable division ;)


At a recent Cisco seminar aimed at corporate customers, Cisco was 
specifying the 7500 be used in all the following situations:

1. connecting a single mainframe computer to the campus backbone
2. connecting a large office to the campus backbone
3. connecting a remote office over frame relay at 512 kbs to the campus 
backbone. But do not despair, if you are running at 256kb, you can drop 
back to a 7200.


#3 implies we are over driving our 7500s.  If the 7500 is intended to
handle a single serial line at 512kb, no wonder it seems to get overloaded
on the backbone. 

Best Regards,
Robert Laughlin
----------------------------------------------------------------------------
DataXchange                sales:  800-863-1550            http://www.dx.net
       Network Operations Center:  703-903-7412 -or- 888-903-7412
----------------------------------------------------------------------------







From planting at vfi.com  Tue Mar  4 19:36:12 1997
From: planting at vfi.com (Paul R.D. Lantinga)
Date: Tue, 4 Mar 1997 11:36:12 -0800 (PST)
Subject: Firewall in Routers??
In-Reply-To: <Pine.GSO.3.93.970304104701.10389E-100000@pluto>
Message-ID: <Pine.LNX.3.95.970304113514.1598L-100000@wacky.eit.com>

On Tue, 4 Mar 1997, Brian Tackett wrote:

> On Mon, 3 Mar 1997, Andrew Smith wrote:
> 
> > Agreed...but in certain situations, ie a widely diverse network,
> > to follow this purist paradigm, you really need a separate firewall/
> > uniquely routed subnet. If someone has a 75XX with a T1 Internet
> > connection, why not let the extra CPU go towards firewall functions.
> 
> Anyone who has a 75XX and a single T1 needs to be taken out back and shot
> by their overly generous accounts payable division ;)
> 
Why use them as routers? They make *great* ethernet hubs!  If only an
arcnet card was available for them...

-- 
Paul R.D. Lantinga  #planting at vfi.com#
Systems Administrator, Verifone IC 
"...'proactive' and 'paradigm', aren't these just buzzwords 
that dumb people use to sound important?"-The Simpsons





From william at neosoft.com  Tue Mar  4 22:10:56 1997
From: william at neosoft.com (William S. Duncanson)
Date: Tue, 04 Mar 1997 16:10:56 -0600
Subject: Firewall in Routers??
Message-ID: <3.0.32.19970304155317.01367310@localhost>

At 12:47 3/4/97 -0500, Robert Laughlin wrote:
>> On Mon, 3 Mar 1997, Andrew Smith wrote:
>> Anyone who has a 75XX and a single T1 needs to be taken out back and shot
>> by their overly generous accounts payable division ;)
>
>
>At a recent Cisco seminar aimed at corporate customers, Cisco was 
>specifying the 7500 be used in all the following situations:
>
>1. connecting a single mainframe computer to the campus backbone
>2. connecting a large office to the campus backbone
>3. connecting a remote office over frame relay at 512 kbs to the campus 
>backbone. But do not despair, if you are running at 256kb, you can drop 
>back to a 7200.
>
>
>#3 implies we are over driving our 7500s.  If the 7500 is intended to
>handle a single serial line at 512kb, no wonder it seems to get overloaded
>on the backbone. 

Wonder what they would recommend for a DS1 or a DS3, then.  BFR, anyone?




From garyz at savvis.com  Wed Mar  5 15:41:00 1997
From: garyz at savvis.com (Gary Zimmerman)
Date: Wed, 5 Mar 1997 07:41:00 -0800
Subject: Fw: "routing table slots" and the real problem 
Message-ID: <19970305134821.AAA1557@rock>



----------
> From: Gary Zimmerman <garyz at savvis.com>
> To: Nathan Stratton <nathan at netrail.net>
> Cc: Joseph T. Klein <jtk at titania.net>; nanog at merit.edu; Paul Ferguson  
<pferguso at cisco.com>
> Subject: Re: "routing table slots" and the real problem 
> Date: Wednesday, March 05, 1997 7:29 AM
> 
> Nathan,
> 
> I know we have five 16 slot routers up and running to date and will go to
> 19 soon.  We have had some issues with adding pvc(s) . The new code
should
> be released soon, but it is not good, when you have to take other
customers
> down to add a new one.  Like you we are very please with the gigarouter,
> but they still have a way to go.  Have you tried getting stats from hssi
> cards? Have you tried to look at the bgp tables?  Have you tried
> communities and federations?
> 
> Any way I am not upset with them, I know they have alot behind, the fact
> that they are open is the main plus, that is why I am carring their flag,
> but they really need to get behind scaling the product.  What a problem,
> sell more in one month than you sold in the first three years.
> 
> Anyway, let's keep in touch.  I am getting some code this week that
should
> really make a big difference.
> 
> Gary Zimmerman 
> 
> ----------
> > From: Nathan Stratton <nathan at netrail.net>
> > To: Gary Zimmerman <garyz at savvis.com>
> > Cc: Joseph T. Klein <jtk at titania.net>; nanog at merit.edu; Paul Ferguson  
> <pferguso at cisco.com>
> > Subject: Re: "routing table slots" and the real problem 
> > Date: Monday, March 03, 1997 3:16 PM
> > 
> > On Mon, 3 Mar 1997, Gary Zimmerman wrote:
> > 
> > > Has anyone looked at Ascend's (NetStar Gigarouter).  We have and like
> the
> > > direction.  If they continue to deliver, I think they are going in
the
> > > right direction.  Still some parts missing, I hope we can hold on
until
> > > they get here, but the direction is right.  I think the open idea is
> the
> > > only way to go on this issue.
> > 
> > We have been using them for about 5 months now, and I like them a lot.
We
> > have worked with Ascend to fix a large numbers of problems. They are
very
> > stable now, and have a lot of people working to make them better. 
> > 
> > 
> > Nathan Stratton                                President, NetRail,Inc.
> >
------------------------------------------------------------------------
> > Phone   (888)NetRail                           NetRail, Inc.
> > Fax     (404)522-1939                          230 Peachtree Suite 500
> > WWW     http://www.netrail.net/                Atlanta, GA 30303
> >
------------------------------------------------------------------------
> > "Therefore do not worry about tomorrow, for tomorrow will worry about 
> > itself. Each day has enough trouble of its own."           Matthew 6:34
> > 




From doleary at cisco.com  Wed Mar  5 17:17:34 1997
From: doleary at cisco.com (dave o'leary)
Date: Wed, 5 Mar 1997 09:17:34 -0800 (PST)
Subject: Firewall in Routers??
In-Reply-To: <3.0.32.19970304155317.01367310@localhost>
Message-ID: <v03007879af42def72000@[171.68.179.47]>

At 22:10 -0000 3/4/97, William S. Duncanson wrote:
>>At a recent Cisco seminar aimed at corporate customers, Cisco was
>>specifying the 7500 be used in all the following situations:
>>
>>1. connecting a single mainframe computer to the campus backbone
>>2. connecting a large office to the campus backbone
>>3. connecting a remote office over frame relay at 512 kbs to the campus
>>backbone. But do not despair, if you are running at 256kb, you can drop
>>back to a 7200.
>>
>>
>>#3 implies we are over driving our 7500s.  If the 7500 is intended to
>>handle a single serial line at 512kb, no wonder it seems to get overloaded
>>on the backbone.

What was the title of the seminar you were attending and who was the
speaker?  Was this something on a slide or just something that the speaker
said?

#1 is true since the CIP (Channel Interface Processor) only plugs into
	a 7000/7500 class box.  (unless of course you are using some
	other channel attached device and connecting the router via
	token ring or serial lines).

We'll try to sort out which mkting person was out running amok
and fix the presentation (and most likely the speaker).

thanks,
						dave






From robert at portal.dx.net  Wed Mar  5 18:12:02 1997
From: robert at portal.dx.net (Robert Laughlin)
Date: Wed, 5 Mar 1997 13:12:02 -0500 (EST)
Subject: Firewall in Routers??
In-Reply-To: <v03007879af42def72000@[171.68.179.47]>
Message-ID: <Pine.3.89.9703051312.C12871-0100000@portal>

On Wed, 5 Mar 1997, dave o'leary wrote:
> What was the title of the seminar you were attending and who was the
> speaker?  Was this something on a slide or just something that the speaker
> said?
> 
> We'll try to sort out which mkting person was out running amok
> and fix the presentation (and most likely the speaker).
> 
> thanks,
> 						dave

The seminar was called "Building a Global Corporate Intranet". As far as I
can tell this same seminar is on the road being presented all over the
country.  The reference to the 7500 routers is on the slides. To the best
of my recollection, the speaker never refered to the routers by model
number. I attended the presentation at Tyson's Corner.  There were about
400 persons at the seminar. The publication number of the handout
containing the slides is:  0563_02F7 / 843601-01

Your welcome,
Robert Laughlin
----------------------------------------------------------------------------
DataXchange                sales:  800-863-1550            http://www.dx.net
       Network Operations Center:  703-903-7412 -or- 888-903-7412
----------------------------------------------------------------------------






From doleary at cisco.com  Wed Mar  5 18:43:42 1997
From: doleary at cisco.com (dave o'leary)
Date: Wed, 5 Mar 1997 10:43:42 -0800 (PST)
Subject: Firewall in Routers??
In-Reply-To: <Pine.3.89.9703051312.C12871-0100000@portal>
References: <v03007879af42def72000@[171.68.179.47]>
Message-ID: <v03007887af42fefca5c8@[171.68.179.47]>


Thanks for the info, Robert.

And now back to your irregularly scheduled unrelated threads....

					dave

At 18:12 -0000 3/5/97, Robert Laughlin wrote:
>On Wed, 5 Mar 1997, dave o'leary wrote:
>> What was the title of the seminar you were attending and who was the
>> speaker?  Was this something on a slide or just something that the speaker
>> said?
>>
>> We'll try to sort out which mkting person was out running amok
>> and fix the presentation (and most likely the speaker).
>>
>> thanks,
>> 						dave
>
>The seminar was called "Building a Global Corporate Intranet". As far as I
>can tell this same seminar is on the road being presented all over the
>country.  The reference to the 7500 routers is on the slides. To the best
>of my recollection, the speaker never refered to the routers by model
>number. I attended the presentation at Tyson's Corner.  There were about
>400 persons at the seminar. The publication number of the handout
>containing the slides is:  0563_02F7 / 843601-01
>
>Your welcome,
>Robert Laughlin
>----------------------------------------------------------------------------
>DataXchange                sales:  800-863-1550            http://www.dx.net
>       Network Operations Center:  703-903-7412 -or- 888-903-7412
>----------------------------------------------------------------------------

?






From glynn at nol.co.uk  Wed Mar  5 23:05:01 1997
From: glynn at nol.co.uk (Glynn Stanton)
Date: Wed, 5 Mar 1997 23:05:01 +0000 (GMT)
Subject: Firewall in Routers??
In-Reply-To: <v03007887af42fefca5c8@[171.68.179.47]>
Message-ID: <Pine.LNX.3.93.970305203350.25077A-100000@obewan.n-e-t.co.uk>

Sadly the amount of traffic saying "this isnt on topic" 
is greater than the amount of traffic caused by the thread.

Even more sadly, if you discuss routers on the firewall list.. 
you get another group of blinkered "firewall experts" who whine
about it not being on topic.

The problem comes when you have a design that requires you to tread the
fine line between buying a router with firewalling capabilities and
buying a firewall with routing capabilities.
The router gurus refer you to a security expert....
The security expert says "whats BGP ? OSPF?... I dont deal with layer 3"

Motto: a blinkered view will only portray a narrow picture.

*sigh*

Glynn Stanton






From pst at jnx.com  Wed Mar  5 23:17:26 1997
From: pst at jnx.com (Paul Traina)
Date: 05 Mar 1997 15:17:26 -0800
Subject: karl and paul, expostulating
In-Reply-To: paul@vix.com's message of 20 Feb 97 03:23:29 GMT
References: <199702200309.VAA29466@Jupiter.Mcs.Net>
	<199702200323.TAA19065@wisdom.home.vix.com>
Message-ID: <7yu3mqvshl.fsf@base.jnx.com>

[back from the grave]

paul at vix.com (Paul A Vixie) writes:
> Filtering packets based on source address makes Ciscos go way slow on 
> every packet.  Filtering based on destination address makes Ciscos go
> very fast on most packets and a little slower on SYN-ACKs.

While I agree with what you're trying to do, your statement about filtering
packets on source addresses is not correct.  It's exactly the same hit.

Paul
-- 
The streets will flow with the blood of non-believers.





From route at ceap.net  Thu Mar  6 00:41:36 1997
From: route at ceap.net (E Gutierrez)
Date: Wed, 5 Mar 1997 16:41:36 -0800 (PST)
Subject: MCI noc
Message-ID: <Pine.LNX.3.95.970305162702.4444B-100000@lethe.ceap.net>



Greetings-
 
   I work for the Network Operations Center for the Army Corps of
Engineers.  We (ceap.net) are basically the ISP for the entire Corps.  One
of our internet service gateways is provided by MCI and we are having a
hell of a time getting a service issue with them resolved. Some time at
about 1:00 pm PST that gateway went down.  Apparently, someone in their
provisioning group has decided to administratively shut down their
interface to us. That much I gathered from talking to someone in their
Internet group. He couldn't give me a good reason why this was the case
and the vapid account managers can't even find a circuit id and can't get
their connections to the MCI noc to do anything. I haven't been able to
get a hold of any one from their Internet group since then. This is
absurd.  Is there anyone from MCI here who might be able to give me a
hand? 


--------------------------------------------
Esteban Gutierrez
US Army Corps Of Engineers
CEAP Network Operations
(503) 326-6126
noc at ceap.net






From randy at psg.com  Thu Mar  6 01:13:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 5 Mar 97 17:13 PST
Subject: measurement
Message-ID: <m0w2Rks-0007zYC@rip.psg.com>

So who actually measures their network performance and how?

randy




From route at ceap.net  Thu Mar  6 01:26:03 1997
From: route at ceap.net (E Gutierrez)
Date: Wed, 5 Mar 1997 17:26:03 -0800 (PST)
Subject: MCI noc
In-Reply-To: <Pine.LNX.3.95.970305162702.4444B-100000@lethe.ceap.net>
Message-ID: <Pine.LNX.3.95.970305172218.4444E-100000@lethe.ceap.net>



 The connection back up. MCI has to figure out how to get their
billing people to talk to their account service people and their INOC
group.

 --------------------------------------------
 Esteban Gutierrez
 US Army Corps Of Engineers
 CEAP Network Operations
 (503) 326-6126
 noc at ceap.net



On Wed, 5 Mar 1997, E Gutierrez wrote:

> 
> 
> Greetings-
>  
>    I work for the Network Operations Center for the Army Corps of
> Engineers.  We (ceap.net) are basically the ISP for the entire Corps.  One
> of our internet service gateways is provided by MCI and we are having a
> hell of a time getting a service issue with them resolved. Some time at
> about 1:00 pm PST that gateway went down.  Apparently, someone in their
> provisioning group has decided to administratively shut down their
> interface to us. That much I gathered from talking to someone in their
> Internet group. He couldn't give me a good reason why this was the case
> and the vapid account managers can't even find a circuit id and can't get
> their connections to the MCI noc to do anything. I haven't been able to
> get a hold of any one from their Internet group since then. This is
> absurd.  Is there anyone from MCI here who might be able to give me a
> hand? 
> 
> 
> --------------------------------------------
> Esteban Gutierrez
> US Army Corps Of Engineers
> CEAP Network Operations
> (503) 326-6126
> noc at ceap.net
> 
> 





From danny at genuity.net  Thu Mar  6 01:27:31 1997
From: danny at genuity.net (Danny McPherson)
Date: Wed, 05 Mar 1997 18:27:31 -0700
Subject: MCI noc 
Message-ID: <199703060127.SAA06059@cognition.genuity.net>


trouble at mci.net or 800-663-9932... 


>    I work for the Network Operations Center for the Army Corps of
> Engineers.  We (ceap.net) are basically the ISP for the entire Corps.  One
> of our internet service gateways is provided by MCI and we are having a
> hell of a time getting a service issue with them resolved. Some time at
> about 1:00 pm PST that gateway went down.  Apparently, someone in their
> provisioning group has decided to administratively shut down their
> interface to us. That much I gathered from talking to someone in their
> Internet group. He couldn't give me a good reason why this was the case
> and the vapid account managers can't even find a circuit id and can't get
> their connections to the MCI noc to do anything. I haven't been able to
> get a hold of any one from their Internet group since then. This is
> absurd.  Is there anyone from MCI here who might be able to give me a
> hand? 
> 
> 
> --------------------------------------------
> Esteban Gutierrez
> US Army Corps Of Engineers
> CEAP Network Operations
> (503) 326-6126
> noc at ceap.net
> 
> 






From lists at reflections.mindspring.com  Thu Mar  6 03:46:32 1997
From: lists at reflections.mindspring.com (Todd Graham Lewis)
Date: Wed, 5 Mar 1997 22:46:32 -0500 (EST)
Subject: measurement
In-Reply-To: <m0w2Rks-0007zYC@rip.psg.com>
Message-ID: <Pine.LNX.3.95.970305224602.771A-100000@reflections.mindspring.com>

On Wed, 5 Mar 1997, Randy Bush wrote:

> So who actually measures their network performance

Us.

> and how?

Numerically.

__
Todd Graham Lewis          MindSpring Enterprises      tlewis at mindspring.com





From alex at nac.net  Thu Mar  6 03:03:10 1997
From: alex at nac.net (Alex Rubenstein)
Date: Wed, 05 Mar 1997 23:03:10 -0400
Subject: measurement
Message-ID: <3.0.32.19970305230306.011299b0@mail.nac.net>


You are WAY too helpfu;


At 10:46 PM 3/5/97 -0500, Todd Graham Lewis wrote:
>On Wed, 5 Mar 1997, Randy Bush wrote:
>
>> So who actually measures their network performance
>
>Us.
>
>> and how?
>
>Numerically.
>
>__
>Todd Graham Lewis          MindSpring Enterprises      tlewis at mindspring.com
>
>




From bill at geo.net  Thu Mar  6 05:45:45 1997
From: bill at geo.net (Bill McCauley)
Date: Wed, 05 Mar 1997 21:45:45 -0800
Subject: measurement
Message-ID: <2.2.32.19970306054545.0076f584@zeus.geo.net>

Randy,

>So who actually measures their network performance and how?

We use a traffic flow monitoring system from Kaspia Systems.
(www.kaspia.com)  The Kaspia product collects all sorts of data from router
ports and RMON probes, stores the data and performs various trend analysis.
We collect traffic flow, router CPU usage and router memory information plus
various errors.  There is a data reduction process which runs once a day,
and a very nifty web interface.  The product isn't cheap, but the system
definitely fills a void here.  

Maybe I should organize a talk on what we're doing with it for an upcoming
NANOG?  As an old instrumentation engineer, I think the basis of our use of
the tool is pretty solid.  Plus, I actually developed a means for
calibration of the accuracy of the flow data.  Haven't had time yet to work
out a validation for the trends, but I'll get to it one of these decades.

Also, the Kaspia people will give you a thirty day trial on their product at
no charge.

Regards,

Bill McCauley





From randy at psg.com  Thu Mar  6 06:15:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 5 Mar 97 22:15 PST
Subject: measurement
References: <m0w2Rks-0007zYC@rip.psg.com>
	<Pine.LNX.3.95.970305224602.771A-100000@reflections.mindspring.com>
Message-ID: <m0w2WT0-0007zWC@rip.psg.com>

Todd Graham Lewis <lists at reflections.mindspring.com>
>> So who actually measures their network performance
> Us.
>> and how?
> Numerically.

I received five useful answers via private email, a few going into detail.
You know who you are.  Thanks.  I will summarize in a day or two.

One clueless wiseass pollutes publicly, and with incorrect grammar.
Figures, eh?  Welcome to the new internet.  Sigh.

randy




From davidc at apnic.net  Thu Mar  6 06:21:38 1997
From: davidc at apnic.net (David R. Conrad)
Date: Thu, 06 Mar 1997 15:21:38 +0900
Subject: measurement 
In-Reply-To: Your message of "Wed, 05 Mar 1997 21:45:45 PST."
             <2.2.32.19970306054545.0076f584@zeus.geo.net> 
Message-ID: <199703060621.PAA00384@palmtree.jp.apnic.net>

Hi,

I might suggest this would be an appropriate topic for the upcoming
IEPG meeting the Sunday before the IETF as there is interest in
traffic flow outside the NANOG community (e.g., Nevil Brownlee and
netramet...)

Regards,
-drc
--------
>We use a traffic flow monitoring system from Kaspia Systems.
>(www.kaspia.com)  
...
>Maybe I should organize a talk on what we're doing with it for an upcoming
>NANOG? 




From william at neosoft.com  Thu Mar  6 07:35:20 1997
From: william at neosoft.com (William S. Duncanson)
Date: Thu, 6 Mar 1997 01:35:20 -0600
Subject: in-addr problems
Message-ID: <B0000002657@apocalypse.ops.neosoft.com>

> Has anyone noticed lately that there have been a lot of problems getting
> in-addr information on ms.uu.net ip addresses?  At first I thought it was
a
> problem with a.root-servers.net, but it appears to be on the MSN/UUNet
> side.  We've had numerous customers of theirs complain that they could
not
> get to some of our sites, or that it was taking a lot longer than usual. 
> We looked at the logs, and sure enough, we're getting "refused connect
from
> aaa.xxx.yyy.zzz: gethostbyaddr() failed" messages from the IP addresses
> that they're coming from.  So, the question is, should we disable this
> temporarily, or just wait for UUNet/MSN to get their act together?
> 
> William S. Duncanson
> william at neosoft.com
> NeoSoft Operations
> (888) NEOSOFT or (713) 968-5800
> 




From peter at wonderland.org  Thu Mar  6 09:16:43 1997
From: peter at wonderland.org (Peter Galbavy)
Date: Thu, 6 Mar 1997 09:16:43 +0000 (GMT)
Subject: Paul Vixie did not spam you (this is an automated response)
In-Reply-To: <199703060213.SAA02103@gw.home.vix.com> from "Paul Vixie" at Mar 5, 97 06:13:07 pm
Message-ID: <199703060916.JAA25925@alice.wonderland.org>

cc'ed to nanog@ FYI

Paul Vixie wrote:
> Today I started receiving a massive number of e-mail bounces and complaints
> about spam.  I immediately realized that someone had abused the network in my
> name; sure enough, I shortly received the evidence shown below.  I apologize
> for this form letter response, but I'm expecting another 10,000 complaints and
> I do not plan to send personalized replies to each one.

[Posting from home, since thats where I get nanog@, but posting
with my work hat on - Reply-To: set to peter at demon.net]

Please note that we were hit by the same spammer. The original
message went out, claiming it was from one of our customers (another
thread last week) when in actual fact it is from an address block
assigned the enterprise.net.

I understand that this ISP (Enterprise in the UK) has made a
statement to the effect that they in turn have traced this to a
Compuserve location. Since the only Recieved: header with anything
useful in it has one of their IP addrs in, this is difficult to
check.

Just for some background, the spammer proceeded to set the Reply-To:
address to a range of mail-news gateways (demon.service at news.demon.co.uk
was one) and really wound people up. This range of gateways have
now been permanently closed, which is in itself a great shame. I
would advise other out there to check if they have similar legacy
newsgroup@ type gateways operating and close them to reduce the
backlash of this type of spam.

Regards,
-- 
Peter Galbavy
@ Home in Wonderland
http://www.wonderland.org/ http://www.whirl-y-gig.org.uk/ http://www.demon.net
     Be remembered not for your final destination, but for your journey.




From pferguso at cisco.com  Thu Mar  6 15:08:55 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Thu, 06 Mar 1997 10:08:55 -0500
Subject: 03/05/97 Internet Routing Problems
Message-ID: <3.0.32.19970306100850.00720db0@lint.cisco.com>

At 03:00 PM 3/6/97 GMT, stats at merit.edu wrote:

>
>Reserved Network and Host Announcements
>---------------------------------------
>0/0 at PacBell from MIBX (6218) ASPATH=6218 Incomplete
>0/0 at PacBell from MIBX (6218) ASPATH=6218 Incomplete
>10/8 at PacBell from MIBX (6218) ASPATH=6218 IGP


FYI.

This is a prinicpal example of why people should be filtering on
both inbound & outbound announcements of default & RFC1918 address
space.

- paul





From amb at xara.net  Thu Mar  6 15:39:13 1997
From: amb at xara.net (Alex.Bligh)
Date: Thu, 06 Mar 1997 15:39:13 +0000
Subject: 03/05/97 Internet Routing Problems 
In-Reply-To: Your message of "Thu, 06 Mar 1997 10:08:55 EST."
             <3.0.32.19970306100850.00720db0@lint.cisco.com> 
Message-ID: <199703061539.PAA19745@diamond.xara.net>

> This is a prinicpal example of why people should be filtering on
> both inbound & outbound announcements of default & RFC1918 address
> space.

Well we do this (we also filter out some other things we
don't want to hear from other people), but this set me
thinking. Is there anyone who actually has a good reason
to propogate default and reserved addresses through the RA?
Wouldn't it be a good move for the RA itself to filter
these announcements (in addition to what's in the policy)?

Alex Bligh
Xara Networks









From prt at Teleglobe.CA  Thu Mar  6 15:52:22 1997
From: prt at Teleglobe.CA (Pierre Thibaudeau)
Date: Thu, 6 Mar 1997 10:52:22 -0500 (EST)
Subject: 03/05/97 Internet Routing Problems 
In-Reply-To: <199703061539.PAA19745@diamond.xara.net>
Message-ID: <Pine.HPP.3.94.970306104830.6956D-100000@alpha.Teleglobe.CA>

On Thu, 6 Mar 1997, Alex.Bligh wrote:

>    > This is a prinicpal example of why people should be filtering on
>    > both inbound & outbound announcements of default & RFC1918 address
>    > space.
>    
>    Well we do this (we also filter out some other things we
>    don't want to hear from other people), but this set me
>    thinking. Is there anyone who actually has a good reason
>    to propogate default and reserved addresses through the RA?
>    Wouldn't it be a good move for the RA itself to filter
>    these announcements (in addition to what's in the policy)?

Alex,

At least in theory, it is. Read paragraph titled "The Routing Arbiter's
Responsibility" in <http://www.ra.net/RADB.tools.docs/radbserv.html>.


>    
>    Alex Bligh
>    Xara Networks
>    
>    
>    
>    
>    
>    

__

Pierre Thibaudeau                     |   e-mail: <prt at Teleglobe.CA>
TELEGLOBE CANADA                      |
1000, rue de La Gauchetiere ouest     |      Tel: +1-514-868-7257
Montreal, QC   H3B 4X5                |
Canada                                |      fax: +1-514-868-8446





From labovit at merit.edu  Thu Mar  6 16:28:03 1997
From: labovit at merit.edu (Craig Labovitz)
Date: Thu, 06 Mar 1997 11:28:03 -0500
Subject: 03/05/97 Internet Routing Problems 
In-Reply-To: Your message of Thu, 06 Mar 1997 15:39:13 +0000.
	     <199703061539.PAA19745@diamond.xara.net> 
Message-ID: <199703061628.LAA15604@merit.edu>


Hi Alex,

Two quick points:

* The RA route servers no longer exist. Around January 1 of this year, the NSF 
sponsored route servers were decomissioned. At serveral exchange points, Route 
Server services are now being provided by the commercially funded RSNG project 
(see http://www.rsng.net).  Other aspects of the RA project (including some 
research, RPSL, and IRR management/development) have continued.

* The RSNG route servers announce routes according to policy registered in the 
IRR. Any routes not explicitly allowed by policy (RFC-1918 routes, default, 
etc.) are effectively filtered in announcements to all RS peers.

- Craig


at Thu, 06 Mar 1997 15:39:13 GMT, you wrote:
> > This is a prinicpal example of why people should be filtering on
> > both inbound & outbound announcements of default & RFC1918 address
> > space.
> 
> Well we do this (we also filter out some other things we
> don't want to hear from other people), but this set me
> thinking. Is there anyone who actually has a good reason
> to propogate default and reserved addresses through the RA?
> Wouldn't it be a good move for the RA itself to filter
> these announcements (in addition to what's in the policy)?
> 
> Alex Bligh
> Xara Networks
> 
> 
> 
> 
> 

-- 
Craig Labovitz				labovit at merit.edu
Merit Network, Inc.			http://www.merit.edu/~labovit
4251 Plymouth  Road, Suite C.		(313) 764-0252 (office)
Ann Arbor, MI 48105-2785                (313) 647-3185 (fax)






From dorn at atl.eni.net  Thu Mar  6 17:12:57 1997
From: dorn at atl.eni.net (Dorn Hetzel)
Date: Thu, 6 Mar 1997 12:12:57 -0500
Subject: 03/05/97 Internet Routing Problems
In-Reply-To: <3.0.32.19970306100850.00720db0@lint.cisco.com>; from Paul Ferguson on Mar 6, 1997 10:08:55 -0500
References: <3.0.32.19970306100850.00720db0@lint.cisco.com>
Message-ID: <Mutt.19970306121257.dorn@atl.eni.net>

Yeah,

They did it to us to...  for a little while...

	-Dorn

Paul Ferguson writes:
> At 03:00 PM 3/6/97 GMT, stats at merit.edu wrote:
> 
> >
> >Reserved Network and Host Announcements
> >---------------------------------------
> >0/0 at PacBell from MIBX (6218) ASPATH=6218 Incomplete
> >0/0 at PacBell from MIBX (6218) ASPATH=6218 Incomplete
> >10/8 at PacBell from MIBX (6218) ASPATH=6218 IGP
> 
> 
> FYI.
> 
> This is a prinicpal example of why people should be filtering on
> both inbound & outbound announcements of default & RFC1918 address
> space.
> 
> - paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 289 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/19970306/33d87bf1/attachment.sig>

From geoffw at precipice.v-site.net  Thu Mar  6 20:14:27 1997
From: geoffw at precipice.v-site.net (Geoff White)
Date: Thu, 6 Mar 1997 12:14:27 -0800 (PST)
Subject: Paul Vixie did not spam you (this is an automated response)
In-Reply-To: <199703060916.JAA25925@alice.wonderland.org>
Message-ID: <Pine.SUN.3.95.970306120524.12349C-100000@precipice.v-site.net>



On Thu, 6 Mar 1997, Peter Galbavy wrote:

> cc'ed to nanog@ FYI
> 
> Paul Vixie wrote:
> > Today I started receiving a massive number of e-mail bounces and complaints
> > about spam.  I immediately realized that someone had abused the network in my
> > name; sure enough, I shortly received the evidence shown below.  I apologize
> > for this form letter response, but I'm expecting another 10,000 complaints and
> > I do not plan to send personalized replies to each one.
> 
> [Posting from home, since thats where I get nanog@, but posting
> with my work hat on - Reply-To: set to peter at demon.net]
> 
> Please note that we were hit by the same spammer. The original
> message went out, claiming it was from one of our customers (another
> thread last week) when in actual fact it is from an address block
> assigned the enterprise.net.


We have also been hit by the same spammer, he is using
exchangecurrency at forprofit.com as his reply-field (which is one of my
clients) Apparently one of the people at forprofit.com send a message to
on of the spammers "superiors" (I think he just sent the message to the
NOC contact of the host on a reply field that was sent to him :) and
shortly after that, their domain name was showing up in the reply field of
the spam.  I am flushing all mail heading for
exchangecurrency at forprofit.com to /dev/null.  I've done a little research,
aparently the original postings were using a domain...

precipice:{root}67-> whois moneyworld.com
Financial Connections, Inc (MONEYWORLD-DOM)
   2508 5th Ave, #104
   Seattle, WA 98121
 
   Domain Name: MONEYWORLD.COM
 
   Administrative Contact, Technical Contact, Zone Contact, Billing
Contact:
      Williams, Bob  (BW747)  willie at MONEYWORLD.COM
      206 269 0846
 
   Record last updated on 13-Oct-96.
   Record created on 26-Oct-95.
 
   Domain servers in listed order:
 
   NSH.WORLDHELP.NET            206.81.217.6
   NSS.MONEYWORLD.COM           205.227.174.9


No answer at the number and apparently non of these DNS machines are
currently on the net... hmm.

This guy  is causing my mail queues to fill up with a ton of bounces and
flames and I don't appreciate it one bit.  The guys at forprofit have some
friends at the FBI, but they say that everytime they try to go after these
guys, the ISPs won't co-operate :)





					Geoff White
					Virtual Sites
					http://www.v-site.net
					(415)437-4600  fax (415)437-4601







From rob at elite.exodus.net  Thu Mar  6 21:59:08 1997
From: rob at elite.exodus.net (Robert Bowman)
Date: Thu, 6 Mar 1997 13:59:08 -0800 (PST)
Subject: Paul Vixie did not spam you (this is an automated response)
In-Reply-To: <Pine.SUN.3.95.970306120524.12349C-100000@precipice.v-site.net> from "Geoff White" at Mar 6, 97 12:14:27 pm
Message-ID: <199703062159.NAA20705@elite.exodus.net>

Financial Connection has been a lovely pest for several years now.  
Exodus had the pleasure of having this customer connected to us in 
Seattle until we realized the company's illegal behavior and terminated
their service.

If anyone would like more information on how to contact this person
or the history of massive spamming done by Financial Connection,
please direct an email to myself.

Rob
rob at exodus.net
> 
> 
> 
> On Thu, 6 Mar 1997, Peter Galbavy wrote:
> 
> > cc'ed to nanog@ FYI
> > 
> > Paul Vixie wrote:
> > > Today I started receiving a massive number of e-mail bounces and complaints
> > > about spam.  I immediately realized that someone had abused the network in my
> > > name; sure enough, I shortly received the evidence shown below.  I apologize
> > > for this form letter response, but I'm expecting another 10,000 complaints and
> > > I do not plan to send personalized replies to each one.
> > 
> > [Posting from home, since thats where I get nanog@, but posting
> > with my work hat on - Reply-To: set to peter at demon.net]
> > 
> > Please note that we were hit by the same spammer. The original
> > message went out, claiming it was from one of our customers (another
> > thread last week) when in actual fact it is from an address block
> > assigned the enterprise.net.
> 
> 
> We have also been hit by the same spammer, he is using
> exchangecurrency at forprofit.com as his reply-field (which is one of my
> clients) Apparently one of the people at forprofit.com send a message to
> on of the spammers "superiors" (I think he just sent the message to the
> NOC contact of the host on a reply field that was sent to him :) and
> shortly after that, their domain name was showing up in the reply field of
> the spam.  I am flushing all mail heading for
> exchangecurrency at forprofit.com to /dev/null.  I've done a little research,
> aparently the original postings were using a domain...
> 
> precipice:{root}67-> whois moneyworld.com
> Financial Connections, Inc (MONEYWORLD-DOM)
>    2508 5th Ave, #104
>    Seattle, WA 98121
>  
>    Domain Name: MONEYWORLD.COM
>  
>    Administrative Contact, Technical Contact, Zone Contact, Billing
> Contact:
>       Williams, Bob  (BW747)  willie at MONEYWORLD.COM
>       206 269 0846
>  
>    Record last updated on 13-Oct-96.
>    Record created on 26-Oct-95.
>  
>    Domain servers in listed order:
>  
>    NSH.WORLDHELP.NET            206.81.217.6
>    NSS.MONEYWORLD.COM           205.227.174.9
> 
> 
> No answer at the number and apparently non of these DNS machines are
> currently on the net... hmm.
> 
> This guy  is causing my mail queues to fill up with a ton of bounces and
> flames and I don't appreciate it one bit.  The guys at forprofit have some
> friends at the FBI, but they say that everytime they try to go after these
> guys, the ISPs won't co-operate :)
> 
> 
> 
> 
> 
> 					Geoff White
> 					Virtual Sites
> 					http://www.v-site.net
> 					(415)437-4600  fax (415)437-4601
> 
> 
> 





From rjones at wicker.com  Thu Mar  6 21:15:40 1997
From: rjones at wicker.com (Ry Jones)
Date: Thu, 6 Mar 1997 13:15:40 -0800
Subject: Paul Vixie did not spam you (this is an automated response)
Message-ID: <01BC2A30.7E053AC0@rjones.corp.netcom.com>

These are the same guys that the WA state AG shut down for mail fraud. I'm suprised they have the nuts to pop up again; this topic was beat to death on Seattle.General about 5 or 6 months ago.

----------
From: 	Geoff White[SMTP:geoffw at precipice.v-site.net]
Sent: 	Thursday, March 06, 1997 4:14 AM
To: 	peter at demon.net
Cc: 	Paul Vixie; geertj at ripe.net; nanog at merit.edu
Subject: 	Re: Paul Vixie did not spam you (this is an automated response)



On Thu, 6 Mar 1997, Peter Galbavy wrote:

> cc'ed to nanog@ FYI
> 
> Paul Vixie wrote:
> > Today I started receiving a massive number of e-mail bounces and complaints
> > about spam.  I immediately realized that someone had abused the network in my
> > name; sure enough, I shortly received the evidence shown below.  I apologize
> > for this form letter response, but I'm expecting another 10,000 complaints and
> > I do not plan to send personalized replies to each one.
> 
> [Posting from home, since thats where I get nanog@, but posting
> with my work hat on - Reply-To: set to peter at demon.net]
> 
> Please note that we were hit by the same spammer. The original
> message went out, claiming it was from one of our customers (another
> thread last week) when in actual fact it is from an address block
> assigned the enterprise.net.


We have also been hit by the same spammer, he is using
exchangecurrency at forprofit.com as his reply-field (which is one of my
clients) Apparently one of the people at forprofit.com send a message to
on of the spammers "superiors" (I think he just sent the message to the
NOC contact of the host on a reply field that was sent to him :) and
shortly after that, their domain name was showing up in the reply field of
the spam.  I am flushing all mail heading for
exchangecurrency at forprofit.com to /dev/null.  I've done a little research,
aparently the original postings were using a domain...

precipice:{root}67-> whois moneyworld.com
Financial Connections, Inc (MONEYWORLD-DOM)
   2508 5th Ave, #104
   Seattle, WA 98121
 
   Domain Name: MONEYWORLD.COM
 
   Administrative Contact, Technical Contact, Zone Contact, Billing
Contact:
      Williams, Bob  (BW747)  willie at MONEYWORLD.COM
      206 269 0846
 
   Record last updated on 13-Oct-96.
   Record created on 26-Oct-95.
 
   Domain servers in listed order:
 
   NSH.WORLDHELP.NET            206.81.217.6
   NSS.MONEYWORLD.COM           205.227.174.9


No answer at the number and apparently non of these DNS machines are
currently on the net... hmm.

This guy  is causing my mail queues to fill up with a ton of bounces and
flames and I don't appreciate it one bit.  The guys at forprofit have some
friends at the FBI, but they say that everytime they try to go after these
guys, the ISPs won't co-operate :)





					Geoff White
					Virtual Sites
					http://www.v-site.net
					(415)437-4600  fax (415)437-4601









From dwarren at Alpha.NetUSA.Net  Thu Mar  6 21:34:32 1997
From: dwarren at Alpha.NetUSA.Net (Douglas Warren)
Date: Thu, 6 Mar 1997 16:34:32 -0500 (EST)
Subject: Paul Vixie did not spam you (this is an automated response)
In-Reply-To: <01BC2A30.7E053AC0@rjones.corp.netcom.com>
Message-ID: <Pine.LNX.3.95.970306163228.10429L-100000@Alpha.NetUSA.Net>

> No answer at the number and apparently non of these DNS machines are
> currently on the net... hmm.
> This guy  is causing my mail queues to fill up with a ton of bounces and
> flames and I don't appreciate it one bit.  The guys at forprofit have some
> friends at the FBI, but they say that everytime they try to go after these
> guys, the ISPs won't co-operate :)

We had the opposite recently, one of our customers was sending out spam.
After we canceled the account, they tried a chargeback on the credit
card, and we contacted the FBI for computer fraud, as the account was
purchased and contracted for personal use.  Personally I'd always cooperate
in such a matter.

---
|Douglas ``Wildcat'' Warren |Email: dwarren at netusa.net|  Jura gur tbireazrag
|Network/Security Consultant|Phone: (516) 543-0234    | bhgynjf Pelcgbtencul,
|President of SBCS a chapter|  Fax: (516) 543-0274    |  bayl pevzvanyf jvyy
|of the ACM.                |  PGP: finger dwarren    |     unir cevinpl





From mpetach at netflight.com  Fri Mar  7 01:25:07 1997
From: mpetach at netflight.com (Matthew Petach)
Date: Thu, 6 Mar 1997 17:25:07 -0800 (PST)
Subject: measurement
In-Reply-To: <m0w2Rks-0007zYC@rip.psg.com> from "Randy Bush" at Mar 5, 97 05:13:00 pm
Message-ID: <199703070125.RAA14088@falcon.netflight.com>

> 
> So who actually measures their network performance and how?
> 
> randy
> 

SNMP queries with a heavily-modified version of MRTG
from the nice guy in Germany.  Works very nicely.
We have recently installed NetScarf 2.0, and are
contemplating merging NetScarf 3.0 with the
MRTG front end.

Matt Petach





From cnielsen at vii.com  Fri Mar  7 03:17:30 1997
From: cnielsen at vii.com (Christian Nielsen)
Date: Thu, 6 Mar 1997 20:17:30 -0700 (MST)
Subject: measurement
In-Reply-To: <199703070125.RAA14088@falcon.netflight.com>
Message-ID: <Pine.GSO.3.95.970306201606.29128B-100000@lonepeak.vii.com>

On Thu, 6 Mar 1997, Matthew Petach wrote:

X->SNMP queries with a heavily-modified version of MRTG
X->from the nice guy in Germany.  Works very nicely.
X->We have recently installed NetScarf 2.0, and are
X->contemplating merging NetScarf 3.0 with the
X->MRTG front end.

We also use MRTG, but it is from someone in Switzerland, ETHZ (I have been
there so I know) But for those who are looking for the url

http://www.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg.html


Christian





From scott at Sonic.NET  Fri Mar  7 14:17:08 1997
From: scott at Sonic.NET (Scott Doty)
Date: Fri, 7 Mar 1997 06:17:08 -0800
Subject: BGP stability
Message-ID: <Mutt.19970307061708.scott@pengo.sonic.net>

Hi.  I'd like to point something out:  by not tieing IGP to EGP,
folks have a responsibility.

Ideally, the purpose of BGP is to announce the availability of
networks -- if your network can't deliver traffic to a remote
network, you shouldn't be announcing via BGP.

Unfortunately, we don't live in an ideal world.  To improve
stability of the global BGP mesh, folks have decided not to tie
BGP to their IGP -- and personally, I think that's a darned good idea.

But this decision has a cost:  when making a change that will
affect routing (such as a router upgrade), these folks can't rely
on IGP to straighten out their network's reachability matrix.  It
seems to me that responsible folks would emply manual
intervention to ensure that their BGP announcements would
match the state of their network.

For instance:  when upgrading a router, I think the responsible
folks would determine the the "top" of that router's topology,
shut down BGP into that topology, do the upgrade, and then
reenable BGP.

In other words, if you're running your BGP on "manual," and you
manually do stuff to affect your network, please make the manual
changes to ensure BGP knows about the state of your network. 
This only means one "flap", and it will make the world a nicer
place.

 -Scott






From oetiker at ee.ethz.ch  Fri Mar  7 23:18:54 1997
From: oetiker at ee.ethz.ch (Tobias Oetiker)
Date: Sat, 8 Mar 1997 00:18:54 +0100 (MET)
Subject: The nice mrtg guy
Message-ID: <Pine.GSO.3.95.970308001635.3295J-100000@engelberg>

>> 
>> So who actually measures their network performance and how?
>> 
>> randy
>> 
>
>SNMP queries with a heavily-modified version of MRTG
>from the nice guy in Germany.  Works very nicely.

The nice guy is from Switzerland and he is called Tobi Oetiker ...
If you want the latest mrtg, go to

http://www.ee.ethz.ch/~oetiker/webtools/mrtg

more about the nice guy is on his homepage

the nice guy ...

--
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL:+41(0)1-6325286  FAX:+41(0)1-6321194
/_/ \___/_.__/_/ oetiker at ee.ethz.ch http://www.ee.ethz.ch/~oetiker





From michael at memra.com  Sat Mar  8 21:47:23 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 8 Mar 1997 13:47:23 -0800 (PST)
Subject: Class "B" forsale (fwd)
Message-ID: <Pine.BSI.3.93.970308134713.18089Y-100000@sidhe.memra.com>


---------- Forwarded message ----------
Date: Sat, 08 Mar 1997 12:06:35 -0800
From: Norman Gillaspie <norman at pc-sat.com>
Reply-To: inet-access at earth.com
To: inet-access at earth.com
Subject: Class "B" forsale
Resent-Date: Sat, 8 Mar 1997 13:07:47 -0700 (MST)
Resent-From: inet-access at earth.com

One class "B" Internet address available to the highest bidder.
Please call 415-854-5263 and leave a message if interested.

Please referance the above.
Satellite delivered usenet news via satellite.
conserve your expensive internet connection and
machine resources. Get a really current feed.
Contact PC-Sat 415-854-5262 or HTTP://www.pc-sat.com

============================== ISP Mailing List ==============================
Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
Experience varies directly with equipment ruined.





From rjoffe at genuity.net  Sat Mar  8 23:18:41 1997
From: rjoffe at genuity.net (Rodney Joffe)
Date: Sat, 8 Mar 1997 16:18:41 -0700
Subject: Remote Operations question
Message-ID: <c=US%a=_%p=Genuity%l=X-FILES-970308231841Z-12446@x-files.genuity.net>

Is anyone using any kind of out of band controlled power system that
will support remote power cycling of multiple devices with high power
ratings? I'd like to be able to cycle individual components in our racks
at NAPs (especially MAE E!) including 7513s.  All the devices we've
found are limited to 15 amps total. I think a 7513 requires 20amps on
its own.

Thanks

Rodney Joffe
Genuity Inc., a Bechtel company
http://www.genuity.net






From len at netsys.com  Sun Mar  9 00:01:52 1997
From: len at netsys.com (Len Rose)
Date: Sat, 08 Mar 1997 19:01:52 -0500
Subject: Class "B" forsale (fwd)
Message-ID: <3.0.32.19970308190152.01371210@netsys.com>


I remember going through hell writing the justification for this network.
I didn't know the NIC would allow sale of address space. 

Len


At 01:47 PM 3/8/97 -0800, Michael Dillon wrote:
>
>---------- Forwarded message ----------
>Date: Sat, 08 Mar 1997 12:06:35 -0800
>From: Norman Gillaspie <norman at pc-sat.com>
>Reply-To: inet-access at earth.com
>To: inet-access at earth.com
>Subject: Class "B" forsale
>Resent-Date: Sat, 8 Mar 1997 13:07:47 -0700 (MST)
>Resent-From: inet-access at earth.com
>
>One class "B" Internet address available to the highest bidder.
>Please call 415-854-5263 and leave a message if interested.
>
>Please referance the above.
>Satellite delivered usenet news via satellite.
>conserve your expensive internet connection and
>machine resources. Get a really current feed.
>Contact PC-Sat 415-854-5262 or HTTP://www.pc-sat.com
>
>============================== ISP Mailing List
==============================
>Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
>Experience varies directly with equipment ruined.
>
>

len at netsys.com
http://www.netsys.com





From alex at nac.net  Sat Mar  8 23:22:27 1997
From: alex at nac.net (Alex Rubenstein)
Date: Sat, 08 Mar 1997 19:22:27 -0400
Subject: Remote Operations question
Message-ID: <3.0.32.19970308190731.016be960@mail.nac.net>


Leviton has some stuff the we use, they have some things that can do 20 amps.

The better question; why? What is the 7513 doing that you need it to be
rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-)


At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote:
>Is anyone using any kind of out of band controlled power system that
>will support remote power cycling of multiple devices with high power
>ratings? I'd like to be able to cycle individual components in our racks
>at NAPs (especially MAE E!) including 7513s.  All the devices we've
>found are limited to 15 amps total. I think a 7513 requires 20amps on
>its own.
>
>Thanks
>
>Rodney Joffe
>Genuity Inc., a Bechtel company
>http://www.genuity.net
>
>
>




From blh at nol.net  Sun Mar  9 00:31:03 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sat, 8 Mar 1997 18:31:03 -0600 (CST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <3.0.32.19970308190152.01371210@netsys.com>
Message-ID: <Pine.GSO.3.95.970308183039.14617E-100000@dazed.nol.net>

As I see it, I don't think the Nic really has a choice in the matter.

On Sat, 8 Mar 1997, Len Rose wrote:

> 
> 
> I remember going through hell writing the justification for this network.
> I didn't know the NIC would allow sale of address space. 
> 
> Len

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From cnielsen at vii.com  Sun Mar  9 01:03:02 1997
From: cnielsen at vii.com (Christian Nielsen)
Date: Sat, 8 Mar 1997 18:03:02 -0700 (MST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.93.970308134713.18089Y-100000@sidhe.memra.com>
Message-ID: <Pine.GSO.3.95.970308180108.2505A-100000@lonepeak.vii.com>


X->One class "B" Internet address available to the highest bidder.
X->Please call 415-854-5263 and leave a message if interested.

	The way I see it, it is worth no more than $10,000. As that is what
ARIN is going to charge any corp to get a Class B. Plus some yearly maint fee.
BTW, I remember reading about someone else selling a Class B, I thought I
heard they got around $30,000 for it. I offered to take it at no cost :)

Christian





From rjoffe at genuity.net  Sun Mar  9 01:09:18 1997
From: rjoffe at genuity.net (Rodney Joffe)
Date: Sat, 8 Mar 1997 18:09:18 -0700
Subject: Remote Operations question
Message-ID: <c=US%a=_%p=Genuity%l=X-FILES-970309010918Z-12511@x-files.genuity.net>

Thanks Alex......

As far as why........   well let's see; when the router gets hosed in
our cage, and we open a ticket with MFS, and it takes 5 hours before
they arrive..... it seems a lot more logical to be able to power cycle
it out of band without waiting. Now if MFS's facility was truly a 24 x 7
facility, which you would expect for a place that was that important :-)
By the way, your $500 is much less than the last bill they sent us ...
$750.

Amazing... and we didn't even see the gun in their hands.

Rodney Joffe
Genuity Inc., a Bechtel company
http://www.genuity.net


>-----Original Message-----
>From:	Alex Rubenstein [SMTP:alex at nac.net]
>Sent:	Saturday, March 08, 1997 4:22 PM
>To:	Rodney Joffe; 'nanog at merit.edu'
>Subject:	Re: Remote Operations question
>
>
>Leviton has some stuff the we use, they have some things that can do 20 amps.
>
>The better question; why? What is the 7513 doing that you need it to be
>rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-)
>
>
>At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote:
>>Is anyone using any kind of out of band controlled power system that
>>will support remote power cycling of multiple devices with high power
>>ratings? I'd like to be able to cycle individual components in our racks
>>at NAPs (especially MAE E!) including 7513s.  All the devices we've
>>found are limited to 15 amps total. I think a 7513 requires 20amps on
>>its own.
>>
>>Thanks
>>
>>Rodney Joffe
>>Genuity Inc., a Bechtel company
>>http://www.genuity.net
>>
>>
>>




From pete at inquo.net  Sun Mar  9 01:17:14 1997
From: pete at inquo.net (Pete Kruckenberg)
Date: Sat, 8 Mar 1997 18:17:14 -0700 (MST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.93.970308134713.18089Y-100000@sidhe.memra.com>
Message-ID: <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net>

On Sat, 8 Mar 1997, Michael Dillon wrote:

> One class "B" Internet address available to the highest bidder.
> Please call 415-854-5263 and leave a message if interested.

I'm just a little curious. If the current policy (as stated by at least
one Draft RFC) is that IP address space is not owned, how can someone sell
a Class B? If they are selling it, that must mean that they don't actually
need it, so therefore they are obligated to return it to InterNIC. On the
other side, maybe InterNIC has an obligation to take it back.

What kinds of guarantees are there that if someone buys it, that they will
actually be able to get and keep this Class B?

Pete Kruckenberg
pete at inquo.net






From stephen at clark.net  Sun Mar  9 01:36:24 1997
From: stephen at clark.net (Stephen Balbach)
Date: Sat, 8 Mar 1997 20:36:24 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net>
Message-ID: <Pine.LNX.3.91.970308202918.11168D-100000@bisco.clark.net>

On Sat, 8 Mar 1997, Pete Kruckenberg wrote:

> On Sat, 8 Mar 1997, Michael Dillon wrote:
> 
> > One class "B" Internet address available to the highest bidder.
> > Please call 415-854-5263 and leave a message if interested.
> 
> I'm just a little curious. If the current policy (as stated by at least
> one Draft RFC) is that IP address space is not owned, how can someone sell
> a Class B? If they are selling it, that must mean that they don't actually
> need it, so therefore they are obligated to return it to InterNIC. On the
> other side, maybe InterNIC has an obligation to take it back.
> 
> What kinds of guarantees are there that if someone buys it, that they will
> actually be able to get and keep this Class B?

Good questions. Furthermore

   The NIC gives IP space out to a particulr user which is registerd via 
   SWIP's how and who is using it. SWIP's are required if you ever want to
   get additional IP space.

So, the seller is also put at risk at never getting additonal IP space if 
the buyer does not use the entire Class B in a satisfactory manner to the 
NIC. So, one could conclude the seller is likely a fly-by-night 
operation. I'd be interested in hearing otherwise ;)

.stb






From pferguso at cisco.com  Sun Mar  9 01:49:07 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sat, 08 Mar 1997 20:49:07 -0500
Subject: Class "B" forsale (fwd)
Message-ID: <3.0.32.19970308204901.006ca138@lint.cisco.com>

At 06:17 PM 3/8/97 -0700, Pete Kruckenberg wrote:

>
>I'm just a little curious. If the current policy (as stated by at least
>one Draft RFC) is that IP address space is not owned, how can someone sell
>a Class B? If they are selling it, that must mean that they don't actually
>need it, so therefore they are obligated to return it to InterNIC. On the
>other side, maybe InterNIC has an obligation to take it back.
>
>What kinds of guarantees are there that if someone buys it, that they will
>actually be able to get and keep this Class B?
>

You know what they say, 'Possession is 9/10'ths of the law'.  ;-)

- paul





From michael at memra.com  Sun Mar  9 03:47:20 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 8 Mar 1997 19:47:20 -0800 (PST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net>
Message-ID: <Pine.BSI.3.93.970308184721.18089v-100000@sidhe.memra.com>

On Sat, 8 Mar 1997, Pete Kruckenberg wrote:

> > One class "B" Internet address available to the highest bidder.
> > Please call 415-854-5263 and leave a message if interested.
> 
> I'm just a little curious. If the current policy (as stated by at least
> one Draft RFC) is that IP address space is not owned, how can someone sell
> a Class B? 

It's a black market thing.

> If they are selling it, that must mean that they don't actually
> need it, so therefore they are obligated to return it to InterNIC. On the
> other side, maybe InterNIC has an obligation to take it back.

Yep.

> What kinds of guarantees are there that if someone buys it, that they will
> actually be able to get and keep this Class B?

None. It is entirely possible that this will happen:

1. Someone will pay $50,000 cash to the seller

2. The seller will go through the motions of transferring the address
   block (which may or may not include some sort of changes to NIC
   records)

3. The NIC will refuse to change the records and/or the operators in the
   defaultless core will refuse to listen to the announcements for this 
   block.

4. The buyer will ask for their money back and the seller will refuse.

5. Upon consulting a lawyer the buyer will find that they have no
   enforcable contract. Especially so if the seller no longer controls
   the block because the NIC has taken it back.

Black markets aren't quite the same as dealing in illegal drugs but 
they are in a similarly shady neighborhood.

NOTE: I don't support the selling of IP addresses and I don't support
      the "ownership" of IP addresses. I believe that the the NIC's 
      are stewards of a public resource and that IP addresses should
      be allocated on the basis of demonstrated need, not market forces.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From len at NETSYS.COM  Sun Mar  9 04:11:48 1997
From: len at NETSYS.COM (Len Rose)
Date: Sat, 8 Mar 1997 23:11:48 -0500 (EST)
Subject: The Class B in Question
Message-ID: <199703090411.XAA23784@netsys.com>


If I am coordinator does this mean I own it :-)

Len

# whois 165.90.0
Pagesat Inc. (NET-PAGESAT)
   Pagesat Inc.
   992 San Antonio Rd.
   Palo Alto, CA 94303

   Netname: PAGESAT
   Netnumber: 165.90.0.0

   Coordinator:
      Rose, Leonard  (LR69)  len at NETSYS.COM
      415-233-0441

   Domain System inverse mapping provided by:

   NS1.PAGESAT.NET              165.90.2.2
   PAGESAT.NET                  165.90.2.3

   Record last updated on 12-Jul-94.

The InterNIC Registration Services Host contains ONLY Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.






From davidc at apnic.net  Sun Mar  9 04:26:51 1997
From: davidc at apnic.net (David R. Conrad)
Date: Sun, 09 Mar 1997 13:26:51 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Sat, 08 Mar 1997 18:03:02 MST."
             <Pine.GSO.3.95.970308180108.2505A-100000@lonepeak.vii.com> 
Message-ID: <199703090426.NAA03330@palmtree.jp.apnic.net>

>
>X->One class "B" Internet address available to the highest bidder.
>X->Please call 415-854-5263 and leave a message if interested.
>
>	The way I see it, it is worth no more than $10,000. As that is what
>ARIN is going to charge any corp to get a Class B. 

How much is your time (spent making up and writing the justification for
a class B) worth?

Regards,
-drc




From randy at psg.com  Sun Mar  9 04:35:00 1997
From: randy at psg.com (Randy Bush)
Date: Sat, 8 Mar 97 20:35 PST
Subject: measurement
Message-ID: <m0w3aKM-0007zcC@rip.psg.com>

I promised to summarize responses to my query

> So who actually measures their network performance and how?

As most responses were private, I have removed attribution.  Thanks to all
constructive respondees.

I have proposed a survey panel for the next NANOG if we do not exhaust the
subject beforehand.

randy


- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We do SNMP polling ever 15 minutes at SESQUINET on every line over which we 
have administrative control and over every peering point. We produce a daily
reports on errors and usage. 

We are getting ready to switch to Vulture or NetScarf (or some combo) to
give us more interactive information.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We perform measurement of certain basic network parameters, such as
usage (bandwidth used / total bandwidth) and line error rates on all of our
non-customer links.  We perform CPU usage, memory usage, and eviron-
mental monitoring of all our routers.  We also perform the line usage and
error rate on all customer lines.  We monitor all of our customers' routers
unless they say otherwise, and notify them of any problems.  Finally, we
monitor select points throughout the Internet (root name servers, etc.) on
a 4 times an hour basis using pings.

We accomplish this monitoring using the following items an in-house built
package that uses SNMP, traceroute, and ping to provide graphs and tabular
statistical information.  We use cabletron's Spectrum for a quick network
overview.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We do.  SNMP MIB-II stuff, plus the cflowd stuff and something we call
'mxd' (measures round trip times, packet loss and potential reason,
etc. from a whole bunch of different points in our network to a bunch of
other points in our network... we use it to create delay matrices,
packet loss reports and other reports).  There are some other things,
but these are the biggies.

I was hoping to get our mxd developer to present at NANOG, but she was
unable to attend and is sort of the shy type (too bad, she's one of our
better people).  Maybe I can throw together some information on what we
measure for a bullet or two at ISMA, and why.  If there's any interest,
that is.  The mxd thing was originally just sort of a toy for neat
reports, but in the last year it's become a critical tool for measuring
delay variance for one of our VPDN customers that does real-time video
stuff (and is to some extent helping us figure out where we've got delay
jitter and why; on the other hand it's also raising more questions :-)).

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

Since most of my professional career has been in the enterprise world, I
can offer you what we used to measure availability to our mail servers,
web servers, DNS servers, etc., at one of my previous employers.

We employed several application tests, along with network performance
tests.  Our primary link was via UUnet, a burstable T1.  We purchased an
ISDN account from another local provider, who wasn't directly connected to
UUnet.  Probably a good example of a joe-average-user out there.

Every 5 minutes, we measured round-trip response times to each of the
servers and gateway router (via ping) and recorded it.  We also had
application tests, such as DNS lookups on our servers, timing sendmail
test mails to a /dev/null account, and time to retrieve the whole home
page.  We trended the results into graphs and used it 

This wasn't meant to be a really great performance monitoring system; it
was actually meant to 1) check how our availability looked from a "joe
user" perspective on the net (granted, reachability/availability wasn't
perfect because it was only one point in the net) and 2) look at response
time trends / application trends to see if our hardware/software was
cutting it.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We use a traffic flow monitoring system from Kaspia Systems.
(www.kaspia.com) The Kaspia product collects all sorts of data from router
ports and RMON probes, stores the data and performs various trend analysis.
We collect traffic flow, router CPU usage and router memory information plus
various errors.  There is a data reduction process which runs once a day,
and a very nifty web interface.  The product isn't cheap, but the system
definitely fills a void here.

Maybe I should organize a talk on what we're doing with it for an upcoming
NANOG?  As an old instrumentation engineer, I think the basis of our use of
the tool is pretty solid.  Plus, I actually developed a means for
calibration of the accuracy of the flow data.  Haven't had time yet to work
out a validation for the trends, but I'll get to it one of these decades.

Also, the Kaspia people will give you a thirty day trial on their product at
no charge.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

It's brain-dead simple, and probably not of real interest to you, but we
keep a few basic stats, going back about two years...

For non-intrusive stuff, we keep a log of all interface status changes on
our routers, and we pull five-minute byte-counts inbound and outbound on
each interface, which we graph against port speed.  Watching the graphs for
any sort of clipping of peaks gives a pretty good indication of problems,
and watching for shifts of traffic between ports on parallel paths likewise.

As far as intrusive testing, we do a three-packet min-length ping to the
LAN-side port of each of our customers' routers once each five minutes, and
follow that up with additional attempts if those three are lost.  We log
latency, and if we have to follow up with a burst, we log loss rate from the
burst. Pinging through to the LAN port obviously lets us know when CPE
routers konk out, as occasionally we see hung routers that still have
operational WAN ports talking to us, likewise, simply watching VC-state
isn't a reliable enough indicator of the status of the remote router.  Plus
it tells you if the customer has kicked the Ethernet transceiver off their
equipment, for instance.  Wouldn't matter to you, probably, but our demarc
is all the way out at their WAN port, since we own and operate our
customers' CPE.

I think a bit about what more we could be doing; flows-analysis and
whatnot...  It's nice to think about, and eventually we'll get around to it,
but programmer-time is relatively precious, and other things have higher
priority, since the current system works and tends to tell us most of what
we seem to need to know to provide decent service.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

we do. in fact, we place quite a bit of emphasis on network stats. currently
we have about 3 years of stats online, and are working on converting our
inhouse engine to an rdbms so we can more easily perform trend
analysis. besides kaspia, other commercial packages include trendsnmp
(www.desktalk.com) and concord's packages (www.concord.com). our inhouse
stuff is located at http://netop.cc.buffalo.edu/ if you are curious about
what we do.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We're neanderthals right now - we use a hacked rcisco to feed data to nocol.
We watch bandwidth (separately as well) on key links - and also watch input
errors and interface transitions (for nocol) - all done with perl and
expect-like routines, parsing 'sho int's every few minutes.

Emergency stuff goes through nocol; bandwidth summaries are mailed to
interested parties overnight.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We have running here now the MRTG package that generate some fancy graphics,
but in my opinion these graphics are useless and looking in detail to some
of the reports they are not accurate, several of our clients request the raw
data but this package only mantain few raw data just to generate the graphs,
mean also useless.

In the past we use to have also a kind of ascii reports (Vikas wrote some of
the scripts and programs) generated from information obtained using the old
snmp tool set developed by nysernet but I guess that nobody mantained the
config files and I believe that the snmp library routines used aren't
working fine.

So, I need to invest some time to provide a fast solution to this, I'll
apreciate your help to identify some useful package or directions about how
to generate some good looking and consistent reports.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

We have been using the MRTG package which is basically a special SNMP agent
that queries the routers for stats and then does some nice graphing of the
data on the web.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

SNMP queries with a heavily-modified version of MRTG from the nice guy in
Germany.  Works very nicely.  We have recently installed NetScarf 2.0, and
are contemplating merging NetScarf 3.0 with the MRTG front end.

- - - - - - - - - - - - - -   c u t   h e r e   - - - - - - - - - - - - - -

I'm researching whether I can rewrite Steve Corbato's fastpoll program
using the fastsnmp library from the NetScarf people.  I think this will
allow fastpoll to scale better.  I've successfully written a quick C
program that uses the library to collect the required data for a router --
now I've just got to make it so we can manage it easily (i.e.
auto-generated config files from our databases). 

My goal is to be able to collect 1-2 minute period data on all links that
are greater than 10 Mbps -- 15 minutes data for everything else.  The 2
minute collection period will allow to scale up to 280Mbps before
experiencing two counter roll-overs within a polling interval.  Hopefully
that will hold us over the interface counters are available as Counter64
objects via SNMPv2 (if that ever happens).

BTW -- what fastpoll collects now is ifInOctets, ifOutOctets, ifInUcastPkts,
ifOutUcastPkts, ifInErrors and ifOutDiscards.  Rather than storing the raw
counters, it calculates the rate by taking the delta and dividing by the
period.  Getting the accurate period is actually the hard part -- I'm having
SNMP send me the uptime of the router in each query and using that to
calculate the interval between polls and to detect counter resets due to
reboots.  The other trick to handle is the fact that, while IOS updates the
SNMP counters for process-switched packets as they are routed, it looks like
the counter for SSE switched packets on C70X0 routers only get updated once
every 10 seconds.

I'll let you know how my tests come out.

-30-




From davidc at apnic.net  Sun Mar  9 04:25:49 1997
From: davidc at apnic.net (David R. Conrad)
Date: Sun, 09 Mar 1997 13:25:49 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Sat, 08 Mar 1997 19:01:52 EST."
             <3.0.32.19970308190152.01371210@netsys.com> 
Message-ID: <199703090425.NAA03310@palmtree.jp.apnic.net>

Hi,

>I remember going through hell writing the justification for this network.
>I didn't know the NIC would allow sale of address space. 

The Internet regsistries cannot disallow someone from selling IP
address space any more than we can disallow someone selling the
Brooklyn Bridge, gold painted bricks, or land with a lovely ocean view
a few miles south of the Everglades.

However, what we can disallow is the update of the registration
database when a full registry allocated block is transfered from one
organization to another.

Of course, although I work for a registry, I (personally) am under no
illusion that this will discourage the insistent as it has little
impact on the operational viability of the network, it just makes
finding out appropriate contacts when bad things happen a bit more
difficult.

Regards,
-drc




From davidc at apnic.net  Sun Mar  9 04:39:46 1997
From: davidc at apnic.net (David R. Conrad)
Date: Sun, 09 Mar 1997 13:39:46 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Sat, 08 Mar 1997 18:17:14 MST."
             <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net> 
Message-ID: <199703090439.NAA03353@palmtree.jp.apnic.net>

[note reply-to]

Hi,

>What kinds of guarantees are there that if someone buys it, that they will
>actually be able to get and keep this Class B?

An Internet address is just a 32 bit number that has uniqueness
guaranteed by the registries.  That guarantee holds regardless of who
is actually "in possesion of" the address.  If an organization with a
surplus /16 agrees to let another organization use that /16 in
exchange for compensation of some sort, that address will still be
routable on the Internet if it was routable before the exchange.  

Of course, whether it is actually routed is another story.

Given the registries do not allow for outright transfers of this sort
directly (see RFC 2050), one course of action would be for the
original "owner" to sell the "right of use" of the /16.  Of course,
the appropriate action (according to RFC 2050 and historical Internet
culture) would be for the original "owner" to return address space
they don't need...

Regards,
-drc




From davidc at apnic.net  Sun Mar  9 04:43:53 1997
From: davidc at apnic.net (David R. Conrad)
Date: Sun, 09 Mar 1997 13:43:53 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Sat, 08 Mar 1997 19:47:20 PST."
             <Pine.BSI.3.93.970308184721.18089v-100000@sidhe.memra.com> 
Message-ID: <199703090443.NAA03378@palmtree.jp.apnic.net>

[note reply-to]

Hi,

>Black markets aren't quite the same as dealing in illegal drugs but 
>they are in a similarly shady neighborhood.

Actually, they are.

>I believe that the the NIC's 
>      are stewards of a public resource and that IP addresses should
>      be allocated on the basis of demonstrated need, not market forces.

Market forces have been shown to be a more efficient mechanism to
determine "need" than central planning when no objective and easily
measured criteria can be determined.

Regards,
-drc





From randy at psg.com  Sun Mar  9 05:26:00 1997
From: randy at psg.com (Randy Bush)
Date: Sat, 8 Mar 97 21:26 PST
Subject: Class "B" forsale (fwd) 
References: <Pine.BSI.3.93.970308184721.18089v-100000@sidhe.memra.com>
	<199703090443.NAA03378@palmtree.jp.apnic.net>
Message-ID: <m0w3b7p-0007zcC@rip.psg.com>

> Market forces have been shown to be a more efficient mechanism to
> determine "need" than central planning when no objective and easily
> measured criteria can be determined.

With "No objective and easily measured criteria," it would seem to be hard
to measure efficiency.

Historically, open markets have worked well sometimes and not worked others.
Pre-judging how one might work in IPv4 addresses would seem hubris.

randy






From blast at broder.com  Sun Mar  9 05:28:28 1997
From: blast at broder.com (Tim Keanini)
Date: Sat, 8 Mar 1997 21:28:28 -0800 (PST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.GSO.3.95.970308180108.2505A-100000@lonepeak.vii.com>
Message-ID: <Pine.BSI.3.95.970308212531.9500C-100000@pillbox.broder.com>

On Sat, 8 Mar 1997, Christian Nielsen wrote:

> X->One class "B" Internet address available to the highest bidder.
> X->Please call 415-854-5263 and leave a message if interested.
> 
> 	The way I see it, it is worth no more than $10,000. As that is what
> ARIN is going to charge any corp to get a Class B. Plus some yearly maint fee.
> BTW, I remember reading about someone else selling a Class B, I thought I
> heard they got around $30,000 for it. I offered to take it at no cost :)

Let us make sure that we understand one thing about ARIN.
A person can't walk in with $10,000 and buy a /16.
You will still have to justify your IP space needs the way
you do it today.  What has changed is that there will be 
an ongoing maint. fee.  

--blast
   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   \    Tim Keanini    |         "The limits of my language,            /
   /                   |         are the limits of my world."           \
   \ blast at broder.com  |         --Ludwig Wittgenstein                  /
   \                   +================================================/
   |Key fingerprint =  7B 68 88 41 A8 74 AB EC  F0 37 98 4C 37 F7 40 D6 |
   /    PUB KEY: http://www-swiss.ai.mit.edu/~bal/pks-commands.html     \
   %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%





From root at netreach.net  Sun Mar  9 06:06:20 1997
From: root at netreach.net (0000-Admin0000)
Date: Sun, 9 Mar 1997 01:06:20 -0500
Subject: Class "B" forsale (fwd)
Message-ID: <9703090606.AA20201@tahiti.netreach.net>

This entire discussion reminds me of the way they do business on the
streets of New York City when it comes to vendors.  It is ILLEGAL to 
sell a vending license in the city of new york.  That, however, does
not prevent some enterprising individuals from selling the use of
carts to vend goods along with a free license thrown in.

It also does not prevent someone from selling not an IP address block, 
but selling ownership of a company that happens to own an IP address
block.  The geometric possibilities alone are astounding.....


-dave
netreach




From vgoel at sprint.net  Sun Mar  9 06:18:25 1997
From: vgoel at sprint.net (Vab Goel)
Date: Sun, 9 Mar 1997 01:18:25 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net>
Message-ID: <Pine.GSO.3.95.970309011426.11427G-100000@iscserv>


>On Sat, 8 Mar 1997, Pete Kruckenberg wrote:


> What kinds of guarantees are there that if someone buys it, that they
>will  actually be able to get and keep this Class B?

If buyer & seller make a deal, with the current model buyer will be able
to use it without any problem.

vab..





From argon at paladin.erols.com  Sun Mar  9 07:19:00 1997
From: argon at paladin.erols.com (James Lang)
Date: Sun, 9 Mar 1997 02:19:00 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.95.970308181454.5791C-100000@inquo.net>
Message-ID: <Pine.LNX.3.95.970309021329.2148C-100000@paladin.erols.com>

On Sat, 8 Mar 1997, Pete Kruckenberg wrote:

> What kinds of guarantees are there that if someone buys it, that they will
> actually be able to get and keep this Class B?

	As has been said allready there are no fail-safes in place that I
know of which would stop the transaction.  However the tradition has been
to "play nice in the sandbox" and give back addresses which are no longer
in use or not needed.  Given that the over the last few years the net has
taken on a diffrent look and feel I was just wondering if there are any
firm rules on this and if not weather someone, or a group of people were
looking at the problems this presents? 


					James





From michael at memra.com  Sun Mar  9 08:33:37 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 00:33:37 -0800 (PST)
Subject: Playing nice in the sandbox
In-Reply-To: <Pine.LNX.3.95.970309021329.2148C-100000@paladin.erols.com>
Message-ID: <Pine.BSI.3.93.970309001123.18089K-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, James Lang wrote:

> However the tradition has been
> to "play nice in the sandbox" and give back addresses which are no longer
> in use or not needed.  Given that the over the last few years the net has
> taken on a diffrent look and feel I was just wondering if there are any
> firm rules on this and if not weather someone, or a group of people were
> looking at the problems this presents? 

In a sense, this is one of the reasons that NANOG exists. Both the mailing
list and the meetings provide a forum for people to not only share what
works operationally, but to work out what is acceptable behavior on the
network. However, there are people that doing work that touches on this.

There is always RFC 2050 which covers IP allocation guidelines.

You might want to read through Randy Bush's slides from the last NANOG
on inter-provider cooperation http://www.psg.com/~randy/970210.nanog/

CAIDA and especially CAIDAnce are somewhat relevant
http://www.nlanr.net/Caida/  http://www.nlanr.net/COLL/caidance.html

You should look through the WG's at
http://www.ietf.org/html.charters/wg-dir.html especially the ones in the
OPS section like PIER and GRIP.

Since the nature of the network is one of voluntary cooperation to make
things work, there are no firm rules and no big brother to see that things
are put right. But if people don't play nice in the sandbox they will find
it tough to make a living in the sand business :-)

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com






From blh at nol.net  Sun Mar  9 13:09:00 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 07:09:00 -0600 (CST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <199703090426.NAA03330@palmtree.jp.apnic.net>
Message-ID: <Pine.GSO.3.95.970309070145.10593B-100000@dazed.nol.net>

On Sun, 9 Mar 1997, David R. Conrad wrote:

> >	The way I see it, it is worth no more than $10,000. As that is what
> >ARIN is going to charge any corp to get a Class B. 
> 
> How much is your time (spent making up and writing the justification for
> a class B) worth?

I think you miss my point, since the ARIN is for all intents and purposes
selling address space, who are they to say no? Apparently someone made a
case for a class B at one time or another, no longer needs it (for whatever
reason) and wants to pass it on to someone else and make a little profit in
at the same time. Now granted, I don't neccessarily agree with what they're
doing, but I certainly can't say anything 'wrong' about it either. I mean,
lets think about this for a second.

Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
is in order as it should be. I decide for whatever reason to turn off my
routers, sell my equipment and move to the Caymans to enjoy the rest of my
life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
block to someone else and make a small (or large for that matter, I'm sure I
could sell it for a interesting sum of money) profit.

scenario 1:

It gets returned and some other poor fool has to jump through flaming hoops
and surive a pool of toxic waste to get a few IPs.

scenario 2:

I change all the records to point to them, swip it out to them, basically do
everything needed to make them the legitimate 'owners' of that block, they
pay me a nice lump of cash and we're both happy.

As I see it, changing ownership of IPs is no different than changing
ownership of a domain. 


[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From tomg at boiled.egg.com  Sun Mar  9 13:40:47 1997
From: tomg at boiled.egg.com (Tom Glover)
Date: Sun, 9 Mar 1997 05:40:47 -0800 (PST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.GSO.3.95.970309070145.10593B-100000@dazed.nol.net>
Message-ID: <Pine.BSI.3.95.970309052842.15829E-100000@boiled.egg.com>


I "kind" of agree. :) If I own a company, lets call it Acme, which has an
internet connection and that company is making use of a class B address
space it got from the 'NIC and if I sell Acme does that address block need
to be returned?  Another example is if I own an ISP that has several
blocks of address space. What happens if I sell the ISP? Do the address
blocks get returned? If Acme has to return their address blocks upon the
sale of the company and the ISP doesn't on its sale, we've got a situation
which would keep lawyers in Lexus for decades. If the answer is that you
can legitimately transfer an address block if you sell the company then
there's a nice big loophole. Anyone with a class B for sale could simply
form a company and then sell it.

Now I don't own a sellable address block. I'm just playing devil's
advocate in what appears to be a very interesting quandary.

On Sun, 9 Mar 1997, Brett L. Hawn wrote:

> On Sun, 9 Mar 1997, David R. Conrad wrote:
> 
> > >	The way I see it, it is worth no more than $10,000. As that is what
> > >ARIN is going to charge any corp to get a Class B. 
> > 
> > How much is your time (spent making up and writing the justification for
> > a class B) worth?
> 
> I think you miss my point, since the ARIN is for all intents and purposes
> selling address space, who are they to say no? Apparently someone made a
> case for a class B at one time or another, no longer needs it (for whatever
> reason) and wants to pass it on to someone else and make a little profit in
> at the same time. Now granted, I don't neccessarily agree with what they're
> doing, but I certainly can't say anything 'wrong' about it either. I mean,
> lets think about this for a second.
> 
> Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
> is in order as it should be. I decide for whatever reason to turn off my
> routers, sell my equipment and move to the Caymans to enjoy the rest of my
> life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
> block to someone else and make a small (or large for that matter, I'm sure I
> could sell it for a interesting sum of money) profit.
> 
> scenario 1:
> 
> It gets returned and some other poor fool has to jump through flaming hoops
> and surive a pool of toxic waste to get a few IPs.
> 
> scenario 2:
> 
> I change all the records to point to them, swip it out to them, basically do
> everything needed to make them the legitimate 'owners' of that block, they
> pay me a nice lump of cash and we're both happy.
> 
> As I see it, changing ownership of IPs is no different than changing
> ownership of a domain. 
> 
> 
> [-]                Brett L. Hawn (blh @ nol dot net)                       [-]
> [-]                Networks On-Line - Houston, Texas                       [-]
> [-]                           713-467-7100                                 [-]
> 

--
Regards,
Tom
  ________________________________________________________________________
 |   "The Egg Domain"    |       "And all you touch and all you see,      | 
 |    tomg at egg.com       |          is all your life will ever be."       |
 | http://www.egg.com/   |                               (Pink Floyd)     |






From nathan at netrail.net  Sun Mar  9 15:01:38 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 9 Mar 1997 10:01:38 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <3.0.32.19970308204901.006ca138@lint.cisco.com>
Message-ID: <Pine.LNX.3.95.970309095924.4476E-100000@netrail.net>

On Sat, 8 Mar 1997, Paul Ferguson wrote:

> You know what they say, 'Possession is 9/10'ths of the law'.  ;-)

Next time you rent a car, when you finish driving over the things that can
kill your tires. Just yell to the guy 'Possession is 9/10'th of the law'
and never come back. 


Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From nathan at netrail.net  Sun Mar  9 15:04:45 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 9 Mar 1997 10:04:45 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <9703090606.AA20201@tahiti.netreach.net>
Message-ID: <Pine.LNX.3.95.970309100421.4476F-100000@netrail.net>

On Sun, 9 Mar 1997, 0000-Admin(0000) wrote:

> This entire discussion reminds me of the way they do business on the
> streets of New York City when it comes to vendors.  It is ILLEGAL to 
> sell a vending license in the city of new york.  That, however, does
> not prevent some enterprising individuals from selling the use of
> carts to vend goods along with a free license thrown in.
> 
> It also does not prevent someone from selling not an IP address block, 
> but selling ownership of a company that happens to own an IP address
> block.  The geometric possibilities alone are astounding.....

Yes, but the new company must justify the space to the nic.

Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From bnite at tremere.ios.com  Sun Mar  9 15:07:55 1997
From: bnite at tremere.ios.com (Golan Ben-Oni)
Date: Sun, 9 Mar 1997 10:07:55 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.LNX.3.95.970309095924.4476E-100000@netrail.net>
Message-ID: <Pine.SUN.3.95.970309100528.13274A-100000@tremere.ios.com>

> On Sat, 8 Mar 1997, Paul Ferguson wrote:
> 
> > You know what they say, 'Possession is 9/10'ths of the law'.  ;-)
> 
> Next time you rent a car, when you finish driving over the things that can
> kill your tires. Just yell to the guy 'Possession is 9/10'th of the law'
> and never come back. 

Only, they've got signed paperwork which encourages you to return the
rental when you're not using it.





From pferguso at cisco.com  Sun Mar  9 15:20:01 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 09 Mar 1997 10:20:01 -0500
Subject: Class "B" forsale (fwd)
Message-ID: <3.0.32.19970309101958.006c3888@lint.cisco.com>

At 10:07 AM 3/9/97 -0500, Golan Ben-Oni wrote:

>> Next time you rent a car, when you finish driving over the things that can
>> kill your tires. Just yell to the guy 'Possession is 9/10'th of the law'
>> and never come back. 
>
>Only, they've got signed paperwork which encourages you to return the
>rental when you're not using it.
>

And pay for damages.  ;-)

- paul





From pferguso at cisco.com  Sun Mar  9 15:18:52 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Sun, 09 Mar 1997 10:18:52 -0500
Subject: Class "B" forsale (fwd)
Message-ID: <3.0.32.19970309101850.006ba0ac@lint.cisco.com>

At 10:01 AM 3/9/97 -0500, Nathan Stratton wrote:

>
>Next time you rent a car, when you finish driving over the things that can
>kill your tires. Just yell to the guy 'Possession is 9/10'th of the law'
>and never come back. 
>

Bad analogy.

- paul





From jtk at titania.net  Sun Mar  9 09:38:37 1997
From: jtk at titania.net (Joseph T. Klein)
Date: Sun,  9 Mar 97 09:38:37 Central Standard Time
Subject: Class "B" forsale (fwd) 
References: <3.0.32.19970309101958.006c3888@lint.cisco.com> 
Message-ID: <Chameleon.857922444.jtk@monet.titania.net>

More than a few people have hoarded, sold, and exchanged
Class Bs for profit. Such exchanges should be given the
same value as the deed to the Brooklyn Bridge and lunar
land parcels.

The result of a few gaining money for B space has been
to encourage people to horde it.
--
From:   Joseph T. Klein, Titania Corporation http://www.titania.net
E-mail: jtk at titania.net  Sent:   09:38:37 CST/CDT 03/09/97

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
                -- Benjamin Franklin, 1759




From blh at nol.net  Sun Mar  9 17:07:38 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 11:07:38 -0600 (CST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Chameleon.857922444.jtk@monet.titania.net>
Message-ID: <Pine.GSO.3.95.970309110535.27751F-100000@dazed.nol.net>

Demand vs. Supply, this sounds like a 3rd grade economics class. This is no
longer a couple of colleges with a bunch of grad students folks. This is a
worldwide business (no matter how much me, you, or anyone else would like it
be something else) and people are here to make a dollar. If I can makea few
bucks (or a hell of a lot of bucks) by selling space that is mine to do with
as I please.. so be it.


On Sun, 9 Mar 1997, Joseph T. Klein wrote:

> 
> More than a few people have hoarded, sold, and exchanged
> Class Bs for profit. Such exchanges should be given the
> same value as the deed to the Brooklyn Bridge and lunar
> land parcels.
> 
> The result of a few gaining money for B space has been
> to encourage people to horde it.
> --
> From:   Joseph T. Klein, Titania Corporation http://www.titania.net
> E-mail: jtk at titania.net  Sent:   09:38:37 CST/CDT 03/09/97
> 
> "They that can give up essential liberty to obtain a little temporary
> safety deserve neither liberty nor safety."
>                 -- Benjamin Franklin, 1759
> 

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From blh at nol.net  Sun Mar  9 17:05:00 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 11:05:00 -0600 (CST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.LNX.3.95.970309100421.4476F-100000@netrail.net>
Message-ID: <Pine.GSO.3.95.970309105846.27751E-100000@dazed.nol.net>

On Sun, 9 Mar 1997, Nathan Stratton wrote:

> > It also does not prevent someone from selling not an IP address block, 
> > but selling ownership of a company that happens to own an IP address
> > block.  The geometric possibilities alone are astounding.....
> 
> Yes, but the new company must justify the space to the nic.

Why? Is there a signed contract tht says I must return unwanted/unused space
to the nic? If so lets go recollect all those IPs being wasted by Frito-Lay,
MIT, and countless other orignizations that got their space before anyone
had to justify needs for IP space.

Face it, all the nic is, is a 'globally' (not totally true but good enough
for our purposes) storage facility that allocates its resources on a first
come, as needed basis. If I have a stockpile of typing paper that I'm
willing to sell because I don't need it should I sent it back to the
wharehouse or should I sell it to the guy next door who's willing to give me
10 bucks per carton?

You are assuming that the nic/ARIN is the end all be all of IP space, and
thats just not true. I could for example go to IANA and request space (no
doubt they would turn me down unless I had a damn good reason) if I wanted
to, one does _NOT_ have to go through the Nic/ARIN.

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From ahp at hilander.com  Sun Mar  9 17:35:50 1997
From: ahp at hilander.com (Alec H. Peterson)
Date: Sun, 9 Mar 1997 12:35:50 -0500
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.GSO.3.95.970309105846.27751E-100000@dazed.nol.net>; from "Brett L. Hawn" on Mar 9, 1997 11:05:00 -0600
References: <Pine.LNX.3.95.970309100421.4476F-100000@netrail.net> <Pine.GSO.3.95.970309105846.27751E-100000@dazed.nol.net>
Message-ID: <19970309123550.RL41297@kurgan.erols.com>

On Mar 9, 1997, Brett L. Hawn wrote:
> 
> Why? Is there a signed contract tht says I must return
> unwanted/unused space to the nic?

No, but by the same token, you do not own your IP addresses, you
simply have the right to use them.  You never signed anything that
said you _do_ have unlimited rights to them, so by your logic the NIC
(or IANA) is completely within its rights to take away said IP address
and re-assign them to somebody who will actually use them.

> 
> Face it, all the nic is, is a 'globally' (not totally true but good
> enough for our purposes) storage facility that allocates its
> resources on a first come, as needed basis. If I have a stockpile of
> typing paper that I'm willing to sell because I don't need it should
> I sent it back to the wharehouse or should I sell it to the guy next
> door who's willing to give me 10 bucks per carton?

Paper is a renewable resource; IP addresses are _definitely_ not in
this category.

> 
> You are assuming that the nic/ARIN is the end all be all of IP
> space, and thats just not true. I could for example go to IANA and
> request space (no doubt they would turn me down unless I had a damn
> good reason) if I wanted to, one does _NOT_ have to go through the
> Nic/ARIN.

Granted the InterNIC is not the end all and be all of IP address
allocation, but the point is that _somebody_ is almost certainly going
to have something to say about the auctioning of IP addresses.  

Alec

-- 
+------------------------------------+--------------------------------------+
|Alec Peterson - ahp at hilander.com    | Erols Internet Services, INC.        |
|Network Engineer                    | Springfield, VA.                     |
+------------------------------------+--------------------------------------+




From michael at memra.com  Sun Mar  9 17:43:12 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 09:43:12 -0800 (PST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.GSO.3.95.970309070145.10593B-100000@dazed.nol.net>
Message-ID: <Pine.BSI.3.93.970309093415.3632A-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, Brett L. Hawn wrote:

> On Sun, 9 Mar 1997, David R. Conrad wrote:
> 
> > >	The way I see it, it is worth no more than $10,000. As that is what
> > >ARIN is going to charge any corp to get a Class B. 
> > 
> > How much is your time (spent making up and writing the justification for
> > a class B) worth?
> 
> I think you miss my point, since the ARIN is for all intents and purposes
> selling address space, who are they to say no? 

But ARIN is *NOT* selling address space. That is not the intent of ARIN
nor is it the purpose of ARIN. With that thought in mind, try reading
through the material at http://www.arin.net once again.

> doing, but I certainly can't say anything 'wrong' about it either.

Read RFC2050. It has this statement

   7.  The transfer of IP addresses from one party to another must be
       approved by the regional registries.  The party trying to obtain
       the IP address must meet the same criteria as if they were
       requesting an IP address directly from the IR.

> I change all the records to point to them, swip it out to them, basically do
> everything needed to make them the legitimate 'owners' of that block, they
> pay me a nice lump of cash and we're both happy.

According to that clause above, you can't SWIP it out to them without
lying. Lying is wrong. According to the above clause, the new owner has to
meet the same criteria for receiving address space as you do. If they
did meet those criteria and if you charge them more than the cost of
applying for free address space then you are ripping them off which is
wrong.


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From jfbb at atmnet.net  Sun Mar  9 18:09:49 1997
From: jfbb at atmnet.net (Jim Browning)
Date: Sun, 9 Mar 1997 10:09:49 -0800
Subject: Class "B" forsale (fwd)
Message-ID: <01BC2C72.066E0A20@jfbb.atmnet.net>

>From:  Vab Goel[SMTP:vgoel at sprint.net]
>Sent:  Saturday, March 08, 1997 10:18 PM
>
>>On Sat, 8 Mar 1997, Pete Kruckenberg wrote:
>
>> What kinds of guarantees are there that if someone buys it, that they
>>will  actually be able to get and keep this Class B?
>
>If buyer & seller make a deal, with the current model buyer will be able
>to use it without any problem.

When what is actually happening differs wildly from documented policies, it 
is a pretty good sign that something needs to change. RFCs should either be 
followed or changed.  Otherwise a crack is opened which may allow splinter 
groups to define their own policies in other areas (AlterNIC, etc.)
-
Jim Browning





From karl at Mcs.Net  Sun Mar  9 18:14:36 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Sun, 9 Mar 1997 12:14:36 -0600
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.BSI.3.93.970309093415.3632A-100000@sidhe.memra.com>; from Michael Dillon on Sun, Mar 09, 1997 at 09:43:12AM -0800
References: <Pine.GSO.3.95.970309070145.10593B-100000@dazed.nol.net> <Pine.BSI.3.93.970309093415.3632A-100000@sidhe.memra.com>
Message-ID: <19970309121436.52749@Jupiter.Mcs.Net>

On Sun, Mar 09, 1997 at 09:43:12AM -0800, Michael Dillon wrote:
> On Sun, 9 Mar 1997, Brett L. Hawn wrote:
> 
> > On Sun, 9 Mar 1997, David R. Conrad wrote:
> > 
> > > >	The way I see it, it is worth no more than $10,000. As that is what
> > > >ARIN is going to charge any corp to get a Class B. 
> > > 
> > > How much is your time (spent making up and writing the justification for
> > > a class B) worth?
> > 
> > I think you miss my point, since the ARIN is for all intents and purposes
> > selling address space, who are they to say no? 
> 
> But ARIN is *NOT* selling address space. That is not the intent of ARIN
> nor is it the purpose of ARIN. With that thought in mind, try reading
> through the material at http://www.arin.net once again.
> 
> > doing, but I certainly can't say anything 'wrong' about it either.
> 
> Read RFC2050. It has this statement
> 
>    7.  The transfer of IP addresses from one party to another must be
>        approved by the regional registries.  The party trying to obtain
>        the IP address must meet the same criteria as if they were
>        requesting an IP address directly from the IR.

Read RFC2008:

Rekhter & Li             Best Current Practice                  [Page 5]
RFC 2008                                                    October 1996
 
 
   "address ownership" policy, the organization would be able to use
   these addresses to gain access to the Internet routing services,
   regardless of where the organization connects to the Internet.
 
   While it has never been explicitly stated that various Internet
   Registries use the "address ownership" allocation policy, it has
   always been assumed (and practiced).

Oh oh... :-)

For address space assigned, transferred or delegated prior to October 1996,
you've got a problem.

> Michael Dillon                   -               Internet & ISP Consulting
> Memra Software Inc.              -                  Fax: +1-250-546-3049
> http://www.memra.com             -               E-mail: michael at memra.com

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From blh at nol.net  Sun Mar  9 18:19:52 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 12:19:52 -0600 (CST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <19970309123550.RL41297@kurgan.erols.com>
Message-ID: <Pine.GSO.3.95.970309121359.4399A-100000@dazed.nol.net>

On Sun, 9 Mar 1997, Alec H. Peterson wrote:

> No, but by the same token, you do not own your IP addresses, you
> simply have the right to use them.  You never signed anything that
> said you _do_ have unlimited rights to them, so by your logic the NIC
> (or IANA) is completely within its rights to take away said IP address
> and re-assign them to somebody who will actually use them.

Ok, I'm leasing it, consider my 'sale' of such as sublease, if I'm paying
money for it (which indeed I am with ARIN) then I certainly have some
rights. Add to which (and god how I hate sounding like flemming or denniger
here but..) who voted them to be the end all be all of IP allocations? I
could, if I so desired, right now, pull 223.223.0.0 out of my ass and start
routing it, and the nic/arin/IANA couldn't do squat about it. Core router
operators could, but thats a whole different discussion.

> Paper is a renewable resource; IP addresses are _definitely_ not in
> this category.

BUt you just said they were via recylcin unused space, so which is it?

> Granted the InterNIC is not the end all and be all of IP address
> allocation, but the point is that _somebody_ is almost certainly going
> to have something to say about the auctioning of IP addresses.  

Oh, I don't doubt for a moment they'll have something to say about it, I'm
just debating on if their comments will be of any value as such. Its no less
than what they're doing (though they do provide some halfassed database
management to kee the records straight) but they're
selling/leasing/auctioning space as welll, even if it is under the guise of
our own best interests.

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From karl at Mcs.Net  Sun Mar  9 18:22:43 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Sun, 9 Mar 1997 12:22:43 -0600
Subject: Class "B" forsale (fwd)
In-Reply-To: <01BC2C72.066E0A20@jfbb.atmnet.net>; from Jim Browning on Sun, Mar 09, 1997 at 10:09:49AM -0800
References: <01BC2C72.066E0A20@jfbb.atmnet.net>
Message-ID: <19970309122243.11206@Jupiter.Mcs.Net>

On Sun, Mar 09, 1997 at 10:09:49AM -0800, Jim Browning wrote:
> >From:  Vab Goel[SMTP:vgoel at sprint.net]
> >Sent:  Saturday, March 08, 1997 10:18 PM
> >
> >>On Sat, 8 Mar 1997, Pete Kruckenberg wrote:
> >
> >> What kinds of guarantees are there that if someone buys it, that they
> >>will  actually be able to get and keep this Class B?
> >
> >If buyer & seller make a deal, with the current model buyer will be able
> >to use it without any problem.
> 
> When what is actually happening differs wildly from documented policies, it 
> is a pretty good sign that something needs to change. RFCs should either be 
> followed or changed.  Otherwise a crack is opened which may allow splinter 
> groups to define their own policies in other areas (AlterNIC, etc.)
> -
> Jim Browning

Under RFC2008, addresses delegated prior to October 1996 have been presumed 
to be, in many cases, "owned".  RFC2008 both documented prior practice and 
introduced a new practice.  

RFC2008 is, IMHO, in many ways a watershed document as it applies to IP 
numbers and their assignment.

Please read the RFC.

Now if you got an address block with the STIPULATION that its not owned,
then that's different.  But absent a declaration for delegations which took
place before October of last year, the *presumption* has been, in many
cases, that delegations in fact do transfer ownership, and that has in 
fact been practiced throughout the Internet community.  This is particularly
true for assignments which would otherwise be portable (ie: /19s and larger)
if made today.

It CERTAINLY applies to a /16 in the Class "B" historical space; that IS
globally valid under today's practice.

You can change things going forward. You *can't* redefine history.  It 
doesn't work that way.

BTW, I'm one of the "good guys" in this debate folks -- before you start
taking cheap shots.  I returned an /11 (yep, 32 Class "B"s) when VideOcart 
Inc. folded, and didn't have to -- my name was listed as the coordinator.  
I knew that I would probably NEVER be able to justify the efficient 
utilization of that much space, and I had no interest in trying to sell 
or otherwise "deal" in it.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From blh at nol.net  Sun Mar  9 18:26:11 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 12:26:11 -0600 (CST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.BSI.3.93.970309093415.3632A-100000@sidhe.memra.com>
Message-ID: <Pine.GSO.3.95.970309122037.4399B-100000@dazed.nol.net>

On Sun, 9 Mar 1997, Michael Dillon wrote:

> > I think you miss my point, since the ARIN is for all intents and purposes
> > selling address space, who are they to say no? 
> 
> But ARIN is *NOT* selling address space. That is not the intent of ARIN
> nor is it the purpose of ARIN. With that thought in mind, try reading
> through the material at http://www.arin.net once again.

Been there, read that, and I still say they're selling space, leasing space,
auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
bannana peels) for services rendered. Their services are to hand out IP
space and maintain databases, therefor they are SELLING space.

> > doing, but I certainly can't say anything 'wrong' about it either.
> 
> Read RFC2050. It has this statement
> 
>    7.  The transfer of IP addresses from one party to another must be
>        approved by the regional registries.  The party trying to obtain
>        the IP address must meet the same criteria as if they were
>        requesting an IP address directly from the IR.

The last time I checked RFC's were not GOSPEL, they are a good idea to
follow but are NOT mandatory. I could turn around tomorrow and create an MUA
that doesn't follow the SMTP RFC except in the most remote cases and whats
going to happen? _NOTHING_, why? because RFCs simply are not the GOSPEL, and
lets face it, stupid traditions are just that, stupid traditions, this is no
longer your cozy little lounge, there are millions of people here and just
because you got here first doesn't mean you're allowed to make decisions for
the rest of them.

> According to that clause above, you can't SWIP it out to them without
> lying. Lying is wrong. According to the above clause, the new owner has to
> meet the same criteria for receiving address space as you do. If they
> did meet those criteria and if you charge them more than the cost of
> applying for free address space then you are ripping them off which is
> wrong.

Since I've already gone over the fact that RFCs can be treated just like
toilet paper (ie. Netscape, MSIE, and countless thousands of other products)
I'll ignore your primary argument as worthless.

They met my critiera, not yours, no lieing there, and if they're going to
pay my costs, thats not ripping them off, thats called business.


[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From ahp at hilander.com  Sun Mar  9 18:34:18 1997
From: ahp at hilander.com (Alec H. Peterson)
Date: Sun, 9 Mar 1997 13:34:18 -0500
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.GSO.3.95.970309121359.4399A-100000@dazed.nol.net>;
References: <19970309123550.RL41297@kurgan.erols.com> <Pine.GSO.3.95.970309121359.4399A-100000@dazed.nol.net>
Message-ID: <19970309133418.WA33571@kurgan.erols.com>

This is really more appropriate on NAIPR, so replies are directed
there...

On Mar 9, 1997, Brett L. Hawn wrote:
> 
> Ok, I'm leasing it, consider my 'sale' of such as sublease, if I'm
> paying money for it (which indeed I am with ARIN) then I certainly
> have some rights.

No, that is _not_ what paying ARIN gives you rights to.  All you pay
ARIN for is the registration service, not for the addresses themselves
(be it a lease or a sale).  

> Add to which (and god how I hate sounding like flemming or denniger
> here but..) who voted them to be the end all be all of IP
> allocations? 

Please don't go there, that's a whole can of worms that has already
been discussed many times.

> I could, if I so desired, right now, pull
> 223.223.0.0 out of my ass and start routing it, and the
> nic/arin/IANA couldn't do squat about it. Core router operators
> could, but thats a whole different discussion.

There is nothing they can _directly_ do about it, however there is a
substantial amount that they can do indirectly.  At any rate, this is
not relavent in the sale of IP addresses (which is the discussion at
hand).

> 
> BUt you just said they were via recylcin unused space, so which is
> it?

There is a big difference between a 'recycable' resource and a
'renewable' one.

> 
> Oh, I don't doubt for a moment they'll have something to say about
> it, I'm just debating on if their comments will be of any value as
> such. 

History has shown that they will be.

> Its no less than what they're doing (though they do provide
> some halfassed database management to kee the records straight) but
> they're selling/leasing/auctioning space as welll, even if it is
> under the guise of our own best interests.

Look, this has all been gone over many times, and really is not all
that relavent to the discussion at hand.  The point is that it is one
cannot very well sell something that one does not own.  Well, said
person can try to sell it, but the person who buys it might end up
being disappointed when he/she cannot justify the space to the
InterNIC/ARIN and has it revoked.

Alec

-- 
+------------------------------------+--------------------------------------+
|Alec Peterson - ahp at hilander.com    | Erols Internet Services, INC.        |
|Network Engineer                    | Springfield, VA.                     |
+------------------------------------+--------------------------------------+




From blh at nol.net  Sun Mar  9 18:48:19 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 12:48:19 -0600 (CST)
Subject: class B for sale
Message-ID: <Pine.GSO.3.95.970309123643.6373A-100000@dazed.nol.net>

So that I'm not misunderstood let me say this:

1: I do not neccessarily agree with the sale of IPs, personally, I don't
think its a good idea

2: This is a real world economy now, outdated academic practices which are
currently being enforced are as wrong as the sale of IPs.

3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intents
and purposes a resellable commodity, otherwise ARIN et all can (ala Jim
Flemming) be called on as being a Monopoly.

4: The simple fact of the matter is that the RFCs are not at any time, the
law of the land. They are at best guidelines and good ideas set down for
others to follow, but there is no rule stating that you _must_ follow them.

5: Before you start chasing wild geese selling Class B address space I
suggest you go back and check on all those folks that got space long before
there were any 'restrictions and justifications'. I have no doubt that there
is a veritable feast of IPs sitting unused at MIT, USC, and other such
institutions that would be better used elsewhere instead of sitting in a
corner like a dusty grad student.

6: Finally and most importantly, stop pretending you still live in the world
of happy academia where everyone is willing to follow the rules you set down
just because you're the proffessor and they're the student. This just does
not work anymore, you may scoff at people like Jim Flemming but for each one
you knock down there is another one to learn from his mistakes and take his
place. Do not pretend you can sit idle and call people who don't fall in
line behind you names so that you can sit back in your dusty chair and
pretend nothing is wrong. The internet as a whole is growing at an unthought
of pace and your failure to keep up will not be fixed by being tight assed
and making it harder on those that follow. Eventually someone else will take
the forefront and throw you off your high horse like yesterdays newspaper.
You purport to be leaders of the internet, then its about time you acted
like it and start to solve the problems instead of trying to make the
problems go away by being ignorant of reality.


[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From jfbb at atmnet.net  Sun Mar  9 18:47:48 1997
From: jfbb at atmnet.net (Jim Browning)
Date: Sun, 9 Mar 1997 10:47:48 -0800
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2C77.54934800@jfbb.atmnet.net>

>From:  Michael Dillon[SMTP:michael at memra.com]
>Sent:  Sunday, March 09, 1997 9:43 AM
>
>On Sun, 9 Mar 1997, Brett L. Hawn wrote:
>
>> On Sun, 9 Mar 1997, David R. Conrad wrote:
>>
>> > >	The way I see it, it is worth no more than $10,000. As that is what
>> > >ARIN is going to charge any corp to get a Class B.
>> >
>> > How much is your time (spent making up and writing the justification 
for
>> > a class B) worth?
>>
>> I think you miss my point, since the ARIN is for all intents and 
purposes
>> selling address space, who are they to say no?
>
>But ARIN is *NOT* selling address space. That is not the intent of ARIN
>nor is it the purpose of ARIN. With that thought in mind, try reading
>through the material at http://www.arin.net once again.
>
>> doing, but I certainly can't say anything 'wrong' about it either.
>
>Read RFC2050. It has this statement
>
>   7.  The transfer of IP addresses from one party to another must be
>       approved by the regional registries.  The party trying to obtain
>       the IP address must meet the same criteria as if they were
>       requesting an IP address directly from the IR.
>
>> I change all the records to point to them, swip it out to them, 
basically do
>> everything needed to make them the legitimate 'owners' of that block, 
they
>> pay me a nice lump of cash and we're both happy.
>
>According to that clause above, you can't SWIP it out to them without
>lying. Lying is wrong. According to the above clause, the new owner has to
>meet the same criteria for receiving address space as you do. If they
>did meet those criteria and if you charge them more than the cost of
>applying for free address space then you are ripping them off which is
>wrong.


Internet Service Providers provide a wide variety of services.  Among them 
is loaning the use of IP addresses within the space allocated to them by 
one of the registries.  Some providers are already charging for this 
service, ostensibly to apply economic forces to the conservation of their 
allocated space.  This practice will certainly increase when ARIN begins 
charging registration fees.  If the owner of the Class B in question 
allocates the vast bulk (let's say about 100%  :-) of the space allocated 
to them to a single customer, it appears to me that even if this space is 
inefficiently used (let's say about 0% initially  :-), the only recourse 
the registry has is to withhold future allocations to the "seller".

In this case, I believe the seller could care less about that 'penalty', as 
they would appear to have no need for additional space.

What am I missing here?
--
Jim Browning





From lon at moonstar.com  Sun Mar  9 18:59:11 1997
From: lon at moonstar.com (Lon R. Stockton, Jr.)
Date: Sun, 9 Mar 1997 13:59:11 -0500 (EST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.GSO.3.95.970309122037.4399B-100000@dazed.nol.net>
Message-ID: <Pine.LNX.3.91.970309135638.10067A-100000@luna.moonstar.com>



On Sun, 9 Mar 1997, Brett L. Hawn wrote:

> Been there, read that, and I still say they're selling space, leasing space,
> auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
> bannana peels) for services rendered. Their services are to hand out IP
> space and maintain databases, therefor they are SELLING space.


So, since I paid money for my car registration & license plates, I should 
be able to sell my plates to someone else to put on their car?





From sob at newdev.harvard.edu  Sun Mar  9 18:52:23 1997
From: sob at newdev.harvard.edu (Scott Bradner)
Date: Sun, 9 Mar 1997 13:52:23 -0500 (EST)
Subject: Class "B" forsale (fwd)
Message-ID: <199703091852.NAA05908@newdev.harvard.edu>

Bret fumed:
--
I could turn around tomorrow and create an MUA
that doesn't follow the SMTP RFC except in the most remote cases and whats
going to happen? _NOTHING_, why? because RFCs simply are not the GOSPEL, and
lets face it, stupid traditions are just that, stupid traditions, this is no
longer your cozy little lounge, there are millions of people here and just
because you got here first doesn't mean you're allowed to make decisions for
the rest of them.
--

oh please do -  it is a great business plan for you to do that (at least for
the rest of us)

"standards", standards-track RFCs among them, are generally not "enforced".
If I recall correctly many governments tried to do that with GOSIP, sure
did that set of standards a lot of good.  Some standards are not even perfect. 
But building to a standard is far better for the consumer (remember twisted-
pair Ethernet before the 10BaseT standard?) and better for the vendor.
Just because you decide to start building twisted pair Ethernet after the
standard was adopted does not mean that it all that good a business plan
to do so in a way that is not complient with 10BBaseT.

Scott




From blh at nol.net  Sun Mar  9 19:12:01 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 13:12:01 -0600 (CST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.LNX.3.91.970309135638.10067A-100000@luna.moonstar.com>
Message-ID: <Pine.GSO.3.95.970309131016.9204B-100000@dazed.nol.net>

On Sun, 9 Mar 1997, Lon R. Stockton, Jr. wrote:

> 
> 
> 
> On Sun, 9 Mar 1997, Brett L. Hawn wrote:
> 
> > Been there, read that, and I still say they're selling space, leasing space,
> > auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
> > bannana peels) for services rendered. Their services are to hand out IP
> > space and maintain databases, therefor they are SELLING space.
> 
> 
> So, since I paid money for my car registration & license plates, I should 
> be able to sell my plates to someone else to put on their car?

If you ask me? so long as you reported the sale and did all the paperwork,
sure.. why not.

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From michael at memra.com  Sun Mar  9 19:18:31 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 11:18:31 -0800 (PST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.GSO.3.95.970309122037.4399B-100000@dazed.nol.net>
Message-ID: <Pine.BSI.3.93.970309111155.3632E-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, Brett L. Hawn wrote:

> On Sun, 9 Mar 1997, Michael Dillon wrote:
> 
> > > I think you miss my point, since the ARIN is for all intents and purposes
> > > selling address space, who are they to say no? 
> > 
> > But ARIN is *NOT* selling address space. That is not the intent of ARIN
> > nor is it the purpose of ARIN. With that thought in mind, try reading
> > through the material at http://www.arin.net once again.
> 
> Been there, read that, and I still say they're selling space, leasing space,
> auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
> bannana peels) for services rendered. Their services are to hand out IP
> space and maintain databases, therefor they are SELLING space.

Here in Western Canada, when a piece of real estate is sold you have to
pay a registration fee to the Land Titles office to register the transfer
of ownership. This registration has the same legal force as a deed does in
Eastern Canada. However, in spite of the fact that the Land Titles office
is _CHARGING MONEY_ for services rendered, they are *NOT* selling real
estate. I think ARIN is in a similar position with regard to IP address
space as the Land Titles office. Of course like any analogy it should not
be pushed too far, but I should note that there are situations in which
the land titles office will not accept the transfer of ownership for any
one of a number of reasons, thus they are applying a policy that has been
set down by the community which they service.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From jfbb at atmnet.net  Sun Mar  9 19:22:18 1997
From: jfbb at atmnet.net (Jim Browning)
Date: Sun, 9 Mar 1997 11:22:18 -0800
Subject: measurement
Message-ID: <01BC2C7C.2B182220@jfbb.atmnet.net>

The measurement techniques described thus far focus on performance within 
the bounds of a single network.  While this is of course a challenge, what 
about efforts to measure performance _across_ networks?  I'm not talking 
about NAP packet loss here, but a true measure of expected customer 
satisfaction.  Most customers do not particularly care why they can't 
download the latest MSIE/Navigator release quickly, and getting traffic to 
and through other networks is of equal importance.  Network rating systems 
are starting to emerge, and I think NANOG should participate in their 
evolution...
--
Jim Browning

----------
From:  Randy Bush[SMTP:randy at psg.com]
Sent:  Saturday, March 08, 1997 8:35 PM
To:  nanog at merit.edu
Subject:  Re: measurement

I promised to summarize responses to my query

> So who actually measures their network performance and how?

As most responses were private, I have removed attribution.  Thanks to all
constructive respondees.

I have proposed a survey panel for the next NANOG if we do not exhaust the
subject beforehand.

randy






From michael at memra.com  Sun Mar  9 19:27:10 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 11:27:10 -0800 (PST)
Subject: class B for sale
In-Reply-To: <Pine.GSO.3.95.970309123643.6373A-100000@dazed.nol.net>
Message-ID: <Pine.BSI.3.93.970309112524.3632F-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, Brett L. Hawn wrote:

> You purport to be leaders of the internet, then its about time you acted
> like it and start to solve the problems instead of trying to make the
> problems go away by being ignorant of reality.

There are no leaders of the Internet. The problems are *YOUR* problems and
it is *YOUR* responsibility to solve them as much as anyone else's. As
always, if you're not part of the solution, you're part of the problem.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From davids at wiznet.net  Sun Mar  9 19:44:14 1997
From: davids at wiznet.net (David Schwartz)
Date: Sun, 9 Mar 1997 14:44:14 -0500 (EST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <199703090425.NAA03310@palmtree.jp.apnic.net>
Message-ID: <Pine.LNX.3.91.970309144342.2373F-100000@davids.wiznet.net>


	You could, of course, SWIP (or otherwise delegate) both halves of 
the block to the same maintainer. Same effect.

	DS

 --------------------------------------------------------------------------
 Jeane L. Dixon, world renowned psychic, died Saturday (1/25/97) at age 79.
 There was almost universal sadness and lament throughout the world of
 celebrity psychics. Contacted at her home, Dionne Warwick's spokeswoman
 said that "[Miss] Warwick is beside herself -- none of us expected this to
 happen".
 --------------------------------------------------------------------------

On Sun, 9 Mar 1997, David R. Conrad wrote:

> Hi,
> 
> >I remember going through hell writing the justification for this network.
> >I didn't know the NIC would allow sale of address space. 
> 
> The Internet regsistries cannot disallow someone from selling IP
> address space any more than we can disallow someone selling the
> Brooklyn Bridge, gold painted bricks, or land with a lovely ocean view
> a few miles south of the Everglades.
> 
> However, what we can disallow is the update of the registration
> database when a full registry allocated block is transfered from one
> organization to another.
> 
> Of course, although I work for a registry, I (personally) am under no
> illusion that this will discourage the insistent as it has little
> impact on the operational viability of the network, it just makes
> finding out appropriate contacts when bad things happen a bit more
> difficult.
> 
> Regards,
> -drc
> 
> 




From davids at wiznet.net  Sun Mar  9 20:07:13 1997
From: davids at wiznet.net (David Schwartz)
Date: Sun, 9 Mar 1997 15:07:13 -0500 (EST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.LNX.3.91.970309135638.10067A-100000@luna.moonstar.com>
Message-ID: <Pine.LNX.3.91.970309150638.2373M-100000@davids.wiznet.net>


	No, but you should be able to let someone else use your car 
without them having to get their own plates and registration. For every 
silly analogy there is an equal and opposite -- sorry, silly analogy.

	DS

 --------------------------------------------------------------------------
 Jeane L. Dixon, world renowned psychic, died Saturday (1/25/97) at age 79.
 There was almost universal sadness and lament throughout the world of
 celebrity psychics. Contacted at her home, Dionne Warwick's spokeswoman
 said that "[Miss] Warwick is beside herself -- none of us expected this to
 happen".
 --------------------------------------------------------------------------

On Sun, 9 Mar 1997, Lon R. Stockton, Jr. wrote:

> 
> 
> On Sun, 9 Mar 1997, Brett L. Hawn wrote:
> 
> > Been there, read that, and I still say they're selling space, leasing space,
> > auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
> > bannana peels) for services rendered. Their services are to hand out IP
> > space and maintain databases, therefor they are SELLING space.
> 
> 
> So, since I paid money for my car registration & license plates, I should 
> be able to sell my plates to someone else to put on their car?
> 
> 




From blh at nol.net  Sun Mar  9 20:17:44 1997
From: blh at nol.net (Brett L. Hawn)
Date: Sun, 9 Mar 1997 14:17:44 -0600 (CST)
Subject: class B for sale
In-Reply-To: <Pine.BSI.3.93.970309112524.3632F-100000@sidhe.memra.com>
Message-ID: <Pine.GSO.3.95.970309141633.16024C-100000@dazed.nol.net>

On Sun, 9 Mar 1997, Michael Dillon wrote:

> There are no leaders of the Internet. The problems are *YOUR* problems and
> it is *YOUR* responsibility to solve them as much as anyone else's. As
> always, if you're not part of the solution, you're part of the problem.

You know, that last line is so overused its sad to see someone I would like
to think is intelligent use it. I as a person am not capable of changing the
way things work at ARIN or across the internet as a whole, but yet I am not
the problem either. I'm at best a bystander watching you people play your
silly games and pointing out what I think is right or wrong.

[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From jbrowne at jbrowne.com  Sun Mar  9 20:10:11 1997
From: jbrowne at jbrowne.com (Jim Browne)
Date: Sun, 9 Mar 1997 12:10:11 -0800
Subject: class B for sale
In-Reply-To: <Pine.BSI.3.93.970309112524.3632F-100000@sidhe.memra.com>
References: <Pine.GSO.3.95.970309123643.6373A-100000@dazed.nol.net>
Message-ID: <v03007803af48c4d84d22@[207.135.64.130]>

At 11:27 -0800 3/9/97, Michael Dillon wrote:
>On Sun, 9 Mar 1997, Brett L. Hawn wrote:
>
>> You purport to be leaders of the internet, then its about time you acted
>> like it and start to solve the problems instead of trying to make the
>> problems go away by being ignorant of reality.
>
>There are no leaders of the Internet.

Yes, there are no leaders, just rulers (IANA, InterNIC, etc.).  It's about
time the rulers started leading, or they will be ignored (seeming divine
right notwithstanding).

>The problems are *YOUR* problems and
>it is *YOUR* responsibility to solve them as much as anyone else's.

Wow, that sounds a lot like fingerpointing.  It's not my problem, it's
yours.  My network isn't losing packets, the NAPs are.  My peering
requirements are reasonable, yours aren't.  My HOL blocking isn't the
problem, your refusal to daisy chain a second non-working device is the
problem.  I'm sure that's not what you meant, Michael, but the wording is
rather ironic given the outcome of packet loss/performance discussions at
NANOG (yuk yuk).

>As always, if you're not part of the solution, you're part of the problem.

The prevailing attitude here seems to be "If it's not my solution, you are
part of the problem."

The tendency of network operators in this arena to jump up and down
screaming "WAH WAH WAH WAH" with their fingers in their ears when problems
are pointed out is rather disturbing.  It seems that the "players" want to
present an appearance of cooperation to prevent regulation, yet I see no
effective cooperation.  (Yes, CAIDA people, I know you are trying.
However, I don't see the big six at http://compute.merit.edu/ipn.html.)

I'm beginning to think a little regulation will go a long way in correcting
this attitude.  Why shouldn't network metrics be standardized, published,
and audited by an independent agency?  Car manufacturers have to publish
results of their mandatory saftey tests.  I'm sure it is embarrasing as
hell when GM makes an alternator that shreds itself, or a window that
breaks too easily.  But, the public interest is served.  Does this analogy
hold for the Internet?  Well, when the network crashes (or provider A
blackholes provider B, or provider C dumps an OC3 of traffic onto a DS3) it
doesn't kill me, but it sure as hell costs me money... which is nearly as
bad.

Then again, if running a network was easy, it would be about as exciting as
running the cash register at your local Taco Bell.

Jim Browne                                                jbrowne at jbrowne.com
   "Also shocking is just how bad Mark Hamill, Harrison Ford, and Carrie
    Fisher are in their first major roles." - CNN Film Critic Paul Tatara






From JimFleming at unety.net  Sun Mar  9 20:22:31 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 14:22:31 -0600
Subject: Cayman Island Scenarios
Message-ID: <01BC2C95.53BBD820@webster.unety.net>

On Sunday, March 09, 1997 1:09 AM, Brett L. Hawn[SMTP:blh at nol.net] wrote:
@ On Sun, 9 Mar 1997, David R. Conrad wrote:
<snip>
@ 
@ Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
@ is in order as it should be. I decide for whatever reason to turn off my
@ routers, sell my equipment and move to the Caymans to enjoy the rest of my
@ life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
@ block to someone else and make a small (or large for that matter, I'm sure I
@ could sell it for a interesting sum of money) profit.
@ 
@ scenario 1:
@ 
@ It gets returned and some other poor fool has to jump through flaming hoops
@ and surive a pool of toxic waste to get a few IPs.
@ 
@ scenario 2:
@ 
@ I change all the records to point to them, swip it out to them, basically do
@ everything needed to make them the legitimate 'owners' of that block, they
@ pay me a nice lump of cash and we're both happy.
@ 
@ As I see it, changing ownership of IPs is no different than changing
@ ownership of a domain. 
@ 


Scenario 3:

	You sell the entire company before turning off the routers and
	the block stays with the operation on a lease arrangement.
	It eventually gets absorbed into a larger ISP and lost on the
	books in the mega transaction.

Scenario 4:

	You move to the Cayman Islands and set up a competing
	"NIC". One of the NICs currently operates out of the
	Seychelles, so maybe the Caymans are the next best
	place to start an address NIC.

Question: When companies like MCI and Bellcore get bought,
	do they have to turn all of their blocks back into the "NIC"
	and start over...;-)


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Sun Mar  9 20:33:58 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 14:33:58 -0600
Subject: IP Address Ownership
Message-ID: <01BC2C96.ED627320@webster.unety.net>

On Sunday, March 09, 1997 12:34 PM, Alec H. Peterson[SMTP:ahp at hilander.com] wrote:
@ This is really more appropriate on NAIPR, so replies are directed
@ there...
@ 
@ On Mar 9, 1997, Brett L. Hawn wrote:
@ > 
@ > Ok, I'm leasing it, consider my 'sale' of such as sublease, if I'm
@ > paying money for it (which indeed I am with ARIN) then I certainly
@ > have some rights.
@ 
@ No, that is _not_ what paying ARIN gives you rights to.  All you pay
@ ARIN for is the registration service, not for the addresses themselves
@ (be it a lease or a sale).  
@ 
@ > Add to which (and god how I hate sounding like flemming or denniger
@ > here but..) who voted them to be the end all be all of IP
@ > allocations? 
@ 
@ Please don't go there, that's a whole can of worms that has already
@ been discussed many times.
@ 

ARIN does not solve any GLOBAL Internet problems. ARIN
mostly attempts to solve some internal InterNIC, NSI (SAIC), and NSF
problems. If people want to study ARIN, I suggest they do that
via <http://www.arin.net> and the proposed ARIN Board of Trustees.

IP Address Ownership IS a global Internet issue. In my opinion
I would think that it is an important issue for NANOG members.
Some suggest that it is not, since it is largely a techno-political
issue and not a router failure or network outage problem.

In the coming months you will be seeing some interesting news,
proposals, products and services coming on the scene. The
leadership of NANOG may choose to keep you informed, they
may not, that is their choice and your choice.

If anyone is interested in discussing IP Address Ownership
off-line, you know where I am at in the Caribbean...;-)

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From GAVRON at ACES.COM  Sun Mar  9 21:24:17 1997
From: GAVRON at ACES.COM (Ehud Gavron)
Date: Sun, 09 Mar 1997 14:24:17 -0700 (MST)
Subject: Is the InterNIC really screwed in the head?
Message-ID: <01IGAVHDAIKYQO5Z6K@ACES.COM>

RFC954 specifies WHOIS.  Client requests, server sends.  Simple, really.

$ whois opus4-hst
....
Would you like to see registered users of this host?

	WHAT???  My whois client is supposed to search for this string
	and then do interactive input???  HuH??


$ whois pa aces

(shows a handful of entries)

There are 96 more matches.... would you like these displayed?

	EH?

	Anyone else think this is not only a gross violation of an RFC,
	does a disservice to millions of WHOIS-using users out there, and
	the final leg of the dissolution of the world?

	Ehud




From mrbill at texas.net  Sun Mar  9 21:42:06 1997
From: mrbill at texas.net (Bill Bradford)
Date: Sun, 9 Mar 1997 15:42:06 -0600 (CST)
Subject: Is the InterNIC really screwed in the head?
In-Reply-To: <01IGAVHDAIKYQO5Z6K@ACES.COM>
Message-ID: <Pine.GSO.3.95.970309154133.7931C-100000@staff1.texas.net>

On Sun, 9 Mar 1997, Ehud Gavron wrote:
> RFC954 specifies WHOIS.  Client requests, server sends.  Simple, really.
> $ whois opus4-hst
> ....
> Would you like to see registered users of this host?
> 	WHAT???  My whois client is supposed to search for this string
> 	and then do interactive input???  HuH??
> $ whois pa aces
> (shows a handful of entries)
> There are 96 more matches.... would you like these displayed?
> 	EH?
> 	Anyone else think this is not only a gross violation of an RFC,
> 	does a disservice to millions of WHOIS-using users out there, and
> 	the final leg of the dissolution of the world?
> 	Ehud

I think your WHOIS may be messed up:

(mrbill) staff1:~$ whois opus4-hst
[No name] (OPUS4-HST)

   Hostname: NS.OPUS1.COM
   Address: 192.245.12.50
   System: VAX running VMS

   Domain Server

   Record last updated on 13-Feb-94.


To see this host record with registered users, repeat the command with
a star ('*') before the name; or, use '%' to show JUST the registered users.

The InterNIC Registration Services Host contains ONLY Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.

Bill Bradford (BB2623)			Systems Admin, UNIX geek, BOFH
mrbill at texas.net * mrbill at mrbill.net	Texas Networking, Inc.
-------------------------------------------------------------------------
"Un-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information 
 is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS."
                                             -- Robert E. McElwaine





From GAVRON at ACES.COM  Sun Mar  9 21:44:56 1997
From: GAVRON at ACES.COM (Ehud Gavron)
Date: Sun, 09 Mar 1997 14:44:56 -0700 (MST)
Subject: Is the InterNIC really screwed in the head?
In-Reply-To: "Your message dated Sun, 09 Mar 1997 15:42:06 -0600 (CST)"
 <Pine.GSO.3.95.970309154133.7931C-100000@staff1.texas.net>
References: <01IGAVHDAIKYQO5Z6K@ACES.COM>
Message-ID: <01IGAW9N53E2QO5Z1M@ACES.COM>

Bill Bradford said:
>On Sun, 9 Mar 1997, Ehud Gavron wrote:
>> RFC954 specifies WHOIS.  Client requests, server sends.  Simple, really.
>> $ whois opus4-hst
>> ....
>> Would you like to see registered users of this host?
>> 	WHAT???  My whois client is supposed to search for this string
...
>I think your WHOIS may be messed up:

>(mrbill) staff1:~$ whois opus4-hst

	No, I think yours is.

	% telnet whois.internic.net whois
OPUS4-HST<CR>
[No name] (OPUS4-HST)

   Hostname: NS.OPUS1.COM
   Address: 192.245.12.50
   System: VAX running VMS

   Domain Server

   Record last updated on 13-Feb-94.

Would you like to see the registered users of this host? y<CR>


   No registered users.

The InterNIC Registration Services Host contains ONLY Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.

	Go fix it.
	
	E


>[No name] (OPUS4-HST)

>   Hostname: NS.OPUS1.COM
>   Address: 192.245.12.50
>   System: VAX running VMS

>   Domain Server

>   Record last updated on 13-Feb-94.


>To see this host record with registered users, repeat the command with
>a star ('*') before the name; or, use '%' to show JUST the registered users.

>The InterNIC Registration Services Host contains ONLY Internet Information
>(Networks, ASN's, Domains, and POC's).
>Please use the whois server at nic.ddn.mil for MILNET Information.

>Bill Bradford (BB2623)			Systems Admin, UNIX geek, BOFH
>mrbill at texas.net * mrbill at mrbill.net	Texas Networking, Inc.
>-------------------------------------------------------------------------
>"Un-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information
> is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS."
>                                             -- Robert E. McElwaine





From matt at netmeg.net  Sun Mar  9 21:50:00 1997
From: matt at netmeg.net (Matt Magri)
Date: Sun, 9 Mar 97 16:50 EST
Subject: Class "B" forsale (fwd)
In-Reply-To: <m0w3b7p-0007zcC@rip.psg.com>
Message-ID: <m0w3qUU-0001UWC@netmeg.net>

Michael Dillon <michael at memra.com> wrote:
>randy at psg.com (Randy Bush) wrote:
>> Market forces have been shown to be a more efficient mechanism to
>> determine "need" than central planning when no objective and easily
>> measured criteria can be determined.
>
> With "No objective and easily measured criteria," it would seem to be hard
> to measure efficiency.

The point is that without "objective and easily measured criteria" it
is flat out impossible for central planning to produce anything
approaching an efficient outcome.

> Historically, open markets have worked well sometimes and not worked others.

This is kind of a meaningless statement without some examples. How is
anyone to glean anything from it without some idea of what conditions
you think it will or won't work well under? At any rate, I don't recall
Michael using terms like "worked well", etc. His claim was that it was
"more efficient". I might not like the way it would shake out, but if
certain conditions were to exist (ownership, ability to change prices
easily to match demand, technological alternatives to getting more IP's,
etc.) then the result would be the "most efficient."

> Pre-judging how one might work in IPv4 addresses would seem hubris.

Once again, this statement doesn't really say anything either. Does
this mean that we shouldn't do anything? Any course chosen would
require "pre-judging" by this criteria, after all. If you'd like to
present reasons why you are skeptical about market forces providing an
efficient mechanism then go ahead. Pointing out that Michael (or you,
or I, or anyone) can't predict the future with a 100% accuracy seems...
well, pointless.

Matt




From GAVRON at ACES.COM  Sun Mar  9 21:34:15 1997
From: GAVRON at ACES.COM (Ehud Gavron)
Date: Sun, 09 Mar 1997 14:34:15 -0700 (MST)
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
In-Reply-To: "Your message dated Sun, 09 Mar 1997 12:48:19 -0600 (CST)"
 <Pine.GSO.3.95.970309123643.6373A-100000@dazed.nol.net>
Message-ID: <01IGAW607XEEQO5Z1M@ACES.COM>

	Let me add a word to Brett's comments.  This IS a world-scale
	economy.

	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
	decided TOMORROW that WE will assign address space and route to
	it, there is no force in the world that will charge for it, or
	be able to change it.

	Here's the Ehud Scenario:
		1. Tomorrow Paul Vixie gets a pirate hair up his dec alpha
	  	   and puts in 64.in-addr.arpa. through 126.in-addr.arpa.
		   in F.
		2. We start assigning nets from this block (64/8-126/8).
		3. We start routing to this block (ok, I don't own a backbone
	    	   yet, but let me use "we" meaning nanog for now ;)

	Is this unlawful?  No.  There's no law about announcing routes,
	nor about delegating them in private internets.  For practical
	purposes, NANOG members form a private internet.  

	Is this unethical?  Some would say 'Sure, only the InterNIC and
	IANA can assign IP addresses.'  Some tell me this thinking is
	obsolete.  Jim Fleming would salivate, and Karl Deninger would
	laugh.  Well, maybe.  
	
	Is this impractical?  I dunno.  I figure we could bribe Paul with
	$ 2000 per assignment regardless of size (after all, two NS entries
	are all the same cost).  After about 52 /24s, he'd double his 
	yearly retainer income (all figures guesses with no real basis)
	and probably be able to retire to Caymans.  (That's a Brett Scenario).

	Oh yeah, it's my idea, so I want anyone who gets an allocation from	
	this scheme to send me a bottle of single-malt Scotch.

	Let me know if I've left something out.

	Ehud

	p.s. If I've pissed off anybody in this post, send me a private
	     note via us mail.  Be sure to include a bottle of single malt
	     Scotch or your note will be returned.  Just like email to admin at crl


>So that I'm not misunderstood let me say this:

>1: I do not neccessarily agree with the sale of IPs, personally, I don't
>think its a good idea

>2: This is a real world economy now, outdated academic practices which are
>currently being enforced are as wrong as the sale of IPs.

>3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intents
>and purposes a resellable commodity, otherwise ARIN et all can (ala Jim
>Flemming) be called on as being a Monopoly.

>4: The simple fact of the matter is that the RFCs are not at any time, the
>law of the land. They are at best guidelines and good ideas set down for
>others to follow, but there is no rule stating that you _must_ follow them.

>5: Before you start chasing wild geese selling Class B address space I
>suggest you go back and check on all those folks that got space long before
>there were any 'restrictions and justifications'. I have no doubt that there
>is a veritable feast of IPs sitting unused at MIT, USC, and other such
>institutions that would be better used elsewhere instead of sitting in a
>corner like a dusty grad student.

>6: Finally and most importantly, stop pretending you still live in the world
>of happy academia where everyone is willing to follow the rules you set down
>just because you're the proffessor and they're the student. This just does
>not work anymore, you may scoff at people like Jim Flemming but for each one
>you knock down there is another one to learn from his mistakes and take his
>place. Do not pretend you can sit idle and call people who don't fall in
>line behind you names so that you can sit back in your dusty chair and
>pretend nothing is wrong. The internet as a whole is growing at an unthought
>of pace and your failure to keep up will not be fixed by being tight assed
>and making it harder on those that follow. Eventually someone else will take
>the forefront and throw you off your high horse like yesterdays newspaper.
>You purport to be leaders of the internet, then its about time you acted
>like it and start to solve the problems instead of trying to make the
>problems go away by being ignorant of reality.


>[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
>[-]                Networks On-Line - Houston, Texas                       [-]
>[-]                           713-467-7100                                 [-]





From randy at psg.com  Sun Mar  9 21:56:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 9 Mar 97 13:56 PST
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
References: <Pine.GSO.3.95.970309123643.6373A-100000@dazed.nol.net>
	<01IGAW607XEEQO5Z1M@ACES.COM>
Message-ID: <m0w3qa8-0007zdC@rip.psg.com>

Emilio Bugatti (sp?), at the time the maker of the finest cars in the world,
was asked why the brakes on his cars were not as good as they might be.  He
replied "Any fool can make a car stop.  It takes a genius to make a car go."

I suggest we focus on the latter.

randy




From JimFleming at unety.net  Sun Mar  9 21:53:11 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 15:53:11 -0600
Subject: class B for sale
Message-ID: <01BC2CA1.FE1E80E0@webster.unety.net>

On Sunday, March 09, 1997 6:48 AM, Brett L. Hawn[SMTP:blh at nol.net] wrote:
@ So that I'm not misunderstood let me say this:
@ 
@ 1: I do not neccessarily agree with the sale of IPs, personally, I don't
@ think its a good idea
@ 

There are several issues here:

	1. The ownership of aggregated IPv4 addresses (i.e. blocks).
	2. The leasing of those blocks.
	3. The registration of those blocks.
	4. The reverse resolution of those blocks.
	5. The routing announcement of those blocks.

An "owner" [#1] may not be involved in any of the remaining
activities above and may only care about collecting "rent".

People might find it interesting that several of the companies
with massive /8 allocations do not think they "own" the blocks.
They can not own them because they never paid for them.

Likewise, they are not leasing the blocks, because they do
not know who the owner is and would be willing to pay "rent"
if they could identify the owner.

@@@@@@@@ First 25% of IPv4 Address Space @@@@@@@@@@

CA	0.0.0.0	IANA (RESERVED-1)
CA	1.0.0.0	IANA (RESERVED-9)
CA	2.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-2)
NJ	3.0.0.0	General Electric Company (NET-GE-INTERNET)
MA	4.0.0.0	BBN Planet (NET-SATNET)
CA	5.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-5)
AZ	6.0.0.0	Army Information Systems Center (NET-YPG-NET)
CA	7.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-11)
MA	8.0.0.0	Bolt Beranek and Newman Inc. (NET-BBN-NET-TEMP)
NY	9.0.0.0	IBM Corporation (NET-IBM)
CA	10.0.0.0	IANA (RESERVED-6)
CA	11.0.0.0	DoD Intel Information Systems (NET-DODIIS)
FL	12.0.0.0	AT&T ITS (NET-ATT)
CA	13.0.0.0	Xerox Palo Alto Research Center (NET-XEROX-NET)
CA	14.0.0.0	Public Data Network (NET-PDN)
CA	15.0.0.0	Hewlett-Packard Company (NET-HP-INTERNET)
CA	16.0.0.0	Digital Equipment Corporation (NET-DEC-INTERNET)
CA	17.0.0.0	Apple Computer, Inc. (NET-APPLE-WWNET)
MA	18.0.0.0	Massachusetts Institute of Technology (NET-MIT-TEMP)
MI	19.0.0.0	Ford Motor Company (NET-FINET)
VA	20.0.0.0	Computer Sciences Corporation (NET-CSC)
VA	21.0.0.0	DDN-RVN (NET-DDN-RVN)
DC	22.0.0.0	Defense Information Systems Agency (NET-DISNET)
CA	23.0.0.0	IANA (NET-DDN-TC-NET)
CA	24.0.0.0	@Home Network (NETBLK-ATHOME)	ATHOME  24.0.0.0 - 24.3.255.0
UK	25.0.0.0	Royal Signals and Radar Establishment (NET-RSRE-EXP)
VA	26.0.0.0	Defense Information Systems Agency (NET-MILNET)
CA	27.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-10)
VA	28.0.0.0	ARPA DSI JPO (NET-DSI-NORTH)
DC	29.0.0.0	Defense Information Systems Agency (NET-MILX25-TEMP)
DC	30.0.0.0	Defense Information Systems Agency (NET-ARPAX25-TEMP)
CA	31.0.0.0	IANA (RESERVED-12)
Norway	32.0.0.0	Norsk Informasjonsteknologi (NET-NORGESNETT)
OH	33.0.0.0	DLA Systems Automation Center (NET-DCMC)
TX	34.0.0.0	Halliburton Company (NET-HALLIBURTON)
MI	35.0.0.0	Merit Network Inc. (NET-MERIT)
CA	36.0.0.0	Stanford University (NET-SU-NET-TEMP)
CA	37.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-37A)
VA	38.0.0.0	Performance Systems International (NET-PSINETA)
CA	39.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-39A)
IN	40.0.0.0	Eli Lilly and Company (NET-LILLY-NET)
CA	41.0.0.0	Internet Assigned Numbers Authority (RESERVED-41A)
CA	42.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-42)
Japan	43.0.0.0	Japan Inet (NET-JAPAN-A)
CA	44.0.0.0	Amateur Radio Digital Communications (NET-AMPRNET)
CA	45.0.0.0	Interop Show Network (NET-SHOWNETA)
MA	46.0.0.0	Bolt Beranek and Newman Inc. (NET-BBNNET)
Canada	47.0.0.0	Bell-Northern Research (NET-BNR)
NY	48.0.0.0	Prudential Securities Inc. (NET-PRUBACHE)
	49.0.0.0	No match for "49.0.0.0".
	50.0.0.0	No match for "50.0.0.0".
UK	51.0.0.0	Department of Social Security of UK (NET-ITSANET)
DE	52.0.0.0	E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1)
Germany	53.0.0.0	cap debis ccs (NET-DB-NET2)
NJ	54.0.0.0	Merck and Co., Inc. (NET-MERCK2)
VA	55.0.0.0	Army National Guard Bureau (NET-RCAS2)
NC	56.0.0.0	U.S. Postal Service (NET-USPS1)
France	57.0.0.0	SITA-Societe Internationale de Telecommunications Aeronautiques (NET-SITA2)
CA	58.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-58)
CA	59.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-59)
CA	60.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-60)
CA	61.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-61)
CA	62.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-62)
CA	63.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) (NET-RESERVED-63)
<...>
	@@@@@@@@@

This situation is similar to what happens when you convert a
country from a government where the land is owned by the
state to a situation where private ownership is allowed. There
is a ONE-TIME chicken and egg problem that has to be solved.
Once that occurs, then the free market dictates the rest.

@ 2: This is a real world economy now, outdated academic practices which are
@ currently being enforced are as wrong as the sale of IPs.
@

The real world economy pre-dates the Internet by a few years...

@ 3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intents
@ and purposes a resellable commodity, otherwise ARIN et all can (ala Jim
@ Flemming) be called on as being a Monopoly.
@ 

Again, ARIN is a local solution for an InterNIC/NSF/NSI/SAIC problem.
I suggest that you study that situation and business restructuring.
It is not in the best interest of the Internet to have obscur, complex,
internal problems shape the future of the Global Internet.

I suggest that you think global and act local.
By local...I mean local to you...if you "own" [#1]
IP addresses then you might want to lease [#2]
them. If you lease them, then you might want to
register[#3], resolve[#4], and route[#5] them.

Some people will be involved in all 5 functions
and some in only one of the functions. As owners [#1]
step forward to start charging "rent", the people
currently leasing the space without charge have several
options...
		1. Pay the rent
		2. Buy the space
		3. Find another place to homestead

Prior art will determine who can sell the addresses.
I suggest that people interested in these areas,
carefully study that.

@ 4: The simple fact of the matter is that the RFCs are not at any time, the
@ law of the land. They are at best guidelines and good ideas set down for
@ others to follow, but there is no rule stating that you _must_ follow them.
@ 

The law of the land is the law of the land...most lawyers
have never heard of an RFC...if you do not believe me
just ask them...

@ 5: Before you start chasing wild geese selling Class B address space I
@ suggest you go back and check on all those folks that got space long before
@ there were any 'restrictions and justifications'. I have no doubt that there
@ is a veritable feast of IPs sitting unused at MIT, USC, and other such
@ institutions that would be better used elsewhere instead of sitting in a
@ corner like a dusty grad student.
@ 

Those people are homesteading. When the "owners" of those
spaces come knocking on their door for a rent check, then
they will have to make some decisions.

@ 6: Finally and most importantly, stop pretending you still live in the world
@ of happy academia where everyone is willing to follow the rules you set down
@ just because you're the proffessor and they're the student. This just does
@ not work anymore, you may scoff at people like Jim Flemming but for each one
@ you knock down there is another one to learn from his mistakes and take his
@ place. Do not pretend you can sit idle and call people who don't fall in
@ line behind you names so that you can sit back in your dusty chair and
@ pretend nothing is wrong. The internet as a whole is growing at an unthought
@ of pace and your failure to keep up will not be fixed by being tight assed
@ and making it harder on those that follow. Eventually someone else will take
@ the forefront and throw you off your high horse like yesterdays newspaper.
@ You purport to be leaders of the internet, then its about time you acted
@ like it and start to solve the problems instead of trying to make the
@ problems go away by being ignorant of reality.
@ 

The "world of happy academia" is not a place where people
follow the rules. That is one of the reasons why many people
like that world. They have tenure, they teach what they want,
they post office hours as they like, they dress as they like,
and they use the university and government supplied computers
as they like.

The commercial world follows the rules...the rules needed
to bring order to the IPv4 address space are very simple....

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From jstewart at isi.edu  Sun Mar  9 22:08:13 1997
From: jstewart at isi.edu (John W. Stewart III)
Date: Sun, 09 Mar 1997 17:08:13 EST
Subject: The Mother of all Solutions (Was Class B for Sale or Rent) 
In-Reply-To: Your message of "Sun, 09 Mar 1997 14:34:15 MST."
             <01IGAW607XEEQO5Z1M@ACES.COM> 
Message-ID: <199703092208.AA13379@metro.isi.edu>


hang on there

while i'm actually *not* necessarily against your proposal for
providers to "just take over," i do think you're being a bit
rash.  specifically, if you want to do something like this,
why not actually propose the *way* that the "seized" addresses
would be allocated such that your proposal results in a *less*
chaotic future?  for example, why not try a test run of some
of the market-based approaches others have suggested?  the most
promising one, in my opinion, is scott huddle's proposal for a
market for both addresses and routing table slots; registries
(which cover the address part) would simply record who has
what address while the providers (and whatever other third-
party businesses which might spring up) would deal with the
routing slot part.  this assumes certain mechanisms within
bgp (or some other ~routing protocol) to reserve slots (kind
of like an RSVP for routing [as opposed to forwarding]), but
i think some of the direct implications, as well as some of
the fallout, would be very good and would show the internet
maturing as a service.  i also think it would help technically
by forcing us to answer the question:  "given a time and a
technology, what does 'full' mean for a routing table?"

in other words, if you're gonna take over the world, don't
just do more of the same...

just my US$0.02

/jws

 > 	Let me add a word to Brett's comments.  This IS a world-scale
 > 	economy.
 > 
 > 	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
 > 	decided TOMORROW that WE will assign address space and route to
 > 	it, there is no force in the world that will charge for it, or
 > 	be able to change it.
 > 
 > 	Here's the Ehud Scenario:
 > 		1. Tomorrow Paul Vixie gets a pirate hair up his dec alpha
 > 	  	   and puts in 64.in-addr.arpa. through 126.in-addr.arpa.
 > 		   in F.
 > 		2. We start assigning nets from this block (64/8-126/8).
 > 		3. We start routing to this block (ok, I don't own a backbone
 > 	    	   yet, but let me use "we" meaning nanog for now ;)
 > 
 > 	Is this unlawful?  No.  There's no law about announcing routes,
 > 	nor about delegating them in private internets.  For practical
 > 	purposes, NANOG members form a private internet.  
 > 
 > 	Is this unethical?  Some would say 'Sure, only the InterNIC and
 > 	IANA can assign IP addresses.'  Some tell me this thinking is
 > 	obsolete.  Jim Fleming would salivate, and Karl Deninger would
 > 	laugh.  Well, maybe.  
 > 	
 > 	Is this impractical?  I dunno.  I figure we could bribe Paul with
 > 	$ 2000 per assignment regardless of size (after all, two NS entries
 > 	are all the same cost).  After about 52 /24s, he'd double his 
 > 	yearly retainer income (all figures guesses with no real basis)
 > 	and probably be able to retire to Caymans.  (That's a Brett Scenario).
 > 
 > 	Oh yeah, it's my idea, so I want anyone who gets an allocation from
	
 > 	this scheme to send me a bottle of single-malt Scotch.
 > 
 > 	Let me know if I've left something out.
 > 
 > 	Ehud
 > 
 > 	p.s. If I've pissed off anybody in this post, send me a private
 > 	     note via us mail.  Be sure to include a bottle of single malt
 > 	     Scotch or your note will be returned.  Just like email to admin at cr
l
 > 
 > 
 > >So that I'm not misunderstood let me say this:
 > 
 > >1: I do not neccessarily agree with the sale of IPs, personally, I don't
 > >think its a good idea
 > 
 > >2: This is a real world economy now, outdated academic practices which are
 > >currently being enforced are as wrong as the sale of IPs.
 > 
 > >3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intent
s
 > >and purposes a resellable commodity, otherwise ARIN et all can (ala Jim
 > >Flemming) be called on as being a Monopoly.
 > 
 > >4: The simple fact of the matter is that the RFCs are not at any time, the
 > >law of the land. They are at best guidelines and good ideas set down for
 > >others to follow, but there is no rule stating that you _must_ follow them.
 > 
 > >5: Before you start chasing wild geese selling Class B address space I
 > >suggest you go back and check on all those folks that got space long before
 > >there were any 'restrictions and justifications'. I have no doubt that ther
e
 > >is a veritable feast of IPs sitting unused at MIT, USC, and other such
 > >institutions that would be better used elsewhere instead of sitting in a
 > >corner like a dusty grad student.
 > 
 > >6: Finally and most importantly, stop pretending you still live in the worl
d
 > >of happy academia where everyone is willing to follow the rules you set dow
n
 > >just because you're the proffessor and they're the student. This just does
 > >not work anymore, you may scoff at people like Jim Flemming but for each on
e
 > >you knock down there is another one to learn from his mistakes and take his
 > >place. Do not pretend you can sit idle and call people who don't fall in
 > >line behind you names so that you can sit back in your dusty chair and
 > >pretend nothing is wrong. The internet as a whole is growing at an unthough
t
 > >of pace and your failure to keep up will not be fixed by being tight assed
 > >and making it harder on those that follow. Eventually someone else will tak
e
 > >the forefront and throw you off your high horse like yesterdays newspaper.
 > >You purport to be leaders of the internet, then its about time you acted
 > >like it and start to solve the problems instead of trying to make the
 > >problems go away by being ignorant of reality.
 > 
 > 
 > >[-]                Brett L. Hawn (blh @ nol dot net)                       
[-]
 > >[-]                Networks On-Line - Houston, Texas                       
[-]
 > >[-]                           713-467-7100                                 
[-]
 > 




From randy at psg.com  Sun Mar  9 22:06:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 9 Mar 97 14:06 PST
Subject: measurement
References: <01BC2C7C.2B182220@jfbb.atmnet.net>
Message-ID: <m0w3qjA-0007zdC@rip.psg.com>

> The measurement techniques described thus far focus on performance within 
> the bounds of a single network.  While this is of course a challenge, what 
> about efforts to measure performance _across_ networks?  I'm not talking 
> about NAP packet loss here, but a true measure of expected customer 
> satisfaction.

Expectations of customer satisfaction are aleph nul or likely aleph one.

Measurement of end user delivery are being done rather ad hack (hit the web
site and see how high it bounces) by the folk at Intel, see

    Network Working Group                      J. Sedayao, Intel Corporation
					   C. Bickerstaff, Intel Corporation
    Internet Draft
    Expiration Date: May 1997                                  November 1996

     Simple End to End Metrics and Methods for Monitoring and Measuring IP
			      Provider Performance

The IPPM WG is trying to work upward from a sound theoretical base.  See the
other IPPM drafts and mailing list archives.

randy




From JimFleming at unety.net  Sun Mar  9 22:06:09 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 16:06:09 -0600
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
Message-ID: <01BC2CA3.CE580E60@webster.unety.net>

On Sunday, March 09, 1997 8:34 AM, Ehud Gavron[SMTP:GAVRON at ACES.COM] wrote:
@ 	Let me add a word to Brett's comments.  This IS a world-scale
@ 	economy.
@ 
@ 	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
@ 	decided TOMORROW that WE will assign address space and route to
@ 	it, there is no force in the world that will charge for it, or
@ 	be able to change it.
@ 
@ 	Here's the Ehud Scenario:
@ 		1. Tomorrow Paul Vixie gets a pirate hair up his dec alpha
@ 	  	   and puts in 64.in-addr.arpa. through 126.in-addr.arpa.
@ 		   in F.
@ 		2. We start assigning nets from this block (64/8-126/8).
@ 		3. We start routing to this block (ok, I don't own a backbone
@ 	    	   yet, but let me use "we" meaning nanog for now ;)
@ 

Your scenario is very interesting. I suggest that you study
prior art. Also, in my other posting I left one of the players out.
I have labeled it 1A. Many owners will not want to "manage"
their blocks just like many people who own large office buildings
do not want to manage the property.

	1. The ownership of aggregated IPv4 addresses (i.e. blocks).
	1A. The management of the blocks.
	2. The leasing of those blocks.
	3. The registration of those blocks.
	4. The reverse resolution of those blocks.
	5. The routing announcement of those blocks.


@ 	Is this unlawful?  No.  There's no law about announcing routes,
@ 	nor about delegating them in private internets.  For practical
@ 	purposes, NANOG members form a private internet.  
@ 
@ 	Is this unethical?  Some would say 'Sure, only the InterNIC and
@ 	IANA can assign IP addresses.'  Some tell me this thinking is
@ 	obsolete.  Jim Fleming would salivate, and Karl Deninger would
@ 	laugh.  Well, maybe.  
@

Please study prior art before jumping to conclusions.

Also, you might want to study the SBA/NSF proposal(s)
that call for the creation of 10 regional InterNIC clones
in the U.S. Each regional InterNIC would have several TLDs
and several /8s to manage to generate revenue to help
cover their costs.
 	
@ 	Is this impractical?  I dunno.  I figure we could bribe Paul with
@ 	$ 2000 per assignment regardless of size (after all, two NS entries
@ 	are all the same cost).  After about 52 /24s, he'd double his 
@ 	yearly retainer income (all figures guesses with no real basis)
@ 	and probably be able to retire to Caymans.  (That's a Brett Scenario).
@

I would first check with the owners of the various
parts of the IPv4 space.
 
@ 	Oh yeah, it's my idea, so I want anyone who gets an allocation from	
@ 	this scheme to send me a bottle of single-malt Scotch.
@ 
@ 	Let me know if I've left something out.
@ 
@ 	Ehud
@ 
@ 	p.s. If I've pissed off anybody in this post, send me a private
@ 	     note via us mail.  Be sure to include a bottle of single malt
@ 	     Scotch or your note will be returned.  Just like email to admin at crl

Why would anyone be upset...?

People most likely fall into one of the following categories...

	1. Owner
	2. Homesteader
	3. Manager
	4. Registrar
	5. Resolver
	6. Router

>From what I understand most of the NANOG people
are #4, #5, or #6. The issues you have raised will mostly
be of interest to people in the categories #1 to #3.



--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From gih at telstra.net  Sun Mar  9 22:23:45 1997
From: gih at telstra.net (Geoff Huston)
Date: Mon, 10 Mar 1997 08:23:45 +1000
Subject: Class "B" forsale (fwd) 
Message-ID: <2.2.32.19970309222345.00689d30@nico.aarnet.edu.au>

Of course this scenario breaks down quickly..

Listed registrant A "sells" to B who "sells" to C who...

Now the sucker who "buys" from C has the problem of tracing authenticity
of the "title" C is selling. This is not easy, particularly if B is less
than scrupulous and has "sold" title to a number of folk including
C, or if C is unscrupulous and is "selling" without have concluded
and transaction with B.

The Land Titles office is there for a damn fine reason. We ignore the
seeds of destructive anarchy in the IP address space at our collective
risk (or is that peril?)

regards,

  Geoff

>Given the registries do not allow for outright transfers of this sort
>directly (see RFC 2050), one course of action would be for the
>original "owner" to sell the "right of use" of the /16.  Of course,
>the appropriate action (according to RFC 2050 and historical Internet
>culture) would be for the original "owner" to return address space
>they don't need...
>
>Regards,
>-drc
>
>
>




From sedriss at Prophet-indy.org  Mon Mar 10 00:16:25 1997
From: sedriss at Prophet-indy.org (Benjamin Inman Vaughn)
Date: Mon, 10 Mar 1997 00:16:25 +0000 (   )
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
In-Reply-To: <01IGAW607XEEQO5Z1M@ACES.COM>
Message-ID: <Pine.LNX.3.95.970310001455.25413A-100000@Judas.prophet-indy.org>


	Less ARIN and NIC are run by the principles Adam Smith described
in the early Nineteenth Century. I don't know, maybe Address assignment is
controlled by the unseen hand of god.

	The beginning and end of it is that selling address space is
against RFC's and ethics, and it should be left at that.

----------------------------
Benajmin Vaughn
Sedriss at IRC
sedriss at prophet-indy.org OR
"whois BV209"
"And the rest is silence."
----------------------------

On Sun, 9 Mar 1997, Ehud Gavron wrote:

> 	Let me add a word to Brett's comments.  This IS a world-scale
> 	economy.
> 
> 	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
> 	decided TOMORROW that WE will assign address space and route to
> 	it, there is no force in the world that will charge for it, or
> 	be able to change it.
> 
> 	Here's the Ehud Scenario:
> 		1. Tomorrow Paul Vixie gets a pirate hair up his dec alpha
> 	  	   and puts in 64.in-addr.arpa. through 126.in-addr.arpa.
> 		   in F.
> 		2. We start assigning nets from this block (64/8-126/8).
> 		3. We start routing to this block (ok, I don't own a backbone
> 	    	   yet, but let me use "we" meaning nanog for now ;)
> 
> 	Is this unlawful?  No.  There's no law about announcing routes,
> 	nor about delegating them in private internets.  For practical
> 	purposes, NANOG members form a private internet.  
> 
> 	Is this unethical?  Some would say 'Sure, only the InterNIC and
> 	IANA can assign IP addresses.'  Some tell me this thinking is
> 	obsolete.  Jim Fleming would salivate, and Karl Deninger would
> 	laugh.  Well, maybe.  
> 	
> 	Is this impractical?  I dunno.  I figure we could bribe Paul with
> 	$ 2000 per assignment regardless of size (after all, two NS entries
> 	are all the same cost).  After about 52 /24s, he'd double his 
> 	yearly retainer income (all figures guesses with no real basis)
> 	and probably be able to retire to Caymans.  (That's a Brett Scenario).
> 
> 	Oh yeah, it's my idea, so I want anyone who gets an allocation from	
> 	this scheme to send me a bottle of single-malt Scotch.
> 
> 	Let me know if I've left something out.
> 
> 	Ehud
> 
> 	p.s. If I've pissed off anybody in this post, send me a private
> 	     note via us mail.  Be sure to include a bottle of single malt
> 	     Scotch or your note will be returned.  Just like email to admin at crl
> 
> 
> >So that I'm not misunderstood let me say this:
> 
> >1: I do not neccessarily agree with the sale of IPs, personally, I don't
> >think its a good idea
> 
> >2: This is a real world economy now, outdated academic practices which are
> >currently being enforced are as wrong as the sale of IPs.
> 
> >3: Wether you, ARIN, or anyone else likes it or not, IPs are for all intents
> >and purposes a resellable commodity, otherwise ARIN et all can (ala Jim
> >Flemming) be called on as being a Monopoly.
> 
> >4: The simple fact of the matter is that the RFCs are not at any time, the
> >law of the land. They are at best guidelines and good ideas set down for
> >others to follow, but there is no rule stating that you _must_ follow them.
> 
> >5: Before you start chasing wild geese selling Class B address space I
> >suggest you go back and check on all those folks that got space long before
> >there were any 'restrictions and justifications'. I have no doubt that there
> >is a veritable feast of IPs sitting unused at MIT, USC, and other such
> >institutions that would be better used elsewhere instead of sitting in a
> >corner like a dusty grad student.
> 
> >6: Finally and most importantly, stop pretending you still live in the world
> >of happy academia where everyone is willing to follow the rules you set down
> >just because you're the proffessor and they're the student. This just does
> >not work anymore, you may scoff at people like Jim Flemming but for each one
> >you knock down there is another one to learn from his mistakes and take his
> >place. Do not pretend you can sit idle and call people who don't fall in
> >line behind you names so that you can sit back in your dusty chair and
> >pretend nothing is wrong. The internet as a whole is growing at an unthought
> >of pace and your failure to keep up will not be fixed by being tight assed
> >and making it harder on those that follow. Eventually someone else will take
> >the forefront and throw you off your high horse like yesterdays newspaper.
> >You purport to be leaders of the internet, then its about time you acted
> >like it and start to solve the problems instead of trying to make the
> >problems go away by being ignorant of reality.
> 
> 
> >[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
> >[-]                Networks On-Line - Houston, Texas                       [-]
> >[-]                           713-467-7100                                 [-]
> 





From spsprunk at paranet.com  Sun Mar  9 22:35:21 1997
From: spsprunk at paranet.com (Stephen Sprunk)
Date: Sun, 09 Mar 1997 16:35:21 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <2.2.32.19970309223521.006c7eb4@pop.srv.paranet.com>

There are LAWs (not RFCs) stating that you cannot do this.  Also, you have
signed papers (which undoubtedly you don't remember) which state that the
plates are owned by the state and you must return them upon request, are
non-transferrable, etc etc etc.

Did you sign any such contract when you got your IP addresses?  Are there
any laws in your jurisdiction stating the ownership and appropriate use of
your addresses?

There is no workable analogy in this case because there are no contracts and
no laws regarding anything on the Net at this point.  Until ARIN makes you
sign an acceptable-use agreement (and makes pre-1996 "owners" sign it too),
there can be no enforceable policy other than what the core router owners
decide.  Routability determines address assignment far more definitively
than a NIC board room full of cigar smoke and $10k fees.

Stephen Sprunk


At 13:59 09 03 97 -0500, Lon R. Stockton, Jr. wrote:
>So, since I paid money for my car registration & license plates, I should 
>be able to sell my plates to someone else to put on their car?

>On Sun, 9 Mar 1997, Brett L. Hawn wrote:
>> Been there, read that, and I still say they're selling space, leasing space,
>> auctioning space, etc. Fact of the matter is they are _CHARGING MONEY_ (not
>> bannana peels) for services rendered. Their services are to hand out IP
>> space and maintain databases, therefor they are SELLING space.





From JimFleming at unety.net  Sun Mar  9 22:34:20 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 16:34:20 -0600
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
Message-ID: <01BC2CA7.BDE519C0@webster.unety.net>

On Sunday, March 09, 1997 6:16 PM, Benjamin Inman Vaughn[SMTP:sedriss at Prophet-indy.org] wrote:
@ 
@ 	Less ARIN and NIC are run by the principles Adam Smith described
@ in the early Nineteenth Century. I don't know, maybe Address assignment is
@ controlled by the unseen hand of god.
@ 
@ 	The beginning and end of it is that selling address space is
@ against RFC's and ethics, and it should be left at that.
@ 

You might want to be more specific when you use the term...
	..."address space"...

Do you mean...?

IPv4 address space ?
IPv6 address space ?
IPv8 address space ?

How do you describe the current status of the address spaces below ?

	1. On loan ?
	2. Homesteading ?
	3. Owned ?
	4. Unused ?
	5. U.S. Government Property ?
	6. Grandfathered ?
	7. Not part of the Real World(tm) ?
	8. _________________ (other)

FL	12.0.0.0	AT&T ITS (NET-ATT)
CA	13.0.0.0	Xerox Palo Alto Research Center (NET-XEROX-NET)
CA	14.0.0.0	Public Data Network (NET-PDN)
CA	15.0.0.0	Hewlett-Packard Company (NET-HP-INTERNET)
CA	16.0.0.0	Digital Equipment Corporation (NET-DEC-INTERNET)
CA	17.0.0.0	Apple Computer, Inc. (NET-APPLE-WWNET)
MA	18.0.0.0	Massachusetts Institute of Technology (NET-MIT-TEMP)
MI	19.0.0.0	Ford Motor Company (NET-FINET)
VA	20.0.0.0	Computer Sciences Corporation (NET-CSC)
VA	21.0.0.0	DDN-RVN (NET-DDN-RVN)
DC	22.0.0.0	Defense Information Systems Agency (NET-DISNET)
CA	23.0.0.0	IANA (NET-DDN-TC-NET)
CA	24.0.0.0	@Home Network (NETBLK-ATHOME)	ATHOME  24.0.0.0 - 24.3.255.0

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Sun Mar  9 22:42:41 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 16:42:41 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2CA8.E8E3C3A0@webster.unety.net>

On Sunday, March 09, 1997 4:35 PM, Stephen Sprunk[SMTP:spsprunk at paranet.com] wrote:
<snip>
@ Did you sign any such contract when you got your IP addresses?  Are there
@ any laws in your jurisdiction stating the ownership and appropriate use of
@ your addresses?
@ 

People who are homesteading may not have "signed" anything.
Other people may have signed papers and paid money.

@ There is no workable analogy in this case because there are no contracts and
@ no laws regarding anything on the Net at this point.  Until ARIN makes you
@ sign an acceptable-use agreement (and makes pre-1996 "owners" sign it too),
@ there can be no enforceable policy other than what the core router owners
@ decide.  Routability determines address assignment far more definitively
@ than a NIC board room full of cigar smoke and $10k fees.
@ 
@ Stephen Sprunk

How do you know...."there are no contracts and no laws"...?

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Sun Mar  9 22:45:27 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 16:45:27 -0600
Subject: The Mother of all Solutions (Was Class B for Sale or Rent)
Message-ID: <01BC2CA9.4BA91A80@webster.unety.net>

On Sunday, March 09, 1997 3:56 PM, Randy Bush[SMTP:randy at psg.com] wrote:
@ Emilio Bugatti (sp?), at the time the maker of the finest cars in the world,
@ was asked why the brakes on his cars were not as good as they might be.  He
@ replied "Any fool can make a car stop.  It takes a genius to make a car go."
@ 
@ I suggest we focus on the latter.
@ 

After the Top Level Domain debates, someone sent me
private mail saying that if General Motors had invented
and released the Internet, the public would currently be
in every court in the land claiming that GM intentionally
forgot to design in the brakes....

I see that you confirm that what some people see as
a flaw, you view as a feature...Thanks...;-)

P.S. Business people may look at this an conclude
that there is a huge market for retrofit brakes...

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From charles at etak.com  Sun Mar  9 23:05:28 1997
From: charles at etak.com (Charles R. Hoynowski)
Date: Sun, 09 Mar 1997 15:05:28 -0800
Subject: Is the InterNIC really screwed in the head? 
In-Reply-To: Your message of "Sun, 09 Mar 1997 14:44:56 MST."
             <01IGAW9N53E2QO5Z1M@ACES.COM> 
Message-ID: <199703092305.PAA08764@ nin>



Just must stop and wonder when I get these messages, it sometimes boggles 
the mind, the extent of Internet problems that this mailing list is held
accountable for.

--charles


--------------------------------------------------------------------
Charles R. Hoynowski (CRH2), domain administrator, various locations
Email: charles at etak.com       
--------------------------------------------------------------------


Ehud Gavron <GAVRON at ACES.COM> says:

>Bill Bradford said:
>>On Sun, 9 Mar 1997, Ehud Gavron wrote:
>>> RFC954 specifies WHOIS.  Client requests, server sends.  Simple, really.
>>> $ whois opus4-hst
>>> ....
>>> Would you like to see registered users of this host?
>>> 	WHAT???  My whois client is supposed to search for this string
>...
>>I think your WHOIS may be messed up:
>
>>(mrbill) staff1:~$ whois opus4-hst
>
>	No, I think yours is.
>
>	% telnet whois.internic.net whois
>OPUS4-HST<CR>
>[No name] (OPUS4-HST)
>
>   Hostname: NS.OPUS1.COM
>   Address: 192.245.12.50
>   System: VAX running VMS
>
>   Domain Server
>
>   Record last updated on 13-Feb-94.
>
>Would you like to see the registered users of this host? y<CR>
>
>
>   No registered users.
>
>The InterNIC Registration Services Host contains ONLY Internet Information
>(Networks, ASN's, Domains, and POC's).
>Please use the whois server at nic.ddn.mil for MILNET Information.
>
>	Go fix it.
>	
>	E
>
>
>>[No name] (OPUS4-HST)
>
>>   Hostname: NS.OPUS1.COM
>>   Address: 192.245.12.50
>>   System: VAX running VMS
>
>>   Domain Server
>
>>   Record last updated on 13-Feb-94.
>
>
>>To see this host record with registered users, repeat the command with
>>a star ('*') before the name; or, use '%' to show JUST the registered users.
>
>>The InterNIC Registration Services Host contains ONLY Internet Information
>>(Networks, ASN's, Domains, and POC's).
>>Please use the whois server at nic.ddn.mil for MILNET Information.
>
>>Bill Bradford (BB2623)			Systems Admin, UNIX geek, BOFH
>>mrbill at texas.net * mrbill at mrbill.net	Texas Networking, Inc.
>>-------------------------------------------------------------------------
>>"Un-altered REPRODUCTION and DISSEMINATION of this IMPORTANT Information
>> is ENCOURAGED, ESPECIALLY to COMPUTER BULLETIN BOARDS."
>>                                             -- Robert E. McElwaine
>




From smb at research.att.com  Mon Mar 10 03:56:04 1997
From: smb at research.att.com (Steven M. Bellovin)
Date: Sun, 09 Mar 1997 22:56:04 -0500
Subject: Class "B" forsale (fwd) 
Message-ID: <3.0.32.19970309225558.006a03ac@127.0.0.1>

At 08:23 AM 3/10/97 +1000, Geoff Huston wrote:
>Of course this scenario breaks down quickly..
>
>Listed registrant A "sells" to B who "sells" to C who...
>
>Now the sucker who "buys" from C has the problem of tracing authenticity
>of the "title" C is selling. This is not easy, particularly if B is less
>than scrupulous and has "sold" title to a number of folk including
>C, or if C is unscrupulous and is "selling" without have concluded
>and transaction with B.

This can easily be solved in a number of ways.  For example, a public key
could be publicly associated with each address.  A transfer is accomplished
by signing a message to that effect.  Similarly -- and very importantly --
control over routing of that address is also governed by that
private/public key pair.  There's more to this protocol than I've
described, but it can be made to work.





From JimFleming at unety.net  Sun Mar  9 23:22:03 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 17:22:03 -0600
Subject: IP Ownership and Domain Names
Message-ID: <01BC2CAE.68464AA0@webster.unety.net>

On Sunday, March 09, 1997 9:56 PM, Steven M. Bellovin[SMTP:smb at research.att.com] wrote:
@ At 08:23 AM 3/10/97 +1000, Geoff Huston wrote:
@ >Of course this scenario breaks down quickly..
@ >
@ >Listed registrant A "sells" to B who "sells" to C who...
@ >
@ >Now the sucker who "buys" from C has the problem of tracing authenticity
@ >of the "title" C is selling. This is not easy, particularly if B is less
@ >than scrupulous and has "sold" title to a number of folk including
@ >C, or if C is unscrupulous and is "selling" without have concluded
@ >and transaction with B.
@ 
@ This can easily be solved in a number of ways.  For example, a public key
@ could be publicly associated with each address.  A transfer is accomplished
@ by signing a message to that effect.  Similarly -- and very importantly --
@ control over routing of that address is also governed by that
@ private/public key pair.  There's more to this protocol than I've
@ described, but it can be made to work.
@ 
@ 

You could also handle it just like "domain names"....

Does AT&T "own"....ATT.COM ?

Does AT&T "own"....

	12.IN-ADDR.ARPA ?
	and
	135.IN-ADDR.ARPA ?

How about...
	
	12.IP4.INT ?
	135.IP4.INT ?

are those registered....?

FL	12.0.0.0	AT&T ITS (NET-ATT)
FL	135.0.0.0	AT&T ITS (NET-ATT-135-0-0-0-B)






--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From michael at memra.com  Mon Mar 10 00:00:18 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 16:00:18 -0800 (PST)
Subject: class B for sale
In-Reply-To: <v03007803af48c4d84d22@[207.135.64.130]>
Message-ID: <Pine.BSI.3.93.970309152945.319D-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, Jim Browne wrote:

> >The problems are *YOUR* problems and
> >it is *YOUR* responsibility to solve them as much as anyone else's.
> 
> Wow, that sounds a lot like fingerpointing.  It's not my problem, it's
> yours.  My network isn't losing packets, the NAPs are.  My peering
> requirements are reasonable, yours aren't.  My HOL blocking isn't the
> problem, your refusal to daisy chain a second non-working device is the
> problem.  I'm sure that's not what you meant, Michael,

No, it's not what I meant. I should have said the problems are *OUR*
problems as individuals and as a group. And it is *OUR* responsibility to
solve them rather than waiting for the gods to speak. 

Aide-toi, Dieu t'aidera.

> The prevailing attitude here seems to be "If it's not my solution, you are
> part of the problem."

I disagree. If you judge people by their actions rather than by their
words there are a LOT of people silently working to make things better and
not interested in loudly proclaiming how great they are. They deserve
some thanks and the rest of us should roll up our sleeves and pitch in.
This network is still a baby. Everyone here on this list could spend the
rest of their adult life building and deploying the network and it still
wouldn't be finished.

> effective cooperation.  (Yes, CAIDA people, I know you are trying.
> However, I don't see the big six at http://compute.merit.edu/ipn.html.)

It's still a significantly long list. And sooner or later some network
engineer is going to figure out how to explain this to their marketing
people and the big six will start to lose contracts because they are not
collaborating.

> I'm beginning to think a little regulation will go a long way in correcting
> this attitude. 

One thing that would help is some legislation that draws a clear line
between what is and what is not antitrust behavior in the Internet
industry. The United States has such severe penalties for antitrust
behavior that it is understandable that companies large enough to be 
considered dominant within the industry would shy away from participating
in things like IPN. 

> Why shouldn't network metrics be standardized, published,
> and audited by an independent agency?  

They should, but...

> Car manufacturers have to publish
> results of their mandatory saftey tests.

The Internet industry has now reached the same level that the car industry
reached just after Henry Ford introduced the Model T. When Internet
engineering is as well understood as automotive engineering is today
then the standards you are looking for will come to be. It's probably no
coincidence that ANX is the major group pushing for this kind of thing.

But the tools are there for any network provider who really wants to work
on quality. ISO 9000, TQM, etc...

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com






From chris at nap.net  Sat Mar  8 10:10:54 1997
From: chris at nap.net (Chris A. Icide)
Date: Sat, 08 Mar 1997 04:10:54 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <3.0.32.19970308041052.007271f0@nap.net>

A few things come to mind as I follow this thread, and I've pondered
shooting myself in the foot instead of adding to the thread, but the
foot injury seems that it might be worse than jumping in here, so
here goes.

Someone mentioned the infamous (and seriously outdated) playing
in the sandbox idea.  This tends to work good when all the people in
the theoretical sandbox are friends and neighbors, and have some
kind of "interest" in the well being of the sandbox.  When someone 
decides that they can get in the sandbox, mess around, and make
a bit of money, then leave the sandbox to never come back, they will.
On another note, if they find they can come in the sand box, and bully
the other sandbox members and get thier way, they will.  The sand-
box has gotten huge, and crowded.

Rules are an interesting thing.  If a rule isn't enforced, the only people
who will follow that rule are those who benefit from it (pardon me if
I insulted anyone here by insinuating that they would only follow a rule
if it benefited them - Let's just assume a clear conscious is benefit 
enough for some, and not run off on a tangent).  If I don't benefit from
a rule (or law), and it's not enforced, then what stops me from breaking
the rule (especially if there is a large benefit at the end of that tunnel)?

When a product has a value, a black market will arise where no "white"
market is available.  The black market will remain in tact until either the
white market is able to supply the required product/service at an 
equivalent volume and price.  If it's easier or cheaper (or both) for me
to go to the black market and buy my product, why buy from the white?

I would propse that this is in fact happening, and will continue to 
happen until there is some negetive incentive.

Now I don't even imagine to propose any comprehensive solution for
this.  However let me toss an idea on the table.  If in fact ARIN does come
into being as an organization supported and funded by an for the commuity
of IP users, then those IP users could work in cooperation with ARIN (and the
other NIC's) to police the usage of IP's.  For example, the NICs could
maintain a database online that could monitor the current BGP tables.
If the NIC determines that an unallocated IP block is in use, they could then
insert a prefix entry into the table, seriously degrading the value of that
IP block.  This could also be used in a gross way to evaluate usage of
prefixes, and unauthorized changes to prefixes.

Again, this is only an idea that I toss on the table, but I do stand by the 
fact that unless there is a negetive incentive, there are those who will
do anything that is beneficial to them.

Chris A. Icide
Sr. Engineer
Nap.Net, L.L.C. 

At 09:38 AM 3/9/97 Time, Joseph T. Klein wrote:
>More than a few people have hoarded, sold, and exchanged
>Class Bs for profit. Such exchanges should be given the
>same value as the deed to the Brooklyn Bridge and lunar
>land parcels.
>
>The result of a few gaining money for B space has been
>to encourage people to horde it.
>--
>From:   Joseph T. Klein, Titania Corporation http://www.titania.net
>E-mail: jtk at titania.net  Sent:   09:38:37 CST/CDT 03/09/97
>
>"They that can give up essential liberty to obtain a little temporary
>safety deserve neither liberty nor safety."
>                -- Benjamin Franklin, 1759
>
>




From paul at vix.com  Mon Mar 10 02:00:32 1997
From: paul at vix.com (Paul A Vixie)
Date: Sun, 09 Mar 1997 18:00:32 -0800
Subject: since my name was mentioned (was Re: The Mother of all Solutions)
In-Reply-To: Ehud's message of "Sun, 09 Mar 1997 14:34:15 MST."
             <01IGAW607XEEQO5Z1M@ACES.COM> 
Message-ID: <199703100200.SAA04387@wisdom.home.vix.com>

> 	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
> 	decided TOMORROW that WE will assign address space and route to
> 	it, there is no force in the world that will charge for it, or
> 	be able to change it.

That's what we already have.  IANA is in charge because the people who own
the physical plant -- that's the multinationals, larger nationals, government,
military, and other gigantic users -- think IANA is a good solution for the
time being.  IANA delegates its address assignment authority to registries
(RIPE, APNIC, and ARIN/InterNIC) whose operational guidelines are set by and
reviewed by open forums made up of the people to whom addresses are allocated,
with some oversight/assistance from IETF.

If the people who own the physical plant were to somehow jointly decide that
some other system would work better for them, then that other system would be
in place (or die trying) pretty much instantaneously, with no relevant 
fighting.  (It's worth noting that confusion over the ownership of the
physical plant is what makes Karl, Eugene, and Jim try to do what they're
trying to do with ".", but it's probably not worth discussing over again.)

> 	Here's the Ehud Scenario:
> 		1. Tomorrow Paul Vixie gets a pirate hair up his dec alpha
> 	  	   and puts in 64.in-addr.arpa. through 126.in-addr.arpa.
> 		   in F.

This could never happen.  I am not an address or domain assignment authority.
The chosen focal point for the will of the owners of the physical plant is
the IANA, and my root (and gTLD and iTLD) name server(s) will export exactly
what the respective domain owners put into their domains.  No more, no less.

Wait, I can feel an example coming on.  Consider these data elements:

	LOCALHOST.		in a	127.0.0.1
	1.0.0.127.IN-ADDR.ARPA.	in ptr	LOCALHOST.

When I was first delegated F, I put these in since they are a standard
feature of all "my" other name servers.  However, a few days later the little
light went on and I said "oops, I just polluted the global DNS name space
with stuff the IANA did not authorize" and I took it out.

> 		2. We start assigning nets from this block (64/8-126/8).
> 		3. We start routing to this block (ok, I don't own a backbone
> 	    	   yet, but let me use "we" meaning nanog for now ;)

This is exactly what happens now except that "we" is larger by far than NANOG.

> 	Let me know if I've left something out.

What you've left out is that the model of Internet self governance has been
in use since before the U.S. Military thought it had allowed such, and is in
use now even though it looks rather autocratic to someone who does not know
from whence IANA and RIPE/APNIC/ARIN derive their relevance.




From jtk at titania.net  Sun Mar  9 20:08:13 1997
From: jtk at titania.net (Joseph T. Klein)
Date: Sun,  9 Mar 97 20:08:13 Central Standard Time
Subject: Class "B" forsale (fwd) 
References: <Pine.GSO.3.95.970309110535.27751F-100000@dazed.nol.net> 
Message-ID: <Chameleon.857961741.jtk@monet.titania.net>

My point is ...

If the transfers are not honored then they will have no value.
The crunch in IP space can be drastically reduced if the horded
addressed where returned to the pool for use by those that need
them.

It is not yours. Anyone who sells IP addresses is committing
fraud. Sell the deed to the moon and you land in jail.

OK who owned it? The administrative contact, the
technical  contact? If I am an administrator for XYZ corp
and I sell XYZ's unused class B to ABC corp for $10K ...
have I embezzled $10K worth of assets from XYZ?

When the lawers get wind of this we are all in it deep.

You are treading on very shaky ground. Your free market
sounds more like anarchy. Commerce can not function without
law.

This line of reasoning based on "anarchist economics" will
bring the whole structure down on all of us.

Catch 22 - If you sell it, you don't need it. You don't need it
it goes back to the numbering authority.

Since the original user of the IP address did not pay for it,
how can they claim to own it? Quid Pro Quo!

--- On Sun, 9 Mar 1997 11:07:38 -0600 (CST)  "Brett L. Hawn" <blh at nol.net> wrote:
> 
> Demand vs. Supply, this sounds like a 3rd grade economics class. This is no
> longer a couple of colleges with a bunch of grad students folks. This is a
> worldwide business (no matter how much me, you, or anyone else would like it
> be something else) and people are here to make a dollar. If I can makea few
> bucks (or a hell of a lot of bucks) by selling space that is mine to do with
> as I please.. so be it.
> 
> 
> On Sun, 9 Mar 1997, Joseph T. Klein wrote:
> 
> > 
> > More than a few people have hoarded, sold, and exchanged
> > Class Bs for profit. Such exchanges should be given the
> > same value as the deed to the Brooklyn Bridge and lunar
> > land parcels.
> > 
> > The result of a few gaining money for B space has been
> > to encourage people to horde it.
> > --
> > From:   Joseph T. Klein, Titania Corporation http://www.titania.net
> > E-mail: jtk at titania.net  Sent:   09:38:37 CST/CDT 03/09/97
> > 
> > "They that can give up essential liberty to obtain a little temporary
> > safety deserve neither liberty nor safety."
> >                 -- Benjamin Franklin, 1759
> > 
> 
> [-]                Brett L. Hawn (blh @ nol dot net)                       [-]
> [-]                Networks On-Line - Houston, Texas                       [-]
> [-]                           713-467-7100                                 [-]
> 

---------------End of Original Message-----------------
--
From:   Joseph T. Klein, Titania Corporation http://www.titania.net
E-mail: jtk at titania.net  Sent:   20:08:13 CST/CDT 03/09/97

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
                -- Benjamin Franklin, 1759




From JimFleming at unety.net  Mon Mar 10 02:42:39 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sun, 9 Mar 1997 20:42:39 -0600
Subject: since my name was mentioned (was Re: The Mother of all Solutions)
Message-ID: <01BC2CCA.6E9362A0@webster.unety.net>

On Sunday, March 09, 1997 8:00 PM, Paul A Vixie[SMTP:paul at vix.com] wrote:
@ > 	If a LARGE GROUP OF NETWORK PROVIDERS (that's us, btw, nanog),
@ > 	decided TOMORROW that WE will assign address space and route to
@ > 	it, there is no force in the world that will charge for it, or
@ > 	be able to change it.
@ 
@ That's what we already have.  IANA is in charge because the people who own
@ the physical plant -- that's the multinationals, larger nationals, government,
@ military, and other gigantic users -- think IANA is a good solution for the
@ time being.  IANA delegates its address assignment authority to registries
@ (RIPE, APNIC, and ARIN/InterNIC) whose operational guidelines are set by and
@ reviewed by open forums made up of the people to whom addresses are allocated,
@ with some oversight/assistance from IETF.
@ 

TRANSLATION:

	The "big boys" support the status quo...that's not surprising...
		
@ If the people who own the physical plant were to somehow jointly decide that
@ some other system would work better for them, then that other system would be
@ in place (or die trying) pretty much instantaneously, with no relevant 
@ fighting.  (It's worth noting that confusion over the ownership of the
@ physical plant is what makes Karl, Eugene, and Jim try to do what they're
@ trying to do with ".", but it's probably not worth discussing over again.)
@ 

TRANSLATION:

	If a whole bunch of average people make a change in unison,
	then no one, including the "big boys", can stop them...

<snip - Root Name Server operational error story>
 
@ > 	Let me know if I've left something out.
@ 
@ What you've left out is that the model of Internet self governance has been
@ in use since before the U.S. Military thought it had allowed such, and is in
@ use now even though it looks rather autocratic to someone who does not know
@ from whence IANA and RIPE/APNIC/ARIN derive their relevance.
@ 
@ 

TRANSLATION:

	The status quo is based on years of momentum...
		as well as U.S. Government and DOD support...
	...again, not surprising...


@@@@@@@@

Alternate Viewpoint...
	The Internet will never be significantly changed by the people in power.
	Only the collective will of the people can result in changes. To make
	changes you have to be open to change. Change for the sake of
	change is not good. Change for the sake of ensuring that governments
	and small autocratic societies do not dominate the mediums IS good.
	Change to allow people of all sexes, sizes, shapes, ages, races, religions,
	sexual preferences, etc. and viewpoints IS good. The U.S. Government's
	blockade of new participants in the Internet will eventually end and
	history will show that thousands of hours were spent with one small group
	supporting the status quo and another large group advocating an open,
	fair and level playing field. The Internet will be used to reinvent itself
	and the few "big boys" will play no significant role other than to provide
	mass for the blockade which will be lifted by the vary government that
	paid to have it installed...that lifting is happening as NANOG sleeps...;-)



--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From aleph1 at dfw.net  Mon Mar 10 02:53:02 1997
From: aleph1 at dfw.net (Aleph One)
Date: Sun, 9 Mar 1997 20:53:02 -0600 (CST)
Subject: measurement
In-Reply-To: <m0w3qjA-0007zdC@rip.psg.com>
Message-ID: <Pine.SUN.3.94.970309204954.11037B-100000@dfw.dfw.net>

On Sun, 9 Mar 1997, Randy Bush wrote:

> > The measurement techniques described thus far focus on performance within 
> > the bounds of a single network.  While this is of course a challenge, what 
> > about efforts to measure performance _across_ networks?  I'm not talking 
> > about NAP packet loss here, but a true measure of expected customer 
> > satisfaction.
> 
> Expectations of customer satisfaction are aleph nul or likely aleph one.

And someone called my name...

> Measurement of end user delivery are being done rather ad hack (hit the web
> site and see how high it bounces) by the folk at Intel, see
> 
>     Network Working Group                      J. Sedayao, Intel Corporation
> 					   C. Bickerstaff, Intel Corporation
>     Internet Draft
>     Expiration Date: May 1997                                  November 1996
> 
>      Simple End to End Metrics and Methods for Monitoring and Measuring IP
> 			      Provider Performance
> 
> The IPPM WG is trying to work upward from a sound theoretical base.  See the
> other IPPM drafts and mailing list archives.

May I also suggest people take a look a Treno. If used consistently and
regularly it may give a rought estimate of connection quality for end
users across networks.

> randy

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 





From ichiro at TokyoNet.AD.JP  Mon Mar 10 03:14:31 1997
From: ichiro at TokyoNet.AD.JP (Ichiro Mizukoshi)
Date: Mon, 10 Mar 1997 12:14:31 +0900
Subject: Routing Information guard (was  Class "B" forsale )
In-Reply-To: Your message of "Sat, 08 Mar 1997 04:10:54 -0600"
References: <3.0.32.19970308041052.007271f0@nap.net>
Message-ID: <199703100314.MAA11022@mylord.shinjuku.TokyoNet.AD.JP>


Chis's Idea is nice. Routing engineers in ISP sometimes misconfigure their
gear, so bogus route will be announced. Checking the Routing Information
ande sending the warning messages to the ISP, makes the network more stable.

And, let me toss an additional idea to it.  
*) If an allocated addresses does not appear in such table for some period,
asking the aloocated guy to return them.

Ichiro Mizukoshi
e-mail(office):ichiro at TokyoNet.ad.jp
Tel:+81-3-3341-6301	Fax:+81-3-3341-6305

From: "Chris A. Icide" <chris at nap.net>
Subject: Re: Class "B" forsale (fwd) 
Date: Sat, 08 Mar 1997 04:10:54 -0600

> Now I don't even imagine to propose any comprehensive solution for
> this.  However let me toss an idea on the table.  If in fact ARIN does come
> into being as an organization supported and funded by an for the commuity
> of IP users, then those IP users could work in cooperation with ARIN (and the
> other NIC's) to police the usage of IP's.  For example, the NICs could
> maintain a database online that could monitor the current BGP tables.
> If the NIC determines that an unallocated IP block is in use, they could then
> insert a prefix entry into the table, seriously degrading the value of that
> IP block.  This could also be used in a gross way to evaluate usage of
> prefixes, and unauthorized changes to prefixes.
> 
> Again, this is only an idea that I toss on the table, but I do stand by the 
> fact that unless there is a negetive incentive, there are those who will
> do anything that is beneficial to them.
> 
> Chris A. Icide
> Sr. Engineer
> Nap.Net, L.L.C. 






From doshea at mail.wiltel.net  Mon Mar 10 03:39:49 1997
From: doshea at mail.wiltel.net (Dave O'Shea)
Date: Sun, 9 Mar 1997 21:39:49 -0600
Subject: Cayman Island Scenarios
Message-ID: <199703100331.VAA29578@wiltel.net>



Jim Fleming <JimFleming at unety.net> writes

> 
> Question: When companies like MCI and Bellcore get bought,
> 	do they have to turn all of their blocks back into the "NIC"
> 	and start over...;-)

I actually went though an amazingly similar situation when we sold off one
of our subsidiaries; InterNIC said we could not have new address space
because of the B that had been assigned to the newly-sold subsidiary; that
we could not "transfer" that block of space.

I offered to assume responsibility for the old block, if they would certify
me as the authority to have routing turned off for the old subsidiary. In
the end, we got new space.

All things considered, it would have been nice if it had been a block of
addresses that could have been "split" - like a /16 up above 192.x.x.x
without confusing the bejeezus out of simple RIP configurations. Would have
saved us the "next time I'll just kill myself" task of renumbering, and
conserved address space.

I think the use of unregistered blocks and better proxy servers is the only
way we can avoid this kind of silliness - with a good setup, a Fortune 500
company has only a handful of "visible" IP addresses, with the rest hidden
and irrelevant.





From davidc at apnic.net  Sun Mar  9 15:52:29 1997
From: davidc at apnic.net (David R. Conrad)
Date: Mon, 10 Mar 1997 00:52:29 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Sun, 09 Mar 1997 20:08:13 EST."
             <Chameleon.857961741.jtk@monet.titania.net> 
Message-ID: <199703091552.AAA09604@moonsky.jp.apnic.net>

Hi,

>If the transfers are not honored then they will have no value.

True.  For address space to have value on the Internet it must be

	a) globally unique
	b) accepted for routing by an Internet service provider

Requirement (a) is met by any address allocated by any of the
registries, regardless of whether the registration information
corresponds to reality or not.  Requirement (b) is where things get
interesting.

>The crunch in IP space can be drastically reduced if the horded
>addressed where returned to the pool for use by those that need
>them.

1) what IP space "crunch"?

2) what incentive do you propose to give to encourage people to
   return address space to the pool of "usable" addresses?  Given
   that they have not done so already, it is safe to assume "for
   the good of the Internet" is not sufficient.

>Commerce can not function without law.

Nit: commerce functions quite well without law (as any drug dealer
will tell you).  It does however need a consensus of behaviors among
buyers and sellers, although those behaviors need not to conform to
those of the rest of "society"...

Regards,
-drc




From michael at memra.com  Mon Mar 10 03:51:00 1997
From: michael at memra.com (Michael Dillon)
Date: Sun, 9 Mar 1997 19:51:00 -0800 (PST)
Subject: measurement
In-Reply-To: <Pine.SUN.3.94.970309204954.11037B-100000@dfw.dfw.net>
Message-ID: <Pine.BSI.3.93.970309194856.2221A-100000@sidhe.memra.com>

On Sun, 9 Mar 1997, Aleph One wrote:

> > The IPPM WG is trying to work upward from a sound theoretical base.  See the
> > other IPPM drafts and mailing list archives.
> 
> May I also suggest people take a look a Treno. If used consistently and
> regularly it may give a rought estimate of connection quality for end
> users across networks.

NLANR has a summary of measurement tools here
http://www.nlanr.net/Caidants/meastools.html that has a link to more TReno
information and you can try it out from PSC via this WWW forms interface
http://www.psc.edu/~pscnoc/treno.html

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From ichiro at TokyoNet.AD.JP  Mon Mar 10 04:30:51 1997
From: ichiro at TokyoNet.AD.JP (Ichiro Mizukoshi)
Date: Mon, 10 Mar 1997 13:30:51 +0900
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Mon, 10 Mar 1997 00:52:29 +0900"
References: <199703091552.AAA09604@moonsky.jp.apnic.net>
Message-ID: <199703100430.NAA11456@mylord.shinjuku.TokyoNet.AD.JP>

Hi,

Let me toss an Idea to encourage people to return address space.
	*) Charge to NIC's (whole) IP Database Entry as maintenace fee.

It will
 A) discourage people to store "not used addresses".
 B) Charging refresh the Database Entry, regullaly. So, addresses will not
be lost.
 C) Cost of the database maintenace should be payed by someone. Even the
address was allocated/assigned.

P.S.
Database Entry is not the IP address. It's a set of IP addresses, its
administrative responsible is the same.

Regards, 

Ichiro Mizukoshi
e-mail(office):ichiro at TokyoNet.ad.jp
Tel:+81-3-3341-6301	Fax:+81-3-3341-6305


From: "David R. Conrad" <davidc at apnic.net>
Subject: Re: Class "B" forsale (fwd) 
Date: Mon, 10 Mar 1997 00:52:29 +0900

> 2) what incentive do you propose to give to encourage people to
>    return address space to the pool of "usable" addresses?  Given
>    that they have not done so already, it is safe to assume "for
>    the good of the Internet" is not sufficient.




From jtk at titania.net  Sun Mar  9 22:10:20 1997
From: jtk at titania.net (Joseph T. Klein)
Date: Sun,  9 Mar 97 22:10:20 Central Standard Time
Subject: Class "B" forsale (fwd) 
References: <199703091552.AAA09604@moonsky.jp.apnic.net> 
Message-ID: <Chameleon.857969852.jtk@monet.titania.net>

This is only a NANOG matter in that the trade in address space
can be seen as undermining those who legitimately request CIDR
blocks and then spend the time to justify them and SWIP the
addresses.

Not to beat this into the ground ...

> 
> 1) what IP space "crunch"?

Addresess are harder to get then they where in 1990. You could
(and many people did) ask for a class B and get it with little
or no hassle. I know people who did it and held on to unused
class Bs based on speculation that they could sell them.

$10K is a good return on some e-mail sent seven years ago.
> 
> 2) what incentive do you propose to give to encourage people to
>    return address space to the pool of "usable" addresses?  Given
>    that they have not done so already, it is safe to assume "for
>    the good of the Internet" is not sufficient.
>
If I can not sell it, I don't need it and it costs me money,
why keep it?

Most of the IP address speculators will give them up if annual
fees are assessed for allocated address space and they can not
transfer them.

I suspect a large number of organizations would then have the
incentive to move to proxies and addresses per RFC 1918

http://ds.internic.net/rfc/rfc1918.txt
 
> >Commerce can not function without law.
> 
> Nit: commerce functions quite well without law (as any drug dealer
> will tell you).  It does however need a consensus of behaviors among
> buyers and sellers, although those behaviors need not to conform to
> those of the rest of "society"...
> 
> Regards,
> -drc

Point Taken. I was taking a rather Hamiltonian approach with my
argument and it has some flaws. I should have replace law with
consensus ... a more Jeffersonian view. Laws do not function with
out the consensus of the governed; nor do rules of commerce without
a consensus within the given market.

What is the InterNIC policy on the sale of class Bs?
--
From:   Joseph T. Klein, Titania Corporation http://www.titania.net
E-mail: jtk at titania.net  Sent:   22:10:20 CST/CDT 03/09/97

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
                -- Benjamin Franklin, 1759




From shields at crosslink.net  Mon Mar 10 11:46:04 1997
From: shields at crosslink.net (Michael Shields)
Date: Mon, 10 Mar 1997 06:46:04 -0500
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.LNX.3.91.970309135638.10067A-100000@luna.moonstar.com>
References: <Pine.GSO.3.95.970309122037.4399B-100000@dazed.nol.net>
	<Pine.LNX.3.91.970309135638.10067A-100000@luna.moonstar.com>
Message-ID: <199703101146.GAA30247@daedalus.crosslink.net>

> So, since I paid money for my car registration & license plates, I should 
> be able to sell my plates to someone else to put on their car?

I believe that people with spiffy vanity plates have sold them.  Why not?

But discussion about the Internet is always plagued with analogies.
IP address allocation is not really like the allocation of land, or
phone numbers, or pollution credits, or milk quotas, or typing paper,
or license plates, or routing table slots, or cocaine.  It's sort of
like all of these things, but not completely like any of them.  And
the nature of an analogy is that it pretends two things are similar in
all ways.

The best way to think about this is not: "IP addresses should be
allocated in X way because Y is allocated that way," "But IP addresses
are not like Y," "Are so!", but instead: "What is the current policy
on IP address allocation?  What are the implications?  What would be
the implications of this other policy?"

Analogies are a good tool when things really are the same, but nothing
hurts you like using the wrong tool.  Since IP addresses are not like
other things, there is not much to compare them to.
-- 
Shields, CrossLink.




From alex at Relcom.EU.net  Mon Mar 10 11:34:53 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Mon, 10 Mar 1997 14:34:53 +0300 (MSK)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <199703090425.NAA03310@palmtree.jp.apnic.net>
Message-ID: <Pine.SUN.3.91.970310142147.15674E-100000@virgin>

Hi. It's not good idea to discusse _can we /NIC/ allow or can we 
disallow_.
More interesting is _how to prevent address space wasting_ and _how to 
prevent extra payements..._.

If you'll disallow class B selling, Internet would lost 256*256 
addresses, because this class B network would be unused (and somebody 
would use class C networks instead_. It's bad thing, isn't it?

On the other hand, if you'll allow free saling of the address space, 
internet would be the homeplace of the big nabobs who can bye total 
address space and break down small competitors (and even small 
countries); it'll mean the deaths of the Internet, isn't it?

I do not know how would NOC go between this _scilla_ and _charibda_, but 
it's one of this important questions the internet's future depends of.





On Sun, 9 Mar 1997, David R. Conrad wrote:

> Hi,
> 
> >I remember going through hell writing the justification for this network.
> >I didn't know the NIC would allow sale of address space. 
> 
> The Internet regsistries cannot disallow someone from selling IP
> address space any more than we can disallow someone selling the
> Brooklyn Bridge, gold painted bricks, or land with a lovely ocean view
> a few miles south of the Everglades.
> 
> However, what we can disallow is the update of the registration
> database when a full registry allocated block is transfered from one
> organization to another.
> 
> Of course, although I work for a registry, I (personally) am under no
> illusion that this will discourage the insistent as it has little
> impact on the operational viability of the network, it just makes
> finding out appropriate contacts when bad things happen a bit more
> difficult.
> 
> Regards,
> -drc
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





From alex at Relcom.EU.net  Mon Mar 10 11:47:05 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Mon, 10 Mar 1997 14:47:05 +0300 (MSK)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.BSI.3.95.970309052842.15829E-100000@boiled.egg.com>
Message-ID: <Pine.SUN.3.91.970310144517.15674G-100000@virgin>

Hmm, let's make your questions more complex - if I own ISP and this ISP 
bacame bankrupt, wpuld it's address space be - selled, returned, owned by 
it's customers, etc... ???





On Sun, 9 Mar 1997, Tom Glover wrote:

> 
> I "kind" of agree. :) If I own a company, lets call it Acme, which has an
> internet connection and that company is making use of a class B address
> space it got from the 'NIC and if I sell Acme does that address block need
> to be returned?  Another example is if I own an ISP that has several
> blocks of address space. What happens if I sell the ISP? Do the address
> blocks get returned? If Acme has to return their address blocks upon the
> sale of the company and the ISP doesn't on its sale, we've got a situation
> which would keep lawyers in Lexus for decades. If the answer is that you
> can legitimately transfer an address block if you sell the company then
> there's a nice big loophole. Anyone with a class B for sale could simply
> form a company and then sell it.
> 
> Now I don't own a sellable address block. I'm just playing devil's
> advocate in what appears to be a very interesting quandary.
> 
> On Sun, 9 Mar 1997, Brett L. Hawn wrote:
> 
> > On Sun, 9 Mar 1997, David R. Conrad wrote:
> > 
> > > >	The way I see it, it is worth no more than $10,000. As that is what
> > > >ARIN is going to charge any corp to get a Class B. 
> > > 
> > > How much is your time (spent making up and writing the justification for
> > > a class B) worth?
> > 
> > I think you miss my point, since the ARIN is for all intents and purposes
> > selling address space, who are they to say no? Apparently someone made a
> > case for a class B at one time or another, no longer needs it (for whatever
> > reason) and wants to pass it on to someone else and make a little profit in
> > at the same time. Now granted, I don't neccessarily agree with what they're
> > doing, but I certainly can't say anything 'wrong' about it either. I mean,
> > lets think about this for a second.
> > 
> > Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
> > is in order as it should be. I decide for whatever reason to turn off my
> > routers, sell my equipment and move to the Caymans to enjoy the rest of my
> > life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
> > block to someone else and make a small (or large for that matter, I'm sure I
> > could sell it for a interesting sum of money) profit.
> > 
> > scenario 1:
> > 
> > It gets returned and some other poor fool has to jump through flaming hoops
> > and surive a pool of toxic waste to get a few IPs.
> > 
> > scenario 2:
> > 
> > I change all the records to point to them, swip it out to them, basically do
> > everything needed to make them the legitimate 'owners' of that block, they
> > pay me a nice lump of cash and we're both happy.
> > 
> > As I see it, changing ownership of IPs is no different than changing
> > ownership of a domain. 
> > 
> > 
> > [-]                Brett L. Hawn (blh @ nol dot net)                       [-]
> > [-]                Networks On-Line - Houston, Texas                       [-]
> > [-]                           713-467-7100                                 [-]
> > 
> 
> --
> Regards,
> Tom
>   ________________________________________________________________________
>  |   "The Egg Domain"    |       "And all you touch and all you see,      | 
>  |    tomg at egg.com       |          is all your life will ever be."       |
>  | http://www.egg.com/   |                               (Pink Floyd)     |
> 
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





From alex at Relcom.EU.net  Mon Mar 10 12:03:43 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Mon, 10 Mar 1997 15:03:43 +0300 (MSK)
Subject: Cayman Island Scenarios
In-Reply-To: <01BC2C95.53BBD820@webster.unety.net>
Message-ID: <Pine.SUN.3.91.970310150014.15674J-100000@virgin>

> @ Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
> @ is in order as it should be. I decide for whatever reason to turn off my
> @ routers, sell my equipment and move to the Caymans to enjoy the rest of my
> @ life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
> @ block to someone else and make a small (or large for that matter, I'm sure I
> @ could sell it for a interesting sum of money) profit.
Hmm, I just asked the same question... If you'll sell your business, why 
do you think somebody buy your routers withouth your address space? If 
somebody buy yoy ISP business this somebody need your address space to 
continue IP service...

> @ scenario 1:
> @ 
> @ It gets returned and some other poor fool has to jump through flaming hoops
> @ and surive a pool of toxic waste to get a few IPs.
> @ 
> @ scenario 2:
> @ 
> @ I change all the records to point to them, swip it out to them, basically do
> @ everything needed to make them the legitimate 'owners' of that block, they
> @ pay me a nice lump of cash and we're both happy.
> @ 
> @ As I see it, changing ownership of IPs is no different than changing
> @ ownership of a domain. 
> @ 
> 
> 
> Scenario 3:
> 
> 	You sell the entire company before turning off the routers and
> 	the block stays with the operation on a lease arrangement.
> 	It eventually gets absorbed into a larger ISP and lost on the
> 	books in the mega transaction.
> 
> Scenario 4:
> 
> 	You move to the Cayman Islands and set up a competing
> 	"NIC". One of the NICs currently operates out of the
> 	Seychelles, so maybe the Caymans are the next best
> 	place to start an address NIC.
> 
> Question: When companies like MCI and Bellcore get bought,
> 	do they have to turn all of their blocks back into the "NIC"
> 	and start over...;-)
Aga...(yes, in english...). 

Or if MCI splits into 2 new companies, would it retirn it's address 
space to the NIC? -:)



> 
> 
> --
> Jim Fleming
> Unir Corporation
> 
> e-mail:
> JimFleming at unety.net
> JimFleming at unety.s0.g0 (EDNS/IPv8)
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





From tomg at boiled.egg.com  Mon Mar 10 13:42:11 1997
From: tomg at boiled.egg.com (Tom Glover)
Date: Mon, 10 Mar 1997 05:42:11 -0800 (PST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <Pine.SUN.3.91.970310144517.15674G-100000@virgin>
Message-ID: <Pine.BSI.3.95.970310054131.18467A-100000@boiled.egg.com>


Good question! Would the bankrupt court consider the address space as a
sellable asset?

On Mon, 10 Mar 1997, Alex P. Rudnev wrote:

> Hmm, let's make your questions more complex - if I own ISP and this ISP 
> bacame bankrupt, wpuld it's address space be - selled, returned, owned by 
> it's customers, etc... ???
> 
> 
> 
> 
> 
> On Sun, 9 Mar 1997, Tom Glover wrote:
> 
> > 
> > I "kind" of agree. :) If I own a company, lets call it Acme, which has an
> > internet connection and that company is making use of a class B address
> > space it got from the 'NIC and if I sell Acme does that address block need
> > to be returned?  Another example is if I own an ISP that has several
> > blocks of address space. What happens if I sell the ISP? Do the address
> > blocks get returned? If Acme has to return their address blocks upon the
> > sale of the company and the ISP doesn't on its sale, we've got a situation
> > which would keep lawyers in Lexus for decades. If the answer is that you
> > can legitimately transfer an address block if you sell the company then
> > there's a nice big loophole. Anyone with a class B for sale could simply
> > form a company and then sell it.
> > 
> > Now I don't own a sellable address block. I'm just playing devil's
> > advocate in what appears to be a very interesting quandary.
> > 
> > On Sun, 9 Mar 1997, Brett L. Hawn wrote:
> > 
> > > On Sun, 9 Mar 1997, David R. Conrad wrote:
> > > 
> > > > >	The way I see it, it is worth no more than $10,000. As that is what
> > > > >ARIN is going to charge any corp to get a Class B. 
> > > > 
> > > > How much is your time (spent making up and writing the justification for
> > > > a class B) worth?
> > > 
> > > I think you miss my point, since the ARIN is for all intents and purposes
> > > selling address space, who are they to say no? Apparently someone made a
> > > case for a class B at one time or another, no longer needs it (for whatever
> > > reason) and wants to pass it on to someone else and make a little profit in
> > > at the same time. Now granted, I don't neccessarily agree with what they're
> > > doing, but I certainly can't say anything 'wrong' about it either. I mean,
> > > lets think about this for a second.
> > > 
> > > Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
> > > is in order as it should be. I decide for whatever reason to turn off my
> > > routers, sell my equipment and move to the Caymans to enjoy the rest of my
> > > life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
> > > block to someone else and make a small (or large for that matter, I'm sure I
> > > could sell it for a interesting sum of money) profit.
> > > 
> > > scenario 1:
> > > 
> > > It gets returned and some other poor fool has to jump through flaming hoops
> > > and surive a pool of toxic waste to get a few IPs.
> > > 
> > > scenario 2:
> > > 
> > > I change all the records to point to them, swip it out to them, basically do
> > > everything needed to make them the legitimate 'owners' of that block, they
> > > pay me a nice lump of cash and we're both happy.
> > > 
> > > As I see it, changing ownership of IPs is no different than changing
> > > ownership of a domain. 
> > > 
> > > 
> > > [-]                Brett L. Hawn (blh @ nol dot net)                       [-]
> > > [-]                Networks On-Line - Houston, Texas                       [-]
> > > [-]                           713-467-7100                                 [-]
> > > 
> > 
> > --
> > Regards,
> > Tom
> >   ________________________________________________________________________
> >  |   "The Egg Domain"    |       "And all you touch and all you see,      | 
> >  |    tomg at egg.com       |          is all your life will ever be."       |
> >  | http://www.egg.com/   |                               (Pink Floyd)     |
> > 
> > 
> > 
> 
> Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
> (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> 

--
Regards,
Tom
  ________________________________________________________________________
 |   "The Egg Domain"    |       "And all you touch and all you see,      | 
 |    tomg at egg.com       |          is all your life will ever be."       |
 | http://www.egg.com/   |                               (Pink Floyd)     |






From JimFleming at unety.net  Mon Mar 10 17:55:03 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 11:55:03 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2D49.E48DEBE0@webster.unety.net>

On Monday, March 10, 1997 8:34 AM, Alex P. Rudnev[SMTP:alex at Relcom.EU.net] wrote:
@ Hi. It's not good idea to discusse _can we /NIC/ allow or can we 
@ disallow_.
@ More interesting is _how to prevent address space wasting_ and _how to 
@ prevent extra payements..._.
@ 
@ If you'll disallow class B selling, Internet would lost 256*256 
@ addresses, because this class B network would be unused (and somebody 
@ would use class C networks instead_. It's bad thing, isn't it?
@ 
@ On the other hand, if you'll allow free saling of the address space, 
@ internet would be the homeplace of the big nabobs who can bye total 
@ address space and break down small competitors (and even small 
@ countries); it'll mean the deaths of the Internet, isn't it?
@ 

This is the case now...upstream providers are the "big nabobs"...
they do not incur the costs of renumbering, they do not get concerned
when they make a bid to a customer, they have the resources
to deliver. They may not have paid for these resources but they
have them...just check the records...

@ I do not know how would NOC go between this _scilla_ and _charibda_, but 
@ it's one of this important questions the internet's future depends of.
@ 
@ 

Yes...some people feel this is a very important area....
unfortunately, the solutions being proposed favor the
"big nabobs"...


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From lists at reflections.eng.mindspring.net  Mon Mar 10 18:04:47 1997
From: lists at reflections.eng.mindspring.net (Todd Graham Lewis)
Date: Mon, 10 Mar 1997 13:04:47 -0500 (EST)
Subject: Cayman Island Scenarios
In-Reply-To: <01BC2D48.AADAEA20@webster.unety.net>
Message-ID: <Pine.LNX.3.95q.970310130240.755B-100000@reflections.eng.mindspring.net>

On Mon, 10 Mar 1997, Jim Fleming wrote:

> Companies should probably make sure they "own" their assets...

And commentators should probably make sure they "have" a clue...

Reorganizing my machine this weekend, I seem to have lost my .procmailrc
with the nice (*Flemming > /dev/null) line in it.  Would someone mind
reposting it, or sending it via private mail? 

__
Todd Graham Lewis          MindSpring Enterprises      tlewis at mindspring.com





From JimFleming at unety.net  Mon Mar 10 17:46:17 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 11:46:17 -0600
Subject: Cayman Island Scenarios
Message-ID: <01BC2D48.AADAEA20@webster.unety.net>

On Monday, March 10, 1997 9:03 AM, Alex P. Rudnev[SMTP:alex at Relcom.EU.net] wrote:
@ > @ Say I 'own' the fictional block 223.101.0.0, its swipped to me, everything
@ > @ is in order as it should be. I decide for whatever reason to turn off my
@ > @ routers, sell my equipment and move to the Caymans to enjoy the rest of my
@ > @ life. I now have two choices, 1: Return my block to ARIN, or 2: Sell my
@ > @ block to someone else and make a small (or large for that matter, I'm sure I
@ > @ could sell it for a interesting sum of money) profit.
@ Hmm, I just asked the same question... If you'll sell your business, why 
@ do you think somebody buy your routers withouth your address space? If 
@ somebody buy yoy ISP business this somebody need your address space to 
@ continue IP service...
@ 

I agree, many of these IP allocation notions seem to come from
people who have never had to worry about the business end
of the ISP operation...

IP addresses are now valuable assets. Businesses may have
to show them on their books. In order to do that, they may have
to show that they "own" the addresses. For some companies
it might be best to purchase their addresses to prove this ownership.

This is an area that is rapidly gaining more attention from CPAs
and attorneys that have to protect corporate assets, especially
when shareholders are involved from the general public.

@ > @ scenario 1:
@ > @ 
@ > @ It gets returned and some other poor fool has to jump through flaming hoops
@ > @ and surive a pool of toxic waste to get a few IPs.
@ > @ 
@ > @ scenario 2:
@ > @ 
@ > @ I change all the records to point to them, swip it out to them, basically do
@ > @ everything needed to make them the legitimate 'owners' of that block, they
@ > @ pay me a nice lump of cash and we're both happy.
@ > @ 
@ > @ As I see it, changing ownership of IPs is no different than changing
@ > @ ownership of a domain. 
@ > @ 
@ > 
@ > 
@ > Scenario 3:
@ > 
@ > 	You sell the entire company before turning off the routers and
@ > 	the block stays with the operation on a lease arrangement.
@ > 	It eventually gets absorbed into a larger ISP and lost on the
@ > 	books in the mega transaction.
@ > 
@ > Scenario 4:
@ > 
@ > 	You move to the Cayman Islands and set up a competing
@ > 	"NIC". One of the NICs currently operates out of the
@ > 	Seychelles, so maybe the Caymans are the next best
@ > 	place to start an address NIC.
@ > 
@ > Question: When companies like MCI and Bellcore get bought,
@ > 	do they have to turn all of their blocks back into the "NIC"
@ > 	and start over...;-)
@ Aga...(yes, in english...). 
@ 
@ Or if MCI splits into 2 new companies, would it retirn it's address 
@ space to the NIC? -:)
@ 

I would assume that assets would be handled as assets...
Companies should probably make sure they "own" their assets...

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Mon Mar 10 18:39:08 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 12:39:08 -0600
Subject: IP Address Assets
Message-ID: <01BC2D50.0CAB0760@webster.unety.net>

On Sunday, March 09, 1997 11:42 PM, Tom Glover[SMTP:tomg at boiled.egg.com] wrote:
@ 
@ Good question! Would the bankrupt court consider the address space as a
@ sellable asset?
@ 

I believe that you will find the answer to be yes...

Companies in the U.S. should probably consult with their
CPAs and attorneys on how the IRS handles assets such
as IP addresses.

This is especially important if an asset is required without
any payment being made. If a /8 is worth $1,000,000 and
some company is arbitrarily given one of these to help
their "start-up" get venture capital, then that asset is a
key to obtaining the funding and is part of the capitalization
of the company.

The organization "giving" the "start-up" that block, could
be viewed as an "equity" partner or stockholder in the
start-up. If the start-up raised $4,000,000 and added the
block to their Balance Sheet then that asset would be
20% of the company. That can be a significant ownership
interest in a start-up, subject to the 5% limits.

Again...I suggest that companies make sure they understand
the value of their IP assets and how to account for that value.

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From kimh at internic.net  Mon Mar 10 20:13:39 1997
From: kimh at internic.net (Kim Hubbard)
Date: Mon, 10 Mar 1997 15:13:39 -0500 (EST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Chameleon.857969852.jtk@monet.titania.net> from "Joseph T. Klein" at Mar 9, 97 10:10:20 pm
Message-ID: <199703102013.PAA08847@moses.internic.net>

> 
> What is the InterNIC policy on the sale of class Bs?
> --
> From:   Joseph T. Klein, Titania Corporation http://www.titania.net
> E-mail: jtk at titania.net  Sent:   22:10:20 CST/CDT 03/09/97

The InterNIC's policy is what's stated in rFC2050.  An organization
must justify the utilization efficiency of address space.  They need
to justify it whether they request it from a regional registry, whether
they buy it or whether they received it for Xmas.

The way I look at it is, an organization received address space because
of information they listed on an IP template.  They had a requirement
for this amount of IP numbers.  Even if they received it long ago when
it was easier to get addresses, they still had to show some kind of
requirement.  If they no longer have a requirement for the address,
they should return it.

Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
right about now and it is true that most companies won't return it
if they think they can sell it.  But I think having a procedure in
place to at least begin reclaiming addresses from those organizations
that are no longer in business can only help matters.  

Kim








From JimFleming at unety.net  Mon Mar 10 20:30:31 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 14:30:31 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2D5F.9C9B55A0@webster.unety.net>

On Monday, March 10, 1997 8:47 AM, Alex P. Rudnev[SMTP:alex at Relcom.EU.net] wrote:
@ Hmm, let's make your questions more complex - if I own ISP and this ISP 
@ bacame bankrupt, wpuld it's address space be - selled, returned, owned by 
@ it's customers, etc... ???
@ 
@ 

In the current system, because there is no active
"renewal fee" system or no aggressive ecology
or reclamation,. it will likely become forgotten
and abandoned...

Of course, if this was space obtained from an
"upstream provider" then it was never the ISP's
to begin with and the "upstream" pulls it back
and gives it to someone else...

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Mon Mar 10 20:28:02 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 14:28:02 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2D5F.43A71E20@webster.unety.net>

On Monday, March 10, 1997 5:46 AM, Michael Shields[SMTP:shields at crosslink.net] wrote:
@ > So, since I paid money for my car registration & license plates, I should 
@ > be able to sell my plates to someone else to put on their car?
@ 
@ I believe that people with spiffy vanity plates have sold them.  Why not?
@ 
@ But discussion about the Internet is always plagued with analogies.
@ IP address allocation is not really like the allocation of land, or
@ phone numbers, or pollution credits, or milk quotas, or typing paper,
@ or license plates, or routing table slots, or cocaine.  It's sort of
@ like all of these things, but not completely like any of them.  And
@ the nature of an analogy is that it pretends two things are similar in
@ all ways.
@ 
@ The best way to think about this is not: "IP addresses should be
@ allocated in X way because Y is allocated that way," "But IP addresses
@ are not like Y," "Are so!", but instead: "What is the current policy
@ on IP address allocation?  What are the implications?  What would be
@ the implications of this other policy?"
@ 
@ Analogies are a good tool when things really are the same, but nothing
@ hurts you like using the wrong tool.  Since IP addresses are not like
@ other things, there is not much to compare them to.
@ -- 
@ Shields, CrossLink.
@ 
@ 

Analogies are sometimes useful when trying to explain
complex technical problems to a non-technical person.

Imagine trying to explain IP address allocations to
a U.S. Senator. Imagine trying to explain routing
tables, flapping, aggregation, source filtering, etc.

Imagine trying to explain how "fair" the allocation
policies are and trying to define an "upstream
provider". Just trying to define an ISP is a challenge
in itself.

Instead, imagine starting with...

	"IP addresses are like phone numbers"
....
	"Senator, the companies in your State have
	no phone numbers allocated to them, the
	State of Virginia controls those..."
...
	"Yes Senator, people in the State of
	Virginia now want to charge fees to
	obtain phone numbers from their stock pile..."
...
	"Where did they get those phone numbers ?
	well Senator, they obtained them from
	California..."
...
	"Yes, Senator people in California do not
	have to pay the State of Virginia for their
	phone numbers they get them directly from
	the source..."
...
	"Yes, Senator there are exceptions, lots
	of exceptions...Nooo, they are not documented
	the Internet does not have anything like the
	Confressional Record...there are mailing
	lists but people can delete records after the
	fact if they do not like the story that unfolds..."

<click>.....<dial tone>


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From alex at Relcom.EU.net  Mon Mar 10 20:33:34 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Mon, 10 Mar 1997 23:33:34 +0300 (MSK)
Subject: IP Address Assets
In-Reply-To: <01BC2D50.0CAB0760@webster.unety.net>
Message-ID: <Pine.SUN.3.91.970310231444.15674U-100000@virgin>

> On Sunday, March 09, 1997 11:42 PM, Tom Glover[SMTP:tomg at boiled.egg.com] wrote:
> @ 
> @ Good question! Would the bankrupt court consider the address space as a
> @ sellable asset?
> @ 
> 
> I believe that you will find the answer to be yes...
I believe... yes, I believe... Through it was not joke but serious 
question; and I hope you get serious answer...

Please, pay attention to the fact - IP numbers are not selled, they cost 
nothing; but they are important part of the assets ISP does have... DO 
you think it'll be forever - the thing _cost nothing_ but _is limited_ 
and _is important_...? 

No matter if _there exist big nabobs_ or _not_... Everything is relative 
- there is one set of _big nabobs_ there i Russia; there is another set 
in Europe, and 3'th set in USA (and some _USA's nabobs_ have not any real 
weight in Russia, for example_). But the truths is _we would not see a 
lot of existing ISP in a few next years_ (in USA, in Russia, in Europe - 
I am not market man and don't like to predict future). And I dislike to 
have a lot of flame in the mail lists, a lot of wasted address space in 
IP numbers, and a lot of routing problems when this small ISP would be 
joined, merged, splitted etc... 

I do not know if InterNIC's people think about this, or they allow 
everything to flow as it's flowing itself. But the time of academic's 
Internet is over, and new players are appeared on the playboard... 
De facto European ISP buy address space, because they pay for the IP 
registry; and this helps to keep address space. You can blame to those 
who sells class-B networks; but if they would not sell them, nobody use 
this address space at all (nobody cause them to free this space)...

It's important to go between scilla and charibda (sorry, I am not sure 
about spelling this names in English); I have when american's NIC began 
to ask money for the top level domains, but can't get this money by any 
acceptable ways (and a lot of people over the world send faxes, try to 
call them by phone etc because they have not enougph phones and peoples 
to do their work); I am afraid if class-B network would cost 60,000$ 
(it's not too great for the _big nabobs_ or for the old ISP but it's 
serious barrier for the small ISP in the small countries - let's imagine 
some ISP in the Georgia, for example, or some scientific institute in 
Armenia)... 

Cleanly it's not good place _nanog_ to discuss there, but I don't see 
another one while...

> 
> Companies in the U.S. should probably consult with their
> CPAs and attorneys on how the IRS handles assets such
> as IP addresses.
> 
> This is especially important if an asset is required without
> any payment being made. If a /8 is worth $1,000,000 and
> some company is arbitrarily given one of these to help
> their "start-up" get venture capital, then that asset is a
> key to obtaining the funding and is part of the capitalization
> of the company.
> 
> The organization "giving" the "start-up" that block, could
> be viewed as an "equity" partner or stockholder in the
> start-up. If the start-up raised $4,000,000 and added the
> block to their Balance Sheet then that asset would be
> 20% of the company. That can be a significant ownership
> interest in a start-up, subject to the 5% limits.
> 
> Again...I suggest that companies make sure they understand
> the value of their IP assets and how to account for that value.
> 
> --
> Jim Fleming
> Unir Corporation
> 
> e-mail:
> JimFleming at unety.net
> JimFleming at unety.s0.g0 (EDNS/IPv8)
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





From shields at crosslink.net  Mon Mar 10 20:53:28 1997
From: shields at crosslink.net (Michael Shields)
Date: Mon, 10 Mar 1997 15:53:28 -0500
Subject: Class "B" forsale (fwd) 
In-Reply-To: <01BC2D5F.43A71E20@webster.unety.net>
References: <01BC2D5F.43A71E20@webster.unety.net>
Message-ID: <199703102053.PAA04605@daedalus.crosslink.net>

> Analogies are sometimes useful when trying to explain
> complex technical problems to a non-technical person.

So?  This is *nanog*.  Where are the non-technical people here?

The thread should be over on piara or something anyway.
-- 
Shields, CrossLink.




From JimFleming at unety.net  Mon Mar 10 20:35:21 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 14:35:21 -0600
Subject: Class "B" forsale (fwd)
Message-ID: <01BC2D60.49111D60@webster.unety.net>

On Monday, March 10, 1997 9:13 AM, Kim Hubbard[SMTP:kimh at internic.net] 
wrote:
@ >
@ > What is the InterNIC policy on the sale of class Bs?
@ > --
@ > From:   Joseph T. Klein, Titania Corporation http://www.titania.net
@ > E-mail: jtk at titania.net  Sent:   22:10:20 CST/CDT 03/09/97
@
@ The InterNIC's policy is what's stated in rFC2050.  An organization
@ must justify the utilization efficiency of address space.  They need
@ to justify it whether they request it from a regional registry, whether
@ they buy it or whether they received it for Xmas.
@
@ The way I look at it is, an organization received address space because
@ of information they listed on an IP template.  They had a requirement
@ for this amount of IP numbers.  Even if they received it long ago when
@ it was easier to get addresses, they still had to show some kind of
@ requirement.  If they no longer have a requirement for the address,
@ they should return it.
@

ISPs have a very small percentage of the IP address
allocations. Despite this, ISPs endure most of the pain.

Why not focus on this 25% of the addess space first...?

CA	0.0.0.0	IANA (RESERVED-1)
CA	1.0.0.0	IANA (RESERVED-9)
CA	2.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-2)
NJ	3.0.0.0	General Electric Company (NET-GE-INTERNET)
MA	4.0.0.0	BBN Planet (NET-SATNET)
CA	5.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-5)
AZ	6.0.0.0	Army Information Systems Center (NET-YPG-NET)
CA	7.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-11)
MA	8.0.0.0	Bolt Beranek and Newman Inc. (NET-BBN-NET-TEMP)
NY	9.0.0.0	IBM Corporation (NET-IBM)
CA	10.0.0.0	IANA (RESERVED-6)
CA	11.0.0.0	DoD Intel Information Systems (NET-DODIIS)
FL	12.0.0.0	AT&T ITS (NET-ATT)
CA	13.0.0.0	Xerox Palo Alto Research Center (NET-XEROX-NET)
CA	14.0.0.0	Public Data Network (NET-PDN)
CA	15.0.0.0	Hewlett-Packard Company (NET-HP-INTERNET)
CA	16.0.0.0	Digital Equipment Corporation (NET-DEC-INTERNET)
CA	17.0.0.0	Apple Computer, Inc. (NET-APPLE-WWNET)
MA	18.0.0.0	Massachusetts Institute of Technology (NET-MIT-TEMP)
MI	19.0.0.0	Ford Motor Company (NET-FINET)
VA	20.0.0.0	Computer Sciences Corporation (NET-CSC)
VA	21.0.0.0	DDN-RVN (NET-DDN-RVN)
DC	22.0.0.0	Defense Information Systems Agency (NET-DISNET)
CA	23.0.0.0	IANA (NET-DDN-TC-NET)
CA	24.0.0.0	@Home Network (NETBLK-ATHOME)	ATHOME  24.0.0.0 - 24.3.255.0
UK	25.0.0.0	Royal Signals and Radar Establishment (NET-RSRE-EXP)
VA	26.0.0.0	Defense Information Systems Agency (NET-MILNET)
CA	27.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-10)
VA	28.0.0.0	ARPA DSI JPO (NET-DSI-NORTH)
DC	29.0.0.0	Defense Information Systems Agency (NET-MILX25-TEMP)
DC	30.0.0.0	Defense Information Systems Agency (NET-ARPAX25-TEMP)
CA	31.0.0.0	IANA (RESERVED-12)
Norway	32.0.0.0	Norsk Informasjonsteknologi (NET-NORGESNETT)
OH	33.0.0.0	DLA Systems Automation Center (NET-DCMC)
TX	34.0.0.0	Halliburton Company (NET-HALLIBURTON)
MI	35.0.0.0	Merit Network Inc. (NET-MERIT)
CA	36.0.0.0	Stanford University (NET-SU-NET-TEMP)
CA	37.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-37A)
VA	38.0.0.0	Performance Systems International (NET-PSINETA)
CA	39.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED-39A)
IN	40.0.0.0	Eli Lilly and Company (NET-LILLY-NET)
CA	41.0.0.0	Internet Assigned Numbers Authority (RESERVED-41A)
CA	42.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-42)
Japan	43.0.0.0	Japan Inet (NET-JAPAN-A)
CA	44.0.0.0	Amateur Radio Digital Communications (NET-AMPRNET)
CA	45.0.0.0	Interop Show Network (NET-SHOWNETA)
MA	46.0.0.0	Bolt Beranek and Newman Inc. (NET-BBNNET)
Canada	47.0.0.0	Bell-Northern Research (NET-BNR)
NY	48.0.0.0	Prudential Securities Inc. (NET-PRUBACHE)
	49.0.0.0	No match for "49.0.0.0".
	50.0.0.0	No match for "50.0.0.0".
UK	51.0.0.0	Department of Social Security of UK (NET-ITSANET)
DE	52.0.0.0	E.I. duPont de Nemours and Co., Inc. (NET-DUPONT1)
Germany	53.0.0.0	cap debis ccs (NET-DB-NET2)
NJ	54.0.0.0	Merck and Co., Inc. (NET-MERCK2)
VA	55.0.0.0	Army National Guard Bureau (NET-RCAS2)
NC	56.0.0.0	U.S. Postal Service (NET-USPS1)
France	57.0.0.0	SITA-Societe Internationale de Telecommunications 
Aeronautiques (NET-SITA2)
CA	58.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-58)
CA	59.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-59)
CA	60.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-60)
CA	61.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-61)
CA	62.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-62)
CA	63.0.0.0	Internet Assigned Numbers Authority (IANA) (RESERVED) 
(NET-RESERVED-63)

@ Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
@ right about now and it is true that most companies won't return it
@ if they think they can sell it.  But I think having a procedure in
@ place to at least begin reclaiming addresses from those organizations
@ that are no longer in business can only help matters.
@

I agree...the following posting explains
why I do not think ARIN will be able to do that...

@@@@@@@@

----------
From: 	Jim Fleming[SMTP:JimFleming at unety.net.]
Sent: 	Monday, March 10, 1997 1:50 PM
To: 	'John Curran'; Jim Fleming
Cc: 	'Leo Smith'; 'Tim Bass'; 'Bradley Dunn'; 'Christopher Sevcik'; 
'ckuehn at nsf.gov'; 'dont at netsol.com'; 'gstrawn at nsf.gov'; 'Jay Fenello'; 
'Justin W. Newton'; 'Kent Landfield'; 'lsundro at nsf.gov'; 'Peter J. de 
Blanc'
Subject: 	RE: InterNIC 2000 Summary

On Monday, March 10, 1997 1:36 PM, John Curran[SMTP:jcurran at bbnplanet.com] 
wrote:
@ >Comments...?
@
@ With respect to 10 regional NIC's performing IP allocations
@ without providing connectivity, you'll need a plan for how
@ routing announcements from such assignments will be handled.
@ The plan can be as simple as hand-waving and saying that
@ technology will allow an order-of-magnitude growth in the
@ routing calculations, but you should at least record the
@ assumption.
@
@ /John
@
@ p.s.  Proposed ARIN Board member
@ p.p.s.  Newdom dropped from cc intentionally,
@         as my comment is IP registry specific.
@

Thanks for the comment.

Once again, I will point out that the /8s will be assigned
for management purposes. The goal is NOT to hand out
virgin /8s to cause a run on the IPv4 address space to
fill the router tables with a massive number of entries.
Those are FUD notions and are not the objective.

The objective is to bring the IP address space under
proper management and funding and to get more people
involved to help work with reclamation and ecology as
well as aggressive aggregation plans. This can only
happen in Regions because some of this work takes
"local knowledge". Also, more people means more eyes
and ears and more attention to seeing IP space that
has been abandoned or is being wasted.

Moving the current small InterNIC group to another
small ARIN group is not the solution. We need to get
more people involved, more adults involved and get the
Internet on a track where the entire world community
can feel the stable structures and continue to invest.


P.S. ARIN list not added because ARIN is aimed at solving
a local InterNIC problem that will quickly go away when we
all work together on a coherent plan that encompasses, NSF,
NSI, the SBA, the FNC, the U.S. Government and the many
people and companies that have invested time and energy on
the emerging Registry Industry.

P.P.S. Newdom is a "whiteboard" archive for many Registry
Industry issues...it is mostly write-only...and has a reliable
operator who does not erase messages...


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)






From JimFleming at unety.net  Mon Mar 10 20:50:30 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 14:50:30 -0600
Subject: IP Address Assets
Message-ID: <01BC2D62.670420E0@webster.unety.net>

On Monday, March 10, 1997 5:33 PM, Alex P. Rudnev[SMTP:alex at Relcom.EU.net] wrote:
@ > On Sunday, March 09, 1997 11:42 PM, Tom Glover[SMTP:tomg at boiled.egg.com] wrote:
@ > @ 
@ > @ Good question! Would the bankrupt court consider the address space as a
@ > @ sellable asset?
@ > @ 
@ > 
@ > I believe that you will find the answer to be yes...
@ I believe... yes, I believe... Through it was not joke but serious 
@ question; and I hope you get serious answer...
@ 
@ Please, pay attention to the fact - IP numbers are not selled, they cost 
@ nothing; but they are important part of the assets ISP does have... DO 
@ you think it'll be forever - the thing _cost nothing_ but _is limited_ 
@ and _is important_...? 
@ 

IP Addresses cost a fortune...

All of the time, energy, travel, consultants fees, etc.
that go into obtaining IP addresses are part of the cost.


@ No matter if _there exist big nabobs_ or _not_... Everything is relative 
@ - there is one set of _big nabobs_ there i Russia; there is another set 
@ in Europe, and 3'th set in USA (and some _USA's nabobs_ have not any real 
@ weight in Russia, for example_). But the truths is _we would not see a 
@ lot of existing ISP in a few next years_ (in USA, in Russia, in Europe - 
@ I am not market man and don't like to predict future). And I dislike to 
@ have a lot of flame in the mail lists, a lot of wasted address space in 
@ IP numbers, and a lot of routing problems when this small ISP would be 
@ joined, merged, splitted etc... 
@ 

When people have to start paying to be routed then
this will end.

I have suggested that ISPs be given a /18 only after
they produce signed routing agreements from 2
providers with a minimum bandwidth on each connection
of 1.5 Mbps or better.

The key is the system has to be objective. It does not
have to be easy it just has to be fair for all. Also, the
system should not favor companies with the resources
to drive or fly to Fairfax County Virginia or companies
that can open an office there or companies that can
spend hours on the phone from Moscow to that location.

The IP resources need to be placed under proper
management and closer to the people that need them.
Geographic considerations have to be taken into account
because sometimes local situations must be fully
understood to do the proper job.

@ I do not know if InterNIC's people think about this, or they allow 
@ everything to flow as it's flowing itself. But the time of academic's 
@ Internet is over, and new players are appeared on the playboard... 
@ De facto European ISP buy address space, because they pay for the IP 
@ registry; and this helps to keep address space. You can blame to those 
@ who sells class-B networks; but if they would not sell them, nobody use 
@ this address space at all (nobody cause them to free this space)...
@ 

Yes...the academics are now off playing with IPv6...

Unfortunately, the real problem is the psuedo-government crowd.
These are people who work for the governments but no one
in the government knows what they do and when things get
hot they step outside of the government arena and claim to
be non-government. It can drive a new company nuts.

Imagine a company going to a government office to get a
business license and finding that it was the company's
competitor issuing the license...

@ It's important to go between scilla and charibda (sorry, I am not sure 
@ about spelling this names in English); I have when american's NIC began 
@ to ask money for the top level domains, but can't get this money by any 
@ acceptable ways (and a lot of people over the world send faxes, try to 
@ call them by phone etc because they have not enougph phones and peoples 
@ to do their work); I am afraid if class-B network would cost 60,000$ 
@ (it's not too great for the _big nabobs_ or for the old ISP but it's 
@ serious barrier for the small ISP in the small countries - let's imagine 
@ some ISP in the Georgia, for example, or some scientific institute in 
@ Armenia)... 
@ 

Your regions need to have IP resources placed in
the region's hands for proper management. As you point
out it is a huge barrier to entry to try to sit on the phone
and FAX from a different part of the world. The time-zone
difference can be a bigg difference. When you are fresh
they are beat (or sleeping) and vice versa...


@ Cleanly it's not good place _nanog_ to discuss there, but I don't see 
@ another one while...
@ 

<http://www.arin.net> is suggested by many but in
my opinion, ARIN is being rail-roaded through the
decision-making process to help solve some very
well-known problems that are mostly local to the
NSF, NSI, and the InterNIC. ARIN mostly helps NSI.

@ > 
@ > Companies in the U.S. should probably consult with their
@ > CPAs and attorneys on how the IRS handles assets such
@ > as IP addresses.
@ > 
@ > This is especially important if an asset is required without
@ > any payment being made. If a /8 is worth $1,000,000 and
@ > some company is arbitrarily given one of these to help
@ > their "start-up" get venture capital, then that asset is a
@ > key to obtaining the funding and is part of the capitalization
@ > of the company.
@ > 
@ > The organization "giving" the "start-up" that block, could
@ > be viewed as an "equity" partner or stockholder in the
@ > start-up. If the start-up raised $4,000,000 and added the
@ > block to their Balance Sheet then that asset would be
@ > 20% of the company. That can be a significant ownership
@ > interest in a start-up, subject to the 5% limits.
@ > 
@ > Again...I suggest that companies make sure they understand
@ > the value of their IP assets and how to account for that value.
@ > 
<trim>

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From blh at nol.net  Mon Mar 10 20:56:39 1997
From: blh at nol.net (Brett L. Hawn)
Date: Mon, 10 Mar 1997 14:56:39 -0600 (CST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <199703102013.PAA08847@moses.internic.net>
Message-ID: <Pine.GSO.3.95.970310145540.6747A-100000@dazed.nol.net>

On Mon, 10 Mar 1997, Kim Hubbard wrote:

> Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
> right about now and it is true that most companies won't return it
> if they think they can sell it.  But I think having a procedure in
> place to at least begin reclaiming addresses from those organizations
> that are no longer in business can only help matters.  
> 
> Kim

So tell me, what exactly is stopping you from doing so and why wasn't this
started one hell of a long time ago? Or are we just hearing more of the
typical rhetoric we've come to expect from the Nic.


[-]                Brett L. Hawn (blh @ nol dot net)                       [-]
[-]                Networks On-Line - Houston, Texas                       [-]
[-]                           713-467-7100                                 [-]





From JimFleming at unety.net  Mon Mar 10 21:00:38 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 15:00:38 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2D63.D12B0140@webster.unety.net>

On Monday, March 10, 1997 2:53 PM, Michael Shields[SMTP:shields at crosslink.net] wrote:
@ > Analogies are sometimes useful when trying to explain
@ > complex technical problems to a non-technical person.
@ 
@ So?  This is *nanog*.  Where are the non-technical people here?
@ 
@ The thread should be over on piara or something anyway.
@ -- 
@ Shields, CrossLink.
@ 
@ 

Many lists are for technical people to discuss
issues and then other people take the results of those
discussions and those threads to other arenas...

Sometimes non-technical people subscribe in
a read-only mode and they have their "bots" read
the mail...this allows them to track more of the
Internet which is rapidly expanding...

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From JimFleming at unety.net  Mon Mar 10 20:55:18 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Mon, 10 Mar 1997 14:55:18 -0600
Subject: Class "B" forsale (fwd) 
Message-ID: <01BC2D63.12A8DD00@webster.unety.net>

On Monday, March 10, 1997 2:53 PM, Michael Shields[SMTP:shields at crosslink.net] wrote:
@ > Analogies are sometimes useful when trying to explain
@ > complex technical problems to a non-technical person.
@ 
@ So?  This is *nanog*.  Where are the non-technical people here?
@ 
@ The thread should be over on piara or something anyway.
@ -- 
@ Shields, CrossLink.
@ 
@ 

Here is my new "standard answer"...
the executive summary is..this can be moved to "newdom"...

@@@

Some people spend a lot of time trying to
divide groups and partition the Internet to
prevent things from getting started. This
usually shows up in the form of comments
about some mailing list having a narrow
charter and postings being "off-topic".

The "newdom" list has evolved to a point
where it has a narrow charter in a broad
Industry. That narrow charter can be best
described to be a "write-only" archival place
where topics related to the Registry Industry
can be placed for safe, reliable storage and
future reference.

With such a narrow charter, "newdom"
becomes a low-traffic Usenet. People that
subscribe to "newdom" might find themselves
like a person trying to read all of the articles
flowing from a Usenet "feed". If you find
yourself in that situation, you might want to
find a list with a broader charter such as
the eDNS, IAHC or ARIN lists...
	<http://www.edns.net>
	<http://www.iahc.org>
	<http://www.arin.net>

Also, people probably should not assume
that because "newdom" is used on a CC
that there is a active "newdom" group that
follows the thread. In many cases, "newdom"
is quietly doing the narrow job of archiving...
and it appears to do an excellent job of it...
It may not be fancy, but it is accurate...

Thanks to Richard Sexton for his reliable
service to "newdom"...the list for New
Directions in Oxygen Marketing...is
that narrow or broad...?

--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)

-----------------------------------------------------------------------------
This is the Newdom mailing list, newdom at vrx.net.  To subscribe or
unsubscribe or get help , send the word "subscribe" or "unsubscribe" or
"help" in the body (not subject) to newdom-request at vrx.net


--
Jim Fleming
Unir Corporation

e-mail:
JimFleming at unety.net
JimFleming at unety.s0.g0 (EDNS/IPv8)





From alex at Relcom.EU.net  Mon Mar 10 21:06:18 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Tue, 11 Mar 1997 00:06:18 +0300 (MSK)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <01BC2D5F.43A71E20@webster.unety.net>
Message-ID: <Pine.SUN.3.91.970311000531.534A-100000@virgin>

BTW, do you see big difference between _IP addres allocation_ and _radio 
frequencies fir TV channels allocation_? 




On Mon, 10 Mar 1997, Jim Fleming wrote:

> On Monday, March 10, 1997 5:46 AM, Michael Shields[SMTP:shields at crosslink.net] wrote:
> @ > So, since I paid money for my car registration & license plates, I should 
> @ > be able to sell my plates to someone else to put on their car?
> @ 
> @ I believe that people with spiffy vanity plates have sold them.  Why not?
> @ 
> @ But discussion about the Internet is always plagued with analogies.
> @ IP address allocation is not really like the allocation of land, or
> @ phone numbers, or pollution credits, or milk quotas, or typing paper,
> @ or license plates, or routing table slots, or cocaine.  It's sort of
> @ like all of these things, but not completely like any of them.  And
> @ the nature of an analogy is that it pretends two things are similar in
> @ all ways.
> @ 
> @ The best way to think about this is not: "IP addresses should be
> @ allocated in X way because Y is allocated that way," "But IP addresses
> @ are not like Y," "Are so!", but instead: "What is the current policy
> @ on IP address allocation?  What are the implications?  What would be
> @ the implications of this other policy?"
> @ 
> @ Analogies are a good tool when things really are the same, but nothing
> @ hurts you like using the wrong tool.  Since IP addresses are not like
> @ other things, there is not much to compare them to.
> @ -- 
> @ Shields, CrossLink.
> @ 
> @ 
> 
> Analogies are sometimes useful when trying to explain
> complex technical problems to a non-technical person.
> 
> Imagine trying to explain IP address allocations to
> a U.S. Senator. Imagine trying to explain routing
> tables, flapping, aggregation, source filtering, etc.
> 
> Imagine trying to explain how "fair" the allocation
> policies are and trying to define an "upstream
> provider". Just trying to define an ISP is a challenge
> in itself.
> 
> Instead, imagine starting with...
> 
> 	"IP addresses are like phone numbers"
> ....
> 	"Senator, the companies in your State have
> 	no phone numbers allocated to them, the
> 	State of Virginia controls those..."
> ...
> 	"Yes Senator, people in the State of
> 	Virginia now want to charge fees to
> 	obtain phone numbers from their stock pile..."
> ...
> 	"Where did they get those phone numbers ?
> 	well Senator, they obtained them from
> 	California..."
> ...
> 	"Yes, Senator people in California do not
> 	have to pay the State of Virginia for their
> 	phone numbers they get them directly from
> 	the source..."
> ...
> 	"Yes, Senator there are exceptions, lots
> 	of exceptions...Nooo, they are not documented
> 	the Internet does not have anything like the
> 	Confressional Record...there are mailing
> 	lists but people can delete records after the
> 	fact if they do not like the story that unfolds..."
> 
> <click>.....<dial tone>
> 
> 
> --
> Jim Fleming
> Unir Corporation
> 
> e-mail:
> JimFleming at unety.net
> JimFleming at unety.s0.g0 (EDNS/IPv8)
> 
> 

Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 239-10-10, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)





From alex at Relcom.EU.net  Mon Mar 10 21:07:42 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Tue, 11 Mar 1997 00:07:42 +0300 (MSK)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <01BC2D5F.43A71E20@webster.unety.net>
Message-ID: <Pine.SUN.3.91.970311000628.534B-100000@virgin>


Sorry for sintax error - I'd like to say _radio frequency allocations, 
for TV channels, for example_.





From michael at memra.com  Mon Mar 10 21:34:27 1997
From: michael at memra.com (Michael Dillon)
Date: Mon, 10 Mar 1997 13:34:27 -0800 (PST)
Subject: IP Address Assets
In-Reply-To: <Pine.SUN.3.91.970310231444.15674U-100000@virgin>
Message-ID: <Pine.BSI.3.93.970310130905.2221S-100000@sidhe.memra.com>

On Mon, 10 Mar 1997, Alex P. Rudnev wrote:

> It's important to go between scilla and charibda (sorry, I am not sure 
> about spelling this names in English)

Scylla and Charybdis -- It comes from the Illiad or the Odyssey by Homer
and a more common English term is "between a rock and a hard place".

Scylla was a beautiful maiden that Circe turned into a horrendous monster.
This monster used to devour seamen including 6 of Ulysses companions until
she was turned into a rock. Charybdis was another monster that lived in a 
whirlpool near this rock. It was a treacherous place and took great skill
to steer a boat between Scylla and Charybdis but Ulysses did succeed in
doing so.

> (it's not too great for the _big nabobs_ or for the old ISP but it's 
> serious barrier for the small ISP in the small countries - let's imagine 
> some ISP in the Georgia, for example, or some scientific institute in 
> Armenia)... 

Anyone in ex-SU will get IP address space from RIPE NCC
http://www.ripe.net or possibly from APNIC http://www.apnic.net if they
are in Asia. I'm not sure where the boundary for the two NIC's runs but
you can check their web pages or send them email. But everyone should
check the list of documents in the Recommended Reading section at
http://www.arin.net because they apply everywhere in the world.


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From bmanning at ISI.EDU  Mon Mar 10 21:48:24 1997
From: bmanning at ISI.EDU (bmanning at ISI.EDU)
Date: Mon, 10 Mar 1997 13:48:24 -0800 (PST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.GSO.3.95.970310145540.6747A-100000@dazed.nol.net> from "Brett L. Hawn" at Mar 10, 97 02:56:39 pm
Message-ID: <199703102148.AA17125@zed.isi.edu>

> 
> On Mon, 10 Mar 1997, Kim Hubbard wrote:
> 
> > Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
> > right about now and it is true that most companies won't return it
> > if they think they can sell it.  But I think having a procedure in
> > place to at least begin reclaiming addresses from those organizations
> > that are no longer in business can only help matters.  
> > 
> > Kim
> 
> So tell me, what exactly is stopping you from doing so and why wasn't this
> started one hell of a long time ago? Or are we just hearing more of the
> typical rhetoric we've come to expect from the Nic.
> 
> 

There is a procedure in place and it has been used to great effect.
The last time the space was "exercised" to recover space, we recovered
about 13% of the total available IPv4 space.  That was in 1995.

There are plans underway to re-exercise the process to see what can be
done wrt the TWD.  I expect that this time the effort will be directed 
to reducing the routing table size and not so much recovery of IP space.

Check the 1995 NANOG archives and the IEPG archives.

--bill




From paul at vix.com  Tue Mar 11 00:44:48 1997
From: paul at vix.com (Paul A Vixie)
Date: Mon, 10 Mar 1997 16:44:48 -0800
Subject: Class "B" forsale (fwd) 
In-Reply-To: Your message of "Mon, 10 Mar 1997 15:13:39 EST."
             <199703102013.PAA08847@moses.internic.net> 
Message-ID: <199703110044.QAA22923@wisdom.home.vix.com>

> Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
> right about now and it is true that most companies won't return it
> if they think they can sell it.  But I think having a procedure in
> place to at least begin reclaiming addresses from those organizations
> that are no longer in business can only help matters.  

I personally oversaw the return of four /16's recently, so I, at least,
do not consider this to be Pollyannaism.




From hank at ibm.net.il  Tue Mar 11 05:36:48 1997
From: hank at ibm.net.il (Hank Nussbacher)
Date: Tue, 11 Mar 1997 07:36:48 +0200 (IST)
Subject: Class "B" forsale (fwd) 
In-Reply-To: <199703110044.QAA22923@wisdom.home.vix.com>
Message-ID: <Pine.A32.3.95-heb-2.07.970311073419.71061F-100000@rex.ibm.net.il>

On Mon, 10 Mar 1997, Paul A Vixie wrote:

> > Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
> > right about now and it is true that most companies won't return it
> > if they think they can sell it.  But I think having a procedure in
> > place to at least begin reclaiming addresses from those organizations
> > that are no longer in business can only help matters.  
> 
> I personally oversaw the return of four /16's recently, so I, at least,
> do not consider this to be Pollyannaism.
> 

When I returned an ASN 2 months ago to RIPE, I asked what the procedure
was to deallocate an AS object and return it to the pool of available
numbers.  I was told there was no procedure since I was the first. :-)

Hank Nussbacher





From bmanning at ISI.EDU  Tue Mar 11 06:19:52 1997
From: bmanning at ISI.EDU (Bill Manning)
Date: Mon, 10 Mar 1997 22:19:52 -0800 (PST)
Subject: Class "B" forsale (fwd)
In-Reply-To: <Pine.A32.3.95-heb-2.07.970311073419.71061F-100000@rex.ibm.net.il> from "Hank Nussbacher" at Mar 11, 97 07:36:48 am
Message-ID: <199703110619.AA25506@zephyr.isi.edu>

> > I personally oversaw the return of four /16's recently, so I, at least,
> > do not consider this to be Pollyannaism.
> > 
> 
> When I returned an ASN 2 months ago to RIPE, I asked what the procedure
> was to deallocate an AS object and return it to the pool of available
> numbers.  I was told there was no procedure since I was the first. :-)
> 
> Hank Nussbacher

Not quite the same thing and not the same registries Hank.  Check the PIER
wg archives.  There is a method to return IPv4 prefixes.  ASN return is a bit
different but does work with InterNIC.  

-- 
--bill




From algold at lambda.lncc.br  Wed Mar 12 13:51:36 1997
From: algold at lambda.lncc.br (Alexandre Leib Grojsgold)
Date: Wed, 12 Mar 1997 10:51:36 -0300 (GRNLNDST)
Subject: AS1
Message-ID: <9703121351.AA15558@lambda.lncc.br>

A "sh ip bgp 200.255.71.0" command executed in a router connected to
MAE-EAST shows an AS-path of 1 7365.

Could someone tell me what is AS1 ??

TIA
Alexandre.





From ed at praseodymium.cistron.nl  Wed Mar 12 14:10:26 1997
From: ed at praseodymium.cistron.nl (Edvard Tuinder)
Date: Wed, 12 Mar 1997 15:10:26 +0100 (MET)
Subject: AS1
In-Reply-To: <9703121351.AA15558@lambda.lncc.br> from Alexandre Leib Grojsgold at "Mar 12, 97 10:51:36 am"
Message-ID: <199703121410.PAA02104@wildlife.cistron.net>

Alexandre Leib Grojsgold wrote:
> A "sh ip bgp 200.255.71.0" command executed in a router connected to
> MAE-EAST shows an AS-path of 1 7365.
> 
> Could someone tell me what is AS1 ??
AS1 is BBNPlanet's primary AS

(whois "AS 1")

-Ed
-- 
Edvard Tuinder
Cistron Internet Services		Finger ed at cistron.nl for PGP key
   ``I must fear Evil, for I am but mortal and mortals can only die''




From danny at genuity.net  Wed Mar 12 14:12:51 1997
From: danny at genuity.net (Danny McPherson)
Date: Wed, 12 Mar 1997 07:12:51 -0700
Subject: AS1 
Message-ID: <199703121412.HAA03179@cognition.genuity.net>

(danny at cognition):~$ whois 1
BBN Planet (ASN-BBN)            BBNPLANET                                    1
IANA (RESERVED-9)               RESERVED-9                             1.0.0.0

To single out one record, look it up with "!xxx", where xxx is the
handle, shown in parenthesis following the name, which comes first.

The InterNIC Registration Services Host contains ONLY Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.

(danny at cognition):~$ whois ASN-BBN
BBN Planet (ASN-BBN)
   150 Cambridge Park Dr.
   Cambridge, MA 02140

   Autonomous System Name: BBNPLANET
   Autonomous System Number: 1

   Coordinator:
      Curran, John  (JC347)  jcurran at BBNPLANET.COM
      (617) 873-4398

   Record last updated on 08-Dec-95.

The InterNIC Registration Services Host contains ONLY Internet Information
(Networks, ASN's, Domains, and POC's).
Please use the whois server at nic.ddn.mil for MILNET Information.

-danny


> A "sh ip bgp 200.255.71.0" command executed in a router connected to
> MAE-EAST shows an AS-path of 1 7365.
> 
> Could someone tell me what is AS1 ??
> 
> TIA
> Alexandre.
> 






From michael at memra.com  Wed Mar 12 14:11:05 1997
From: michael at memra.com (Michael Dillon)
Date: Wed, 12 Mar 1997 06:11:05 -0800 (PST)
Subject: AS1
In-Reply-To: <9703121351.AA15558@lambda.lncc.br>
Message-ID: <Pine.BSI.3.93.970312060918.24485c-100000@sidhe.memra.com>

On Wed, 12 Mar 1997, Alexandre Leib Grojsgold wrote:

> Could someone tell me what is AS1 ??

To find out the owner of an AS# use whois with the number by itself

whois 1

If this fails because you have a local version of whois then try

whois -h whois.internic.net 1

or

whois 1 at whois.internic.net

The -h version is the most common one.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From ttauber at noc.bbn.com  Wed Mar 12 14:13:57 1997
From: ttauber at noc.bbn.com (Tony Tauber)
Date: Wed, 12 Mar 1997 09:13:57 -0500
Subject: AS1
In-Reply-To: Alexandre Leib Grojsgold <algold@lambda.lncc.br>
        "AS1" (Mar 12, 10:51am)
References: <9703121351.AA15558@lambda.lncc.br>
Message-ID: <9703120913.ZM5213@noc.bbn.com>

On Mar 12, 10:51am, Alexandre Leib Grojsgold wrote:
> Subject: AS1
> A "sh ip bgp 200.255.71.0" command executed in a router connected to
> MAE-EAST shows an AS-path of 1 7365.
>
> Could someone tell me what is AS1 ??
>
> TIA
> Alexandre.
>
>-- End of excerpt from Alexandre Leib Grojsgold

noc-~ 169: whois 1
BBN Planet (ASN-BBN)            BBNPLANET                                    1

Gives a boost to know your #1, sometimes. 8-)

Tony





From sgarfink at hq.mainet.com  Wed Mar 12 22:52:01 1997
From: sgarfink at hq.mainet.com (sgarfink at hq.mainet.com)
Date: Wed, 12 Mar 1997 17:52:01 EST
Subject: Boston MXP Meeting
Message-ID: <199703122301.SAA02665@iris.mai.net>


This is MAI's official notice for the Boston MXP Meeting on Friday:

        The Boston MXP Meeting will be held in Boston City Hall this 
coming Friday, March 14th, at 2pm.  We must receive your reply for 
you to gain entrance.  Please let us know the number of people you 
wish to bring, as well as their names.  We look forward to seeing you 
there and to your participation in the Boston MXP.  
Please RSVP to noc at mai.net.

The meeting will take place in the MIS Conference Room (room 200) 
in City Hall.  City of Boston CIO (Chief Information Officer) Michael
Hernon will attend.  Lunch will be provided.

For more information on the Boston MXP,  see:

http://www.mai.net/bostonmxp

To join the Boston-MAX list, please email boston-max at hq.mainet.com
with subscribe in the body.

        More good news for the Boston MXP!

In the foreseeable future, the Boylston St. collocation will be bridged to
a collocation facility in 1 City Hall Plaza to provide additional rack
space for all MXP members.

Please send all questions/flames to noc at mai.net!  Thank you.  
Now returning you to your regularly scheduled brangles...


Sarah Garfinkel
Network Support Specialist
MAI Network Services - http://www.mai.net
1-888-624-2780




From stroud at jvnc.net  Thu Mar 13 00:15:56 1997
From: stroud at jvnc.net (Danny Stroud)
Date: Wed, 12 Mar 1997 19:15:56 -0500
Subject: New email address and telephone numbers
Message-ID: <199703130018.TAA05570@nfs1.jvnc.net>

I finally got set up with a GES Internet mail account.  Please update your
address books with this address.  Also, if you don't have it, note the new
phone and fax numbers.  This should make a lot of you happy that I no
longer use the un-cool .msn address!

Thanks, 
des
____________________________________________________
Danny E. Stroud
President
GES Internet
t: 609-514-3792
f: 609-514-9010
e: stroud at ges.com




From sunwei at sea.net.edu.cn  Thu Mar 13 18:42:49 1997
From: sunwei at sea.net.edu.cn (Sun Wei)
Date: Thu, 13 Mar 1997 10:42:49 -0800
Subject: How to protect registered IP addresses
Message-ID: <33284AA9.52C7@sea.net.edu.cn>

Hi, Internet Experts,

I run into a problem these days. We have a campus network with a class B
IP block. This network is connected with Internet. By now, we have
thousands of registered users and allocate IP addresses to them.
Recently, we installed an accouting system to monitor how much traffic
each user had accounted for. Each month, these users should pay their
bills based on how much traffic they have used.

Soon, we find some problems: Some guys are using the unallocated
addresses, and they are accessing Internet wildly; At the same time,
other anonymous users are using illegally the addresses of registered
users.

Here my questions are:

First, Is there any better solution to protect the unallocated addresses
--- besides access-list? The first selection seems to be adding
access-lists on the routers, to block all the unallocted addresses.
However, considering the quantity of the IP addresses(a class B), it
sure is a great burden to block the addresses one by one(or almost one
by one). I'm not sure if cisco routers support such long access-list.

Second, how can we protect the IP addresses of registered users from
being used by other people ?

Any tips are greatly appreciated!

regards,

Wei Sun




From gherbert at crl.com  Thu Mar 13 03:39:29 1997
From: gherbert at crl.com (George Herbert)
Date: Wed, 12 Mar 1997 19:39:29 -0800
Subject: How to protect registered IP addresses 
In-Reply-To: Your message of "Thu, 13 Mar 1997 10:42:49 PST."
             <33284AA9.52C7@sea.net.edu.cn> 
Message-ID: <199703130339.AA08682@mail.crl.com>


I believe you can just deny by default and allow traffic from the
registered address blocks under each interface, on incoming interfaces
at your central router (and sub-routers).  Nice short list.

-george william herbert
gherbert at crl.com




From randy at psg.com  Thu Mar 13 07:14:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 12 Mar 97 23:14 PST
Subject: consistent policy != consistent announcements
Message-ID: <m0w54io-0007zaC@rip.psg.com>

[ Most of this work was done by Andrew ]

A normal condition of peering between consenting adults is that the peers
have consistent policy across all points where they peer.  This is to allow
hot potato, whereby I can get rid of my packets destined for a peer at my
nearest exit to them.

A naive assumption we make is that this means that the peers will be making
the same announcements to each other at all points.  This turns out to not
always be the case.

I have customer A who connects to multihomed site M.  I also have customer B
who also connects to M.  I will see M as either "A M" or "B M", equal length
AS paths. depending on whether I am closer to A or B.

So in some portions of my network, I will prefer to get to M via A and in
others I will prefer to go via B.  Thus I will announce to my peers in some
locations "A M" and in others "B M".  The result is that I do not give the
same announcements to my peers at all locations, yet I have a consistent,
simple, and seemingly reasonable policy.

In another example, I have a peer P who connects to multihomed site M.  I
also have a customer C who connects to the multihomed site M.  I will see M
as either "P M" or "C M" - again equal length AS paths.  If I follow the
'normal' BGP path selection rules (and don't always prefer customers over
peers), then in some portions of my network, I will prefer M via P and in
others I will prefer M via C.

Therefore I will not announce any route to M to my peers in some locations,
as I don't announce peers to other peers, and in others I will announce "C
M".  Again, I do not make identical announcements to my peers, yet I have a
consistent policy.

Am I being unfair to my peers?  Would they be justified in making a stronger
requirement than 'consistent' policy?  What requirement would be reasonable?
[ note that, in the first example, the common policy of preferring customer
routes over peer routes will not change my announcements. ]

randy




From chris at netasset.com  Thu Mar 13 02:19:58 1997
From: chris at netasset.com (Chris Cook, Net Asset LLC)
Date: Wed, 12 Mar 1997 19:19:58 -0700
Subject: How to protect registered IP addresses
Message-ID: <000000508582941064398@corpserver.netasset.com>


On Thu, Mar 13, 1997, 3:39:29 AM PST George Herbert wrote:


>
>I believe you can just deny by default and allow traffic from the
>registered address blocks under each interface, on incoming interfaces
>at your central router (and sub-routers).  Nice short list.
>
>-george william herbert
>gherbert at crl.com
>

This is obviously better then nothing, and probably the most practical
solution, but most networks have holes in their allocated blocks.  
Wouldn't some sort of authentication scheme (RADIUS/TACACS
or maybe Kerbros) be a better solution?  More complicated for sure. 

The idea would be to check the connection request to the outgoing router
against some sort of database, then expiring the token after it's use.  The 
real trick to this is checking only the initial request.  Something more in the
realm of switching authentication...

Anyone have any ideas how something as large as a class B with say 30% address
utilization on scattered addresses (non-contigeous) could be rapidly verified
without checking every packet?

Thanks for your indulgance,

Chris Cook
Network Engineer
__________________________________________________________________________
Net Asset Network Operations Center
1315 Van Ness Ave., Suite 103
Fresno CA 93721
209/225-0222




From avg at pluris.com  Thu Mar 13 10:38:57 1997
From: avg at pluris.com (Vadim Antonov)
Date: Thu, 13 Mar 1997 02:38:57 -0800
Subject: consistent policy != consistent announcements
Message-ID: <199703131038.CAA01529@quest.pluris.com>

Randy Bush wrote:

>A normal condition of peering between consenting adults is that the peers
>have consistent policy across all points where they peer.

[example of a quasi-consistent scenario skipped]

>Am I being unfair to my peers?  Would they be justified in making a stronger
>requirement than 'consistent' policy?  What requirement would be reasonable?

There are three quasi-answers:

1) it's ok with consent of parties involved (i.e. you may want to coordinate
fancy policies with peers)

2) generally speaking, BGP path length is too blunt an instrument.  More fine-grained
control is needed to allow peers to fine-tune balance of their interests.  I'm
sorry to be too naive, but i'm repeating that for years and nobody seems to agree
that BGP needs real metrics.  How come?

3) on a phylosophical level, all involved parties should have a way to control
destiny of routes, to a some extent.  Right now, it's either control local to
the destination (local preferences), or control by adjacent neighbour (MEDs).
There's no way to extend it further (save for as-replication kludgery) or to
combine local and remote metrics in any meaningful way.

--vadim




From SEAN at SDG.DRA.COM  Thu Mar 13 10:46:38 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Thu, 13 Mar 1997 4:46:38 -0600 (CST)
Subject: consistent policy != consistent announcements
Message-ID: <970313044638.c4a6@SDG.DRA.COM>

>Therefore I will not announce any route to M to my peers in some locations,
>as I don't announce peers to other peers, and in others I will announce "C
>M".  Again, I do not make identical announcements to my peers, yet I have a
>consistent policy.

Yep, policy filters run up against the policy of only announcing the
single, best route.  I've been thinking with policy filters and variable
weighting, should it be changed to announcing the 'best' route that
meets policy, even if it is the second or third 'best' route you
know about.

>Am I being unfair to my peers?  Would they be justified in making a stronger
>requirement than 'consistent' policy?  What requirement would be reasonable?
>[ note that, in the first example, the common policy of preferring customer
>routes over peer routes will not change my announcements. ]

Fairness by what measure, and to which peers?  My first concern is the
loss of information when the route to M isn't announced.  This causes
unfairness when traffic ends up taking the 'long' route.  Since we don't
have a full-mesh among peering partners, the unfairness of the long
route could be considered a normal part of today's Internet, like
asymetrical routing.  More than likely your peer is doing the same
thing unto you.

The second effect of M's route not being announced happens when traffic
is blocked because no 'longer' path shows up anywhere else due to different
route weightings and policy filters across various combinations of ASs.
I consider this possibility the more serious problem.  As the peering
mesh becomes sparser, expect more missing in action paths, even if
the physical connections exist the 'best' path may not be announced.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation




From tonyb at uunet.pipex.com  Thu Mar 13 11:23:55 1997
From: tonyb at uunet.pipex.com (Tony Barber)
Date: Thu, 13 Mar 1997 11:23:55 +0000 (GMT)
Subject: consistent policy != consistent announcements
In-Reply-To: <199703131038.CAA01529@quest.pluris.com> from "Vadim Antonov" at Mar 13, 97 02:38:57 am
Message-ID: <19970313112355.15960.qmail@pool.pipex.net>

Vadim Antonov wrote:
>
>2) generally speaking, BGP path length is too blunt an instrument.  More fine-grained
>control is needed to allow peers to fine-tune balance of their interests.  I'm
>sorry to be too naive, but i'm repeating that for years and nobody seems to agree
>that BGP needs real metrics.  How come?
>

On this point does anyone have any experience of using the cisco DPA implementation
between providers ?

--Tony       




From randy at psg.com  Thu Mar 13 14:19:00 1997
From: randy at psg.com (Randy Bush)
Date: Thu, 13 Mar 97 06:19 PST
Subject: consistent policy != consistent announcements
References: <199703131038.CAA01529@quest.pluris.com>
Message-ID: <m0w5BMH-0007zaC@rip.psg.com>

>> A normal condition of peering between consenting adults is that the peers
>> have consistent policy across all points where they peer.
> [example of a quasi-consistent scenario skipped]
> 1) it's ok with consent of parties involved (i.e. you may want to coordinate
> fancy policies with peers)

In this particular case, a peer is complaining about a simple policy.  Is
there an other policy that would make them happy.  Can I hope that it is not
complex, hardier to maintain, or have undesirable side effects?  Is the peer
justified in asking me to implement different policy and what other
policies?

> 2) generally speaking, BGP path length is too blunt an instrument.  More
> fine-grained control is needed to allow peers to fine-tune balance of
> their interests.  I'm sorry to be too naive, but i'm repeating that for
> years and nobody seems to agree that BGP needs real metrics.  How come?

I thought that there was some plan to experiment with this, but have seen
nothing recently.  Perhaps the BGP artists have become otherwise occupied.
[ what will changing the length of the ASN do to the community format? ]

> 3) on a philosophical level, all involved parties should have a way to
> control destiny of routes, to a some extent.  Right now, it's either
> control local to the destination (local preferences), or control by
> adjacent neighbour (MEDs).  There's no way to extend it further (save for
> as-replication kludgery) or to combine local and remote metrics in any
> meaningful way.

I agree that this is worth exploring.  But it is a philosophical problem and
protocol design issue, thus perhaps better suited to other fora.  I am just
an unsmooth operator trying to understand how to be a good citizen and how
far I may have to bend to be one.

The reason I posted to NANOG is that I have a real today problem with an
actual unhappy peer.  And I am trying to understand if there is something
reasonable I can do to make them happy.  The inconsistencies described may
also cause problems for real world routing analysis tools.

So all good points.  And I agree with you philosophically.  But please bail
me out today.

randy




From randy at psg.com  Thu Mar 13 14:31:00 1997
From: randy at psg.com (Randy Bush)
Date: Thu, 13 Mar 97 06:31 PST
Subject: consistent policy != consistent announcements
References: <970313044638.c4a6@SDG.DRA.COM>
Message-ID: <m0w5BX6-0007zaC@rip.psg.com>

> My first concern is the loss of information when the route to M isn't
> announced.  This causes unfairness when traffic ends up taking the 'long'
> route.

My peer fears that and would like me to fix it.  I don't understand how I
can do that in a simple maintainable fashion.

> More than likely your peer is doing the same thing unto you.

Quite possibly, but they won't 'fess up to it.  And I don't want to whine at
them unless I know how to constructively address the opportunity (the peer
is a Californian:-).

> The second effect of M's route not being announced happens when traffic is
> blocked because no 'longer' path shows up anywhere else due to different
> route weightings and policy filters across various combinations of ASs.  I
> consider this possibility the more serious problem.  As the peering mesh
> becomes sparser, expect more missing in action paths, even if the physical
> connections exist the 'best' path may not be announced.

If my peer does not agree that my policy is reasonable and a consequence of
current tools, their reaction may be to reject inconsistent announcements
thereby increasing the likelihood that no path is propagated.

randy




From hhui at stardot.com  Thu Mar 13 14:49:32 1997
From: hhui at stardot.com (Hui-Hui Hu)
Date: Thu, 13 Mar 1997 09:49:32 -0500
Subject: How to protect registered IP addresses 
In-Reply-To: Your message of "Wed, 12 Mar 1997 19:19:58 MST."
             <000000508582941064398@corpserver.netasset.com> 
Message-ID: <199703131449.JAA26326@solstice.stardot.com>


Princeton has a piece of code that ARP bombs unregistered hosts. IPs that
are broken get sent an ARP packet with the same IP and an ethernet 
address of 00:00:00:de:ad or something. This is usually enough to disable 
Windows 95 boxes (since they do a RARP call when they boot up to check 
for duplicates) and some other OSes too. This provides a quick filter 
before actually blocking things at the router level, which is more expensive.

Of course the clueful can easily get around this, but hey.

-Tung-Hui Hu / Arc Four / hhui at arcfour.com





From jstewart at isi.edu  Thu Mar 13 14:58:26 1997
From: jstewart at isi.edu (John W. Stewart III)
Date: Thu, 13 Mar 1997 09:58:26 -0500
Subject: consistent policy != consistent announcements 
In-Reply-To: Your message of "Wed, 12 Mar 1997 23:14:00 PST."
             <m0w54io-0007zaC@rip.psg.com> 
Message-ID: <199703131458.JAA16197@central-services.east.isi.edu>


on the first example, if someone is complaining about what
you're doing, then, unless i'm missing something, they're
concerned much more about the letter of the policy than
the tone

add a peer P to your first example.  if P peers with you at
Point1 close to A's connection and again at a Point2 close
to B's connection, then P will hear M's prefixes at Point1
as "R A M" and at Point2 as "R B M".  but because the AS
path length is equal, they'll still be able to do closest
exit for M's prefixes.  the tone of the "consistent route"
policy is to keep one provider from having to carry
packets cross-country in both directions:  in this example
P does not have to do that

/jws

 > [ Most of this work was done by Andrew ]
 > 
 > A normal condition of peering between consenting adults is that the peers
 > have consistent policy across all points where they peer.  This is to allow
 > hot potato, whereby I can get rid of my packets destined for a peer at my
 > nearest exit to them.
 > 
 > A naive assumption we make is that this means that the peers will be making
 > the same announcements to each other at all points.  This turns out to not
 > always be the case.
 > 
 > I have customer A who connects to multihomed site M.  I also have customer B
 > who also connects to M.  I will see M as either "A M" or "B M", equal length
 > AS paths. depending on whether I am closer to A or B.
 > 
 > So in some portions of my network, I will prefer to get to M via A and in
 > others I will prefer to go via B.  Thus I will announce to my peers in some
 > locations "A M" and in others "B M".  The result is that I do not give the
 > same announcements to my peers at all locations, yet I have a consistent,
 > simple, and seemingly reasonable policy.
 > 
 > In another example, I have a peer P who connects to multihomed site M.  I
 > also have a customer C who connects to the multihomed site M.  I will see M
 > as either "P M" or "C M" - again equal length AS paths.  If I follow the
 > 'normal' BGP path selection rules (and don't always prefer customers over
 > peers), then in some portions of my network, I will prefer M via P and in
 > others I will prefer M via C.
 > 
 > Therefore I will not announce any route to M to my peers in some locations,
 > as I don't announce peers to other peers, and in others I will announce "C
 > M".  Again, I do not make identical announcements to my peers, yet I have a
 > consistent policy.
 > 
 > Am I being unfair to my peers?  Would they be justified in making a stronger
 > requirement than 'consistent' policy?  What requirement would be reasonable?
 > [ note that, in the first example, the common policy of preferring customer
 > routes over peer routes will not change my announcements. ]
 > 
 > randy




From stephen at clark.net  Thu Mar 13 15:05:34 1997
From: stephen at clark.net (Stephen Balbach)
Date: Thu, 13 Mar 1997 10:05:34 -0500 (EST)
Subject: IP over ATM overhead
Message-ID: <Pine.LNX.3.91.970313100137.21788F-100000@bisco.clark.net>


We are installing an ATM backbone connection and wondering what level 
of overhead can be expected. Ive read from %10 to %50 - this will be a 
LAN connection so we can assume almost no cell loss. Our provider has 
said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN 
configuration. Thanks!

Stephen Balbach
VP ClarkNet




From madison at queber.acsi.net  Thu Mar 13 15:31:46 1997
From: madison at queber.acsi.net (Eric D. Madison)
Date: Thu, 13 Mar 1997 10:31:46 -0500 (EST)
Subject: IP over ATM overhead
In-Reply-To: <Pine.LNX.3.91.970313100137.21788F-100000@bisco.clark.net>
Message-ID: <Pine.SOL.3.95.970313102210.27183A-100000@queber.acsi.net>

Well Stephen,
   Here at ACSI, our entire national backbone is ATM, the overhead so far
seems to be about 12-14%.  This is taking into account the 48/53 byte
percentage and the time to reassemble the cells into packets at the remote
end.  I have run tests in our lab and we can totally saturate a DS3 and an
OC-3 link via ATM.  This is in contrast to a clear channel DS-3 which
itself loses some bandwidth to conversions and overhead.  I would guess
that the difference of DS-3 ATM and clear channel is around 9% of your
bandwidth but I need to run more tests in the lab to make a more educated
guess.  But you don't run an ATM backbone if your just offering IP
service,  we use it to offer Frame/ATM/IP services all over the same
wire. Now, packet of sonet seems the way to go for high speed IP with
little overhead, but it is only available at 0C-3 and higher.  I have not
tested it yet to see the overhead or how good it works.  

Anyone out there really tested the POS cards from Cisco yet?


Eric


_______________________________________________________
      Eric D. Madison - Senior Network Engineer -   
 ACSI - Advanced Data Services - ATM/IP Backbone Group  
   24 Hour NMC/NOC (800)291-7889 Email: noc at acsi.net


On Thu, 13 Mar 1997, Stephen Balbach wrote:

> 
> We are installing an ATM backbone connection and wondering what level 
> of overhead can be expected. Ive read from %10 to %50 - this will be a 
> LAN connection so we can assume almost no cell loss. Our provider has 
> said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN 
> configuration. Thanks!
> 
> Stephen Balbach
> VP ClarkNet
> 





From jgs at ieng.com  Thu Mar 13 15:46:06 1997
From: jgs at ieng.com (John Scudder)
Date: Thu, 13 Mar 1997 10:46:06 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <970313044638.c4a6@SDG.DRA.COM> from "Sean Donelan" at Mar 13, 97 04:46:38 am
Message-ID: <199703131546.KAA16729@ieng.com>

> Yep, policy filters run up against the policy of only announcing the
> single, best route.  I've been thinking with policy filters and variable
> weighting, should it be changed to announcing the 'best' route that
> meets policy, even if it is the second or third 'best' route you
> know about.

Unless I misunderstand what you mean by "variable weighting", this
would not be a good idea.

It's a BGP design point for a router to only announce the route(s) that
it is actively *using*.  In your comment above,

a. If a router has a route it believes is "best", why isn't it using
   it?

b. Regardless of the answer, the router should announce the route it is
   using for its own forwarding.  To do otherwise would be to lie about
   the path which traffic will take to the advertised destination.  

   If policy forbids it from announcing the route it is using, so be
   it.  (Or, if that's not acceptable change the policy.)

By the way, this general fact about BGP (external announcements are
governed by internal route selection) also means that for Randy to
always announce the same route to his peer, he would have to change his
own, internal routing policy to do cold-potato routing to one of the
two candidate paths.  This doesn't seem like a reasonable thing for a
peer to demand he do.

Regards,

--John




From johnc at msc.edu  Thu Mar 13 15:59:38 1997
From: johnc at msc.edu (John Cavanaugh)
Date: Thu, 13 Mar 1997 09:59:38 -0600 (CST)
Subject: IP over ATM overhead
In-Reply-To: <Pine.LNX.3.91.970313100137.21788F-100000@bisco.clark.net> from "Stephen Balbach" at Mar 13, 97 10:05:34 am
Message-ID: <199703131559.JAA03117@kb.msc.edu>

> We are installing an ATM backbone connection and wondering what level 
> of overhead can be expected. ...

I wrote a paper on this subject a couple of years ago.  You can find
it at
	http://www.msci.magic.net/
under "Papers," the title is "Protocol Overhead in IP/ATM Networks",
or at
	ftp://www.magic.net/pub/overhead.ps

The level of protocol overhead depends on the medium, the AAL, and the
size of the transmission unit.  The best you'll do is to get 87% of the
raw bandwidth to the application (most of this is taken up by the lower
layers (ATM and below)), and this number can go as low as 70%.
-- 
John Cavanaugh                              EMail: johnc at msc.edu
Minnesota Supercomputer Center, Inc.
1200 Washington Ave. S                      Phone: +1 612 337-3556
Minneapolis, MN  55415                      FAX:   +1 612 337-3400




From pkavi at pcmail.casc.com  Thu Mar 13 16:18:43 1997
From: pkavi at pcmail.casc.com (pkavi at pcmail.casc.com)
Date: Thu, 13 Mar 97 11:18:43 EST
Subject: IP over ATM overhead
Message-ID: <9702138582.AA858281093@pcmail.casc.com>

     
The complete answer is that it depends upon packet size distributions.  
Let's assume that typical Internet type traffic patterns, which tend to 
have high percentages of packets at 40, 44, and 552 bytes.  
     
If you have a DS3 backbone, and have PLCP turned on, the maximum cell rate 
is 96,000 cells/sec.  If you multiply this value by the number of bits in 
the payload, you get:
     
        96000 cells/sec * 48 bytes/cell * 8 = 36.864 Mbps
     
But this is unrealistic, as it assumes perfect payload packing.  There are 
two other things that eat into the overhead value, namely the wasted 
padding, and the 8 byte SNAP header.
     
It's the SNAP header which causes most of the problems, forcing most small 
packets to consume two cells, with the second cell to be mostly empty 
padding.  This causes a loss of about another 16% from the 36.8 Mbps ideal 
throughput.
     
So the total throughput ends up being (for a DS3):
     
        DS3 Line Rate:              44.736
        PLCP Overhead              - 4.032            
        Per Cell Header:           - 3.840
        SNAP Header & Padding:     - 5.900
                                  =========
                                    30.960 Mbps

So, from a DS3 line rate of 44.736 Mbps, the total overhead is about 31%.  Hope 
this helps.

Prabhu Kavi
Manager, Network Architecture Group
Cascade Communications.
  







______________________________ Reply Separator _________________________________
Subject: IP over ATM overhead
Author:  Stephen Balbach <stephen at clark.net> at SMTPLINK
Date:    3/13/97 10:47 AM


     
We are installing an ATM backbone connection and wondering what level 
of overhead can be expected. Ive read from %10 to %50 - this will be a 
LAN connection so we can assume almost no cell loss. Our provider has 
said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN 
configuration. Thanks!
     
Stephen Balbach
VP ClarkNet





From hank at rem.com  Thu Mar 13 19:42:43 1997
From: hank at rem.com (Henry Kilmer)
Date: Thu, 13 Mar 1997 14:42:43 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <CMM.0.90.2.858281395.vaf@valinor.barrnet.net>
References: <CMM.0.90.2.858281395.vaf@valinor.barrnet.net>
Message-ID: <199703131942.OAA18533@crazy.rem.com>


Vince Fuller writes:
>I can see why you present inconsistant routes to us but I'm not sure that I
>understand why you'd prefer a customer prefix via a direct connection to them
>at one point in your network but via a connection to another provider at a
>different point in your network. That would seem internally inconsistant to
>me. Is this deliberate behavior to do shortest-exit within your network toward
>your customer?

We have some customers that have specifically requested this sort of arrangement.

-Hank




From vaf at valinor.barrnet.net  Thu Mar 13 19:29:55 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Thu, 13 Mar 97 11:29:55 PST
Subject: consistent policy != consistent announcements
In-Reply-To: Your message of Thu, 13 Mar 97 06:31 PST
Message-ID: <CMM.0.90.2.858281395.vaf@valinor.barrnet.net>

    > My first concern is the loss of information when the route to M isn't
    > announced.  This causes unfairness when traffic ends up taking the 'long'
    > route.
    
    My peer fears that and would like me to fix it.  I don't understand how I
    can do that in a simple maintainable fashion.
    
    > More than likely your peer is doing the same thing unto you.
    
    Quite possibly, but they won't 'fess up to it.  And I don't want to whine
    at them unless I know how to constructively address the opportunity (the
    peer is a Californian:-).

A correction: the peer individual is definitely not a native Californian,
though he does reside there.

As best I can tell, we present consistant routes to all of our peers. How do
I know this? Because I set up test routers to peer with our public interconnect
points and run periodically run my consistancy checker against them.

    If my peer does not agree that my policy is reasonable and a consequence of
    current tools, their reaction may be to reject inconsistent announcements
    thereby increasing the likelihood that no path is propagated.

>From our point of view, we aren't seeing any route which can be used for
shortest-exit to your multi-homed customers. Why? Probably because we don't
peer with the other ISP which serves those customers. The result is that we
have to backhaul traffic to other interconnect points, something which is
expensive for us and inconsistant with our normal peering policy.

I can see why you present inconsistant routes to us but I'm not sure that I
understand why you'd prefer a customer prefix via a direct connection to them
at one point in your network but via a connection to another provider at a
different point in your network. That would seem internally inconsistant to
me. Is this deliberate behavior to do shortest-exit within your network toward
your customer?

	--Vince




From vaf at valinor.barrnet.net  Thu Mar 13 19:44:34 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Thu, 13 Mar 97 11:44:34 PST
Subject: consistent policy != consistent announcements
In-Reply-To: Your message of Thu, 13 Mar 1997 14:42:43 -0500 (EST)
Message-ID: <CMM.0.90.2.858282274.vaf@valinor.barrnet.net>

    Vince Fuller writes:
    >I can see why you present inconsistant routes to us but I'm not sure that
    >I understand why you'd prefer a customer prefix via a direct connection to
    >them at one point in your network but via a connection to another provider
    >at a different point in your network. That would seem internally
    >inconsistant to me. Is this deliberate behavior to do shortest-exit within
    >your network toward your customer?

    We have some customers that have specifically requested this sort of
    arrangement.

Hmm. Do you treat the customer routes received from the other peer to be
"customer" routes, i.e. will you provide transit for them and re-advertise
them to your interconnect peers? If not, then you'll prevent interconnect
peers from using shortest-exit to get to those customer routes, which may
be considered a problem by those peers.

	--Vince




From vaf at valinor.barrnet.net  Thu Mar 13 19:42:25 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Thu, 13 Mar 97 11:42:25 PST
Subject: consistent policy != consistent announcements
In-Reply-To: Your message of Thu, 13 Mar 1997 09:58:26 -0500
Message-ID: <CMM.0.90.2.858282145.vaf@valinor.barrnet.net>

    add a peer P to your first example.  if P peers with you at
    Point1 close to A's connection and again at a Point2 close
    to B's connection, then P will hear M's prefixes at Point1
    as "R A M" and at Point2 as "R B M".  but because the AS
    path length is equal, they'll still be able to do closest
    exit for M's prefixes.

If that were happening, then we'd consisder the routes to be consistant, at
least for shortest-exit purposes.

What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely
because Randy doesn't consider "R B M", received from one of his peers, to be
a customer route.

    the tone of the "consistent route" policy is to keep one provider from
    having to carry packets cross-country in both directions:

Full agreement.

    in this example P does not have to do that

In your example, you are correct. But your example doesn't match the situation
that Randy is describing.

	--Vince




From riz at boogers.sf.ca.us  Thu Mar 13 19:54:40 1997
From: riz at boogers.sf.ca.us (the Riz)
Date: Thu, 13 Mar 1997 11:54:40 -0800 (PST)
Subject: consistent policy != consistent announcements
In-Reply-To: <CMM.0.90.2.858281395.vaf@valinor.barrnet.net> from Vince Fuller at "Mar 13, 97 11:29:55 am"
Message-ID: <199703131954.LAA16378@boogers.sf.ca.us>

Vince Fuller wrote:
> >From our point of view, we aren't seeing any route which can be used for
> shortest-exit to your multi-homed customers. Why? Probably because we don't
> peer with the other ISP which serves those customers. The result is that we
> have to backhaul traffic to other interconnect points, something which is
> expensive for us and inconsistant with our normal peering policy.
> 
> I can see why you present inconsistant routes to us but I'm not sure that I
> understand why you'd prefer a customer prefix via a direct connection to them
> at one point in your network but via a connection to another provider at a
> different point in your network. That would seem internally inconsistant to
> me. Is this deliberate behavior to do shortest-exit within your network toward
> your customer?
> 
> 	--Vince
> 

The scenario I can think where this would happen is using BGP
route-reflectors internally to reduce the intermeshing requirements for
IBGP peers.  Since a route-reflector only propagates the best route, it is
quite easy to get different as-paths in different parts of the network.
Not an ideal situation, to be sure, but "correcting" this behaviour is more
than a simple fix.

+j

-- 
Jeff Rizzo                                         http://boogers.sf.ca.us/~riz




From vaf at valinor.barrnet.net  Thu Mar 13 19:31:33 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Thu, 13 Mar 97 11:31:33 PST
Subject: consistent policy != consistent announcements
In-Reply-To: Your message of Thu, 13 Mar 1997 10:46:06 -0500 (EST)
Message-ID: <CMM.0.90.2.858281493.vaf@valinor.barrnet.net>

    By the way, this general fact about BGP (external announcements are
    governed by internal route selection) also means that for Randy to
    always announce the same route to his peer, he would have to change his
    own, internal routing policy to do cold-potato routing to one of the
    two candidate paths.  This doesn't seem like a reasonable thing for a
    peer to demand he do.

Well, if that "candidate path" is, in fact, one of Randy's customer, then
I would expect him to "cold-potato" route toward it. One would think that
to be part of the service that his customer is purchasing. I certainly
shouldn't have to do "cold-potato" routing to his customer, as that customer
isn't purchasing anything from me.

	--Vince




From dkerr at cisco.com  Thu Mar 13 20:04:16 1997
From: dkerr at cisco.com (Darren Kerr)
Date: Thu, 13 Mar 1997 12:04:16 -0800
Subject: IP over ATM overhead
In-Reply-To: <Pine.LNX.3.91.970313100137.21788F-100000@bisco.clark.net>
	(message from Stephen Balbach on Thu, 13 Mar 1997 10:05:34 -0500
	(EST))
Message-ID: <199703132004.MAA06668@monarch.cisco.com>

> We are installing an ATM backbone connection and wondering what level 
> of overhead can be expected. Ive read from %10 to %50 - this will be a 
> LAN connection so we can assume almost no cell loss. Our provider has 
> said on average %12 bandwidth is overhead. It will be a Cisco->Cisco LAN 
> configuration. Thanks!
> 
> Stephen Balbach
> VP ClarkNet

It probably depends on what you define as overhead.  You might define
it as that 16 bytes of AAL5/SNAP header & trailer per IP datagram,
plus 5 bytes per cell, plus whatever trailing bytes are wasted
in the last cell.

Compare this with packet over sonet (1 byte of IFG, 4 bytes of
ppp encapsulation, and 4 bytes of CRC).

Peter Lothberg gathered some packet size distributions at various
internet routers in January, and found that using the above definitions,
atm overhead consumed 22% of bandwidth, vs. 3.1% for POS overhead.
Looking at it another way, POS can move 24% more payload than ATM
using the same packet size distribution.  I've taken other snapshots
at other routers since then, and the results come very close.

/Darren









From SEAN at SDG.DRA.COM  Thu Mar 13 20:27:00 1997
From: SEAN at SDG.DRA.COM (Sean Donelan)
Date: Thu, 13 Mar 1997 14:27:00 -0600 (CST)
Subject: consistent policy != consistent announcements
Message-ID: <970313142700.c73d@SDG.DRA.COM>

>It's a BGP design point for a router to only announce the route(s) that
>it is actively *using*.  In your comment above,
>
>a. If a router has a route it believes is "best", why isn't it using
>   it?

I believe this is why it is called a "policy routing," to force sub-optimal
behavior compared to the normal selection algorithm of the routing
protocol.  You may have a 'best' route to a destination you use internally,
but you don't advertise it outside of your AS  because of policy reasons.
The standard example is not announcing routes heard from peers to other
peers.  This keeps all of MCI's traffic from being routed through a small
customer in the Northwest.  You may also have a 'lessor' path, which you
would advertise, except its not the 'best' route according to your policy,
i.e. a multi-homed customer with unequal cost lines.

Policy: Shortest Path

                       X         X A
                       X D       X D C
                       X D C
                     +----+     +----+
                -----| A  |-----| B  |-----   X A B
               /     +----+     +----+
              /        |    \     |
             X         |     \    |
              \        |      \   |
               \     +----+     +----+
                 ----| D  |-----| C  |-----   X A C
                     +----+     +----+
                      X          X A
                      X A        X D
                                 X A B

Policy: Fastest/Biggest Path between X & A(T1) & D(T3)

                       X D       X D A
                       X         X D C
                       X C D
                     +----+     +----+
              T1-----| A  |-----| B  |-----   X D A B
               /     +----+     +----+
              /        |    \     |
             X         |     \    |
              \        |      \   |
               \     +----+     +----+
              T3-----| D  |-----| C  |-----   X D C
                     +----+     +----+
                      X          X D
                      X A        X D A
                                 X D A B

Policy: Shortest Path/Do Not Announce Peer-to-Peer

                       X         X A
                       X D
                     +----+     +----+
                -----| A  |-----| B  |-----   X A
               /     +----+     +----+
              /        |    \     |
             X         |     \    |
              \        |      \   |
               \     +----+     +----+
                -----| D  |-----| C  |-----   X A
                     +----+     +----+
                      X          X A
                      X A        X D

Policy: Fastest/Biggest Path between X & A & D/Do Not Announce Peer-to-Peer

                       X D
                       X
                     +----+     +----+
              T1-----| A  |-----| B  |-----  No Route
               /     +----+     +----+
              /        |    \     |
             X         |     \    |
              \        |      \   |
               \     +----+     +----+
              T3-----| D  |-----| C  |-----   X D
                     +----+     +----+
                      X          X D
                      X A



>b. Regardless of the answer, the router should announce the route it is
>   using for its own forwarding.  To do otherwise would be to lie about
>   the path which traffic will take to the advertised destination.
>
>   If policy forbids it from announcing the route it is using, so be
>   it.  (Or, if that's not acceptable change the policy.)

Policy is a business decision, not a technical decision.

You can be unfair to C by congesting the line XA. Or you can be unfair
to B by announcing a longer path XDAB, or no path.  Who do you care more
about B or C?  All animals are equal, but some animals are more equal
than others.

Yes, you might be able to play enough games with this simple example, to
force things to work 'right.'  But the mesh is being extended all the time.

>By the way, this general fact about BGP (external announcements are
>governed by internal route selection) also means that for Randy to
>always announce the same route to his peer, he would have to change his
>own, internal routing policy to do cold-potato routing to one of the
>two candidate paths.  This doesn't seem like a reasonable thing for a
>peer to demand he do.

In any business negotiation, either side can demand whatever they want.
But the other side doesn't have to give it to them.  This really isn't
an operational issue, other than the engineers need to keep their managers
informed of the consequences of managerial decisions.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation





From hank at rem.com  Thu Mar 13 20:16:04 1997
From: hank at rem.com (Henry Kilmer)
Date: Thu, 13 Mar 1997 15:16:04 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <CMM.0.90.2.858282274.vaf@valinor.barrnet.net>
References: <CMM.0.90.2.858282274.vaf@valinor.barrnet.net>
Message-ID: <199703132016.PAA21783@crazy.rem.com>


Vince Fuller writes:
>Hmm. Do you treat the customer routes received from the other peer to be
>"customer" routes, i.e. will you provide transit for them and re-advertise

Yes.

>them to your interconnect peers? If not, then you'll prevent interconnect
>peers from using shortest-exit to get to those customer routes, which may
>be considered a problem by those peers.

Agreed.

-Hank




From pjc at off-road.com  Thu Mar 13 21:04:16 1997
From: pjc at off-road.com (Patrick J. Chicas)
Date: Thu, 13 Mar 1997 11:04:16 -1000 (HST)
Subject: Need Solid Sprintlink Contact
Message-ID: <Pine.LNX.3.95.970313104715.10554K-100000@unix.off-road.com>


Greetings All,

In one of my current lives, we have a need to establish peering
connectivity with Sprintlink at their Anahiem POP. 

I am looking for a solid Sprintlink Sales Engineer that can help.
Please, pass on your recommendations.

Regards

Patrick J. Chicas





From djls at gate.net  Thu Mar 13 20:55:05 1997
From: djls at gate.net (David Schwartz)
Date: Thu, 13 Mar 1997 15:55:05 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <199703131942.OAA18533@crazy.rem.com>
Message-ID: <Pine.LNX.3.91.970313155219.8843B-100000@davids.wiznet.net>


	Consider the case where a customer has two AS numbers and uses one
for his East Coast operations and one for his West Coast operations. 
Since he only purchases transit, he can use his Internet connections to
back up his coast-to-coast link, which he normally prefers. Suppose he has
connections to a particular backbone on both coasts and wishes nearest
exit to be used. 

	At MAE-E, this backbone will prefer the East Coast AS to reach 
his IPs. At MAE-W, this backbone will prefer the West Caost AS to reach 
his IPs. The BGP advertisements this backbone will make to its peers will 
be 'inconsistent' but also 'optimal'.

	DS

On Thu, 13 Mar 1997, Henry Kilmer wrote:

> 
> Vince Fuller writes:
> >I can see why you present inconsistant routes to us but I'm not sure that I
> >understand why you'd prefer a customer prefix via a direct connection to them
> >at one point in your network but via a connection to another provider at a
> >different point in your network. That would seem internally inconsistant to
> >me. Is this deliberate behavior to do shortest-exit within your network toward
> >your customer?
> 
> We have some customers that have specifically requested this sort of arrangement.
> 
> -Hank
> 
> 




From djls at gate.net  Thu Mar 13 21:00:41 1997
From: djls at gate.net (David Schwartz)
Date: Thu, 13 Mar 1997 16:00:41 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <CMM.0.90.2.858282145.vaf@valinor.barrnet.net>
Message-ID: <Pine.LNX.3.91.970313155550.8843C-100000@davids.wiznet.net>


On Thu, 13 Mar 1997, Vince Fuller wrote:

> What we are seeing, though, is "R A M" at Point1 and nothing at Point2, likely
> because Randy doesn't consider "R B M", received from one of his peers, to be
> a customer route.

	Ahh, now that's another story. That is something it is reasonable
for a peer to object to. If you are going to advertise a route to a block
at one peering point, you should be advertising a route to that block at 
all peering points and with the same AS length.

	It is not consistent policy to route to a customer through both
another customer and a non-customer. That's what you can't do. 
Alternatively, if you do decide you must accept routes to a customer from
a non-customer, you must consider those routes to be customer routes. 

	Agree? Disagree?

	DS




From jgs at ieng.com  Thu Mar 13 21:41:41 1997
From: jgs at ieng.com (John G. Scudder)
Date: Thu, 13 Mar 1997 16:41:41 -0500
Subject: consistent policy != consistent announcements
In-Reply-To: <CMM.0.90.2.858281493.vaf@valinor.barrnet.net>
References: Your message of Thu, 13 Mar 1997 10:46:06 -0500 (EST)
Message-ID: <v03101919af4e08805b01@[152.160.213.42]>

At 11:31 AM -0800 3/13/97, Vince Fuller wrote:
>Well, if that "candidate path" is, in fact, one of Randy's customer, then
>I would expect him to "cold-potato" route toward it.  One would think that
>to be part of the service that his customer is purchasing.

I think that his internal routing policy and service to his customer is
really irrelevant to the question at hand, except insofar as its
side-effects affect you.

>I certainly
>shouldn't have to do "cold-potato" routing to his customer, as that customer
>isn't purchasing anything from me.

Ah, I finally see the problem.  In essence, Randy's (announcement) policy
assumes that a destination is either in the set of customer routes OR the
set of peer routes, but not both.  But in this case we have a destination
which is in both.  The side-effect ends up making you "cold-potato" route
to destinatons in the (customer + peer) intersection.

The question is, does it make sense for a destination to be considered to
be in both sets?  If "peer" is supposed to mean "not-customer" then the
answer is probably no, there is (should be) no intersection between
"customer" and "not-customer".

If this is right, the problem is that sometimes the AS path is an overly
blunt instrument to determine the customer-ness of a route.

In the case where using the AS path doesn't allow the route to be
categorized correctly, the only way *I* can see of fixing it is using
manual policy (sorry).  Presumably this could be done with a minimum of
pain by something like (assumes M should properly be categorized as
"customer"):

	(at router peering with customer C in Randy's example):
	write "customer" community onto all routes from C

	(at router peering with peer P in Randy's example):
	write "customer" community onto all routes from (P M)
	write "peer" community onto all other routes from P

	(at routers sending routes to external neighbors)
	send routes with "customer" community to all peer routers
	send routes with "peer" community to all customer routers
	send routes with "customer" community to all customer routers

The special-casing is limited to the guy who peers with P, who has to
decide to write "customer" onto (P M) routes.

Presumably one could (semi) automatically detect when a new special case is
needed by gathering routing table snapshots from border routers from time
to time, and finding routes which are colored inconsistently (identical
destinations, different communities).

Regards,

--John

--
John Scudder                        email:  jgs at ieng.com
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com






From doshea at mail.wiltel.net  Fri Mar 14 00:15:41 1997
From: doshea at mail.wiltel.net (Dave O'Shea)
Date: Thu, 13 Mar 1997 18:15:41 -0600
Subject: Blacklist of spammers?
Message-ID: <01BC2FDA.912183C0@splatter.wilcom.com>

Not to start another "discussion" of mailspamming again, but I seem to recall that someone out here has a BGP update containing known spammers. Having had to update my &^% router twice today to block induhvidual spammers, I don't mind throwing my hands up in disgust.






From alex at nac.net  Fri Mar 14 00:38:25 1997
From: alex at nac.net (Alex Rubenstein)
Date: Thu, 13 Mar 1997 20:38:25 -0400
Subject: Remote Operations question
Message-ID: <3.0.32.19970313194514.00a7d5a0@mail.nac.net>


Any thoughts on the peering question?

At 06:09 PM 3/8/97 -0700, Rodney Joffe wrote:
>Thanks Alex......
>
>As far as why........   well let's see; when the router gets hosed in
>our cage, and we open a ticket with MFS, and it takes 5 hours before
>they arrive..... it seems a lot more logical to be able to power cycle
>it out of band without waiting. Now if MFS's facility was truly a 24 x 7
>facility, which you would expect for a place that was that important :-)
>By the way, your $500 is much less than the last bill they sent us ...
>$750.
>
>Amazing... and we didn't even see the gun in their hands.
>
>Rodney Joffe
>Genuity Inc., a Bechtel company
>http://www.genuity.net
>
>
>>-----Original Message-----
>>From:	Alex Rubenstein [SMTP:alex at nac.net]
>>Sent:	Saturday, March 08, 1997 4:22 PM
>>To:	Rodney Joffe; 'nanog at merit.edu'
>>Subject:	Re: Remote Operations question
>>
>>
>>Leviton has some stuff the we use, they have some things that can do 20
amps.
>>
>>The better question; why? What is the 7513 doing that you need it to be
>>rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-)
>>
>>
>>At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote:
>>>Is anyone using any kind of out of band controlled power system that
>>>will support remote power cycling of multiple devices with high power
>>>ratings? I'd like to be able to cycle individual components in our racks
>>>at NAPs (especially MAE E!) including 7513s.  All the devices we've
>>>found are limited to 15 amps total. I think a 7513 requires 20amps on
>>>its own.
>>>
>>>Thanks
>>>
>>>Rodney Joffe
>>>Genuity Inc., a Bechtel company
>>>http://www.genuity.net
>>>
>>>
>>>
>




From owen at DeLong.SJ.CA.US  Fri Mar 14 02:25:17 1997
From: owen at DeLong.SJ.CA.US (Owen DeLong)
Date: Thu, 13 Mar 1997 18:25:17 -0800
Subject: Remote Operations question
Message-ID: <199703140225.SAA15956@dixon.DeLong.SJ.CA.US>


FWIW, Crestron has some goodies that will do the trick (20 Amps) at about
$80/port + controller (per site).  We're trying to get them to add some
voice-response DTMF control capability.  Might be good to call them and
tell them you're an ISP that would be interested in what ConXioN has been
asking for.  Might help to convince them there's a market for it.

Their specialty is remote control for theater/auditorium lighting and audio/
visual stuff, but their solution looks pretty keen.  They're really close
to exactly what I'd want.

Owen

> Any thoughts on the peering question?
> 
> At 06:09 PM 3/8/97 -0700, Rodney Joffe wrote:
> >Thanks Alex......
> >
> >As far as why........   well let's see; when the router gets hosed in
> >our cage, and we open a ticket with MFS, and it takes 5 hours before
> >they arrive..... it seems a lot more logical to be able to power cycle
> >it out of band without waiting. Now if MFS's facility was truly a 24 x 7
> >facility, which you would expect for a place that was that important :-)
> >By the way, your $500 is much less than the last bill they sent us ...
> >$750.
> >
> >Amazing... and we didn't even see the gun in their hands.
> >
> >Rodney Joffe
> >Genuity Inc., a Bechtel company
> >http://www.genuity.net
> >
> >
> >>-----Original Message-----
> >>From:	Alex Rubenstein [SMTP:alex at nac.net]
> >>Sent:	Saturday, March 08, 1997 4:22 PM
> >>To:	Rodney Joffe; 'nanog at merit.edu'
> >>Subject:	Re: Remote Operations question
> >>
> >>
> >>Leviton has some stuff the we use, they have some things that can do 20
> amps.
> >>
> >>The better question; why? What is the 7513 doing that you need it to be
> >>rebooted? I can be paid to go do it for you; lets say, $500 ea time? :-)
> >>
> >>
> >>At 04:18 PM 3/8/97 -0700, Rodney Joffe wrote:
> >>>Is anyone using any kind of out of band controlled power system that
> >>>will support remote power cycling of multiple devices with high power
> >>>ratings? I'd like to be able to cycle individual components in our racks
> >>>at NAPs (especially MAE E!) including 7513s.  All the devices we've
> >>>found are limited to 15 amps total. I think a 7513 requires 20amps on
> >>>its own.
> >>>
> >>>Thanks
> >>>
> >>>Rodney Joffe
> >>>Genuity Inc., a Bechtel company
> >>>http://www.genuity.net
> >>>
> >>>
> >>>
> >
> 




From vaf at valinor.barrnet.net  Fri Mar 14 03:13:42 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Thu, 13 Mar 97 19:13:42 PST
Subject: consistent policy != consistent announcements
In-Reply-To: Your message of Thu, 13 Mar 1997 16:41:41 -0500
Message-ID: <CMM.0.90.2.858309222.vaf@valinor.barrnet.net>

    At 11:31 AM -0800 3/13/97, Vince Fuller wrote:
    >Well, if that "candidate path" is, in fact, one of Randy's customer, then
    >I would expect him to "cold-potato" route toward it.  One would think that
    >to be part of the service that his customer is purchasing.

    I think that his internal routing policy and service to his customer is
    really irrelevant to the question at hand, except insofar as its
    side-effects affect you.

Yup, it isn't my business to care about his internal routing, just to insure
that he presents appropriate routing to me (i.e. I care about the functional
specification not the design details...)

I was merely speculating, perhaps incorrectly, on what might be going wrong
so that I don't see what I consider consistant routes.

    Ah, I finally see the problem.  In essence, Randy's (announcement) policy
    assumes that a destination is either in the set of customer routes OR the
    set of peer routes, but not both.  But in this case we have a destination
    which is in both.  The side-effect ends up making you "cold-potato" route
    to destinatons in the (customer + peer) intersection.

    The question is, does it make sense for a destination to be considered to
    be in both sets?  If "peer" is supposed to mean "not-customer" then the
    answer is probably no, there is (should be) no intersection between
    "customer" and "not-customer".

See your objection above - I really don't care how the routes are handled
internally to Randy's net; I just want to see routes for the same prefixes
with equal preference (as path length, origin, etc.) at all interconnects.

	--Vince




From oberman at es.net  Fri Mar 14 03:16:57 1997
From: oberman at es.net (Kevin Oberman)
Date: Thu, 13 Mar 97 19:16:57 -0800
Subject: Blacklist of spammers? 
In-Reply-To: Your message of "Thu, 13 Mar 97 18:15:41 CST."
             <01BC2FDA.912183C0@splatter.wilcom.com> 
Message-ID: <9703140316.AA24653@ptavv.es.net>

See http://www.vix.com/spam/
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634






From paul at vix.com  Fri Mar 14 03:33:39 1997
From: paul at vix.com (Paul A Vixie)
Date: Thu, 13 Mar 1997 19:33:39 -0800
Subject: Blacklist of spammers? 
In-Reply-To: Your message of "Thu, 13 Mar 1997 19:16:57 PST."
             <9703140316.AA24653@ptavv.es.net> 
Message-ID: <199703140333.TAA22632@wisdom.home.vix.com>

> See http://www.vix.com/spam/

With all due respect, yes, please do look at the above page since it contains
the best information I know of for how to promote responsible internet
commerce.  However, the blackhole list (not blacklist) is not described
there since that's Scott Mueller's page and the blackhole list is my personal
project.

If you want a real time BGP4 feed of nets that I personally blackhole on my
own exit gateway, along with instructions on how to set up Cisco route-maps
so that you blackhole these nets locally (rather than sending them to me),
then send me some e-mail and ask.  There's an indemnification agreement that
you and your management have to sign, and the blackhole feed is free.




From apb at iafrica.com  Fri Mar 14 07:51:27 1997
From: apb at iafrica.com (Alan Barrett)
Date: Fri, 14 Mar 1997 09:51:27 +0200 (GMT+0200)
Subject: consistent policy != consistent announcements
In-Reply-To: <Pine.LNX.3.91.970313155550.8843C-100000@davids.wiznet.net>
Message-ID: <Pine.NEB.3.95.970314090504.162U-100000@apb.iafrica.com>

The topology we are discussing:

                    M
                  /   \
                 A     B      * Peer link
                 |     *      | Customer link
                 RRRRRRR
          Point1 *     * Point2
                 VVVVVVV

  Vince Fuller said:
> > What we are seeing, though, is "R A M" at Point1 and nothing at
> > Point2, likely because Randy doesn't consider "R B M", received from
> > one of his peers, to be a customer route.

I suppose that R should change their policy, so that all routes to M get
treated as customer routes, even if non-customers appear in the path
between R and M.  Then R would announce "R A M" to V at Point1, and
would announce "R B M" to V at Point2, and V would be happy.

But if A and B have other providers (P, Q), or if B peers with V, then
V is likely to see some non-zero number of paths like "P A M", "P B M",
"Q A M", "Q B M" or "B M" at or near Point2, and so V will not actually
have to carry M's traffic all the way from Point2 to Point1.  In this
case, V should be happy despite R's failure to announce "R B M" at
Point2.

David Schwartz said:
>       It is not consistent policy to route to a customer through both
> another customer and a non-customer. That's what you can't do.

M might very well have requested R to consider the paths "R A M" and "R
B M" to be equally good, and M doesn't care that A is a customer of R
but B is not a customer of R.  It's perfectly reasonable for R to accede
to M's wishes in this regard.

> Alternatively, if you do decide you must accept routes to a customer
> from a non-customer, you must consider those routes to be customer
> routes.

Agree.

--apb (Alan Barrett)





From randy at psg.com  Fri Mar 14 15:59:00 1997
From: randy at psg.com (Randy Bush)
Date: Fri, 14 Mar 97 07:59 PST
Subject: consistent policy != consistent announcements
References: <Pine.LNX.3.91.970313155550.8843C-100000@davids.wiznet.net>
	<Pine.NEB.3.95.970314090504.162U-100000@apb.iafrica.com>
Message-ID: <m0w5ZNn-0007zbC@rip.psg.com>

>                     M
>                   /   \
>                  A     B      * Peer link
>                  |     *      | Customer link
>                  RRRRRRR
>           Point1 *     * Point2
>                  VVVVVVV
> 
> I suppose that R should change their policy, so that all routes to M get
> treated as customer routes, even if non-customers appear in the path
> between R and M.

How is R supposed to recognize some likely disjoint set of of what A
announces to R as coming from M through B so as to recognize it as a
customer prefix?  Note that the paths from M to R through A and B can
be longer than depicted and that M's address space may not be taken
from R's, A's, or B's.

randy




From apb at iafrica.com  Fri Mar 14 16:57:51 1997
From: apb at iafrica.com (Alan Barrett)
Date: Fri, 14 Mar 1997 18:57:51 +0200 (GMT+0200)
Subject: consistent policy != consistent announcements
In-Reply-To: <m0w5ZNn-0007zbC@rip.psg.com>
Message-ID: <Pine.NEB.3.95.970314182414.162i-100000@apb.iafrica.com>

> >                     M
> >                   /   \
> >                  A     B      * Peer link
> >                  |     *      | Customer link
> >                  RRRRRRR
> >           Point1 *     * Point2
> >                  VVVVVVV

> How is R supposed to recognize some likely disjoint set of of what A
> announces to R as coming from M through B so as to recognize it as a
> customer prefix?  Note that the paths from M to R through A and B can
> be longer than depicted and that M's address space may not be taken
> from R's, A's, or B's.

R could request A to provide it with a list of ASes for indirect
customers behind A.  (R probably already does that.)  That would be
sufficient information for R's router at the R/B interconnection to tag
M's routes as customer routes.  Essentially, when R's router at the R/B
interconnection receives a route with path "B M", it could use the fact
"M is an indirect customer" rather than "B is a non-customer" to tag the
route appropriately.

Alternatively, R could make the decision using prefixes rather than AS
numbers, and could make it at the R/V[Point2] outbound announcement
point rather than at the B/R inbound announcement point.

--apb (Alan Barrett)





From djls at gate.net  Fri Mar 14 17:19:44 1997
From: djls at gate.net (David Schwartz)
Date: Fri, 14 Mar 1997 12:19:44 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <Pine.NEB.3.95.970314090504.162U-100000@apb.iafrica.com>
Message-ID: <Pine.LNX.3.91.970314121724.9403C-100000@davids.wiznet.net>


On Fri, 14 Mar 1997, Alan Barrett wrote:

> The topology we are discussing:
> 
>                     M
>                   /   \
>                  A     B      * Peer link
>                  |     *      | Customer link
>                  RRRRRRR
>           Point1 *     * Point2
>                  VVVVVVV
> 
> M might very well have requested R to consider the paths "R A M" and "R
> B M" to be equally good, and M doesn't care that A is a customer of R
> but B is not a customer of R.  It's perfectly reasonable for R to accede
> to M's wishes in this regard.

	M and A have no direct relationship in this picture so I don't 
see why M would be making requests to R. R should normally be preferring 
customer links to peer links.

	I think it's reasonable of V to demand that if R wishes to treat 
M in such an unusual way, R consider all of M's routes customer routes. 
Otherwise R cannot present a consistent picture to V because R's policy 
is not consistent (preferring a customer route on one side and a peer 
route on the other).

	DS





From jgs at ieng.com  Fri Mar 14 17:14:44 1997
From: jgs at ieng.com (John Scudder)
Date: Fri, 14 Mar 1997 12:14:44 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <Pine.NEB.3.95.970314182414.162i-100000@apb.iafrica.com> from "Alan Barrett" at Mar 14, 97 06:57:51 pm
Message-ID: <199703141714.MAA00886@ieng.com>

> > >                     M
> > >                   /   \
> > >                  A     B      * Peer link
> > >                  |     *      | Customer link
> > >                  RRRRRRR
> > >           Point1 *     * Point2
> > >                  VVVVVVV
[...]
> R could request A to provide it with a list of ASes for indirect
> customers behind A.  (R probably already does that.)  That would be
> sufficient information for R's router at the R/B interconnection to tag
> M's routes as customer routes.  Essentially, when R's router at the R/B
> interconnection receives a route with path "B M", it could use the fact
> "M is an indirect customer" rather than "B is a non-customer" to tag the
> route appropriately.

Furthermore, R could provide sufficient incentive for A to provide a
list of indirect customers by accepting only registered routes (or AS
paths).  (This should sound familiar.)  E.g. (A) and (A M) routes would
be accepted but all other (A *) would not be in this example.

Alternately, R could audit routing tables at Point1 and Point2 from
time to time, as I mentioned earlier.  It ought to be rather simple to
find routes which are in Point1 as "exportable" and Point 2 as
"non-exportable", or vice-versa.  The rest follows.

Regards,

--John




From jyy at ans.net  Fri Mar 14 17:48:49 1997
From: jyy at ans.net (Jessica Yu)
Date: Fri, 14 Mar 1997 12:48:49 -0500
Subject: consistent policy != consistent announcements
Message-ID: <199703141748.MAA27678@cannes.aa.ans.net>


If a provider/AS does not have the policy of dumping hot potatos to other 
peers for the traffic to its customers who happen to multihome to those peers.
Then there is a simple way to do it.  They can have policy of always favor 
its own customer routes over the routes learned from other peers.  This will 
avoid the inconsistent announcement by eliminating the cases that some part 
of the AS favors routes M from it's customer and other part favors M from 
another peer, thus announce consistent routes to other peers.   

It's very easy to manage this policy.  Just assign lower (less favored)  
local_pref to routes learned from peers than those learned from customers.
It's AS based.  By using the default local_pref value, one only need to
assign a lower than default local_pref value to the peer AS at border routers.
 
A good side effect of this policy is that your customers routes will be 
protected from being blackingholed from careless ISPs leaking/advertising your 
customers routes but have no way to reach them.
							--Jessica 

 
------- Forwarded Message

Return-Path: owner-nanog at merit.edu 
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by cannes.aa.ans.net (8.8.5/8.8.3) with SMTP id QAA24798 for <jyy at cannes.aa.ans.net>; Thu, 13 Mar 1997 16:58:11 -0500 (EST)
Received: by interlock.ans.net id AA25369
  (InterLock SMTP Gateway 3.0 for regional-techsers at ans.net);
  Thu, 13 Mar 1997 16:57:00 -0500
Received: by interlock.ans.net (Internal Mail Agent-5);
  Thu, 13 Mar 1997 16:57:00 -0500
Received: by interlock.ans.net (Internal Mail Agent-4);
  Thu, 13 Mar 1997 16:57:00 -0500
Received: by interlock.ans.net (Internal Mail Agent-3);
  Thu, 13 Mar 1997 16:57:00 -0500
Received: by interlock.ans.net (Internal Mail Agent-2);
  Thu, 13 Mar 1997 16:57:00 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
  Thu, 13 Mar 1997 16:57:00 -0500
Message-Id: <v03101919af4e08805b01@[152.160.213.42]>
In-Reply-To: <CMM.0.90.2.858281493.vaf at valinor.barrnet.net>
References: Your message of Thu, 13 Mar 1997 10:46:06 -0500 (EST)
Mime-Version: 1.0
Date: Thu, 13 Mar 1997 16:41:41 -0500
To: Vince Fuller <vaf at valinor.barrnet.net>
From: "John G. Scudder" <jgs at ieng.com>
Subject: Re: consistent policy != consistent announcements
Cc: Sean Donelan <SEAN at sdg.dra.com>, nanog at merit.edu
Sender: owner-nanog at merit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Length: 2715

At 11:31 AM -0800 3/13/97, Vince Fuller wrote:
>Well, if that "candidate path" is, in fact, one of Randy's customer, then
>I would expect him to "cold-potato" route toward it.  One would think that
>to be part of the service that his customer is purchasing.

I think that his internal routing policy and service to his customer is
really irrelevant to the question at hand, except insofar as its
side-effects affect you.

>I certainly
>shouldn't have to do "cold-potato" routing to his customer, as that customer
>isn't purchasing anything from me.

Ah, I finally see the problem.  In essence, Randy's (announcement) policy
assumes that a destination is either in the set of customer routes OR the
set of peer routes, but not both.  But in this case we have a destination
which is in both.  The side-effect ends up making you "cold-potato" route
to destinatons in the (customer + peer) intersection.

The question is, does it make sense for a destination to be considered to
be in both sets?  If "peer" is supposed to mean "not-customer" then the
answer is probably no, there is (should be) no intersection between
"customer" and "not-customer".

If this is right, the problem is that sometimes the AS path is an overly
blunt instrument to determine the customer-ness of a route.

In the case where using the AS path doesn't allow the route to be
categorized correctly, the only way *I* can see of fixing it is using
manual policy (sorry).  Presumably this could be done with a minimum of
pain by something like (assumes M should properly be categorized as
"customer"):

	(at router peering with customer C in Randy's example):
	write "customer" community onto all routes from C

	(at router peering with peer P in Randy's example):
	write "customer" community onto all routes from (P M)
	write "peer" community onto all other routes from P

	(at routers sending routes to external neighbors)
	send routes with "customer" community to all peer routers
	send routes with "peer" community to all customer routers
	send routes with "customer" community to all customer routers

The special-casing is limited to the guy who peers with P, who has to
decide to write "customer" onto (P M) routes.

Presumably one could (semi) automatically detect when a new special case is
needed by gathering routing table snapshots from border routers from time
to time, and finding routes which are colored inconsistently (identical
destinations, different communities).

Regards,

- --John

- --
John Scudder                        email:  jgs at ieng.com
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com



------- End of Forwarded Message





From jyy at ans.net  Fri Mar 14 21:53:34 1997
From: jyy at ans.net (Jessica Yu)
Date: Fri, 14 Mar 1997 16:53:34 -0500
Subject: consistent policy != consistent announcements 
In-Reply-To: Your message of "Fri, 14 Mar 1997 12:48:49 EST."
             <199703141748.MAA27678@cannes.aa.ans.net> 
Message-ID: <199703142153.QAA28513@cannes.aa.ans.net>

Excuse me for responding myself here.  Just like to clarify my previous 
message a bit. 

The note below does not intend to solve Randy's problem for his chosen
policy.  It rather intends to describe a different policy used by many 
ISPs which won't run into the same problem.  
 
IMO, ISPs who are engaging in the 'hot potato' routing practice have the 
obligation to announce consistent routes to its peers at different peering
points.  It may require an ISP to change it's internal policy to achive 
this with reasonable maintance work (like the one described below) or to
excercise whatever internal policy it decide but do more work (configuration
management,etc) to fulfill the obligation.
 
                                                 --Jessica
                                                   speaking for myself. 
 
Date:    Fri, 14 Mar 1997 12:48:49 EST
To:      jgs at ieng.com
cc:      vaf at valinor.barrnet.net, Sean Donelan <SEAN at sdg.dra.com>, nanog at merit.
     ***edu
 
From:    Jessica Yu <jyy at ans.net>
Subject: Re: consistent policy != consistent announcements
 
Return-Path: owner-nanog at merit.edu 
Sender:  owner-nanog at merit.edu
Content-Type: text
Content-Length: 5173
 
 
If a provider/AS does not have the policy of dumping hot potatos to other 
peers for the traffic to its customers who happen to multihome to those peers.
Then there is a simple way to do it.  They can have policy of always favor 
its own customer routes over the routes learned from other peers.  This will 
avoid the inconsistent announcement by eliminating the cases that some part 
of the AS favors routes M from it's customer and other part favors M from 
another peer, thus announce consistent routes to other peers.   
 
It's very easy to manage this policy.  Just assign lower (less favored)  
local_pref to routes learned from peers than those learned from customers.
It's AS based.  By using the default local_pref value, one only need to
assign a lower than default local_pref value to the peer AS at border routers.
 
A good side effect of this policy is that your customers routes will be 
protected from being blackingholed from careless ISPs leaking/advertising your 
customers routes but have no way to reach them.
                                                        --Jessica 
 
 





From amb at xara.net  Fri Mar 14 22:22:57 1997
From: amb at xara.net (Alex.Bligh)
Date: Fri, 14 Mar 1997 22:22:57 +0000
Subject: consistent policy != consistent announcements 
In-Reply-To: Your message of "Fri, 14 Mar 1997 16:53:34 EST."
             <199703142153.QAA28513@cannes.aa.ans.net> 
Message-ID: <199703142222.WAA27836@diamond.xara.net>

> IMO, ISPs who are engaging in the 'hot potato' routing practice have the 
> obligation to announce consistent routes to its peers at different peering
> points.  It may require an ISP to change it's internal policy to achive 
> this with reasonable maintance work (like the one described below) or to
> excercise whatever internal policy it decide but do more work (configuration
> management,etc) to fulfill the obligation.

Peers get announced customer routes. In broad brush-strokes, if you
don't consistently prefer customer routes over peer routes, and don't
reannounce peer routes, you are bound to announce routes inconsistently.
If you do reannounce peer routes, you get into all sorts of possible
messiness (see below). This much is presumably obvious.

Is there any *customer-led* reason why one might not want to prefer customer
routes over peer routes? (i.e. not "it saves me doing some backhaul as
I can dump the traffic off to the customers other provider").

If we and X (my peer) both transit Y, I would complain if X didn't prefer
customer routes over my (peer) routes. Internally-to-X generated traffic
(news being an obvious example) or other X-customer traffic which gets into
X's network near a peering point far from where X provides transit to Y,
I get to do backhaul for. Not nice, not only from a traffic point of
view but also a debugging one. Also makes asymmetry worse.

I'd also complain if X started announcing routes like <us> <Y>. Mainly
from bitter experience where incompetents announced routes like that
then blackholed the traffic.

So I'd be interested to know why the customer might prefer anything other
than "prefer customer routes over peer routes".

Alex Bligh
Xara Networks






From rusty at mci.net  Sat Mar 15 00:37:01 1997
From: rusty at mci.net (Rusty Zickefoose)
Date: Fri, 14 Mar 1997 19:37:01 -0500
Subject: consistent policy != consistent announcements 
In-Reply-To: Your message of "Fri, 14 Mar 1997 22:22:57 GMT."
             <199703142222.WAA27836@diamond.xara.net> 
Message-ID: <199703150038.TAA21150@iridium.cary.mci.net>

Alex,
	I haven't seen all of the email on this subject, so forgive me if this was all ready mentioned or if it "goes with out saying" but one faily common case would be when a multi-homed customer prefers on provider as primary and the other/s as a backup.  The primary provider would prefer customer announced routes over that of any peers, while the backup providers would set there preferences to normal customers at highest, then peers, and then the customer designated backup at lowest priority.


-- 
Rusty

> > IMO, ISPs who are engaging in the 'hot potato' routing practice have the 
> > obligation to announce consistent routes to its peers at different peering
> > points.  It may require an ISP to change it's internal policy to achive 
> > this with reasonable maintance work (like the one described below) or to
> > excercise whatever internal policy it decide but do more work (configuration
> > management,etc) to fulfill the obligation.
> 
> Peers get announced customer routes. In broad brush-strokes, if you
> don't consistently prefer customer routes over peer routes, and don't
> reannounce peer routes, you are bound to announce routes inconsistently.
> If you do reannounce peer routes, you get into all sorts of possible
> messiness (see below). This much is presumably obvious.
> 
> Is there any *customer-led* reason why one might not want to prefer customer
> routes over peer routes? (i.e. not "it saves me doing some backhaul as
> I can dump the traffic off to the customers other provider").
> 
> If we and X (my peer) both transit Y, I would complain if X didn't prefer
> customer routes over my (peer) routes. Internally-to-X generated traffic
> (news being an obvious example) or other X-customer traffic which gets into
> X's network near a peering point far from where X provides transit to Y,
> I get to do backhaul for. Not nice, not only from a traffic point of
> view but also a debugging one. Also makes asymmetry worse.
> 
> I'd also complain if X started announcing routes like <us> <Y>. Mainly
> from bitter experience where incompetents announced routes like that
> then blackholed the traffic.
> 
> So I'd be interested to know why the customer might prefer anything other
> than "prefer customer routes over peer routes".
> 
> Alex Bligh
> Xara Networks
> 
> 






From amb at xara.net  Sat Mar 15 00:53:59 1997
From: amb at xara.net (Alex.Bligh)
Date: Sat, 15 Mar 1997 00:53:59 +0000
Subject: consistent policy != consistent announcements 
In-Reply-To: Your message of "Fri, 14 Mar 1997 19:37:01 EST."
             <199703150038.TAA21150@iridium.cary.mci.net> 
Message-ID: <199703150053.AAA04281@diamond.xara.net>

> Alex,
> 	I haven't seen all of the email on this subject, so forgive me
> if this was all ready mentioned or if it "goes with out saying" but one
> faily common case would be when a multi-homed customer prefers on provider
> as primary and the other/s as a backup.  The primary provider would prefer
> customer announced routes over that of any peers, while the backup providers
> would set there preferences to normal customers at highest, then peers, and
> then the customer designated backup at lowest priority.

Absolutely. But then while primary is still up one would assume the (primary)
peer routes are preferred throughout the network of the backup provider
so it won't be announing anything anywhere (so nothing announced would
be inconsistent). I guess what I meant was "is there any case where a
customer would want a provider to prefer customer routes in some parts
of the provider net and peer routes elsewhere?".

To answer my own question:

One possible scenario for the above is if the customer had their own high
capacity ungongested East to West link, but couldn't get peering. Instead
the customer takes connectivity from two large providers, A and B, one
on the East and one on the West. As the large providers' backbones are
congested, the customer elects to do their own backhaul (may be they
are a content provider style customer and most of the high volume
traffic is outbound and handed off hot-potato). So if A and B have peer
routes which are a substantial % of the internet, and the A link is
West coast and the B East coast, the customer may prefer to get traffic
from A's East coast customers through B, rather than suffer a congested
backhaul through A. And vice-versa.

However I'd have thought the above scenario was relatively rare.

Alex Bligh
Xara Networks






From apb at iafrica.com  Sat Mar 15 11:22:02 1997
From: apb at iafrica.com (Alan Barrett)
Date: Sat, 15 Mar 1997 13:22:02 +0200 (GMT+0200)
Subject: consistent policy != consistent announcements 
In-Reply-To: <199703142222.WAA27836@diamond.xara.net>
Message-ID: <Pine.NEB.3.95.970315130455.162t-100000@apb.iafrica.com>

> Is there any *customer-led* reason why one might not want to prefer
> customer routes over peer routes? (i.e. not "it saves me doing some
> backhaul as I can dump the traffic off to the customers other
> provider"). 

Yes.  Suppose that I am "M", and I have two providers "A" and "B".  The
links M/A and M/B are expensive international links, much lower bandwidth
than I would like, and prone to congestion.  Further suppose that A is a
customer of R, and B is a peer of R.  For load balancing reasons, I would
like R to send some of my traffic via A and some via B.  Since I pay A and
B for transit, and A pays R for transit, and A and B both agree to play
along with my desire to load balance, it's reasonable for us to ask R to
do this.  From R's point of view, their customer A and their indirect
customer M have asked them to treat peer routes (via B) and customer
routes (via A) to destinations in M as being equivalent.

--apb (Alan Barrett)





From jhawk at bbnplanet.com  Sat Mar 15 16:14:32 1997
From: jhawk at bbnplanet.com (John Hawkinson)
Date: Sat, 15 Mar 1997 11:14:32 -0500 (EST)
Subject: consistent policy != consistent announcements
In-Reply-To: <Pine.NEB.3.95.970315130455.162t-100000@apb.iafrica.com> from "Alan Barrett" at Mar 15, 97 01:22:02 pm
Message-ID: <199703151614.LAA25401@all-purpose-gunk.near.net>

> Yes.  Suppose that I am "M", and I have two providers "A" and "B".  The
> links M/A and M/B are expensive international links, much lower bandwidth
> than I would like, and prone to congestion.  Further suppose that A is a
> customer of R, and B is a peer of R.  For load balancing reasons, I would
> like R to send some of my traffic via A and some via B.  Since I pay A and
> B for transit, and A pays R for transit, and A and B both agree to play
> along with my desire to load balance, it's reasonable for us to ask R to
> do this.

> From R's point of view, their customer A and their indirect customer
> M have asked them to treat peer routes (via B) and customer routes
> (via A) to destinations in M as being equivalent.

This is just plain difficult to orchestrate, if one asks R to treat
some subset of peer routes as transit routes.

Far better to adopt the reverse solution of having R de-preference
the routes received from A to be an equivalent localperf to those
received from B. That is, give special treatment to a subset of
customer roues, and continue to treat all peer routes the same.

RFC1998 provides a very nice example of this, as implemented by
one provider (MCI).

Nevertheless, this is not a panacea.

Peers of R may still receive routes with different as-paths, but
as-path lengths and origin codes (which matter for selection) should
at least be the same, which should be sufficient.

--jhawk




From danny at genuity.net  Sun Mar 16 07:15:09 1997
From: danny at genuity.net (Danny McPherson)
Date: Sun, 16 Mar 1997 00:15:09 -0700
Subject: consistent policy != consistent announcements 
Message-ID: <199703160715.AAA02006@genbsd.genuity.net>


> Peers of R may still receive routes with different as-paths, but
> as-path lengths and origin codes (which matter for selection) should
> at least be the same

for the most part, ever do a "sh ip bgp inconsistant-as" in a cisco?

-danny






From hank at ibm.net.il  Sun Mar 16 11:59:10 1997
From: hank at ibm.net.il (Hank Nussbacher)
Date: Sun, 16 Mar 1997 13:59:10 +0200
Subject: Information Week article
Message-ID: <2.2.16.19970316115910.5927756a@rex.ibm.net.il>

Net Services Rated -- Startup measures user access times 

      http://www.techweb.com/se/directlink.cgi?IWK19970310S0043

Does anyone know where these stats can be seen online?

Thanks,
Hank





From randy at verio.net  Sun Mar 16 12:27:00 1997
From: randy at verio.net (Randy Bush)
Date: Sun, 16 Mar 97 04:27 PST
Subject: GRIDNET wake up
Message-ID: <m0w6F1p-0007zYC@rip.psg.com>

Dear GridNet:

Mail to the contacts in your whois data bounces.  So we will make this a
public plea:

  o Fix your whois data.

  o Please stop the SNMP probes from 206.80.163.6 to our routers.  As they
    get no data as you do not know our community string, the continual
    repition could be interpreted as a denial attack.

rady




From storpis at redhead.pbi.net  Mon Mar 17 00:39:18 1997
From: storpis at redhead.pbi.net (storpis at redhead.pbi.net)
Date: Sun, 16 Mar 1997 16:39:18 -0800 (PST)
Subject: Information Week article
In-Reply-To: <2.2.16.19970316115910.5927756a@rex.ibm.net.il> from "Hank Nussbacher" at Mar 16, 97 01:59:10 pm
Message-ID: <19970317003919.13346.qmail@redhead.pbi.net>

> Net Services Rated -- Startup measures user access times 
> 
>       http://www.techweb.com/se/directlink.cgi?IWK19970310S0043
> 
> Does anyone know where these stats can be seen online?

It's a peep show. You have to pay to get a look. And I don't believe
they offer anything online even after paying.

-- 
Sharif Torpis (storpis at pbi.net)
Network Engineering
Pacific Bell Internet
PGP Key at http://www-swiss.ai.mit.edu/~bal/pks-toplev.html




From dcohn at cisco.com  Mon Mar 17 03:29:41 1997
From: dcohn at cisco.com (dan)
Date: Sun, 16 Mar 1997 19:29:41 -0800
Subject: [Fwd: Software Forum Dinner Mtg., Wed. Mar. 19, Bob Metcalfe]
Message-ID: <332CBAA5.4C9@cisco.com>

Just ran accross this on ba.seminars, thought it may be of interest to
some of you. ;)

dc

> 
>                   SOFTWARE FORUM  (Palo Alto CA)
>               Dinner Meeting, Wednesday March 19
> 
> Bob Metcalfe will review his early 1996 prediction of imminent
> Internet collapse, and will identify what current trends will become
> dominant in the future.
> 
> Bob has a Ph.D. from Harvard, led the development of Ethernet, founded
> 3Com Corporation, was an InfoWorld columnist for several years, and is
> now VP of technology for IDG, a leading IT research firm. He is an
> entertaining and provocative speaker. Come and ask your own questions!
> 
>   Where:   4249 El Camino Real, Palo Alto (call Software Forum office
>            for directions)
> 
>   Date:    Wednesday, March 19, 1997
>   Time:    6:30 p.m. - Cocktail hour, 7:00 p.m. - Dinner
> 
>   Price:   $25 members, $40 non-members
> 
>   Reserve: Software Forum voice mail (415/854-8298)
> 
>   Info:    Software Forum office (415/854-7219)
>            http://www.softwareforum.org
> 
>   **********************************************************************
>  For these announcements by email, send mail to majordomo at netcom.com,
>  with any subject, and with this text: subscribe software-forum-dinner
>   **********************************************************************
> 
>  Software Forum, started in 1983, is a Silicon Valley based non-profit
>  organization dedicated to software  professionals, with over 900
>  members. It informs and educates its members on all facets of the
>  software industry -- ranging from technical innovation to product
>  development, marketing, and sales. The group offers professionals a
>  sense of community and is a valuable forum for exchanging ideas.
> 
>  Software Forum also sponsors 13 special interest groups, which meet
>  once a month: UNIX, C++, Business Operations, Delphi, Games & AR
>  Developers, International, Internet, Java, Marketing, Multimedia,
>  Visual Basic, VMRL, and Windows.




From randy at psg.com  Mon Mar 17 06:06:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 16 Mar 97 22:06 PST
Subject: [Fwd: Software Forum Dinner Mtg., Wed. Mar. 19, Bob Metcalfe]
References: <332CBAA5.4C9@cisco.com>
Message-ID: <m0w6VZ4-0007zYC@rip.psg.com>

>                   SOFTWARE FORUM  (Palo Alto CA)
>               Dinner Meeting, Wednesday March 19
> 
> Bob Metcalfe will review his early 1996 prediction of imminent
> Internet collapse, and will identify what current trends will become
> dominant in the future.

Well, we can hope what Bob will eat for dinner.

randy




From tli at jnx.com  Mon Mar 17 06:58:48 1997
From: tli at jnx.com (Tony Li)
Date: Sun, 16 Mar 1997 22:58:48 -0800 (PST)
Subject: consistent policy != consistent announcements
References: <199703131038.CAA01529@quest.pluris.com>
Message-ID: <199703170658.WAA07018@chimp.jnx.com>


   2) generally speaking, BGP path length is too blunt an instrument.  More
   fine-grained control is needed to allow peers to fine-tune balance of
   their interests.  I'm sorry to be too naive, but i'm repeating that for
   years and nobody seems to agree that BGP needs real metrics.  How come? 

Well, for several reasons.

First, any such proposal should have a reasonable architecture.  Not just a
description of the mechanism.  Motivational explanations are most welcome,
preferably sprinkled with real world examples.

Second, there's the issue of the consistency of the values used.  As I
recall your proposal, each domain in the path would propose a metric for
its contribution for a prefix.  A receiving domain then weighted each
domain in whichever way it chose to arrive at a final, composite metric.
Thus, the semantics of the metric are hardly clear.

Third, there's the pragmatic issue of implementation cost.  Yes, the cost
of an integer per AS in an AS path is tolerable, tho not "cheap".  This
cost becomes painful if most domains are not using the metric.  And it
becomes more painful if two prefixes with otherwise identical attributes
have different metrics.  This results in them not landing in the same
update, thereby increasing overhead.  Are we willing to take a signficant
step forward in overhead for this flexibility?  

Tony




From Mirjam.Kuehne at ripe.net  Mon Mar 17 11:43:53 1997
From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne)
Date: Mon, 17 Mar 1997 12:43:53 +0100
Subject: De-registration request 
In-Reply-To: Your message of Tue, 11 Mar 1997 11:14:57 +0100.
             <9703111014.AA23717@ncc.ripe.net> 
Message-ID: <9703171143.AA20490@ncc.ripe.net>


Dear Hank,

Sorry for the delay, I am not on the nanog list anymore (it's hard
enough to follow naipr ;-)

Just to correct this: Fortunately you were not the first one who
returned an AS number. Since we have many hostmasters working at 
the RIPE NCC the particular hostmaster you dealt with might not 
have been aware of this.

We even make regular surveys to find out if networks are multihomed. 
Some people then realise  that they don't need an AS number and
return it. 

And the procedure is really easy: You just inform us that you don't
need the numbers anymore and we take appropriate action.

We are always happy to take AS numbers or address space back.
Don't hesitate :-)

Kind Regards,

Mirjam Kuehne
Manager Registraton Services
RIPE NCC


  * -------- Forwarded Message
  * 
  * Return-Path: owner-nanog at merit.edu
  * Date: Tue, 11 Mar 1997 07:36:48 +0200 (IST)
  * From: Hank Nussbacher <hank at ibm.net.il>
  * To: Paul A Vixie <paul at vix.com>
  * cc: nanog at merit.edu
  * Subject: Re: Class "B" forsale (fwd) 
  * In-Reply-To: <199703110044.QAA22923 at wisdom.home.vix.com>
  * Message-ID: <Pine.A32.3.95-heb-2.07.970311073419.71061F-100000 at rex.ibm.net.
  * il>
  * MIME-Version: 1.0
  * Content-Type: TEXT/PLAIN; charset=US-ASCII
  * Sender: owner-nanog at merit.edu
  * Status: RO
  * 
  * On Mon, 10 Mar 1997, Paul A Vixie wrote:
  * 
  * > > Yes, I know many (David and Geoff:-)) are probably calling me Pollyanna
  * > > right about now and it is true that most companies won't return it
  * > > if they think they can sell it.  But I think having a procedure in
  * > > place to at least begin reclaiming addresses from those organizations
  * > > that are no longer in business can only help matters.  
  * > 
  * > I personally oversaw the return of four /16's recently, so I, at least,
  * > do not consider this to be Pollyannaism.
  * > 
  * 
  * When I returned an ASN 2 months ago to RIPE, I asked what the procedure
  * was to deallocate an AS object and return it to the pool of available
  * numbers.  I was told there was no procedure since I was the first. :-)
  * 
  * Hank Nussbacher
  * 
  * 
  * -------- End of Forwarded Message




From denny at rns.net  Mon Mar 17 12:49:03 1997
From: denny at rns.net (Douglas Denny)
Date: Mon, 17 Mar 1997 07:49:03 -0500 (EST)
Subject: Canadian Network Operators:
Message-ID: <Pine.GSO.3.96.970317074708.5951B-100000@admin.rns.net>


	This is of interest to all Canadian Internet operators.
Re-distributed by request. 

-Doug


                    -- PLEASE DISTRIBUTE --

       Net '97: The 11th Annual Canadian Internet Conference
                         June 22-25
                     Dalhousie University
                      Halifax, NS CANADA

            Together on the Ocean / Voyageons Ensemble

           Net '97, vous invite a presenter en francais.

~~~~~~~~~~~~~~
SPONSORED BY:
~~~~~~~~~~~~~~
     Cisco Canada Ltd
     CA*net networking Inc
     Bell Advanced Communications
     MT&T Advanced Communications
     Dalhousie University
     CANARIE Inc
     iSTAR Internetwork Inc


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CONFERENCE INFORMATION & REGISTRATION
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Check out:

        http://net97.dal.ca/

     Online Registration and Accommodations;
     Full Conference Information


~~~~~~~~~~~~~~~~
CALL FOR PAPERS
~~~~~~~~~~~~~~~~
Dalhousie University, in Halifax, Nova Scotia invites the
Canadian networking community to your eleventh annual congress,
on June 22nd to 25th. Net '97 will bring together the people who
make the Internet work in Canada, to share knowlege, experiences
and future plans in both the commercial and academic fields.

This is a conference for Canadian Internet articifers; the people
who design, build and maintain the net. A job which since the
beginning of networking in Canada has been most closely linked
with higher education and research. The past year has seen
dramatic changes and Net '97 will involve both academic and
commercial tracks.

Extended abstracts outlining the proposed paper should not exceed
300 words. Please indicate which track, commercial or academic,
you feel your paper would be most appropriate for. Papers will be
published on the Web for two years, and CD-ROMs of the
proceedings will also be available.


~~~~~~~~~~~
KEY DATES:
~~~~~~~~~~~
  March 28: Receipt of abstracts
  April 11: Acceptance Notification
  June  1:  Submission of full paper in machine readable form
  July 25:  Submission of revised paper in machine readable form


~~~~~~~~~~
ENQUIRIES
~~~~~~~~~~
Please direct all correspondence regarding Net '97 conference to
Net97 at Dal.Ca.

                             - 30 -
--
Douglas A. Denny                        denny at rns.net
Network Operations Specialist           DIRECT:    +1 416 443 7941
Rogers Network Services                 TOLL-FREE: +1 800 267 DATA





From garyz at savvis.com  Mon Mar 17 15:10:24 1997
From: garyz at savvis.com (Gary Zimmerman)
Date: Mon, 17 Mar 1997 07:10:24 -0800
Subject: consistent policy != consistent announcements
Message-ID: <19970317131919.AAA6392@rock>

I agree.  the BGP path is a blunt instrument.  BGP is in need of real
metrics.  I really want to fine tune but find it hard with current
abilities of BGP.  I would also like to use the bits within the TCP/IP
header to help determine class of services which is there but no one uses
or seems to care about.  

We could offer some really good services to the internet if we could get
this fine-grained control.  But, when you get down to it, most companies
are having a hard time with this from a resource and the overhead cost on
routers.  I think the big companies (cisco) are holding us back.  We need
routing to take place more on a switch fabric, hardware/card based, vrs
software based routing. Routers like the Ascend (NetStar) are a step in the
right direction.  This will help take care of the third issue.  

Gary Zimmerman
V.P. of Network Engineering
Savvis Communications

"I don't wear the uniform to play,  I wear it to win!"  Larry Byrd

----------
> From: Tony Li <tli at jnx.com>
> To: Vadim Antonov <avg at pluris.com>
> Cc: nanog at merit.edu
> Subject: Re: consistent policy != consistent announcements
> Date: Sunday, March 16, 1997 10:58 PM
> 
> 
>    2) generally speaking, BGP path length is too blunt an instrument. 
More
>    fine-grained control is needed to allow peers to fine-tune balance of
>    their interests.  I'm sorry to be too naive, but i'm repeating that
for
>    years and nobody seems to agree that BGP needs real metrics.  How
come? 
> 
> Well, for several reasons.
> 
> First, any such proposal should have a reasonable architecture.  Not just
a
> description of the mechanism.  Motivational explanations are most
welcome,
> preferably sprinkled with real world examples.
> 
> Second, there's the issue of the consistency of the values used.  As I
> recall your proposal, each domain in the path would propose a metric for
> its contribution for a prefix.  A receiving domain then weighted each
> domain in whichever way it chose to arrive at a final, composite metric.
> Thus, the semantics of the metric are hardly clear.
> 
> Third, there's the pragmatic issue of implementation cost.  Yes, the cost
> of an integer per AS in an AS path is tolerable, tho not "cheap".  This
> cost becomes painful if most domains are not using the metric.  And it
> becomes more painful if two prefixes with otherwise identical attributes
> have different metrics.  This results in them not landing in the same
> update, thereby increasing overhead.  Are we willing to take a signficant
> step forward in overhead for this flexibility?  
> 
> Tony




From mreed at veiwcall.net  Mon Mar 17 14:20:40 1997
From: mreed at veiwcall.net (Michael Reed)
Date: Mon, 17 Mar 1997 09:20:40 -0500
Subject: GRIDNET wake up
Message-ID: <199703171550.KAA27775@vca.atlanta.net>

The whois contact has move to a better company (me)

the remaining engineers probable do no know who is being probed

you can contact them at twilkens at gridnet.com
lprovow at gridnet.com

----------
> From: Randy Bush <randy at verio.net>
> To: nanog at merit.edu
> Subject: GRIDNET wake up
> Date: Sunday, March 16, 1997 7:00 AM
> 
> Dear GridNet:
> 
> Mail to the contacts in your whois data bounces.  So we will make this a
> public plea:
> 
>   o Fix your whois data.
> 
>   o Please stop the SNMP probes from 206.80.163.6 to our routers.  As
they
>     get no data as you do not know our community string, the continual
>     repition could be interpreted as a denial attack.
> 
> rady




From randy at psg.com  Mon Mar 17 15:57:00 1997
From: randy at psg.com (Randy Bush)
Date: Mon, 17 Mar 97 07:57 PST
Subject: GRIDNET wake up
References: <199703171550.KAA27775@vca.atlanta.net>
Message-ID: <m0w6emr-0007zbC@rip.psg.com>

> The whois contact has move to a better company (me)
> the remaining engineers probable do no know who is being probed

Would you like a saucer of milk with your breakfast?

Jim McManus of UUNET managed to get through to the right folk.  Thanks,
Jim.

randy




From avg at pluris.com  Mon Mar 17 21:31:40 1997
From: avg at pluris.com (Vadim Antonov)
Date: Mon, 17 Mar 1997 13:31:40 -0800
Subject: consistent policy != consistent announcements
Message-ID: <199703172131.NAA08317@quest.pluris.com>

[BGP Metrics]

Tony Li wrote:

>First, any such proposal should have a reasonable architecture.  Not just a
>description of the mechanism.  Motivational explanations are most welcome,
>preferably sprinkled with real world examples.

Agreed, though i was coming to it from the diffrent angle -- out of the
sense of general disgust about having several different metrics, every one
being rather limited.  I.e. the idea was to introduce a simple generic mechanism
including all existing metrics as particluar cases.

>Second, there's the issue of the consistency of the values used.  As I
>recall your proposal, each domain in the path would propose a metric for
>its contribution for a prefix.  A receiving domain then weighted each
>domain in whichever way it chose to arrive at a final, composite metric.
>Thus, the semantics of the metric are hardly clear.

There's a clear statement that the default value of a single AS hop is 1.0.
Since there's no central administration, there's no way to coordinate the
scale of metrics globally (i.e. what constitutes 1/2 of a default hop?) -- so
the weights are provided to give other parties ability to compensate the
variations in the interpretation.

The reason for carrying a vector is to make possible establishing local policies
on values originated from remote side, and to allow operators to do things
like having closer metrics to have higher costs (i.e. the more remote
as-path component is, the less important its metric is).

>Third, there's the pragmatic issue of implementation cost.  Yes, the cost
>of an integer per AS in an AS path is tolerable, tho not "cheap".  This
>cost becomes painful if most domains are not using the metric.

Then it does not take space in the path attributers.  I.e. if you have a box
implementing proposed metrics, and use only old-style paths, you end up with
identical updates and identical results of their comparison.   If old boxes
implement transitive attributes properly, their effect would simply be setting
static metric 1.0 for a hop.

>And it becomes more painful if two prefixes with otherwise identical attributes
>have different metrics.  This results in them not landing in the same
>update, thereby increasing overhead.  Are we willing to take a signficant
>step forward in overhead for this flexibility?

Exactly the same happens when you have different MEDs or different communities.
Since the proposal obsoletes MEDs and LOCAL_PREFs (and makes the practice of
ASN replication unnecessary) the overall overhead is likely to be close to zero
(providing that same policies are implemented).

--vadim




From liam at bbnplanet.com  Mon Mar 17 21:46:41 1997
From: liam at bbnplanet.com (L. Sean Kennedy)
Date: Mon, 17 Mar 1997 16:46:41 -0500
Subject: FYI: BBN/MCI Peering Change 3/31/97
Message-ID: <9703171645.aa20175@mail.bbnplanet.com>

Just over two years ago BBN/NEARNET, BBN/BARRNet, and SURAnet (later 
BBN/SURAnet) independently selected MCI to provide Network Service Provider 
(NSP) transit services.  The transit agreement obligated BBN-owned 
regionals to use MCI for transit services.  Over the past two years BBN 
has migrated from this collection of semi-autonomous regional networks
to one nationwide infrastructure.  We have made minimal use of MCI 
transit services, using existing connections to MCI primarily to reach
MCI customers.

In light of this change and in order to provide improved connectivity
to their customers, BBN and MCI have agreed to replace the transit 
service agreement with a private peering agreement.  Cessation of the 
transit agreement is scheduled for 3/31/97.

The technical impact of this change is that MCI will no longer announce
BBN routes at the public interconnects, except to those providers who 
have purchased transit service from MCI.  Providers with significant
trans-national US infrastructure at DS3 or greater speeds who are reliant 
on MCI's announcement of AS1 prefixes are encouraged to pursue peering with 
BBN by contacting 'peering at bbnplanet.com' by 3/19/97.  Those providers
with a existing transit provider who peers with BBN should see no change in 
how they reach BBN customers (and should contact their transit provider with 
questions regarding its connectivity).  Existing peers of BBN will see no 
change in our announcements or routing.

 Sean




From yone at wolfenet.com  Mon Mar 17 23:17:43 1997
From: yone at wolfenet.com (Scott Yoneyama)
Date: Mon, 17 Mar 1997 15:17:43 -0800
Subject: request for data
Message-ID: <199703172318.PAA10491@wolfenet.com>

Does anyone know some sources I can go to for data on bandwidth needs,
technological marketplace, and other telecommunications information (i.e.
number of major corporations, carriers, etc.) for the Bay Area and Los
Angeles?

I trying to justify some network expansion and need to focus the data on
not only those marketplaces, but be able to pull enough specific data to
show the effect on the northwest. 

All suggestions are desparately appreciated!

Scott Yoneyama
Director
Starcom Service Corporation
206-448-4034
206-448-4485 fax
yone at wolfenet.com




From davec at ziplink.net  Tue Mar 18 03:20:40 1997
From: davec at ziplink.net (Dave Curado)
Date: Mon, 17 Mar 1997 22:20:40 -0500 (EST)
Subject: FYI: BBN/MCI Peering Change 3/31/97
Message-ID: <199703180320.WAA23635@zip1.ziplink.net>


> The technical impact of this change is that MCI will no longer announce
> BBN routes at the public interconnects, except to those providers who 
> have purchased transit service from MCI. 

You're inferring I can buy transit from MCI at the naps.
If that is true, please let me know.

davec





From mpetach at netflight.com  Tue Mar 18 08:30:50 1997
From: mpetach at netflight.com (Matthew Petach)
Date: Tue, 18 Mar 1997 00:30:50 -0800 (PST)
Subject: FYI: BBN/MCI Peering Change 3/31/97
In-Reply-To: <199703180320.WAA23635@zip1.ziplink.net> from "Dave Curado" at Mar 17, 97 10:20:40 pm
Message-ID: <199703180830.AAA02247@falcon.netflight.com>

> 
> 
> > The technical impact of this change is that MCI will no longer announce
> > BBN routes at the public interconnects, except to those providers who 
> > have purchased transit service from MCI. 
> 
> You're inferring I can buy transit from MCI at the naps.
> If that is true, please let me know.

Not at all.  The only inference you can draw is that MCI does
indeed sell transit services, and that as part of that service,
they will announce BBN routes to you.  Indeed, they will announce
everyone's routes to you if you so desire as a transit customer.
No claims, or even vague references are made as to how or where
that transit service connection is made.  I know MCI will be
quite willing to provide you transit services over a DS3 you
purchase from them.  Of course, there's the matter of the
small additional fee for transit services.  :-)

Of course, if I totally misread your post, and you meant it
to be tongue-in-cheek, then please forgive my overly candid
response.


> davec

Matt





From rs at bifrost.seastrom.com  Tue Mar 18 09:07:38 1997
From: rs at bifrost.seastrom.com (Robert E. Seastrom)
Date: Tue, 18 Mar 1997 04:07:38 -0500 (EST)
Subject: FYI: BBN/MCI Peering Change 3/31/97
In-Reply-To: <199703180320.WAA23635@zip1.ziplink.net> (message from Dave
	Curado on Mon, 17 Mar 1997 22:20:40 -0500 (EST))
Message-ID: <199703180907.EAA12931@bifrost.seastrom.com>


   From: Dave Curado <davec at ziplink.net>

   > The technical impact of this change is that MCI will no longer announce
   > BBN routes at the public interconnects, except to those providers who 
   > have purchased transit service from MCI. 

   You're inferring I can buy transit from MCI at the naps.
   If that is true, please let me know.

No, you're inferring.  He's insinuating.

                                        ---Rob





From davec at ziplink.net  Tue Mar 18 10:14:34 1997
From: davec at ziplink.net (Dave Curado)
Date: Tue, 18 Mar 1997 05:14:34 -0500 (EST)
Subject: FYI: BBN/MCI Peering Change 3/31/97
Message-ID: <199703181014.FAA00521@zip1.ziplink.net>

 
>>> The technical impact of this change is that MCI will no longer announce
>>> BBN routes at the public interconnects, except to those providers who 
>>> have purchased transit service from MCI. 
 
>> You're inferring I can buy transit from MCI at the naps.
>> If that is true, please let me know.

I meant implying -- please, no more corrections needed. =-)

> Not at all.  The only inference you can draw is that MCI does
> indeed sell transit services, and that as part of that service,
> they will announce BBN routes to you.  Indeed, they will announce
> everyone's routes to you if you so desire as a transit customer.
> No claims, or even vague references are made as to how or where
> that transit service connection is made. 

Um, yes, I think there was at least a vague reference in there. =-)
(read it again)

My intention, by the way, is not to simply pick nits over a posting.
I have heard in the past that there is at least one major provider
who sells transit through the naps.  Regardless of whether that is
an OK thing to do or not, I am sincerely interested in knowing if
that is true.  

> I know MCI will be quite willing to provide you transit services 
> over a DS3 you purchase from them.  Of course, there's the matter of the
> small additional fee for transit services.  :-)

You're implying they won't sell me transit over a T1?
(just kidding)

davec





From crumley at trinet.com  Tue Mar 18 17:46:35 1997
From: crumley at trinet.com (Steve Crumley)
Date: Tue, 18 Mar 1997 12:46:35 -0500 (EST)
Subject: usable T1 bandwidth
Message-ID: <199703181746.MAA12945@blusky.trinet.com>

How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
some bits are taken for framing and such.  I think I remember it is
around 1.3 something.
Thanks,
-Steve




From pam at merit.edu  Tue Mar 18 18:59:52 1997
From: pam at merit.edu (Pam Ciesla)
Date: Tue, 18 Mar 1997 13:59:52 -0500 (EST)
Subject: NANOG 10 
Message-ID: <199703181859.NAA20344@home.merit.edu>


Will be held in Tampa, Florida June 5th & 6th. All info is available via
http://www.nanog.org/. Networking tutorial is scheduled 7:00-9:00PM 
Wednesday evening (subject TBA). Please note payment information on the
registration page before registering. Any questions contact me at
(313)936-0172 or e-mail.  Thanks
  Pam Ciesla




From mheroux at u.washington.edu  Tue Mar 18 19:38:10 1997
From: mheroux at u.washington.edu (Mike Heroux)
Date: Tue, 18 Mar 1997 11:38:10 -0800
Subject: usable T1 bandwidth
Message-ID: <199703181938.LAA44660@bp09.u.washington.edu>

>    How much of the 1.544 Mbits/second of a T1 are available to IP?  I
know
>    some bits are taken for framing and such.  I think I remember it is
>    around 1.3 something.
> It's better than that, but the topic is inappropriate to this list, so...

So you bothered to clutter it up with even more senseless mail. (much like
this reply)

This list gets so pathetic at times.. Is anybody else on this list younger
than 20?

--mike




From sosebee at bellsouth.net  Tue Mar 18 19:43:18 1997
From: sosebee at bellsouth.net (John R. Sosebee)
Date: Tue, 18 Mar 1997 14:43:18 -0500
Subject: NANOG 10 
Message-ID: <3.0.32.19970318144313.00db1234@mail.msy.bellsouth.net>

At 01:59 PM 3/18/97 -0500, Pam Ciesla wrote:
>
>Will be held in Tampa, Florida June 5th & 6th. All info is available via


Is this just coincidence that cisco Networkers '97 is June 3-5 in Orlando.
little over an hour from Tampa ? 

-Paul F. ... can you say "a week at the beach ? "


>http://www.nanog.org/. Networking tutorial is scheduled 7:00-9:00PM 
>Wednesday evening (subject TBA). Please note payment information on the
>registration page before registering. Any questions contact me at
>(313)936-0172 or e-mail.  Thanks
>  Pam Ciesla
>
John
sosebee at bellsouth.net
(770) 392-4300 




From tli at jnx.com  Tue Mar 18 19:08:34 1997
From: tli at jnx.com (Tony Li)
Date: Tue, 18 Mar 1997 11:08:34 -0800 (PST)
Subject: usable T1 bandwidth
References: <199703181746.MAA12945@blusky.trinet.com>
Message-ID: <199703181908.LAA10948@chimp.jnx.com>


   How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
   some bits are taken for framing and such.  I think I remember it is
   around 1.3 something.

It's better than that, but the topic is inappropriate to this list, so...

Tony





From cmontano at mail.hamquist.com  Tue Mar 18 19:55:33 1997
From: cmontano at mail.hamquist.com (Christopher Montano)
Date: 18 Mar 1997 11:55:33 -0800
Subject: usable T1 bandwidth
Message-ID: <n1353435898.22770@mail.hamquist.com>

                      RE>>usable T1 bandwidth                      3/18/97

where is the "approved topics list" by the way ...

curious.

--------------------------------------
Date: 3/18/97 11:48 AM
To: Christopher Montano
From: Tony Li

   How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
   some bits are taken for framing and such.  I think I remember it is
   around 1.3 something.

It's better than that, but the topic is inappropriate to this list, so...

Tony


------------------ RFC822 Header Follows ------------------
Received: by mail.hamquist.com with ADMIN;18 Mar 1997 11:43:27 -0800
Received: from localhost (daemon at localhost) by merit.edu (8.8.5/merit-2.0)
with SMTP id OAA13330; Tue, 18 Mar 1997 14:34:08 -0500 (EST)
Received: by merit.edu (bulk_mailer v1.5); Tue, 18 Mar 1997 14:31:47 -0500
Received: (from daemon at localhost) by merit.edu (8.8.5/merit-2.0) id OAA13254
for nanog-outgoing; Tue, 18 Mar 1997 14:31:47 -0500 (EST)
Received: from red.jnx.com (red.jnx.com [208.197.169.254]) by merit.edu
(8.8.5/merit-2.0) with ESMTP id OAA13242 for <nanog at merit.edu>; Tue, 18 Mar
1997 14:31:18 -0500 (EST)
Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.246]) by red.jnx.com
(8.8.5/8.8.3) with ESMTP id LAA02382; Tue, 18 Mar 1997 11:08:35 -0800 (PST)
Received: (from tli at localhost) by chimp.jnx.com (8.7.6/8.7.3) id LAA10948;
Tue, 18 Mar 1997 11:08:34 -0800 (PST)
Date: Tue, 18 Mar 1997 11:08:34 -0800 (PST)
Message-Id: <199703181908.LAA10948 at chimp.jnx.com>
From: Tony Li <tli at jnx.com>
To: crumley at trinet.com (Steve Crumley)
cc: nanog at merit.edu
Subject: Re: usable T1 bandwidth
References: <199703181746.MAA12945 at blusky.trinet.com>
Sender: owner-nanog at merit.edu







From randy at psg.com  Tue Mar 18 20:19:00 1997
From: randy at psg.com (Randy Bush)
Date: Tue, 18 Mar 97 12:19 PST
Subject: usable T1 bandwidth
References: <n1353435898.22770@mail.hamquist.com>
Message-ID: <m0w75Lr-0007zYC@rip.psg.com>

> where is the "approved topics list" by the way ...

That question is not an approved topic?

BTW, of what national network are you an operator?

randy




From jdd at vbc.net  Tue Mar 18 20:30:42 1997
From: jdd at vbc.net (Jim Dixon)
Date: Tue, 18 Mar 1997 20:30:42 +0000 (GMT)
Subject: usable T1 bandwidth
In-Reply-To: <m0w75Lr-0007zYC@rip.psg.com>
Message-ID: <Pine.BSI.3.91.970318203005.28440B-100000@avon-gw.uk1.vbc.net>

On Tue, 18 Mar 1997, Randy Bush wrote:

> > where is the "approved topics list" by the way ...
> 
> That question is not an approved topic?
> 
> BTW, of what national network are you an operator?

I answered the original question off list.  Can we drop it now?

--
Jim Dixon                  VBCnet GB Ltd           http://www.vbc.net
tel +44 117 929 1316                             fax +44 117 927 2015





From dlc at avtel.net  Tue Mar 18 20:36:13 1997
From: dlc at avtel.net (David Carmean)
Date: Tue, 18 Mar 1997 12:36:13 -0800
Subject: usable T1 bandwidth
In-Reply-To: <m0w75Lr-0007zYC@rip.psg.com>; from Randy Bush on Tue, Mar 18, 1997 at 12:19:00PM -0700
References: <n1353435898.22770@mail.hamquist.com> <m0w75Lr-0007zYC@rip.psg.com>
Message-ID: <19970318123613.33863@beach.silcom.com>

On Tue, Mar 18, 1997 at 12:19:00PM -0700, Randy Bush wrote:
> > where is the "approved topics list" by the way ...
> 
> That question is not an approved topic?
> 
> BTW, of what national network are you an operator?
> 
> randy


Look, all you arrogant, self-important fscks!  Knock it off with the 
secret handshake gag already.  And stop playing "my network (penis) is 
bigger than your network (penis)".

This is an open list; I don't find a /list/ charter or FAQ anywhere.  If 
you want to start a country club, make a closed list somewhere.

A polite "that question is more appropriately asked on the inet-access 
list" or similar would have been just fine.

You bitch about new network operators who don't know how to keep their 
BGP announcements clean, and who don't know about the politics and 
procedures of peering vs. transit, and the NAPs and elsewhere.  But 
let someone come here and try to learn, and you turn your nose up and 
try to shame them out of your sight.  

You should be ashamed of yourselves.


-- 
David Carmean                                           <dlc at avtel.net>
Avtel Communications, Santa Barbara, CA			+1-805-730-7740
  Opinions herein are those of the author only, unless otherwise noted




From brian at capecod.net  Wed Mar 19 21:15:45 1997
From: brian at capecod.net (Brian)
Date: Wed, 19 Mar 1997 16:15:45 -0500
Subject: usable T1 bandwidth
Message-ID: <3.0.32.19970319161542.00735c2c@204.255.214.5>

>This list gets so pathetic at times.. Is anybody else on this list younger
>than 20?

Might as well add to this mail clutter that just started flowing in...
Yes.. I'm under 20.
I'm not a national network administrator... just trying to learn some
things for when I do become one :)

Brian


--
CAPEInternet Network Administrator




From bmanning at ISI.EDU  Tue Mar 18 21:02:33 1997
From: bmanning at ISI.EDU (bmanning at ISI.EDU)
Date: Tue, 18 Mar 1997 13:02:33 -0800 (PST)
Subject: usable T1 bandwidth
In-Reply-To: <m0w75Lr-0007zYC@rip.psg.com> from "Randy Bush" at Mar 18, 97 12:19:00 pm
Message-ID: <199703182102.AA08770@zed.isi.edu>

> 
> > where is the "approved topics list" by the way ...
> 
> That question is not an approved topic?
> 
> BTW, of what national network are you an operator?
> 
> randy

Er, last I checked... North
		      American
		      Network
		      Operations
		      Group

Which "N" became national?

-- 
--bill




From mpearson at games-online.com  Tue Mar 18 21:17:39 1997
From: mpearson at games-online.com (Matthew E. Pearson)
Date: Tue, 18 Mar 1997 16:17:39 -0500
Subject: usable T1 bandwidth
Message-ID: <3.0.32.19970318161739.00947100@207.77.39.11>

At 12:36 PM 3/18/97 -0800, David Carmean wrote:
>A polite "that question is more appropriately asked on the inet-access 
>list" or similar would have been just fine.
>

I agree..

>You bitch about new network operators who don't know how to keep their 
>BGP announcements clean, and who don't know about the politics and 
>procedures of peering vs. transit, and the NAPs and elsewhere.  But 
>let someone come here and try to learn, and you turn your nose up and 
>try to shame them out of your sight.  
>

Actually I usually see a 50% flame 50% helpfull reply anytime I post. So I
just use my standard rule of thumb.. 90% of the people in the world are
total morons and 10% have some clue. So with a 50/50 split I think the
overall clue level is quite a bit higher here.


>You should be ashamed of yourselves.

I am ashamed everytime I look at my paycheck.

-----------------------------------------------------------------
Matthew Pearson
Vice President of Development
Games-Online Inc.
http://www.games-online.com
-----------------------------------------------------------------




From len at netsys.com  Tue Mar 18 21:33:22 1997
From: len at netsys.com (Len Rose)
Date: Tue, 18 Mar 1997 16:33:22 -0500
Subject: NANOG 10 
Message-ID: <3.0.32.19970318163322.00b296c0@netsys.com>

Who in their right mind would want to go to Florida in the middle of
summer?

Len


len at netsys.com
http://www.netsys.com





From alex at nac.net  Tue Mar 18 21:00:27 1997
From: alex at nac.net (Alex Rubenstein)
Date: Tue, 18 Mar 1997 17:00:27 -0400
Subject: usable T1 bandwidth
Message-ID: <3.0.32.19970318143201.00ff1490@mail.nac.net>


1536 kb/s (24 x 64 kb/s). 

But, protocol (PPP and IP) overhead can eat a lot of that, 10-20%)


At 12:46 PM 3/18/97 -0500, Steve Crumley wrote:
>How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
>some bits are taken for framing and such.  I think I remember it is
>around 1.3 something.
>Thanks,
>-Steve
>




From lambert at psc.edu  Tue Mar 18 21:58:56 1997
From: lambert at psc.edu (Michael H. Lambert)
Date: Tue, 18 Mar 1997 16:58:56 -0500
Subject: NANOG 10 
In-Reply-To: Your message of "Tue, 18 Mar 1997 16:33:22 EST."
             <3.0.32.19970318163322.00b296c0@netsys.com> 
Message-ID: <199703182159.QAA17869@ebola.psc.edu>

> Who in their right mind would want to go to Florida in the middle of
> summer?

That's why NANOG is being held in late spring???

Michael Lambert
lambert at psc.edu




From smd at cesium.clock.org  Tue Mar 18 21:42:21 1997
From: smd at cesium.clock.org (Sean Doran)
Date: Tue, 18 Mar 1997 13:42:21 -0800
Subject: usable T1 bandwidth
Message-ID: <97Mar18.134227pst.119170-108+16@cesium.clock.org>

Ok, so you're under 20.  What time is it?

	Sean.




From randy at psg.com  Tue Mar 18 21:56:00 1997
From: randy at psg.com (Randy Bush)
Date: Tue, 18 Mar 97 13:56 PST
Subject: NANOG 10 
References: <3.0.32.19970318163322.00b296c0@netsys.com>
Message-ID: <m0w76sB-0007zhC@rip.psg.com>

> Who in their right mind would want to go to Florida in the middle of
> summer?

Do you really care in which air conditioned hotel you spend two days?

And when is being in one's right mind relevant to networking?

randy




From shields at crosslink.net  Tue Mar 18 22:16:28 1997
From: shields at crosslink.net (Michael Shields)
Date: Tue, 18 Mar 1997 17:16:28 -0500
Subject: usable T1 bandwidth
In-Reply-To: <199703181746.MAA12945@blusky.trinet.com>
References: <199703181746.MAA12945@blusky.trinet.com>
Message-ID: <g63etsu9v2.fsf@daedalus.crosslink.net>

> How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
> some bits are taken for framing and such.  I think I remember it is
> around 1.3 something.

It's 1.536 Mbps.  This is 64000 x 24.  The other 8k goes to framing
overhead.  It's full-duplex.  Can we stop the flames now?

Daniel Minoli has put out some good books that cover the low-layer
telecom transports, check with your local bookstore.
-- 
Shields, CrossLink.




From perry at piermont.com  Tue Mar 18 22:31:03 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Tue, 18 Mar 1997 17:31:03 -0500
Subject: NANOG 10 
In-Reply-To: Your message of "Tue, 18 Mar 1997 16:33:22 EST."
             <3.0.32.19970318163322.00b296c0@netsys.com> 
Message-ID: <199703182231.RAA14315@jekyll.piermont.com>


Len Rose writes:
> Who in their right mind would want to go to Florida in the middle of
> summer?

Someone looking for a cheap conference site.

I'll point out that air conditioning is available in most places, and
that makes the place fine for those who want to treat the meeting as a
meeting and not as an excuse to see the sights.

Perry




From lists at reflections.eng.mindspring.net  Tue Mar 18 23:26:17 1997
From: lists at reflections.eng.mindspring.net (Todd Graham Lewis)
Date: Tue, 18 Mar 1997 18:26:17 -0500 (EST)
Subject: usable T1 bandwidth
In-Reply-To: <199703181938.LAA44660@bp09.u.washington.edu>
Message-ID: <Pine.LNX.3.95q.970318182532.783B-100000@reflections.eng.mindspring.net>

On Tue, 18 Mar 1997, Mike Heroux wrote:

> This list gets so pathetic at times.. Is anybody else on this list younger
> than 20?

I just barely miss that illustrious distinction, but I know of at least
one subscriber who is.  Why in the world does it matter?

__
Todd Graham Lewis          MindSpring Enterprises      tlewis at mindspring.com





From michael at memra.com  Wed Mar 19 03:24:35 1997
From: michael at memra.com (Michael Dillon)
Date: Tue, 18 Mar 1997 19:24:35 -0800 (PST)
Subject: usable T1 bandwidth
In-Reply-To: <199703181908.LAA10948@chimp.jnx.com>
Message-ID: <Pine.BSI.3.93.970318192128.8828m-100000@sidhe.memra.com>

On Tue, 18 Mar 1997, Tony Li wrote:

> 
>    How much of the 1.544 Mbits/second of a T1 are available to IP?  I know
>    some bits are taken for framing and such.  I think I remember it is
>    around 1.3 something.
> 
> It's better than that, but the topic is inappropriate to this list, so...

Golly gee, Tony, someone seems to be tearing down the messages that you
post.  Maybe you need to hammer in a few more nails :-)

The part that got left out of Tony's message was ...so you should try
asking on comp.dcom.telecom.tech in USENET or search the USENET archives
at http://www.dejanews.com

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From swb1 at cornell.edu  Wed Mar 19 13:59:45 1997
From: swb1 at cornell.edu (Scott W Brim)
Date: Wed, 19 Mar 1997 08:59:45 -0500
Subject: NANOG 10
In-Reply-To: <199703182231.RAA14315@jekyll.piermont.com>
References: Your message of "Tue, 18 Mar 1997 16:33:22 EST."          
   <3.0.32.19970318163322.00b296c0@netsys.com>
Message-ID: <v03020900af55a0fd0d12@[132.236.199.117]>

I've been to meetings at the Orlando Airport Hyatt.  You get off the
plane, go up the escalator, and check in.  You might get a room facing
the inside of the airport, looking over the enclosed airport atrium.
You eat in the airport restaurants.  You might, some time during your
stay, pass a window looking outside.  You might as well be in Botswana
(they have MacDonald's, don't they?).

...Scott






From len at netsys.com  Thu Mar 20 03:25:59 1997
From: len at netsys.com (Len Rose)
Date: Wed, 19 Mar 1997 22:25:59 -0500 (EST)
Subject: Domain Rant.
Message-ID: <199703200325.WAA15937@netsys.com>


So.. how many people here have domains predating the NIC contracts, who
politely objected to paying and got their domains put on hold this week?

Len





From dcrocker at brandenburg.com  Thu Mar 20 04:13:19 1997
From: dcrocker at brandenburg.com (Dave Crocker)
Date: Wed, 19 Mar 1997 20:13:19 -0800
Subject: Domain Rant.
In-Reply-To: <199703200325.WAA15937@netsys.com>
Message-ID: <v03102202af5669afa1c1@[205.214.160.62]>

At 7:25 PM -0800 3/19/97, Len Rose wrote:
>So.. how many people here have domains predating the NIC contracts, who
>politely objected to paying and got their domains put on hold this week?

	My objections were not polite, but I paid since I can't afford the
service interruption.

	Always interesting to see monopoly forces at work...

d/

--------------------
Dave Crocker                                             +1 408 246 8253
Brandenburg Consulting                              fax: +1 408 249 6205
675 Spruce Dr.                                  dcrocker at brandenburg.com
Sunnyvale CA 94086 USA                        http://www.brandenburg.com

Internet Mail Consortium                http://www.imc.org, info at imc.org






From randy at psg.com  Thu Mar 20 04:31:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 19 Mar 97 20:31 PST
Subject: Domain Rant.
References: <199703200325.WAA15937@netsys.com>
Message-ID: <m0w7ZVP-0007zWC@rip.psg.com>

> So.. how many people here have domains predating the NIC contracts, who
> politely objected to paying and got their domains put on hold this week?

Not we.  We don't expect a free lunch.

randy




From len at netsys.com  Thu Mar 20 04:46:57 1997
From: len at netsys.com (Len Rose)
Date: Wed, 19 Mar 1997 23:46:57 -0500
Subject: Domain Rant.
Message-ID: <3.0.32.19970319234656.00bf5b90@netsys.com>

It's not about a free lunch.. It's called no involvement in the decision
making process beforehand. I don't want to start any sort of flame war
despite what it may appear -- seeing my domain on hold upset me. It is
at least 11 years old.. I won't be able to afford my network space soon
too if things keep going.

At 08:31 PM 3/19/97 PST, Randy Bush wrote:

[stuff deleted]

>Not we.  We don't expect a free lunch.
>
>randy
>





From randy at psg.com  Thu Mar 20 04:56:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 19 Mar 97 20:56 PST
Subject: Domain Rant.
References: <3.0.32.19970319234656.00bf5b90@netsys.com>
Message-ID: <m0w7ZuB-0007zWC@rip.psg.com>

> I won't be able to afford my network space soon too if things keep going.

Oh, and who do you imagine is threatening that?

randy




From len at netsys.com  Thu Mar 20 04:59:08 1997
From: len at netsys.com (Len Rose)
Date: Wed, 19 Mar 1997 23:59:08 -0500
Subject: Domain Rant.
Message-ID: <3.0.32.19970319235907.00a0c360@netsys.com>


Randy, I am not given to "imagining threats" much. If I have to start paying
2500 per year for my block of 5 networks I won't be able to keep them.
This has gone beyond the scope of NANOG;s charter so please redirect this
to personal mail.

Thanks

Len

At 08:56 PM 3/19/97 PST, Randy Bush wrote:
>> I won't be able to afford my network space soon too if things keep going.
>
>Oh, and who do you imagine is threatening that?
>
>randy
>
>




From randy at psg.com  Thu Mar 20 05:03:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 19 Mar 97 21:03 PST
Subject: Mail bounces from Deere
References: <DACDXC01.POSTMSTR.224658220097078FDACDXC01@TCP30.DX.DEERE.COM>
Message-ID: <m0w7a12-0007zWC@rip.psg.com>

Possibly subscribers to NANOG should convince their mail systems to follow
RFC1123 section 5.3, and send bounces to the list owner as opposed to the
message From:.

<sigh>

randy

> Received: from deere-bh.dx.deere.com (207.122.201.66) by psg.com via smtp
> 	id m0w7ZxX-00012xC; Wed, 19 Mar 97 21:00 PST (Smail3.1.29.1#2)
> Received: (from uucp at localhost) by deere-bh.dx.deere.com (8.6.12/8.6.11) id WAA15396 for <randy at PSG.COM>; Wed, 19 Mar 1997 22:57:52 -0600
> Received: from 192.43.1.3 by deere-bh.dx.deere.com via smap (V3.1.1)
> 	id xma015353; Wed, 19 Mar 97 22:57:37 -0600
> Received: from TCP30.DX.DEERE.COM by deere (SMI-8.6/SMI-SVR4)
> 	id WAA06458; Wed, 19 Mar 1997 22:59:57 -0600
> Received: by TCP30.DX.DEERE.COM
>         (Soft*Switch Central V4L40P1A) id 224658220097078FDACDXC01;
>         19 Mar 1997 22:58:22 GMT
> Message-Id: <DACDXC01.POSTMSTR.224658220097078FDACDXC01 at TCP30.DX.DEERE.COM>
> Date: 19 Mar 1997 22:58:22 GMT
> From: "Postmaster" <DACDXC01.POSTMSTR at TCP30.DX.deere.com>
> Subject: DISTRIBUTION STATUS
> To: randy at PSG.COM
> Comment: MEMO 03.19.97 22.58
> 
> 
> DACDXE03.RANDY4     DISTRIBUTION STATUS INFORMATION      03/19/97 22:58
> :44
> =======================================================================
> 
> DISTRIBUTION ID: DACDXE03.RANDY4.6776
> SUBJECT        : Re: Domain Rant.
> DOCUMENT NAME  : MEMO 03.19.97 22.58
> DATE  SENT     : 03/19/97        TIME SENT: 22:58:00
> =======================================================================
> 
> YOUR MAIL WAS NOT DELIVERED FOR THE FOLLOWING REASON:
> 
> SNADS STATUS  : 0301
> X.400 CODE    : 01
> INFORMATION   :
> EXPLANATION   : Ambiguous OR name or recipient unknown on target system
> 
> =======================================================================
> 
> RECIPIENT      : DACDXX21.JM00722
> LAST NAME      : MEANY
> FIRST NAME     : JOHN
> MIDDLE INITIAL : P
> INITIALS       : P
> NATIVE NAME    :
> COUNTRY        : US
> ADMD           : TELEMAIL
> PRMD           : TRT400
> ORGANIZATION   : JOHN DEERE
> ORG UNIT 1     : DACDXX21
> ORG UNIT 2     :
> ORG UNIT 3     :
> ORG UNIT 4     :
> DDA            : ID!JM00722
> TITLE          : NO TITLE
> DESCRIPTION    : 9A945INFORMATION SERVICES
> USERDATA       : 9A945:FARM PLAN CORPORATIO
> STREET         :
> TOWN           :
> REGION         :
> TELEPHONE      : 3112890
> TELEX          :
> FAX            :




From randy at psg.com  Thu Mar 20 05:06:00 1997
From: randy at psg.com (Randy Bush)
Date: Wed, 19 Mar 97 21:06 PST
Subject: Domain Rant.
References: <3.0.32.19970319235907.00a0c360@netsys.com>
Message-ID: <m0w7a3c-0007zWC@rip.psg.com>

> Randy, I am not given to "imagining threats" much. If I have to start
> paying 2500 per year for my block of 5 networks I won't be able to keep
> them.

But no one has proposed that you pay $2,500 per year for 5x/24, so this is
purely scare mongering.

> This has gone beyond the scope of NANOG;s charter so please redirect this
> to personal mail.

The list on which this particular scare mongering is squashed weekly is
naipr at internic.net.

randy




From michael at memra.com  Thu Mar 20 05:07:56 1997
From: michael at memra.com (Michael Dillon)
Date: Wed, 19 Mar 1997 21:07:56 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <199703200325.WAA15937@netsys.com>
Message-ID: <Pine.BSI.3.93.970319210158.28844H-100000@sidhe.memra.com>

On Wed, 19 Mar 1997, Len Rose wrote:

> So.. how many people here have domains predating the NIC contracts, who
> politely objected to paying and got their domains put on hold this week?

One notably vocal opponent of domain name charges is hedging his bets or
so it seems. Whois shows that MCS.NET is OK but MCS.COM is on hold.

Seems to me that somebody has to pay for the service and I'd rather pay
for it myself rather than have the U.S. taxpayer foot the bill. Note that
I am NOT a U.S. taxpayer, not yet anyway. But that saying about no
taxation without representation cuts both ways. I'm quite happy to see the
tax money, and therefore the U.S. government, out of the loop. Some things
are just done better by private enterprise. You'll note that the closer we
get to the end of the NSI monopoly on .COM/.NET/.ORG domain names, the
better their service is getting to be.

Operationally speaking, I'd rather pay my money and be assured that the
service would work reliably and consistently.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From repstein at user.host.net  Thu Mar 20 05:14:18 1997
From: repstein at user.host.net (repstein)
Date: Thu, 20 Mar 1997 00:14:18 -0500 (EST)
Subject: Domain Rant.
In-Reply-To: <199703200325.WAA15937@netsys.com>
Message-ID: <Pine.LNX.3.93.970320001338.2955A-100000@user.host.net>

About 5 of my domains that predate Sept. 13th, 1995 were put on hold, and
guess what?  Removal notices just arrived.  Talk about quick.

-Randy 

On Wed, 19 Mar 1997, Len Rose wrote:

> 
> So.. how many people here have domains predating the NIC contracts, who
> politely objected to paying and got their domains put on hold this week?
> 
> Len
> 
> 





From matthew at scruz.net  Thu Mar 20 05:23:58 1997
From: matthew at scruz.net (Matthew Kaufman)
Date: Wed, 19 Mar 1997 21:23:58 -0800
Subject: Domain Rant.
In-Reply-To: randy@psg.com (Randy Bush)
       "Re: Domain Rant." (Mar 19, 20:31)
Message-ID: <199703200523.VAA14288@scruz.net>

So start paying the operators of the root nameservers for their services.
I find the root nameservers to be vastly more useful than where my
money appears to be going.

-matthew kaufman

Original message <m0w7ZVP-0007zWC at rip.psg.com>
From: randy at psg.com (Randy Bush)
Date: Mar 19, 20:31
Subject: Re: Domain Rant.
> 
> > So.. how many people here have domains predating the NIC contracts, who
> > politely objected to paying and got their domains put on hold this week?
> 
> Not we.  We don't expect a free lunch.
> 
> randy
>-- End of excerpt from Randy Bush







From indus at professionals.com  Thu Mar 20 07:09:14 1997
From: indus at professionals.com (Sanjay Dani (maillists))
Date: Wed, 19 Mar 1997 23:09:14 -0800 (PST)
Subject: Domain Rant.
Message-ID: <199703200709.XAA29040@osprey.professionals.com>


> Seems to me that somebody has to pay for the service and I'd rather pay
> for it myself rather than have the U.S. taxpayer foot the bill. Note that
> I am NOT a U.S. taxpayer, not yet anyway. But that saying about no
> taxation without representation cuts both ways. I'm quite happy to see the
> tax money, and therefore the U.S. government, out of the loop.

Inferencing the US govt. is out of the loop is a logical leap
of faith. Tell me who owns the "." and why wouldn't the Feds
of some denomination step in to "stabilize" the namespace.
In other words, why would they risk such a valuable resource,
built in the past with US taxpayer money, walk away to a
potentially non-US private enterprise or a consortium.

I'm just pointing out one more plausible outcome, not meaning
to argue.

Regards,
Sanjay.




From rudy at hcl.com  Thu Mar 20 07:28:57 1997
From: rudy at hcl.com (Rudy Amid)
Date: Thu, 20 Mar 1997 02:28:57 -0500
Subject: NANOG 10 
Message-ID: <26141785.0@hclmail.hcl.com>

Go to Toronto, Canada then!  Summers are nice here.  It can be as warm as the
Sahara desert. :)

There are so many ISPs here in Toronto alone, they may benefit from NANOG's
wisdom.

---
Rudy Amid (rudy at hcl.com), Systems "I'm IT!" Administrator     NB: IMHO!
>/` Hummingbird Communications, Ltd.  1 Sparks Ave. Toronto, Ont.        __
"   Canada. M2H 2W1. 416-496-2200 Fax 496-2207 [URL] http://www.hcl.com  |
PGP key fingerprint is on my home page at http://www.warped.com/~radix  \_)



----------
> From: Len Rose <len at netsys.com>
> To: nanog at home.merit.edu
> Subject: Re: NANOG 10 
> Date: Tuesday, March 18, 1997 4:33 PM
> 
> Who in their right mind would want to go to Florida in the middle of
> summer?
> 
> Len
> 
> 
> len at netsys.com
> http://www.netsys.com




From magibson at netcom.ca  Thu Mar 20 13:50:52 1997
From: magibson at netcom.ca (Michael Gibson)
Date: Thu, 20 Mar 1997 08:50:52 -0500
Subject: NANOG 10
References: <26141785.0@hclmail.hcl.com>
Message-ID: <333140BC.3A59@netcom.ca>

Rudy Amid wrote:
> 
> Go to Toronto, Canada then!  Summers are nice here.  It can be as warm as the
> Sahara desert. :)
> 
> There are so many ISPs here in Toronto alone, they may benefit from NANOG's
> wisdom.
> 
> ---
> Rudy Amid (rudy at hcl.com), Systems "I'm IT!" Administrator     NB: IMHO!
> >/` Hummingbird Communications, Ltd.  1 Sparks Ave. Toronto, Ont.        __
> "   Canada. M2H 2W1. 416-496-2200 Fax 496-2207 [URL] http://www.hcl.com  |
> PGP key fingerprint is on my home page at http://www.warped.com/~radix  \_)
> 
> ----------
> > From: Len Rose <len at netsys.com>
> > To: nanog at home.merit.edu
> > Subject: Re: NANOG 10
> > Date: Tuesday, March 18, 1997 4:33 PM
> >
> > Who in their right mind would want to go to Florida in the middle of
> > summer?
> >
> > Len
> >
> >
> > len at netsys.com
> > http://www.netsys.com

Agreed, Toronto would be the ideal location.


Michael Gibson
Sr. Network Admin - Netcom Canada




From id at CC.McGill.CA  Thu Mar 20 14:17:17 1997
From: id at CC.McGill.CA (Ian Duncan)
Date: Thu, 20 Mar 1997 09:17:17 -0500 (EST)
Subject: NANOG 10
In-Reply-To: <333140BC.3A59@netcom.ca>
Message-ID: <Pine.SOL.3.91.970320090754.6163A-100000@amaretto.cc.mcgill.ca>

On Thu, 20 Mar 1997, Michael Gibson wrote:
>
> Rudy Amid wrote:
> > 
> > Go to Toronto, Canada then!  Summers are nice here.  It can be as warm as the
> > Sahara desert. :)
> > 
> > There are so many ISPs here in Toronto alone, they may benefit from NANOG's
> > wisdom.

[ ... ]

> Agreed, Toronto would be the ideal location.
> 

I think it'd be great to see NANOG happen regularly north of 49.  But
ideal locations include a generous sponsor who'll handle some significant
hassles and expenses--suggestions?
--
    --
    Ian Duncan <id at CC.McGill.CA>
    Constructive Advice 





From wbn at merit.edu  Thu Mar 20 14:36:54 1997
From: wbn at merit.edu (William B. Norton)
Date: Thu, 20 Mar 1997 09:36:54 -0500 (EST)
Subject: NANOG 10
Message-ID: <199703201436.JAA23497@home.merit.edu>


At 08:50 AM 3/20/97 -0500, Michael Gibson wrote:
>Agreed, Toronto would be the ideal location.

In fact I was approached by a couple of Canadians eh ;-) looking to explore
hosting a future NANOG.  I still need to work with them on initial
recommendations (hotel and room availability, data needs, transportation
issues, etc.), but the locations discussed were Vancouver and Toronto.  As
mentioned before, all we need is a sponsor to step up to the plate.

Another North American possibility to explore would be Mexico. I personally
don't know the state of Internet connectivity there, or if it even makes
sense; only a couple of .mx folks come to NANOG now.

Bill

--------------------------------------------------------------
William B. Norton	<wbn at merit.edu>		(313) 764-9430





From geboykin at SCSnet.Com  Thu Mar 20 14:24:41 1997
From: geboykin at SCSnet.Com (Greg Boykin)
Date: Thu, 20 Mar 1997 08:24:41 -0600 (CST)
Subject: NANOG 10
In-Reply-To: <c=US%a=ATTMAIL%p=SOUTHERN%l=Internet_Mail-970320142726Z-7693@sa064460.scsa.scsnet.com>
Message-ID: <Pine.SOL.3.91.970320082150.16249B-100000@scsx86.scsb.scsnet.com>



On Thu, 20 Mar 1997, Ian Duncan wrote:
> 
> I think it'd be great to see NANOG happen regularly north of 49.  But
> ideal locations include a generous sponsor who'll handle some
> significant
> hassles and expenses--suggestions?

What about Network Solutions Inc. coughing up some of
the domain$$$ for first class flight for everyone and
something more than a continental breakfast?

-Greg-
geboykin at scsnet.com




From michael at memra.com  Thu Mar 20 14:47:37 1997
From: michael at memra.com (Michael Dillon)
Date: Thu, 20 Mar 1997 06:47:37 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <199703200709.XAA29040@osprey.professionals.com>
Message-ID: <Pine.BSI.3.93.970320064103.28844J-100000@sidhe.memra.com>

On Wed, 19 Mar 1997, Sanjay Dani wrote:

> Inferencing the US govt. is out of the loop is a logical leap
> of faith. Tell me who owns the "." and why wouldn't the Feds
> of some denomination step in to "stabilize" the namespace.

Because "stepping in" often leads to more destabilization. Why didn't the
Feds of some denomination step in to stabilize Albania? Right now the
Internet industry, which includes the research institutions, is doing just
fine by itself. If it ain't broke why would governments want to fix it? In
the USA there is one person who has learned that lesson very well. Compare
Ira Magaziner's position on the Internet to his position on health care.

> In other words, why would they risk such a valuable resource,
> built in the past with US taxpayer money, walk away to a
> potentially non-US private enterprise or a consortium.

Because it has already happened several years ago and the end result was
an incredibly energetic new industry in which U.S. companies and U.S.
research institutions are playing a key role. Tight central control was
tried in the ex-SU and it didn't work.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From michael at memra.com  Thu Mar 20 15:02:05 1997
From: michael at memra.com (Michael Dillon)
Date: Thu, 20 Mar 1997 07:02:05 -0800 (PST)
Subject: NANOG 13
In-Reply-To: <333140BC.3A59@netcom.ca>
Message-ID: <Pine.BSI.3.93.970320065351.28844M-100000@sidhe.memra.com>

On Thu, 20 Mar 1997, Michael Gibson wrote:

> > Go to Toronto, Canada then!  Summers are nice here.  It can be as warm
> > as the Sahara desert. :) 

Don't kid yourself. Toronto summers aren't any different from any other
Great Lakes city like Rochester, Buffalo, Ann Arbor. The Sahara is HOT and
DRY.

> Agreed, Toronto would be the ideal location.

Here's what you do then. NANOG 13 will be held in June of 1998, right? 
Torontonians aren't afraid of lucky 13 are they? So dig up a sponsor
like Rogers Network Services who is willing to throw a bit of money into
the pot, get them to read http://www.nanog.org/tips.html so they have a
vague idea of what is needed and get them to send some email to
wbn at merit.edu 

Make sure you do the planning on this with more lead time than traditional
NANOG meetings because, although Americans can just waltz through the
border anytime with merely a birth certificate, people who are not
American citizens may need to get a visa depending on their country of
origin.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From markb at infi.net  Thu Mar 20 05:01:30 1997
From: markb at infi.net (Mark Borchers)
Date: Thu, 20 Mar 1997 10:01:30 +0500
Subject: Domain Rant.
Message-ID: <199703201503.KAA10798@mh004.infi.net>


> At 7:25 PM -0800 3/19/97, Len Rose wrote:
> >So.. how many people here have domains predating the NIC contracts, who
> >politely objected to paying and got their domains put on hold this week?
> 
> 	My objections were not polite, but I paid since I can't afford the
> service interruption.
> 
> 	Always interesting to see monopoly forces at work...
> 
> d/


$50/year seems pretty reasonable for monopolistic pricing.




From dirk at power.net  Thu Mar 20 15:21:25 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Thu, 20 Mar 1997 07:21:25 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <199703201503.KAA10798@mh004.infi.net>
Message-ID: <Pine.LNX.3.95.970320071239.307B-100000@hermosa.power.net>


$50/year is outrageous and does reflect monopolistic pricing. 

Real costs are probably <$1 onetime and cents/year. So $49+/year are a tax
in disguise from an entitiy that has no right to tax. Emotionally, it
feels like extortion. Which is one reason people get mad at InterNIC.

It's not the amount.  I'd happily pay the same amount to the NSF for being
willing to jumpstart the Internet.

Dirk

On Thu, 20 Mar 1997, Mark Borchers wrote:

> 
> > At 7:25 PM -0800 3/19/97, Len Rose wrote:
> > >So.. how many people here have domains predating the NIC contracts, who
> > >politely objected to paying and got their domains put on hold this week?
> > 
> > 	My objections were not polite, but I paid since I can't afford the
> > service interruption.
> > 
> > 	Always interesting to see monopoly forces at work...
> > 
> > d/
> 
> 
> $50/year seems pretty reasonable for monopolistic pricing.
> 





From cym at acrux.net  Thu Mar 20 15:49:38 1997
From: cym at acrux.net (Brian Tackett)
Date: Thu, 20 Mar 1997 09:49:38 -0600 (CST)
Subject: Domain Rant.
In-Reply-To: <199703200709.XAA29040@osprey.professionals.com>
Message-ID: <Pine.GSO.3.93.970320094828.17740A-100000@pluto>



<whole thread snipped>

 Folks, I got off NAIPR because I didn't want to keep seeing the same
issues hashed over again and again. Am I going to havr to get off nanog
for the same reason now? This thread should die in it's tracks.





From netsurf at pixi.com  Thu Mar 20 06:11:21 1997
From: netsurf at pixi.com (NetSurfer)
Date: Thu, 20 Mar 1997 06:11:21 -0000
Subject: Domain Rant.
Message-ID: <199703201611.GAA22821@mail.pixi.com>


If you think $50 is bad, just wait and see if the $20,000/year/domain goes
through...


#include <standard.disclaimer>
                    _   __     __  _____            ____
                   / | / /__  / /_/ ___/__  _______/ __/__  _____
                  /  |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/
                 / /|  /  __/ /_ ___/ / /_/ / /  / __/  __/ /
================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/===============


----------
From: Randy Bush <randy at psg.com>
To: nanog at merit.edu
Subject: Re: Domain Rant.
Date: Wednesday, March 19, 1997 6:00 PM

> So.. how many people here have domains predating the NIC contracts, who
> politely objected to paying and got their domains put on hold this week?

Not we.  We don't expect a free lunch.

randy




From planting at vfi.com  Thu Mar 20 17:17:11 1997
From: planting at vfi.com (Paul R.D. Lantinga)
Date: Thu, 20 Mar 1997 09:17:11 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <199703201611.GAA22821@mail.pixi.com>
Message-ID: <Pine.LNX.3.95.970320091546.17967G-100000@wacky.eit.com>

Gee, netsurf, what a cool name!  For a second there, I thought htat it
wasn't your real name and that you were looking for a bbs or a warez site
and accidentally stumbled onto nanog.  My bad.

-- 
Paul R.D. Lantinga  #planting at vfi.com#
Systems Administrator, Verifone IC 
"...'proactive' and 'paradigm', aren't these just buzzwords 
that dumb people use to sound important?"-The Simpsons


On Thu, 20 Mar 1997, NetSurfer wrote:

> 
> If you think $50 is bad, just wait and see if the $20,000/year/domain goes
> through...
> 
> 
> #include <standard.disclaimer>
>                     _   __     __  _____            ____
>                    / | / /__  / /_/ ___/__  _______/ __/__  _____
>                   /  |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/
>                  / /|  /  __/ /_ ___/ / /_/ / /  / __/  __/ /
> ================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/===============
> 
> 
> ----------
> From: Randy Bush <randy at psg.com>
> To: nanog at merit.edu
> Subject: Re: Domain Rant.
> Date: Wednesday, March 19, 1997 6:00 PM
> 
> > So.. how many people here have domains predating the NIC contracts, who
> > politely objected to paying and got their domains put on hold this week?
> 
> Not we.  We don't expect a free lunch.
> 
> randy
> 





From paul at vix.com  Thu Mar 20 17:51:05 1997
From: paul at vix.com (Paul A Vixie)
Date: Thu, 20 Mar 1997 09:51:05 -0800
Subject: Domain Rant. 
Message-ID: <199703201751.JAA22374@wisdom.home.vix.com>

hey, a content free rant fest.  "these are a few of my favorite things..."

> Seems to me that somebody has to pay for the service and I'd rather pay
> for it myself rather than have the U.S. taxpayer foot the bill. 

Indeed.  When you let a taxpayer buy something for you, then the so-called
representatives of that taxpayer get to make decisions about the service,
and sometimes those decisions have a lot of social engineering built in.
Far better to get something done without this kind of government value-add.

> So start paying the operators of the root nameservers for their services.
> I find the root nameservers to be vastly more useful than where my
> money appears to be going.

Network Solutions paid for the hardware I now run F.ROOT-SERVERS.NET on.  I
reached a certain point where I could not afford to buy the next 512MB of RAM
out of ISC funds.  So from my point of view, domain holders who send money to
Network Solutions are doing the right thing, no matter what the original
contract may have said.

> Inferencing the US govt. is out of the loop is a logical leap of
> faith. Tell me who owns the "." and why wouldn't the Feds of some
> denomination step in to "stabilize" the namespace.  

They will try, but since it's not a defense issue noone will take them
seriously.

> In other words, why would they risk such a valuable resource, built in the
> past with US taxpayer money, walk away to a potentially non-US private
> enterprise or a consortium.

They can and would do this with .MIL and .GOV, but the others don't point at
any resources that they own, and point at many resources owned by citizens
of countries where treaties are in effect.  They will at some point take over
.US, but the process of government intervention in the affairs of "." will
take every bit as long as the one which led to the international allocation
of radio frequency spectrums.

> $50/year is outrageous and does reflect monopolistic pricing. 

if i had to do it, i'd end up burning $25 of it on the accounts receivable
process and the other $25 of it on legal fees and end up with nothing.  so,
as a root name server operator, i am happy as hell not to be in this loop.

> If you think $50 is bad, just wait and see if the $20,000/year/domain goes
> through...

i havn't heard that one.  i think you're confused about top level domains vs.
second level domains.




From perry at piermont.com  Thu Mar 20 17:42:25 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Thu, 20 Mar 1997 12:42:25 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 06:11:21 GMT."
             <199703201611.GAA22821@mail.pixi.com> 
Message-ID: <199703201742.MAA02396@jekyll.piermont.com>


"NetSurfer" writes:
> If you think $50 is bad, just wait and see if the $20,000/year/domain goes
> through...

Since no one has proposed that, its unlikely that it will happen.

Perry




From pjnesser at martigny.ai.mit.edu  Thu Mar 20 18:57:28 1997
From: pjnesser at martigny.ai.mit.edu (Philip J. Nesser II)
Date: Thu, 20 Mar 1997 13:57:28 -0500 (EST)
Subject: NANOG 10
In-Reply-To: <Pine.SOL.3.91.970320082150.16249B-100000@scsx86.scsb.scsnet.com> from "Greg Boykin" at Mar 20, 97 08:24:41 am
Message-ID: <199703201857.AA134464249@martigny.ai.mit.edu>

Greg Boykin supposedly said:
> 
> 
> 
> On Thu, 20 Mar 1997, Ian Duncan wrote:
> > 
> > I think it'd be great to see NANOG happen regularly north of 49.  But
> > ideal locations include a generous sponsor who'll handle some
> > significant
> > hassles and expenses--suggestions?
> 
> What about Network Solutions Inc. coughing up some of
> the domain$$$ for first class flight for everyone and
> something more than a continental breakfast?
> 


Why do people seem to think that they have any right to any money NSI has
made off of domain registrations?  Why not pick on Cisco? or Sun? or any of
the other countless companies that have made billions in profit on the
Internet as well?  NSI just happened to be sitting in the right place at
the right time.  Do I wish I was sitting there?  You bet.  Anyone could
have bid for that contract four years ago, but most people didn't want to
touch the job with a ten foot pole.

And even if we could get NSI to cough up some money to the common good, 500
first class tickets and elaborate breakfasts are about the last thing that
I would suggest we use the money for.


--->  Phil

P.S.  My only affiliation with NSI is when I send them checks to pay for my
domains.  




From gherbert at crl.com  Thu Mar 20 20:13:50 1997
From: gherbert at crl.com (George Herbert)
Date: Thu, 20 Mar 1997 12:13:50 -0800
Subject: Domain Rant. 
Message-ID: <199703202013.AA15791@mail.crl.com>


Whether or not InterNIC feels like putting people who haven't
paid on hold, doing so to people who have paid is completely
irresponsible.  Despite having cancelled check literally in hand,
I'm on hold.  I got a notice 10 days ago and sent them a response
that i had the cancelled check.  TODAY, they put me on hold and said 
"sorry, we have no record of this, please send us the check
date and details" rather than ask me that first and then
put me on hold if I couldn't provide them.

I will be lobbying to have InterNICs contract voided immediately
for failure to keep proper records and act in a responsible
manner with its fee operations if this goes on.  The "is registry
something that is charged for" debate is one thing, but gross
mismanagement is another.


-george william herbert
gherbert at crl.com






From michael at memra.com  Thu Mar 20 20:35:33 1997
From: michael at memra.com (Michael Dillon)
Date: Thu, 20 Mar 1997 12:35:33 -0800 (PST)
Subject: Domain Rant. 
In-Reply-To: <199703202013.AA15791@mail.crl.com>
Message-ID: <Pine.BSI.3.93.970320123238.28844t-100000@sidhe.memra.com>

On Thu, 20 Mar 1997, George Herbert wrote:

> I will be lobbying to have InterNICs contract voided immediately
> for failure to keep proper records and act in a responsible
> manner with its fee operations if this goes on.  The "is registry
> something that is charged for" debate is one thing, but gross
> mismanagement is another.

They seem to have a few technical problems there today. Their whois
servers are no longer returning contact info for domains and the
webserver for www.internic.net is down.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From cameo at corp.idt.net  Thu Mar 20 21:00:47 1997
From: cameo at corp.idt.net (Cameo Wood)
Date: Thu, 20 Mar 1997 16:00:47 -0500 (EST)
Subject: Internic slightly broken
Message-ID: <Pine.GSO.3.95.970320155855.21293C-100000@hq.idt.net>

Seems that you do an inquiry on any domain, through whois or telnet
directly, and it stops at Administrative contact.  Seems like we might
have a small problem.

InterNIC > 
[vt100] InterNIC > whois internic.net
Connecting to the rs Database . . . . . .
Connected to the rs Database
Network Solutions, Inc. (INTERNIC-DOM)
   505 Huntmar Park Drive
   Herndon, VA 20170

   Domain Name: INTERNIC.NET

   Administrative Contact[vt100] InterNIC > 

  ______ 
  \____/  IDT Corporation               E-mail:     cameo at corp.idt.net
   \__/      Cameo Wood                  Phone:     +1 201 928 2889 
    \/  Network Management Engineer      Pager:     800 225 0256 x 85-452 





From hchen at aimnet.net  Fri Mar 21 00:15:12 1997
From: hchen at aimnet.net (Hong Chen)
Date: Thu, 20 Mar 1997 16:15:12 -0800 (PST)
Subject: Domain Rant. 
In-Reply-To: <199703202013.AA15791@mail.crl.com>
Message-ID: <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>


Yes, we have to do something about it. Recently, I have seen 
several large ISPs got affected by Internic. 

I know for sure that both Aimnet.net and Internex.net are
putting on hold, despite the fact that Aimnet.net already 
paid and our check was cashed 2 days before they put us 
on hold. 

You just cannot imagine how many our customers are getting
affected. CRL, Aimnet, and Internex likes are major ISPs with
hundred and thousands of corporate customers using their 
services.

George, we are fully behind you on this. 



Hong Chen				408-567-3800 (tel)
hchen at aimnet.net			408-567-0990 (fax)

On Thu, 20 Mar 1997, George Herbert wrote:

> 
> Whether or not InterNIC feels like putting people who haven't
> paid on hold, doing so to people who have paid is completely
> irresponsible.  Despite having cancelled check literally in hand,
> I'm on hold.  I got a notice 10 days ago and sent them a response
> that i had the cancelled check.  TODAY, they put me on hold and said 
> "sorry, we have no record of this, please send us the check
> date and details" rather than ask me that first and then
> put me on hold if I couldn't provide them.
> 
> I will be lobbying to have InterNICs contract voided immediately
> for failure to keep proper records and act in a responsible
> manner with its fee operations if this goes on.  The "is registry
> something that is charged for" debate is one thing, but gross
> mismanagement is another.
> 
> 
> -george william herbert
> gherbert at crl.com
> 
> 
> 





From karl at Mcs.Net  Fri Mar 21 00:27:19 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 18:27:19 -0600
Subject: Domain Rant.
In-Reply-To: <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>; from Hong Chen on Thu, Mar 20, 1997 at 04:15:12PM -0800
References: <199703202013.AA15791@mail.crl.com> <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>
Message-ID: <19970320182719.21233@Jupiter.Mcs.Net>

Its time to move on to eDNS folks.

Give YOURSELF a choice when someone does this kind of thing to you.

Would you tolerate no options in who you buy connectivity and hardware from?
No?  Then why do you tolerate it in the DNS business?

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal


On Thu, Mar 20, 1997 at 04:15:12PM -0800, Hong Chen wrote:
> 
> Yes, we have to do something about it. Recently, I have seen 
> several large ISPs got affected by Internic. 
> 
> I know for sure that both Aimnet.net and Internex.net are
> putting on hold, despite the fact that Aimnet.net already 
> paid and our check was cashed 2 days before they put us 
> on hold. 
> 
> You just cannot imagine how many our customers are getting
> affected. CRL, Aimnet, and Internex likes are major ISPs with
> hundred and thousands of corporate customers using their 
> services.
> 
> George, we are fully behind you on this. 
> 
> 
> 
> Hong Chen				408-567-3800 (tel)
> hchen at aimnet.net			408-567-0990 (fax)
> 
> On Thu, 20 Mar 1997, George Herbert wrote:
> 
> > 
> > Whether or not InterNIC feels like putting people who haven't
> > paid on hold, doing so to people who have paid is completely
> > irresponsible.  Despite having cancelled check literally in hand,
> > I'm on hold.  I got a notice 10 days ago and sent them a response
> > that i had the cancelled check.  TODAY, they put me on hold and said 
> > "sorry, we have no record of this, please send us the check
> > date and details" rather than ask me that first and then
> > put me on hold if I couldn't provide them.
> > 
> > I will be lobbying to have InterNICs contract voided immediately
> > for failure to keep proper records and act in a responsible
> > manner with its fee operations if this goes on.  The "is registry
> > something that is charged for" debate is one thing, but gross
> > mismanagement is another.
> > 
> > 
> > -george william herbert
> > gherbert at crl.com
> > 
> > 
> > 
> 




From geoffw at precipice.v-site.net  Fri Mar 21 00:47:23 1997
From: geoffw at precipice.v-site.net (Geoff White)
Date: Thu, 20 Mar 1997 16:47:23 -0800 (PST)
Subject: Domain Rant. 
In-Reply-To: <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>
Message-ID: <Pine.SUN.3.95.970320164459.2842G-100000@precipice.v-site.net>

> On Thu, 20 Mar 1997, George Herbert wrote:
> 
> > 
> > Whether or not InterNIC feels like putting people who haven't
> > paid on hold, doing so to people who have paid is completely
> > irresponsible.  Despite having cancelled check literally in hand,
> > I'm on hold.  I got a notice 10 days ago and sent them a response
> > that i had the cancelled check.  TODAY, they put me on hold and said 
> > "sorry, we have no record of this, please send us the check
> > date and details" rather than ask me that first and then
> > put me on hold if I couldn't provide them.
> > 
> > I will be lobbying to have InterNICs contract voided immediately
> > for failure to keep proper records and act in a responsible
> > manner with its fee operations if this goes on.  The "is registry
> > something that is charged for" debate is one thing, but gross
> > mismanagement is another.


I too have been affected by this. After paying for domain names months
ago.
The internic is telling me that they didn't receive payment.
This is down right incompetant to say the least.  People pay their money
and then the burden of proof is on THEM? This is total Bulls*it.


					Geoff White
					Virtual Sites






From gherbert at crl.com  Fri Mar 21 00:53:14 1997
From: gherbert at crl.com (George Herbert)
Date: Thu, 20 Mar 1997 16:53:14 -0800
Subject: Domain Rant. 
Message-ID: <199703210053.AA25054@mail.crl.com>


I should clarify, this didn't happen to CRL domains (that I know of);
I'm an end user at CRL at this point, not an employee, and as such
of course I don't speak for CRL on this issue...  The domain in
question was mine (my other, non-computer related business actually...).

However, I am getting plenty of private mail that ISPs and their
customers were affected like my personal domain by InterNIC records
problems with the billing, as well as the public responses to the
nanog list here.  It is apparent that InterNIC has a serious problem
of major scale here: they do not have accurate records of who has
paid and who has not, and are acting as though they did and thus
denying services to a number of people whose money they took.
That is not good behaviour in the best of circumstances.


-george william herbert
gherbert at crl.com





From paul at vix.com  Fri Mar 21 00:57:51 1997
From: paul at vix.com (Paul A Vixie)
Date: Thu, 20 Mar 1997 16:57:51 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 18:27:19 CST."
             <19970320182719.21233@Jupiter.Mcs.Net> 
Message-ID: <199703210057.QAA31961@wisdom.home.vix.com>

> Would you tolerate no options in who you buy connectivity and hardware from?
> No?  Then why do you tolerate it in the DNS business?

Because there can be only one authority for ".".

I don't like the one we have but I like your proposal even less.

IAHC's proposal fixes the problem folks are seeing with NS today.





From karl at Mcs.Net  Fri Mar 21 01:46:55 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 19:46:55 -0600
Subject: Domain Rant.
In-Reply-To: <199703210057.QAA31961@wisdom.home.vix.com>; from Paul A Vixie on Thu, Mar 20, 1997 at 04:57:51PM -0800
References: <19970320182719.21233@Jupiter.Mcs.Net> <199703210057.QAA31961@wisdom.home.vix.com>
Message-ID: <19970320194655.05290@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 04:57:51PM -0800, Paul A Vixie wrote:
> > Would you tolerate no options in who you buy connectivity and hardware from?
> > No?  Then why do you tolerate it in the DNS business?
> 
> Because there can be only one authority for ".".
> 
> I don't like the one we have but I like your proposal even less.
> 
> IAHC's proposal fixes the problem folks are seeing with NS today.

No it doesn't.

If you register with someone, pay them, and they claim never to have
received payment you're just as screwed.  They hold or delete your 
record and you end up paying again.

What is it that you dislike about eDNS Paul?  I'd love to see some actual
substantive criticism (as opposed to "IAHC is God") of the policy points.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From stf at altair.com  Fri Mar 21 02:06:32 1997
From: stf at altair.com (Steve Ferguson)
Date: Thu, 20 Mar 1997 21:06:32 -0500 (EST)
Subject: Domain Rant. 
In-Reply-To: <Pine.SUN.3.95.970320164459.2842G-100000@precipice.v-site.net>
Message-ID: <Pine.LNX.3.95.970320210517.7688A-100000@pc125>

Add us to the list of 'paid and put on hold'.  We host ipdmug.org, which
recently had the same thing happen.  You can guess what a burden it was to
finally get matters resolved.

Steve

--
Steve Ferguson                   | Altair Computing, Inc.
Systems Analyst                  | Troy, MI 48084
E-mail: stf at altair.com           | USA
WWW: http://www.altair.com/      | 810/614-2400





From dcrocker at imc.org  Fri Mar 21 01:39:00 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Thu, 20 Mar 1997 17:39:00 -0800
Subject: Domain Rant.
In-Reply-To: <19970320182719.21233@Jupiter.Mcs.Net>
References: <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>; from
 Hong Chen on Thu, Mar 20, 1997 at 04:15:12PM -0800
 <199703202013.AA15791@mail.crl.com>
 <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>
Message-ID: <v03102230af5796d7af15@[205.214.160.78]>

At 4:27 PM -0800 3/20/97, Karl Denninger wrote:
>Give YOURSELF a choice when someone does this kind of thing to you.

	The choice you are referring to is which monopoly will control the
name the user rents, rather that ensuring that there are alternatives which
can support the SAME name.

d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From dcrocker at imc.org  Fri Mar 21 02:37:42 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Thu, 20 Mar 1997 18:37:42 -0800
Subject: Domain Rant.
In-Reply-To: <19970320194655.05290@Jupiter.Mcs.Net>
References: <199703210057.QAA31961@wisdom.home.vix.com>; from Paul A Vixie
 on Thu, Mar 20, 1997 at 04:57:51PM -0800
 <19970320182719.21233@Jupiter.Mcs.Net>
 <199703210057.QAA31961@wisdom.home.vix.com>
Message-ID: <v03102231af57a3b8b699@[205.214.160.78]>

At 5:46 PM -0800 3/20/97, Karl Denninger wrote:
>What is it that you dislike about eDNS Paul?  I'd love to see some actual
>substantive criticism (as opposed to "IAHC is God") of the policy points.

	you've seen it, you just won't admit it.

	you are setting up additional monopolies.  monopolies over critical
resources are to be avoided wherever possible.  the problem for you, here,
of course, is that monopolies over critical resources can incur windfall
profits.  you want to allow that.  the iahc doen't.

	you are attempting to coopt an established administrative structure
that has worked well for 10 years, rather than to work contructively on its
enhancements.

	you are holding yourself beyond accountability

	you are pretending that the DNS gTLD space is a US resource rather
than one that is global.

	no doubt there are more substantive criticisms, but one grows weary
and the list is long enough.

d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From indus at professionals.com  Fri Mar 21 03:01:16 1997
From: indus at professionals.com (Sanjay Dani (maillists))
Date: Thu, 20 Mar 1997 19:01:16 -0800 (PST)
Subject: Domain Rant.
Message-ID: <199703210301.TAA11406@osprey.professionals.com>


> Add us to the list of 'paid and put on hold'.  We host ipdmug.org, which
> recently had the same thing happen.  You can guess what a burden it was to
> finally get matters resolved.

I know this does not exactly belong here, several
of our customers have reported spending days on hold
just trying to reach a person at Network Solutions so
their paid domain will not go on hold. I have heard
from three such customers just today morning.

It is worse if you paid for more than one domain in
a single credit card transaction. There is no email
receipt or a record that matches the money paid to
a specific domain name.

If anyone has ideas how to get Network Solutions
to fix this operational problem _now_, so these
domains do not go off line, please post here.




From alex at nac.net  Fri Mar 21 02:47:35 1997
From: alex at nac.net (Alex Rubenstein)
Date: Thu, 20 Mar 1997 21:47:35 -0500 (EST)
Subject: Domain Rant.
In-Reply-To: <19970320194655.05290@Jupiter.Mcs.Net>
Message-ID: <Pine.NEB.3.95.970320214641.10811E-100000@duncan.nac.net>

> > 
> > Because there can be only one authority for ".".

I don't agree with this. 

It is quite possible for everyone to maintain ".". Then, there would be no
need for root domain servers; HOWEVER, this would take massive cooperation
throughout the industy, which will never happen. 







From rudy at hcl.com  Fri Mar 21 03:11:08 1997
From: rudy at hcl.com (Rudy Amid)
Date: Thu, 20 Mar 1997 22:11:08 -0500
Subject: Domain Rant.
Message-ID: <26212719.0@hclmail.hcl.com>

Len,

So why do you have a domain name if you can't "afford it"?  Don't
tell me you can't afford paying $50/year?  That's a year!  If you've
been spending all of your money every month and thinks that's expensive,
then perhaps you're not meant to be on the internet.

---
Rudy Amid (rudy at hcl.com), Systems "I'm IT!" Administrator     NB: IMHO!
>/` Hummingbird Communications, Ltd.  1 Sparks Ave. Toronto, Ont.        __
"   Canada. M2H 2W1. 416-496-2200 Fax 496-2207 [URL] http://www.hcl.com  |
PGP key fingerprint is on my home page at http://www.warped.com/~radix  \_)



----------
> From: Len Rose <len at netsys.com>
> To: Randy Bush <randy at psg.com>; nanog at merit.edu
> Subject: Re: Domain Rant.
> Date: Wednesday, March 19, 1997 11:46 PM
> 
> It's not about a free lunch.. It's called no involvement in the decision
> making process beforehand. I don't want to start any sort of flame war
> despite what it may appear -- seeing my domain on hold upset me. It is
> at least 11 years old.. I won't be able to afford my network space soon
> too if things keep going.
> 
> At 08:31 PM 3/19/97 PST, Randy Bush wrote:
> 
> [stuff deleted]
> 
> >Not we.  We don't expect a free lunch.
> >
> >randy
> >




From len at netsys.com  Fri Mar 21 03:12:52 1997
From: len at netsys.com (Len Rose)
Date: Thu, 20 Mar 1997 22:12:52 -0500
Subject: Domain Rant.
Message-ID: <3.0.32.19970320221251.00a644a0@netsys.com>

If you read my message, the "cannot afford" came from paying for network
space. There are plenty of reading programs in various adult education
facilities that will help you with comprehending the written word. Get
help now..

Len


At 10:11 PM 3/20/97 -0500, Rudy Amid wrote:
>Len,
>
>So why do you have a domain name if you can't "afford it"?  Don't
>tell me you can't afford paying $50/year?  That's a year!  If you've
>been spending all of your money every month and thinks that's expensive,
>then perhaps you're not meant to be on the internet.
>
>---
>Rudy Amid (rudy at hcl.com), Systems "I'm IT!" Administrator     NB: IMHO!
>>/` Hummingbird Communications, Ltd.  1 Sparks Ave. Toronto, Ont.        __
>"   Canada. M2H 2W1. 416-496-2200 Fax 496-2207 [URL] http://www.hcl.com  |
>PGP key fingerprint is on my home page at http://www.warped.com/~radix  \_)
>
[deleted]


len at netsys.com
http://www.netsys.com





From karl at Mcs.Net  Fri Mar 21 03:15:36 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 21:15:36 -0600
Subject: Domain Rant.
In-Reply-To: <v03102231af57a3b8b699@[205.214.160.78]>; from Dave Crocker on Thu, Mar 20, 1997 at 06:37:42PM -0800
References: <199703210057.QAA31961@wisdom.home.vix.com>; <19970320182719.21233@Jupiter.Mcs.Net> <199703210057.QAA31961@wisdom.home.vix.com> <v03102231af57a3b8b699@[205.214.160.78]>
Message-ID: <19970320211536.30264@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 06:37:42PM -0800, Dave Crocker wrote:
> At 5:46 PM -0800 3/20/97, Karl Denninger wrote:
> >What is it that you dislike about eDNS Paul?  I'd love to see some actual
> >substantive criticism (as opposed to "IAHC is God") of the policy points.
> 
> 	you've seen it, you just won't admit it.
> 
> 	you are setting up additional monopolies.  monopolies over critical
> resources are to be avoided wherever possible.  the problem for you, here,
> of course, is that monopolies over critical resources can incur windfall
> profits.  you want to allow that.  the iahc doen't.

Mr. Crocker, I really wish you'd stop posting material that just is not true
and that you *know* is in fact false.

eDNS enables *all* business models for registration of TLDs and SLDs.  
Not one, not two, not three.  It passes no judgement on which models are
appropriate, leaving that to the open marketplace.

Instead, it prevents any model or any organization from owning a "controlling
interest" in the namespace.  THAT is the public policy portion of eDNS.  It
is the only "policy" portion of eDNS which is actually enforced at the root
level.

> 	you are attempting to coopt an established administrative structure
> that has worked well for 10 years, rather than to work contructively on its
> enhancements.

18 months of working "constructively" got nowhere.  Eventually, the time
comes to change the structure.  Remember, the Internet credo is "rough
consensus and working code".  We have working code, and are building
consensus day by day.

> 	you are holding yourself beyond accountability

On the contrary.  I am one man, and the machine I run as a root is one
computer.  It is the only one which I own or control in the entire eDNS 
root structure, and will always be the only one.  I also have publically
refused to take a position with an RA organization, and will do so again 
if asked in the future.

Contrast this with the existing IANA roots, several of which are owned by
the existing monopoly registrar or have been partially or totally funded 
by them.  As an example, f.root-servers.net, which Paul Vixie has in his
control, he has admitted was partially or fully paid for by NSI.

Its tough to tell the person who pays the check every day "no".  Very, very
difficult.

My accountability is simple.  If I violate the process someone steps in and
my single machine gets replaced with another.  I have no authority or control 
over the root whatsoever.  Only consent of the people who use it, and who
operate the RAs and registries make the structure work.

I don't pretend to hold in my hand that which is not mine.

> 	you are pretending that the DNS gTLD space is a US resource rather
> than one that is global.

Nonsense.  The TLD namespace IS global.  There is nothing preventing non-US
interests from registering TLDs, and in fact more than one has (proof positive
that this statement is ALSO false).  There are currently registrars in Germany 
and Japan -- pretty much opposite "ends" of the world.

Proof follows and can be reproduced by anyone who does not believe me (eDNS 
delegations all have TXT records designating the RA and Registrar responsible
for their operation):

; <<>> DiG 2.2 <<>> txt jpn. 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 2
;; QUESTIONS:
;;	jpn, type = TXT, class = IN

;; ANSWERS:
jpn.	86400	TXT	"2-23-1-1038 ,Yoyogi,Shibuya-ku, 151, Tokyo, Japan"
jpn.	86400	TXT	"RA: Alternic / Shirokuma Publishing - Masafumi Yoshida <myoshida at po.iijnet.or.jp>"

;; AUTHORITY RECORDS:
jpn.	86400	NS	aragorn.alternic.net.
jpn.	86400	NS	nyc.alternic.net.
jpn.	86400	NS	mx.alternic.net.

;; ADDITIONAL RECORDS:
nyc.alternic.net.	86400	A	207.51.48.15
mx.alternic.net.	86400	A	204.94.42.1

;; Total query time: 6 msec
;; FROM: Jupiter.Mcs.Net to SERVER: default -- 192.160.127.90
;; WHEN: Thu Mar 20 21:10:19 1997
;; MSG SIZE  sent: 21  rcvd: 278


; <<>> DiG 2.2 <<>> txt ger. 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 2
;; QUESTIONS:
;;	ger, type = TXT, class = IN

;; ANSWERS:
ger.	86400	TXT	"Kennedyallee 89 Frankfurt, D-60596 GERMANY"
ger.	86400	TXT	"RA: Alternic / Callisto germany.net GMBH - Robert Hanke <robi at germany.net>"

;; AUTHORITY RECORDS:
ger.	172000	NS	aragorn.alternic.net.
ger.	172000	NS	nyc.alternic.net.
ger.	172000	NS	mx.alternic.net.

;; ADDITIONAL RECORDS:
nyc.alternic.net.	86400	A	207.51.48.15
mx.alternic.net.	86400	A	204.94.42.1

;; Total query time: 6 msec
;; FROM: Jupiter.Mcs.Net to SERVER: default -- 192.160.127.90
;; WHEN: Thu Mar 20 21:11:29 1997
;; MSG SIZE  sent: 21  rcvd: 264

These are new and not yet actually operational from my understanding, but
they ARE registered.  These two just happend to pop immediately to mind.

> 	no doubt there are more substantive criticisms, but one grows weary
> and the list is long enough.

If you remove the blatently and easily proven false statements which you
have made from consideration, you haven't posted a single substantive
criticism here.

--
-- 
Karl Denninger (karl at MCS.Net)| eDNS - The free-market solution
http://www.edns.net/	     | hostmaster at edns.net




From ekgermann at cctec.com  Fri Mar 21 03:19:41 1997
From: ekgermann at cctec.com (Eric Germann)
Date: Thu, 20 Mar 1997 22:19:41 -0500
Subject: Domain Rant.
Message-ID: <3.0.32.19970320221929.0076cc90@207.87.243.20>

Not to mention the fact their automated pay by CC over the phone scam
doesn't recognize their invoice numbers...

At 07:01 PM 3/20/97 -0800, maillists wrote:
>
>> Add us to the list of 'paid and put on hold'.  We host ipdmug.org, which
>> recently had the same thing happen.  You can guess what a burden it was to
>> finally get matters resolved.
>
>I know this does not exactly belong here, several
>of our customers have reported spending days on hold
>just trying to reach a person at Network Solutions so
>their paid domain will not go on hold. I have heard
>from three such customers just today morning.
>
>It is worse if you paid for more than one domain in
>a single credit card transaction. There is no email
>receipt or a record that matches the money paid to
>a specific domain name.
>
>If anyone has ideas how to get Network Solutions
>to fix this operational problem _now_, so these
>domains do not go off line, please post here.
>
>


============================================================================
====
Eric Germann				Computer and Communications Technologies
ekgermann at cctec.com			Van Wert, OH 45891
					Phone:	419 968 2640
http://www.cctec.com			Fax:	419 968 2641

Network Design, Connectivity & System Integration Services 
A Microsoft Solution Provider					




From avg at pluris.com  Fri Mar 21 03:39:14 1997
From: avg at pluris.com (Vadim Antonov)
Date: Thu, 20 Mar 1997 19:39:14 -0800
Subject: Domain Rant.
Message-ID: <199703210339.TAA03044@quest.pluris.com>


So far, that sounds like nice basis for a class action lawsuit.

Imagine a land title company throwing away records just because they
lost a payment receipt.  That's what InterNIC is doing.

My experience with InterNIC was that i managed to get hold of
actual person, and got assurances that everything's ok.  Then
i see nothing happened in the database, so i call again, and they
tell the information "is not there yet".  Now, i go to the automatic
system and make a card payment -- the system gives back authorization
code, etc.  Guess what.  It still says the domain registration is not paid.

I think it is time ISPs take the matter in their hands.  I.e. let ISPs
to perform registrations.  Root serer operators can ensure uniqueness
just fine.

--vadim




From pedro at orca.sitesonthe.net  Fri Mar 21 03:50:05 1997
From: pedro at orca.sitesonthe.net (Robert B. Evans)
Date: Thu, 20 Mar 1997 22:50:05 -0500 (EST)
Subject: Domain Rant. 
In-Reply-To: <Pine.SUN.3.95.970320164459.2842G-100000@precipice.v-site.net>
Message-ID: <Pine.SOL.3.95.970320224800.9582B-100000@orca>

Hello,
   I have had the same thing happen to me, but unfortunately it was on a
credit card, and having processed so many domains on that card, I am
unable to prove which domain it was, that didn't stop them from holding
the domain. My customer had to be up with thousands of dollars worth of
marketing collateral already printed. So we paid again. Please keep me
informed of ideas to solve the problem. I will think on it as well.
Robert Evans
sysadmin
GETtheNET, Inc.
332 W. Broadway
Suite 911
Louisville, KY 40202 
502 585 4638






From michael at memra.com  Fri Mar 21 04:06:16 1997
From: michael at memra.com (Michael Dillon)
Date: Thu, 20 Mar 1997 20:06:16 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <19970320194655.05290@Jupiter.Mcs.Net>
Message-ID: <Pine.BSI.3.93.970320200030.9278M-100000@sidhe.memra.com>

On Thu, 20 Mar 1997, Karl Denninger wrote:

> > IAHC's proposal fixes the problem folks are seeing with NS today.
> 
> No it doesn't.
> 
> If you register with someone, pay them, and they claim never to have
> received payment you're just as screwed.  They hold or delete your 
> record and you end up paying again.

My understanding is that the precise protocol used to register a new name
has not been frozen yet. This issue can be addressed if CORE requires a
non-repudiable transaction from a registrar in order to register a domain
or to update its payment status.

And even if the IAHC were so foolish as to not consider this possibility
they certainly did create a Policy Oversight Committee that can change
procedures at any time. 

http://www.iahc.org/draft-iahc-recommend-00.html

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From hchen at aimnet.net  Fri Mar 21 04:13:24 1997
From: hchen at aimnet.net (Hong Chen)
Date: Thu, 20 Mar 1997 20:13:24 -0800 (PST)
Subject: Domain Rant. 
In-Reply-To: <Pine.SOL.3.95.970320224800.9582B-100000@orca>
Message-ID: <Pine.SUN.3.95.970320200939.328A-100000@aimnet.net>



I really believe that the Internet is to the point where a
possible law suit will be brought up by someone. 

I just checked hinet.net, the internet service of Chunghwa
Telecom of Taiwan, who has close to half million users using 
the hinet.net, are put on hold. 

No wonder I can not send email to them. 

Hinet.net is similar to ATT Worldnet, and it is beyond my belief
that Internic is in the process of shutting the Internet down.


Hong Chen				408-567-3800 (tel)
hchen at aimnet.net			408-567-0990 (fax)

On Thu, 20 Mar 1997, Robert B. Evans wrote:

> Hello,
>    I have had the same thing happen to me, but unfortunately it was on a
> credit card, and having processed so many domains on that card, I am
> unable to prove which domain it was, that didn't stop them from holding
> the domain. My customer had to be up with thousands of dollars worth of
> marketing collateral already printed. So we paid again. Please keep me
> informed of ideas to solve the problem. I will think on it as well.
> Robert Evans
> sysadmin
> GETtheNET, Inc.
> 332 W. Broadway
> Suite 911
> Louisville, KY 40202 
> 502 585 4638
> 
> 
> 





From dcrocker at imc.org  Fri Mar 21 04:19:53 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Thu, 20 Mar 1997 20:19:53 -0800
Subject: Domain Rant.
In-Reply-To: <Pine.NEB.3.95.970320214641.10811E-100000@duncan.nac.net>
References: <19970320194655.05290@Jupiter.Mcs.Net>
Message-ID: <v03102233af57bcb597f9@[205.214.160.78]>

At 6:47 PM -0800 3/20/97, Alex Rubenstein wrote:
>It is quite possible for everyone to maintain ".". Then, there would be no

	as soon as one person's root has a different .com (or whatever)
then you have parititioned the net.

	there can be only one root.
d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From karl at Mcs.Net  Fri Mar 21 04:39:13 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 22:39:13 -0600
Subject: Domain Rant.
In-Reply-To: <Pine.BSI.3.93.970320200030.9278M-100000@sidhe.memra.com>; from Michael Dillon on Thu, Mar 20, 1997 at 08:06:16PM -0800
References: <19970320194655.05290@Jupiter.Mcs.Net> <Pine.BSI.3.93.970320200030.9278M-100000@sidhe.memra.com>
Message-ID: <19970320223913.31594@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 08:06:16PM -0800, Michael Dillon wrote:
> On Thu, 20 Mar 1997, Karl Denninger wrote:
> 
> > > IAHC's proposal fixes the problem folks are seeing with NS today.
> > 
> > No it doesn't.
> > 
> > If you register with someone, pay them, and they claim never to have
> > received payment you're just as screwed.  They hold or delete your 
> > record and you end up paying again.
> 
> My understanding is that the precise protocol used to register a new name
> has not been frozen yet. This issue can be addressed if CORE requires a
> non-repudiable transaction from a registrar in order to register a domain
> or to update its payment status.
> 
> And even if the IAHC were so foolish as to not consider this possibility
> they certainly did create a Policy Oversight Committee that can change
> procedures at any time. 

So what?

The registrar claims you haven't paid and didn't submit the non-repudiable
transaction (because they claim it didn't happen).  You have a cancelled 
check.

This is precisely the situation people are claiming is happening to them.

Again, the problem isn't payments being posted that didn't happen, its 
payments made which *didn't get posted*.  Non-repudiation doesn't help 
this situation; that's a control on *positive* events, not ones which 
people claim didn't occur.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From dcrocker at brandenburg.com  Fri Mar 21 04:30:52 1997
From: dcrocker at brandenburg.com (Dave Crocker)
Date: Thu, 20 Mar 1997 20:30:52 -0800
Subject: Domain Rant.
In-Reply-To: <19970320211536.30264@Jupiter.Mcs.Net>
References: <v03102231af57a3b8b699@[205.214.160.78]>; from Dave Crocker on
 Thu, Mar 20, 1997 at 06:37:42PM -0800
 <199703210057.QAA31961@wisdom.home.vix.com>;
 <19970320182719.21233@Jupiter.Mcs.Net>
 <199703210057.QAA31961@wisdom.home.vix.com>
 <v03102231af57a3b8b699@[205.214.160.78]>
Message-ID: <v03102234af57bd2cb3f9@[205.214.160.78]>

At 7:15 PM -0800 3/20/97, Karl Denninger wrote:
>> 	you are setting up additional monopolies.  monopolies over critical
>> profits.  you want to allow that.  the iahc doen't.
>
>Mr. Crocker, I really wish you'd stop posting material that just is not true
>and that you *know* is in fact false.

	Karl, first of all, just because you are pissed at me is no reason
to revert to artificial formality.  We've always called each other by first
names and there's no reason to stop now.

	Second of all, you need to re-read the above statement to which you
took exception.

>eDNS enables *all* business models for registration of TLDs and SLDs.

	as I said, it sets up monopolies.  the fact that you demure from
prohibiting or requiring them does not make the above false, since it DOES
mean that you permit them.  Oh gee.  Do we think that folks will take
advantage of this opportunity you are providing them to gain exclusive
control?  Gosh, I wonder...

>by them.  As an example, f.root-servers.net, which Paul Vixie has in his
>control, he has admitted was partially or fully paid for by NSI.
>
>Its tough to tell the person who pays the check every day "no".  Very, very
>difficult.

	Now, you see.  That's interesting, because I don't have any trouble
imagining Paul say no, even to someone who has been giving him money.  It
has to  do with the nature of the person.  That's been one of the hallmarks
of the Internet, the personal integrity of those put into positions of
responsibility.

	Why do you want to change that?

>My accountability is simple.  If I violate the process someone steps in and
>my single machine gets replaced with another.  I have no authority or control

	Let's see.  That means that you are offering the Root du Jour.  And
tomorrow, it may be someone else.  Personally, I rather have a system that
ensures rather more stability for the DNS root and TLD service than that.

>Nonsense.  The TLD namespace IS global.  There is nothing preventing non-US
>interests from registering TLDs, and in fact more than one has (proof positive
>that this statement is ALSO false).  There are currently registrars in
>Germany
>and Japan -- pretty much opposite "ends" of the world.

	Well, since I've lost track of the number of "how dare you take
this outside the US" messages you've sent, your above declaration comes as
a bit of a surprise.

d/

--------------------
Dave Crocker                                             +1 408 246 8253
Brandenburg Consulting                              fax: +1 408 249 6205
675 Spruce Dr.                                  dcrocker at brandenburg.com
Sunnyvale CA 94086 USA                        http://www.brandenburg.com

Internet Mail Consortium                http://www.imc.org, info at imc.org






From karl at Mcs.Net  Fri Mar 21 04:51:20 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 22:51:20 -0600
Subject: Domain Rant.
In-Reply-To: <v03102234af57bd2cb3f9@[205.214.160.78]>; from Dave Crocker on Thu, Mar 20, 1997 at 08:30:52PM -0800
References: <v03102231af57a3b8b699@[205.214.160.78]>; <199703210057.QAA31961@wisdom.home.vix.com>; <19970320182719.21233@Jupiter.Mcs.Net> <199703210057.QAA31961@wisdom.home.vix.com> <v03102231af57a3b8b699@[205.214.160.78]> <v03102234af57bd2cb3f9@[205.214.160.78]>
Message-ID: <19970320225120.55034@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 08:30:52PM -0800, Dave Crocker wrote:
> 
> >eDNS enables *all* business models for registration of TLDs and SLDs.
> 
> 	as I said, it sets up monopolies.  

No it doesn't.  eDNS sets up NO business model.  *RA*s set up business
models.  Again, you are confusing things deliberately.  

The eDNS model does not mandate, or prohibit, any model EXCEPT one which
seeks to stop other models from being born and tested in a free 
marketplace.  eDNS eschews monopolization of business models. 

McDonalds does not have a "monopoly".  They have a *BRAND*.  You like to use
that word because it is emotionally charged and you get a "kick" from it
when you use it.  

But the fact is that a company which develops a particular brand has certain 
rights which come along with that development.  McDonalds can stop people
from selling "Big Macs", unless they pay the appropriate license fee and 
adhere to their standards.

We don't believe this is "bad" in any other line of work.  In fact, the
United States and virtually every other country in the world honors these
principles.  

Do you claim that McDonalds has a monopoly?  Or do they have a brand of 
hamburger?

> >Its tough to tell the person who pays the check every day "no".  Very, very
> >difficult.
> 
> 	Now, you see.  That's interesting, because I don't have any trouble
> imagining Paul say no, even to someone who has been giving him money.  

Really?  Well, let's see.  So far they have all said no.  So far NSI has
maintained the monopoly.  So far *NSI* has not bought off on the IAHC model,
and in fact has issued press releases which pretty strongly indicate, at
least from how I read them, that they have no intention of doing so now or 
in the future.

Yet the IANA roots remain closed.

> >My accountability is simple.  If I violate the process someone steps in and
> >my single machine gets replaced with another.  I have no authority or control
> 
> 	Let's see.  That means that you are offering the Root du Jour.  And
> tomorrow, it may be someone else.  Personally, I rather have a system that
> ensures rather more stability for the DNS root and TLD service than that.

On the contrary.  eDNS is a process.  It is not a person.  It will survive
if I get hit by a bus tomorrow, because the *process* is valid.  It will
survive if I turn rogue tomorrow for the same reason.

eDNS isn't Karl Denninger.  Its a model for recognition of the development 
of competing models in a free marketplace of TLDs.

If the "all shared" model is the best one, then it will win on its own.
Nobody has to force it on anybody.  The "brands" which aren't controlled by
huge numbers of registrars, all with equal access, will fail.  

On their own.

I do *NOT* claim to be omniscient and know what is the "best" model.  I *DO*
believe the market can figure that out for itself without my "help".
Meddling in what is fundamentally a free process inherently leads to 
higher costs and poorer performance.  History says that this is basically
always true, and I have no reason to believe that you, or anyone else,
myself included, is THAT good.

> >Nonsense.  The TLD namespace IS global.  There is nothing preventing non-US
> >interests from registering TLDs, and in fact more than one has (proof positive
> >that this statement is ALSO false).  There are currently registrars in
> >Germany
> >and Japan -- pretty much opposite "ends" of the world.
> 
> 	Well, since I've lost track of the number of "how dare you take
> this outside the US" messages you've sent, your above declaration comes as
> a bit of a surprise.

Not in the least.

I've said that *I* want the right to register in a namespace which is
controlled by a US organization because if they screw me I want legal
recourse.

Others may not see it that way.

Under eDNS, they have that *choice*.  Under the IAHC model, NOBODY gets to
make a free choice.

eDNS is about choice Dave.  Its not about people, and its not about
dictators or monopolies.  Its about users of the network choosing the 
models of registration that they want, and the companies who provide 
those models efficiently being the ones who "win" over time.

None of the other models can make that claim.  All of them claim to know what
is best for everyone else.  The arrogance displayed by the people making
those proclamations is, in many cases, transparent enough to see right
through -- most of those folks have quite a bit of self-interest driving
their conclusions, and the rest simply think they're smarter than everyone
else.

Virtually everyone who believes that of themself is eventually proven to be
foolish at best.

--
-- 
Karl Denninger (karl at MCS.Net)| eDNS - The free-market solution
http://www.edns.net/	     | hostmaster at edns.net




From karl at Mcs.Net  Fri Mar 21 04:57:01 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Thu, 20 Mar 1997 22:57:01 -0600
Subject: Domain Rant.
In-Reply-To: <199703210339.TAA03044@quest.pluris.com>; from Vadim Antonov on Thu, Mar 20, 1997 at 07:39:14PM -0800
References: <199703210339.TAA03044@quest.pluris.com>
Message-ID: <19970320225701.26115@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 07:39:14PM -0800, Vadim Antonov wrote:
> 
> So far, that sounds like nice basis for a class action lawsuit.
> 
> Imagine a land title company throwing away records just because they
> lost a payment receipt.  That's what InterNIC is doing.
> 
> My experience with InterNIC was that i managed to get hold of
> actual person, and got assurances that everything's ok.  Then
> i see nothing happened in the database, so i call again, and they
> tell the information "is not there yet".  Now, i go to the automatic
> system and make a card payment -- the system gives back authorization
> code, etc.  Guess what.  It still says the domain registration is not paid.
> 
> I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> to perform registrations.  Root serer operators can ensure uniqueness
> just fine.
> 
> --vadim

You just described eDNS.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From dcrocker at imc.org  Fri Mar 21 04:39:43 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Thu, 20 Mar 1997 20:39:43 -0800
Subject: Domain Rant.
In-Reply-To: <Pine.BSI.3.93.970320200030.9278M-100000@sidhe.memra.com>
References: <19970320194655.05290@Jupiter.Mcs.Net>
Message-ID: <v03102235af57c0a98627@[205.214.160.78]>

At 8:06 PM -0800 3/20/97, Michael Dillon wrote:
>My understanding is that the precise protocol used to register a new name
>has not been frozen yet. This issue can be addressed if CORE requires a
>non-repudiable transaction from a registrar in order to register a domain
>or to update its payment status.
>
>And even if the IAHC were so foolish as to not consider this possibility
>they certainly did create a Policy Oversight Committee that can change
>procedures at any time.

	The choice of data base technology for the shared repsoitories will
be the choice of CORE, i.e., the registrars themselves.  I believe it is a
matter strictly of operational issues, rather than policy.  I suppose one
could imagine some bizarre decision by CORE which challenges policy issues,
but I doubt it.

	Rick Wesson has organized a BOF for the Memphis IETF, to consider
requirements and technical issues, all of which are intended to jump-start
the background work for CORE.

d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From hchen at aimnet.net  Fri Mar 21 05:30:28 1997
From: hchen at aimnet.net (Hong Chen)
Date: Thu, 20 Mar 1997 21:30:28 -0800 (PST)
Subject: Domain Rant. 24x7 NOC Internic NOC support required?
In-Reply-To: <199703210339.TAA03044@quest.pluris.com>
Message-ID: <Pine.SUN.3.95.970320212043.764A-100000@aimnet.net>


The Internic is really getting us crazy. I just talked with 
Hinet, that has 500,000 users, and they have tried very hard
to get hold of Internic, but only end up with an answering machine.

If Internic controls domain name, and domain name is so important
to ISPs, Internic should AT LEAST provide a 24x7 support NOC
center so that problems like this can be resoved quickly. We 
thought paying $50/year will give us some services, and now
it seems to be just another way around.

When AOL  and Netcom were done for a few hours, it created such
a big news in US. AOL and Netcom were at least having the 
choice of working Days & Nights to resolve the problems.

Now Hinet has been down for two days, and similarly half million 
users are affected. They can do very little, but can only 
speak to the answering machine at Internic, and painfully 
waiting for Internic people come back to work the next day!

The funny thing is that you can do nothing, but begging Internic
to resolve the problem. 

Again, Hinet already has paid the fee 2 days ago (the fee was 
drawn from the bank)

Anyone has a pager number of the Internic engineers?


Hong Chen				408-567-3800 (tel)
hchen at aimnet.net			408-567-0990 (fax)

On Thu, 20 Mar 1997, Vadim Antonov wrote:

> 
> So far, that sounds like nice basis for a class action lawsuit.
> 
> Imagine a land title company throwing away records just because they
> lost a payment receipt.  That's what InterNIC is doing.
> 
> My experience with InterNIC was that i managed to get hold of
> actual person, and got assurances that everything's ok.  Then
> i see nothing happened in the database, so i call again, and they
> tell the information "is not there yet".  Now, i go to the automatic
> system and make a card payment -- the system gives back authorization
> code, etc.  Guess what.  It still says the domain registration is not paid.
> 
> I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> to perform registrations.  Root serer operators can ensure uniqueness
> just fine.
> 
> --vadim
> 





From hank at ibm.net.il  Fri Mar 21 05:35:45 1997
From: hank at ibm.net.il (Hank Nussbacher)
Date: Fri, 21 Mar 1997 07:35:45 +0200 (IST)
Subject: Domain Rant.
In-Reply-To: <199703210339.TAA03044@quest.pluris.com>
Message-ID: <Pine.A32.3.95-heb-2.07.970321073018.43966J-100000@rex.ibm.net.il>

On Thu, 20 Mar 1997, Vadim Antonov wrote:

> 
> So far, that sounds like nice basis for a class action lawsuit.
> 
> Imagine a land title company throwing away records just because they
> lost a payment receipt.  That's what InterNIC is doing.
> 
> My experience with InterNIC was that i managed to get hold of
> actual person, and got assurances that everything's ok.  Then
> i see nothing happened in the database, so i call again, and they
> tell the information "is not there yet".  Now, i go to the automatic
> system and make a card payment -- the system gives back authorization
> code, etc.  Guess what.  It still says the domain registration is not paid.
> 
> I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> to perform registrations.  Root serer operators can ensure uniqueness
> just fine.

Or endorse the IAHC proposal which removes the NSI monopoly, and adds
global competition in the way of registrars.  See www.iahc.org for
details.  eDNS jsut creates many monopolies and becomes a first come first
serve land grab with thousands and perhaps millions of TLDs that would
have to be monitored by trademark lawyers.  


> 
> --vadim
> 

Hank Nussbacher





From bmanning at ISI.EDU  Fri Mar 21 05:42:54 1997
From: bmanning at ISI.EDU (bmanning at ISI.EDU)
Date: Thu, 20 Mar 1997 21:42:54 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <19970320225701.26115@Jupiter.Mcs.Net> from "Karl Denninger" at Mar 20, 97 10:57:01 pm
Message-ID: <199703210542.AA16171@zed.isi.edu>


There used to be (and it may still exist) a record for the number of
newsgroups/maillists that a thread would migrate to. Something like
a parasite.... it would render its host devoid of useful content, driving
productive work elsewhere, and then just as its host became a dry husk of
its former self, the thread would hop to an other maillist/newsgroup and
proceed to suck it dry as well...

I'd start to put money on this thread.. the subject changes but the 
rant is the same.

Three newdom's, one iahc, lots'o'private mail-filters, and now nanog?

--bill




From davidc at apnic.net  Thu Mar 20 17:50:15 1997
From: davidc at apnic.net (David R. Conrad)
Date: Fri, 21 Mar 1997 02:50:15 +0900
Subject: Please move elsewhere (was Re: Domain Rant)
In-Reply-To: Your message of "Thu, 20 Mar 1997 19:46:55 CST."
             <19970320194655.05290@Jupiter.Mcs.Net> 
Message-ID: <199703201750.CAA19427@moonsky.jp.apnic.net>

[iahc-discuss flamage deleted]

Folks,

A plea for rationality.

Granted, the DNS stuff is important, particularly given recent events
at InterNIC, however there are better lists to discuss this stuff on,
including (but not limited to):

iahc-discuss at iahc.org
newdom at vrx.net
newdom at ar.com
/dev/null

It would be a shame to have to unsubscribe from nanog because it
degenerated into the repetitive name-calling, moaning, and bitching
that the (top two) above lists periodically experience.

Regards,
-drc





From dcrocker at imc.org  Fri Mar 21 05:39:06 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Thu, 20 Mar 1997 21:39:06 -0800
Subject: Domain Rant.
In-Reply-To: <19970320225120.55034@Jupiter.Mcs.Net>
References: <v03102234af57bd2cb3f9@[205.214.160.78]>; from Dave Crocker on
 Thu, Mar 20, 1997 at 08:30:52PM -0800
 <v03102231af57a3b8b699@[205.214.160.78]>;
 <199703210057.QAA31961@wisdom.home.vix.com>;
 <19970320182719.21233@Jupiter.Mcs.Net>
 <199703210057.QAA31961@wisdom.home.vix.com>
 <v03102231af57a3b8b699@[205.214.160.78]>
 <v03102234af57bd2cb3f9@[205.214.160.78]>
Message-ID: <v0310223aaf57ce16ae94@[205.214.160.78]>

At 8:51 PM -0800 3/20/97, Karl Denninger wrote:
>McDonalds does not have a "monopoly".  They have a *BRAND*.  You like to use
>that word because it is emotionally charged and you get a "kick" from it
>when you use it.

	I like to use it because it fits.  When a consumer is locked into
dependency on a particular vendor and does not have freedom to change
vendors, that vendor is in a monopoly position.

	The difference between buying hamburgers and buying domain names is
that you are free to buy your next hamburger from someone else.  While one
might counter that one is also free to buy the next domain name from
someone else, it ignores the continuing dependency for names already
purchased.

	If the exclusive vendor of a name chooses to triple the fee next
year, the consumer is stuck.  The cost of changing domain names, after
putting marketing collateral development and building up their own brand
equity in the domain name, is onerous.

d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From alex at Relcom.EU.net  Fri Mar 21 08:51:54 1997
From: alex at Relcom.EU.net (Alex P. Rudnev)
Date: Fri, 21 Mar 1997 11:51:54 +0300 (MSK)
Subject: Domain Rant.
In-Reply-To: <199703210339.TAA03044@quest.pluris.com>
Message-ID: <Pine.SUN.3.91.970321114149.22337M-100000@virgin>


> 
> Imagine a land title company throwing away records just because they
> lost a payment receipt.  That's what InterNIC is doing.
Agree. InterNIC can't get invoices and credit cards correctly, and cause 
a lot of headache over the whole world. Through I don't think it's the 
subj. for NANOG. I know a lot of small companies who could not pay them 
at all (not because 50$ is expansive...).

alex at kiae.su

 




From alex at arch.relcom.ru  Fri Mar 21 09:06:56 1997
From: alex at arch.relcom.ru (Aleksei P. Rudnev)
Date: Fri, 21 Mar 97 12:06:56 +0300
Subject: Domains and NIC
Message-ID: <AAm-aCpGHH@arch.relcom.ru>

Hi.

1-st, InterNIC do not posses Internet, and it's amazing why they decide to
drop some domain from the Name Servers. If it was done (50$ / month rent)
to clear Internet from the heaps of the garbage, why do not check if
domain you want to drop is in use or not... It's thousands of dead domains in
 .com zone, but if compuserve.com don't pay 50$ and they'll remove this domain it'll
cause InterNET to the total collaps simple because a lot of mail
servers fall down due to long mail queue's,,,

2-nd. You can get fee for something need money to support. You need some money
to register new domain (and 50 or 100$ is not expansive for it), but
let's divide the cost to support all .COM name servers to the number
of domains... - I'll wonder if it'll be more than 1$/1year.

3-d. Why InterNIC? If they can't serve 100,000 customers over the whole
world, have not regional branches - they are not best choise. Guess if
CISCO would get this service, or IBM - they have local re-sellers,
local branches, local people to get money, convert currensy etc...

Yes, it's monopoly, it's the worst example of _socialism_, and it's one of the important things
dangerous for the Internet... If you deal (of 100,000,000$/year) depends
of 1 small company having 1 telephone, 1 fax and don't answering on E-MAIL,
FAXES and phone calls in 3 weeks - it's dangerous...



--- 
Aleksei Roudnev, Moscow
------------
It's my personal opinion if I use this E-mail address.




From gherbert at crl.com  Fri Mar 21 09:16:59 1997
From: gherbert at crl.com (George Herbert)
Date: Fri, 21 Mar 1997 01:16:59 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 21:42:54 PST."
             <199703210542.AA16171@zed.isi.edu> 
Message-ID: <199703210917.AA01330@mail.crl.com>


We have two seperate rants here.

The nanog-completely-appropriate rant is that InterNIC has just
screwed the pooch in a massive way and a hell of a lot of domains
which have paid their bills don't exist anymore.  I lost count
before heading off to the Bay-LISA meeting tonight where Paul Vixie
was talking about BIND 8... I've had dozens of "me too" responses.
It's beginning to look like just about everyone may have customers
who got bit by this, and what happened, why, and what's going to
be done to fix it are or should be of interest to the big (and small)
networks right now.

The "what do we do about more roots/domains/etc" stuff is a different
discussion not directly related to the current problem; I don't think
anyone would harbor any illusions that we can get the problems fixed
this week any way but InterNIC fixing them.  But if InterNIC doesn't
deal with this appropriately, next week it may be an issue with a half
life of a week or two instead of a year or two as it has been so far.
Whether it's nanog appropriate or not is another story.

But my patience on this issue is running very thin right now.
If InterNIC can't do its job, then they need to step aside or
be forced aside.  If they have lost the capability to accurately
track payments and are now randomly cutting off service as a result,
they are not doing their job, and the time that this can go on without
becoming the over-riding problem for everyone won't be measured in months.
I have yet to hear any official overall statement from InterNIC
(Mark, are you on nanog?) or any replies related to my specific
domain problem, and it's "good luck" on getting through on the phone
this week as far as I can tell.  So the question becomes, if InterNIC
can't get it straightened out, what the hell do we do?


-george william herbert
gherbert at crl.com
Speaking only for myself, see prior disclaimers





From MDella at CStone.COM  Fri Mar 21 02:09:16 1997
From: MDella at CStone.COM (Marcos Della)
Date: Thu, 20 Mar 1997 18:09:16 -0800
Subject: Domain Rant.
In-Reply-To: <19970320182719.21233@Jupiter.Mcs.Net>
References: <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>
 <199703202013.AA15791@mail.crl.com>
 <Pine.SUN.3.95.970320161023.15787E-100000@aimnet.net>
Message-ID: <3.0.1.32.19970320180916.0072e308@mail.beachnet.com>

At 06:27 PM 3/20/97 -0600, Karl Denninger wrote:
>On Thu, Mar 20, 1997 at 04:15:12PM -0800, Hong Chen wrote:
>> 
>> Yes, we have to do something about it. Recently, I have seen 
>> several large ISPs got affected by Internic. 
>> 
>> I know for sure that both Aimnet.net and Internex.net are
>> putting on hold, despite the fact that Aimnet.net already 
>> paid and our check was cashed 2 days before they put us 
>> on hold. 
>> 
>> You just cannot imagine how many our customers are getting
>> affected. CRL, Aimnet, and Internex likes are major ISPs with
>> hundred and thousands of corporate customers using their 
>> services.

Actually, its been rather interesting.  Talk about opportune times for
the domain to disappear.  I've been hanging out in New York, trying to
get at my email when all of a sudden the domain disappeared.  Its been
rather interesting trying to keep up on events once the domain disappears.
I don't even know how much email bounced back as "undeliverable, no such
address" to sites that have also automatically removed me from mailing
lists and the like.  In some cases, news had some interesting issues
when the names disappeared.  *SIGH*

Mistakes happen I suppose, however these are rather expensive... You
can't believe how expensive they can cost you...

I would like to have as part of the whois process to be able to look
at the account balance and last check reciept so that I at least can
tell if the InterNIC is about to screw up on myself or a customer.
The burden of proof on me however is definately unacceptable, but
barring a long lawsuit and the like, I'd at least like to be able to
see what their records on me or my customers look like.

Marcos
      '''
     (o o)
-oOO--(_)--OOo-------------------------mdella at internex.net---------
Marcos R. Della               Senior Engineering Project Consultant 




From pferguso at cisco.com  Fri Mar 21 12:03:46 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Fri, 21 Mar 1997 07:03:46 -0500
Subject: Domain Rant. 
Message-ID: <3.0.32.19970321070337.006e9308@lint.cisco.com>

Can this discussion PLEASE be taken to another, more approriate list?

Much more of this, and people will be unsubscribing in droves (including
myself).   :-/

- paul





From rs at bifrost.seastrom.com  Fri Mar 21 13:38:04 1997
From: rs at bifrost.seastrom.com (Robert E. Seastrom)
Date: Fri, 21 Mar 1997 08:38:04 -0500 (EST)
Subject: Domain Rant.
In-Reply-To: <Pine.SOL.3.95.970320224800.9582B-100000@orca>
	(pedro@orca.sitesonthe.net)
Message-ID: <199703211338.IAA12232@bifrost.seastrom.com>


   From: "Robert B. Evans" <pedro at orca.sitesonthe.net>

   My customer had to be up with thousands of dollars worth of
   marketing collateral already printed. So we paid again.

Add me to the list of people who have paid twice to alleviate a
service interruption in progress.

                                        ---Rob






From pferguso at cisco.com  Fri Mar 21 13:36:28 1997
From: pferguso at cisco.com (Paul Ferguson)
Date: Fri, 21 Mar 1997 08:36:28 -0500
Subject: ARIS [Was: Re: Domain Rant.]
Message-ID: <3.0.32.19970321083625.006dfdc8@lint.cisco.com>

At 01:16 PM 3/21/97 +0000, rayaz_siddiqi at telewest.co.uk wrote:

>
>As an aside, I have just heard froma colleague that IBM claim to be able to 
>connect IP subnets without routing via SVCc on their 8260 ATM switch. Is 
>anyone aware of this? Does anyone have any more info.
>

This sounds like the IBM ARIS [Aggregate Route IP Switching] stuff.

More appropriately discussed over on the MPLS [Multi Protocol Label
Switching] IETF WG list; see:

  http://www.ietf.org/html.charters/mpls-charter.html

- paul





From rayaz_siddiqi at telewest.co.uk  Fri Mar 21 13:16:00 1997
From: rayaz_siddiqi at telewest.co.uk (rayaz_siddiqi at telewest.co.uk)
Date: Fri, 21 Mar 97 13:16:00 +0000
Subject: Domain Rant.
In-Reply-To: <8CC03233018F2C79>
Message-ID: <E8F5223101FFFFFF@twsmtp.telewest.co.uk>

I agree with Paul. I have recently subscribed to NANOG, I'm wondering what 
I've let myself in for!!

As an aside, I have just heard froma colleague that IBM claim to be able to 
connect IP subnets without routing via SVCc on their 8260 ATM switch. Is 
anyone aware of this? Does anyone have any more info.

Thanks,

Rayaz

-------------
Original Text
>From pferguso at cisco.com (Paul Ferguson), on 3/21/97 7:03 AM:
Can this discussion PLEASE be taken to another, more approriate list?

Much more of this, and people will be unsubscribing in droves (including
myself).   :-/

- paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ATTRIBS.BND
Type: application/octet-stream
Size: 1793 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/19970321/358e37ad/attachment.obj>

From karl at Mcs.Net  Fri Mar 21 14:16:52 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Fri, 21 Mar 1997 08:16:52 -0600
Subject: Domain Rant.
In-Reply-To: <v0310223aaf57ce16ae94@[205.214.160.78]>; from Dave Crocker on Thu, Mar 20, 1997 at 09:39:06PM -0800
References: <v03102234af57bd2cb3f9@[205.214.160.78]>; <v03102231af57a3b8b699@[205.214.160.78]>; <199703210057.QAA31961@wisdom.home.vix.com>; <19970320182719.21233@Jupiter.Mcs.Net> <199703210057.QAA31961@wisdom.home.vix.com> <v03102231af57a3b8b699@[205.214.160.78]> <v03102234af57bd2cb3f9@[205.214.160.78]> <v0310223aaf57ce16ae94@[205.214.160.78]>
Message-ID: <19970321081652.35547@Jupiter.Mcs.Net>

On Thu, Mar 20, 1997 at 09:39:06PM -0800, Dave Crocker wrote:
> At 8:51 PM -0800 3/20/97, Karl Denninger wrote:
> >McDonalds does not have a "monopoly".  They have a *BRAND*.  You like to use
> >that word because it is emotionally charged and you get a "kick" from it
> >when you use it.
> 
> 	I like to use it because it fits.  When a consumer is locked into
> dependency on a particular vendor and does not have freedom to change
> vendors, that vendor is in a monopoly position.
> 
> 	The difference between buying hamburgers and buying domain names is
> that you are free to buy your next hamburger from someone else.  While one
> might counter that one is also free to buy the next domain name from
> someone else, it ignores the continuing dependency for names already
> purchased.
> 
> 	If the exclusive vendor of a name chooses to triple the fee next
> year, the consumer is stuck.  The cost of changing domain names, after
> putting marketing collateral development and building up their own brand
> equity in the domain name, is onerous.
> 
> d/

If CORE decides to hike the maintenance fee in Year 2, 3 or 4, all
registrars will have to pass that fixed cost of doing business on to their
customers, and not only are you stuck if you stay with one vendor, you're
stuck if you *MOVE*!

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From jerry_eyers at xprimary.7000.albertsons.com  Fri Mar 21 14:46:07 1997
From: jerry_eyers at xprimary.7000.albertsons.com (Jerry Eyers)
Date: Fri, 21 Mar 1997 07:46:07 -0700
Subject: Domain Rant.
Message-ID: <c=US%a=_%p=albertsons%l=XPRIMARY-970321144607Z-21086@xprimary.7000.albertsons.com>

Not necessarily a massive cooperation of everyone. but at
least a few.  Seems to me you could find some folks would be 
interested in approaching that.

Jerry

Jerry Eyers
U Psalms 46:1


>----------
>From: 	Alex Rubenstein[SMTP:alex at nac.net]
>Sent: 	Thursday, March 20, 1997 7:47 PM
>To: 	Karl Denninger
>Cc: 	Paul A Vixie; nanog at merit.edu
>Subject: 	Re: Domain Rant.
>
>> > 
>> > Because there can be only one authority for ".".
>
>I don't agree with this. 
>
>It is quite possible for everyone to maintain ".". Then, there would be no
>need for root domain servers; HOWEVER, this would take massive cooperation
>throughout the industy, which will never happen. 
>
>
>
>




From cyarnell at earthdome.arc.nasa.gov  Fri Mar 21 14:45:20 1997
From: cyarnell at earthdome.arc.nasa.gov (Chris Yarnell)
Date: Fri, 21 Mar 1997 06:45:20 -0800
Subject: Domain Rant.
In-Reply-To: <19970321081652.35547@Jupiter.Mcs.Net>
References: <v0310223aaf57ce16ae94@[205.214.160.78]>
 <v03102234af57bd2cb3f9@[205.214.160.78]>
 <v03102231af57a3b8b699@[205.214.160.78]>
 <199703210057.QAA31961@wisdom.home.vix.com>
 <19970320182719.21233@Jupiter.Mcs.Net>
 <199703210057.QAA31961@wisdom.home.vix.com>
 <v03102231af57a3b8b699@[205.214.160.78]>
 <v03102234af57bd2cb3f9@[205.214.160.78]>
 <v0310223aaf57ce16ae94@[205.214.160.78]>
Message-ID: <3.0.1.32.19970321064520.006cc364@earthdome.arc.nasa.gov>

Ugh!  Please, please, please, take this to another list?

>If CORE decides to hike the maintenance fee in Year 2, 3 or 4, all


----
Chris Yarnell - cyarnell at nasa.gov - 415-604-0726
NASA Network Information Center & GLOBE - NASA Ames Research Center




From alex at nac.net  Fri Mar 21 14:23:57 1997
From: alex at nac.net (Alex Rubenstein)
Date: Fri, 21 Mar 1997 10:23:57 -0400
Subject: Domain Rant.
Message-ID: <3.0.32.19970321101846.00acd970@mail.nac.net>


I would be very interested. Is anybody interested in starting a talk about
this?

At 07:46 AM 3/21/97 -0700, Jerry Eyers wrote:
>Not necessarily a massive cooperation of everyone. but at
>least a few.  Seems to me you could find some folks would be 
>interested in approaching that.
>
>Jerry
>
>Jerry Eyers
>U Psalms 46:1
>
>
>>----------
>>From: 	Alex Rubenstein[SMTP:alex at nac.net]
>>Sent: 	Thursday, March 20, 1997 7:47 PM
>>To: 	Karl Denninger
>>Cc: 	Paul A Vixie; nanog at merit.edu
>>Subject: 	Re: Domain Rant.
>>
>>> > 
>>> > Because there can be only one authority for ".".
>>
>>I don't agree with this. 
>>
>>It is quite possible for everyone to maintain ".". Then, there would be no
>>need for root domain servers; HOWEVER, this would take massive cooperation
>>throughout the industy, which will never happen. 
>>
>>
>>
>>
>




From dcrocker at imc.org  Fri Mar 21 15:26:36 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Fri, 21 Mar 1997 07:26:36 -0800
Subject: Domain Rant.
In-Reply-To: <19970321081652.35547@Jupiter.Mcs.Net>
References: <v0310223aaf57ce16ae94@[205.214.160.78]>; from Dave Crocker on
 Thu, Mar 20, 1997 at 09:39:06PM -0800
 <v03102234af57bd2cb3f9@[205.214.160.78]>;
 <v03102231af57a3b8b699@[205.214.160.78]>;
 <199703210057.QAA31961@wisdom.home.vix.com>;
 <19970320182719.21233@Jupiter.Mcs.Net>
 <199703210057.QAA31961@wisdom.home.vix.com>
 <v03102231af57a3b8b699@[205.214.160.78]>
 <v03102234af57bd2cb3f9@[205.214.160.78]>
 <v0310223aaf57ce16ae94@[205.214.160.78]>
Message-ID: <v03102247af58588e4055@[205.214.160.78]>

At 6:16 AM -0800 3/21/97, Karl Denninger wrote:
>If CORE decides to hike the maintenance fee in Year 2, 3 or 4, all
>registrars will have to pass that fixed cost of doing business on to their

	CORE is required to be strictly cost-recovery.  CORE is a creature
of the registrars, in the aggregate AND is subject to the POC which means
that there is public oversight.  Whimsical and excessive increases in
charges won't happen.

	eDNS cannot make any such assurances about domains subject to
monopoly control.

d/

ps.  sorry, folks.  I know you want this off the list, but misinformation
begs a response.


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From netsurf at pixi.com  Fri Mar 21 05:50:38 1997
From: netsurf at pixi.com (NetSurfer)
Date: Fri, 21 Mar 1997 05:50:38 -0000
Subject: Domain Rant.
Message-ID: <199703211550.FAA06500@mail.pixi.com>


The following is from Computer Reseller News, 720 dated 1/20/97, page 7:

"Vars Concerned over IP Payment Plan", by Sam Masud, Washington

... 8< snip
"The registry would have ISP's pay annual fees between $2,000 and $20,000,
depending on the amount of IP space bought.  Web site owvers would be
slapped with a one-time fee of $2,500 to $10,000..  Network Solutions Inc.,
a vendor charged with allocating Internet addresses through a division
called InterNIC, said the registry proposal is up for comment but could be
implemented within three to six months following discussion."
...

I did NOT make this up or base it on unsubstantiated rumor.

----------
From: Steve Kann <stevek at SteveK.COM>
To: NetSurfer <netsurf at pixi.com>
Subject: Re: Domain Rant.
Date: Thursday, March 20, 1997 7:36 AM

NetSurfer writes:
> 
> If you think $50 is bad, just wait and see if the $20,000/year/domain
goes
> through...

Please stop spreading vicous unsubstantiated rumors, Mr. NetSurfer.   No
one has proposed any "$20,000/year/domain" charges.

> #include <standard.disclaimer>
>                     _   __     __  _____            ____
>                    / | / /__  / /_/ ___/__  _______/ __/__  _____
>                   /  |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/
>                  / /|  /  __/ /_ ___/ / /_/ / /  / __/  __/ /
>
================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/===============

BTW: It is customary to prefix signatures with the string "\n-- \n",
such that mail user agents can skip over them.  Unless, of course, that
cool banner is part of your content.
----- 8< snip

Fixed - thanks!





From netsurf at pixi.com  Fri Mar 21 06:01:31 1997
From: netsurf at pixi.com (NetSurfer)
Date: Fri, 21 Mar 1997 06:01:31 -0000
Subject: Domain Rant. 
Message-ID: <199703211601.GAA07370@mail.pixi.com>


Excuse me I should have said IP registration.  To see the entire article,
go to http://www.crn.com/ and do a search on "IP Payment Plan" and you will
get two links to the article.

----------
From: Perry E. Metzger <perry at piermont.com>
To: NetSurfer <netsurf at pixi.com>
Cc: Randy Bush <randy at psg.com>; nanog at merit.edu
Subject: Re: Domain Rant. 
Date: Thursday, March 20, 1997 7:42 AM


"NetSurfer" writes:
> If you think $50 is bad, just wait and see if the $20,000/year/domain
goes
> through...

Since no one has proposed that, its unlikely that it will happen.

Perry




From stevek at SteveK.COM  Fri Mar 21 16:07:27 1997
From: stevek at SteveK.COM (Steve Kann)
Date: Fri, 21 Mar 1997 11:07:27 -0500
Subject: Domain Rant.
In-Reply-To: <199703211550.FAA06500@mail.pixi.com>; from NetSurfer on Mar 21, 1997 05:50:38 -0000
References: <199703211550.FAA06500@mail.pixi.com>
Message-ID: <Mutt.19970321110727.stevek@spheara.io360.com>

> NetSurfer writes:
> > 
> > If you think $50 is bad, just wait and see if the $20,000/year/domain
> goes
> > through...

In a private e-mail message, I replied:
 
> Please stop spreading vicous unsubstantiated rumors, Mr. NetSurfer.   No
> one has proposed any "$20,000/year/domain" charges.


NetSurfer writes:
> 
> The following is from Computer Reseller News, 720 dated 1/20/97, page 7:
> 
> "Vars Concerned over IP Payment Plan", by Sam Masud, Washington
> 
> ... 8< snip
> "The registry would have ISP's pay annual fees between $2,000 and $20,000,
> depending on the amount of IP space bought.  Web site owvers would be
> slapped with a one-time fee of $2,500 to $10,000..  Network Solutions Inc.,
> a vendor charged with allocating Internet addresses through a division
> called InterNIC, said the registry proposal is up for comment but could be
> implemented within three to six months following discussion."
> ...
> 
> I did NOT make this up or base it on unsubstantiated rumor.

As I said in my private reply to you, no one has proposed any
$20,000/year/domain charges.  The article that you have quoted, while
itself a misrepresentation of the ARIN proposal, has nothing at all to
do with domain names, the subject that prompted your original message.

Whether your intention was to incite fear, or if you simply do not
understand the distinction between domain names and IP address blocks,
your message was unsubstantiated nonetheless.

Also, I should have mentioned this in my original reply to you, but It
was no accident that my reply to you was private, and not addressed to
nanog.  This is not a nanog issue, as it has no bearing on North
American Network Operations.  If you wish to discuss this topic, feel
free to join the mailing list specifically devoted to this,
naipr at internic.net.  Subscription instructions should be available at
the ARIN website, http://www.arin.net/, but I think that the standard
practice of sending a message to "naipr-request at lists.internic.net" with
the word "subscribe" in the body should suffice.   

-SteveK

> 
> 
> > #include <standard.disclaimer>
> >                     _   __     __  _____            ____
> >                    / | / /__  / /_/ ___/__  _______/ __/__  _____
> >                   /  |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/
> >                  / /|  /  __/ /_ ___/ / /_/ / /  / __/  __/ /
> >
> ================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/===============
> 
> BTW: It is customary to prefix signatures with the string "\n-- \n",
> such that mail user agents can skip over them.  Unless, of course, that
> cool banner is part of your content.
> ----- 8< snip
> 
> Fixed - thanks!

-- 
     Steve Kann   i/o 360 digital design   841 Broadway, Suite 502
  PGP 1024/C0145E05  F2 D6 24 83 9E 52 9A 61  AA BB 97 61 5C A1 B8 CE
       Personal:stevek at SteveK.COM    Business: stevek at io360.com	




From michael at memra.com  Fri Mar 21 16:04:54 1997
From: michael at memra.com (Michael Dillon)
Date: Fri, 21 Mar 1997 08:04:54 -0800 (PST)
Subject: Domain Rant.
In-Reply-To: <199703211550.FAA06500@mail.pixi.com>
Message-ID: <Pine.BSI.3.93.970321080051.13015H-100000@sidhe.memra.com>

On Fri, 21 Mar 1997, NetSurfer wrote:

> The following is from Computer Reseller News, 720 dated 1/20/97, page 7:

> I did NOT make this up 

No, you didn't make it up, the CRN reporter did.

> or base it on unsubstantiated rumor.

However, you *DID* base your comments on unsubstantiated rumor. That means
that you didn't take time to check out the true facts of the situation.
Those facts are available at http://www.arin.net and if you haven't read
any of the materials in the Recommended Reading section it would be a good
idea to go through some of these for further background information, in
particular RFC2050.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From perry at piermont.com  Fri Mar 21 16:59:15 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 21 Mar 1997 11:59:15 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 18:27:19 CST."
             <19970320182719.21233@Jupiter.Mcs.Net> 
Message-ID: <199703211659.LAA01996@jekyll.piermont.com>


Karl Denninger writes:
> Its time to move on to eDNS folks.

The eDNS is a joke, Karl, and not even a very funny one.

Perry
Speaking purely for myself and not for the IAHC




From booloo at cats.ucsc.edu  Fri Mar 21 17:06:48 1997
From: booloo at cats.ucsc.edu (Mark Boolootian)
Date: Fri, 21 Mar 1997 09:06:48 -0800 (PST)
Subject: NSI hit with suit
Message-ID: <199703211706.JAA20455@krazy.ucsc.edu>


>From C|Net <http://www.news.com/News/Item/0,4,9006,00.html>:

Network Solutions hit with suit 
By Margie Wylie
March 20, 1997, 3:45 p.m. PT 

[...]

PGP Media this morning filed a suit in a New York court alleging that the
partially government-funded Network Solutions has conspired with several
other Internet groups to set up artificial barriers to competition in the
selling of Internet domain names and maintain monopoly control of the
market. The International Ad Hoc Committee, the Internet Assigned Names
Authority (IANA) and its director, Jon Postel, the Internet Society (ISOC),
and unnamed "control persons" are named as "nonparty coconspirators" in the
complaint. 

According to the complaint, which has not yet been formally served on
Network Solutions, the company is using its historical control of Internet
"root servers" to preclude competition in domain name service. Root servers
are computers that act like switchboard operators, matching up familiar
network names, like "cnet.com" with the location of that Net resource, like
a Web site, email server, or gopher server. 

[...]

PGP Media's own domain naming service, called name.space, can't operate on
the Internet without access to the config file on the Internet's official
root servers. The company is asking that the court force Network Solutions
to list name.space's top-level domains, such as ".camera," in the official
root servers in addition to minimum damages of $1 million. 





From vaf at valinor.barrnet.net  Fri Mar 21 17:10:28 1997
From: vaf at valinor.barrnet.net (Vince Fuller)
Date: Fri, 21 Mar 97 9:10:28 PST
Subject: Fwd: master "spam remove" list?
Message-ID: <CMM.0.90.2.858964228.vaf@valinor.barrnet.net>

Has anyone else received this? Is it legit or is it yet another dishonest
attempt by spammers to improve the quality of their mailing lists? I very
much suspect the former as I doubt that spammers pay much attention to
"remove" lists.

	--Vince

                ---------------

Received: from hq.barrnet.net (hq.barrnet.net [204.160.73.5]) by valinor.barrnet.net (8.6.8/8.6.6) with ESMTP id CAA15241 for <vaf at valinor.barrnet.net>; Fri, 21 Mar 1997 02:31:46 -0800
Received: from netchem.com ([205.246.66.97]) by hq.barrnet.net (8.7.5/HQ-Len-1.1) with ESMTP id CAA08490 for <vaf at valinor.barrnet.net>; Fri, 21 Mar 1997 02:34:43 -0800 (PST)
Received: (from danw at localhost)
	by netchem.com (8.8.5/8.8.5) id FAA20879
	for vaf at valinor.barrnet.net; Fri, 21 Mar 1997 05:39:58 -0800 (PST)
Date: Fri, 21 Mar 1997 05:39:58 -0800 (PST)
Message-Id: <199703211339.FAA20879 at netchem.com>
From: remove at netchem.com
Subject: Please Help Yourself, Help Others & Help the Internet
Apparently-To: <vaf at valinor.barrnet.net>

Dear Sir/Madam,

Your email address is on many spammers' lists.
That is why you received so much junk email lately.

Most of the spammers will stop sending you junk email
if you ask them to remove your email address from their lists.

But the problem is that there are too many spammers.
The spammers are not supposed to send you junk email in the first place.
Why do you even have to spend your time to reply?

We are compiling a REMOVE list.  It is much faster for the spammers
to remove your email address if we send them the list because most
of the spammers use automated software.

To add your name to the REMOVE list, simply reply to this email. 
You do not have to write anything. It is FREE!

We are also compiling a blacklist of spammers. If you receive junk email
from someone, please forward the original message to list at netchem.com.

Please do not use spammers to advertise your product on the Internet.
It is not easy to send out 1 million email. The spammer will take your
money and disappear. 

To avoid further spamming, we send out this message only to limited number 
of users. Please forward this email to your friends if you think it is
useful to them. 

Sincerely,
Jerry

-------------------------------------------------
Jerry Wang, PhD, Chemechanics, Inc.					 
http://www.netchem.com, mailto:jerryw at netchem.com 
-------------------------------------------------





From perry at piermont.com  Fri Mar 21 17:07:54 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 21 Mar 1997 12:07:54 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 19:46:55 CST."
             <19970320194655.05290@Jupiter.Mcs.Net> 
Message-ID: <199703211707.MAA02019@jekyll.piermont.com>


Karl Denninger writes:
> No it doesn't.
> 
> If you register with someone, pay them, and they claim never to have
> received payment you're just as screwed.

No, you aren't. Today, if someone does that, you are stuck. In the new
model, you will be able to switch to another registrar. Competition,
you know.

> What is it that you dislike about eDNS Paul?

I think its what most people don't like about eDNS -- they think that
someone who's "DNS" is visible to way under a percent of the net and
who claims authority based on self-appointment isn't to be taken
seriously.

I mean, I'm sure that some people take the eDNS seriously, but then
again, some people take sales of the Brooklyn Bridge seriously...

Perry
Speaking for myself, and not for the IAHC in an official capacity




From karl at Mcs.Net  Fri Mar 21 17:17:53 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Fri, 21 Mar 1997 11:17:53 -0600
Subject: Domain Rant.
In-Reply-To: <199703211707.MAA02019@jekyll.piermont.com>; from Perry E. Metzger on Fri, Mar 21, 1997 at 12:07:54PM -0500
References: <19970320194655.05290@Jupiter.Mcs.Net> <199703211707.MAA02019@jekyll.piermont.com>
Message-ID: <19970321111753.05243@Jupiter.Mcs.Net>

On Fri, Mar 21, 1997 at 12:07:54PM -0500, Perry E. Metzger wrote:
> 
> Karl Denninger writes:
> > No it doesn't.
> > 
> > If you register with someone, pay them, and they claim never to have
> > received payment you're just as screwed.
> 
> No, you aren't. Today, if someone does that, you are stuck. 

Boiled down: You pay again.

> In the new
> model, you will be able to switch to another registrar. Competition,
> you know.

Boiled down: You pay again.

What was that difference again?

I know you're good at trying to avoid facts, but this is rediculous!

> Perry

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From perry at piermont.com  Fri Mar 21 17:15:00 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 21 Mar 1997 12:15:00 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 21:15:36 CST."
             <19970320211536.30264@Jupiter.Mcs.Net> 
Message-ID: <199703211715.MAA02032@jekyll.piermont.com>


Karl Denninger writes:
> Mr. Crocker, I really wish you'd stop posting material that just is not true
> and that you *know* is in fact false.
> 
> eDNS enables *all* business models for registration of TLDs and SLDs.  

The eDNS enables nothing because it isn't real. Its the creation of a
group of self-appointed people and has nothing to do with the root
name servers used by over 99% of the people on the internet no matter
how many press releases you put out. Almost no one uses your "domain
name system" so it doesn't matter.

The eDNS is not taken seriously by most people other than reporters
starved for material for articles. It isn't like its useable.

Heck, by your model, next week I could set up the "pDNS" and put out
dozens of press releases and pretend that I had an "alternative DNS"
in place. Of course, my fantasy would have nothing to do with the real
world, and neither, I will point out, does yours.

Perry




From paul at vix.com  Fri Mar 21 17:41:08 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 09:41:08 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 20:30:52 PST."
             <v03102234af57bd2cb3f9@[205.214.160.78]> 
Message-ID: <199703211741.JAA30147@wisdom.home.vix.com>

> 	Now, you see.  That's interesting, because I don't have any trouble
> imagining Paul say no, even to someone who has been giving him money.  It
> has to  do with the nature of the person.  That's been one of the hallmarks
> of the Internet, the personal integrity of those put into positions of
> responsibility.

:-).  I guess you can see that David and I have worked together.  Twice he
has been my indirect supervisor, and as it turns out he never heard me say
"no" but he has heard me say "f*** o** and d** m*****f*****", and I dare say
that Network Solutions has heard even choicer words when they screw up.

Giving me money is no guarantee of polite treatment.  I do the right thing,
money or no money.  The funny thing is, people keep giving me money anyway.




From paul at vix.com  Fri Mar 21 17:22:57 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 09:22:57 -0800
Subject: Paul and Karl going at it again -- don't read this (Re: Domain Rant. )
In-Reply-To: Your message of "Thu, 20 Mar 1997 19:46:55 CST."
             <19970320194655.05290@Jupiter.Mcs.Net> 
Message-ID: <199703211722.JAA31343@wisdom.home.vix.com>

This message is entirely worthless.  Don't waste your time on it.  Hit D now.

> > IAHC's proposal fixes the problem folks are seeing with NS today.
> 
> No it doesn't.

Yes, it does.  Nyaa, nyaa.

> If you register with someone, pay them, and they claim never to have
> received payment you're just as screwed.  They hold or delete your 
> record and you end up paying again.

With 28 competing registries all able to handle the accounting for a *.gTLD
second level name -- and we expect that COM will be made into one such after
the cooperative agreement expires in 1998 -- I expect world class professional
billing to be the norm.  After all, if customers can switch registry providers
WITHOUT CHANGING THEIR DOMAIN NAME, I think that providers will have a little
more incentive to mark down when someone makes a payment.

(ISC.ORG was put on hold recently.  I faxed NS the cancelled check, and they
unheld me.  This is clearly a case of a networking company trying to do
accounting.  There's probably a broken AWK script at the root of this idiocy.)

> What is it that you dislike about eDNS Paul?  I'd love to see some actual
> substantive criticism (as opposed to "IAHC is God") of the policy points.

eDNS is a coup attempt by disgruntled loop seekers who, having been told the
rules in the real sandbox, pouted for a while and then went off to form their
own, and are now trying to convince onlookers that theirs is the real one.

You should spend some time volunteering at your local kindergarten -- once you
have seen how 5-year-olds play together, a lot of the mystery goes right out
of DNS politics.




From paul at vix.com  Fri Mar 21 17:27:54 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 09:27:54 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 21:47:35 EST."
             <Pine.NEB.3.95.970320214641.10811E-100000@duncan.nac.net> 
Message-ID: <199703211727.JAA23002@wisdom.home.vix.com>

> > Because there can be only one authority for ".".
> 
> I don't agree with this. 

This must be because you've read RFC1034 and RFC1035 more recently than I
have, and have implemented your own DNS servers which works better than BIND,
and you know something about DNS architecture that continues to elude me?

> It is quite possible for everyone to maintain ".". Then, there would be no
> need for root domain servers; HOWEVER, this would take massive cooperation
> throughout the industy, which will never happen. 

I said "one authority".  That means "one definition of its content".  Sure,
if everybody in the industry could agree on all changes, even minor little
"add an NS" or "change an NS" changes, then they could all run "." as primary
masters.  But there would still be only one authority.

Since we know democracy doesn't work at that level of granularity, we usually
elect representatives.  The current nonelected representative is Jon Postel,
who is trying very hard to hold free elections without destabilizing what
passes for government at the moment.




From paul at vix.com  Fri Mar 21 17:34:32 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 09:34:32 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Thu, 20 Mar 1997 19:39:14 PST."
             <199703210339.TAA03044@quest.pluris.com> 
Message-ID: <199703211734.JAA30435@wisdom.home.vix.com>

> I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> to perform registrations.  Root serer operators can ensure uniqueness
> just fine.

this is definitely where we are headed if the IAHC proposal stalls.  i'm
already in contact with some of the larger ISPs about this subject.




From stevek at SteveK.COM  Fri Mar 21 17:51:40 1997
From: stevek at SteveK.COM (Steve Kann)
Date: Fri, 21 Mar 1997 12:51:40 -0500
Subject: Domain Rant.
In-Reply-To: <19970321111753.05243@Jupiter.Mcs.Net>; from Karl Denninger on Mar 21, 1997 11:17:53 -0600
References: <19970320194655.05290@Jupiter.Mcs.Net> <199703211707.MAA02019@jekyll.piermont.com> <19970321111753.05243@Jupiter.Mcs.Net>
Message-ID: <Mutt.19970321125140.stevek@spheara.io360.com>

Karl Denninger writes:
> On Fri, Mar 21, 1997 at 12:07:54PM -0500, Perry E. Metzger wrote:
> > 
> > Karl Denninger writes:
> > > No it doesn't.
> > > 
> > > If you register with someone, pay them, and they claim never to have
> > > received payment you're just as screwed.
> > 
> > No, you aren't. Today, if someone does that, you are stuck. 
> 
> Boiled down: You pay again.
> 
> > In the new
> > model, you will be able to switch to another registrar. Competition,
> > you know.
> 
> Boiled down: You pay again.
> 
> What was that difference again?
> 
> I know you're good at trying to avoid facts, but this is rediculous!

Cute, but we both know that you are avoiding the point.

Here's the point, in three sentences:

a. There is very little than can be done about companies providing
substandard service, or even screwing you over, when they have a
monopolistic stranglehold on you.  

b. In your "eDNS" model, registrars have this stranglehold on you, because
you you cannot switch to the services of a newer (better) registrar
without having to also change domain names.  

c. With the IAHC plan, if a registrar is providing unsatisfactory service,
you can switch registrars, while keeping the same domain name.

-SteveK


-- 
     Steve Kann   i/o 360 digital design   841 Broadway, Suite 502
  PGP 1024/C0145E05  F2 D6 24 83 9E 52 9A 61  AA BB 97 61 5C A1 B8 CE
       Personal:stevek at SteveK.COM    Business: stevek at io360.com	




From tim at taggnet.skyscape.net  Fri Mar 21 17:59:09 1997
From: tim at taggnet.skyscape.net (Tim Gibson)
Date: Fri, 21 Mar 1997 12:59:09 -0500 (EST)
Subject: Domain Rant. [re: should be in iahc list if it existed] 
In-Reply-To: <199703211734.JAA30435@wisdom.home.vix.com>
Message-ID: <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>



On Fri, 21 Mar 1997, Paul A Vixie wrote:

> > I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> > to perform registrations.  Root serer operators can ensure uniqueness
> > just fine.
> 
> this is definitely where we are headed if the IAHC proposal stalls.  i'm
> already in contact with some of the larger ISPs about this subject.

It's not bad enough that Mr. Postel throws out an RFC process mid stream 
and assumes god mode. Now you are pulling authority out of the air 
aswell? Guys if you want your god mode, play by the rules that you set 
down or go change those rules first! This "group of 7" b.s. is wearing 
very thin and you're only going to find more business consumers of the 
net legally dragging you across the carpet for it.

Tim Gibson




From paul at vix.com  Fri Mar 21 17:54:08 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 09:54:08 -0800
Subject: Domain Rant. 
In-Reply-To: Your message of "Fri, 21 Mar 1997 01:16:59 PST."
             <199703210917.AA01330@mail.crl.com> 
Message-ID: <199703211754.JAA02254@wisdom.home.vix.com>

> The "what do we do about more roots/domains/etc" stuff is a different
> discussion not directly related to the current problem; I don't think
> anyone would harbor any illusions that we can get the problems fixed
> this week any way but InterNIC fixing them.  But if InterNIC doesn't
> deal with this appropriately, next week it may be an issue with a half
> life of a week or two instead of a year or two as it has been so far.
> Whether it's nanog appropriate or not is another story.

I think you need to petition IANA directly (Postel, at least, does not
read NANOG that I know of) to freeze the .COM zone until InterNIC stops
screwing up the billing.  I take hardware from InterNIC, but I get my
marching orders from IANA, and if he says "stop transferring new .COM
zones from InterNIC" then I will make that change instantly, and so will
the rest of the roots.




From paul at vix.com  Fri Mar 21 18:12:35 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 10:12:35 -0800
Subject: Domain Rant. [re: should be in iahc list if it existed] 
In-Reply-To: Your message of "Fri, 21 Mar 1997 12:59:09 EST."
             <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net> 
Message-ID: <199703211812.KAA32148@wisdom.home.vix.com>

> It's not bad enough that Mr. Postel throws out an RFC process mid stream 
> and assumes god mode. Now you are pulling authority out of the air 
> aswell? Guys if you want your god mode, play by the rules that you set 
> down or go change those rules first! This "group of 7" b.s. is wearing 
> very thin and you're only going to find more business consumers of the 
> net legally dragging you across the carpet for it.

Go ahead, drag me.  But I'm not willing to let "." turn into babel, and if
the IAHC process stalls, I will ask the large ISP's to take direct control.




From stevek at io360.com  Fri Mar 21 18:14:04 1997
From: stevek at io360.com (Steve Kann)
Date: Fri, 21 Mar 1997 13:14:04 -0500
Subject: Fwd: master "spam remove" list?
References: <CMM.0.90.2.858964228.vaf@valinor.barrnet.net>
Message-ID: <Mutt.19970321131403.stevek@spheara.io360.com>

Vince Fuller writes:
> Has anyone else received this? Is it legit or is it yet another dishonest
> attempt by spammers to improve the quality of their mailing lists? I very
> much suspect the former as I doubt that spammers pay much attention to
> "remove" lists.

Seems to me that the spammers might hage caught on to the "GOOD TIMES"
vehicle of e-mail distribution.  It's easier and more effective to get
users to spam each other than it is to spam the users directly.
Firstly, it gets through most filtering schemes (except for body-content
filtering).  Secondly it would get better readership, since it ends up
with a "friends" e-mail address in the "From:" header, and thirdly, it
is cheap.  Social Engineering attacks at their ugliest.

My guess is (and I have no substantiation for this at all), is that they
are going to compile a great big list of users from the replies to the
"REMOVE" list, and then try to sell it to every spammer who's mail is
forwarded to the "Blacklist".  Of course, this particular effort may be
legitimate, but it would be an interesting next step for the spammers.

[ let's move this to spam-list at psc.edu ]

-SteveK

> Dear Sir/Madam,
> 
> Your email address is on many spammers' lists.
> That is why you received so much junk email lately.
> 
> Most of the spammers will stop sending you junk email
> if you ask them to remove your email address from their lists.
> 
> But the problem is that there are too many spammers.
> The spammers are not supposed to send you junk email in the first place.
> Why do you even have to spend your time to reply?
> 
> We are compiling a REMOVE list.  It is much faster for the spammers
> to remove your email address if we send them the list because most
> of the spammers use automated software.
> 
> To add your name to the REMOVE list, simply reply to this email. 
> You do not have to write anything. It is FREE!
> 
> We are also compiling a blacklist of spammers. If you receive junk email
> from someone, please forward the original message to list at netchem.com.
> 
> Please do not use spammers to advertise your product on the Internet.
> It is not easy to send out 1 million email. The spammer will take your
> money and disappear. 
> 
> To avoid further spamming, we send out this message only to limited number 
> of users. Please forward this email to your friends if you think it is
> useful to them. 
> 
> -------------------------------------------------
> Jerry Wang, PhD, Chemechanics, Inc.					 
> http://www.netchem.com, mailto:jerryw at netchem.com 
> -------------------------------------------------

-- 
     Steve Kann   i/o 360 digital design   841 Broadway, Suite 502
  PGP 1024/C0145E05  F2 D6 24 83 9E 52 9A 61  AA BB 97 61 5C A1 B8 CE
       Personal:stevek at SteveK.COM    Business: stevek at io360.com	




From karl at Mcs.Net  Fri Mar 21 18:15:40 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Fri, 21 Mar 1997 12:15:40 -0600
Subject: Domain Rant. [re: should be in iahc list if it existed]
In-Reply-To: <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>; from Tim Gibson on Fri, Mar 21, 1997 at 12:59:09PM -0500
References: <199703211734.JAA30435@wisdom.home.vix.com> <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>
Message-ID: <19970321121540.57371@Jupiter.Mcs.Net>

On Fri, Mar 21, 1997 at 12:59:09PM -0500, Tim Gibson wrote:
> 
> On Fri, 21 Mar 1997, Paul A Vixie wrote:
> 
> > > I think it is time ISPs take the matter in their hands.  I.e. let ISPs
> > > to perform registrations.  Root serer operators can ensure uniqueness
> > > just fine.
> > 
> > this is definitely where we are headed if the IAHC proposal stalls.  i'm
> > already in contact with some of the larger ISPs about this subject.
> 
> It's not bad enough that Mr. Postel throws out an RFC process mid stream 
> and assumes god mode. Now you are pulling authority out of the air 
> aswell? Guys if you want your god mode, play by the rules that you set 
> down or go change those rules first! This "group of 7" b.s. is wearing 
> very thin and you're only going to find more business consumers of the 
> net legally dragging you across the carpet for it.
> 
> Tim Gibson

Bingo.

There has already been one Sherman Act related lawsuit filed.  Collude with
others and RICO gets added to the mix.

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From karl at Mcs.Net  Fri Mar 21 18:14:28 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Fri, 21 Mar 1997 12:14:28 -0600
Subject: Domain Rant.
In-Reply-To: <Mutt.19970321125140.stevek@spheara.io360.com>; from Steve Kann on Fri, Mar 21, 1997 at 12:51:40PM -0500
References: <19970320194655.05290@Jupiter.Mcs.Net> <199703211707.MAA02019@jekyll.piermont.com> <19970321111753.05243@Jupiter.Mcs.Net> <Mutt.19970321125140.stevek@spheara.io360.com>
Message-ID: <19970321121428.48277@Jupiter.Mcs.Net>

On Fri, Mar 21, 1997 at 12:51:40PM -0500, Steve Kann wrote:
> > Boiled down: You pay again.
> > 
> > What was that difference again?
> > 
> > I know you're good at trying to avoid facts, but this is rediculous!
> 
> Cute, but we both know that you are avoiding the point.

On the contrary.

> Here's the point, in three sentences:
> 
> a. There is very little than can be done about companies providing
> substandard service, or even screwing you over, when they have a
> monopolistic stranglehold on you.  

Which you choose freely when you sign for that domain name.  Remember, there
is no restriction on business models.  In fact, the IAHC model is welcome
under eDNS and they have been officially notified and asked to sign the
charter.

> b. In your "eDNS" model, registrars have this stranglehold on you, because
> you you cannot switch to the services of a newer (better) registrar
> without having to also change domain names.  

What if the cost is 5% of what the IAHC registrar's "best bid" is?  10%?
50%?  Who are you to make that choice for others?

> c. With the IAHC plan, if a registrar is providing unsatisfactory service,
> you can switch registrars, while keeping the same domain name.

Again, if that model is superior, and really worth the expense, whatever it
is, then it wins on its own.

It is UNNECESSARY to mandate the model - unless, of course, you don't really
believe it will win in the free market, in which case you're not only a
dictator, you're a hypocrite as well.

What's necessary is preventing the elimination of free market selection.

>      Steve Kann   i/o 360 digital design   841 Broadway, Suite 502

--
-- 
Karl Denninger (karl at MCS.Net)| MCSNet - The Finest Internet Connectivity
http://www.mcs.net/~karl     | T1's from $600 monthly to FULL DS-3 Service
			     | 99 Analog numbers, 77 ISDN, Web servers $75/mo
Voice: [+1 312 803-MCS1 x219]| Email to "info at mcs.net" WWW: http://www.mcs.net/
Fax:   [+1 312 803-4929]     | 2 FULL DS-3 Internet links; 400Mbps B/W Internal




From kent at songbird.com  Fri Mar 21 18:25:18 1997
From: kent at songbird.com (Kent Crispin)
Date: Fri, 21 Mar 1997 10:25:18 -0800
Subject: Domain Rant.
In-Reply-To: <199703211741.JAA30147@wisdom.home.vix.com>; from Paul A Vixie on Fri, Mar 21, 1997 at 09:41:08AM -0800
References: <v03102234af57bd2cb3f9@[205.214.160.78]> <199703211741.JAA30147@wisdom.home.vix.com>
Message-ID: <19970321102518.38728@bywater.songbird.com>

On Fri, Mar 21, 1997 at 09:41:08AM -0800, Paul A Vixie wrote:
> > 	Now, you see.  That's interesting, because I don't have any trouble
> > imagining Paul say no, even to someone who has been giving him money.  It
> > has to  do with the nature of the person.  That's been one of the hallmarks
> > of the Internet, the personal integrity of those put into positions of
> > responsibility.
> 
> :-).  I guess you can see that David and I have worked together.  Twice he
> has been my indirect supervisor, and as it turns out he never heard me say
> "no" but he has heard me say "f*** o** and d** m*****f*****", and I dare say
> that Network Solutions has heard even choicer words when they screw up.
> 
> Giving me money is no guarantee of polite treatment.  I do the right thing,
> money or no money.  The funny thing is, people keep giving me money anyway.

A slight correction:  You do what *you think* is the right thing.

-- 
Kent Crispin				"No reason to get excited",
kent at songbird.com,kc at llnl.gov		the thief he kindly spoke...
PGP fingerprint:   B1 8B 72 ED 55 21 5E 44  61 F4 58 0F 72 10 65 55
http://songbird.com/kent/pgp_key.html




From pjnesser at martigny.ai.mit.edu  Fri Mar 21 18:47:29 1997
From: pjnesser at martigny.ai.mit.edu (Philip J. Nesser II)
Date: Fri, 21 Mar 1997 13:47:29 -0500 (EST)
Subject: Domain Rant.
In-Reply-To: <199703211727.JAA23002@wisdom.home.vix.com> from "Paul A Vixie" at Mar 21, 97 09:27:54 am
Message-ID: <199703211847.AA070920050@martigny.ai.mit.edu>

Paul A Vixie supposedly said:
> 
> > Someone else said:
> > It is quite possible for everyone to maintain ".". Then, there would be no
> > need for root domain servers; HOWEVER, this would take massive cooperation
> > throughout the industy, which will never happen. 
> 
> I said "one authority".  That means "one definition of its content".  Sure,
> if everybody in the industry could agree on all changes, even minor little
> "add an NS" or "change an NS" changes, then they could all run "." as primary
> masters.  But there would still be only one authority.

I have an excellent idea.  If we can all work together like this, why don't
we just put all the hostnames and IP addresses, and all sorts of other info
in a flat file that people could get off of a common ftp (or web) site.  We
could call such a file HOSTS.TXT.  I think it could work...

:-)

--->  Phil






































































































From wayne at host.domain.net  Fri Mar 21 18:59:50 1997
From: wayne at host.domain.net (Wayne D. Correia)
Date: Fri, 21 Mar 1997 10:59:50 -0800
Subject: root-server envy, racketeering, and black helicopters.
In-Reply-To: <19970321121540.57371@Jupiter.Mcs.Net>
References:  <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>; from Tim
 Gibson on Fri, Mar 21, 1997 at 12:59:09PM -0500
 <199703211734.JAA30435@wisdom.home.vix.com>
 <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>
Message-ID: <v03007801af58883d4887@[207.21.10.112]>

I've been on NANOG list since the day of NANOG 9. I subscribed to hopefully
learn about current network operations issues and related software and
hardware technologies. I got the impression that this was a professional
trade mailing list.

Then the messages started coming...

So, here I am, reading messages about One World Government black helicopter
teams who conspire to control network registries, from groups of ignored
and (appropriately unempowered) people who seem to have root-server-envy,
now I've read about how RICO laws are inferred to about to be applied to
domain name registration.

What the hell is going on here? It's wacky!

I've really enjoyed reading about subjects that I assumed I would find on
this list: BGP and flapping, technical discussion of spam management,
network management tools, and network outages, etc.

As the Interenet grows, so, it seems, do my filtering rules. I just didn't
think I'd have to apply filters to a list with a subjectlike this.

I guess I was wrong? :-)

_________________________________________________________________________
 Wayne D. Correia             +1.415.826.6000    900 Tennessee Street
                          fax +1.415.826.6100    San Francisco, CA 94107






From ghersh at bbnplanet.com  Fri Mar 21 19:38:42 1997
From: ghersh at bbnplanet.com (Gregory Hersh)
Date: Fri, 21 Mar 1997 14:38:42 -0500
Subject: root-server envy, racketeering, and black helicopters.
In-Reply-To: "Wayne D. Correia" <wayne@host.domain.net>
        "root-server envy, racketeering, and black helicopters." (Mar 21, 10:59am)
References: <Pine.BSD/.3.91.970321125411.8273A-100000@taggnet.skyscape.net>  ; 
	from  Tim  Gibson  on  Fri  Mar  21 
	1997 at 12:59:09PM -0500 <199703211734.JAA30435@wisdom.home.vix.com> 
	<v03007801af58883d4887@[207.21.10.112]>
Message-ID: <970321143842.ZM6618@tuba.bbnplanet.com>

Add the discussion on T1 utilization ...





From avg at pluris.com  Fri Mar 21 19:57:43 1997
From: avg at pluris.com (Vadim Antonov)
Date: Fri, 21 Mar 1997 11:57:43 -0800
Subject: Domain Rant
Message-ID: <199703211957.LAA03636@quest.pluris.com>


I do not think the domain issue is beyond the scope of NANOG.
In fact, w/o working DNS the value of services provided by N.A.N.Operators
is zero.  In other words, the domain insanity reached the level where
it starts to impact the business of ISPs materially.

In other words, it is in the interest of ISPs to step in and inject some
sanity into how that vital part of infrastructure is being run.

ISPs is the only party in the debate which actually has resources and
enough business sense to make it a workable setup.  I strongly suspect that
"expert groups" and "engineering task forces" have already demonstrated
their unability to fix the problem.

Now, to me it looks like CIDR movie rerun.

--vadim




From perry at piermont.com  Fri Mar 21 19:47:32 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 21 Mar 1997 14:47:32 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Fri, 21 Mar 1997 05:50:38 GMT."
             <199703211550.FAA06500@mail.pixi.com> 
Message-ID: <199703211947.OAA02296@jekyll.piermont.com>


"NetSurfer" writes:
> 
> The following is from Computer Reseller News, 720 dated 1/20/97, page 7:
> 
> "Vars Concerned over IP Payment Plan", by Sam Masud, Washington
> 
> ... 8< snip
> "The registry would have ISP's pay annual fees between $2,000 and $20,000,
> depending on the amount of IP space bought.  Web site owvers would be
> slapped with a one-time fee of $2,500 to $10,000..
[...]
> I did NOT make this up or base it on unsubstantiated rumor.

'fraid you did.

You seem to be confusing DOMAIN NAMES with NETWORK NUMBERS.

Perry


> ----------
> From: Steve Kann <stevek at SteveK.COM>
> To: NetSurfer <netsurf at pixi.com>
> Subject: Re: Domain Rant.
> Date: Thursday, March 20, 1997 7:36 AM
> 
> NetSurfer writes:
> > 
> > If you think $50 is bad, just wait and see if the $20,000/year/domain
> goes
> > through...
> 
> Please stop spreading vicous unsubstantiated rumors, Mr. NetSurfer.   No
> one has proposed any "$20,000/year/domain" charges.
> 
> > #include <standard.disclaimer>
> >                     _   __     __  _____            ____
> >                    / | / /__  / /_/ ___/__  _______/ __/__  _____
> >                   /  |/ / _ \/ __/\__ \/ / / / ___/ /_/ _ \/ ___/
> >                  / /|  /  __/ /_ ___/ / /_/ / /  / __/  __/ /
> >
> ================/_/=|_/\___/\__//____/\__,_/_/==/_/==\___/_/===============
> 
> BTW: It is customary to prefix signatures with the string "\n-- \n",
> such that mail user agents can skip over them.  Unless, of course, that
> cool banner is part of your content.
> ----- 8< snip
> 
> Fixed - thanks!
> 




From tbates at cisco.com  Fri Mar 21 20:00:01 1997
From: tbates at cisco.com (Tony Bates)
Date: Fri, 21 Mar 1997 12:00:01 -0800
Subject: The Cidr Report
Message-ID: <199703212000.MAA09430@lovefm.cisco.com>


This is an auto-generated mail on Fri Mar 21 12:00:00 PST 1997
It is not checked before it leaves my workstation.  However, hopefully 
you will find this report interesting and will take the time to look 
through this to see if you can improve the amount of aggregation you 
perform.

The report is split into sections:

   0) General Status
   
      List the route table history for the last week, list any possibly
      bogus routes seen and give some status on ASes.

   1) Gains by aggregating at the origin AS level

      This lists the "Top 30" players who if they decided to aggregate
      their announced classful prefixes at the origin AS level could 
      make a significant difference in the reduction of the current 
      size of the Internet routing table. This calculation does not 
      take into account the inclusion of holes when forming an aggregate
      so it is possible even larger reduction should be possible.

   2) Weekly Delta

      A summary of the last weeks changes in terms of withdrawn and
      added routes. Please note that this is only a snapshot but does 
      give some indication of ASes participating in CIDR. Clearly,
      it is generally a good thing to see a large amont of withdrawls.

   3) Interesting aggregates

      Interesting here means not an aggregate made as a set of 
      classful routes.      

Thanks to xara.net for giving me access to their routing tables once a
day. 

Please send any comments about this report directly to me.

Check http://www.employees.org/~tbates/cidr-report.html for a daily
update of this report.



------------------------------------------------------------------------------

                        CIDR REPORT for 21Mar97


0) General Status

Table History
-------------

Date	Prefixes
140397	44819
150397	44729
160397	44582
170397	44529
180397	44846
190397	44783
200397	44750
210397	44783

Check http://www.employees.org/~tbates/cidr.plot.html for a plot
of the table history.


Possible Bogus Routes
---------------------


AS Summary
----------

Number of ASes in routing system:                 2159

Number of ASes announcing only one prefix:         913 (450 cidr, 463 classful)

Largest number of  cidr routes:                    515 announced by AS3561
Largest number of classful routes:                1541 announced by  AS174



1) Gains by aggregating at the origin AS level

 --- 21Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1541     1065      476   30.9%   Performance Systems International
AS2493       843      520      323   38.3%   i*internet
AS3602       635      339      296   46.6%   Sprint Canada Inc.
AS1221      1378     1116      262   19.0%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1103      912      191   17.3%   BBN Planet backbone
AS1691       308      171      137   44.5%   BCTEL
AS2048       258      122      136   52.7%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       179       95       84   46.9%   Internet Services GmbH & Co
AS813        303      220       83   27.4%   UUNET Canada (ASN-UUNETCA-AS1)
AS1967       150       72       78   52.0%   Middle East Technical University 
AS7195       119       46       73   61.3%   INTERRED
AS2704       264      191       73   27.7%   HOOKUP-NET-A
AS855        132       62       70   53.0%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        890      827       63    7.1%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS3799        72       25       47   65.3%   IDS
AS3739       185      138       47   25.4%   NEWNET
AS3491       132       87       45   34.1%   CAIS-ASN
AS816        200      156       44   22.0%   UUNETCA-AS4
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS3561       900      856       44    4.9%   MCI
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS97         187      144       43   23.0%   JvNCnet
AS4175       470      427       43    9.1%   CONNECT-NCM

 --- 20Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1545     1069      476   30.8%   Performance Systems International
AS2493       844      521      323   38.3%   i*internet
AS3602       629      337      292   46.4%   Sprint Canada Inc.
AS1221      1376     1114      262   19.0%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1102      913      189   17.2%   BBN Planet backbone
AS1691       308      172      136   44.2%   BCTEL
AS2048       256      128      128   50.0%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS813        299      216       83   27.8%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       150       72       78   52.0%   Middle East Technical University 
AS7195       120       46       74   61.7%   INTERRED
AS2704       262      192       70   26.7%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        846      790       56    6.6%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS97         185      138       47   25.4%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS3739       184      137       47   25.5%   NEWNET
AS3491       134       89       45   33.6%   CAIS-ASN
AS816        194      150       44   22.7%   UUNETCA-AS4
AS3749        70       26       44   62.9%   Tennessee Board of Regents
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS4175       472      429       43    9.1%   CONNECT-NCM
AS3561       897      854       43    4.8%   MCI

 --- 19Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1538     1068      470   30.6%   Performance Systems International
AS2493       847      523      324   38.3%   i*internet
AS3602       629      337      292   46.4%   Sprint Canada Inc.
AS1221      1367     1106      261   19.1%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1103      914      189   17.1%   BBN Planet backbone
AS1691       309      173      136   44.0%   BCTEL
AS2048       257      124      133   51.8%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       117       20       97   82.9%   SIGNET
AS813        306      220       86   28.1%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS7195       120       46       74   61.7%   INTERRED
AS855        132       63       69   52.3%   NBTel
AS2704       260      191       69   26.5%   HOOKUP-NET-A
AS2386       187      121       66   35.3%   INS-AS
AS701        858      799       59    6.9%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        219      166       53   24.2%   ONet Backbone
AS3397        74       22       52   70.3%   EMI-AS
AS3799        72       25       47   65.3%   IDS
AS97         184      138       46   25.0%   JvNCnet
AS3561       904      858       46    5.1%   MCI
AS3739       183      138       45   24.6%   NEWNET
AS3491       135       90       45   33.3%   CAIS-ASN
AS225         76       32       44   57.9%   University of Virginia (VIRnet)
AS816        192      149       43   22.4%   UUNETCA-AS4
AS4175       473      430       43    9.1%   CONNECT-NCM
AS4454        64       22       42   65.6%   OIR Telecommunications, State of 
AS3320        56       14       42   75.0%   Deutsche Telekom AG

 --- 18Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1527     1060      467   30.6%   Performance Systems International
AS2493       841      518      323   38.4%   i*internet
AS3602       629      337      292   46.4%   Sprint Canada Inc.
AS1221      1356     1100      256   18.9%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1103      914      189   17.1%   BBN Planet backbone
AS1691       307      171      136   44.3%   BCTEL
AS2048       255      122      133   52.2%   State of Louisiana/Office of Tele
AS721        485      376      109   22.5%   DLA-ASNBLOCK-AS
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       117       20       97   82.9%   SIGNET
AS813        309      223       86   27.8%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS7195       122       44       78   63.9%   INTERRED
AS1967       150       72       78   52.0%   Middle East Technical University 
AS2704       262      191       71   27.1%   HOOKUP-NET-A
AS855        129       61       68   52.7%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        866      807       59    6.8%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        219      166       53   24.2%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS97         186      139       47   25.3%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS4175       481      435       46    9.6%   CONNECT-NCM
AS3739       182      137       45   24.7%   NEWNET
AS3561       904      859       45    5.0%   MCI
AS3491       134       89       45   33.6%   CAIS-ASN
AS225         76       32       44   57.9%   University of Virginia (VIRnet)
AS816        188      146       42   22.3%   UUNETCA-AS4

 --- 17Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1511     1057      454   30.0%   Performance Systems International
AS2493       845      521      324   38.3%   i*internet
AS3602       629      337      292   46.4%   Sprint Canada Inc.
AS1221      1365     1104      261   19.1%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1093      911      182   16.7%   BBN Planet backbone
AS1691       308      172      136   44.2%   BCTEL
AS2048       253      126      127   50.2%   State of Louisiana/Office of Tele
AS721        482      374      108   22.4%   DLA-ASNBLOCK-AS
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        307      220       87   28.3%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS7195       119       47       72   60.5%   INTERRED
AS2704       262      192       70   26.7%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        856      797       59    6.9%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3739       192      139       53   27.6%   NEWNET
AS3397        74       22       52   70.3%   EMI-AS
AS97         187      140       47   25.1%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS4175       468      423       45    9.6%   CONNECT-NCM
AS3491       134       89       45   33.6%   CAIS-ASN
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS3320        59       17       42   71.2%   Deutsche Telekom AG
AS3561       893      852       41    4.6%   MCI
AS3132        83       42       41   49.4%   Red Cientifica Peruana (ASN-RCP)

 --- 16Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1518     1063      455   30.0%   Performance Systems International
AS2493       838      516      322   38.4%   i*internet
AS3602       629      337      292   46.4%   Sprint Canada Inc.
AS1221      1368     1108      260   19.0%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1104      914      190   17.2%   BBN Planet backbone
AS1691       308      172      136   44.2%   BCTEL
AS2048       253      126      127   50.2%   State of Louisiana/Office of Tele
AS721        475      367      108   22.7%   DLA-ASNBLOCK-AS
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        304      218       86   28.3%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       149       73       76   51.0%   Middle East Technical University 
AS7195       119       47       72   60.5%   INTERRED
AS855        132       63       69   52.3%   NBTel
AS2704       260      191       69   26.5%   HOOKUP-NET-A
AS2386       187      121       66   35.3%   INS-AS
AS701        857      798       59    6.9%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS3739       192      139       53   27.6%   NEWNET
AS549        217      165       52   24.0%   ONet Backbone
AS3397        74       22       52   70.3%   EMI-AS
AS3799        72       25       47   65.3%   IDS
AS3561       903      857       46    5.1%   MCI
AS97         176      131       45   25.6%   JvNCnet
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3491       133       88       45   33.8%   CAIS-ASN
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS3320        59       17       42   71.2%   Deutsche Telekom AG

 --- 15Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1524     1069      455   29.9%   Performance Systems International
AS2493       842      519      323   38.4%   i*internet
AS1221      1349     1095      254   18.8%   AARNET-AS
AS3602       557      327      230   41.3%   Sprint Canada Inc.
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1116      919      197   17.7%   BBN Planet backbone
AS1691       308      172      136   44.2%   BCTEL
AS721        481      373      108   22.5%   DLA-ASNBLOCK-AS
AS2048       208      106      102   49.0%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        308      220       88   28.6%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       149       73       76   51.0%   Middle East Technical University 
AS2704       262      192       70   26.7%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        861      803       58    6.7%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3739       192      139       53   27.6%   NEWNET
AS97         187      140       47   25.1%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3561       901      856       45    5.0%   MCI
AS3491       135       90       45   33.3%   CAIS-ASN
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS3397        61       19       42   68.9%   EMI-AS
AS3320        59       17       42   71.2%   Deutsche Telekom AG
AS3132        83       42       41   49.4%   Red Cientifica Peruana (ASN-RCP)

 --- 14Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1530     1071      459   30.0%   Performance Systems International
AS2493       842      519      323   38.4%   i*internet
AS3602       622      336      286   46.0%   Sprint Canada Inc.
AS1221      1368     1113      255   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1120      923      197   17.6%   BBN Planet backbone
AS1691       307      171      136   44.3%   BCTEL
AS2048       243      127      116   47.7%   State of Louisiana/Office of Tele
AS721        480      372      108   22.5%   DLA-ASNBLOCK-AS
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        308      223       85   27.6%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       149       73       76   51.0%   Middle East Technical University 
AS7195       118       46       72   61.0%   INTERRED
AS2704       263      192       71   27.0%   HOOKUP-NET-A
AS855        133       63       70   52.6%   NBTel
AS2386       188      121       67   35.6%   INS-AS
AS701        872      809       63    7.2%   Alternet
AS2711       114       56       58   50.9%   SUNBELT-AS
AS4454        75       21       54   72.0%   OIR Telecommunications, State of 
AS3739       192      138       54   28.1%   NEWNET
AS549        219      166       53   24.2%   ONet Backbone
AS3397        74       22       52   70.3%   EMI-AS
AS97         185      138       47   25.4%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS3561       907      861       46    5.1%   MCI
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3491       135       90       45   33.3%   CAIS-ASN
AS225         75       31       44   58.7%   University of Virginia (VIRnet)




2) Weekly Delta

This a daily snapshot of changes in classful routes being withdrawn and added.
the deltas are calculated over a rolling 7 day period. Please bear in mind this
is purely a "snapshot" and a large flucuation could be caused by a connectivity
problem for example. However, this does give some indication of service
providers that are moving to classless routing.


Top 20 Withdrawn Classful Routes from 14Mar97 to 21Mar97
	-220  AS721 DLA-ASNBLOCK-AS
	 -45 AS4780 APNIC-AS-BLOCK
	 -31 AS2752 THOMSONCA-AS
	 -23 AS2497 IIJNET
	 -20 AS1325 ANS Cleveland - DNSS 43
	 -17 AS4433 Access One Pty Ltd (ASN-ACCESS-ON
	 -16 AS4364 IgLou Internet Services
	 -15  AS724 DLA-ASNBLOCK-AS
	 -11  AS400 AFCONC-BLOCK1-AS
	 -10 AS4778 AUNET Corp.
	  -9  AS278 Red Academica de la UNAM, Mexico.
	  -8 AS5872 DDN-ASNBLK
	  -7 AS3300 AT&T-Unisource Communications Ser
	  -6 AS8013 PSINET-CA
	  -5 AS2711 SUNBELT-AS
	  -4 AS1333 ANS Atlanta - DNSS 107
	  -3 AS6203 ISDN-Net Inc.
	  -2 AS2563 KoRea Education Network
	  -1 AS5071 WesTel Telecommunications Ltd (We

Top 20 Added Classful Routes from 14Mar97 to 21Mar97
	  43 AS4648 NZIX 2
	  42  AS685 NorthWestNet Primary AS
	  36 AS2015 Msen, Inc.
	  30  AS816 UUNETCA-AS4
	  21 AS3255 Ukrainian Academic and Research N
	  19 AS2521 Tokyo Internet
	  18  AS701 Alternet
	  17 AS1794 SprintLink Pennsauken NJ
	  15 AS2048 State of Louisiana/Office of Tele
	  14 AS5650 Electric Lightwave Inc. and XMiss
	  13 AS3602 Sprint Canada Inc.
	  11 AS4740 OzEmail ISP
	  10 AS1221 AARNET-AS
	   9 AS3404 COLORADOCOOP
	   8 AS5486 Euronet Digital Communications
	   7 AS4004 Global IP
	   6 AS3749 Tennessee Board of Regents
	   5 AS5560 UNIGLOBE
	   4 AS3267 RUNNet
	   3 AS4174 CONNECT-COM

This a daily snapshot of changes in classles routes being withdrawn and added.


Top 20 Withdrawn Classles Routes from 14Mar97 to 21Mar97
	 -18 AS5501 Fraunhofer Gesellschaft
	 -14 AS1221 AARNET-AS
	  -9 AS3559 KORNET-3559 Autonomous-system
	  -8  AS701 Alternet
	  -7 AS4780 APNIC-AS-BLOCK
	  -6 AS4060 KORNET-AS4060
	  -5 AS1325 ANS Cleveland - DNSS 43
	  -4 AS6753 DPN location Duisburg
	  -3 AS3300 AT&T-Unisource Communications Ser
	  -2 AS4805 Global IP
	  -1  AS378 ILAN

Top 20 Added Classles Routes from 14Mar97 to 21Mar97
	  32  AS568 JIS (Joint Interconnection Servic
	  21  AS681 KAWAIHIKO-1
	  12 AS2907 SINET
	   9 AS2018 The research and academic network
	   8  AS685 NorthWestNet Primary AS
	   7 AS4742 AT&T EasyLink Services Australia 
	   5 AS3561 MCI
	   4 AS2548 DIGEX-AS
	   3 AS4664 Hyundai Information Technology Co
	   2 AS5659 VIVANET
	   1 AS5679 PBI-NET-BLK



3) Interesting aggregates



            List of possibly interesting aggregates
            ---------------------------------------

         Aggregate | Origin | AS Description          | Netname                
-------------------------------------------------------------------------------
     154.11.1.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.2.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.8.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.9.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.10.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.11.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.12.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.33.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.34.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.35.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.36.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.37.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.48.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.50.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.52.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.64.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.65.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.66.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.67.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.96.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.97.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.98.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.99.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.100.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.101.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.102.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.103.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.104.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.105.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.108.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.109.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.110.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.111.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.112.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.113.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.114.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.120.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.121.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.122.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.123.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.124.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.126.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.127.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.129.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.130.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.136.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.13.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.16.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.17.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.18.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.19.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.24.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.25.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.26.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.27.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.28.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.32.0/24 | AS8013 | PSINET-CA               | *                      
     24.130.0.0/18 | AS7757 | CCI-AS2-BLK             | @Home Network (NETBLK-A
   24.131.128.0/18 | AS7756 | CCI-AS2-BLK             | @Home Network (NETBLK-A
  142.205.232.0/23 | AS7734 | AS For TDBANK           | Canadian Research Netwo
  142.205.240.0/23 | AS7734 | AS For TDBANK           | Canadian Research Netwo
  142.205.248.0/23 | AS7734 | AS For TDBANK           | Canadian Research Netwo
   129.231.48.0/21 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.56.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.59.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.67.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
  146.115.132.0/23 | AS7174 | Onward Technologies, In | UltraNet Communications
   207.48.62.32/27 | AS7052 | HTS-AS                  | MCI Internet Services (
     24.129.0.0/18 | AS7017 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.131.0.0/18 | AS7016 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.128.0.0/18 | AS7015 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.113.0.0/18 | AS6997 | Rogers Network Services | @Home Network (NETBLK-A
     24.113.0.0/19 | AS6997 | Rogers Network Services | @Home Network (NETBLK-A
  192.254.27.16/29 | AS6989 | GTSI                    | GTSI (NET-GTSI27)      
    206.96.20.0/26 | AS6900 | EDS Industrien (Deutsch | MCI FRACTIONALY ASSIGNE
   206.96.20.64/26 | AS6900 | EDS Industrien (Deutsch | MCI FRACTIONALY ASSIGNE
   152.158.84.0/24 | AS6755 | ASN - TURNET            | Advantis (NET-ADVANTIS-
   160.81.156.0/24 | AS6718 | Global One Italy        | Sprint International (N
   160.81.252.0/24 | AS6718 | Global One Italy        | Sprint International (N
194.235.164.232/30 | AS6718 | Global One Italy        | European Regional Inter
      24.96.0.0/18 | AS6541 | GTE Intelligent Network | @Home Network (NETBLK-A
   163.247.83.0/27 | AS6471 | ENTELCHILE              | Oficina de Estudios y P
     24.112.0.0/19 | AS6463 | Rogers Network Services | @Home Network (NETBLK-A
  168.234.128.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  168.234.135.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  206.152.59.32/28 | AS6362 | VAULTLINE-AS            | Globetrotter Software (
 206.114.192.64/26 | AS6347 | Savvis - St.Louis Regio | Savvis Communications (
206.114.192.128/26 | AS6347 | Savvis - St.Louis Regio | Savvis Communications (
      24.64.0.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
     24.64.32.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
 205.138.230.64/27 | AS6307 | AMERICAN-EXPRESS        | American Express (NET-M
205.138.230.128/27 | AS6307 | AMERICAN-EXPRESS        | American Express (NET-M
   149.236.92.0/24 | AS6292 | FCI                     | Bruker Analytische Mess
       12.1.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.5.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.8.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.9.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
      12.0.64.0/18 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
    134.129.0.0/18 | AS6263 | NDIN                    | North Dakota State Univ
   134.129.64.0/18 | AS6263 | NDIN                    | North Dakota State Univ
  134.129.128.0/17 | AS6263 | NDIN                    | North Dakota State Univ
     165.88.1.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.15.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.17.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.19.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.23.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.24.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.27.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.28.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.29.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.30.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.31.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.32.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.33.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.34.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.35.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.36.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.37.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.38.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.39.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.40.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.41.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.42.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.43.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.44.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.45.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.46.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.47.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.49.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.50.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.51.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.100.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.101.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.102.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.104.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.105.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.106.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.107.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.108.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.109.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.110.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.111.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.112.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.113.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.114.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.124.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.125.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.126.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.128.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.129.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.130.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.131.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.132.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.133.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.134.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.135.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.151.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.152.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.154.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.155.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.158.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.159.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.160.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.163.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.166.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.168.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.175.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.177.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.179.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.182.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.190.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.195.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.200.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.206.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.207.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.208.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.209.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.212.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.217.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.230.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.235.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.236.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.240.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.242.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.251.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.115.0/24 | AS6254 | EGGINC                  | *                      
   165.88.116.0/24 | AS6254 | EGGINC                  | *                      
   165.88.117.0/24 | AS6254 | EGGINC                  | *                      
   165.88.118.0/24 | AS6254 | EGGINC                  | *                      
   165.88.119.0/24 | AS6254 | EGGINC                  | *                      
   165.88.120.0/24 | AS6254 | EGGINC                  | *                      
   165.88.121.0/24 | AS6254 | EGGINC                  | *                      
   165.88.122.0/24 | AS6254 | EGGINC                  | *                      
   165.88.252.0/24 | AS6254 | EGGINC                  | *                      
   165.88.253.0/24 | AS6254 | EGGINC                  | *                      
   165.88.254.0/24 | AS6254 | EGGINC                  | *                      
   146.115.96.0/22 | AS6249 | UltraNet RI             | UltraNet Communications
  170.147.200.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.208.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.216.0/22 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.220.0/24 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
       24.0.0.0/14 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.0.0.0/18 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.1.0.0/17 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
   169.130.52.0/24 | AS6153 | ASN-SPRN-NYSERNET       | Sprint, Business Servic
  165.113.197.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.198.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.199.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.211.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
   161.223.90.0/23 | AS6077 | Network Intensive - A D | Indian Health Service (
   148.94.210.0/24 | AS5714 | EDS-WEBS                | EDS Network Naming & Ad
   165.247.33.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.36.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.47.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.77.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.88.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.101.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.234.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.235.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.236.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.237.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.240.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.241.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.244.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.247.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.248.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.249.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.250.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  157.232.100.0/24 | AS5696 | Primary AS for GoodNet  | Health Data Sciences Co
   169.149.70.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
   169.149.98.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
   169.149.99.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
    148.160.6.0/24 | AS5556 | Telenordia AB           | Boras Energi (NET-BS-EN
   153.96.232.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   194.215.65.4/30 | AS5488 | Skynet                  | European Regional Inter
  194.151.154.1/32 | AS5484 | BT Netherlands Regional | European Regional Inter
    131.114.0.0/17 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
  131.114.128.0/18 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
   194.72.24.89/32 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.25.246/32 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.26.172/30 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.26.204/30 | AS5400 | BT INCS network.        | European Regional Inter
      57.12.0.0/16 | AS5384 | Etisalat Emirates Inter | SITA-Societe Internatio
  165.215.191.0/24 | AS5090 | CWI-NYD                 | Bell & Howell Company (
      12.64.0.0/12 | AS5074 | ATT-WN-DP               | AT&T ITS (NET-ATT)     
  166.102.163.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.164.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.165.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
   160.81.101.0/24 | AS4861 | Global One Communicatio | Sprint International (N
   163.44.224.0/23 | AS4853 | Justsystem Corporation  | Justsystem Corporation 
   164.100.80.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce
  164.100.199.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce
     158.40.3.0/24 | AS4740 | OzEmail ISP             | Department of Prime Min
     158.40.4.0/24 | AS4740 | OzEmail ISP             | Department of Prime Min
   202.69.3.192/26 | AS4639 | Planet Internet Limited | Asia Pacific Network In
   146.222.11.0/24 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
  146.222.198.0/23 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
     168.29.0.0/17 | AS4565 | HLC Networks            | State of Georgia/Board 
     168.29.0.0/17 | AS4565 | HLC Networks            | State of Georgia/Board 
  152.129.186.0/24 | AS4478 | PNET-STL                | Department of Veterans 
   208.196.3.64/29 | AS4372 | Telerama                | Administrative Office o
     166.45.0.0/19 | AS4292 | MCI Reston              | MCI Internet Services (
    166.45.22.0/24 | AS4292 | MCI Reston              | MCI Internet Services (
 204.70.252.248/29 | AS4292 | MCI Reston              | MCI IP Development (NET
     159.24.7.0/24 | AS4286 | IMCI                    | MCI Telecommunications 
   128.193.32.0/19 | AS4201 | Oregon State University | Oregon State University
   128.193.64.0/19 | AS4201 | Oregon State University | Oregon State University
   128.193.96.0/19 | AS4201 | Oregon State University | Oregon State University
  128.193.128.0/19 | AS4201 | Oregon State University | Oregon State University
  128.193.160.0/19 | AS4201 | Oregon State University | Oregon State University
  128.193.192.0/19 | AS4201 | Oregon State University | Oregon State University
  128.193.224.0/19 | AS4201 | Oregon State University | Oregon State University
   206.250.40.0/25 | AS4200 | AGIS (Apex Global Infor | Overland Network (NET-O
   166.102.95.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.97.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.99.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.101.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.102.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.103.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.105.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.106.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.108.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.109.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.110.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.113.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.114.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.116.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.117.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.120.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.122.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.123.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.150.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   206.250.27.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  205.199.213.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.203.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.204.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  150.207.128.0/24 | AS4175 | CONNECT-NCM             | AWA Defence Industries 
    163.124.7.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
  163.124.221.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
    156.5.252.0/23 | AS4004 | Global IP               | Unilever (NET-UNILEVER2
      24.72.0.0/18 | AS4004 | Global IP               | @Home Network (NETBLK-A
    147.85.21.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.25.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.39.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.44.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.51.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.54.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.98.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
   147.85.115.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
  162.126.135.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.136.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.137.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.138.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  161.200.139.0/24 | AS3839 | CHULANET                | Chulalongkorn Universit
  149.112.251.0/24 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.252.0/23 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.254.0/24 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
   163.249.43.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.53.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.54.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.57.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.140.0/22 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.160.0/21 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.168.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.169.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.170.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   148.207.38.0/24 | AS3632 | INFOTEC-RTN             | Consejo Nacional de Cie
     163.12.0.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.5.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.6.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.8.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.16.0/22 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.21.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.22.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.22.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.23.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.24.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.32.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.64.0/18 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.64.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.81.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.82.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.84.0/22 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.88.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.96.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.128.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.136.0/22 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.144.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.160.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.192.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.240.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
  157.126.209.0/24 | AS3563 | Pilot Network Services, | J.M. Huber Corp. (NET-H
  157.126.212.0/24 | AS3563 | Pilot Network Services, | J.M. Huber Corp. (NET-H
      161.6.0.0/17 | AS3561 | MCI                     | Western Kentucky Univer
    161.6.128.0/17 | AS3561 | MCI                     | Western Kentucky Univer
  158.106.253.0/24 | AS3561 | MCI                     | VA Power Co. (NET-VANCP
   148.212.48.0/20 | AS3561 | MCI                     | Universidad Autonoma de
   148.212.64.0/18 | AS3561 | MCI                     | Universidad Autonoma de
  148.212.128.0/17 | AS3561 | MCI                     | Universidad Autonoma de
  165.237.108.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
  165.237.220.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
    164.103.3.0/24 | AS3561 | MCI                     | Telecommunications Depa
   163.49.131.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.132.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.136.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.140.0/23 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.142.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
     168.14.1.0/24 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.2.0/23 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.4.0/22 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.8.0/21 | AS3561 | MCI                     | State of Georgia/Board 
    168.14.16.0/20 | AS3561 | MCI                     | State of Georgia/Board 
   134.204.14.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  134.204.176.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  155.203.254.0/24 | AS3561 | MCI                     | Safety-Kleen Corporatio
  132.235.204.0/24 | AS3561 | MCI                     | Ohio University (NET-OH
   147.206.20.0/24 | AS3561 | MCI                     | Ochsner Foundation (NET
    161.120.6.0/24 | AS3561 | MCI                     | Norton Company (NET-SGC
   161.181.37.0/24 | AS3561 | MCI                     | Nordstrom, Inc. (NET-NO
   164.100.64.0/20 | AS3561 | MCI                     | National Informatics Ce
   164.100.81.0/24 | AS3561 | MCI                     | National Informatics Ce
   164.100.82.0/23 | AS3561 | MCI                     | National Informatics Ce
   164.100.84.0/22 | AS3561 | MCI                     | National Informatics Ce
   164.100.88.0/21 | AS3561 | MCI                     | National Informatics Ce
   164.100.96.0/19 | AS3561 | MCI                     | National Informatics Ce
  164.100.167.0/24 | AS3561 | MCI                     | National Informatics Ce
    159.179.0.0/24 | AS3561 | MCI                     | MIGROSBANK (NET-MIGROSB
    166.38.40.0/24 | AS3561 | MCI                     | MCI Telecommunications 
    166.43.30.0/27 | AS3561 | MCI                     | MCI Telecommunications 
 166.32.131.160/27 | AS3561 | MCI                     | MCI Telecommunications 
 166.35.174.160/27 | AS3561 | MCI                     | MCI Telecommunications 
  165.166.123.0/24 | AS3561 | MCI                     | Info Avenue Internet Se
  165.108.130.0/23 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.132.0/22 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.136.0/21 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.144.0/22 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.148.0/23 | AS3561 | MCI                     | ITOCHU Corporation (NET
       9.67.0.0/19 | AS3561 | MCI                     | IBM Corporation (NET-IB
   147.116.63.0/24 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
   147.116.64.0/23 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.160.0/21 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.168.0/22 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  167.208.125.0/24 | AS3561 | MCI                     | Harcourt Brace & Co. (N
    166.147.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.150.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.151.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.147.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.150.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.151.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.147.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  137.170.136.0/24 | AS3561 | MCI                     | Freudenberg-NOK (NET-FN
    136.140.9.0/24 | AS3561 | MCI                     | Ford Motor Company (NET
    169.200.1.0/24 | AS3561 | MCI                     | First Union National Ba
    169.200.9.0/24 | AS3561 | MCI                     | First Union National Ba
   168.175.70.0/24 | AS3561 | MCI                     | First Union National Ba
   169.200.11.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.170.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.171.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.172.0/24 | AS3561 | MCI                     | First Union National Ba
  146.18.32.192/26 | AS3561 | MCI                     | Federal Express Corpora
    167.77.32.0/24 | AS3561 | MCI                     | Dequesne Light Company 
    147.160.0.0/17 | AS3561 | MCI                     | Concurrent Technologies
  147.160.128.0/18 | AS3561 | MCI                     | Concurrent Technologies
  147.160.192.0/20 | AS3561 | MCI                     | Concurrent Technologies
  147.160.200.0/21 | AS3561 | MCI                     | Concurrent Technologies
  147.160.208.0/20 | AS3561 | MCI                     | Concurrent Technologies
  147.160.224.0/19 | AS3561 | MCI                     | Concurrent Technologies
  147.160.224.0/20 | AS3561 | MCI                     | Concurrent Technologies
  167.105.232.0/24 | AS3561 | MCI                     | Coca-Cola Enterprises (
    168.97.37.0/24 | AS3561 | MCI                     | Carlson Companies (NET-
    135.40.66.0/24 | AS3561 | MCI                     | AT&T ITS (NETBLK-ATT-13
     135.37.2.0/24 | AS3561 | MCI                     | AT&T ITS (NET-ATT-135-3
     135.37.4.0/24 | AS3561 | MCI                     | AT&T ITS (NET-ATT-135-3
    135.37.10.0/24 | AS3561 | MCI                     | AT&T ITS (NET-ATT-135-3
  138.108.100.0/24 | AS3561 | MCI                     | A.C. Nielsen Company (N
      24.88.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
     24.124.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
  159.140.213.0/24 | AS3561 | MCI                     | *                      
  159.140.254.0/24 | AS3561 | MCI                     | *                      
   163.180.96.0/19 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
  163.180.128.0/17 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
    143.192.1.0/24 | AS3549 | Primenet Services for t | Choice Hotels Internati
     168.29.0.0/17 | AS3492 | ATLANTA                 | State of Georgia/Board 
   206.161.67.0/30 | AS3491 | CAIS-ASN                | CAIS Internet (NETBLK-C
  207.226.209.0/26 | AS3491 | CAIS-ASN                | CAIS Internet (NETBLK-C
  143.222.116.0/24 | AS3407 | Interpath               | Cummins Engine Company 
  149.172.150.0/24 | AS3402 | TerraNet, Inc.          | Ikos Systems Incorporat
  164.167.103.0/24 | AS3392 | Infinet Norfolk - MAE-E | Bureau of Medicine and 
   163.49.143.0/24 | AS3384 | New York Net            | TDK Corporation (NET-TD
   163.49.144.0/22 | AS3384 | New York Net            | TDK Corporation (NET-TD
    167.170.6.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
   167.170.32.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
 194.237.174.32/27 | AS3308 | TeliaNet Denmark        | European Regional Inter
    194.19.0.15/32 | AS3307 | Telia ICN Norway        | European Regional Inter
 194.183.203.44/30 | AS3305 | Internet Service Provid | European Regional Inter
   156.51.150.0/24 | AS3301 | TeliaNet Sweden         | Vasakronan (NET-VASAKRO
   156.51.204.0/24 | AS3301 | TeliaNet Sweden         | Vasakronan (NET-VASAKRO
    164.9.190.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.192.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.194.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.196.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
   164.10.140.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
  164.10.27.128/26 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
   146.75.251.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   146.75.254.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   171.25.128.0/19 | AS3301 | TeliaNet Sweden         | European Regional Inter
   171.25.144.0/21 | AS3301 | TeliaNet Sweden         | European Regional Inter
     137.39.2.4/32 | AS3300 | AT&T-Unisource Communic | UUNET Technologies, Inc
    149.212.0.0/18 | AS3292 | Tele Danmark Internet E | Siemens-Nixdorf Informa
 194.135.241.16/30 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.152/29 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.160/29 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.199/32 | AS3255 | Ukrainian Academic and  | European Regional Inter
    151.86.72.0/21 | AS3242 | ITnet S.p.A. Autonomous | IUnet (NET-IUNET-BNET86
  194.142.136.8/30 | AS3238 | ALCOM                   | European Regional Inter
     171.18.1.0/24 | AS3215 | RAIN                    | European Regional Inter
    135.14.65.0/24 | AS3111 | Internet Direct Inc. (A | Lucent Technologies (NE
   139.61.102.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
   139.61.103.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
  165.212.158.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
  165.212.230.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
   160.92.129.0/24 | AS2917 | OLEANE - UUNET PIPEX In | Axime S.A. (NET-SEGIN) 
     133.34.9.0/24 | AS2907 | SINET                   | Yokohama National Unive
     157.1.16.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.31.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.32.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.34.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.51.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.52.0/24 | AS2907 | SINET                   | National Center for Sci
     157.1.60.0/24 | AS2907 | SINET                   | National Center for Sci
    157.1.101.0/24 | AS2907 | SINET                   | National Center for Sci
    157.1.151.0/24 | AS2907 | SINET                   | National Center for Sci
    157.1.152.0/24 | AS2907 | SINET                   | National Center for Sci
    157.1.153.0/24 | AS2907 | SINET                   | National Center for Sci
   146.193.60.0/22 | AS2860 | IP Global, Informatica  | INESC (NET-INESC)      
   145.17.100.0/24 | AS2856 | BTnet UK Regional netwo | Unilever Research Labor
   145.246.16.0/24 | AS2856 | BTnet UK Regional netwo | No match for "145.246.0
   145.246.17.0/24 | AS2856 | BTnet UK Regional netwo | No match for "145.246.0
   143.252.80.0/24 | AS2856 | BTnet UK Regional netwo | News International (NET
  158.174.254.0/24 | AS2856 | BTnet UK Regional netwo | KPMG Peat Marwick (NET-
   194.61.54.32/27 | AS2856 | BTnet UK Regional netwo | European Regional Inter
   171.30.170.0/24 | AS2856 | BTnet UK Regional netwo | BR Telecommunications L
  159.142.192.0/18 | AS2714 | General Services Admini | General Services Admini
    159.142.0.0/18 | AS2714 | General Services Admini | *                      
   159.142.64.0/18 | AS2714 | General Services Admini | *                      
  159.142.128.0/18 | AS2714 | General Services Admini | *                      
  144.127.110.0/23 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.112.0/20 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.128.0/19 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.160.0/21 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.168.0/23 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  145.248.112.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.155.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.157.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.159.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.161.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.165.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
    164.53.55.0/24 | AS2706 | HKSUPER                 | National Australia Bank
    134.6.160.0/22 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
    134.6.180.0/24 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
       9.20.0.0/17 | AS2686 | Autonomous System numbe | IBM Corporation (NET-IB
   155.39.191.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
   155.39.230.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
    140.212.2.0/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
  140.212.2.128/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
      32.96.0.0/16 | AS2685 | IBM Global Network - US | Norsk Informasjonstekno
  192.129.3.128/25 | AS2614 | Romanian Educational Ne | German National Researc
  131.114.192.0/18 | AS2598 | Consiglio Nazionale del | CNR - Istituto CNUCE (N
    137.98.96.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.97.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.98.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.99.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.100.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.101.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.102.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.196.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.200.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.203.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.204.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.208.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.209.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.223.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.224.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.225.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.235.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.239.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.240.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
  142.218.120.0/24 | AS2551 | NETCOM On-line Communic | George Weston Ltd. (NET
  141.227.111.0/24 | AS2529 | Demon Internet Ltd      | Societe Nationale Elf A
  159.197.158.0/23 | AS2529 | Demon Internet Ltd      | Civil Aviation Authorit
  156.114.200.0/24 | AS2529 | Demon Internet Ltd      | Baring Securities Limit
    129.237.0.0/18 | AS2495 | KANREN                  | University of Kansas (N
  155.194.200.0/24 | AS2493 | i*internet              | City of Kitchener (NET-
    137.15.34.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.35.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.39.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.41.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.43.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.44.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.52.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.54.0/24 | AS2493 | i*internet              | Central Mapping Agency 
  163.155.120.0/24 | AS2493 | i*internet              | Canada Mortgage and Hou
   205.250.6.64/26 | AS2493 | i*internet              | CBCL (NET-CBCL-CA)     
  161.173.243.0/24 | AS2386 | INS-AS                  | Wal-Mart Stores, Inc. (
  145.247.128.0/18 | AS2120 | DAXnet (Tele 3)         | No match for "145.247.0
   153.110.50.0/24 | AS2120 | DAXnet (Tele 3)         | Fellesdata AS (NET-FELL
    148.122.1.0/24 | AS2119 | Telenor Internett, Norw | Telenor AS (NET-NORTELE
    146.192.0.0/17 | AS2119 | Telenor Internett, Norw | Allianse Informasionssy
  146.192.128.0/17 | AS2116 | EUnet Norway            | Allianse Informasionssy
   157.151.64.0/19 | AS2041 | CRL-GATE                | Information Access Tech
   169.24.186.0/24 | AS2019 | JP MORGAN               | J.P. Morgan & Co. (NETB
     148.59.4.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.224.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.241.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.244.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.245.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.246.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.247.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
    198.11.42.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
    198.11.51.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
   164.52.249.0/24 | AS1982 | Northwest Nexus, Inc.   | Associated Grocers, Inc
    157.25.64.0/23 | AS1887 | NASK                    | Advanced Technology Man
   161.51.224.0/20 | AS1849 | PIPEX, Public IP EXchan | The M.W. Kellogg Compan
  148.176.225.0/24 | AS1849 | PIPEX, Public IP EXchan | ScottishPower (NET-SCOT
  155.140.124.0/24 | AS1849 | PIPEX, Public IP EXchan | Paribas, Ltd. (NET-CMD1
   148.185.45.0/24 | AS1849 | PIPEX, Public IP EXchan | Mercury Communications 
   159.245.84.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
  159.245.104.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
   170.194.51.0/24 | AS1849 | PIPEX, Public IP EXchan | Deloitte Touche Tohmats
  150.185.128.0/18 | AS1800 | ICM-Atlantic            | Consejo Nacional de Inv
  150.185.192.0/18 | AS1800 | ICM-Atlantic            | Consejo Nacional de Inv
   169.130.31.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   169.130.54.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   149.212.64.0/20 | AS1759 | Telecom Finland iNET    | Siemens-Nixdorf Informa
        9.2.0.0/16 | AS1747 | IBM Watson, Yorktown He | IBM Corporation (NET-IB
      24.48.0.0/18 | AS1677 | ANS  Hartford - CNSS 53 | @Home Network (NETBLK-A
   204.148.62.0/26 | AS1673 | ANS-BB                  | ANS CO+RE Systems, Inc.
  194.51.28.152/30 | AS1667 | ANS-DC2                 | European Regional Inter
    152.164.0.0/21 | AS1667 | ANS-DC2                 | ANS CO+RE Systems, Inc.
  157.184.150.0/24 | AS1330 | ANS St. Louis - DNSS 83 | Lexmark International I
  149.112.246.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.247.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.248.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.249.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
      24.48.0.0/18 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.62.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
    148.212.1.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.2.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.3.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.4.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.5.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.6.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.7.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.8.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.9.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.10.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.11.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.12.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.13.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.14.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.15.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.16.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.32.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
  160.104.128.0/17 | AS1290 | PSINet UK Ltd.          | Tadpole Technology, Inc
 192.151.12.171/32 | AS1290 | PSINet UK Ltd.          | Hewlett Packard (NET-HP
  130.168.105.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.115.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.125.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
   146.75.253.0/24 | AS1257 | SWIPnet Swedish IP Netw | Nexus AB (NET-COMBITECH
  144.199.161.0/24 | AS1238 | ICM Malaysia (MIMOS) co | Sarawak Shell Berhad (N
    163.180.0.0/18 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
   163.180.64.0/19 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
     159.99.0.0/17 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
   159.99.128.0/19 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
   159.99.160.0/21 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
   158.155.24.0/22 | AS1221 | AARNET-AS               | Computer Generation (NE
    150.207.2.0/24 | AS1221 | AARNET-AS               | AWA Defence Industries 
     24.192.0.0/18 | AS1221 | AARNET-AS               | @Home Network (NETBLK-A
  139.162.128.0/17 | AS1136 | Unisource Internet Serv | Nedlloyd Computer Servi
    145.100.0.0/18 | AS1103 | SURFnet                 | SURFnet BV (NET-SURFNET
     24.108.0.0/18 |  AS852 | AGT Advance Communicati | @Home Network (NETBLK-A
    24.112.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    24.113.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    150.241.0.0/20 |  AS766 | RedIRIS Autonomous Syst | LABEIN (NET-ESZSARE)   
    149.20.64.0/24 |  AS701 | Alternet                | Vixie Enterprises (NET-
     168.86.1.0/24 |  AS701 | Alternet                | United Artists Theater 
    160.104.0.0/17 |  AS701 | Alternet                | Tadpole Technology, Inc
     134.6.77.0/24 |  AS701 | Alternet                | Maxtor Corporation (NET
   158.118.51.0/24 |  AS701 | Alternet                | Matsushita Electric Wor
  167.152.251.0/24 |  AS701 | Alternet                | EMI Communications Corp
   134.33.100.0/24 |  AS701 | Alternet                | Codex Corporation (NET-
   164.218.95.0/24 |  AS701 | Alternet                | Bureau of Naval Personn
   155.134.60.0/24 |  AS701 | Alternet                | Best Foods Baking Group
      155.7.0.0/19 |  AS701 | Alternet                | American Forces Informa
     155.7.64.0/18 |  AS701 | Alternet                | American Forces Informa
    155.7.128.0/17 |  AS701 | Alternet                | American Forces Informa
    165.125.0.0/17 |  AS701 | Alternet                | Alexander & Alexander I
     155.7.32.0/21 |  AS701 | Alternet                | *                      
     155.7.40.0/24 |  AS701 | Alternet                | *                      
     155.7.41.0/24 |  AS701 | Alternet                | *                      
     155.7.42.0/23 |  AS701 | Alternet                | *                      
     155.7.44.0/22 |  AS701 | Alternet                | *                      
     155.7.48.0/20 |  AS701 | Alternet                | *                      
    130.188.2.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.3.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.9.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.150.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.250.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.252.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    131.117.0.0/17 |  AS559 | SWITCH, Swiss Academic  | Municipality of Zuerich
      53.64.4.0/22 |  AS517 | Xlink                   | cap debis ccs (NET-DB-N
    153.96.80.0/21 |  AS517 | Xlink                   | Fraunhofer Institut fue
    153.96.92.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
   153.96.230.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
    143.93.32.0/19 |  AS517 | Xlink                   | Fachhochschule Rheinlan
 194.59.152.128/27 |  AS517 | Xlink                   | European Regional Inter
  129.181.208.0/21 |  AS517 | Xlink                   | Bull Louveciennes (NET-
  129.181.216.0/22 |  AS517 | Xlink                   | Bull Louveciennes (NET-
  198.200.138.0/28 |  AS174 | Performance Systems Int | Quadritek Systems, Inc.
  128.145.228.0/24 |  AS174 | Performance Systems Int | Performance Systems Int
  199.99.247.32/27 |  AS174 | Performance Systems Int | Performance Systems Int
   136.161.17.0/24 |  AS174 | Performance Systems Int | PSI Network One (NET-PS
   162.17.253.0/24 |  AS174 | Performance Systems Int | Compass Design Automati
   129.35.208.0/24 |  AS163 | IBM-RESEARCH-AS         | IBM Corporation (NET-IB
    166.4.174.0/26 |    AS1 | BBN Planet backbone     | US Forest Service (NETB
 199.14.184.128/26 |    AS1 | BBN Planet backbone     | U.S. Sprint (NETBLK-SPR
  134.241.109.0/24 |    AS1 | BBN Planet backbone     | Massachusetts Higher Ed
  161.223.220.0/22 |    AS1 | BBN Planet backbone     | Indian Health Service (
  161.223.224.0/24 |    AS1 | BBN Planet backbone     | Indian Health Service (
   143.192.24.0/24 |    AS1 | BBN Planet backbone     | Choice Hotels Internati
    159.87.34.0/24 |    AS1 | BBN Planet backbone     | Arizona State Governmen
   135.16.150.0/24 |    AS1 | BBN Planet backbone     | AT&T ITS (NET-ATT-135-1




From Steven_M._Riley at aep.com  Fri Mar 21 19:05:26 1997
From: Steven_M._Riley at aep.com (Steven_M._Riley at aep.com)
Date: Fri, 21 Mar 1997 15:05:26 -0400
Subject: Frustrating...
Message-ID: <85256461.006E2D82.00@col_lngw.aepsc.com>





Can we get back to the good stuff, please? I joined this list because it
seemed like a great place to learn some the thorny technical stuff that
keeps the Internet going. Now all I get all day are mails from people
complaining about this and that and the other thing. I've given up reading
the "Domain rant" thread -- I just delete them all. I miss the technical
stuff.






From karl at Mcs.Net  Fri Mar 21 20:25:17 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Fri, 21 Mar 1997 14:25:17 -0600
Subject: Domain Rant
In-Reply-To: <199703211957.LAA03636@quest.pluris.com>; from Vadim Antonov on Fri, Mar 21, 1997 at 11:57:43AM -0800
References: <199703211957.LAA03636@quest.pluris.com>
Message-ID: <19970321142517.22127@Jupiter.Mcs.Net>

On Fri, Mar 21, 1997 at 11:57:43AM -0800, Vadim Antonov wrote:
> 
> I do not think the domain issue is beyond the scope of NANOG.
> In fact, w/o working DNS the value of services provided by N.A.N.Operators
> is zero.  In other words, the domain insanity reached the level where
> it starts to impact the business of ISPs materially.
> 
> In other words, it is in the interest of ISPs to step in and inject some
> sanity into how that vital part of infrastructure is being run.
> 
> ISPs is the only party in the debate which actually has resources and
> enough business sense to make it a workable setup.  I strongly suspect that
> "expert groups" and "engineering task forces" have already demonstrated
> their unability to fix the problem.
> 
> Now, to me it looks like CIDR movie rerun.
> 
> --vadim

Yep.

The problem is, who are the "ISPs" involved in this whole thing?

A half-dozen national megacorporations?  No.

The 2,000+ ISPs in the US who actually connect customers to the Internet?  
Yes.

What do THEY want?  Choice, quality of service, and happy customers.

	One of *OUR* domains (MCS.COM) was wrongly terminated the other day.  
	They still claim we haven't paid.  We claim we have, and have
	cancelled checks to prove it.  We dispute who has paid for what 
	period of time.  Fine and well.  Except for one problem.  
		They never invoiced us.

	They have turned it back on after much shouting from our accounting
	department, pending us receiving something which commercially passes
	as an invoice so that a real investigation of who has paid for what
	can be figured out.

	How do you dispute a bill you never received?  You don't.

	How do you possibly validate using *EMAIL* for invoices without prior
	consent (ie: by default), as NSI does?  The obvious reason for this is
	avoiding the cost of running it through the postage meter at 32 cents 
	a crack, but heh, if I have to do that to invoice my customers in a 
	legitimate format, why not NSI?

	Email, especially email without a digital signature affixed, is too 
	easily spoofed to be commercially acceptable for this kind of thing.  
	I don't pay off email bills, because there is no documentation and 
	no paper trail.

	If audited, guess what -- I have to produce that paper.

Now let's look at the alternatives to the current mess:

1)	IAHC - Nice concept, but troublesome in many areas.  Jurisdictional,
	regulatory, due process, all kinds of problems.  Unknown costs at
	the CORE level, unknown budgets, single-model.  

	The worst problem is that if it sucks we can't "go around" it as
	the Internet has always done.  Why?  Because it is claimed to be 
	the only model which will exist AND THERE ARE PEOPLE TRYING TO MAKE 
	IT THAT WAY BY FORCE THROUGH TREATY PROCEEDINGS.  Further, I don't 
	believe they CAN force NSI to play, or that NSI will voluntarily -- 
	and believe that NSI's recent press release backs up that view -- 
	but that's the claim.

	Costs? $20,000 to play in the lottery, plus $500,000 in hard assets 
	or a credit line for same.  This is a "big business" approach to the
	problem, and directly opposite how the net has been built from the
	ground up.

2)	eDNS - Open.  Consensual.  Multi-business-model based.  Build it
	and they will come (ie: how the net got where it is today).
	Operates on the principle that the policy of the root is to prevent
	market concentration (ie: monopoly) and collisions between TLDs, and
	nothing more.  The IAHC model and their TLDs (other than WEB and
	ARTS, which someone claimed first) are welcome.  The NSI model is 
	welcome.  Alternic is welcome.  Any other model, including a Freenet 
	who wants to run a registry, is welcome.  Lots of choices for 
	jurisdiction under which registrants can select from.  Lots of 
	business models to choose from.  Lots of different prices to be
	charged, and different levels of service assurance available for
	the fees assessed.  Due process as allowed or mandated by the laws
	governing the registry in question.  Fixed (zero) costs at the 
	root, fixed (zero) budgets. 

	$0 to play; based on rough consensus, working code, and a published
	policy for the world to view and evaluate *on its own*.

Which model SHOULD win?  

If you pick or support the IAHC model, then you had better be right -- because
the alternative is that the world collapses.

If you pick the eDNS model, you don't have to be right -- in fact, you don't
have to take a position on the "right" model.  eDNS supports all business
models, and believes that the "right" ones will survive *on their own*
without coercion being applied.

I think the choices are obvious, and the people who support the "fixed
model" rather transparent with their motivations. 

But of course, that's just my opinion.

I've said my peace on this.  Anyone on the "other side" who feels compelled
to get in the last word is welcome to do so.  Those who want more
information can get it through the web page below.

--
-- 
Karl Denninger (karl at MCS.Net)| eDNS - The free-market solution
http://www.edns.net/	     | hostmaster at edns.net




From perry at piermont.com  Fri Mar 21 20:09:06 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Fri, 21 Mar 1997 15:09:06 -0500
Subject: Domain Rant. 
In-Reply-To: Your message of "Fri, 21 Mar 1997 11:17:53 CST."
             <19970321111753.05243@Jupiter.Mcs.Net> 
Message-ID: <199703212009.PAA02326@jekyll.piermont.com>


Karl Denninger writes:
> On Fri, Mar 21, 1997 at 12:07:54PM -0500, Perry E. Metzger wrote:
> > 
> > Karl Denninger writes:
> > > No it doesn't.
> > > 
> > > If you register with someone, pay them, and they claim never to have
> > > received payment you're just as screwed.
> > 
> > No, you aren't. Today, if someone does that, you are stuck. 
> 
> Boiled down: You pay again.

What happens if you go into a McDonald's, order lunch, pay for it, and
they don't give you your food? You may sue, but the biggest impact you
can have is not using their service again.

> I know you're good at trying to avoid facts, but this is rediculous!

Whatever, Karl.

Perry
Speaking for myself, and not for the IAHC in an official capacity




From hchen at aimnet.net  Fri Mar 21 20:28:51 1997
From: hchen at aimnet.net (Hong Chen)
Date: Fri, 21 Mar 1997 12:28:51 -0800 (PST)
Subject: root-server envy, racketeering, and black helicopters.
In-Reply-To: <v03007801af58883d4887@[207.21.10.112]>
Message-ID: <Pine.SUN.3.95.970321121954.2743A-100000@aimnet.net>

> What the hell is going on here? It's wacky!
> 
> I've really enjoyed reading about subjects that I assumed I would find on
> this list: BGP and flapping, technical discussion of spam management,
> network management tools, and network outages, etc.

Wayne, I do agree with you that the discussion should not be off the 
base too much, however, holding off an domain names of large ISPs
cause the Network Outages, which are the discussions of this group.

What are the technical solutions to bring the domain name back 
immediately, instead of waiting for Monday/Wed/Friday 5:00pm updates.
To us as Network Operators, Internic is considered as our super network
operator (anyone disagree with this?), as they have the power
to shut down any ISP down any minute. We have 24x7 centers, 
shouldn't Internic have the similar one?

2 to 3 days unreachable domain names are serious Network Outages
we NANOG members should look into.

Hong


> 
> As the Interenet grows, so, it seems, do my filtering rules.. I just didn't
> think I'd have to apply filters to a list with a subjectlike this.
> 
> I guess I was wrong? :-)
> 
> _________________________________________________________________________
>  Wayne D. Correia             +1.415.826.6000    900 Tennessee Street
>                           fax +1.415.826.6100    San Francisco, CA 94107
> 
> 
> 





From jdfalk at cyberNOTHING.org  Fri Mar 21 20:30:34 1997
From: jdfalk at cyberNOTHING.org (J.D. Falk)
Date: Fri, 21 Mar 1997 15:30:34 -0500 (EST)
Subject: Fwd: master "spam remove" list?
In-Reply-To: <CMM.0.90.2.858964228.vaf@valinor.barrnet.net>
Message-ID: <Pine.NEB.3.96.970321152921.7448M-100000@unagi.cybernothing.org>

On Fri, 21 Mar 1997, Vince Fuller wrote:

> Has anyone else received this? Is it legit or is it yet another dishonest
> attempt by spammers to improve the quality of their mailing lists? I very
> much suspect the former as I doubt that spammers pay much attention to
> "remove" lists.

	At best, it's some guy who thinks he can come up with a list and
the spammers will follow it.  At worst, it's a shill for Sanford Wallace
trying to retaliate against "the anti-spammers" for getting hacked.
	More details in news.admin.net-abuse.email and .misc, I'm sure.

 ---------========== J.D. Falk <jdfalk at cybernothing.org> =========---------
  | "When I've captured my adversary and he says, 'Look, before you kill |
  |  me, will you at least tell me what this is all about?' I'll say,    |
  |  'No,' and shoot him."               --Peter Anspach                 |
 ----========== http://www.cybernothing.org/jdfalk/home.html ==========----






From michael at memra.com  Fri Mar 21 21:30:56 1997
From: michael at memra.com (Michael Dillon)
Date: Fri, 21 Mar 1997 13:30:56 -0800 (PST)
Subject: Domain Rant
In-Reply-To: <199703211957.LAA03636@quest.pluris.com>
Message-ID: <Pine.BSI.3.93.970321132444.13015N-100000@sidhe.memra.com>

On Fri, 21 Mar 1997, Vadim Antonov wrote:

> I do not think the domain issue is beyond the scope of NANOG.
> In fact, w/o working DNS the value of services provided by N.A.N.Operators
> is zero.  In other words, the domain insanity reached the level where
> it starts to impact the business of ISPs materially.
> 
> In other words, it is in the interest of ISPs to step in and inject some
> sanity into how that vital part of infrastructure is being run.

I agree 100% with this. However, NANOG is not the right forum. First, this
is more than just an operational issue. Thus I would claim that it should
be discussed in a forum like inet-access which does cover business issues,
politics and everything related to the ISP industry. It also has broader
participation by small to mid-size ISP's who are arguably the closest to
the Internet's user base. Send a subscribe message to inet-access at earth.com

Alternatively, I think this issue should be addressed in ISP trade
associations and, in fact, the members of the ISP/C of which I am a
director are currently discussing what action, if any, we might take.
Trade associations are a better place, IMHO, to deal with policy issues.
More info on ISP/C at http://www.ispc.org and, of course, there is also
the CIX and CAIP as well.

> ISPs is the only party in the debate which actually has resources and
> enough business sense to make it a workable setup.  I strongly suspect that
> "expert groups" and "engineering task forces" have already demonstrated
> their unability to fix the problem.

Not quite. Remember that some engineering projects take lots of time and
planning and then take lots of construction time. Engineering is not
synonymous with quick. Consider the BART system, the chunnel, space
station Alpha.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From michael at memra.com  Fri Mar 21 21:36:09 1997
From: michael at memra.com (Michael Dillon)
Date: Fri, 21 Mar 1997 13:36:09 -0800 (PST)
Subject: Domain Rant
In-Reply-To: <19970321142517.22127@Jupiter.Mcs.Net>
Message-ID: <Pine.BSI.3.93.970321133415.13015O-100000@sidhe.memra.com>

On Fri, 21 Mar 1997, Karl Denninger wrote:

> If you pick or support the IAHC model, then you had better be right --
> because the alternative is that the world collapses. 

Bull! If the IAHC doesn't work, you simply build an alternate network of
nameservers and use them instead. Just like eDNS is doing now. Nothing
about the IAHC removes this as a failsafe possibility.

But first we need to try the IAHC because if it does work it will solve a
lot of problems that we are facing.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From rjoffe at genuity.net  Fri Mar 21 21:53:27 1997
From: rjoffe at genuity.net (Rodney Joffe)
Date: Fri, 21 Mar 1997 14:53:27 -0700
Subject: MAE West
Message-ID: <c=US%a=_%p=Genuity%l=X-FILES-970321215327Z-25712@x-files.genuity.net>

Does anyone have any idea if there's something *bad* going on at MAE
West? Half our peers are down....

Rodney Joffe
Chief Plumber
Genuity Inc., a Bechtel company
http://www.genuity.net






From paul at vix.com  Fri Mar 21 22:26:43 1997
From: paul at vix.com (Paul A Vixie)
Date: Fri, 21 Mar 1997 14:26:43 -0800
Subject: omnibus Domain Rant
Message-ID: <199703212226.OAA00021@wisdom.home.vix.com>

Here's your chance.  You've been complaining about this thread.  Hit D now.

> There has already been one Sherman Act related lawsuit filed.  Collude with
> others and RICO gets added to the mix.

You must be referring to http://namespace.autono.net/ns./litigation_cont.html.
I'm not a judge or jury or even a lawyer, but this suit looks pretty weak to
me -- eventually GSA would have to be named as a codefendant and that's not
going to work.  This too, shall pass.

>> Giving me money is no guarantee of polite treatment.  I do the right thing,
>> money or no money.  The funny thing is, people keep giving me money anyway.
>
>A slight correction:  You do what *you think* is the right thing.

The difference only matters if you don't trust your own judgement or you
accept a higher moral authority than yourself.  In the case of DNS I have
subjected my moral judgement to the review of people I respect, and have
honed it according to the feedback.  I'm not aware of a higher authority.

>What's necessary is preventing the elimination of free market selection.

And I suppose that we ought to allow the free market to allocate radio
frequency spectrum as well.  And if you don't like the TV station that is
now broadcasting where the CB radios you've been selling also operate, then
I guess the market just got less free.  And if you don't like the fact that
your phone number has been allocated to other people by several local phone
companies, then I guess one of those phone companies will achieve some kind
of ascendancy and the ones who "mis-"allocated "your" phone numbers will
eventually stop doing that or go out of business.

In this crowd I'm probably the expert on economic theory, weak though I am
on the subject.  And a free market requires some basic rules.  Unique spectrum
allocations backed by the force of law don't constrain the size of the market
or its freedom, in fact it is the only way to prevent monopoly forces from
squeezing out the little guy.  The so-called eDNS allocation scheme is not
workable for at least two reasons: someone else will start pDNS and allocate
from _their_ version of "." if they think they can "compete"; and, the second
level players are not required to cooperate for the greater good of the end
users.

We have a coherent "." right now, and we're going to continue to have one, and
its owners will be subject to the rule of law and to the administration of
representatives of the user population.  Right now that's IETF/IANA.  In the
future it will be IAHC/CORE/etc.  eDNS does not qualify and is a nonstarter.

>Can you point me to a nice summary of the IAHC proposal?  And your plan for
>things if it stalls?

http://www.iahc.org/ has their proposal, as well as background materials like
searchable mailing list archives and some historical documents.

My plan for things if IAHC stalls is to call folks I know at the various
large ISP's and say "if you think ARIN was a good idea, you ain't seen nothin'
yet".  Ultimately the people who own the gold, make the rules.  In civilized
countries, everything happens through a government agency who owns the ISO3166
two-letter country code top level domain, and they ignore all of this three-
letter silliness.  In the US, the government ignores everything we do and we
all seem strangely pleased by this, and we hardly use .US at all, preferring
to pollute the worldwide name space with our petty desires for short names.




From rob at elite.exodus.net  Fri Mar 21 23:43:38 1997
From: rob at elite.exodus.net (Robert Bowman)
Date: Fri, 21 Mar 1997 15:43:38 -0800 (PST)
Subject: MAE West
In-Reply-To: <c=US%a=_%p=Genuity%l=X-FILES-970321215327Z-25712@x-files.genuity.net> from "Rodney Joffe" at Mar 21, 97 02:53:27 pm
Message-ID: <199703212343.PAA09057@elite.exodus.net>

Mae-West is down hard.  Mae-West MFS that is.  AMES is beautiful.

Rob
Exodus Communications Inc.
> 
> Does anyone have any idea if there's something *bad* going on at MAE
> West? Half our peers are down....
> 
> Rodney Joffe
> Chief Plumber
> Genuity Inc., a Bechtel company
> http://www.genuity.net
> 
> 





From joe at vpop.net  Sat Mar 22 02:19:19 1997
From: joe at vpop.net (Joe McDonald)
Date: Fri, 21 Mar 1997 18:19:19 -0800
Subject: Domain Rant. 
In-Reply-To: <199703211734.JAA30435@wisdom.home.vix.com>
References: <199703211734.JAA30435@wisdom.home.vix.com>
Message-ID: <3337402e.274122487@mail.smartlink.net>


Please, Please!  I have five domains that I have already paid for put on
hold (or about to be put on hold in the next few days), I also have a
zillion "Invoice" notices cc'd to us from internic sent to customers that I
*know* have paid.  Since we paid by credit card, I'm sure that we're going
to have to pay them *again* (at least one domain has already been paid
twice, this'll be the 3rd payment we have to make becuase internic can't
find a record that we paid, and our CC bill doesn't have the name of the
domain on it.)

It's just gross incompetence, and at this point I don't have much choice
but to throw the internic more of my money.

-joe

On Fri, 21 Mar 1997 09:34:32 -0800, Paul A Vixie <paul at vix.com> spaketh:

>> I think it is time ISPs take the matter in their hands.  I.e. let ISPs
>> to perform registrations.  Root serer operators can ensure uniqueness
>> just fine.
>
>this is definitely where we are headed if the IAHC proposal stalls.  i'm
>already in contact with some of the larger ISPs about this subject.
>

=============================================================================
           * NewsHub: Updated every 15 minutes/24 hours a day! *
                          http://newshub.com/




From jdp at cyberramp.net  Sat Mar 22 02:35:06 1997
From: jdp at cyberramp.net (Janet Pippin)
Date: Fri, 21 Mar 1997 20:35:06 -0600 (CST)
Subject: Frustrating...
In-Reply-To: <85256461.006E2D82.00@col_lngw.aepsc.com> from "Steven_M._Riley@aep.com" at "Mar 21, 97 03:05:26 pm"
Message-ID: <199703220235.UAA05896@mailhost.cyberramp.net>



Thorns will sometimes prick you...
Welcome to our world... 

/jdp

Steven_M._Riley at aep.com wrote:
> 
> Can we get back to the good stuff, please? I joined this list because it
> seemed like a great place to learn some the thorny technical stuff that
> keeps the Internet going. Now all I get all day are mails from people
> complaining about this and that and the other thing. I've given up reading
> the "Domain rant" thread -- I just delete them all. I miss the technical
> stuff.
> 
> 


-- 
        Janet Pippin           *        CyberRamp Internet Services
   Network Administrator      ***           11350 Hillguard Road
     jdp at cyberramp.net         *         Dallas, Texas  75243-8311
  http://www.cyberramp.net      *      (214) 340-2020  (817) 226-2020




From gherbert at crl.com  Sat Mar 22 02:38:45 1997
From: gherbert at crl.com (George Herbert)
Date: Fri, 21 Mar 1997 18:38:45 -0800
Subject: Frustrating... 
Message-ID: <199703220238.AA18648@mail.crl.com>


>Can we get back to the good stuff, please? I joined this list because it
>seemed like a great place to learn some the thorny technical stuff that
>keeps the Internet going. Now all I get all day are mails from people
>complaining about this and that and the other thing. I've given up reading
>the "Domain rant" thread -- I just delete them all. I miss the technical
>stuff.

Having domains dissapearing because InterNIC can't keep its databases
straight about payments is VERY IMPORTANT.  Think about the consequences
for you as a provider if they can't clean up the situation soon.


-george william herbert
gherbert at crl.com





From jdp at cyberramp.net  Sat Mar 22 03:32:59 1997
From: jdp at cyberramp.net (Janet Pippin)
Date: Fri, 21 Mar 1997 21:32:59 -0600 (CST)
Subject: Frustrating... (fwd)
Message-ID: <199703220332.VAA12585@mailhost.cyberramp.net>



oh and *hint*:  We depend on DNS and dns starts with ".".
		All of the ISP/IAP/NAP's depend on "."
 		if the root servers are maintained by 
         	friviolousity <is this a word??> then we
		are in a very delicate state.  if domains
		that are 5 yrs old start to go "on hold"
		we will loose dns for half the net..
		ie: mine is 4 yrs old, went on hold and
		2 days later i got a removal notice.



Thorns will sometimes prick you...
Welcome to our world... 

/jdp

Steven_M._Riley at aep.com wrote:
> 
> Can we get back to the good stuff, please? I joined this list because it
> seemed like a great place to learn some the thorny technical stuff that
> keeps the Internet going. Now all I get all day are mails from people
> complaining about this and that and the other thing. I've given up reading
> the "Domain rant" thread -- I just delete them all. I miss the technical
> stuff.
> 
> 


-- 
        Janet Pippin           *        CyberRamp Internet Services
   Network Administrator      ***           11350 Hillguard Road
     jdp at cyberramp.net         *         Dallas, Texas  75243-8311
  http://www.cyberramp.net      *      (214) 340-2020  (817) 226-2020

----- End of forwarded message from Janet Pippin -----

-- 
        Janet Pippin           *        CyberRamp Internet Services
   Network Administrator      ***           11350 Hillguard Road
     jdp at cyberramp.net         *         Dallas, Texas  75243-8311
  http://www.cyberramp.net      *      (214) 340-2020  (817) 226-2020




From jdp at cyberramp.net  Sat Mar 22 03:38:32 1997
From: jdp at cyberramp.net (Janet Pippin)
Date: Fri, 21 Mar 1997 21:38:32 -0600 (CST)
Subject: Domain Rant.
In-Reply-To: <199703211659.LAA01996@jekyll.piermont.com> from "Perry E. Metzger" at "Mar 21, 97 11:59:15 am"
Message-ID: <199703220338.VAA13216@mailhost.cyberramp.net>

Perry E. Metzger wrote:
> 
> Karl Denninger writes:
> > Its time to move on to eDNS folks.
> 
> The eDNS is a joke, Karl, and not even a very funny one.

ditto.. a joke, unwarranted and simply rediculous.

karl, some of us are sick of being referred to as:
"hey folks" from one who calims to have the "answer"

blah
/jdp
<my opinion and not the opinion of CR>

> 
> Perry
> Speaking purely for myself and not for the IAHC


-- 
        Janet Pippin           *        CyberRamp Internet Services
   Network Administrator      ***           11350 Hillguard Road
     jdp at cyberramp.net         *         Dallas, Texas  75243-8311
  http://www.cyberramp.net      *      (214) 340-2020  (817) 226-2020




From jfbb at atmnet.net  Sat Mar 22 19:05:09 1997
From: jfbb at atmnet.net (Jim Browning)
Date: Sat, 22 Mar 1997 11:05:09 -0800
Subject: FYI: BBN/MCI Peering Change 3/31/97
Message-ID: <01BC36B0.E8FD7540@jfbb.atmnet.net>

>From:  Dave Curado[SMTP:davec at ziplink.net]
>Sent:  Tuesday, March 18, 1997 2:15 AM
>
>My intention, by the way, is not to simply pick nits over a posting.
>I have heard in the past that there is at least one major provider
>who sells transit through the naps.  Regardless of whether that is
>an OK thing to do or not, I am sincerely interested in knowing if
>that is true.

There are two different flavors of this:

A.	Providing transit over the NAP fabric (ATM or FDDI)
B.	Providing transit via a private interconnect which happens to be at a 
NAP facility.

You should speak to each provider yourself, with an awareness that this 
approach is avoided because of the fact that getting traffic both through 
and _away from_ the exchanges is a serious concern of providers carrying a 
lot of traffic.  This problem is exacerbated if transit connections are 
accepted at the exchange points.

There may a time when "Purchased Peering" becomes the chosen approach for 
what you are seeking...
--
Jim






From kozowski at structured.net  Mon Mar 24 04:44:51 1997
From: kozowski at structured.net (Eric Kozowski)
Date: Sun, 23 Mar 1997 20:44:51 -0800 (PST)
Subject: Domain Rant
Message-ID: <199703240444.UAA06291@teufel.structured.net.>

Has anyone heard from InterNIC about the billing screwups of the last week?

We just got hit by the InterNIC billing SNAFU and I'm wondering what other
people have done to get their situation resolved.


-- 
Eric Kozowski              VP Internet Services
eric at structured.net        Structured Network Systems, Inc.
(800)390-5945 Support      http://www.structured.net/
(800)881-0962 Sales/Info   (503)525-9375 FAX
PGP Key fingerprint =  2E 5F 3E 6D AA 61 AA 14  D8 FB A4 15 CE 2C D8 8C
'They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759




From dcrocker at imc.org  Mon Mar 24 06:29:09 1997
From: dcrocker at imc.org (Dave Crocker)
Date: Sun, 23 Mar 1997 22:29:09 -0800
Subject: Domain Rant
In-Reply-To: <19970321142517.22127@Jupiter.Mcs.Net>
References: <199703211957.LAA03636@quest.pluris.com>; from Vadim Antonov
 on Fri, Mar 21, 1997 at 11:57:43AM -0800
 <199703211957.LAA03636@quest.pluris.com>
Message-ID: <v03102219af5bc2e7ace3@[205.214.160.78]>

At 12:25 PM -0800 3/21/97, Karl Denninger wrote:
>Now let's look at the alternatives to the current mess:

An analysis about which we all rest safe, knowing that it will be careful
and, of course, fully impartial...

>>1)	IAHC - Nice concept, but troublesome in many areas.  Jurisdictional,
>	regulatory, due process, all kinds of problems.  Unknown costs at
>	the CORE level, unknown budgets, single-model.

So of course, let's start off with a maximum FUD attack.  Heck, if THIS
list doesn't sow nice, solid fear, uncertaintly, and doubt, why bother with
facts?

>	The worst problem is that if it sucks we can't "go around" it as

As noted already, this claim is fully silly, not to mention wrong.

>	believe they CAN force NSI to play, or that NSI will voluntarily --

Indeed, NSI remains an interesting question, but since neither of the
'alternatives' cited here claim to force a solution to the question of NSI,
one wonders why it is mentioned, here.

>	Costs? $20,000 to play in the lottery, plus $500,000 in hard assets

And heaven knows, we can't go around expecting fiscal responsibility from
folks who provide such a fundamental service for the Internet.  Why, that
would be unAmerican...

>2)	eDNS - Open.  Consensual.  Multi-business-model based.  Build it

Open.  You mean, you allow monopolies over TLDs.  Multi-business.  Well,
multi-business, as long as Karl gets to be at the top of the heap, in
charge of the root, and we all get to rely on Karl for oversight.  Now
THAT's comforting.

By the way.  As soon as Karl refutes the claim that he's in charge, then
the question of who is responsible for the root emerges.  As soon as he
responds that it's a coalition of the registrars, then we have to wonder
just how different the eDNS management scheme is from the IAHC plan.

The answer, of course, is that the ONLY oversight for the eDNS scheme is
the registrars whereas the IAHC scheme put into place a public structure
with public representatives, separate from those with a direct profit
involvement in the running of the DNS.  Karl objects to such public
oversight.

Why?

What is he afraid of?

The best part are his efforts to claim that such oversight is new and
unusual.  This suggests a failure to understand the rough consensus mode in
which the DNS has always been operated.

>	Operates on the principle that the policy of the root is to prevent
>	market concentration (ie: monopoly) and collisions between TLDs, and

Well, then, the eDNS fails.  It allows monopolies over individual TLDs.
This means that after you get your TLD, and after you invest in its use
with marcom collateral materials, etc., you are entirely captive to the ONE
registrar who controls that TLD.  The eDNS claim that is does not "enforce"
a particular model belies the permission it gives for this scenario.

Rather than demure from responsbility for the problems caused by such
exclusive control, the IAHC model ensures that registrars compete on
service, not exclusivity of control.

With the IAHC model, you can change registrars.  With the eDNS model, you
can't.

>	jurisdiction under which registrants can select from.  Lots of
>	business models to choose from.  Lots of different prices to be

Nothing in the IAHC plan dictates particular 'business' models, Karl's
persistant misrepresentations notwithstanding.  The IAHC plan DOES dictate
a control model over the DNS resource, itself.  And it does dictate that
candidate registrars demonstrate basic fiscal responsibilities, appropriate
to the level of any startup.  But it does NOT say anything at all about
registrar business models.

>Which model SHOULD win?

	The one which offers incremental enhancement to the existing
structure, rather than shifting the whole service over to a brand new
operational authority (an authority comprising folk with a track record no
participation in the larger Internet consensus process and of
non-comformance and personality-driven public behavior, at that.)

	The one which ensures that registrants can change registrars
without having to change domain names.

	The one which ensures public oversight for a public resource.

d/


----------------------------
Dave Crocker, Director                                       +1 408 246 8253
Internet Mail Consortium                                 (f) +1 408 249 6205
127 Segre Place                                             dcrocker at imc.org
Santa Cruz, CA  95060 USA                                 http://www.imc.org

Also: IAHC member, expressing personal opinions          http://www.iahc.org






From michael at memra.com  Mon Mar 24 09:15:04 1997
From: michael at memra.com (Michael Dillon)
Date: Mon, 24 Mar 1997 01:15:04 -0800 (PST)
Subject: Domain names going on hold for non-payment (fwd)
Message-ID: <Pine.BSI.3.93.970324011439.9969R-100000@sidhe.memra.com>


---------- Forwarded message ----------
Date: Mon, 24 Mar 1997 00:31:35 -0500 (EST)
From: Fu Bar <fubar at dino.fdt.net>
Reply-To: inet-access at earth.com
To: inet-access at earth.com
Subject: Domain names going on hold for non-payment
Resent-Date: Sun, 23 Mar 1997 22:31:52 -0700 (MST)
Resent-From: inet-access at earth.com

I just got 4 messages from billing at internic.net with the subject:
Domain names going on hold for non-payment
It should really be read as:
You thought we had our heads up our asses before?  You aint seen nuthin yet.

Of the domains listed, many in the first 2 messages were valid past due
domains waiting to expire.  However, I have confirmation from clients that
at least 2 listed domains are paid up to date, and should not be in the
remove queue.  

The really amazing part is that the second 2 messages list domains I've
never heard of, and which none of my DNS servers are listed with (I did
whois's on a bunch just to see if some luser had registered with my DNS
servers without telling me...wouldn't be the first time).  The last of
these messages lists more than 3 dozen domains I've never heard of and
don't give a damn about.  I just wonder if the true owners have been
notified? 

The odd thing is all of these that I checked are registered to 
organizations in France and England.

------------------------------------------------------------------
 Jon Lewis <jlewis at fdt.net>  |  Unsolicited commercial e-mail will
 Network Administrator       |  be proof-read for $199/hr.
________Finger jlewis at inorganic5.fdt.net for PGP public key_______

============================== ISP Mailing List ==============================
Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
Don't post very large messages, post a pointer to an ftp or web site.





From michael at memra.com  Mon Mar 24 09:16:57 1997
From: michael at memra.com (Michael Dillon)
Date: Mon, 24 Mar 1997 01:16:57 -0800 (PST)
Subject: Domain names going on hold for non-payment (fwd)
Message-ID: <Pine.BSI.3.93.970324011646.9969T-100000@sidhe.memra.com>


---------- Forwarded message ----------
Date: Sun, 23 Mar 1997 23:55:45 -0700 (MST)
From: Jason Marshall <marshalj at spots.ab.ca>
Reply-To: inet-access at earth.com
To: Fu Bar <fubar at dino.fdt.net>
Cc: inet-access at earth.com
Subject: Re: Domain names going on hold for non-payment
Resent-Date: Sun, 23 Mar 1997 23:55:52 -0700 (MST)
Resent-From: inet-access at earth.com

> The really amazing part is that the second 2 messages list domains I've
> never heard of, and which none of my DNS servers are listed with (I did
> whois's on a bunch just to see if some luser had registered with my DNS
> servers without telling me...wouldn't be the first time).  The last of
> these messages lists more than 3 dozen domains I've never heard of and
> don't give a damn about.  I just wonder if the true owners have been
> notified? 

That's pretty bad!  But get this!  I've got 4 or 5 domains registered for
a client of ours whose name is Garry Lee (that's not the funny part).
When they were registered, particular attention was paid to the spelling
of his name since there were already a couple of Garry Lee's, and
thereafter we ensured that we were using the right internic 'handle' to
register him as the admin/billing contact.

At some point, all of these domains were suddenly owned by Gary Lee (note
the spelling) in Montreal.  It was THAT Gary Lee who was receiving all the
"you better pay up" notices, and THAT Gary Lee who responsed the first few
times to say that they had the wrong person, and had better get their
facts straight.  

Then, on their 5-day notice, they send me, the tech contact, a warning,
saying that Gary Lee in Montreal hadn't paid, etc, etc.  After playing
phone tag with the morons at InterNIC for close to a month (at least they
gave us some leeway here), payment was finally arranged by the right Garry
Lee with his Visa.  

NOW, however, *I* am listed as all three contacts for each of Garry's
domains, **AND** they still put the domains on hold.  I just about give up
with these fuckwits.  With the amount they receive in revenue, they can
afford to throw people at the problem.  They don't need to be rocket
scientists, either.  Any neanderthal can answer the phone and read what
they see on the screen, and even update it if they need to.  Don't these
assholes realize that a lot of people are *depending* on these domain
names to make their *living*?

Jesus, I just looked, and now they have only ONE Garry Lee, and he's in
San Jose, CA, not Calgary Alberta...  Oh well, more mess for me to clean
up.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
| Jason Marshall, marshalj at spots.ab.ca. Spots InterConnect, Inc. Calgary, AB |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


============================== ISP Mailing List ==============================
Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
inet-access archives are at ftp://ftp.earth.com/pub/archive/inet-access/





From tbates at cisco.com  Fri Mar 14 20:00:01 1997
From: tbates at cisco.com (Tony Bates)
Date: Fri, 14 Mar 1997 12:00:01 -0800
Subject: The Cidr Report
Message-ID: <199703142000.MAA24382@lovefm.cisco.com>


This is an auto-generated mail on Fri Mar 14 12:00:00 PST 1997
It is not checked before it leaves my workstation.  However, hopefully 
you will find this report interesting and will take the time to look 
through this to see if you can improve the amount of aggregation you 
perform.

The report is split into sections:

   0) General Status
   
      List the route table history for the last week, list any possibly
      bogus routes seen and give some status on ASes.

   1) Gains by aggregating at the origin AS level

      This lists the "Top 30" players who if they decided to aggregate
      their announced classful prefixes at the origin AS level could 
      make a significant difference in the reduction of the current 
      size of the Internet routing table. This calculation does not 
      take into account the inclusion of holes when forming an aggregate
      so it is possible even larger reduction should be possible.

   2) Weekly Delta

      A summary of the last weeks changes in terms of withdrawn and
      added routes. Please note that this is only a snapshot but does 
      give some indication of ASes participating in CIDR. Clearly,
      it is generally a good thing to see a large amont of withdrawls.

   3) Interesting aggregates

      Interesting here means not an aggregate made as a set of 
      classful routes.      

Thanks to xara.net for giving me access to their routing tables once a
day. 

Please send any comments about this report directly to me.

Check http://www.employees.org/~tbates/cidr-report.html for a daily
update of this report.



------------------------------------------------------------------------------

                        CIDR REPORT for 14Mar97


0) General Status

Table History
-------------

Date	Prefixes
070397	44643
080397	45097
090397	44635
100397	44670
110397	44690
120397	44565
130397	44805
140397	44819

Check http://www.employees.org/~tbates/cidr.plot.html for a plot
of the table history.


Possible Bogus Routes
---------------------


AS Summary
----------

Number of ASes in routing system:                 2145

Number of ASes announcing only one prefix:         906 (448 cidr, 458 classful)

Largest number of  cidr routes:                    510 announced by AS3561
Largest number of classful routes:                1530 announced by  AS174



1) Gains by aggregating at the origin AS level

 --- 14Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1530     1071      459   30.0%   Performance Systems International
AS2493       842      519      323   38.4%   i*internet
AS3602       622      336      286   46.0%   Sprint Canada Inc.
AS1221      1368     1113      255   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1120      923      197   17.6%   BBN Planet backbone
AS1691       307      171      136   44.3%   BCTEL
AS2048       243      127      116   47.7%   State of Louisiana/Office of Tele
AS721        480      372      108   22.5%   DLA-ASNBLOCK-AS
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        308      223       85   27.6%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       149       73       76   51.0%   Middle East Technical University 
AS7195       118       46       72   61.0%   INTERRED
AS2704       263      192       71   27.0%   HOOKUP-NET-A
AS855        133       63       70   52.6%   NBTel
AS2386       188      121       67   35.6%   INS-AS
AS701        872      809       63    7.2%   Alternet
AS2711       114       56       58   50.9%   SUNBELT-AS
AS4454        75       21       54   72.0%   OIR Telecommunications, State of 
AS3739       192      138       54   28.1%   NEWNET
AS549        219      166       53   24.2%   ONet Backbone
AS3397        74       22       52   70.3%   EMI-AS
AS97         185      138       47   25.4%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS3561       907      861       46    5.1%   MCI
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3491       135       90       45   33.3%   CAIS-ASN
AS225         75       31       44   58.7%   University of Virginia (VIRnet)

 --- 13Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1532     1073      459   30.0%   Performance Systems International
AS2493       842      519      323   38.4%   i*internet
AS3602       622      336      286   46.0%   Sprint Canada Inc.
AS1221      1349     1096      253   18.8%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1122      924      198   17.6%   BBN Planet backbone
AS1691       307      171      136   44.3%   BCTEL
AS2048       255      127      128   50.2%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS721        464      366       98   21.1%   DLA-ASNBLOCK-AS
AS3819       116       19       97   83.6%   SIGNET
AS813        312      224       88   28.2%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS1967       149       71       78   52.3%   Middle East Technical University 
AS7195       120       44       76   63.3%   INTERRED
AS2704       263      192       71   27.0%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS2386       188      121       67   35.6%   INS-AS
AS701        859      798       61    7.1%   Alternet
AS2711       114       56       58   50.9%   SUNBELT-AS
AS3739       193      139       54   28.0%   NEWNET
AS549        219      166       53   24.2%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS97         187      140       47   25.1%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS4454        59       14       45   76.3%   OIR Telecommunications, State of 
AS4175       475      430       45    9.5%   CONNECT-NCM
AS3491       133       88       45   33.8%   CAIS-ASN
AS3561       910      866       44    4.8%   MCI
AS225         76       32       44   57.9%   University of Virginia (VIRnet)

 --- 12Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1538     1080      458   29.8%   Performance Systems International
AS2493       838      519      319   38.1%   i*internet
AS3602       622      336      286   46.0%   Sprint Canada Inc.
AS1221      1343     1093      250   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1087      905      182   16.7%   BBN Planet backbone
AS1691       307      171      136   44.3%   BCTEL
AS2048       255      123      132   51.8%   State of Louisiana/Office of Tele
AS721        483      372      111   23.0%   DLA-ASNBLOCK-AS
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       116       19       97   83.6%   SIGNET
AS813        310      223       87   28.1%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       172       92       80   46.5%   Internet Services GmbH & Co
AS7195       120       44       76   63.3%   INTERRED
AS2386       196      125       71   36.2%   INS-AS
AS2704       262      192       70   26.7%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS701        862      803       59    6.8%   Alternet
AS1967       117       58       59   50.4%   Middle East Technical University 
AS2711       115       57       58   50.4%   SUNBELT-AS
AS549        219      166       53   24.2%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS97         188      141       47   25.0%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS3739       182      136       46   25.3%   NEWNET
AS4454        60       15       45   75.0%   OIR Telecommunications, State of 
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3491       133       88       45   33.8%   CAIS-ASN
AS3561       908      864       44    4.8%   MCI
AS225         76       32       44   57.9%   University of Virginia (VIRnet)

 --- 11Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1531     1076      455   29.7%   Performance Systems International
AS2493       833      516      317   38.1%   i*internet
AS3602       627      338      289   46.1%   Sprint Canada Inc.
AS1221      1331     1084      247   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1112      926      186   16.7%   BBN Planet backbone
AS2048       259      127      132   51.0%   State of Louisiana/Office of Tele
AS1691       302      170      132   43.7%   BCTEL
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       115       18       97   84.3%   SIGNET
AS813        309      224       85   27.5%   UUNET Canada (ASN-UUNETCA-AS1)
AS2871       171       91       80   46.8%   Internet Services GmbH & Co
AS721        434      358       76   17.5%   DLA-ASNBLOCK-AS
AS7195       119       45       74   62.2%   INTERRED
AS2704       263      192       71   27.0%   HOOKUP-NET-A
AS2386       196      125       71   36.2%   INS-AS
AS855        132       63       69   52.3%   NBTel
AS2711       115       57       58   50.4%   SUNBELT-AS
AS701        846      789       57    6.7%   Alternet
AS549        219      166       53   24.2%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS1967       104       52       52   50.0%   Middle East Technical University 
AS568        113       63       50   44.2%   JIS (Joint Interconnection Servic
AS97         188      141       47   25.0%   JvNCnet
AS4454        64       17       47   73.4%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       185      138       47   25.4%   NEWNET
AS3561       914      868       46    5.0%   MCI
AS4175       475      430       45    9.5%   CONNECT-NCM
AS3491       133       89       44   33.1%   CAIS-ASN

 --- 10Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1521     1076      445   29.3%   Performance Systems International
AS2493       839      520      319   38.0%   i*internet
AS3602       625      339      286   45.8%   Sprint Canada Inc.
AS1         1235      979      256   20.7%   BBN Planet backbone
AS1221      1345     1094      251   18.7%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1691       303      170      133   43.9%   BCTEL
AS2048       257      125      132   51.4%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       115       18       97   84.3%   SIGNET
AS813        300      214       86   28.7%   UUNET Canada (ASN-UUNETCA-AS1)
AS721        438      361       77   17.6%   DLA-ASNBLOCK-AS
AS2871       168       91       77   45.8%   Internet Services GmbH & Co
AS7195       118       44       74   62.7%   INTERRED
AS2386       197      123       74   37.6%   INS-AS
AS2704       262      190       72   27.5%   HOOKUP-NET-A
AS855        133       64       69   51.9%   NBTel
AS701        861      801       60    7.0%   Alternet
AS2711       110       53       57   51.8%   SUNBELT-AS
AS549        215      162       53   24.7%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS568        110       60       50   45.5%   JIS (Joint Interconnection Servic
AS1967        98       49       49   50.0%   Middle East Technical University 
AS97         183      136       47   25.7%   JvNCnet
AS4454        64       17       47   73.4%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       184      137       47   25.5%   NEWNET
AS4175       474      429       45    9.5%   CONNECT-NCM
AS3566        86       42       44   51.2%   JRIVER-LINK
AS3491       134       90       44   32.8%   CAIS-ASN

 --- 09Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1534     1078      456   29.7%   Performance Systems International
AS2493       840      520      320   38.1%   i*internet
AS3602       625      339      286   45.8%   Sprint Canada Inc.
AS1         1269      986      283   22.3%   BBN Planet backbone
AS1221      1358     1104      254   18.7%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1691       302      169      133   44.0%   BCTEL
AS2048       258      126      132   51.2%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       115       18       97   84.3%   SIGNET
AS813        294      213       81   27.6%   UUNET Canada (ASN-UUNETCA-AS1)
AS721        437      360       77   17.6%   DLA-ASNBLOCK-AS
AS2871       168       91       77   45.8%   Internet Services GmbH & Co
AS7195       118       44       74   62.7%   INTERRED
AS2386       197      123       74   37.6%   INS-AS
AS855        133       64       69   51.9%   NBTel
AS2704       261      192       69   26.4%   HOOKUP-NET-A
AS701        839      779       60    7.2%   Alternet
AS4175       545      488       57   10.5%   CONNECT-NCM
AS2711       112       55       57   50.9%   SUNBELT-AS
AS549        221      167       54   24.4%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS1967       104       52       52   50.0%   Middle East Technical University 
AS568        110       60       50   45.5%   JIS (Joint Interconnection Servic
AS4454        63       16       47   74.6%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       186      139       47   25.3%   NEWNET
AS3566        86       42       44   51.2%   JRIVER-LINK
AS3491       133       89       44   33.1%   CAIS-ASN
AS225         76       32       44   57.9%   University of Virginia (VIRnet)

 --- 08Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1592     1106      486   30.5%   Performance Systems International
AS2493       840      520      320   38.1%   i*internet
AS3602       627      338      289   46.1%   Sprint Canada Inc.
AS1         1266      983      283   22.4%   BBN Planet backbone
AS1221      1349     1096      253   18.8%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1691       309      173      136   44.0%   BCTEL
AS2048       260      128      132   50.8%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       115       18       97   84.3%   SIGNET
AS813        316      227       89   28.2%   UUNET Canada (ASN-UUNETCA-AS1)
AS721        442      363       79   17.9%   DLA-ASNBLOCK-AS
AS2871       168       91       77   45.8%   Internet Services GmbH & Co
AS7195       118       44       74   62.7%   INTERRED
AS2386       197      123       74   37.6%   INS-AS
AS2704       264      191       73   27.7%   HOOKUP-NET-A
AS701        936      865       71    7.6%   Alternet
AS855        133       64       69   51.9%   NBTel
AS2711       115       57       58   50.4%   SUNBELT-AS
AS4175       546      489       57   10.4%   CONNECT-NCM
AS549        219      166       53   24.2%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS1967       104       52       52   50.0%   Middle East Technical University 
AS568        111       61       50   45.0%   JIS (Joint Interconnection Servic
AS97         187      140       47   25.1%   JvNCnet
AS4454        63       16       47   74.6%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       186      139       47   25.3%   NEWNET
AS3566        86       42       44   51.2%   JRIVER-LINK
AS3491       133       89       44   33.1%   CAIS-ASN

 --- 07Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1528     1073      455   29.8%   Performance Systems International
AS2493       839      519      320   38.1%   i*internet
AS3602       627      338      289   46.1%   Sprint Canada Inc.
AS1         1273      984      289   22.7%   BBN Planet backbone
AS1221      1343     1091      252   18.8%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1691       304      171      133   43.8%   BCTEL
AS2048       257      125      132   51.4%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       115       18       97   84.3%   SIGNET
AS813        316      229       87   27.5%   UUNET Canada (ASN-UUNETCA-AS1)
AS721        433      355       78   18.0%   DLA-ASNBLOCK-AS
AS2871       166       90       76   45.8%   Internet Services GmbH & Co
AS2386       197      123       74   37.6%   INS-AS
AS2704       263      190       73   27.8%   HOOKUP-NET-A
AS855        131       62       69   52.7%   NBTel
AS701        854      791       63    7.4%   Alternet
AS2711       114       56       58   50.9%   SUNBELT-AS
AS4175       546      489       57   10.4%   CONNECT-NCM
AS549        220      166       54   24.5%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS1967       104       52       52   50.0%   Middle East Technical University 
AS568        108       58       50   46.3%   JIS (Joint Interconnection Servic
AS97         187      140       47   25.1%   JvNCnet
AS3799        72       25       47   65.3%   IDS
AS4454        63       17       46   73.0%   OIR Telecommunications, State of 
AS3566        87       43       44   50.6%   JRIVER-LINK
AS3491       136       92       44   32.4%   CAIS-ASN
AS225         76       32       44   57.9%   University of Virginia (VIRnet)
AS7195        76       34       42   55.3%   INTERRED




2) Weekly Delta

This a daily snapshot of changes in classful routes being withdrawn and added.
the deltas are calculated over a rolling 7 day period. Please bear in mind this
is purely a "snapshot" and a large flucuation could be caused by a connectivity
problem for example. However, this does give some indication of service
providers that are moving to classless routing.


Top 20 Withdrawn Classful Routes from 07Mar97 to 14Mar97
	-153    AS1 BBN Planet backbone
	 -72 AS4175 CONNECT-NCM
	 -47 AS3566 JRIVER-LINK
	 -43  AS685 NorthWestNet Primary AS
	 -32 AS3308 TeliaNet Denmark
	 -31  AS568 JIS (Joint Interconnection Servic
	 -28 AS5650 Electric Lightwave Inc. and XMiss
	 -19 AS2819 EUnet Czechia AS
	 -18 AS3336 Internet Services, Kolumbus proje
	 -15 AS3255 Ukrainian Academic and Research N
	 -14 AS1273 ECRC Network
	 -13 AS1794 SprintLink Pennsauken NJ
	 -12 AS5769 Le Groupe Videotron Ltee
	 -10 AS3632 INFOTEC-RTN
	  -9 AS2386 INS-AS
	  -8 AS5006 Minnesota Internet eXchange
	  -7 AS1325 ANS Cleveland - DNSS 43
	  -6 AS6727 Easynet France
	  -5 AS1670 ANS-BLK AS
	  -4 AS4004 Global IP

Top 20 Added Classful Routes from 07Mar97 to 14Mar97
	  50 AS4786 APNIC-AS-BLOCK
	  49 AS3320 Deutsche Telekom AG
	  47 AS3739 NEWNET
	  45 AS1967 Middle East Technical University 
	  42 AS7195 INTERRED
	  33 AS3561 MCI
	  25 AS1221 AARNET-AS
	  19 AS8013 PSINET-CA
	  18  AS701 Alternet
	  15 AS4628 Pacific Internet ASN
	  12 AS6367 NWLINK
	  11 AS1327 ANS Washington D.C. - DNSS 59
	  10 AS3149 SOSI-AS
	   9  AS611 University of New Brunswick
	   8 AS2563 KoRea Education Network
	   7 AS6772 SUPERNOVA AS
	   6  AS210 Utah Education Network
	   5 AS3912 CHECS-net (NMSU.EDU)
	   4  AS196 Rockwell International Science Ce
	   3 AS3749 Tennessee Board of Regents

This a daily snapshot of changes in classles routes being withdrawn and added.


Top 20 Withdrawn Classles Routes from 07Mar97 to 14Mar97
	 -23 AS2819 EUnet Czechia AS
	 -20 AS4175 CONNECT-NCM
	 -15 AS3561 MCI
	  -9 AS6727 Easynet France
	  -8  AS685 NorthWestNet Primary AS
	  -7 AS1328 ANS Houston - DNSS 67
	  -6 AS1670 ANS-BLK AS
	  -5 AS1332 ANS Denver - DNSS 99
	  -4 AS1333 ANS Atlanta - DNSS 107
	  -3 AS2056 AOL-AS
	  -2 AS2563 KoRea Education Network
	  -1 AS5553 CBERNET

Top 20 Added Classles Routes from 07Mar97 to 14Mar97
	  13 AS4786 Ballarat NetConnect Pty Ltd
	  11 AS4628 Pacific Internet ASN
	  10 AS1967 Middle East Technical University 
	   6 AS1916 RNP-AS
	   5 AS2764 connect.com.au pty ltd
	   4  AS816 UUNETCA-AS4
	   3 AS3566 JRIVER-LINK
	   2 AS4805 Global IP
	   1 AS6793 Telivo Ltd



3) Interesting aggregates



            List of possibly interesting aggregates
            ---------------------------------------

         Aggregate | Origin | AS Description          | Netname                
-------------------------------------------------------------------------------
     154.11.1.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.2.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.8.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.9.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.10.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.11.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.12.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.13.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.16.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.17.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.18.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.19.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.24.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.99.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.100.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.101.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.102.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.103.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.104.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.105.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.108.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.109.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.110.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.111.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.112.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.113.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.114.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.120.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.121.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.122.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.123.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.124.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.126.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.127.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.129.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.130.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.136.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.25.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.26.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.27.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.28.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.32.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.33.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.34.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.35.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.36.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.37.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.48.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.50.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.52.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.64.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.65.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.66.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.67.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.96.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.97.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.98.0/24 | AS8013 | PSINET-CA               | *                      
     24.130.0.0/18 | AS7757 | CCI-AS2-BLK             | @Home Network (NETBLK-A
   24.131.128.0/18 | AS7756 | CCI-AS2-BLK             | @Home Network (NETBLK-A
  142.205.232.0/23 | AS7734 | AS For TDBANK           | Canadian Research Netwo
  142.205.240.0/23 | AS7734 | AS For TDBANK           | Canadian Research Netwo
  142.205.248.0/23 | AS7734 | AS For TDBANK           | *                      
   129.231.48.0/21 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.56.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.59.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.67.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
  146.115.132.0/23 | AS7174 | Onward Technologies, In | UltraNet Communications
     24.129.0.0/18 | AS7017 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.131.0.0/18 | AS7016 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.128.0.0/18 | AS7015 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.113.0.0/19 | AS6997 | Rogers Network Services | @Home Network (NETBLK-A
  192.254.27.16/29 | AS6989 | GTSI                    | GTSI (NET-GTSI27)      
   152.158.84.0/24 | AS6755 | ASN - TURNET            | Advantis (NET-ADVANTIS-
   160.81.156.0/24 | AS6718 | Global One Italy        | Sprint International (N
194.235.164.232/30 | AS6718 | Global One Italy        | European Regional Inter
      24.96.0.0/18 | AS6541 | GTE Intelligent Network | @Home Network (NETBLK-A
   163.247.83.0/27 | AS6471 | ENTELCHILE              | Oficina de Estudios y P
     24.112.0.0/19 | AS6463 | Rogers Network Services | @Home Network (NETBLK-A
  168.234.128.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  168.234.135.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  206.152.59.32/28 | AS6362 | VAULTLINE-AS            | Globetrotter Software (
      24.64.0.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
     24.64.32.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
   149.236.92.0/24 | AS6292 | FCI                     | Bruker Analytische Mess
       12.1.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.5.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.8.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.9.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
      12.0.64.0/18 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
    134.129.0.0/18 | AS6263 | NDIN                    | North Dakota State Univ
   134.129.64.0/18 | AS6263 | NDIN                    | North Dakota State Univ
  134.129.128.0/17 | AS6263 | NDIN                    | North Dakota State Univ
   146.115.96.0/22 | AS6249 | UltraNet RI             | UltraNet Communications
  170.147.200.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.208.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.216.0/22 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.220.0/24 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
       24.0.0.0/14 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.0.0.0/18 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.1.0.0/17 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
   169.130.52.0/24 | AS6153 | ASN-SPRN-NYSERNET       | Sprint, Business Servic
  165.113.197.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.198.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.199.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.211.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
   161.223.90.0/23 | AS6077 | Network Intensive - A D | Indian Health Service (
   148.94.210.0/24 | AS5714 | EDS-WEBS                | EDS Network Naming & Ad
   165.247.33.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.36.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.47.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.77.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.88.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.101.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.235.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.236.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.237.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.241.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.244.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.247.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.248.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.249.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  157.232.100.0/24 | AS5696 | Primary AS for GoodNet  | *                      
  165.247.250.0/24 | AS5696 | Primary AS for GoodNet  | *                      
   169.149.70.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
   169.149.98.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
   169.149.99.0/24 | AS5638 | BBN Planet, Central Reg | Montgomery Ward (NET-MW
    148.160.6.0/24 | AS5556 | Telenordia AB           | Boras Energi (NET-BS-EN
    153.96.10.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
    153.96.11.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
    153.96.56.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
    153.96.96.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
    153.97.64.0/18 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.101.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.104.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.110.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.120.0/23 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.132.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.149.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.150.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.176.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.188.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.192.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.232.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.236.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.243.0/24 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   153.96.244.0/22 | AS5501 | Fraunhofer Gesellschaft | Fraunhofer Institut fue
   194.215.65.4/30 | AS5488 | Skynet                  | European Regional Inter
  194.151.154.1/32 | AS5484 | BT Netherlands Regional | European Regional Inter
    131.114.0.0/17 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
  131.114.128.0/18 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
   194.72.24.89/32 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.25.246/32 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.26.172/30 | AS5400 | BT INCS network.        | European Regional Inter
  194.72.26.204/30 | AS5400 | BT INCS network.        | European Regional Inter
      57.12.0.0/16 | AS5384 | Etisalat Emirates Inter | SITA-Societe Internatio
  165.215.191.0/24 | AS5090 | CWI-NYD                 | Bell & Howell Company (
      12.64.0.0/12 | AS5074 | ATT-WN-DP               | AT&T ITS (NET-ATT)     
  166.102.163.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.164.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.165.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
   163.44.224.0/23 | AS4853 | Justsystem Corporation  | Justsystem Corporation 
  164.100.199.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce
   164.100.80.0/24 | AS4755 | Videsh Sanchar Nigam Lt | *                      
     158.40.3.0/24 | AS4740 | OzEmail ISP             | *                      
     158.40.4.0/24 | AS4740 | OzEmail ISP             | *                      
   202.69.3.192/26 | AS4639 | Planet Internet Limited | Asia Pacific Network In
   146.222.11.0/24 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
  146.222.198.0/23 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
     168.29.0.0/17 | AS4565 | HLC Networks            | State of Georgia/Board 
     168.29.0.0/17 | AS4565 | HLC Networks            | State of Georgia/Board 
  152.129.186.0/24 | AS4478 | PNET-STL                | *                      
     159.24.7.0/24 | AS4286 | IMCI                    | MCI Telecommunications 
   165.90.134.0/23 | AS4263 | CERFnet / UC Santa Barb | Pagesat Inc. (NET-PAGES
   165.90.149.0/24 | AS4263 | CERFnet / UC Santa Barb | Pagesat Inc. (NET-PAGES
   165.90.224.0/21 | AS4263 | CERFnet / UC Santa Barb | Pagesat Inc. (NET-PAGES
   165.90.232.0/24 | AS4263 | CERFnet / UC Santa Barb | Pagesat Inc. (NET-PAGES
   128.193.32.0/19 | AS4201 | Oregon State University | *                      
   128.193.64.0/19 | AS4201 | Oregon State University | *                      
   128.193.96.0/19 | AS4201 | Oregon State University | *                      
  128.193.128.0/19 | AS4201 | Oregon State University | *                      
  128.193.160.0/19 | AS4201 | Oregon State University | *                      
  128.193.192.0/19 | AS4201 | Oregon State University | *                      
  128.193.224.0/19 | AS4201 | Oregon State University | *                      
   206.250.40.0/25 | AS4200 | AGIS (Apex Global Infor | Overland Network (NET-O
   166.102.95.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.97.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.99.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.101.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.102.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.105.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.108.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.109.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.110.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.113.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.114.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.116.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.117.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.120.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.122.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.123.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   206.250.27.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  205.199.213.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.203.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.204.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  150.207.128.0/24 | AS4175 | CONNECT-NCM             | *                      
    163.124.7.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
  163.124.221.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
    156.5.252.0/23 | AS4004 | Global IP               | Unilever (NET-UNILEVER2
   169.130.33.0/24 | AS3972 | AS-SPRINTLINK-NYSERN1   | Sprint, Business Servic
   169.130.34.0/24 | AS3972 | AS-SPRINTLINK-NYSERN1   | Sprint, Business Servic
    147.85.21.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.25.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.39.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.44.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.51.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.54.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.98.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
   147.85.115.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
  162.126.135.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.136.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.137.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.138.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
    161.200.0.0/17 | AS3839 | CHULANET                | Chulalongkorn Universit
  161.200.144.0/20 | AS3839 | CHULANET                | Chulalongkorn Universit
  161.200.160.0/19 | AS3839 | CHULANET                | Chulalongkorn Universit
  149.112.251.0/24 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.252.0/23 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.254.0/24 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
   163.249.43.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.53.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.54.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.57.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.140.0/22 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.160.0/21 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.168.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.169.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.170.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   148.207.38.0/24 | AS3632 | INFOTEC-RTN             | Consejo Nacional de Cie
     163.12.0.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.5.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.6.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.8.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.96.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.128.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.136.0/22 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.144.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.160.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.192.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.240.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.16.0/22 | AS3576 | PREPnet-EAST            | *                      
    163.12.21.0/24 | AS3576 | PREPnet-EAST            | *                      
    163.12.22.0/23 | AS3576 | PREPnet-EAST            | *                      
    163.12.22.0/24 | AS3576 | PREPnet-EAST            | *                      
    163.12.23.0/24 | AS3576 | PREPnet-EAST            | *                      
    163.12.24.0/21 | AS3576 | PREPnet-EAST            | *                      
    163.12.32.0/19 | AS3576 | PREPnet-EAST            | *                      
    163.12.64.0/18 | AS3576 | PREPnet-EAST            | *                      
    163.12.64.0/20 | AS3576 | PREPnet-EAST            | *                      
    163.12.81.0/24 | AS3576 | PREPnet-EAST            | *                      
    163.12.82.0/23 | AS3576 | PREPnet-EAST            | *                      
    163.12.84.0/22 | AS3576 | PREPnet-EAST            | *                      
    163.12.88.0/21 | AS3576 | PREPnet-EAST            | *                      
  157.126.209.0/24 | AS3563 | Pilot Network Services, | *                      
  157.126.212.0/24 | AS3563 | Pilot Network Services, | *                      
      161.6.0.0/17 | AS3561 | MCI                     | Western Kentucky Univer
    161.6.128.0/17 | AS3561 | MCI                     | Western Kentucky Univer
   148.212.48.0/20 | AS3561 | MCI                     | Universidad Autonoma de
   148.212.64.0/18 | AS3561 | MCI                     | Universidad Autonoma de
  148.212.128.0/17 | AS3561 | MCI                     | Universidad Autonoma de
  165.237.108.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
  165.237.220.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
    164.103.3.0/24 | AS3561 | MCI                     | Telecommunications Depa
   163.49.131.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.132.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.136.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.140.0/23 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.142.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
     168.14.1.0/24 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.2.0/23 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.4.0/22 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.8.0/21 | AS3561 | MCI                     | State of Georgia/Board 
    168.14.16.0/20 | AS3561 | MCI                     | State of Georgia/Board 
   134.204.14.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  134.204.176.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  155.203.254.0/24 | AS3561 | MCI                     | Safety-Kleen Corporatio
  132.235.204.0/24 | AS3561 | MCI                     | Ohio University (NET-OH
   147.206.20.0/24 | AS3561 | MCI                     | Ochsner Foundation (NET
    161.120.6.0/24 | AS3561 | MCI                     | Norton Company (NET-SGC
   161.181.37.0/24 | AS3561 | MCI                     | Nordstrom, Inc. (NET-NO
   164.100.96.0/19 | AS3561 | MCI                     | National Informatics Ce
  164.100.167.0/24 | AS3561 | MCI                     | National Informatics Ce
    159.179.0.0/24 | AS3561 | MCI                     | MIGROSBANK (NET-MIGROSB
    166.38.40.0/24 | AS3561 | MCI                     | MCI Telecommunications 
  165.166.123.0/24 | AS3561 | MCI                     | Info Avenue Internet Se
  165.108.130.0/23 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.132.0/22 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.136.0/21 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.144.0/22 | AS3561 | MCI                     | ITOCHU Corporation (NET
  165.108.148.0/23 | AS3561 | MCI                     | ITOCHU Corporation (NET
   147.116.63.0/24 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
   147.116.64.0/23 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.160.0/21 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.168.0/22 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  167.208.125.0/24 | AS3561 | MCI                     | Harcourt Brace & Co. (N
    166.147.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.150.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.151.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.147.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.150.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.151.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.147.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.147.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  137.170.136.0/24 | AS3561 | MCI                     | Freudenberg-NOK (NET-FN
    136.140.9.0/24 | AS3561 | MCI                     | Ford Motor Company (NET
    169.200.1.0/24 | AS3561 | MCI                     | First Union National Ba
    169.200.9.0/24 | AS3561 | MCI                     | First Union National Ba
   168.175.70.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.170.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.171.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.172.0/24 | AS3561 | MCI                     | First Union National Ba
    167.77.32.0/24 | AS3561 | MCI                     | Dequesne Light Company 
  147.160.224.0/19 | AS3561 | MCI                     | Concurrent Technologies
  167.105.232.0/24 | AS3561 | MCI                     | Coca-Cola Enterprises (
  159.140.213.0/24 | AS3561 | MCI                     | Cerner Corporation (NET
  159.140.254.0/24 | AS3561 | MCI                     | Cerner Corporation (NET
    168.97.37.0/24 | AS3561 | MCI                     | Carlson Companies (NET-
  138.108.100.0/24 | AS3561 | MCI                     | A.C. Nielsen Company (N
      24.88.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
     24.124.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
     135.37.2.0/24 | AS3561 | MCI                     | *                      
     135.37.4.0/24 | AS3561 | MCI                     | *                      
    135.37.10.0/24 | AS3561 | MCI                     | *                      
    135.40.66.0/24 | AS3561 | MCI                     | *                      
    147.160.0.0/17 | AS3561 | MCI                     | *                      
   164.100.64.0/20 | AS3561 | MCI                     | *                      
   164.100.81.0/24 | AS3561 | MCI                     | *                      
   164.100.82.0/23 | AS3561 | MCI                     | *                      
   164.100.84.0/22 | AS3561 | MCI                     | *                      
   164.100.88.0/21 | AS3561 | MCI                     | *                      
  147.160.128.0/18 | AS3561 | MCI                     | *                      
  147.160.192.0/20 | AS3561 | MCI                     | *                      
  147.160.200.0/21 | AS3561 | MCI                     | *                      
  147.160.208.0/20 | AS3561 | MCI                     | *                      
  147.160.224.0/20 | AS3561 | MCI                     | *                      
  158.106.253.0/24 | AS3561 | MCI                     | *                      
   163.180.96.0/19 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
  163.180.128.0/17 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
    143.192.1.0/24 | AS3549 | Primenet Services for t | *                      
     168.29.0.0/17 | AS3492 | ATLANTA                 | State of Georgia/Board 
  207.226.209.0/26 | AS3491 | CAIS-ASN                | CAIS Internet (NETBLK-C
  169.137.170.0/24 | AS3407 | Interpath               | Cox Enterprises/AJC (NE
  143.222.116.0/24 | AS3407 | Interpath               | *                      
  149.172.150.0/24 | AS3402 | TerraNet, Inc.          | Ikos Systems Incorporat
  164.167.103.0/24 | AS3392 | Infinet Norfolk - MAE-E | Bureau of Medicine and 
   163.49.143.0/24 | AS3384 | New York Net            | TDK Corporation (NET-TD
   163.49.144.0/22 | AS3384 | New York Net            | TDK Corporation (NET-TD
    167.170.6.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
   167.170.32.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
 194.237.174.32/27 | AS3308 | TeliaNet Denmark        | European Regional Inter
 194.183.203.44/30 | AS3305 | Internet Service Provid | European Regional Inter
    164.9.190.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.192.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.194.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.196.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
   164.10.140.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
  164.10.27.128/26 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
   146.75.251.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   146.75.254.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   171.25.128.0/19 | AS3301 | TeliaNet Sweden         | European Regional Inter
   156.51.150.0/24 | AS3301 | TeliaNet Sweden         | *                      
   156.51.204.0/24 | AS3301 | TeliaNet Sweden         | *                      
     137.39.2.4/32 | AS3300 | AT&T-Unisource Communic | UUNET Technologies, Inc
    149.212.0.0/18 | AS3292 | Tele Danmark Internet E | Siemens-Nixdorf Informa
193.162.145.128/30 | AS3292 | Tele Danmark Internet E | European Regional Inter
  194.142.136.8/30 | AS3238 | ALCOM                   | European Regional Inter
     171.18.1.0/24 | AS3215 | RAIN                    | European Regional Inter
    135.14.65.0/24 | AS3111 | Internet Direct Inc. (A | Lucent Technologies (NE
   139.61.102.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
   139.61.103.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
  165.212.158.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
  165.212.230.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
   160.92.129.0/24 | AS2917 | OLEANE - UUNET PIPEX In | Axime S.A. (NET-SEGIN) 
     133.34.9.0/24 | AS2907 | SINET                   | Yokohama National Unive
   146.193.60.0/22 | AS2860 | IP Global, Informatica  | INESC (NET-INESC)      
   145.17.100.0/24 | AS2856 | BTnet UK Regional netwo | Unilever Research Labor
   145.246.16.0/24 | AS2856 | BTnet UK Regional netwo | No match for "145.246.0
   145.246.17.0/24 | AS2856 | BTnet UK Regional netwo | No match for "145.246.0
   194.61.54.32/27 | AS2856 | BTnet UK Regional netwo | European Regional Inter
   171.30.170.0/24 | AS2856 | BTnet UK Regional netwo | BR Telecommunications L
   143.252.80.0/24 | AS2856 | BTnet UK Regional netwo | *                      
  158.174.254.0/24 | AS2856 | BTnet UK Regional netwo | *                      
    159.142.0.0/18 | AS2714 | General Services Admini | General Services Admini
   159.142.64.0/18 | AS2714 | General Services Admini | General Services Admini
  159.142.128.0/18 | AS2714 | General Services Admini | General Services Admini
  159.142.192.0/18 | AS2714 | General Services Admini | General Services Admini
  144.127.112.0/20 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.128.0/19 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.160.0/21 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.168.0/23 | AS2707 | WEC                     | Elkem A/S (NET-ELKEM-NO
  144.127.110.0/23 | AS2707 | WEC                     | *                      
  145.248.112.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.155.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.157.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.159.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.161.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.165.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
    164.53.55.0/24 | AS2706 | HKSUPER                 | National Australia Bank
    134.6.160.0/22 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
    134.6.180.0/24 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
       9.20.0.0/17 | AS2686 | Autonomous System numbe | IBM Corporation (NET-IB
   155.39.191.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
   155.39.230.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
    140.212.2.0/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
  140.212.2.128/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
      32.96.0.0/16 | AS2685 | IBM Global Network - US | Norsk Informasjonstekno
  192.129.3.128/25 | AS2614 | Romanian Educational Ne | German National Researc
  131.114.192.0/18 | AS2598 | Consiglio Nazionale del | CNR - Istituto CNUCE (N
    137.98.96.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.97.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.98.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.99.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.100.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.101.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.102.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.196.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.200.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.203.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.204.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.208.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.209.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.223.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.224.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.225.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.235.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.239.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.240.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
  142.218.120.0/24 | AS2551 | NETCOM On-line Communic | *                      
  141.227.111.0/24 | AS2529 | Demon Internet Ltd      | Societe Nationale Elf A
  159.197.158.0/23 | AS2529 | Demon Internet Ltd      | Civil Aviation Authorit
  156.114.200.0/24 | AS2529 | Demon Internet Ltd      | *                      
    129.237.0.0/18 | AS2495 | KANREN                  | University of Kansas (N
  155.194.200.0/24 | AS2493 | i*internet              | City of Kitchener (NET-
    137.15.34.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.35.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.39.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.41.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.43.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.44.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.52.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.54.0/24 | AS2493 | i*internet              | Central Mapping Agency 
  163.155.120.0/24 | AS2493 | i*internet              | Canada Mortgage and Hou
  161.173.243.0/24 | AS2386 | INS-AS                  | Wal-Mart Stores, Inc. (
  145.247.128.0/18 | AS2120 | DAXnet (Tele 3)         | No match for "145.247.0
   153.110.50.0/24 | AS2120 | DAXnet (Tele 3)         | Fellesdata AS (NET-FELL
    148.122.1.0/24 | AS2119 | Telenor Internett, Norw | Telenor AS (NET-NORTELE
    146.192.0.0/17 | AS2119 | Telenor Internett, Norw | Allianse Informasionssy
  146.192.128.0/17 | AS2116 | EUnet Norway            | Allianse Informasionssy
   198.81.22.32/28 | AS2056 | AOL-AS                  | Advanced Network and Se
   198.81.22.48/28 | AS2056 | AOL-AS                  | Advanced Network and Se
   157.151.64.0/19 | AS2041 | CRL-GATE                | *                      
   169.24.186.0/24 | AS2019 | JP MORGAN               | J.P. Morgan & Co. (NETB
    198.11.42.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
    198.11.51.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
   164.52.249.0/24 | AS1982 | Northwest Nexus, Inc.   | Associated Grocers, Inc
    157.25.64.0/23 | AS1887 | NASK                    | *                      
   161.51.224.0/20 | AS1849 | PIPEX, Public IP EXchan | The M.W. Kellogg Compan
  148.176.225.0/24 | AS1849 | PIPEX, Public IP EXchan | ScottishPower (NET-SCOT
  155.140.124.0/24 | AS1849 | PIPEX, Public IP EXchan | Paribas, Ltd. (NET-CMD1
   148.185.45.0/24 | AS1849 | PIPEX, Public IP EXchan | Mercury Communications 
   159.245.84.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
  159.245.104.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
   170.194.51.0/24 | AS1849 | PIPEX, Public IP EXchan | Deloitte Touche Tohmats
  150.185.128.0/18 | AS1800 | ICM-Atlantic            | *                      
  150.185.192.0/18 | AS1800 | ICM-Atlantic            | *                      
   169.130.31.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   169.130.54.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   149.212.64.0/20 | AS1759 | Telecom Finland iNET    | Siemens-Nixdorf Informa
        9.2.0.0/16 | AS1747 | IBM Watson, Yorktown He | IBM Corporation (NET-IB
      24.48.0.0/18 | AS1677 | ANS  Hartford - CNSS 53 | @Home Network (NETBLK-A
   204.148.62.0/26 | AS1673 | ANS-BB                  | ANS CO+RE Systems, Inc.
 204.151.108.16/29 | AS1670 | ANS-BLK AS              | ANS CO+RE Systems, Inc.
 204.151.108.24/29 | AS1670 | ANS-BLK AS              | ANS CO+RE Systems, Inc.
  194.51.28.152/30 | AS1667 | ANS-DC2                 | European Regional Inter
    152.164.0.0/21 | AS1667 | ANS-DC2                 | ANS CO+RE Systems, Inc.
  152.182.192.0/18 | AS1667 | ANS-DC2                 | ANS CO+RE Systems, Inc.
  152.190.192.0/18 | AS1667 | ANS-DC2                 | ANS CO+RE Systems, Inc.
  157.184.150.0/24 | AS1330 | ANS St. Louis - DNSS 83 | *                      
  149.112.246.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.247.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.248.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.249.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
     24.48.33.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.34.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.36.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.40.0/21 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.48.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.52.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.54.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.62.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
    148.212.1.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.2.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.3.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.4.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.5.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.6.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.7.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.8.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.9.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.10.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.11.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.12.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.13.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.14.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.15.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.16.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.32.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
  160.104.128.0/17 | AS1290 | PSINet UK Ltd.          | Tadpole Technology, Inc
 192.151.12.171/32 | AS1290 | PSINet UK Ltd.          | Hewlett Packard (NET-HP
  130.168.105.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.115.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.125.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
   146.75.253.0/24 | AS1257 | SWIPnet Swedish IP Netw | Nexus AB (NET-COMBITECH
  144.199.161.0/24 | AS1238 | ICM Malaysia (MIMOS) co | Sarawak Shell Berhad (N
    163.180.0.0/18 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
   163.180.64.0/19 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
     159.99.0.0/17 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
   159.99.128.0/19 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
   159.99.160.0/21 | AS1221 | AARNET-AS               | Honeywell Ltd Australia
     24.192.0.0/18 | AS1221 | AARNET-AS               | @Home Network (NETBLK-A
    150.207.2.0/24 | AS1221 | AARNET-AS               | *                      
   158.155.24.0/22 | AS1221 | AARNET-AS               | *                      
  139.162.128.0/17 | AS1136 | Unisource Internet Serv | Nedlloyd Computer Servi
    145.100.0.0/18 | AS1103 | SURFnet                 | SURFnet BV (NET-SURFNET
     24.108.0.0/18 |  AS852 | AGT Advance Communicati | @Home Network (NETBLK-A
    24.112.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    24.113.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    150.241.0.0/20 |  AS766 | RedIRIS Autonomous Syst | *                      
  146.188.244.0/24 |  AS702 | Alternet                | UUNET PIPEX (NET-UUNET-
  146.188.245.0/24 |  AS702 | Alternet                | UUNET PIPEX (NET-UUNET-
    149.20.64.0/24 |  AS701 | Alternet                | Vixie Enterprises (NET-
     168.86.1.0/24 |  AS701 | Alternet                | United Artists Theater 
    160.104.0.0/17 |  AS701 | Alternet                | Tadpole Technology, Inc
     134.6.77.0/24 |  AS701 | Alternet                | Maxtor Corporation (NET
  167.152.251.0/24 |  AS701 | Alternet                | EMI Communications Corp
   134.33.100.0/24 |  AS701 | Alternet                | Codex Corporation (NET-
   164.218.95.0/24 |  AS701 | Alternet                | Bureau of Naval Personn
   155.134.60.0/24 |  AS701 | Alternet                | Best Foods Baking Group
      155.7.0.0/19 |  AS701 | Alternet                | American Forces Informa
     155.7.32.0/21 |  AS701 | Alternet                | American Forces Informa
     155.7.40.0/24 |  AS701 | Alternet                | American Forces Informa
     155.7.41.0/24 |  AS701 | Alternet                | American Forces Informa
     155.7.42.0/23 |  AS701 | Alternet                | American Forces Informa
     155.7.44.0/22 |  AS701 | Alternet                | American Forces Informa
     155.7.48.0/20 |  AS701 | Alternet                | American Forces Informa
     155.7.64.0/18 |  AS701 | Alternet                | American Forces Informa
    155.7.128.0/17 |  AS701 | Alternet                | American Forces Informa
    165.125.0.0/17 |  AS701 | Alternet                | Alexander & Alexander I
   158.118.51.0/24 |  AS701 | Alternet                | *                      
    130.188.2.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.3.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.9.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.150.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.250.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.252.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    131.117.0.0/17 |  AS559 | SWITCH, Swiss Academic  | Municipality of Zuerich
      53.64.4.0/22 |  AS517 | Xlink                   | cap debis ccs (NET-DB-N
    153.96.80.0/21 |  AS517 | Xlink                   | Fraunhofer Institut fue
    153.96.92.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
   153.96.230.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
 194.59.152.128/27 |  AS517 | Xlink                   | European Regional Inter
    143.93.32.0/19 |  AS517 | Xlink                   | *                      
  129.181.208.0/21 |  AS517 | Xlink                   | *                      
  129.181.216.0/22 |  AS517 | Xlink                   | *                      
     132.83.5.0/24 |  AS306 | NGNET-AS                | National Guard Bureau (
     132.88.5.0/24 |  AS306 | NGNET-AS                | National Guard Bureau (
    132.102.5.0/24 |  AS306 | NGNET-AS                | National Guard Bureau (
    132.105.2.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.105.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.115.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.118.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.119.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
  132.118.200.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
  198.200.138.0/28 |  AS174 | Performance Systems Int | Quadritek Systems, Inc.
  128.145.228.0/24 |  AS174 | Performance Systems Int | Performance Systems Int
  199.99.247.32/27 |  AS174 | Performance Systems Int | Performance Systems Int
   136.161.17.0/24 |  AS174 | Performance Systems Int | PSI Network One (NET-PS
   162.17.253.0/24 |  AS174 | Performance Systems Int | Compass Design Automati
   129.35.208.0/24 |  AS163 | IBM-RESEARCH-AS         | *                      
 199.14.184.128/26 |    AS1 | BBN Planet backbone     | U.S. Sprint (NETBLK-SPR
  134.241.109.0/24 |    AS1 | BBN Planet backbone     | Massachusetts Higher Ed
  161.223.220.0/22 |    AS1 | BBN Planet backbone     | Indian Health Service (
  161.223.224.0/24 |    AS1 | BBN Planet backbone     | Indian Health Service (
    159.87.34.0/24 |    AS1 | BBN Planet backbone     | Arizona State Governmen
    166.4.174.0/26 |    AS1 | BBN Planet backbone     | *                      
   135.16.150.0/24 |    AS1 | BBN Planet backbone     | *                      
   143.192.24.0/24 |    AS1 | BBN Planet backbone     | *                      




From geoffw at precipice.v-site.net  Tue Mar 25 16:02:39 1997
From: geoffw at precipice.v-site.net (Geoff White)
Date: Tue, 25 Mar 1997 08:02:39 -0800 (PST)
Subject: Reserved Network Numbers
In-Reply-To: <199703251551.PAA18058@corp.netcom.net.uk>
Message-ID: <Pine.SUN.3.95.970325080157.21013A-100000@precipice.v-site.net>

On Tue, 25 Mar 1997, Rick Payne wrote:

> Geoff White writes:
>  > Now for a brief excursion into the totally mundane.
>  > Can anyone point me to the internet-draft/RFC that
>  > specifies the "reserverd networks" (i.e. the class A,B, & C [sic]
>  > network numbers that are considered "safe" (no-one should be routing them)
>  > to use as test/intranet/private IP networks?
> 
> RFC1918.
> 
> Rick
> -- 
> Rick Payne, Senior Network Admin     | Meddle not in the affairs of
> NETCOM Internet Ltd.                 | dragons - for you are crunchy &
> rickp at corp.netcom.net.uk             | taste great dipped in chocolate.
> 


THANKS ALL.






From geoffw at precipice.v-site.net  Tue Mar 25 15:46:37 1997
From: geoffw at precipice.v-site.net (Geoff White)
Date: Tue, 25 Mar 1997 07:46:37 -0800 (PST)
Subject: Reserved Network Numbers
Message-ID: <Pine.SUN.3.95.970325074306.20927B-100000@precipice.v-site.net>


Now for a brief excursion into the totally mundane.
Can anyone point me to the internet-draft/RFC that
specifies the "reserverd networks" (i.e. the class A,B, & C [sic]
network numbers that are considered "safe" (no-one should be routing them)
to use as test/intranet/private IP networks?

I need to know all of the numbers, i.e. I believe 10.0.0.0 is the class A
component of the list.

Thanks in advance.


						Geoff White
						Virtual Sites






From hannan at UU.NET  Tue Mar 25 16:08:01 1997
From: hannan at UU.NET (Alan Hannan)
Date: Tue, 25 Mar 1997 11:08:01 -0500 (EST)
Subject: Reserved Network Numbers
In-Reply-To: <Pine.SUN.3.95.970325074306.20927B-100000@precipice.v-site.net> from "Geoff White" at Mar 25, 97 07:46:37 am
Message-ID: <QQcikm25790.199703251608@loc-nar.UU.NET>


  RFC 1918, previously RFC1597.

	  http://globecom.net/ietf/rfc/rfc1918.shtml
	
  or 
		
	  ftp://ftp.ds.internic.net:/rfc/rfc1918.txt

  Here is an excerpt from section 3:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

  -a
] 
] 
] Now for a brief excursion into the totally mundane.
] Can anyone point me to the internet-draft/RFC that
] specifies the "reserverd networks" (i.e. the class A,B, & C [sic]
] network numbers that are considered "safe" (no-one should be routing them)
] to use as test/intranet/private IP networks?
] 
] I need to know all of the numbers, i.e. I believe 10.0.0.0 is the class A
] component of the list.
] 
] Thanks in advance.
] 
] 
] 						Geoff White
] 						Virtual Sites
] 
] 





From lhoward at UU.NET  Tue Mar 25 16:10:20 1997
From: lhoward at UU.NET (Lee Howard)
Date: Tue, 25 Mar 1997 11:10:20 -0500 (EST)
Subject: Reserved Network Numbers
In-Reply-To: <Pine.SUN.3.95.970325074306.20927B-100000@precipice.v-site.net> from "Geoff White" at Mar 25, 97 07:46:37 am
Message-ID: <QQcikm02157.199703251610@asgard.UU.NET>

The following should be attributed to Geoff White:
> 
> 
> Now for a brief excursion into the totally mundane.
> Can anyone point me to the internet-draft/RFC that
> specifies the "reserverd networks" (i.e. the class A,B, & C [sic]
> network numbers that are considered "safe" (no-one should be routing them)
> to use as test/intranet/private IP networks?
> 
> I need to know all of the numbers, i.e. I believe 10.0.0.0 is the class A
> component of the list.
> 
> Thanks in advance.
> 
> 
> 						Geoff White
> 						Virtual Sites
> 
http://ds.internic.net/ds/rfc-index.html
Specifically, RFC 1918,
specifically, 
   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:

     10.0.0.0        -   10.255.255.255  (10/8 prefix)
     172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
     192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

Lee





From jsaker at intellitek.com  Tue Mar 25 16:29:34 1997
From: jsaker at intellitek.com (James R. Saker Jr.)
Date: Tue, 25 Mar 1997 10:29:34 -0600
Subject: Reserved Network Numbers
Message-ID: <01BC3907.70C5D960@geneva.intellix.net>

Geoff White [SMTP:geoffw at precipice.v-site.net] writes:

Now for a brief excursion into the totally mundane.
Can anyone point me to the internet-draft/RFC that
specifies the "reserverd networks" (i.e. the class A,B, & C [sic]
network numbers that are considered "safe" (no-one should be routing them)
to use as test/intranet/private IP networks?

I believe you're looking for RFC 1918. Here's the header; document available at:

http://ds.internic.net/rfc/rfc1918.txt

---document header---

Network Working Group                                         Y. Rekhter
Request for Comments: 1918                                 Cisco Systems
Obsoletes: 1627, 1597                                       B. Moskowitz
BCP: 5                                                    Chrysler Corp.
Category: Best Current Practice                            D. Karrenberg
                                                                RIPE NCC
                                                          G. J. de Groot
                                                                RIPE NCC
                                                                 E. Lear
                                                  Silicon Graphics, Inc.
                                                           February 1996


                Address Allocation for Private Internets

Status of this Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

1. Introduction

   For the purposes of this document, an enterprise is an entity
   autonomously operating a network using TCP/IP and in particular
   determining the addressing plan and address assignments within that
   network.

   This document describes address allocation for private internets. The
   allocation permits full network layer connectivity among all hosts
   inside an enterprise as well as among all public hosts of different
   enterprises. The cost of using private internet address space is the
   potentially costly effort to renumber hosts and networks between
   public and private.


James R. Saker Jr.	James_Saker at Intellitek.com
President			http://Intellitek.com
Network Media Division	voice: 402.333.6233
Intellitek Corporation	fax: 402.333.6432






From pam at merit.edu  Wed Mar 26 12:23:54 1997
From: pam at merit.edu (Pam Ciesla)
Date: Wed, 26 Mar 1997 07:23:54 -0500 (EST)
Subject: ATTENDEE LIST FOR JUNE MEETING
Message-ID: <199703261223.HAA07335@home.merit.edu>


AN ATTENDEE LIST IS NOW AVAILABLE ON THE WEB PAGE FOR THE JUNE MEETING IN
TAMPA.  IF YOU ARE NOT ON THE LIST AND SHOULD BE PLEASE LET ME KNOW. THANKS
  Pam Ciesla




From JimFleming at unety.net  Wed Mar 26 20:24:17 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 14:24:17 -0600
Subject: NSI is not the InterNIC
Message-ID: <01BC39F1.63CE5760@webster.unety.net>


To help confirm that the InterNIC and NSI are not the same
and that a new management team is running NSI...

November 1, 1996...[1]
	"Gabe Battista officially became the new CEO for NSI"

November 12, 1996...[2]
	According to the IAHC, Dr. Don Telage is the President of NSI
	and "Network Solutions will participate and support this effort
	enthusiastically"...is that what happened...?

January 1997...[3]
	According to ARIN, "Donald N. Telage, Ph.D, President
	and Chief Operating Officer at Network Solutions Inc....
	has become active in the governance community of the
	Internet.."...where ?

February 1997...[4]
	According to the redesigned NSI web site..http://www.netsol.com
	"Don Telage, Senior VP Internet Relations and Special Projects"
	is one of the contact people, other InterNIC people are not
	mentioned.

March 11, 1997...
	"Network Solutions and Leading ISPs Launch Premier
	Domain Registration Service Program"
	INTERNET WORLD, LOS ANGELES
	"CompuServe, DIGEX, Earthlink, iServer, MCI, MindSpring,
	Netcom Interactive, Rapidsite, SuperNet, Inc. and TIAC
	have all signed agreements with Network Solutions"

March 24, 1997...[5]
	According to Kim Hubbard of the InterNIC (kimh at internic.net)
	"As for the status of ARIN, there are still a few issues that will
	need to be resolved before we can proceed.  These are political/
	financial issues between NSF and NSI."

====================================================

[1] @@@@ http://www.netsol.com

"Network Solutions, Inc. and the InterNIC will be moving forward
under both old and new leadership. On November 1, 1996
Gabe Battista officially became the new CEO for NSI. Formerly
president and chief executive officer at Cable and Wireless, Inc.,
Battista brings years of experience and leadership in the
networking technology field to the top position at NSI.
Don Telage continues in the position of chief operating officer,
and Michael A. Daniels continues to serve as chairman of
the board for NSI."

@@@@@@@@@@@@@@@

[2] @@@ http://www.iahc.org/iahcmembers.html

WASHINGTON, DC, November 12, 1996...

"Dr. Donald N. Telage, president of the Herndon, Virginia - based
Network Solutions, Inc., which manages the InterNIC Registry
administering the .com, .net, .edu, and .org top level domains,
said: "Network Solutions has supported the registration process
and the growth of the Internet since 1991. We have seen its
evolution from a research and education tool to a powerful medium
for global communication and collaboration. The National Science
Foundation has played a critical role in the early governance activities,
and we support the Internet Society's efforts to review issues
critical to the future of Internet growth, evolution and governance.
Network Solutions will participate and support this effort
enthusiastically supplying our extensive operational knowledge
as needed." 

@@@@@@@@@@@@@@@@@@@@@


[3] @@@@ http://www.arin.net/arin_board.html

"Proposed Board Of Trustees"

"Donald N. Telage, Ph.D, President and Chief Operating
Officer at Network Solutions Inc.since January 1995 following
its acquisition by Science Applications International Corporation
(SAIC). He has grown NSI into a key Internet company and the
world technology leader in Internet Registration services.
His prior experience with SAIC, from 1986 to 1995, involved
a progression in executive management culminating with
the position of Senior Vice President managing the
Telecommunications Technology Operating Group, which he
started. While at GTE from 1980 to 1985, he held a variety
of systems engineering positions, both technical and
management, involving data communications systems
design. Prior to 1980, Dr. Telage was a faculty member
in mathematics and computer science at several universities,
and conducted parallel research programs. He has
become active in the governance community of the Internet,
and he is a frequent speaker on matters of governance
and administration of Internet infrastructure."

@@@@@@@@@@@@@@@@@@@@@@@

[4] @@@ http://www.netsol.com

Gabriel A. Battista, CEO 
Robert Korzeniewski , CFO 
Don Telage, Senior VP Internet Relations and Special Projects 
David Holtzman, Senior VP of Engineering 
Chris Clough, Director of Communications 
Chuck Gomes, Director of Customer Programs

[5] @@@@@@@@@@@@@@@@@@@@@@@@

----------
From: 	Kim Hubbard[SMTP:kimh at INTERNIC.NET]
Sent: 	Monday, March 24, 1997 8:09 AM
To: 	Michael Dillon
Cc: 	naipr at arin.net
Subject: 	Re: AS Numbers, website, timing...

> 
> 
> Could we have RFC 1930 regarding AS numbers added to the Recommended
> Reading section at ARIN's website as well as a link added for the
> March archive of the discussion list? Perhaps an April link should be
> added as well since the list-server software automatically rolls over the
> archive each month.
> 
> Also, is the BoT close enough to a budget and/or next draft proposal that
> someone would be willing to give out a guesstimate of when these will
> be available for perusal?
> 
> Michael Dillon                   -               Internet & ISP Consulting
> Memra Software Inc.              -                  Fax: +1-250-546-3049
> http://www.memra.com             -               E-mail: michael at memra.com
> 


Okay, I'll take care of adding the RFC and the links.

As for the status of ARIN, there are still a few issues that will
need to be resolved before we can proceed.  These are political/
financial issues between NSF and NSI.

I know we projected an April operational date, obviously we will 
not be making that.  Please be patient with us, while these details are
worked out.  We need to make sure everything is done right, even if it
takes longer than planned.

Thanks,

Kim

@@@@@@@@@@@@@@@@@@@@

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From JimFleming at unety.net  Thu Mar 27 00:31:21 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 18:31:21 -0600
Subject: 252 Active TLDs
Message-ID: <01BC3A13.E8071860@webster.unety.net>


According to our latest study, there are 252
active Top Level Domains with Name Servers, etc.

@@@@@ As of 6:00 PM CST March 26, 1997

800 AD AE AG AGN AI AL AM AN AO AQ AR
ARPA ART ARTS AT AU AUDIO AUTO AW AZ BA BB BE
BF BG BH BI BIZ BJ BM BN BO BR BS BW
BY BZ CA CF CG CH CI CITY CK CL CM CN
CO COM CORP CR CU CV CY CZ DE DJ DK DM
DO DOT DZ EARTH EC EDU EE EG ER ES ET EUR
EXP FAM FCN FI FJ FM FO FR FREE GAY GB GD
GE GES GF GG GH GI GL GN GOV GP GR GT
GU GW GY HIGGS HK HN HR HU ID IE IL IM
IN INC INT IR IS IT JE JM JO JP JPN K12
KE KH KI KN KR KW KY KZ LA LAW LB LC
LI LK LNX LS LT LTD LU LV MA MAIL MALL MC
MD MED METRO MEX MG MH MIL MK ML MM MN MO
MP MR MT MU MV MW MX MY MZ NA NC NE
NET NEWS NF NG NI NIC NL NO NP NPO NUM NZ
OM ORG PA PE PER PF PG PH PHONE PK PL PR
PRO PT PY QA RO RU RW SA SB SE SEA SG
SHOP SI SK SM SN SR SU SV SY SZ TC TG
TH TN TO TOUR TR TT TV TW TZ UA UG UK
US USA USVI UY UZ VA VC VE VI VN VU WEB
WS WTV XXX YE YU Z ZA ZM ZONE ZOO ZR ZW

@@@@@

A report on the health of the eDNS Root Name Servers
with respect to the InterNIC Root Name Servers will be
forthcoming. The above TLDs will be the ones included
in the report.






From avg at pluris.com  Thu Mar 27 00:58:02 1997
From: avg at pluris.com (Vadim Antonov)
Date: Wed, 26 Mar 1997 16:58:02 -0800
Subject: 252 Active TLDs
Message-ID: <199703270058.QAA11006@quest.pluris.com>

I want to register TLD .XXX with eDNS.  What should i do
about it?

--vadim


From JimFleming at unety.net  Thu Mar 27 00:31:21 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 18:31:21 -0600
Subject: 252 Active TLDs
Message-ID: <mailman.71.1599875436.15750.nanog@nanog.org>


According to our latest study, there are 252
active Top Level Domains with Name Servers, etc.

@@@@@ As of 6:00 PM CST March 26, 1997

800 AD AE AG AGN AI AL AM AN AO AQ AR
ARPA ART ARTS AT AU AUDIO AUTO AW AZ BA BB BE
BF BG BH BI BIZ BJ BM BN BO BR BS BW
BY BZ CA CF CG CH CI CITY CK CL CM CN
CO COM CORP CR CU CV CY CZ DE DJ DK DM
DO DOT DZ EARTH EC EDU EE EG ER ES ET EUR
EXP FAM FCN FI FJ FM FO FR FREE GAY GB GD
GE GES GF GG GH GI GL GN GOV GP GR GT
GU GW GY HIGGS HK HN HR HU ID IE IL IM
IN INC INT IR IS IT JE JM JO JP JPN K12
KE KH KI KN KR KW KY KZ LA LAW LB LC
LI LK LNX LS LT LTD LU LV MA MAIL MALL MC
MD MED METRO MEX MG MH MIL MK ML MM MN MO
MP MR MT MU MV MW MX MY MZ NA NC NE
NET NEWS NF NG NI NIC NL NO NP NPO NUM NZ
OM ORG PA PE PER PF PG PH PHONE PK PL PR
PRO PT PY QA RO RU RW SA SB SE SEA SG
SHOP SI SK SM SN SR SU SV SY SZ TC TG
TH TN TO TOUR TR TT TV TW TZ UA UG UK
US USA USVI UY UZ VA VC VE VI VN VU WEB
WS WTV XXX YE YU Z ZA ZM ZONE ZOO ZR ZW

@@@@@

A report on the health of the eDNS Root Name Servers
with respect to the InterNIC Root Name Servers will be
forthcoming. The above TLDs will be the ones included
in the report.









From JimFleming at unety.net  Thu Mar 27 01:11:33 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 19:11:33 -0600
Subject: 252 Active TLDs
Message-ID: <01BC3A19.85D2A820@webster.unety.net>

On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
@ I want to register TLD .XXX with eDNS.  What should i do
@ about it?
@ 

If you want to start a new Top Level Domain, you
might want to review http://www.edns.net. For the
eDNS system, you will need to contact one of the
5 (last count) Registration Authorities. The eDNS
Root Name Server operators get their direction from
the RAs.

If you want to register in the .XXX Top Level Domain
then you need to visit the registry just as you would
with the InterNIC. Here are some of the operational
registries:

@@@@@  http://www.alternic.net/domains/quick_form/

	.LNX - Linux Systems
	.LTD - Limited
	.MED - Medical
	.NIC - Network Information Center
	.XXX - Adult

@@@@@  http://www.mcs.net/nic/domain-register.html

	.CORP - For Corporations (Commercial)
	.NPO - Not-for-Profit Organizations
	.K12 - For people under the age of 18
	.BIZ - General Business Use

@@@@@  http://webtld.com/

	.WEB - Web Sites

@@@@@  http://www.agn.net/EARTH-DOMAIN.html

	.EARTH - General

@@@@@  http://www.agn.net/USA-DOMAIN.html

	.USA - General

@@@@@  http://www.higgs.net/hanic/reg/

	.NEWS - News services, etc.

@@@@@ http://www.iperdome.com/rpdn.htm

	.PER  -  Personal Domain Names

@@@@@@@@@@@@@

By the way, some of the registries such as
http://Register.A.Mall and the .CORP registry
are developing "channel partner" marketing programs
so that you can share in the revenue, thus making the
TLD effectively shared even though one company has
to handle the key entry of the names and ensure the
inegrity of the data.

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From gherbert at crl.com  Thu Mar 27 01:14:19 1997
From: gherbert at crl.com (George Herbert)
Date: Wed, 26 Mar 1997 17:14:19 -0800
Subject: InterNIC responds to me
Message-ID: <199703270114.AA13632@mail.crl.com>


I just finished up a phone conversation (45 min or so) with Chuck Gomes
at InterNIC (NSI), regarding the recent set of problems that have
happened with various domains.  While it appears that a number of
issues remain to be investegated, I think that Chuck addressed
most of the major concerns I had and said he's investegating the
other concerns.  He said they are working on a FAQ / info release
on recent events and hope to send it out tomorrow, though he
couldn't guarantee it would be that soon.

The most important thing that came up in the conversation was that
the event that appears to have percipitated the rash of public complaints
is that they are in the process of catching up their billing status so
that domains that haven't paid are now in the 30-15-5-hold-deleted
track not sitting in limbo for months before being acted on.
This means that they are now seeing many many months worth of
minor accumulated errors hitting all at once, effectively.

Chuck said that they are implimenting a new problem handling procedure,
if your domain is about to go on hold email to billing at internic
with the keywords URGENT and DEACTIVATION in the subject will
get seen most promptly and he stated that their policy is that
they are supposed to always err on the side of leaving domains
turned on while issues are investegated.  He did comment that they
have had problems with that not always being the case, but he's
working on making sure that policy is consistent in all cases.

We also talked about various specific problems they've been seeing
and he disclosed some failures they had recently in check and credit
card billing accounting and in domain status processing.  He said that
they'd fixed most of them shortly after they occurred, but a few
were lingering on and are expected to be fixed this week.
The problem of having credit card payments not going to the
right domain (and he brought up a related problem, refunds
in multi-payment cases) he said was known and being looked at.
I don't think they know what they are going to do about it
yet but they are aware of it.

I did comment that they need more proactive communications about
things like this, and he said they have a fulltime communications
director who's been hired and is coming up to speed.

On the whole, I am a lot less unhappy about recent events than I
was yesterday, I think he addressed the concerns I had about
what's going on.  There are problems, some of which they know
remain large and unresolved, but I don't think now that we saw
a sudden bitrot in their databases last week.  I'm looking forwards
to the official announcement...


-george william herbert
gherbert at crl.com





From dirk at power.net  Thu Mar 27 01:32:35 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Wed, 26 Mar 1997 17:32:35 -0800 (PST)
Subject: InterNIC responds to me
In-Reply-To: <199703270114.AA13632@mail.crl.com>
Message-ID: <Pine.LNX.3.95.970326172435.12657D-100000@ws6.power.net>


Isn't it amazing how much extra work gets generated because of billing
for domain names? Call centers, directors of communications... are we
this desperate to create jobs? How many hours of productivity where wasted
world wide being on the hold with InterNIC? Looking up receipts?

This entire thing could and should be automated.

Dirk

On Wed, 26 Mar 1997, George Herbert wrote:

> 
> I just finished up a phone conversation (45 min or so) with Chuck Gomes
> at InterNIC (NSI), regarding the recent set of problems that have
> happened with various domains.  While it appears that a number of
> issues remain to be investegated, I think that Chuck addressed
> most of the major concerns I had and said he's investegating the
> other concerns.  He said they are working on a FAQ / info release
> on recent events and hope to send it out tomorrow, though he
> couldn't guarantee it would be that soon.
> 
> The most important thing that came up in the conversation was that
> the event that appears to have percipitated the rash of public complaints
> is that they are in the process of catching up their billing status so
> that domains that haven't paid are now in the 30-15-5-hold-deleted
> track not sitting in limbo for months before being acted on.
> This means that they are now seeing many many months worth of
> minor accumulated errors hitting all at once, effectively.
> 
> Chuck said that they are implimenting a new problem handling procedure,
> if your domain is about to go on hold email to billing at internic
> with the keywords URGENT and DEACTIVATION in the subject will
> get seen most promptly and he stated that their policy is that
> they are supposed to always err on the side of leaving domains
> turned on while issues are investegated.  He did comment that they
> have had problems with that not always being the case, but he's
> working on making sure that policy is consistent in all cases.
> 
> We also talked about various specific problems they've been seeing
> and he disclosed some failures they had recently in check and credit
> card billing accounting and in domain status processing.  He said that
> they'd fixed most of them shortly after they occurred, but a few
> were lingering on and are expected to be fixed this week.
> The problem of having credit card payments not going to the
> right domain (and he brought up a related problem, refunds
> in multi-payment cases) he said was known and being looked at.
> I don't think they know what they are going to do about it
> yet but they are aware of it.
> 
> I did comment that they need more proactive communications about
> things like this, and he said they have a fulltime communications
> director who's been hired and is coming up to speed.
> 
> On the whole, I am a lot less unhappy about recent events than I
> was yesterday, I think he addressed the concerns I had about
> what's going on.  There are problems, some of which they know
> remain large and unresolved, but I don't think now that we saw
> a sudden bitrot in their databases last week.  I'm looking forwards
> to the official announcement...
> 
> 
> -george william herbert
> gherbert at crl.com
> 
> 
> ============================== ISP Mailing List ==============================
> Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
> If the thread changes topics, change the subject.
> 





From JimFleming at unety.net  Thu Mar 27 01:55:21 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 19:55:21 -0600
Subject: 252 Active TLDs
Message-ID: <01BC3A1F.A3F3EAC0@webster.unety.net>

On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
@ I want to register TLD .XXX with eDNS.  What should i do
@ about it?
@ 

If by .XXX, you mean a new 3 letter name,
you might want to take advantage of this bit
of market research. Here is the frequency
count for 3 letter combinations before the
.COM TLD. These were taken from a recent
list of the over 1,000,000 .COM domains.

17097 NET.COM	.
15835 ING.COM	.
13821 INC.COM	. <---- New TLD
11353 INE.COM	.
9026 ION.COM
7496 ECH.COM
7183 ONS.COM
6768 TER.COM
6453 OUP.COM
6032 USA.COM <------ New TLD
5965 WEB.COM <-------- New TLD
5824 ICS.COM
5534 ESS.COM <--- The most common ending in English words...
5295 ARE.COM
5196 ORP.COM
4955 IES.COM
4650 ALL.COM
4619 ENT.COM
4345 COM.COM <-------Interesting
4243 AGE.COM
3840 EST.COM
3722 RTS.COM
3627 ONE.COM
3577 SYS.COM
3575 NCE.COM
3574 DIA.COM
3517 EMS.COM
3473 MES.COM
3411 INK.COM
3397 OFT.COM
3366 CES.COM
3338 ATE.COM
3317 IGN.COM
3297 RLD.COM
3246 ART.COM <--------- New TLD
3235 LES.COM
3192 ITY.COM
3136 LAW.COM <-------- New TLD
3056 ITE.COM
3037 AND.COM
3009 MAN.COM
2984 ICE.COM
--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From avg at pluris.com  Thu Mar 27 02:11:20 1997
From: avg at pluris.com (Vadim Antonov)
Date: Wed, 26 Mar 1997 18:11:20 -0800
Subject: 252 Active TLDs
Message-ID: <199703270211.SAA11063@quest.pluris.com>

Jim Fleming <JimFleming at unety.net> wrote:

On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
@ I want to register TLD .XXX with eDNS.  What should i do
@ about it?
@ 

>If you want to register in the .XXX Top Level Domain
>then you need to visit the registry just as you would
>with the InterNIC. Here are some of the operational
>registries:

Nah, you don't understand.  Somebody have already taken
.XXX.  I suppose that claim is illegitimate, and the rights to
that TLD belong to me.  You see, i own the trademark XXX (cyrillic
HA-HA-HA), valid in Russian Federation.

Now, would you please hand me rights to dispose the TLD .XXX as
i see fit?

--vadim




From karl at Mcs.Net  Thu Mar 27 01:52:16 1997
From: karl at Mcs.Net (Karl Denninger)
Date: Wed, 26 Mar 1997 19:52:16 -0600
Subject: 252 Active TLDs
In-Reply-To: <199703270058.QAA11006@quest.pluris.com>; from Vadim Antonov on Wed, Mar 26, 1997 at 04:58:02PM -0800
References: <199703270058.QAA11006@quest.pluris.com>
Message-ID: <19970326195216.04398@Jupiter.Mcs.Net>

On Wed, Mar 26, 1997 at 04:58:02PM -0800, Vadim Antonov wrote:
> I want to register TLD .XXX with eDNS.  What should i do
> about it?
> 
> --vadim

See the web page at http://www.edns.net/, select an RA, negotiate a deal as
a registry, and have them send it in.

As long as its not REALLY "xxx"; that one is taken:

; <<>> DiG 2.2 <<>> txt xxx. 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 3, Addit: 2
;; QUESTIONS:
;;	xxx, type = TXT, class = IN

;; ANSWERS:
xxx.	86400	TXT	"245 4th St, #501, Bremerton, WA  98337 +1 360-275-7830  http://www.alternic.net/ "
xxx.	86400	TXT	"RA: Alternic / Registry: Alternic ekashp at alternic.net (6)"

;; AUTHORITY RECORDS:
xxx.	172000	NS	MX.ALTERNIC.NET.
xxx.	172000	NS	aragorn.ALTERNIC.NET.
xxx.	172000	NS	NYC.ALTERNIC.NET.

;; ADDITIONAL RECORDS:
MX.ALTERNIC.NET.	86400	A	204.94.42.1
NYC.ALTERNIC.NET.	86400	A	207.51.48.15

;; Total query time: 6 msec
;; FROM: Jupiter.Mcs.Net to SERVER: default -- 192.160.127.90
;; WHEN: Wed Mar 26 19:51:59 1997
;; MSG SIZE  sent: 21  rcvd: 286


--
-- 
Karl Denninger (karl at MCS.Net)| eDNS - The free-market solution
http://www.edns.net/	     | hostmaster at edns.net




From JimFleming at unety.net  Thu Mar 27 02:14:38 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Wed, 26 Mar 1997 20:14:38 -0600
Subject: 252 Active TLDs
Message-ID: <01BC3A22.555A1F80@webster.unety.net>

On Wednesday, March 26, 1997 8:11 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
@ Jim Fleming <JimFleming at unety.net> wrote:
@ 
@ On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
@ @ I want to register TLD .XXX with eDNS.  What should i do
@ @ about it?
@ @ 
@ 
@ >If you want to register in the .XXX Top Level Domain
@ >then you need to visit the registry just as you would
@ >with the InterNIC. Here are some of the operational
@ >registries:
@ 
@ Nah, you don't understand.  Somebody have already taken
@ .XXX.  I suppose that claim is illegitimate, and the rights to
@ that TLD belong to me.  You see, i own the trademark XXX (cyrillic
@ HA-HA-HA), valid in Russian Federation.
@ 
@ Now, would you please hand me rights to dispose the TLD .XXX as
@ i see fit?
@ 

It sounds like you would be a good candidate
to be a "channel partner". You should contact the
.XXX registry.

Of course you could also start the .HAHAHA
Top Level Domain. If you want to start the
HAHAHA.MALL check with me...;-)

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From perry at piermont.com  Thu Mar 27 02:33:08 1997
From: perry at piermont.com (Perry E. Metzger)
Date: Wed, 26 Mar 1997 21:33:08 -0500
Subject: 252 Active TLDs 
In-Reply-To: Your message of "Wed, 26 Mar 1997 19:11:33 CST."
             <01BC3A19.85D2A820@webster.unety.net> 
Message-ID: <199703270233.VAA08748@jekyll.piermont.com>


Jim Fleming writes:
> On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrot
e:
> @ I want to register TLD .XXX with eDNS.  What should i do
> @ about it?
> @ 
> 
> If you want to start a new Top Level Domain, you
> might want to review http://www.edns.net.

Of course, you'll only be visible to, like, what, under half of one
percent of the net?

Perry




From tim at taggnet.skyscape.net  Thu Mar 27 02:37:12 1997
From: tim at taggnet.skyscape.net (Tim Gibson)
Date: Wed, 26 Mar 1997 21:37:12 -0500 (EST)
Subject: 252 Active TLDs
In-Reply-To: <199703270211.SAA11063@quest.pluris.com>
Message-ID: <Pine.BSD/.3.91.970326213624.18822A-100000@taggnet.skyscape.net>

Then I'm going to have to counter with 2 trademarks, Canadian and U.S. 
...stronger.

On Wed, 26 Mar 1997, Vadim Antonov wrote:

> Jim Fleming <JimFleming at unety.net> wrote:
> 
> On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
> @ I want to register TLD .XXX with eDNS.  What should i do
> @ about it?
> @ 
> 
> >If you want to register in the .XXX Top Level Domain
> >then you need to visit the registry just as you would
> >with the InterNIC. Here are some of the operational
> >registries:
> 
> Nah, you don't understand.  Somebody have already taken
> .XXX.  I suppose that claim is illegitimate, and the rights to
> that TLD belong to me.  You see, i own the trademark XXX (cyrillic
> HA-HA-HA), valid in Russian Federation.
> 
> Now, would you please hand me rights to dispose the TLD .XXX as
> i see fit?
> 
> --vadim
> 




From dirk at power.net  Thu Mar 27 02:43:41 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Wed, 26 Mar 1997 18:43:41 -0800 (PST)
Subject: 252 Active TLDs
In-Reply-To: <01BC3A1F.A3F3EAC0@webster.unety.net>
Message-ID: <Pine.LNX.3.95.970326184147.13067D-100000@ws6.power.net>


I still don't know why we need top level domains at all. I can see how
having 5 doesn't too much harm. But I can't remember any more then that.

So, why not joe at microsoft, tim at sony and so on? No, its not a technical
problem.

Dirk

On Wed, 26 Mar 1997, Jim Fleming wrote:

> On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrote:
> @ I want to register TLD .XXX with eDNS.  What should i do
> @ about it?
> @ 
> 
> If by .XXX, you mean a new 3 letter name,
> you might want to take advantage of this bit
> of market research. Here is the frequency
> count for 3 letter combinations before the
> .COM TLD. These were taken from a recent
> list of the over 1,000,000 .COM domains.
> 
> 17097 NET.COM	.
> 15835 ING.COM	.
> 13821 INC.COM	. <---- New TLD
> 11353 INE.COM	.
> 9026 ION.COM
> 7496 ECH.COM
> 7183 ONS.COM
> 6768 TER.COM
> 6453 OUP.COM
> 6032 USA.COM <------ New TLD
> 5965 WEB.COM <-------- New TLD
> 5824 ICS.COM
> 5534 ESS.COM <--- The most common ending in English words...
> 5295 ARE.COM
> 5196 ORP.COM
> 4955 IES.COM
> 4650 ALL.COM
> 4619 ENT.COM
> 4345 COM.COM <-------Interesting
> 4243 AGE.COM
> 3840 EST.COM
> 3722 RTS.COM
> 3627 ONE.COM
> 3577 SYS.COM
> 3575 NCE.COM
> 3574 DIA.COM
> 3517 EMS.COM
> 3473 MES.COM
> 3411 INK.COM
> 3397 OFT.COM
> 3366 CES.COM
> 3338 ATE.COM
> 3317 IGN.COM
> 3297 RLD.COM
> 3246 ART.COM <--------- New TLD
> 3235 LES.COM
> 3192 ITY.COM
> 3136 LAW.COM <-------- New TLD
> 3056 ITE.COM
> 3037 AND.COM
> 3009 MAN.COM
> 2984 ICE.COM
> --
> Jim Fleming
> Unir Corporation
> http://www.Unir.Corp
> 
> Check out...http://Register.A.Mall
> 





From jordy at snappy.wserv.com  Thu Mar 27 05:28:14 1997
From: jordy at snappy.wserv.com (Jordan Mendelson)
Date: Thu, 27 Mar 1997 00:28:14 -0500 (EST)
Subject: 252 Active TLDs 
In-Reply-To: <199703270233.VAA08748@jekyll.piermont.com>
Message-ID: <Pine.LNX.3.95.970327001724.32066B-100000@snappy.wserv.com>

-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 26 Mar 1997, Perry E. Metzger wrote:

> 
> Jim Fleming writes:
> > On Wednesday, March 26, 1997 6:58 PM, Vadim Antonov[SMTP:avg at pluris.com] wrot
> e:
> > @ I want to register TLD .XXX with eDNS.  What should i do
> > @ about it?
> > @ 
> > 
> > If you want to start a new Top Level Domain, you
> > might want to review http://www.edns.net.
> 
> Of course, you'll only be visible to, like, what, under half of one
> percent of the net?

I really wouldn't say even that much. The problem with doing percentages
is that in order to do them, you actually have to know how big the
Internet is right now. No one really knows that. Estimates range from 20
million to half a billion.

I mean, the entire eDNS, AlterNIC and all the other 'alternet registries'
are silly. I rather have a set of rules, regulations, official committees
where more than 'one guy who once sold domains and figures that he can
make a lot more this way' decides who gets what. Granted, InterNIC has its
problems, billing isn't perfect yet, some technical bugs need to be worked
out... but damn it, do you REALLY think that you can do better? I mean, you
try dealing with 500,000 checks coming in and see how many billing
mistakes you'll make.

The fact of the matter is that the idea of the Internet is getting screwed
up by people who want to turn a fast buck. I'm sick and tired of it. I
don't mind people selling products on the web, but I just wish it would
STOP there. I mean, things like MS rewriting ICMP because they didn't like
it and trying to force everyone to adapt is completely uncalled for. The
same applies for eDNS.

Seriously, if you want to promote eDNS (which it is obvious the person who
posted the messages does), go somewhere else. I really don't need talk
about ".XXX FOR SALE!!!" cluttering up my mailbox.


Jordy


- --
Jordan Mendelson     : www.wserv.com/~jordy
Web Services, Inc.   : www.wserv.com







-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMzoFchA7rx9toVxZAQEWDAP+I0KoPweirhb7B5CoIW5a1d6rPyAU5/03
TU5Ik0a1LNRMkLBoYSSfoTkcyF22nMHWGtvAm7m3ZBUHr+I8XC+Vl5DGP6sdy3QF
wkVhC60X3C0qKdVgHPPKBcvuhLP3L5er1sPre9d5huVRuUEQnon85jKGzdjk3yl0
3Ktz+ozyjIc=
=GxoD
-----END PGP SIGNATURE-----





From avg at pluris.com  Thu Mar 27 06:56:02 1997
From: avg at pluris.com (Vadim Antonov)
Date: Wed, 26 Mar 1997 22:56:02 -0800
Subject: 252 Active TLDs
Message-ID: <199703270656.WAA11315@quest.pluris.com>

@ Nah, you don't understand.  Somebody have already taken
@ .XXX.  I suppose that claim is illegitimate, and the rights to
@ that TLD belong to me.  You see, i own the trademark XXX (cyrillic
@ HA-HA-HA), valid in Russian Federation.
@ 
@ Now, would you please hand me rights to dispose the TLD .XXX as
@ i see fit?

>It sounds like you would be a good candidate
>to be a "channel partner". You should contact the
>.XXX registry.

>Of course you could also start the .HAHAHA
>Top Level Domain. If you want to start the
>HAHAHA.MALL check with me...;-)

No, i would like to enforce my rights and therefore request that
this particular TLD being made unavailable to clients on the
territory of R.F.  I certainly do not want to share it with
someone else.

--vadim




From avg at pluris.com  Thu Mar 27 06:59:58 1997
From: avg at pluris.com (Vadim Antonov)
Date: Wed, 26 Mar 1997 22:59:58 -0800
Subject: 252 Active TLDs
Message-ID: <199703270659.WAA11324@quest.pluris.com>

Tim Gibson <tim at taggnet.skyscape.net> wrote:

>Then I'm going to have to counter with 2 trademarks, Canadian and U.S.
>...stronger.

In U.S. and Canada.  Now, i'd like to see infringing stopped on
territory of R.F. where U.S. and Canadian trademark registrations
do not apply.

--vadim




From kevinbr at netcomm.ie  Thu Mar 27 11:51:17 1997
From: kevinbr at netcomm.ie (Kevin Brown)
Date: Thu, 27 Mar 1997 14:51:17 +0300
Subject: 252 Active TLDs
In-Reply-To: <199703270659.WAA11324@quest.pluris.com>
Message-ID: <l03010d01af600f675b98@[129.156.240.33]>

Again,


First come first served.


XXX as a trademark? Maybe I can get th word "the" as a trademark!

Kevin

At 9:59 +0300 27/3/97, Vadim Antonov wrote:
>Tim Gibson <tim at taggnet.skyscape.net> wrote:
>
>>Then I'm going to have to counter with 2 trademarks, Canadian and U.S.
>>...stronger.
>
>In U.S. and Canada.  Now, i'd like to see infringing stopped on
>territory of R.F. where U.S. and Canadian trademark registrations
>do not apply.
>
>--vadim
>-----------------------------------------------------------------------------
>This is the Newdom mailing list, newdom at vrx.net.  To subscribe or
>unsubscribe or get help , send the word "subscribe" or "unsubscribe" or
>"help" in the body (not subject) to newdom-request at vrx.net


////////////////////////////////////////////////////////////
     Kevin Brown            | N \  We operate in Ireland, UK
       NetComm              | e /  and the Middle East
  Internet Training,        | t \  --DUBAI--
 Consultancy and Networking | C /  Voice: +971-4-491476
                            | o \  Fax: +971-4-492957
    Sun Microsystems        | m /
   Internet Associate       | m \
                            |   /
     The Internet           |   \  email: kevinbr at netcomm.ie
       Experts              |   /         info at netcomm.ie
                            |   \  http://www.netcomm.ie

\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\







From rbenn at clark.net  Thu Mar 27 13:10:38 1997
From: rbenn at clark.net (rbenn at clark.net)
Date: Thu, 27 Mar 1997 08:10:38 -0500 (EST)
Subject: 252 Active TLDs 
In-Reply-To: <Pine.LNX.3.95.970327001724.32066B-100000@snappy.wserv.com>
Message-ID: <Pine.GSO.3.95.970327080351.1435A-100000@clark.net>

On Thu, 27 Mar 1997, Jordan Mendelson wrote:

> I really wouldn't say even that much. The problem with doing percentages
> is that in order to do them, you actually have to know how big the
> Internet is right now. No one really knows that. Estimates range from 20
> million to half a billion.
> 
> I mean, the entire eDNS, AlterNIC and all the other 'alternet registries'
> are silly. I rather have a set of rules, regulations, official committees
> where more than 'one guy who once sold domains and figures that he can
> make a lot more this way' decides who gets what. Granted, InterNIC has its
> problems, billing isn't perfect yet, some technical bugs need to be worked
> out... but damn it, do you REALLY think that you can do better? I mean, you
> try dealing with 500,000 checks coming in and see how many billing
> mistakes you'll make.
> 
> The fact of the matter is that the idea of the Internet is getting screwed
> up by people who want to turn a fast buck. I'm sick and tired of it. I
> don't mind people selling products on the web, but I just wish it would
> STOP there. I mean, things like MS rewriting ICMP because they didn't like
> it and trying to force everyone to adapt is completely uncalled for. The
> same applies for eDNS.
> 
> Seriously, if you want to promote eDNS (which it is obvious the person who
> posted the messages does), go somewhere else. I really don't need talk
> about ".XXX FOR SALE!!!" cluttering up my mailbox.
> 
> 
> Jordy
> 
> 
> - --
> Jordan Mendelson     : www.wserv.com/~jordy
> Web Services, Inc.   : www.wserv.com

The nice part about the 'new Internet' is that the market will decide if
any of these new services or proposals have any value.  If enough people
find value in the MS ICMP protocol and it becomes widely adopted, then so
be it.  Likewise, if enough people find value  in alternative registries
and they become valuable at some point, then so be it.  Of course, if
nobody adopts the idea of alternate registries (i.e., nobody sends checks 
to eDNS, etc.), the cash flow will soon run out and so will these kind of 
services.  I suspect the latter will occur more often than the former.

Randy Benn





From paul at vix.com  Thu Mar 27 17:37:17 1997
From: paul at vix.com (Paul A Vixie)
Date: Thu, 27 Mar 1997 09:37:17 -0800
Subject: boardwatch magazine -- hotbed of spammers?  irresponsible jerks?
Message-ID: <199703271737.JAA14917@wisdom.home.vix.com>

miserable scumsucking morons from hell?
completely unclear on the concept?
unaware of what NANOG is?
unaware of what the Internet is?

you decide.  see below.

for the record, mr. david dixon, i did NOT ask you for any information,
i am NOT an internet service provider, i do NOT allow this kind of trash
in my inbox, and your name is now MUD in most of known space.  good job.

see http://www.vix.com/spam/ for background material.

------- Forwarded Message

Received: by gw.home.vix.com; id HAA25989; Thu, 27 Mar 1997 07:01:16 -0800
Message-ID: <19970327075941.10104 at boardwatch.com>
From: David Dixon <david.dixon at boardwatch.com>
Errors-To: david.dixon at boardwatch.com
Reply-To: david.dixon at boardwatch.com
Organization: Boardwatch Magazine
To: "'Paul Vixie'" <paul at vix.com>
Subject: Directory of Internet Service Providers
Date: Thu, 27 Mar 1997 07:59:41 -0600
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit



Dear Paul

 Thank you for your interest in the NANOG9 conference. While attending the                 
 conference we hoped that you received and enjoyed your Fall issue of                      
 Boardwatch Magazine's Directory of Internet Service Providers. We have                    
 recently completed the March/April issue and want to send you a                           
 complimentary issue and subsequent issues. We currently do not have the                   
 correct mailing address to send this issue.                                               
                                                                                           
 Please fill in the information below and return email me so that we may                   
 send it out to you as soon as possible.                                                   
                                                                                           
 Street address                                                                            
                                                                                           
 City                                                                                      
                                                                                           
 State                                                                                     
                                                                                           
 Zip Code                                                                                  
                                                                                           
 Thanks and if you need any other information from Boardwatch don't hesitate               
 to call me at (800)933-6038.                                                              
                                                                                           
 David Dixon                                                                               
 Circulation Manager                                                                       
                                                                                           




------- End of Forwarded Message





From tim at taggnet.skyscape.net  Thu Mar 27 18:15:24 1997
From: tim at taggnet.skyscape.net (Tim Gibson)
Date: Thu, 27 Mar 1997 13:15:24 -0500 (EST)
Subject: boardwatch magazine -- hotbed of spammers? irresponsible jerks?
In-Reply-To: <199703271737.JAA14917@wisdom.home.vix.com>
Message-ID: <Pine.BSD/.3.91.970327130805.20837A-100000@taggnet.skyscape.net>

Mr. Vixie,
	Sorry you are spam magnet, but I like to read BoardWatch while 
taking a dump... been reading for years. TAKE their free copy, push them 
that 1 issue closer to bankruptcy. 

	I pick option 5, after the full issue of BoardWatch dedicated to 
anti-spam. They are hipocrits <sp> with maybe Mr. Dixon's superiours 
possessing some of 2 and 4 combined due to the lack of training they 
provided him. 1 is too harsh and 3 can't comment on without further 
screen garbage coming across.


							Tim Gibson

On Thu, 27 Mar 1997, Paul A Vixie wrote:

> miserable scumsucking morons from hell?
> completely unclear on the concept?
> unaware of what NANOG is?
> unaware of what the Internet is?
> 
> you decide.  see below.
> 
> for the record, mr. david dixon, i did NOT ask you for any information,
> i am NOT an internet service provider, i do NOT allow this kind of trash
> in my inbox, and your name is now MUD in most of known space.  good job.
> 
> see http://www.vix.com/spam/ for background material.




From Walter.Towbin at TELUS.COM  Thu Mar 27 18:24:33 1997
From: Walter.Towbin at TELUS.COM (Walter Towbin)
Date: Thu, 27 Mar 1997 11:24:33 -0700
Subject: BGP4 COMMUNITY attribute
Message-ID: <c=US%a=_%p=TELUS%l=TAC_NT1-970327182433Z-4334@tac-nt1.tac.net>

In the preparation for upcoming 2nd (multihomed) connection to Internet
I am looking into
COMMUNITY attribute of BGP4 as a way (in conjunction with my own
LOCAL_PREF) of load balancing
traffic between my two internet links (both T3). After reading CISCO
documentation I am still not
clear on some issues:

1. Is COMMUNITY a transitive attribute only between me and my immediate
upstream supplier or 
is it being propagated further into Internet (so I can influence how
somebody ,say, 5 AS hops 
away from me sees my routes) ?

2. If COMMUNITY propagates into big I, and I set COMMUNITY to 3561:70
(for MCI to set 
LOCAL_PREF on my routes to 70) and my next hop supplier sets COMMUNITY
of my routes to  
3561:80, what happens ? what MCI is going to do ?

3. Is COMMUNITY a CISCO only or is it part of RFC ? Has any other router
vendor implemented
this parameter ?

4. Which major Internet providers have COMMUNITY/LOCAL_PREF implemented
 (I am aware of MCI and Sprint) ?

5. Your experiences, comments, suggestions .....


Thanks in advance, Walter



Walter Towbin
Telus Advanced Communications
phone: 403-543-2032, fax: 403-543-2030, cell: 403-620-0019
walter.towbin at telus.com





From michael at memra.com  Thu Mar 27 18:21:00 1997
From: michael at memra.com (Michael Dillon)
Date: Thu, 27 Mar 1997 10:21:00 -0800 (PST)
Subject: boardwatch magazine -- hotbed of spammers?  irresponsible jerks?
In-Reply-To: <199703271737.JAA14917@wisdom.home.vix.com>
Message-ID: <Pine.BSI.3.93.970327101944.4620T-100000@sidhe.memra.com>

On Thu, 27 Mar 1997, Paul A Vixie wrote:

> miserable scumsucking morons from hell?
> completely unclear on the concept?
> unaware of what NANOG is?
> unaware of what the Internet is?

>  David Dixon                                                                               
>  Circulation Manager                                                                       
   ^^^^^^^^^^^^^^^^^^^
I think this says it all. You forgot one choice

  all of the above  (X)


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From jstewart at isi.edu  Thu Mar 27 18:32:38 1997
From: jstewart at isi.edu (John W. Stewart III)
Date: Thu, 27 Mar 1997 13:32:38 EST
Subject: BGP4 COMMUNITY attribute 
In-Reply-To: Your message of "Thu, 27 Mar 1997 11:24:33 MST."
             <c=US%a=_%p=TELUS%l=TAC_NT1-970327182433Z-4334@tac-nt1.tac.net> 
Message-ID: <199703271832.AA14587@metro.isi.edu>


many of your questions are for MCI and not nanog

 > In the preparation for upcoming 2nd (multihomed) connection to Internet
 > I am looking into
 > COMMUNITY attribute of BGP4 as a way (in conjunction with my own
 > LOCAL_PREF) of load balancing
 > traffic between my two internet links (both T3). After reading CISCO
 > documentation I am still not
 > clear on some issues:
 > 
 > 1. Is COMMUNITY a transitive attribute only between me and my immediate
 > upstream supplier or 
 > is it being propagated further into Internet (so I can influence how
 > somebody ,say, 5 AS hops 
 > away from me sees my routes) ?

the attribute is defined as transitive (i.e., once associated
with a route it *stays* associated with the route).  however, in
practice, many providers are configured to not send communities
to other providers

 > 2. If COMMUNITY propagates into big I, and I set COMMUNITY to 3561:70
 > (for MCI to set 
 > LOCAL_PREF on my routes to 70) and my next hop supplier sets COMMUNITY
 > of my routes to  
 > 3561:80, what happens ? what MCI is going to do ?

is one of your immediate upstream provider's MCI?  if so, then
you would tag routes with 3561:70 and MCI would immediately see
and react to that.  however, you imply that your "next hop
supplier" isn't MCI, which makes it a bit odd for you to be
sending communities for MCI, but is doable if your "next hop
supplier" agrees to carry your communities all the way to MCI

 > 3. Is COMMUNITY a CISCO only or is it part of RFC ? Has any other router
 > vendor implemented
 > this parameter ?

rfc1997.  i think there's a GateD with communities

/jws

 > 4. Which major Internet providers have COMMUNITY/LOCAL_PREF implemented
 >  (I am aware of MCI and Sprint) ?
 > 
 > 5. Your experiences, comments, suggestions .....
 > 
 > 
 > Thanks in advance, Walter
 > 
 > 
 > 
 > Walter Towbin
 > Telus Advanced Communications
 > phone: 403-543-2032, fax: 403-543-2030, cell: 403-620-0019
 > walter.towbin at telus.com
 > 




From allan at bellsouth.net  Thu Mar 27 18:57:26 1997
From: allan at bellsouth.net (Allan Chong)
Date: Thu, 27 Mar 1997 10:57:26 -0800
Subject: boardwatch magazine -- hotbed of spammers?  irresponsible jerks?
References: <199703271737.JAA14917@wisdom.home.vix.com>
Message-ID: <333AC316.641E@bellsouth.net>

Paul A Vixie wrote:
> 

They asked me whether I wanted their free ISP directory.  I 
said sure.  They used this as an excuse to send me a free
subscription which has been coming ever since.  Good way to
pump up subscriptions for those advertisers and yet still
get most of their subscriber base to pay.  I've also noticed
that those free magazines ALWAYS (4 or 5 times now) conveniently
lose your unsubscribe letter.



allan
PS.  Is the f.root located in La Honda or Woodside?  I noticed
that 415 747 number.




From pknight at BayNetworks.COM  Thu Mar 27 19:03:15 1997
From: pknight at BayNetworks.COM (Paul Knight)
Date: Thu, 27 Mar 1997 14:03:15 -0500
Subject: BGP4 COMMUNITY attribute
References: <c=US%a=_%p=TELUS%l=TAC_NT1-970327182433Z-4334@tac-nt1.tac.net>
Message-ID: <333AC473.7D55368C@BayNetworks.com>

Walter Towbin wrote:
> 
> In the preparation for upcoming 2nd (multihomed) connection to Internet
> I am looking into
> COMMUNITY attribute of BGP4 as a way (in conjunction with my own
> LOCAL_PREF) of load balancing
> traffic between my two internet links (both T3). After reading CISCO
> documentation I am still not
> clear on some issues:
> 
> 1. Is COMMUNITY a transitive attribute only between me and my immediate
> upstream supplier or
> is it being propagated further into Internet (so I can influence how
> somebody ,say, 5 AS hops
> away from me sees my routes) ?

It is propagated further into the Internet.  Note that only BGP routers
which are configured with specific policies will pay any attention to
any communities you set, other than the well-known communities.  Unless
an ISP decides to set up its policies to handle communities, you can't
use communities to influence how it sees your routes.
> 
> 2. If COMMUNITY propagates into big I, and I set COMMUNITY to 3561:70
> (for MCI to set
> LOCAL_PREF on my routes to 70) and my next hop supplier sets COMMUNITY
> of my routes to
> 3561:80, what happens ? what MCI is going to do ?

MCI will receive and act on 3561:80
> 
> 3. Is COMMUNITY a CISCO only or is it part of RFC ? Has any other router
> vendor implemented
> this parameter ?

Bay Networks also supports Communities, including the well-known
communities:
      NO_EXPORT (0xFFFFFF01)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised outside a BGP confederation
         boundary (a stand-alone autonomous system that is not part of a
         confederation should be considered a confederation itself).
      NO_ADVERTISE (0xFFFFFF02)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to other BGP peers.
      NO_EXPORT_SUBCONFED (0xFFFFFF03)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to external BGP peers (this

> 
> 4. Which major Internet providers have COMMUNITY/LOCAL_PREF implemented
>  (I am aware of MCI and Sprint) ?

> 
> 5. Your experiences, comments, suggestions .....
> 
> Thanks in advance, Walter
> 
> Walter Towbin
> Telus Advanced Communications
> phone: 403-543-2032, fax: 403-543-2030, cell: 403-620-0019
> walter.towbin at telus.com

-- 
Paul Knight 			     mailto:pknight at BayNetworks.com
IP Engineering, Systems Test	     Office: (508) 916-7087
Bay Networks, Inc.	M/S BL2-02	Lab: (508) 670-8888, x-65404
2 Federal St., Billerica, MA 01821	Fax: (508) 670-4004




From pdonner at cisco.com  Thu Mar 27 22:20:09 1997
From: pdonner at cisco.com (Paul G. Donner)
Date: Thu, 27 Mar 1997 14:20:09 -0800
Subject: BGP4 COMMUNITY attribute 
Message-ID: <3.0.32.19970327141852.00ff39f4@lint.cisco.com>

Actually, along this vein (granted, this may not be the place but since
the subject came up)..

What is the general concensus about passing communities in the "community"?

See in-line below...

At 01:32 PM 3/27/97 EST, John W. Stewart III wrote:
>
>many of your questions are for MCI and not nanog
>
> > In the preparation for upcoming 2nd (multihomed) connection to Internet
> > I am looking into
> > COMMUNITY attribute of BGP4 as a way (in conjunction with my own
> > LOCAL_PREF) of load balancing
> > traffic between my two internet links (both T3). After reading CISCO
> > documentation I am still not
> > clear on some issues:
> > 
> > 1. Is COMMUNITY a transitive attribute only between me and my immediate
> > upstream supplier or 
> > is it being propagated further into Internet (so I can influence how
> > somebody ,say, 5 AS hops 
> > away from me sees my routes) ?
>
>the attribute is defined as transitive (i.e., once associated
>with a route it *stays* associated with the route).  however, in

Unless an intermediate provider deliberately changes the value, as
opposed to appending to it.

>practice, many providers are configured to not send communities
>to other providers

Is this a conscious decision or just that they have not turned on 
"send-community"?

Donner

>
> > 2. If COMMUNITY propagates into big I, and I set COMMUNITY to 3561:70
> > (for MCI to set 
> > LOCAL_PREF on my routes to 70) and my next hop supplier sets COMMUNITY
> > of my routes to  
> > 3561:80, what happens ? what MCI is going to do ?
>
>is one of your immediate upstream provider's MCI?  if so, then
>you would tag routes with 3561:70 and MCI would immediately see
>and react to that.  however, you imply that your "next hop
>supplier" isn't MCI, which makes it a bit odd for you to be
>sending communities for MCI, but is doable if your "next hop
>supplier" agrees to carry your communities all the way to MCI
>
> > 3. Is COMMUNITY a CISCO only or is it part of RFC ? Has any other router
> > vendor implemented
> > this parameter ?
>
>rfc1997.  i think there's a GateD with communities
>
>/jws
>
> > 4. Which major Internet providers have COMMUNITY/LOCAL_PREF implemented
> >  (I am aware of MCI and Sprint) ?
> > 
> > 5. Your experiences, comments, suggestions .....
> > 
> > 
> > Thanks in advance, Walter
> > 
> > 
> > 
> > Walter Towbin
> > Telus Advanced Communications
> > phone: 403-543-2032, fax: 403-543-2030, cell: 403-620-0019
> > walter.towbin at telus.com
> > 
>
>




From algold at lambda.lncc.br  Thu Mar 27 19:26:22 1997
From: algold at lambda.lncc.br (Alexandre Leib Grojsgold)
Date: Thu, 27 Mar 1997 16:26:22 -0300 (GRNLNDST)
Subject: BGP4 COMMUNITY attribute
In-Reply-To: <333AC473.7D55368C@BayNetworks.com> from "Paul Knight" at Mar 27, 97 02:03:15 pm
Message-ID: <9703271926.AA19289@lambda.lncc.br>

Regardless of the COMMUNITY attribute being pushed further or not, one
must keep in mind that an AS will only advertise to other AS's  the route it
has selected itself as "best route".

It means that one's ability to influence routing decisions of ASes "far
away" is minimal, not to say =zero.

Alexandre.




From jstewart at isi.edu  Thu Mar 27 19:34:59 1997
From: jstewart at isi.edu (John W. Stewart III)
Date: Thu, 27 Mar 1997 14:34:59 EST
Subject: BGP4 COMMUNITY attribute 
In-Reply-To: Your message of "Thu, 27 Mar 1997 14:20:09 PST."
             <3.0.32.19970327141852.00ff39f4@lint.cisco.com> 
Message-ID: <199703271934.AA15439@metro.isi.edu>


 > What is the general concensus about passing communities in the "community"?

i could see a reason for a subscriber passing communities
through a mid-level provider to a top-level provider.  but i'm
not sure if it makes sense [yet] for top-levels to pass
communities between themselves

 > > > 1. Is COMMUNITY a transitive attribute only between me and my immediate
 > > > upstream supplier or 
 > > > is it being propagated further into Internet (so I can influence how
 > > > somebody ,say, 5 AS hops 
 > > > away from me sees my routes) ?
 > >
 > >the attribute is defined as transitive (i.e., once associated
 > >with a route it *stays* associated with the route).  however, in
 > 
 > Unless an intermediate provider deliberately changes the value, as
 > opposed to appending to it.

these values aren't an end-to-end thing .. it's simply a
way for providers to more easily facilitate routing policies.
your comment implies somebody being a bad guy...

 > >practice, many providers are configured to not send communities
 > >to other providers
 > 
 > Is this a conscious decision or just that they have not turned on 
 > "send-community"?

both.  they don't turn on send-community so that others don't
see their communities.  maybe they have some whiz-bang features
that make configing their neat really cool, and they don't want
others to see their communities because it might imply a way for
others to do the same thing without the same amount of work

/jws




From jgs at ieng.com  Thu Mar 27 20:10:52 1997
From: jgs at ieng.com (John Scudder)
Date: Thu, 27 Mar 1997 15:10:52 -0500 (EST)
Subject: BGP4 COMMUNITY attribute
In-Reply-To: <199703271832.AA14587@metro.isi.edu> from "John W. Stewart III" at Mar 27, 97 01:32:38 pm
Message-ID: <199703272010.PAA14950@ieng.com>

John W. Stewart II writes:
> rfc1997.  i think there's a GateD with communities

Yup.

--John




From pdonner at cisco.com  Thu Mar 27 23:23:09 1997
From: pdonner at cisco.com (Paul G. Donner)
Date: Thu, 27 Mar 1997 15:23:09 -0800
Subject: BGP4 COMMUNITY attribute 
Message-ID: <3.0.32.19970327150653.00ef7970@lint.cisco.com>

At 02:34 PM 3/27/97 EST, John W. Stewart III wrote:
>
> > What is the general concensus about passing communities in the
"community"?
>
>i could see a reason for a subscriber passing communities
>through a mid-level provider to a top-level provider.  but i'm
>not sure if it makes sense [yet] for top-levels to pass
>communities between themselves
>
> > > > 1. Is COMMUNITY a transitive attribute only between me and my
immediate
> > > > upstream supplier or 
> > > > is it being propagated further into Internet (so I can influence how
> > > > somebody ,say, 5 AS hops 
> > > > away from me sees my routes) ?
> > >
> > >the attribute is defined as transitive (i.e., once associated
> > >with a route it *stays* associated with the route).  however, in
> > 
> > Unless an intermediate provider deliberately changes the value, as
> > opposed to appending to it.
>
>these values aren't an end-to-end thing .. it's simply a
>way for providers to more easily facilitate routing policies.
>your comment implies somebody being a bad guy...

Actually, I hadn't necessarily meant to imply "being a bad guy".  
The comment was meant to show that the "intermediate" ISP has this 
kind of control over the attribute.  In any case, if the decision 
about whether or not to pass on an attribute (or to modify it) was 
part of the intermediate ISP's policy, whether or not he/she is a 
bad guy would depend on varying points of view.

Donner

>
> > >practice, many providers are configured to not send communities
> > >to other providers
> > 
> > Is this a conscious decision or just that they have not turned on 
> > "send-community"?
>
>both.  they don't turn on send-community so that others don't
>see their communities.  maybe they have some whiz-bang features
>that make configing their neat really cool, and they don't want
>others to see their communities because it might imply a way for
>others to do the same thing without the same amount of work
>
>/jws
>
>




From jstewart at isi.edu  Thu Mar 27 20:43:28 1997
From: jstewart at isi.edu (John W. Stewart III)
Date: Thu, 27 Mar 1997 15:43:28 EST
Subject: BGP4 COMMUNITY attribute 
In-Reply-To: Your message of "Thu, 27 Mar 1997 15:23:09 PST."
             <3.0.32.19970327150653.00ef7970@lint.cisco.com> 
Message-ID: <199703272043.AA16259@metro.isi.edu>


 > > > >the attribute is defined as transitive (i.e., once associated
 > > > >with a route it *stays* associated with the route).  however, in
 > > > 
 > > > Unless an intermediate provider deliberately changes the value, as
 > > > opposed to appending to it.
 > >
 > >these values aren't an end-to-end thing .. it's simply a
 > >way for providers to more easily facilitate routing policies.
 > >your comment implies somebody being a bad guy...
 > 
 > Actually, I hadn't necessarily meant to imply "being a bad guy".  
 > The comment was meant to show that the "intermediate" ISP has this 
 > kind of control over the attribute.  In any case, if the decision 
 > about whether or not to pass on an attribute (or to modify it) was 
 > part of the intermediate ISP's policy, whether or not he/she is a 
 > bad guy would depend on varying points of view.

to date communities haven't been an end-to-end thing.  they
have mostly had significance only to adjacent ASs.  i do know
of a small number of exceptions where a subscriber sets the
communities, they're carried through a mid-level provider to
a top-level provider, at which point the top-leve. provider
reacts in some way (e.g., setting local-pref to a certain
value)

to me the practical bottom line seems to be that communities
are being used to ease the configuration work to achieve
certain routing policies, and since an AS has complete
autonomy over its routing policies, that AS should have the
freedom to keep, add to, or stomp on communities that it
hears from others.  it's possible that in the future we
might have an end-to-end application of communities, but i
don't know of one yet, so i'm loathe to mandate anything
about how far communities are carried and how much they're
kept intact

/jws




From randy at psg.com  Thu Mar 27 22:36:00 1997
From: randy at psg.com (Randy Bush)
Date: Thu, 27 Mar 97 14:36 PST
Subject: BGP4 COMMUNITY attribute 
References: <3.0.32.19970327141852.00ff39f4@lint.cisco.com>
	<199703271934.AA15439@metro.isi.edu>
Message-ID: <m0wANml-000IY4C@roam.psg.com>

> i could see a reason for a subscriber passing communities
> through a mid-level provider to a top-level provider.  but i'm
> not sure if it makes sense [yet] for top-levels to pass
> communities between themselves

See my NANOG/SF presentation.

randy




From matt at netmeg.net  Fri Mar 28 00:10:00 1997
From: matt at netmeg.net (Matt Magri)
Date: Thu, 27 Mar 97 19:10 EST
Subject: boardwatch magazine -- hotbed of spammers? irresponsible jerks?
Message-ID: <m0wAPF8-0001UqC@netmeg.net>

Tim Gibson <tim at taggnet.skyscape.net> wrote:
>         I pick option 5, after the full issue of BoardWatch dedicated to 
> anti-spam. [ ... ]

Would that be the Dec 1996 issue, when they helpfully reviewed the
spamming packages currently available to determine which was best?

Favorite excerpt...
: The one tool that makes this program worth the price is its built in
: ability to scour any newsgroup for e-mail addresses in the headers or
: the bodies of postings. This allows for some very targeted mailings, as
: you can also filter out specific domain types and include key words
: from the postings to further refine your search so that only those who
: fit your marketing letter are extracted.

The company who makes the "winning package" even includes the review on
their website and puts a quote from it in their own spam. Quite the
anti-spam issue, alright.

Matt




From chris at nap.net  Fri Mar 28 19:50:40 1997
From: chris at nap.net (Chris A. Icide)
Date: Fri, 28 Mar 1997 13:50:40 -0600
Subject: Ascend/Netstar GRF 400
Message-ID: <01BC3B7F.06850EC0@Mallard.nap.net>

Is anyone successfuly using one of these?  I've got one in the labs
here, and have found some interesting problems.  Ascend engineers
are hot on the problems, but I was wondering if anyone else has any
experience.

Our current problems seem to be related to buffer overruns on the 
ATM/Q card.

Chris





From tbates at cisco.com  Fri Mar 28 20:00:02 1997
From: tbates at cisco.com (Tony Bates)
Date: Fri, 28 Mar 1997 12:00:02 -0800
Subject: The Cidr Report
Message-ID: <199703282000.MAA28766@lovefm.cisco.com>


This is an auto-generated mail on Fri Mar 28 12:00:00 PST 1997
It is not checked before it leaves my workstation.  However, hopefully 
you will find this report interesting and will take the time to look 
through this to see if you can improve the amount of aggregation you 
perform.

The report is split into sections:

   0) General Status
   
      List the route table history for the last week, list any possibly
      bogus routes seen and give some status on ASes.

   1) Gains by aggregating at the origin AS level

      This lists the "Top 30" players who if they decided to aggregate
      their announced classful prefixes at the origin AS level could 
      make a significant difference in the reduction of the current 
      size of the Internet routing table. This calculation does not 
      take into account the inclusion of holes when forming an aggregate
      so it is possible even larger reduction should be possible.

   2) Weekly Delta

      A summary of the last weeks changes in terms of withdrawn and
      added routes. Please note that this is only a snapshot but does 
      give some indication of ASes participating in CIDR. Clearly,
      it is generally a good thing to see a large amont of withdrawls.

   3) Interesting aggregates

      Interesting here means not an aggregate made as a set of 
      classful routes.      

Thanks to xara.net for giving me access to their routing tables once a
day. 

Please send any comments about this report directly to me.

Check http://www.employees.org/~tbates/cidr-report.html for a daily
update of this report.



------------------------------------------------------------------------------

                        CIDR REPORT for 28Mar97


0) General Status

Table History
-------------

Date	Prefixes
210397	44783
220397	44717
230397	44448
240397	44278
250397	44615
260397	44748
270397	44655
280397	44843

Check http://www.employees.org/~tbates/cidr.plot.html for a plot
of the table history.


Possible Bogus Routes
---------------------


AS Summary
----------

Number of ASes in routing system:                 2169

Number of ASes announcing only one prefix:         918 (452 cidr, 466 classful)

Largest number of  cidr routes:                    509 announced by AS3561
Largest number of classful routes:                1534 announced by  AS174



1) Gains by aggregating at the origin AS level

 --- 28Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1534     1063      471   30.7%   Performance Systems International
AS2493       841      520      321   38.2%   i*internet
AS3602       629      341      288   45.8%   Sprint Canada Inc.
AS1221      1380     1123      257   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1126      936      190   16.9%   BBN Planet backbone
AS1691       308      171      137   44.5%   BCTEL
AS2048       256      122      134   52.3%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       120       20      100   83.3%   SIGNET
AS2871       179       97       82   45.8%   Internet Services GmbH & Co
AS813        289      210       79   27.3%   UUNET Canada (ASN-UUNETCA-AS1)
AS1967       152       74       78   51.3%   Middle East Technical University 
AS7195       119       45       74   62.2%   INTERRED
AS2704       262      190       72   27.5%   HOOKUP-NET-A
AS855        133       63       70   52.6%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        889      827       62    7.0%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS816        227      175       52   22.9%   UUNETCA-AS4
AS549        216      164       52   24.1%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS4454        67       20       47   70.1%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       184      137       47   25.5%   NEWNET
AS3491       137       90       47   34.3%   CAIS-ASN
AS3561       900      854       46    5.1%   MCI
AS97         185      140       45   24.3%   JvNCnet
AS719        512      467       45    8.8%   LANLINK autonomous system
AS3563       133       88       45   33.8%   Pilot Network Services, Inc.

 --- 27Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1531     1056      475   31.0%   Performance Systems International
AS2493       843      521      322   38.2%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1385     1127      258   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1125      935      190   16.9%   BBN Planet backbone
AS2048       257      123      134   52.1%   State of Louisiana/Office of Tele
AS1691       303      170      133   43.9%   BCTEL
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       120       20      100   83.3%   SIGNET
AS2871       179       97       82   45.8%   Internet Services GmbH & Co
AS813        294      215       79   26.9%   UUNET Canada (ASN-UUNETCA-AS1)
AS7195       121       43       78   64.5%   INTERRED
AS855        133       63       70   52.6%   NBTel
AS2704       260      191       69   26.5%   HOOKUP-NET-A
AS2386       187      121       66   35.3%   INS-AS
AS701        879      821       58    6.6%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS549        217      165       52   24.0%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS816        221      171       50   22.6%   UUNETCA-AS4
AS4454        66       19       47   71.2%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       184      137       47   25.5%   NEWNET
AS3491       135       89       46   34.1%   CAIS-ASN
AS97         185      140       45   24.3%   JvNCnet
AS719        512      467       45    8.8%   LANLINK autonomous system
AS3561       892      847       45    5.0%   MCI
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS225         75       31       44   58.7%   University of Virginia (VIRnet)

 --- 26Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1519     1056      463   30.5%   Performance Systems International
AS2493       841      520      321   38.2%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1384     1125      259   18.7%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1073      891      182   17.0%   BBN Planet backbone
AS1691       309      172      137   44.3%   BCTEL
AS2048       257      123      134   52.1%   State of Louisiana/Office of Tele
AS3804       188       87      101   53.7%   Bell Blobal Solutions
AS3819       121       23       98   81.0%   SIGNET
AS2871       179       97       82   45.8%   Internet Services GmbH & Co
AS813        292      214       78   26.7%   UUNET Canada (ASN-UUNETCA-AS1)
AS1967       152       74       78   51.3%   Middle East Technical University 
AS7195       120       46       74   61.7%   INTERRED
AS2704       259      187       72   27.8%   HOOKUP-NET-A
AS855        133       63       70   52.6%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        876      815       61    7.0%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS816        220      170       50   22.7%   UUNETCA-AS4
AS4454        66       19       47   71.2%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       182      136       46   25.3%   NEWNET
AS97         186      141       45   24.2%   JvNCnet
AS719        511      466       45    8.8%   LANLINK autonomous system
AS3561       895      850       45    5.0%   MCI
AS3491       133       88       45   33.8%   CAIS-ASN
AS3749        72       28       44   61.1%   Tennessee Board of Regents

 --- 25Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1528     1055      473   31.0%   Performance Systems International
AS2493       842      520      322   38.2%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1378     1120      258   18.7%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1071      892      179   16.7%   BBN Planet backbone
AS1691       309      172      137   44.3%   BCTEL
AS2048       257      123      134   52.1%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       180       96       84   46.7%   Internet Services GmbH & Co
AS813        293      214       79   27.0%   UUNET Canada (ASN-UUNETCA-AS1)
AS7195       121       43       78   64.5%   INTERRED
AS2704       259      188       71   27.4%   HOOKUP-NET-A
AS855        131       62       69   52.7%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        888      830       58    6.5%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS549        217      165       52   24.0%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS816        218      170       48   22.0%   UUNETCA-AS4
AS4454        66       19       47   71.2%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       185      138       47   25.4%   NEWNET
AS3491       134       89       45   33.6%   CAIS-ASN
AS719        509      465       44    8.6%   LANLINK autonomous system
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS3561       887      843       44    5.0%   MCI
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS4175       470      427       43    9.1%   CONNECT-NCM

 --- 24Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1503     1051      452   30.1%   Performance Systems International
AS2493       844      521      323   38.3%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1381     1124      257   18.6%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1074      893      181   16.9%   BBN Planet backbone
AS1691       309      172      137   44.3%   BCTEL
AS2048       258      122      136   52.7%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       180       96       84   46.7%   Internet Services GmbH & Co
AS813        291      211       80   27.5%   UUNET Canada (ASN-UUNETCA-AS1)
AS7195       119       45       74   62.2%   INTERRED
AS2704       261      189       72   27.6%   HOOKUP-NET-A
AS855        131       63       68   51.9%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        874      815       59    6.8%   Alternet
AS2711       110       56       54   49.1%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS816        216      168       48   22.2%   UUNETCA-AS4
AS3799        72       25       47   65.3%   IDS
AS97         185      140       45   24.3%   JvNCnet
AS4454        62       17       45   72.6%   OIR Telecommunications, State of 
AS3561       901      856       45    5.0%   MCI
AS3491       131       86       45   34.4%   CAIS-ASN
AS3749        71       27       44   62.0%   Tennessee Board of Regents
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS6181        50        7       43   86.0%   FUSE-NET
AS4175       469      426       43    9.2%   CONNECT-NCM

 --- 23Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1521     1053      468   30.8%   Performance Systems International
AS2493       845      522      323   38.2%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1288     1054      234   18.2%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1075      894      181   16.8%   BBN Planet backbone
AS1691       309      172      137   44.3%   BCTEL
AS2048       258      122      136   52.7%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       180       96       84   46.7%   Internet Services GmbH & Co
AS813        288      208       80   27.8%   UUNET Canada (ASN-UUNETCA-AS1)
AS7195       121       43       78   64.5%   INTERRED
AS1967       150       72       78   52.0%   Middle East Technical University 
AS2704       259      188       71   27.4%   HOOKUP-NET-A
AS855        132       63       69   52.3%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS701        865      813       52    6.0%   Alternet
AS3397        75       23       52   69.3%   EMI-AS
AS3799        72       25       47   65.3%   IDS
AS816        217      171       46   21.2%   UUNETCA-AS4
AS3739       184      138       46   25.0%   NEWNET
AS4454        61       16       45   73.8%   OIR Telecommunications, State of 
AS3561       898      853       45    5.0%   MCI
AS3491       132       87       45   34.1%   CAIS-ASN
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS6181        50        7       43   86.0%   FUSE-NET

 --- 22Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1532     1062      470   30.7%   Performance Systems International
AS2493       844      521      323   38.3%   i*internet
AS3602       626      338      288   46.0%   Sprint Canada Inc.
AS1221      1378     1116      262   19.0%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1060      895      165   15.6%   BBN Planet backbone
AS1691       309      172      137   44.3%   BCTEL
AS2048       258      122      136   52.7%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       180       96       84   46.7%   Internet Services GmbH & Co
AS813        290      211       79   27.2%   UUNET Canada (ASN-UUNETCA-AS1)
AS1967       150       72       78   52.0%   Middle East Technical University 
AS7195       119       46       73   61.3%   INTERRED
AS2704       260      189       71   27.3%   HOOKUP-NET-A
AS2386       187      121       66   35.3%   INS-AS
AS855        123       61       62   50.4%   NBTel
AS701        884      822       62    7.0%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        73       21       52   71.2%   EMI-AS
AS816        217      169       48   22.1%   UUNETCA-AS4
AS97         188      141       47   25.0%   JvNCnet
AS4454        65       18       47   72.3%   OIR Telecommunications, State of 
AS3799        72       25       47   65.3%   IDS
AS3739       183      137       46   25.1%   NEWNET
AS3491       132       87       45   34.1%   CAIS-ASN
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS3561       899      855       44    4.9%   MCI
AS225         75       31       44   58.7%   University of Virginia (VIRnet)

 --- 21Mar97 ---
ASnum    NetsNow NetsCIDR  NetGain  % Gain   Description

AS174       1541     1065      476   30.9%   Performance Systems International
AS2493       843      520      323   38.3%   i*internet
AS3602       635      339      296   46.6%   Sprint Canada Inc.
AS1221      1378     1116      262   19.0%   AARNET-AS
AS839        240       40      200   83.3%   North West Territories Regional N
AS1         1103      912      191   17.3%   BBN Planet backbone
AS1691       308      171      137   44.5%   BCTEL
AS2048       258      122      136   52.7%   State of Louisiana/Office of Tele
AS3804       187       86      101   54.0%   Bell Blobal Solutions
AS3819       118       20       98   83.1%   SIGNET
AS2871       179       95       84   46.9%   Internet Services GmbH & Co
AS813        303      220       83   27.4%   UUNET Canada (ASN-UUNETCA-AS1)
AS1967       150       72       78   52.0%   Middle East Technical University 
AS7195       119       46       73   61.3%   INTERRED
AS2704       264      191       73   27.7%   HOOKUP-NET-A
AS855        132       62       70   53.0%   NBTel
AS2386       187      121       66   35.3%   INS-AS
AS701        890      827       63    7.1%   Alternet
AS2711       109       55       54   49.5%   SUNBELT-AS
AS549        218      165       53   24.3%   ONet Backbone
AS3397        75       23       52   69.3%   EMI-AS
AS3799        72       25       47   65.3%   IDS
AS3739       185      138       47   25.4%   NEWNET
AS3491       132       87       45   34.1%   CAIS-ASN
AS816        200      156       44   22.0%   UUNETCA-AS4
AS3749        72       28       44   61.1%   Tennessee Board of Regents
AS3561       900      856       44    4.9%   MCI
AS225         75       31       44   58.7%   University of Virginia (VIRnet)
AS97         187      144       43   23.0%   JvNCnet
AS4175       470      427       43    9.1%   CONNECT-NCM




2) Weekly Delta

This a daily snapshot of changes in classful routes being withdrawn and added.
the deltas are calculated over a rolling 7 day period. Please bear in mind this
is purely a "snapshot" and a large flucuation could be caused by a connectivity
problem for example. However, this does give some indication of service
providers that are moving to classless routing.


Top 20 Withdrawn Classful Routes from 21Mar97 to 28Mar97
	 -49 AS4175 CONNECT-NCM
	 -40  AS681 KAWAIHIKO-1
	 -22 AS1852 UCNet
	 -21 AS6315 XMISSION
	 -20 AS3252 "Relcom-Ukraine" Ltd. TS network 
	 -18 AS2548 DIGEX-AS
	 -14 AS4780 APNIC-AS-BLOCK
	 -13 AS1290 PSINet UK Ltd.
	 -12 AS1274 GMD
	 -11 AS2856 BTnet UK Regional network
	 -10 AS3462 Data communications Institute (Hi
	  -8 AS5486 Euronet Digital Communications
	  -7 AS1328 ANS Houston - DNSS 67
	  -6 AS3602 Sprint Canada Inc.
	  -5 AS1323 ANS Chicago - DNSS 27
	  -4 AS1791 SprintLink Fort Worth TX
	  -3 AS6805 mediaWays Autonomous System
	  -2 AS5481 SYSTEMY
	  -1 AS3354 THENET-AS-1

Top 20 Added Classful Routes from 21Mar97 to 28Mar97
	  34 AS3563 Pilot Network Services, Inc.
	  31 AS2752 THOMSONCA-AS
	  27  AS816 UUNETCA-AS4
	  23 AS3976 NURI-ASN
	  18 AS3388 UNM-AS
	  15 AS5650 Electric Lightwave Inc. and XMiss
	  13 AS4999 SPRINTIPDIAL
	  12  AS719 LANLINK autonomous system
	   9 AS1325 ANS Cleveland - DNSS 43
	   8 AS2500 WIDE Internet AS
	   7 AS1275 DFN-IP service and DFN customer n
	   6 AS2707 WEC
	   5 AS3267 RUNNet
	   4 AS6203 ISDN-Net Inc.
	   3 AS1270 EUnet Germany
	   2 AS1333 ANS Atlanta - DNSS 107
	   1 AS8022 WTNET

This a daily snapshot of changes in classles routes being withdrawn and added.


Top 20 Withdrawn Classles Routes from 21Mar97 to 28Mar97
	 -32 AS4780 INSTITUTE FOR INFORMATION IDUSTRY
	 -11 AS2907 SINET
	  -9 AS4175 CONNECT-NCM
	  -7 AS4742 AT&T EasyLink Services Australia 
	  -6 AS3561 MCI
	  -5 AS5639 Telecommunications Services of Tr
	  -4 AS2548 DIGEX-AS
	  -3 AS6912 Hayes Computer Systems, Inc.
	  -2 AS5486 Euronet Digital Communications
	  -1 AS1333 ANS Atlanta - DNSS 107

Top 20 Added Classles Routes from 21Mar97 to 28Mar97
	  17 AS2056 AOL-AS
	  14 AS3976 NURI-ASN
	  11   AS97 JvNCnet
	  10 AS4618 Internet Thailand Service Center,
	   9 AS3559 KORNET-3559 Autonomous-system
	   8  AS701 Alternet
	   7 AS4004 Global IP
	   5 AS5650 Electric Lightwave Inc. and XMiss
	   4 AS1275 DFN-IP service and DFN customer n
	   3 AS8041 ATW
	   2 AS5693 InteleNet Communications, Inc.
	   1  AS378 ILAN



3) Interesting aggregates



            List of possibly interesting aggregates
            ---------------------------------------

         Aggregate | Origin | AS Description          | Netname                
-------------------------------------------------------------------------------
     154.11.1.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.2.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.8.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
     154.11.9.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.10.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.11.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.12.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.13.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.16.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.17.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.18.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.19.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.24.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.25.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.26.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.27.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.28.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.32.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.104.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.105.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.108.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.109.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.110.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.111.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.112.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.113.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.114.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.120.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.121.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.122.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.123.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.124.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.126.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.127.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.129.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.130.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
   154.11.136.0/24 | AS8013 | PSINET-CA               | Performance Systems Int
    154.11.33.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.34.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.35.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.36.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.37.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.48.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.50.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.52.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.64.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.65.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.66.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.67.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.96.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.97.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.98.0/24 | AS8013 | PSINET-CA               | *                      
    154.11.99.0/24 | AS8013 | PSINET-CA               | *                      
   154.11.100.0/24 | AS8013 | PSINET-CA               | *                      
   154.11.101.0/24 | AS8013 | PSINET-CA               | *                      
   154.11.102.0/24 | AS8013 | PSINET-CA               | *                      
   154.11.103.0/24 | AS8013 | PSINET-CA               | *                      
     24.130.0.0/18 | AS7757 | CCI-AS2-BLK             | @Home Network (NETBLK-A
   24.131.128.0/18 | AS7756 | CCI-AS2-BLK             | @Home Network (NETBLK-A
   129.231.48.0/21 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.56.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.59.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
   129.231.67.0/24 | AS7435 | ATM-CIN                 | Digital Commnications A
  146.115.132.0/23 | AS7174 | Onward Technologies, In | UltraNet Communications
     24.129.0.0/18 | AS7017 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.131.0.0/18 | AS7016 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.128.0.0/18 | AS7015 | CCI-AS-BLK              | @Home Network (NETBLK-A
     24.113.0.0/19 | AS6997 | Rogers Network Services | @Home Network (NETBLK-A
  192.254.27.16/29 | AS6989 | GTSI                    | GTSI (NET-GTSI27)      
   152.158.84.0/24 | AS6755 | ASN - TURNET            | *                      
   160.81.156.0/24 | AS6718 | Global One Italy        | Sprint International (N
   160.81.252.0/24 | AS6718 | Global One Italy        | Sprint International (N
      24.96.0.0/18 | AS6541 | GTE Intelligent Network | @Home Network (NETBLK-A
   163.247.83.0/27 | AS6471 | ENTELCHILE              | Oficina de Estudios y P
     24.112.0.0/19 | AS6463 | Rogers Network Services | @Home Network (NETBLK-A
  168.234.128.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  168.234.135.0/24 | AS6458 | EMPRESSA GUATEMALTECA D | Universidad del Valle d
  206.152.59.32/28 | AS6362 | VAULTLINE-AS            | Globetrotter Software (
      24.64.0.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
     24.64.32.0/19 | AS6327 | Shaw Fiberlink Ltd.     | @Home Network (NETBLK-A
   149.236.92.0/24 | AS6292 | FCI                     | *                      
       12.1.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.5.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.8.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
       12.9.0.0/17 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
      12.0.64.0/18 | AS6269 | AT&T NWCS backbone netw | AT&T ITS (NET-ATT)     
    134.129.0.0/18 | AS6263 | NDIN                    | North Dakota State Univ
   134.129.64.0/18 | AS6263 | NDIN                    | North Dakota State Univ
  134.129.128.0/17 | AS6263 | NDIN                    | North Dakota State Univ
     165.88.1.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.10.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.11.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.15.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.17.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.19.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.23.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.24.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.27.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.28.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.29.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.30.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.31.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.32.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.33.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.34.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.35.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.36.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.37.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.38.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.39.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.40.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.41.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.42.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.43.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.44.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.45.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.46.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.47.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.49.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.50.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
    165.88.51.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.100.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.126.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.128.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.129.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.130.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.131.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.132.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.133.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.134.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.135.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.151.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.152.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.154.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.155.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.158.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.159.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.160.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.163.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.166.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.168.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.175.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.177.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.179.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.182.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.190.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.195.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.200.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.206.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.207.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.208.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.209.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.212.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.217.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.219.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.230.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.235.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.236.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.240.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.242.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.251.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.252.0/24 | AS6254 | EGGINC                  | EG&G, Inc./ Corporate H
   165.88.101.0/24 | AS6254 | EGGINC                  | *                      
   165.88.102.0/24 | AS6254 | EGGINC                  | *                      
   165.88.104.0/24 | AS6254 | EGGINC                  | *                      
   165.88.105.0/24 | AS6254 | EGGINC                  | *                      
   165.88.106.0/24 | AS6254 | EGGINC                  | *                      
   165.88.107.0/24 | AS6254 | EGGINC                  | *                      
   165.88.108.0/24 | AS6254 | EGGINC                  | *                      
   165.88.109.0/24 | AS6254 | EGGINC                  | *                      
   165.88.110.0/24 | AS6254 | EGGINC                  | *                      
   165.88.111.0/24 | AS6254 | EGGINC                  | *                      
   165.88.112.0/24 | AS6254 | EGGINC                  | *                      
   165.88.113.0/24 | AS6254 | EGGINC                  | *                      
   165.88.114.0/24 | AS6254 | EGGINC                  | *                      
   165.88.115.0/24 | AS6254 | EGGINC                  | *                      
   165.88.116.0/24 | AS6254 | EGGINC                  | *                      
   165.88.117.0/24 | AS6254 | EGGINC                  | *                      
   165.88.118.0/24 | AS6254 | EGGINC                  | *                      
   165.88.119.0/24 | AS6254 | EGGINC                  | *                      
   165.88.120.0/24 | AS6254 | EGGINC                  | *                      
   165.88.121.0/24 | AS6254 | EGGINC                  | *                      
   165.88.122.0/24 | AS6254 | EGGINC                  | *                      
   165.88.124.0/24 | AS6254 | EGGINC                  | *                      
   165.88.125.0/24 | AS6254 | EGGINC                  | *                      
   165.88.253.0/24 | AS6254 | EGGINC                  | *                      
   165.88.254.0/24 | AS6254 | EGGINC                  | *                      
   146.115.96.0/22 | AS6249 | UltraNet RI             | UltraNet Communications
  170.147.200.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.208.0/21 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.216.0/22 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
  170.147.220.0/24 | AS6176 | SPRINTLINK10            | Intelcom Group (NET-ICG
       24.0.0.0/14 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.0.0.0/18 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
       24.1.0.0/17 | AS6172 | HOME-NET-1              | @Home Network (NETBLK-A
   169.130.52.0/24 | AS6153 | ASN-SPRN-NYSERNET       | Sprint, Business Servic
  165.113.199.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.211.0/24 | AS6086 | INFOMAGIC               | CRL Network Services, I
  165.113.197.0/24 | AS6086 | INFOMAGIC               | *                      
  165.113.198.0/24 | AS6086 | INFOMAGIC               | *                      
   161.223.90.0/23 | AS6077 | Network Intensive - A D | Indian Health Service (
    148.94.35.0/24 | AS5714 | EDS-WEBS                | EDS Network Naming & Ad
   148.94.210.0/24 | AS5714 | EDS-WEBS                | EDS Network Naming & Ad
   165.247.33.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.36.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.47.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.77.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
   165.247.88.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.101.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.235.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.236.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.237.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.241.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.244.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.247.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.248.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.249.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  165.247.250.0/24 | AS5696 | Primary AS for GoodNet  | Internet Direct, Inc. (
  157.232.100.0/24 | AS5696 | Primary AS for GoodNet  | *                      
    148.160.6.0/24 | AS5556 | Telenordia AB           | Boras Energi (NET-BS-EN
   194.215.65.4/30 | AS5488 | Skynet                  | *                      
  194.151.154.1/32 | AS5484 | BT Netherlands Regional | *                      
    131.114.0.0/17 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
  131.114.128.0/18 | AS5444 | Routing domain of the G | CNR - Istituto CNUCE (N
      57.12.0.0/16 | AS5384 | Etisalat Emirates Inter | SITA-Societe Internatio
  165.215.191.0/24 | AS5090 | CWI-NYD                 | Bell & Howell Company (
      12.64.0.0/12 | AS5074 | ATT-WN-DP               | AT&T ITS (NET-ATT)     
  166.102.163.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.164.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
  166.102.165.0/24 | AS4993 | NET99-4-7-BLK           | ALLTEL Corporation (NET
   160.81.101.0/24 | AS4861 | Global IP / Global Spri | Sprint International (N
   163.44.224.0/23 | AS4853 | Justsystem Corporation  | Justsystem Corporation 
   164.100.80.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce
  164.100.199.0/24 | AS4755 | Videsh Sanchar Nigam Lt | National Informatics Ce
     158.40.3.0/24 | AS4740 | OzEmail ISP             | *                      
     158.40.4.0/24 | AS4740 | OzEmail ISP             | *                      
   146.222.11.0/24 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
  146.222.198.0/23 | AS4637 | Hong Kong Telecom       | Hewlett-Packard Company
     168.29.0.0/17 | AS4565 | HLC Networks            | State of Georgia/Board 
  152.129.186.0/24 | AS4478 | PNET-STL                | *                      
     159.24.7.0/24 | AS4286 | IMCI                    | *                      
   128.193.32.0/19 | AS4201 | Oregon State University | *                      
   128.193.64.0/19 | AS4201 | Oregon State University | *                      
   128.193.96.0/19 | AS4201 | Oregon State University | *                      
  128.193.128.0/19 | AS4201 | Oregon State University | *                      
  128.193.160.0/19 | AS4201 | Oregon State University | *                      
  128.193.192.0/19 | AS4201 | Oregon State University | *                      
  128.193.224.0/19 | AS4201 | Oregon State University | *                      
   206.250.40.0/25 | AS4200 | AGIS (Apex Global Infor | Overland Network (NET-O
   166.102.95.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.97.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   166.102.99.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.101.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.102.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.103.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.105.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.106.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.108.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.109.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.110.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.112.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.113.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.114.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.116.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.117.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.120.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.121.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.122.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.123.0/24 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
  166.102.150.0/23 | AS4200 | AGIS (Apex Global Infor | ALLTEL Corporation (NET
   206.250.27.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  205.199.213.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.203.0/25 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
  206.250.204.0/26 | AS4200 | AGIS (Apex Global Infor | AGIS/Net99 (NETBLK-NET9
    163.124.7.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
  163.124.221.0/24 | AS4058 | Primary AS for LinkAGE  | Lehman Brothers. (NET-S
    156.5.252.0/23 | AS4004 | Global IP               | Unilever (NET-UNILEVER2
      24.72.0.0/18 | AS4004 | Global IP               | @Home Network (NETBLK-A
    147.85.21.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.25.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.39.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.44.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.51.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.54.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
    147.85.98.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
   147.85.115.0/24 | AS3951 | ICONNET                 | Nomura Research Institu
  162.126.135.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.136.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.137.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  162.126.138.0/24 | AS3847 | Genuity Inc             | Arizona Department of E
  161.200.139.0/24 | AS3839 | CHULANET                | Chulalongkorn Universit
  149.112.251.0/24 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.252.0/23 | AS3803 | UltraNet MA             | US Robotics (NET-USR-1)
  149.112.254.0/24 | AS3803 | UltraNet MA             | *                      
   163.249.43.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.53.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.54.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   163.249.57.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.140.0/22 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.160.0/21 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.168.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.169.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
  163.249.170.0/24 | AS3739 | NEWNET                  | Commanding Officer Navy
   148.207.38.0/24 | AS3632 | INFOTEC-RTN             | Consejo Nacional de Cie
     163.12.0.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.5.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.6.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
     163.12.8.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.16.0/22 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.21.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.22.0/23 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.22.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.23.0/24 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.24.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.32.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.160.0/19 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.192.0/21 | AS3576 | PREPnet-EAST            | navy aviation supply of
   163.12.240.0/20 | AS3576 | PREPnet-EAST            | navy aviation supply of
    163.12.64.0/18 | AS3576 | PREPnet-EAST            | *                      
    163.12.64.0/20 | AS3576 | PREPnet-EAST            | *                      
    163.12.81.0/24 | AS3576 | PREPnet-EAST            | *                      
    163.12.82.0/23 | AS3576 | PREPnet-EAST            | *                      
    163.12.84.0/22 | AS3576 | PREPnet-EAST            | *                      
    163.12.88.0/21 | AS3576 | PREPnet-EAST            | *                      
    163.12.96.0/19 | AS3576 | PREPnet-EAST            | *                      
   163.12.128.0/21 | AS3576 | PREPnet-EAST            | *                      
   163.12.136.0/22 | AS3576 | PREPnet-EAST            | *                      
   163.12.144.0/20 | AS3576 | PREPnet-EAST            | *                      
  157.126.209.0/24 | AS3563 | Pilot Network Services, | J.M. Huber Corp. (NET-H
  157.126.212.0/24 | AS3563 | Pilot Network Services, | J.M. Huber Corp. (NET-H
      161.6.0.0/17 | AS3561 | MCI                     | Western Kentucky Univer
    161.6.128.0/17 | AS3561 | MCI                     | Western Kentucky Univer
   148.212.48.0/20 | AS3561 | MCI                     | Universidad Autonoma de
   148.212.64.0/18 | AS3561 | MCI                     | Universidad Autonoma de
  148.212.128.0/17 | AS3561 | MCI                     | Universidad Autonoma de
  165.237.108.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
  165.237.220.0/24 | AS3561 | MCI                     | Time Warner Cable (NET-
    164.103.3.0/24 | AS3561 | MCI                     | Telecommunications Depa
   163.49.131.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.132.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.136.0/22 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.140.0/23 | AS3561 | MCI                     | TDK Corporation (NET-TD
   163.49.142.0/24 | AS3561 | MCI                     | TDK Corporation (NET-TD
     168.14.1.0/24 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.2.0/23 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.4.0/22 | AS3561 | MCI                     | State of Georgia/Board 
     168.14.8.0/21 | AS3561 | MCI                     | State of Georgia/Board 
    168.14.16.0/20 | AS3561 | MCI                     | State of Georgia/Board 
   134.204.14.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  134.204.176.0/24 | AS3561 | MCI                     | Seagate Technology (NET
  155.203.254.0/24 | AS3561 | MCI                     | Safety-Kleen Corporatio
  132.235.204.0/24 | AS3561 | MCI                     | Ohio University (NET-OH
   147.206.20.0/24 | AS3561 | MCI                     | Ochsner Foundation (NET
    161.120.6.0/24 | AS3561 | MCI                     | Norton Company (NET-SGC
   161.181.37.0/24 | AS3561 | MCI                     | Nordstrom, Inc. (NET-NO
   164.100.64.0/20 | AS3561 | MCI                     | National Informatics Ce
   164.100.81.0/24 | AS3561 | MCI                     | National Informatics Ce
   164.100.88.0/21 | AS3561 | MCI                     | National Informatics Ce
   164.100.96.0/19 | AS3561 | MCI                     | National Informatics Ce
  164.100.167.0/24 | AS3561 | MCI                     | National Informatics Ce
    159.179.0.0/24 | AS3561 | MCI                     | MIGROSBANK (NET-MIGROSB
    166.38.40.0/24 | AS3561 | MCI                     | MCI Telecommunications 
  165.166.123.0/24 | AS3561 | MCI                     | Info Avenue Internet Se
   147.116.63.0/24 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
   147.116.64.0/23 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.160.0/21 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  147.116.168.0/22 | AS3561 | MCI                     | Hercules, Inc. (NET-HER
  167.208.125.0/24 | AS3561 | MCI                     | Harcourt Brace & Co. (N
    166.147.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.150.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
    166.151.0.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.147.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.150.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
   166.151.64.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.147.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.147.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.150.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.128.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  166.151.192.0/18 | AS3561 | MCI                     | GTE Telecommunications 
  137.170.136.0/24 | AS3561 | MCI                     | Freudenberg-NOK (NET-FN
    136.140.9.0/24 | AS3561 | MCI                     | Ford Motor Company (NET
    169.200.1.0/24 | AS3561 | MCI                     | First Union National Ba
    169.200.9.0/24 | AS3561 | MCI                     | First Union National Ba
   168.175.70.0/24 | AS3561 | MCI                     | First Union National Ba
   169.200.11.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.170.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.171.0/24 | AS3561 | MCI                     | First Union National Ba
  168.175.172.0/24 | AS3561 | MCI                     | First Union National Ba
    167.77.32.0/24 | AS3561 | MCI                     | Dequesne Light Company 
   164.84.105.0/24 | AS3561 | MCI                     | Cytec Industries Inc. (
    147.160.0.0/17 | AS3561 | MCI                     | Concurrent Technologies
  147.160.128.0/18 | AS3561 | MCI                     | Concurrent Technologies
  147.160.192.0/20 | AS3561 | MCI                     | Concurrent Technologies
  147.160.200.0/21 | AS3561 | MCI                     | Concurrent Technologies
  147.160.208.0/20 | AS3561 | MCI                     | Concurrent Technologies
  147.160.224.0/19 | AS3561 | MCI                     | Concurrent Technologies
  147.160.224.0/20 | AS3561 | MCI                     | Concurrent Technologies
  167.105.232.0/24 | AS3561 | MCI                     | Coca-Cola Enterprises (
  159.140.254.0/24 | AS3561 | MCI                     | Cerner Corporation (NET
    168.97.37.0/24 | AS3561 | MCI                     | Carlson Companies (NET-
  138.108.100.0/24 | AS3561 | MCI                     | A.C. Nielsen Company (N
      24.88.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
     24.124.0.0/18 | AS3561 | MCI                     | @Home Network (NETBLK-A
     135.37.2.0/24 | AS3561 | MCI                     | *                      
     135.37.4.0/24 | AS3561 | MCI                     | *                      
    135.37.10.0/24 | AS3561 | MCI                     | *                      
    135.40.66.0/24 | AS3561 | MCI                     | *                      
   164.100.82.0/23 | AS3561 | MCI                     | *                      
   164.100.84.0/22 | AS3561 | MCI                     | *                      
  158.106.253.0/24 | AS3561 | MCI                     | *                      
  159.140.213.0/24 | AS3561 | MCI                     | *                      
  165.108.130.0/23 | AS3561 | MCI                     | *                      
  165.108.132.0/22 | AS3561 | MCI                     | *                      
  165.108.136.0/21 | AS3561 | MCI                     | *                      
  165.108.144.0/22 | AS3561 | MCI                     | *                      
  165.108.148.0/23 | AS3561 | MCI                     | *                      
   163.180.96.0/19 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
  163.180.128.0/17 | AS3559 | KORNET-3559 Autonomous- | Kyunghee Univ. Computer
     168.29.0.0/17 | AS3492 | ATLANTA                 | State of Georgia/Board 
   206.161.67.0/30 | AS3491 | CAIS-ASN                | CAIS Internet (NETBLK-C
  207.226.209.0/26 | AS3491 | CAIS-ASN                | CAIS Internet (NETBLK-C
  143.222.116.0/24 | AS3407 | Interpath               | *                      
  149.172.150.0/24 | AS3402 | TerraNet, Inc.          | *                      
  164.167.103.0/24 | AS3392 | Infinet Norfolk - MAE-E | Bureau of Medicine and 
   163.49.143.0/24 | AS3384 | New York Net            | TDK Corporation (NET-TD
   163.49.144.0/22 | AS3384 | New York Net            | TDK Corporation (NET-TD
    167.170.6.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
   167.170.32.0/23 | AS3313 | I.Net S.p.A.            | MEMC Electronic Materia
 194.183.203.44/30 | AS3305 | Internet Service Provid | *                      
   156.51.150.0/24 | AS3301 | TeliaNet Sweden         | Vasakronan (NET-VASAKRO
   156.51.204.0/24 | AS3301 | TeliaNet Sweden         | Vasakronan (NET-VASAKRO
    164.9.190.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.192.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.194.0/23 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
    164.9.196.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.9.0.0
   164.10.140.0/24 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
  164.10.27.128/26 | AS3301 | TeliaNet Sweden         | No match for "164.10.0.
   146.75.251.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   146.75.254.0/24 | AS3301 | TeliaNet Sweden         | Nexus AB (NET-COMBITECH
   171.25.128.0/19 | AS3301 | TeliaNet Sweden         | European Regional Inter
   171.25.144.0/21 | AS3301 | TeliaNet Sweden         | European Regional Inter
193.162.145.128/30 | AS3292 | Tele Danmark Internet E | European Regional Inter
    149.212.0.0/18 | AS3292 | Tele Danmark Internet E | *                      
 194.135.241.16/30 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.152/29 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.160/29 | AS3255 | Ukrainian Academic and  | European Regional Inter
 194.44.209.199/32 | AS3255 | Ukrainian Academic and  | European Regional Inter
    151.86.72.0/21 | AS3242 | ITnet S.p.A. Autonomous | *                      
  194.142.136.8/30 | AS3238 | ALCOM                   | European Regional Inter
     171.18.1.0/24 | AS3215 | RAIN                    | European Regional Inter
    135.14.65.0/24 | AS3111 | Internet Direct Inc. (A | Lucent Technologies (NE
   139.61.102.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
   139.61.103.0/24 | AS3111 | Internet Direct Inc. (A | Litton Computer Service
  165.212.158.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
  165.212.230.0/24 | AS2941 | CSCNS-AS                | USA.NET, Inc. (NET-USAN
   160.92.129.0/24 | AS2917 | OLEANE - UUNET PIPEX In | Axime S.A. (NET-SEGIN) 
     133.34.9.0/24 | AS2907 | SINET                   | Yokohama National Unive
   146.193.60.0/22 | AS2860 | IP Global, Informatica  | INESC (NET-INESC)      
   194.61.54.32/27 | AS2856 | BTnet UK Regional netwo | European Regional Inter
   171.30.170.0/24 | AS2856 | BTnet UK Regional netwo | BR Telecommunications L
   143.252.80.0/24 | AS2856 | BTnet UK Regional netwo | *                      
   145.17.100.0/24 | AS2856 | BTnet UK Regional netwo | *                      
  158.174.254.0/24 | AS2856 | BTnet UK Regional netwo | *                      
    159.142.0.0/18 | AS2714 | General Services Admini | General Services Admini
   159.142.64.0/18 | AS2714 | General Services Admini | General Services Admini
  159.142.128.0/18 | AS2714 | General Services Admini | General Services Admini
  159.142.192.0/18 | AS2714 | General Services Admini | General Services Admini
  144.127.110.0/23 | AS2707 | WEC                     | *                      
  144.127.112.0/20 | AS2707 | WEC                     | *                      
  144.127.128.0/19 | AS2707 | WEC                     | *                      
  144.127.160.0/21 | AS2707 | WEC                     | *                      
  144.127.168.0/23 | AS2707 | WEC                     | *                      
  145.248.112.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.155.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.157.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.159.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.161.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
  145.248.165.0/24 | AS2706 | HKSUPER                 | No match for "145.248.0
    164.53.55.0/24 | AS2706 | HKSUPER                 | National Australia Bank
    134.6.160.0/22 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
    134.6.180.0/24 | AS2706 | HKSUPER                 | Maxtor Corporation (NET
       9.20.0.0/17 | AS2686 | Autonomous System numbe | IBM Corporation (NET-IB
  194.53.172.20/30 | AS2686 | Autonomous System numbe | European Regional Inter
   155.39.191.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
   155.39.230.0/24 | AS2685 | IBM Global Network - US | Putnam Investments (NET
    140.212.2.0/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
  140.212.2.128/25 | AS2685 | IBM Global Network - US | Panasonic Technology, I
      32.96.0.0/16 | AS2685 | IBM Global Network - US | Norsk Informasjonstekno
  192.129.3.128/25 | AS2614 | Romanian Educational Ne | German National Researc
  131.114.192.0/18 | AS2598 | Consiglio Nazionale del | CNR - Istituto CNUCE (N
    137.98.96.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.97.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.98.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
    137.98.99.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.100.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.101.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.102.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.196.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.200.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.203.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.204.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.208.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.209.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.223.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.224.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.225.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.235.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.239.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
   137.98.240.0/24 | AS2571 | DHLNET                  | DHL Systems, Inc. (NET-
  133.194.226.0/24 | AS2554 | PSINet-PSI_Japan        | Institute for Supercomp
  142.218.120.0/24 | AS2551 | NETCOM On-line Communic | George Weston Ltd. (NET
  141.227.111.0/24 | AS2529 | Demon Internet Ltd      | Societe Nationale Elf A
  156.114.200.0/24 | AS2529 | Demon Internet Ltd      | Baring Securities Limit
  133.246.142.0/24 | AS2500 | WIDE Internet AS        | Japan Network Informati
    129.237.0.0/18 | AS2495 | KANREN                  | University of Kansas (N
  155.194.200.0/24 | AS2493 | i*internet              | City of Kitchener (NET-
    137.15.34.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.35.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.39.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.41.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.43.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.44.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.52.0/24 | AS2493 | i*internet              | Central Mapping Agency 
    137.15.54.0/24 | AS2493 | i*internet              | Central Mapping Agency 
  163.155.120.0/24 | AS2493 | i*internet              | Canada Mortgage and Hou
  161.173.243.0/24 | AS2386 | INS-AS                  | Wal-Mart Stores, Inc. (
  145.247.128.0/18 | AS2120 | DAXnet (Tele 3)         | No match for "145.247.0
   153.110.50.0/24 | AS2120 | DAXnet (Tele 3)         | Fellesdata AS (NET-FELL
    146.192.0.0/17 | AS2119 | Telenor Internett, Norw | Allianse Informasionssy
  146.192.128.0/17 | AS2116 | EUnet Norway            | Allianse Informasionssy
    152.170.0.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
    152.170.8.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
    152.171.0.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
    152.171.8.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
    152.172.0.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
   152.168.72.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
   152.168.80.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
   152.171.80.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
   152.172.16.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
   152.172.32.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.120.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.192.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.208.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.224.0/20 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.240.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.171.248.0/21 | AS2056 | AOL-AS                  | America Online, Inc (NE
  152.163.205.0/25 | AS2056 | AOL-AS                  | *                      
   157.151.64.0/19 | AS2041 | CRL-GATE                | *                      
   169.24.186.0/24 | AS2019 | JP MORGAN               | J.P. Morgan & Co. (NETB
     148.59.4.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.224.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.241.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.244.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.245.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.246.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
   148.59.247.0/24 | AS2015 | Msen, Inc.              | Msen, Inc. (NET-MSEN)  
    198.11.42.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
    198.11.51.0/27 | AS2015 | Msen, Inc.              | InterNIC Registration (
   164.52.249.0/24 | AS1982 | Northwest Nexus, Inc.   | Associated Grocers, Inc
    157.25.64.0/23 | AS1887 | NASK                    | Advanced Technology Man
   161.51.224.0/20 | AS1849 | PIPEX, Public IP EXchan | The M.W. Kellogg Compan
  148.176.225.0/24 | AS1849 | PIPEX, Public IP EXchan | ScottishPower (NET-SCOT
   148.185.45.0/24 | AS1849 | PIPEX, Public IP EXchan | Mercury Communications 
   159.245.84.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
  159.245.104.0/22 | AS1849 | PIPEX, Public IP EXchan | GEC ALSTHOM NV (NET-GEC
   170.194.51.0/24 | AS1849 | PIPEX, Public IP EXchan | Deloitte Touche Tohmats
  150.185.128.0/18 | AS1800 | ICM-Atlantic            | *                      
  150.185.192.0/18 | AS1800 | ICM-Atlantic            | *                      
   169.130.31.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   169.130.54.0/24 | AS1785 | NYSERNet Backbone       | Sprint, Business Servic
   149.212.64.0/20 | AS1759 | Telecom Finland iNET    | *                      
        9.2.0.0/16 | AS1747 | IBM Watson, Yorktown He | IBM Corporation (NET-IB
      24.48.0.0/18 | AS1677 | ANS  Hartford - CNSS 53 | @Home Network (NETBLK-A
    152.164.0.0/21 | AS1667 | ANS-DC2                 | ANS CO+RE Systems, Inc.
  157.184.150.0/24 | AS1330 | ANS St. Louis - DNSS 83 | *                      
  149.112.246.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.247.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.248.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
  149.112.249.0/24 | AS1327 | ANS Washington D.C. - D | US Robotics (NET-USR-1)
     24.48.33.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.34.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.36.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.40.0/21 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.48.0/22 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.52.0/23 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
     24.48.54.0/24 | AS1325 | ANS Cleveland - DNSS 43 | @Home Network (NETBLK-A
    148.212.1.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.2.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.3.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.4.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.5.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.6.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.7.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.8.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
    148.212.9.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.10.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.11.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.12.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.13.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.14.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.15.0/24 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.16.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
   148.212.32.0/20 | AS1292 | ITESM Campus -- Monterr | Universidad Autonoma de
  160.104.128.0/17 | AS1290 | PSINet UK Ltd.          | Tadpole Technology, Inc
 192.151.12.171/32 | AS1290 | PSINet UK Ltd.          | Hewlett Packard (NET-HP
    195.153.6.0/27 | AS1290 | PSINet UK Ltd.          | European Regional Inter
    153.96.76.0/24 | AS1275 | DFN-IP service and DFN  | Fraunhofer Institut fue
  130.168.105.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.115.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
  130.168.125.0/24 | AS1270 | EUnet Germany           | Convex Computer Corpora
   146.75.253.0/24 | AS1257 | SWIPnet Swedish IP Netw | Nexus AB (NET-COMBITECH
  144.199.161.0/24 | AS1238 | ICM Malaysia (MIMOS) co | *                      
    163.180.0.0/18 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
   163.180.64.0/19 | AS1237 | SERI Autonomous System  | Kyunghee Univ. Computer
   139.163.18.0/24 | AS1221 | AARNET-AS               | QANTAS Airways Limited 
    20.22.200.0/24 | AS1221 | AARNET-AS               | Computer Sciences Corpo
     24.192.0.0/18 | AS1221 | AARNET-AS               | @Home Network (NETBLK-A
     159.99.0.0/17 | AS1221 | AARNET-AS               | *                      
    144.55.12.0/24 | AS1221 | AARNET-AS               | *                      
    150.207.2.0/24 | AS1221 | AARNET-AS               | *                      
   158.155.24.0/22 | AS1221 | AARNET-AS               | *                      
   159.99.128.0/19 | AS1221 | AARNET-AS               | *                      
   159.99.160.0/21 | AS1221 | AARNET-AS               | *                      
  150.207.128.0/24 | AS1221 | AARNET-AS               | *                      
  139.162.128.0/17 | AS1136 | Unisource Internet Serv | Nedlloyd Computer Servi
    145.100.0.0/18 | AS1103 | SURFnet                 | *                      
     24.108.0.0/18 |  AS852 | AGT Advance Communicati | @Home Network (NETBLK-A
    24.112.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    24.113.32.0/19 |  AS812 | Rogers Communications I | @Home Network (NETBLK-A
    150.241.0.0/20 |  AS766 | RedIRIS Autonomous Syst | *                      
    149.20.64.0/24 |  AS701 | Alternet                | Vixie Enterprises (NET-
     168.86.1.0/24 |  AS701 | Alternet                | United Artists Theater 
    160.104.0.0/17 |  AS701 | Alternet                | Tadpole Technology, Inc
     134.6.77.0/24 |  AS701 | Alternet                | Maxtor Corporation (NET
  167.152.251.0/24 |  AS701 | Alternet                | EMI Communications Corp
   134.33.100.0/24 |  AS701 | Alternet                | Codex Corporation (NET-
   164.218.95.0/24 |  AS701 | Alternet                | Bureau of Naval Personn
   155.134.60.0/24 |  AS701 | Alternet                | Best Foods Baking Group
      155.7.0.0/19 |  AS701 | Alternet                | American Forces Informa
     155.7.32.0/21 |  AS701 | Alternet                | American Forces Informa
     155.7.40.0/24 |  AS701 | Alternet                | American Forces Informa
     155.7.41.0/24 |  AS701 | Alternet                | American Forces Informa
     155.7.42.0/23 |  AS701 | Alternet                | American Forces Informa
     155.7.44.0/22 |  AS701 | Alternet                | American Forces Informa
     155.7.48.0/20 |  AS701 | Alternet                | American Forces Informa
     155.7.64.0/18 |  AS701 | Alternet                | American Forces Informa
    155.7.128.0/17 |  AS701 | Alternet                | American Forces Informa
    165.125.0.0/17 |  AS701 | Alternet                | Alexander & Alexander I
   158.118.51.0/24 |  AS701 | Alternet                | *                      
    130.188.2.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.3.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    130.188.9.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.150.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.250.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
  130.188.252.0/24 |  AS565 | VTT autonomous system   | Technical Research Cent
    131.117.0.0/17 |  AS559 | SWITCH, Swiss Academic  | Municipality of Zuerich
      53.64.4.0/22 |  AS517 | Xlink                   | cap debis ccs (NET-DB-N
    153.96.80.0/21 |  AS517 | Xlink                   | Fraunhofer Institut fue
    153.96.92.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
   153.96.230.0/24 |  AS517 | Xlink                   | Fraunhofer Institut fue
    143.93.32.0/19 |  AS517 | Xlink                   | Fachhochschule Rheinlan
 194.59.152.128/27 |  AS517 | Xlink                   | European Regional Inter
  129.181.208.0/21 |  AS517 | Xlink                   | Bull Louveciennes (NET-
  129.181.216.0/22 |  AS517 | Xlink                   | Bull Louveciennes (NET-
     132.83.5.0/24 |  AS306 | NGNET-AS                | National Guard Bureau (
    132.105.2.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.105.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
    132.115.5.0/24 |  AS306 | NGNET-AS                | Army National Guard Bur
  198.200.138.0/27 |  AS174 | Performance Systems Int | Quadritek Systems, Inc.
  199.99.247.32/27 |  AS174 | Performance Systems Int | Performance Systems Int
   136.161.17.0/24 |  AS174 | Performance Systems Int | PSI Network One (NET-PS
   162.17.253.0/24 |  AS174 | Performance Systems Int | Compass Design Automati
  128.145.228.0/24 |  AS174 | Performance Systems Int | *                      
   129.35.208.0/24 |  AS163 | IBM-RESEARCH-AS         | *                      
    166.4.174.0/26 |    AS1 | BBN Planet backbone     | US Forest Service (NETB
 199.14.184.128/26 |    AS1 | BBN Planet backbone     | U.S. Sprint (NETBLK-SPR
  134.241.109.0/24 |    AS1 | BBN Planet backbone     | Massachusetts Higher Ed
  161.223.220.0/22 |    AS1 | BBN Planet backbone     | Indian Health Service (
  161.223.224.0/24 |    AS1 | BBN Planet backbone     | Indian Health Service (
   135.16.150.0/24 |    AS1 | BBN Planet backbone     | AT&T ITS (NET-ATT-135-1
    159.87.34.0/24 |    AS1 | BBN Planet backbone     | *                      
  151.124.250.0/24 |    AS1 | BBN Planet backbone     | *                      




From dave at rtd.net  Fri Mar 28 20:08:13 1997
From: dave at rtd.net (Dave Siegel)
Date: Fri, 28 Mar 1997 13:08:13 -0700 (MST)
Subject: BGP4 COMMUNITY attribute
In-Reply-To: <199703272010.PAA14950@ieng.com> from "John Scudder" at Mar 27, 97 03:10:52 pm
Message-ID: <199703282008.NAA23819@seagull.rtd.com>

> John W. Stewart II writes:
> > rfc1997.  i think there's a GateD with communities
> 
> Yup.

Bay Networks supports them as well, though I'm not sure if it's in the
mainstream code...it might only be in 11.01 (ANS code).

Dave

-- 
Dave Siegel					      Sr. Network Engineer
(520)388-9000 x130	    		    			 President
dave at rtd.net, dave at page.rtd.com(pager)	    RTD Systems & Networking, Inc.
http://www.rtd.com/~dsiegel/		"Experience the Power of Connectivity"




From amb at xara.net  Fri Mar 28 20:26:57 1997
From: amb at xara.net (Alex.Bligh)
Date: Fri, 28 Mar 1997 20:26:57 +0000
Subject: NAPs - Temperature vs Packet loss
Message-ID: <199703282026.UAA18650@diamond.xara.net>

We've noticed an interesting phenomenon with MAE-East. Packet loss
corelates nicely to temperature.

At first I assumed the relationship was Busy Network => Hot routers
and also Busy Network => Packet Loss. But this is not the case.
It appears to be Hot Routers => Packet Loss.

Boone Boulevard MAE-East is currently running very hot. Intake temp
on our router has been up to 40 degrees today, and output at 70.
Under these conditions, the router (a 7010) starts dropping a pile
of packets occassionally. Mostly these seem to be through the AIP
and a clear int a0/0 fixes it. The time it stays fixed for is
heavilly corelated with temperature. The higher the temperature,
the shorter it stays fixed for. Eventually MFS put a fan on the
router and it seems a lot better now, intake temperature being
down to 36/37 degrees.

40 degrees is Cisco's default "warning" threshold. One would have
thought boxes should work OK at 40 degrees. On the other hand one
might also have thought a 18-22 degree aircon environment was a
prerequisite of running a decent IXP.

Is anyone else seeing high temperature and otherwise inexplicable
packet loss at MAE-East? Or does anyone else have data to corelate?

Alex Bligh
Xara Networks






From dkerr at cisco.com  Fri Mar 28 21:09:11 1997
From: dkerr at cisco.com (Darren Kerr)
Date: Fri, 28 Mar 1997 13:09:11 -0800
Subject: NAPs - Temperature vs Packet loss
In-Reply-To: <199703282026.UAA18650@diamond.xara.net> (amb@xara.net)
Message-ID: <199703282109.NAA17338@monarch.cisco.com>

> X-Mailer: exmh version 2.0alpha 12/3/96
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Date: Fri, 28 Mar 1997 20:26:57 +0000
> From: "Alex.Bligh" <amb at xara.net>
> Sender: owner-nanog at merit.edu
> Content-Length: 1220
> 
> We've noticed an interesting phenomenon with MAE-East. Packet loss
> corelates nicely to temperature.
> 
> At first I assumed the relationship was Busy Network => Hot routers
> and also Busy Network => Packet Loss. But this is not the case.
> It appears to be Hot Routers => Packet Loss.
> 
> Boone Boulevard MAE-East is currently running very hot. Intake temp
> on our router has been up to 40 degrees today, and output at 70.
> Under these conditions, the router (a 7010) starts dropping a pile
> of packets occassionally. Mostly these seem to be through the AIP
> and a clear int a0/0 fixes it. The time it stays fixed for is
> heavilly corelated with temperature. The higher the temperature,
> the shorter it stays fixed for. Eventually MFS put a fan on the
> router and it seems a lot better now, intake temperature being
> down to 36/37 degrees.

First I've heard of it, but sounds like you've captured a lot of
empirical evidence, so could you send me your data (hopefully
telling me whether these were output drops, input ignores, input
drops, or other errors).  Did you notice any errors logged?
Anyways, send me all your usual "show ver", "show int", "show
contr cbus" info (nanog un-cc'ed, please) and I'll pass it around.

/Darren

PS - I've noticed that ever since I moved to San Diego, people
around here have been dropping like flies.  Coincidence, or
cause&effect?  ;-)

> 40 degrees is Cisco's default "warning" threshold. One would have
> thought boxes should work OK at 40 degrees. On the other hand one
> might also have thought a 18-22 degree aircon environment was a
> prerequisite of running a decent IXP.
> 
> Is anyone else seeing high temperature and otherwise inexplicable
> packet loss at MAE-East? Or does anyone else have data to corelate?
> 
> Alex Bligh
> Xara Networks
> 
> 
> 




From michael at memra.com  Fri Mar 28 22:03:51 1997
From: michael at memra.com (Michael Dillon)
Date: Fri, 28 Mar 1997 14:03:51 -0800 (PST)
Subject: NAPs - Temperature vs Packet loss
In-Reply-To: <199703282109.NAA17338@monarch.cisco.com>
Message-ID: <Pine.BSI.3.93.970328135434.5701b-100000@sidhe.memra.com>

On Fri, 28 Mar 1997, Darren Kerr wrote:

> > Boone Boulevard MAE-East is currently running very hot. Intake temp
> > on our router has been up to 40 degrees today, and output at 70.
       
70 degrees!!! This is pushing the limit for reliable operation of
electronic equipment. I know I have frequently solved problems with all
sorts of equipment (computers, modems, terminal servers, routers) by
dropping the ambient room temperature to below the level where it is
comfortable for people to work, i.e. around 15 degrees. or by adding fans
internally or externally. 

I think that ambient temperatures at the tops of the racks and at the
room's outflow vents should be specified in IXP agreements along with
a protocol for dealing with this kind of problem. And most especially,
this needs to be properly engineered from the start.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From jhc at lynxhub.att.com  Fri Mar 28 23:08:44 1997
From: jhc at lynxhub.att.com (Jonathan Clark)
Date: Fri, 28 Mar 1997 18:08:44 -0500
Subject: Anti-SPAM announcement from AT&T Worldnet
Message-ID: <9703281808.ZM17244@lynxhub.att.com>

AT&T Worldnet announces that starting Monday, March 31 1997,
it will be taking action to stop email from non-AT&T Worldnet
account holders being relayed through its servers.
 
We have reserved the right to treat such mail any way we deem appropriate,
which may include deleting it without notification to the originator.
 
Please address any questions about this policy to abuse at worldnet.att.net.
 




From kevin at ascend.com  Fri Mar 28 23:37:53 1997
From: kevin at ascend.com (Kevin Smith)
Date: Fri, 28 Mar 1997 15:37:53 -0800
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <9703281808.ZM17244@lynxhub.att.com>
Message-ID: <3.0.1.32.19970328153753.009e5908@mktg_srv.ascend.com>

At 06:08 PM 3/28/97 -0500, Jonathan Clark wrote:
>AT&T Worldnet announces that starting Monday, March 31 1997,
>it will be taking action to stop email from non-AT&T Worldnet
>account holders being relayed through its servers.

Any email...even regular questions/replies....I think specific
types of email would be more appropriate..."spam","obscene" etc.


Kevin Smith                              Updated Service and Support
Senior Technical Support Engineer        Resources are now at:
Customer Satisfaction 
Ascend Communications                    http://www.ascend.com/service






From jfbb at ATMnet.net  Fri Mar 28 23:56:42 1997
From: jfbb at ATMnet.net (Jim Browning)
Date: Fri, 28 Mar 1997 15:56:42 -0800
Subject: ARIN is A Good Thing
Message-ID: <01BC3B90.A1E06B60@jfbb.atmnet.net>

My apologies to those who do not consider this to be an operational issue, 
however I feel that service providers who believe ARIN represents a 
positive step should express their support for the proposal, to ensure that 
it is not slowed by institutional intervention.  Should the allocation of 
IP addresses become mired in the problems we have seen happen with domain 
names, it will certainly become a major operational consideration...

----------
I am writing this to express ATMnet's support for ARIN (the American 
Registry for Internet Numbers) in the strongest possible terms.  It is of 
the utmost importance that the allocation of Internet Protocol (IP) 
addresses not be jeopardized by the turmoil currently surround the Domain 
Name System (DNS), and that immediate steps be taken to move in the 
direction defined in the ARIN proposal.  DNS issues are primarily related 
to factors such as market leverage, and obtaining any particular domain 
name can be viewed as something of a luxury.  IP Addresses, on the other 
hand, are of operational concern, and timely and appropriate access to this 
resource is absolutely required for the continued growth of the Internet.

Obtaining consensus on any important Internet related topic is 
excruciatingly difficult in today's environment.  Nowhere is this more 
obvious than in the debates over DNS and IP Addresses.  Fortunately, there 
are stark contrasts between the two issues.

The DNS debates are filled with rancor and punctuated by alternative 
efforts and litigation.

While ARIN has been a subject of hot debate, there is nonetheless a rough 
consensus within the Internet community that establishing a non-profit 
entity to handle the administration of this vital function is both 
necessary and appropriate.  Old-timers and newcomers have found some common 
ground.  There are of course those who would like to see things taken in a 
different direction, as there always will be when something of this nature 
is discussed.  There are also issues which still need to be resolved, and a 
lot of work which needs to be done.  ATMnet is confident that the people 
trying to accomplish these tasks have the necessary skills, ethics and 
standing in the community to get the job done right.

There is "rough consensus".  There is "running code" in the form of the 
people and systems currently performing the function, and the two similar 
entities (APNIC and RIPE) which are already in operation under similar 
charters.  It is time for ARIN to move forward unfettered by Federal 
intervention or oversight.

When confronted with change and new alternatives, the appropriate direction 
to take is not always evident.  In this case however, it is clear to ATMnet 
that ARIN deserves all our support simply because it is the right thing to 
do for the health of a growing and vibrant industry.
--
Jim Browning <jfbb at ATMnet.net>
CEO, ATMnet  <www.ATMnet.net>






From nathan at netrail.net  Sat Mar 29 01:33:14 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Fri, 28 Mar 1997 20:33:14 -0500 (EST)
Subject: Ascend/Netstar GRF 400
In-Reply-To: <01BC3B7F.06850EC0@Mallard.nap.net>
Message-ID: <Pine.LNX.3.95.970328202925.23210A-100000@netrail.net>

On Fri, 28 Mar 1997, Chris A. Icide wrote:

> Is anyone successfuly using one of these?  I've got one in the labs
> here, and have found some interesting problems.  Ascend engineers
> are hot on the problems, but I was wondering if anyone else has any
> experience.

Yes, our network is now cisco free! We have been using the GRF1600s for
several months in our network. We have found a few problems, but Ascend
has been VERY fast to fix them. So far they blow away the Cisco solution
we were using.

> Our current problems seem to be related to buffer overruns on the 
> ATM/Q card.

We have not used the ATM/Q card a lot, but I am sure Ascend can fix any
problem you may have. We are using cascade 900s as backbone switches into
the GRF 1600s via HSSI. We plan to move this to OC3 as soon as we finish
testing.


Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From nathan at netrail.net  Sat Mar 29 01:37:32 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Fri, 28 Mar 1997 20:37:32 -0500 (EST)
Subject: NAPs - Temperature vs Packet loss
In-Reply-To: <Pine.BSI.3.93.970328135434.5701b-100000@sidhe.memra.com>
Message-ID: <Pine.LNX.3.95.970328203553.23210B-100000@netrail.net>

On Fri, 28 Mar 1997, Michael Dillon wrote:

> electronic equipment. I know I have frequently solved problems with all
> sorts of equipment (computers, modems, terminal servers, routers) by
> dropping the ambient room temperature to below the level where it is
> comfortable for people to work, i.e. around 15 degrees. or by adding fans
> internally or externally. 

We had a problem with this at the Atlanta-NAP, people were complaining
that it was to cold. When we warmed it up a bit, we started having
problems. So now we just tell them to dress warmly. :-)

Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From bgreene at cisco.com  Sat Mar 29 02:37:13 1997
From: bgreene at cisco.com (Barry Raveendran Greene)
Date: Sat, 29 Mar 1997 10:37:13 +0800
Subject: (FWD)US Federal gov't decides to solve DNS problem - rugpulled out from under NSF -  
Message-ID: <01BC3C2D.8EECA6C0@bgreene-pc>

Hello All,

Speaking of ARIN.....

Anyone have more details about theses White House efforts?

Barry


[Orginal header attached to the bottom.]

>Clinton Administration Embraces DNS Tar Baby, Magaziner & OMB Responsible 
>
>Action Derails Agreement with Network Solutions & NSF to End 
>Co-operative Agreement on April 1 1997 
>
>Ill Considered Move Halts Formation of ARIN IP Registry
>
>Critics Say Action Deprives IANA of Opportunity for Legal Foundation of 
>Authority & Endangers Stability of the Internet by Putting IP Numbers at
>Risk
>
>[NOTE:  This is the public summary of the page one article for the MAY
>1997 Cook Report on Internet. We are releasing it to the internet before
>the weekend begins. We hope to publish the complete May issue before the
>end of the weekend.]
>
>Thanks to the meddling of hopefully well meaning folk - Ira Magaziner's
>Internet task force at the White House, and an inter agency task force
>centered at OMB, we are faced with a potentially dangerous situation for
>the Internet. It is no secret how badly the Domain Name System is about to
>become fouled up after a year and a half of squabbling among competing
>bodies. But what is not broadly understood is that NSI runs the IP
>registry for the Western hemisphere and feeds content to the "." dot
>servers for the world that are located at NSI  but owned by IANA. These
>are functions that there is no longer any legitimate reason for the US
>government to be involved with. But they are also so critical to the
>operation of the Internet that they must be moved very promptly to a
>separate and neutral body independent of NSI and one unable to be dragged
>"under" by the waves litigation now threatening everyone involved with
>Domain Name System.
>
>After talking with numerous sources familiar with the events of the last
>two months, we are convinced that policy coming from the White House has,
>inadvertently, put a stop to plans that had moved far enough along so that
>the above removal of ARIN's functions from NSI could have happened in a
>way that would benefit the world wide Internet community. Fall out from
>this action has meant a halt in plans under way that would have - very
>shortly - resulted in the establishment of an independent American
>Registry for Internet Numbers. The establishment of ARIN also means that
>for the first time the operations of the IANA could become
>institutionalized and gain a sounder international foundation
>
>Putting a hold on the establishment of ARIN renders the authority of IANA
>more liable to court challenge and leaves the payroll, database, and
>control of the IP number registry process in the hands of a commercial
>company (NSI) that does the original .com and other global top level
>domain name registry for the entire internet world wide. As someone
>closely involved with ARIN told us: "The real danger is that numbers are
>being subsidized by domain names, and domain names are about to become a
>disaster."
>
>While NSI has shown no signs that it cannot or should not be trusted, it
>is improbable that NSF oversight of NSI will extend beyond the current
>agreement whereas the need for NSI as a stabilized registry operation in
>an impending sea of change in the Domain Name arena will continue.
>
>Therefore, it is reasonable to assume that NSI will sooner or later be
>granted full independence from NSF oversight . When this happens leaving
>the power inherent in both the DNS and the ARIN functions in the hands of
>a single corporation would be unwise. Also, while one hopes the chances
>are small that anything serious will happen to the viability of Network
>Solutions, it's DNS database performance during the last half of March has
>been horrendous with major names that had already paid being removed from
>the root servers for non payment - something that has led to disruption of
>service for many entities involved. In the litigious atmosphere that
>surrounds this whole environment, Network Solutions will surely be a
>target. 
>
>In an exclusive interview on March 27 with Don Telage, President of NSI we
>were able to establish, with some degree of precision, that at the end of
>February, the National Science Foundation and Network Solutions had
>reached an agreement in principal to bring the NSF/NSI cooperative
>agreement to a conclusion a year early on April 1, 1997 and to establish
>and fund during a transition period the American Registry for Internet
>Numbers (ARIN) which would have been freed from NSI control on April 1,
>1997. Unfortunately, the administration move to find a fix for DNS
>(discussed later in our full article) caused all forward movement between
>NSI and NSF to cease on Monday March 3. Since then the situation has
>become much more difficult and the freeing of ARIN as part of a package
>deal that was acceptable to both sides at the beginning of March looks far
>less acceptable to to NSI now as a stand alone option. [Editor's note: we
>have here confirmation of the damage that the administration's ill advised
>meddling has done. We and, we hope the entire internet, will be watching
>closely to see what they do to fix the mess they have created.]
>
>ARIN will temporarily cover Latin America and sub-Saharan Africa. The ARIN
>organizers are working with both areas to help them set up their own
>regional registries.  Then, under the auspices of IANA would be five
>registries, AfriNIC, ALyCNIC, APNIC, ARIN, and RIPE. Leaving IP
>registration for the western hemisphere and sub-Saharan Africa
>indefinitely under the aegis of NSI under the current stressful conditions
>does not make sense. If anything disastrous happened to impact the
>viability of NSI, IP registration and dot operation could be set up
>elsewhere within 48 to 72 hours - if the people and hardware were
>available. But during such a transition there would likely be substantial
>disruption of Internet service worldwide. Also, during such a move,
>assignment of new numbers would not take place and that process would take
>longer to get back to normal.
>
>In a conversation with a White House source on March 25 we found out the
>Administration has decided that the Federal government needs to study the
>DNS and solve a problem for the Internet community that it has been
>otherwise unable to solve for itself. Unfortunately it appears that
>Magaziner's group has been listening to the positions that Tony Rutkowski
>and the corporate lawyers of the Internet Law and Policy Forum have been
>promoting both on the network and off line. The source maintains that the
>inter-agency task force is unaware that in grabbing the DNS tar baby it
>also has grabbed and derailed - for the time being - ARIN.
>
>In derailing ARIN the group is undertaking actions that pose some risk to
>the stable operation of the internet world wide. That stability can be
>ensured only by the resumption of swift action to resume the establishment
>of ARIN and, in the face of a likely onslaught of DNS related lawsuits,
>and to create a Global Council of IP Registries, to internationalize the
>IANA, with members taken initially from the three regional registries;
>European (Ripe), the American (ARIN) and the Asian (APNIC) IP registries;
>and other regional registries added as they develop. 
>
>
>************************************************************************
>The COOK Report on Internet               For subsc. pricing & more than
>431 Greenway Ave, Ewing, NJ 08618 USA     ten megabytes of free material
>(609) 882-2572 (phone & fax)              visit   http://pobox.com/cook/
>Internet: cook at cookreport.com             For NEW study: EVOLVING INTER-
>NET INFRASTRUCTURE, 222 page Handbook http://pobox.com/cook/evolving.html
>************************************************************************
>
>
>
>============================== ISP Mailing List
==============================
>Email ``unsubscribe'' to inet-access-request at earth.com to be removed.
>PLEASE READ THE FAQ ON http://www.amazing.com/internet/ BEFORE POSTING.
>
>Return-Path: inet-access-ignored at earth.com
>Resent-Date: Fri, 28 Mar 1997 13:23:50 -0700 (MST)
>Resent-Message-Id: <199703282023.NAA10139 at austin.bsdi.com>
>List-Admin: inet-access-request at earth.com (subscribe/unsubscribe requests)
>Errors-To: inet-access-ignored at earth.com
>Originator: inet-access at earth.com
>Reply-To: inet-access at earth.com
>Resent-From: inet-access at earth.com
>Sender: inet-access at earth.com
>Date: Fri, 28 Mar 1997 14:23:08 -0500 (EST)
>From: Gordon Cook <cook at netaxs.com>
>To: com-priv at psi.com, nettime-l at Desk.nl
>cc: inet-access at earth.com, cosndisc at list.cren.net,
>        telecomreg at relay.doit.wisc.edu
>Subject: US Federal gov't decides to solve DNS problem - rug pulled out
from under NSF -  
>


-- 
-- 
--
Barry Raveendran Greene             |       ||        ||        |
Senior Consultant                   |       ||        ||        |
Consulting Engineering              |      ||||      ||||       |
tel: +65 738-5535 ext 235           |  ..:||||||:..:||||||:..   |
e-mail: bgreene at cisco.com           |  c i s c o S y s t e m s  |





From redhead at cloudy.lightning.net  Sat Mar 29 04:00:40 1997
From: redhead at cloudy.lightning.net (Reid Fishler)
Date: Fri, 28 Mar 1997 23:00:40 -0500 (EST)
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <9703281808.ZM17244@lynxhub.att.com> from Jonathan Clark at "Mar 28, 97 06:08:44 pm"
Message-ID: <199703290400.XAA18215@cloudy.lightning.net>

While we are discussing AT&T Worldnet, does anyone LOOK at mail to abuse?
I personally emailed this address, along with root and postmaster over three
months ago, and I know of at least 4 others who did the same, and got no
response. In fact, I believe 2 of the addresses bounced...And when BBN
(transit provider) was called, they refused to do anything about it...
Reid Fishler
Lightning Internet Services, LLC

> AT&T Worldnet announces that starting Monday, March 31 1997,
> it will be taking action to stop email from non-AT&T Worldnet
> account holders being relayed through its servers.
>  
> We have reserved the right to treat such mail any way we deem appropriate,
> which may include deleting it without notification to the originator.
>  
> Please address any questions about this policy to abuse at worldnet.att.net.
>  
> 





From planting at vfi.com  Sat Mar 29 04:46:16 1997
From: planting at vfi.com (Paul R.D. Lantinga)
Date: Fri, 28 Mar 1997 20:46:16 -0800 (PST)
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <199703290400.XAA18215@cloudy.lightning.net>
Message-ID: <Pine.LNX.3.95.970328204459.4801D-100000@wacky.eit.com>

Last I checked Reid, it was only the 28th of March, not the 31st.  Give
'em a chance there buddy and then maybe flame them.  -Paul.

-- 
Paul R.D. Lantinga  #planting at vfi.com#
Systems Administrator, Verifone IC 
"...'proactive' and 'paradigm', aren't these just buzzwords 
that dumb people use to sound important?"-The Simpsons


On Fri, 28 Mar 1997, Reid Fishler wrote:

> While we are discussing AT&T Worldnet, does anyone LOOK at mail to abuse?
> I personally emailed this address, along with root and postmaster over three
> months ago, and I know of at least 4 others who did the same, and got no
> response. In fact, I believe 2 of the addresses bounced...And when BBN
> (transit provider) was called, they refused to do anything about it...
> Reid Fishler
> Lightning Internet Services, LLC
> 
> > AT&T Worldnet announces that starting Monday, March 31 1997,
> > it will be taking action to stop email from non-AT&T Worldnet
> > account holders being relayed through its servers.
> >  
> > We have reserved the right to treat such mail any way we deem appropriate,
> > which may include deleting it without notification to the originator.
> >  
> > Please address any questions about this policy to abuse at worldnet.att.net.
> >  
> > 
> 
> 





From dgs at us.net  Sat Mar 29 06:29:57 1997
From: dgs at us.net (David Stoddard)
Date: Sat, 29 Mar 1997 01:29:57 -0500 (EST)
Subject: ARIN is *NOT* A Good Thing
In-Reply-To: <01BC3B90.A1E06B60@jfbb.atmnet.net> from "Jim Browning" at Mar 28, 97 03:56:42 pm
Message-ID: <199703290629.BAA15441@us.net>

	This message is in response to Jim Browning's support for ARIN.
	It doesn't belong on NANOG, but because it originated there I
	feel I have to address it.  Feel free to hit the "D" key now ...


















	While everyone is entitled to their opinion, ARIN is no magic
	bullet and is the wrong answer for our industry.  The supporters 
	of ARIN seem to fall into several categories:

	a)  You have a very small network and have NOTHING to lose if
	      ARIN goes forward,
	b)  You are filty rich and you don't mind paying big chunks of
	      money for something that your tax dollars already support,
	c)  You are a Canadian or Mexican citizen and you are tired of the
	      US Government managing the resources you require to run your 
	      business,
	d)  You work for an ISP, but as a technical person you have no idea
	      what all this stuff costs and you really don't care,
	e)  You are trying to suck up to the political structure because you
	      are afraid to really voice your opposition,
	f)  You are vying for a position in the ARIN organization, or
	g)  You really don't understand what this ARIN thing is anyhow.

	While the ARIN proposal has gotten much better in the past three
	months, I still assert that there is *nothing* ARIN will give me 
	for my $10,000 per year allocation fee that I don't get right now from 
	the tax dollars I currently pay to support the National Science 
	Foundation.

	*  It will take money that could have gone to support my network, my
	   employees, and my customers, and instead divert that money to 
	   a yet another bureaucracy.
	*  It will increase my costs, which will have to be passed along to
	   my customers, which will effect my business.
	*  It will not allow me to increase the size of my current address 
	   allocations any faster than the current InterNIC slow start 
	   policy allows (slow start has impacted us substantially in some 
	   of the school districts we have brought online -- at least Cisco
	   has a product to address this dilemna [the PIX]).
	*  It will not decrease the amount of time it takes to get a new
	   allocation (although this has improved tremendously under
	   Kim Hubbard's leadership).

	Worse, if ARIN goes forward, my company will be forced to join and
	support this organization because our very survival will depend upon
	it.  This is equivalent to holding a gun to our head and extorting 
	us to pay the $10,000 (or more) annual fee.

	Frankly, this whole "pay for" address policy is crazy -- the InterNIC
	made 60 million dollars PROFIT last year issuing domain names (while
	funding the assignment of IP address space AT THE SAME TIME).  This
	has to be the biggest money grab in history -- 60 million dollars
	isn't enough for one monopoly to make?  Unbelievable.

	For the sake of discussion, this is the following fee structure
	that has been proposed by ARIN (see the ARIN proposal page at
	http://www.arin.net/arin_proposal.html):

	Small	$2500/year	/24 - /19 
	Medium	$5000/year	>/19 - /16 
	Large	$10K/year	>/16 - /14
	X-Large	$20K/year	>/14

	Fees are based on your total allocation for the previous year,
	plus another $1,000 per year to maintain membership in ARIN.
	It is safe to say that any ISP able to receive address blocks
	falls somewhere between Medium and X-Large on this chart.

	I want to address each of the elements Jim Browning sets forth 
	in his message of support for ARIN:

	> "It is of the utmost importance that the allocation of 
	> Internet Protocol (IP) addresses not be jeopardized by the 
	> turmoil currently surround the Domain Name System (DNS)"

	The inference here is that by creating a costly new bureaucracy,
	all our problems will go away.  I see absolutely NO evidence of
	any legal or procedural mechanism that will prevent turmoil.  There
	is only one IPv4 address space, so the concept of "alternate
	registries" (aka, like the alternate TLD proposals) has no relevence
	to address space allocation.  Comparing address space to domain
	name allocation is comparing apples to oranges.

	> "IP Addresses, on the other hand, are of operational concern, and 
	> timely and appropriate access to this resource is absolutely 
	> required for the continued growth of the Internet."

	I put an allocation request in last Monday and received my new
	allocation Thursday.  Even if allocation requests could be turned
	around in one-hour, paying an annual $10K fee is not worth it
	to speed the process up three days.  Think about it.

	> "Obtaining consensus on any important Internet related topic is 
	> excruciatingly difficult in today's environment.  Nowhere is 
	> this more obvious than in the debates over DNS and IP Addresses."

	There is nothing about ARIN that says we will all be in concensus.
	If anything, there will be tremendous dischord because we will have
	hundreds of ISPs voicing their opinions at the semi-annual ARIN
	meetings.  The current NSF sponsored system does not foster this
	level of turmoil.  If anything, ARIN will turn the currently stable
	IP address policy mechanism into a semi-annual slug fest.

	Slow start was an important policy to conserve address space and
	(dispite is short comings) was a necessary at the time.  ARIN will
	not eliminate slow start or any other policy.  Having a vote on the
	ARIN board will not eliminate debate over IP address policy.

	> "While ARIN has been a subject of hot debate, there is nonetheless
	> a rough consensus within the Internet community that establishing 
	> a non-profit entity to handle the administration of this vital 
	> function is both necessary and appropriate."

	There is one -- the same one that has been funded by the NSF since
	the mid 1980's.  Why change something that has worked so well in
	the past?  There are no substantive advantages to ARIN, and it will
	cost all of us a lot more money.

	> "There are also issues which still need to be resolved, and a 
	> lot of work which needs to be done."

	Anyone remember what it was like to register a domain name in 1994?
	And we want to do that to our IP address allocation mechanism?
	Start ARIN and then wait for the systems to fall in place?  I think
	that is a recipe for total disaster.  It took YEARS for the current
	InterNIC to get its act together.

	> "There is "running code" in the form of the people and systems 
	> currently performing the function, and the two similar entities 
	> (APNIC and RIPE) which are already in operation under similar 
	> charters."

	APNIC and RIPE are not run by governmental entities and must charge
	for address space in order to exist.  They get that address space
	from the current system that is under control of the NSF.  As a US
	taxpayer, I pay taxes to support the NSF.  Because the NSF has 
	alternate sources for its funding, ISPs and their customers do not
	have to make direct payments for address space.  This keeps prices
	for Internet access low.  Starting ARIN will not reduce your US
	taxes, it will simply add to the cost of doing business.  For no
	additional benefit.  Comparing APNIC and RIPE to the current US
	model is not fair or accurate.

	> "It is time for ARIN to move forward unfettered by Federal 
	> intervention or oversight."

	I believe (as a US citizen) that the Internet is strategic to the
	United States, and control over the address space should remain with
	the US Government.  The US funded the development of the Internet,
	and there is a substantial portion of the US economy that is riding
	on top of it.  Giving control over this strategic asset to a non-profit
	organization that is beholden to nobody is foolishness.

	> "ARIN deserves all our support simply because it is the right 
	> thing to do for the health of a growing and vibrant industry."

	Charging for IP addresses will raise the cost of an Internet
	connection.  Raising costs will not improve the health of a growing
	and vibrant industry -- it is anathma to our industry.

	ARIN is the wrong answer for our industry.  As an example, in the
	radio and television industry, members have fought for years
	to prevent charges from being assessed against the limited radio
	spectrum they use.  Compare this to ARIN, where we are trying to levy
	substantial fees against members of our own industry.  ARIN is a bad
	idea.  It will continue to be a bad idea because it will always cost
	more that what we currently have with the NSF, and it will provide
	no substantive benefit.  Slow start is not going away, and ARIN will
	not quell address policy debates.  ARIN will hurt our industry, it
	will make the Internet more expensive for customers, and it will
	form yet another elite club.  Like I said in January, ARIN is
	equivalent to throwing your money away.

	Unfortunately, like it or not, ARIN will probably go forward anyhow.
	And we will be writing big expensive checks to ARIN to keep our
	businesses running.  I urge people to speak up now if you think
	ARIN is a bad idea.  Lets work together to reduce cost, not increase
	cost.

	Dave Stoddard, CEO
	US Net Incorporated
	301-572-5926
	dgs at us.net

Jim Browning writes:
> My apologies to those who do not consider this to be an operational issue, 
> however I feel that service providers who believe ARIN represents a 
> positive step should express their support for the proposal, to ensure that 
> it is not slowed by institutional intervention.  Should the allocation of 
> IP addresses become mired in the problems we have seen happen with domain 
> names, it will certainly become a major operational consideration...
> 
> ----------
> I am writing this to express ATMnet's support for ARIN (the American 
> Registry for Internet Numbers) in the strongest possible terms.  It is of 
> the utmost importance that the allocation of Internet Protocol (IP) 
> addresses not be jeopardized by the turmoil currently surround the Domain 
> Name System (DNS), and that immediate steps be taken to move in the 
> direction defined in the ARIN proposal.  DNS issues are primarily related 
> to factors such as market leverage, and obtaining any particular domain 
> name can be viewed as something of a luxury.  IP Addresses, on the other 
> hand, are of operational concern, and timely and appropriate access to this 
> resource is absolutely required for the continued growth of the Internet.
> 
> Obtaining consensus on any important Internet related topic is 
> excruciatingly difficult in today's environment.  Nowhere is this more 
> obvious than in the debates over DNS and IP Addresses.  Fortunately, there 
> are stark contrasts between the two issues.
> 
> The DNS debates are filled with rancor and punctuated by alternative 
> efforts and litigation.
> 
> While ARIN has been a subject of hot debate, there is nonetheless a rough 
> consensus within the Internet community that establishing a non-profit 
> entity to handle the administration of this vital function is both 
> necessary and appropriate.  Old-timers and newcomers have found some common 
> ground.  There are of course those who would like to see things taken in a 
> different direction, as there always will be when something of this nature 
> is discussed.  There are also issues which still need to be resolved, and a 
> lot of work which needs to be done.  ATMnet is confident that the people 
> trying to accomplish these tasks have the necessary skills, ethics and 
> standing in the community to get the job done right.
> 
> There is "rough consensus".  There is "running code" in the form of the 
> people and systems currently performing the function, and the two similar 
> entities (APNIC and RIPE) which are already in operation under similar 
> charters.  It is time for ARIN to move forward unfettered by Federal 
> intervention or oversight.
> 
> When confronted with change and new alternatives, the appropriate direction 
> to take is not always evident.  In this case however, it is clear to ATMnet 
> that ARIN deserves all our support simply because it is the right thing to 
> do for the health of a growing and vibrant industry.
> --
> Jim Browning <jfbb at ATMnet.net>
> CEO, ATMnet  <www.ATMnet.net>
> 
> 





From jfbb at ATMnet.net  Sat Mar 29 08:08:41 1997
From: jfbb at ATMnet.net (Jim Browning)
Date: Sat, 29 Mar 1997 00:08:41 -0800
Subject: ARIN is A Good Thing
Message-ID: <01BC3BD5.5CBB8FC0@jfbb.atmnet.net>

>From:  David Stoddard[SMTP:dgs at us.net]
>Sent:  Friday, March 28, 1997 10:30 PM
>
>	This message is in response to Jim Browning's support for ARIN.
>	It doesn't belong on NANOG, but because it originated there I
>	feel I have to address it.  Feel free to hit the "D" key now ...

Certainly more appropriate  than the DNS thread, and I believe that ^D is 
easy to use, but if a consensus is shown that it is off-topic, I will 
certainly abide by that consensus
>
>	While everyone is entitled to their opinion, ARIN is no magic
>	bullet and is the wrong answer for our industry.  The supporters
>	of ARIN seem to fall into several categories:
>
>	a)  You have a very small network and have NOTHING to lose if
>	      ARIN goes forward,

Define 'small'. Compared to MCI, or compared to a local ISP?

>	b)  You are filty rich and you don't mind paying big chunks of
>	      money for something that your tax dollars already support,

I don't fit that one...

>	c)  You are a Canadian or Mexican citizen and you are tired of the
>	      US Government managing the resources you require to run your
>	      business,

Not us...

>	d)  You work for an ISP, but as a technical person you have no idea
>	      what all this stuff costs and you really don't care,

I pay the bills.  I know...

>	e)  You are trying to suck up to the political structure because you
>	      are afraid to really voice your opposition,

Right.  That's why I posted flame bait...

>	f)  You are vying for a position in the ARIN organization, or

I will volunteer to help as I can, just as for IETF or NANOG...

>	g)  You really don't understand what this ARIN thing is anyhow.

I have been involved in the topic for a long time, have studied the 
proposal, and participated in the dialog.

I have also been an open critic of certain registry policies (esp. "slow 
start" that have hampered the growth of my business.

>	While the ARIN proposal has gotten much better in the past three
>	months, I still assert that there is *nothing* ARIN will give me
>	for my $10,000 per year allocation fee that I don't get right now from
>	the tax dollars I currently pay to support the National Science
>	Foundation.

Which are going/have gone (depending on who you ask)  away.  The IP 
services are being supported by DNS revenues. And anyway, if NSF funds are 
available for the support if IP Address allocation, I'm sure that ARIN 
would accept them, and adjust its fee structure accordingly.  ARIN is based 
on a cost recovery model.

>	*  It will take money that could have gone to support my network, my
>	   employees, and my customers, and instead divert that money to
>	   a yet another bureaucracy.
>	*  It will increase my costs, which will have to be passed along to
>	   my customers, which will effect my business.
>	*  It will not allow me to increase the size of my current address
>	   allocations any faster than the current InterNIC slow start
>	   policy allows (slow start has impacted us substantially in some
>	   of the school districts we have brought online -- at least Cisco
>	   has a product to address this dilemna [the PIX]).
>	*  It will not decrease the amount of time it takes to get a new
>	   allocation (although this has improved tremendously under
>	   Kim Hubbard's leadership).

Having to pay for this service is inevitable.  NSF support was temporary. 
 Using DNS revenues is unworkable in the long term, as DNS services will be 
spread over multiple entities and no longer able to support IP allocation, 
which isn't appropriate anyway...  Revenues should be associated with the 
cost drivers.  DNS revenues to support DNS services, IP Allocation fees to 
support IP registration.

>	Worse, if ARIN goes forward, my company will be forced to join and
>	support this organization because our very survival will depend upon
>	it.  This is equivalent to holding a gun to our head and extorting
>	us to pay the $10,000 (or more) annual fee.

You, or your customers, or someone else's customers, are paying for it 
*now* with DNS fees...
>
>	Frankly, this whole "pay for" address policy is crazy -- the InterNIC
>	made 60 million dollars PROFIT last year issuing domain names (while
>	funding the assignment of IP address space AT THE SAME TIME).  This
>	has to be the biggest money grab in history -- 60 million dollars
>	isn't enough for one monopoly to make?  Unbelievable.

Your numbers are inflated. Profits are what is left after you deduct your 
costs of doing business from your revenues.  If you are going to quote 
numbers as fact, please ensure that they are accurate.  Yours are 
definitely *not* accurate.  And do you realize that InterNIC related 
activities represent a minority of NSI's business, and a *tiny* fraction of 
those of its parent company?
>
<summary of ARIN proposal deleted>

>	> "It is of the utmost importance that the allocation of
>	> Internet Protocol (IP) addresses not be jeopardized by the
>	> turmoil currently surround the Domain Name System (DNS)"
>
>	The inference here is that by creating a costly new bureaucracy,
>	all our problems will go away.  I see absolutely NO evidence of
>	any legal or procedural mechanism that will prevent turmoil.  There
>	is only one IPv4 address space, so the concept of "alternate
>	registries" (aka, like the alternate TLD proposals) has no relevence
>	to address space allocation.  Comparing address space to domain
>	name allocation is comparing apples to oranges.

Exactly.  IP Address allocation must be separated from DNS registration, 
and before it gets caught up in the DNS 'morass'.  Do you think a federal 
judge would understand the difference between DNS and IP?  What would 
happen if a DNS litigant obtained a restraining order forcing NSI to cease 
InterNIC activities? Are you ready to go without new addresses while the 
courts addressed the situation?  Are you prepared to have IP Addresses 
handled by people without the experience Kim and her crew have developed? 
 Do want to stall the evolution of registration policies indefinitely, so 
that slow start remains cast in stone?

>	> "IP Addresses, on the other hand, are of operational concern, and
>	> timely and appropriate access to this resource is absolutely
>	> required for the continued growth of the Internet."
>
>	I put an allocation request in last Monday and received my new
>	allocation Thursday.  Even if allocation requests could be turned
>	around in one-hour, paying an annual $10K fee is not worth it
>	to speed the process up three days.  Think about it.

No, but dedicated funding is necessary to ensure that those services remain 
available.

>	> "Obtaining consensus on any important Internet related topic is
>	> excruciatingly difficult in today's environment.  Nowhere is
>	> this more obvious than in the debates over DNS and IP Addresses."
>
>	There is nothing about ARIN that says we will all be in concensus.
>	If anything, there will be tremendous dischord because we will have
>	hundreds of ISPs voicing their opinions at the semi-annual ARIN
>	meetings.  The current NSF sponsored system does not foster this
>	level of turmoil.  If anything, ARIN will turn the currently stable
>	IP address policy mechanism into a semi-annual slug fest.

The current situation is not stable, as the NSF support is gone...  ARIN 
maintains the current system as much as is possible given the change in 
funding status...

>	Slow start was an important policy to conserve address space and
>	(dispite is short comings) was a necessary at the time.  ARIN will
>	not eliminate slow start or any other policy.  Having a vote on the
>	ARIN board will not eliminate debate over IP address policy.

As a membership funded organization, ARIN will be more responsive to 
suggestions for policy change.  There has been much discussion of slow 
start on the appropriate lists (where my concerns are well known).  ARIN 
will accept changes to policies which are agreed to using established 
processes.

>	> "While ARIN has been a subject of hot debate, there is nonetheless
>	> a rough consensus within the Internet community that establishing
>	> a non-profit entity to handle the administration of this vital
>	> function is both necessary and appropriate."
>
>	There is one -- the same one that has been funded by the NSF since
>	the mid 1980's.  Why change something that has worked so well in
>	the past?  There are no substantive advantages to ARIN, and it will
>	cost all of us a lot more money.

Because it *has* to change.  The funding situation has changed, and we must 
change with it.

>	> "There are also issues which still need to be resolved, and a
>	> lot of work which needs to be done."
>
>	Anyone remember what it was like to register a domain name in 1994?
>	And we want to do that to our IP address allocation mechanism?
>	Start ARIN and then wait for the systems to fall in place?  I think
>	that is a recipe for total disaster.  It took YEARS for the current
>	InterNIC to get its act together.

And those resources will transition over to ARIN!  So will people, 
including Kim!  ARIN is not a start from scratch organization...
>
>	> "There is "running code" in the form of the people and systems
>	> currently performing the function, and the two similar entities
>	> (APNIC and RIPE) which are already in operation under similar
>	> charters."
>
>	APNIC and RIPE are not run by governmental entities and must charge
>	for address space in order to exist.  They get that address space
>	from the current system that is under control of the NSF.  As a US
>	taxpayer, I pay taxes to support the NSF.  Because the NSF has
>	alternate sources for its funding, ISPs and their customers do not
>	have to make direct payments for address space.  This keeps prices
>	for Internet access low.  Starting ARIN will not reduce your US
>	taxes, it will simply add to the cost of doing business.  For no
>	additional benefit.  Comparing APNIC and RIPE to the current US
>	model is not fair or accurate.

So if those funds are in fact available, then let's give them to ARIN and 
reduce the registration fees!!  And it is IANA which controls the address 
space, because the folks on this list accept IANA's decisions in that 
regard.  I'm not at all certain what would happen if NSF said one thing and 
IANA said another, but I would put my money on people following IANA.


>	> "It is time for ARIN to move forward unfettered by Federal
>	> intervention or oversight."
>
>	I believe (as a US citizen) that the Internet is strategic to the
>	United States, and control over the address space should remain with
>	the US Government.  The US funded the development of the Internet,
>	and there is a substantial portion of the US economy that is riding
>	on top of it.  Giving control over this strategic asset to a non-profit
>	organization that is beholden to nobody is foolishness.

So is the PSTN.  Does the U.S. government pay for the registration of phone 
numbers?  Order a new number and find out...

>	> "ARIN deserves all our support simply because it is the right
>	> thing to do for the health of a growing and vibrant industry."
>
>	Charging for IP addresses will raise the cost of an Internet
>	connection.  Raising costs will not improve the health of a growing
>	and vibrant industry -- it is anathma to our industry.

No, it does not increase the cost, it just stops using DNS fees to cover 
the costs.  I suspect that the smaller entity will in fact represent a 
*reduction* in the cost of registration services, as ARIN will not bear 
NSI's and SAIC's corporate overhead and G&A, which is substantial.
>
>	ARIN is the wrong answer for our industry.  As an example, in the
>	radio and television industry, members have fought for years
>	to prevent charges from being assessed against the limited radio
>	spectrum they use.  Compare this to ARIN, where we are trying to levy
>	substantial fees against members of our own industry.  ARIN is a bad
>	idea.  It will continue to be a bad idea because it will always cost
>	more that what we currently have with the NSF, and it will provide
>	no substantive benefit.  Slow start is not going away, and ARIN will
>	not quell address policy debates.  ARIN will hurt our industry, it
>	will make the Internet more expensive for customers, and it will
>	form yet another elite club.  Like I said in January, ARIN is
>	equivalent to throwing your money away.

Your primary argument is that NSF should cover the costs of IP 
registrations.  I maintain that ARIN in fact makes this much more 'doable' 
than the current situation, where the costs of IP allocations are 
commingled with the costs of domain registrations, which NSF has already 
decided should be user funded.  ARIN males it possible for the NSF to fund 
IP allocation services without also funding DNS services *IF* they chose to 
do so.
>
>	Unfortunately, like it or not, ARIN will probably go forward anyhow.
>	And we will be writing big expensive checks to ARIN to keep our
>	businesses running.  I urge people to speak up now if you think
>	ARIN is a bad idea.  Lets work together to reduce cost, not increase
>	cost.

I agree.  Let's reduce costs by putting IP Allocation services into a 
streamlined, low overhead, non-profit organization, staffed by people who 
have the experience to perform the required services as efficiently as 
possible, and tried and tested systems and procedures.  Let's convince NSF 
to at least partially fund that organization so that fees are minimal. 
 Let's provide Gb's of input into how that entity can do its job 
effectively, and define the policies it should follow.

Let's support that process now, and let's call that organization...

*** ARIN ***

--
Jim Browning
CEO, ATMnet





From GAVRON at ACES.COM  Sat Mar 29 09:11:16 1997
From: GAVRON at ACES.COM (Ehud Gavron)
Date: Sat, 29 Mar 1997 02:11:16 -0700 (MST)
Subject: ARIN is A Good Thing
In-Reply-To: "Your message dated Sat, 29 Mar 1997 00:08:41 -0800"
 <01BC3BD5.5CBB8FC0@jfbb.atmnet.net>
Message-ID: <01IH23Y6AYGG8WW0FK@ACES.COM>

	Morons.  You fight for paying less taxes April 15th, but
	act like sheep when it comes to analyzing simple business:

>Which are going/have gone (depending on who you ask)  away.  The IP
>services are being supported by DNS revenues.
...
>Having to pay for this service is inevitable.  NSF support was temporary.
> Using DNS revenues is unworkable in the long term, as DNS services will be
>spread over multiple entities and no longer able to support IP allocation,
>which isn't appropriate anyway...  Revenues should be associated with the
>cost drivers.  DNS revenues to support DNS services, IP Allocation fees to
>support IP registration.

	IF DNS pays for IP and the InterNIC made $60M profit DESPITE
	also doing IP, then clearly DNS fees are too high.

	IF ARIN means that IP pays for IP and the DNS funds are unfettered,
	then that $60M profit (in one year) would be much more than $60M.

	Personally I think ARIN is a piece of shit.  It's only that stupid
	because of arbitrary, capricious, and high pricing.  (See CIX, 1994).

	If ARIN had any iota of real power (i.e. if it had the backing of
	anyone real) and if it had real pricing (i.e. its costs were based on
	a cost-recovery model, not a make-lots-of-money-for-scumbags model)
	it would succeed.

	I'll give you a clue. Domain registrations pay for DNS and IP allocs
	and leave the Internic $60M in the black.  I'd say that means that
	your average ISP should pay _less_ for DNS and part of the difference
	applied to ARIN.

	With no offense to Internic, IANA, Jon, or Jbb.  If I have to pay
	the Internic (and I do) and they can also support IP (and they do)
	and come out $60M black (they do!) then they can damn well fund their
	own damn program to assign the goddamned addresses without billing me.

	Ehud
	p.s. As to the argument that "many nics mean that $50/domain won't
	cover IP" perhaps "many nics" is not a good idea.  Not if it hits
	every ISP out ther efor $5K-$10K/year.  Get a grip.


>>	Worse, if ARIN goes forward, my company will be forced to join and
>>	support this organization because our very survival will depend upon
>>	it.  This is equivalent to holding a gun to our head and extorting
>>	us to pay the $10,000 (or more) annual fee.

>You, or your customers, or someone else's customers, are paying for it
>*now* with DNS fees...
>>
>>	Frankly, this whole "pay for" address policy is crazy -- the InterNIC
>>	made 60 million dollars PROFIT last year issuing domain names (while
>>	funding the assignment of IP address space AT THE SAME TIME).  This
>>	has to be the biggest money grab in history -- 60 million dollars
>>	isn't enough for one monopoly to make?  Unbelievable.

>Your numbers are inflated. Profits are what is left after you deduct your
>costs of doing business from your revenues.  If you are going to quote
>numbers as fact, please ensure that they are accurate.  Yours are
>definitely *not* accurate.  And do you realize that InterNIC related
>activities represent a minority of NSI's business, and a *tiny* fraction of
>those of its parent company?
>>
><summary of ARIN proposal deleted>

>>	> "It is of the utmost importance that the allocation of
>>	> Internet Protocol (IP) addresses not be jeopardized by the
>>	> turmoil currently surround the Domain Name System (DNS)"
>>
>>	The inference here is that by creating a costly new bureaucracy,
>>	all our problems will go away.  I see absolutely NO evidence of
>>	any legal or procedural mechanism that will prevent turmoil.  There
>>	is only one IPv4 address space, so the concept of "alternate
>>	registries" (aka, like the alternate TLD proposals) has no relevence
>>	to address space allocation.  Comparing address space to domain
>>	name allocation is comparing apples to oranges.

>Exactly.  IP Address allocation must be separated from DNS registration,
>and before it gets caught up in the DNS 'morass'.  Do you think a federal
>judge would understand the difference between DNS and IP?  What would
>happen if a DNS litigant obtained a restraining order forcing NSI to cease
>InterNIC activities? Are you ready to go without new addresses while the
>courts addressed the situation?  Are you prepared to have IP Addresses
>handled by people without the experience Kim and her crew have developed?
> Do want to stall the evolution of registration policies indefinitely, so
>that slow start remains cast in stone?

>>	> "IP Addresses, on the other hand, are of operational concern, and
>>	> timely and appropriate access to this resource is absolutely
>>	> required for the continued growth of the Internet."
>>
>>	I put an allocation request in last Monday and received my new
>>	allocation Thursday.  Even if allocation requests could be turned
>>	around in one-hour, paying an annual $10K fee is not worth it
>>	to speed the process up three days.  Think about it.

>No, but dedicated funding is necessary to ensure that those services remain
>available.

>>	> "Obtaining consensus on any important Internet related topic is
>>	> excruciatingly difficult in today's environment.  Nowhere is
>>	> this more obvious than in the debates over DNS and IP Addresses."
>>
>>	There is nothing about ARIN that says we will all be in concensus.
>>	If anything, there will be tremendous dischord because we will have
>>	hundreds of ISPs voicing their opinions at the semi-annual ARIN
>>	meetings.  The current NSF sponsored system does not foster this
>>	level of turmoil.  If anything, ARIN will turn the currently stable
>>	IP address policy mechanism into a semi-annual slug fest.

>The current situation is not stable, as the NSF support is gone...  ARIN
>maintains the current system as much as is possible given the change in
>funding status...

>>	Slow start was an important policy to conserve address space and
>>	(dispite is short comings) was a necessary at the time.  ARIN will
>>	not eliminate slow start or any other policy.  Having a vote on the
>>	ARIN board will not eliminate debate over IP address policy.

>As a membership funded organization, ARIN will be more responsive to
>suggestions for policy change.  There has been much discussion of slow
>start on the appropriate lists (where my concerns are well known).  ARIN
>will accept changes to policies which are agreed to using established
>processes.

>>	> "While ARIN has been a subject of hot debate, there is nonetheless
>>	> a rough consensus within the Internet community that establishing
>>	> a non-profit entity to handle the administration of this vital
>>	> function is both necessary and appropriate."
>>
>>	There is one -- the same one that has been funded by the NSF since
>>	the mid 1980's.  Why change something that has worked so well in
>>	the past?  There are no substantive advantages to ARIN, and it will
>>	cost all of us a lot more money.

>Because it *has* to change.  The funding situation has changed, and we must
>change with it.

>>	> "There are also issues which still need to be resolved, and a
>>	> lot of work which needs to be done."
>>
>>	Anyone remember what it was like to register a domain name in 1994?
>>	And we want to do that to our IP address allocation mechanism?
>>	Start ARIN and then wait for the systems to fall in place?  I think
>>	that is a recipe for total disaster.  It took YEARS for the current
>>	InterNIC to get its act together.

>And those resources will transition over to ARIN!  So will people,
>including Kim!  ARIN is not a start from scratch organization...
>>
>>	> "There is "running code" in the form of the people and systems
>>	> currently performing the function, and the two similar entities
>>	> (APNIC and RIPE) which are already in operation under similar
>>	> charters."
>>
>>	APNIC and RIPE are not run by governmental entities and must charge
>>	for address space in order to exist.  They get that address space
>>	from the current system that is under control of the NSF.  As a US
>>	taxpayer, I pay taxes to support the NSF.  Because the NSF has
>>	alternate sources for its funding, ISPs and their customers do not
>>	have to make direct payments for address space.  This keeps prices
>>	for Internet access low.  Starting ARIN will not reduce your US
>>	taxes, it will simply add to the cost of doing business.  For no
>>	additional benefit.  Comparing APNIC and RIPE to the current US
>>	model is not fair or accurate.

>So if those funds are in fact available, then let's give them to ARIN and
>reduce the registration fees!!  And it is IANA which controls the address
>space, because the folks on this list accept IANA's decisions in that
>regard.  I'm not at all certain what would happen if NSF said one thing and
>IANA said another, but I would put my money on people following IANA.


>>	> "It is time for ARIN to move forward unfettered by Federal
>>	> intervention or oversight."
>>
>>	I believe (as a US citizen) that the Internet is strategic to the
>>	United States, and control over the address space should remain with
>>	the US Government.  The US funded the development of the Internet,
>>	and there is a substantial portion of the US economy that is riding
>>	on top of it.  Giving control over this strategic asset to a non-profit
>>	organization that is beholden to nobody is foolishness.

>So is the PSTN.  Does the U.S. government pay for the registration of phone
>numbers?  Order a new number and find out...

>>	> "ARIN deserves all our support simply because it is the right
>>	> thing to do for the health of a growing and vibrant industry."
>>
>>	Charging for IP addresses will raise the cost of an Internet
>>	connection.  Raising costs will not improve the health of a growing
>>	and vibrant industry -- it is anathma to our industry.

>No, it does not increase the cost, it just stops using DNS fees to cover
>the costs.  I suspect that the smaller entity will in fact represent a
>*reduction* in the cost of registration services, as ARIN will not bear
>NSI's and SAIC's corporate overhead and G&A, which is substantial.
>>
>>	ARIN is the wrong answer for our industry.  As an example, in the
>>	radio and television industry, members have fought for years
>>	to prevent charges from being assessed against the limited radio
>>	spectrum they use.  Compare this to ARIN, where we are trying to levy
>>	substantial fees against members of our own industry.  ARIN is a bad
>>	idea.  It will continue to be a bad idea because it will always cost
>>	more that what we currently have with the NSF, and it will provide
>>	no substantive benefit.  Slow start is not going away, and ARIN will
>>	not quell address policy debates.  ARIN will hurt our industry, it
>>	will make the Internet more expensive for customers, and it will
>>	form yet another elite club.  Like I said in January, ARIN is
>>	equivalent to throwing your money away.

>Your primary argument is that NSF should cover the costs of IP
>registrations.  I maintain that ARIN in fact makes this much more 'doable'
>than the current situation, where the costs of IP allocations are
>commingled with the costs of domain registrations, which NSF has already
>decided should be user funded.  ARIN males it possible for the NSF to fund
>IP allocation services without also funding DNS services *IF* they chose to
>do so.
>>
>>	Unfortunately, like it or not, ARIN will probably go forward anyhow.
>>	And we will be writing big expensive checks to ARIN to keep our
>>	businesses running.  I urge people to speak up now if you think
>>	ARIN is a bad idea.  Lets work together to reduce cost, not increase
>>	cost.

>I agree.  Let's reduce costs by putting IP Allocation services into a
>streamlined, low overhead, non-profit organization, staffed by people who
>have the experience to perform the required services as efficiently as
>possible, and tried and tested systems and procedures.  Let's convince NSF
>to at least partially fund that organization so that fees are minimal.
> Let's provide Gb's of input into how that entity can do its job
>effectively, and define the policies it should follow.

>Let's support that process now, and let's call that organization...

>*** ARIN ***

>--
>Jim Browning
>CEO, ATMnet





From davidc at apnic.net  Sat Mar 29 10:22:35 1997
From: davidc at apnic.net (David R. Conrad)
Date: Sat, 29 Mar 1997 19:22:35 +0900
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: Your message of "Sat, 29 Mar 1997 01:29:57 EST."
             <199703290629.BAA15441@us.net> 
Message-ID: <199703291022.TAA17136@palmtree.jp.apnic.net>

[note reply-to and cc]

David,

>While everyone is entitled to their opinion, ARIN is no magic
>bullet and is the wrong answer for our industry.  

I don't think anyone is arguing it is a magic bullet.  Whether it is
the right or wrong answer would depend, I guess, on your view of the
role of the US government in an international industry.

>I still assert that there is *nothing* ARIN will give me 
>for my $10,000 per year allocation fee 

Recently, at the APNIC meeting held in Hong Kong, the APNIC membership
voted to modify the APNIC pricing structure, the procedures by which
APNIC allocates the initial block of address space to new ISPs, and
whether or not APNIC should operate a service that could conceivably
compete with services offered by the membership.

How exactly do _you_ influence how InterNIC operates?

>that I don't get right now from 
>the tax dollars I currently pay to support the National Science 
>Foundation.

Your tax dollars are NOT funding address allocation.

> *  It will take money that could have gone to support my network, my
>    employees, and my customers, and instead divert that money to 
>    a yet another bureaucracy.

TANSTAAFL.  Somebody has to pay for registry services.  Right now,
they are being paid for by the domain name charges.  Do you really
want something as critical to your business as address allocations
dependent on NSI given the myriad lawsuits against NSI over domain
issues?

> *  It will increase my costs, which will have to be passed along to
>    my customers, which will effect my business.

Let's look at this a bit (simplifying and not to pick on US.NET, but...):

Size    Fee             Amt of space    Per address per year fee
------------------------------------------------------------------------------
Small   $2500/year      /24 - /19       $9.77 - $0.31
Medium  $5000/year      >/19 - /16      $0.61 - $0.08
Large   $10K/year       >/16 - /14      $0.15 - $0.04
X-Large $20K/year       >/14            $0.08 -> $0.00

So, lets say you have a customer to which you'll be assigning a /22.
Presumably you wouldn't eat the costs if they were a significant
portion of the income you derive from a customer.  Given you indicate
you'd fall in to the "Large" category, this would mean you'll be
passing along a US $3.41 to $12.80 per month cost increase or less
that what you charge for secondarying the customer's domain in the
worst case.  

To be more complete:

                                          % of US.NET's Connect costs*
       monthly "Evil Registry Surcharge"  128K/56K               T1
Prefix     min               max        min     max          min     max
------------------------------------------------------------------------------
/32       $0.0033          $0.0125    0.0011% 0.0042%      0.0003% 0.0013%
/31       $0.0067          $0.0250    0.0023% 0.0085%      0.0007% 0.0025%
/30       $0.01            $0.05      0.0045% 0.0169%      0.0013% 0.0050%
/29       $0.02            $0.10      0.0090% 0.0339%      0.0027% 0.0101%
/28       $0.05            $0.20      0.0181% 0.0678%      0.0054% 0.0201%
/27       $0.10            $0.40      0.0362% 0.1356%      0.0107% 0.0402%
/26       $0.21            $0.80      0.0723% 0.2712%      0.0214% 0.0804%
/25       $0.42            $1.60      0.1446% 0.5424%      0.0429% 0.1608%
/24       $0.85            $3.20      0.2893% 1.0847%      0.0858% 0.3216%
/23       $1.70            $6.40      0.5785% 2.1695%      0.1715% 0.6432%
/22       $3.41           $12.80      1.1571% 4.3390%      0.3430% 1.2864%
/21       $6.82           $25.60      2.3141% 8.6780%      0.6861% 2.5729%
/20      $13.65           $51.20      4.6282% 17.3559%     1.3722% 5.1457%

(*) connect costs taken from http://www.us.net/prices/serv-business.html

Also, while I hesitate to mention it, a possible implication: to avoid
the ERS to those nasty registry people, maybe your customers would
only ask for the amount of address space they NEED?

> *  It will not allow me to increase the size of my current address 
>    allocations any faster than the current InterNIC slow start 
>    policy allows

NOT "InterNIC slow start" -- ALL registries must use slow start and
besides, it was originally implemented at RIPE.

I will note in passing: in the case of APNIC, the membership voted to
change our allocation policy such that it DID directly impact the
amount of address space a new ISP obtains.  Of course, we still have
to abide by the global restrictions of RFC 2050, but the methods by
which the registries follow those restrictions are at the descretion
of the membership.  Presumably this will be the case for ARIN as well.

>This is equivalent to holding a gun to our head and extorting 
>us to pay the $10,000 (or more) annual fee.

Does your electric company extort money from you too?

>the InterNIC
>made 60 million dollars PROFIT last year issuing domain names (while
>funding the assignment of IP address space AT THE SAME TIME).  This
>has to be the biggest money grab in history -- 60 million dollars
>isn't enough for one monopoly to make?  Unbelievable.

You do understand that ARIN is an attempt to make address allocation
independent of NSI and under the discretion of the people who need the
resource ARIN allocates, right?

>The inference here is that by creating a costly new bureaucracy,
>all our problems will go away.  I see absolutely NO evidence of
>any legal or procedural mechanism that will prevent turmoil.  

Please see RIPE-NCC and APNIC.  There doesn't appear to be much
turmoil in either of those organizations.

>There is only one IPv4 address space, so the concept of "alternate
>registries" (aka, like the alternate TLD proposals) has no relevence
>to address space allocation.  Comparing address space to domain
>name allocation is comparing apples to oranges.

No.  The one thing domain name delegation and address allocation have
in common is that they both reply on the Internet community to be
implemented.  If the eDNS crowd ever get a significant following
(e.g., a major service provider takes them seriously), they will be
relevant.  If an AntiNIC becomes established, it would have exactly
the same requirements for relevancy.

>I put an allocation request in last Monday and received my new
>allocation Thursday.  Even if allocation requests could be turned
>around in one-hour, paying an annual $10K fee is not worth it
>to speed the process up three days.  Think about it.

Scenario: NSI loses one of the lawsuits against it.  NSI must pay
damages, etc.  NSI declares bankruptcy.  How long will it take you to
get your IP address space?  Of course, this would never happen.

>There is nothing about ARIN that says we will all be in concensus.
>If anything, there will be tremendous dischord because we will have
>hundreds of ISPs voicing their opinions at the semi-annual ARIN
>meetings.  The current NSF sponsored system does not foster this
>level of turmoil.  If anything, ARIN will turn the currently stable
>IP address policy mechanism into a semi-annual slug fest.

I'm surprised you take such a dim view of democracy and such a
positive view of (arguably enlightened) autocracy.

>There is one -- the same one that has been funded by the NSF since
>the mid 1980's.  Why change something that has worked so well in
>the past?  

The cooperative agreement that created InterNIC (in 1992, not the
mid-80's) expires in '98.  NSF has (in the past) been uninterested in
supporting production services (they are research oriented after all).
As such, it is reasonable to assume they'll not be particularly
interested in continuing in their oversight of the Americas registry
system.

>APNIC and RIPE are not run by governmental entities 

Neither is the registration portion of InterNIC.  Is is operated by a
commercial entity under a cooperative agreement with the NSF.

>They get that address space
>from the current system that is under control of the NSF.  

No.  We get our address space from the IANA, which was funded by DARPA.

>Comparing APNIC and RIPE to the current US model is not fair or
>accurate.

True.  Where APNIC and RIPE members have direct input into how their
registries are operated, American (and South African) ISPs are subject
to the political winds of the US government.  Where APNIC and RIPE
members control how resources are expended, American (and South
African) ISPs must abide by a commercial company's decisions as
(theoretically) moderated by the NSF.  Where APNIC and RIPE members
take responsibility for the administration of the resource on which
they depend, American (and South African) ISPs rely on the US
government to play mommy.

>I believe (as a US citizen) that the Internet is strategic to the
>United States, and control over the address space should remain with
>the US Government.  

And just how does the US government control the address space now?

>Giving control over this strategic asset to a non-profit
>organization that is beholden to nobody is foolishness.

Please see what 501c6 means.  The non-profit organization would be
beholden to the industry it supports.

>Charging for IP addresses will raise the cost of an Internet
>connection.  Raising costs will not improve the health of a growing
>and vibrant industry -- it is anathma to our industry.

I'm surprised you, as a businessman, would have this attitude towards
government intervention in free trade.  Oh, right, as long as it is a
subsidy its OK.

>Lets work together to reduce cost, not increase cost.

And how would you go about doing this, given you have no input as to
how the registry operates?

Regards,
-drc





From Brian_Murrell at bctel.net  Sat Mar 29 10:36:07 1997
From: Brian_Murrell at bctel.net (Brian Murrell)
Date: Sat, 29 Mar 1997 02:36:07 -0800 (PST)
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <3.0.1.32.19970328153753.009e5908@mktg_srv.ascend.com> from "Kevin Smith" at Mar 28, 97 03:37:53 pm
Message-ID: <199703291036.CAA08345@mocha.bctel.net>

As enscripted by Kevin Smith:
> 
> Any email...even regular questions/replies....I think specific
> types of email would be more appropriate..."spam","obscene" etc.

Kevin,

We meet again.  The circles certainly seem small at times.  I question
your comments regarding AT&T Worldnet's announcement.  I read it as
clearly stating that _any_ mail (not limited to spam or obscene, etc.)
being relayed (not to or from an AT&T Worldnet customer) will not be
delivered by AT&T Worldnet's mail servers.  I have three things to say,
each from a different point of view.

1. As a frequent recipient of spam delivered by AT&T Worldnet: it's about
   time.  See number 2.

2. As above and a proponent of the open Internet: Yay, another provider
   taking control and repsonsibility for their participation in the
   Internet.

3. As a system admin at an ISP: I don't blame 'em.  I have investigated
   methods for doing this myself and will be proposing early next week
   that we take the same measures.  Nobody has an obligation to relay any
   mail for any other body on the Internet.

If more mail servers on the Internet took these measures, the level of
spam would come down due to the easier job of finding the real point of
origin of the spam.

Take care Kevin,
b.

-- 
Brian J. Murrell                                        Brian_Murrell at bctel.net
BCTel Advanced Communications                                   brian at ilinx.com
Vancouver, B.C.                                                brian at wimsey.com
604 454 5279




From mje at mje99.posix.co.za  Sat Mar 29 13:50:42 1997
From: mje at mje99.posix.co.za (Mark J Elkins)
Date: Sat, 29 Mar 1997 15:50:42 +0200
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: "David R. Conrad" <davidc@APNIC.NET>
       "Re: ARIN is not/is too/is not/is too... blah." (Mar 29,  7:22pm)
Message-ID: <199703291350.PAA31653@mje99.posix.co.za>

On Mar 29,  7:22pm, "David R. Conrad" wrote:
} >Comparing APNIC and RIPE to the current US model is not fair or
} >accurate.
} 
} True.  Where APNIC and RIPE members have direct input into how their
} registries are operated, American (and South African) ISPs are subject
} to the political winds of the US government.  Where APNIC and RIPE
} members control how resources are expended, American (and South
} African) ISPs must abide by a commercial company's decisions as
} (theoretically) moderated by the NSF.  Where APNIC and RIPE members
} take responsibility for the administration of the resource on which
} they depend, American (and South African) ISPs rely on the US
} government to play mommy.
}-- End of excerpt from "David R. Conrad"

I'm from South Africa.  The fact that we are so tied to the USA upsets
me.  I also administer the 'co.za' domain - probably the largest domain
in Africa - with (as of writing) 5607 registered names.

Many folk have stated that Africa should have its own NIC.  It would
make most sense that DNS, ASN and IP Allocation came from one place.
Adopting the line of 'slow startup' - I approached the InterNIC for a
single superblock of Class C addresses - to start attending with some
of the local address problems - and have currently been refused.

I'm not planning on running all this myself - but it would be unfair
to expect any organisation to suddently have the full required
infrastructure to run everything that a full blown NIC probably should
have.  Sure there are a number of people talking about getting this
going - but thats all - just talking.  The AfricanNIC has to start
somehow - and a slow start is the Internet Way.

So whom do I petition?

Oh - my personal interests range as far as Central Africa - Zaire -
etc...  This is not just a local South African only thing.


-- 
  .  .     ___. .__      Olivetti Systems & Networks, Unix Support - Sth Africa
 /| /|       / /__       mje at posix.co.za  -  Mark J Elkins, SCO ACE, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 11 456 3125  Cell: +27 82 601 0496




From paul at vix.com  Sat Mar 29 15:54:54 1997
From: paul at vix.com (Paul A Vixie)
Date: Sat, 29 Mar 1997 07:54:54 -0800
Subject: ARIN is A Good Thing 
In-Reply-To: Your message of "Sat, 29 Mar 1997 02:11:16 MST."
             <01IH23Y6AYGG8WW0FK@ACES.COM> 
Message-ID: <199703291554.HAA16965@wisdom.home.vix.com>

Ehud wrote:

> With no offense to Internic, IANA, Jon, or Jbb.  If I have to pay the
> Internic (and I do) [1] and they can also support IP (and they do) [2]
> and come out $60M black (they do!) then they can damn well fund their [3]
> own damn program to assign the [4] goddamned addresses without billing me.

I added the [#] notations above so I could comment in detail.  [1] you do
not have to pay the InterNIC -- there's always .US, and once IAHC's proposal
gets going, you will be able to select among other alternatives as well (and
my expectation is that .COM et al will become a shared gTLD in 1998).  [2]
you're right that they support IP, but remember the golden rule: whoever has
the gold makes the rules.  Leaving InterNIC to support this means that they
(InterNIC rather than Kim personally or any ISP) get to decide _how_ they
support it.  They don't presently have to do anything you agree with.  [3] 
it's not their program, it was NSF's program most recently, and believe me
when I tell you that you don't WANT it to be "InterNIC's program".  Finally,
[4] to assign is to assert some form of ownership.  I'd much rather see the
ISP's, with Kim continuing as coordinator reporting a board of ISP "regents",
assign and therefore assert ownership of, the address pool.




From kimh at internic.net  Sat Mar 29 16:19:39 1997
From: kimh at internic.net (Kim Hubbard)
Date: Sat, 29 Mar 1997 11:19:39 -0500 (EST)
Subject: ARIN is *NOT* A Good Thing
In-Reply-To: <199703290629.BAA15441@us.net> from "David Stoddard" at Mar 29, 97 01:29:57 am
Message-ID: <199703291619.LAA02998@jazz.internic.net>

>
Dave,
 
> 	While the ARIN proposal has gotten much better in the past three
> 	months, I still assert that there is *nothing* ARIN will give me 
> 	for my $10,000 per year allocation fee that I don't get right now from 
> 	the tax dollars I currently pay to support the National Science 
> 	Foundation.

Name one allocation policy that you have had a say in.  ARIN will give you
that opportunity.  While you don't have to join ARIN, its members will have
the opportunity to influence policy on something that affects your business.

> 	Frankly, this whole "pay for" address policy is crazy -- the InterNIC
> 	made 60 million dollars PROFIT last year issuing domain names (while
> 	funding the assignment of IP address space AT THE SAME TIME).  This
> 	has to be the biggest money grab in history -- 60 million dollars
> 	isn't enough for one monopoly to make?  Unbelievable.

As has been pointed out, your numbers are totally wrong.  
> 
> 	There is nothing about ARIN that says we will all be in concensus.
> 	If anything, there will be tremendous dischord because we will have
> 	hundreds of ISPs voicing their opinions at the semi-annual ARIN
> 	meetings.  The current NSF sponsored system does not foster this
> 	level of turmoil.  If anything, ARIN will turn the currently stable
> 	IP address policy mechanism into a semi-annual slug fest.
>
I don't know, I get quite a bit of turmoil everyday :-)  At least with ARIN
I'll be allocating address space based on what the consensus of ISPs in
our region want and need.
  
> 	Slow start was an important policy to conserve address space and
> 	(dispite is short comings) was a necessary at the time.  ARIN will
> 	not eliminate slow start or any other policy.  Having a vote on the
> 	ARIN board will not eliminate debate over IP address policy.
>
No, but there are many changes that could be made to improve the current
policies and procedures but without some form of community discussion and
consensus they won't happen.  It took 18 months to get the current IP
allocation policies approved for BCP and they were actually outdated long
before that happened.  

> 	> "While ARIN has been a subject of hot debate, there is nonetheless
> 	> a rough consensus within the Internet community that establishing 
> 	> a non-profit entity to handle the administration of this vital 
> 	> function is both necessary and appropriate."
> 
> 	There is one -- the same one that has been funded by the NSF since
> 	the mid 1980's.  Why change something that has worked so well in
> 	the past?  There are no substantive advantages to ARIN, and it will
> 	cost all of us a lot more money.

Because NSF is no longer funding IP allocation.  The cooperative agreement
between NSF and NSI ends next year, are you saying that NSI should continue
administering IP space after the cooperative agreement ends?

> 
> 	APNIC and RIPE are not run by governmental entities and must charge
> 	for address space in order to exist.  They get that address space
> 	from the current system that is under control of the NSF.  As a US
> 	taxpayer, I pay taxes to support the NSF.  Because the NSF has 
> 	alternate sources for its funding, ISPs and their customers do not
> 	have to make direct payments for address space.  This keeps prices
> 	for Internet access low.  Starting ARIN will not reduce your US
> 	taxes, it will simply add to the cost of doing business.  For no
> 	additional benefit.  Comparing APNIC and RIPE to the current US
> 	model is not fair or accurate.

You do not pay for IP support with your tax dollars, everyone else pays for
your IP support with their DNS money.

> 
> 	I believe (as a US citizen) that the Internet is strategic to the
> 	United States, and control over the address space should remain with
> 	the US Government.  The US funded the development of the Internet,
> 	and there is a substantial portion of the US economy that is riding
> 	on top of it.  Giving control over this strategic asset to a non-profit
> 	organization that is beholden to nobody is foolishness.

ARIN isn't going to control anything, it's members, along with the IANA will
be determining policies and procedures.
> 
> 	Charging for IP addresses will raise the cost of an Internet
> 	connection.  Raising costs will not improve the health of a growing
> 	and vibrant industry -- it is anathma to our industry.
> 
> 	ARIN is the wrong answer for our industry.  As an example, in the
> 	radio and television industry, members have fought for years
> 	to prevent charges from being assessed against the limited radio
> 	spectrum they use.  Compare this to ARIN, where we are trying to levy
> 	substantial fees against members of our own industry.  ARIN is a bad
> 	idea.  It will continue to be a bad idea because it will always cost
> 	more that what we currently have with the NSF, and it will provide
> 	no substantive benefit.  Slow start is not going away, and ARIN will
> 	not quell address policy debates.  ARIN will hurt our industry, it
> 	will make the Internet more expensive for customers, and it will
> 	form yet another elite club.  Like I said in January, ARIN is
> 	equivalent to throwing your money away.
 
You're right, you will have to pay for a service that has been "free" because
the US government decided to stop subsidizing this service.  But is it
their responsibility to continue subsidizing your business?

Kim






From jcurran at bbnplanet.com  Sat Mar 29 17:09:15 1997
From: jcurran at bbnplanet.com (John Curran)
Date: Sat, 29 Mar 1997 12:09:15 -0500
Subject: ARIN is *NOT* A Good Thing
Message-ID: <v02140b11af62fb8ff6fe@[192.52.71.233]>

At 1:29 3/29/97, David Stoddard wrote:
>
>The inference here is that by creating a costly 
>new bureaucracy, all our problems will go away.  

The inference is that we can have IP address 
allocations being made by a relatively nimble
non-profit if we take the steps to establish 
such now.  

There is a very real difference between a large 
for-profit company working under the goverment
cooperative agreement and a small standalone
operation running under member goverance.

I don't think creating ARIN solves the world's
problems, but I do think it provides a solid
path forward for IP administration in a very
uncertain world.

/John






From aleph1 at dfw.net  Sat Mar 29 17:37:20 1997
From: aleph1 at dfw.net (Aleph One)
Date: Sat, 29 Mar 1997 11:37:20 -0600 (CST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <199703291022.TAA17136@palmtree.jp.apnic.net>
Message-ID: <Pine.SUN.3.94.970329113351.1141A-100000@dfw.dfw.net>

On Sat, 29 Mar 1997, David R. Conrad wrote:

> Size    Fee             Amt of space    Per address per year fee
> ------------------------------------------------------------------------------
> Small   $2500/year      /24 - /19       $9.77 - $0.31
> Medium  $5000/year      >/19 - /16      $0.61 - $0.08
> Large   $10K/year       >/16 - /14      $0.15 - $0.04
> X-Large $20K/year       >/14            $0.08 -> $0.00

   I'am I the only one that finds that the fact that the prices actually
*decrease* the larger the address blocks is disturbing? Not only does it
make entrace into the ISP market more difficult, but it allows the
creation of a highly profitable market for the resale of IP addresses if
you buy then in bulk to beging with (yeah, yeah I know about allocation
policies, but I seen people get large blocks easily).

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 





From mpearson at games-online.com  Sat Mar 29 18:39:25 1997
From: mpearson at games-online.com (Matthew Pearson)
Date: Sat, 29 Mar 1997 13:39:25 -0500
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.SUN.3.94.970329113351.1141A-100000@dfw.dfw.net>
References: <199703291022.TAA17136@palmtree.jp.apnic.net>
Message-ID: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com>

At 11:37 AM 3/29/97 -0600, Aleph One wrote:
>On Sat, 29 Mar 1997, David R. Conrad wrote:
>
>> Size    Fee             Amt of space    Per address per year fee
>>
------------------------------------------------------------------------------
>> Small   $2500/year      /24 - /19       $9.77 - $0.31
>> Medium  $5000/year      >/19 - /16      $0.61 - $0.08
>> Large   $10K/year       >/16 - /14      $0.15 - $0.04
>> X-Large $20K/year       >/14            $0.08 -> $0.00
>
>   I'am I the only one that finds that the fact that the prices actually
>*decrease* the larger the address blocks is disturbing? Not only does it
>make entrace into the ISP market more difficult, but it allows the
>creation of a highly profitable market for the resale of IP addresses if
>you buy then in bulk to beging with (yeah, yeah I know about allocation
>policies, but I seen people get large blocks easily).
>

I feel that it is disturbing as well. Since IP addresses are supposed to
come from a non-profit organization all prices should be equal. Why should
US Sprint get a deal (not to single them out.. take any HUGE network
provider) on addresses and then have ARIN stick it to smaller NSPs such as
our own.

It makes no sense...

Not to mention you will then create 2nd level IP allocation companies. I
could pay the bucks, misfile the paperwork and get a /14 or two and then
resell smaller blocks for less than ARIN's prices to NSPs starving for
address space.

Gimme a break.

Just my $.02, no flames made nor requested





From JimFleming at unety.net  Sat Mar 29 18:40:43 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 29 Mar 1997 12:40:43 -0600
Subject: ARIN is not/is too/is not/is too... blah.
Message-ID: <01BC3C3E.6BAD7520@webster.unety.net>

On Saturday, March 29, 1997 7:50 AM, Mark J Elkins[SMTP:mje at mje99.posix.co.za] wrote:
@ On Mar 29,  7:22pm, "David R. Conrad" wrote:
@ } >Comparing APNIC and RIPE to the current US model is not fair or
@ } >accurate.
@ } 
@ } True.  Where APNIC and RIPE members have direct input into how their
@ } registries are operated, American (and South African) ISPs are subject
@ } to the political winds of the US government.  Where APNIC and RIPE
@ } members control how resources are expended, American (and South
@ } African) ISPs must abide by a commercial company's decisions as
@ } (theoretically) moderated by the NSF.  Where APNIC and RIPE members
@ } take responsibility for the administration of the resource on which
@ } they depend, American (and South African) ISPs rely on the US
@ } government to play mommy.
@ }-- End of excerpt from "David R. Conrad"
@ 
@ I'm from South Africa.  The fact that we are so tied to the USA upsets
@ me.  I also administer the 'co.za' domain - probably the largest domain
@ in Africa - with (as of writing) 5607 registered names.
@ 
@ Many folk have stated that Africa should have its own NIC.  It would
@ make most sense that DNS, ASN and IP Allocation came from one place.
@ Adopting the line of 'slow startup' - I approached the InterNIC for a
@ single superblock of Class C addresses - to start attending with some
@ of the local address problems - and have currently been refused.
@ 

Who did you talk to or contact ?
Did you contact the NSF ?

@ I'm not planning on running all this myself - but it would be unfair
@ to expect any organisation to suddently have the full required
@ infrastructure to run everything that a full blown NIC probably should
@ have.  Sure there are a number of people talking about getting this
@ going - but thats all - just talking.  The AfricanNIC has to start
@ somehow - and a slow start is the Internet Way.
@ 

You have to start somewhere. People who already
have all of the "nic" infrastructure are not going to
give you much help building yours, because they
want to try to control the industry.

Your task is large but it is not impossible.
There are many activities that you might want to
consider as you proceed. Here is a short list:

	1. Get the buy-in from 4 or 5 ISPs that have
		existing facilities to handle the basics
		and pick a name and banner to rally
		around.

	2. Get the buy-in of your elected officials
		and have them contact the U.S. State Department
		and the National Science Foundation.

	3. Deploy a confederation of TRUE Root Name Servers
		similar to the eDNS confederation (http://www.edns.net)

	4. Develop a Registration Authority (RA) to help cultivate
		the growth of TLD Registries.

	5. Develop one or more TLD Registries to develop some
		of the infrastructure and business community awareness
		needed to support the Internet Registry industry in
		an area.

	6. Help with IPv4 ecology and reclamation efforts and plan
		to take over the management of an existing /8
		once you have enough infrastructure in place.

@ So whom do I petition?
@ 
@ Oh - my personal interests range as far as Central Africa - Zaire -
@ etc...  This is not just a local South African only thing.
@ 

Just as your range is a wide area of Africa,
the topics the Registry Industry touches
cover the gamut. It is important to develop
and demonstrate the infrastructure needed
to handle domain names, IP addresses, etc.

As more and more products and services
are added to the Registry Industry, the
companies that you help to develop will
be the natural candidates to provide the
region with the Internet Infrastructure
management that is needed to grow
the region in an organized way.

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From randy at psg.com  Sat Mar 29 18:58:00 1997
From: randy at psg.com (Randy Bush)
Date: Sat, 29 Mar 97 10:58 PST
Subject: ARIN is not/is too/is not/is too... blah.
References: <199703291022.TAA17136@palmtree.jp.apnic.net>
	<Pine.SUN.3.94.970329113351.1141A-100000@dfw.dfw.net>
	<3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com>
Message-ID: <m0wB3Kq-000IY4C@roam.psg.com>

>>   I'am I the only one that finds that the fact that the prices actually
>> *decrease* the larger the address blocks is disturbing?
> I feel that it is disturbing as well. Since IP addresses are supposed to
> come from a non-profit organization all prices should be equal.

You seem to have a model that the IP space is being sold as if it were a
commodity.  What is being charged are the services.  Please read the ARIN
proposal.

randy




From michael at memra.com  Sat Mar 29 19:09:42 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 29 Mar 1997 11:09:42 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com>
Message-ID: <Pine.BSI.3.93.970329105749.13595e-100000@sidhe.memra.com>

On Sat, 29 Mar 1997, Matthew Pearson wrote:

> >   I'am I the only one that finds that the fact that the prices actually
> >*decrease* the larger the address blocks is disturbing? 

> I feel that it is disturbing as well. Since IP addresses are supposed to
> come from a non-profit organization all prices should be equal. Why should
> US Sprint get a deal (not to single them out.. take any HUGE network
> provider) on addresses and then have ARIN stick it to smaller NSPs such as
> our own.
> 
> It makes no sense...

That's because you are misunderstanding what is happening. ARIN is not
selling IP addresses, If you want the costs to be spread evenly among all
ISP's then you can join ARIN and have a say in doing this but please be
aware that this will likely result in Sprint paying LESS and you paying
MORE. The fact is that in order to be independent of government, ARIN has
to pay its own way. This means that the members of ARIN and the users of
ARIN's services must divide the costs between them somehow. If you have a
better plan that takes into consideration ALL costs then please propose it
on the ARIN list. In fact, since ARIN is a member-run non-profit
organization, it is a certainty that if real costs go down, then fees will
also go down. This is what happened in Europe with RIPE.

> Not to mention you will then create 2nd level IP allocation companies. I
> could pay the bucks, misfile the paperwork and get a /14 or two and then
> resell smaller blocks for less than ARIN's prices to NSPs starving for
> address space.

This will not happen unless you lie to ARIN and forge documents to back up
your lies. If this did happen, not only would your criminal behavior be
made public but I would urge the FBI to lay charges against you. If the
FBI would not do this I would urge ISOC and EFF to file a civil suit
against you. I suspect the FTC would also have some interest if you are
selling IP addresses which you do not own since IP addresses are not
things which you buy, they are also not things which you can sell.

I don't understand why so many people want to push these ideas to reductio
ad absurdum. We all rely on a cooperative network in order to support our
businesses. Without a cooperative network there is no industry and we
would all be out of work. Why can you not see that ARIN is just another
form of cooperation in keeping the network running smoothly so that we can
all get on with business. As the network gets bigger there are more and
more activities that it makes sense to carve out and run autonomously.


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From aleph1 at dfw.net  Sat Mar 29 19:16:51 1997
From: aleph1 at dfw.net (Aleph One)
Date: Sat, 29 Mar 1997 13:16:51 -0600 (CST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <m0wB3Kq-000IY4C@roam.psg.com>
Message-ID: <Pine.SUN.3.94.970329131244.11190B-100000@dfw.dfw.net>

On Sat, 29 Mar 1997, Randy Bush wrote:

> You seem to have a model that the IP space is being sold as if it were a
> commodity.  What is being charged are the services.  Please read the ARIN
> proposal.

You misunderstand. ARIN may not sell IP space as if it where a commodity.
But by making cheaper large IP address blocks than smaller ones is allows
the creation of just such a commodity market at a second level. In anycase
how is a smaller block allocationa a chaper "service" than a smaller one?
They should all cost the same per IP address, or even increaser as the
block gets larger to give an incentive for intelligent use of address
space, aggregation, and things like NAT. Not the other way around.

> randy
> 

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 





From planting at vfi.com  Sat Mar 29 19:29:56 1997
From: planting at vfi.com (Paul R.D. Lantinga)
Date: Sat, 29 Mar 1997 11:29:56 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.SUN.3.94.970329131244.11190B-100000@dfw.dfw.net>
Message-ID: <Pine.LNX.3.95.970329112855.6310A-100000@wacky.eit.com>

Ack!  Could we leave this discussion just on the naipr list?  PLEASE don't
cc nanog on this topic!  

-- 
Paul R.D. Lantinga  #planting at vfi.com#
Systems Administrator, Verifone IC 
"...'proactive' and 'paradigm', aren't these just buzzwords 
that dumb people use to sound important?"-The Simpsons






From aleph1 at dfw.net  Sat Mar 29 19:49:51 1997
From: aleph1 at dfw.net (Aleph One)
Date: Sat, 29 Mar 1997 13:49:51 -0600 (CST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.BSI.3.93.970329105749.13595e-100000@sidhe.memra.com>
Message-ID: <Pine.SUN.3.94.970329134043.11190C-100000@dfw.dfw.net>

On Sat, 29 Mar 1997, Michael Dillon wrote:

> This will not happen unless you lie to ARIN and forge documents to back up
> your lies. If this did happen, not only would your criminal behavior be
> made public but I would urge the FBI to lay charges against you. If the
> FBI would not do this I would urge ISOC and EFF to file a civil suit
> against you. I suspect the FTC would also have some interest if you are
> selling IP addresses which you do not own since IP addresses are not
> things which you buy, they are also not things which you can sell.

Michael I know you are a bright guy. I've run into you in enough mailing
lists. You are making some big assumtions here:

a) That the offending company will be in the US.
b) That people wont lie to ARIN (people are lying InterNIC now, surely
   they will lie to ARIN).
c) That I (we?) dont like the ARIN proposal.

   I for one like the idea of ARIN. It's the pricing structure that is
compleatly wrong. The structure will create a market for companies to
"lease" large quantities for address space from ARIN, and then "sublease"
them cheaper than ARIN it self. You may claim you can not sell address
space but we have all seen it happen.

   As a capitalist you must also know that if you leave the oporunity for
such a market to exists even if ARIN does not intended to happen that way,
it will appear. You cannot control market forces. Where there is an
opportunity there will always be someone to exploit it. Not me, not you,
but someone.

> I don't understand why so many people want to push these ideas to reductio
> ad absurdum. We all rely on a cooperative network in order to support our
> businesses. Without a cooperative network there is no industry and we
> would all be out of work. Why can you not see that ARIN is just another
> form of cooperation in keeping the network running smoothly so that we can
> all get on with business. As the network gets bigger there are more and
> more activities that it makes sense to carve out and run autonomously.

   To reiterate: I'am all for ARIN, but their pricing structure is
upside-down.

> Michael Dillon                   -               Internet & ISP Consulting
> Memra Software Inc.              -                  Fax: +1-250-546-3049
> http://www.memra.com             -               E-mail: michael at memra.com

Aleph One / aleph1 at dfw.net
http://underground.org/
KeyID 1024/948FD6B5 
Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 





From spsprunk at paranet.com  Sat Mar 29 19:48:42 1997
From: spsprunk at paranet.com (Stephen Sprunk)
Date: Sat, 29 Mar 1997 13:48:42 -0600
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com>
References: <Pine.SUN.3.94.970329113351.1141A-100000@dfw.dfw.net>
 <199703291022.TAA17136@palmtree.jp.apnic.net>
Message-ID: <3.0.1.32.19970329134842.006bf5e4@pop.srv.paranet.com>

It will take the exact same level of effort for a NIC to assign you a /24
as it does to assign you a /14, provided numbers are available.  When you
consider this, the LARGER providers should be screaming about how much THEY
are getting ripped off.

There are patently obvious reasons to charge this way:

1. A large block uses less space in routing tables than hundreds of small
blocks.  Slow-start will undoubtedly be changed in favor of a policy that
encourages providers to get a single appropriate-sized network instead of
having to register dozens of non-contiguous blocks over time.

2. Most SMALLER providers will be getting addresses from a larger provider,
and will only have to pay that provider's price for their addresses (plus
profit, of course).  Not only is this a good deal for all parties involved,
it also encourages route aggregation.

Remember, ARIN policies and prices will change based on member input.  If
you don't believe ARIN will work, then you need to get into the debates and
get what you don't like changed.

Stephen Sprunk


At 13:39 29 03 97 -0500, you wrote:
>At 11:37 AM 3/29/97 -0600, Aleph One wrote:
>>On Sat, 29 Mar 1997, David R. Conrad wrote:
>>
>>> Size    Fee             Amt of space    Per address per year fee
>>>
>---------------------------------------------------------------------------
---
>>> Small   $2500/year      /24 - /19       $9.77 - $0.31
>>> Medium  $5000/year      >/19 - /16      $0.61 - $0.08
>>> Large   $10K/year       >/16 - /14      $0.15 - $0.04
>>> X-Large $20K/year       >/14            $0.08 -> $0.00
>>
>>   I'am I the only one that finds that the fact that the prices actually
>>*decrease* the larger the address blocks is disturbing? Not only does it
>>make entrace into the ISP market more difficult, but it allows the
>>creation of a highly profitable market for the resale of IP addresses if
>>you buy then in bulk to beging with (yeah, yeah I know about allocation
>>policies, but I seen people get large blocks easily).
>>
>
>I feel that it is disturbing as well. Since IP addresses are supposed to
>come from a non-profit organization all prices should be equal. Why should
>US Sprint get a deal (not to single them out.. take any HUGE network
>provider) on addresses and then have ARIN stick it to smaller NSPs such as
>our own.
>
>It makes no sense...
>
>Not to mention you will then create 2nd level IP allocation companies. I
>could pay the bucks, misfile the paperwork and get a /14 or two and then
>resell smaller blocks for less than ARIN's prices to NSPs starving for
>address space.
>
>Gimme a break.
>
>Just my $.02, no flames made nor requested
>
>
>




From michael at memra.com  Sat Mar 29 19:49:30 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 29 Mar 1997 11:49:30 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.SUN.3.94.970329134043.11190C-100000@dfw.dfw.net>
Message-ID: <Pine.BSI.3.93.970329114618.13595f-100000@sidhe.memra.com>

On Sat, 29 Mar 1997, Aleph One wrote:

>    I for one like the idea of ARIN. It's the pricing structure that is
> compleatly wrong. The structure will create a market for companies to
> "lease" large quantities for address space from ARIN, and then "sublease"
> them cheaper than ARIN it self. You may claim you can not sell address
> space but we have all seen it happen.

I'm not claiming that ARIN is perfect and that it will instantly solve all
problems. But I do believe that it will be far more responsive to the
industry than the Internic could be. And if enough ISP's join ARIN and
come up with a better funding/pricing scheme then I believe it *CAN*
be implemented. The fundamental feature of ARIN is that it will be 
responsive to the needs of those organizations who use IP address space.
It's just a first step in the right direction, not the ultimate goal.

Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From epg at corp.home.net  Sat Mar 29 20:05:40 1997
From: epg at corp.home.net (Elise Gerich)
Date: Sat, 29 Mar 1997 12:05:40 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com> from "Matthew Pearson" at Mar 29, 97 01:39:25 pm
Message-ID: <199703292005.MAA04070@phone.eos.home.net>

Cathy,

So, does this mean that our new budget needs to include
$20K for ARIN "membership"?
     --Elise

> 
> At 11:37 AM 3/29/97 -0600, Aleph One wrote:
> >On Sat, 29 Mar 1997, David R. Conrad wrote:
> >
> >> Size    Fee             Amt of space    Per address per year fee
> >>
> ------------------------------------------------------------------------------
> >> Small   $2500/year      /24 - /19       $9.77 - $0.31
> >> Medium  $5000/year      >/19 - /16      $0.61 - $0.08
> >> Large   $10K/year       >/16 - /14      $0.15 - $0.04
> >> X-Large $20K/year       >/14            $0.08 -> $0.00
> >
> >   I'am I the only one that finds that the fact that the prices actually
> >*decrease* the larger the address blocks is disturbing? Not only does it
> >make entrace into the ISP market more difficult, but it allows the
> >creation of a highly profitable market for the resale of IP addresses if
> >you buy then in bulk to beging with (yeah, yeah I know about allocation
> >policies, but I seen people get large blocks easily).
> >
> 
> I feel that it is disturbing as well. Since IP addresses are supposed to
> come from a non-profit organization all prices should be equal. Why should
> US Sprint get a deal (not to single them out.. take any HUGE network
> provider) on addresses and then have ARIN stick it to smaller NSPs such as
> our own.
> 
> It makes no sense...
> 
> Not to mention you will then create 2nd level IP allocation companies. I
> could pay the bucks, misfile the paperwork and get a /14 or two and then
> resell smaller blocks for less than ARIN's prices to NSPs starving for
> address space.
> 
> Gimme a break.
> 
> Just my $.02, no flames made nor requested
> 
> 





From jhc at lynxhub.att.com  Sat Mar 29 20:04:07 1997
From: jhc at lynxhub.att.com (Jonathan Clark)
Date: Sat, 29 Mar 1997 15:04:07 -0500
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: Brian Murrell <Brian_Murrell@bctel.net>
        "Re: Anti-SPAM announcement from AT&T Worldnet" (Mar 29,  2:36)
References: <199703291036.CAA08345@mocha.bctel.net>
Message-ID: <9703291504.ZM18585@lynxhub.att.com>

	> Any email...even regular questions/replies....I think specific
	> types of email would be more appropriate..."spam","obscene" etc.

	I read it as clearly stating that _any_ mail (not limited to spam
	or obscene, etc.) being relayed (not to or from an AT&T Worldnet
	customer) will not be delivered by AT&T Worldnet's mail servers.

``We have reserved the right to treat such mail any way we deem appropriate,''.
This may include actually delivering it, but in the vast majority
of cases I do not expect the mail to reach its intended destination(s).

We will be keeping statistics and I hope to be able to present these
in some public forum in due course.

Jonathan




From jfbb at ATMnet.net  Sat Mar 29 20:08:05 1997
From: jfbb at ATMnet.net (Jim Browning)
Date: Sat, 29 Mar 1997 12:08:05 -0800
Subject: ARIN is A Good Thing
Message-ID: <01BC3C39.DC08D4E0@jfbb.atmnet.net>

>From:  Ehud Gavron[SMTP:GAVRON at ACES.COM]
>Sent:  Saturday, March 29, 1997 1:11 AM
>
>	IF DNS pays for IP and the InterNIC made $60M profit DESPITE
>	also doing IP, then clearly DNS fees are too high.
>
>	IF ARIN means that IP pays for IP and the DNS funds are unfettered,
>	then that $60M profit (in one year) would be much more than $60M.

As has been pointed out, the numbers you are quoting are fictitious..
--
Jim Browning





From randy at psg.com  Sat Mar 29 21:46:00 1997
From: randy at psg.com (Randy Bush)
Date: Sat, 29 Mar 97 13:46 PST
Subject: ARIN is not/is too/is not/is too... blah.
References: <m0wB3Kq-000IY4C@roam.psg.com>
	<Pine.SUN.3.94.970329131244.11190B-100000@dfw.dfw.net>
Message-ID: <m0wB5ws-000IY3C@roam.psg.com>

> how is a smaller block allocationa a chaper "service" than a smaller one?

We have all been here before many times.  Please read the archives.

randy




From michael at stb.info.com  Sat Mar 29 22:12:00 1997
From: michael at stb.info.com (Michael Gersten)
Date: Sat, 29 Mar 97 14:12 PST
Subject: ARINANOG
Message-ID: <m0wB6Mq-000ZC8C@stb.info.com>

Jim raises an extremely good point.

Why not start ARIN off by giving it a /8 to work with and see how well
it will actually work?

Lets face it, there is only ONE /0, and giving that to ARIN might not
be a good idea if it doesn't work right. By giving them a /8, they
will have to compete with other ways of assigning IP addresses, and
demonstrate that they actually can work.

Just like a would-be ISP has to start with a /24 and work up...

		Michael




From dirk at power.net  Sat Mar 29 22:08:03 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Sat, 29 Mar 1997 14:08:03 -0800 (PST)
Subject: ARIN is A Good Thing
In-Reply-To: <01BC3C39.DC08D4E0@jfbb.atmnet.net>
Message-ID: <Pine.LNX.3.95.970329140755.19007C-100000@orlando.power.net>


What are the actual numbers?

Dirk

On Sat, 29 Mar 1997, Jim Browning wrote:

> >From:  Ehud Gavron[SMTP:GAVRON at ACES.COM]
> >Sent:  Saturday, March 29, 1997 1:11 AM
> >
> >	IF DNS pays for IP and the InterNIC made $60M profit DESPITE
> >	also doing IP, then clearly DNS fees are too high.
> >
> >	IF ARIN means that IP pays for IP and the DNS funds are unfettered,
> >	then that $60M profit (in one year) would be much more than $60M.
> 
> As has been pointed out, the numbers you are quoting are fictitious..
> --
> Jim Browning
> 





From loco at isi.net  Sat Mar 29 22:27:04 1997
From: loco at isi.net (Jonathan Heiliger)
Date: Sat, 29 Mar 1997 14:27:04 -0800 (PST)
Subject: ARIN mail
Message-ID: <Pine.GSO.3.96.970329142515.3099D-100000@buffy>


i apologize for further increasing the S/N of this list.. but I believe
the 'naipr at arin.net' list was created to focus on ARIN discussions, among
other things.  as we all know, NANOG's charter is defined in murky terms,
but why continue a retorical debate on two lists? 

thanks.


-jh-

---------- Forwarded message ----------
Date: Sat, 29 Mar 97 14:12 PST
From: Michael Gersten <michael at stb.info.com>
To: JimFleming at unety.net, naipr at arin.net
Cc: ckuehn at NSF.GOV, gstrawn at NSF.GOV, lsundro at NSF.GOV, nanog at merit.edu
Subject: Re: ARINANOG

Jim raises an extremely good point.

Why not start ARIN off by giving it a /8 to work with and see how well
it will actually work?

Lets face it, there is only ONE /0, and giving that to ARIN might not
be a good idea if it doesn't work right. By giving them a /8, they
will have to compete with other ways of assigning IP addresses, and
demonstrate that they actually can work.

Just like a would-be ISP has to start with a /24 and work up...

		Michael





From jim at carroll.com  Sat Mar 29 22:28:25 1997
From: jim at carroll.com (Jim Carroll)
Date: Sat, 29 Mar 1997 17:28:25 -0500
Subject: Anti-SPAM announcement from AT&T Worldnet (fwd)
Message-ID: <Pine.BSD.3.91.970329172142.29408X-100000@apollo.carroll.com>


> Date: Fri, 28 Mar 1997 18:08:44 -0500
> From: Jonathan Clark <jhc at lynxhub.att.com>
> To: spam-list at psc.edu, nanog at merit.edu, spam at zorch.sf-bay.org
> Subject: Anti-SPAM announcement from AT&T Worldnet
>
> AT&T Worldnet announces that starting Monday, March 31 1997,
> it will be taking action to stop email from non-AT&T Worldnet
> account holders being relayed through its servers.
> 
> We have reserved the right to treat such mail any way we deem appropriate,
> which may include deleting it without notification to the originator.
> 
> Please address any questions about this policy to abuse at worldnet.att.net.

 
 This should really be treated as a warning message to  mail  administrators
 everywhere.  If  you  have not already implemented mail-relay blocking, you
 should think seriously about adding it now.
 
 When AT&T starts the filtering, those senders "hijacking" AT&T mail servers
 will go searching for alterate  servers;  sort  of  like  rats  fleeing  an
 abandoned warehouse that is now being renovated.
 
---
Jim C., President       | C A R R O L L - N E T, Inc.
201-488-1332 voice      | New Jersey's Premier Internet Service Provider
201-487-5717 dialup     |
http://www.carroll.com  | Ask about our Business Web Services





From dirk at power.net  Sat Mar 29 22:05:24 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Sat, 29 Mar 1997 14:05:24 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.SUN.3.94.970329131244.11190B-100000@dfw.dfw.net>
Message-ID: <Pine.LNX.3.95.970329140410.19007B-100000@orlando.power.net>


Precisly. If the goal is to use a financial incentive to make IP
allocation more efficent, then the price per address should go up with the
number of addresses allocated at one time. 

Dirk


On Sat, 29 Mar 1997, Aleph One wrote:

> On Sat, 29 Mar 1997, Randy Bush wrote:
> 
> > You seem to have a model that the IP space is being sold as if it were a
> > commodity.  What is being charged are the services.  Please read the ARIN
> > proposal.
> 
> You misunderstand. ARIN may not sell IP space as if it where a commodity.
> But by making cheaper large IP address blocks than smaller ones is allows
> the creation of just such a commodity market at a second level. In anycase
> how is a smaller block allocationa a chaper "service" than a smaller one?
> They should all cost the same per IP address, or even increaser as the
> block gets larger to give an incentive for intelligent use of address
> space, aggregation, and things like NAT. Not the other way around.
> 
> > randy
> > 
> 
> Aleph One / aleph1 at dfw.net
> http://underground.org/
> KeyID 1024/948FD6B5 
> Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 
> 





From paul at vix.com  Sat Mar 29 23:14:17 1997
From: paul at vix.com (Paul A Vixie)
Date: Sat, 29 Mar 1997 15:14:17 -0800
Subject: let's just have one mailing list
Message-ID: <199703292314.PAA04399@wisdom.home.vix.com>

------- Blind-Carbon-Copy

to: nobody at vix.com
reply-to: nobody at vix.com
Subject: let's just have one mailing list
Date: Sat, 29 Mar 1997 15:14:17 -0800
From: Paul A Vixie <vixie at wisdom.home.vix.com>

why on earth do we have a nanog list that's separate from spam-list
that's separate from spam-list?  clearly all discussions on any topic
belong on all three lists -- otherwise why would we consistently see:

        cc: spam-list at psc.edu, nanog at merit.edu, spam at zorch.sf-bay.org

i'm receiving multiple copies of this stuff since i'm on all three lists.
can't we just coalesce all three lists, and the other 20,000 mailing lists
on the internet, onto one?  we could call it net.general at ihnp4.uucp and
just put everybody on the internet onto it.  then noone would ever miss
out on an interesting discussion that takes place on a list that they are
not on.

not being on a mailing list is clearly an error, and if someone happens to
prefer not being on a list since they don't want to hear about the topic of
that list, they are clearly confused since lists don't have topics, right?

i'm especially worried about the fact that there is a NAIPR list for ARIN
discussions and that not all NANOG messages are -- yet -- automatically CC'd
to it.  can the postmaster at merit.edu please automatically CC all NANOG
messages to all known mailing lists to correct this obvious problem?

(grrrrrrrrrrrrrrrrr.)


------- End of Blind-Carbon-Copy




From michael at memra.com  Sat Mar 29 21:46:10 1997
From: michael at memra.com (Michael Dillon)
Date: Sat, 29 Mar 1997 13:46:10 -0800 (PST)
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <199703292132.QAA14080@newdev.harvard.edu>
Message-ID: <Pine.BSI.3.93.970329134244.13595p-100000@sidhe.memra.com>

On Sat, 29 Mar 1997, Scott Bradner wrote:

> --
> Someone correct me if I'm wrong, but I'm under the impression that the
> Electronic Communications Act of 1986 (?) makes it quite illegal to screw
> around with mail that you have accepted for delivery.
> --
> 
> spammers bill of rights?  kinda don't think that would have been the 
> aim.

I think that you can comply with the ECPA by simply bouncing back the
email to the sender and only if that is not possible, then drop it in
/dev/null. Since spammers almost always have bogus reply addresses you
shouldn't run into a problem with this even if you are a relay since once
you have failed to bounce back one message, you can then add that source
address to a list that you refuse to accept email from.

If there is a way that spammers can launch a lawsuit against AT&T on the
basis of the ECPA then I am sure they will try so it's best to be
proactive here.


Michael Dillon                   -               Internet & ISP Consulting
Memra Software Inc.              -                  Fax: +1-250-546-3049
http://www.memra.com             -               E-mail: michael at memra.com





From dirk at power.net  Sat Mar 29 21:57:10 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Sat, 29 Mar 1997 13:57:10 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.SUN.3.94.970329113351.1141A-100000@dfw.dfw.net>
Message-ID: <Pine.LNX.3.95.970329133643.19007A-100000@orlando.power.net>



On Sat, 29 Mar 1997, Aleph One wrote:

> On Sat, 29 Mar 1997, David R. Conrad wrote:
> 
> > Size    Fee             Amt of space    Per address per year fee
> > ------------------------------------------------------------------------------
> > Small   $2500/year      /24 - /19       $9.77 - $0.31
> > Medium  $5000/year      >/19 - /16      $0.61 - $0.08
> > Large   $10K/year       >/16 - /14      $0.15 - $0.04
> > X-Large $20K/year       >/14            $0.08 -> $0.00
> 
>    I'am I the only one that finds that the fact that the prices actually
> *decrease* the larger the address blocks is disturbing? Not only does it
> make entrace into the ISP market more difficult, but it allows the
> creation of a highly profitable market for the resale of IP addresses if
> you buy then in bulk to beging with (yeah, yeah I know about allocation
> policies, but I seen people get large blocks easily).

Yup, I noticed that too.

Of course, according to every network CFO's spreadsheets, the real
Internet money at the moment is in co-location and T1 connections for
businesses. 

The nightmare scenario for UUnet, MCI, Sprint and so on is easy to
imagine. What if small local providers got that business? Unlike almost
any other business, smaller ISPs have *less* costs per user. Larger
routers are *more* expensive per port then smaller routers. What if people
used PCs running Linux instead of Cisco/Bay routers? Economy of scale in
reverse. 

Could we have 4000 10 people companies provide Internet connectivity to
the majority of US business within a couple of years? At $80-200/month for
a T1? This is what "they" are trying to avoid/slow down. 

Seems that the Internet turns some things on its head. Like the need to
have large corporations for providing large scale Internet services.
According to Boardwatch magazine, about 4000 2-10 people ISPs are
providing Internet services to the majority of the US. ATT, Sprint and so
on can't make money at it but it sure is a great way for a technical
person to make $100K/year from with a T1 in a living room.

Dirk

 
> Aleph One / aleph1 at dfw.net
> http://underground.org/
> KeyID 1024/948FD6B5 
> Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 
> 





From sob at newdev.harvard.edu  Sat Mar 29 21:32:13 1997
From: sob at newdev.harvard.edu (Scott Bradner)
Date: Sat, 29 Mar 1997 16:32:13 -0500 (EST)
Subject: Anti-SPAM announcement from AT&T Worldnet
Message-ID: <199703292132.QAA14080@newdev.harvard.edu>

--
Someone correct me if I'm wrong, but I'm under the impression that the
Electronic Communications Act of 1986 (?) makes it quite illegal to screw
around with mail that you have accepted for delivery.
--

spammers bill of rights?  kinda don't think that would have been the 
aim.

Scott




From lon at moonstar.com  Sat Mar 29 20:55:14 1997
From: lon at moonstar.com (Lon R. Stockton, Jr.)
Date: Sat, 29 Mar 1997 15:55:14 -0500 (EST)
Subject: Anti-SPAM announcement from AT&T Worldnet
In-Reply-To: <9703291504.ZM18585@lynxhub.att.com>
Message-ID: <Pine.LNX.3.91.970329155204.19719B-100000@luna.moonstar.com>


On Sat, 29 Mar 1997, Jonathan Clark wrote:

> ``We have reserved the right to treat such mail any way we deem appropriate,''.
> This may include actually delivering it, but in the vast majority
> of cases I do not expect the mail to reach its intended destination(s).

Someone correct me if I'm wrong, but I'm under the impression that the 
Electronic Communications Act of 1986 (?) makes it quite illegal to screw 
around with mail that you have accepted for delivery. You have the option 
of not accepting it at all, but once you accept a piece of mail destined 
for someone, you're obligated to make a best effort to deliver it.

You can't reserve a right that you don't have to begin with, even if you 
are AT&T.





From JimFleming at unety.net  Sat Mar 29 21:09:28 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 29 Mar 1997 15:09:28 -0600
Subject: ARIN is not/is too/is not/is too... blah.
Message-ID: <01BC3C53.33445680@webster.unety.net>

On Saturday, March 29, 1997 5:09 AM, Michael Dillon[SMTP:michael at MEMRA.COM] wrote:
@ On Sat, 29 Mar 1997, Matthew Pearson wrote:
@ 
<snip>
@ 
@ I don't understand why so many people want to push these ideas to reductio
@ ad absurdum. We all rely on a cooperative network in order to support our
@ businesses. Without a cooperative network there is no industry and we
@ would all be out of work. Why can you not see that ARIN is just another
@ form of cooperation in keeping the network running smoothly so that we can
@ all get on with business. As the network gets bigger there are more and
@ more activities that it makes sense to carve out and run autonomously.
@ 
@ 
@ Michael Dillon                   -               Internet & ISP Consulting
@ Memra Software Inc.              -                  Fax: +1-250-546-3049
@ http://www.memra.com             -               E-mail: michael at memra.com
@ 
@ 
@ 

Yes Michael...you never seem to understand...

Maybe the reason is that some people rely on MORE than just
a cooperative network to support their businesses. They rely
on cooperative communities, they rely on cooperative governments,
and they rely on cooperative companies to provide jobs, etc.

For a person tucked away in a cabin in the woods in Canada
without a TV and without contact with urban areas, you
may not be able to understand. Unfortunately, many of the
people in the real world have different challenges that face
them each day, because of that they have different solutions
than the ones you dream up.

Have you considered that people DO understand that ARIN
is "just another form of cooperation", but the problem is
it is a cooperation of people that are out of touch with the
needs of the real world ?

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From JimFleming at unety.net  Sat Mar 29 21:26:50 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 29 Mar 1997 15:26:50 -0600
Subject: ARIN is not/is too/is not/is too... blah.
Message-ID: <01BC3C55.A035D320@webster.unety.net>

On Saturday, March 29, 1997 5:49 AM, Michael Dillon[SMTP:michael at MEMRA.COM] wrote:
@ On Sat, 29 Mar 1997, Aleph One wrote:
@ 
@ >    I for one like the idea of ARIN. It's the pricing structure that is
@ > compleatly wrong. The structure will create a market for companies to
@ > "lease" large quantities for address space from ARIN, and then "sublease"
@ > them cheaper than ARIN it self. You may claim you can not sell address
@ > space but we have all seen it happen.
@ 
@ I'm not claiming that ARIN is perfect and that it will instantly solve all
@ problems. But I do believe that it will be far more responsive to the
@ industry than the Internic could be. And if enough ISP's join ARIN and
@ come up with a better funding/pricing scheme then I believe it *CAN*
@ be implemented. The fundamental feature of ARIN is that it will be 
@ responsive to the needs of those organizations who use IP address space.
@ It's just a first step in the right direction, not the ultimate goal.
@ 
@ Michael Dillon                   -               Internet & ISP Consulting
@ Memra Software Inc.              -                  Fax: +1-250-546-3049
@ http://www.memra.com             -               E-mail: michael at memra.com
@ 
@ 
@ 

If more companies had been allowed to develop
more Registry Industy Infrastructure during the
past 18 months, rather than debate how many
IAHCs or ARINs can dance on the head of a pin,
then we would all be much further, at least here in
the U.S.

As companies come up to speed in the Registry
Industry they will be natural candidates to help
take over some of the InterNIC duties. IP allocations
are only one aspect of those duties. Some companies
may not choose to get into that activity, other
companies might start there.

Again, why don't the people chomping at the
bit to form ARIN, just do it ? Once they do they
can stand in line with the other ISPs to obtain
an IP allocation which they can then use to
provide "services" to fund themselves.

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From epg at corp.home.net  Sat Mar 29 20:34:37 1997
From: epg at corp.home.net (Elise Gerich)
Date: Sat, 29 Mar 1997 12:34:37 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah. (fwd)
Message-ID: <199703292034.MAA04137@phone.eos.home.net>

Forwarded message:


From epg at corp.home.net  Sat Mar 29 20:05:40 1997
From: epg at corp.home.net (Elise Gerich)
Date: Sat, 29 Mar 1997 12:05:40 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com> from "Matthew Pearson" at Mar 29, 97 01:39:25 pm
Message-ID: <199703292005.MAA04070@phone.eos.home.net>

Cathy,

So, does this mean that our new budget needs to include
$20K for ARIN "membership"?
     --Elise

> 
> At 11:37 AM 3/29/97 -0600, Aleph One wrote:
> >On Sat, 29 Mar 1997, David R. Conrad wrote:
> >
> >> Size    Fee             Amt of space    Per address per year fee
> >>
> ------------------------------------------------------------------------------
> >> Small   $2500/year      /24 - /19       $9.77 - $0.31
> >> Medium  $5000/year      >/19 - /16      $0.61 - $0.08
> >> Large   $10K/year       >/16 - /14      $0.15 - $0.04
> >> X-Large $20K/year       >/14            $0.08 -> $0.00
> >
> >   I'am I the only one that finds that the fact that the prices actually
> >*decrease* the larger the address blocks is disturbing? Not only does it
> >make entrace into the ISP market more difficult, but it allows the
> >creation of a highly profitable market for the resale of IP addresses if
> >you buy then in bulk to beging with (yeah, yeah I know about allocation
> >policies, but I seen people get large blocks easily).
> >
> 
> I feel that it is disturbing as well. Since IP addresses are supposed to
> come from a non-profit organization all prices should be equal. Why should
> US Sprint get a deal (not to single them out.. take any HUGE network
> provider) on addresses and then have ARIN stick it to smaller NSPs such as
> our own.
> 
> It makes no sense...
> 
> Not to mention you will then create 2nd level IP allocation companies. I
> could pay the bucks, misfile the paperwork and get a /14 or two and then
> resell smaller blocks for less than ARIN's prices to NSPs starving for
> address space.
> 
> Gimme a break.
> 
> Just my $.02, no flames made nor requested
> 
> 






From JimFleming at unety.net  Sat Mar 29 20:17:19 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 29 Mar 1997 14:17:19 -0600
Subject: ARINANOG
Message-ID: <01BC3C4B.EA6606E0@webster.unety.net>


[1] As a reminder, there is an ARIN mailing list available from
	http://www.arin.net.

[2] I hope that this NANOG discussion gets reflected on the ARIN
	mailing list because some people may be following that
	list and may falsely conclude that the "Internet community"
	supports ARIN with "broad consensus" when in fact they
	have not really seen the discussions about ARIN which
	are held on other lists, in other meetings, in Hong Kong, etc.

[3] The reasons for creating ARIN have nothing to do with the words
	reflected in the ARIN proposal. This nonsense about DNS
	funding IP and vice versa are not the core issues any more
	than an ISP debating how dial-up subsidizes leased lines
	or vice versa.

[4] If ARIN is such a great idea why don't the proposed founders
	quit their comfortable jobs, give up their benefits and
	U.S. Government funding and start ARIN ? That is what
	other people do when they want to start a business.
	Before doing that, why don't the founders get ISPs to
	sign subscription agreements agreeing to fund the
	enterprise and therefore money will not be an issue
	because the companies that sign up will fund the
	effort. In fact, some of the people on NANOG claim that
	people are always throwing money at them. Why don't
	those people step forward to bank-roll ARIN ?

[5] Once ARIN is launched, why doesn't ARIN petition the
	NSF/InterNIC/IANA for a /8 to manage ? Given that
	some people think that ARIN is such a great idea,
	this should not take long, especially if the "right"
	people are on the ARIN board of directors.

[6] If NANOG members think that ARIN is such a great idea
	why not just pull the activity into NANOG and call
	the thing ARINANOG and get on with it ?


@@@@ http://www.merit.edu/mail.archives/html/nanog/msg02405.html

Re: ARIN is A Good Thing

------------------------------------------------------------------------
.To: "nanog at merit.edu" <nanog at MERIT.EDU>
.Subject: Re: ARIN is A Good Thing
.From: Paul A Vixie <paul at vix.com>
.Date: Sat, 29 Mar 1997 07:54:54 -0800
.In-reply-to: Your message of "Sat, 29 Mar 1997 02:11:16 MST." <01IH23Y6AYGG8WW0FK at ACES.COM>
.Sender: owner-nanog at MERIT.EDU 
------------------------------------------------------------------------

Ehud wrote:

> With no offense to Internic, IANA, Jon, or Jbb.  If I have to pay the
> Internic (and I do) [1] and they can also support IP (and they do) [2]
> and come out $60M black (they do!) then they can damn well fund their [3]
> own damn program to assign the [4] goddamned addresses without billing me.

I added the [#] notations above so I could comment in detail.  [1] you do
not have to pay the InterNIC -- there's always .US, and once IAHC's proposal
gets going, you will be able to select among other alternatives as well (and
my expectation is that .COM et al will become a shared gTLD in 1998).  [2]
you're right that they support IP, but remember the golden rule: whoever has
the gold makes the rules.  Leaving InterNIC to support this means that they
(InterNIC rather than Kim personally or any ISP) get to decide _how_ they
support it.  They don't presently have to do anything you agree with.  [3] 
it's not their program, it was NSF's program most recently, and believe me
when I tell you that you don't WANT it to be "InterNIC's program".  Finally,
[4] to assign is to assert some form of ownership.  I'd much rather see the
ISP's, with Kim continuing as coordinator reporting a board of ISP "regents",
assign and therefore assert ownership of, the address pool.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@


As for the rest of the Registry Industry, there is a lot
of work still to be done. As companies develop Internet
Infrastructure and Registry Industry Infrastructure some
of them will become likely candidates to take over parts
of the IPv4 address space for management purposes.
This will help to spread some of the administrative costs
around and will ensure more fair and equitable policies.

--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From babylon at mokushi.psybernet.com  Sun Mar 30 03:29:07 1997
From: babylon at mokushi.psybernet.com (babylon at mokushi.psybernet.com)
Date: Sat, 29 Mar 1997 22:29:07 -0500 (EST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.LNX.3.95.970329133643.19007A-100000@orlando.power.net> from "Dirk Harms-Merbitz" at Mar 29, 97 01:57:10 pm
Message-ID: <199703300329.WAA17973@mokushi.psybernet.com>



<Stuff Deleted>

> 
> Could we have 4000 10 people companies provide Internet connectivity to
> the majority of US business within a couple of years? At $80-200/month for
> a T1? This is what "they" are trying to avoid/slow down. 

I am not sure how you can come to thus conclusion. Where do you think
the 4000 10 person businesses are getting their connectivity from? I do
not see them forming their own connectivity to each other. There is a
need for large providers as well, and they need your business.

Jonathan

> 
> Seems that the Internet turns some things on its head. Like the need to
> have large corporations for providing large scale Internet services.
> According to Boardwatch magazine, about 4000 2-10 people ISPs are
> providing Internet services to the majority of the US. ATT, Sprint and so
> on can't make money at it but it sure is a great way for a technical
> person to make $100K/year from with a T1 in a living room.
> 
> Dirk
> 
>  
> > Aleph One / aleph1 at dfw.net
> > http://underground.org/
> > KeyID 1024/948FD6B5 
> > Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 
> > 
> 
> 





From Valdis.Kletnieks at vt.edu  Sun Mar 30 03:34:05 1997
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu)
Date: Sat, 29 Mar 1997 22:34:05 -0500
Subject: ARINANOG 
In-Reply-To: Your message of "Sat, 29 Mar 1997 14:17:19 CST."
             <01BC3C4B.EA6606E0@webster.unety.net> 
References: <01BC3C4B.EA6606E0@webster.unety.net>
Message-ID: <199703300334.WAA16352@black-ice.cc.vt.edu>

On Sat, 29 Mar 1997 14:17:19 CST, Jim Fleming said:
> [4] If ARIN is such a great idea why don't the proposed founders
> 	quit their comfortable jobs, give up their benefits and
> 	U.S. Government funding and start ARIN ? That is what
> 	other people do when they want to start a business.

(a) Some of the proposed founders *WILL* be quitting their comfortable
jobs to go work at ARIN.

(b) "venture capital".  Almost nobody (except for very small mom&pop
operations on the low end) starts a business totally on their own funds.
Why should this be any different?

-- 
				Valdis Kletnieks
				Computer Systems Engineer
				Virginia Tech


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 284 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/19970329/6469b738/attachment.sig>

From JimFleming at unety.net  Sun Mar 30 03:44:01 1997
From: JimFleming at unety.net (Jim Fleming)
Date: Sat, 29 Mar 1997 21:44:01 -0600
Subject: ARINANOG 
Message-ID: <01BC3C8A.51672980@webster.unety.net>

On Saturday, March 29, 1997 9:34 PM, Valdis.Kletnieks at vt.edu wrote:
@ On Sat, 29 Mar 1997 14:17:19 CST, Jim Fleming said:
@ > [4] If ARIN is such a great idea why don't the proposed founders
@ > 	quit their comfortable jobs, give up their benefits and
@ > 	U.S. Government funding and start ARIN ? That is what
@ > 	other people do when they want to start a business.
@ 
@ (a) Some of the proposed founders *WILL* be quitting their comfortable
@ jobs to go work at ARIN.
@ 

Who ?
When ?

Those questions were never answered ?

@ (b) "venture capital".  Almost nobody (except for very small mom&pop
@ operations on the low end) starts a business totally on their own funds.
@ Why should this be any different?
@ 

Venture capitalists are going to look for a 10x return
in a 12 month period. ARIN proposes to be cost based
and non-profit. VCs might not be interested in that.

Again, why don't all the people that want to see ARIN
happen fund the thing and then ARIN can line up for
one /8 and if they make that work, they can get another.

Why does ARIN "assume" that the InterNIC's resources
are its resources ? Air Force pilots do not take their jets
with them when they leave the military.

Also, these concerns about ARIN helping to safeguard
against lawsuits brought against the InterNIC for domain
names are pure FUD. In fact, just the opposite situation
exists. I would be MORE concerned about ARIN getting
shut down by the DOJ or the IRS than about the InterNIC
being shut down because the InterNIC is the NSF + AT&T
+ NSI.

I think that I would trust that AT&T's lawyers, NSI's lawyers
and the NSF's lawyers could keep the InterNIC going much
longer than ARIN could withstand a challenge. Besides,
if ARIN is cost-based and the "members" pay the costs
then a loawsuit or charges brought against ARIN could
become very expensive for the members. Special fees or
taxes might be needed to keep ARIN solvent through a
challenge.


--
Jim Fleming
Unir Corporation
http://www.Unir.Corp

Check out...http://Register.A.Mall





From jfbb at ATMnet.net  Sun Mar 30 04:43:31 1997
From: jfbb at ATMnet.net (Jim Browning)
Date: Sat, 29 Mar 1997 20:43:31 -0800
Subject: ARIN is A Good Thing
Message-ID: <01BC3C81.DDF80D00@jfbb.atmnet.net>

AFAIK, SAIC does not publish financial results for its subsidiaries, nor do 
those subsidiaries publish breakdowns of the finances of specific projects. 
 It is possible to determine the rough amount of revenues received for 
domain registrations by looking at the number of new domains registered and 
total domains being administered, and also by looking at was been accrued 
into the infrastructure account.  The last semingly credible number I read 
put the DNS *revenues* at less than half what has been quoted as *profits*. 
--
Jim Browning

----------
From:  Dirk Harms-Merbitz[SMTP:dirk at power.net]
Sent:  Saturday, March 29, 1997 2:08 PM
To:  Jim Browning
Cc:  'Ehud Gavron'; nanog at merit.edu
Subject:  RE: ARIN is A Good Thing


What are the actual numbers?

Dirk

On Sat, 29 Mar 1997, Jim Browning wrote:

> >From:  Ehud Gavron[SMTP:GAVRON at ACES.COM]
> >Sent:  Saturday, March 29, 1997 1:11 AM
> >
> >	IF DNS pays for IP and the InterNIC made $60M profit DESPITE
> >	also doing IP, then clearly DNS fees are too high.
> >
> >	IF ARIN means that IP pays for IP and the DNS funds are unfettered,
> >	then that $60M profit (in one year) would be much more than $60M.
>
> As has been pointed out, the numbers you are quoting are fictitious..
> --
> Jim Browning
>






From horvitz at websecure.net  Sun Mar 30 05:09:54 1997
From: horvitz at websecure.net (Brian Horvitz)
Date: Sun, 30 Mar 1997 00:09:54 -0500 (EST)
Subject: NAPs - Temperature vs Packet loss
In-Reply-To: <199703282026.UAA18650@diamond.xara.net>
Message-ID: <Pine.GSO.3.95.970330000630.20176B-100000@sp02.websecure.net>

I experienced an airflow problem on a 7010 once which just made it shut
down and restart when it got hot.  Are you sure that this is not
happening occesionally?  It would seem to me that a 7xxx router should be
able to survive its shutdown threshold without affecting performance.

	Brian Horvitz
	WebSecure, Inc.

On Fri, 28 Mar 1997, Alex.Bligh wrote:

> We've noticed an interesting phenomenon with MAE-East. Packet loss
> corelates nicely to temperature.
> 
> At first I assumed the relationship was Busy Network => Hot routers
> and also Busy Network => Packet Loss. But this is not the case.
> It appears to be Hot Routers => Packet Loss.
> 
> Boone Boulevard MAE-East is currently running very hot. Intake temp
> on our router has been up to 40 degrees today, and output at 70.
> Under these conditions, the router (a 7010) starts dropping a pile
> of packets occassionally. Mostly these seem to be through the AIP
> and a clear int a0/0 fixes it. The time it stays fixed for is
> heavilly corelated with temperature. The higher the temperature,
> the shorter it stays fixed for. Eventually MFS put a fan on the
> router and it seems a lot better now, intake temperature being
> down to 36/37 degrees.
> 
> 40 degrees is Cisco's default "warning" threshold. One would have
> thought boxes should work OK at 40 degrees. On the other hand one
> might also have thought a 18-22 degree aircon environment was a
> prerequisite of running a decent IXP.
> 
> Is anyone else seeing high temperature and otherwise inexplicable
> packet loss at MAE-East? Or does anyone else have data to corelate?
> 
> Alex Bligh
> Xara Networks
> 
> 
> 





From doshea at mail.wiltel.net  Sun Mar 30 05:39:51 1997
From: doshea at mail.wiltel.net (Dave O'Shea)
Date: Sat, 29 Mar 1997 23:39:51 -0600
Subject: Anti-SPAM announcement from AT&T Worldnet
Message-ID: <01BC3C9A.800E9240@homer.frap.wilcom.com>

The original message confused me a little. I could (mis?)interpret it to say that mail that has been given to them, by some outside party, to be relayed to another outside party - since spammers typically attack a mail server outside their (registered via credit card) home provider, who might just whack them with an arbitrary "high message traffic" charge.

In this case, so long as AT&T made the policy clear up front (perhaps by having sendmail reference it in it's greeting) I think they would be in the clear.

I've been tempted to put a "$1000 per non-local origin/destination" charge message on my sendmail banner, and then have my legal department whack Krazy Kevin with a seven-digit default judgement next time he tries a spam run. Let's see ya get a mortgage with that one on your TRW, pal.



Dave O'Shea
Manager, Network Operations			713-307-6760
Wiltel Communications Systems			Houston, TX


-----Original Message-----
From:	Scott Bradner [SMTP:sob at newdev.harvard.edu]
Sent:	Saturday, March 29, 1997 3:32 PM
To:	jhc at lynxhub.att.com; lon at moonstar.com
Cc:	Brian_Murrell at bctel.net; kevin at ascend.com; nanog at merit.edu; spam-list at psc.edu; spam at zorch.sf-bay.org
Subject:	Re: Anti-SPAM announcement from AT&T Worldnet

--
Someone correct me if I'm wrong, but I'm under the impression that the
Electronic Communications Act of 1986 (?) makes it quite illegal to screw
around with mail that you have accepted for delivery.
--

spammers bill of rights?  kinda don't think that would have been the 
aim.

Scott





From hank at ibm.net.il  Sun Mar 30 11:49:49 1997
From: hank at ibm.net.il (Hank Nussbacher)
Date: Sun, 30 Mar 1997 13:49:49 +0200
Subject: PC Magazine on Internet logjams 
Message-ID: <2.2.16.19970330114949.45ffee46@rex.ibm.net.il>

http://www.pcmag.com/issues/1607/pcmg0165.htm

Breaking Up the Internet Logjam (04/08/97)

Hank





From tomg at boiled.egg.com  Sun Mar 30 13:27:41 1997
From: tomg at boiled.egg.com (Tom Glover)
Date: Sun, 30 Mar 1997 05:27:41 -0800 (PST)
Subject: PC Magazine on Internet logjams 
In-Reply-To: <2.2.16.19970330114949.45ffee46@rex.ibm.net.il>
Message-ID: <Pine.BSI.3.95.970330052324.16113C-100000@boiled.egg.com>


It is seldom that John C. Dvorak says anything that resembles an
intelligent statement or is even remotely supported by fact.  He is a
sensationalist. This article is no different from his usual crap.

On Sun, 30 Mar 1997, Hank Nussbacher wrote:

> http://www.pcmag.com/issues/1607/pcmg0165.htm
> 
> Breaking Up the Internet Logjam (04/08/97)
> 
> Hank
> 

--
Regards,
Tom
  ________________________________________________________________________
 |   "The Egg Domain"    |       "And all you touch and all you see,      | 
 |    tomg at egg.com       |          is all your life will ever be."       |
 | http://www.egg.com/   |                               (Pink Floyd)     |






From dirk at power.net  Sun Mar 30 14:07:19 1997
From: dirk at power.net (Dirk Harms-Merbitz)
Date: Sun, 30 Mar 1997 06:07:19 -0800 (PST)
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <199703300329.WAA17973@mokushi.psybernet.com>
Message-ID: <Pine.LNX.3.95.970330055509.1048B-100000@hermosa.power.net>


I agree, there is a need for long-haul providers. But they also don't have
to be that big. 20-30 people companies with an annual gross of, say 10
million, would probably do it. All they need is a T3/OC3/OC12 nation wide
mesh which is expensive, but not that expensive. Plus peering arangements.

Try selling a third T3 to a local ISP with 100 T1 clients and two T3s to
larger networks. The local ISP will most likely talk about pricing plus
how hop-counts can be reduced for his customers. Pricing being the more
important factor at this point. 

Dirk

On Sat, 29 Mar 1997 babylon at mokushi.psybernet.com wrote:

> 
> 
> <Stuff Deleted>
> 
> > 
> > Could we have 4000 10 people companies provide Internet connectivity to
> > the majority of US business within a couple of years? At $80-200/month for
> > a T1? This is what "they" are trying to avoid/slow down. 
> 
> I am not sure how you can come to thus conclusion. Where do you think
> the 4000 10 person businesses are getting their connectivity from? I do
> not see them forming their own connectivity to each other. There is a
> need for large providers as well, and they need your business.
> 
> Jonathan
> 
> > 
> > Seems that the Internet turns some things on its head. Like the need to
> > have large corporations for providing large scale Internet services.
> > According to Boardwatch magazine, about 4000 2-10 people ISPs are
> > providing Internet services to the majority of the US. ATT, Sprint and so
> > on can't make money at it but it sure is a great way for a technical
> > person to make $100K/year from with a T1 in a living room.
> > 
> > Dirk
> > 
> >  
> > > Aleph One / aleph1 at dfw.net
> > > http://underground.org/
> > > KeyID 1024/948FD6B5 
> > > Fingerprint EE C9 E8 AA CB AF 09 61  8C 39 EA 47 A8 6A B8 01 
> > > 
> > 
> > 
> 





From mikeg at savvis.com  Sun Mar 30 15:59:13 1997
From: mikeg at savvis.com (Mike Gaddis)
Date: Sun, 30 Mar 1997 09:59:13 -0600
Subject: ARIN is A Good Thing
References: <01BC3C39.DC08D4E0@jfbb.atmnet.net>
Message-ID: <333E8DD1.3F7D@savvis.com>

An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/19970330/23b6f8c4/attachment.html>

From mikeg at savvis.com  Sun Mar 30 16:38:24 1997
From: mikeg at savvis.com (Mike Gaddis)
Date: Sun, 30 Mar 1997 10:38:24 -0600
Subject: ARIN is not/is too/is not/is too... blah.
References: <Pine.LNX.3.95.970330055509.1048B-100000@hermosa.power.net>
Message-ID: <333E9700.6038@savvis.com>

Dirk Harms-Merbitz wrote:

  I agree, there is a need for long-haul providers. But they also
  don't have
  to be that big. 20-30 people companies with an annual gross of, say
  10
  million, would probably do it. All they need is a T3/OC3/OC12 nation
  wide
  mesh which is expensive, but not that expensive. Plus peering
  arangements.

  Try selling a third T3 to a local ISP with 100 T1 clients and two
  T3s to
  larger networks. The local ISP will most likely talk about pricing
  plus
  how hop-counts can be reduced for his customers. Pricing being the
  more
  important factor at this point.

  Dirk

Rest of thread deleted...

Dirk,

You are showing a lack of knowledge about the real costs of long haul
networking.  Economies of scale do not even begin to come into play
until the revenue
hits $50 million or so given the need for a network that is not sparsely
connected or
under provisoned in the backbone.  This is the reality.  There is a
definitive place for the "big boys"
as transit aggregators of bandwidth.  Without them our collective costs
would skyrocket.

Mike Gaddis
Savvis Communications





From randy at psg.com  Sun Mar 30 17:24:00 1997
From: randy at psg.com (Randy Bush)
Date: Sun, 30 Mar 97 09:24 PST
Subject: ARIN is A Good Thing
References: <01BC3C39.DC08D4E0@jfbb.atmnet.net>
	<333E8DD1.3F7D@savvis.com>
Message-ID: <m0wBOL7-000IY3C@roam.psg.com>

> If you know this is fictitious then you must know what the real numbers
> are.

FAQ off.

randy




From netsurf at pixi.com  Sun Mar 30 08:37:36 1997
From: netsurf at pixi.com (NetSurfer)
Date: Sun, 30 Mar 1997 08:37:36 -0000
Subject: ARIN is *NOT* A Good Thing
Message-ID: <199703301837.IAA05283@mail.pixi.com>


Proposed charging up to $20,000 for IP addresses - more unsubstantiated
rumor?

----------
From: David Stoddard <dgs at us.net>
To: nanog at merit.edu
Cc: jfbb at atmnet.net
Subject: Re: ARIN is *NOT* A Good Thing
Date: Friday, March 28, 1997 8:29 PM

  8< snip      8< snip     8< snip

	For the sake of discussion, this is the following fee structure
	that has been proposed by ARIN (see the ARIN proposal page at
	http://www.arin.net/arin_proposal.html):

	Small	$2500/year	/24 - /19 
	Medium	$5000/year	>/19 - /16 
	Large	$10K/year	>/16 - /14
	X-Large	$20K/year	>/14

	Fees are based on your total allocation for the previous year,
	plus another $1,000 per year to maintain membership in ARIN.
	It is safe to say that any ISP able to receive address blocks
	falls somewhere between Medium and X-Large on this chart.

---------

As for an IANA Statement on the subject:

http://www.arin.net/iana.html

=========================================

IANA Statement on ARIN (1/14/97)


------------------------------------------------------------------------
The Internet Assigned Nunbers Authority (IANA) views the move by Network
Solutions to promote the creation of the American Registry for Internet
Numbers (ARIN) as a non-profit, self-supporting, independent operation as a
very positive step and fully supports the general concept. 

--jon. 

Jon Postel
Internet Assigned Numbers Authority

----------





From justin at erols.com  Sun Mar 30 21:55:52 1997
From: justin at erols.com (Justin W. Newton)
Date: Sun, 30 Mar 1997 16:55:52 -0500
Subject: PC Magazine on Internet logjams
Message-ID: <3.0.32.19970330165551.0098e268@justin.erols.com>

At 01:49 PM 3/30/97 +0200, Hank Nussbacher wrote:
>http://www.pcmag.com/issues/1607/pcmg0165.htm
>
>Breaking Up the Internet Logjam (04/08/97)

Wow, this article is so phenominally inaccurate hat it is almost silly. I
wonder who all of the rest of my peering sessions are with if there are
only 20 or so providers connected to NAP's.  

Justin Newton				
Network Architect					
Erol's Internet Services
ISP/C Director at Large




From wayne at eff.org  Mon Mar 31 02:44:38 1997
From: wayne at eff.org (Wayne D. Correia)
Date: Sun, 30 Mar 1997 18:44:38 -0800
Subject: ARIN is not/is too/is not/is too... blah.
In-Reply-To: <Pine.BSI.3.93.970329105749.13595e-100000@sidhe.memra.com>
References: <3.0.1.32.19970329133925.0068c4dc@locnar.games-online.com>
Message-ID: <v03007807af64d54a830d@[204.107.140.22]>

At 11:09 AM -0800 3/29/97, Michael Dillon wrote:
>This will not happen unless you lie to ARIN and forge documents to back up
>your lies. If this did happen, not only would your criminal behavior be
>made public but I would urge the FBI to lay charges against you. If the
>FBI would not do this I would urge ISOC and EFF to file a civil suit
>against you. I suspect the FTC would also have some interest if you are
>selling IP addresses which you do not own since IP addresses are not
>things which you buy, they are also not things which you can sell.

Excuse me? EFF?

_______________________________________________________________________
Wayne D. Correia   Electronic Frontier Foundation  tel: +1.415.436.9333
<wayne at eff.org>    1550 Bryant Street, Suite 725   fax: +1.415.436.9993
                   San Francisco, CA 94103 USA     <http://www.eff.org>






From nathan at netrail.net  Mon Mar 31 03:40:55 1997
From: nathan at netrail.net (Nathan Stratton)
Date: Sun, 30 Mar 1997 22:40:55 -0500 (EST)
Subject: PC Magazine on Internet logjams
In-Reply-To: <3.0.32.19970330165551.0098e268@justin.erols.com>
Message-ID: <Pine.LNX.3.95.970330223631.954C-100000@netrail.net>

On Sun, 30 Mar 1997, Justin W. Newton wrote:

> At 01:49 PM 3/30/97 +0200, Hank Nussbacher wrote:
> >http://www.pcmag.com/issues/1607/pcmg0165.htm
> >
> >Breaking Up the Internet Logjam (04/08/97)
> 
> Wow, this article is so phenominally inaccurate hat it is almost silly. I
> wonder who all of the rest of my peering sessions are with if there are
> only 20 or so providers connected to NAP's.  

Well I think NAP's is referring to more then just 1 NAP. There are under 20
providers connected to say 4 or 5 major NAP's.

Nathan Stratton                                President, NetRail,Inc.
------------------------------------------------------------------------
Phone   (888)NetRail                           NetRail, Inc.
Fax     (404)522-1939                          230 Peachtree Suite 500
WWW     http://www.netrail.net/                Atlanta, GA 30303
------------------------------------------------------------------------
"Therefore do not worry about tomorrow, for tomorrow will worry about 
itself. Each day has enough trouble of its own."           Matthew 6:34





From gmatey at BayNetworks.COM  Mon Mar 31 03:50:01 1997
From: gmatey at BayNetworks.COM (George Matey)
Date: Sun, 30 Mar 1997 22:50:01 -0500
Subject: BGP4 COMMUNITY attribute
Message-ID: <3.0.32.19970330224959.0069f1f4@bl-mail1.corpeast.baynetworks.com>

At 01:08 PM 3/28/97 -0700, Dave Siegel wrote:
>> John W. Stewart II writes:
>> > rfc1997.  i think there's a GateD with communities
>> 
>> Yup.
>
>Bay Networks supports them as well, though I'm not sure if it's in the
>mainstream code...it might only be in 11.01 (ANS code).
>
>Dave

BGP communities have been in mainline Bay code since 11.00.
11.01 is also mainline code that has recently been released.


--
George Matey
Network Engineer
Internet Service Provider Group
Bay Networks




From davidc at apnic.net  Mon Mar 31 04:36:36 1997
From: davidc at apnic.net (David R. Conrad)
Date: Mon, 31 Mar 1997 13:36:36 +0900
Subject: ARIN is *NOT* A Good Thing 
In-Reply-To: Your message of "Sun, 30 Mar 1997 08:37:36 GMT."
             <199703301837.IAA05283@mail.pixi.com> 
Message-ID: <199703310436.NAA18172@palmtree.jp.apnic.net>

[cc's and reply-to to the appropriate place]

>Proposed charging up to $20,000 for IP addresses - more unsubstantiated
>rumor?

Sigh.

Would you *please* read the proposal (http://www.arin.net/arin_proposal.html,
http://www.arin.net/arin_faq.html might also be helpful).  If you had you would 
see that the fee is for allocation _services_ and only applicable to
organizations requesting address space _directly_ from ARIN.

Regards,
-drc





From garyz at savvis.com  Mon Mar 31 15:51:11 1997
From: garyz at savvis.com (Gary Zimmerman)
Date: Mon, 31 Mar 1997 07:51:11 -0800
Subject: Ascend/Netstar GRF 400
Message-ID: <19970331140037.AAA21733@rock>

Yes, we are having very good luck with are GRF1600s also,  We are now Cisco
free, and the GRFs are performing very well.  There are some issues, but
Ascend is stepping to plate on all issues.  We are building a ATM nation
wide network using the GRF to get to the internet.  These things will melt
down a Cisco 75xx router and keep on ticking, and for allot less money. 
Also, did everyone see the WallStreet this morning.  Ascend buys
Cascade.....  Look out, IP switching is really around the corner for all of
us ATMer....

Gary Zimmerman
V.P. Network Engineering
Savvis Communication Corp.
www.savvis.com
Office: 314.719.2423

----------
> From: Nathan Stratton <nathan at netrail.net>
> To: Chris A. Icide <chris at nap.net>
> Cc: 'nanog at merit.edu'
> Subject: Re: Ascend/Netstar GRF 400
> Date: Friday, March 28, 1997 5:33 PM
> 
> On Fri, 28 Mar 1997, Chris A. Icide wrote:
> 
> > Is anyone successfuly using one of these?  I've got one in the labs
> > here, and have found some interesting problems.  Ascend engineers
> > are hot on the problems, but I was wondering if anyone else has any
> > experience.
> 
> Yes, our network is now cisco free! We have been using the GRF1600s for
> several months in our network. We have found a few problems, but Ascend
> has been VERY fast to fix them. So far they blow away the Cisco solution
> we were using.
> 
> > Our current problems seem to be related to buffer overruns on the 
> > ATM/Q card.
> 
> We have not used the ATM/Q card a lot, but I am sure Ascend can fix any
> problem you may have. We are using cascade 900s as backbone switches into
> the GRF 1600s via HSSI. We plan to move this to OC3 as soon as we finish
> testing.
> 
> 
> Nathan Stratton                                President, NetRail,Inc.
> ------------------------------------------------------------------------
> Phone   (888)NetRail                           NetRail, Inc.
> Fax     (404)522-1939                          230 Peachtree Suite 500
> WWW     http://www.netrail.net/                Atlanta, GA 30303
> ------------------------------------------------------------------------
> "Therefore do not worry about tomorrow, for tomorrow will worry about 
> itself. Each day has enough trouble of its own."           Matthew 6:34




From netsurf at pixi.com  Mon Mar 31 06:27:48 1997
From: netsurf at pixi.com (NetSurfer)
Date: Mon, 31 Mar 1997 06:27:48 -0000
Subject: ARIN is *NOT* A Good Thing 
Message-ID: <199703311628.GAA18250@mail.pixi.com>


Earlier I was chastised for stating unfounded rumor about fees of up to
$20,000/year yet a similar fee structure for new registrations/services
from ARIN is being proposed.   Just wanted to point out that I wasn't
referencing unfounded rumor but rather a reference that needed qualified
i.e. allocation services for organizations requesting address space
directly from ARIN.  

----------
From: David R. Conrad <davidc at apnic.net>

>Proposed charging up to $20,000 for IP addresses - more unsubstantiated
>rumor?

Sigh.

Would you *please* read the proposal
(http://www.arin.net/arin_proposal.html,
http://www.arin.net/arin_faq.html might also be helpful).  If you had you
would 
see that the fee is for allocation _services_ and only applicable to
organizations requesting address space _directly_ from ARIN.





From randy at psg.com  Mon Mar 31 17:37:00 1997
From: randy at psg.com (Randy Bush)
Date: Mon, 31 Mar 97 09:37 PST
Subject: ARIN is *NOT* A Good Thing
References: <199703301837.IAA05283@mail.pixi.com>
Message-ID: <m0wBl1O-0007zWC@rip.psg.com>

> Proposed charging up to $20,000 for IP addresses - more unsubstantiated
> rumor?

FAQ off.




From jeff at netstar.com  Mon Mar 31 15:15:13 1997
From: jeff at netstar.com (Jeff Wabik)
Date: Mon, 31 Mar 1997 09:15:13 -0600 (CST)
Subject: Ascend/Netstar GRF 400
In-Reply-To: <19970331140037.AAA21733@rock> from "Gary Zimmerman" at Mar 31, 97 07:51:11 am
Message-ID: <9703311515.AA23669@banzai.netstar.com>


FYI:

Thanks to the good folks at MAGIC, there is now a mailing list for
discussion  of the Ascend GRF.  If you're interested:

	List:		ascend-grf at magic.net	
	Subscribe:	ascend-grf-request at magic.net
	Owner:		owner-ascend-grf at magic.net

Note the list is very new..  Traffic volume is low.

	-Jeff
	

> Yes, we are having very good luck with are GRF1600s also,  We are now Cisco
> free, and the GRFs are performing very well.  There are some issues, but
> Ascend is stepping to plate on all issues.  We are building a ATM nation
> wide network using the GRF to get to the internet.  These things will melt
> down a Cisco 75xx router and keep on ticking, and for allot less money. 
> Also, did everyone see the WallStreet this morning.  Ascend buys
> Cascade.....  Look out, IP switching is really around the corner for all of
> us ATMer....
> 
> Gary Zimmerman
> V.P. Network Engineering
> Savvis Communication Corp.
> www.savvis.com
> Office: 314.719.2423
> 
> > From: Nathan Stratton <nathan at netrail.net>
> > To: Chris A. Icide <chris at nap.net>
> > Cc: 'nanog at merit.edu'
> > Subject: Re: Ascend/Netstar GRF 400
> > Date: Friday, March 28, 1997 5:33 PM
> > 
> > On Fri, 28 Mar 1997, Chris A. Icide wrote:
> > 
> > > Is anyone successfuly using one of these?  I've got one in the labs
> > > here, and have found some interesting problems.  Ascend engineers
> > > are hot on the problems, but I was wondering if anyone else has any
> > > experience.
> > 
> > Yes, our network is now cisco free! We have been using the GRF1600s for
> > several months in our network. We have found a few problems, but Ascend
> > has been VERY fast to fix them. So far they blow away the Cisco solution
> > we were using.
> > 
> > > Our current problems seem to be related to buffer overruns on the 
> > > ATM/Q card.
> > 
> > We have not used the ATM/Q card a lot, but I am sure Ascend can fix any
> > problem you may have. We are using cascade 900s as backbone switches into
> > the GRF 1600s via HSSI. We plan to move this to OC3 as soon as we finish
> > testing.
> > 
> > 
> > Nathan Stratton                                President, NetRail,Inc.
> > ------------------------------------------------------------------------
> > Phone   (888)NetRail                           NetRail, Inc.
> > Fax     (404)522-1939                          230 Peachtree Suite 500
> > WWW     http://www.netrail.net/                Atlanta, GA 30303
> > ------------------------------------------------------------------------
> > "Therefore do not worry about tomorrow, for tomorrow will worry about 
> > itself. Each day has enough trouble of its own."           Matthew 6:34
> 
> 


-- 
Jeff Wabik                              E/Mail:  jeff_wabik at ascend.com
Ascend Communications (www.ascend.com)  Phone:   +1 612 996 6814
High Performance Networking Division    FAX:     +1 612 943 8939
Minneapolis, MN  55344                  Pager:   +1 800 493 9804
	 "The artists formerly known as Netstar, Inc."




From pjnesser at martigny.ai.mit.edu  Mon Mar 31 20:56:16 1997
From: pjnesser at martigny.ai.mit.edu (Philip J. Nesser II)
Date: Mon, 31 Mar 1997 15:56:16 -0500 (EST)
Subject: ARINANOG
In-Reply-To: <m0wB6Mq-000ZC8C@stb.info.com> from "Michael Gersten" at Mar 29, 97 02:12:00 pm
Message-ID: <199703312056.AA207391778@martigny.ai.mit.edu>

Michael Gersten supposedly said:
> 
> Jim raises an extremely good point.
> 
> Why not start ARIN off by giving it a /8 to work with and see how well
> it will actually work?
> 

Guess what.  That IS the plan.

The IANA controls /0 and will retain control of it.  ARIN, just like RIPE
and APNIC will be given a /8 to work from.

> Lets face it, there is only ONE /0, and giving that to ARIN might not
> be a good idea if it doesn't work right. By giving them a /8, they
> will have to compete with other ways of assigning IP addresses, and
> demonstrate that they actually can work.
> 
> Just like a would-be ISP has to start with a /24 and work up...
> 
> 		Michael
> 





From todd.glassey at worldnet.att.net  Wed Mar 12 22:11:25 1997
From: todd.glassey at worldnet.att.net (todd glassey)
Date: Wed, 12 Mar 1997 14:11:25 -0800
Subject: Fw:      website case
Message-ID: <006601bc2f33$13dd5080$020aff0a@home.glassey.com>


FYI -
----- Original Message -----
From: "Rae Cogar" <rcogar at localnet.com>
To: <CLCC-MEMS at MAIL.ABANET.ORG>
Sent: Tuesday, May 14, 2002 7:26 AM
Subject: website case


> Here is a recently reported case from California that found a company
> guilty of spoliation of evidence by changing information on their
> website during litigation.   One point made by the court in this case is
> there were no policies or procedures for the updating or deleting of
> material from the website.  You can find this opinion at:
>
>
>
http://www.cand.uscourts.gov/cand/tentrule.nsf/4f9d4c4a03b0cf70882567980073b
> 2e4/cf68f686007991fa88256af1006a9e16?OpenDocument
>
> (you will need to cut and paste url)
>
> Spoliation Sanctions for Deletion of Web Page
> The defendant corporation moved to dismiss for lack of personal
> jurisdiction, denying minimum contacts with the state of California.
> The plaintiff offered as evidence a page from the defendant's web site
> that listed a California office address.  While the motion was pending,
> the California address disappeared from the defendant's web site.
> Though one employee of the defendant testified that he had deleted the
> page in routine maintenance, there was no corporate maintenance policy
> that would explain the deletion.  The court granted the plaintiff's
> motion to enjoin further spoliation and ordered that the defendant pay
> plaintiff's attorney's fees as a sanction. Pennar Software Corp. v.
> Fortune 500 Sys., 51 Fed. R. Serv. 279 (N.D. Cal. 2001).
>
>
> Another case for good records management!
>
> Rae Cogar, Esq.
> RCS Consulting
> Hamburg, NY  716-646-6192
> rcogar at localnet.com