February 2001 - lir-wg - mailman.ripe.net

RE: IP Management Tool - Minimum Requirements
by Arif OKTAY 26 Feb '01

26 Feb '01

Hi all, I was thinking whether it may be possible -usefull ?- to add some criteria for how succesfull the adress space managed. Regards, arif ao189-ripe -----Original Message----- From: Guy Vegoda To: lir-wg(a)ripe.net Sent: 2/26/01 1:50 PM Subject: Re: IP Management Tool - Minimum Requirements Other than adding that it should be useable simulteniously by multiple users without data corruption, shall I go away and write it now? Guy (Since no one else seems interested) > Hi, > > Following a presentation of an IP Management Tool by Guy Vegoda at the > last RIPE Meeting Tools BOF, interest was expressed in the development > of an Open Source version of such a tool and I agreed to use the lirwg > list to try and draw up Requirements for this. Hopefully this can be > refined into something that we can then begin writing Specifications > for. > > Please remember that these are *Requirements* - i.e. what the users > want the tool to do. Please confine remarks to this area and avoid > mixing in the *Specifications* - i.e. how those requirements will be > met - which we will come to, in good time. > > It should also be emphasised that we would at this stage like to > concentrate on _minimum_ requirements for a simple tool, such that it > would be useful to a large number of LIRs. I think we can use these > Minimum Requirements to produce something that may or may not include > more advanced features as well, knowing that we would at least have > covered the basic needs. > > Comments on this process and the document are most welcome, and > we would also like a good name. > > Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in > drawing up this document, and especially to Guy for presenting his > tool. > > Cheers, > > Maldwyn Morris > Software Manager > RIPE NCC > > -- > > Minimum Requirements for an IP Management Tool > ---------------------------------------------- > > 0. Introduction > > Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 > [1]. This document is an attempt to specify the minimum requirements > for a similar tool, with the aim of producing an Open Source version > for anyone who wants to use it. > > Below, I address 1. General Points about the project, 2. The > Requirements themselves, 3. External Constraint that must be > considered, and 4. A list of References. > > > 1. General Points > > Name: > > Let's use IPMT ( IP Management Tool ) as a placeholder for now. > > Users: > > We will target as users 'The Hostmaster staff of Local Internet > Registries which are Customers of the RIPE NCC and who need to manage > their IP Allocations and Assignments and the requests for same that > they send to the RIPE NCC' [phew]. We will call one of these people a > 'LIRHostmaster' and their organisation an 'LIR'. It may also be > useful to other people in other organisations to do other things, but > that will not influence the requirements. > > Open Source: > > We will release this software under the LGPL licence [2]. > We use this instead of GPL [3] because this means we will remain able > to using non-GPL'ed libraries, should that prove necessary. > > The RIPE NCC is happy to support this project, but of course its Open > Source nature means anyone else can use the code to begin their own > Open Source project. We are also happy about that. > > IPV6: > > We would be foolish not to consider the possibility of using this tool > for managing IPV6 addresses and writing it such that this is possible, > but we think it will be useful even if it does not and do not consider > IPV6 support a requirement. > > > 2. Requirements > > General functionality: > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 allocations. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should provide the LIRHostmasters with list, create, update, and > delete access to information regarding their LIR's IPV4 assignments. > These actions must be undoable where necessary. > Basic validity checks will be performed on all input. > > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > IPMT should allow LIRHostmasters to send well-formatted email requests > for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters > to receive and process responses from the RIPE NCC. > > User Interface: > > LIRHostmasters should be able to conveniently access IPMT functions > from a wide range of Desktop Operating Systems, possibly including > non-modern, non-Unix-like ones. A GUI interface is the minimal > acceptable convenience level. > > A less-convenient interface to IPMT for more complex functions and > administration is acceptable. > > > 3. External constraints > > The RIPE NCC only accepts requests for new IPv4 Assignments and > Allocations via email to hostmaster(a)ripe.net and replies only via > email [4]. > > IPV4 Assignment requests must be in RIPE 141 format [5]. > Requests for new IPV4 Allocations have no special format. > > LIRHostmasters handle customer requests for Assignments via telephone, > email and web pages. > > IPMT must have access to the RIPE DB [6] or a local mirror thereof. > > > 4. References > > [1] http://www/ripe/meetings/archive/ripe-38/index.html > [2] http://www.gnu.org/copyleft/lesser.html > [3] http://www.gnu.org/copyleft/gpl.html > [4] http://www.ripe.net/ripencc/mem-services/registration/status.html > [5] http://www.ripe.net/ripe/docs/ripe-141.html > [6] http://www.ripe.net/ripencc/pub-services/db/ > > -- Guy Vegoda \ guy(a)vegoda.org *Please do not send html* NIC: GUY-RIPE \ guy(a)cryptography.org.uk *attachments* Unix, Linux Hobbyist \ +44(0)20 7961 8318 (work) www.thenakedfrenchman.com \ +44(0)958 469 532 (cell)

