- ripe-list - mailman.ripe.net

Open letter
by matsb＠sics.se 18 Sep '92

18 Sep '92

Mats Brunell 1992-09-18 THIS IS A PERSONAL VIEW Medicine for the ill ==================== There is a a great possibility that Europe once again misses its possibilities to find mechanisms to progress the networking infrastructure development. By this message I would like to urge the involved parties to re-evaluate their positions and hopefully come to terms with the real issues at hand. I have said most of this before in different fora, but I think it is really important. RARE and CEC is coming close to a situation were things are getting out of their hands. No money in the world can buy collaboration, nor the personal knowledge from the couple of 10:s of people who really can resolve the hard issues at hand. People refuse to be manipulated and treated as "FTE units in production". Taxpayers money is at stake here, and the persons involved will fortunately be accountable sometime in the future. I wonder if the CEC/DGXIII really understands that it surrounds itself with people who only say and do what they think is expected that the CEC think should be said. This will ultimately lead to an enourmous lie. Nobody will benfit from such a situation. Openness is the only way to progress. ON THE GOALS There is no such thing as R&D network! In the long term all services will have to be for public use, we the R&D community, happens to be among the first to have realized the oppurtunities with open communication although only a few of us knows how to build and collaborate to make it happen. The reasons for building open public services are several: - costs will be lower if the services will be public a matter of scale thus, the cost for the services will be possible through regular funding channels and not by a separate government funded infrastructure - incentive for the teleoperators and IT industry to develop products and services for the Gigabit and beyond I actually think the the CEC believes that the open market is a goal, also in the field of tele- and datacommunications. Comparing the European situation with the US one is wrong in many cases, the US situation will have to change fast, the new NSF solicitation will open for the open market from being a separte funded infrastructure. We don't have to make the same mistakes over here! The present R&D networks only a starting point The present R&D networks has shown a market potential for open networking, we see the first generation public services established, in this first incarnation (yes we are still in the early stages of open networking in all aspects, technical organisational and market wise) is based on Internet IP standards, the reason for this is simply that is is the only scalable technology taday. ON THE MEANS The model has to support mechanisms to move to public services The move towards a public service market for open networking has to be supported by the actions taken in Europe! This means co-existance between the so called Acceptabel Use Policy based R&D networks and the early public service providers. There are strict technical reasons for this as well as the usefulness to interact in a knowledge transfer activity. Todays teleoperators are not used to the concept of open networking. The technical issues are: - routing - DNS - management The market issues are: - solicitations is an important tool to develop a market, not just to choose ONE provider, but to stimulate a multitude of service providers - to promote interconnectivity between all providers - competition must be fostered through skillful handled policy actions, based on a sound tehcnical knowledge to develop the market, this goes for each country, and the pan-european scene as a whole The GIX/NAP concept and no X.25 The technical solution to implement a service infrastrucure must be based on: - allow for interconnection of a multitude of networks and service providers be they R&D networks or public providers - allow for scalability into 34-155 Mbps to support new applications such as distributed file systems, video conferencing et c, this in turn means: - support for Internet IP and multicast - bandwidth per see is not an issue in the GIX/NAP model it allows for sevaral interconnecting "routes" just as long as the interconnection point and the overall routing is skilful handled - The bandwidth can be separtely provided by a mix of providers Unfortunaltely the specifications so far made for the IXI-production service nor the EMPP in is current modelservice can't meet these requirements, this is a very serious problem. ON THE POLITICS The different roles: The enabling role: - the ONLY thing the goverments should be using the taxpayers money for is to enable the establishment of a long term market, in this case by showing the teleoperators and IT industry how to build the new generation communications services. - this infrstructure starts at the customer site, and thus is the local development in each country most important - don't try to enforce the HOWS, so far this has lead to a disaster - promote collaboration! The developers role: - to develop the best possible technical solutions based on the early experiences from the early large scale experiments, scalability, performance management et c This is valid for todays technology and especially for tomorrows! One who claims he has a technical solution today ought to question himself which probelm he has solved. We are only slowly learning the problems! - To develop the technology we need as broad as possibel collaboration across industry, teleoperators and research, (not R&D network organisations, not the CEC etc, between the people who has to collaborate and solve the issues) The operators role: - to collaborate with all other providers to build a new management model based on mutual knowledge transfer and interaction which is needed for open networking (this is not X.25/X.75!) The users role: - we still need to prove that we want these services, but also be open about WHEN we can trust the teleoperators to manage the infrastructure. No market for them, and we won't see the Gigabits developed! ON TODAYS SITUATION Now to the hot part! RARE RARE must become a true democratic organisation. Its decisions should be made in the meetings, not in the corridors of the CEC. If RARE is to become a representative organistion the RARE CoA mebership and officials should be appointed based on personal elections. If this won't happen we have to establish a true user organisation as soon as possible. EBONE - collaboration between all European open network service providers The short term service provision should only be funded by the users based on a open model. The users or their representatives is the counterparts that needs to agree upon costs and services. So far the Ebone structure is a first step in this direction, it needs improvement in terms of a framework were the users has the real influence and the technical issues is not made into politics. The management should be based on those organisations that actually is collaborating and putting in efforts in the service provision, noone else. The open routing and interaction between the European and global service providers has to be re-inforced in order to maintain both the connectivity and service quality on a global scale. RIPE-NCC RIPE-NCC is a vital part for developing open networking. It is a resource that all users and service providers in Europe need. Thus mechanisms to secure direct funding from those parties should be found. I e to lower the cost for the taxpayers by not relying solely by CEC or RARE membership funding. ENABLING HIGH SPEED SERVICES This could be achieved through two steps: - enabling funding for the EBONE structure to reinforce the bandwidth to 34 MBPS which is the technical and infrastructure possibility today. this could be made in an open tender, where the interconnections points in Ebone represents the European "GIX:es". For future development (this is still a development and research issue) - Build upon a separte infrastructure based on fiber interconnect with optical interfaces and possibilites to field trial in large scale ATM equipment, where local ATM LAN:s is the interconnection points to the WAN. Alternative solution will be possible to connect to the optical interfaces to develop high bandwith solutions beyond Gigabit. These solution will never be possibel to buy, they can only be established through close collaboration in between teleoperators, IT industry and research with interested field trial users involved. Such islands are present is several countries already and more are planned. A good strategy would be to establish interconnections between them. This minimizes the need for large sums of money being shipped to Brussels, and relyes on true collaboration between the parties involved on national regional level in an interantional context. DGXIII:s initiative "Demonstration of Interworking via optical Networks" is open for proposal now, I consider this to be a very fruitful possibility forward. Once these first experiments are settled one could enter a pilot service phase and subsequently a move to a open market.

