- ripe-list - mailman.ripe.net

[SRI NISC: Domain Survery -- July 1992]
by Tony Bates +44 71 405 8400 29 Jul '92

29 Jul '92

I don't see this forwarded yet so I'll do the honours. FYI. Tony Bates, ULCC ----- Forwarded message # 1: Received: from [128.9.0.32] by Ean-Relay.AC.UK via Ethernet with SMTP id aa00898; 29 Jul 92 6:48 BST Received: by venera.isi.edu (5.65c/5.65+local-6) id <AA14823>; Tue, 28 Jul 1992 11:22:45 -0700 Received: from phoebus.nisc.sri.com by venera.isi.edu (5.65c/5.65+local-6) id <AA14818>; Tue, 28 Jul 1992 11:22:42 -0700 Received: by phoebus.nisc.sri.com (5.64/SRI-NISC1.1) id AA26031; Tue, 28 Jul 92 11:17:56 -0700 Date: Tue, 28 Jul 92 11:17:56 PDT From: SRI NISC <nisc(a)com.sri.nisc> To: ietf(a)edu.isi Cc: nisc(a)com.sri.nisc, tcp-ip(a)mil.ddn.nic Subject: Domain Survery -- July 1992 Message-Id: <CMM.0.90.2.712347476.nisc(a)phoebus.nisc.sri.com> Network Information Systems Center July 1992 SRI International Internet Domain Survey The Domain Survey attempts to discover every host on the Internet by doing a complete search of the Domain Name System. The latest results gathered during late July 1992 are listed. For more information see RFC 1296; for detailed data see the pub/zone directory on ftp.nisc.sri.com. This survey was done using the census program developed at the University of California Santa Cruz; see technical report UCSC-CRL-92-34 available on host ftp.cse.ucsc.edu in pub/csl. -- Mark K. Lottor Hosts: 992,000 [890,000 hosts in Apr 1992] Domains: 16,300 [approximately] Network number analysis of all IP addresses listed in the DNS: Percent Of Network-Address-Space Capacity Being Used Number of Networks 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Class A: 60 100% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% Class B: 2714 99.9% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% Class C: 3795 85.0% 7.6% 3.0% 1.5% 0.9% 0.9% 0.4% 0.2% 0.2% 0.0% Total: 6569 [for example: 3.0% of class C networks have 30% of the available class C address space (256 hosts) assigned to hosts] Host Distribution by Top-Level Domain Name 326630 edu 21021 se 2902 kr 943 br 74 hu 277551 com 19192 fr 2803 il 789 mx 50 int 62584 gov 17188 ch 2733 dk 633 pl 43 ee 48639 au 15757 jp 2410 hk 624 ie 14 yu 43907 de 15718 fi 2118 tw 616 gr 8 tn 38929 ca 14354 no 2073 za 569 cs 6 in 37776 uk 7044 net 1831 nz 400 is 5 ve 33161 mil 6489 at 1532 be 201 us 5 aq 25896 org 5147 it 1318 pt 165 cl 2 ar 21105 nl 3603 es 949 sg 80 lu 1 th Top 50 Host Names 508 venus 377 gw 303 eagle 263 fred 240 mac12 471 pluto 360 mercury 301 mac5 262 sirius 240 mac11 438 mars 355 iris 296 gauss 262 mac8 236 alpha 421 cisco 351 pc2 292 pc3 262 hermes 235 mac13 408 pc1 337 mac3 284 mac6 259 mac9 234 mac14 407 jupiter 334 orion 275 hobbes 257 calvin 231 phoenix 405 zeus 320 mac4 274 mac10 254 pc4 231 mozart 405 mac1 310 newton 271 mac7 253 apollo 231 mac15 383 mac2 310 neptune 266 thor 248 athena 227 earth 381 saturn 306 charon 263 merlin 243 titan 226 mac16 ----- End of forwarded messages

1 0

12th RIPE Meeting Minutes
by Anne Lord 27 Jul '92

27 Jul '92

Dear All, Thanks to all those who commented on the 12th RIPE meeting minutes. Copies of the minutes have now been placed in the document store and are available in ASCII format (.txt) and in PostScript (.ps). As usual these minutes will need to be formally accepted at the next RIPE meeting in September, so if you have any additional comments, please make them known before then. Regards, Anne.

1 0

RIPE 13 - Meeting announcement
by k13＠nikhef.nl 24 Jul '92

24 Jul '92

