- NZNOG - lists.nznog.org

OT: Seeking a Book
by Anaru Hartley 05 Mar '05

05 Mar '05

Hello All, I have been looking for a way to progress my career in the Telecommunications Industry and a good friend of mine suggested that I read this particular book. I was hoping one of you individuals would be able to put me in the direction of one or might be able to lend me a copy of it. Here is a picture of the books cover: http://www50.brinkster.com/photochopnz/top.jpg Thanks in advance!

2 2

Cisco 2600 LNS help.
by Neil Fincham 05 Mar '05

05 Mar '05

Hi all, On of my clients has had a bit of a disaster and lost their config for a Cosco 2600 that they were using as an LNS for telstraclear's network, I have put the basic information back in (IP, Routes etc) but my cisco speek for LNS and Radius is non existant. Could someone cut and paste the relevent bits out of one of their routers (minus passwords and such) and send it to me. As you can imagine this is quite urgent and help would be greatly appreiciated, this is what I have at the moment;- L2TP#write terminal Building configuration... Current configuration : 1642 bytes ! version 12.3 service timestamps debug uptime service timestamps log uptime service password-encryption ! hostname L2TP ! boot-start-marker boot-end-marker ! ! voice-card 0 dspfarm no local-bypass ! aaa new-model ! ! aaa authentication login default local aaa authentication ppp default local aaa authentication ppp vpdn group radius aaa authorization network default group radius aaa accounting network default start-stop group radius aaa session-id common ip subnet-zero ! ! ! ! ip name-server 203.97.37.1 vpdn enable ! vpdn-group 1 accept-dialin protocol l2tp virtual-template 1 terminate-from hostname sp_lac ! no ftp-server write-enable ! ! ! ! ! ! ! ! ! ! ! ! syscon password XXX syscon community XXX ! ! controller E1 0/1 ! ! ! interface FastEthernet0/0 ip address XXX.XXX.XXX.XXX 255.255.255.248 speed auto half-duplex no mop enabled ! interface Serial0/0 no ip address shutdown ! interface FastEthernet0/1 description connected to EthernetLAN ip address XXX.XXX.XXX.XXX 255.255.255.248 duplex auto speed auto ! interface Virtual-Template1 ip unnumbered FastEthernet0/1 peer default ip address pool default ppp authentication chap vpdn ppp multilink ! ip classless ip route 0.0.0.0 0.0.0.0 XXX.XXX.XXX.XXX permanent ip route 203.98.24.0 255.255.255.0 XXX.XXX.XXX.XXX permanent ip route 203.98.25.0 255.255.255.0 XXX.XXX.XXX.XXX permanent no ip http server ! ! snmp-server community public RO snmp-server enable traps tty snmp-server manager ! radius-server host XXX.XXX.XXX.XXX auth-port 1812 acct-port 1813 radius-server key XXXXXXXXXX ! control-plane ! ! ! ! ! ! ! ! line con 0 line aux 0 line vty 0 4 ! ! ! end Thanks for any help. No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.6.2 - Release Date: 4/03/2005

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. --- OBJECT BELOW CREATED: aut-num: AS24347 as-name: NZRR-AS24347 descr: Intergen descr: WIX peering at '202.7.0.121' descr: see Citylink RT job #1990 admin-c: RPA1-NZRR tech-c: RPA1-NZRR import: from AS9439 accept ANY AND NOT fltr-bogons export: to AS9439 announce AS24347 notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dwayne.bace(a)intergen.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR --- OBJECT BELOW CREATED: route-set: AS9439:RS-ROUTES:AS24347 descr: Route set advertised to AS9439 by Intergen - AS24347 members: 202.126.80.0/21^21-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: dwayne.bace(a)intergen.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR

1 0

tradme etc
by Simon Lyall 03 Mar '05

03 Mar '05

Interestign wee article: http://www.nzherald.co.nz/index.cfm?c_id=5&ObjectID=10113474 Somebody might know this fior sure but doesn't AT&T (trademe's upstream) connect to APE? Just I can't see trademe's routes being advertised there. -- Simon J. Lyall. | Very Busy | Mail: simon(a)darkmere.gen.nz "To stay awake all night adds a day to your life" - Stilgar | eMT.

