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

Help Re: address-policy-wg Digest, Vol 48, Issue 17
by 8lb. 7zin 19 Aug '15

19 Aug '15

‏في الثلاثاء، ١٨ أغسطس، ٢٠١٥, <address-policy-wg-request(a)ripe.net> كتب: > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net <javascript:;> > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net <javascript:;> > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net <javascript:;> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: 2015-04 New Policy Proposal (RIPE Resource Transfer > Policies) (Jan Ingvoldstad) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 17 Aug 2015 18:26:30 +0200 > From: Jan Ingvoldstad <frettled(a)gmail.com <javascript:;>> > To: Address Policy Working Group <address-policy-wg(a)ripe.net > <javascript:;>> > Subject: Re: [address-policy-wg] 2015-04 New Policy Proposal (RIPE > Resource Transfer Policies) > Message-ID: > < > CAEffzkzzpKA1aqUtUzESDJpLggLbOUdfMhaETmStDcRddPmUjg(a)mail.gmail.com > <javascript:;>> > Content-Type: text/plain; charset="utf-8" > > On Fri, Aug 14, 2015 at 12:17 PM, James Blessing < > james.blessing(a)despres.co.uk <javascript:;>> wrote: > > > On 14 August 2015 at 10:54, Marco Schmidt <mschmidt(a)ripe.net > <javascript:;>> wrote: > > > > > https://www.ripe.net/participate/policies/proposals/2015-04 > > > > Thanks for putting in the time and effort, Erik! > > Couple of questions/comments... > > > > From 1.0 > > > > Shouldn't the scope be explicit as to what is/isn't included > > > > I agree that this would help. > > >From 2.1 > > > > "Transfers can be on a permanent or non-permanent basis." > > > > How is this going to be recorded and managed within the context of > > reflecting it being a non-permanent transfer? > > > > Wouldn't that be up to the RIPE NCC? > > >From 2.2 > > > > "assigned by the RIPE NCC on a restricted basis (such as IPv4 or 16-bit > > ASNs)" > > > > Rather than "such as" this needs to be a definitive list of what is > > classed as a restricted resource > > > > I concur, but I don't think it should be listed in the same document. > > My first thought is that this list should be maintained by the RIPE NCC. > > Keeping that list in a separate document means changing fewer documents > when policy changes, or reality reaches a pre-set limit set in policy. > > That separate list should reference the policy documents enabling the > restrictions. > > >From 3.1 > > > > Again a list of conditions or references to policies that impose > > restrictions needed > > > > I'm a bit confused both by the point and by your response to it, maybe I'm > just tired, but I think both could be clearer. :) > > >From 4.0 > > > > M&A process is mentioned, should there be other references to this? > > Especially as M&A (as I understand it) allows 2.2 to be overridden > > > > "The document proposes to include the transfer restrictions to mergers and > acquisitions. This is done to make the policy more in line with the > intention of the transfer policy restrictions when proposed." > > General > > > > - As this is about transfers should this also cover returning > > resources to ripe NCC so all types of transfers be included > > > > I'm not sure that this would be useful, but 2015-04 could 1) include a > reference to the policy for that, and 2) make it even clearer that this is > a document for transfers between resource holders. > > I don't think it's useful to consider the RIR a resource holder in this > context. > > - broadly support the unification of transfer policy into a single > > document, just things bits are missing or muddy > > > > Agreed, but the document is largely clarifying more than muddying, IMHO. > -- > Jan >

1 0

Fwd: 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by ripe＠europeiptv.net 16 Aug '15

16 Aug '15

Hello, The allocations made before the date of this announcement, should be governed by the old politics. is not serious things apply retroactively. On exhaustion, RIPE Why is not like other RIRs? Because RIPE accepts LIRs outside the region? without having a registered company and physical address in the RIPE Region? Other ARIN RIR as it met. Regards. David

8 12

