December 2002 - lir-wg - mailman.ripe.net

Updated proposal for clean-up of references by name
by Engin Gunduz 16 Jan '03

16 Jan '03

[Apologies for duplicate messages] Dear Colleagues, I'm attaching the updated proposal for automatically cleaning up the references by name in RIPE Whois Database. We have incorporated Janos's suggestions to the proposal. If no more comments come, we plan to apply the procedure described in the proposal in the first half of January, 2003. The operation should not take more than a day. We will notify the community about the actual date of the operation. Regards, Engin Gunduz ____________________________ RIPE NCC Database Group -------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database Motivation: References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software. Classification of the inconsistencies we need to solve and proposed solutions: 1. Objects that refer to a person or role object by name. a. There is only one object with this name. 1. The referring inconsistent object is not maintained, or the maintainers of referring inconsistent object and the person/role object with this name are the same. Solution: Update the referring inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. The referring object is maintained, and the maintainers are different from the maintainers of the object with the referred name (If the latter object is not maintained, then the maintainers are by definition different.) Solution: Create a role object with this name. It will list the role or person object with this name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. Protect it with the inconsistent object's maintainer(s). c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Protect it with the inconsistent object's maintainer(s). Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Protect it with inconsistent object's maintainer(s). Then update the inconsistent object to refer to the NIC handle of this new place holder person object. In each case an object is updated, or created, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates). Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.

1 2

Draft Agenda for RIPE 44 (version 0.3)
by Hans Petter Holen 01 Jan '03

01 Jan '03

Dear Working Group, Please find enclosed a draft agenda for the upcoming working group. As a matter of procedure I suggest that Policy items to be discussed are to be discussed at the mailinglist. We should aslo be careful not to make policy desicions at the upcoming meeting _unless_ there is a concrete proposal circulated to the list in advance of the meeting, we should circulate any policy proposals to this list after te meeting before making any policy desicions. Thanks to leo for preparing the very first draft, looking forward to input from the rest of you. Best Regards, Hans Petter Holen lir-wg chair --- Draft Agenda for RIPE 44 (version 0.2) Wednesday 29 January 2003 09:00 - 12:30 Chair: Hans Petter Holen Co-chair: Denesh Bhabuta A. Admin: Scribe Participant List, Charter, Mailing lists B. Agenda bashing C. RIPE 43 minutes and actions http://www.ripe.net/ripe/wg/lir/r43-minutes.html http://www.ripe.net/ripe/wg/lir/lir-actions.html D. Report from the RIPE NCC Registration Services Presentation by leo vegoda E. Report from the Address Council - Presentation F. Election of new LIR-WG Chairs G. LIR Portal H. Policy issues -- Mailing list AUP ? -- EGLOP Multicast policy discussion ? -- IPv6 policy - experiences ? -- IP addressing for always on (residential broadband) revisited ? X. Any other business Y. Summary of actions arising from this meeting Z. Open microphone

2 1

[lir-wg]Election of chairs to the lir-wg - call for nominations
by Hans Petter Holen 13 Dec '02

13 Dec '02

Dear wg, As mentioned at the last wg-meeting, one of the co-chairs, James Alderidge, has started working for the RIPE NCC, and as one of the unwritten rules of the LIR-wg is that it should be chaired by non RIPE NCC staff, James is no longer serving as a co-chair of this wg. Last time we had an election the wg deceided that one chair and two co-chairs was suitable. As I find it good practice to hold an open election from time to time I propose that we do an election for all 3 chairs. I would like to propose to the WG that we do a open nomination process on the lir-wg list up until lets say one month before the next RIPE meeting (27 to 31 January 2003) for chair and two co-chairs and that we do the chair election at the next wg meeting in Amsterdam. This should give the wg a good opportunity to discuss potential candidates. Best Regards, Hans Petter Holen lir-wg chair.

3 3

Acceptable use policy ?
by Hans Petter Holen 12 Dec '02

12 Dec '02

