- lir-wg - mailman.ripe.net

Request for Information re: Internet Service Providers
by Susan Estrada 17 Jul '93

17 Jul '93

I am writing a book called Connecting to the Internet: A Buyer's Guide. I will be including a list (DLIST) of dedicated line providers to make it easy for the reader to find a connection. If you have a network and I have not already contacted you, I need the information at the end of this message for your network. If you would like to add your information, please reply by Tuesday, July 20, noon. The book is going to be published by O'Reilly and Associates and should be available in August. The list will be made available on the Internet courtesy of O'Reilly upon completion. Details are forthcoming about how to get updates of DLIST or add your network information in the future. This message should be forwarded to anyone you think should see it. Thanks for your assistance. Susan Estrada sestrada(a)cerf.net -------------------------- Network Name: Service Area: Contact: Voice: email: FTP more info: Network Description (short paragraph):

1 0

RIPE NCC Quarterly Report #5 Available
by Daniel Karrenberg 16 Jul '93

16 Jul '93

[sorry for the slight duplication] Dear colleagues, the 5th RIPE NCC Quarterly Report covering the second quarter of 1993 is now available. It has document-ID: ripe-90 and can be retrieved from the ripe document store. The files are: ftp.ripe.net:ripe/docs/ripe-docs/ripe-90.ps (PostScript) ftp.ripe.net:ripe/docs/ripe-docs/ripe-90.txt (ASCII) Should you have difficulties retrieveing it, we will be happy to help you with retrieval via the network or send you a hardcopy. The management summary part is attached below. Kind Regards Daniel Karrenberg RIPE NCC Manager ---- Management Summary The European Internet continues to grow steadily as the number of hosts registered in the domain name system will be in excess of 400,000 at the end of the reporting period. All NCC activities have run smoothly during the reporting period. Delegated Registry The number of local registries has increased to some 61. Together with the NCC they have assigned 3511 class C and 14 class B network numbers during the reporting period. Still only about 10% of the assigned networks are routed on the Internet while usage of the internet protocols and thus demand for addresses continues to expand in all areas. Since the European registry system runs smoothly, the highest priority in this area remains automatic alignment of regis try databases with the global Internet registry. RIPE Database There are now more that 30,000 objects in the RIPE database and the NCC is still processing around 500 update requests on an average working day. A complete re-design of the database software has been completed and implementation is progressing. Additional efforts to increase database coverage and to provide pro-active maintenance are required. This and the software implementation will be the highest priorities during the next quarter. Documentation The document store is running reliably and is being used worldwide. In addition to a number of new RIPE documents a leaflet describing registry services has been produced. Joint Projects The two running projects have almost completed and are successful. While the projects have been very valuable to the NCC and vice-versa they have required more resources from permanent NCC staff than expected. A follow up project PRIDE (Policy-Based Routing Implementation and Deployment in Europe) has been proposed with this experience in mind. Funding for this project has been secured almost completely. The NCC has started its second year of operation successfully continuing a high level of service. We are looking forward to the results of the first-year review and to the subsequent revision of the NCC activity plan. Based on the growing European Internet community and the increasing demand for service and new activities, the NCC will need additional resources in the medium term.

1 0

Re: (Non)-Uniqueness of Net Names
by Gartha S. Parrish 08 Jul '93

08 Jul '93

I agree with Daniel that unique network names do serve a purpose. In addition to making it easier to discuss a specific network, there is a recognition factor associated with a network name that just does not exist with an internet address. I have discovered many errors because a net name didn't look right and when I checked, there was either a typo or some kind of mix-up with the number/numbers. I would hate to see this error-checking "feature" removed. I would vote for keeping network names unique at least to the level of the organization or site. This would leave the level of granularity up to individual organizations. Network names would still be registered in the InterNIC and RIPE whois databases, and multiples would appear much as a block entry looks now. This would also be helpful in cases where troubleshooting is needed and either administrative or technical contacts must be reached. Gartha Parrish NSFNET/MERIT ================================================================

2 1

