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

Summary: Fixed Boundary (/29) Assignments
by Mirjam Kuehne 19 Sep '01

19 Sep '01

Dear LIR-WG, Here is an attempt to summarise the recent discussions on this mailing list regarding possible fixed size assignments. Following a review of the comments, it looks like the majority does not believe that a special assignment policy is needed. Most contributors agreed that there is no need to make a distinction in policy relating to different access methods. All assignments should be made on actual needs and according to the current IP address policies. The comments showed concerns about the administrative procedures required for these kinds of assignments. However, it was felt that these addresses need to be accounted for in some way. A possible way forward would be to initiate discussion surrounding the set of information necessary to justify these assignments while providing an efficient way for the LIRs to provide services to their customers. I realise that I did not touch on every aspect of the discussion but I hope that this is a fair summary in order for you to move forward Looking forward to a continuation of this debate. Best Regards, Mirjam Kuehne RIPE NCC

3 2

Call for agenda items & draft agenda
by Hans Petter Holen 11 Jul '01

11 Jul '01

Dear WG, I would like to bring to your attention the upcoming working group meeting in Bologna, likely to be on Wed May 2nd. Please suggest agenda items that needs to be discussed to the mailinglist. Draft Agenda 1.Admin - scribe, participant list, charter, mailing-lists 2.Agenda 3.RIPE 38 minutes & actions 4.Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. 17th of May Task force - goal reached or what to do next ? 6. Report from The ASO: AC happenings and GA 7.Closure of the ICANN ad Hoc Group on numbering 8.Election of WG Chair and co-chair Actions from last meeting: 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes 37.1 WG Further discuss restoring the transparency 37.2 NCC Incorporate IESG/IAB proposal into IPv6 policy 37.3 M17 Work with the RIPE NCC to implement suggestions

1 4

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

IP Management Tool - Minimum Requirements
by Maldwyn Morris 06 Jun '01

06 Jun '01

Hello everyone, Guy wrote: > > I am officially asking Mal to please repost the > current requirements back up on this list. [...] Happy to oblige. Cheers, Maldwyn Morris Software Manager RIPE NCC -- 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

agenda for IPv6 working group RIPE39
by David Kessens 29 Apr '01

29 Apr '01

Hi, Below follows the final version of the agenda for the ipv6 wg. The second part of our session will be used for ipv6 policy discusions. This part will be a joint session with the local-ir working group. 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. 3G and IPv6 (Niall Murphy) E. IPv6 deployments at Jippii (Jan-Ahrent Czmok) F. 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 G. Draft on allocation sizes http://www.enigma.ie/articles/global-ipv6-alteration.html (Niall Murphy) other info: http://www.djp.net/ipv6/proposal.html http://www.ripe.net/ripe/mail-archives/ipv6-wg/20010101-20010401/msg00017.h… (Dave Pratt) H. Status of IETF/RIR allocation boundary discussions (Randy Bush/Mirjam Kuehne) Z. AOB ---

1 0

The status of the migration iissues
by Andrei Robachevsky 26 Apr '01

26 Apr '01

