From mnorris at hea.ie Tue Feb 4 11:59:59 1997 From: mnorris at hea.ie (Mike Norris) Date: Tue, 4 Feb 1997 10:59:59 GMT Subject: Minutes of LIR WG meeting at RIPE 26 Message-ID: <199702041059.KAA06990@dalkey.hea.ie> Below are the minutes of the LIR WG meeting on 20th Jan, kindly prepared by our scribe, Carol Orange. Any inaccuracies or omissions are my fault, and open to correction by list members. Regards. Mike Norris Local IR Working Group meeting Chair: Mike Norris RIPE-26 Mon Jan 20 1997 1. Preliminaries Scribe: Carol Orange Agenda: agreed, without adjustment Participants: At RIPE-26 Local IR WG, /26 = 2^6 = 64 attended. 2. RIPE-25 Minutes: no comments Actions: 1. Charging paper published as: ripe-152. 2. The LIR Training slides are currently being converted to HTML. 3. Reports from registries + Mirjam Kuehne gave the RIPE NCC Registration Services report. Her slides can be obtained in: ftp: //ftp.ripe.net/ripe/presentations/ripe-m26-mir-RS-Report.ps.gz http://www.ripe.net/meetings/ripe/ripe-26/pres/ncc-reg/ + Other registry stuff: Mike Norris reports that there are interesting statistics on ISPs in the US in: http://www.boardwatch.com/isp/intro2.htm + Other Regional Registries: Daniel reported that cooperation among the three regionals remains good, and that there is substantial contact. He also reported on the development of ARIN, the American Registry for Internet Numbers (http://rs.internic.net/arin) ARIN closely resembles the RIPE NCC and APNIC regional registry model both in terms of operations and charging. This development strengthens the position of the RIPE NCC and other Regional registries. Together, the three registries are an excellent example of industry self regulation. The question arises as to whether the IANA should eventually be run by the regionals since together they represent the user community. ARIN is planned to be independent of NSI in 2nd Quarter of 97. Daniel says they will be watching the breakoff from NSI closely, as it resembles the RIPE NCC breakoff from TERENA to take place before January 1, 1998. 4. IP Address Space Assignment + RIPE policy, ripe-140 Mike Norris pointed out that both the policy document (ripe-140) and the associated procedures document (ripe-142) have been in place for a time, and are working well. + IETF WG: IRE --> PAGAN A new IETF working group in the operations area called PAGAN (Policies and Guidelines for Allocations of Network numbers) was kicked off in San Jose to discuss registry policy issues. You can subscribe to the mailing list by sending "subscribe" in the body of a message to "pagan-request at apnic.net". + Use of A's Mike Norris informed the group that ther is a new RFC (rfc2036) entitled: "Observations on the use of Components of the Class A Address Space within the Internet" The document examines the implications for service providers and end clients who get an allocation or assignment of the unallocated Class A address space. DFK: For next allocation, we can ask IANA for 1. A /8 in Class C space. 2. A /8 in Class A space. 3. Both. It was pointed out that while option 1 is safe in the short run, that when the Class C space runs out, we will have no experience with the Class A space which at that point will be the only IPv4 address space at our disposal. It was therefore considered optimal to obtain a /8 from Class A space immediately, and allow those interested in working with it to have an allocation next to their Class C allocation to assign from as they see fit. There were about 15 people present who said they understood the nature of the issues associated with making Class A assignments and would be interested in such an allocation. Daniel said he would request a /8 in Class A space from IANA immediately. A question arose as to whether Local IRs would be able to ease the requirements associated with address space assignments in order to encourage their customers to take an assignment from Class A space. There was *no* consensus on this issue, and it was therefore decided that the normal policies apply at least until further discussion can take place. 5. IP Address Space Usage and Reclamation + use of Class B's It was agreed that this is not a significant issue at the moment. + reclamation of 192.0.0.0/8 It was noted that Bill Manning's effort to get back the address space in 192 seems to have died out. This raised a question about the followup to the "dollar BOF" at the 36th IETF in Montreal. The proposal to set up an IETF working group (PIARA) in which the possibility of experimenting with marketing IPv4 address space (starting with 192.0.0.0/8) has been formally dropped by the IESG who says it falls outside the charter of the IETF. 6. Training + RIPE training courses Aside from the report that the RIPE NCC regularly holds Local IR training courses around Europe and will continue to do so (also in a broader region), Mirjam Kuehne brought up the problem that there are an increasing number of people who sign up, but don't show up. Lars Liman suggested that the RIPE NCC charge a fee to sign up which is returned to those who show up at the course, but not to others. There was consensus that the RIPE NCC should introduce some form of financial back-pressure to prevent this problem, which the NCC happily agreed to do. + Local IR Workshop Rather than having a local IR workshop in conjunction with RIPE 27 in Dublin, it was suggested by Wilfried Woeber that we hold a Database workshop with an emphasis on its use by local Internet registries and their requirements of the RIPE database. It was agreed that such a workshop will be held at RIPE 27. + Other training e.g. APRICOT Mike Norris noted that there is a broad range of in depth tutorials taking place at the APRICOT (Asian Pacific Operators) meeting at the end of January. He asked those attending to give input to the RIPE community on the usefulness of these trainings, that we might hold similar courses in conjunction with future RIPE meetings. Daniel and Mirjam, who are attending APRICOT agreed to give input for the next meeting. 7. Input / Output with other working groups None. 8. Tools + registry administration + stats Bernard Stockman asked if anyone had had experience with "netramet" for gathering network statistics. Wilfried said he'd worked with it quite some time ago, but found it unwieldly (hard to configure to collect the right stuff). It was noted that work on this tool continues and that people may want to check it out. 9. Reverse Domains + counts, errors Daniel noted that the behavior for 193-195 is good, but did not have exact statistics. + administration It was noted that increasingly servers are refusing to allow the NCC to do zone transfers, and claim doing so would cause security risks. This was considered generally unacceptable, as the NCC is chartered to safeguard the quality of the 193-195.inaddr.arpa name space data. 10. AOB Yves Devillers mentioned that it was hard to convince customers wanting connectivity for PI/UNSPECIFIED space already assigned to them to renumber into one of the local IR's PA blocks. He asked what the NCC response is when approached. John Crain answered that we try to convince people to renumber. A question was also raised as to what happens to a local IR's allocation if the local IR closes. Daniel stated that it depends on the circumstances. If it is a takeover by another local IR, then the space will just be allocated by the local IR taking over. There are a lot of complicated scenarios possible, but luckily they've not come up yet in practice. He stated that each closing local IR will have to be dealt with carefully on an individual basis to make sure the customers suffer as little as possible. From yucel at knidos.cc.metu.edu.tr Tue Feb 18 16:58:44 1997 From: yucel at knidos.cc.metu.edu.tr (Yucel Guven) Date: Tue, 18 Feb 1997 16:58:44 +0100 (EET) Subject: Local Whois Server Message-ID: Hi, Here, in Middle East Tech. University (METU), we setup a whois server. Together with updating RIPE sources, we also want RIPE NCC directly to communicate with our whois-server and got the all neccessary info's (such as inetnum:'s domain:'s person:'s etc..) Is this possible? If possible, could you inform me about the steps we must follow? TIA. Yucel Guven METU Computer Center, Network Group e-mail: yucel at metu.edu.tr tel : +90 (312) 2102091 fax : +90 (312) 2101120 metu-nic: YG1-METU ripe-nic: YG251-RIPE