- ripe-list - mailman.ripe.net

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

IAB's proposals in response to the work of the ROAD group
by Daniel Karrenberg 09 Jul '92

09 Jul '92

Friends, Below you find a summary of the IAB (now called Internet *Architecture* Board after moving under the wings of the Internet Society) proposals in response to the ROAD group work which we discussed at the last RIPE meeting. Personally I think that this is a very sound proposal and that RIPE should endorse it. Discussion welcome. Daniel ------- Forwarded Message Date: Wed, 1 Jul 92 19:55:36 EDT From: "Lyman Chapin" <lyman(a)BBN.COM> Subject: IAB proposals for CIDR and IPv7 A summary of the IAB's proposals in response to the work of the ROAD group. ------------------------------------------------------------------------ During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed the draft report of the ROAD group concerning the problems of "running out of IP network numbers" and "Internet routing table size explosion", and a companion report from the IESG of "IESG Deliberations on Routing and Addressing". The IAB's analysis of the many possibilities suggested by these two reports led it to the following conclusions, which are docu- mented in an internet-draft entitled "IP Version 7": 1) The ROAD group's work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin now, and it is therefore imperative that the efforts of the Internet community be focussed on a common goal. 2) The IETF should aggresively pursue the work to engineer CIDR ("classless inter-domain routing", described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm. 3) Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses 160-bit addresses) as the basis for a new version of IP (which we have dubbed "IP version 7"), succeeding over time the current version of IP (version 4) in the Internet. An initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications is described in RFC 1347. 4) CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic). It is important to understand that (3) above does NOT mean "adopting OSI" or "migrating to OSI" or "converting the Internet to use GOSIP protocols". The IAB recommends only that a new version of IP (IPv7), with much wider addresses and a more extensible header, be based on the existing CLNP. IPv7 is intended to be deployed within the current Internet TCP/IP architecture, not as part of an "OSI stack". There are, of course, many issues that must be resolved before CIDR and IPv7 can actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwith- standing the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year. In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket "condemnation" of the alternative proposals that have been floated in various parts of the IETF. However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston. - Lyman Chapin IAB chair ------- End of Forwarded Message

2 2

Congratulations
by Sylvain Langlois 08 Jul '92

08 Jul '92

I've just grab the 1st issue of the RIPE NCC Quarterly Report and browse through it. You all deserve loud applause for producing such a high quality report. Thanks for all this *VERY* useful information! Sylvain ---------------- Sylvain.Langlois(a)der.edf.fr

1 0