October 2014 - address-policy-wg

Re: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais)
by Tore Anderson 21 Oct '14

21 Oct '14

* steve.r.wright(a)bt.com > Hi all, I support the goals of 2014-15, the suggestion below seems to be a practical solution, if acceptable to all parties. Agreed. I would have ideally preferred to see language that was sufficiently generic to accommodate for any condition (i.e., not just limited to ARIN's "needs-based" requirement) imposed by another RIR region on the RIPE region entities engaging in inter-region transfers with that RIR region. However, I see that accomplishing this might be more trouble than it's worth, especially when taking into account that ARIN doesn't consider the attempt currently in 2014-05 adequate. So it would seem that a "KISS" approach would be better, explicitly putting in a "needs-based" requirement as mandated by ARIN. John, thank you for suggesting text, it's very helpful to have a starting point that we know that ARIN will consider compatible. I have some comments on your suggested text, though: * John Curran > "For transfers from RIR regions which require needs-based policies, > recipients must provide a plan to the RIPE NCC for use of the > transferred resource within 24 months." (for example) 1) «RIR regions which require needs-based policies» might be too broad. APNIC requires needs-based for intra-region transfers but not for inter-region transfers. As they already have (IMHO) misinterpreted the current "interop clauses" in 2014-05 to apply to them even though there is no need for that, we need to make it clearer that it only applies for regions which require *the RIPE region* to have needs-based policies. 2) Hard-coding 24 months is a risk. If for example the ARIN community changes their transfer policy to have different need period, then we would find ourselves with incompatible policies again. So I think that we should instead just refer to whatever need period the other RIR has. 3) I think it would be more flexible to not require the usage plan to be presented to the NCC, but that it could be presented to the other RIR instead. My reasoning is that the other RIR might already have the forms and criteria ready for performing need evaluation in a way that's (obviously) "compatible" with that RIR's own policies, while the NCC might not. Therefore it could potentially be easier for all involved parties if the other RIR performs the required need evaluation (if that RIR and the NCC agrees on such a transfer procedure, that is). It might also help prevent possibly complaints from the other region that the NCC doesn't perform stringent enough evaluation, and so on. Suggested new text that takes the above into account below. It would replace the second paragraph in section 2.0 of 2014-05. (Also, the last sentence of section 3.0 should be removed.) «For transfers from RIR regions which require the RIPE region to have needs-based policies, recipients must provide a plan to the RIPE NCC or the other RIR for the use of the transferred resource within the time period defined by the transfer policy of the other RIR». It would be good if you could confirm that this variant would also be regarded as "compatible" by ARIN, John. Tore (who feels somewhat guilty for this stuff being tricky in the first place...)

2 4

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 21 Oct '14

21 Oct '14

Hi Erik - - >>>> 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. >>I noticed that the existing policy proposal doesn't have the arbitration point and the fact is, that the policies between RIPE and APNIC >>and RIPE and ARIN aren't the same. >>That in combination with the remark in the current policy summary : >>>> 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. >>That is an issue in my view. >>That in combination with what is stated in the Impact Assessment that the ARIN staff does not see the policy to be compatible with >>theirs .. are the points that I wanted to address. >>By having the other RIR pre-approve the transfer (either receiving or sending transfers) based on their view and interpretation of their >>own policy, they can do the need justification. >>Adjustments in their policy won't affect compatibility of the inter-RIR policy. >>And when the transfer is then submitted for processing to RIPE, it will always be compatible, the RIPE staff doesn't have to cram up on >>all policy changes, arbitration isn't an issue and you will have a policy that will work. >>If one of the other RIR's is going to change to a no needs justification policy, they can just pre-approve the transfer, and the RIPE NCC >>can still just process the transfer ... >>Personally I think that having the other RIR (not RIPE NCC) do the local policy checking and need justification if they have it for the >>transfer, makes this a lot easier, without having the RIPE NCC to line up on both the ARIN and APNIC policies. >>As an example: >>What if Registration Services (RS) from RIPE NCC would approve a certain justification according to their policy interpretation and ARIN >>or APNIC RS would not approve the same logic ? >>Policy interpretation and the justification checking, should be done at the RIR who has the most strict policy. It doesn't make sense to >>me, to have RIPE IPRA's try to do a justification check based on interpretation of the APNIC or ARIN policy ... Erik, if I understand you correctly, you are saying that the RIR with the strictest rules will perform the justification checks. For example, If we had a transfer from ARIN region to RIPE NCC region, then you are proposing the RIPE region buyer would have the needs justification performed by ARIN. Do I understand you correctly? The wording of the current proposal simply says that RIPE NCC would create an operational procedure. Marco Schmidt guides me that this operational procedure will be created in detail between the RIRs once RIPE NCC implements the proposal. The proposal will open the door for the option that other RIRs ask for information from the buying resource holder in RIPE NCC, in other words, that the operational procedure could be what you suggest, that another RIR, such as ARIN in my example above, would perform the needs justification on the RIPE buyer. Another solution might be that the other RIR sends a list of questions based on its policies/requirements and RIPE NCC passes this information to the purchaser and communicates back its answers. This seems more practical than having RIPE NCC staff updated about any policy changes in other regions. However what procedure(s) will be established is to be decided between the RIRs and, as I said, I did not intend for the policy itself to define operational procedures. So far we only know that ARIN doesn't see compatibility between the policies - again, to add commentary, I find this very surprising, since I repeat again, that the policy allows for the enforcement of needs justification to ARIN's content, through operational control. APNIC is unsure. Erik, I think we are on the same page with respect to the meaning, and it is merely that Marco, Gert, Sander, et al, should guide us on what is policy versus operational procedure. >>>> This is the nature of negotiation in the global community. >>Perhaps, but a policy for the benefit of the global community, should have some kind of arbitration clauses in there or at least define >>where arbitration should be done. >>It is good stewardship to have a RIPE policy that wouldn't open up the doors for long international discussions without a clear view on >>who the 'problem-owner' is .. and for future customers it should be clear where they can take their complains if they are not happy >>with the outcome. I asked Marco about this and so far there is no Inter-RIR arbitration. Currently if an LIR in our region disagrees with a RIPE NCC decision, they can start an arbitration. However, as you point out, if a resource holder in RIPE NCC region disagrees with a decision e.g. from ARIN, there will be no direct way that they can start arbitration against this decision. I suppose a solution would be a global arbitration procedure, and this would seem to need a global policy proposal (to be accepted by the different RIRs and beyond the scope of 2014-05). Another more light-weight solution would be that the transfer partner in the other region starts the arbitration. Here is another hypothetical example. Say, Company A in ARIN wants to transfer to company B in RIPE NCC region. ARIN rejects the transfer request, due to missing requirements by company B. They both disagree with ARIN's decision. Then Company A starts an appeal with ARIN (as the ARIN member). This use of existing mechanisms would at least allow 2014-05 to get off the ground without making it too large. >>Regards, >>Erik Bais Regards, and thanks for pointing out these potential issues, Sandra Brown

3 2

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