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

New on RIPE Labs: RIPE NCC Membership Statistics Q3 2015
by Mirjam Kuehne 30 Oct '15

30 Oct '15

Dear colleagues, We look at the RIPE NCC in terms of growth, geographic distribution and IPv6 deployment. We find that recent RIPE policy changes have had an impact on membership statistics and development trends. Please find the results on RIPE Labs: https://labs.ripe.net/Members/wilhelm/ripe-ncc-membership-statistics-q3-2015 Kind regards, Mirjam Kuehne RIPE NCC

1 0

2015-05
by Shahin Gharghi 29 Oct '15

29 Oct '15

Hello I support this proposal. If you are worry about running out of IPv4, you should stop those are registering new LIRs, transfer the IPs and close the LIR. Even 2015-01 is unable to stop them. If it is limited to those LIRs who didn't transfer any IP to other LIRs, I think it could reduce amount of unnecessary transfers. I heard a lot about this: "New entrants should have access to IPv4". I think you should say that in this way: " The new entrants should have access to the INTERNET". Don't you think the new LIRs need to run IPv6? or imagine we are in 2020 and we ran out of IPv4, what should we do? Do it now. I think we are just postpone switching to v6. -- Shahin Gharghi

17 47

Revision of Last /8 Allocation Criteria
by Pietro Asproni 29 Oct '15

29 Oct '15

Dear All,, proposal appropriate and acceptable. Also you need to put a brake to trade of the IPv4 networks Regards, Pietro Asproni PA7-RIPE

1 0

Re: [address-policy-wg] IP addresses for Iran
by Saeed Khademi 22 Oct '15

22 Oct '15

Hello everybody, I read all messages in this regard, and I think conversation is going off the road. One individual, or one LIR may talk about their own opinion regarding the proposal. Please do not extent the talk to all LIRs from Iran or any other region. and I don't think that it is wise to stamp a technical proposal with political issues. Are we talking about IPV4 and IPV6, or we are talking about how Iran is managing it's address space? Kind Regards, Saeed. -----Original Message----- From: Jim Reid Sent: Wednesday, October 21, 2015 5:43 PM To: Shahin Gharghi Cc: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] IP addresses for Iran On 21 Oct 2015, at 14:49, Shahin Gharghi <shahin(a)gharghi.ir> wrote: >> What's stoping Iranian LIRs getting an IPv6 allocation from the NCC? > > Iran has a lot of IPv6 allocation but can't announce any. So the probem isn't getting or using address space, it's routing that space. This WG (and RIPE more generally) is not in a position to decide or enforce the peering and transit policies used by ISPs ad IXPs. >> Even they can't buy IP from outside of country because of sanctions. > > Solving the sanctions problem isn't within RIPE's control. > > RIPE NCC can ease the process.I'm not sure it can. It would be up to the RIPE community to reach consensus > on a policy proposal which somehow eases Iran's sanctions problems. I > doubt a policy could have that effect. If you have some ideas about how > this could be done, please share them or submit a policy proposal which > does that. > People mentioned Iran as instance, so I explained the situation. > Community has to agree that Iran and similar countries are a part of > community and they can see the proposals from their own view. You are > talking about making IPv4 available in future, and one of the biggest user > of IPv4 in future is Iran or similar countries, so it seems we have to > look at them. Of course Iran is part of the community. However when RIPE develops address policies here, we are supposed to consider the interests of the community as a whole and do the best (or least worst) for everyone. Current policy allows Iranian LIRs to get the same sized IPv4 allocations as everyone else. IMO they're no better off or worse off than any other LIRs in the RIPE service region who need to get v4 space from the NCC.

3 3

2015-05
by Shahin Gharghi 21 Oct '15

21 Oct '15

