January 1993 - lir-wg - mailman.ripe.net

Re: NCC Funding (fwd)
by bonito＠nis.garr.it 28 Jan '93

28 Jan '93

Folks, after the discussion at in Prague I recirculate on the list a message I sent to Daniel and Rob with y ideas on the funding issue. Greetings to everybody from a much warmer climate than in Prague ;-) Blasco Forwarded message: > From bonito Thu Jan 21 12:23:53 1993 > Subject: Re: NCC Funding > To: Daniel.Karrenberg(a)RIPE.NET, k13(a)nikhef.nl (Rob Blokzijl) > Date: Thu, 21 Jan 93 12:23:53 MET > Reply-To: > In-Reply-To: <9301201639.AA00678(a)jolly.nis.garr.it>; from "Daniel Karrenberg" at Jan 20, 93 5:18 pm > Organization: GARR Network Information Service > X-Mailer: ELM [version 2.3 PL11] > > Daniel, Rob, > > > Rob and I have been asked by many people (among them the current funders > > of the NCC) to come up with ideas for funding the NCC in 1994 and maybe to > > provide addtitional funding in 1993. > > > > This is related to the strategic decisions which must be made about > > charging for the registry functions. Below is a *very* rough first draft > > representing out thinking in this. I circulate it for discussion > > during the agenda point registry funding at Praha local-ir meeting. > > Please do not take this as prejudicating anything. It is just some very > > basic thoughts. > > > > Comments welocme. > > I was already stimulated to think about this issue by the NSF announcement. > Your (well done) paper has unblocked my natural attitutive against writing. > I feel myself involved in the problem as "representing" a service provider > as well as RIPE deputy chairman. > > I generally agree with what is said in your document about feasible > and unfeasible ways of funding the NCC. > I think you should spend some effort trying to "model" funding criterias > in the overall european networking scene, but only SOME EFFORT. > Our major concern should be to exactly define rules to fund NCC, leaving > to service providers the task of defining their own rules to charge > customer organizations or even final users. It is evident that there > are very different requirements and constraints put on a national > research network than on a commercial network: the first is supported > by the government and is able to give services for free. > > I think that: > > RIPE Network Management Database > has not yet reached the status of a strongly needed service, so it could > be a risk to charge service providers on this base. I think we should > continue the effort in order to have major backbones (EBONE, EMPB, GIX, ...) > making use of the database: it is then a unavoidable tool! > > A small uncorrectness: > > The community represented in the database is limited to Eu- > > ropean organisations with Internet connectivity. *stats* > -------------------------- > not true, it contains also networks with connect: LOCAL > > I think that the > > European Regional Internet Registry > despite it is a young service, it is already a strongly needed service: > without unique IP numbers no one can be connected to Internet either now > or in the future. By the way the NCC should start some activity as soon > as possible about the registration of the successors of 4-byte IP addresses > whatever they will be. > > I think it is feasible to define ways of finance the NCC which are based > on the IP registry > > > RIPE Support > > General Coordination > should be financed through basic funding mechanisms (i.e. RARE, the > CEC trough RARE, the CEC directly): the importance of RIPE has > reached a sufficient general consensus, I think. > > A note: > > The NCC also partecipates in global activities representing RIPE > ------------ > I think this is a task of the RIPE chairman and deputy chairmans, not > of the NCC. > > Now about charging mechanisms: > > > > European Internet Service Providers > > ... > > Charging the service providers could be achieved in the same > > way as above through a database registration charge and with > > the same drawbacks Also the use of the registry service > > could be billed, with similar difficulties. > > > > The big benefit of funding via the service providers is that > > the number of entities to bill is relatively small and -even > > more importantly- there is a chance to come to a consensus > > about the charging model. On the other hand the wider Euro- > > pean user community will be funding the NCC services from > > which they benefit via the providers. So the users having a > > direct benefit pay, albeit indirectly. > > I think that a reasonable and acceptable way to charge should be > based on services actually given, so > - a service provider can charge a customer organization on the base > of the address space, because a larger address space can connect > more hosts and can generate more traffic > - a registry service can charge a service provider on the base > of the effort needed to make and maintain a registration > > The funding model I have in mind is the following: > 1- any service provider is registered by RIPE-NCC and pays an annual fee > (subscription + some advance payment for a foreseen number of > actual network registration) > 2- any "RIPE registered" service provider can submit registration > requests during the year, as well as updates of the database concerning > routing privileges. This registration are tipically about > connected networks/block of networks. They have a steady benefit > from the RIPE registration. > 3- any national "non-provider registry" is also registered by RIPE-NCC > and pays a much smaller annual fee > 4- non-provider registries can tipically submit a number of new > "unconnected" network registration. They have a "once-only" > benefit from the RIPE registration. > > The RIPE-NCC issues an yearly bill > a) to service providers computed as follows: > inetnum entries with connect: <service providers name> are counted > (note this is NOT the number of networks) and then multiplied by a > database-management tariff and then discounted by the advance payment > already done. > b) to non-provider regitries as follows: > inetnum entries with country: <non-provider country>, connect: LOCAL > and changed: <current year> are counted and multiplied by a > registration tariff. > > Service providers can then bill, if they need so, their customers on > the base of the address space used or any other rule. > Non-provider registeries can bill requestors per single request/assignment > made or as they like, but I think that it is time to state that an > official address cannot be given for free. > > All my best, see you in Praha. > ---------- ---------- > Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it > GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito > c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 > Via S. Maria, 36 Telex: 500371 CNUCE I > 56126 PISA Italy Fax: +39 (50) 904052 > ---------- ---------- > -- ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