7 6

How fair practice is this; is it spam? - Orcon Response
by Craig Whitmore 03 Mar '05

03 Mar '05

This has been posted on Behalf of Orcon MD by Craig Whitmore --- There appears to have been a serious mis-understanding between Barry and Orcon on this matter Orcon has NOT spammed Barry's customers, and Barry's post is very mis-leading. I will clarify Orcon's position, and lay out the facts, and then I suggest that Barry and Orcon take this matter offline as it is not something that needs to be discussed in NZNOG. Orcon has not, and never will: a) Spam potential customers seeking to provide them services b) Poach customers deliberately from wholesale customers, as a significant portion of our revenue comes from wholesale. What has happened is that our marketing department has been in MUTUAL contact with the owner of a single website, and came to an arrangement whereby we would receive free advertising on the person's website in return for providing free web-hosting and domain name registration. Our marketing department was not aware that this website owner was actually a customer of a customer of Barry's. The website owner has contacted their provider (a customer of a Barry's), and told them that they were moving to us, and the provider and Barry have come to the knee-jerk reaction that we are trying to poach customers. This is absolutely NOT the case. Once Barry made us aware of the issue, Barry's account manager tried to point out that end users are free to choose whichever web hosting provider they want, and that sometimes we lose customers to our wholesale hosting customers and vice-versa - this does NOT mean we are poaching customers or spamming people. However, our account manager communicated this to Barry in a less than elegant manner, and via email, after I had specifically asked that Barry be called so that the situation could be discussed and explained rationally. It is NOT our desire that Barry be upset, This is a SINGLE website owner who had prior discussions with our marketing department, and this conflict has only just been brought to our attention. Thanks for reading NZNOGer's - thanks for your time. Regards Seeby Woodhouse MD Orcon Internet -----Original Message----- From: Barry Murphy [mailto:barry(a)unix.co.nz] Sent: Friday, March 04, 2005 2:23 PM To: nznog(a)list.waikato.ac.nz Subject: [nznog] How fair practice is this; is it spam? ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

2 1

problems with NTP on bigben?
by Simon Blake 03 Mar '05

03 Mar '05

Anybody else observed that bigben gained about 19 years at about 1:25pm this arvo? $ date Tue Jan 1 14:54:33 NZDT 2002 $ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276 1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset -0.001089 sec $ /usr/sbin/ntpdate -q bigben.clix.net.nz server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613 1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset 619315199.998172 sec - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 20

How fair practice is this; is it spam?
by Barry Murphy 03 Mar '05

03 Mar '05

