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

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by sandrabrown＠ipv4marketgroup.com 17 Sep '14

17 Sep '14

---------------------------------------------------------------------- Date: Wed, 17 Sep 2014 11:56:23 +1000 From: Elvis Velea <elvis(a)velea.eu> Subject: Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) To: address-policy-wg(a)ripe.net Message-ID: <5418EA47.8080307(a)velea.eu> Content-Type: text/plain; charset="utf-8" Hi Sandra, I see that the status of this proposal on the RIPE website is "Awaiting Decision from Proposer". The status has not changed since 02 July 2014 :) Do you have any updates on this policy proposal? @WG-chairs - is this proposal frozen now, waiting the result of 2014-02 or will it move to the next PDP step anytime soon? Kind regards, Elvis ----- Hi Elvis - RIPE NCC is conducting impact analysis at this time. Once this is complete, review phase will start. Best Sandra ------

2 1

2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by sandrabrown＠ipv4marketgroup.com 17 Sep '14

17 Sep '14

Tore, Thanks for your feedback. See below for comments. From: Tore Anderson <tore(a)fud.no> Subject: Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) To: address-policy-wg(a)ripe.net Message-ID: <53A7ECB6.60108(a)fud.no> Content-Type: text/plain; charset=ISO-8859-1 I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of ?LIR? should be avoided. However, I'd also like to add that suggested replacement ?organisation? could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as ?resource holder?/?resource holder to be? or ?entity?. **** I think this is a very good point, thanks. Sandra 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: ?When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.? These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, ?fulfill? is incorrectly spelled.) *** Thanks for pointing out this redundancy issue. *** Let me look into it with Marco and the Chairs, as to whether we *** would add the text or were making a statement of fact. *** Agree on spelling of fulfill. Thanks. Sandra 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: ?If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.? This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) *** I am not sure we will add that statement to the policy or if it is *** just a statement of fact: that legacy policy will apply, as you say. *** Let me check with Marco, as what you say makes total sense to *** me. Sandra So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. *** Yes the intention is not to add bloat but perhaps to re-confirm what *** is already there. Thanks a ton for your feedback, and of course for *** your support for the intent. *** Sandra Tore End of address-policy-wg Digest, Vol 34, Issue 15 *************************************************

3 2

2014-02 Last Call for Comments (Allow IPv4 PI transfer)
by Marco Schmidt 26 Aug '14

26 Aug '14

Dear colleagues, The proposal described in 2014-02, "Allow IPv4 PI transfer", 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 24 September 2014 and must be supported by an explanation. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-02 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 24 September 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
by Gert Doering 25 Aug '14

25 Aug '14

Dear Address Policy WG, another one, and then it's enough for today... On Fri, Jul 11, 2014 at 10:21:11AM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2014-03, > "Remove Multihoming Requirement for AS Number Assignments" has been > published. The impact analysis that was conducted for this proposal > has also been published. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 11 August 2014. the review phase is over. Based on the comments received, the authors have decided to work on the text and a "version 2.0" of the document will come forward soon -> new impact analysis and a new round of discussion phase. Stay tuned :-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

Re: [address-policy-wg] 2014-03 two cents on multi homing ASN requirement
by Aleksi Suhonen 19 Aug '14

19 Aug '14

Hello, On 07/11/2014 11:21 AM, Marco Schmidt wrote: > The draft document for the proposal described in 2014-03, > "Remove Multihoming Requirement for AS Number Assignments" has been > published. The impact analysis that was conducted for this proposal > has also been published. I know I'm late in the game, but I thought I'd contribute this view rather than stay silent: Remove multi homing requirement for 32bit ASNs only, keep the requirement for 16bit ASNs. I foresee new weird legacy setups run by non-ISPs that still require a unique ASN well into the future. The example I would usually use is factory floor environments, but that is probably not an applicable example here. I hope someone else's imagination can supply a valid example. Cheers, -- Aleksi Suhonen You say "potato", I say "closest-exit."

12 24

