Lo and behold, the Local IR minutes which Anne had produced ages ago, but which got delayed by.... ...your humble servant, Mike Norris Local IR working group Minutes RIPE 23 Amsterdam, 30th January 1996 Chair: Mike Norris Scribe: Anne Lord At the working group meeting there were 111 attenders. 1. Preliminaries A scribe was volunteered :) and the agenda which was previously circulated to the Local IR mailing list was agreed with some modifications to the order of the discussion. The minutes will reflect the order in which items appeared on the agenda. 2. RIPE 22 2.1 Minutes The minutes of the 22nd RIPE meeting had been circulated shortly after that meeting to the Local IR mailing list for comment and minor corrections were made to the text. The minutes were then accepted. 2.2.Review of actions Action 21.3 on Daniel Karrenberg, Mike Norris To draft a recommendation on charging by local IRs until September. Action is still open. A first outline had been written but needed further study and elaboration before a draft would be sent to the list. Action 22.1 on Mike Norris and RIPE NCC To find volunteers from the Local IR working group to continue working on the revision of ripe-104++ without waiting for the publication of rfc1466++. This action was closed. In addition to the RIPE NCC, the members of the editorial committee were: Mike Norris Wilfried Woeber Sabine Dolderer Hans Petter Holen Holger Weinhardt Janos Zsako 3. Reports from registries 3.1 European Regional Registry (RIPE NCC) As the formal report from the European IR was presented in the RIPE meeting plenary, the report to the working group was brief. The shortened report was as follows: * there are now 308 local IR`s. * the predictions for the workload for 1995 were accurate. * new staff are now fully trained. * the "wait" queue is now empty ("wait" queue is non-assigned requests). * approximately one new registry per working day is now being signed up. 3.2 Other Registries There were no comments from other local registries. It was suggested that this might be a good opportunity to organise a local IR workshop in conjunction with the next meeting. There was consensus within the group that this should not be organised in parallel with the EOF meeting. An action item was taken on by the RIPE NCC. Action: RIPE NCC To organise a Local IR workshop in conjunction with RIPE24. 4. Registry Procedures 4.1 European registries - ripe-104++ The draft document "European Internet Registry, Policies and Procedures" (ftp://ftp.ripe.net/ripe/drafts/ripe-104++.{txt,ps} was previously circulated to the Local IR mailing list for comment. There has been and still was considerable discussion on the mailing list. Within the working group the aim was to isolae the salient points and to resolve any differences of opinion so that consensus could be agreed and the document progressed. The following points were discussed: Assignment procedures VSE's - - It was commented that the assignment procedures are too complicated for VSE's. The common situation being one or two externally facing hosts and the rest behind a firewall. It was suggested that the end customer does not necessarily have to complete a network number application form in such cases, but the information might be collected by the Local IR. The important point is however, that the information is archived. PI/PA address space issues - - There was a discussion about PA (Provider Aggregatable) and PI (Provider Independent) address space. If your customer insists, PI address space can be allocated. Local IR's can apply on a per case basis for PI address space from the EU IR or they can apply for a PI block. As specified in ripe-127, there will be no guarantees over the routability of such blocks assigned and using such address space is *strongly* discouraged. - - It was also suggested that ripe-104++ could include a sentence to strongly recommend that ISP's/Local IR's should *not* accept PA address space from new customers which is outside their own CIDR address space. This was agreed. - - There was a question about the existing allocation registration information in the RIPE database. It was agreed that unless a contractual arrangement existed with the customer, assignments in the RIPE database without the "status" attribute marked as PA are considered PI (Provider Independent). If local IR's can make such contractual arrangements retrospectively, then such allocations can be considered PA and marked as such. Agreed. - - Assignments of address space are only valid as long as the assignment criteria under which the original addresses were allocated are still true. Agreed. - - It was suggested that the assignment messages from the RIPE NCC could be made clearer to reflect the significance of the PA assigned address space. Renumbering - - There was some discussion around the procedures for renumbering. It was agreed, that this would be encouraged by making the procedures as easy as possible for those who had agreed to renumber and words to the effect that the size of the previous assignment would not be questioned unless the efficiency was extremely low. Reservations Policy - - It was agreed to base assignments on a 2 year plan from the requestor. No reservations policy was endorsed. Static assignments for dial up - - The document strongly discourages the use of static IP assignments for dial up service. Strongly discourages means that if a strong technical reason is given and accepted, then assignments will be made for a vastly shortened time scale - 3 months was mentioned. Assignment window anomaly - - The largest current assignment window for any local IR is /19 -1. This refers to the amount of address space that they can assign without referring first to the RIPE NCC. The proposal in ripe-104++ was to reduce this to /20. After some discussion and by way of compromise, it was agreed to make the new maximum /19 rather than /20. However, for every local IR with a /19 -1 assignment window, the current value of it's assignment window will be set to /20, with the understanding that it can be increased to a /19 based on the usual criteria (as specified in ripe-104++). It was agreed that this would come into effect immediately after the meeting. Work remaining on ripe-104++ Sections 5,6,7 and 8 remain to be drafted. Section 5 will be drafted shortly after the RIPE meeting when the editorial committee meet and the draft will be circulated to the list shortly after the meeting. 5. Registry services and charges 5.1 RIPE NCC charging model The contributors committee had agreed on a charging model for 1996. All documents relating to the Contributors Committee meetings and revenue and expenditure documents can be found in: ftp://ftp.ripe.net/ripe/new-registry/ncc-co/ 5.2 Charging by local IR's As reported under item 2.2 a draft outline had been prepared. The reviewed document will be circulated to the mailing list after the RIPE meeting, once it has been reviewed and edited. The main emphasis of the document is that it is acceptable practise for Local IR's to charge for their services. There will probably also be some wording included to the effect that any remaining Last Resort Registries should not charge for profit. 6. Tools All Local IR's were encouraged to make any tools developed for local use available to the wider community if they thought that they could be useful to others. The RIPE NCC offered to "house" these tools and make their location visible. 7. Input from other Working Groups 7.1 DNS Ripe-105 will be incorporated into ripe-104++. 7.2 Database A proposal was made to the Database WG mailing list to incorporate the functionality of <auto-inaddr@ripe.net> into the general database update procedure. In future, it was proposed that in-addr updates could be sent to <auto-dbm@ripe.net> with a special tag which could be something like "INADDRREQUEST". 8. AOB 8.1 Reverse delegation of networks for partially assigned class B networks There was a question about in-addr.arpa delegations for assigned portions of class B address space. It was suggested that either you could ask the Internic to delegate 128 zones to the Local IR or to channel this request through the RIPE NCC. It was suggested that it might be useful to include a reference to this in ripe-104++. Action: RIPE NCC To include a paragraph on procedures for the reverse delegation of partially assigned class B networks. 8.2 Handing back of networks from block 192.0.0.0/8 In a mail of the PIER working group it was proposed that by 1997 users of non-aggregatable 192 address space should consider renumbering. There was a question concerning where 192 address space should be returned to. It was suggested to return it to the RIPE NCC in all cases, and the RIPE NCC will handle it as appropriate. Any queries can be sent to the RIPE NCC <hostmaster@ripe.net>.