Fwd: Suggestions on a new asn assignment policy
by Nick Hilliard 14 Aug '15

14 Aug '15

AP-WG, I've included below an email which was sent to the authors of 2014-03 as a followup to this email (dated Sat May 16 01:40:13 CEST 2015): > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-May/009982.h… Saku, Job and I discussed these ideas but the discussions didn't come to anything. The suggestions below don't fix everything with ASN assignment because 100% solutions don't work. However they provide a practical and workable mechanism which trivially deals with the vast majority of cases, and provides a known working mechanism for creating a run-out pool for ASN16, all based on policy principals which are either in place for other resources, or else which have been tried and tested in practice. I'm planning to write this up as a formal policy proposal in the next short while, as an alternative to 2014-03. If anyone has suggestions or tweaks, please feel free to bring them up. Nick -------- Forwarded Message -------- Subject: Suggestions on a new asn assignment policy Date: Sat, 16 May 2015 00:43:18 +0100 From: Nick Hilliard <nick(a)foobar.org> To: Job Snijders <job(a)instituut.net>, Saku Ytti <saku(a)ytti.fi> CC: AP WG Chairs <apwg-chairs(a)ripe.net> Saku, Job, WG Chairs, re: my email to ap-wg of a couple of moment ago, here are some ideas I've been mulling over: - if an end user wants a single ASN32 and they don't already have one, they should get it on the basis of entitlement. - if an end user wants more than one ASN32, they should get it on the basis of a needs-based policy. - if an end user wants one or more ASN16s, they should get it on the basis of an needs-based policy, unless the remaining pool of ASN16s has reached a certain threshold - regardless of the requirement, end users may only receive one ASN16 from the remaining pool, and this should be assigned on the basis of a needs-based policy. The needs criteria can be collated by both operator input and by taking a look at historical assignment reasons: the ripe ncc have 25 years of experience in assigning ASNs and have a large database of reasons that end-users have put forward on their application forms. But we already have a pretty good idea of what this list should include. Basing a new policy along the lines of these principals will provide the following: - no requirement for charging - trivially deals with the most common case, namely assignment of a single asn32 - a runout policy for asn16s which both has well-understood limitations and will probably be palatable to the ripe community, as it's proposed on a similar basis to the last /8 + will be subject to 24m rule. - no practical way of asn32 resource exhaustion because each application will be individually evaluated by an IPRA (either on the basis of 2007-01 for end-user authentication or else on the basis of needs evaluation once that authentication has been completed). - continuation of existing ASN16 policy until a hard limit is hit, after which a run-out policy will apply - conceptually very similar to ipv4 / ipv6 policy. - hopefully an end to lies on asn application forms for asn32s I don't know what you guys feel about these suggestions, but I think they could be used to create something a good deal better than what we have right now. If you want to use these suggestions to form 2014-03 v3.0, you are welcome to do so, but I would ask you kindly to acknowledge my input as appropriate. Alternatively, if either or both of you have got tired of 2014-03, I would be happy to take up the baton and run with something along the lines of the above. Nick

5 12

Promote the use of IRC
by Daniel Baeza (Red y Sistemas TVT) 13 Aug '15

13 Aug '15

Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #address-policy channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel

19 25