2 1

IP Management Tool - Minimum Requirements
by Maldwyn Morris 26 Feb '01

26 Feb '01

Hi, Following a presentation of an IP Management Tool by Guy Vegoda at the last RIPE Meeting Tools BOF, interest was expressed in the development of an Open Source version of such a tool and I agreed to use the lirwg list to try and draw up Requirements for this. Hopefully this can be refined into something that we can then begin writing Specifications for. Please remember that these are *Requirements* - i.e. what the users want the tool to do. Please confine remarks to this area and avoid mixing in the *Specifications* - i.e. how those requirements will be met - which we will come to, in good time. It should also be emphasised that we would at this stage like to concentrate on _minimum_ requirements for a simple tool, such that it would be useful to a large number of LIRs. I think we can use these Minimum Requirements to produce something that may or may not include more advanced features as well, knowing that we would at least have covered the basic needs. Comments on this process and the document are most welcome, and we would also like a good name. Thanks to Guy Vegoda, Leo Vegoda and Nigel Titley for their help in drawing up this document, and especially to Guy for presenting his tool. Cheers, Maldwyn Morris Software Manager RIPE NCC -- Minimum Requirements for an IP Management Tool ---------------------------------------------- 0. Introduction Guy Vegoda presented an IP Management Tool at the Tools BOF at RIPE 38 [1]. This document is an attempt to specify the minimum requirements for a similar tool, with the aim of producing an Open Source version for anyone who wants to use it. Below, I address 1. General Points about the project, 2. The Requirements themselves, 3. External Constraint that must be considered, and 4. A list of References. 1. General Points Name: Let's use IPMT ( IP Management Tool ) as a placeholder for now. Users: We will target as users 'The Hostmaster staff of Local Internet Registries which are Customers of the RIPE NCC and who need to manage their IP Allocations and Assignments and the requests for same that they send to the RIPE NCC' [phew]. We will call one of these people a 'LIRHostmaster' and their organisation an 'LIR'. It may also be useful to other people in other organisations to do other things, but that will not influence the requirements. Open Source: We will release this software under the LGPL licence [2]. We use this instead of GPL [3] because this means we will remain able to using non-GPL'ed libraries, should that prove necessary. The RIPE NCC is happy to support this project, but of course its Open Source nature means anyone else can use the code to begin their own Open Source project. We are also happy about that. IPV6: We would be foolish not to consider the possibility of using this tool for managing IPV6 addresses and writing it such that this is possible, but we think it will be useful even if it does not and do not consider IPV6 support a requirement. 2. Requirements General functionality: IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 allocations. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should provide the LIRHostmasters with list, create, update, and delete access to information regarding their LIR's IPV4 assignments. These actions must be undoable where necessary. Basic validity checks will be performed on all input. IPMT should allow the LIRHostmasters to receive requests for IPV4 assignments from the customers of their LIR and allow them to process them. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 assignments to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. IPMT should allow LIRHostmasters to send well-formatted email requests for new IPv4 allocations to the RIPE NCC and allow the LIRHostmasters to receive and process responses from the RIPE NCC. User Interface: LIRHostmasters should be able to conveniently access IPMT functions from a wide range of Desktop Operating Systems, possibly including non-modern, non-Unix-like ones. A GUI interface is the minimal acceptable convenience level. A less-convenient interface to IPMT for more complex functions and administration is acceptable. 3. External constraints The RIPE NCC only accepts requests for new IPv4 Assignments and Allocations via email to hostmaster(a)ripe.net and replies only via email [4]. IPV4 Assignment requests must be in RIPE 141 format [5]. Requests for new IPV4 Allocations have no special format. LIRHostmasters handle customer requests for Assignments via telephone, email and web pages. IPMT must have access to the RIPE DB [6] or a local mirror thereof. 4. References [1] http://www/ripe/meetings/archive/ripe-38/index.html [2] http://www.gnu.org/copyleft/lesser.html [3] http://www.gnu.org/copyleft/gpl.html [4] http://www.ripe.net/ripencc/mem-services/registration/status.html [5] http://www.ripe.net/ripe/docs/ripe-141.html [6] http://www.ripe.net/ripencc/pub-services/db/

