- lir-wg - mailman.ripe.net

May 17 Task Force Findings / Recommendations
by Stephen Burley 05 Sep '00

05 Sep '00

May 17 WG Meeting, 07/21/2000 Proposed Agenda: 1. Scope and goal of discussion 2. Description of current procedures for obtaining address space, assignment windows, approvals 3. New LIR growth 4. Assignment window 5. Response time and emergency measures 6. Usage Criteria 7. Category priorities 8. accessibility and communication 9. tools List of attendees Nurani Joao Anne Wilfred Stephen Barbara Daniel Sabine Gert 1. Scope and goals of discussion Propose changes to policies and procedures for address assignments to ultimately be submitted to LIR WG, with the clarification of best practices and tangible steps to achieving those goals. This group will not determine how RIPE NCC internally achieves those goals. 2. Current status of procedures a. Process includes sanity checks that may be delegated to LIRs b. Previously no automatic review of Assignment window, now auto reminders in place, made difficult by no flagging of good/bad tickets, no record of why assignment window was denied i.e.. The quality of the LIR requests will be flagged so a more informed decision of the AW status can be made. c. Wait queue due mostly to under staffing combined with significant increase in new LIR growth. d. Improving ripe-141 instructions (ripe-185) may cut down on common time-consuming errors. Although the form provides the hostmasters with enough detail to approve/decline a request it is very sparse on helpful comments for the engineer/customer filling in the details. 3. New LIRs a. Nurani provided information on how many new LIRs are being added, current rate is ~80/month b. Who is becoming an LIR? Should we actively discourage LIR's some how? Raise the setup fee? See 3d. c. LIRs are coming in a at a much faster rate than previously, ask RIPE to review resources consumed in supporting LIRs and whether it would be appropriate to create a specialized group for dealing with LIR applications, education, etc. d. Also, review new LIR fees to see if they cover resources consumed by the application and education process, a new LIR takes up more time and resources than does a large well established registry with experienced Hostmaster. But this creates a problem when the same country with more than one registry uses the same engineers how do you justify charging them more? and how do you track the experienced engineers, we could end up creating a market for exirienced RIPE hostmasters. 4. Assignment window a. Safety net would provide a certain measure of business performance, problem is that safety nets can be abused if not implemented properly. b. Flexible assignment window offers more security from abuse and a traceable audit. c. This becomes a problem of registration accuracy and address conservation, random audits difficult to perform. d. Consensus is that some process of flexible assignment windows will be appropriate to implement but it will have an upper limit. e. Run the db audit at the time of the assignment window increase, with all errors fixed for qualification. This would take the place of audits at each assignment approval request. This could also be part of the LIR's responsibility to provide a valid clean audit, rather than the hostmaster running it. It is also a measure of whether they are really competent and deserve a larger AW. 5. Category priorities: should different categories of request have different priorities in the queue? i.e. contact requests are not the same as IP requests but how do you decide how important each type is? a. once we reach our goal of having a reasonable wait queue, this issue becomes moot. b. if we reach a point where queue exceeds maximum point, then prioritization becomes useful. c. should be looked at in conjunction with response time measures. 6. Accessibility a. Phone help desk runs into problems of accessibility for language and cost factors b. Possible to set up email help desk as a test mode, possibly a three month trial c. Translation of ripe-142 and ripe-185 and other supporting address space documents to other languages to improve communication and education for LIRs. 7. Response time a. Flexible assignment windows when acceptable limit is exceeded. b. When a ticket is in the queue for longer than the target RTT, then certain simplification efforts would kick in. These could be with multiple levels of intervention, and could be invisible to the LIR as a separate process. c. Once a ticket hits the maximum RTT, a special response would occur, which would be marked as unique and auditable and the special response should be capped at a certain level (e.g. /22, or number of approvals per LIR, or other set criteria) d. RTT is defined as getting meaningful response from hostmaster (the initial human response) to ticket request, and should apply for each iteration of reply, not for overall ticket assignment e. The limiting criteria can be described as: Response times. 1-2 days - Normal and acceptable 3-4 days - Request simplification processes put in place. Or AW +1 applied on temp basis below /22 5+ days - Auto approval with auditable response on all requests in queue over 4 days up to /22 8. Usage Criteria /20 criteria a. When an LIR gets a /20 as an initial allocation, they may run into a utilization issue at the 80% mark (12.8 used, 3.2 available) with one customer able to eat this space up an LIR could end up with no IP's to assign till more allocated. Again this is only with a high wait queue once the queue is under control this also becomes moot. b. Proposal is that if the growth is happening in a very short amount of time, the utilization level could be set at an amount smaller than 80%, offering a buffer for growth. So if an LIR can show fast take up at less than 80% the rest of the /19 will be allocated. 9. Tools a. db audit tool for LIRs to run before submitting requests for allocations thus removing the need for Hostmasters to run exhaustive audits when the problems are caused by the LIR. In other words get your house in order before even coming back to RIPE NCC for more space. b. Improved user interface to forms such as the 141 syntax checker. 10. Feedback useful for evaluating the changes proposed are the collection of statistics regarding IP assignments, LIR growth, and other elements impacting this process. This should be done on a continuous basis with a web page resource for the community. 11. We will distribute minutes to the TF, then distribute them to the LIR WG and we will prepare a presentation for the September RIPE NCC meeting. Your Fellow RIPE Members May17TF