2015-02 Proposal Accepted and Implemented (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 10 Aug '15

10 Aug '15

Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-641, "IPv6 Address Allocation and Assignment Policy", has been accepted by the RIPE community. This policy change removes the requirement that LIRs return their IPv6 Provider Independent (PI) assignment when requesting an IPv6 allocation if there are no specific routing requirements to justify both. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 The new RIPE Document is called ripe-650 and is available at: https://www.ripe.net/publications/docs/ripe-650 This proposal is implemented with immediate effect. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2015-02 Last Call for Comments (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 06 Aug '15

06 Aug '15

Dear colleagues, The proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation", 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 6 August 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. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-02 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 6 August 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

2 1

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Silvia Hagen 28 Jul '15

28 Jul '15

Hi to all +1 I fully support this proposal. I believe it is an important step to allow for useful deployment of IPv6 taking advantage of the advanced and extended IPv6 address architecture. Responding to the request for feedback on the "RIPE understanding" section here are some thoughts and comments: - The overall tone of the "understanding" section still sounds more like "our main goal is to preserve addresses" instead of "let's make generous use oft he extended address architecture and available space" to me. It is not easy to step out of IPv4 thinking. While we all know in our minds that we need to do this, implementing it is much more difficult. (I am for instance referring to this sentence, which appears more than once: " The RIPE NCC will ask for additional documentation to justify why a less address consuming hierarchy or topology can not be implemented."). There is a widely adopted rule that all address conservation mechanisms should be removed from IPv6 address plans. - There is one point where I have a problem to understand, maybe I am misinterpreting the statement. It says " The RIPE NCC will consider longevity reasonable for a similar timeframe for which past growth was documented." - So my question is: how does this accomodate startups? We are moving into the age of the Internet of Things. We expect new technologies and services to spring up, not foreseeable. This includes new business models and opportunities for new companies that have no history. - The policy for subsequent allocations will have to be updated accordingly if this policy is accepted. - Quote: "If this network topology is justified, the RIPE NCC will consider up to one extra bit per hierarchical level or geographical segment as reasonable, on top of the documented need for that part of the network." Comment: how about "generally up to one bit" - leave room for exceptions. - The rules seem quite complicated and a bit hard to really understand and correctly apply to me. I wonder how easy it will be to assess requests based on this. As mentioned already, I believe this proposal is a good step. When it comes to how to apply it, I feel there is a lot of "strictness" in the wording. It is always nice to have clear and strict rules, everyone can easily apply them. But reality is different. There is no good rule without exceptions and I hope that this policy will be applied with common sense and adjusted to reality. And my personal viewpoint is, that we should not restrict IPv6 address plans from the beginning. Our main target should be to finally DEPLOY it as broadly as possible and have ease of operation as a main goal. That is what the address architecture provides. By today we have given out the equivalent of 171'000 /32 of the currently defined global unicast space (2000::/3) (according to Bgpexpert<http://www.bgpexpert.com/addrspace-ipv6.php>) and this equals 0.032%. Hey that is 171'000 times more than the whole current Internet and we are at 0.032%! I think we should apply a generous allocation model that makes it easy to deploy, operate, secure..... ...and if we get to the point where we feel we have been too generous, we can still adjust policies and become more careful. Once we have used 2000::/3 we still have 7 more chances to do better. We could even define a re-assessment once we are 30% or 50% into the 2000::/3. My two cents, greetings from the summer heat Silvia Hagen Chair Swiss IPv6 Council -----Ursprüngliche Nachricht----- Von: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 9. Juli 2015 14:20 An: policy-announce(a)ripe.net<mailto:policy-announce@ripe.net> Cc: address-policy-wg(a)ripe.net<mailto:address-policy-wg@ripe.net> Betreff: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) 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<mailto:address-policy-wg@ripe.net> before 7 August 2015. Regards Marco Schmidt Policy Development Officer RIPE NCC Sunny Connection AG CH-8124 Maur +41 (0)44 887 62 10 www.sunny.ch<http://www.sunny.ch/> http://twitter.com/sunny_shagen ****************************************** IPv6 Business Conference, June 18, 2015, Zurich<http://www.ipv6conference.ch/> International Top Speakers, Unique Program Great Networking - watch out for the 2016 Conference ****************************************** Switzerland is in the Top 5 in IPv6 User Adoption We reached 21% in June 2015! *********************************** Our website is dual-stack - how about yours? ***********************************

5 9

Re: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by poty＠iiat.ru 27 Jul '15

27 Jul '15