1 0

Database updates
by Marten Terpstra 26 Jan '93

26 Jan '93

Dear folks, The network connection to Prague is of such qualt\ity that we cannot do an update of the database from here right now. We cannot risk the update to break somewhere halfway because of network connectivuty. We will of course try to do an update whenever possible. Apologies for this, the NCC staff.

1 0

Database updates during upcoming RIPE meeting
by Marten Terpstra 22 Jan '93

22 Jan '93

Dear folks, Since all of the RIPE NCC staff will be in Prague next week for the RIPE meeting, there may be a chance that we miss an update. Because of time or connectivity constraints it can happen that we cannot keep our daily update service. Our apologies for this, but we will try to do the best we can. -Marten

1 0

NCC Funding
by Daniel Karrenberg 20 Jan '93

20 Jan '93

Folks, Rob and I have been asked by many people (among them the current funders of the NCC) to come up with ideas for funding the NCC in 1994 and maybe to provide addtitional funding in 1993. This is related to the strategic decisions which must be made about charging for the registry functions. Below is a *very* rough first draft representing out thinking in this. I circulate it for discussion during the agenda point registry funding at Praha local-ir meeting. Please do not take this as prejudicating anything. It is just some very basic thoughts. Comments welocme. Daniel RIPE NCC Funding Some General Observations DRAFT Vertsion 0.1 Rob Blokzijl Daniel Karrenberg Introduction When examining the problem of how the RIPE NCC should be funded, the question of "Who uses the NCC?" immediately comes to mind. And indeed the RARE CoA has asked for an answer to just this question. However, it is difficult to answer such a general question. A little easier might be "Who benefits from NCC services?". In this paper, an attempt has been made to analyse the prob- lem by categorising the services and user communities of the NCC. A single model for NCC funding has not yet been con- sidered, as this requires discussion and consensus from all the parties involved. Instead, this paper aims to examine the problem, discuss some of the possible options and to ar- rive at a framework which will promote further discussion. Categories of NCC Services When approaching the problem from the NCC user angle one can identify several classes of users according to the different services the NCC offers. Therefore we present the main ser- vices presently provided by the NCC first. For details about these services, please see the RIPE NCC Quarterly reports. Information Service - RIPE Document Store The biggest and most diverse group of NCC users are those makeing use of the NCC information services. The informa- tion services consist of various ways to retrieve informa- tion from what is called the "RIPE Document Store". Despite the name this carries not only documents but also software tools related to network management. The scope is wider than just RIPE but restricted to information relevant to Internet and RIPE activities. For instance the document store con- tains mirror images of the RARE, EBONE and IETF document stores including all RFC and all Internet draft documents. In the Internet tradition the document store is available to all sites on the Internet and additionally accessible from the public X.25 networks as well as EMPB(IXI). Users do not January 20, 1993 - 2 - need to register before using this information service. Logs are kept about usage though and summaries are published in the RIPE NCC Quarterly Reports * insert some usage stats* The user community of this service is the whole worldwide Internet. No registration is necessary. RIPE Network Management Database The RIPE network management database holds information about European IP networks (network in the sense of IP network numbers), DNS Domains and contact persons for these. Furth- er it contains routing policy information. Users do not need to register before querying the RIPE database. Logs are kept about usage though and summaries are published in the RIPE NCC Quarterly Reports. * insert some usage stats* The database is available to the whole worldwide Internet community. The community represented in the database is limited to Eu- ropean organisations with Internet connectivity. *stats* European Regional Internet Registry The RIPE NCC functions as the European regional registry for Internet numbers. The most important such numbers are the IP network numbers, which constitute the IP address space. The NCC provides a meachanism which enables European organisa- tion to obtain the address space they need in an efficient manner without the need to refer to the global registry in the US. At the same time the NCC ensures that usage of the address space fair and economical. In principle the NCC achieves the above by working through so called local registries. These are IP service providers assigning address space to their customers or "non-provider" registries assigning address space for local use. Wherever a local registry has not been established the NCC assigns ad- dress space directly. The NCC also handles all requests for larger amounts of address space directly, especially those for class B IP numbers. *insert numbers of registries* The user community for the regional registry functions is all European organisations using TCP/IP protocols and desir- ing unique addresses. Note that this is larger than the com- munity connected to what we call the European part of the Internet. Looking at it in a hierarchical fashion the direct user com- munity are the European IP service providers and the "non- provider" registries. This the direct assignments by the January 20, 1993 - 3 - NCC in cases where there is no appropriate local registry. RIPE Support The RIPE NCC supports RIPE activities in general. This in- cludes providing mailing list service as well as some secre- tarial service to RIPE and the RIPE working groups, prepara- tion and logistics for three RIPE meetings a year in varying locations for an increasing amount of attendees. The last meeting was attended by approximately 75 people. The NCC also participates in global activities representing RIPE. The direct user community of these services are the organi- sations participating in RIPE. The indirect user commmunity are all organisations connected to the European part of the Internet because RIPE is the organisation coordinating the European Internet. General Coordination The NCC also performs a host of small and/or incidental coordination functions related to the European part of the Internet which are not easy to categorise. This is normal for a focal point of distributed activities like the RIPE NCC. Categories of RIPE NCC Users Based on the different services offered one can disitinguish different categories of NCC users. We will do this in a hierarchical fashion by defining a number of user categories which are progressively smaller subsets of each other. The Internet at Large The most general category is users of Internet protocols and the Internet worldwide. The information and database query- ing services of the NCC are open to the whole global Inter- net community. Charging for these services is nesxt to im- possible in the current Internet framework because users do not need to register before using these services. The sheer number of users makes traditional billing methods unworkable as well. If it was practicable to bill for these services it would probably be counterproductive because their usage helps keeping the Internet coordinated and keeps quite a bit of load off the NCC itself as well as the help desks of the service providers. January 20, 1993 - 4 - European TCP/IP Users The next category is all organisations using TCP/IP in Eu- rope. This category is a subset of the previous one. In ad- dition to the global Internet community this community uses the regional Internet registry and database registration services. These organisations are known with contact infor- mation, so billing is at least theoretically possible. The only basis for billing which is obvious at this level is the adress space. Once could charge either per assignment or one could "rent" address space. The limits of practicability here are the number of orgaisations, the legal implications, especially with holders of already assigned address space. Another prerequisite is global agreement on the charges to prevent "black imports". Our conclusion is that this is impractical for the time being but could be valuable in the future, especially as a tool to rationalise address space usage. It remains doubtful however whether it will ever become practi- cable and economical to do. European Internet Users The next category is all organisation connected to the Euro- pean Internet. In addition to the services used by the pre- vious categories organisations in this category can depend more sophisticated use of the RIPE database registration service because of the role the database plays in distribut- ing routing policy information. Because these organisations are connected they are alos more likely to benefit from the general coordination activities of the RIPE NCC. Charging these users could be done in form of a poeriodical database registration charge. However this could work out counterproductive to the goal of manageability of the Euro- pean Internet if organisations or service providers find ways of achieving the desired connectivity without register- ing. Also the measurement of use and the charging model will be hard to agree. The number of entities to bill is still large. European Internet Service Providers Each organisation in the previous category either is con- nected through a service provider or is itself such a ser- vice provider. The service providers make use of all NCC services the previous category uses. However they do so much more directly than their customers, the users of the Europe- an Intnernet. The service providers interact directly with the NCC for the registry function, as members of RIPE and when using the RIPE database for trouble shooting and rout- January 20, 1993 - 5 - ing. Most of the time the service providers act on behalf of their customers. Charging the service providers could be achieved in the same way as above through a database registration charge and with the same drawbacks Also the use of the registry service could be billed, with similar difficulties. The big benefit of funding via the service providers is that the number of entities to bill is relatively small and -even more importantly- there is a chance to come to a consensus about the charging model. On the other hand the wider Euro- pean user community will be funding the NCC services from which they benefit via the providers. So the users having a direct benefit pay, albeit indirectly. *list service providers from local registty list* Making suggestions for that charging model needs consider- ably more time than we have had so far to write this paper. Any simplistic model suggested and simulated so far was un- fair and/or might cause providers economise in undesirable ways. So we will just present an incomplete list of the problems: What service measures to charge on? registry service ehat measures? do not penalise well organised local registries! do not reward service providers putting load on the NCC by not running a local registry! do not stimulate bad adress space usage pat- terns! do not break route aggregation! database service what measures? do not discourage registration! reward organised local maintenance of database! Legal Framework? how to organise? what to do with providers who "do not p(l)ay"? January 20, 1993 - 6 - How to build consensus? RIPE is the obvious place! How to proceed? Conclusion Looking at the services and the user communities the most practical general model is funding via the service provid- ers. If this much can be agreed then an activity can be started to further work things out within this group. Because this needs more work we suggest that in order to seek additional funding for (part of) 1993 all identifiable service providers not contributing yet are approached for a voluntary contribution and all commitments including the al- ready established ones are publisised publicised within RIPE. January 20, 1993

