- lir-wg - mailman.ripe.net

Announcement: new procedure for in-addr.arpa reverse delegations
by RIPE NCC IN-ADDR. ARPA Role Account 19 Jun '95

19 Jun '95

Dear all, As of today the RIPE NCC offers an automated method for the submission of reverse zone delegations in 193.in-addr.arpa and 194.in-addr.arpa. Your delegation requests and the zone files on all nameservers will be checked automatically. The diagnostics generated by these checks will be returned to you automatically too. This will make you aware of any problems very quickly, so that you can correct them and re-submit your request. When the automated procedure does not detect any errors, the request is forwarded to the inaddr role account person for some additional manual checks and the processing of the delegation itself. Of course, you will receive an acknowledgement when this has been done. To use the new automated procedure send your request in ripe-105 format to: <auto-inaddr(a)ripe.net> You can use some keywords in the 'Subject:' line of your E-mail to control the checking process. The use of the LONGACK keyword is very recommended. HELP - will send you a (patched) ripe-105 document CHANGE - is needed if you want to change an existing reverse delegation LONGACK - will give you the most verbose output as possible RIPE document ripe-105 requires you to send in a RIPE database 'inetnum' object with a 'rev-srv' attribute for each nameserver for single/multiple C's reverse delegation requests and for whole blocks 'domain' objects with 'nserver' attributes for each nameserver. I recommend to use the following procedure for doing your request: Send an E-mail to <auto-inaddr(a)ripe.net> with LONGACK in the 'Subject:' line and an appropriate RIPE database object as described in ripe-105 in the body of the message. We still accept the old method for reverse delegation requests (ripe-105 format request to <inaddr(a)ripe.net>), however it might take some more time to process them. After some time, when the software doesn't change daily anymore, the source code will be published. I am neither a DNS expert or native English writer ;-) so all your comments are welcome! Please send them together with complaints, bug reports or special requests to <inaddr(a)ripe.net>. Kind regards, David Kessens RIPE NCC

1 0

Minutes of mtg at RIPE 21
by Mike Norris 13 Jun '95

13 Jun '95

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

1 0

message from es.medusa
by RIPE NCC Hostmaster 07 Jun '95

07 Jun '95

Medusa have asked us to make clear to other local IR's that they are not connected with the recent discussions over multiple address space requests from ICL. Their mail is appended below. Anne Lord RIPE NCC ------- Forwarded Message Date: Mon, 22 May 1995 13:18:15 +0100 From: enrique(a)medusa.es (Enrique Garcia Sanchez) To: RIPE NCC Hostmaster <hostmaster(a)ripe.net> cc: otero(a)medusa.es Subject: NCC#950389 Re: Caution: assignments to ICL >This problem does not affect medusa as you are assigning address space >to your customers,=20 Hi,=20 It's good to know this problem does not affect Medusa. The thing is, Medusa is fully identified in Spain with ICL, and this message has arrived to many spanish mailboxes, I suppose. It would be very good for us if you just send a mail to the same people, noting this problem does not affect to Medusa, and we are not "shopping" around with the IP addrress space. I'm sure this is not a problem for you. Thank you very much in advance. ___________________________________________________________________ Enrique Garc=EDa S=E1nchez e_mail: enrique(a)medusa.es Director T=E9cnico MEDUSA tel: +34 (9) 1 3848180 Servicios de Acceso a INTERNET fax: +34 (9) 1 3848210 I.C.L. Espa=F1a S.A. C/Arturo Soria, 245 28033 MADRID SPAIN ___________________________________________________________________ Web Server http://www.medusa.es/ Medusa is member of PIPEX International and RIPE (Reseaux IP Europeen). ------- End of Forwarded Message

1 0

Dalays in RIPE NCC Registration Services
by Daniel Karrenberg 06 Jun '95

06 Jun '95

Dear customers, as some of you will unfortunately have noticed, the response time of the RIPE NCC registration services has increased considerably compared to the very short times most of you were used to. 'Hostmaster' currently has a queue of more than 200 requests, 'in-addr' is above 70. This is mainly due to increased load. 'time permitting' requeste are not processed at all at this time. Please consider the following graph which plots the total number of mesages received by registration services per quarter: 3500++---------------------------------------------------+ | | | A | 3000++ * | | ** | | * | 2500++ * | | *A | | *** | 2000++ *A* | | *** | | *A* | 1500++ *** | | *A* | | ** | 1000++ ** | | ***A | | *A** | 500++ *** | | A* | | | 0++----+-----+-----+-----+-----+-----+-----+-----+----+ Q2/93 Q3/93 Q4/93 Q1/94 Q2/94 Q3/94 Q4/94 Q1/95 Unfortunately during the last 12 months we have not been able to increase staff resources in accordance with expected load because problems with 1994 revenue and the initially unclear revenue situation for 1995 did not allow that. Fortunately we can now be confident again about sufficient revenue and the hiring of three additional staff for registration services has been authorised. We have already signed a contract with a person from Turkey who will start this month, as soon as her visa becomes available. We will hire two more junior hostmasters as quickly as possible drawing from the response from our announcement in March. This step will very quickly more than double the staff time available for registration services. Hiring and training the new staff will take some time. This means we will have to live with larger backlogs and increased response times for some weeks to come. I ask you to bear with us for a few weeks and to show some understanding to NCC registration services staff who are working very hard to process your requests as quickly as possible. We expect to see a gradual improvement during July and to be able to return to our usual level of response times by late August. If you have any further questions, please do not hesitate to contact me. Regards Daniel Karrenberg RIPE NCC Manager

1 0

Re: PI vs PA Address Space
by mak＠aads.net 06 Jun '95

06 Jun '95

