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

do you believe ? the time is near.
by Frederic 21 Apr '09

21 Apr '09

hi, http://www.ripe.net/ripe/policies/proposals/2006-01.html it is time to permit IPV6-PI assignement. That the way to permit to IPV6 to be alive in the entire network. Awaiting Decision from WG Chairs : Please give you décision. we need, we want ask our Ipv6-PI ! Bst regards. F.

1 0

New Document available: RIPE-465
by RIPE NCC Document Announcement Service 20 Apr '09

20 Apr '09

Dear Colleagues, The mention of 0.8 as the HD ratio (in two occurrences) in ripe-450 is an error. In RIPE, the HD ratio for IPv6 has been set at 0.94 since November 2007 and was documented correctly in the previous IPv6 Address Allocation and Assignment Policy (ripe-421). We have corrected the error and published an updated document (ripe-465) that you can find at: http://test-www.ripe.net/ripe/docs/ripe-465.html We apologise for any confusion this may have caused and will put in place additional checks to prevent similar errors in the future Kind Regards Adrian Bedford Web Services Team Leader RIPE NCC and Filiz Yilmaz Policy Development Officer RIPE NCC

2 2

2009-05 New Policy Proposal (Multiple IPv6 /32 Allocations for LIRs)
by Ingrid Wijte 18 Apr '09

18 Apr '09

PDP Number: 2009-05 Multiple IPv6 /32 Allocations for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-05.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 12 May 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC

20 73

RE: Multiple IPv6 /32 Allocations for LIRs
by Stream Service 15 Apr '09

15 Apr '09

Hello, (ab)using IPv6 PI is also not a good solution for it I guess. How should we make it possible? With kind regards, Mark Scholten -----Original Message----- From: Andy Davidson [mailto:andy.davidson@netsumo.com] Sent: woensdag 15 april 2009 13:54 To: Stream Service Subject: Re: Multiple IPv6 /32 Allocations for LIRs On 15 Apr 2009, at 12:18, Stream Service wrote: > It should be aggegatable for as far as the LIR wants. It should also > be > possible to split it up to /48's without a problem (for example is 1 > LIR has > multiple ASN's or when some address space should only be available via > peering). It is possible with IPv4 for as far as I know, why don't > make it > possible with IPv6? Hi, Mark Thank you for your email. It is possible with IPv6. The question is, do we really want the v6 table to be as fragmented as the v4 one ? Of course we do not. We want fast convergence in the default free zone. We wont get this if we don't look after the policies which govern assignment though. Andy -- Regards, Andy Davidson, NetSumo Limited D: +44 (0) 20 7993 1702 S: +44 (0) 20 7993 1700 E: andy.davidson(a)netsumo.com

1 0

Policy Proposal : "Run Out Fairly"
by Daniel Karrenberg 15 Apr '09

15 Apr '09

Dear colleagues, attached you will find a policy proposal we call "Run Out Fairly". It is based on a discussion instigated by your's truly during the open policy hour at the latest RIPE meeting. This is a proposal to gradually reduce the allocation and assignment periods in step with the expected life time of the IPv4 unallocated pool in order to address the perception of unfairness once the pool has run out. The proposal is not intended to stretch the lifetime of the unallocated pool. The proposal is independent of other proposals to reserve address space for transition purposes and/or new entrants. It can be implemented independently of these. We thank Filiz Yilmaz for her help, invite discussion of this proposal and look forward to high quality comments. For the authors Daniel Karrenberg PS: Can we refer to this proposal by name and not by number? ;-)

11 17

Volker Frank/PLZ/CSC is out of the office.
by Volker Frank 14 Apr '09

14 Apr '09

I will be out of the office starting 08.04.2009 and will not return until 20.04.2009.

1 0

2009-04 New Policy Proposal (IPv4 Allocationand Assignments to Facilitate IPv6 Deployment)
by alain.bidron＠orange-ftgroup.com 10 Apr '09

10 Apr '09