3 2

Re: Fixed Boundary (/29) Assignments
by Judith Heffernan 18 Feb '01

18 Feb '01

As an employee of a large broadband provider, I agree with the recommendation of allowing ISPs the ability to provide residential subscribers multiple IP addresses without having the subscriber provide usage-based requirements. It doesn't scale to extend the rules that apply to commercial end users to residential subscribers. This would be equivalent to a tier 1 ISP having to manage the justification of IP address requests of 3million tier 2 ISPs. It doesn't scale. The subscriber should not just be assigned /29 worth of address space when they sign up for the service whether they need it or not. However, if the subscriber sign's up for the service requesting 2 or 3 CPE addresses, they shouldn't have to submit a RIPE-141 form or provide some other justification. It should simply be a service that the ISP can provide. We have many subscribers with multiple CPE addresses - however, that doesn't necessarily mean they have their own subnet. In a broadband cable environment, the subscribers off of the same downstream shares the same broadcast domain. The downstream is assign /24 which the subscribers are addressed out of. A subscriber with two CPE's may not have consecutive IP addresses. Would this mean the subscriber would have to register each /32? Or that the ISP has to ensure that the subscriber gets consecutive addresses (that would be a huge operational overhead for the ISP). The ISP should be responsible of ensuring the /24 is being effectively utilized. And this can be done the same way it is today for one CPE as it can for multiple. -Judith

2 1

RIPE: last call for comments RPSL transition
by SchmitzJo＠aol.com 17 Feb '01

17 Feb '01

Hello all, as you are aware, we are preparing the migration of the RIPE database software to support and deploy the new RPSL format. The required steps have been discussed in depth on various occassions (for references, see end of mail). We are now preparing the most important step, really transitioning from old RIPE-181 to new RPSL format: proposed transition date is 23-Apr-2001. This step, once taken, will not be reversed. The majority of the user community takes a neutral role, while some want an earlier, and a few a later date for migration. During the joint session of Routing and DB WG at RIPE38, the chairmen of both WGs were tasked to file a last call for comments on that date, in particular whether there are serious, unresolvable technical or operational problems which would benefit from a slightly longer warning period. According to consensus at the session: If you are convinced that the transition date as proposed would lead to significant operational problems, please explain and justify why within the next 2 weeks: deadline for transition comments: 1-Mar-2001 Only well founded reasoning (including an educated guess about the time and resources required to resolve the issue) shall be accepted by the community in order to consider postponing the transition. With the discussion about the migration going on for quite some time, and information available from various places, we do not expect a delay, but we would want to give everybody a last opportunity to comment. To summarize the dates, we are looking at: o 23-Apr-2001: switching to the RPSL database - All objects are automatically converted to RPSL format - Queries return RPSL only - Mirroring follows new format and rules at whois.ripe.net, port 4444 - RPSL formatted updates can be submitted to auto-rpsl(a)ripe.net - RIPE-181 updates are still accepted at auto-dbm(a)ripe.net, but are autmatically converted to RPSL - RFC2725 (Routing Policy Security System) rules apply throughout o 14-May-2001: exchanging mail addresses for submitting RIPE181 and RPSL- formatted updates - auto-dbm(a)ripe.net only accepts RPSL updates - RIPE-181 updates are still possible but now go to auto-181(a)ripe.net and are automatically converted to RPSL (again, RFC2725 rules apply here as well) o 15-Oct-2001: RIPE-181 updates are no longer accepted For further reading, please refer to the migration web page http://www.ripe.net/rpsl or for the discussion during the joint session of the DB/Routing WGs please review the minutes. For technical specifications of RPSL please refer to - rfc2622: "Routing Policy Specification Language (RPSL)" Status: PROPOSED STANDARD, - rfc2650: "Using RPSL in Practice" Status: INFORMATIONAL - rfc2725: "Routing Policy System Security" Status: PROPOSED STANDARD Thanks a lot - the RIPE NCC and the chairmen of Routing: Joachim Schmitz DB: Wilfried Woeber LIR: Hans Peter Holen

