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

First phase of the migration to the new RIPE Database is completed
by DB-News 23 Apr '01

23 Apr '01

Dear Colleagues, The new version of the RIPE Database is now up and running! All objects have been automatically converted to RPSL and loaded into the new version of the Database. The first phase of the migration has been successfully completed. The following mail robots accept updates to the RIPE Database: <auto-dbm(a)ripe.net> - updates are accepted in RIPE-181 format and automatically translated into RPSL. However, several restrictions apply to such updates: empty and misspelled attributes are not allowed, PGP auth is not supported. Also, RPSL authorization rules apply. <auto-rpsl(a)ripe.net> - updates are accepted in RPSL format. This setup will be in place till 14 May, 2001. For more information about the migration please visit http://www.ripe.net/ripencc/pub-services/db/rpsl/announcement.html and http://www.ripe.net/ripencc/pub-services/db/rpsl/index.html Best Regards, Andrei Robachevsky DB Group RIPE NCC

4 4

Migration of the TEST database is completed
by Andrei Robachevsky 20 Apr '01

20 Apr '01

Dear Colleagues, The TEST database has been successfully migrated to v3 software. All objects in the TEST database were converted to RPSL compliant format. You can continue using the TEST database till 14 May as follows: - <test-dbm(a)ripe.net> mail robot accepts updates in RIPE-181 format with some limitations. - <test-rpsl(a)ripe.net> mail robot accepts updates in RPSL format. After that day changes in robots' functionality will follow the plan fro the production database. Please see http://www/ripencc/pub-services/db/rpsl/announcement.html and http://www/ripencc/pub-services/db/rpsl/index.html for more information. Finding objects in the TEST Database: Do whois -h test-whois.ripe.net <Search String> e.g. whois -h test-whois.ripe.net PB3-TEST The whois options that work in the RIPE Database also work in the TEST Database. We invite you to try them. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Re: IP Management Tool - Minimum Requirements
by Guy Vegoda 20 Apr '01

20 Apr '01

> Our internal solution does: > > -> assigns subnets out of internal 'allocations' to help aggregation. > The LIR allocations and internal 'allocations' form a tree down to > the most specific assignments. I think that this comes under designing the human viewable data structures to store information about the IP address space itself. I think what you have done is a good idea, though. As Nigel Titley pointed this out to me originally, IP lends itself very nicely to a binary tree of largest free blocks. Lets design the data structure available to the hostmaster. > -> validation against 'overlapping' assignments and assignments out > of 'less specific' allocation bounds. We definately need overlap detection. > -> 'allocation pools' for flexible assignments in cases where addresses > for a single site are not aggregated into a single block. This comes under designing the data structures, I think. > -> searching of unassigned space using a combined exact-fit/first-fit > strategy. Please expand on this. I don't want an end product that decides for you which subnet you will be assigning. That will be useful for people who need to migrate already used ranges of IP address space into the tool (ie everyone). QIP 4 does this, which is another reason why IMHO, it's totally useless. (My views do not represent anybody that Lucent can sue). > -> heuristic net_name generation I think that this is a lovely touch, but it doesn't come into the "minimal requirements" umbrella. > -> quick overview of allocation tree, also showing unassigned gaps. think that this will indeed be a useful feature of any data structre we decide on. > -> data is stored in a database that also stores routing and reverse > DNS information. I don't believe if IPMT is mandated to deal with DNS at all, at least in its first incarnation. > no support for IPv6 so far... IPv6 is something I'd like IPMT to eventually support. Still, this might have to get stuck on the back burner for the moment... So; A summary so far: 1) We need to check for properly formulated dotted quad format IPs: n.n.n.n/m where n >= 0; n <= 255; m >= 1; m <= 32; 2) We need to check for overlaps so that two subnets cannot overlap any space. We need to check for: (where a is frist IP in range, z is last IP in range) 0 : No overlap a1---z1 a2---z2 a1---z1 a2---z2 1 : Range 1 totally inside range 2 a1---z1 a2--------------z2 2 : Range 2 totally inside range 1 a1--------------z1 a2---z2 3 : Partial overlap a1-----z1 a2-----z2 a1-----z1 a2-----z2 4 : Perfect overlap, range 1 == range 2 a1-----z1 a2-----z2 5 : Edge overlap = someone screwed up, editing by hand a1---z1 a2---z2 a1---z1 a2---z2 ie. 10.15.20.0 -- 10.15.21.0 10.15.21.0 -- 10.15.21.255 (oops). 3) We need some kind of data structure to be defined, so that the hostmaster can access the IP space in a sensible way. I reckon this should include: o A way of seeing the IP space - what is free, what is used. o A way of dividing the IP space into sections for assigning to different areas, such as colo, dialup etc. o A sensible method of assigning free space (ie not always the next free block - think of migration). 4) We need to think about IPv6 I hope people will comment on this summary and pummel beat it into shape. Nothing worthwhile ever happened by people being polite. Thank you very much Michael for your comments. Guy -- 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)