(Non)-Uniqueness of Net Names
by Daniel Karrenberg 07 Jul '93

07 Jul '93

Any strong opinions? I'll answer the factual questions. Daniel ------- Forwarded Message Date: Mon, 05 Jul 1993 23:14:10 -0400 From: Mark Knopper <mak(a)merit.edu> Resent-From: RIPE NCC Staff <ncc(a)ripe.net> To: ncc(a)ripe.net, merit-ie(a)merit.edu, conf(a)merit.edu, dsj(a)merit.edu, markk(a)internic.net, scottw(a)internic.net Resent-To: RIPE NCC Staff <staff(a)ripe.net> Subject: (Non)-Uniqueness of Net Names Hi. I'm including the RIPE and InterNIC folks on this discussion. Here are some questions for your consideration: 1) Should we remove the uniqueness requirement for net names in the Merit and InterNIC/whois databases? 2) My understanding is that RIPE's database does not require existence or uniqueness of net names. Is that correct? 3) Do net names serve any useful purpose? Should we get rid of them altogether? If we reach consensus here, I suggest that we issue an Internet draft containing a proposal. If no major concerns are raised we can make the decision final and issue an RFC. What do you think about this suggestion? What other people or organizations should be consulted in this process? Mark .... included messages omitted ------- End of Forwarded Message

6 6

Re: (Non)-Uniqueness of Net Names
by Wilfried Woeber, UniVie/ACOnet, +43 1 436111 355 06 Jul '93

06 Jul '93

Daniel, I'm not including all the original recipients to save bandwidth and junkmail. I propose that you could summarize to them, if you rate something as being substantial input. |.. | > 3) Do net names serve any useful purpose? | |Yes they do! As with all names they make it easier to talk about |the object named. I agree wholeheartedly! I think there is already too much things in Internet that is talked about (and output by programs) in numbers and figures only. | > Should we get rid of them altogether? | |So this answer is no. I think we should keep them, although names are only as useful as the information being put into it. Eg. calling a network say 193.170.x "NET01" for the database... Wilfried.

1 0

Re: (Non)-Uniqueness of Net Names
by Daniel Karrenberg 06 Jul '93

06 Jul '93

> 1) Should we remove the uniqueness requirement for net names in the > Merit and InterNIC/whois databases? This is worth cosidering seriously. Withou a whole lot of consideration I tend to be in favour. We should require uniqueness within some local domain such as an organisation or site. > 2) My understanding is that RIPE's database does not require existence > or uniqueness of net names. Is that correct? No, we require exitence and uniqueness, although uniqueness is not checked thoroughly for blocks. > 3) Do net names serve any useful purpose? Yes they do! As with all names they make it easier to talk about the object named. > Should we get rid of them altogether? So this answer is no. > What other people or organizations should be consulted in this process? I'll copy the RIPE local registries group. Daniel

1 0

ripe-83 update
by Anne Lord 28 Jun '93

28 Jun '93

Hi, I am currently updating the European IP template since the expiry date on the document is 30th June. I have received comments from some people already, and have made some changes (which comprise mostly typographical tidying up and word order changes - nothing huge). If anyone has any further suggestions, just let me know - by the end of the week please. Thanks, -Anne

1 0

New database software update
by Marten Terpstra 24 Jun '93

24 Jun '93