Dear lir-wg, as a discussion point for the next working group meeting, and perhaps as a desicion to be made by the RIPE plenary, if there is a feeling that a change is needed. Up until recently I have been of the opinion that the lir-wg list should be open. I realise this is somewhat naive as I personally clearly don't want to see spam on this list. Currently there is an AUP on http://www.ripe.net/ripe/about/maillists.html All working group mailing lists are open for subscribing. Postings are accepted only from subscribed members, but the lists may only be used for purposes covered by the charter of each RIPE Working Group. Unsolicited Bulk E-mail ("spam") is never acceptable. The RIPE NCC will, at its own discretion, remove addresses likely to lead to misuse of any list or lists, and may take further action against individuals and service providers involved. The question then is: is this wording acceptable ? Do we need a more detailed charter like ftp://ftp.rfc-editor.org/in-notes/rfc3005.txt What should the procedures be to handle a breach to this policy ? Personally I do not see my role as chair of the lir-wg as editor of the content of this list, but recently there was an expectation that the chair should call act on such a matter. Opinions from the WG ? -hph

1 0

Re: [lir-wg] Re: 50% increase in RIPE fees ? Since when ?
by Bovio＠aol.com 11 Dec '02

11 Dec '02

In a message dated 12/2/02 1:06:32 PM Romance Standard Time, kurtis(a)kurtis.pp.se writes: Kurtis, All, now that the discussion on the list came back to the previous (good) level I am willing to give it a try and explain the fee raise. > The burst of the dot.com bubble is no news. It was there a year ago. > Businesses adopted and cut back to cope with it. Some did better, some > did worse. RIPE NCC seems to belong in the later category. If this > would have been a Ltd, the share holders would be asking if the > management and accountants was a sleep. > The burst of the dot.com bubble has indeed impacted the RIPE-NCC, but not as much as one can imagine: the Internet is still growing, although there are less players providing services, and therefore the amount of addresses to be assigned/allocated is obviously still growing. In addition, as already explained by Axel, closing LIRs create at least as much work as creating new ones. Here are some facts for you to consider that may help understanding the situation better. 1) The RIPE-NCC business model during the last few years was biased for a number of reasons, in particular a Dutch law that prevent a non profit organization to accumulate monies beyond a certain amount (putting a limit to the contingency fund), and the too conservative assumptions made concerning the growth. In the last 3 years the Ripe-NCC fees were reduced each year because the number of new LIR each year was increasing more than forecasted and the total income was exceeding the contingency fund amount. In other words in the last 3 years most of the expenditures were supported by the influx of new LIRs coming in each year, which "artificially" reduced the fees for existing LIRs. This was no longer the case in 2002, where the amount of new LIR turned out to be overestimated, which caused, for the first time, a big hole in the budget, which was covered by the contingency fund. This old model obviously no longer works, so the LIRs have now to pay for 2003 the "actual" fees, i.e. more or less the fees paid in 1999. 2) The vast majority of expenses of the RIPE-NCC are wages. The RIPE-NCC is now comprised of about 100 employees. These people were hired during the fat-cows years both to support and improve the core activities such as registration services and database, as well as activities proposed during various RIPE working group meetings, and approved by the AGM. To fire 1 employee in NL takes as much money as to pay his salary for a full year (the financial impact/improvement would be apparent only on the second year), so since the contingency fund was almost gone we had to recover the money and replenish the reserves as explained by Axel. 3) The board is now concerned (and focusing) with long term scenarios that guarantee the stability of the core services and take in account the industry situation, the needs of the membership, and their willingness (or not) to pay for additional services. Needless to say since last August, when we became aware of the situation, Axel was asked to reduce as much as possible the expenditures (but since most of the cost are wages there was not much he could save) and to provide different possible scenarios for the future. Year 2003 will be a transition year: we believe the membership survey will help in understanding what the membership expect the RIPE-NCC to do and whether it is prepared to pay for such activities (beyond the core activities). We will also closely monitor the discussion in the LIR-wg and other lists, and try to collect as much input as possible from RIPE meetings. We will then work with Axel to prepare a business plan for 2004 that reflects what we learned. If you have input don't hesitate to approach me (or any other member of the board) at RIPE meetings or write mail to me. Best Regards Daniele

3 5

New question
by Peter Galbavy 09 Dec '02

09 Dec '02

Honest question, in order that I am able to better formulate my own views; Can someone please answer these in a clear and non-'Yes Minister' way: 1. What is the difference between RIPE and RIPE-NCC ? 2. What is our membership fee funding (RIPE or RIPE-NCC) ? 3. What other funding does RIPE or RIPE-NCC recieve, other than membership fees (with respect to the answer to the preceeding questions) ? I am not trying to start yet another funding thread, I am doing research - so private replies are welcome. Apart from JR. Peter

15 21

