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

RIPE 68 Address Policy WG Draft Minutes
by Marco Schmidt 17 Oct '14

17 Oct '14

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

1 0

Re: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais)
by sandrabrown＠ipv4marketgroup.com 16 Oct '14

16 Oct '14

>>Hi, >>Thank you for the analyses. >>>> You can find the full proposal and the impact analysis at: >>>> https://www.ripe.net/ripe/policies/proposals/2014-05 >>I see some issues that aren't consistent in the wording of the policy, especially in terms of Legacy and PI space holders (non-members) and: >> Address space may only be re-allocated to another resource holder who is a >>member of an RIR that allows transfers. >>Both PI space holders and Legacy holders are not always members of an RIR. >>I'm speaking with my RIPE region community member experience here. So it >>could be that in for instance ARIN or APNIC all resource holders are members >>of the RIR, but here in the RIPE region that isn't (always) the case. > When Internet number resources are transferred from another RIR, the RIPE >>NCC will work with the resource holder to fulfil any requirements of the >>sending RIR. >>Suggested wording: >>When Internet number resources are transferred from another RIR to the RIPE >>Region, the RIPE NCC will work with the receiving party and the resource >>holder and the sending RIR to confirm the qualification requirements in >>order to complete transfer. As Tore noted, the PI transfer section 6.4 was added recently, and since the Impact Analysis makes it clear that PI transfers will be permitted, this doesn't justify a version 3.0 of the inter-RIR transfer policy, in my mind. However, your comments are correct, and duly noted. >>It is more specific to the intend, however as the RIPE NCC is put in a >>position to check if the receiving party qualifies following a needs >>assessment according to the policy of another RIR, the RIPE NCC needs to be >>in contact with the receiving party, the resource holder and the sending >>RIR. >>On the part of arbitration, the policy as it is described in the Summary of >>the Proposal is a nightmare I think.. >>The Summary of the proposal states : >>> If another RIR has a different policy, the RIPE NCC should create an >>operational procedure that satisfies the requirements of both RIRs in order >>to allow transfers to and from its service region >>I understand the intend of what it stated, but I don't think that the NCC >>should be put in a position where Axel would come opposite from the board of >>ARIN or APNIC and have them sort out the procedure, without a proper >>arbitration procedure in place outside the RIR's ... >>What if a transfer isn't going as planned and it does pass the arbitration >>in the RIPE region ... the sending RIR doesn't agree with the arbitration >>out-come ... And what is next ? Will the NCC take the other RIR to court ? >>Or is there an arbitration process for RIR's ? >>Personally I think that the policy should state that the party in the RIPE >>Region should deal with the arbitration in the RIPE region and that the >>sending or receiving party in the other RIR should convert to the >>arbitration in their respective RIR. Or agree by agreement which of the 2 >>RIR's their arbitration will be used (and with that choice to apply their >>policy) if we keep the policy as it is currently on the table.. >>If the intent of the policy, as it is currently, is that the RIPE NCC should >>adhere to the policy of the more strict assignment policy of the other RIR, >>state in the policy specifically that the other RIR needs to do the need >>justification checking with the receiving party and approve the transfer >>prior to submitting the transfer for processing to the RIPE NCC. >>They have the best knowledge of the policy in that specific RIR and if they >>don't agree with the justification or qualification of the receiving party, >>their arbitration can also be used, without getting the RIPE NCC in a >>squeeze between a rock and a hard place or putting a requirement in place >>for the RIPE NCC staff that they should get intimately familiar with other >>RIR their addressing policy. >>If the other RIR approves the transfer based on their current policy at that >>time (as if it is an intra-rir transfer ) it can be submitted to the RIPE >>NCC for administrative processing, as the RIPE NCC has a more liberal >>addressing policy towards transfers than any other RIR. The model proposed in the policy is intended to mimic the existing policy between APNIC and ARIN whereby the arbitration topic is not needed. When two RIR's have like needs assessment, this topic goes away. As noted, however, in the Impact Assessment, ARIN staff does not see the policy to be compatible with theirs. I am surprised that they say that explicit needs justification is not stated, and must be. The policy states that the requirements of the sending RIR will be met. If the requirement of the sending RIR is needs justification, then needs justification will be performed. But as Tore, says, it opens the door, and in my mind, the door is opened for a next step. Interestingly, ARIN34 seemed to be pushing for removal of needs justification on blocks sized /16 and smaller. >>I hope that I've made my point on the topic and with that also suggested a >>way forward. >>I really don't like a policy that has too many open ends or topics that we >>haven't addressed enough and already know up-front that the other RIR's >>don't agree with. This is the nature of negotiation in the global community. Sandra >>Regards, >>Erik Bais

