- lir-wg - mailman.ripe.net

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

FYI: US NIC changes or non-changes
by Daniel Karrenberg 05 Jan '93

05 Jan '93

The NCC will get in touch with the appropriate people a.s.a.p. to ensure smooth interoperation. Daniel ------- Forwarded Message Date: Tue, 5 Jan 1993 07:08:05 -0800 (PST) From: Susan Estrada <estradas(a)nic.cerf.net> To: com-priv(a)psi.com cc: Eric Grimmelmann <egrimmelmann(a)attmail.com>, mitchel(a)nic.cerf.net, Scott Williamson <scottw(a)nic.ddn.mil>, Susan Estrada <estradas(a)nic.cerf.net> Subject: NIS Manager Award Announced For Immediate Release January 5, 1993 National Science Foundation Contact Don Mitchell (202) 357-9717 dmitchel(a)nsf.gov Network Solutions Contact Mary Bloch (703) 742-4740 maryb(a)netsol.com AT&T Contact Shelly London (908) 221-4355 london(a)attmail.com General Atomics Contact Susan Calcari (619) 455-3900 calcaris(a)cerf.net NSF NETWORK INFORMATION SERVICES AWARDS In cooperation with the Internet community, the National Science Foundation developed and released, in the spring of 1992, Project Solicitation NSF92-24 for one or more Network Information Services Managers (NIS Manager(s)) to provide and/or coordinate (i) Registration Services, (ii) Directory and Database Services, and (iii) Information Services for the NSFNET. As a result of this solicitation, three separate organizations were competitively selected to receive cooperative agreements totalling over $12 million in the three areas of (i) Registration Services, (ii) Directory and Database Services, and (iii) Information Services. Together, these three awards constitute the NIS Manager(s) Project, named the INTERNIC. Network Solutions will provide registration services, AT&T will provide directory and database services, and General Atomics will provide information services. It is important that the three project participants work closely together to provide a seamless interface for users in need of services. For this reason, the three awardees, at the request of the Foundation, have developed a detailed concept and plan to provide this seamless interface called the "INTERNIC" and have agreed to the structuring of their three separate awards as one collaborative project. Steve Wolff, Director of NSF's Division of Networking and Communications Research and Infrastructure says, "We all feel intuitively that the domestic Internet and the distributed collaboration that it facilitates are rapidly creating a national "workplace without walls". These three awards to geographically dispersed organizations for Network Information Services, which require a high degree of coordination and collaboration, will both exploit and demonstrate the success of the network in enabling such distributed collaboration." Consistent with FNC guidelines on obtaining reasonable cost recovery from users of NREN networks, the NSF has determined that the INTERNIC Information Services provider may charge users beyond the U.S. research and education community for any services provided. Also, the INTERNIC Directory and Database Services provider may charge a fee for maintenance of special databases, for extensive directory listings and may charge users beyond the U.S. research and education community. Finally, because the registration function provided by the INTERNIC Registration Services applies to domestic and international, commercial and individual users in addition to research and educational users, it is expected that an appropriate registration fee structure will take time to develop. NSF expects to engage in an extensive discussion with the domestic and international Internet community of the motivation, strategy and tactics of imposing fees for these services during the next fifteen months. Decisions will be implemented only after they have been announced in advance and an opportunity given for additional public comment. Network Solutions will provide registration services as the IP registrar, issue IP numbers worldwide using delegated registries under the guidance of the Internet Assigned Numbers Authority and also register domain names, and track points of contact. Applications for assignment will be accepted via email or facsimile. The information from these assignments will be provided to the directory and database services provider to be made available to the entire Internet community. As a part of the Domain registration efforts Network Solutions will periodically release the top level zone files to be used by all root Domain Name servers. AT&T will develop and maintain a Directory of Directories, including lists of FTP (File Transfer Protocol) sites, lists of various types of servers available on the Internet, lists of white and yellow page directories, library catalogs and data archives. AT&T will also provide white and yellow pages type Directory Services. Access to these services will initially be provided through several currently popular in-use interface methods while migrating to the use of X.500 technology, the current standard specification for distributed information storage and retrieval. The database services which AT&T will provide include the establishment of Database Services to extend and supplement the resources of the NSFNET, such as databases of contributed materials of common interest to the user community. AT&T will also offer database design, management, and maintenance to institutions and groups for inclusion in the Internet. General Atomics will provide Information Services acting as the NIC of first and last resort and the NIC of NICs. The INTERNIC information services will include a full-service Reference Desk, a database of comprehensive networking materials called the Info Source, training classes and documentation, and coordination services among all appropriate groups in the community. In keeping with the innovative spirit of the Internet, several new approaches to distributing services will be implemented. Among these innovations is NICLink, a user-friendly hypermedia interface offering access to the Info Source and all the information it contains. NICLink will be distributed on both standard computer diskettes and CD-ROM. Another is the concept of the Info Scout, an individual who will scout out new resources and innovative uses of the network for inclusion in the Info Source. Network Solutions is a 400-person telecommunications analysis and integration company headquartered in Northern Virginia. Its mission is to support its customers in achieving their missions through the mastery and application of networking technology. Network Solutions currently operates the DDN NIC. AT&T is the leading provider of global information movement and management products and services. AT&T offers a wide array of data communications services that includes private line, X.25, frame relay, TCP/IP, protocol conversion, and electronic mail services. General Atomics is a San Diego-based high-technology research and development company and operates CERFnet and the San Diego Supercomputer Center. CERFnet is an Internet network service provider that operates throughout the state of California and nationally. CERFnet was launched in the spring of 1989 with a $2.8 million grant from the National Science Foundation. The San Diego Supercomputer Center is a five year cooperative agreement funded by the National Science Foundation to support high performance computing. ### ------- End of Forwarded Message