1 0

Address Space Waiting Time...
by Feico Dillema 04 Sep '00

04 Sep '00

Hello, I filed a first request for address space for a new LIR about a week ago. Ticket number is NCC#2000085969 and it's still in the waiting queue. Can any of you give me a hint on what the average queuing time is at the moment? My boss is getting a bit nervous as it is on the critical path for meeting some deadlines, and I'd like to be able to tell him whether he can relax or should panic... Thanks, Feico.

3 3

asused question
by Abdullah Saad Al-Ashry 04 Sep '00

04 Sep '00

Hi, When I use the utility "asused" ftp://ftp.ripe.net/tools/asused-3.5.tar.gz It gives me this warning: **************** Please check the following WARNINGS: 212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached **************** Could anybody explain this. Regards; ---------------------------------------------------------------------- Abdullah Saad M. Al-Ashry Al Faisaliah Internet Services and Technology Est. (AwalNet) Tel: +966-1-4600111 x 311 Fax: +966-1-4601110

3 2

Re: ripe-db question
by Christian Storch 02 Sep '00

02 Sep '00

You're right! That number space wasn't registrated at RIPE - you have to look at ARIN: http://www.arin.net/cgi-bin/whois.pl?queryinput=NETBLK-SPRINT-CDF4C7 The AS of omnitel looks like the first upstream provider of Omnitel was SprintLink (USA) and the second is Telianet (Sweden). So the address space 205.244.196.0/24 seems to be registrated by SprintLink at ARIN. Later it becomes an LIR at RIPE and so on... So I think for that you would have to ask all RIR's for your purpose: RIPE, ARIN and APNIC. And you won't get always the right answer for your geographical question I think. Christian ---------- | Von: Andrius Kasparavicius <andrius(a)andrius.org> | An: Christian Storch <storch(a)infra.net> | Cc: 'mediaWays Hostmaster' <hostmaster(a)mediaways.net>; lir-wg(a)ripe.net; db-wg(a)ripe.net | Betreff: RE: ripe-db question | Datum: Samstag, 2. September 2000 14:01 | | On Wed, 30 Aug 2000, Christian Storch wrote: | | > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. | > - Perhaps that page could solve your question. | | hmm, look at lt.Omnitel: | lt.omnitel (OMNITEL Net) | 19951120 194.176.32/19 ALLOCATED PA | 19971010 195.22.160/19 ALLOCATED PA | 19990913 212.47.96/19 ALLOCATED PA | | querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 | | route: 205.244.197.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | route: 205.244.196.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva(a)kaunas.omnitel.net 19970605 | source: RIPE | | | it mean's that in allocation list, is not all ip blocks allocated to | LIR's. Why? | | Andrius

1 0

RE: ripe-db question
by Christian Storch 02 Sep '00