3 2

Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources)
by Tore Anderson 15 Oct '14

15 Oct '14

* Marco Schmidt > The draft document for version 2.0 of the policy proposal 2014-05, > "Policy for Inter-RIR Transfers of Internet Resources" has now been > published, along with an impact analysis conducted by the RIPE NCC. Supported. I think it's fairly obvious that some resource holders will engage in inter-regional transfers, and for the sake of registry accuracy we should ensure that our policies do not stand in the way of this. I have no objections to Nick's proposed amendments. I'd like to point out that the proposal does not modify ripe-623 section 6.4 (PI transfers) in the same way it does 5.3 (PA transfers). This is understandable, as 6.4 was very recently added, but it does contain language that could conceivably be interpreted as a barrier to inter-regional transfers, e.g., «any holder of Provider Independent (PI) address space is allowed to re-assign complete or partial blocks of IPv4 address space that were previously assigned to them *by the RIPE NCC*» (emphasis mine). That said, the Impact Analysis makes it clear that PI transfers will be permitted, so this doesn't alone justify a version 3.0 of the proposal. I note that the ARIN staff does not consider the policy to be sufficiently compatible with theirs. That comes as no surprise to me, but at least 2014-05 opens the door for the ARIN community to adjust their policy in a way that would allow inter-regional transfers between our regions, while at the same time allowing them to insist on need evaluation being performed. We'll just have to wait and see whether they accept our invitation or not; at least we're trying to be flexible and accommodating here, we can't do much more than that. That the APNIC staff are unsure whether or not their policy would be compatible (due to different need evaluation requirements) surprises me greatly. From http://www.apnic.net/policy/transfer-policy#rir-transfer: > 4.3 Conditions on the recipient of the transfer > > The conditions on the recipient of the transfer will be defined by > the RIR where the recipient organization holds an account. This means: > > * For transfers to an APNIC recipient, the conditions defined in > Section 3.3 will apply. > * Where the recipient is in another region, the conditions on the > recipient as defined in the counterpart RIR's transfer policy at > the time of the transfer will apply. Section 3.3 is where the need evaluation requirement is. It therefore seems quite clear that for a transfer from the RIPE region to the APNIC region, the receiver would be required to undergo a need evaluation per section 3.3. This does not seem to be in conflict with 2014-05, rather quite the opposite due to the statement that «the RIPE NCC will also comply with the commitments imposed by the receiving RIR, in order to facilitate the transfer». For transfers from the APNIC region to the RIPE region, APNIC's section 3.3 (and thereby any APNIC need evaluation requirement) is not invoked; rather, the «counterpart RIR's transfer policy» is. In other words, 2014-05 + ripe-623 sections 5.5 and 6.4. Since the APNIC policy explicitly delegates all conditions on the RIPE region recipient to RIPE region policies, I cannot see any potential conflict for transfers in the APNIC->RIPE direction either. I'm perplexed that the APNIC staff is uncertain whether or not 2014-05 is compatible with their policy. The way I read them, they unequivocally are. Perhaps there are some APNIC folks lurking here who could elaborate? Tore

3 4

Re: [address-policy-wg] [policy-announce] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources)
by Erik Bais 14 Oct '14

14 Oct '14