Thank you for the first comments received on 2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment). Please find hereafter some response. >From Marcus Stoegbauer: >> For a start: I can't really tell if the new policy text should replace >> the old IPv4 address allocation and assignment policy. The new policy >> only talks about address space given out to ISPs for transition >> techniques, so I assume that an ISP with a lot of free (i.e. not >>assigned/unused) IPv4 address space can also get another allocation >>under this policy? Response This policy is done in accordance with existing v4 policies and basic principle is that allocation/assignment should be based on needs. The difference with that policy is the minimum allocation/assignment size is different and filtering policies, should be different in this range. So when requesting additional IPv4 resources (after the IPv4 pool is depleted - from the transition /8) an ISP should still demonstrate the required utilisation of already allocated addresses. If an ISP has already sufficient resources allocated for implementing transition techniques it should not be qualified to receive additional resources from that policy, except if the use of these resources implies fragmentation and filtering issues. This is to be evaluated by the RIPE-NCC when analysing the request. >From Marcus Stoegbauer: > >Then the minimum size of /27. Obviously it would be a brilliant test >> to see if routers will be able to hold all the IPv6 PI prefixes that >> will come to life once we allow them to be handed out. And it would be > >a very handy way to tear down the v4 internet, so it's in full >> compliance with some IPv6 implementation plans. >> But to be serious for a minute: if all those /27 would be announced a > >IPv4 full table would nearly triple in size (or in other words: all > >those /27 are twice the size of a full IPv4 table today). This can't >> possibly end well, so I'm not in favor for this proposal in its >> current form. Response I don't think this policy will really change the size of routing table. If the policy is based on a /24 it would only waste v4 resources, and reduce on medium long term the possibility to provide those necessary resources. The growth of the routing table will be proportional to the growth of the number of new ISPs - PA holders and the use of multi-homing, exactly as today, this proposal will not change this significantly. Please note that a /27 under this proposal will actually represent a today's /21 ( or even shorter prefix). >From Sebastian Wiesinger [ripe+apwg(a)karotte.org] >> First: It won't work. Most people I know filter prefixes smaller than >> /24 in the DFZ. They will not see these allocations. You can't assume >> that they will change their filters for this. I would estimate that >> most of them won't. Many can't do this because it will not fit in >> their RIB/FIB. So if you do this you would have to give out a /24 at least. Response: It won't work in the current situation but will have to work in the new depleted context. Rather than splitting the existing v4 resources in small pieces, the proposal suggests to dedicate a specific /8 where filtering policies could be adapted. >From Sebastian Wiesinger [ripe+apwg(a)karotte.org] >> Second: We do want to facilitate deployment of IPv6. I think this >> proposal could be counterproductive. You're splitting up the remaining >> space in smaller peaces so that more people can use IPv4 for a longer >> timespan. And if you have to give out /24s you can bet that people >> will use it for other things besides NAT-PT etc. Response: No we don't want to prolong v4 lifetime, only to allow for v6 providers to interact with the existing v4 environment that will not disappear overnight. This proposal will not in my views prolong v4. Whether we want this or not, the demand for IPv4 address space after the IPv4 pool is depleted will continue. It will be proportional to the amount of existing IPv4-only resources and the number of newly connected customers, regardless whether they are IPv4 or IPv6-only, or dual-stack. This proposal attempts to satisfy this demand on continuous and predictable basis for the transition period without changing the fundamental principles of resource allocation. >From Sebastian Wiesinger [ripe+apwg(a)karotte.org] > Third: Is it necessary? You already have to demonstrate a need for > address space if you want a new allocation. If an LIR already has an > allocation I assume that they can spare an /27 for IPv6 transition. >> If you have a new LIR you allocate them a /21 if they can demonstrate > the need for it, no change there. Response: I say YES it is necessary because remember we are in a depleted context. It means that the RIPE-NCC will not be in a position to allocate IPv4 addresses under today policies. Are you totally sure that all existing holders of IPv4 resources will be able to spare /27 for IPv6 transition? And regarding new entrants where those /21 will come from? I think we cannot deny that exhaustion is becoming a reality. >From Andy Davidson >> If it's good to restrict the allocation and assignment of v4 resources >> to organisations who have a stated v6 deployment policy, then why do >> we need to wait until the final /8 has been allocated to the NCC >> before we begin such a policy ? Perhaps we should have a phased >> process that asks organisations how they are deploying v6 on the PA >> and PI request forms, and then future requests from that organisation, >> or related organisations are refused if the deployment has not started. Good point Andy, I am not opposed to think about something that could be inserted in the "run out fairly proposal" opening the way to something stricter on the last /8 policy >From Andy Davidson >>Why was /27 selected rather than /26 or /25 ? Since most deployments >>have multiple, separate infrastructure assignments, and services/user >> assignments, it seems that a /27 as a minimum allocation is far to >> small to promote any degree of aggregation whatsoever. This policy is >> therefore counter to one of RIPE's regularly stated aims - to promote >> route aggregation. The counter argument to this is that I might as > >well accept that we the side of common sense has lost the v4 > >aggregation debate, and v4 after-market sales will drive deagg > >further, so why should we care ? Response: Remember that we need a mechanism that allows to provide the small amount of IPv4 addresses needed to interact with the IPv4 environment for a long time (before Ipv4 addresses being completely obsolete).A similar approved policy in ARIN is based on a /28! A downscaling factor of 64 is in my view a good compromise. >From Andy Davidson >> On the other hand, perhaps this policy will be seen as an ipv4 life >> extension policy. We do not want to muddy the message that we send to >> the community. V4's free pool will soon be gone. Do not gamble your >> company on policies designed to extend the availability of a very >> scarce resource. >> Maybe we can pool some of the ideas in 2009-03 and -04, and the >> community response, and build a solid run down policy that encourages >>v6 adoption, but doesn't pretend to be able to extend the life of v4. Response: The intention of the proposal is certainly not to extent the IPv4 life. On the contrary we try to put some incentive for a move to v6 facilitating to those who go that way a fair access to the limited v4 resources strictly needed to interact with the existing v4 environment. We must be realistic even if we all call for a move to v6 Ipv4 will not disappear overnight and transition to IPv6 requires continuous supply of IPv4. Without this we will face an double or triple NAT and walled garden alternatives which will change the architecture and principles of the Internet significantly and will never get us to IPv6. Regards Alain ********************************* This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. Messages are susceptible to alteration. France Telecom Group shall not be liable for the message if altered, changed or falsified. If you are not the intended addressee of this message, please cancel it immediately and inform the sender. ********************************