02 Sep '00

Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. - Perhaps that page could solve your question. regards, Christian //========================== // Christian Storch // InfraNet AG // Niederlassung Muenchen // Hansastr. 136 // D-81373 Muenchen // phone: +49 89 743523-55 // fax: +49 89 743523-23 // E-mail: storch(a)infra.NET //========================== -----Original Message----- From: mediaWays Hostmaster [SMTP:hostmaster@mediaways.net] Sent: Wednesday, August 30, 2000 4:24 PM To: lir-wg(a)ripe.net; db-wg(a)ripe.net Subject: ripe-db question Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

2 1

ripe-db question
by mediaWays Hostmaster 02 Sep '00

02 Sep '00

Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

7 8

IAB/IESG Recommendations on IPv6 Address Delegation
by Fred Baker 01 Sep '00

01 Sep '00

Folks: The RIR community asked the IETF community for advice regarding the assignment of IPv6 prefixes to service providers and edge networks, both with a view to topological address assignment and to multihomed networks. The IPv6 Directorate prepared a statement, which the IESG and IAB have reviewed and approved. This is attached. I trust that this answers the questions you asked, and serves as a basis for IPv6 deployment in the near term. If you have questions or issues concerning it, I would suggest that you address them to the IPv6 Directorate copying the IESG and IAB. We intend to publish an Informational RFC in the near future documenting the contents of this note. Fred Baker ----------------------------------------------------------------------- IAB/IESG Recommendations on IPv6 Address Allocations September 1, 2000 Introduction During a discussion between IETF and RIR experts at the Adelaide IETF, a suggestion was made that it might be appropriate to allocate /56 prefixes instead of /48 for homes and small businesses. However, subsequent analysis has revealed significant advantages in using /48 uniformly. This note is an update following further discussions at the Pittsburgh IETF. This document was developed by the IPv6 Directorate, IAB and IESG, and is a recommendation from the IAB and IESG to the RIRs. Background The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On the one hand, when managing the use of a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as precious a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies. The IETF makes no comment on business issues or relationships. However, in general, we observe that technical delegation policy can have strong business impacts. A strong requirement of the address delegation plan is that it not be predicated on or unduly bias business relationships or models. The IPv6 address, as currently defined, consists of 64 bits of "network number" and 64 bits of "host number". The technical reasons for this are several. The requirements for IPv6 agreed to in 1993 included a plan to be able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split effectively accomplishes this. Procedures used in host address assignment, such as the router advertisement of a network's prefix to hosts [RFC 2462], which in turn place a locally unique number in the host portion, depend on this split. Examples of obvious choices of host number (IEEE Mac Address, E.164 number, E.214 IMSI, etc) suggest that no assumption should be made that bits may be stolen from that range for subnet numbering; current generation MAC layers and E.164 numbers specify up to 64 bit objects. Therefore, subnet numbers must be assumed to come from the network part. This is not to preclude routing protocols such as IS-IS level 1 (intra-area) routing, which routes individual host addresses, but says that it may not be depended upon in the world outside that zone. The IETF has also gone to a great deal of effort to minimize the impacts of network renumbering. None-the-less, renumbering of IPv6 networks is neither invisible nor completely painless. Therefore, renumbering should be considered an acceptable event, but to be avoided if reasonably avoidable. The IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48 bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities. It is not obvious, however, that all edge networks are likely to be recursively subnetted; an individual PC in a home, or a single cell in a mobile telephone network, for example, may or may not be further subnetted (depending whether they are acting as, e.g., gateways to personal, home, or vehicular networks). When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64 bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home and vehicle networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. Note that in the mobile environment, the device connecting a mobile site to the network may in fact be a third generation cellular telephone. In other words the subscriber allocation unit is not always a host; it is always potentially a site. Address Delegation Recommendations The RIR communities, with the IAB, have determined that reasonable address prefixes delegated to service providers for initial allocations should be on the order of 29 to 35 bits in length, giving individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber networks. Allocations are to be given in a manner such that an initial prefix may be subsumed by subsequent larger allocations without forcing existing subscriber networks to renumber. We concur that this meets the technical requirement for manageable and scalable backbone routing while simultaneously allowing for managed growth of individual delegations. The same type of rule could be used in the allocation of addresses in edge networks; if there is doubt whether an edge network will in turn be subnetted, the edge network might be encouraged to allocate the first 64 bit prefix out of a block of 8..256, preserving room for growth of that allocation without renumbering up to a point. However, for the reasons described below, we recommend use of a fixed boundary at /48 for all subscribers except the very largest (who could receive multiple /48's), and those clearly transient or otherwise have no interest in subnetting (who could receive a /64). Note that there seems to be little benefit in not giving a /48 if future growth is anticipated. In the following, we give the arguments for a uniform use of /48 and then demonstrate that it is entirely compatible with responsible stewardship of the total IPv6 address space. The arguments for the fixed boundary are: - only by having an ISP-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets. - to enable straightforward site renumbering, i.e., when a site renumbers from one prefix to another, the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site). - there are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.) - to allow easy growth of the subscribers' networks -- no need to keep going back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough). - remove the burden from the ISPs and registries of judging sites' needs for address space, unless the site requests more space than a /48, with several advantages: - ISPs no longer need to ask for details of their customers' network architecture and growth plans - ISPs and registries no longer have to judge rates of address consumption by customer type - registry operations will be made more efficient by reducing the need for evaluations and judgements - address space will no longer be a precious resource for customers, removing the major incentive for subscribers to install v6/v6 NATs, which would defeat the ability of IPv6 to restore address transparency. - to allow the site to maintain a single reverse-DNS zone covering all prefixes. - If and only if a site can use the same subnetting structure under each of its prefixes, then it can use the same zone file for the address-to-name mapping of all of them. And, using the conventions of RFC 2874, it can roll the reverse mapping data into the "forward" (name-keyed) zone. Specific advantages of the fixed boundary being at /48 include - to leave open the technical option of retro-fitting the GSE (Global, Site and End-System Designator, a.k.a "8+8") proposal for separating locators and identifiers, which assumes a fixed boundary between global and site addressing at /48. Although the GSE technique was deferred a couple of years ago, it still has strong proponents. Also, the IRTF Namespace Research Group is actively looking into topics closely related to GSE. It is still possible that GSE or a derivative of GSE will be used with IPv6 in the future. - since the site local prefix is fec0::/48, global site prefixes of /48 will allow sites to easily maintain a simple 1 to 1 mapping between the global topology and the site local topology in the SLA field. - similarly, if the 6to4 proposal is standardized, migration from a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix will be simplified if the native prefix is /48. Note that none of these reasons imply an expectation that homes, vehicles, etc. will intrinsically require 16 bits of subnet space. Conservation of Address Space The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the Aggregatable Global Unicast Address (TLA) format prefix actually contains 45 variable bits, i.e., the number of available prefixes is 2**45 or about 35 trillion (35,184,372,088,832). If we take the limiting case of assigning one prefix per human, then the utilization of the TLA space appears to be limited to approximately 0.03% on reasonable assumptions. More precisely, - RFC 1715 defines an "H ratio" based on experience in address space assignment in various networks. Applied to a 45 bit address space, and projecting a world population of 10.7 billion by 2050 (see http://www.popin.org/pop1998/) the required assignment efficiency is log_10(1.07*10^10) / 45 = 0.22. This is less than the efficiencies of telephone numbers and DECnetIV or IPv4 addresses shown in RFC 1715, i.e., gives no grounds for concern. - We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, we have reserved more than 85% of the address space (i.e., the bulk of the space not under the Aggregatable Global Unicast Address (TLA) format prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. - For transient use by non-routing hosts (e.g., for stand-alone dial-up users who prefer transient addresses for privacy reasons), a prefix of /64 might be OK. But a subscriber who wants "static" IPv6 address space, or who has or plans to have multiple subnets, ought to be provided with a /48, for the reasons given above, even if it is a transiently provided /48. To summarize, we argue that although careful stewardship of IPv6 address space is essential, this is completely compatible with the convenience and simplicity of a uniform prefix size for IPv6 sites of any size. The numbers are such that there seems to be no objective risk of running out of space, giving an unfair amount of space to early customers, or of getting back into the over-constrained IPv4 situation where address conservation and route aggregation damage each other. Multihoming Issues In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing tables will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG working group. Until existing or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6. Key characteristics of an ideal multi-homing proposal include (at minimum) that it provides routing connectivity to any multi-homed network globally, conserves address space, produces high quality routes at least as well as the single-homed host case previously discussed via any of the network's providers, enables a multi-homed network to connect to multiple ISPs, does not inherently bias routing to use any proper subset of those networks, does not unduly damage route aggregation, and scales to very large numbers of multi-homed networks. One class of solution being considered amounts to permanent parallel running of two (or more) prefixes per site. In the absence of a fixed prefix boundary, such a site might be required to have multiple different internal subnet numbering strategies, (one for each prefix length) or, if it only wanted one, be forced to use the most restrictive one as defined by the longest prefix it received from any of its ISPs. In this approach, a multi-homed network would have an address block from each of its upstream providers. Each host would either have exactly one address picked from the set of upstream providers, or one address per host from each of the upstream providers. The first case is essentially a variant on RFC 2260, with known scaling limits. In the second case (multiple addresses per host), if two multi-homed networks communicate, having respectively m and n upstream providers, then the one initiating the connection will select one address pair from the n*m potential address pairs to connect from and to, and in so doing will select the providers, and therefore the applicable route, for the life of the connection. Given that each path will have a different ambient bit rate, loss rate, and delay, if neither host is in possession of any routing or metric information, the initiating host has only a 1/(m*n) probability of selecting the optimal address pair. Work on better-than-random address selection is in progress in the IETF, but is incomplete. An existence proof exists in the existing IPv4 Internet that a network whose address is distinct from and globally advertised to all upstream providers permits the routing network to select a reasonably good path within the applicable policy. Present-day routing policies are not QoS policies but reachability policies, which means that they will not necessarily select the optimal delay, bit rate, or loss rate, but the route will be the best within the metrics that are indeed in use. One may therefore conclude that this would work correctly for IPv6 networks as well, apart from scaling issues. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Fred Baker | 519 Lado Drive IETF Chair | Santa Barbara California 93111 www.ietf.org | Desk: +1-408-526-4257 | Mobile: +1-805-886-3873 | FAX: +1-413-473-2403