all, It's time to let you know what has happened wth RIPE database software development. After some more experimenting to check feasibility we have progressed quite far into a complete rewrite of the database software. We have completed the system design and started to implement various modules. The new design has the following features - fully (and we *mean* fully!) configurable from a config file - separate files (and indices) to store different databases - dynamic updates and deletes as opposed to batch only - possibility for update protocol other than e-mail - guarded fields designed in - dynamic update of secondary databases possible Features which have been requested but are not designed in: - preserve the order of tags within object - preserve the position of remark or comment lines within objects These two features turned out to be hard to specify in the light of updates and even harder to implement. They might go in the next release if someone can come up with a consistent and intuitive spec. The new software will be implemented in the perl language. So those of you who do not have it installed and want to use the RIPE database software should plan to install perl. Of course you won't need perl if you just want to use a whois client and send in updates by mail. Implementing in perl instead of shell, awk and C has three benefits: coding in perl ist fast, subroutines can be used (missing from std awk) and the result is portable. We have a copy of the alpha software running on a PC under UNIX. Together with a notebook this gives you a "portable" RIPE database. The first module completed is the whois server (net.c and netdbm.c replacement). This server runs as its own daemon process rather than under inetd. The measured performance on a SUN ELC before optimising is 5 queries/s on average and the server can sustain peaks of 50 queries arriving in parallel. The new server is compatible with the current one and has some added features: the source databases (RIPE, MERIT, NIC etc.) can be selected individually rather than either RIPE or all, the same connection can be used for multiple queries (nice for tools like prtraceroute), a grep type query as well as nice logging. We have an alpha version of the whois server and the database indexing tool running. The next part to be tackled is the update procedure including the guarded attributes. The last part will be the current mail interface for the update procedure. Impact: Sometime in the next few weeks (after another announcement) we will start using the new server on whois.ripe.net. This should be transparent. Once this is running we will implement the backlogged new tags such as the DMZ specifics in the network and the operatinal contacts. Sometime later we will start using the new update procedures. This will mean that updates mailed in will appear in the database more quickly. It will also mean that we will be more stringent in checking updates, because there will be less human intervention from NCC staff. So you should expect more bounced updates, but they will also happen much more quickly. Diagnostics will be better because the dynamic update procedure will have access to the current database. This will mean that heuristic checks of updates can be better. If you have any questions, please do not hesitate to ask them either puclicly for the benefit of all or privately. The NCC people working on this are me (design, coding and testing) and Daniel (design and testing). Cheers, -Marten

1 0

the difference between assign@ripe.net and ripe-dbm@ripe.net
by RIPE Database Manager 21 Jun '93

21 Jun '93

Dear people, There seems to be some misunderstanding between the usage of assign(a)ripe.net and ripe-dbm(a)ripe.net. Please use these two addresses as follows: assign(a)ripe.net - only for NEW assignments made out of your 193.x block (so, they should not be in the RIPE or NIC database yet) ripe-dbm(a)ripe.net - all other nets new to the database, and all updates. x.193.in-addr.arpa requests should be send to hostmaster(a)ripe.net, because there is some additional action on behalf of the NCC needed. We will then forward the objects to ripe-dbm, when all set up. The reason we have a difference between the two is that assign(a)ripe.net has some additional consistency checking before it will forward to the database, since we found that many people made 192/193 typos, and also we are planning with InterNIC to automatically forward NEW 193 assignments directly to them in exchange format in the future. If a network send in to assign(a)ripe.net is already present in the NIC or RIPE database, the update is bounced back to the NCC for manual review. In most cases it will be forwarded to ripe-dbm after, but it would be nice if we could keep these kinds of "assignment errors" as we call them, to a minimum. PS contact people send in to either address are not checked, so you can simply include them in assign or ripe-dbm together with the network numbers they belong to. Cheers, -Marten

1 0

Re: RIPE NCC Review
by Daniel Karrenberg 09 Jun '93

09 Jun '93

On May 27th I sent the message below. Noone has volunteered to represent the lcoal-IR WG. Unless someone comes forward now, the group will not be represented formally. Regards Daniel > Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> writes: > > As agreed at the last RIPE meeting a review of the first year of NCC > operations as well as a review of the NCC activity plan will take place. > The review board will consist of the RIPE chair, the RIPE WG > chairpeople and the NCC manager. Any interested members of the RIPE > community will also be invited to paricipate. The RIPE chair is going > to announce this activity shortly. > > The local-ir WG has a problem here as the chairperson *is* the RIPE NCC > manager. To avoid any possibilities of a conflict of interests I would > appreciate if the local-ir group could agree on a different representative > for this purpose. > > If you are prepared to represent the local-ir group in this, > please identify yourself either to me or to the while group. > > Ragrads > > Daniel

3 3