1 0

2009-04 New Policy Proposal (IPv4 Allocation and Assignments to Facilitate IPv6 Deployment)
by Filiz Yilmaz 10 Apr '09

10 Apr '09

PDP Number: 2009-04 IPv4 Allocation and Assignments to Facilitate IPv6 Deployment Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-04.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 5 May 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

9 12

2008-05 New Policy Proposal (Anycasting Tier 0/1 ENUM)
by Filiz Yilmaz 10 Apr '09

10 Apr '09

PDP Number: 2008-05 Anycasting Tier 0/1 ENUM Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-05.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 2 October 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

3 2

Agenda items for upcoming RIPE meeting?
by Gert Doering 09 Apr '09

09 Apr '09

Hi APWG, the next RIPE meeting is getting close - so if you want to see something specific on the agenda for the APWG meeting in May, please let the WG chairs know. All the "usual" things will be on the agenda already, of course (discussion of open policy proposals, overview of ongoing work, etc.) - this is mainly for exceptional items. I will send a detailed draft agenda with all your input end of next week. Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 0

Run Out Fairly (2009-03) New Policy Proposal
by Filiz Yilmaz 07 Apr '09

07 Apr '09

PDP Number: 2009-03 Run Out Fairly Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-03.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 5 May 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

1 0

2009-02 New Policy Proposal (Allocating Resources to the RIPE NCC)
by Filiz Yilmaz 03 Apr '09

03 Apr '09

PDP Number: 2009-02 Allocating Resources to the RIPE NCC Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-02.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 21 April 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

8 8

Policy?
by Max Tulyev 20 Mar '09

20 Mar '09

Hi all, imagine there is a company having huge allocation/assignment. Some happens (i.e. crisis), they lost a significant number of clients, so they have a lot of free IP space. Is there any policy ENFORCES this company to return unused address space? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 3

Autonomous System (AS) Number Assignment Policies and Procedures
by Filiz Yilmaz 16 Mar '09

16 Mar '09

Dear Colleagues, As previously announced, a draft RIPE Policy Document, "Autonomous System (AS) Number Assignment Policies and Procedures", was published, removing all reference to the previous AS Number registration format (ASDOT). This update was proposed following the publication of RFC5396: ftp://ftp.ripe.net/rfc/rfc5396.txt This review period for this draft document has now concluded, and the updated RIPE Policy Document, "Autonomous System (AS) Number Assignment Policies and Procedures", has been published. You can find this document at: http://www.ripe.net/ripe/docs/ripe-463.html http://www.ripe.net/ripe/docs/asn-assignment.html Thank you for your input. Kind regards, Filiz Yilmaz Policy Development Officer RIPE NCC

1 0

2006-01 Last Call for Comments (Provider Independent (PI) IPv6 Assignments for End User Organisations)
by Filiz Yilmaz 16 Mar '09

16 Mar '09

PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues, The proposal described in 2006-01 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 13 April 2009. Regards, Filiz Yilmaz Policy Development Officer RIPE NCC

1 0

Global Policy for the Allocation of the Remaining IPv4 Address Space
by Filiz Yilmaz 12 Mar '09

12 Mar '09

