- address-policy-wg - mailman.ripe.net

Resilience Featuresof IPv6, DNSSEC and MPLS and Deployment Scenarios
by Alaa Al-Din Al-Radhi 27 Jan '09

27 Jan '09

Dear Colleagues Kind regards I like to knowledge share with you this latest interesting post: http://www.enisa.europa.eu/sta/files/resilience_features.pdf Please spread the words among your colleagues and peers. Best regards Alaa Al-Din ( Aladdin ) Al-Radhi Consultant Engineer and Researcher Passionate / Advocate of: Internet, Science, technology, innovations and new frontiers. alradhi2000(a)yahoo.ca , alaalradhi(a)hotmail.com http://www.linkedin.com/in/alaaaldinalradhi http://www.pir.org/index.php?db=content/Website&tbl=About_Us&id=7#aalradhi http://akms.org/site_content.aspx?page_key=board_of_trustees&lang=en http://www.isoc.org/pubpolpillar/governance/igf-hyderabad_ambassadors.shtm l http://aso.icann.org/elections/radhi.html http://www.itu.int/ITU-D/arb/ARO_2008_work/IP-Communications/ListofDocs-tn.… http://icie.zkm.de/join#members http://alumni.depaul.edu/community/groups/International.asp __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com

2 1

IPv6 Latest Report 2009
by Alaa Al-Din Al-Radhi 18 Jan '09

18 Jan '09

Dear Colleagues A new report on IPv6. May be you find it interesting http://tinyurl.com/7q8kbw Alaa __________________________________________________________________ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php

1 0

Direct End USer Assignments, 2007-01 and Contractual Requirements
by Marcus.Gerdon 16 Jan '09

16 Jan '09

Hello @All, hopefully it's just an incapability of mine not to be able to get that topic into my head and understood... :-| ... because else I'd have to rant about this being accepted and implemented in a totally inconclusive and incomplete manner only useful for creating additional chaos. Not to take me wrong, in general I agree with putting in place some 'garbage collection' mechanism to return unused resources to the pool. What I was able to gather by digging through the archives, document store, google etc. was: 2007-01v4 has been accepted despite containing a bunch of topics left open. How's the 'sponsoring lir' defined ? Definition of fees left to NCC (what have been done by now, but I come back to that later). 'Contractual Requirements' left in some indefinite state (and without any discussion) as far as I can see. The charging scheme has been adapted to reflect End User - RIPE NCC contracts and fees. Did someone read that and compared LIR to End User ? The lowest fee - applicable for a single /24 already - equals to becoming a lir. What's the minimum allocation size today ? /21 ? Would you pay 1300 EUR p.a. to get a /24 when you can get a /21 by bcoming a lir for the same fees (which even provides much greater freedom, i.e. assignmnets allowed, partial transfer allowed) ? I think the only result of this will be PI/ASN fees turning into a mrket competition criteria. Anyone really going into the direct contract thing I expect to go for the /21-same-fee lir option. Won't this turn out to become an additional waste of addresses ? What about the 'sponsoring lir' theme ? The 'Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region' is a nice document. But that's the meaning of it ? All I see is a *draft* document trying to lay hands on the bussiness relationship between lir and end user. Getting a few additional scoring points in the billing algorithm I don't even think about. The member fee and the difference between categories isn't that expensive. (Before someone complains, those having a problem with the fees by stepping up a category due to issuing a sufficient amount of PI/ASN imho have a problem with their business plan and calculations.) So, let's see: I tell my (potential) customers to sign a contract with RIPE and pay thousends of EUR per year whilst another LIR is 'sponsoring' the PI. Bad idea - my boss won't like me forcing customers to contract another isp instead. So, we'll go for 'sponsoring' mode and get the score. No problem so far. Now, what's that 'Contractual Requirements' thing ? Even accepting the process including automatic return of resources to RIPE, how is RIPE going to verify the future existence ? Why should I be forced to charge a fee ? Do 'I have to forward that fee to RIPE's bank account ? What about transfer of a PI or ASN? When the customer decides to cancell contracts PI and ASN have to be transferred to the new lir so I get rid of the score (and more important administrative issues). In the past any transfer was charged for with an non-ignorable amount. Unfortunately I didn't find the document which fee applies here. In case the 'Administrative fee' - which has been nullified - is applied, everything is good at least here. So, put together in a simple single question: How the f*** are PI/ASN handled today and under which constraints ? Hope anybody's able to enlighten me ... Thanks in advance, Marcus ---------------------------------------------------------------------------------------- Systemtechnik Internet / Internet Engineering Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon(a)versatel.de | www.versatel.de Sitz der Gesellschaft: Essen, Registergericht: Essen HRB 19502 Geschäftsführer: Marc Lützenkirchen, Peer Knauer, Dr. Hai Cheng, Dr. Christian Schemann ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ----------------------------------------------------------------------------------------

2 1

Updated RIPE Documents
by Laura Cobley 15 Jan '09

15 Jan '09

[Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce the publication of two updated RIPE Documents, ripe-444, 'Autonomous System Number Request Form' and ripe-445, 'Supporting Notes for the Autonomous System Number Request Form'. The updated documents are available at: http://www.ripe.net/ripe/docs/asnrequestform.html http://www.ripe.net/ripe/docs/asnsupport.html These updates have been made to correct an administrative error. Best Regards, Laura Cobley Registration Services RIPE NCC

1 0

Updated RIPE Documents
by Laura Cobley 08 Jan '09

08 Jan '09

[Apologies for duplicate e-mails] Dear Colleagues, We are pleased to announce the publication of two updated RIPE Documents, ripe-442, 'Autonomous System Number Request Form' and ripe-443, 'Supporting Notes for the Autonomous System Number Request Form'. The updated documents are available at: http://www.ripe.net/ripe/docs/ripe-442.html http://www.ripe.net/ripe/docs/ripe-443.html These updates have been made to reflect the default assignment of 32-bit AS Numbers as of 1 January 2009, in accordance with ripe-389, 'Autonomous System (AS) Number Assignment Policies and Procedures': http://www.ripe.net/ripe/docs/ripe-389.html. Best Regards, Laura Cobley Registration Services RIPE NCC

1 0

Recent Predestinations – End Nov 2008, Tunisia
by Alaa Al-Din Al-Radhi 29 Dec '08

29 Dec '08

Dear Colleagues / Friends Kind respects and happy New Year Allow me to seize this moment to share with you the attached recent PPTs that I have presented (as being hired as an ITU regional consultant) in Tunisia lately. Feel free to disseminate these PPTs to related interested parties. I believe firmly in knowledge share. Your comments and notes are kindly appreciated. If I can be of any future help to your mission, that would be my pleasure and honor. All Blessings and respects Alaa Al-Din (Aladdin) Passionate / Advocate of: Internet, Science, technology, innovations and new frontiers. + 962 796347600 alradhi2000(a)yahoo.ca, alaalradhi(a)hotmail.com http://www.linkedin.com/in/alaaaldinalradhi http://aso.icann.org/elections/radhi.html http://www.pir.org/index.php?db=content/Website&tbl=About_Us&id=7#aalradhi http://akms.org/site_content.aspx?page_key=board_of_trustees&lang=en http://www.isoc.org/pubpolpillar/governance/igf-hyderabad_ambassadors.shtml Excellence is never an accident; it’s always the result of high intention, sincere effort, intelligent direction, skilful execution and the vision to see obstacles as opportunities __________________________________________________________________ Connect with friends from any web browser - no download required. Try the new Yahoo! Canada Messenger for the Web BETA at http://ca.messenger.yahoo.com/webmessengerpromo.php

1 0

DRAFT: allocating resources to the RIPE NCC
by Remco van Mook 17 Dec '08

17 Dec '08

Dear all, Please find below my first attempt at a policy for allocating resources to the NCC. I think it should be a separate ripe document. Please let me know what you think and where it needs some more polishing. I want to publish the formal proposal soon, so the policy can potentially be adopted well in time for the next RIPE meeting. Best, Remco Number: (assigned by the RIPE NCC) Policy Proposal Name: Allocating resources to the RIPE NCC Author: name: Remco van Mook email: remco(a)eu.equinix.com organisation: Equinix Proposal Version: 1.0 Submission Date: TBD Suggested RIPE WG for discussion and publication: address policy Proposal Type: new Policy Term: permanent Summary of proposal: This proposal sets the way in which the RIPE NCC can get resources allocated to itself. Policy text: Current (if modify): none New: Abstract: This document describes how the RIPE NCC can get resources allocated to itself. 1.0 Introduction The RIPE NCC is an independent association and serves as one of five Regional Internet Registries (RIRs). Its service region incorporates Europe, the Middle East, and Central Asia. The RIPE NCC is responsible for the allocation and assignment of Internet Protocol (IP) address space, Autonomous System Numbers (ASNs) and the management of reverse domain names within this region. 1.1 Scope This document describes the policy for allocating resources to the RIPE NCC. This policy applies to all resources, current and future, allocated to the RIPE NCC, its subsidiaries or affiliates. This document does not describe any specific resource or a policy restricted to a specific resource; it does however impact how the resource-specific policies should be interpreted when applied to the RIPE NCC as the entity requesting resources. This document does not describe or impact any policy where it is applied to regular LIRs. 2.0 RIPE NCC as a resource-holder Any resources allocated to the RIPE NCC will be registered in the RIPE database under the LIR identity of 'eu.ripencc'. All policies set for allocating resources to LIRs apply equally to the RIPE NCC. RIPE NCC as a resource holder should fulfill the same basic requirements that are also expected of normal LIRs, such as returning unused resources. Since the RIPE NCC cannot sign a contract with itself, the requirement for an explicit contract as set by various policies does not apply for this particular case. While the RIPE NCC will still handle the administrative tasks involved with allocating resources itself, it will not evaluate the validity of their own requests. 3.0 Pool of Arbiters Defined in ripe-174, the pool of Arbiters has been appointed by the RIPE NCC Executive Committee (and approved by the AGM). The arbiters function is to mediate in a conflict between the RIPE NCC and one of its members. In addition to executing the RIPE NCC Conflict Arbitration Procedure, the pool of arbiters will also evaluate the validity of all requests for resources made by the RIPE NCC. 4.0 Evaluating a request The evaluation of an allocation request made by the RIPE NCC will be done by a team of at least 3 of the arbiters. The arbiters will respond to any new request within one month. For the purpose of evaluating, the request will be treated as if it was filed by a normal LIR. If the request is approved, the resources will then be allocated by the RIPE NCC and registered in the RIPE database. 5.0 Conflict resolution Should the pool of arbiters reject a request, or if the request cannot be granted by applying the standard LIR policies, the RIPE NCC can file a request to the RIPE plenary meeting to have its case heard. It is then up to the RIPE plenary to decide whether the request should be granted or not. At no point can the RIPE NCC allocate resources to itself without prior consent of either the pool of arbiters or the RIPE plenary. Rationale: All resource-holders in the RIPE NCC service area are now being required to have a contractual relationship with the RIPE NCC, directly or indirectly. There is however one entity that cannot sign a contract with the RIPE NCC - the NCC itself. This policy cleans up the current variety in which the NCC has allocated resources to itself and sets a standard way for the RIPE NCC to get further resources allocated. For all means and purposes the RIPE NCC will be treated as a LIR and will follow the same policies as a LIR; however the role the RIPE NCC has in analysing and evaluating any request by an LIR is instead done by members of the pool of arbiters. Arguments supporting the proposal Currently there is no standard way for the RIPE NCC to get resources allocated. This has so far led to an inconsistent picture between the various resource types; a lot of ad hoc policies and exemptions. This needs to be cleaned up. One way to look at it is that every single resource allocated to the RIPE NCC is a conflict of interest between the RIPE NCC and ALL of its members. Therefore it makes sense that the same people who arbitrate conflicts between RIPE NCC and its members evaluate the requests for resources as filed by the RIPE NCC. Arguments opposing the proposal None. This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383.

2 2

2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM)
by Antoin Verschuren 16 Dec '08