R I P E meeting announcement ============================= This is to announce that the 13th RIPE meeting will take place: dates: 30 September 14:00h - 18:00h 1 October 09:00h - 18:00h 2 October 09:00h - 16:00h place: Ecole Nationale Superieure des Telecommunications (Telecom Paris) 46, rue Barrault Paris 13 metro: - Place d'Italie, or - Corvisart NOTE: - In order to facilitate the logistics of the meeting, could you please give notice of your coming a.s.a. possible to anne(a)ripe.net and NOT TO THE LIST. - old hands: please bring your RIPE badge - newcomers: please provide the following info for your badge: + full name + affiliation + country to the above address. Agenda: a detailed agenda will be mailed the first week of September. Don't hesitate to suggest topics of interest. Appended to this announcement: - how to reach the meeting place - hotels in Paris ############################################################################## How to reach the Ecole Nationale Superieure des Telecommunications ================================================================== - Take the RER-B to Chatelet from the airport. - Transfer to Line 7, direction Mairie d'Ivry/Villejuif. Don't get lost, it's a bit of a labyrinth. - Get off at the metro station Place d'Italie. - Exit onto "rue Bobillot". - Walk south-west down rue Bobillot until you come to the second set of traffic lights and a church on the right-hand corner. - Turn left and walk west on rue Tolbiac. - After 4 short blocks, you will find yourself standing in front of a large, fairly modern apartment build with a highly visible "La Poste" sign in front. - Turn right up the street (rue Barrault), go 20m, and you will be standing in front of the main entrance of the school. - Directions will be posted inside. ############################################################################### Hotels in Paris, conveniently reachable from the meeting place: Name/Price Address Phone Fax =========================================================================== Hotel Urbis 177, rue de Tolbiac 45.80.16.60 45.80.95.80 FF 350 75013 Paris TIM Hotel 22, rue Barrault 45.80.67.67 45.89.39.63 FF 360 75013 Paris Pullman St-Jacques 17, bd St-Jacques 40.78.78.40 45.88.43.93 FF 1015 75014 Paris Hotel Etchegarry 43, rue Broulebaide 43.36.22.41 FF unknown 75013 Paris All phone and fax numbers should be read as: +33 1 <quoted number>

1 0

RIPE version of whois client
by Marten Terpstra 24 Jul '92

24 Jul '92

Gang, we made a RIPE version of the well known whois client. This version will by default query "whois.ripe.net", includes the -a flag for other than RIPE database information, and has some compiled in features that can find secondary RIPE database servers nearer to your machine. Check the README and Makefile for this. Below is the manpage. You can find this version on: ftp.ripe.net:/tools/ripe-whois.tar.Z If anyone has problems compiling or running the thing, please let us know. -Marten ----------------- WHOIS(1) USER COMMANDS WHOIS(1) NAME whois - TCP/IP Internet directory service, RIPE version SYNOPSIS whois [ -h host ] [ -v ] [ -a ] identifier DESCRIPTION whois searches for an object in the RIPE Network Management database. The key can be either a name (such as "Karrenberg"),a nic-handle (such as "DK58"), a network number ("192.87.45") or a domain name ("ripe.net"). OPTIONS -h host Select alternate host to direct the query -a This causes the server to include information from non-RIPE whois databases in the reply. Currently these are the public parts of the US NIC and NSFnet databases. Please note that the RIPE NCC does not maintain these databases. The information is included for for your convenience only. -v verbose mode (debugging purposes only) EXAMPLES example% whois karrenberg person: Daniel Karrenberg address: RIPE Network Coordination Centre address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: Netherlands phone: +31 20 5925065 fax-no: +31 20 5925155 e-mail: dfk(a)ripe.net nic-hdl: DK58 changed: dfk(a)ripe.net 920407 changed: ripe-dbm(a)ripe.net 920407 source: RIPE RIPE VERSION This is the RIPE version of the whois client program. This is intended for European users as it will query a RIPE whois server by default rather than the US NIC whois server. For questions refer to <ncc(a)ripe.net>. For more information about the RIPE database please also refer to <ncc(a)ripe.net> This version also includes a compiled-in option to find secondary RIPE database servers closer to your machine, if there are any. Sun Release 4.1 Last change: 23 July 1992 1

1 0

Boston IETF report
by Marten Terpstra 22 Jul '92

22 Jul '92