ref: the 50% increase discussion: reality check, pls.
by Wilfried Woeber, UniVie/ACOnet 09 Dec '02

09 Dec '02

The invitaion to the general assembly meeting is still accessible on the web server: http://www.ripe.net/ripencc/about/gm/gm2002/gm-announce2002.html It lists all the items on the agenda, and those topics (with a verbatim resolution for decision included) for which a vote was required. And it included the link to the Articles of the Association. In particular Article 15 - General Meeting is relevant there, in that it states, i.a., <included here to provide context> "The executive board shall send the verbatim text of the resolutions proposed by the said members immediately to all members of the association." </included ...> "The general meeting may only resolve with respect to resolutions concerning subjects for which the verbatim text of the related resolutions has been sent to the members in accordance with the above." This provision _in particular_ is meant to support proxy voting, by clearly documenting the issues at hand and the resolutions put in front of the members to decide. So it _is_ easy to be represented by proxy. Reality check, please! And, no, I _don't_ like increased fees, but I _do_ understand that they are necessary for the moment. Regards, Wilfried.

16 30

Re: [lir-wg] Re: 50% increase in RIPE fees ? Since when ?
by Bovio＠aol.com 06 Dec '02

06 Dec '02

In a message dated 12/4/02 5:58:30 AM Romance Standard Time, kurtis(a)kurtis.pp.se writes: Kurtis, > Ok, so for next year we will see a staff reduction or a > "re-prioritistion"? As I wrote earlier we expect the survey to tell us what the membership at large expects the RIPE-NCC to do. If the members indicate that they are only intrested in core activities some restructuring will be required. I personally doubt that this will be the case and I do not think a staff reduction will be needed. > So does this mean that we need to plan for an increase for next year as > well? The current budget/activity plan, as published, shows that we are forecasting zero growth for 2003. As I already explained the business model is changed and we no longer expect new LIRs to cover most of the charges. The fees set for 2003 allow to cover the current expenditures, and generate some surplus to recover part of the contingency fund. If our forecast (zero growth) is accurate, or conservative, the fees should remain at this level (unless, again, the membership survey gives us totally different signals). > > >3) The board is now concerned (and focusing) with long term scenarios > >that guarantee the stability of the core services and take in account > >the industry > > I would very much appreciate some details on what is mean with > "stability". Stability for me means that in n years the RIPE-NCC will still be able to efficiently run core services as a non profit organization, to the satisfaction of its members/customers (at least the majority of them ;-)) > > I am now playing the devils advocate so don't take this literal - the > RIPE NCCs number one focus is to provide adequate registration > services. Anything else is pure bonus. > The RIPE-NCC was never meant to be "only" about registration services. At any rate I do not believe the RIPE database can be considered "a bonus" anyway. Regards Daniele

6 9

Re: [db-wg] Proposal for automated clean-up of references by name
by Janos Zsako 06 Dec '02

06 Dec '02

> From engin(a)ripe.net Thu Dec 5 13:25:05 2002 Dear Engin, > > I have one question though: who will be the maintainer of the new > > "ugly" object created? I have the feeling it could/should be the > > maintainer of the object that will reference it. > > That would make sense, when creating person objects, I think. > However, thinking about role objects that will be created: > If we put the once-inconsistent object's maintainer on it, > the users that happen to have the referenced name but have no relation > to the inconsistent object will not be able to delete their > NIC handle from the newly created role object. They will need > to contact the owners of once-inconsistent object, however chances > are that they will be irresponsive (otherwise they would > have updated their inconsistent objects long ago, wouldn't they ;) > > So I'd propose putting mntners of relevant inconsistent object > in the new person object, but leaving the new role objects > unmaintained. What do you think? Yes, this makes much more sense, indeed. I have a new question, though (I quote from the original proposal): > From db-wg-admin(a)ripe.net Thu Dec 5 10:43:33 2002 > From: Engin Gunduz <engin(a)ripe.net> > 1. Objects that refer to a person or role object by name. > a. There is only one object with this name. > Solution: Update the inconsistent object so that it > will contain the NIC handle instead of the name. Add > appropriate remarks and changed attributes to the object > to explain the reason for update. In case the referring object is maintained (by a probably unresponsive maintainer, as you well suggested above) and the referred person happens not to be related to the referring object (i.e. the program inferred incorrectly the relationship), then the owner/maintainer of the object will not be able to delete the person object once it becomes unused. Would it not be advisable then to act as in case 1.c. (with a single person/role object being referenced by the newly created role object)? In other words, it may be advisable to refine 1.a. by the following: 1.a.1. If the referring object is maintained, and the maintainer is different from the maintainer of the object with the referred name, then proceed as in 1.c. (If the latter object is not maintained, then the maintainers are by definition different.) 1.a.2. If the referring object is unmaintained or both objects are maintained by the same maintainer, then proceed as previously described. This procedure may create superfluous role objects, but I would think the chances are low for this to happen and it is a price worth paying. What do you think? Best regards, Janos