> > I think the answer expected was to clarify (for whomever is interested) why > Iran companies can't announce IPv6. > > You can check that in RIP NCC's statistics. Whole Iran LIRs have one upstream provider (AS12880 AS48159) and it doesn't support IPv6. Also making tunnel to some brokers is illegal and blocked and if it was open, brokers don't work with Iran because of sanctions. Again, what are you talking about sanctions ? As I mentioned Iran is the > largest importer of IPv4 space and it comes from all over the region. > People should transfer money illegally to outside of Iran because we can't use SWIFT as you know. So if we transfer money and they won't transfer the IP's, there is no where to complain. (at least RIPE NCC can help in this case to ease transfers) So if we could transfer easily the number of transfers would be much more. > I'm not sure it can. It would be up to the RIPE community to reach > consensus on a policy proposal which somehow eases Iran's sanctions > problems. I doubt a policy could have that effect. If you have some ideas > about how this could be done, please share them or submit a policy proposal > which does that. > > I'll do my best to submit a proposal. > Of course Iran is part of the community. However when RIPE develops > address policies here, we are supposed to consider the interests of the > community as a whole and do the best (or least worst) for everyone. Current > policy allows Iranian LIRs to get the same sized IPv4 allocations as > everyone else. IMO they're no better off or worse off than any other LIRs > in the RIPE service region who need to get v4 space from the NCC. > > I don't say Iranian LIRs should receive bigger parts, I mean even this /22's can help them. I apologize if some of my notes are not related to this WG. -- Shahin Gharghi

1 0

2015-05
by Shahin Gharghi 21 Oct '15

21 Oct '15

> > > > > > They need IP more than every country and they can't have even ONE IPv6. > > What's stoping Iranian LIRs getting an IPv6 allocation from the NCC? > Iran has a lot of IPv6 allocation but can't announce any. > > > Even they can't buy IP from outside of country because of sanctions. > > Solving the sanctions problem isn't within RIPE's control. > RIPE NCC can ease the process. People mentioned Iran as instance, so I explained the situation. Community has to agree that Iran and similar countries are a part of community and they can see the proposals from their own view. You are talking about making IPv4 available in future, and one of the biggest user of IPv4 in future is Iran or similar countries, so it seems we have to look at them. -- Shahin Gharghi

4 3

2015-05
by Shahin Gharghi 21 Oct '15

21 Oct '15

> > > > If RIPE runs out of IPv4 sooner it will not help switching to v6 faster. > It only means that the new entrants will have to buy the resources from > the market at prices which will be obviously higher. > And what will happen if we run out of IPv4 later? People have to pay a lot of money while there are a lot of unused IPs in the world. Don't you think that's a good business for those got a lot of IPs and didn't use them? > > Iran is a good example, as a country can be considered a relatively new > entrant. What has happened over there ? 0.05% IPv6 adoption rate > according to google stats and Iran is the #1 importing country of IPv4 > resources. > This is exactly why I'm supporting this proposal. Most of you have no idea about how bad the situation is in Iran. They need IP more than every country and they can't have even ONE IPv6. Even they can't buy IP from outside of country because of sanctions. > > I don't understand why there's still this confusion that if RIPE's pool > will be empty, many think there will be no more IPv4 available and > everyone will go the next day to IPv6. It's totally wrong. > > I agree with you but at least makes it faster. -- Shahin Gharghi

3 2

2015-05
by Jim Reid 20 Oct '15

20 Oct '15

This policy proposal is a Very Bad Idea. I oppose it. The arguments presented in support of this proposal make no sense. IMO 2015-05 is harmful and not in the best short- or long-term interests of the RIPE community. There may be a case for making an LIR's final IPv4 allocation larger than a /22. However that position is not yet backed up by any supporting data and would need to go in another policy proposal anyway. I hope the WG kills 2015-05.

3 2

2014-03 "Remove Multihoming Requirement for AS Numbers Assignments" take #4
by Job Snijders 15 Oct '15

15 Oct '15

Dear APWG, Following the outcome of the vote on the new charging scheme, the inevitable depletion of 16-bit ASNs, opposition to arbitrary limits suck as '1000', but most importantly the incessant need to obtain ASNs when one needs them, we have a new simpler version of the proposal ready for your consideration and review: """ A new AS Number is only assigned when the End User has a need that cannot be satisfied with an existing AS Number. RIPE NCC will record, but not evaluate this need. The Autonomous System's routing policy should be defined with RPSL in the RIPE RIPE Database. The RIPE NCC will assign the AS Number directly to the End User upon a request that is properly submitted to the RIPE NCC either directly or through a sponsoring LIR. AS Number assignments are subject to the policies described in the RIPE Document, "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". """ diff: https://github.com/ytti/ripe/commit/5c0a8587c53c42e5b6630716ff073cfd117ef1b9 full: https://github.com/ytti/ripe/blob/master/ripe-525.remove_multihome.txt I've noted as an argument opposing this proposal: "An adversary could try to deplete the pool of available ASNs." If someone has a workable suggestion how to resolve that in policy, I am all ears, but I wouldn't mind a pragmatic approach where we just trust our community and deal with issues if and when they arise. Kind regards, Job