1 0

Revised European IP template
by Anne Lord 20 Jan '93

20 Jan '93

Dear All, Below is the revised draft European IP template which will be discussed at the local-ir working group in Prague. The aim is to discuss and agree on a format of the template, so that it can be used after Prague. As before, comments welcome. ------------------------------------------------------------------------ DRAFT January 1993 RIPE NCC EUROPEAN IP-NETWORK NUMBER INFORMATION PACKAGE GUIDELINES DOCUMENT and APPLICATION FORM ---------------------------------------- Introduction ------------ In the past, if you needed an IP network number you would need to obtain and complete a form issued by the Global Internet Registry in the United States (aka hostmaster(a)nic.ddn.mil). Since August 1st 1992, there has been a change in procedure, whereby all network number requests from European organisations are handled by the European Regional Internet Registry. This refers to the RIPE Network Coordination Centre located in Amsterdam, The Netherlands (RIPE NCC or hostmaster(a)ripe.net). The RIPE NCC receives blocks of network numbers from the Global Registry. Class C numbers it reallocates to local registries across Europe, who in turn, according to strictly defined RIPE procedures make the actual network number assignments. Slightly different procedures exist for Class B network numbers which are only assigned by the RIPE NCC. Therefore when you are making an application for a class B you should complete this form and send it direct to the RIPE NCC. However, if it is felt that a class B is not justified, then your application will be forwarded to your local registry who will consult you over an appropriate allocation of class C network numbers. There are two types of local registries: those who are IP service providers who run local registries for their customers. The majority of IP service providers run local registries. There are also "non-service provider" local registries which provide an IP registry service to organisations who do not have an IP service provider. Only one "non-service provider" registry exists per European country, but they are as yet not established for every country in Europe. In cases where a local non-service provider registry does not exist for a country, the RIPE NCC manages the allocations. If you are in doubt contact the RIPE NCC for more information. An "IP service provider" can be defined as an organisation that provides Internet services to other organisations. Examples of IP service providers are (national) research network organisations or commercial network service providers. In making your application for a network number you should be guided by the following preliminary question: Q. Are you a customer (existing or prospective) of an IP Service Provider? A. If the answer is YES - then you should complete this form and then return it to your IP Service Provider. or A. If the answer is NO - then you should complete the European IP request form and return it to your local non-provider registry. If you do not know whether a local registry exists for your country, please contact the RIPE NCC who will be able to advise you. If you have any queries or problems please do not hesitate to contact the RIPE NCC or <your local registry address>. Before making your request for an IP number, you should you have read all the documentation carefully. There are 3 documents which you should receive and read: a) the European IP number request form - the actual application form b) the `Guidelines Document' - this document c) the `Helpful Hints' document - which contains information you need to know before applying for IP network numbers (Bob Day) This document will guide you in how to complete the European IP number request form correctly. The request form is used by all the Internet registries across Europe. The format of the form is designed so that it enables us to process your application quickly. That is why we ask you to carefully read and follow this 'Guidelines Document' which describes in detail how to complete the form. In addition, please ensure that you read the 'Helpful Hints' document which contains information that you should know before applying for a network number. Local language versions of the 'Guidelines' document and the `Helpful Hints' may document exist. Please contact your local registry for a copy (or the RIPE NCC?). ------------------------------------------------------------------- new page Part A - Administrative Details - Guidelines -------------------------------------------- The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: Please complete with an appropriate network name for the network to be numbered which is short and meaningful. The `netname' is used mainly for administrative purposes like consistency checking of the Internet Registry. You will most likely not see this name appear anywhere, but on forms like this. eg. netname: TBIT descr: Please complete with a short description of the organisation, including the location. The full postal address is not needed as this is required in the person template. eg. descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown country: Please give the ISO 3166 two letter country code which is appropriate for the organisation. We know this gives problems for networks crossing national boundaries, so choose the most appropriate country, based on the location of the admin contact. If you do not know the ISO 3166 code for your country, please complete with the full name of the country. eg. country: IE admin-c: Please complete with the name or NIC handle of the person who is the administrative contact for the network. The NIC handle (if known) is preferred. Please do not use formal titles like `Dr' or `Prof' or `Sir'. Please specify as in the example below (or with the NIC handle if known). Do not add full stops between the names or initials. eg. admin-c: John E Doe tech-c: Please give the name of technical contact person. There can be more than one technical contacts name. NOTE: please give names for both the administrative AND the technical contact. If two different names are not appropriate, then the same name for both contacts is fine. changed: Email address of the person who is completing the template, followed by the current date. If you do not have email connectivity please leave blank and we will complete it. Please add the date as it is shown below. eg. changed: johndoe(a)terabit.nn 921215 source: Source of the information. This will always be RIPE, which we have added. PERSON TEMPLATE NOTES For each different person specified in the network template, please complete a separate person template, unless the data about those persons is already in the RIPE database. person: Please give the full name of the admin-c contact and the tech-c contact. There must be a person template completed for each different name specified. The names must be written identically to those given above in the "admin-c:" and "tech-c:" attributes above (but must not be the NIC handle). eg. person: John E Doe address: Please complete with the full postal address, and write as you would for ordinary postal mail using one line for each part of the address as shown below. eg. address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NN-1234 Northtown address: Repubic of Northern Nowhere phone: Please give the work telephone number of the person specified above. Please specify the telephone number with + <country code> <area code> <telephone number> Most countries should drop the leading zero when specifying their area code. More than one telephone number is fine. Each telephone number should be put on a separate line and written in order of the most appropriate number for the contact person. eg. phone: +31 20 12334676 phone: +44 71 9876542 ext. 4711 fax-no: Please complete with the telefax number of the person specified above. eg. fax-no: +31 20 12334677 e-mail: Please supply the appropriate electronic mail address for the contact. If you DO NOT have e-mail connectivity, please insert <none>. Please ensure that this is a valid domain address please. eg. e-mail: johndoe(a)terabit.nn or e-mail: <none> nic-hdl: This refers to a NIC handle which is a unique identifier assigned and used by the US NIC to unambiguously refer to Internet people. If you do not have a NIC handle, then please leave blank. eg. nic-hdl: JD0401 changed: Who and when changed this last. Please complete with your e-mail address followed by the current date in the format which is shown below. If you do not have e-mail connectivity, please leave blank and we will complete this on your behalf. Example - changed: johndoe(a)terabit.nn 921215 source: Source of the information. This should always be RIPE. ------------------------------------------------------------------- new page Part B - Technical Details -------------------------- Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. request-typ: Please specify the quantity and class of your request for network numbers. eg. request-type: 1 class C In making the application, please be guided by the following EXAMPLES of number of hosts which relate to the quantity of network numbers requested: eg. 1 class C number (up to 254 hosts) 2 class C numbers (up to 508 hosts) 4 class C numbers (up to 1016 hosts) 8 class C numbers (up to 2032 hosts) 16 class C numbers (up to 4064 hosts) 32 class C numbers (up to 8128 hosts) a single class B number other (please specify) machine-0: Please state the number of machines in your organisation that currently require a unique IP address. Do not forget to include terminal servers and transit networks when calculating this figure. eg. machine-0: 100 machine-1: Estimate the number of machines requiring a unique IP address in one years time. eg. machine-1: 134 machine-2: Estimate the number of machines requiring a unique IP address in two years time. eg. machine-2: 250 subnet-0: Please state the number of subnets required for the current network. A subnet refers to the physical parts of the network which need a unique (sub)net number. eg: subnet-0: 10 subnet-1: Estimate the number of subnets in one years time. subnet-2: Estimate the number of subnets in two years time. inet-connect: Please state whether you plan to connect to the Internet. Please answer with whichever of the following options most closely describes the position of your organisation. eg. - will never connect - already connected <through whom> - plan to connect <date> If you are "already connected" to the Internet, please state which service provider you are connected to. If you answer with "plan to connect" then please make an estimation on the date that you hope to connect, specifying the month and the year (if possible). eg. inet-connect: already connected JANET in the UK or eg. inet-connect: plan to connect December 1993 use-net: Has your organisation already obtained an IP network number or numbers? If so, please give the network number(s) and the network name if known. If not, then please complete with <no>. Format: complete with the network number only - four numbers separated by dots, as shown below. If known, please also add the network name entry as shown below. This must be specified in exactly the same way as it appears Example - use-net: 193.87.45.0 TBIT or Example - use-net: <no> iso-net: Please give the ISO 3166 country code which describes where the network will be located. If more than one country applies, then give the name of the country "responsible" for the network, using the country of the admin-c: contact given in Part A. Format: complete with country name using ISO 3166 country code. Example - iso-net: NL Part C - Technical Details --------------------------- Please complete this section on a separate page if you are applying for more than 2 Class C network numbers. The more numbers you are requesting, the more detailed your technical description will need to be. Furthermore, the more detail you provide, the quicker we will be able to process your application. Please include an overview of the size of your subnets, ensuring that you do not forget transit networks, terminal servers etc. when calculating your needs. Before you complete this section you should read the `Helpful Hints' document (currently under preparation) which will guide you. It is particularly important to read this document if you are applying for a class B network number, as it provides additional hints. It is available from: <supportingip-docs(a)wherever.net>. Local language versions also exist. Please contact your local registry for copies or the RIPE NCC. If you are applying for a Class B network number please send your completed application to the RIPE NCC who will review your case. If it is felt that a Class B network number is not justified, your application will be forwarded to your local registry who will consult with you over an alternative allocation. Please be reminded that Class B network numbers are extremely scarce and are rarely allocated. Part D - Contact Details ------------------------ This section should be completed *ONLY IF* you are making an application on behalf of another organisation. Please indicate who the application is being made by and behalf of whom, giving all the contact details requested. ====================== 8< please cut here ================================== DRAFT January 1993 RIPE NCC EUROPEAN IP NUMBER REQUEST FORM ------------------------------- Part A - Administrative Details ------------------------------- The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: descr: descr: country: admin-c: tech-c: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE ----------------------------------------------------------------------- new page Part B - Technical Details -------------------------- Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. request-typ: machine-0: machine-1: machine-2: subnet-0: subnet-1: subnet-2: inet-connect: use-net: iso-net: Part C - Technical Details -------------------------- If you are applying for more than 2 Class C network numbers then on a separate page, please submit a description of your network plans. Current network layout: Future network plans: In both please include an overview of the size of your subnets. Please do not forget transit networks, terminal servers etc. when calculating your needs. ------------------------------------------------------------------------ new page Part D - Contact Details ------------------------ Complete the section below *ONLY IF* you are making an application on behalf of another organisation. This application is made by:- Name: Organisation: Country: Tel: Fax: E-mail: On behalf of the following organisation: Name: Organisation: Country: Tel: Fax: E-mail: ----------------------------------------------------------------- Please return this document to: local ir-registry name <email of local ir-registry> <phone of local ir-registry> <fax no of local ir-registry> <address of local ir-registry> or to the RIPE NCC if you are applying for a class B network number.