Hello, I do not see any wrong cases here. When my company obtained our address block in 1998 there was one set of policies, since then the policies have been evolved a lot. Nobody asks you to return your address space or changes its USAGE rules, it's only transfer delays, not more, not less. Regards, Vladislav Potapov ________________________________ От: ripe(a)europeiptv.net<mailto:ripe@europeiptv.net> Отправлено: ‎25.‎07.‎2015 19:29 Кому: address-policy-wg(a)ripe.net<mailto:address-policy-wg@ripe.net> Тема: [address-policy-wg] 2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations) Hello, I do not see that the political right have retroactive effect, is not very democratic change the rules of what was received with other policies, but if I see the correct application of this policy to allocations received after this announcement, how do you see? Best Regards David IPTV EUROPE LTD.

3 3

2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by ripe＠europeiptv.net 26 Jul '15

26 Jul '15

Hello, I do not see that the political right have retroactive effect, is not very democratic change the rules of what was received with other policies, but if I see the correct application of this policy to allocations received after this announcement, how do you see? Best Regards David IPTV EUROPE LTD.

4 3

2015-01 Proposal Accepted and Implemented (Alignment of Transfer Requirements for IPv4 Allocations)
by Marco Schmidt 23 Jul '15

23 Jul '15

Dear colleagues, Consensus has been reached, and the proposal for a change to ripe-643, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. This policy change aligns the transfer requirements for all IPv4 allocations. LIRs that receive an IPv4 allocation from the RIPE NCC or via a transfer cannot subsequently transfer this allocation to another party within 24 months. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2015-01 The new RIPE Document is called ripe-649 and is available at: https://www.ripe.net/publications/docs/ripe-649 This proposal is implemented with immediate effect. Please note that: - All IPv4 allocation transfer requests received by the RIPE NCC after this announcement will be evaluated under the new policy. - The evaluation of transfer requests received before this announcement will be completed under the previous policy. This policy change particularly concerns IPv4 allocations made by the RIPE NCC. If the RIPE NCC made the allocation less than 24 months ago, the allocation cannot be transferred until the defined holding period has passed. Regards, Marco Schmidt Policy Development Officer RIPE NCC

2 1

2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size) - “subsequent allocations”
by LIR (BIT I 5) 23 Jul '15

23 Jul '15

Hi community, hi Tore, the LIR-team of de.government supports this current policy proposal “2015-03 New Draft Document”. +1 In addition we also made up our mind about the resulting inconsistency to the criteria for subsequent allocations. Therefore we plan to propose a “follow-up” proposal which tries to align the subsequent allocation criteria in case of a successful 2015-03 PDP. Kind regards, Annette Suedmeyer LIR de.government ------------------------------------- Bundesverwaltungsamt Bundesstelle für Informationstechnik (BIT) BIT I 5 Besucheradresse: Barbarastr.1 in 50735 Köln (Riehl) Servicezeiten: Montag bis Freitag 08:00 Uhr bis 16:30 Uhr Postadresse: Bundesverwaltungsamt, Barbarastraße 1, 50728 Köln Telefon: +49 22899 358 3551 E-Mail: annette.suedmeyer(a)bva.bund.de Internet: www.bundesverwaltungsamt.de<http://www.bundesverwaltungsamt.de/> www.bit.bund.de<http://www.bit.bund.de/>

2 1

Final consensus on 2015-01: Alignment of Transfer Requirements for IPv4 Allocations
by Sander Steffann 22 Jul '15

22 Jul '15