1 0

SV: Fixed Boundary (/29) Assignments
by Bjarne Carlsen 13 Feb '01

13 Feb '01

> -----Oprindelig meddelelse----- > Fra: Randy Bush [SMTP:randy@psg.com] > Sendt: 9. februar 2001 15:16 > Til: Bjarne Carlsen > Cc: lir-wg(a)ripe.net > Emne: RE: Fixed Boundary (/29) Assignments > > are we? we see folk using dsl at t1 rates to replace p2p t1 lines because > it's a very different cost for the circuit. (here, t1 is expensive and > dsl > is based on old alarm circuit tarrifs) [Bjarne Carlsen] OK - in other words, you don't even see the small difference, that I see on this side of the pond.. > just to push this to the limit. in the states, we usually have free local > dialup. so we have analog "nail up" customers, i.e. they stay dialed up > 7x24. it's just another form of p2p dedicated circuit. and, as far as > address allocation policy goes, treat them the same as an OC12 customer, > they justify what address space they need. [Bjarne Carlsen] Yes, but make it somehow easier for them, since there is one significant difference between private an corporate customers, (at least as seen from this little backwater), namely that the corporate customer usually understands the technical jargon used in documents like RIPE-141 and the private customer invariably says "Huh, er... what is an IP-address??" /Bjarne

8 8

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

1 0

Re: Policy and PR problem
by Marco Davids 13 Feb '01

13 Feb '01

On Tue, 13 Feb 2001, Hans Petter Holen wrote: > -"it is currently very difficult to get IP address space" and as a result of > that we have to plan complex network solutions with a combination of private > and public addresses. > > This claim is very different from the one I tend to make: "you get the > addresses you need as long as you can provide documentation that you realy > need them". I agree with that, although I use to have a hard time convincing my manager to come up with copy's of invoice and all kinds of other 'strategic' information to proof to RIPE that we really needed the IP-space that was required by that time. I wonder what RIPE does with all this information? I trust they destroy it, after the IP-request has been approved? And how about returning IP-space? The procedures there are not very clear to me (except for the case when the LIR does not pay its fee). Can allocated address-blocks for example be transferred to another party without mediation of RIPE after a merge of company's or something of that kind? Cheers, -- Marco

2 1

Re: Policy and PR problem
by Wilfried Woeber, UniVie/ACOnet 13 Feb '01

13 Feb '01