IETF trip report ================ The 24th IETF was held in the Hyatt Regency hotel in Boston (actually in Cambridge) from July 13th to the 18th. There were 675 attendees, an all time record. The IETF consisted of several plenary sessions and technical reports, and some 80 working group sessions and "Birds Of a Feather" (BOF) sessions, also an all time record. The conference hotel was connected to the Internet by means of a 10 Mbits/sec laser link between the hotel and MIT, a few blocks down the road. The following report consists of reports of areas of interest for RIPE, the RIPE NCC and of personal interest. Please note that the report is a personal impression. If you have any questions about all of this please send mail either to me directly <marten(a)ripe.net> or the NCC <ncc(a)ripe.net>. Shared Whois Project ==================== MERITs taken up a project to align the network databases of the US NIC, RIPE and MERIT. Their first approach is to load all databases into a temporary X.500 database and find all conflicts. The conflicts will then be solved between the three partners in this project. The initial conflicts to resolve are network names and responsible persons. The initial structure used for database alignment is a non-standard structure designed by MERIT, which will be used ONLY for the database alignment. A more definite structure will be designed in close cooperation with the OSI Directory Services group of the IETF. A longer term project is to find a means of actually distributing the databases among the (initially three) partners. The basic idea was to use X.500 for this distributed database, but it will need quite some research to find an appropriate structure. MERIT will take the lead in the whole project, the US NIC and the RIPE NCC will of course work in close relationship with them. contact persons: RIPE NCC <ncc(a)ripe.net> Sheri Repucci <smr(a)merit.edu> BGP and BGP deployment ====================== The BGP-4 specifications have been finalized at this IETF and will be send out to the IESG for proposed standard. BGP-4 will support classless addressing and routing following the CIDR proposal. The first BGP-4 field tests between several implementations are planned for January 1993. MERIT will coordinate interoperability tests. Peter Lothberg gave a presentation of the current situation of EBONE, specifically the BGP implementation in EBONE. Currently, the EBONE BGP network seems to be the biggest network running BGP-3. The US BGP network is mostly using BGP-2 and BGP-1. Gated and Cisco implementation of BGP-3 seem to be stable. references: internet-drafts: draft-ietf-bgp-bgp4-00.txt draft-ietf-bgp-bgp4-01.txt draft-ietf-bgp-experience-00.txt draft-ietf-bgp-usage-01.txt Global IP addressing ==================== It was generally accepted that CIDR will be used as the interim solution, until a new version of IP will solve the addressing and routing problems. The IP addressing plan that will be used, will be a merger of two proposals written by Daniel Karrenberg/Bernhard Stockman and Tony Li/Yakov Rekhter. Bernhard Stockman and Tony Li will merge the two documents, and hope to send the document as an informational RFC within 2 months. references: internet-drafts: draft-karrenberg-proposal-00.txt draft-rekhter-ipaddress-guide-01.txt Global Internet Exchange (GIX) ============================== There was quite some discussion on a GIX which should provide a interconnection point for everyone who whishes to connect globally. The model is similar to the NSFnet "NAP" proposal. No official sessions were held. The IEPG has taken a lead in coordinating and engineering the GIX. The GIX will most probably be located at the US east-coast. contact person: Bernhard Stockman <boss(a)ebone.net> IPv7 ==== The "hottest" item at this IETF was the IAB position with regards to IPv7. The IAB retracted its position on the first day of the IETF, to align with the IESG recommendation. That recommendation says that we should start CIDR now, and wait until the November IETF to make a decision on what IPv7 will be. There have been several proposals for IPv7 or parts of it (PIP, NIMROD, TUBA and others). They can all be found in the internet-drafts directory of your favorite internet-drafts server (ftp.ripe.net for instance). Following the IPv7 statement of the IAB, in the Thursday evening open plenary, there was a large debate on the relation between IAB, IETF, ISOC and other bodies. references: internet-drafts: draft-tsuchiya-pip-00.[ps|txt] draft-tsuchiya-pip-overview-01.[ps|txt] draft-callon-routing-00.ps draft-chiappa-ipaddressing-00.txt draft-chiappa-routing-00.txt draft-iab-ipversion7-00.txt rfc1347.txt Policy based Routing ==================== There was a lot of action in the field of policy based routing. It really is something that people need now, and we will certainly need even more in the future. There are tests going on with IDPR (Inter Domain Policy Routing). One of the IPv7 proposals (PIP) even has Policy information inside a packet. In the BGP session there was some discussion on "BGP communities" which would let you give a route a certain community (for instance "educational") The CIDR proposal and policy based routing may conflict in terms of optimal address assignment. It was therefore suggested that different policies should have different CIDR blocks. references: internet-drafts: draft-ietf-idpr-* Whois ===== WHOIS is now an official Internet Standard. There will be some effort to recommend a certain standardized output from whois servers. How this will proceed is not very clear to me. Operational Requirements Area Directorate ========================================= The ORAD will restructure itself. They have made a list of actions which will all be reviewed. The intention is to set up a ORAD board of about 12-16 people to review each internet-draft on operational impact. contact person: Bernhard Stockman <boss(a)ebone.net> Phill Gross <pgross(a)ans.net> Audiocast/Videocast =================== As you may have heard, parts of the IETF have been audio and videocast throughout the world. The current estimates are that over 200 people joined the audiocast during the week, and some 100 joined the videocast. At this meeting the videocast was one way only, but work in underway to make the videocast two way at the next IETF. This videocast test used 4 frames/sec video using some 200 Kbits/sec if there was motion. For the videocasting of slides, only when the slide changed the 200 Kbit/sec was needed. The audiocast was already two-way, and of good quality. The RIPE NCC joined the audiocast in the middle of the week, and setting up of all the software took about an hour. The audiocast used from the IETF used 64 Kbit/sec, if there was any sound. The NCC has done some tests, and a different encoding which uses 32 Kbits/sec gave almost the same quality. Other encoding mechanisms use only 4.8 Kbit/sec and are still reasonable. The RIPE NCC has proposed an audiocast test within the RIPE community. This could be used to audiocast parts of RIPE meetings, have working group audio conferences etc. contact person: RIPE NCC <ncc(a)ripe.net> Other topics ============ The following "hot" topics were also discussed, but I did not attend the sessions or have not much to say about them. - Mobile IP, presentations and discussions, approved charter. Steve Deering <deering(a)xerox.xom> - OPSTAT, finalized draft, ready for informational RFC Bernhard Stockman <boss(a)ebone.net> - User Connectivity Problems, discussion about ticketing systems Dan Long <long(a)bbn.com> - DNS, DNS MIB under discussion, restructuring of .com and .edu domains under discussion. BIND 4.9 will come out within 1 to 2 months. It will contain all of the patches people currently use in 4.8.3 plus the RP resource record. Also processing speed and various other bugs have been improved and fixed. Next Meetings ============= 25th IETF - Nov 92 Washington DC (hosted by Sprint) 26th IETF - Spring 93 Columbus Ohio 27th IETF - Jul 93 Amsterdam (hosted by SURFnet) <<=== (A "hands up" poll showed that around 70 percent of all people present at the IESG plenary -- around 250 people -- will attend the first IETF in Europe. All in all, Erik Huizer from SURFnet estimates to have around 500+ people at the Amsterdam IETF)