Dear Colleagues, As some of you might have noticed, several problems showed up after the migration. Let me present an update on their status: 1. PGP signed messages sent to <auto-rpsl(a)ripe.net> didn't pass authorization checks This was fixed on 24th of April. Please note that PGP signed updates cannot be processed by <auto-dbm(a)ripe.net>. Until 14th of May, <auto-dbm(a)ripe.net> processes updates in RIPE-181 format and automatically translates them into RPSL, which voids PGP signatures. 2. Conversion problems of updates sent to <auto-dbm(a)ripe.net> Problematic objects were: - Objects with syntax errors - Indented objects (containing leading whitespace) In both cases objects were not converted to RPSL and user received an empty acknowledgement. This was fixed today, 26th of April. Please note that <auto-dbm(a)ripe.net> cannot reproduce all the behaviour of the v2 database. In particular, empty attribute is treated as a syntax error and Routing Policy System Security authorization rules apply. We strongly recommend you to switch to updates in RPSL format as soon as possible. Also note, that <auto-dbm(a)ripe.net> will process updates in RIPE-181 format until 14th of May. After that, updates in RIPE-181 format should be sent to the new address, <auto-181(a)ripe.net>, and <auto-dbm(a)ripe.net> will accept only RPSL syntax. 3. Due to above problems some of the updates were not processed. If you haven't received an acknowledgement from the database one day after you sent your update we would kindly ask to re-send it. We apologize for any inconvenience these problems caused. We are working on some minor problems and rely on your understanding. Please visit the "Migration Issues" link on the "Database Status" page (http://www.ripe.net/ripencc/pub-services/db/issues.html) for the up-to-date information. Regards, Andrei Robachevsky DB Group Manager RIPE NCC

3 2

Hostmaster Centre at RIPE 39
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, Ripe NCC Registrations Services are pleased to announce that during the RIPE 39 Meeting in Bologna, we will open a Ripe NCC Hostmaster Centre. Ripe NCC Hostmasters will be available for any IP and ASN request questions, and also any general policy questions. A timesheet at the centre will be made available for appointments, though 'walk-in's will also be welcome. Please note the following time-table: Monday April 30. 12:30 - 14:00 Tuesday May 1. 9:00 - 17:30 Wednesday May 2. 12:30 - 14:00 & 16:00 - 17:00 Thursday May 3. 9:00 - 14:00. Friday May 4. CLOSED. (IP request Tutorial, 14.00-17.30) We look forward to meeting you. Regards, Ripe NCC Hostmasters

1 0

portable address space
by RIPE NCC Staff 25 Apr '01

25 Apr '01

Dear all, At the upcoming RIPE meeting next week, the RIPE NCC will put forward a proposal attempting to clarify current policy on independent/portable address space. We are seeking the communities input on this matter. The RIPE NCC is currently experiencing an increased demand for portable address space, clearly visible through the amount of new members signing up from a need for portable address space but also through the amount of PI (Provider Independent) address requests received at the RIPE NCC. At this time there is no clear and consistent policy on any of these types of portable address space. - PI address space is discouraged and requestors are informed of disadvantages with PI space and what possible implications there may be. However, there are no criteria for obtaining PI address space. - PA allocations can be obtained by anyone who is a member of the RIPE NCC. (The RIPE NCC membership is open.) The LIR is only required to justify the first assignment out of that address block. As all members are required to request and justify each assignment made to customers or own infrastructure, we feel that current poorly defined PA Allocation criteria create an inconsistency in policy. In practice it means that anyone justifying the need of one IP address can receive a PA allocation (currently a /20 = 4096 addresses). This has resulted in an enormous growth of new members over the last three years. Whilst ARIN has a clearly defined policy on portable address space, APNIC has experienced the same dilemma as the RIPE NCC with their similar policies on portable address space. This was brought up and discussed at the APNIC meeting in Kuala Lumpur, March 2001. (see URL below.) As demonstrated in several recent studies of the changes in the Internet over the last years, it is clear that there is an increase of multi-homing taking place globally, an increase of smaller routes being announced in the Internet and an increased need for portable address space. The RIPE NCC wishes to develop a clear and consistent policy for portable address space in a realistic and pragmatic manner that also accommodates this increased need for portable address space. We will at the upcoming lir-wg meeting present statistics showing this trend and suggest possible steps forward. We wish to request the communities input in this discussion and we look forward to a fruitful discussion. Kind regards Nurani Nimpuno Registration Services Manager RIPE NCC http://www.ripe.net REFERENCES: -------------------- Policy documentation: "European Internet Registry Policies and Procedures", section 3.4.2.PA vs PI Space http://www.ripe.net/ripe/docs/ripe-185.html#toc34 "Provider Independent versus Provider Aggregatable Address Space" http://www.ripe.net/ripe/docs/ripe-127.html APNIC policy documentation: http://www.apnic.net/docs/add-manage-policy.html ARIN policy documentation: http://www.arin.net/regserv.html Presentations and papers: "Architectural Requirements for Inter-Domain Routing in the Internet" - Geoff Huston http://www.ietf.org/internet-drafts/draft-iab-bgparch-00.txt "The State of BGP routing" http://www.telstra.net/gih/papers/ietf/ietf50-plenary.pdf "Consistent and realistic policy framework for 'Portable' allocation and assignment" - Paul Wilson http://www.apnic.net/meetings/presentations/pa-pi-criteria.ppt Global policy document: "RIR comparative Policy Overview" http://www.ripe.net/ripencc/mem-services/registration/rir-comp-matrix-rev.h…

1 0

Proposed Agenda for Tools WG at RIPE 39
by Maldwyn Morris 25 Apr '01

25 Apr '01

Proposed Agenda for Tools WG at RIPE 39 --------------------------------------- 1. Administratrivia a. Scribe b. List of participants 2. Agenda bashing 3. Election of WG Chair Maldwyn Morris is leaving the RIPE NCC and will be stepping down as Chair of the WG, so we need to chose a new Chair. Manuel Valente, the new RIPE NCC Software Manager, will stand for the position. 4. IPMT - Manuel Valente a. Specifications We have already produced basic requirements for the IP Management Tool ( IPMT ) and would now like your assistance to flesh out the specifications - a real _working_ group ! Anyone who has used a similar tool or might use IPMT is encouraged to come along and help. b. Developers Group We would like to organise a group of people willing to help implement IPMT. 5. Tools and Techniques - Manuel Valente We would like to discuss proposed and existing tools or techniques of use to LIRs. If you have tools or ideas of your own, please bring them along. Cheers, Maldwyn Morris Software Manager RIPE NCC

1 0

IPv6 addresses for Exchange Points
by Mirjam Kuehne 24 Apr '01

24 Apr '01

[Appologies for multiple postings. I suggest to keep the discussion on <lir-wg(a)ripe.net> as it is related to address allocation policies]. Dear colleagues, The RIPE NCC received a number of requests from Internet Exchange Points (IXPs) for IPv6 address space. While evaluating these requests, we realised that it is still not entirely clear what the role of an IXP is in the IPv6 world. We also noticed that the allocation criteria currently described in the 'Provisional IPv6 Assignment and Allocation Policy Document' (http://www.ripe.net/ripe/docs/ripe-196.html) do not necessarily apply to IXPs. Please find some more details regarding this issue below. We would like to discuss this with you at the upcoming RIPE Meeting in Bologna. For more information abut the schedule, please refer to the agenda of the EIX-WG and the LIR-WG: http://www.ripe.net/ripe/meetings/current/ripe-39/ Kind Regards, Mirjam Kuehne RIPE NCC ------------ PROBLEM STATEMENT: - IXPs need independent address space for their infrastructure to allow their members/customers to connect via native IPv6 - IXPs do not necessarily fulfill the current criteria: - they do not have 40 customers (in most cases IXPs do not assign address space to their members) - if IXPs are on the 6bone, they might not have a whole pTLA, but only connect to the 6bone via another ISP - they do not need a whole subTLA (a /64 or /48, depending on the case, might be enough) POSSIBLE SOLUTIONS: 1. view IXPs as a site and assign them a /48 (or /64) directly (equivalent to IPv4 PI space) 2. require IXPs to fulfill the criteria and allocate a subTLA: - either by requiring them to get 6bone experience first - or by applying the general allocation criteria and require to connect to 3 other subTLA holders OPEN ISSUES: - what about IXPs with multiple PoPs - technical criteria for exchange points

1 0

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

change maintainer
by Stefan.Gasteiger＠Gendorf.de 10 Apr '01

10 Apr '01

sorry, if this is trivial or has been asked before. how can i change the mnt-by attribute of an object? i am authoritative for both maintainers. Kind regards, Stefan Gasteiger I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de

2 1

PI assignments
by Arif OKTAY 10 Apr '01

10 Apr '01

Hi, Can anybody help me about PI assigments please ? I have sent a PI request nearly 2 mounths ago. Though the automatic answer said that it was handed to a hostmaster, I couldn't receive any response since then. I have also send an e-mail to ncc(a)ripe.net and I couldn't receive any answer yet either. Is there a policy conflict I'm missing ? Regards arif ao189-ripe

2 1

Re: change maintainer
by RIPE Database Administration 09 Apr '01

09 Apr '01

Dear Colleagues, We have answered Mr. Gasteiger's question. For any questions regarding the RIPE database, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee ______________ RIPE NCC

1 0

ICANN Board Nominations - Expression of support
by Hans Petter Holen 07 Apr '01

07 Apr '01

Dear WG, The address council is about to elect a new Director for the ICANN board over the next few months. The nominees can be found at: http://www.aso.icann.org/board/comf_board_members.html It would be valuable , at least for myself, to get advice from members of this working group on the candidates in question. You may express your support by clicking on the Express support link on the page refered to above. Hans Petter

1 0

RE: Call for nominations for lir-wg chair and co-chairs
by mike.norris＠heanet.ie 05 Apr '01

05 Apr '01

> > Please nominate yourself to lir-wg(a)ripe.net. > > I was suggested to nominate myself as a co-chair. > > I am prepared to be a candidate for this role. I'll certainly second you, Janos. Mike

1 0