1 0

Local IR WG meeting in Praha
by Daniel Karrenberg 15 Jan '93

15 Jan '93

The local Internet Registries Group will meet during the Praha RIPE meeting. Draft Agenda ============ 1. Approval of the European Internet Number Registration Template Goal is to have an approved template which will replace all local templates thus standardising information and facilitating referral of requests. 2. General discussion about registration procedures Could they be improved and how? Could NCC support be improved and how? 3. 193.in-addr.arpa delegation Report by NCC. 4. Brainstorming about charging models for registration services Deferred from the Paris meeting. Needs progress because of NSF's intention to develop a scheme within 15 months.

1 0

RIPE Database Update Scripts
by Daniel Karrenberg 13 Jan '93

13 Jan '93

Some of the database updates scripts we released on Friday neglect to check for the presence of the configuration file. This can cause hard to diagnose errors. The checks have been added and a new version released at the same place as before: ftp.ripe.net:~ftp/tools/db-scripts.shar.Z Thanks to Daniele Vannozzi of the GARR NIS for reporting the bug. Daniel

1 0

Database Software
by Daniel Karrenberg 08 Jan '93

08 Jan '93

We still need to make a new version of the database indexing and whois-server software which will be controllable by configuration file. The NCC have been thinking about the design of these modules and we came to the conclusion that a total rework is worthwhile. Once we do a total rework we can of course incorporate new features. Some of the features we were thinking about are - (almost) fully controllable via config file - dynamic updates (as opposed to batch updates) This would mean changes are immediately visible in whois - simple update protocol for local registries This would mean that registries could do dynamic and immediately visible updates directly and not via mail - exchange facilities with global internet registry We are currently implementing some prototypes in the PERL language which provides excellent portability. Actually the RIPE database is now running on my laptop PC ;-). We are contemplating of using PERL for the production version as well. If you have any input about this, please let us know. We are especially interested in features required for the local registries. Regards Daniel

1 0

RIPE Dasatase
by Daniel Karrenberg 08 Jan '93

08 Jan '93

The revised database update scripts are now available on ftp.ripe.net as file ~ftp/tools/db-scripts.shar.Z. These are the scripts we use to process database entries. A subset of them can be used to check database entries for correct syntax etc. A big thanks to the beta testers for trying them first. If yoy have problems using the scripts, please let us know. Daniel

1 0

RIPE Whois Server Software Available
by Daniel Karrenberg 08 Jan '93

08 Jan '93

The RIPE whois server software is now available from ftp.ripe.net as file ~ftp/tools/whois-server.shar.Z. This is just the software which allows you to query a RIPE database file. The updates scripts will be released separately. If you have trouble installing the package, please let me know. If you use the package to run a full-service RIPE database server, please notify ncc(a)ripe.net. If apporpriate we can then arrange to automatically re-direct queries from your area to that server. We also ask every full-service RIPE database server to enable query logging and send us the results regularly because we would like to publish usage statistics of the RIPE database as such in the NCC quarterly reports. Daniel

1 0