Hello working group, We have reached the end of the last-call period for 2015-01 (Alignment of Transfer Requirements for IPv4 Allocations). After analysing the messages on the mailing list that were posted about 2015-01 after the last-call was announced I have come to the conclusion that the consensus declared at the end of the review phase still stands. I therefore declare final consensus on this policy proposal and ask the RIPE NCC to turn it into active policy and implement it. My decision is based on the following: Shahin Gharghi, Petr Umelov and Yuri@Ip4market argued that this proposal doesn't solve all problems. This has already been discussed and acknowledged during the review phase. No policy proposal will ever solve everything all at once. People wanting additional changes are encouraged to submit new policy proposals to address any remaining issues. Petr Umelov was under the impression that RIPE NCC receives a fixed size IPv4 block from IANA every 6 months, which is not correct as pointed out by Leo Vegoda. Petr Umelov and Vladimir Andreev also discussed the statistics on transfers and whether the trend justifies changing policy. Arguments that RIPE NCC has enough address space and a policy change would therefore not be necessary have already been discussed in the review phase and are considered addressed. Vladimir Andreev suggested writing a summary of the discussions so I hope he reads this email. Arash Naderpour argued that with 2015-01 existing LIRs cannot request their last /22 and then immediately transfer it. This has been discussed before: it is one of the actual goals of this policy: to stop LIRs from requesting a /22 just to transfer it. Sincerely, Sander Steffann APWG co-chair

3 5

Policy Proposal Implemented: 2014-13, "Allow AS Number Transfers"
by Nikolas Pediaditis 22 Jul '15

22 Jul '15

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-13, "Allow AS Number Transfers”. In accordance with the new policy, any holder of Autonomous System (AS) Numbers is allowed to re-assign AS Numbers that were previously assigned to them by the RIPE NCC The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2014-13 The updated RIPE Document, "Autonomous System (AS) Number Assignment Policies", is available at: https://www.ripe.net/publications/docs/ripe-638 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services

1 0

Policy Proposal Implemented: 2014-12, "Allow IPv6 Transfers"
by Nikolas Pediaditis 22 Jul '15

22 Jul '15

Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2014-12, "Allow IPv6 Transfers". In accordance with the new policy, any holder of IPv6 address space is allowed to transfer complete or partial blocks of IPv6 address space that were previously allocated or assigned to them by the RIPE NCC. Please note that blocks being transferred must not be smaller than the minimum allocation/assignment size at the time of the transfer: - For IPv6 allocations this is currently a /32 - For IPv6 PI assignments this is currently a /48 The archived policy proposal can be found at: https://www.ripe.net/ripe/policies/proposals/2014-12 The updated RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available at: https://www.ripe.net/publications/docs/ripe-641 Kind regards, Nikolas Pediaditis RIPE NCC Registration Services

1 0

Re: [address-policy-wg] [policy-announce] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Mathew Newton 17 Jul '15

17 Jul '15

Hi Marco, > -----Original Message----- > From: policy-announce [mailto:policy-announce-bounces@ripe.net] On > Behalf Of Marco Schmidt > Sent: 09 July 2015 13:20 > 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. Thank you to you and colleagues for this. It can't have been the easiest analysis to undertake, not least given the multiple aspects to consider. It is clear however that a great deal of thought and consideration has gone into it. I need to take some time to fully consider all of the detail however my initial view of the interpretation and proposed implementation is very positive. Could I possibly seek some clarification on the following sentence from the second-to-last paragraph of Section A? 'Each assignment will be taken into account only once towards the total count of needed IPv6 space for an organisation and will not be multiplied by the times it is encapsulated in higher addressing plan levels.' Whilst I don't have a specific concern, and it may well be an insignificant statement, I thought it worthwhile double-checking what this means? Regards, Mathew

3 2

Opposing policy 2015-01
by Shahin Gharghi 12 Jul '15

12 Jul '15

Dear Garry If you read my previous messages you can find my solution. We have to discuss about accepting this proposals or not. We will talk about other solutions in other proposals. -- Shahin Gharghi

16 47

Re: [address-policy-wg] address-policy-wg Digest, Vol 47, Issue 9
by Shahin Gharghi 11 Jul '15

11 Jul '15