Hi Nurani, Thanks for your comments, and I agree that your "the Hostmaster Role's" point of view is of interest of course, eventually, but that the community still has to do a bit more thinking and brain-storming before we can wrap up. >However, what I can say is that we at the RIPE NCC are very aware of >how complicated it is for new LIRs to learn all policies and >procedures involved in obtaining IP address space and AS numbers. >(And indeed there are quite a few.) One of the things that adds to complexity (IMHO) is the fact that the policies (you have to make your needs known, and to do so in a way that can be reviewed) are not clearly separated from the procedures involved. While I think the basic *policy* is more or less straightforward: You get what you need and as much as you can reasonably argue for, and we don't interfere with the engineering approach for your networks by making *policy* that cripples certain design approaches. (With a very few exceptions) We do, however require the applicant to think about alternative approaches, and to make a conscious decision in favour of one or another approach, like rfc1918, http 1.1, ... What indeed has become too complex is the *procedures*. What has been appropriate a few years ago, is not necessarily appropriate any longer for every application everywhere. The Internet has changed a bit. There are more diverse entities active now which have to look at some other boundary conditions in addition to network engineering and address space conservation (as the "only" goal) like size, internal structure, business models, investments, security, helpdesk and customer care issues, and last but not least privacy issues.... >Although it has always been seen as part of the hostmaster role to >educate the LIRs, it is not an easy task with the current dramatic >growth of LIRs. We have partly discussed this with the May 17 >Taskforce and we are also constantly discussing it internally at the >RIPE NCC, trying to find more efficient ways of coping with the >workload and the growth. Indeed. >This may be a PR problem. It is also possible that the policies >simply have become too complicated for new members. (Can it be that >the policies which are developed by experienced and clueful members >of the Internet community is not necessarily easy for newer, less >experienced LIRs?) Is the problem possibly a combination of the two? We should put the effort in dealing with the scaling problem of the *procedures*. While I do not know (and do not want to know) which application made Leo "go public", I would like to report to the community that I had a few very interesting private discussions during the last RIPE Meeting with a sizable company planning the roll-out of a "mass-market" product, and they indeed were a) present at the meeting, and b) had *very* sound questions to ask and were looking for input from the community. So "they" are out there, trying to do "the right thing". But the community should try to understand their position as well, and the scaling problems. Otherwise nobody should be surprised to hear the claims, that it is not possible for them to work with and as part of the "established" community, and that "they" have to build something else that fits their needs.... Wilfried.

1 0

Policy and PR problem
by Hans Petter Holen 13 Feb '01

13 Feb '01

Hi, I am just attending a seminar in Broad band networks, and met again the claim that -"it is currently very difficult to get IP address space" and as a result of that we have to plan complex network solutions with a combination of private and public addresses. This claim is very different from the one I tend to make: "you get the addresses you need as long as you can provide documentation that you realy need them". personally I think that we have a serious PR problem here: is it so that the rules and regulations have become so strict and complicated that we, the lirs, tell our customers that this is very difficult and you should realy use private addresses, rather than explaining how the procedures and policies realy work ? Is this what we want ? -hph

6 6

Re: Policy and PR problem
by Denesh Bhabuta 13 Feb '01

13 Feb '01

At 10:27 13/02/2001, Hans Petter Holen wrote: >personally I think that we have a serious PR problem here: is it so that the >rules and regulations have become so strict and complicated that we, the >lirs, tell our customers that this is very difficult and you should realy >use private addresses, rather than explaining how the procedures and >policies realy work ? IMHO, the main problem seems to be clueless salesmen who do not understand RIPEs procedures, and the clueless product managers who will go and design a solution without knowing what procedures they have to follow or restrictions they have when it comes to IP addresses. This leaves the poor hostmaster trying to explain to the company that it can not do what it wants to do and by then it is almost too late.. advertising etc is all done. What may be worth doing is getting 'salesmen' to go to RIPE training courses - as it is these people who talk to customers directly for that signature on the contract. :) What we need to realise is how companies in this industry conduct business nowadays.. (I am not including those companies who have followed the RIPE rules from time immemorial). I have also already spoken to Axel about RIPE maybe looking at an Outreach program (something that Nominet - the .uk not for profit registry - is doing now)... this will be good for PR. The other aspect I have briefly spoken to Axel about and also to Margriet is how to make the new LIR sign up process less administratively heavy. I am not saying that we change the RIPE NCC we have all come to love over the years.. just that we need to be aware of business in this industry and the way it is going. Regards Denesh -- Denesh Bhabuta Chairman, CEO and Principal Consultant Cyberstrider Limited www.cyberstrider.net Internet and E-Commerce: Strategy, Consultancy and Solutions

1 0