Dear Colleagues, Proposal 2008-03, "Global Policy for the Allocation of the Remaining IPv4 Address Space", was accepted by the RIPE community in September 2008. This proposal has since reached consensus in all other RIR regions and it is now also ratified by ICANN on 6 March 2009. You can find the policy documented at: http://www.ripe.net/ripe/docs/ripe-436.html Kind regards, Filiz Yilmaz Policy Development Officer RIPE NCC

1 0

New AS Number block allocated to the RIPE NCC
by florpare＠ripe.net 10 Mar '09

10 Mar '09

Dear Colleagues, The RIPE NCC received the AS Number Block 49152 - 52223 from the Internet Assigned Numbers Authority (IANA) in March 2009. You may want to update your records accordingly. Regards, Flor de Maria Paredes Mattos Registration Services Manager RIPE NCC

3 2

New Documents available
by Ingrid Wijte 03 Mar '09

03 Mar '09

Dear Colleagues We have published several new RIPE Documents. The publication of these documents follows the implementation by the RIPE NCC of phase one of the previously accepted policy proposal 2007-01: "Direct Internet Resource Assignments to End Users from the RIPE NCC". Policy Documents: - ripe-449, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". It replaces ripe-441, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". - ripe-448, "Autonomous System (AS) Number Assignment Policies and Procedures". It replaces ripe-389, "Autonomous System (AS) Number Assignment Policies and Procedures". - ripe-450, "IPv6 Address Allocation and Assignment Policy". It replaces ripe-421, "IPv6 Address Allocation and Assignment Policy". - ripe-451, "IPv6 Address Space Policy for Internet Exchange Points". It replaces ripe-256, "IPv6 Address Space Policy for Internet Exchange Points". - ripe-452, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". This is a new RIPE Document. RIPE NCC Organisational Document: - ripe-462, "RIPE NCC End User Assignment Agreement". This is a new RIPE Document. Request Forms and Supporting Notes: - ripe-453, "Provider Independent (PI) Assignment Request Form". It replaces ripe-356, "Provider Independent (PI) Assignment Request Form". - ripe-454, "Supporting Notes for the Provider Independent (PI) Assignment Request Form". It replaces ripe-357, "Supporting Notes for the Provider Independent (PI)Assignment Request Form". - ripe-456, "AS Number Request Form". It replaces ripe-444, "AS Number Request Form". - ripe-457, "Supporting Notes for the Autonomous System Number Request Form". It replaces ripe-445, "Supporting Notes for the Autonomous System Number Request Form". - ripe-458, "Anycast Assignment Request Form". It replaces ripe-390, "Anycast Assignment Request Form". - ripe-459, "Supporting Notes for the Anycast Assignment Request Form". It replaces ripe-391, "Supporting Notes for the Anycast Assignment Request Form". - ripe-460, "IPv6 Internet Exchange Points Assignment Request Form". It replaces ripe-371, "IPv6 Internet Exchange Points Assignment Request Form" - ripe-461, "Supporting Notes for the IPv6 Internet Exchange Points Assignment Request Form". It replaces ripe-372, "Supporting Notes for the IPv6 Internet Exchange Points Assignment Request Form". The new documents are available at: http://www.ripe.net/ripe/docs/titletoc.html Recently Published section available at: http://www.ripe.net/ripe/docs/recent.html Best regards Ingrid Wijte IP Resource Analyst RIPE NCC

1 0

2009-01 New Policy Proposal (Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries)
by Filiz Yilmaz 27 Feb '09

27 Feb '09

PDP Number: 2009-01 Global Policy for the Allocation of IPv4 blocks to Regional Internet Registries Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-01.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 19 March 2009. Regards Filiz Yilmaz Policy Development Officer RIPE NCC

15 29

2009-01 New Policy Proposal
by Milton L Mueller 25 Feb '09

25 Feb '09

A typo? Addresses will be allocated to RIRs "Providing that the RIR satisfies the allocation criteria described section 4.2.2,..." There is no 4.2.2. Does it mean 3.2.2.? Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org

2 1

Re: 2009-01 New Policy Proposal
by Milton L Mueller 24 Feb '09

24 Feb '09

Some short questions about this policy: 1. What does this policy do that a globalized transfer policy would not do faster, better and with less overhead? 2. Is this policy proposal motivated by the asymmetry in RIR's transfer policies? (e.g., the failure of ARIN to adopt a transfer policy despite North Am. being where most of the unused v4 space is) 3. In regards to Remco's statement: > The current policy between IANA and the RIRs for allocating > IPv4 will become unusable once IANA runs out. We need a new > policy that keeps the structure between IANA and RIRs in place > and gives IANA something useful to do. Why should we care about "keeping the structure between IANA and RIRs in place?" (not a rhetorical question, really want to know) 4. Did anyone answer Heather's excellent question: > If address space is returned to an RIR, and they have an immediate > need for that space, can they assign it? or *must* they wait for the > quarterly interval and return it to IANA? Milton Mueller Professor, Syracuse University School of Information Studies XS4All Professor, Delft University of Technology ------------------------------ Internet Governance Project: http://internetgovernance.org