Hi, Thank you for the analyses. > You can find the full proposal and the impact analysis at: > https://www.ripe.net/ripe/policies/proposals/2014-05 I see some issues that aren't consistent in the wording of the policy, especially in terms of Legacy and PI space holders (non-members) and: > Address space may only be re-allocated to another resource holder who is a member of an RIR that allows transfers. Both PI space holders and Legacy holders are not always members of an RIR. I'm speaking with my RIPE region community member experience here. So it could be that in for instance ARIN or APNIC all resource holders are members of the RIR, but here in the RIPE region that isn't (always) the case. > When Internet number resources are transferred from another RIR, the RIPE NCC will work with the resource holder to fulfil any requirements of the sending RIR. Suggested wording: When Internet number resources are transferred from another RIR to the RIPE Region, the RIPE NCC will work with the receiving party and the resource holder and the sending RIR to confirm the qualification requirements in order to complete transfer. It is more specific to the intend, however as the RIPE NCC is put in a position to check if the receiving party qualifies following a needs assessment according to the policy of another RIR, the RIPE NCC needs to be in contact with the receiving party, the resource holder and the sending RIR. On the part of arbitration, the policy as it is described in the Summary of the Proposal is a nightmare I think.. The Summary of the proposal states : > If another RIR has a different policy, the RIPE NCC should create an operational procedure that satisfies the requirements of both RIRs in order to allow transfers to and from its service region I understand the intend of what it stated, but I don't think that the NCC should be put in a position where Axel would come opposite from the board of ARIN or APNIC and have them sort out the procedure, without a proper arbitration procedure in place outside the RIR's ... What if a transfer isn't going as planned and it does pass the arbitration in the RIPE region ... the sending RIR doesn't agree with the arbitration out-come ... And what is next ? Will the NCC take the other RIR to court ? Or is there an arbitration process for RIR's ? Personally I think that the policy should state that the party in the RIPE Region should deal with the arbitration in the RIPE region and that the sending or receiving party in the other RIR should convert to the arbitration in their respective RIR. Or agree by agreement which of the 2 RIR's their arbitration will be used (and with that choice to apply their policy) if we keep the policy as it is currently on the table.. If the intent of the policy, as it is currently, is that the RIPE NCC should adhere to the policy of the more strict assignment policy of the other RIR, state in the policy specifically that the other RIR needs to do the need justification checking with the receiving party and approve the transfer prior to submitting the transfer for processing to the RIPE NCC. They have the best knowledge of the policy in that specific RIR and if they don't agree with the justification or qualification of the receiving party, their arbitration can also be used, without getting the RIPE NCC in a squeeze between a rock and a hard place or putting a requirement in place for the RIPE NCC staff that they should get intimately familiar with other RIR their addressing policy. If the other RIR approves the transfer based on their current policy at that time (as if it is an intra-rir transfer ) it can be submitted to the RIPE NCC for administrative processing, as the RIPE NCC has a more liberal addressing policy towards transfers than any other RIR. I hope that I've made my point on the topic and with that also suggested a way forward. I really don't like a policy that has too many open ends or topics that we haven't addressed enough and already know up-front that the other RIR's don't agree with. Regards, Erik Bais

2 1

Re: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources)
by Nick Hilliard 13 Oct '14

13 Oct '14

On 13/10/2014 14:09, Marco Schmidt wrote: > You can find the full proposal and the impact analysis at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > And the draft document at: > > https://www.ripe.net/ripe/policies/proposals/2014-05/draft The RIPE NCC analysis says: "Existing RIPE Policies will be applied to IPv4 resources." It may be a good idea to note explicitly in the policy that as long as the transfer is in effect, RIPE policy applies to the resources. This isn't explicit in the policy. Conversely, it would also be sensible to assume that resources transferred out of the region will be subject to the receiving RIR. The purpose of stating this explicitly is to ensure that it's clear to all parties that only one set of rules apply, and that once a transfer has taken place, another RIR can't come knocking at some time in the future and make a claim that maybe they had changed their minds after all. It also stops conditional or transitive policy claims, i.e. "we'll transfer to you on condition that ..." or even worse "we'll transfer to you and our conditions are binding on any future transfers". suggested text: > 2.0 Transferring Internet Resources to the RIPE NCC Service Region > > The RIPE NCC shall accept all transfers of Internet number resources to > its service region, provided they comply with the policies relating to > transfers within its service region. Internet Resources transferred to > the RIPE NCC Service Region will be subject exclusively to RIPE policy > for the duration of the transfer. > > When Internet number resources are transferred from another RIR, the > RIPE NCC will work with the resource holder to fulfil any requirements > of the sending RIR. > > 3.0 Transferring Internet Resources from the RIPE NCC Service Region > > When transferring Internet numberresources to another RIR, the RIPE > NCC will follow the transfer policies that apply within its own service > region. The RIPE NCC will also comply with the commitments imposed by > the receiving RIR, in order to facilitate the transfer. Internet > Resources transferred to another RIR will be subject exclusively to > that RIR's number resourcing policy for the duration of the transfer. Nick

1 0

2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources)
by Marco Schmidt 13 Oct '14

13 Oct '14