8 15

RIPE 70 Address Policy WG Draft Minutes
by Marco Schmidt 12 Oct '15

12 Oct '15

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 70 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-70 Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Policy Proposal Implemented: 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size"
by Matt Parker 09 Oct '15

09 Oct '15

Dear colleagues, We are pleased to announce that we have implemented policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size". In accordance with the new policy, the criteria used to evaluate the size of an initial IPv6 allocations has been expanded to include: - Hierarchical and geographical structuring of the organisation - Planned longevity of the allocation - Segmentation of infrastructure for security You can find more information about the expanded evaluation criteria here: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-crite… The archived policy proposal can be found here: https://www.ripe.net/participate/policies/proposals/2015-03 The RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available here: https://www.ripe.net/publications/docs/ripe-655 Kind regards, Matt Parker RIPE NCC Registration Services

2 3

2015-04 Discussion Period extended until 25 September 2015 (RIPE Resource Transfer Policies)
by Marco Schmidt 08 Oct '15

08 Oct '15

Dear colleagues, The Discussion Period for the proposal 2015-04, "RIPE Resource Transfer Policies" has been extended until 25 September 2015. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. The proposer asked to provide additional feedback or questions. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Marco Schmidt Policy Development Officer RIPE NCC

3 3

New on RIPE Labs: IPv4 in the RIPE NCC Service Region - Three Years After Reaching the Last /8
by Mirjam Kuehne 08 Oct '15

08 Oct '15

Dear colleagues, In September 2012 the RIPE NCC reached its last /8 of available IPv4 addresses. This activated a new phase in the RIPE IPv4 policies, with each LIR now eligible to receive one final /22 allocation. In this new article on RIPE Labs we look at developments in IPv4 allocations and remaining addresses at the RIPE NCC in the three years since then: https://labs.ripe.net/Members/wilhelm/ipv4-in-the-ripe-ncc-service-region-t… Kind regards, Mirjam Kuehne RIPE NCC

1 0

2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by Marco Schmidt 02 Oct '15

02 Oct '15

Dear colleagues, A new RIPE Policy Proposal, "RIPE Resource Transfer Policies" has been made and is now available for discussion. The goal of this proposal is to create a single document with all relevant information regarding the transfer of Internet number resources. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 14 September. Regards Marco Schmidt Policy Development Officer RIPE NCC

12 24

Re: [address-policy-wg] 2015-03 Proposal Accepted (Assessment Criteria for IPv6 Initial Allocation Size)
by Mathew Newton 01 Oct '15

01 Oct '15

Hi Marco, > Consensus has been reached on the proposal to amend RIPE Document > ripe-650, "IPv6 Address Allocation and Assignment Policy". > The new RIPE Document is called ripe-655 and is available at: > > https://www.ripe.net/publications/docs/ripe-655 That's great news! > Thank you to everyone who provided input. Yes, and thanks also to you and your colleagues for your assistance throughout the process. Regards, Mathew

1 0

Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"
by Nikolas Pediaditis 01 Oct '15

01 Oct '15

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". In accordance with the new policy, Internet number resources can be transferred between resource holders in the RIPE NCC service region and resource holders in the service regions of other Regional Internet Registries (RIRs). Inter-RIR transfers are possible between RIRs with compatible policies. Currently, ARIN and APNIC are the only RIRs that can perform inter-RIR transfers with the RIPE NCC: - IPv4 addresses can be transferred to/from the ARIN service region - IPv4 addresses and AS Numbers can be transferred to/from the APNIC service region The main web page on inter-RIR transfers with the supporting documentation and all related information to get you started can be found at: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tra… The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2014-05 The RIPE Document, "Policy for Inter-RIR Transfers of Internet Resources", is available at: https://www.ripe.net/publications/docs/ripe-644 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services

5 7