6 5

[guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Guy Vegoda 20 Apr '01

20 Apr '01

Hi there all you internet people! I hope your all well, I emailed this to everyone yesterday and was dismayed when nobody commented on it. Only this morning did I notice that I mailed it to lir-wg(a)sirius-cybernetics-corporation.com rather than lir-wg(a)ripe.net by mistake )-: Hmm. Please enjoy your reading this mail. Thaaaank youuuuu. So here is my considered and very close to final draft of the top down specs for the IMPT program. You are all invited to tear it to peaces in the purpose of constructive whatsit. I would ask, if you are going to point out a problem, at least also point out a solution. ________________________________________________________________________ Questions: 1. Which platforms are we looking to support? I think that UNIX platforms would be easier for development, and would cover the needs of the majority of users. Also, ala Perl. A gui provides windows users with an opportunity to use the sotware too. The same could be achieved on a win32 platform under visual basic, but this would strain the GNU lisence considerable, as well as denying use by the UNIX users amongst us. Miscrosoft have a web platform and we could theortically write the whole thing in ASP. MS's web server is NOT free however, and ASP, in my opinion is less open than Perl. An apache web server is free, and I believe that they even have a windows version. Perl exists for windows. I don't recommend this setup, but I believe that it's better than ASP under a MS web server. Equally, the majority of people would find Perl easy and familiar. Many excellent, free, IP libraries already exist. They are also exstensible. 2. What's up with this IPv6 thing? Since, AFAICT, IPv6 still isn't _finished_ finished, let's leave room for it, but not impliment it yet. When the time comes, and it is polished and ready, we can slot in IPv6 support. > 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. Questions: 1. How do we store this information? How about a back end database capable of being acccessed by the DBI for the following reasons: a. If you don't want to run a database, the DBI can be used with a CSV filei. (Beware multiple users about data integrity). b. SQL shouldn't change too much from one DBMS to another, and the DBI code stays the same. c. It's free (the DBI) and talks to free DBMS's like mysql and postgreSQL. 2. In which case, how will data modifications be achieved? We're just talking 'bout plain old SQL here. 3. How will we make updates undoable? a. So, you changed the wrong customer's address by accident and now you need to change it back, but you can't find the original scrap of paper. How do you reverse the change? We're are talking about keeping logs, here, right? It would be simple if every DBMS was the same, but since we cannot rely on that, we need a database independent solution. I recommend a table containing this information, accessible in the same way by the DBI. b. We can embed enough information in the tables store a chronological history of what has happened to a particular and restore previous incarnations. 4. How will be make the software multi user proof? I haven't figured this one out yet. There is a really easy way with MySQL, but that doesn't scale to other DBMS systems. 5. Which checks need be done? I believe the following are crucial: o IP Address Space ranges must not overlap each other. o IP ranges must be entered correctly, or else give error messages. o Non IP information, such as customer names and addresses should be unique. o IP addresses should not be on illegal bit boundaries. o Assignment windows should not be exceeded for any given customer. 6. How should IP ranges be inserted? By this I am asking about the mechanisms for choosing how to assign out of one's allocation. I recommend an auto-manual solution wherby the computer is able to work out exactly which IP ranges matching your criteria are free and assignable, and allign them all nicely along the bit boundaries. The human can then choose out of a list which IP range to assign. The advantages are that you don't have to do too much math yourself, but neither are you stuch when it comes to migrating existing allocations into the program. 7. How much non IP info should be stored in the database, such as customer address, names, contact...? My view is that enough should be stored to be able to autogenerate an intenum object. Remaining problems: 1. With regard to storing both allocation information assignment information, perhaps also, customer information: What kind of data structure will we use? What about people with multiple registries? 2. We still need to tackle the mutli user problem. 3. If assigning something would exceed the window, we need to have some process. Autogenerate a 141? Maybe. If we did, how do we tell the software that the assignment has been approved? Have a toggle? Perhaps, but this need furthere discussion. > IPMT should allow the LIRHostmasters to receive requests for IPV4 > assignments from the customers of their LIR and allow them to process > them. Questions: 1. What does this mean? It is very general. (I should have spotted this during the reqs stage and primpted for more clarity. My bad.) Does the IMPT program sit on the end of an email address and parse 141 forms? My belief is that IMPT needs to be simple. By all means, have an inetnum autogenerator built into the program as that's easy. As for "allowing the LIRHostmasters to receive requests", I think that this means "Not getting in the way". All companies and organisations have their own policies and protocols for dealing with customers. We need an easy GUI for entering cust info and making assignments. Automise what we can and simplify what we can't. Clearly this needs further discussion WRT details! 2. Process them: ie integrate them into their DB? Do we save customer information accross multiple assignments, or keep a separate customer record for each assignment? I strongly opt for the former. This suggests that a customer object/table in the database would be a GOOD THING (tm). > 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. Questions: 1. Which requests should be sent? For assignments, I believe that the following are non negotiable: a. inetnum objects, (whether or not the customer already has a person object- thats's what auto-1 is for.) So how do we tell IMPT when RIPE assigns the person object to a customer? How about hourly reminders so that the human is reminded to reguraly check his/her email and add the contact info when it is ready? b. 141 forms. These can be a right illigitimate child. Cull information from the DB and automate it as much as possible. I believe that any required use of the RIPE Whois is an example of a defincieny in the scope of data stored by the backend DBMS. For allocations, I believe these _are_ negotiable: Requests for more space. It's nice having this automated. However, how easy would it be to program? I've a feeling, letting the hostmaster know that NOW is a good time to get new space might have to do. And most hostsmasters are bright enough to know this themselves. Problems: 1. Basicaly, this needs low level refining. What and how. 2. To what extent do we need to deal with replies from RIPE NCC? Should we attempt to flag the users attention or parse the email itself? Should we extract any ticket numbers? What do we do with them? > 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. I think I discussed most of this at the top. Questions remaining: 1. Java script enabled? My choice would be a cautious yes... Maybe an old Javascript just for keeping state and sanatizing input (performing above checks?), so that most browsers won't choke. 2. Fancy shmancy HTML? I'm no web designer. Not sure how thos would be too much a problem as long as its multi broswer compliant. 3. Cookies? Not, should we use them, but, do we need them? 4. Keeping state otherwise? See, I think we need to get this far. 5. Who will design it so it looks pretty? Who among you does designs thinsg to be easy to use, and to look purdy? ________________________________________________________________________ So, hows about letting me know what y'all think? Thanks, Guy -- 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)

