- lir-wg - mailman.ripe.net

Re: selling PA as PI
by Nurani Nimpuno 03 Aug '01

03 Aug '01

Dear Bogdan, Thank you for bringing this to our attention. The RIPE NCC has an auditing service that we provide to the community. The auditing activity was set in place to promote the consistent and fair application of IP Address policies. The activity is focused around helping the LIRs to understand and follow the correct policies and procedures. The RIPE NCC will first discuss the issue with the LIR involved and outline the correct policies and procedure. Most audits are done by random selection, but there is also the possibility of requesting an audit. LIRs can approach the RIPE NCC if they suspect that another LIR is violating the address policies set in place by the Internet community. For more information about the Audit Activity, please refer to: http://www.ripe.net/rs/audit/ and RIPE Document: "RIPE NCC Consistency and Auditing Activity" at: http://www.ripe.net/ripe/docs/auditing.html As you already know, IP Addresses are not to be considered property as stated in RIPE Document:" Charging by Local Internet Registries": http://www.ripe.net/ripe/docs/ripe-152.html Again, thank you for bringing this to our attention. The RIPE NCC will look into the matter and contact the LIR in question. For any other issues of this kind, please write to <lir-help(a)ripe.net> . Kind regards, Nurani -- +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ Bogdan Surdu <tim(a)rdsnet.ro> writes: * * Hi, * * I'm working for a ISP in Romania which is also a LIR. The biggest LIR in * Romania RNC (ro.rnc) received a /15 PA block from RIPE last month. They * are selling prefixes (yes selling, they charge different amounts for differe * nt * space: $50 for a /28 up to $230 for a /24) to almost anyone who wants IPs, * even they are not connected to RNC. Basically they sell the PA space as * PI, since they are not advertising the PA block and the prefixes are * announced in Internet by other ISPs. * 80.96/15 is not the only block sold as PI space, they have many PA * blocks distributed to customers connected to other ISPs (for example our * customers have about 60 * /24 prefixes from 217.156/17 PA block allocated * to RNC). * What can we do to stop this practice? * * * inetnum: 80.96.0.0 - 80.97.255.255 * netname: RO-RNC-20010705 * descr: National Institute for R|&D in Informatics * descr: Provider Local Registry * country: RO * admin-c: ES16 * tech-c: CH7396-RIPE * status: ALLOCATED PA * mnt-by: RIPE-NCC-HM-MNT * mnt-lower: AS3233-MNT * mnt-routes: AS3233-MNT * changed: hostmaster(a)ripe.net 20010705 * source: RIPE * * * -- * Bogdan Surdu * * Romania Data Systems S.A. * E-mail: tim(a)rdsnet.ro * Tel: +40 1 30 10 850 * Fax: +40 1 30 10 851 * * ------------------------------------------------------------------- ------- * Privileged/Confidential Information may be contained in this message. If * you are not the addressee indicated in this message (or responsible for * delivery of the message to such person), you may not copy or deliver this * message to anyone. In such a case, you should destroy this message and * kindly notify the sender by reply e-mail. * * *

1 0

selling PA as PI
by Bogdan Surdu 03 Aug '01

03 Aug '01

Hi, I'm working for a ISP in Romania which is also a LIR. The biggest LIR in Romania RNC (ro.rnc) received a /15 PA block from RIPE last month. They are selling prefixes (yes selling, they charge different amounts for different space: $50 for a /28 up to $230 for a /24) to almost anyone who wants IPs, even they are not connected to RNC. Basically they sell the PA space as PI, since they are not advertising the PA block and the prefixes are announced in Internet by other ISPs. 80.96/15 is not the only block sold as PI space, they have many PA blocks distributed to customers connected to other ISPs (for example our customers have about 60 * /24 prefixes from 217.156/17 PA block allocated to RNC). What can we do to stop this practice? inetnum: 80.96.0.0 - 80.97.255.255 netname: RO-RNC-20010705 descr: National Institute for R|&D in Informatics descr: Provider Local Registry country: RO admin-c: ES16 tech-c: CH7396-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-lower: AS3233-MNT mnt-routes: AS3233-MNT changed: hostmaster(a)ripe.net 20010705 source: RIPE -- Bogdan Surdu Romania Data Systems S.A. E-mail: tim(a)rdsnet.ro Tel: +40 1 30 10 850 Fax: +40 1 30 10 851 -------------------------------------------------------------------------- Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such a case, you should destroy this message and kindly notify the sender by reply e-mail.