2 1

Announcement: IPv4 Early Registration Transfer Test
by leo vegoda 05 Dec '02

05 Dec '02

Dear Collegues, Following from the work of the ERX Task Force in October, the four RIRs will begin a test transfer on Monday, 9 December 2002. <http://www.ripe.net/db/erx/> The objective of the test transfer is to estimate time and resources needed to carry out the whole project as well as further elaborate procedures and identify issues. 43 networks from one range (129.0.0.0/8) will be transferred to the RIPE Database during this test phase according to the timeline below. A detailed list of the networks can be found at: <http://www.ripe.net/db/erx/erx-ip/network-129.html> Since this is an ARIN majority /8, the transfer will be of networks within the /8, rather than the /8 itself. Contacts for networks to be transferred to the RIPE Database will be notified by e-mail on 11 December 2002. Each network will use a single ticket number. Please do not remove the ticket number from the Subject header when replying to the e-mail. If you have questions regarding the process, please contact <er-transfer(a)ripe.net>. Kind regards, -- leo vegoda RIPE NCC Registration Services The transfer process is as below: APPROACH The plan is to perform the transfer by /8. For each /8 the following tasks have to be performed: 1. Conflicts (contacts and description) to be resolved 2. Records and associated documentation to be transferred 3. Reverse delegation to be set up CONFLICTS The following types of conflicts have been identified: C1. Record exists in ARIN Database only. There is no exact matching (range wise) record in the RIPE Databas Proposal: to update internal documentation, create the record in the RIPE Database and protect with a unique generated maintainer. The inetnum will be created with a status attribute value of "EARLY-REGISTRATION"(*) C2. Range matches records in both ARIN and RIPE Databases. Meaning that contacts and description may be different. Most cases indicate out of date information in one of the Databases, not real conflicts or attempts to hijack address space. What happened in most cases is that people started maintaining their allocation or assignement in the RIPE Database, especially since RIPE Database started to support the Routing Registry. Proposal: Notify the contacts and give them time to reach consensus. After the deadline merge the records whose contacts have not responded. Database objects will not be locked by either ARIN or the RIPE NCC during the transfer process. The RIPE NCC will not change the maintainer on objects following the transfer process. C3.0 Record exists in the RIPE DB only. C3.1. One reason why such situation may exist is that this is a valid RIPE NCC allocation. Proposal: To preserve information in the RIPE DB. The existing value of the status attribute will be preserved. If the existing inetnum object does not have a status attribute a status attribute with a value of "EARLY-REGISTRATION"(*) will be inserted. C3.2 Another situation is that the registration data are simply garbage. Proposal: Notify contacts and give them time to explain the situation. Where no explanation is forthcoming or the contacts explain that the registrations are 'garbage' the records will be deleted. (*) The status of "EARLY-REGISTRATION"(*) is a special value proposed for the ERX networks. It has no policy implications and objects with this status can be created only by the Database Administration. PROCEDURE for a /8 1. Pre transfer 1.1 Initial dump is prepared for transfer by ARIN 1.2 Announcement is sent to ARIN's contacts 1.3 Reverse delegation domain space is cleaned up in the RIPE Database (reverse domain objects for which no delegation was provided are deleted) 2. Transfer 2.1 Final dump is prepared by ARIN 2.2 C1 group: database records are imported, documentation is updated, contacts are notified 2.3 C2 group: contacts (ARIN+RIPE) are asked to reach consensus. 2.4 C3.2 group: contacts are notified of possible deletion. 3. Conflict resolution 3.1 C2 group: non responding records are merged but not locked. 3.2 C3.2 group: records without good reasons are deleted. TIMELINE 1 Happens on 9 December 2002 2 Happens on day 10 January and only takes 1 day. At this point we are done with this /8 from ARIN's point of view. 3 May continue after 10 January if necessary

1 0