RIPE Meeting 21, Rome May, 8-10th, 1995 Chairman: Mike Norris Local IR Working Group Minutes Agenda 1. Select scribe 2. Agree agenda 3. Minutes ripe meeting 20 4. Actions outstanding 5. Reports from registries - local registries - RIPE NCC - global coordination 6. Charging for services - report of position for 1995 - billing procedures - model for future years - ticketing system 7. Training of (new) registries 8. Tools 9. Others - ripe-104 - database issues - reverse domains 10. AOB 1. Select scribe The meeting was held in two sessions, on 8th and 9th May 1995. Mike Norris, chairman of the WG, presided. Mirjam Kuehne kindly volunteered to take a record of the proceedings. There were about 110 people in attendance. 3. Agree agenda and 4. Actions outstanding Referring to the minutes of RIPE 20, it was noted that all actions for the working group had been completed. 5. Report from registries 5.1. Global Registries Mike Norris reported on a meeting of the three regional registries (RIPE NCC, APnic, InterNIC) held in January 1995 in Amsterdam after the last RIPE Meeting. Mike Norris attended this meeting as a representative of the local IR's in Europe. His report was sent to the local-ir mailing list at 29 Apr 1995. This meeting and another held in San Diego confirmed the good working relations and close cooperation between these registries at worldwide level. Daniel Karrenberg reported that procedures and criteria were being harmonised. The three regional registries are singing from the same hymn-sheet, and contacts between them were being intensified. 5.2. NCC Daniel Karrenberg reported on the activities of the RIPE NCC as the regional IP registry for Europe. A big change had been the introduction of a ticketing system to track transactions. He outlined the formalities this system required of people mailing queries to the NCC and urged all to read ripe-183 where these were documented. Daniel Karrenberg gave some reasons for the introduction of a ticketing system at the RIPE NCC: - Since the RIPE NCC receives more and more requests multiple hostmasters work on one mailbox. The ticketing system helps coordinating this activity. - Sometimes aditional information is sent by the requestor and not by the local IR that sent the requests originally. Ticketing system helps tracking requests. - Statistics will be included in the ticketing system that shows how long a requestis pending and why. This is not implemented yet. - Ticketing system can help supporting the model of usage based charging. Another new prodecure has been introduced at the RIPE NCC: the Reg ID that every registry is assigned must be mentioned in every request sent to the RIPE NCC, preferably in the form of X-NCC-RegID: regID. Please read ripe-183 for more details. Currently ticketing is still done by hand, but it will soon be overtaken by a robot. This requires strict adherence to the new formats. If the registry ID is not mentioned in a request sent to the RIPE NCC the ticketing procedure has to be done manually. This will produce delay in processing the request. A new request can be sent with a new ticket line: NCC#new-request-number This is not specified yet in ripe-183. *Action Daniel Karrenberg: Daniel Karrenberg will specify exact format of NCC#new-request-number and send it to the local IR mailing list. Details of growth in the activities of the NCC and of the Internet in Europe would be reported to the plenary session. Daniel Karrenberg reported the current staff situation at the RIPE NCC. He noticed a tremendous increase in number of registries and requests. Unfortunately there is not the same increase in the number of staff. But in June Hatice Kuey will join the RIPE NCC as Junior Hostmaster staff. 5.3. Reports from Local Registries No workshop has been organised between local IR's before the RIPE Meeting as usual. None of the present local registries had a report about unusual occurencies in the registries. Daniel Karrenberg mentioned a problem that occured with requests from large organisations that had large address space assigned in the past. These assignments were justified by the number of subsidaries. The address space was meant to be distributed among the subsidaries. The situation has often changed so that the subsidaries do not receive address space from the mother organisation and submit requests for address space to local IR's or directly to the RIPE NCC. Daniel Karrenberg suggested the following procedure: Ask the subsidary to provide a letter (or e-mail) with a statement that no address space can be received from mother organisation and why. This could help to ask address space back from mother organisation since original conditions are not held anymore. Daniel Karrenberg said he understands problem for provider to refuse address space to customers but the community needs to avoid that organisations are stockpiling addresses. The RIPE NCC wants to know where addresses are and if they are used. Maybe addresses can be asked back in the future when we run out of address space. 6. Charging for Services Details of commitments and payments for NCC services in 1995 were circulated. Daniel Karrenberg said that the problem of contributions from EUnet constituents had been resolved. This, together with natural growth in the number of new registries, meant that the current financial position was quite healthy, with 67% of the budget for the year already banked after four months. *Action Daniel Karrenberg: to put billing information in the database. The meeting discussed charging arrangements for 1996 and subsequent years. In September 1994, the RIPE NCC Contributors' Committee, representing the paying customers, had decided that from 1996 onwards, charging should be related in some way to the volume of service provided. The Committee would meet again in September 1995 to agree on a charging model, which would be prepared by the NCC and discussed on the list beforehand. It was agreed that the model should be transparent, with subscribers being able to find out what their bills were going to be. Automated transactions would not be counted for billing purposes. The fixed charges for small, medium and large subscribers would probably account for 50% of the budget in order to provide for financial stability and continuity. *Action Daniel Karrenberg and Mike Norris: to draft a recommendation on charging by local IRs until September The RIPE NCC will restart the publication of Quartely Reports. Production has been simplified. Questions: Q: Do last resort registries run by EUnet remain? A: Yes, but RIPE NCC will watch carefully that addresses are really assigned as last resort. Q: What is the difference between the prices on the list? A: Different prices for different sized registries; registries determine their size themselves. The size and the price is published and can be seen and compared by all registries. Size can be changed over the time. Q: Some registries have higher billing/income than committed. What does this mean? A: These are new registries and the sign-up fee is added in the income column. Q: How is the time-permitting procedure working (has it effect)? A: Is works excellent! Q: How long is the delay? A: Technically the RIPE NCC maintains two queues of requests (normal-service queue and time-permitting queue). Hostmasters can proceed with a request in the time-permitting queue when the normal-service queue is empty. This has not happen too often (not at all). Q: How much resources take referrals to service providers? A: The RIPE NCC doesn't advertise itself as such a service and doesn't answer end user questions in general. When the RIPE NCC receives requests for service providers, requester will be pointed to the ip-provs mailing list. We should continue doing this. This does not require too much resources. We don't spend local IR's money to provide consultancy for customers of the competitor. Q: If RIPE NCC could publish referral information, this would relief the NCC. A: Referral service is not a problem yet. The RIPE NCC receives 2 of such questions per week. When it becomes a remarkable amount of time, we will find a solution. Q: Couldn't we take the amount of e-mail messages registry sends to the RIPE NCC as indicator for usage based charging? A: This is not such a good idea. It discourages registries to ask questions. What, if the RIPE NCC has a question about a request and the registry sends the answer back, should they be charged for this message? No. Q: Shouldn't we improve a model that combines the size of a registry with with the usage? A: This is a good idea. Q: Couldn't we take inetnum objects in DB as criteria? A: This could also be a possibility. Q: What is the current relation between the RIPE NCC and TERENA? A: The RIPE NCC is still under the umbrella of TERENA. Staff of RIPE NCC is employed by TERENA. But the NCC does all dealings with the registries on its site, apart from the real billing process. We pay 10,000 ECU to TERENA for administrative work. current problem: TERENA is shrinking, RIPE NCC is growing, problems with hiring more staff. Q: Can local IR charge customer for their services? If yes, who has implemented it? A: Yes, local IR's can charge for their services. The RIPE NCC does not know who has implemented it, since no registry informs us about it. Note: It is only allowed to charge for services, it is not allowed to sell address space! Q1: Should the RIPE NCC publish a document with charging recommendation? Q2: Should the RIPE NCC publish a list about charging registries? A1: Yes, some recommendations would be useful: For what services can be charged and for which not; helping with the right language. A2: No, this is not a good idea. This could be interpreted as selling addresses. 7. Training On the last ncc-co meeting was agreed to produce a training course to help new registries to fulfil their function as Local Internet Registry. This was coppeled with the charging model: New registries pay a sign-up fee that will be used to produce such a course. But while the course were intended primarily to help new registries, "old" IRs were welcome to attend if places were available (those registries that have payed sign-up fee will be preferred). Mike Norris encouraged all registries to avail of this valuable training/ re-training resource for their staff. A lot of procedures and guidelines have changed in the past. The RIPE NCC has started in March to produce a training course. A project framework has been published to the local-ir mailing list. Some help and input has been offered to the RIPE NCC. Anne Lord and Mirjam Kuehne are running the project. They are currently busy to prepare the course. Please note that they have only two hours per day to do so. The first course will be held at 26 June 1995 and a training guide would soon be published. After this first course as much course as necessary will be held. The RIPE NCC is also prepared to give courses abroad, when enough registries come together in one country. 8. Tools The monthly host count condicted by the NCC had been further delegated, with sixteen European top-level domains now doing the count locally and making the results available to the NCC. The NCC had refined existing tools in order to analyse the reverse DNS for IP networks in European blocks. The results showed a very poor picture, with low coverage and lots of errors. People were urged to avail of the tools and to try to improve the situation. 8.1. Geert Jan de Groot produced tools that check for errors in reverse delegations and complains if they sustain for a week or more. The tools are available at: ftp://ftp.ripe.net/ripe/local-ir/{inaddrcount, revcheck} 8.2. David Kessens from the RIPE NCC has written a tool to automize requests for reverse domain delegations. It checks the zone that asks for reverse delegation and produces a fairly long output containing all errors found. The requests sent to the RIPE NCC still contain 70% errors but usually the errors are removed at the second time the RIPE NCC receives the request (that was not always the case in the past). The output that is send back to the requestor helps to correct the request and the zone. The tool is still in the test period at the RIPE NCC. After it is stable, it will be published. 9. Other Issues 9.1. ripe-104 Daniel Karrenberg has circulated his draft about VSE's again. He also reported on the current discussion about address space allocation and assignment procedures: On the IETF has been agreed to distinguish between two different kinds of address space: - provider agreegatable address space (PAS) - povider independent address space (PIS) Daniel Karrenberg summarized other topics in the current discussion: The exhaustion of IPv4 address space is not the main problem. The main issue is the growth of the routing tables. On average there are 4000 hosts per route. This shows that CIDR works, but still not enough. Some routers begin to fall over. Service Provider and local IR's should only use and assign PAS (see draft from Yakov Rekhter: ftp://ftp.ripe.net/internet-drafts/draft-ietf-cidrd-ownership-01.txt) The current debate mentiones sizes of address space for PIS and PAS: smaller and equal than /19 (32 C's): PIS greater than /19 (32 C's): PAS This discussion delayed the revision of ripe-104. The providers should decide what prefixes they will route and for what price. It should not be the regional registrie's task to make this decision. The registries should clarify the implications of PIS and PAS but not regulate. Daniel Karrenberg has written a draft that lists the possible implications: If customers receives PAS they may have to renumber when they change service provider. If they receives PIS the addresses might not be routable in the future. There must be a clear contractual agreement between customers and registries, when registries assign PAS. The IANA has been asked to circulate this draft. Questions, Comments: Suggestion: RIPE should provide recommendation about prefix length. It is not clear yet where the boundary between PIS and PAS will be (/19?). PAS must be easy to renumber (rather short prefix). But this issue needs more discussion in the Local IR group. Comment against recommendation: The recommended prefix length will probably change over the time. A recommendation would produce false security. DFK: This has to be clear in the recommendation. Q: Problem with large multinational organisations that contact varies last resort registries to request address space. A clear statement or recommended guidelines from RIPE is needed. A: The basic principle is already included in ripe-104: If the multinational organisation is connected only in one place, addresses should be received from this one service provider. If the multinational organisation is connected in varies places/countries it should receive address space from these different service providers. The problem is rather that it is easier for these organisations to ask for small amounts of addresss space at different registries than for a large amount of address space at one place. It is easier to provide an addressing plan for small parts of a network than for the whole network. There is no clear procedure how this can be prevented apart from being careful and asking carefully for detailed documentaion. Q: Can't the RIPE NCC make a clear recommendation that these kind of organisations should contact the RIPE NCC for address space? A: There are clear guidelines in ripe-104: 4. Organisations operating a network which spans several countries may obtain address space from a service provider, the RIPE NCC, or the global NIC, as is appropriate to their network confi- guration. In many cases it will be best to obtain addresses for the whole network from the provider operating the main connection of the multi-national network to the Internet. When in doubt, contact the RIPE NCC for guidance. 9.2. DB issues On the last RIPE Meeting it has been agreed that the technical contact in an object can also be a role, e.g. a NIC instead of a person. Harvard Eidnes has written a draft about tyhis issue and circulated to the local-ir mailing list in advance to the 21. RIPE Meeting. 9.3. Reverse Domains The group endorsed the recommendation of the DNS WG that the reverse domains of connected IP networks be name served. *Action Mirjam Kuehne and Anne Lord: to incorporate strong recommendation regarding reverse DNS in training materials. ------- End of Forwarded Message