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

New RIPE Database features
by Andrei Robachevsky 07 Feb '02

07 Feb '02

Dear colleagues, [ Apologies for multiple messages ] The new features of the RIPE Database requested by the community are now available in "beta version" on our TEST whois server (http://www.ripe.net/ripencc/pub-services/db/testdb.html). The new features are: - the "irt" object (please see my previous announcement at http://www/ripe/mail-archives/db-wg/current/msg00012.html) - the new "status:" value of the inetnum object "LIR-PARTITIONED PA/PI" (please see the original proposal at http://www/ripe/mail-archives/db-wg/20010701-20020101/msg00090.html). You may try these features by - sending your updates to test-dbm(a)ripe.net; - querying the test-whois.ripe.net, port 43. The new version of the software is under heavy testing now and will be put into production shortly after the RIPE meeting. Your comments are appreciated. You may contact the development team directly at dbrip(a)ripe.net. Best regards, Andrei Robachevsky DB Group Manager RIPE NCC

2 4

ICANN ASO General Assembly Meeting Call for Presentations and Participation
by Richard Jimmerson 28 Jan '02

28 Jan '02

ICANN ADDRESS SUPPORTING ORGANIZATION ASO General Assembly Meeting Tuesday, March 5, 2002 Bangkok, Thailand CALL FOR PRESENTATIONS AND PARTICIPATION The Address Council of the Address Supporting Organization has announced the third ASO General Assembly meeting, to be held on Tuesday, March 5, 2002, in Bangkok, Thailand. This meeting will be hosted by APNIC alongside APNIC's Open Policy Meeting, and is open to all parties with an interest in the activities of the ASO. The ASO GA 2002 Program Committee is seeking interested individuals and organizations who would be willing to make presentations for the upcoming ASO General Assembly meeting. The presentations should relate directly to the mission of the ASO as stated in the ASO Memorandum of Understanding. The ASO responsibilities are comprised of the following areas: * Definition of global policies for the distribution and registration of Internet address space (currently IPv4 and IPv6); * Definition of global policies for the distribution and registration of identifiers used in Internet inter-domain routing (currently BGP autonomous system numbers); and * Definition of global policies concerning the part of the DNS name space which is derived from the Internet address space and the interdomain routing identifiers (currently in-addr.arpa and ip6.int). PROPOSAL SUBMISSION: Presentation proposals for the ASO General Assembly meeting should be sent by electronic mail to <secretariat(a)aso.icann.org> and contain the following information: * Presentation title * Name of presenter * Email address of presenter * Voice phone number of presenter * Organizational affiliation * Abstract of proposed presentation (125 words or less) * Time requested for presentation Presentation submission deadline: Wednesday, February 20, 2002 The ASO Program Committee will review the proposals and make appropriate additions to the draft agenda provided below. CONTACT INFORMATION: More information about the ASO and the ASO General Assembly can be found on the ASO web site at http://www.aso.icann.org/ Please feel free to contact the ASO secretariat at <secretariat(a)aso.icann.org> should you have any questions. ### Draft Agenda ### ICANN ASO General Assembly Meeting Bangkok, Thailand March 5, 2002 (1600 - 1900) Draft Agenda 1. AC operational update * Goals and achievements since last ASO GA * ASO secretariat change * New members on AC * Emerging RIRs status report 2. Overview of RIR policy process and status * Process and status in the APNIC region * Process and status in the ARIN region * Process and status in the RIPE NCC region 3. Global statistics presentation from the RIRs 4. Nominee introductions for the ASO elections to the ICANN Board Richard Jimmerson ASO Secretariat

1 0

Fwd: Revision of IPv4 policy doc - proposed timeline
by Nurani Nimpuno 23 Jan '02

23 Jan '02

Dear colleagues, Just a quick reminder that the first revision period of the IPv4 policy draft document, will end the coming Friday (25 January). The document which will replace the current RIPE document:"European Internet Registry Policies and Procedures" (ripe-185) is available at: http://www.ripe.net/rs/ipv4policy.html We encourage you to revise this document and to send any comments you may have to the <ripe-185bis(a)ripe.net> mailing list. Your input is essential, as this document describes all IPv4 policies to be implemented by the RIPE NCC and the LIRs in the RIPE NCC service region. Mirjam Kuhne <mir(a)ripe.net> will be co-ordinating the revision process, should you have any specific questions regarding the policy draft document. We look forward to your comments. Regards, Nurani Nimpuno RIPE NCC >Date: Fri, 11 Jan 2002 13:12:39 +0100 (CET) >From: Nurani Nimpuno <nurani(a)ripe.net> >To: <lir-wg(a)ripe.net> >Subject: Revision of IPv4 policy doc - proposed timeline > >Dear colleagues, > >We wish to draw your attention to the revision of the current IPv4 policy >document and the first draft, posted on the web in August 2001: > >http://www.ripe.net/rs/ipv4policy.html > >A few comments were gathered after the publication of the draft, as >summarised below: > >- ASN policy should be in a separate policy document. >- Further clarification of the "Static assignments for services that are >permanently connected to the Internet" possibly needed. >- Clarification of policy on registration of End-User contact details in >the RIPE db (with respect to privacy). >- Re-wording (re-clarification) of the Reverse Delegation policy section. > >The public mailing list <ripe-185bis(a)ripe.net> was set up to facilitate >the revision of this draft, but other than the comments listed above, >there has been very little activity. > >The IPv4 policy draft has now been publicly available for comments for >five months and I believe we are all keen to see a final version of this >document out soon. We would therefore like to propose the following >timeline to move forward with the publication of the new IPv4 policy >document: > >11-25 Jan : 1st revision period (2 weeks) > - Public call for comments >25 Jan-7 Feb: Editing by the RIPE NCC (2 weeks) > Comments to be incorporated by the RIPE NCC >7 Feb : 2nd draft to be published by the RIPE NCC >7 Feb-21 Feb: 2nd revision period (2 weeks) > - Public call for comments >21-28 Feb : Final editing by the RIPE NCC (1 week) >28 Feb : Final version of the policy document to be published. > >We welcome any input on this draft and encourage you to send your comments >to <ripe-185bis(a)ripe.net>. > >If you wish to subscribe to this mailing list, please send a mail to ><majordomo(a)ripe.net> with "subscribe ripe-185(a)ripe.net" (without quotation >marks) in the body of the message. The mailing list is also archived at: > >http://www.ripe.net/ripe/mail-archives/ripe-185bis/index.html > >Mirjam <mir(a)ripe.net> will be co-ordinating the revision process, should >you have any specific questions regarding the policy draft document. > >We hope that the proposed timeline is acceptable to everyone and we look >forward to your comments. > >Regards, > >Nurani Nimpuno >Internet Address Policy Manager >RIPE NCC

1 0

Fwd: Re: Status of IRT object
by Rogier Spoor 22 Jan '02

22 Jan '02

ls, When I read the mail below the irt objects should be available now, but it isn't working yet. Is there already a new planning about the release date of the irt objects? regards, Rogier >Delivered-To: lists-lir-wg-out(a)lists.ripe.net >X-Sender: joao(a)birch.ripe.net >Date: Mon, 7 Jan 2002 18:30:01 +0100 >To: Gabriella Paolini <gabriella.paolini(a)garr.it>, techsec-wg(a)ripe.net, > <db-wg(a)ripe.net>, <lir-wg(a)ripe.net> >From: Joao Luis Silva Damas <joao(a)ripe.net> >Subject: Re: Status of IRT object >Cc: info(a)cyberabuse.org, <philippe(a)cyberabuse.org>, <enzo.valente(a)garr.it> >Sender: owner-lir-wg(a)ripe.net >X-Loop-Detect: RIPE NCC > >Dear gabriella, > >if nothing unexpected happens, you will be able to look at irt objects in >the RIPE DB this week. > >Joao > > >At 18:26 +0100 7/1/02, Gabriella Paolini wrote: >>Dear all, >>which is the status of IRT object? >>Is the trial implementation available? >>This example shows again the need for a specific object. >>If someone uses whois information from cyberabuse.org, as many times >>people does, that information is wrong, because ciberabuse guys used >>Admin-c email without considering all other informations in inetnum >>object and in role object. >> >>Thanks and regards, >>Gabriella Paolini >>INFN-GARR >> >>[ Informations about 193.204.17.211 ] >> >>IP range : 193.204.16.0 - 193.204.23.255 >>Network name : UNIBAS-NET >>AS number : AS137 >>Infos : Universita' Degli Studi Di Basilicata >>Infos : Centro Interfacolta' Servizi Informatici E Telematici - Cisit >>Phone number : +39 06 49914352 >>Country : IT >>Abuse contact : enzo.valente(a)infn.it >>Source : RIPE >> >>right information are >> >>inetnum: 193.204.16.0 - 193.204.23.255 >>netname: UNIBAS-NET >>descr: Universita' degli Studi di Basilicata >>descr: Centro Interfacolta' Servizi Informatici e Telematici - >>CISIT >>country: IT >>admin-c: EV182-RIPE >>tech-c: GL965-RIPE >>tech-c: GM976-RIPE >>... >>remarks: To notify abuse mailto: cert(a)garr.it >>remarks: Multiple lan of university departments >>remarks: GARR - Italian academic and research network >>mnt-by: GARR-LIR >>... >> >>role: GARR LIR >>... >>trouble: To notify abuse mailto: cert(a)garr.it >>trouble: Information at http://www.lir.garr.it/ >>... >> >>person: Enzo Valente >>address: INFN - Dipartimento di Fisica >>address: Universita' La Sapienza >>address: Piazzale Aldo Moro,2 >>address: I-00185 Roma >>address: Italy >>phone: +39 06 49914352 >>fax-no: +39 06 4957697 >>e-mail: Enzo.Valente(a)infn.it >>... > > >-- > Account Management SURFnet bv t: +31 30 2 305 361 f: +31 30 2 305 329

2 1

RIPE-230
by Alan Sawyer 22 Jan '02

22 Jan '02

Hi All, I would like to raise a topic for discussion Re: recent changes to RIPE-230. Specifically, 3.2. Address Space requirements (see also http://www.ripe.net/ripencc/new-mem/flowchart3.html) In order to receive an initial allocation, an LIR needs to demonstrate either the utilisation of a minimum /22 (1024 addresses), or an immediate need for an assignment of at least a /22 . This can include your own infrastructure as well as your customers' networks that will be renumbered into your allocation == As a MSP we have many Enterprise customers who come to us for their colocation/remote hands needs. They also want reliable Internet, no point outsourcing if your data sits on an island. In the absence of a tested/reliable/accepted alternative, this means they want to Multihome. If they're sufficiently large we can process their application for PI space and send them on their way. However in a dedicated enterprise hosting environment many don't qualify, those that do are often not making a lot of use of their allocation once operational. We would like to offer a redundant multihome(ing) service, essentially creating an aggregation point for smaller clients and we take supply from our carriers who can focus on wholesale. This also services those that want small mb volume of traffic who generally aren't serviced by our colocated wholesale carriers because of the overheads vs revenue of servicing a mb or two. So: De-aggregating our /20 is not an option. Some providers filter. Taking the same set of suppliers, de-aggregating to them and having our upstream announce our aggregated block is not an option because of our footprint and our desire to be open in terms of suppliers. So to go forward we need to: 1. Register as an LIR at a country level (as we, as a single LIR do not qualify for multiple PA assignments under current assignment policy, even though this would be administratively easier for us) *OR* 2. leased line connectivity (and no, not a tunnel across multiple AS's!!) between each country which simply introduces another POF, another cost overhead and increases the possibility of blackholing parts of your AS if an inter-country link fails. (remembering that our advantage is we have all these carriers on our doorstep aka ODF) Justifying a /22 for immediate use is well, not possible. Customers won't wait to be provisioned until you have enough of them to use a /22 immediately. Last year we applied to RIPE for LIR status and it was granted. If this were still last year I'd do the same at a country level. However now RIPE-230 prevents this.... Possible (to bounce around) solutions are: Use other quantitative methods for approving LIR status, i.e. what resources/capital investment will an LIR put into to ensuring their growth over a period. aka 'the put your money where your mouth is' metric. && Remove 3.2 from RIPE-230. *OR* Allow a PA allocation of /21 and Remove 3.2 from RIPE-230 <lowers risk of waste should LIR be slow to reach expectations, also as the PA space exists in a LAN/MAN environment moving to /20 announcement later is trivial, no real migration.> *OR* Allow LIR to use PI space for locally colocated customers provided they are in a situation to pull the plug. (service operator) - (possible flamebait, do we want more prefix's with less un-utilized space *or* less prefix's with higher un-utilized space in the short term? -- also migrating enterprise hosting clients from PI to PA later is hell, I imagine many will take the easy route and not bother until sufficiently pressured by RIPE/community.) Would appreciate a constructive dialog on how this can be achieved. With Thanks. Alan.

1 0

Fw: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy
by Stuart Prevost 17 Jan '02

17 Jan '02

FW: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global PolicyAll, I have send this to this lists as the global-v6 lists does not seem to be working. Regards, Stuart ----- Original Message ----- From: Stuart Prevost To: stu(a)prevost.net Sent: Friday, January 11, 2002 7:32 PM Subject: Re: [GLOBAL-V6] New draft available: IPv6 Address Allocation and Assignment Global Policy Dear all, Please find enclosed comments on new draft enclosed in text below. I an unable to attend the RIPE meeting next week in Amsterdam, but Paul Mylotte will comment on the comments in this mail at the meeting. Regards, Stuart IPv6 Address Allocation and Assignment Global Policy Draft of December, 22 2001 Version 2001-12-22 APNIC ARIN RIPE - NCC Status of this Memo This document specifies "Internet best current practices" for the Internet community, and requests discussion and suggestions for improvements. Distribution of this document is unlimited as long as its contents remain unchanged. Comments on this document should be sent to the global-v6 mailing list: To post: <global-v6(a)lists.apnic.net>. To subscribe: <http://www.apnic.net/net_comm/lists/> Archives: <http://www.apnic.net/mailing-lists/global-v6> Contents Status of this Memo.......................................... 1 1. Introduction............................................. 2 1.1. Overview............................................ 2 1.2. Current Status...................................... 3 2. Definitions.............................................. 4 2.1. Autonomous System (AS).............................. 5 2.2. Internet Registry (IR).............................. 5 2.3. Internet Assigned Numbers Authority (IANA).......... 5 2.4. Regional Internet Registry (RIR).................... 6 2.5. National Internet Registry (NIR).................... 6 2.6. Local Internet Registry (LIR)....................... 6 2.7. Allocate............................................ 6 2.8. Assign.............................................. 6 2.9. Utilization......................................... 7 2.10. Site............................................... 7 3. Goals of IPv6 address space management................... 7 3.1. Goals............................................... 7 3.2. Uniqueness.......................................... 8 3.3. Registration........................................ 8 3.4. Aggregation......................................... 8 3.5. Conservation (Stewardship).......................... 9 3.6. Fairness............................................ 9 3.7. Minimize Overhead................................... 9 3.8. Conflict of goals................................... 9 4. IPv6 Policy Principles................................... 10 4.1. Address space not to be considered property......... 10 4.2. Routability not guaranteed.......................... 11 4.3. Minimum Allocation.................................. 11 4.4. Consideration of IPv4 Infrastructure................ 12 5. Policies for allocations and assignments................. 12 5.1. Consistency of IR address space management policies. 12 5.2. Initial allocation.................................. 12 5.2.1. Initial allocation criteria.................... 12 5.2.2. Initial allocation size........................ 13 5.3. Subsequent allocation............................... 13 5.3.1. Subsequent allocation criteria................. 13 5.3.2. Utilization Metric............................. 13 5.3.3. Applied HD-Ratio............................... 14 5.3.4. Subsequent Allocation Size..................... 14 5.4. LIR-to-ISP allocation............................... 14 5.5. Assignment.......................................... 15 5.5.1. Assignment address space size.................. 15 5.5.2. Assignment to a site........................... 15 5.5.3. Assignment of multiple /48s to a single site... 15 5.5.4. Assignment to operator's infrastructure........ 15 5.6. DB registration..................................... 16 5.7. Reverse lookup...................................... 16 5.8. Validity of allocations and assignments............. 16 5.9. Existing IPv6 address space holders................. 17 6. Special case............................................. 17 6.1. IX (Internet Exchange).............................. 17 7. Acknowledgment........................................... 17 8. References............................................... 18 9. Appendix A:.............................................. 19 1. Introduction 1.1. Overview This document describes policies for the allocation and assignment of globally unique Internet Protocol Version 6 (IPv6) address space. In particular, [RFC2373, RFC2373bis] designates 2000::/3 to be global unicast address space that IANA may allocate. In accordance with [RFC2928, RFC2373bis, IAB-Request], IANA has assigned initial ranges of global unicast IPv6 address space from the 2001::/16 address block to the existing RIRs. This document concerns the initial and subsequent allocations of the 2000::/3 unicast address space, for which RIRs formulate allocation policies. Because end sites will generally be given /48 allocations [RFC 3177, RIRs-on-48s], the particular emphasis of this document is on policies relating the bits within 2000::/3 to the left of the /48 boundary. However, since some end sites will receive /64 and /128 allocations, all bits to the left of /64 are in scope. This document updates and replaces all the guidelines and procedures of the existing Provisional IPv6 Policies [RIRv6-Policies] based on over two years of experience with the 1999 policy. The Provisional IPv6 Policy document will be obsoleted with the adoption of this document. Address policies should be globally uniform and formulated in a bottom-up manner through consensus processes at regional and global levels. Address policies must be determined with well-balanced consideration given to not only technical constraints and the expectations of the Internet community, but also to the operational needs of ISPs and end users. Furthermore, the policies should be reviewed whenever necessary in accordance with changes in the external environment or operational experience of the relevant communities. Policies described in this document are global in nature and are intended to be followed in each registry. However, adoption of this document does not preclude local variations in each region or area. This policy is also considered an interim policy in the sense that there is still little experience with allocating IPv6 addresses. As experience from implementing the policy is gained, some aspects of the policy will likely need review and updating. 1.2. Current Status The APNIC meeting held in Taiwan in August 2001 discussed policies relating to IPv6 address allocation and assignment and reached a certain consensus. Afterward, similar suggestions were made at a RIPE meeting held in October 2001 and an ARIN meeting held in the same month. Various discussions were held at these meetings, with consensus identified on a number of points. This document makes a proposal based upon the results of discussions at these meetings. In all of these meetings, the participants recognized an urgent need for more detailed, complete policies in the Asia Pacific Region governing global IPv6 address space management. It was generally recognized that discussion about policies for IPv6 allocation and assignment will not easily come to an end, but there is a consensus that such discussion should be summed up quickly to establish interim policies. Accordingly, this document should be considered as a time- limited public document that describes the most reasonable solution available at present that has been obtained through these discussions. This document will therefore be duly updated as the Internet environment of IPv6 progresses, and it is expected that updates will occur relatively frequently in the coming years. This document does not provide details of discussions concerning individual policy issues, however the following sources provide background information which may be of interest: Meeting results: <http://www.apnic.net/meetings/12/results/> <http://www.ripe.net/ripe/meetings/archive/ripe-40/minutes.html> <http://www.arin.net/minutes/ARIN_VIII/PPM.html> Presentation Materials: <http://www.apnic.net/meetings/12/docs/prop_new_ipv6_policy.ppt> <http://www.apnic.net/meetings/12/docs/ipv6principles-dist.ppt> <http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/> <http://www.arin.net/minutes/ARIN_VIII/PPM.html> 2. Definitions [note: some of these definitions will be replaced by definitions from other RIR documents in order to be more consistent.] The following terms and their definitions are of particular importance to the understanding of the goals, environment, and policies described in this document. Responsibility for management of IPv6 address spaces is distributed globally in accordance with the hierarchical structure shown below. +--------+ | IANA | +--------+ | +-----------+-----------+ | | | +--------+ +--------+ +--------+ | RIR | | RIR | | RIR | Regional Internet +--------+ +--------+ +--------+ Registries | +-----------+--+--------+ | | | | +-----+ +-----+ | | NIR | | NIR | National Internet | +-----+ +-----+ Registries | | | +--------+ +--------+ +--------+ |LIR/ISP | |LIR/ISP | |LIR/ISP | Local Internet +--------+ +--------+ +--------+ Registries | | | +---------+ | | | | | | +-------+ +----+ +----+ +----+ |EU(ISP)| | EU | | EU | | EU | End users +-------+ +----+ +----+ +----+ 2.1. Autonomous System (AS) Autonomous Systems are the unit of routing policy in the world of exterior routing, and are specifically applicable to protocols like BGP [RFC1771]. 2.2. Internet Registry (IR) An Internet Registry (IR) is an organization that is responsible for distributing IP address space to its members or customers and for registering those distributions. IRs are classified according to their primary function and territorial scope within the hierarchical structure depicted in the figure above. 2.3. Internet Assigned Numbers Authority (IANA) The Internet Assigned Numbers Authority (IANA) has responsibility for management of the entire IP address space used on the Internet. Actual assignment operations are performed by organizations under IANA. Rather than allocating or assigning address space to operational networks, the IANA delegates responsibility for large blocks of address space to Regional Internet Registries, for management at the regional level. 2.4. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. Currently, there are three RIRs: APNIC, RIPE NCC, and ARIN. Preparations are being made to establish LACNIC and AfriNIC. 2.5. National Internet Registry (NIR) A National Internet Registry (NIR) is an IR that primarily allocates address space to its members, which are Local Internet Registries (LIRs). NIR members are generally Internet Service Providers (ISPs) organized at a national level. A NIR is constituted from ISPs, but the NIR itself does not function as an ISP. NIRs are expected to remain neutral to the interests of ISPs of their constituency. NIRs exist mostly in the Asia Pacific Region. 2.6. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. 2.7. Allocate To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. 2.8. Assign To assign means to designate address space that an IR distributes part or all of to an end user for the purpose of actual deployment in that end user's or ISP's own network. Address space is also designated as assigned if the IR uses it for the purpose of addressing their own network. Assignments are made only for specific purposes demonstrated by specific organizations and are not be sub- allocated or sub-assigned to other parties. In this hierarchical structure, IANA allocates address space to RIRs for the purpose of redistribution. RIRs then allocate address space to NIRs or LIRs in their respective regions (or in some cases to NIRs which further allocate the space to LIRs within their own countries). Each NIR allocates address space to LIRs in its own country. When an RIR or NIR allocates address space to an LIR, it also delegates to the LIR the authority to assign addresses to end users. 2.9. Utilization Unlike IPv4, IPv6 generally assigns a /48 to each end site. The actual utilization of any particular /48, when compared to IPv4 , will be extremely low. In IPv6, the "utlization" that is of interest refers to the bits to the left of the /48. Throughout this document, the term utilization refers to the allocation of /48s to end sites, and not the utilization of those /48s within those end sites. 2.10. Site A site is defined as an end user (subscriber) who has a business relationship with a provider that involves that provider carrying its traffic. Every end user (subscriber) individually on a contract with an ISP is considered an entity and is eligible to receive a /48 IPv6 assignment, regardless of organization or geographical location. 3. Goals of IPv6 address space management 3.1. Goals The goals of address space management described here reflect the mutual interest of all members of the Internet community and ensure that the Internet is able to function and grow to the maximum extent possible. Address policies must be determined with well-balanced consideration given to not only technical constraints and the expectations of the Internet community but also to the operational needs of ISPs and end users. These goals are essentially the same as the goals in IPv4 policies that have been formulated by the Internet community. However, attention must be paid to the fact that differences between IPv6 and IPv4 change the relative priority of elements that must be considered to attain these goals. 3.2. Uniqueness Every assignment and/or allocation of address space must guarantee uniqueness worldwide. This is an absolute requirement for ensuring that every public host on the Internet can be uniquely identified. 3.3. Registration Every assignment and allocation of Internet address space must be registered in a public registry database accessible to all members of the Internet community. Which database is this referring to ? Each RIR database? This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to end users. Are we talking /48s /64s and /128s? It also reflects the expectation of the Internet community that all users of public resources, such as address space, should be able to check the conditions of the resources. What does "conditions of the resource" mean? 3.4. Aggregation Wherever possible, address space should be distributed in a hierarchical manner, according to the topology of network infrastructure. This is necessary to permit the aggregation of routing information and limit the expansion of Internet routing tables. With its vast address space, IPv6 makes hierarchical distribution for aggregation much easier than IPv4. The IPv6 specification creates a huge address space, and the number of hosts under internal routing control of an individual autonomous system is expected to increase dramatically compared with IPv4. For example, cellular phones, various electric appliances, and telemeter sensors, are likely to become connected to the Internet in addition to the conventional types of IPv4 hosts. Thus, hierarchical distributions must be considered to limit the expansion of routing tables regarding not only external routing information advertised in the Internet default-free zone but also internal routing information within an autonomous system. Because internal aggregation is important, policies should be sensitive to supporting better internal aggregation (e.g, through assignment of bigger blocks). 3.5. Conservation (Stewardship) Maintaining unnecessary allocations and assignments or stockpiling address space with no aggregation merit should be avoided as a matter of course. Also, efforts must be made for the efficiency of address use as much as possible within the bounds of other constraints. 3.6. Fairness All policies and practices relating to the use of public address space should apply fairly and equitably to all existing and potential members of the Internet community, regardless of their location, nationality, size or any other factor. 3.7. Minimize Overhead It is desirable to minimize the overhead associated with obtaining additional address space as a site grows. Overhead includes the need to go back to RIRs for additional space too frequently, the overhead associated with managing address space that grows through a number of small successive incremental expansions rather than through fewer, but larger, expansions, etc. This para talks about trying to minimize overhead as a site grows, but if a site is allocated a /48 and needs an additional /48 for expansion then according to 5.5.3 The LIR whose customers needs an additional /48 request needs to be reviewed at the RIR/NIR level. Is this really minimizing overhead!! Maybe this section needs more text and a reference to 5.5.3? 3.8. Conflict of goals The goals of conservation, aggregation and minimization of administrative overhead often conflict with each other. In IPv6 address management, the six goals described above are given different priorities from the implicit priorities of IPv4 address management. IPv6 address management should give higher priority to aggregation and lower priority to address conservation, when compared with current IPv4 management practices. This does not mean that wasteful address usage should be tolerated because vast address space is available. Instead, emphasis is placed on the need for policies that place aggregation in higher priority so that the number of external and internal routes will be practically limited in the large address space to ensure stable Internet operations for a long time to come. Emphasis on aggregation sometimes leads to somewhat lower priority on address conservation because these two goals tend to conflict with each other. It should be noted that an exclusive choice between aggregation and conservation will not be made on the basis of the policies or judgment of any registry practices in accordance with these policies. Both aggregation and conservation should be taken into consideration in the right balance. In IPv6, the right balance is generally "more aggregation, less conservation". The balance between aggregation and conservation will be reviewed over time according to various factors, such as operational experience and address consumption. Some or all of the goals described here may occasionally be in conflict with the interests of individual IRs or end users. Therefore, all IRs evaluating requests for allocations and assignments must make judgment, seeking to balance the needs of the applicant with the needs of the Internet community as a whole. The policies described in this document are intended to help IRs balance these needs in consistent and equitable ways. Full documentation of and transparency within the decision making process must also be maintained in order to achieve this result. 4. IPv6 Policy Principles To address the goals described in the previous section, the policies in this document discuss and follow the basic principles described below. 4.1. Address space not to be considered property It is contrary to the goals of this document and is not in the interests of the Internet community as a whole for address space to be considered freehold property. The global IPv6 policies in this document are based upon the understanding that address space is lease-licensed for use rather than owned. All Internet Registries are expected to manage address space operations correctly in accordance with this principle. According to this policy, IP addresses will be allocated on a lease- license basis, with such lease-licenses to be of specific limited duration of normally one year. Conditions of a lease-license have specific conditions applied at the start or renewal of the lease. Lease-licenses will typically be renewed automatically at the end of their duration when the following two conditions are met: a) The original basis of the allocation remains valid. b) Registration requirements relating to that allocation have been fulfilled at the time of renewal However, when a lease-license is renewed, the new lease-license will be evaluated under and governed by the applicable resource allocation and renewal policies in place at the time of renewal. It is not clear what "resource allocation and renewal policies" are exactly. There is no definition of them in this document. Sounds like we are moving towards the way the DNS system works with the renewal of Domain Names. Changes to the conditions of current lease-licences shall be subject to a definite period of notice, except in exceptional circumstances recognized by a consensus of the Internet community. As address space is not owned, and consistent with the desire to avoid excessive fragmentation of address space, it may become necessary in extreme circumstances to renumber assignments. Such renumbering will only be undertaken after extensive consultation with the Internet community. 4.2. Routability not guaranteed Because IPv6 is fundamentally based upon aggregatable addresses, its circumstance differs from IPv4, which contains a number of non- provider-based assignments for historical reasons. Nonetheless, registries are not responsible for routability, which is affected by the technical implementation by LIRs/ISPs. RIRs must take steps, however, to ensure that allocations they make will not result in excessively fragmented address space, as that may lead to loss of routability. 4.3. Minimum Allocation As under current IPv4 management policies, it is proposed that IPv6 policies establish a "minimum allocation" of address space, which serves to limit the distribution by Internet Registries of portable address prefixes. Generally speaking, making minimum allocation size too small leads to address fragmentation, and making the size too large lowers the efficiency of address use. Discussion about the appropriate size of allocation needs to be continued in the future. The interim policies adopt the following concept: First, a minimum address space (/32) will be provided by default by RIR/NIR to LIRs. However, many large providers will quickly deplete a /32 space and need to use more address space within a short time. For this reason, providers requiring space larger than a /32 may request more address space, but must provide justification for such a request. 4.4. Consideration of IPv4 Infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used as a reason for requesting more space in justifying IPv6 address space requests. This is based upon the implicit assumption that service providers having a large number of IPv4 customers are likely to have many customers in IPv6 as well. This assumption should be evaluated and reviewed on the next occasion of revising the policies. 5. Policies for allocations and assignments 5.1. Consistency of IR address space management policies All Internet Registries shall adopt policies that are consistent with the policies formulated by the Internet community and described in this document. 5.2. Initial allocation 5.2.1. Initial allocation criteria A requesting organization can receive an initial allocation by demonstrating that it has an immediate (i.e., within next three months) requirement for at least a /36 prefix. That is, immediately after the allocation, the organization will have 776 or more sites in need of address assignments. 776 is the number of /48 address blocks that can be assigned out of a /36 address block to achieve an HD- Ratio of 0.8. The HD-Ratio is an address allocation utilization metric proposed in RFC 3194 as an adaptation of the H-Ratio originally defined in [RFC1715]. (See also Section 5.3.3.) This para now mention 3 months, but this is too short a time to connect 776 customer sites. It is not obvious what the new time frame should be, but it should be longer than 3 months. [Note: discussion is needed as to whether justification for need of a /36 is reasonable initial starting point, or whether the criteria of an immediate need to address 776 sites is too high. Note also, that once a request for an initial allocation has been granted, the minimum allocation (i.e., /32) is provided, even though the requestor has not justified a need for such a large amount of space.] 5.2.2. Initial allocation size A requesting organization satisfying the initial allocation criteria can receive an initial allocation of the minimum /32 address block. Any organization requesting a larger address block may receive the necessary size of allocation by submitting documentation that reasonably justifies the necessity. For instance, a provider or an enterprise currently providing IPv4 address services may apply for and receive an initial allocation of the size reasonably judged necessary to provide all the existing users with IPv6 services. In this case, the necessary size will be judged on the basis of the number of existing users and infrastructure. Shouldn't this be that the IPv4 provider should be allocated an initial allocation for its IPv4 customers PLUS the next 2 years growth, as in 5.3.4. Otherwise we will have the scenario where an IP v4 provider switches to IPv6, and changes its customers over to IPv6 and then has to go back to the RIR to request an additional block for its new IPv6 customers. Suggest that the "2 year rule" should be applied here also. This can be represented by the following expression: S(0) = shorter(/32, eval(required prefix size)) where (required prefix size) is the prefix size of applicant requesting allocation 5.3. Subsequent allocation An organization (ISP/LIR) that has already received an address block from an RIR/NIR may receive a subsequent allocation in accordance with the following policies. 5.3.1. Subsequent allocation criteria Subsequent allocation will be provided when an organization (ISP/LIR) satisfies the evaluation threshold of past address utilization in terms of the number of sites in units of /48 assignments. The HD- Ratio is used to assess the utilization of the existing address block as described below. 5.3.2. Utilization Metric In general, HD-Ratio [RFC3194] is expressed as follows: Log (number of allocated objects) HD = ------------------------------------------------ Log (maximum number of allocatable objects) where the objects are IPv6 site addresses (/48s) assigned from an IPv6 prefix of length P. The utilization threshold T, expressed as a number of individual /48 prefixes to be allocated from IPv6 prefix P, can be calculated as: ((48-P)*HD) T = 2 Thus, the utilization threshold for an organization requesting subsequent allocation of IPv6 address block is specified as a function of the prefix size and target HD ratio. This utilization refers to the allocation of /48s to end sites, and not the utilization of those /48s within those end sites. It is an address allocation utilization ratio and not an address assignment utilization ratio. 5.3.3. Applied HD-Ratio A desirable HD-Ratio for evaluation is thought to lie between 0.80 and 0.85, with the actual value needing to be determined as experience is gathered from implementation of this policy. An HD- ratio of 0.8 is adopted for this interim policy. The value may change in response to implementation experience. 5.3.4. Subsequent Allocation Size The size of an "n"-th time subsequent allocation S(n) is found as: S(n) = shorter(S(n-1)-1, eval(two_years_req)) where S(n-1)-1 represents one bit shorter prefix address block size of the previous allocated address block size, and eval(two_years_req) represents the evaluation of two-year demands of the requesting organization. In other words, an organization (ISP/LIR) satisfying the criteria can receive at least one bit shorter prefix automatically. If an organization needs more address space, it needs to demonstrate its two-year demand to an RIR/NIR. Then, the RIR/NIR evaluates it and allocates the address prefix enough to satisfy its two-year requirements. 5.4. LIR-to-ISP allocation There is no specific policy for an organization (ISP/LIR) to allocate address space to subordinate ISPs. Each LIR organization may develop its own policy for subordinate ISPs to encourage optimum utilization of the total address block allocated to the LIR. However, the LIR is required to keep track of all /48s assignments, including assignments made by its subordinate ISPs to end users, and report the assignment status to RIR/NIR so that the HD-Ratio can be evaluated when a subsequent allocation becomes necessary. Here the text implies that the LIR should keep track of all subordinate allocations, which means that if an LIR allocates a block to a subordinate ISP then the LIR needs to keep track of all the /48s that the subordinate ISP allocates to its own customers. Then, when the LIR requests a larger allocation, that same LIR needs to report these allocations to RIR/NIR so that the RIR/NIR can then calculate the subsequent allocation. However, earlier in "3.3. Registration" it says that "Every assignment and allocation of Internet address space must be registered in a public registry database accessible to all members of the Internet community" It also talks about registration in 5.6 see below. This registration question needs clarifying - the document contradicts itself. Currently in IPv4, addresses are registered in either a public database or in the LIR's own database, thus allowing a mixture. Thus, if we need to keep our customer information private, we can keep it "off" a public database, but if the customer does want to be seen in the public database then we can enter it. Suggest the same principle needs to be applied to IPv6. 5.5. Assignment This section describes the assignment policy. 5.5.1. Assignment address space size Address space following the 64th bit is the IETF boundary [RFC2460]. Address space following the 48th bit is a policy boundary, with IETF recommendations [RFC3177] and RIR agreement [RIRs-on-48] recommending the assignment of: - /48 in the general case, except for very large subscribers - /64 when it is known that one and only one subnet is needed by design - /128 when it is absolutely known that one and only one device is connecting. RIRs/NIRs are not concerned about which address size an LIR/ISP actually assigns. Accordingly, RIRs/NIRs will not request the detailed information on user networks as they did in IPv4, except for the cases described in Section 4.4. and for the purposes of measuring utilization as defined in this document. 5.5.2. Assignment to a site 5.5.3. Assignment of multiple /48s to a single site When a single site requires an additional /48 address block, it can request the assignment with documentation or materials that justify the request. Requests for multiple or additional /48s will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. 5.5.4. Assignment to operator's infrastructure An organization (ISP/LIR) may assign a /48 per PoP as the service infrastructure of an IPv6 service operator. Each assignment to a PoP is regarded as one assignment regardless of the number of users using the PoP. On the other hand, a separate assignment can be obtained for the in-house operations of the operator. 5.6. DB registration When an organization in reciept of an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a public database (initially a database maintained by an RIR/NIR, which may be replaced by a distributed database for registering address management information in future). Information is registered in units of assigned /48 networks. When an organization assigns an address space larger than a /48 to another organization, it must monitor if this organization has registered address utilization information in a public database. This para talks about an organization (LIR) assigning an address space larger than a /48 to another organization. In this case it implies that the other organization (NOT THE LIR) must register its /48's in a public database and that the LIR must ensure that the other organization has done this. But section 3.3 implies that every allocation be an a public database, and section 5.4 implies that it is not. RIR/NIRs will use registered data to calculate the HD-Ratio at the time of application for subsequent allocation and to check for changes in assignments over time. Each registry shall handle personal information with ultimate care. Concrete methods of protecting personal data shall be in accordance with privacy policies of each RIR/NIR (e.g., assign providers as tech-c or admin-c, divide an address in the middle, etc.). 5.7. Reverse lookup When an RIR/NIR delegates IPv6 address space to an organization, it also delegates the right to manage the reverse lookup zone that corresponds to the allocated IPv6 address space. Each organization should properly manage its reverse lookup zone. When making an address assignment, the organization must delegate to an assigned organization, upon request, the right to manage the reverse lookup zone that corresponds to the assigned address. 5.8. Validity of allocations and assignments An allocation or assignment of address space is valid only so long as the original criteria on which the allocation or assignment was based continues to be valid. If an allocation or assignment is made for a specific purpose, but the original purpose or original justification no longer applies, the allocation or assignment shall become invalid. If an allocation or assignment is based on information that is found to be false or incomplete, the allocation or assignment shall become invalid. Invalid allocations shall be returned to the appropriate IR. 5.9. Existing IPv6 address space holders Once the policies described in this document have been adopted, an organization already receiving an allocation according to the "PROVISIONAL IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT" [RIRv6-Polices] is immediately eligible to having its allocation expanded to a /32 address block. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document. 6. Special case Special considerations will be given to the cases described below, with no regard to the provision of this document. Individual RIRs are currently discussing policies for these cases independent of this document. 6.1. IX (Internet Exchange) An IX is a point at which ISPs connect with one another. It requires ISP-independent addresses. 7. Acknowledgment The initial version of this document was produced by The JPNIC IPv6 global policy drafting team consisting of Akihiro Inomata, Akinori Maemura, Kosuke Ito, Kuniaki Kondo, Takashi Arano, Tomohiro Fujisaki, and Toshiyuki Yamasaki. Special thanks goes out to this team, who worked over a holiday in order to produce an initial document quickly. An editing team was then organized by representatives from each of the three RIRs (Takashi Arano, Chair of APNIC's Policy SIG, Thomas Narten, Chair of ARIN's IPv6 WG, and David Kessens, Chair of RIPE- NCC's IPv6 WG). The editing team would like to acknowledge the contributions to this document of Takashi Arano, John Crain, Steve Deering, Kosuke Ito, Richard Jimmerson, David Kessens, Mirjam Kuehne, Anne Lord, Jun Murai, Paul Mylotte, Thomas Narten, Ray Plzak, Paul Wilson and Wilfried Woeber. 8. References [RFC1715] "The H Ratio for Address Assignment Efficiency", C. Huitema. November 1994, RFC 1715. [RFC1771] "A Border Gateway Protocol 4 (BGP-4)", Y. Rekhter, T. Li. March 1995, RFC 1771. [IAB-Request] "Email from IAB to IANA", [XXX need better reference]. See IAB Minutes, Dec. 12, 1998, <ftp://ftp.iab.org/in>- notes/IAB/IABmins/IABmins.981208, <ftp://ftp.iab.org/in>- notes/IAB/IABmins/IABmins.990112. [RFC2373] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. July 1998, RFC 2373. [RFC2373bis] draft-ietf-ipngwg-addr-arch-v3-07.txt. [RFC2460] "Internet Protocol, Version 6 (IPv6) Specification", S. Deering, R. Hinden. December 1998, RFC 2460. [RFC2780] "IP Version 6 Addressing Architecture", R. Hinden, S. Deering. July 1998. RFC 2373. [RFC2928] "Initial IPv6 Sub-TLA ID Assignments", R. Hinden, S. Deering, R. Fink, T. Hain. September 2000, RFC 2928. [RFC3177] "IAB/IESG Recommendations on IPv6 Address". IAB, IESG. September 2001, RFC 3177. [RFC3194] "The H-Density Ratio for Address Assignment Efficiency An Update on the H ratio", A. Durand, C. Huitema. November 2001, RFC 3194. [RIRs-on-48] <http://www.arin.net/minutes/bot/bot08152001.html>, XXX fill in. [RIRv6-Policies] <http://www.arin.net/regserv/ipv6/ipv6guidelines.html>, <http://www.ripe.net/ripe/docs/ripe-196.html>, <http://www.apnic.net/docs/drafts/ipv6/ipv6-policy-280599.html>. 9. Appendix A: In accordance with the recommendations of "The Host-Density Ratio for Address Assignment Efficiency: An update on the H ratio" [RFC 3194], it is proposed in this draft to adopt an HD-Ratio of 0.8 as the utilization threshold for IPv6 address space allocations. The following table provides equivalent absolute and percentage address utilization figures for IPv6 prefixes, corresponding to an HD-Ratio of 0.8 P 48-P Total /48s Threshold Util% 48 0 1 1 100.0% 47 1 2 2 87.1% 46 2 4 3 75.8% 45 3 8 5 66.0% 44 4 16 9 57.4% 43 5 32 16 50.0% 42 6 64 28 43.5% 41 7 128 49 37.9% 40 8 256 84 33.0% 39 9 512 147 28.7% 38 10 1024 256 25.0% 37 11 2048 446 21.8% 36 12 4096 776 18.9% 35 13 8192 1351 16.5% 34 14 16384 2353 14.4% 33 15 32768 4096 12.5% 32 16 65536 7132 10.9% 31 17 131072 12417 9.5% 30 18 262144 21619 8.2% 29 19 524288 37641 7.2% 28 20 1048576 65536 6.3% 27 21 2097152 114105 5.4% 26 22 4194304 198668 4.7% 25 23 8388608 345901 4.1% 24 24 16777216 602249 3.6% 23 25 33554432 1048576 3.1% 22 26 67108864 1825677 2.7% 21 27 134217728 3178688 2.4% 20 28 268435456 5534417 2.1% 19 29 536870912 9635980 1.8% 18 30 1073741824 16777216 1.6% 17 31 2147483648 29210830 1.4% 16 32 4294967296 50859008 1.2% 15 33 8589934592 88550677 1.0% 14 34 17179869184 154175683 0.9% 13 35 34359738368 268435456 0.8% 12 36 68719476736 467373275 0.7% 11 37 137438953472 813744135 0.6% 10 38 274877906944 1416810831 0.5% 9 39 549755813888 2466810934 0.4% 8 40 1099511627776 4294967296 0.4% 7 41 2199023255552 7477972398 0.3% 6 42 4398046511104 13019906166 0.3% 5 43 8796093022208 22668973294 0.3% 4 44 17592186044416 39468974941 0.2% DRAFT [Page 20]

3 3

Revised LIR WG Agenda (now using the surplus IPv6 WG slots)
by James Aldridge 15 Jan '02

15 Jan '02

To give more time and to move the IPv6 policy section so it doesn't clash with the joint IPv6/Routing session, I've revised the LIR WG agenda. As David Kessens estimates that the IPv6 WG will only take about 30 minutes, we'll now start the IPv6 policy stuff immediatly after the IPv6 WG is over and use the rest of the time originally allocated for IPv6. The morning sessions are in the Grand Ballroom, the afternoon sessions are in St John's Room II. Regards, James ---------- LIR WG @ RIPE41 - 16 Jan 2002 Draft Agenda (rev 2) 09:00-10:30 A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 minutes actions D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space 11:00-12:30 G. RFC 2050 ("Internet Registry IP Allocation Guidelines") revision H. Report from the Address Council Y. Any other business Z. Open microphone... 14:30-15:30 (end of 1st IPv6 WG slot) + 16:00-17:30 (2nd IPv6 WG slot) I. IPv6 interim policy J. IPv6 future policy

1 0

Announcement - Database Consistency and Statistics Project
by Can Bican 14 Jan '02

14 Jan '02

Dear Colleagues, [Apologies for multiple messages]. The new version of database consistency project, along with whois server usage statistics have been released on the RIPE NCC's web pages, with the following url: http://www.ripe.net/db/dbconstat/ The goal of this project is to find the objects with consistencies not enforced by the database, and provide reports and statistics to help users correct them. It also aims at checking for the necessary protection of objects and tracing the query and update statistics of the RIPE whois server to analyze the current trends of using the database. The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references. Here are the types of inconsistencies which are addressed in this project: * Inetnum object related: * Inetnum objects without status attribute, * Assigned inetnum objects without allocations, * Overlapping inetnum objects, * Inetnum objects with suspicious boundaries to form a network, * Assigned inetnum objects from assignments, * Inetnum objects with wrong PA or PI status, * Wrongly allocated inetnum objects. * Person object related: * Person objects with multiple identical copies, * Person objects which do not have any references to them, * Person objects not having a valid nic-handle, * Objects which have references to invalid nic-handles. * Maintainer object related: * Maintainer objects which do not have any references to them. * Protection related: * Weak authentications schemes for maintainers. * Inetnum objects with no mnt-lower attribute. Reports about individual inconsistencies are sent only to the maintainers of objects. If you'd like to receive the report for your inconsistencies, send an e-mail to auto-dbcon(a)ripe.net containing the maintainer name in its body, and the appropriate authentication. * If the authentication of your maintainer is MAIL-FROM, mail should be sent from the appropriate e-mail address, and should contain the following in its body: mntner: <maintainer_name> * If the authentication of your maintainer is CRYPT-PW, mail should contain the following lines in its body: mntner: <maintainer_name> password: <password> * If the authentication of your maintainer is PGPKEY, mail should contain the following line and should be signed with the appropriate key: mntner: <maintainer_name> If you supply an existing maintainer and the proper authentication, the report of the inconsistencies related to the maintainer will be mailed back to you. For questions, comments and suggestions, please contact ripe-dbm(a)ripe.net. -- Can Bican RIPE NCC

1 1

Announcement - Database Consistency and Statistics Project
by Can Bican 14 Jan '02

14 Jan '02

Dear Colleagues, [Apologies for multiple messages]. The new version of database consistency project, along with whois server usage statistics have been released on the RIPE NCC's web pages, with the following url: http://www.ripe.net/db/dbconstat/ The goal of this project is to find the objects with consistencies not enforced by the database, and provide reports and statistics to help users correct them. It also aims at checking for the necessary protection of objects and tracing the query and update statistics of the RIPE whois server to analyze the current trends of using the database. The goals of the consistency project do not include, for example, reality checks for inetnum objects, but it addresses only internal inconsistencies in the database, such as invalid references. Here are the types of inconsistencies which are addressed in this project: * Inetnum object related: * Inetnum objects without status attribute, * Assigned inetnum objects without allocations, * Overlapping inetnum objects, * Inetnum objects with suspicious boundaries to form a network, * Assigned inetnum objects from assignments, * Inetnum objects with wrong PA or PI status, * Wrongly allocated inetnum objects. * Person object related: * Person objects with multiple identical copies, * Person objects which do not have any references to them, * Person objects not having a valid nic-handle, * Objects which have references to invalid nic-handles. * Maintainer object related: * Maintainer objects which do not have any references to them. * Protection related: * Weak authentications schemes for maintainers. * Inetnum objects with no mnt-lower attribute. Reports about individual inconsistencies are sent only to the maintainers of objects. If you'd like to receive the report for your inconsistencies, send an e-mail to auto-dbcon(a)ripe.net containing the maintainer name in its body, and the appropriate authentication. * If the authentication of your maintainer is MAIL-FROM, mail should be sent from the appropriate e-mail address, and should contain the following in its body: mntner: <maintainer_name> * If the authentication of your maintainer is CRYPT-PW, mail should contain the following lines in its body: mntner: <maintainer_name> password: <password> * If the authentication of your maintainer is PGPKEY, mail should contain the following line and should be signed with the appropriate key: mntner: <maintainer_name> If you supply an existing maintainer and the proper authentication, the report of the inconsistencies related to the maintainer will be mailed back to you. For questions, comments and suggestions, please contact ripe-dbm(a)ripe.net. -- Can Bican RIPE NCC

1 0

Status and appologies from the Chair
by Hans Petter Holen 12 Jan '02

12 Jan '02

Dear lir-wg, Just to give you all a brief update on my whereabouts: The ICANN Address Council this week had its first phone conference his year, with the newly elected members on participating. The Secretariat has been transferred from the RIPE NCC where Mirjam and others have done an excellent job organizing the practical details for our work, to ARIN who will serve as ASO secretariat this year. After two years as chair of ICANNs address Council I was happy to pass the work on to Barbara Rosseman who was nominated and elected as chair for the upcoming year. I volunteered and was elected to serve as one of two vice chairs. Minutes from the AC meetings can be found at http://www.aso.icann.org/meetings/index.html For the upcoming RIPE meeting I will due to work commitments at Tiscali Norway unfortunately not be able to participate in the lir-wg meeting. James Aldridge, whom you elected as one of two co-chairs, has kindly stepped in, and will be chairing the meeting. I may still be able to attend at the end of the week. If not, I wish you all a constructive and interesting meeting! Best Regards, Hans Petter Holen

1 0