Hi > I would be happy to support returning this proposal to the discussion phase, but only if there are compelling reasons to do so. To date nobody has made the case for taking that action. Although some have asked for this, nobody has put forward anything to justify these requests. The case has not been made yet. It?s up to you and your fellow travellers to make that case. > The problem is: The person who should justify the criticisms, never does! And he is supporting the proposal so that he will never return it to the discussion phase... -- Shahin Gharghi

3 3

2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)
by Shahin Gharghi 11 Jul '15

11 Jul '15

Hi +1 to 2015-03 proposal. -- Shahin Gharghi

1 0

PA policy
by Kennedy, James 08 Jul '15

08 Jul '15

Hello, At the risk of sounding naïve, I have a question regarding the legitimate usage of PA address space. That is, what *type* of network or End User can it be assigned to. "LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to *downstream networks*." https://www.ripe.net/publications/docs/ripe-643#7 To me this reads networks or End Users assigned PA space must receive transit from the LIR holding the parent allocation. Or can the LIR assign PA blocks to customers/companies that don't receive transit, or any other technical network service for that matter, from the LIR? Regards, James

8 17

2015-02 Draft Document and Impact Analysis Published (Keep IPv6 PI When Requesting IPv6 Allocation)
by Marco Schmidt 07 Jul '15

07 Jul '15

Dear colleagues, The draft document for the proposal described in 2015-02, "Keep IPv6 PI When Requesting IPv6 Allocation" has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-02 and the draft document at: https://www.ripe.net/participate/policies/proposals/2015-02/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 7 July 2015. Regards, Marco Schmidt Policy Development Officer RIPE NCC

22 21

"ALLOCATED UNSPECIFIED"
by Enno Rey 02 Jul '15

02 Jul '15

Hi, some of you might already cringe just from this mail's subject ;-) I'm currently involved in handling some netblocks which are in "ALLOCATED UNSPECIFIED" state and this turns out to be surprisingly difficult, even in cases where both organizations (that is the LIR holding the covering aggregate and the organization which received the "more specific" PI assignment back in the 90s) apparently agree on a course of action. My impression is that these difficulties not least arise as seemingly no policy exists on "how to convert those assignments into 'ASSIGNED PI' or 'ALLOCATED PA' space". I'm aware that these netblocks might only be "remnant corner cases" totally irrelevant to the majority of the community. Which brings me to the following questions: a) do any of you "feel the same pain" when it comes to these blocks? b) do you think a policy proposal should be prepared how to handle those? I'm willing to prepare sth. c) what could such a proposal look like? What do those concerned think how a reasonable way of moving those blocks into a "stable state" can be identified/described. many thanks in advance for any type of feedback. everybody have a pleasant evening Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator =======================================================

2 1

ARIN reaches depletion
by Nick Hilliard 01 Jul '15

01 Jul '15

https://www.arin.net/announcements/2015/20150701.html Nick

1 0

Opposing policy 2015-01
by Arash Naderpour 01 Jul '15

01 Jul '15

Hi, I oppose policy 2015-01 because it can affect LIRs which are not new but they recently have received their /22 from last /8. (For example an LIR which is registered in 2010 and just received its /22) the LIR is not established to just receive the /22 but it has to wait for 2 years to be able to transfer it and I don't see any reason for this limitation. As a side effect it makes it harder for IP distribution which is the main goal of RIPE. Regards, Arash Naderpour

6 6

We need IPv4 transfers
by Shahin Gharghi 01 Jul '15

01 Jul '15

Hi > You are just adding noise to the list. The messages show you are making noise. If you have any idea we can hear that. And I think you'd better play fair. You are using your power as a chair to get this proposal accepted. I asked a question and if you have an answer for that, tell me. People will be able to transfer their /22 after accepting this proposal. So this proposal won't help at all. What's your answer as a person who supports this proposal and of course as the chair? -- Shahin Gharghi

2 1

We need IPv4 transfers
by Shahin Gharghi 01 Jul '15

01 Jul '15

Dear Gert This question is for you and all of the members too. There is nothing private. -- Shahin Gharghi

2 1