16 Dec '08

PDP Number: 2008-05 Anycasting Assignments for TLD's and Tier 0/1 ENUM While I strongly support the proposal for more than 1 anycast assignment per TLD/ENUM tier1 operator, I do have some problems with the definition of the ENUM tier1 operators. Where it says: "ENUM operators as defined by the ITU" I think it should say: "ENUM tier0/1 operators as defined by RIPE NCC" I wouldn't want the ITU to determine who should get address space, and the counterpart for IANA in the ENUM space is RIPE NCC. I see the ITU more in the role ICANN has with regards to TLD's, or perhaps even the US DOC. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525500 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

5 4

Re: [address-policy-wg] 2008-05 Revised/New Discussion Phase set (Anycasting Assignments for TLD's and Tier 0/1 ENUM)
by B C 16 Dec '08

16 Dec '08

I just realised that I responded directly to Antoin and missed cc to the group, so here was my response, apologies for the confusion. On Thu, Dec 11, 2008 at 10:25 AM, B C <brettlists(a)gmail.com> wrote: > On Wed, Dec 10, 2008 at 11:21 AM, Antoin Verschuren > <Antoin.Verschuren(a)sidn.nl> wrote: >> PDP Number: 2008-05 >> Anycasting Assignments for TLD's and Tier 0/1 ENUM >> >> While I strongly support the proposal for more than 1 anycast assignment >> per TLD/ENUM tier1 operator, I do have some problems with the definition >> of the ENUM tier1 operators. >> >> Where it says: >> >> "ENUM operators as defined by the ITU" >> >> I think it should say: >> >> "ENUM tier0/1 operators as defined by RIPE NCC" >> >> I wouldn't want the ITU to determine who should get address space, and >> the counterpart for IANA in the ENUM space is RIPE NCC. >> I see the ITU more in the role ICANN has with regards to TLD's, or >> perhaps even the US DOC. >> However the reason this was put there is that as I undertstand this area, it's not the RIPE NCC's responsibility who gets an ENUM Country Code, those are I believe approved by the ITU and then administred by the RIPE NCC. So I think "ENUM tier0/1 operators as defined by RIPE NCC" would be factually incorrect. Regards Brett

1 0

2007-08 Proposal Accepted (Enabling Methods for Reallocation of IPv4 Resources)
by Filiz Yilmaz 16 Dec '08

16 Dec '08

PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, Consensus has been reached, and the proposal described in 2007-08, "Enabling Methods for Reallocation of IPv4 Resources" has been accepted by the RIPE community. The related RIPE policy document is now updated, published and can be found at: http://www.ripe.net/ripe/docs/ripe-441.html or http://www.ripe.net/ripe/docs/ipv4-policies.html Further implementation details of this policy will follow soon. The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2007-08.html Thank you for your input. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

1 0