1 0

Re: Mailing List for NCC Referrals to Network Service Providers
by Daniel Karrenberg 20 Jul '92

20 Jul '92

To jog your memory: the proposal was to set up a mailing list of all IP service providers and to post all referral requests that reach the NCC on that list. This way all providers get the address of the prospective customer at the same time and can get in touch with them however they see fit. The whole process is streamlined and the NCC stays out of the loop as much as possible to avoid any bias. The proposed name of the list is ip-provs(a)ripe.net. Any IP service provider can subscribe to it by sending a request to ip-provs-request(a)ripe.net. The list is *not* intended for any discussion whatsoever. We have not only received no objections to the ip-provs(a)ripe.net list proposal but a total of eight subscriptions before the list request address was even active. This means that the list has been created. Current subscribers will be notified via the newly established list soon. If you do not receive the notification or would like to subscribe now, please send mail to ip-provs-request(a)ripe.net. For the NCC Team Daniel Karrenberg

1 0

Wrap-up Report: 3rd Network Seminar/Intensive Course
by Wilfried Woeber, CAN ACOnet/TU-Wien, +43(1)58801-3614 15 Jul '92

15 Jul '92

Wrap-up Report, 3rd Network Seminar and Intensive Course ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Friday, July 10, 1992, the "Third Network Seminar and Intensive Course" for Scientists and Network Managers from Central Europe was closed after a very busy week of lectures, presentations and discussions in the field of networking. Presentations were given by lecturers from various Austrian Universities and companies (Softlab, DEC) as well as by representatives of the national R&D networks from The Netherlands (SURFnet) and Switzerland (SWITCH), and by the Vice-Chairman of DECUS Munich. The most valuable contributions by all the speakers to the success of the event are gratefully acknowledged! The seminar was supported and collectively funded by - the Rectorate, University of Technology, Vienna, - the Austrian Ministry of Science and Research, - the University of Technology Extension Centre, Vienna - and (last but not least) Digital Equipment Corp., Europe. During the seminar an ad-hoc panel session and discussion forum was organized in order to present and discuss the current state of the various national research networking projects in PL, CS, HU, HR, SI, RO and BG. This panel was chaired by Laszlo Csaba, representing HUNGARNET. Given the success of these seminars and the very positive responses from the participants, ACOnet expects to run similar events in the near future. FYI, the following table lists the number of participants from ECE-countries for the three network seminars: 1st 2nd 3rd total ------------------------------------- BG - - 6 6 CS 18 18 13 49 HU 15 9 10 34 HR - - 4 4 PL 12 20 13 45 RO - - 6 6 SI - - 6 6 ------------------------------------- 45 47 58 150 -------------------------------------------------------------------------------- Wilfried Woeber : E-mail: woeber(a)access.can.ac.at (Internet) CAN/ZWK - ACOnet : woeber(a)can.aconet.ada.at (X.400) c/o Vienna Univ. of Technology : | | | | | Gusshausstrasse 25/E027 : S O P A C A-1040 Vienna, Austria, Europe : Tel: +43 1 58801 3614, Fax: +43 1 5056849 --------------------------------------------------------------------------------