2 1

Re: One question about RIPE
by Nurani Nimpuno 03 Aug '01

03 Aug '01

Hi Andreas, I'll try to shed some light on this. First of all. There are no forms needed for routing addresses. Only if you are *requesting addresses* on behalf of your customer you need to fill in the IP request form at: http://www.ripe.net/ripe/docs/iprequestform.html Your routing decisions do not fall under RIPE NCC's responsibility. There are some recommendations however that can be found in the current Policy Document: http://www.ripe.net/ripe/docs/ir-policies-procedures.html Recommendations specific to Provider Independent (PI) and Provider Aggregatable (PA) address space are outlined in RIPE-127: http://www.ripe.net/ripe/docs/pi-pa.html In short, a PA Assignment is a range within a larger aggregate (a PA Allocation). A PI Assignment is an address range separately assigned to an end-user. If the customer has Provider Independent address space, it is your decision whether you want to route the addresses. As for PA Address space, ISPs are recommended to make contractual agreements with their customers, clarifying that the customers are required to renumber, should they change providers. Respecting these agreements, another ISP should naturally not accept to announce their PA address range separately to the Internet. However, it is also possible to multi-home by having a PA address range announced through two providers. If the PA addresses come from ISP A's allocation, the customer would have to agree with ISP B to announce that range separately. ISP A would also have to announce the range as a more specific route together with their aggregate. I hope this clarified the issue. If you have any further questions, please don't hesitate to write to <lir-help(a)ripe.net>. Kind regards, Nurani +------------------------------------+ | Nurani Nimpuno | | Internet Address Policy Manager | | RIPE Network Co-ordination Centre | | http://www.ripe.net | +------------------------------------+ "Roehling, Andreas" <Andreas.Roehling(a)lambdanet.net> writes: * Hello, * * We have a customer that has got a range of IP addresses from one Provider * (say X) and he now would like to use these addresses via our network. * * Our sales representatives say it is possible to do * it * 1) If Provider X is OK * 2) If we have got the agreement from RIPE * * Is it correct ? * * Would you know which RIPE's form would be used then? * * Thanks * * Andreas * *

1 0

Re: One question about RIPE
by Wilfried Woeber, UniVie/ACOnet 03 Aug '01

03 Aug '01

Hi Gert, >PI ("provider independent") address space - this could theoretically >be used. You do not have to ask the old ISP or RIPE for permission. You >just register the routes in the RIPE database, ask the old ISP to >stop announcing them, and start announcing them via BGP. PI space has >other disadvantages, though, like "much harder to debug if some goal >in the Internet cannot be reached", so we usually recommend to the >customer to return his PI space to RIPE and accept PI space from us ^^ I guess this should be "PA" here !? ______________/ >(unless the PI block is very large and the customer network so complex >that it would make renumbering too hard). Cheers, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A catholic church ad sign near Maryborough, QLD:"Where Miracles Happen"

1 0

Re: One question about RIPE
by Denesh Bhabuta 03 Aug '01

03 Aug '01

Andreas At 08:40 02/08/2001, Roehling, Andreas wrote: >We have a customer that has got a range of IP addresses from one Provider >(say X) and he now would like to use these addresses via our network. >Our sales representatives say it is possible to do >it >1) If Provider X is OK >2) If we have got the agreement from RIPE >Is it correct ? This is only correct if the customer is using PI space. If the other provider has assigned PA space to the customer, then they will have to get a new set of addresses from you and renumber their network when they start a service with you. If the customer does have PI space from the other provider then you have to consider the size of the address space the customer is bringing in and whether it is worth *your* effort to route that size of block (say if the customer has a /24) through your network and whether it would be beneficial to the customer. HTH Regards Denesh

1 0

One question about RIPE
by Roehling, Andreas 03 Aug '01

03 Aug '01

Hello, We have a customer that has got a range of IP addresses from one Provider (say X) and he now would like to use these addresses via our network. Our sales representatives say it is possible to do it 1) If Provider X is OK 2) If we have got the agreement from RIPE Is it correct ? Would you know which RIPE's form would be used then? Thanks Andreas

5 5

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