2 2

Revised RIPE NCC folders - v2.
by Anne Lord 17 Sep '92

17 Sep '92

Dear All, The NCC folders have been revised and version 2 of each has been produced. The modified folders .ps versions have been placed in the RIPE document store : /ripe/docs/ripe-drafts/ ripe-draft-folder1.v2.ps - Interactive Information Server ripe-draft-folder2.v2.ps - Network Management Database The text versions are included at the end of this message. The .ps drafts contain the graphics, whilst the text versions have none. To avoid repetition, the 'About RIPE' boiler plate information has been included only once in the following text versions. These documents will be raised for approval at the forthcoming RIPE meeting (ie. very soon). Until then, comments welcome. Regards, Anne. ~ -------------------------- NCC Interactive Information Service One of the activities of RIPE is to disseminate information. In accord- ance with this role, the NCC maintains a document store which can be accessed via the NCC developed Interactive Information Service. The Main Menu of the Interactive Information Service is shown below. If you wish to find out more about RIPE and the RIPE NCC, you would select the first item on the menu. Should you wish to "browse" through the RIPE document store, you would select the second item on the menu. Alternatively you might wish to search the same document store on a particular topic of interest. In this case, you would select item 3 from the menu - the "keyword" search. Item 4 on the menu allows you to interactively search the RIPE Network Management Database. Item 9 enables you to send mail directly to the NCC. We are happy to receive your comments and suggestions. Menus and the Pager in the RIPE Document Store The NCC Interactive Information Service for the RIPE Document Store comprises a number of hierarchically arranged menus. If you are reading a document you will be able to move around the document with the help of a `pager`, using simple commands. Typing `u` for example will move you up through the document, `d` will move you down and `q' will quit the document. If you need help on how to use the pager type `h'. Browsing through the RIPE Document Store If you select item 2 from the Main Menu you arrive at `browse` menus. One of these sub menus is shown on the facing page.: Each sub-menu choice is followed by either a slash, indicating further sub-menus or a dot which indicates that the menu choice is a docu- ment.To read a document, highlight the document you require and press return. This can be done either by using the cursor keys or by typing in the corresponding number and pressing return twice. Once you have finished reading the document, type `q' to quit. After quitting the document, you are asked whether you would like an email copy of the document. You will then be prompted for an e-mail address. Once this has been entered the document will be sent to you and you will be returned to the current menu. If you would like to return to a previous menu, type `u'. Keyword Search of the RIPE Document Store Similarly, if you select item 3 from the Main Menu, you will move to a sub menu which shows the indices currently provided by the NCC: Currently these indices comprise Internet RFC's, the RIPE documents and the RIPE Network Management Database. Once you have selected the index you are interested in, you will be prompted to specify a keyword for the search. This can be more than one word provided it is separated by spaces. To start the search, you simply press return. The names of the documents containing your keyword matches are presented in a menu form sorted by a score. The higher the score, the greater the number of matches found. By positioning the cursor over the document titles you are interested in and typing `m' you can receive an e-mail copy of the document (you will be prompted for an e-mail address). It is not necessary to read the document before asking for it to be mailed to you. By hitting return on a document name you can then read your `matched' document. If you type `q' you will quit the search and return to the Main Menu. Search of the RIPE Database If you make selection 4 from the Main Menu, you will start a search of the RIPE Database. Additionally you can include in your search the databases of the NSFnet and the US NIC's. You will be asked to specify a search key. The results of the search are displayed on the screen. Further information on the RIPE Database can be found in a separate information leaflet. How to reach the Interactive Information Service The Information Service is easily accessed from both the Internet and via IXI and the Public Data Networks. From the Internet you type: telnet info.ripe.net or if it returns with a `host unknown' message type: telnet 192.87.45.1 Using IXI, on most machines you can connect by typing: pad 020430459300031 and via the Public Data Network by using: pad 0204129004331 Some configurations on hosts require the IXI and PDN network addresses to be without the leading zeroes. If you experience difficulties in connecting to the Interactive Information Service please do not hesitate to call the RIPE NCC for help. About RIPE RIPE (Reseaux IP Europeens) is a collaborative organisation open to all European Internet service providers. The objective of RIPE is to ensure the necessary administrative and technical coordination to allow the operation of a pan-European IP network. RIPE does not operate a network of its own. RIPE is the IP activity of RARE. RIPE has been functioning since 1989. Currently more than 60 organisations participate in the work. The result of the RIPE coordi- nation effort is that the individual end-user is presented on his desk- top with a uniform IP service irrespective of the particular network his or her workstation is attached to. In August 1992 more than 220,000 hosts throughout Europe are reachable via networks coordinated by RIPE. The total number of systems reachable worldwide is estimated at more than one million. About the RIPE NCC The RIPE Network Coordination Centre supports all those RIPE activities which cannot be effectively performed by volunteers from the participating organisations. Besides supporting RIPE activities in general the NCC provides the following services to network operators: m network management database containing information about IP networks, DNS domains, IP routing policies and contact information m delegated Internet registry, a clearing house distributing IP network numbers m coordinated network statistics gathering m domain name system (DNS) coordination m graphical maps of IP networks (planned) m repository for network operations software m RIPE document store m interactive information service The RIPE NCC currently has 3 permanent staff members. The RARE association provides the formal framework for the NCC. Funding for the first year of operation of the NCC is provided by the national members of RARE, EARN, EUnet and Israel. To learn more about the RIPE NCC and its services you can consult the appropriate leaflet, the interactive information server or contact the NCC by electronic mail, telephone or fax. RIPE NCC Contact Information Address: RIPE NCC Kruislaan 409 NL-1098 SJ Amsterdam The Netherlands Phone: +31 20 592 5065 Fax: +31 20 592 5090 Electronic Mail: ncc(a)ripe.net RIPE NCC Interactive Information Service Information about RIPE and RIPE NCC services can also be obtained using the Interactive Information Service. This menu-driven service allows browsing through the RIPE document store, reading documents and sending them by electronic mail. It can be reached by telnetting to host info.ripe.net. The service is also available via the public X.25 networks at 0204129004331 and via the IXI X.25 network at 020430459300031. Access to the RIPE Document Store All RIPE documents and Internet RFCs are available via anonymous FTP from host ftp.ripe.net. The same documents are also available via a "gopher" server at gopher.ripe.net and a "WAIS" server at wais.ripe.net. Access via "World Wide Web" and OSIFTAM are planned. Access to the RIPE Database The RIPE network management database can be accessed via the whois (RFC 954) server running on host whois.ripe.net. The database can also be accessed via the RIPE NCC interactive information service, described above Mailserver Documents can also be retrieved from the RIPE document store using a mailserver program. For more information on how to use the program, send email to mail-server(a)ripe.net with "send HELP" in the body text. RIPE-NCC F-1 Version 0.2 /September 1992 ------------------------------------------ DATABASE LEAFLET What is the RIPE Network Management Database ? One of the activities of RIPE is to maintain a database of European IP networks, DNS domains and their contact persons. This database is called the RIPE Network Management Database or simply the "RIPE Database". The information held on this database is available to the public for the purpose of coordinating IP networking. This sup- ports the work of network operators (NICs and NOCs) throughout Europe and worldwide. For instance, if a user in network A cannot reach a machine in network B, then the network manager of network A could find out the technical contact person of network B, to locate and solve the problem. The database also holds information which supports optimal routing of IP packets through the networks. The information in the database is maintained centrally by the RIPE NCC. The access to the database is currently only available at the RIPE NCC, but in the future the maintenance and access of the database will be distributed throughout Europe. What information is in the database ? Currently the RIPE database consists of IP networks, Domain Name System domains and contact persons. Information from the US NIC database and the NSFnet Routing Policy Database is also available in the same format. The latter databases are not maintained by the RIPE NCC, but made available for your convenience. A network and its contact persons are represented by different data- base objects. This means that for each network there is a network object describing the network and one or more person objects describing the persons. Objects are described by attributes, one per line separated by empty lines. The information stored about network 192.87.45.0 consists of 3 objects, one network object and 2 person objects and looks like this: inetnum: 192.87.45.0 netname: RIPE-NCC descr: RIPE Network Coordination Centre descr: Amsterdam, Netherlands country: NL admin-c: Daniel Karrenberg tech-c: Marten Terpstra connect: RIPE SURF NSF rev-srv: ns.ripe.net changed: dfk(a)cwi.nl 920312 changed: ripe-dbm(a)ripe.net 920407 source: RIPE 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 person: Marten Terpstra address: RIPE Network Coordination Centre address: Kruislaan 409 address: NL-1098 SJ Amsterdam address: The Netherlands phone: +31 20 592 5065 fax-no: +31 20 592 5155 e-mail: marten(a)ripe.net changed: dfk(a)cwi.nl 920501 source: RIPE The information stored about the DNS domain name ripe.net consists of 3 objects, one domain object and two person objects and looks like this: domain: ripe.net descr: RIPE Network Coordination Centre admin-c: Daniel Karrenberg tech-c: Marten Terpstra zone-c: Daniel Karrenberg nserver: 192.87.45.1 nserver: 192.16.202.11 nserver: 137.39.1.3 remarks: fully-managed changed: ripe-dbm(a)ripe.net 920401 source: RIPE and again, the objects for the 2 mentioned persons would appear. An extensive explanation of the fields in an object can be found in the object templates described in the paragraph. titled 'How do I send updates for the RIPE database?` How to reach the RIPE database ? The RIPE database can be accessed via a whois server (RFC 954) on host whois.ripe.net (tcp port 43). An example of accessing the database using whois to get the DNS domain information for ripe.net would be: whois -h whois.ripe.net ripe.net This would result in providing the information as in the example above. Search keys for the database are surname, first name, network number, network name, domain name and nic handle. By default, only the RIPE database information is searched. To also access the NSFnet and US NIC databases you can add the -a flag to the search key. You will have to put quotes around the flag and the search key. On most machines you should use the following to find the information in all databases on person Karrenberg: whois -h whois.ripe.net "-a karrenberg" The whole database is also available via anonymous ftp from ftp.ripe.net as file ripe.db in directory ripe/dbase. Alternative ways of reaching the RIPE database The information in the RIPE database is also available from the Inter- active Information Service provided by the RIPE NCC, by means of a browser and a full text search through the database. This is explained in the RIPE NCC Interactive Information Services leaflet. As a very last resort, you can access the database by connecting to tcp port 43 using telnet, after which you can type the search key. How do I send updates for the RIPE database ? Database updates should be sent via electronic mail to ripe-dbm(a)ripe.net Templates for the objects are available via anonymous ftp from ftp.ripe.net in the directory ripe/docs/lpr/db-templates in files network and domain. When sending in updates, be sure to supply a person object for each contact person mentioned in the any of objects. Of course you need not supply person objects if they are already present in the database and the information is still correct.

1 0

FYI: Hints for Organisations Requesting Class B Network NumberS
by Daniel Karrenberg 15 Sep '92

15 Sep '92

The NCC is receiveing more and more requests for class B network numbers with very little justification as to why a class B number is needed. We have therefore developed a text giving additional hints to organisations requesting class B network numbers. Please find a copy attached below. We are happy to receive comments on the text and we would be obliged if you could ensure it reachas organisations applying for Bs. Daniel ------- Additional Hints for Organisations Requesting Class B Network Numbers Please understand that the criteria for allocating Class B network addresses are extremely strict. This is due to the global scarcity of these network numbers. Out of necessity then, the NCC has to closely examine each and every request we receive for a class B network address. As a result the allocation process will take longer. Organisations can however speed up the process by providing the NCC with as much information as possible on their initial request to enable us to make a decision without having to request more information. Specifically, we require information about the number of hosts in your network at the following points in time: - now - one year from now - two years from now - any other significant milestone The number of hosts estimates should be substantiated with other data about the network and/or organisation like number of employees, geographical distribution, type of hosts. The clearer you can document that your estimates are carefully derived, the easier it is for us to justify allocation of a class B address. Besides a sufficient number of hosts we must determine that your network cannot be engineered using a number of contiguous class C networks. If your network consists of a large number of physical networks with relatively small numbers of hosts on each, you will have to consider subnetting class C networks. A large number of subnetworks alone is not sufficient justification for allocation of a class B network number. We realise that a number of engineering decisions can be based on administrative convenience. Unfortunately the remaining class B address space is too small to take these considerations into account. The clearer your explanation is, as to why your network *cannot* be engineered using a block of class C network numbers, the easier it is for us to justify allocation of a class B network address. All the above mentioned points apply even more strongly to cases where multiple class B network numbers are requested. Assignments of multiple class B network numbers will only occur when the RIPE NCC is satisfied with a detailed justification in terms of the criteria mentioned. Finally, please understand that we are not working against you, but with the whole Internet community to achieve a fair distribution of the remaining address space. If you have any questions about the procedure or the information needed, please do not hesitate to contact the RIPE NCC for further guidance.

1 0

PTTs and IP service providers
by Hank Nussbacher 15 Sep '92

15 Sep '92

I would like to hear from people who have experience with a PTT that provides some sort of IP service as a joint venture with academia or as a new service with no ties to academia. Questions I have are: - Does the PTT provide for a POP (Point of Presence) model within their telephone exchange buildings? - If yes, how much does the PTT charge for the POP service? Rent? Facilities management? - Does your network have the PTT providing just the fiber infrastructure for the IP network (levels 1 & 2 in the ISO model) or do they also provide all management services including routing table management, IP address allocation, etc.? If they do not provide the management of the upper layers, who does? - How much new manpower was required by your PTT to provide an IP service? Where they able to retrain X.25 network operators to be competent IP network operators? - In addition to NOC (Network Operations Center) services, who provides NIS (Network Information Services)? The PTT? The consortium? An outside contractor? - How are shares divided between consortium owners and the PTT? In general, does your national network work as a consortium between the PTT and some user population, or is it solely owned by the PTT? Anything else you might be able to add to this topic would be greatly appreciated. Thanks, Hank Nussbacher Israel

2 1

Service in Belgium
by abe＠infonet.com 14 Sep '92

14 Sep '92

Does anyone know of an IP service provider in Belgium? Plz send me their name and phone number. Thanks, Hank Hank, Infonet provides service in Belgium. Contact myself or Michel Vervoort Interpac Belgium SA 350/358 Avenue Louise, Box 11 B-1050 Brussels Belgium Phone 32-2-646-6000 Regards, George Abe

1 0

RIPE and European network resources registry
by Milan Sterba 14 Sep '92

14 Sep '92

At the last RIPE meeting in Amsterdam, we have extensively discussed the need for a metainformation service about network resources and accessible services at european level. The result of the discussion has been the founding of the NIDUS WG. Network Metainformation Server ============================== The general feeling was that the RIPE User Information Service (if defined and set up) should act as a starting point for further search. It shouldn't (in most areas) store the information itself but rather pointers to other information sources and network resources and even pointers to pointers. Lets call this function the Network Metainformation Server (because I want it to cover a wider area than that covered by the current NIC's). 1. In order to implement a NMS we need first to study the overall structure of the information and resources accessible today and in the near future by the network and to define how the information in the NMS should be ORGANIZED. 2. Then we have to define tools which would be suitable to support the type of data organization required (access tools, maintenance and update tools) 3. Then we must define the mechanisms (algorithms & responsabilities) to maintain the NMS up to date - links to other such activities on the network (formal and automated) At the last RIPE meeting in the NIDUS WG I have proposed to study a little bit what a structure of a RIPE metainformation server could be. This has lead me directly to reflections about how could the information about existing and future network resources be organized. Many things in many different ways are being done on many places in the area of network resource registry/discovery. One can easily be wrong because of incompleteness, wrong tools used, insufficient availability etc. Nevertheless a european resource registry is a reasonable need, the RIPE community is probably one of the best places to start such an activity and the RIPE NCC is a reasonable place to do it. That's why I propose to use the well established RIPE database mechanism to register available network resources in the european IP [CLNP] network. RIPE has succeeded in implementing a pan-european data collection and maintenance machanism which I find really suitable for the purpose of creating a pan-european network resource registry. Using the RIPE database framework would bring elements of solution to all tasks 1.-3. stated above. If there is enough interest in this topic I think it should be discussed during the next RIPE meeting in Paris in the NIDUS and the DB WG's. I will be happy to receive your comments before the meeting to be able to prepare a more detailed proposal (or to withdraw it if it doesn't make sense). Follows a proposal of a template of the new "resource" object of the RIPE database. ================================================== Description of the "resource" RIPE database object ================================================== resname: Resource name in human Mandatory admin-c: Name of administrative contact person Format : <firstname> <initials> <lastname> Mandatory tech-c: Name of the technical contact person Format : <firstname> <initials> <lastname> Mandatory restype: Type of the resource Describes in one word the nature of the resource (the list of the most common should be agreed upon at RIPE) Format : one of the strings listed bellow meta = server of servers library = library catalogue docs = document store database = structured data base local = local information system (e.g. university information system) archive = specific data objects archive (e.g. public domain software) super = supercomputer facility Mandatory acc-method: Access protocol to the service This should be the name of the IP [CLNP] service which allows to access the server Format: sequence of bellow listed strings separated by space telnet | ftp | ftam | wais | gopher | www | e-mail | prospero | archie | ... Mandatory acc-key: Access info necessary to access the first level service (e.g. login name for public telnet sessions or port number and database name for wais servers) Format: depends on the access protocol acc-right: Access rights to the resource Format : sequence of strings bellow separated by space ANY | see connect attribute in network object | LIMITED Mandatory topics: Keyword description of the topics covered by the resource Each topic should be mentioned in a new topic attribute. e.g. economy, mollecular biology, computer networks, software Mandatory description: Short description of the resource Postal address is not needed, it can be found via the contacts host: List of hosts for this resource Format: fully qualified domainname without trailing "." Mandatory media: Type of data stored on the server Format: sequence of strings bellow separated by space ascii = ascii texts text = other textual data (e.g. in native language or various text processing formats - PostScript) struct = record oriented data graphics = graphical data (images) sound = self explanatory video = dtto binaries = computer programs in binary form sources = computer program sources etc. ================================================================== Other open issues : - description of CLNP services - description of other services (accessible via other network protocols) -- ====================================================================== Prague School of Economics e-mail : Milan.Sterba(a)vse.cs Computing Center tel : +42 2 21 25 704 nam. W. Churchilla 4 home: +42 2 823 78 59 130 67 Praha 3 fax : +42 2 235 85 09 Czechoslovakia =======================================================================

1 0

RIPE-DB WG Paris, item 2.3
by Wilfried Woeber, ACOnet, +43(1)58801-3614 14 Sep '92

14 Sep '92

Andreas Schachtner (afs(a)Germany.EU.net) submitted the following proposal for discussion in Paris (RIPE-DB WG, agenda:2.3) -------------------------------------------------------------------------------- As it is getting more common, to allocate nets according to supernetting, the RIPE database should reflect this. It might change the perspective for a router manager (and might change the technical implications as soon as classless routing will be deployed), if someone realizes that [s]he's in fact seeing a supernetted network instead of a siongle class C. Considering this, I would propose to have thos networks classes in the RIPE DB as <net> <mask> pairs: *in: 192.124.0.0 255.255.0.0 instead of 256 (ok, 254 :-) network entries. The RIPE DB software has to be changed, of course. It would be clever, if for the purpose of indexing the software explodes the <net>,<mask> pair to all networks covered by this. All those index entries should point to the supernetted object, of course. By this, if such a network number comes along, I simply do a query as for an ordinary class C, but get the supernetted as answer. Opinions ? Andreas Schachtner --------------------------------------------------------------------------------

4 5

Belgium IP provider
by Hank Nussbacher 13 Sep '92

13 Sep '92

Does anyone know of an IP service provider in Belgium? Plz send me their name and phone number. Thanks, Hank

1 0

RIPE-DB WG Paris, item 2.2
by Wilfried Woeber, ACOnet, +43(1)58801-3614 11 Sep '92

11 Sep '92

For discussion in Paris (RIPE-DB WG, agenda:2.2) Andreas Schachtner (afs(a)Germany.EU.net) proposes to introduce an optional field for any DB object where this information does make sense: *tl: <e-mail-address> *tech-l: <e-mail-address> This field is not supposed to replace the *tc or *ac fields! The *tech-l filed should point to a mail address or mailinglist to provide access to people with _technical_ knowledge for the object referenced. Advantages are seen with the addressing of trouble tickets, managing configuration changes, etc. Any comments? Wilfried.

1 0

Propsed Agenda for the RIPE-DB WG at the Paris Mtg.
by Wilfried Woeber, ACOnet, +43(1)58801-3614 11 Sep '92

11 Sep '92

Dear RIPE'ers, below please find the draft agend for the proposed meeting of the RIPE-DB WG in Paris. Please forward any suggestions (additions, changes) to modify the agenda directly to me. I'm going to circulate supporting material for some of the proposals in separate messages. Reference to the item numbers on this proposed agenda are included. Please circulate any comments on these topics on "ripe(a)ripe.net", as agreed at the previous meeting of the RIPE-DB WG.. Best regards, Wilfried. -------------------------------------------------------------------------------- Proposed agend for the RIPE-DB WG at the Paris RIPE Meeting. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DB-WG 1. RIPE-DB Operational Issues 1.1 - change of DB format by NIC (nicnets.db) issue raised by Ruediger Volk, Marten Terpstra 1.2 - addition of, or "nonstandard use" of fields issue raised by Jean-Michel Jouanigot, Marten Terpstra DB-WG 2. RIPE-DB Technical Issues 2.1 - definition of and agreeement on Autonomous System Object issue raised by Daniel Karrenberg >>input solicited from Ruediger Volk, Daniel Karrenberg 2.2 - proposal to add field *tech-l/*tl to objects where useful proposal by Andreas Schachtner 2.3 - modification of *in field to take care of supernetting proposal by Andreas Schachtner 2.4 - review of importance of Domain Object, superceded by RFC1183 issue raised by Daniel Karrenberg 2.5 - discussion on feasibility of general purpose extensions to DB >>input (example for GARR usage) solicited from A. Blasco Bonito DB-WG 3. RIPE-DB Organizational and Legal Issues 3.1 - ownership and "acceptable use" of RIPE-DB 3.2 - review/update of ripe-w02 describing the database objects 3.3 - coordination and future liaison with X.400/X.500/MHS activities --------------------------------------------------------------------------------

1 0