1 0

Mailing List for NCC Referrals to Network Service Providers
by Daniel Karrenberg 13 Jul '92

13 Jul '92

As a NIC of the last resort the NCC is getting requests from prospective European Internet users on how to connect and consequently which service provider to use. Of course we strive to give complete and unbiased information to people contacting us. Thus far we have been working with a list of service providers based on information sent to us after earlier polls. This is cumbersome because: The list is sparsely populated and never up-to-date. Entries often do not have comparable information. People calling on the phone often want a specific recommendation and cannot understand that we are not able to give that as the NCC has to remain impartial vis a vis the different providers. In order to overcome those problems I propose to get any requesters into contact with all potential suppliers as quickly as possible. The best way to achieve this is to set up a mailing list of all IP service providers and to post all referral requests that reach the NCC on that list. This way all providers get the address of the prospective customer at the same time and can get in touch with them however they see fit. The whole process is streamlined and the NCC stays out of the loop as much as possible to avoid any bias. The proposed name of the list is ip-provs(a)ripe.net. Any IP service provider can subscribe to it by sending a request to ip-provs-request(a)ripe.net. The list is *not* intended for any discussion whatsoever. If anyone in RIPE thinks this should not be done, please speak up so that a discussion can be started. If no serious objections are recieved the NCC will proceed as described. Daniel

1 0

Re: IAB's proposals in response to the work of the ROAD group
by bob＠informatics.rutherford.ac.uk 10 Jul '92

10 Jul '92

COMMENTS ON IAB STATEMENT The following is a set of initial comments regarding the recent statement from the IAB suggesting the adoption of TUBA and CIDR as a practical way forward in solving the impending scaling problems as the Internet grows. The comments are a result of discussions in the Joint Network Team's IP Technical Advisory Group (which advises the JNT on technical issues affecting the operation of the IP service over JANET, amongst other things), but the overall conclusions are mine, made in the context of managing the JANET IP service. Of course, comments at this stage can only be preliminary, as most people here have not had sufficient exposure to the technical arguments as yet. I'm sure this situation will change as we study the pros and cons more deeply. Bob Day Manager, JANET IP Service Joint Network Team, UK 1. We believe that it is a sensible policy to try to set the technical work in a defined direction; if it is necessary to act in the short term then this should be done using technology that is sufficiently mature that it will be reliable in practice, and relatively inexpensive to deploy. 2. We believe that if ISO CLNP is used as a replacement for IP to alleviate the scaling problem then it is important that attempts are not made to "improve" it, and hence to depart from the Base Standard (and preferably not to introduce a new profile, if an existing one can be used instead). Given that we see the use of ISO protocols as a desirable strategic goal, it would be counter-productive to introduce non-standard variants at this stage in the life of CLNP. 3. We have serious concerns, however, about the technical suitability of CLNP to replace IP in the longer term. These revolve around the suitability of CLNP for mapping onto high-performance networks (ATM in particular), and whether CLNP has associated with it a sufficiently functional routing capability to really solve the routing problems of the global Internet in the longer term. Therefore we would not like to see CLNP as a long term goal at the expense of a better network protocol (whatever this might turn out to be). This implies that the resource put into deploying CLNP should be kept as low as possible -- ie by using existing products without expensive developments and "enhancements", and concentrating the bulk of resources on a technically more far-reaching solution. 4. We have some concern that the details of the TUBA proposal are not sufficiently worked out, even at the top level. In particular it is not clear at this stage that the simple model described of hosts determining the capability of other hosts via the DNS takes into account the problems of intervening regional networks that do not support TUBA. Without some strategy at this level, as well as at host level there seems to be a danger of either unreachability or excessive traffic due to failures using CLNP followed by retries using IP. 5. We will support the use of classless addressing on the JANET IP Network as soon as we can do so. However, we note that there may be cases where an attached site network cannot use classless addressing itself due to limitations of its equipment (and of money to do anything about it), and suggest that the NICs should take this into account when assessing a request for a Class B network number -- ie it may not just be a matter of number of hosts that determines a site's requirement, but also one of the technology it has available.

