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

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

19 Sep '01

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

3 2

Call for Nominations for Representatives to the ASO Address Council - RIPE region
by Hans Petter Holen 23 Aug '01

23 Aug '01

Dear colleagues, This is a call for nominations of individuals from the RIPE region to serve on the ASO Address Council. During October 2001, one RIPE region Address Council seat will become vacant and will be filled for the next three years by an individual nominated through this open call. This document describes the functions of the ASO and the Address Council, as well as the nomination and selection processes. If you are interested in nominating an individual, or if you are interested in being nominated as a member of the Address Council, please read this document carefully. 1. The Address Supporting Organisation - -------------------------------------- The ASO was formed in August 1999 as a consensus-based advisory body within the ICANN Framework, though a Memorandum of Understanding (MoU) signed by the current Regional Internet Registries and ICANN. The ICANN Bylaws (http://www.icann.org/general/bylaws.htm#VI-A) assign to the ASO the responsibility for the development of global policies relating to the distribution and registration of Internet address space, inter-domain routing identifiers and that part of the DNS name space that is used to name these addresses and identifiers. More information about the ASO is available at: http://www.aso.icann.org 2. The Address Council - ---------------------- The ASO Address Council co-ordinates the process of policy development in areas within the responsibility of the ASO, according to procedures defined within the MoU and by the AC itself. Specifically, these include the hosting of an annual open General Assembly meeting, and attending regular meetings by teleconference or in person at which policy issues and submissions may be considered. The other major responsibility of the Address Council is the appointment of individuals to fill ASO seats on the ICANN Board of Directors, according to procedures defined within the MoU. More information on the Address Council is available at: http://www.aso.icann.org/ac 3. The Role of Members of the Address Council - --------------------------------------------- Members of the Address Council do not represent any RIR, nor do they act as representatives of any other body. They are appointed in their individual capacity, and their membership cannot be proxied by any other individual or organisation. No member of the Address Council is entitled to any compensation from the ASO. No member can be indemnified by the ASO, nor can the ASO obtain insurance coverage relating to the liability of the actions of members of the Address Council. 4. Address Council Nominations Process - -------------------------------------- Through this nomination process, one individual from the RIPE region will be selected to serve on the Address Council for three years, replacing Hans Petter Holen who has served as an initial AC member for the past 2 years. The selection will be made though an open election from the set of individuals who have been nominated within this process. Any individual may be nominated, with the exception of any staff member of any Regional Internet Registry. Self-nominations are permitted. Nominations should be sent by email to <nominations(a)ripe.net>, by midnight UTC on 5 September 2001. The information included with the nomination is to be in English and should include: Name of Nominee: Country of residence: Organisation: Email Address: Postal Address: Biographical information: Motivation for nomination: Name of nominating individual: Organisation: Email Address: All nominees will be contacted via email to confirm their willingness to serve on the Address Council. If a nominee is not contactable via email, or does not respond, then their nomination will not be confirmed and they will not be eligible for election to the Address Council. All confirmed nominations will be listed on the RIPE web site after they are confirmed. All nominees will have the opportunity to submit a written statement in support of their nomination, for publication on the web site. In addition, others may express support for nominated individuals simply by completing and submitting the nomination form provided above. 5. Address Council Selection Process - ------------------------------------ The process for selection of the nominee to serve on the Address Council will involve an open election to be held during the plenary session of the RIPE 40 Meeting, in Prague, Czech Republic, on 5 October 2001. See the following URL for details about the selection procedure: http://www.ripe.net/ripe/wg/lir/adress_council-election.html More information about RIPE 40 will be available shortly at: http://www.ripe.net/ripe/meetings http://www.ripe.net/ripe/meetings/current/ripe-40/ Important Dates: 5 September 2001 - deadline for Address Council nominations Regards, Hans Petter Holen Local IR WG chair

1 1

Opening registration RIPE 40, Prague 1-5 October 2001
by RIPE NCC Meeting Registration 18 Jul '01

18 Jul '01

Dear Colleagues, It is our pleasure to open registration for the RIPE 40 meeting, to be held from 1 October - 5 October 2001 at the Prague Congress Center, Czech Republic. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-40/ Online registration will open on 16 July and close on 21 September 2001. On-site registration will open on Monday 1 October 2001 at 8.00 a.m. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 21 September 2001, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgement of your registration. You will receive a second acknowledgement by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter Czech Replublic are advised to begin the required procedures as soon as possible. The RIPE Meeting organisers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Asha Raghoebarsing RIPE Meeting Coordinator meeting(a)ripe.net

1 0

ALSC Request for input
by Hans Petter Holen 16 Jul '01

16 Jul '01

Thank you very much for your request. The topic you are studying are indeed of interest to us, and I will seek guidiance from my community on what response will be appropriate. I have forwarded your message to all of the Address Council and will expect us to discuss how to respond to your request at our next meeting at latest I have also forwarded your message to the RIPE Policy Working group (lir-wg) to seek comments and input from the working group members. We have a working group meeting in Prague 1 - 5 October 2001 but that may as I understand your timeline, be a bit on the late side for the result of the discussion to be incorporated. Sincerely, Hans Petter Holen AC Chair/RIPE lir-wg Chair ----- Original Message ----- From: "Carl Bildt" <cbildt(a)atlargestudy.org> To: "Hans Petter Holen" <hph(a)online.no>; "Takashi Arano" <arano(a)byd.ocn.ad.jp>; "Jianping Wu" <jianping(a)sea.net.edu.cn>; "Seung-Min Lee" <smlee(a)i-names.co.kr>; "Raimundo Beca" <rbeca(a)ctc.cl>; "Cathy Wittbrodt" <cjw(a)remarque.org>; "Barbara Roseman" <barbara(a)gblx.net>; "Wilfried Woeber" <Woeber(a)CC.UniVie.ac.at>; "Sabine Jaume" <Sabine.Jaume(a)renater.fr>; "Raul Echeberria" <raul(a)inia.org.uy>; "Nii Quaynor" <Quaynor(a)ghana.com> Sent: Monday, July 16, 2001 7:51 AM Subject: Request for input | Greetings, | | On behalf of the At-Large Membership Study Committee (ALSC), I would | like to solicit input from the Supporting Organization (SO)ASO and its | constituents, as well as share with you our first "Discussion Paper" | and our plans for completing our recommendations. | | We are eager to work with you and your colleagues to ensure that we | have a thorough understanding of your activities, structure and needs - | and your views on the relationship between your Supporting | Organization, its constituents, and the "At-Large" membership | (individual Internet user community). Details on the functioning of | current ICANN organizations will aid in our efforts to recommend a | successful structure/process for At-Large. | | Please find enclosed our current thoughts regarding the concept, | structure and processes relating to an "At-Large" membership ("ALSC | Discussion Paper"). As indicated in the attached, we are eager to get | your input on a number of factual questions and normative issues that, | for us, remain unresolved and important to our recommendations on At- | Large participation and Board representation. | | In light of the ongoing DNSO review and the recent "Country Code | Supporting Organization Statement," it is clear to us that our | recommendations should not take ICANN's current organizational | structure as an unalterable premise. Rather we need to consider ICANN's | representational and decision-making structures in their entirety (e.g. | the possible creation of additional Sos and re-allocation of Board | seats). | | As such, the ALSC is actively considering a variety of potential | participation structures for an "At-Large" that may affect the existing | SOs, and we would not like to do so without adequate consultation with | you | | Please forward this email to other relevant parties and send your | thoughts, comments, concerns and suggestions to our Executive Director, | Denise Michel (dmichel(a)atlargestudy.org) or to our email forum | (comments(a)atlargestudy.org) if possible by July 27. | | Included in the paper is a proposed schedule of ALSC activities leading | up to the submission for our final report to the Board in November. As | you can see, we have an ambitious and tight schedule, which makes us | eager to hear from you soon. | | If possible, we would like the opportunity to meet with members of your | organization face-to-face to discuss our activities and draft | recommendations. The ALSC will be in Silicon Valley (Santa Clara, | California, USA) on August 13 - 14 and in Montevideo, Uruguay, on | September 7-8. We would welcome a meeting with your organization, or | some of its representatives, at these locations or elsewhere. Please | contact Denise Michel to coordinate or to request additional | information. | | Thank you for your cooperation, and we look forward to working with | you. | | Sincerely, | | Carl Bildt | ALSC Chairman | | | ---------------------------------------------------------------- | | At-Large Membership Study Committee Discussion Paper #1 | | July 12, 2001 | | | | "In theory, there is no difference between theory and practice. But, in | practice, there is." | Jan L. A. van de Snepscheut | | Introduction | | Over the last two and a half years, ICANN has made considerable | progress towards achieving the objectives for which it was formed, | including providing coordinated advice on technical management of the | DNS and IP addresses, launching a process for implementing new TLDs, | and supporting the creation of new regional internet registries. | | However, there is concern by some that ICANN still lacks the perceived | legitimacy and accountability to a broad public that will enable it to | operate effectively and flexibly as the Internet scales up and as | ICANN's policies affect an ever broader and less technically oriented | Internet community. | | In order to help fulfill ICANN's promise of accountability, the ICANN | Board created the At-Large Membership Study Committee (ALSC) earlier | this year to conduct a complete review of the At-Large (individual | Internet user) membership concept and its structure and processes, and | to "achieve a broad consensus on effective means by which the diverse | global Internet communities and individual stakeholders may participate | in ICANN's policy development, deliberations, and actions ."[1] (See | Appendix A, "Brief Background") | | Purpose | | We need to keep in mind that ICANN is a very young international entity | that faces both high expectations and operational challenges as one of | the world's most unusual "Internet start-ups." | | Over the last several months, in order to understand ICANN and its | structure and processes, the ALSC has read through the volumes of | publicly available discussions and material surrounding its history, | form and function, and its controversy. We also have reviewed numerous | emailed views and participated in several face-to-face discussions (in | our "outreach" events and in individual meetings), and listened to | those of you who have shared your thoughts and views on how we might | address our task and provided feedback on the questions we have asked. | | While we will continue to listen to everyone's input, work with other | related review efforts, and keep an open mind, it is now time for us to | begin to formulate and share our own thoughts with the goal of | encouraging more specific feedback. That is the purpose of this | Discussion Paper and the specific concept papers we will shortly post. | | Your Input is Needed | | We have received clear indications that, as part of our efforts to | achieve a consensus on how the various Internet communities and | stakeholders should be involved in ICANN, our recommendations should | not take ICANN's current organizational structure as an unalterable | premise. The ongoing DNSO review[2] and the recent "Country Code | Supporting Organization Statement,"[3] indicate that there are | significant concerns within these groups, and perhaps among others, | that clearly need to be addressed. | | Specifically, we need your input on which current ICANN structures are | working well and which are not, and the causes of any current | "problems" or "inadequacies". We also welcome your constructive ideas | on solutions. Clearly any changes to existing ICANN organizational | structure need to adequately accommodate the role of the At-Large and | the overall structure of ICANN, and vice versa. We recognize that a | consensus on a new approach to individual participation and | representation in ICANN must be developed in close coordination with | the existing ICANN organizations and constituencies, and with extensive | input from all interested individuals. We hope this discussion paper | and subsequent discussion will foster such collaboration and result in | better outcomes. | | Our Initial Conclusion: Yes, Individuals Need A Voice in ICANN | | After broad outreach and deliberation, the ALSC has come to the initial | position that some form of structured involvement of individual | Internet users in ICANN policy formulation and decision-making is | needed, along with representation of individual Internet users on | ICANN's Board. While this may appear obvious to some, we did not want | to jump to conclusions without considering a full range of arguments. | | It is clear to us that there is a "public interest" responsibility | vested in ICANN, and therefore some role for individuals (as well as | non-commercial interests, etc.) is appropriate. In essence, ICANN needs | to be accountable not just to those people whose daily work concerns | ICANN's activities (and who may be Supporting Organization members), | but also those who are affected by its actions but whose daily focus is | elsewhere. Actions ICANN takes within its seemingly narrow technical | and administrative mission can affect (and generate interest among) the | world's individual Internet users in a myriad of ways. These users hold | a variety of values and represent interests that may be personal, | political or economic. They care about issues such as access to domain | names in non-Latin characters, the potential use of IP addresses and | domain names for identification or location of individuals and groups, | the mapping of telephone numbers to Internet addresses, competition and | choice (or not) in the provision of various services provided by | independent parties under contract to ICANN, domain-name intellectual | property issues, and the like. | | There is concern, however, that the existing ICANN policy development | and decision-making structure has not fulfilled expectations of | involving and representing these various individuals and their | interests. | | The Process | | In reviewing numerous ICANN discussions and resulting decisions, we | found it difficult to follow the documented "consensus" decision-making | process. In many instances, it is unclear how the input into a | particular "open process" decision was duly considered, documented and | assimilated. We want to ensure that all interested individuals have an | opportunity to participate fully in "bottom-up ICANN consensus | development." And we want to ensure that there is a mechanism that will | make this possible. There certainly is an opportunity for ICANN, | potentially through an At-Large membership, to organize individuals' | energy and experience in a more productive manner - making the issues | intelligible to a broader community and giving individuals a way to | turn their feedback into tangible influence in an accountable, | transparent and predictable manner. | | In making recommendations on the role of an At Large membership in | ICANN, our intention is to help create a policy and decision-making | structure and process within ICANN that fosters understanding and | accommodation between various constituencies, including individual | Internet users. We are striving to recommend such a structure and | process to help ensure that ICANN's policies truly reflect the needs, | interests and rights of all its stakeholders - including those who may | not like its policies but who will ideally feel that at least their | arguments were understood and fairly considered. | | Concept Papers to Follow | | Our charge to conduct a comprehensive study and to "consider the proper | relationship between an At-Large membership and ICANN's three | Supporting Organizations,"[1] has led us to begin development, in | conjunction with the affected communities, of recommendations for | individual Internet user participation in ICANN. | | We welcome input to help further our understanding of how the existing | ICANN policy development and decision-making structure has (or has not) | fulfilled expectations of involving and representing all relevant | stakeholders. We also look forward to receiving any ideas that might | improve the ICANN process and structure and individuals' role within | it. To foster constructive discussion, and to focus on concrete | possibilities - solutions rather than opinions and goals - we are | developing concept papers for your review. [See Appendix B, "Proposed | Schedule of ALSC Activities"] | | We are particularly interested in hearing your views on what would | constitute a successful structure and process for individual Internet | user participation. Thus far, our view is that a successful structure | and process should: | | * Fulfill ICANN's mission of acting in the public's interest in its | administration of the Internet's technical name and numbering | infrastructure, and balance the commercial and institutional | interests that are already well represented within the | organization. | * Ensure that ICANN operates in a manner that is stable, | accountable, transparent, and predictable. | * Increase the likelihood of voluntary compliance by fulfilling | ICANN's goal of having its decisions supported by a broad and | documented consensus among affected parties. | * Engender knowledge within, and support from, interested | communities by giving them a demonstrable way of participating and | affecting policy. | * Inject the necessary public interest perspectives into | coordination of relevant ICANN issues. This includes bringing | non-technical considerations to bear on technical decisions, as | well as providing ICANN with advance warning of issues that have | the potential of being critical or controversial in the | "non-technical" world. | * Encourage both the "non-technical" and "technical" communities to | explain their concerns and the impact of their work more | effectively to the broader public. | | | | Regardless of how individual involvement is ultimately achieved, it is | reasonable to expect that ICANN's Board will continue to be the focal | point for critical decisions. Therefore, Board representation of | individual Internet users also must be addressed, and we are eager to | hear your views on how this might be achieved. | | Our effort to recommend any reconfiguration of Board membership is | driven by several goals, including the need to: | | | | * Fulfill ICANN's commitment to greater accountability of the Board | of Directors to the Internet community. | * Ensure "users' voices" are represented in ICANN's decisions. | * Represent the diverse interests of those affected by ICANN | decisions. | * Select high-quality Board members capable of understanding and | fulfilling ICANN's responsibilities. | * Avoid "capture" of the Board through disproportionate and opaque | representation of any one organization or interest group or | community. | * Ensure the Board Members work together effectively to fulfill its | responsibilities. | | In considering participation and Board representation, your input is | especially needed on both factual questions and normative issues that, | for us, remain unresolved, including (but not limited to): | | * Within each Supporting Organization, are the existing processes | and structures meeting the expectations of their participants? | What aspects of the process are working well? How can existing | processes be improved? Are all stakeholders/communities adequately | represented? | * In order to gauge the level of participation and activity in | ICANN's existing communities, as represented by their mailing | lists, what are the basic statistics of these lists (e.g. number | of participants, demographics, frequency of posting etc.)? | * Similarly, how many participants attend face-to-face | meetings/teleconferences? How often are such meetings held? | * How are the results of the email discussions, teleconferences, and | face-to-face meetings summarized, documented and forwarded for | consideration by other ICANN participants? What working languages | are used? | * What conflict-of-interest provisions exist within each of the | existing Supporting Organizations? | * What mechanisms exist to demonstrate that due weight is given to | input provided to each of the Supporting Organizations? What is | the Supporting Organizations' operational definition of | "consensus"? If consensus is/is not possible, are the points of | agreement and disagreement, rationale, etc. summarized and | documented? What/who determines if consensus has been reached? | * How much can be expected to be achieved from purely voluntary | ICANN participation? What might the role of a professional | secretariat/support staff for the Supporting Organizations play in | facilitating participation and deliberation? How might such staff | be funded? | * Who is staff accountable to (and who should staff be accountable | to)? What is the nature of the relationship between ICANN staff | and the existing Supporting Organizations? What protocol governs | their interactions and priorities? | * Other than reading through relevant mailing list archives, what | other resources exist that make understanding the issues being | discussed in ICANN more accessible? In which languages are such | materials produced? | * How should existing and potential constituencies be organized into | Supporting Organizations or other entities such as interest | groups, political parties, etc. | * How can individuals be encouraged to self-organize without ICANN's | direct involvement? | * What would be each entity's role, authority, and funding source? | * What (if any) specific consensus development processes should be | recommended? | * Should Directors selected by individual Internet users be a | majority or minority of the Board members? How should Board seats | be allocated? Should the current balance of Directors (i.e. 9 from | the SOs and 9 from At-Large) be kept? | * Should elections of Directors be direct or indirect (or a | combination)? How should candidates be nominated? What voting | procedures should be used? Who should have the ability to vote? | * If direct elections are recommended, should they be held among | particular groupings of Internet users, or should they be | geographic or issue-based (including issue or agenda-driven | "parties")? | * Should some demonstration of commitment be required for | participation in elections (such as requirements based on | knowledge, participation, or money)? | * How can individual users be informed about ICANN? How can | candidates for election and interest groups in any form | communicate with ICANN's "At-Large members"? Relevant issues | include privacy, language, Net access (use of Web vs. e-mail) and | others. | | Comments(a)atlargestudy.org | | In making any recommendations to the ICANN Board, we want to ensure | that we adequately address the role of an At-Large membership within | the ICANN structure as a whole . We are optimistic that mechanisms with | individual involvement can be found that will enable ICANN to develop | balanced and well-considered policies for Internet domain names, IP | address numbers, protocol parameter and port numbers, with the consent | of those who have the responsibility to implement them for the benefit | of the world's Internet community. | | Please email your comments to us at comments(a)atlargestudy.org or send | them to our on-line forum at http://www.atlargestudy.org/forum.shtml . | | Thank you for your consideration and participation. | | The At-Large Study Committee: Carl Bildt (Chair), Chuck Costello (Vice | Chair), Pierre Dandjinou, Esther Dyson, Olivier Iteanu, Ching-Yi Liu, | Thomas Niles, Oscar Robles, and Pindar Wong (Vice Chair). Denise | Michel, Executive Director. | | | ---------------------------------------------------------------- | | | | Appendix A: Brief Background | | The U.S. Department of Commerce, in granting ICANN its authority, urged | ICANN to ensure "greater accountability of the Board of Directors to | the Internet community" and to "operate in a bottom-up and | representative manner, open to input from the broad community of | Internet users."[4] | | How this accountability and representation should be achieved has been | hotly debated since before ICANN was created in response to a request | from (but not by) the U.S. Government. In addition to the diversity of | views on how ICANN should be structured and operated, there also has | been widespread disagreement on the mechanisms for At-Large | representation (how to avoid fraud, abuse or capture). | | Currently, a 19-member Board of Directors governs ICANN, with nine | members from three Supporting Organizations (three from each SO), five | members who were selected by an At-Large membership, four members who | were appointed and have served since ICANN was created, and one member | who is the corporation's President and CEO. The Board and the three | SO's are designed to include representatives of a specific set of | Internet "stakeholders." ICANN's bylaws called for these three SO's to | be "formed through community consensus": the Domain Name Supporting | organization (DNSO), the Address Supporting Organization (ASO), and the | Protocol Supporting Organization (PSO). | | Although the original nine-member Board was picked by Jon Postel and | was seated upon ICANN's creation, there was no consensus on how the | nine "At-Large Directors" should be selected going forward. In July, | 2000, ICANN's Board adopted a compromise interim solution: the | worldwide direct election of five "At-Large" Directors for the ICANN | Board, one from each of five geographic regions (Africa, | Asia/Australia/Pacific, Europe, Latin America/Caribbean, and North | America), by a self-selected At-Large membership, combined with the | continued service of four of the initial ICANN directors (for a period | not to exceed two years) to ensure that there would remain nine | At-Large "slots" on the ICANN Board until (at a minimum) the results of | this At-Large study are implemented. As part of this compromise, it was | agreed that, during the next two years, there would be a "clean-sheet" | study of how to appropriately provide for input and influence into | ICANN policy deliberations and actions by the individual Internet user | community. The five At-Large Directors were selected through an on-line | election process and seated on the Board in November 2000. On January | 26, 2001, ICANN announced the creation of the ALSC and the Board | approved the Committee's members on March 20.[5] | | | | Appendix B: Proposed Schedule of ALSC Activities | | | | * Issue Discussion Paper #1 with Proposed Schedule of ALSC | Activities (July 12) | * Issue key questions regarding potential structures/directions | (July) | * Issue Discussion Paper #2 listing additional points of ALSC | agreement and potential options for individual Internet user | participation in ICANN (July) | * ALSC working and outreach meetings (August 13) | * Issue Draft Report (by September 7) | * ALSC working and outreach meetings (September 7) | * Submit final report to ICANN Board and issue to public (by | November 14) | | ---------------------------------------------------------------- | | Footnotes | | 1. "Charter for the At Large Membership Study Committee," ICANN, | January 22, 2001, | http://www.icann.org/committees/at-large-study/charter-22jan01.htm | 2. ICANN Public Comment Forum, DNSO Review, | http://forum.icann.org/dnsoreview1/ | 3. "ccSO Formation Statement (Stockholm, 1 June, 2001)," by the | "World Wide Alliance of Top Level Domain-names, ccTLD Constituency | of the DNSO," http://www.wwtld.org/ | 4. "U.S. Government White Paper" (United States Department Of | Commerce Management of Internet Names and Addresses, National | Telecommunications and Information Administration, Statement of | Policy), June 5, 1998, | http://www.ntia.doc.gov/ntiahome/domainname/6_5_98dns.htm | 5. At-Large Study Committee information can be found at | http://www.atlargestudy.org | |

1 2

Initial PA Allocation Criteria
by RIPE NCC Staff 11 Jul '01

11 Jul '01

Dear all, Further to my mail on PA Allocation criteria (see below), here follows a concrete proposal, including details of the actual criteria to be determined. Very little feedback was received on the last mail asking for input on the actual details of such criteria. Therefore, in order to move forward and establish the details of these criteria, please find below a clear proposal of criteria for the initial PA Allocation received by a newly established Local IR. Proposed Criteria for Initial /20 PA Allocation ----------------------------------------------- The Local IR is required to: - Demonstrate previous efficient utilisation of a /22 (1024 addresses). Or - Demonstrate immediate need for a /22 Renumbering: If current address space held by the Local IR amounts to a /22 or less, the Local IR is required to renumber that address space into the PA Allocation it will receive from the RIPE NCC. Can the lir-wg agree with the above proposed criteria? If no further objections are raised I would like to suggest that the RIPE NCC moves forward and implements this policy. Please let us know if you are not in agreement with the above. Kind regards, Nurani Nimpuno +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ ------- Forwarded Message Date: Fri, 01 Jun 2001 18:23:48 +0200 From: RIPE NCC Staff <ncc(a)ripe.net> Resent-From: Nurani Nimpuno <nurani(a)ripe.net> Sender: owner-lir-wg(a)ripe.net To: lir-wg(a)ripe.net Resent-To: ncc(a)ripe.net Subject: Summary: PA Allocation criteria discussion Dear all, Thank you for you input thus far in the discussion on portable address space. Many useful points have been raised on the matter of PI address space and PA Allocations. (The complete discussion can be read at: http://www.ripe.net/ripe/mail-archives/lir-wg/current/msg00130.html) Below is an attempt to summarise the discussion so far: The concept of smaller allocations (than current /20) was initially brought but the majority felt that this was not a realistic option. The comments showed concern about the exponential growth in the routing table and it was believed that smaller allocations would further contribute to this growth. There was consequently further discussion on how the RIR policies can prevent/reduce this through sensible address allocation/assignment criteria. On the subject of PI assignments, related to the current growth in the routing table, it was agreed that PI assignments should (as current policy states) be based on need and not routability. It was further stated that end users should be discouraged from multi-homing with globally visible address space. Some participants of the discussion argued for a complete discontinuation of PI. Most contributors agreed that /20 PA Allocations should be given to organisations who wish to further assign addresses to customers / end-users from their PA block. PA Allocations should not be made to organisations to satisfy pure multi-homing / independence needs. A set of criteria should therefore be determined to clarify this. Lastly, the majority agreed that the PA Allocation criteria should be based on previous efficient utilisation. There was further discussion with regards to the size of the efficiently utilised address space the requestor needs to demonstrate. The prefix sizes /22 and /21 were briefly discussed. If the community believes that this is a just summary of the discussion, I wish to move forward and determine the details of such criteria, through presenting a few very concrete discussion points. I would like your opinion on the following: 1. Do you agree on the following criteria to be set: The requesting organisation need to show - Demonstrated efficient utilisation of a /xx or - Immediate need for a /xx ? 2. If qualifying through the criterion of demonstrated efficient utilisation of address space, should the requestor need to demonstrate efficient utilisation of A. /22 or B. /21 ? 3. If qualifying through the criterion of demonstrated immediate need, should the requestor need to demonstrate an immediate need of a A. /22 or B. /21? 4. Should the requesting organisation be required to renumber depending on the sizes of its current aggregates? 4A. If so, what is a reasonable size of the smallest aggregate that an organisation would be required to renumber? I am looking forward to your input on these concrete points. Kind regards, Nurani Nimpuno RIPE NCC ------- End of Forwarded Message

2 1

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

11 Jul '01

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

1 4

IPv6 for IXPs
by Mirjam Kuehne 02 Jul '01

02 Jul '01

Dear all, how about this (thanks to Henk): Definition: A physical network infrastructure (layer 2) operated by a single entity with the purpose to facilitate the exchange of Internet traffic between Internet service providers. The number of Internet Service providers connected should at least be three and there must be a clear and open policy for others to join. Addresses needed for other purposes (e.g. additional services provided to the members) should be assigned by upstream ISPs. Assignment size: - a /48 in most cases - a /64 if it is known that there will only be one subnet (basically following the IAB recommendation) Additional warning: The RIRs should warn the IXP that it is strongly discouraged to announce the addresses and that they will likely not to be globally routable. If this is agreeable the RIPE NCC will implement this policy and co-ordinate it with the other Regional Internet Registries. Mirjam Kuehne RIPE NCC

6 7

Fwd: IN-ADDR.ARPA Progress Report
by Joao Luis Silva Damas 02 Jul '01

02 Jul '01

Dear all, here I forward an announcement from ARIN regarding current progress in the maintainance of the in-addr.arpa zone. Best regards, Joao Damas RIPE NCC >From: ARIN IN-ADDR Role <inaddr(a)arin.net> >Subject: IN-ADDR.ARPA Progress Report >Message-ID: <Pine.SOL.4.05.10106291525050.10191-100000(a)ops.arin.net> > >Goal: > >Reduce the size of the IN-ADDR.ARPA zone file. This file will be reduced >in size by only containing name servers for /8 networks. > > >Completed Steps: > >Apr 2001 - Established relationships with 2 companies to provide >independent server networks for all ARIN IN-ADDR zone files. > >Jun 2001 - Released a new IN-ADDR.ARPA zone file generator to correct >existing erroneous data. > > >Next Step: > >July 9, 2001 - ARIN will begin revising the IN-ADDR.ARPA zone for those >direct /8 delegations to ARIN. These /8 zone files will be serviced by >the two ARIN nameserver networks. These changes will not affect the >performance of reverse lookup in any of the IPv4 Address space. > >Please direct any questions to inaddr(a)arin.net. > > >Ginny Listman >Director of Engineering >American Registry for Internet Numbers --

1 0