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

Re: [address-policy-wg] [policy-announce] 2016-05 New Policy Proposal (Synchronising the Initial and Subsequent IPv6 Allocation Policies)
by Newton, Mathew C1 (ISS Des-Arch33-Arch) 24 Nov '16

24 Nov '16

Dear WG, On 24 November 2016 13:16, Marco Schmidt wrote: > A new RIPE Policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" > is now available for discussion. > > The goal of this proposal is to match the subsequent IPv6 allocation requirements with the initial allocation requirements. I am pleased to see the arrival of this policy proposal as whilst the additional assessment criteria introduced by proposal 2015-03 allowed the legitimate requirements of a broader range of organisations to be satisfied it was of benefit only to those that had not previously received address space (and/or those in a position to return/exchange it). These same requirements do however exist equally for many other organisations who should not be discriminated against simply because they happened to have received their initial allocation under the previous assessment criteria. The proposed policy serves to remove this discrimination and provide the same benefits to all, notwithstanding the unavoidable practical difficulty of providing contiguous address space to organisations who may find themselves 'landlocked' by allocations already made to other organisations. In light of the above I fully support the adoption and implementation of the proposed policy. Regards, Mathew

1 0

RIPE Accountability Task Force
by Athina Fragkouli 24 Nov '16

24 Nov '16

Dear colleagues, At RIPE 73 there was support for a review of the RIPE community's accountability, by looking at its current procedures, documentation and structures. An Accountability Task Force has been established to carry out this work and will have its first meeting in the coming weeks, after which a charter and additional information will be published. A mailing list will also be created for the Task Force’s discussions and the archives will be publicly available. You can find the accountability presentation at RIPE 73 here: https://ripe73.ripe.net/archives/video/1248/ If you have feedback or would like to join the Task Force, please send an email to <athina.fragkouli(a)ripe.net>. Kind regards, Athina Fragkouli Head of Legal RIPE NCC

1 0

Migration Datacenter
by ANGEL MARTINEZ SANCHEZ 24 Nov '16

24 Nov '16

Hello, We are going to migrate from our actually datacenter to another one. We have /22 IPs block and not have AS number, our datacenter announce them. Our plan is as follows: - We already add new route objects before migration and will remove old after migration. - At dawn on Sunday, November 27 about 3:00 AM, we will shut down all our servers from the current data center. - At that point we will delete the current route ASXXXX in RIPE DB from inetnum XXX.XXX.XX.0/22 and only the route object corresponding to new datacenter will remain. - We will contact new datacenter to activate our IP block on their router and configure the requested gateway. - We will dismantle the entire rack from old datacenter and move it to the new datacenter where we will start up all our servers again. We need to know if the procedure is correct and very important, the time it takes to propagate the new route of our IP block since we delete the current ASXXXXX and the new ASXXXX is activated by new datacenter. We also need to know if we depend on any action by the current data center to complete this procedure. For example, if they have to remove our block from their AS or their router and that would happen in case they refused to do so on the date indicated for the migration. Thanks and regards. Angel Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)
by Marius Cristea 18 Nov '16

18 Nov '16

Dear colleagues, Over the last years RIPE NCC has imposed a "rule" that when the last IPs are transferred the transferring LIR has to pay the full annual membership fee (even if the LIR was not a member of RIPE for that entire year). I think that if this is something everybody agrees with, it should be inserted into the policy text to make this very clear. But if not, then maybe it would be useful to add a text which would simply say that RIPE NCC should relate exclusively on this policy when processing transfer requests and is not mandated by the RIPE community in imposing any kind of abusive taxes. I also have a problem with the 24 months period of keeping the IPv4 addresses after merging 2 companies. It's exactly our case, we want to buy and merge with a telecom company and we will no longer need all their IPv4 addresses since we have more than enough by merging both companies resources. We want to transfer a part of the IP addresses to other Company that really need them. Why to wait 24 months? Best Regards, Marius Cristea

11 32

2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)
by Marco Schmidt 17 Nov '16

17 Nov '16

Dear colleagues, A new RIPE Policy proposal 2016-04, "IPv6 PI Sub-assignment Clarification" is now available for discussion. The goal of this proposal is to define sub-assignments in IPv6 PI assignments as subnets of /64 and shorter. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2016-04 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 21 November 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