1 0

seasons greetings
by RIPE NCC Staff 21 Dec '92

21 Dec '92

Dear colleagues, We would like to thank all of you for a year of splendid cooperation during the first 3/4 year of NCC operation and for all your support during 1992. We would like to wish you all a merry X-mas and the best wishes for all of you in 1993, and hope to continue the excellent cooperation in the coming year. Thank you all, Anne, Daniel and Marten

2 1

Re: First draft of the European Template for IP number requests
by Peter Koch 18 Dec '92

18 Dec '92

Just as a support for PR actions we could ask requestors how they managed to contact the local IR or RIPE-NCC, i.e. where they got the address from. Of course this question is optional and we might increase the chance of getting answers if we ask in a multiple choice manner. XX. If this is the first time you apply for an address, please tell us how you came to know about <insert-local-ir> O received a pointer from RIPE-NCC (well, who or what made you contact RIPE-NCC ?) O USENET News O customer support/documentation O local dealer O computer magazine (pls specify: _____________) O other publication (pls specify: _____________) O ... -Peter-

1 0

Re: First draft of the European Template for IP number requests
by Duncan Rogerson 15 Dec '92

15 Dec '92

> then it obviously won't be worth it. Might it be worth "piloting" various > types of forms?? This might be a nice idea, if we got a few forms together, and then at first see how much trouble it is for the local Registries to translate/transform each into a local language version, and then take it from there, trying to find guinea pig applicants who don't mind taking the time to comment on the forms ? Dunc

2 1

Re: First draft of the European Template for IP number requests
by Havard.Eidnes＠runit.sintef.no 10 Dec '92

10 Dec '92

