- ripe-list - mailman.ripe.net

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

GMD will establish an EBONE EBS in Germany
by Dave Morton 11 Sep '92

11 Sep '92

>Colleagues, > >you all are aware of the suboptimal IP-connectivity within Europe in general >and to and from Germany specifically. After talks with the german national >network organization (DFN) GMD decided to make the following commitment: > >GMD will establish an EBONE EBS in Germany. This shall be done by providing >at least 2x256Kb bandwidth to two other EBSs in short term. The selection >of the endpoints of the lines will be negotiated within EBONE as well as the >embedding in a new financial structure of EBONE. Add ons on the bandwith by >the other endpoints or other contributors are welcome. We are in contact with >the German IP service providers to organize the national setup and connectivity >of the EBS. We plan to be operational by Feb. 93. Klaus, This is extremly good news for whole community in Germany. Well done. >We also shall participate in the EMPB activities and shall continuosly evaluate >both services to provide the best possible connectivity for our clients. > >We talked to a number of people on this plan and got mostly a very possitive >response. We hope this step to improve internet connectivity in Europe gets >support from everybody in the arena. As you are, aware ECRC supports this new and much needed initiative. Congratulations to all concerned at the GMD. Dave Morton

1 0

None
by Klaus Birkenbihl 11 Sep '92

11 Sep '92

Colleagues, you all are aware of the suboptimal IP-connectivity within Europe in general and to and from Germany specifically. After talks with the german national network organization (DFN) GMD decided to make the following commitment: GMD will establish an EBONE EBS in Germany. This shall be done by providing at least 2x256Kb bandwidth to two other EBSs in short term. The selection of the endpoints of the lines will be negotiated within EBONE as well as the embedding in a new financial structure of EBONE. Add ons on the bandwith by the other endpoints or other contributors are welcome. We are in contact with the German IP service providers to organize the national setup and connectivity of the EBS. We plan to be operational by Feb. 93. We also shall participate in the EMPB activities and shall continuosly evaluate both services to provide the best possible connectivity for our clients. We talked to a number of people on this plan and got mostly a very possitive response. We hope this step to improve internet connectivity in Europe gets support from everybody in the arena. Best regards, Klaus Birkenbihl GMD - Center for Science Networks

1 0

what's needed to be taken serious
by Urs Eppenberger 11 Sep '92

11 Sep '92

Hello Piet, your message could only be understood as slightly offensive: > its already some time ago, that I have sent an e-mail to the wg-dns > list. In that e-mail SWITCH was offering to run a secondary root name > server at a location with good connectivity (2 Mbit/s) to CERN. I have > heard whether positive nor negative responses to this proposal. >Well, I've seen a couple of reactions floating by. >The DNS group is the place to discuss this issue. >But such an offer from a network service provider >within RIPE that blocks traffic from certain other >RIPE networks is not to be taken serious. > Piet And you managed! Some Swiss problems to find out about who is allowed to use whose resources at which cost is used by you to consider one party as not serious just because the other party used every means to throw mud around. And you are fully inline with this game. This leads me to start thinking if I can take you serious if you are not able to consider proposals on objective and technical grounds and show this also by Cc-ing to the full RIPE-list. EUNET is known to contribute valuable technical expertise to keep a European IP service running. Your comments count on the negative side. Best regards, Urs.

4 3