19 33

2016-03 Policy Proposal Withdrawn (Locking Down the Final /8 Policy)
by Marco Schmidt 15 Nov '16

15 Nov '16

Dear colleagues, The proposal 2016-03, "Locking Down the Final /8 Policy" has been withdrawn. It is now archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer decided to abandon the proposal as he felt that the ongoing discussion was damaging the RIPE community’s reputation. As nobody stepped forward to take over the authorship this proposal, the proposal was withdrawn. Regards Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

ALLOCATED PI / UNSPECIFIED next action
by Sander Steffann 27 Oct '16

27 Oct '16

Hello working group, The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions. A total of 16 people and the working group chairs participated in the discussion following Ingrid’s proposal on how to handle the situation of PI assignments within ALLOCATED PI / UNSPECIFIED. Five people (Sergey Myasoedov, Radu-Adrian FEURDEAN, Nick Hilliard, Leo Vegoda and Hank Nussbacher) created side-threads without expressing an explicit opinion on the proposal. The remaining 11 people were: − Patrick Velder − Larisa Yurkina − Randy Bush − Enno Rey − Herve Clement − Stefan Schiele − Markus Weber − Carlos Friacas − Leo Vegoda − Andre Chapuis − Daniel Stolpe − Oliver Bartels Four participants stated that they represent organisations holding such allocations (Larisa, Markus, Andre and Daniel). Three people indicate that they are related to PI assignments within such allocations (Enno, Stefan and Oliver). Five people stated their clear support for the proposal (Enno, Stefan, Oliver, Patrick and Herve), mainly to increase clarity for PI assignment user and to support correct registration. While there was no explicit opposition, Larisa and Andre stated that it would create extra workload for their organisations while they don’t really see the gains of such change. Larisa suggested to introduce alternative RIPE database statuses instead. The other participants had mixed opinions: Markus understands the advantages for PI assignment users, but was concerned about the extra workload for his organisation. He suggested to somehow lock PI’s within the allocations and force the PI holders to sign contracts, but recognized that this idea might be not practicable. Daniel could life with the change from ASSIGNED PI to ASSIGNED PA but agreed with Larisa and Andre that there is actually no issue to be fixed. Randy supported the aim of correct registration but also stated his concerns about the routing table and that some PI holders might not be happy to pay a fee for the sponsoring LIR. Carlos also stated his concerns for the routing table. Conclusion: Five people supported the proposed approach, four people saw some advantages but also were concerned about side effects, while two people didn’t see the need to take action. There were three opposing arguments: - big workload compared to the gain - increase of the routing table - PI holders might not like to pay a fee for the sponsorship The first opposing argument can be considered as addressed as three PI users confirmed that a clarification of that issue would be very important to them. And the RIPE NCC can support the LIRs, for example making bulk updates on route and domain objects. The second opposing argument, could be considered that this is not directly related to the fixing of the registration. Already now all but one of the allocations in question contain more specific route advertisements. Also in the extem case that all ASSIGNED PI within the allocations would be carved out, we would talk few thousand new entries in regards to 628K total routing entries (normal growth of the routing table is around 2K per week). The third opposing argument was addressed by Gert, stating that PI holders appreciate to pay a small fee to be sure that their resources are correctly registered. Based on all of this I feel we have a strong enough mandate for the RIPE NCC to move forward, but some concerns about the amount of work involved. I therefore would like to ask the RIPE NCC on behalf of this working group to move forward with their plan, but to extend the proposed deadline of the end of January 2017 by a few months (the end of Q1 2017) to give LIRs a little bit more time if needed. Cheers, Sander APWG co-chair

6 6

RIPE 2016-03 (Locking Down the Final /8 Policy) abandoned, not yet withdrawn
by Sander Steffann 26 Oct '16

26 Oct '16

Hello working group, Remco van Mook, the author of 2016-03, has decided to abandon the 2016-03 policy proposal. The reasons he has given are: - Not because of a lack of consensus - that’s for the chairs to decide - Out of embarrassment for the “discussion” and how it is damaging our community’s reputation - If anyone else wants to pick up from here, be my guest, but I think we need to discuss the process for that first. If there is anybody who wants to take over as the author of this policy proposal then please contact the working group chairs at apwg-chairs(a)ripe.net in the next two weeks. The deadline for authors to step forward is Friday the 11th of November. If nobody has offered to take over at that point the chairs will declare the proposal withdrawn. Cheers, Gert & Sander Your friendly neighbourhood working group chairs