2015-03 Proposal Accepted (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 01 Oct '15

01 Oct '15

Dear colleagues, Consensus has been reached on the proposal to amend RIPE Document ripe-650, "IPv6 Address Allocation and Assignment Policy". This policy change introduces new criteria for the evaluation of large IPv6 allocation requests: * Hierarchical and geographical structure * Segmentation for security * Planned longevity The existing requirements in the policy that stipulate the number of users a nd extent of the infrastructure remain unchanged. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 The new RIPE Document is called ripe-655 and is available at: https://www.ripe.net/publications/docs/ripe-655 We estimate that this proposal will take about one week to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 29 Sep '15

29 Sep '15

Dear colleagues, The draft document for version 2.0 of the policy proposal 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", has now been published, along with an impact analysis conducted by the RIPE NCC. The proposal aims to expand the criteria for evaluating initial IPv6 allocations larger than a /29. The RIPE NCC would consider additional aspects beyond only the number of existing users and extent of the organisation's infrastructure. Some of the differences from version 1.0 include: - Introduction of new assessment criteria used to evaluate IPv6 allocations larger than a /29 - Related wording adjustments in the summary and rationale of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-03/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC

9 19

Discussion phase .. 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by Erik Bais 16 Sep '15

16 Sep '15

Dear all, The initial discussion phase of the proposal has passed .. however I would like to extend it to allow some additional time for people to provide insight or feedback and questions to the end of next week ( Sept. 25 2015 ). Ill work with the NCC in the timing to see if we can get the Impact Analyses done before the Bucharest RIPE meeting. So if you have not read the proposal, please have a look at it.. If you have additional insight or questions about it, please let me know. Quick short link to the proposal : https://www.ripe.net/participate/policies/proposals/2015-04 Regards, Erik Bais

1 0

"last /8" allocation size - community feedback request before engaging PDP
by Radu-Adrian FEURDEAN 15 Sep '15

15 Sep '15

Hello everybody, Back at RIPE70 Elvis and me presented some ideas about revising the IPv4 allocation policy ( https://ripe70.ripe.net/presentations/93-Last-_8-allocation-size.pdf ) Before submitting the proposal we would like to have some community feedback on several aspects : 1. Separate pools or single pool a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per LIR) and a "recovered space pool" containing all space received from IANA as "recovered and redistributed space" (for extra allocations) - APNIC-like separation of pools b. treat all addressing space available for allocation as a single pool 2. Conditions for allocation the first /22. - none (keep the situation as it is today - our preferred option) - something else (please detail) 3. Further allocation(s) (after the first /22) 3.1 introduce some minimum delay after the last allocation : 12 months (Elvis' favourite) ? 18 Months ? 24 Months (my favourite) ? More ? Less ? None ? 3.1.1 Does that mean one can get a new allocation every X months (LACNIC-style) while the stock lasts ? 3.2 Allocation size : /22 ? /23 ? variable depending on how much is available at the time of allocation, max /22, min /24 (which does imply a little more policy text in order to detail this) ? 3.3 Additional conditions 3.3.1 "LIR did not perform an outbound transfer" (do you think it would make sense to have this condition for the first allocation too) ? 3.3.2 Other conditions ??? We (me and Elvis) would like to hear your opinion (on the list or in private) on those subjects in order to be able to submit a (we hope stable) policy proposal before the end of the month. The arguments for each change in the policy will come at that moment (with the policy itself), and yes, we do have arguments for each option presented here :) Regards, -- Radu-Adrian FEURDEAN fr.ccs

13 23

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by George Michaelson 03 Sep '15

03 Sep '15

Right. I mussed up some details. The substance remains: if you are exposed to economics which depends on the use of communities for TE, and cannot influence external agents you do BGP with to support extended communities, then you may decide you need a 16bit ASN, and so they have inherent value to you, distinct from any other resources potentially in transfer. You aren't looking to acquire active IPv4, or IPv6, you are looking to acquire a 16 bit ASN as a thing in itself. -G On 3 September 2015 at 15:49, Nick Hilliard <nick(a)inex.ie> wrote: > This has come up several times before. There is support for asn32s in bgp > extended communities: you need the "Transitive Four-Octet AS-Specific > Extended Community" values from here: > > http://www.iana.org/assignments/bgp-extended-communities > > ... and you need to hope that this is supported on your router software. > And everyone else's that you plan to talk to. > > This can work in some situations where you have tight control over the > entire management plane of everywhere you plan to export these communities > to, but the internet at large is going to have a lot more difficulty with > it. > > As you point out, you can only support 16b:32b or 32b:16b style communities > with the current community mechanism, not 32b:32b communities. The latter > will require implementation of draft-ietf-idr-wide-bgp-communities. > > So if you have any requirement for 32b:32b communities, you're out of luck. > > Nick > > On 03/09/2015 18:59, George Michaelson wrote: > > Purely as a point of information, I think its worth remembering that 32 > bit > > ASN cannot be used in currently specified BGP4 in communities, because > its > > a 32 bit field defined as two 16 bit halves. I believe there is work > afoot > > in IETF to fix this. I don't have concrete details. > > > > Therefore there *is* a quality in 16 bit ASN which may be divorced from > its > > association with specific V4 or V6 resources and which makes it a > desirable > > thing, in itself, for some people: If you are in the business of doing TE > > in BGP with communities, you can't do it with 32 bit ASN. You have to use > > other mechanisms. > > > > On that basis, Should you permit transfers of ASN, you might wish to > permit > > transfers of ASN independently of any associated routable IP address > space: > > people who already have space but need a 16 bit ASN may wish to acquire > one. > > > > I'm not an asset holder in the RIPE region, and I am staff at another > RIR, > > so I stress this is purely informational. I'm not trying to directly > > advocate for or against ASN transfers. > > > > -George > > > > On 3 September 2015 at 14:38, Nick Hilliard <nick(a)inex.ie > > <mailto:nick@inex.ie>> wrote: > > > > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > > Mind, if yelling loudly is how you get policy made in the RIPE > > > community, rest assured I can yell VERY loudly. I can, in fact, > > > even automate the yelling if need be. > > > > please don't: rfc7282 works much better. > > > > Nick > > > >

2 1

Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE Resource Transfer Policies)
by George Michaelson 03 Sep '15

03 Sep '15

Purely as a point of information, I think its worth remembering that 32 bit ASN cannot be used in currently specified BGP4 in communities, because its a 32 bit field defined as two 16 bit halves. I believe there is work afoot in IETF to fix this. I don't have concrete details. Therefore there *is* a quality in 16 bit ASN which may be divorced from its association with specific V4 or V6 resources and which makes it a desirable thing, in itself, for some people: If you are in the business of doing TE in BGP with communities, you can't do it with 32 bit ASN. You have to use other mechanisms. On that basis, Should you permit transfers of ASN, you might wish to permit transfers of ASN independently of any associated routable IP address space: people who already have space but need a 16 bit ASN may wish to acquire one. I'm not an asset holder in the RIPE region, and I am staff at another RIR, so I stress this is purely informational. I'm not trying to directly advocate for or against ASN transfers. -George On 3 September 2015 at 14:38, Nick Hilliard <nick(a)inex.ie> wrote: > On 03/09/2015 18:09, Sascha Luck [ml] wrote: > > Mind, if yelling loudly is how you get policy made in the RIPE > > community, rest assured I can yell VERY loudly. I can, in fact, > > even automate the yelling if need be. > > please don't: rfc7282 works much better. > > Nick > >

2 1

Update on Inter-RIR Transfer Implementation
by Marco Schmidt 01 Sep '15

01 Sep '15

Dear colleagues, We wanted to update you on our implementation of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources". We have made good progress so far on what has been one of the most substantial policy changes ever implemented by the RIPE NCC. Most of the updates to our internal processes and software have been finalised, as have the processes that require interaction with the other RIRs. During the implementation we encountered some additional complexity in the transfer process. To compensate for this, we are developing additional software automation to ensure the quality of registration data is maintained. We now therefore expect the implementation to be finished before the end of September. The policy implementation status has been updated accordingly, and you can find this here: https://www.ripe.net/manage-ips-and-asns/resource-management/policy-impleme… We will send another announcement once the implementation has been completed. Kind regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

RIPE IPv4 Allocation Policy
by SBS - Support 31 Aug '15

31 Aug '15

Dear RIPE Address Policy Group, The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and coming up with a process to allocate further resources to new LIR's if the need can be justified. Regards, Walter This electronic message contains information from Sona Business Services (SBS) which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or e-mail and delete this message immediately.

10 15

2015-03 Last Call for Comments (Assessment Criteria for IPv6 Initial Allocation Size)
by Marco Schmidt 31 Aug '15

31 Aug '15

Dear colleagues, The proposal described in 2015-03, "Assessment Criteria for IPv6 Initial Allocation Size", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 29 September 2015 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of the Working Group for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-03 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 29 September 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0