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

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

Problems with the RIPE Database.
by RIPE Database Administration 29 Dec '99

29 Dec '99

Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

Problems with the RIPE Database.
by RIPE Database Administration 29 Dec '99

29 Dec '99

Dear Colleagues, This morning, the primary server for the RIPE Database had a serious hardware failure. Since that time, no updates of the RIPE Database have been possible. Queries are possible, but using the backup service. We are currently restoring the data. We must do this from backup tapes; thus, we do not expect to resume normal service until sometime between 2000 and 2200 GMT tonight. If you have sent updates, there is no need to send them again; they are being queued on another machine. We realise that this situation may cause you some inconvenience, but we are making every effort to fix it as quickly as possible. We are also investigating the subtle hardware failure that caused the original problem. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, A. M. R. Magee _______________________ RIPE NCC Database Group

1 0

Top 100 Maintainers List 19991221
by RIPE Database Administration 21 Dec '99

21 Dec '99

1 0

IPv6 Policy Document Review - Call for comments
by RIPE NCC Staff 21 Dec '99

21 Dec '99

Dear colleagues, In July 1999, the three Regional Internet Registries (APNIC, ARIN, and the RIPE NCC) released the "Provisional IPv6 Assignment and Allocation Policy Document" (see http://www.ripe.net/lir/registries/ipv6.html). These initial policies and procedures have been carefully discussed within the community before publishing them. A formal review of the document was scheduled to start in October 1999, so that early experiences of IPv6 operation and administration could be fully evaluated and any necessary amendments made. The RIPE NCC, together with the other RIRs, now calls for comments to assist in this first review. We would like you to re-visit this document and we invite you to make any comments you feel would be constructive to the development of the next version. In particular, the RIRs seek your comments on the following sections of the document: * 4.2.3.2 Multihomed Sites This section was left unwritten in the first release, as there was insufficient experience to draw on in formulating a policy. We encourage any members of the community who have operational experience or interest in IPv6 and multi-homing to contribute suggestions for this section. * 4.2.8 Allocations to NLA Registries * 4.3.1 Assignments to End-users Review of these two sections is sought from members of the community who have relevant operational experience. * Definition of 'transit provider' A definition for the above term was not included in the current document. Comments and suggestions for an appropriate definition are encouraged. Finally, we also encourage you to take a look at the "IPv6 sub-TLA Request Form" (http://www.ripe.net/docs/ripe-195.html) and provide any comments or suggestions for improvements. Discussion will take place on the IPv6-WG mailing list <ipv6-wg(a)ripe.net>. If you prefer to submit any private comments, please do not hesitate to contact Nurani Nimpuno <nurani(a)ripe.net>. We would like to receive comments before the end of January. Kind Regards, Nurani Nimpuno Manager Registration Services RIPE NCC

2 1

Countdown to the next LIR Working Group meeting
by Hans Petter Holen 19 Dec '99

19 Dec '99

Dear LIR WG, A new RIPE meeting is approaching and we have some important business to conduct. I have just posted the minutes from the last working group meeting to the list, with the comments I have received from the participants. The time since the last meeting has been particularly busy, partially because the company I work for has been bought by Infostream ASA, partially because several people left the company leaving me with the task of rebuilding the sales and marketing department. Things are now returning to normal, and I hope to have some more time to spend on RIPE and ICANN ASO business. The most important thing that has happened this autumn was the ICANN meeting in Los Angeles. The long version of what happened at that meeting can be found at the ICANN web site at http://cyber.law.harvard.edu/icann/la/archive/ The formal version, IE, the minutes from the Board meeting: http://www.icann.org/minutes/prelim-report-4nov99.htm The short version of what happened related to the Address Supporting Organisation, http://www.aso.icann.org according to my memory is: - The Address Council and the ASO directors met with some ICANN board members and staff to get aquatinted and have informal discussions on how to proceed with our work. - The Address Council had an open meeting, minutes can be found at: http://aso.icann.org/mailing-lists/aso-policy/9912/msg00000.html (The minutes from the previous phone conference can be found at: http://aso.icann.org/mailing-lists/aso-announce/9911/msg00000.html ) - The discussions on the ad Hoc committee turned into something that seems more acceptable to all parties. -I had the pleasure of presenting the status of the work done by the Address Council so far to the ICANN annual meeting. http://home.sol.no/~hph/ASO/ICANN%20ASO%20rapport%209911/ After this the address council as such has not done that much work, our eminent staff at the regionally registries are however driving the process forward and have been working to move things forward. The European part of the AC will thus meet with the RIPE NCC executive board next week to discuss how to proceed. There is however some items on the action lists that needs to be taken care of: LIR-34.4 Form a task force for documenting the existing policy process LIR.34.6 Form a task force to define final Address council selection procedure Sincerely, Hans Petter Holen Chair LIR-WG

1 0

RIPE 34 LIR WG Draft Minutes 1.0
by hph＠a.sol.no 19 Dec '99

19 Dec '99

Thanks to Eamonn for poduccing detailed minutes from our last meeting. Please feel free to mail me or the list comments or clearifications. RIPE 34 LIR-WG DRAFT Minutes 1.0 Chair: Hans Petter Holen Scribe: Eamonn McGuiness Agenda 1. Admin scribe distribute participants list charter mailing lists 2. Additional agenda points 3. Introduction of the new Registration Service Manager, Nurani Nimpuno Meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Regional Internet Registries 6. The RIPE community policy making process (Mirjam Kuhne, RIPE NCC) Discussion: Is this well understood? 7. ICANN - ASO Current status, further work. Definition of the selection procedure for the address council 8. Auditing Results and experiences (Mirjam Kuhne, RIPE NCC) 9. Discuss an additonal value for inetnum status attribute (James Aldridge, EUnet) 10. PGP authentication of e-mails to and from hostmaster(a)ripe.net (Maldwyn Morris, RIPE NCC) 11. Release of rtt source code (Maldwyn Morris, RIPE NCC) 12. AOB 12.1 IPv6 policy matters (move to LIR WG?) 12.2 mnt-by from mandatory to optional (Wilfried Woeber, ACONET) 12.3 PI address assignments to end-users (Eyal Yaniv, Netvision Ltd.) 12.4 DB support for multiple Domain objects 1. Admin Eamonn McGuiness volunteered to take notes. The participant list was circulated and signed by approximately 89 attendees. The Working group web pages and mailing list were pointed at: Mailing list: lir-wg(a)ripe.net Archive: http://www.ripe.net/mail-archives/lir-wg/index.html Web pages: http://www.ripe.net/wg/lir/index.html The Local IR working group deals with issues that concern Local Internet Registries. For example, Local IR operation, and the local implementation of RIPE policies and procedures are discussed here. There was consensus that we may need a better formulated charter stating that the LIR-WG is the open forum where RIPE policy is made. ACTION LIR-34.1 on Chair to suggest clarification of WG charter. 2. Agenda The agenda previously circulated to the lir-wg list, was approved and the following items were added to Any Other Business: Wilfried Woeber: RIPE NCC Auditing Activity Eyal Yaniv: PI Assignments 3. Presentation of RIPE Hostmasters The new Registration Services Manager Nurani Nimpuno was introduced. Paula Caslav left the RIPE NCC to go back to the US. Also all hostmasters present at the meeting were introduced to the audience. 4. Actions All actions from RIPE 32 were done before RIPE 33. There were no additional action points from RIPE 33. The WG minutes (published as part of the plenary minutes) from RIPE 32 were approved. 5. Reports from the Regional Internet Registries 5.1. Report from the RIPE NCC Registration Services Activities (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights of the developments since the last meeting: Beginning of the year almost 2 new members per calendar day. This has now slowed down, but is still higher than the last few years, approximately 1.5 new members per calendar day. Those new members tend to grow slower than members used to in the past. This means that the workload is not increasing proportionally to the number of new members. Due to automation and efficient procedures, there was no major staff increase even though the number of new members has grown. The RIPE NCC has started allocating IPv6 addresses, 6 sub-TLAs allocated so far, smooth start. The RIPE NCC proposes to change the procedures for reverse delegation such that only members can submit requests for reverse delegation. This would decrease the workload of the RIPE NCC and increase the quality of the DNS. This issue will further be discussed on the lir-wg mailing list to understand all aspects of such a change. This item was added to AOB for further discussion but due to time shortage it was concluded with the following action: ACTION LIR-34.2 on RIPE NCC to start discussion on changing the reverse delegation policies, and make sure all aspects of it are fully understood. The RIPE NCC is currently busy updating and improving the LIR Training Course material and delivery. This will be ready before the next RIPE Meeting. A few questions were raised after the presentation: Q: Is there a deadline for the change in procedure for reverse delegation? A: Before the end of the year: We are currently re-writing the inaddr robot and would like to implement this change at the same time. Comment: We need to think about the implications for address space originally assigned by last resort registries. Q: Test Traffic Measurement will be part of membership services in 2000. How will the RIPE NCC charge for it? A: It will be a different type of membership service than registration services, because the users are not necessarily the same. We are slowly moving TTM in this direction and need to further investigate an exact charging scheme for it. Q: Are all statistics shown during the presentation also visible on the web site and are they kept up to date? A: They will be stored on the web site as part of the presentation, but we will also put them on the statistics pages. ACTION LIR-34.3 RIPE NCC: store statistics on web site and keep them up to date. Q: Can we get support from the RIPE NCC for addresses that have been assigned by the InterNIC? A: Yes, you can, we currently provide administrative support for our members. We are also working on a more structural solution, so that the assignments are stored in the DB of the region the network is operated in, even if the addresses have been originally assigned by the InterNIC. We will also work together on a technical solution for a distributed reverse delegation. 5.2. Report from the APNIC (Kyoko Day) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Some highlights: IP distribution is growing in the region even though there was a dip due to the economic crisis in Asia. The growth during this year is mainly due growth in India and Australia. Priorities for the next period: review of the APNIC membership-charging scheme. Currently the categories Small, Medium, Large are self-determined (like the RIPE NCC charging scheme was before 1997). 5.3. Report from ARIN Unfortunately no one from ARIN could attend the Meeting. Mirjam Kuhne announces that ARIN will hold their AGM in October in conjunction with a first open policy meeting and the second meeting of ARIN WGs (18.10. - 20.10.1999) 5.4. Reports from other regions At the ICANN Meeting in Santiago in August ICANN welcomed the developments in Africa and Latin America. In Latin America various groups have been co-operating and form the LatinNIC, they proposed a draft paper, which they asked the existing RIRs to review. The Interim Board of the AfriNIC is currently reviewing proposals of potential AfriNIC hosts. 6. Policy Development in the RIPE community Mirjam Kuhne gave a presentation to describe how policy is developed in this region and how people can participate in this process. See http://www.ripe.net/meetings/ripe/ripe-34/pres/ for details. The process is simple, open to anyone and based on consensus. The WG Participants were in agreement that these are true open processes and that there is no need to change them. During the discussion that followed it became apparent that more effort must be spent to make the existence of RIPE known to the outside world and to clearly distinguish it from the RIPE NCC. A comment was made that the RIPE community and the RIPE NCC membership is mainly comprised of small ISPs and that the policies and guidelines are sometimes difficult to be implemented by larger ISPs. Hans Petter understands the concern, but has experienced that difficult or unusual cases were handled on a case by case bases usually solved in the end. The question was raised if there is a voting procedure to finalise agreements and policies? Hans Petter clarifies that there is normally general agreement and a voting procedure was not necessary. Someone thinks that people might be intimidated to speak up on the mailing list and that LIRs in particular might be afraid that their performance as LIR will be questions if they raise their opinion on the mailing list. Mirjam clarifies that the RIPE WG mailing lists are open and independent and not directly linked with the operations of the RIPE NCC and individual members. Maybe this needs to be made known more widely. ACTION LIR-34.4 on the Chair to form a Task Force to document and publish the current procedures for policy development. Volunteers to this task force were to contact the chair after the meeting. Further process will be: - announce the charter of the task force to the mailinglist - Interested parties may volunteer - A draft will be posted to lir-wg for discussion - A second draft will be based on that discussion - The document will be endorsed by consensus at RIPE 35 The outcome of this task force will be useful not only to the working group members but also externally to promote the openness of RIPE. 7. ICANN - ASO The LIR-WG needs to discuss and define the selection procedure for the RIPE region nominees of the ASO Address Council. The WG chair had asked Rob Blokzijl, the chair of RIPE, to chair this part of the discussion because the WG chair was among the nominees for the Address Council. This is the first time the RIPE community needs to define a procedure to select representatives to external bodies. This task is particularly difficult, because ICANN has introduced some time pressure: They would like to have ICANN directors elected by the beginning of October. As the ICANN directors are to be selected by the address council the address council needs to be selected at this very RIPE meeting. Therefor the carefully defined time schedules and deadline for the set up of the Address Council and the selection of the ICANN directors can not be followed. The RIPE community therefor needs to define an interim procedure for the initial set of Address Council members. In the time before the next RIPE meting the procedure needs to be revisited and refined. Each candidate submitted a paragraph to motivate why they think they are suitable for the Address Council. This has been made available on the RIPE Web pages and copied and distributed among the audience. 3 of the 8 nominees were present at the LIR-WG meeting. There was a discussion if the initial candidates should only serve one year or if they should be prepared to serve 1, 2 and 3 years as defined in the ASO MoU. The audience agrees that it would create instability if all members would change after one year and that they should serve 1, 2 and 3 years respectively. It was suggested that the address council at their own discretion may ask their seat to be reconfirmed by the procedures yet to be defined. This Q: Why was self-nomination was allowed. A: It is an open process, if a person believes he or she is a suitable candidate, why should he or she not nominate him or herself? Q: Can't we use the same procedure that is used for the RIPE NCC executive board? A: The problem is that the RIPE NCC membership is a clearly defined electorate, but in this case the electorate can not clearly be identified. The audience dismissed an e-mail selection process for many reasons. One was the time frame forced upon us, other being the too difficulty to verify correct votes. An attempt was made to find general criteria in order to make a possible pre-selection. Finally it was suggested to organise an open ballot at the plenary session. Gordon Lennox from DG-XIII, European Commission warned the WG not to fall into the trap of pure voting. He admires the open and transparent processes in the RIPE community and urges the audience to make sure to have some sort of consensus decision incorporated in the procedure, either before the voting or after to endorse the decision. ACTION LIR-34.5 on Rob Blokzijl to summarise this discussion and present it at the plenary session the following day. Several ideas for the final procedures were suggested: to look at USENET voting, the IETF procedures and the RIPE NCC Association procedures. These will be further discussed on the lir-wg list. ACTION LIR-34.6 on the Chair to form at task force to define final Address council selection procedure. 8. Auditing Activity at the RIPE NCC (Mirjam Kuhne) See http://www.ripe.net/meetings/ripe/ripe-34/pres/ Mirjam clarifies that this activity has been initiated by the LIR-WG in order to ensure fair distribution of address space. She shows statistics that have been derived after having performed this activity for more than a year now. In summary it can be noted that many LIRs are familiar with policies and procedures and apply them. One area of attention is the RIPE database. The RIPE NCC works together with LIRs to maintain and update the information in the database. There was some uncertainty regarding the role of the RIPE NCC member in this process. It was not clear to some attendees if the information provided by the end-user can or needs to be amended before passing on to the RIPE NCC. This is specifically related to documentation, which is provided in local language. After a short discussion it has been agreed that the RIPE NCC requires a certain set of documentation in English. It then depends on the service the LIR provides to their customers. Some LIRs may require their customers to provide the full set of documentation and in English, some LIR may just collect information from their customers (in the local language) and then amend and translate it if sent on to the RIPE NCC. ACTION LIR-34.7 on the RIPE NCC to document the audit procedure in more detail and to clarify the role of the NCC and the member during an audit process and what is expected from each party. 9. Additional value for the status attribute (James Aldridge) James suggests allowing for more hierarchy in the status attribute of the inetnum object. The rationale behind this is to allow "sub allocating" parts of a LIRs address blocks to "sub LIRs". This is important to large (multi national) ISPs. Also Wilfried Woeber is looking for additional values to indicate for instance returned address space that needs to be documented during transition to new. ACTION LIR-34.8 on James (and Wilfried) to write up a proposal and send it to the LIR-WG mailing list. 10. PGP authentication of mails to and from hostmaster(a)ripe.net (Maldwyn Morris, Software Manager RIPE NCC) The RIPE NCC would like to offer PGP authentication for mail sent to the hostmaster(a)ripe.net. In the first instance this will only be used for authentication, not for encryption. There is consensus in the WG that this would be a useful service. As other security mechanisms (e.g. in the RIPE DB) this will not be a requirement but optional. ACTION LIR-34.9 on RIPE NCC to proceed with plans to implement PGP as an option for hostmaster communication. 11. Release of rtt source code (Maldwyn Morris, Software Manager RIPE NCC) There is consensus in the LIR WG that the RIPE NCC may publish the source code of the rtt ticketing system software. ACTION LIR-34.10 on RIPE NCC Release source code to rtt due to demand. 12. Any Other Business 12.1 IPv6 policy matters In principle all address policy related matters should be handled in the LIR-WG. For this meeting the chair had decided not to include Ipv6 policy matters on the agenda, since the agenda already had possibly time-consuming items already. It was argued that participants interested in developing RIPE policy only should have to go to one working group. The chair agrees in principle, but also sees the advantages of keeping the policy discussions in the Ipv6 WG where Ipv6 expertise is sure to be present. It was questioned from the audience what the purpose of the Ipv6 WG would be if not to discuss Ipv6 policy. This was not made particularly clear, but a reference to the work division between the LIR-WG and the DB-WG was made: the policy discussions takes place in the LIR-WG while technical implementation details relating to the database takes place in the DB-WG and is implemented by the RIPE NCC. The chair feels it is premature to make a final decision on this, but senses coming consensus that LIR-WG should do policy development for IPv4 and IPv6. ACTION LIR-34.11 on Chair Discuss moving Ipv6 policy matters to lir-wg. 12.2 PI Assignments (Eyal Yaniv) Eyal wonders if end-users who require PI address space should become RIPE NCC members themselves in order to obtain address space directly from the RIPE NCC. Mirjam clarifies that although it is discouraged to assign PI addresses to end-users it is possible if technically required. These assignments should not be made out of the PA range allocated to the LIR; the RIPE NCC will make these assignments from a separate range in order to avoid holes in the PA range of the LIR. The desire to obtain PI addresses is not a reason in itself to become a RIPE NCC member and to obtain a separate allocation from the RIPE NCC. There was also a clarification to why use of PI addresses is discouraged: this relates to the additional burden that individual route entries for end-users create on the global Internet. The RIPE policy in this area has thus been carefully worded to promote PA addresses and CIDR. It is also worth noting that certain big US providers do not accept fragments of PA addresses from peering partners (but may do so in transit agreements). 12.3 Reverse delegation process -> discussion on lir-wg to fully understand all implications This came up during Mirjams report. Since we had no time left to further discuss the aspects of this it was added to the action list to conclude this discussion on the mailinglist. (See action LIR-34.3) 12.4 DB support for multiple Domain objects Was not discussed. It was suggested to move the discussion to the db wg. Actions: Action Owner Status Description LIR-34.1 Chair Suggest clarification of WG charter LIR-34.2 WG Reverse delegation process -> discussion on lir-wg to fully understand all implications LIR-34.3 NCC Store statistics on web site and keep them up to date. LIR-34.4 Chair Form a task force for documenting the existing policy process LIR-34.5 RB suggest a selection procedure for the plenary LIR.34.6 Chair Form a task force to define final Address council selection procedure LIR-34.7 NCC Clarify LIR-RIR expectations in the audit process LIR-34.8 JA additional value for the inetnum "status" field LIR-34.9 NCC Proceed with plans to implement PGP as an option for hostmaster communication LIR-34.10 NCC Release source code to rtt due to demand LIR-34.11 WG Discuss moving IPv6 policy matters to lir-wg Draft Agenda LIR WG RIPE 35 (as presented to the RIPE 34 plenary) 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters 4. RIPE 34 minutes actions 5. Reports from the Registries RIPE NCC APNIC ARIN Status of the Latin and AFRI NiCs 6. Report from the address council 7. The policy making process 8. Establish final selection procedure for the address council 9. Domain objects in the database 10. AOB

2 1

IP assignment for virtual webhosting
by Nurani Nimpuno 16 Dec '99

16 Dec '99

Dear LIR working group, We wish to thank you all for your constructive participation in the discussion regarding IP assignment for virtual webhosting. Your input has been valuable and contributive and we believe we now have a clear picture of the various views within the RIPE community. We will now, with your feedback, initiate a discussion with the other Regional Registries, ARIN and APNIC and will share the outcome with you as soon as some conclusions can be drawn. Thank you again for your participation. Kind regards, Nurani Nimpuno Registration Service Manager RIPE NCC

1 0

Top 100 Maintainers List 19991208
by RIPE Database Administration 08 Dec '99

08 Dec '99

1 0

RE:
by Bhabuta, Denesh 08 Dec '99

08 Dec '99

> A quick question does anyone have or know of any tools for > checking for > overlaps in the RIPE DB for a given range of addreses? The tool is called email. Send a request to RIPE and they will only be too happy to use their auditing software to send you the details of overlapping objects. :) Regards Denesh -- Denesh Bhabuta, AMISM European Internet Services Group Level (3) Communications Limited +44-20-7864-0498 ; denesh.bhabuta(a)level3.com

1 0