1 0

2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)
by Marco Schmidt 26 Oct '16

26 Oct '16

Dear colleagues, The draft documents for version 3.0 of the policy proposal 2016-03, "Locking Down the Final /8 Policy" have now been published, along with an impact analysis conducted by the RIPE NCC. The goal of this proposal is to ban transfers of allocations made under the final /8 policy. Also the proposal specifies what resources must be added to the RIPE NCC IPv4 available pool. Some of the differences from version 2.0 include: - Clarification that changes to holdership of address space as a result of company mergers or acquisitions are not affected by proposed transfer restriction - Legacy space handed over to the RIPE NCC will be added to the IPv4 available pool You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2016-03 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2016-03/draft We want to draw your attention to two changes, which we hope it will make your proposal evaluation easier. - Policy proposals now contain a diff tool that allows easy comparison of different proposal versions – simply click on the “View Changes” symbol right beside the list of proposal versions. - The RIPE NCC impact analysis only mentions areas where the proposal is actually expected to have an impact. For example, if the analysis makes no comment about financial or legal impact, it means that no such impact is expected. We encourage you to read the draft document and send any comments to <address-policy-wg(a)ripe.net> before 17 November 2016. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

41 91

Re: [address-policy-wg] 2015-04 New Version and Impact Analysis Published (RIPE Resource Transfer Policies)
by Ciprian Nica 24 Oct '16

24 Oct '16

Hi, I've sent this only to Marco instead of replying to the list. Please see my comments below. Ciprian On Monday, October 17, 2016, Ciprian Nica <office(a)ip-broker.uk> wrote: > Hi, > > I think it would be useful to list on the statistics also the broker that > facilitated the transfer. That might be of interest to the community and I > think the NCC should revise the transfer agreement template in order to be > able to mention the broker and also to publish it's name on the transfer > statistics page. Also the broker should be allowed to communicate with RIPE > and pass information on behalf of the customers during the transfer process. > > There is also a cosmetic thing that I don't know if it needs be mentioned > in policy in order to be implemented. The netname of the allocation keeps > the original allocation date in it's name which can be confusing although > there's the new "created" attribute. > > For example, the subnet 128.0.52.0/24 was transferred on 14/10/2016 and > it was part of an allocation with netname EU-JM-20120914. The new > allocation has netname ES-SISTEC-20120914. > > If the date is no longer relevant in a netname then I think it should be > simply ES-SISTEC, otherwise it can be ES-SISTEC-20161014 > > Ciprian > > > On Tue, Sep 27, 2016 at 4:08 PM, Marco Schmidt <mschmidt(a)ripe.net > <javascript:_e(%7B%7D,'cvml','mschmidt(a)ripe.net');>> wrote: > >> Dear colleagues, >> >> The draft documents for version 4.0 of the policy proposal 2015-04, "RIPE >> Resource Transfer Policies" have now been published, along with an impact >> analysis conducted by the RIPE NCC. >> >> The goal of this proposal is to create a single document with all >> relevant information regarding the transfer of Internet number resources. >> >> Some of the differences from version 3.0 include: >> >> - Adding a reference in all related allocation and assignment policies to >> the new transfer policy document >> - Clarification in the policy text and policy summary regarding transfers >> due to a change in the organisation’s business (such as a merger or >> acquisition) >> >> You can find the full proposal and the impact analysis at: >> https://www.ripe.net/participate/policies/proposals/2015-04 >> >> And the draft documents at: >> https://www.ripe.net/participate/policies/proposals/2015-04/draft >> >> We encourage you to read the draft document and send any comments to < >> address-policy-wg(a)ripe.net >> <javascript:_e(%7B%7D,'cvml','address-policy-wg(a)ripe.net');>> before 26 >> October 2016. >> >> Regards >> >> Marco Schmidt >> Policy Development Officer >> RIPE NCC >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> >> >

6 19