[Ticket#2014081101013263] Transfer from last /8
by LeaderTelecom Ltd. 12 Aug '14

12 Aug '14

Dear Sirs, I suggest to allow transfer from the last /8 only in 2 years after date of allocation from RIPE NCC. I see in the transfer list that this is already common practice to transfer /22 from the last /8. Any Pros/cons? -- Aleksei Ivanov LeaderTelecom -- При ответе сохраняйте [Ticket#-] в теме письма. --- С уважением, Алексей Иванов Генеральный директор ООО "ЛидерТелеком" Тел.: 8(495)778-98-51 [1]www.LeaderTelecom.ru URL: [2]http://www.InstantSSL.su/ - SSL-сертификаты Comodo URL: [3]http://Symantec.Leadertelecom.ru/ - SSL-сертификаты Symantec (Verisign) URL: [4]http://www.Thawte.su/ - SSL-сертификаты Thawte URL: [5]http://www.HostingConsult.ru/ - Лицензии связи, IP-адреса и AS [1] http://www.leadertelecom.ru [2] http://www.instantssl.su/ [3] http://symantec.leadertelecom.ru [4] http://www.thawte.su/ [5] http://www.hostingconsult.ru/

5 11

Re: [address-policy-wg] 2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer)
by Gert Doering 09 Aug '14

09 Aug '14

Dear AP WG, On Thu, Jul 10, 2014 at 11:58:51AM +0200, Marco Schmidt wrote: > The draft document for the proposal described in 2014-02, > "Allow IPv4 PI transfer" 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/ripe/policies/proposals/2014-02 > > and the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-02/draft We could use a bit more input on this proposal. We have one clear statement of support, and one mail that puts up some questions while not taking a clear pro/con position - and that is not enough to declare anything except "needs more time" at the end of review phase. So, tell me your thoughts, please. thanks, Gert Doering, APWG chair Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

15 26

Policy Proposal Implemented: 2014-01, "Abandoning the Minimum Allocation Size for IPv4"
by Saloumeh Ghasemi 07 Aug '14

07 Aug '14

Dear colleagues, We are pleased to announce that the accepted RIPE Policy Proposal 2014-01, "Abandoning the Minimum Allocation Size for IPv4", has now been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2014-01 The new RIPE Document, ripe-622, "IPv4 Address Allocation and Assignment Policy", is available at: https://www.ripe.net/ripe/docs/ripe-622/ Please note that we republished the RIPE Document, "IPv4 Address Allocation and Assignment Policy", because it was originally published with a small error. The new, correct document is ripe-622, which deprecates ripe-621. As per section 5.5 of this new RIPE Document, Local Internet Registries (LIRs) are now allowed to transfer allocated Provider Aggregatable (PA) address space to other LIRs, regardless of the size of the allocations: https://www.ripe.net/ripe/docs/ripe-622#55 The RIPE NCC will continue to issue /22 allocations, as per section 5.1: https://www.ripe.net/ripe/docs/ripe-622#51 If you have any questions, please contact <ncc(a)ripe.net <mailto:ncc@ripe.net>>. Regards, Saloumeh Ghasemi Registration Services RIPE NCC

1 0

Re: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Sebastian Wiesinger 07 Aug '14

07 Aug '14

* Marco Schmidt <mschmidt(a)ripe.net> [2014-07-31 13:42]: > > Dear colleagues, > > The draft document for version 2.0 of the policy proposal 2014-04, > "Relaxing IPv6 Requirement for Receiving Space from the Final /8", > has now been published, along with an impact analysis conducted by > the RIPE NCC. I support this draft! Make it so. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant

1 0

Re: [address-policy-wg] [ncc-services-wg] Crimea papers
by Axel Pawlik 06 Aug '14

06 Aug '14

On 28/07/2014 15:54, Max Tulyev wrote: > Hello All, > > Do RIPE NCC accept legal papers (i.e. company registration papers) > issued by Russian occupation authorities in Crimea? If yes - why? Max, all, the foremost concern of the RIPE NCC as a neutral membership organisation is to ensure accurate registration of Internet number resources. To do this, we rely on the information and documentation provided by our members. This documentation must come from a national authority and prove that the member exists as a legal entity. Russia and Ukraine both have national authorities that can confirm the existence of legal entities, so the RIPE NCC will accept documentation from whichever national authority the member chooses. cheers, Axel

22 42