1 0

Re: IAB's proposals in response to the work of the ROAD group
by Denis.Russell＠newcastle.ac.uk 09 Jul '92

09 Jul '92

>Since there has been only one (positive) reaction so far, may I conclude >that RIPE as a whole is supporting the IAB position? I am wondering >how many people have read it and thought "If I don't oppose it is clear >that I agree". So please if you are in favour or of RIPE supporting this, >send me a personal mail message. I'll count them and report back to the list. > >Daniel Daniel, I don't think that I can either support or oppose the IAB position. I have been following the Big-Internet discussion for a few weeks now, and I still don't believe that I sufficiently understand all the issues to give a considered opinion. This applies both to "purely technical" issues, and "mainly operational/political" issues, and all issues in between. (I'm not even sure this is a one-dimensional space :-)). There does not even seem to be any consensus on Big-Internet on how urgently "a solution" is required. Although the need for a solution to the class-B shortage is widely recognized, there is a wide diversity of opinion about how much time interim solutions like CIDR would buy, and thus exactly how urgent the, a, next stage is. The IAB proposals produced a deluge of opinion and dissent on Big-Internet and Ietf over the last weekend. Discounting the bigotry :-), some hard issues emerged. For example, of the two urgent matters, address exhaustion and routing table explosion, there is nothing in the IAB proposal about routing table explosion (i.e. routing aggregation, etc), and Jon Crowcroft has pointed out that if certain accepted NSAP allocation schemes are assumed, then only 5 bytes of CLNS addressing are left. Some believe that adopting CLNP to get 5 addressing bytes rather than 4, and no solution to routing table explosion doesn't look like a good way forwards. This has lead onto a discussion of exactly what the IAB proposal actually means. One extreme is "CLNP standard exactly, together with accepted NSAP allocation", another extreme is "well take IP as a starting point and CLNP is a step forward. Where do we go from there", and, needless to say, all points in between. There have been various messages trying to clear up this confusion, and discussing the implication of various points in this spectrum of interpretation. The above is not deliberately my opinion, but an attempt to summarise my understanding of a very active list. The discussion archives of a little while ago contained 884474 bytes, and that is just for this month. Most of it must be the message storm over the IAB proposal. I must have missinterpreted something if not many things. Please refer back to Big-Internet for the actual discussion. I believe that it is extremely important and urgent that a short-term fix be put into place - presumably CIDR. I believe that it is also extremely important and urgent to decide on the next steps. It is urgent enough that we will probably have to choose a pragmatic "interim" next step that might fall short of a "theoretical best" (though some believe that the next change to the Internet will have to be the last). However, I believe that it is *not* yet clear that "adopting CLNP" - whatever that actually means, is the best choice. It might actually be completely irrelevant. I would hope that the undoubted discussion at next week's IETF will generate more light than heat. (After all, our Internet community prides itself in that doesn't it? That's why we are more successful than others, isn't it?). Only coming OUT of the IETF can we hope to make a decision on this. While it would be nice to be able to take a recommendation in, I don't believe we should. "If you can keep your head when all about are losing their's..." Kipling. Sorry for the long message. Denis. PS Wish I was going to the IETF - sounds like it will be very interesting. :-( Denis Russell email: Denis.Russell(a)Ncl.AC.UK Computing Service Tel: (+44) 91 222 8243 The University Fax: (+44) 91 222 8232 Claremont Road Telex: 53 65 4 UNINEW G Newcastle upon Tyne NE1 7RU ENGLAND

1 0