7 9

RE: [guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Hallgren, Michael 19 Apr '01

19 Apr '01

> > Hi there all you internet people! > > Hello. 'lo, > > > Questions: > > > > 1. Which platforms are we looking to support? > > > > I think that UNIX platforms would be easier for > > development, and would cover the needs of the > > majority of users. Also, ala Perl. > > > > A gui provides windows users with an opportunity > > to use the sotware too. > > > > The same could be achieved on a win32 platform > > under visual basic, but this would strain the GNU > > lisence considerable, as well as denying use by > > the UNIX users amongst us. > > FWIW Perl with the TK toolkit/widget set runs under both *nix and > Windows. > > I still would prefer a web based solution. > Would as well. > WRT people's comments about php vs. perl - php is very easy > to learn, and > it's very easy with perl to write code in such a way as to render it > incomprehensible to anyone else (or to anyone who dosn't > understand you > particular dialect of perl). > > also doing compilcated datastructures in perl is a pain. hrm,... recent versions (5, 6) have gotten a _lot_ more freiendly than old 4. mh > > you can't (afaik) do non web based gui's in php tho. > > -- > Internet Vision Internet Consultancy Tel: > 020 7589 4500 > 60 Albert Court & Web development Fax: > 020 7589 4522 > Prince Consort Road > vision(a)ivision.co.uk > London SW7 2BE http://www.ivision.co.uk/