At 18:06 5/25/95, Sean Doran wrote: >It's not so much a conspiracy theory as a general wondering >why Kent took the position he did. I like knowing about motivations, >that's all. Call it a hobby. > > Sean. Well Sean, you should know that phone companies are a good place to be right now in terms of rapid Internet development and deployment. However, not all such organizations are perfect. See the latest round of Dilbert strips (the cartoonist apparently works for Pac Bell). Mark

1 0

Local IR Training Course - Registration Closed
by RIPE NCC Training 01 Jun '95

01 Jun '95

Dear Colleagues, Local IR Training Course, Amsterdam, June 26th 1995 The registration for the Local IR Training course has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. Those who were not able to attend this course, will automatically be placed on the waiting list. They will also be given priority for the next course - but will need to re-register to confirm their continued interest in attending. We would still only like one person from any single organisation to register. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to <training(a)ripe.net>. Kind regards, Anne Lord and Mirjam Kuehne RIPE NCC

1 0

AS690 advisories
by Daniel Karrenberg 29 May '95

29 May '95

We have met with both the RA team and ANS last Tuesday. The message below is the result of these discussions. The upshot is: If you want your routes imported by ANS (AS690) you need to now: make sure you have route objects with correct advisory attruibutes in the RADB. Put those advisories in the RIPE RR. after Friday: European route objects can be removed from the RADB. AS690 advisories in the RIPE RR are sufficient to talk to ANS. July: advisory attributes will no longer be needed. This is a little easier as we expected at the RIPE meeting, so I hope everyone is happy. Daniel ------- Forwarded Message Date: Fri, 26 May 1995 16:44:47 -0400 From: Steve Heimlich <heimlich(a)ans.net> To: nanog(a)merit.edu Subject: AS690 use of multiple routing registries Folks, This note outlines changes to the ANS AS690 use of various registries which comprise the Internet Routing Registry (IRR). [RIPE gang, please forward to your mailing lists as appropriate]. Currently, the IRR consists of the following four well-known registries: the RADB, the CA*Net registry, the MCI registry, and the RIPE registry. AS690, to date, has relied exclusively on the RADB for generation of its configurations. As a result, those organizations which would naturally register in the MCI, CA*Net, or RIPE registries have been making redundant registrations in the RADB to ensure connectivity with ANS. This redundant registration has been inconvenient for many, and leads to multiple copies of route objects with inconsistent attributes. As of next week, ANS will begin to use route objects from the CA*Net, MCI, and RIPE routing registries. In order to do this, we will first create an ANS registry (containing customers of ANS) with "source: ANS" as its distinguishing attribute. Beginning with next Wednesday's AS690 config run (changed from Tuesday due to the U.S. Memorial Day holiday), we will prefer routes with AS690 advisories from these registries in the following order: ANS, CA*Net, MCI, and the RADB. Once we verify that this has succeeded, we will include the RIPE registry ahead of the RADB on next Friday's config run (i.e., ANS, CA*Net, MCI, RIPE, RADB). This method for config generation will eliminate the need for multiple registrations of singly-homed routes. Toward the end of June, we expect to have software running which will eliminate the use of AS690 advisories. This software generates an initial policy first by using registered advisories (a one-time operation). Currently, this results in a 16,000 line aut-num object for AS690. As this is somewhat unreasonable, we will be reducing the number of per-network exceptions in favor of one policy per home AS. As we approach the deployment of this capability, we will be working with peer providers on arranging mutually acceptable policies with AS690. Steve ------- End of Forwarded Message

1 0

Re: PI vs PA Address Space
by kwe＠6SigmaNets.com 26 May '95

26 May '95

At 1:16 PM 5/25/95, Sean Doran wrote: >| Without some acceptable terms and conditions on assignment coupled with >| route-ability assurances, there will be too much latitude to screw up >| global routing and the significant risk that someone else will step in to >| help fix the problem in future. > >Are you speaking with your personal hat on, or as a person >contracting for a firm which is busily using its NAP award as >a means of developing business plans on the IP front in direct >competition with what one could perceive as a captive market? > > Sean. (speaking with his personal hat on, and very curious) Yes, I assume everything you post from clock.org is your personal opinion, but I don't think that will stand up in court. Sean, I'll accept this as a fair question even though it has no bearing on the issue I raised. I don't find your question funny or flip. I speak for myself, as my signature attests, and I am consistent in my point of view. I have a lot of personal stake in the Internet, having spent the last decade working on it. I don't want some Senator deciding that we can't manage our own affairs and I wouldn't want to be a stockholder of any publicly traded company that gets sued by some startup for restraint of trade. I'm quite comfortable about my contribution to this discussion, should my words turn up in court. Tie the cannons to the deck and haul up the sail. Let's see just how far we can take this Internet thing without wrecking it. ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~ Kent W. England Six Sigma Networks 1655 Landquist Drive, Suite 100 Voice/Fax: 619.632.8400 Encinitas, CA 92024 kwe(a)6SigmaNets.com ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ [PGP ready] ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~

1 0

Re: PI vs PA Address Space
by Sean Doran 25 May '95

25 May '95

It's not so much a conspiracy theory as a general wondering why Kent took the position he did. I like knowing about motivations, that's all. Call it a hobby. Sean.

1 0

Re: PI vs PA Address Space
by Sean Doran 25 May '95

25 May '95

| Without some acceptable terms and conditions on assignment coupled with | route-ability assurances, there will be too much latitude to screw up | global routing and the significant risk that someone else will step in to | help fix the problem in future. Are you speaking with your personal hat on, or as a person contracting for a firm which is busily using its NAP award as a means of developing business plans on the IP front in direct competition with what one could perceive as a captive market? Sean. (speaking with his personal hat on, and very curious)

2 1