You're viewing an archived page. It is no longer being updated.
Status: |
Final |
Revision Number: |
1 |
Please mail comments/suggestions on:
Chair: Mike Norris
RIPE-26 Mon Jan 20 1997
Scribe: Carol Orange
Agenda: agreed, without adjustment
Participants: At RIPE-26 Local IR WG, /26=2^6=64 attended.
Minutes: no comments
Actions:
+ Mirjam Kuehne gave the RIPE NCC Registration Services report.
Her slides can be obtained at:
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.
+ 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 <[email protected]>.
+ Use of A's
Mike Norris informed the group that there is a new RFC (RFC 2036) 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.
+ 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.
+ 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.
None.
+ 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.
+ 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.
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.