1 0

2007-01 implementation clarification
by Andy Davidson 24 Feb '09

24 Feb '09

Hi, A customer has indicated to me that they want PI space for a business or project that is not incorporated. Under the new 2007-01 rules, what is the correct way to request PI? In UK law, a business might not be incorporated, but in such circumstances, the income and actions of the business are treated as the income and actions of the principal person behind the business. In such circumstances does this mean the individual should apply for PI? Previously I'd have advised to use the trading name to apply for PI, but under new rules I am aware that PI holders need to be able to sign contracts... The trading name might not be a legal entity able or willing to sign. They plan to multihome, their need for PI appears justified to me. Andy

5 4

Minutes from RIPE 57 (Dubai)
by Gert Doering 16 Feb '09

16 Feb '09

Hi APWG, the minutes from RIPE 57 are now online: http://www.ripe.net/ripe/wg/address-policy/r57-minutes.html if you feel there is anything missing or inaccurate, please let us know. Many thanks to the folks at the RIPE NCC for this amazing job! Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 0

2007-01 Implementation: Direct Internet Resource Assignments to End Users from the RIPE NCC
by Andrea Cima 16 Feb '09

16 Feb '09

[Apologies for duplicate emails] Dear Colleagues, We are pleased to announce that phase one of policy proposal 2007-01, "Direct Internet Resource Assignments to End Users from the RIPE NCC", will be implemented on 3 March 2009. This change will require that an End User have a contractual relationship with a sponsoring LIR or the RIPE NCC before the End User can receive Internet number resources (Autonomous System (AS) Number, Provider Independent (PI) IPv4 and IPv6, Internet Exchange Point (IXP) and anycasting assignments) directly from the RIPE NCC. The full text of policy proposal 2007-01 can be found at: http://www.ripe.net/ripe/policies/proposals/2007-01.html Phase one addresses the implementation of the new policy in relation to all new requests for independent numbering resource assignments. Please note that from 3 March 2009, End Users requesting independent numbering resources must sign a contract with a sponsoring LIR or with the RIPE NCC in order to receive those resources. Requests for independent numbering resources that do not demonstrate such a contract will not be processed by the RIPE NCC. Information on the required content of contracts between End Users and sponsoring LIRs is available at: http://www.ripe.net/membership/lir-end-user-requirements.html Phase two of policy proposal 2007-01 will address the contractual relationship between End Users who hold previously assigned independent numbering resources and the RIPE NCC or a sponsoring LIR. A plan for implementation of this phase will be presented at the next meeting of the RIPE NCC Services Working Group, which will take place at the RIPE 58 Meeting in Amsterdam from 4-8 May 2009. Kind regards, Andrea Cima RIPE NCC

5 5

2008-09 Policy Proposal Withdrawn (ASPLAIN Format for the Registration of 4-byte ASNs)
by Filiz Yilmaz 12 Feb '09

12 Feb '09

PDP Number: 2008-09 ASPLAIN Format for the Registration of 4-byte ASNs Dear Colleagues, The proposal 2008-09, "ASPLAIN Format for the Registration of 4-byte ASNs", has been withdrawn. It is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2008-09.html Given the recent publication of RFC 5396, the proposer and the Address Policy WG Chairs have agreed that there is no need to keep 2008-09 in the RIPE Policy Development Process. RFC 5396 can be found at: ftp://ftp.ripe.net/rfc/rfc5396.txt Following feedback received in RIPE 57, the Address Policy WG Chairs have also concluded that the current RIPE Policy Document ripe-389, "Autonomous System (AS) Number Assignment Policies and Procedures", will be updated so that the reference to the previous registration format is deleted from the policy document. We have now published a draft RIPE Policy Document, in which the changes are marked: http://www.ripe.net/ripe/draft-documents/ripe-389-draft-2008-09.html We encourage you to read this document and, if you have any comments, send them to <address-policy-wg(a)ripe.net> before 12 March 2009. After this date we will publish the draft document as a RIPE Policy Document. A further announcement will be made shortly regarding the full implementation of the ASPLAIN registration format for 32-bit AS Numbers by the RIPE NCC. Regards, Filiz Yilmaz Policy Development Officer RIPE NCC

3 2