1 0

Tips for IP and AS Requests!
by Nurani Nimpuno 01 Sep '00

01 Sep '00

Dear all, We are happy to announce our new "TIPS" page on the RIPE NCC website! The RIPE NCC hostmasters have put together a clear, concise and comprehensible list of tips useful to LIRs when requesting Address Space and Autonomous System Numbers from the RIPE NCC. The TIPS page can be reached from our main page and can be found at: http://www.ripe.net/ripencc/tips/tips3.html This is one of several steps we are taking in improving the documentation on our website, making vital information more comprehensible and accessible to our members. We hope this is useful to you in your communication with the RIPE NCC! Kind regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC

1 0

Tips for IP and AS Requests!
by Nurani Nimpuno 01 Sep '00

01 Sep '00

Dear all, We are happy to announce

1 0

ANNOUNCEMENT: Release of stt2
by Maldwyn Morris 01 Sep '00

01 Sep '00

Hi, The RIPE NCC are pleased to announce the release of stt2. Stt2 is a tool that uses templates to produce customised standard emails. These templates may also contain Perl code to produce the email text and perform other actions. The standard usage is to produce a reply to the current message using the template specified. stt2 is a complete re-write of stt. The main changes are: * It is now a Perl 5 program, * It uses standard CPAN modules where possible * One can use modules in the templates * There is new variable type, VARMULTI * One can restrict editing to just the text part of a template The software is written in standard Perl 5 and uses several standard CPAN modules. It uses and requires MH. It was written and tested on BSD/OS 3.1, and due to OS dependencies, will probably not work on other OSes. We welcome patches for other OSes. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/stt2.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. We are keen to receive your feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn(a)ripe.net Software Manager RIPE NCC

1 0