I said: > * ...If you subnet a class C network number... you *always* waste > * address space, since subnet 0 and -1 and host 0 and -1 can (normally) > * not be used. Thus, the best utilization one can make of a subnetted > * class C network number is around 75% (if I haven't made an error in > * my calculation). If there is a need for two large subnets, the > * largest potential utilization immediately drops to around 50%. and Marten Terpstra replied: > Not quite sure what you mean here. What do you consider the best utilization > of a subnetted class C address ? If you split up the C net in 32 hosts parts > (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 > (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose > hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will > have to convince people to pack their network numbers as good as possible. Ok, lets do the arithmetic for these two cases: for a subnet mask of 0xffffffc0, you lose 0-63 (subnet zero) 192-255 (subnet "minus one") and 64, 127, 128, 191 (various broadcast addresses) which comes out to just under 50% utilization. With cisco routers, if you know what you are doing (!) you may say "subnet-zero", and use subnet zero as an ordinary subnet. This is not without danger. With a subnet mask of 0xfffffff0, you lose 0-15 (subnet zero) 240-256 (subnet "minus one") and 14*2 host numbers (0 and "minus one" for subnet broadcasts) which comes out to just under 77% utilization. > * It is good to see that the number of subnets is asked for. > > Exactly, and I think that the mix of number of hosts and subnets is a good > indication for the registries to base the assigments on. I do not think that > one should simply give whatever they ask for. We have had more than one case > where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You > really want these people to only use up 8 or maybe 16 Cs. Besides if you > compare the hosts and subnet predictions together with the number of nets > they request, you get a fair idea whether of not they have any idea what they > are doing ;-) Yes, but with other (older) routing protocols than OSPF, this all depends on the (planned?) topology of the network, since you can't tie together subnets of a subnetted network with pieces of another network. - Havard

1 0

Re: First draft of the European Template for IP number requests
by Havard.Eidnes＠runit.sintef.no 10 Dec '92

10 Dec '92

> > Format: quantity of numbers requested followed by class of request. > > > > Example - req-typ: 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: > > > > 1 class C number (up to 255 hosts) > > 2 class C numbers (up to 510 hosts) > > 4 class C numbers (up to 1020 hosts) > > 8 class C numbers (up to 2040 hosts) > > 16 class C numbers (up to 4080 hosts) > > 32 class C numbers (up to 8160 hosts) I have for a while looked at these host numbers as somewhat inaccurate, primarily since this does not take subnetting into account. If you subnet a class C network number (as some people end up doing, as was mentioned by Peter Koch, since sometimes people have a small number of hosts at a given site), you *always* waste address space, since subnet 0 and -1 and host 0 and -1 can (normally) not be used. Thus, the best utilization one can make of a subnetted class C network number is around 75% (if I haven't made an error in my calculation). If there is a need for two large subnets, the largest potential utilization immediately drops to around 50%. It is good to see that the number of subnets is asked for. In connection with this, this is a part of a relatively recent addition to the form I use: + Since there is a danger of IP addresses becoming a scarce resource, + there is a general desire to reduce the waste of IP addresses. + Therefore, please take the following points into consideration when you + evaluate your own need for IP addresses: + - A class C network may also be subnetted, and the subnet mask can at + least be chosen separately for each class C network. You should + probably consider adopting the strategy for assignment of host and + subnet numbers outlined in RFC 1219. + - Newer routing protocols (OSPF) may support variable length subnet + masks. Likewise, if you use OSPF, you may tie together different + pieces of a subnetted network with (pieceds of) another IP network. + Ok, the reference to OSPF is probably too technical for this type of form (and it is perhaps also a bit too advanced for most people), but you get the direction I was thinking in. Sometimes, people do not know (or "want" to know) about subnetting C numbers, but I generally disregard arguments of administrative ease and such... :-) > > host-0: > > Please state the number of machines in your organisation that > > currently require a unique IP network number (hosts). > > The term 'host' often causes confusion here, which may be a local language > problem. Hosts are often thought of as > x m^3 big :-) > An explanatory text should explicitly tell people to take also into account > PCs (terminal servers ...) and the like. Yep. "Each and every box requiring a separate IP address is considered a host in this terminology." is probably something in the direction of what you want (?). > Somewhere in the information package (here or in (c)) requestors should > be guided to not forget transit networks when calculating their needs. > And, in close relation with that, people should be asked to give an > overview of the size of the different subnets, e.g. 17 subnets, 10 with < > 20 hosts, the rest with up to 120 machines. This is often the case when > large companies (e.g. insurance comp.) have some central administration > and a number of regional offices. I completely agree. Should one mention unnumbered P-P serial links as a possibility? Or is this again too technical? > > provider: > > Please state whether you have an IP service provider. > > An "IP service provider" is an organisation which can provide you > > with connectivity external to your network. This seems to assume that the applicant already has established relations with an IP service provider, which does not need to be the case. However, people most often know if they are going to connect to a service provider, and who that would be. Unfortunately, I have to agree with Duncan Rogerson that I also don't really like the appearence of the new form too much. The main objection I have goes in the same direction as Duncan's, I think, as I see no reason to "formalize" the application form in the style of the RIPE database entries, as long as this data isn't going to be stored in such a system. I also agree with Duncan that explanatory text should be interspersed with the registration information (at least short versions of it, as shown by Duncan). My initial gut reaction was also that this form looked too complicated for most people to grasp and understand easily, and that this thus may cause more load on us, the delegated registries, explaining what needs to be filled in and what can be left out in each case. In my form I have a "nic-hdl" entry for the persons in addition to address, phone etc., and even though I have stated The nic-hdl is optional, as explained in the attached document (ripe-50). I still get questions about it (ok, not many, but you probably see my point...) - Havard

5 7