1 0

Re: [guy@sirius-cybernetics-corporation.com: IPMT specen.]
by Gyan Mathur 19 Apr '01

19 Apr '01

In response to Guy Vegoda: > However, JavaScript might be equally worth considering. Please don't make something that can only be used with Javascript. In our office, Javascript is considered a security risk and it is not allowed to switch it on on any browser here, so we would be unable to use your tool. Gyan Mathur nl.demon

1 0

ANNOUNCEMENT: New Version of Asused
by Maldwyn Morris 19 Apr '01

19 Apr '01

Hi, The RIPE NCC are pleased to announce the release of a new version of Asused - this is Version 3.60. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.60.tar.gz or alternatively, just: ftp://ftp.ripe.net/tools/asused-latest.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The main change since Version 3.52 is that Whois DB Version 3 objects are now handled correctly. Timur Bakeyev of RIPE NCC did the programming. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to the address below. Cheers, Maldwyn Morris swcontact(a)ripe.net

1 0

draft agenda (v1) for IPv6 working group RIPE39
by David Kessens 19 Apr '01

19 Apr '01

Hi, Below follows the first draft of the agenda for the ipv6 wg. The current plan is to use the second part of our session for ipv6 policy discusions. This part will be a joint session with the local-ir working group. Please let me know if you have any other topics that you want to have discussed or if you would like to volunteer for a presentation. We still have some time left in our agenda for additional topics. Thanks, David K. --- Agenda for the IPv6 Working Group Meeting RIPE39, Bologna Tuesday, May 1, 2001, 14:00-17:30 1st part 14:00-15:30 A. Administrative stuff - appointment of scribe - agenda bashing (David Kessens) B. Status of the 6bone (David Kessens) C. Securing the Mobile-IPv6 Binding Update (Tony Hain) D. Developments/initiatives regarding IPv6 in the RIPE region and beyond (input from the audience) 2nd part 16:00-17:30 joint session with lir-wg E. Draft on allocation sizes (Niall Murphy) F. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

Migration of the TEST database is delayed
by Andrei Robachevsky 18 Apr '01

18 Apr '01

Dear colleagues, Unfortunately due to hardware problems with the computer running TEST database server we need to delay the migration of the TEST database that was planned on 17-18.04. We plan to start the migration of the TEST database tomorrow, 19.04. We will keep you informed. Sorry for any inconvenience this caused. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

1 0

Discussion on change to policy process
by Hans Petter Holen 12 Apr '01

12 Apr '01

Dear WG, I would like to start a discussion on slightly improving the process for setting new policy. http://www.ripe.net/ripe/wg/lir/howto_devolep.html This is inspired by the ARIN policy process: http://www.arin.net/announcements/policy_eval_process.html Altough this is very different from how we do things in the lir-wg there is one change I would like us to discuss: "To be considered for presentation at these meetings the proposal should be submitted to ARIN staff six (6) weeks prior to commencement of the meetings to allow time for it to be posted and an announcement to be sent out at least thirty (30) days before the meetings convene." Should we in our procedures include a requirement for the proposed change to be submitted to the lir-wg some weeks before the lir-wg meeting ? Hans Petter

2 1