ok.... how fair is this... I purchase telehousing from orcon and register domains through them. They have spammed one of my customers offering to host their website free of charge in return for advertising space on their website. After hearing this I emailed my account manager at orcon and this was his response. "As Im sure you are aware, Orcon also runs hosting, and as such, from a marketing perspective we have to treat other web hosting companies as competition, even if they are buying wholesale services from us. All other ISP's do the same - Telecom actively market to our customers for all ISP services even though we purchase a massive amount of wholesale services off them. " Is this spam/fair practice? Seeing as they could obtain a list of these domains in their database (as they're the registrar for this domain) Kindest Regards Barry Murphy

3 2

Notification of NZRR Database changes
by NZRR Database Notifications 03 Mar '05

03 Mar '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. The update causing these changes had the following mail headers: - From: Andy Linton <asjl(a)citylink.co.nz> - Cc: - Subject: [CityLink #1987] Routing updates for APE Route Servers (fwd) - Date: Fri, 4 Mar 2005 13:10:15 +1300 (NZDT) - Msg-Id: <Pine.LNX.4.58.0503041309040.991(a)jennings.citylink.co.nz> NZRR Database Notification Department --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS4770 descr: advertised to AS9439 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.90.0/23^23-29, 199.212.92.0/23^23-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050225 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS4770 descr: advertised to AS9560 by ICONZ - AS4770 members: 138.235.0.0/16^16-29, 192.107.113.0/24^24-29, 192.173.16.0/21^21-29, 198.32.66.0/24^24-29, 199.212.93.0/24^24-29, 202.6.84.0/24^24-29, 202.12.70.0/24^24-29, 202.12.248.0/21^21-29, 202.14.100.0/24^24-29, 202.20.6.0/24^24-29, 202.21.130.0/24^24-29, 202.21.136.0/23^23-29, 202.36.155.0/24^24-29, 202.36.157.0/24^24-29, 202.36.32.0/24^24-29, 202.36.36.0/22^22-29, 202.36.44.0/24^24-29, 202.36.45.0/24^24-29, 202.36.76.0/23^23-29, 202.36.119.0/24^24-29, 202.37.136.0/24^24-29, 202.37.140.0/22^22-29, 202.37.144.0/21^21-29, 202.37.163.0/24^24-29, 202.37.197.0/24^24-29, 202.37.200.0/22^22-29, 202.37.224.0/21^21-29, 202.37.232.0/24^24-29, 202.37.240.0/23^23-29, 202.37.252.0/23^23-29, 202.37.76.0/24^24-29, 202.37.85.0/24^24-29, 202.41.136.0/22^22-29, 202.41.140.0/24^24-29, 202.46.190.0/24^24-29, 202.49.62.0/24^24-29, 202.49.89.0/24^24-29, 202.49.249.0/24^24-29, 202.49.159.0/24^24-29, 202.50.87.0/24^24-29, 202.50.246.0/24^24-29, 202.55.96.0/20^20-29, 202.74.224.0/21^21-29, 202.78.240.0/23^23-29, 202.182.192.0/19^19-29, 205.233.128.0/21^21-29, 205.233.136.0/23^23-29, 205.233.243.0/24^24-29, 210.185.0.0/18^18-29, 210.48.0.0/17^17-29, 210.54.136.0/22^22-29, 210.54.140.0/24^24-29, 210.54.160.0/19^19-29, 210.55.182.0/23^23-29, 210.55.24.0/22^22-29, 210.55.253.0/24^24-29, 210.56.32.0/20^20-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: john(a)iconz.net mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050304 source: NZRR

1 0

The Impact of the Reworked TTL Field on Regional IP Allocations
by Jim Fleming 02 Mar '05

02 Mar '05

The Impact of the Reworked TTL Field on Regional IP Allocations The TTL Field (or Hop Count) is normally 8-bits wide. Some operating systems start it with a value of 255 (all 1s) and some with 64 and other smaller values. In order to improve services for broad-band users, there is a benefit in **reducing** the size of the TTL Field from 8-bits to 4-bits. That limits the maximum number of hops to 15. Equipment that auto-encapsulates can work around this by moving a packet a long distance and then removing a wrapper and allowing it to have some of the hops near the source and some near the destination. Reducing the TTL Field to 4-bits frees up 4-bits for address expansion. With two of those bits for the Source and two bits for the Destination, the entire legacy Internet plus three more equal size address spaces can be supported, without changing the existing protocol header size. One could view that as a planar Internet or a 4-story office building. Existing allocations of address space could all be viewed as from one plane or one could map regions to the 4 planes, allowing a region to expand to space used by another region because the extra bits prevent collisions and provide unique allocations. Another approach is to use the 4 planes for local networks, VPNs, a wireless extranet, and the legacy Internet (core). In a restricted approach only intra-plane traffic is allowed. A totally open approach would allow any node to address any other node. This would be like any location in the 4-story office being able to connect with any other, rather then be restricted to intra-floor-only connections. A more conservative approach is simply to zero the left-most 4 bits and reserve (save) the other three planes for future generations, once equipment is better able to route and process the reworked TTL Field. Current market trials and tests with broad-band-only subscribers will help to determine which approach has the most benefit. IP address allocations are already being red-lined for re-allocation and use in other planar nets because they can not be reached in 15 hops from/to certain regions of the world. Since there may not be any bandwidth to those regions anyway, it does not matter because the laws of physics will prevent broadband services from becoming available in one region with the same level of service observed in another region. Voice services are of course "the killer apps" and place great demands on the aging best-effort transports. As new equipment is provisioned it can be done with an awareness of the benefits of using a smaller TTL Field. Some might argue that 15 hops is stilll too many and one or two more bits should be removed leaving a 7 hop or a 3 hop limit. The 7 hop approach only frees up 1 more bit and it can be combined with the unused 49th bit to add another entire bit to both the source and destination fields. The 3 hop approach makes one look sooner at the needed equipment to bypass the aging legacy core. Having 6 added bits for addressing and 8 planar levels can have more long-term benefits and there can still be a short-term work-around because the 3-bits of the destination address field can be allowed to be processed by *existing* TTL algorithms and packets then transform their addressing as they pass thru the core network. The address bits can then be used to prioritize delivery by allowing packets that come from a long distance to be processed before those that come from closer locations. They appear to be going to different destinations by looking at the changed TTL value as an address. Since packets now travel greater distances with less decrements of the hop-count the 7 hop approach may be the best compromise. Eventually, the free-market place will decide. People can not make "governance" decisions based on 20 year old designs and how they are applied in regions of the world that have no bandwidth. That is the lowest-common-denominator approach advocated by The Big Lie Society. As people have seen, that prevents a nation from Running at the speed of light. Jim Fleming A.Net

4 3

Read-Only BLOB (packet) Additions to the IP Protocol
by Jim Fleming 02 Mar '05

02 Mar '05

Read-Only BLOB (packet) Additions to the IP Protocol An analysis of many packets of data show that the same binary content appears over and over. This is especially the case when a smaller and smaller size BLOB is considered. For example, a 512 byte (octet) BLOB contains 4096 bits (ones or zeroes) and there can be a large number of **unique** BLOBs, in fact, approximately (1.0443888814131525066917527107166e+1233). If users are able to create (own?) any number of the unique BLOBs and then place them in a public cache (library), then new broadband modems can pull those BLOBs in and attach them to packet headers. Since the BLOBS are read-only and never change, once created, they can each have their own IP address as the "source". The destination address is the end-user's system. One obvious BLOB is a 512 byte BLOB of all zeroes. Another obvious one is all ones. Those can be two of the possible BLOBS. If a 32-bit index (handle) is used to specify a unique BLOB, then there can be exactly 4,294,967,296. It might take several BLOBS to hold commonly communicated binary content. Also, several BLOBS may be needed if graphics/voice/sound is recorded vs. text. Compression can be allowed because the BLOB is just 512 bytes of arbitrary ones and zeroes. Also, careful attention to repetition in tones (like dial-tone in VOIP) can result in the same BLOB being used over and over with no clicks or gaps noticed between BLOBs. With that as a bit of an intro, no pun intended, some "Internet Governance" questions come to mind. 1. Who owns the content of the BLOBs ? 2. If it costs $1 dollar (OZ dollars) to "register" a unique BLOB who collects that $4,294,967,296 ? 3. How and where will the BLOBs be cached ? 4. Do the users really care where they come from as long as their broad-band system works "better" ? 5. Are people concerned that the same BLOB may appear over and over, creating boring content ? 6. Are people concerned that a small error could become part of a read-only archive and live for a long time ? 7. As a follow-on to #6, would another BLOB be allowed ? to fix that error ? 8. Is first-come-first-serve the best way to sell off the BLOBs? 9. Should existing archives and databases be encoded first ? at no charge ? 10. Once one BLOB address space is used up, should another be opened up ? 11. Will there be vanity-value in owning a BLOB ? Is the one-millionth BLOB special ? 12. Will BLOBs that can be compressed be favored ? 13. Should there be an age-limit to register a BLOB ? For the curious, the entire BLOB cache would be 2,199,023,255,552 bytes without compression. An ISP can cache the entire BLOB space and do inserts in the last mile of the broad-band connection. The broad-band "modem" can of course cache a working set of the most common BLOBs. Is this bit torrent at the IP level ? http://bittorrent.com/ Jim Fleming A.Net

3 2