Dear colleagues, The draft document for version 2.0 of the policy proposal 2014-05, "Policy for Inter-RIR Transfers of Internet Resources" has now been published, along with an impact analysis conducted by the RIPE NCC. Some of the differences from version 1.0 include: - Replacing the term "LIR" with "resource holder" - Removing the reference to legacy resources from IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region - Defining special conditions for legacy resources in the inter-RIR transfer policy - Rewording the second argument opposing the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2014-05 And the draft document at: https://www.ripe.net/ripe/policies/proposals/2014-05/draft We encourage you to read the draft document text and send any comments to <address-policy-wg(a)ripe.net> before 11 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-04 Review Period extended until 20 October 2014 (Relaxing IPv6 Requirement for Receiving Space from the Final /8)
by Marco Schmidt 13 Oct '14

13 Oct '14

Dear colleagues, The Review Period for the proposal 2014-04, "Relaxing IPv6 Requirement for Receiving Space from the Final /8 has been extended until 20 October 2014. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-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

1 0

Re: [address-policy-wg] 2014-02 Proposal Accepted (Allow IPv4 PI transfer)
by Erik Bais 30 Sep '14

30 Sep '14

Hi Marco, Thank you for assistance and processing. Regards, Erik Bais -----Oorspronkelijk bericht----- Van: address-policy-wg-bounces(a)ripe.net [mailto:address-policy-wg-bounces@ripe.net] Namens Marco Schmidt Verzonden: dinsdag 30 september 2014 13:55 Aan: policy-announce(a)ripe.net CC: address-policy-wg(a)ripe.net Onderwerp: [address-policy-wg] 2014-02 Proposal Accepted (Allow IPv4 PI transfer) Dear colleagues, Consensus has been reached and the proposal for a change to ripe-622, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 The new RIPE Document is called ripe-623 and is available at: https://www.ripe.net/ripe/docs/ripe-623 The RIPE NCC has already begun preparations to implement this policy proposal. We will create new internal and external procedures, and related tools and documentation, to ensure the correct processing of IPv4 PI transfers. We estimate it will take about two months to fully implement the policy proposal. Once the implementation is complete, we will make another announcement and the transfer of IPv4 PI assignments will then be possible. Thank you to everyone who provided input. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

2014-02 Proposal Accepted (Allow IPv4 PI transfer)
by Marco Schmidt 30 Sep '14

30 Sep '14

Dear colleagues, Consensus has been reached and the proposal for a change to ripe-622, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-02 The new RIPE Document is called ripe-623 and is available at: https://www.ripe.net/ripe/docs/ripe-623 The RIPE NCC has already begun preparations to implement this policy proposal. We will create new internal and external procedures, and related tools and documentation, to ensure the correct processing of IPv4 PI transfers. We estimate it will take about two months to fully implement the policy proposal. Once the implementation is complete, we will make another announcement and the transfer of IPv4 PI assignments will then be possible. Thank you to everyone who provided input. Regards, Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] Moving "2014-02 New Draft Document and Impact Analysis Published (Allow IPv4 PI transfer)" to Last Call
by Gert Doering 24 Sep '14

24 Sep '14

Dear Address Policy 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. [..] > We encourage you to read the draft document text and send any comments > to address-policy-wg(a)ripe.net before 8 August 2014. The review phase for 2014-02 has ended. Given the amount of support, the WG chairs have decided that we have reached consensus. We think that all points brought up by the opposers have been sufficiently discussed - this might not be sufficient to convince the opposers to change their mind, but given sufficient support otherwise, it's good enough to move forward. This is what we'll do now -> move 2014-02 to Last Call. Marco will send the formal announcement for that tomorrow or Wednesday. For reference, a list of people that voiced support or opposition (or something else) in the previous review phase is appended below. This is what the chairs based their decision on. If you disagree with our interpretation of what has been said, and the conclusion we have drawn from it, please let us know. Gert Doering, Address Policy WG Chair Review Phase, starting July 10, 2014 Support: Tore Anderson Sonderegger Olaf Andre Keller Scott Leibrand Elvis Velea Donal Cunningham Juan P. Cerezo Daniel Suchy Piotr.Strzyzewski Larisa Yurkina Hamed Shafaghi Questions: George Giannousopoulos (neutral) Opposing: Aleksei Ivanov (LeaderTelecom), main reason seems to be pricing some discussion, after clarification that APWG cannot directly influence pricing, opposition wasn't kept up In Discussion with Alexsei, without voicing a clear pro/contra statement, mainly about pricing for LIR account, PI, ... Erik Bais Andrzej Dopiera??a Andrei Kushnireuski Jens Ott

1 1