From pk at DENIC.DE Sun Oct 5 22:14:58 2014 From: pk at DENIC.DE (Peter Koch) Date: Sun, 5 Oct 2014 22:14:58 +0200 Subject: [address-policy-wg] WG chair re-selection procedure In-Reply-To: <541D61A1.3060505@inex.ie> References: <36064F33-CE66-4407-8B0E-1B356D642520@steffann.nl> <20140916075207.GR14459@Space.Net> <5417EEF5.6010107@tvt-datos.es> <5417FCF0.20701@tvt-datos.es> <8FD6BA9C-F864-48D8-8AC8-981315B7585F@rfc1035.com> <541D61A1.3060505@inex.ie> Message-ID: <20141005201458.GJ26411@x28.adm.denic.de> On Sat, Sep 20, 2014 at 12:14:41PM +0100, Nick Hilliard wrote: > [...] The candidates will be different but there is no > good reason not to have the same or a similar selection process. if the RIPE community was a collective of otherwise independent or sovereign working groups, there might be such a reason, but that's not the case. Also, the WG chairs do have multiple roles: 1) "run" the WG meetings 2) process a PDP proposal through the PDP in their respective WG 3) participate in the "WG chairs collective" (*) 4) participate in "other" meetings This is mostly covered in RIPE 542 (which, although titled "Working Group Chair Job Description and Procedures", also covers part of the WG life cycle). The PDP was layed out in RIPE-500 at the time of publication of RIPE-542 but has been recently updated (RIPE-614), therefore the duties under (3) above have significantly changed. In any case, the WG chairs have a role in the PDP, so for good governance, their taking (and leaving) "office" should be in line with the PDP. > Firstly, you're voicing an implicit assumption that the WG chairs are > responsible for deciding the baseline scope of this policy. In fact, this > is a matter of general RIPE community policy and the opinion of the WG > Chairs matters only insofar as they are also members of the RIPE community. Well said, but from that it could be equally deduced that the group was free in their choice of accepting the work and eventually not move the result through the PDP. > The place to discuss this is not the WG lists, but ripe-list and at the > plenary. If the RIPE community comes to some form of consensus that this > should be devolved to the WGs, only then should this happen. Otherwise, > this is subject to general RIPE community policy. I do agree, but so far neither of us two nor anybody else has spoken up on that list? > The RIPE Community has a policy development process for deciding matters of > community policy. Once again, it is being ignored because of top-down > decisions which were made in private without reference to the wider RIPE > community. We're bootsptrapping. The proposed approach is better than what we have today, albeit far from ideal. If the community cares enough, we'll hopefully find someone who takes the draft (meanwhile having been posted at least to the anti-abuse-wg list) through the PDP. Honestly, though, as much as I prefer the 'design team' output over what has been started now, I believe the PDP has more important and serious issues than whether all WGs eventually arrive at the same process for WG chair inauguration. -Peter From nick at inex.ie Thu Oct 9 00:40:03 2014 From: nick at inex.ie (Nick Hilliard) Date: Wed, 08 Oct 2014 23:40:03 +0100 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20140919113127.3590d567@fizzix> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> Message-ID: <5435BD43.6010104@inex.ie> On 19/09/2014 10:31, Martin Pels wrote: > You are correct in that having received a small IPv6 PA assigment from another > LIR may not be enough for deploying IPv6 to end-customers. But I could argue > that having this PA assignment actually deployed in your network is more > meaningful than having requested your own PA allocation without doing anything > with it (which would satisfy the policy as it is now). There is nothing in the proposal about deployment of either PI or PA space, so it's not clear why you're making this argument. The proposal as it stands is window dressing because it requires only tickbox-style compliance. This is completely pointless. Organisations will either deploy ipv6 or they won't, and this decision will be made on business merit rather than because a RIPE NCC IPRA delayed a /22 allocation because of a policy violation. >From a syntax point of view, the wording is contradictory. The summary states that there is a requirement for an "inet6num object registered in the RIPE Database or any of the other RIR databases mirrored by the RIPE NCC". The policy itself does not state this; just that the /22 allocation can be made if the LIR has "already received a valid globally routeable unicast IPv6 address block". These two things are not the same. If you intend something to be in the policy, then put it into the policy. The policy is what ends up in RIPE-* documents; the summary is not a part of this. >From an implementation point of view, it may be worth asking the RIPE NCC if they intend to demand that the assignee of the inet6num is an exact text match of the legal name of the LIR. Most organisations are pretty sloppy about this, and this is a likely source of future confusion because getting PA or other RIR assignment/allocation details changed in order to qualify for the /22 could turn out to be surprisingly troublesome. FWIW, the RIPE NCC has done the community a favour by implicitly pointing this out: "Delay and extra workload is only expected if the provided IPv6 range is not clearly registered to the requesting RIPE NCC member." In other words, be careful what you ask for because you might get it. Also, the RIPE NCC has clarified that IPv6 assignments to different companies within the same company group do not qualify for this proposal. >From what I understand, this was one of the original complaints about the existing policy, and it will not be fixed with this proposal. overall: - I don't support this policy because window dressing is not a good basis for making ip addressing policy. - even if I did support it, a) the policy doesn't say what you think it says and b) it doesn't handle some of the problems of the current policy. I would kindly suggest either dropping the ipv6 requirement completely from the last /8 policy, or if you feel strongly that it should stay, rewording this proposal to make it say what you intend. Nick From gert at space.net Fri Oct 10 21:20:59 2014 From: gert at space.net (Gert Doering) Date: Fri, 10 Oct 2014 21:20:59 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5435BD43.6010104@inex.ie> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> Message-ID: <20141010192059.GB31092@Space.Net> Hi, On Wed, Oct 08, 2014 at 11:40:03PM +0100, Nick Hilliard wrote: > The proposal as it stands is window dressing because it requires only > tickbox-style compliance. This is completely pointless. Organisations > will either deploy ipv6 or they won't, and this decision will be made on > business merit rather than because a RIPE NCC IPRA delayed a /22 allocation > because of a policy violation. Indeed, but that's what we have in the policy right *now* :-) So maybe the question to the group should be: - abandon the IPv6 requirement completely, and "who asks for their last /22 gets it, done" or - come to some agreement about what sort of IPv6 window dressing should be there, maybe only to serve as an awareness thing. - *iff* that, what sort of IPv6 space should qualify? Onlookers might have noticed that this proposal should have ended it's current phase (discussion) quite a while ago, was extended, and should have ended now again - but we'll extend the discussion phase again, to clarify this point. Then the proposers have a clear direction in which way to re-word their proposal for the next discussion phase - the current text certainly hasn't reached consensus yet. So, working group, please let us know what you think. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From ebais at a2b-internet.com Fri Oct 10 21:57:09 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 10 Oct 2014 21:57:09 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141010192059.GB31092@Space.Net> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> Message-ID: <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> Hi Gert, Any windows dressing in the policy should be avoided .. If people want to implement v6, they will .. If people need to request v6 in order to obtain v6, they will.. But it doesn't mean they will deploy ... Based on that, I would say, strike the v6 requirement in order to request the last v4 /22 .. Added to that, having people that deployed v6 based on PI having to turn in their space as it doesn't fit the requirement feels like a slap in the face and a waste of effort ... I would vote to have that fixed ... Erik Bais Verstuurd vanaf mijn iPad > Op 10 okt. 2014 om 21:20 heeft Gert Doering het volgende geschreven: > > Hi, > >> On Wed, Oct 08, 2014 at 11:40:03PM +0100, Nick Hilliard wrote: >> The proposal as it stands is window dressing because it requires only >> tickbox-style compliance. This is completely pointless. Organisations >> will either deploy ipv6 or they won't, and this decision will be made on >> business merit rather than because a RIPE NCC IPRA delayed a /22 allocation >> because of a policy violation. > > Indeed, but that's what we have in the policy right *now* :-) > > So maybe the question to the group should be: > > - abandon the IPv6 requirement completely, and "who asks for their last > /22 gets it, done" > > or > > - come to some agreement about what sort of IPv6 window dressing should > be there, maybe only to serve as an awareness thing. > > - *iff* that, what sort of IPv6 space should qualify? > > > Onlookers might have noticed that this proposal should have ended it's > current phase (discussion) quite a while ago, was extended, and should > have ended now again - but we'll extend the discussion phase again, to > clarify this point. Then the proposers have a clear direction in which > way to re-word their proposal for the next discussion phase - the current > text certainly hasn't reached consensus yet. > > > So, working group, please let us know what you think. > > 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 From rogerj at gmail.com Sat Oct 11 10:45:07 2014 From: rogerj at gmail.com (=?UTF-8?Q?Roger_J=C3=B8rgensen?=) Date: Sat, 11 Oct 2014 10:45:07 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> Message-ID: On Fri, Oct 10, 2014 at 9:57 PM, Erik Bais wrote: > Hi Gert, > > Any windows dressing in the policy should be avoided .. If people want to implement v6, they will .. If people need to request v6 in order to obtain v6, they will.. But it doesn't mean they will deploy ... > > Based on that, I would say, strike the v6 requirement in order to request the last v4 /22 .. > Added to that, having people that deployed v6 based on PI having to turn in their space as it doesn't fit the requirement feels like a slap in the face and a waste of effort ... I would vote to have that fixed ... agree, let's just drop the v6 and give out the last /22 to those that want it. -- Roger Jorgensen | ROJO9-RIPE rogerj at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From frettled at gmail.com Sat Oct 11 16:56:23 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Sat, 11 Oct 2014 16:56:23 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> Message-ID: On Sat, Oct 11, 2014 at 10:45 AM, Roger J?rgensen wrote: > On Fri, Oct 10, 2014 at 9:57 PM, Erik Bais wrote: > > Hi Gert, > > > > Any windows dressing in the policy should be avoided .. If people want > to implement v6, they will .. If people need to request v6 in order to > obtain v6, they will.. But it doesn't mean they will deploy ... > > > > Based on that, I would say, strike the v6 requirement in order to > request the last v4 /22 .. > > Added to that, having people that deployed v6 based on PI having to turn > in their space as it doesn't fit the requirement feels like a slap in the > face and a waste of effort ... I would vote to have that fixed ... > > agree, let's just drop the v6 and give out the last /22 to those that want > it. > > I could probably write a couple of thousands of words about this, but I'll be brief: Yes, please let's just drop the v6 requirement. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Mon Oct 13 09:27:29 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 13 Oct 2014 09:27:29 +0200 Subject: [address-policy-wg] 2014-04 Review Period extended until 20 October 2014 (Relaxing IPv6 Requirement for Receiving Space from the Final /8) Message-ID: 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 . Regards, Marco Schmidt Policy Development Officer RIPE NCC From d.baeza at tvt-datos.es Mon Oct 13 10:02:21 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 13 Oct 2014 10:02:21 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> Message-ID: <543B870D.2010609@tvt-datos.es> Hi all! El 11/10/2014 16:56, Jan Ingvoldstad escribi?: > On Sat, Oct 11, 2014 at 10:45 AM, Roger J?rgensen On Fri, Oct 10, 2014 at 9:57 PM, Erik Bais > Hi Gert, > > > > Any windows dressing in the policy should be avoided .. If people want to implement v6, they will .. If people need to request v6 in order to obtain v6, they will.. But it doesn't mean they will deploy ... > > > > Based on that, I would say, strike the v6 requirement in order to request the last v4 /22 .. > > Added to that, having people that deployed v6 based on PI having to turn in their space as it doesn't fit the requirement feels like a slap in the face and a waste of effort ... I would vote to have that fixed ... > > agree, let's just drop the v6 and give out the last /22 to those > that want it. > > > I could probably write a couple of thousands of words about this, but > I'll be brief: > > Yes, please let's just drop the v6 requirement. I totally disagree. In other hand, I'll make harder the v6 requeriment to get the /22. How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible. Cheers, -- Daniel Baeza From sander at steffann.nl Mon Oct 13 11:58:48 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 13 Oct 2014 11:58:48 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543B870D.2010609@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> Message-ID: Hi Daniel, Some comments to clarify the discussion: > I totally disagree. In other hand, I'll make harder the v6 requeriment to get the /22. For what purpose? When making statements like this please explain what your underlying intentions are. We make policy for a purpose and if the purpose isn't clear then it is impossible to have a reasonable discussion about the solution space. > How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible. IP addresses allocated/assigned do not have to be routed on 'the global internet' (for whatever value of 'global internet' you pick). Routing requirements were explicitly removed from the IPv6 policy with https://www.ripe.net/ripe/policies/proposals/2009-06. Cheers, Sander From mschmidt at ripe.net Mon Oct 13 15:09:37 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 13 Oct 2014 15:09:37 +0200 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: 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 before 11 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From d.baeza at tvt-datos.es Mon Oct 13 17:46:17 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Mon, 13 Oct 2014 17:46:17 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> Message-ID: <543BF3C9.4090501@tvt-datos.es> Hi Sander, And I'll try to explain as better I can. El 13/10/2014 11:58, Sander Steffann escribi?: > Hi Daniel, > > Some comments to clarify the discussion: > >> I totally disagree. In other hand, I'll make harder the v6 requeriment to get the /22. > > For what purpose? When making statements like this please explain what your underlying intentions are. We make policy for a purpose and if the purpose isn't clear then it is impossible to have a reasonable discussion about the solution space. Easy. The current IPv6 deploy makes me cry like a little girl. NOBODY (as percentage) is deploying it in their customer/backone/whatever network. If we want to migrate from v4 to v6, some drastic changes should be made. One of them, requiring the v6 to be publicly visible if you want to have the last /22. That way we ensure that LIR/Network will have, 'at least', ipv6 working on the router. Its sad we cant check deeper if clients/servers/etc is having v6 conectivity but at least we can check if v6 is public in bgp. >> How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible. > > IP addresses allocated/assigned do not have to be routed on 'the global internet' (for whatever value of 'global internet' you pick). Routing requirements were explicitly removed from the IPv6 policy with https://www.ripe.net/ripe/policies/proposals/2009-06. So please, tell me why someone will require/request public ip space if is not to be publicly routed on "the global internet". And that is a real question since I saw that "IP addresses allocated/assigned do not have to be routed on 'the global internet" several times and cant understand why. Cheers, -- Daniel Baeza From nick at inex.ie Mon Oct 13 18:40:40 2014 From: nick at inex.ie (Nick Hilliard) Date: Mon, 13 Oct 2014 17:40:40 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <20141013131148.9C6152E14B@prometheus.inex.ie> References: <20141013131148.9C6152E14B@prometheus.inex.ie> Message-ID: <543C0088.3080806@inex.ie> 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 From jim at rfc1035.com Mon Oct 13 19:19:29 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 13 Oct 2014 18:19:29 +0100 Subject: [address-policy-wg] working IPv6 requirement for last /22 In-Reply-To: <543BF3C9.4090501@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> Message-ID: On 13 Oct 2014, at 16:46, Daniel Baeza (Red y Sistemas TVT) wrote: > If we want to migrate from v4 to v6, some drastic changes should be made. One of them, requiring the v6 to be publicly visible if you want to have the last /22. In your opinion. > That way we ensure that LIR/Network will have, 'at least', ipv6 working on the router. > Its sad we cant check deeper if clients/servers/etc is having v6 conectivity but at least we can check if v6 is public in bgp. This is just silly. An LIR could easily pass your "working IPv6" test without actually deploying or using IPv6 in their network for real. All this protocol policing would do is the equivalent of security theatre at an airport. People get a (bogus) feeling that Something Is Being Done which has little bearing on anything that actually matters. Few, if any, incentives have made a meaningful difference to IPv6 deployment to date. So I doubt the one you are advocating can succeed where other, better ones have failed. >>> How? Making the policy not only "to have" the v6 alloc, I'll require also having it with route6 and published in BGP. RIPEstat is a good tool to check if the v6 is publicly visible. >> >> IP addresses allocated/assigned do not have to be routed on 'the global internet' (for whatever value of 'global internet' you pick). Routing requirements were explicitly removed from the IPv6 policy with https://www.ripe.net/ripe/policies/proposals/2009-06. > > So please, tell me why someone will require/request public ip space if is not to be publicly routed on "the global internet". > And that is a real question since I saw that "IP addresses allocated/assigned do not have to be routed on 'the global internet" several times and cant understand why. One of the jobs of an RIR is to distribute globally unique IP addresses. It's up to the address holder to decide if they want to route those addresses or not, nobody else. The RIR doesn't get to decide that. FYI many organisations use globally unique addresses so that they do not have to undergo expensive renumbering if/when they sell off parts of their business or acquire another company or interconnect with other corporate nets that aren't directly connected to the Internet From gert at space.net Mon Oct 13 19:43:42 2014 From: gert at space.net (Gert Doering) Date: Mon, 13 Oct 2014 19:43:42 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543BF3C9.4090501@tvt-datos.es> References: <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> Message-ID: <20141013174342.GE31092@Space.Net> Hi, On Mon, Oct 13, 2014 at 05:46:17PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > > For what purpose? When making statements like this please explain what your underlying intentions are. We make policy for a purpose and if the purpose isn't clear then it is impossible to have a reasonable discussion about the solution space. > > Easy. The current IPv6 deploy makes me cry like a little girl. NOBODY > (as percentage) is deploying it in their customer/backone/whatever network. Well, we're most certainly not there yet, but at least in my neck of the woods (DE/CH), IPv6 uptake has been quite good in the last years - some client ISPs have reached over 20% of their customers, which translates to quite a bit of IPv6 traffic - and quite a few high profile content providers have also IPv6-enabled their offerings (youtube, netflix, facebook, ...). Now, the interesting question here is: - who will be requesting that /22? Will it make a difference in the big picture if they deploy IPv6 "soonish" or not? - will it make a difference if we force them to provide some sort of "look I have IPv6!" dance? (We had this discussion every now and then in the last years, including "give every LIR a /32 right away!" and the end consensus was along the lines of "if they want to deploy, it is easy enough to get space, so forcing an IPv6 prefix on them won't make a difference") Deploying IPv6 is more than "setup a tunnel somewhere and anounce your prefix", so we should consider whether the incentives we give are effective, or just theater. - who will benefit, and who will be hurt by such a requirement? Right now we have a policy which is actually hurting people that already *have* deployed IPv6, just not the right type of addresses... (because they have to get their own PA and renumber out of the PI they have already deployed). *This* is certainly not a useful incentive. I officially do not have an opinion here, but I hope I'm asking the right questions to reach some useful policy at the end :-) (but indeed, I am known to be in favour of fairly simple and easy to implement policies) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From sander at steffann.nl Mon Oct 13 21:07:37 2014 From: sander at steffann.nl (Sander Steffann) Date: Mon, 13 Oct 2014 21:07:37 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543BF3C9.4090501@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> Message-ID: Hi Daniel, > So please, tell me why someone will require/request public ip space if is not to be publicly routed on "the global internet". > And that is a real question since I saw that "IP addresses allocated/assigned do not have to be routed on 'the global internet" several times and cant understand why. For example if running a closed network that interconnects with other organisations but not with the whole internet. For example a closed network between banks or municipalities that needs guaranteed globally unique addresses to avoid clashes with the networks of the connected organisations. The network itself is not connected to the internet but systems at the participating organisations probably are. Therefore you need globally unique addresses. Another example might be a car manufacturer that wants addresses for the internal networks of the cars they manufacture. You probably don't want your cars systems to be connected to the global internet. Having connectivity to some other systems (monitoring, fleet management etc) might be useful though. And those systems are connected to the internet so the cars need globally unique addresses that don't overlap with anything used on the internet or within the companies that run the remote systems. And these are just some things that I can think of now. There certainly will be others. We have a registry to make sure we hand out unique addresses to organisations so no clashes occur and so we know who is responsible for which addresses. Not to limit the kinds of networks and the way those networks are connected to each other. Cheers, Sander PS: This is nothing new for IPv6, networks like this exists in the IPv4 world as well From jim at rfc1035.com Mon Oct 13 21:11:12 2014 From: jim at rfc1035.com (Jim Reid) Date: Mon, 13 Oct 2014 20:11:12 +0100 Subject: [address-policy-wg] WG chair re-selection procedure In-Reply-To: <20141005201458.GJ26411@x28.adm.denic.de> References: <36064F33-CE66-4407-8B0E-1B356D642520@steffann.nl> <20140916075207.GR14459@Space.Net> <5417EEF5.6010107@tvt-datos.es> <5417FCF0.20701@tvt-datos.es> <8FD6BA9C-F864-48D8-8AC8-981315B7585F@rfc1035.com> <541D61A1.3060505@inex.ie> <20141005201458.GJ26411@x28.adm.denic.de> Message-ID: On 5 Oct 2014, at 21:14, Peter Koch wrote: > In any case, the WG chairs have a role in the PDP, so > for good governance, their taking (and leaving) "office" should be in > line with the PDP. IMO these are two very different things and they should not be conflated with each other. Please explain why these should be combined. For bonus points, please show how and why appointment of WG chairs have to be in line with the PDP. AFAICT there is no document or consensus decision which supports this position. You've made this claim a few times but as yet you've not presented a justification for that PoV. I also think it's unwise to attempt to retrospectively force everything at RIPE to be derived from the foundations of a somewhat flawed PDP. Further discussion of this topic does not belong in the AP list. From tore at fud.no Mon Oct 13 21:42:10 2014 From: tore at fud.no (Tore Anderson) Date: Mon, 13 Oct 2014 21:42:10 +0200 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: Message-ID: <543C2B12.5080306@fud.no> * 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 From ebais at a2b-internet.com Tue Oct 14 18:30:04 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 14 Oct 2014 18:30:04 +0200 Subject: [address-policy-wg] [policy-announce] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) Message-ID: <01ee01cfe7cc$1fa5d4e0$5ef17ea0$@a2b-internet.com> 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 From scottleibrand at gmail.com Tue Oct 14 19:20:40 2014 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 14 Oct 2014 10:20:40 -0700 Subject: [address-policy-wg] [policy-announce] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <01ee01cfe7cc$1fa5d4e0$5ef17ea0$@a2b-internet.com> References: <01ee01cfe7cc$1fa5d4e0$5ef17ea0$@a2b-internet.com> Message-ID: On Tue, Oct 14, 2014 at 9:30 AM, Erik Bais wrote: > 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. > Only ISPs are ARIN members. End user organizations in the ARIN region are just resource holders, not members. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Wed Oct 15 10:10:44 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 15 Oct 2014 10:10:44 +0200 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <543C2B12.5080306@fud.no> References: <543C2B12.5080306@fud.no> Message-ID: <543E2C04.8060402@fud.no> * Tore Anderson > 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. I was pointed this recording of APNIC's policy-sig meeting which sheds some more light on the matter (the relevant presentation starts at 1:33): https://www.youtube.com/watch?v=5cXk8BrMJJU It would appear there are two distinct problems: 1) APNIC feels that 2014-05 causes a circular policy loop for APNIC->RIPE transfers, cf. the slide that's up at 1:36:30. As I understand it, the problem is that APNIC's policy says any requirements on the receiver is ?as defined in [RIPE's] tranfer policy?, which in turn says the ?the RIPE NCC will work with the resource holder to fulfil[sic] any requirements of [APNIC]?. I personally believe this is a misinterpretation on APNIC's part, as my understanding on the latter language is that it is only to be applied when the sending RIR insists on particular requirements being imposed on the receiver, that which are not found in our own set of policies. The most obvious example of such a requirement would be ARIN's insistence on ?reciprocal, compatible, needs-based policies? (cf. https://www.arin.net/policy/nrpm.html#eight4). For APNIC, on the other hand, there does not appear to be any policy requirement that would require this language to come into effect. (They could still use it for non-policy requirements though, such as demanding a transfer fee from the RIPE region recipient, but I digress.) Therefore, the receiver of a transfer from APNIC to RIPE would only be subject to any requirements in our own policies (i.e., ripe-623 section 5.5 or 6.4). In any case, 2014-05 probably needs to be amended so that it is clear that the statements ?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? and ?the RIPE NCC will also comply with the commitments imposed by the receiving RIR, in order to facilitate the transfer?, is only to be used if and only if there other RIR has an absolute requirement that does not exist in our policies, and furthermore that they are used to allow compliance with that particular requirement alone. 2) Assuming the previous point is handled, there is an additional concern that if 2014-05 passes, it will cause ARIN to declare that APNIC's policy is no longer compatible. It wasn't entirely clear to me if they though this would happen instantaneously (by ARIN-the-RIR, not the community), or if they were worried that the ARIN community would react by changing their policies to make them incompatible. - The instantaneous alternative does strike me as somewhat far fetched, considering that ARIN has already deemed APNIC's policy to be ?reciprocal, compatible, needs-based?, and the fact that 2014-05 doesn't change a single word in neither ARIN's nor APNIC's policy documents. That said, obviously I can't know for certain if 2014-04 could possibly cause such an instantaneous change in how ARIN interprets APNIC's policy text. Maybe John could chime in? - The other alternative, where 2014-05's passing would prompt the ARIN community to change their policy document so that APNIC<->ARIN transfers are no longer possible, does seems more plausible, yet somewhat speculative as we have no idea whether the ARIN community cares about 2014-05 at all and if so what they think about it. Another possibility, which was suggested by one commentator, is that the APNIC community preempts such an ARIN policy change, by changing their own policy instead (if they feel it is necessary in order to keep the ARIN community happy that is). In any case, as other RIRs' policies are out of our hands, I don't think we can do much about it in 2014-05, unless there is some clear guidance from APNIC and/or ARIN on how 2014-05 could be amended to make them happy (assuming either of them are unhappy in the first place). While I'm a firm believer in letting the individual RIR communities write their own policies without other regions trying to influence the process, Inter-RIR policies are necessarily exceptions. Tore From d.baeza at tvt-datos.es Wed Oct 15 11:16:24 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 15 Oct 2014 11:16:24 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141013174342.GE31092@Space.Net> References: <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <20141013174342.GE31092@Space.Net> Message-ID: <543E3B68.9040300@tvt-datos.es> Hi, Sorry for late answer as Im really busy here :) El 13/10/2014 19:43, Gert Doering escribi?: > - who will be requesting that /22? Will it make a difference in the > big picture if they deploy IPv6 "soonish" or not? Only 1 wont make the difference in the big picture. Thousands of them will do. > - will it make a difference if we force them to provide some sort of > "look I have IPv6!" dance? (We had this discussion every now and then > in the last years, including "give every LIR a /32 right away!" and > the end consensus was along the lines of "if they want to deploy, it > is easy enough to get space, so forcing an IPv6 prefix on them won't > make a difference") Deploying IPv6 is more than "setup a tunnel > somewhere and anounce your prefix", so we should consider whether the > incentives we give are effective, or just theater. There arent at this moment (or I dont know them) any incentives to deploy IPv6... If nobody does, nobody will do. > - who will benefit, and who will be hurt by such a requirement? Right now > we have a policy which is actually hurting people that already *have* > deployed IPv6, just not the right type of addresses... (because they > have to get their own PA and renumber out of the PI they have already > deployed). *This* is certainly not a useful incentive. Then lets change the text of the policy for recieving the last /22. Point 5.1, rule 4: From: Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. To: Allocations will only be made to LIRs if the have already received and IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont just read literally as my english is not very good. Try to read what I want to transmit) > I officially do not have an opinion here, but I hope I'm asking the right > questions to reach some useful policy at the end :-) (but indeed, I am > known to be in favour of fairly simple and easy to implement policies) We should not make policy only considering the simplicity and ease of implementation. Of course, if we have 2 options for a policy change saying the same but with different implementations, we should use the simple and easy one. Cheers, -- Daniel Baeza From d.baeza at tvt-datos.es Wed Oct 15 11:22:55 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 15 Oct 2014 11:22:55 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> Message-ID: <543E3CEF.1050403@tvt-datos.es> Hi Steffan, El 13/10/2014 21:07, Sander Steffann escribi?: > For example if running a closed network that interconnects with other organisations but not with the whole internet. For example a closed network between banks or municipalities that needs guaranteed globally unique addresses to avoid clashes with the networks of the connected organisations. The network itself is not connected to the internet but systems at the participating organisations probably are. Therefore you need globally unique addresses. Another example might be a car manufacturer that wants addresses for the internal networks of the cars they manufacture. You probably don't want your cars systems to be connected to the global internet. Having connectivity to some other systems (monitoring, fleet management etc) might be useful though. And those systems are connected to the internet so the cars need globally unique addresses that don't overlap with anything used on the internet or within the companies that run the remote systems. > > And these are just some things that I can think of now. There certainly will be others. We have a registry to make sure we hand out unique addresses to organisations so no clashes occur and so we know who is responsible for which addresses. Not to limit the kinds of networks and the way those networks are connected to each other. There isnt any other way of doing it? I mean: - Public and unique IP Space works for both, private and public networks. - Private and NOT unique Space only works for private networks. Since public and unique IP Space is the only one you can use for "whole internet" and we (not we as me, we as all LIRs/RIRs) are running out of v4 space. There is a little conflict as private networks can work with private space, but public ones cant. Do you know what I mean? Cheers, -- Daniel Baeza From gert at space.net Wed Oct 15 11:23:01 2014 From: gert at space.net (Gert Doering) Date: Wed, 15 Oct 2014 11:23:01 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543E3B68.9040300@tvt-datos.es> References: <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <20141013174342.GE31092@Space.Net> <543E3B68.9040300@tvt-datos.es> Message-ID: <20141015092301.GK31092@Space.Net> Hi, On Wed, Oct 15, 2014 at 11:16:24AM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > There arent at this moment (or I dont know them) any incentives to > deploy IPv6... If nobody does, nobody will do. Repeating the claim that "nobody deploys IPv6" - which is quite obviously not true, and everybody can see that - is not really strengthening any argument based on that. There are quite some incentives to deploy IPv6, like "IPv4 run-out" and "cost of CGN, cost of IPv4 deployment, poor quality of web services to IPv4-behind-CGN users, etc." Even our policy has (indirect) incentives to deploy IPv6 - getting IPv6 address blocks is so much easier than it ever was for IPv4 addresses... [..] > Then lets change the text of the policy for recieving the last /22. > > Point 5.1, rule 4: > > From: > > Allocations will only be made to LIRs if they have already received an > IPv6 allocation from an upstream LIR or the RIPE NCC. > > To: > > Allocations will only be made to LIRs if the have already received and > IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont > just read literally as my english is not very good. Try to read what I > want to transmit) But that's basically back to "window dressing" - acquiring an IPv6 network is trivial, but if someone does not want to deploy IPv6, it will not make him. [..] > > I officially do not have an opinion here, but I hope I'm asking the right > > questions to reach some useful policy at the end :-) (but indeed, I am > > known to be in favour of fairly simple and easy to implement policies) > > We should not make policy only considering the simplicity and ease of > implementation. Of course, if we have 2 options for a policy change > saying the same but with different implementations, we should use the > simple and easy one. If we have a clause in the policy that is there to achieve something, but doesn't do so, and the policy without the clause is easier to understand and implement, this is definitely preferred. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From d.baeza at tvt-datos.es Wed Oct 15 12:05:56 2014 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 15 Oct 2014 12:05:56 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <20141015092301.GK31092@Space.Net> References: <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <20141013174342.GE31092@Space.Net> <543E3B68.9040300@tvt-datos.es> <20141015092301.GK31092@Space.Net> Message-ID: <543E4704.1090509@tvt-datos.es> Hi, El 15/10/2014 11:23, Gert Doering escribi?: > Hi, > > On Wed, Oct 15, 2014 at 11:16:24AM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: >> There arent at this moment (or I dont know them) any incentives to >> deploy IPv6... If nobody does, nobody will do. > > Repeating the claim that "nobody deploys IPv6" - which is quite obviously > not true, and everybody can see that - is not really strengthening any > argument based on that. Sorry, I didnt mean to say nobody have deployed IPv6. For example I did and currently at least 40% of my customers have IPv6 ready equipment (modem and their cpe) and arround 15% of my total traffic is IPv6. A this moment only the 18.46% of ASN are announcing an IPv6 prefix. Imagine this situation: A new created LIR is asking for the last /22 v4 allocation. RIPE says, "hey, you can recieve also an IPv6 alloc" and the new LIR checks how many ppl have IPv6 and see is a marginal percentage. Why is going that LIR to stress the mind to implement IPv6 if "nobody" does and will not make any difference to the quality of their customer connections? Again, im sure im not writting what Im trying to say, but Im doing my best on that. > There are quite some incentives to deploy IPv6, like "IPv4 run-out" and > "cost of CGN, cost of IPv4 deployment, poor quality of web services to > IPv4-behind-CGN users, etc." Those arent incentives, are facilities. An incentive is, for example: Hey, you will recieve a /23 IPv4 alloc if you make your network dual-stack. Note: IS AN EXAMPLE!!!! It's the first incentive that has fly on my mind, but surely there are many more and not related to more IPv4 allocs. > Even our policy has (indirect) incentives to deploy IPv6 - getting IPv6 > address blocks is so much easier than it ever was for IPv4 addresses... Same. That is facilities, not incentives. > [..] >> Then lets change the text of the policy for recieving the last /22. >> >> Point 5.1, rule 4: >> >> From: >> >> Allocations will only be made to LIRs if they have already received an >> IPv6 allocation from an upstream LIR or the RIPE NCC. >> >> To: >> >> Allocations will only be made to LIRs if the have already received and >> IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont >> just read literally as my english is not very good. Try to read what I >> want to transmit) > > But that's basically back to "window dressing" - acquiring an IPv6 network > is trivial, but if someone does not want to deploy IPv6, it will not make > him. Sorry, cant understand what you mean. > [..] >>> I officially do not have an opinion here, but I hope I'm asking the right >>> questions to reach some useful policy at the end :-) (but indeed, I am >>> known to be in favour of fairly simple and easy to implement policies) >> >> We should not make policy only considering the simplicity and ease of >> implementation. Of course, if we have 2 options for a policy change >> saying the same but with different implementations, we should use the >> simple and easy one. > > If we have a clause in the policy that is there to achieve something, but > doesn't do so, and the policy without the clause is easier to understand > and implement, this is definitely preferred. If the clause in the policy dont change the way the policy is, and make easier to understand and implement, for sure is preferred. If the clause is "core" and without it the policy completely changes, only to make is easier I do not agree with that. -- Daniel Baeza From sander at steffann.nl Wed Oct 15 12:08:18 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 15 Oct 2014 12:08:18 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543E3B68.9040300@tvt-datos.es> References: <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <20141013174342.GE31092@Space.Net> <543E3B68.9040300@tvt-datos.es> Message-ID: <2328A503-5314-416A-B86D-B3E05ED25BDC@steffann.nl> Hi Daniel, > Then lets change the text of the policy for recieving the last /22. > > Point 5.1, rule 4: > > From: > Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC. > > To: > Allocations will only be made to LIRs if the have already received and IPv6 PI or PA from another LIR, RIPE NCC or other RIR. That is still something that won't push real deployment, only administrative work... A different idea: if we want people requesting IPv4 space to be aware of IPv6 then why not just make it a requirement that the requester declares that they are aware that IPv4 is a scarce and limited resource and that for further scalability of the internet IPv6 deployment is required. It would probably have the same impact on real IPv6 deployment without any window dressing. And it would avoid requiring people to request resources that they have no intention of using at that point in time. IPv6 resources are easy to get: when they decide to deploy IPv6 it is easy for them to get the necessary resources at that point. And they will probably also know better what to request. I wonder how many LIRs have just requested an IPv6 /32 without thinking because they only needed to go through the motions to get an IPv4 /22. Cheers, Sander From sander at steffann.nl Wed Oct 15 11:36:34 2014 From: sander at steffann.nl (Sander Steffann) Date: Wed, 15 Oct 2014 11:36:34 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543E3CEF.1050403@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <543E3CEF.1050403@tvt-datos.es> Message-ID: Hi, > There is a little conflict as private networks can work with private space, but public ones cant. You are assuming something which isn't true: not all private networks can run on RFC1918 space (for various reasons that I tried to explain in my previous email). But this is getting off-topic for this thread, which is about "Relaxing IPv6 Requirement for Receiving Space from the Final /8". Cheers, Sander From tore at fud.no Wed Oct 15 12:15:14 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 15 Oct 2014 12:15:14 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <5435BD43.6010104@inex.ie> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> Message-ID: <543E4932.9060202@fud.no> * Nick Hilliard > I would kindly suggest either dropping the ipv6 requirement completely from > the last /8 policy I'd support such a policy proposal. Tore From gert at space.net Wed Oct 15 15:38:52 2014 From: gert at space.net (Gert Doering) Date: Wed, 15 Oct 2014 15:38:52 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543E4704.1090509@tvt-datos.es> References: <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> <20141013174342.GE31092@Space.Net> <543E3B68.9040300@tvt-datos.es> <20141015092301.GK31092@Space.Net> <543E4704.1090509@tvt-datos.es> Message-ID: <20141015133852.GN31092@Space.Net> Hi, On Wed, Oct 15, 2014 at 12:05:56PM +0200, Daniel Baeza (Red y Sistemas TVT) wrote: > >> Allocations will only be made to LIRs if the have already received and > >> IPv6 PI or PA from another LIR, RIPE NCC or other RIR. (Please, dont > >> just read literally as my english is not very good. Try to read what I > >> want to transmit) > > > > But that's basically back to "window dressing" - acquiring an IPv6 network > > is trivial, but if someone does not want to deploy IPv6, it will not make > > him. > > Sorry, cant understand what you mean. Let me try to explain again. Such a policy would make the applicant request an IPv6 network block, yes. But will it make a difference for their IPv6 *deployment*? If they already plan to deploy, there's no extra incentive - and if they are not deploying IPv6, requesting an address and putting it into a drawer won't make a difference for their IPv6 deployment either. As Jim said upthread: this is window dressing, as in "it looks nice" - but it will not actually achieve what we want ("further IPv6 deployment"). [..] > > If we have a clause in the policy that is there to achieve something, but > > doesn't do so, and the policy without the clause is easier to understand > > and implement, this is definitely preferred. > > If the clause in the policy dont change the way the policy is, and make > easier to understand and implement, for sure is preferred. If the clause > is "core" and without it the policy completely changes, only to make is > easier I do not agree with that. The "core" of this policy is "define IPv4 /22 distribution", not "IPv6". The IPv6 clause was put there to give an incentive for IPv6 deployment, but it turns out that it is not effective in most cases, and harmful in others, so that clause has not met its purpose. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From nigel at titley.com Wed Oct 15 16:21:51 2014 From: nigel at titley.com (Nigel Titley) Date: Wed, 15 Oct 2014 15:21:51 +0100 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <543E2C04.8060402@fud.no> References: <543C2B12.5080306@fud.no> <543E2C04.8060402@fud.no> Message-ID: <543E82FF.9040600@titley.com> On 15/10/14 09:10, Tore Anderson wrote: > * Tore Anderson > >> 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. > 2) Assuming the previous point is handled, there is an additional > concern that if 2014-05 passes, it will cause ARIN to declare that > APNIC's policy is no longer compatible. It wasn't entirely clear to me > if they though this would happen instantaneously (by ARIN-the-RIR, not > the community), or if they were worried that the ARIN community would > react by changing their policies to make them incompatible. > > - The instantaneous alternative does strike me as somewhat far fetched, > considering that ARIN has already deemed APNIC's policy to be > ?reciprocal, compatible, needs-based?, and the fact that 2014-05 doesn't > change a single word in neither ARIN's nor APNIC's policy documents. > That said, obviously I can't know for certain if 2014-04 could possibly > cause such an instantaneous change in how ARIN interprets APNIC's policy > text. Maybe John could chime in? > > - The other alternative, where 2014-05's passing would prompt the ARIN > community to change their policy document so that APNIC<->ARIN transfers > are no longer possible, does seems more plausible, yet somewhat > speculative as we have no idea whether the ARIN community cares about > 2014-05 at all and if so what they think about it. > > Another possibility, which was suggested by one commentator, is that the > APNIC community preempts such an ARIN policy change, by changing their > own policy instead (if they feel it is necessary in order to keep the > ARIN community happy that is). > Just for information, at the recent ARIN meeting last week, John Curran stated that the adoption of 2014-05 would *not* impair the ability of LIRs to transfer address space from ARIN to APNIC and thence to RIPE NCC. Nigel From jcurran at arin.net Wed Oct 15 16:48:00 2014 From: jcurran at arin.net (John Curran) Date: Wed, 15 Oct 2014 14:48:00 +0000 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: <543E2C04.8060402@fud.no> References: <543C2B12.5080306@fud.no> <543E2C04.8060402@fud.no> Message-ID: On Oct 15, 2014, at 1:10 AM, Tore Anderson wrote: > ... > 2) Assuming the previous point is handled, there is an additional > concern that if 2014-05 passes, it will cause ARIN to declare that > APNIC's policy is no longer compatible. It wasn't entirely clear to me > if they though this would happen instantaneously (by ARIN-the-RIR, not > the community), or if they were worried that the ARIN community would > react by changing their policies to make them incompatible. > > - The instantaneous alternative does strike me as somewhat far fetched, > considering that ARIN has already deemed APNIC's policy to be > ?reciprocal, compatible, needs-based?, and the fact that 2014-05 doesn't > change a single word in neither ARIN's nor APNIC's policy documents. > That said, obviously I can't know for certain if 2014-04 could possibly > cause such an instantaneous change in how ARIN interprets APNIC's policy > text. Maybe John could chime in? Per , section "Compatibility with other RIRs" - >... > The following statement has been received from APNIC and ARIN: > > ?After consulting with both ARIN and APNIC, the two RIRs have confirmed how > ARIN policy requires ?needs based?, explicitly stated, policy principals to > be in place to allow for inter-RIR resource transfers, and that APNIC?s has > the same needs based principles explicitly stated in its policy document. > RIPE policy document ripe-622 (paragraph 5.1, sub 3), addresses a needs base > in an implicit manner. It is therefore not possible for the APNIC secretariat > to interpret this and take a position. The APNIC secretariat indicates that > it will consult their community in order to get guidance on how to proceed. > ARIN staff notes that the lack of a specific needs-based requirement in the > RIPE policy document will prevent the policy from being deemed compatible > with ARIN's Inter-RIR transfer policy requirements to the RIPE region > (although its adoption will have no effect on Inter-RIR transfers between > ARIN and the APNIC region.)? > - The other alternative, where 2014-05's passing would prompt the ARIN > community to change their policy document so that APNIC<->ARIN transfers > are no longer possible, does seems more plausible, yet somewhat > speculative as we have no idea whether the ARIN community cares about > 2014-05 at all and if so what they think about it. Indeterminate. The existence of RIPE 2014-05 was raised last week during the ARIN 34 meeting, and I noted the ARIN staff determination on this matter (that APNIC's inter-RIR transfer policy remains compatible with ARIN policy if RIPE 2014-05 is adopted by the RIPE community.) The ARIN community is aware that they would need to propose some change to ARIN's Inter-RIR transfer policy if another outcome is desired. FYI, /John John Curran President and CEO ARIN p.s. The RIPE and APNIC RIR policy development staff should be thanked for their foresight in researching this topic in advance, and arranging for the very coherent "Compatibility with other RIRs" section in the RIPE 2014-05 Impact Analysis... thanks! :-) From sandrabrown at ipv4marketgroup.com Wed Oct 15 18:01:43 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Wed, 15 Oct 2014 09:01:43 -0700 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) Message-ID: <20141015090143.ec289651d84890fcbef5f195936e1217.ff24ae548e.wbe@email17.secureserver.net> >>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 From springer at inlandnet.com Wed Oct 15 18:49:10 2014 From: springer at inlandnet.com (John Springer) Date: Wed, 15 Oct 2014 09:49:10 -0700 (PDT) Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <20141015090143.ec289651d84890fcbef5f195936e1217.ff24ae548e.wbe@email17.secureserver.net> References: <20141015090143.ec289651d84890fcbef5f195936e1217.ff24ae548e.wbe@email17.secureserver.net> Message-ID: Hi Sandra, On Wed, 15 Oct 2014, sandrabrown at ipv4marketgroup.com wrote: > > 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. Well, a conversation has been and is taking place. There is an ARIN Draft Policy (ARIN-2014-14) that proposes this. The phrase "ARIN34 seemed to be pushing" works fine as optimism, but may suggest progress that, IMHO, has not yet been made. At best, feedback on the matter seems deeply polarized. John Springer Primary shepherd for 2014-14, and NOT speaking for ARIN, ARIN34, the ARIN AC or anybody besides myself >>> 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 > > > > > > From tore at fud.no Wed Oct 15 20:46:36 2014 From: tore at fud.no (Tore Anderson) Date: Wed, 15 Oct 2014 20:46:36 +0200 Subject: [address-policy-wg] 2014-05 New Draft Document and Impact Analysis Published (Policy for Inter-RIR Transfers of Internet Resources) In-Reply-To: References: <543C2B12.5080306@fud.no> <543E2C04.8060402@fud.no> Message-ID: <543EC10C.8050704@fud.no> Hi John, > Per e >> [...] (although its adoption will have no effect on Inter-RIR >> transfers between ARIN and the APNIC region.)? There it is indeed, black on white. Thank you for pointing out my poor short time memory. :-) I suppose that the reason why this was being brought up as a possible problem at the APNIC meeting was that this clarification had not yet been made at that point. > The existence of RIPE 2014-05 was raised last week during the ARIN 34 > meeting, and I noted the ARIN staff determination on this matter > (that APNIC's inter-RIR transfer policy remains compatible with ARIN > policy if RIPE 2014-05 is adopted by the RIPE community.) The ARIN > community is aware that they would need to propose some change to > ARIN's Inter-RIR transfer policy if another outcome is desired. Ack. This is reasonable and what I would expect. I would find it interesting to watch this discussion from the ARIN 34 meeting, hopefully recordings from it will be made available at some point. > p.s. The RIPE and APNIC RIR policy development staff should be > thanked for their foresight in researching this topic in advance, and > arranging for the very coherent "Compatibility with other RIRs" > section in the RIPE 2014-05 Impact Analysis... thanks! :-) Indeed, it is important to know if the new policy is going to work at all before adopting it. Not much point in doing it if not... I guess what remains to be done with 2014-05 in this regard, is to clarify it so that APNIC (or any other RIR for that matter) realises that its language isn't meant to cause a "policy loop", but rather to be accommodating to RIR communities that would like to explicitly insist that a out of region transfer source/destination entity must be invariably subjected to a certain set of conditions (which are not necessarily duplicated in the policies of the region of the aforementioned entity). Tore From richih.mailinglist at gmail.com Thu Oct 16 15:08:24 2014 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 16 Oct 2014 15:08:24 +0200 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543BF3C9.4090501@tvt-datos.es> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <20141010192059.GB31092@Space.Net> <2F603004-9069-4D0A-B042-6B8AE2D04C3D@a2b-internet.com> <543B870D.2010609@tvt-datos.es> <543BF3C9.4090501@tvt-datos.es> Message-ID: On Mon, Oct 13, 2014 at 5:46 PM, Daniel Baeza (Red y Sistemas TVT) wrote: > Easy. The current IPv6 deploy makes me cry like a little girl. https://www.youtube.com/watch?v=XjJQBjWYDTs > NOBODY (as > percentage) is deploying it in their customer/backone/whatever network. This is not true. > If we want to migrate from v4 to v6, some drastic changes should be made. Like only handing out /22 any more? > One of them, requiring the v6 to be publicly visible if you want to have the > last /22. This is not something that will drive v6 adoption. It's laughably easy to get around this requirement. For Gert's benefit: I am fine with removing and/or softening this requirement. Richard From ebais at a2b-internet.com Thu Oct 16 18:17:23 2014 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 16 Oct 2014 18:17:23 +0200 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <20141015090143.ec289651d84890fcbef5f195936e1217.ff24ae548e.wbe@email17.secureserver.net> References: <20141015090143.ec289651d84890fcbef5f195936e1217.ff24ae548e.wbe@email17.secureserver.net> Message-ID: <018601cfe95c$af04e3b0$0d0eab10$@a2b-internet.com> Hi Sandra, > 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 ... > 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. Regards, Erik Bais From mschmidt at ripe.net Fri Oct 17 10:19:33 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 17 Oct 2014 10:19:33 +0200 Subject: [address-policy-wg] RIPE 68 Address Policy WG Draft Minutes Message-ID: <5440D115.9020401@ripe.net> 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 From sandrabrown at ipv4marketgroup.com Fri Oct 17 17:29:00 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Fri, 17 Oct 2014 08:29:00 -0700 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) Message-ID: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> 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 From jcurran at arin.net Sat Oct 18 02:02:18 2014 From: jcurran at arin.net (John Curran) Date: Sat, 18 Oct 2014 00:02:18 +0000 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> Message-ID: On Oct 17, 2014, at 8:29 AM, sandrabrown at ipv4marketgroup.com wrote: > > 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. Sandra - The assessment of RIPE 2014-05 for compatibility is based on the very first sentence of the section 8.4 (Inter-RIR Transfer) of the ARIN Number Resource Policy Manual - "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." The requirement is quite specific, in that ARIN can only to transfers to RIRs which share _policies_ which are compatible and needs-based. I do understand that adoption and implementation of RIPE 2014-05 may result in some form of operational processes which meet this criteria, but the policy itself must be explicitly needs-based and would not be as presently proposed. The goal of RIPE 2014-05 is laudable, in that the proposed policy text seeks to meet the requirements of any other RIR with amazing level of brevity. Unfortunately, it is lacks any needs-based specific criteria and thus it is not explicitly compatible with respect to Inter-RIR transfers from the ARIN region per our community-developed policy. Given that the intention of the RIPE 2014-05 proposal is to be compatible with ARIN's Inter-RIR transfer policy (including needs-based requirement), and it is just the lack of specificity in the proposed policy text which is problematic, would it be worth considering changing your very streamlined policy text to make the needs-basis requirement explicit for transfers from region that requiring such? This could be as simple as adding a policy statement to the effect of: "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) I recognize that having to place such a statement in your proposed policy text detracts from its present elegance, but this may be a situation where a less refined approach is warranted so that maximum compatibility can be achieved to the benefit of all IP address users. If this suggestion is not of interest, please disregard. If you have any questions of the above, I'd be happy to answer them either on-list or privately as you prefer. Best wishes, /John John Curran President and CEO ARIN p.s. Regardless of outcome, I will also report back to the ARIN community about how the current NRPM 8.4 policy text places requirements on other RIR's policy text, and to consider the merits and concerns when compared to other approaches, e.g. putting any Inter-RIR recipient requirements (to extend deemed necessary at all) in ARIN's policy text instead. FYI,/John From dcunningham at airspeed.ie Mon Oct 20 11:41:52 2014 From: dcunningham at airspeed.ie (Donal Cunningham) Date: Mon, 20 Oct 2014 09:41:52 +0000 Subject: [address-policy-wg] 2014-04 New Draft Document and Impact Analysis Published (Relaxing IPv6 Requirement for Receiving Space from the Final /8) In-Reply-To: <543E4932.9060202@fud.no> References: <20140731114101.2BC3D6087A@mobil.space.net> <20140825184753.GA15964@Space.Net> <53FB8A3D.9050403@inex.ie> <540D1D91.1060509@ssd.axu.tm> <540DC8BC.5090602@inex.ie> <54112C3A.1000501@ssd.axu.tm> <5411974E.7080009@inex.ie> <20140919113127.3590d567@fizzix> <5435BD43.6010104@inex.ie> <543E4932.9060202@fud.no> Message-ID: >> I would kindly suggest either dropping the ipv6 requirement completely >> from the last /8 policy > I'd support such a policy proposal. As would I. It's tickyboxitis. D. Airspeed Telecom From ipaddman at bt.com Tue Oct 21 15:46:16 2014 From: ipaddman at bt.com (ipaddman at bt.com) Date: Tue, 21 Oct 2014 14:46:16 +0100 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> Message-ID: Hi all, I support the goals of 2014-15, the suggestion below seems to be a practical solution, if acceptable to all parties. Best regards, Steve Wright BTnet This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of John Curran Sent: 18 October 2014 01:02 To: sandrabrown at ipv4marketgroup.com Cc: Tore Anderson; Erik Bais; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) On Oct 17, 2014, at 8:29 AM, sandrabrown at ipv4marketgroup.com wrote: > > 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. Sandra - The assessment of RIPE 2014-05 for compatibility is based on the very first sentence of the section 8.4 (Inter-RIR Transfer) of the ARIN Number Resource Policy Manual - "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." The requirement is quite specific, in that ARIN can only to transfers to RIRs which share _policies_ which are compatible and needs-based. I do understand that adoption and implementation of RIPE 2014-05 may result in some form of operational processes which meet this criteria, but the policy itself must be explicitly needs-based and would not be as presently proposed. The goal of RIPE 2014-05 is laudable, in that the proposed policy text seeks to meet the requirements of any other RIR with amazing level of brevity. Unfortunately, it is lacks any needs-based specific criteria and thus it is not explicitly compatible with respect to Inter-RIR transfers from the ARIN region per our community-developed policy. Given that the intention of the RIPE 2014-05 proposal is to be compatible with ARIN's Inter-RIR transfer policy (including needs-based requirement), and it is just the lack of specificity in the proposed policy text which is problematic, would it be worth considering changing your very streamlined policy text to make the needs-basis requirement explicit for transfers from region that requiring such? This could be as simple as adding a policy statement to the effect of: "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) I recognize that having to place such a statement in your proposed policy text detracts from its present elegance, but this may be a situation where a less refined approach is warranted so that maximum compatibility can be achieved to the benefit of all IP address users. If this suggestion is not of interest, please disregard. If you have any questions of the above, I'd be happy to answer them either on-list or privately as you prefer. Best wishes, /John John Curran President and CEO ARIN p.s. Regardless of outcome, I will also report back to the ARIN community about how the current NRPM 8.4 policy text places requirements on other RIR's policy text, and to consider the merits and concerns when compared to other approaches, e.g. putting any Inter-RIR recipient requirements (to extend deemed necessary at all) in ARIN's policy text instead. FYI,/John From tore at fud.no Tue Oct 21 16:28:47 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 21 Oct 2014 16:28:47 +0200 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> Message-ID: <54466D9F.2040404@fud.no> * steve.r.wright at 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...) From jcurran at arin.net Tue Oct 21 17:13:50 2014 From: jcurran at arin.net (John Curran) Date: Tue, 21 Oct 2014 15:13:50 +0000 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <54466D9F.2040404@fud.no> References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> <54466D9F.2040404@fud.no> Message-ID: On Oct 21, 2014, at 10:28 AM, Tore Anderson wrote: > > * steve.r.wright at 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 wanted to make that this community understood the reason for the incompatibility, since it did not appear to be a mismatch in actual policy intent. Glad it was helpful. > I have some comments on your suggested text, though: > ... > 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. To be clear, ARIN policy for inter-RIR transfers does not require any specific need period - my text was solely to be an example. There must be policy text that refers to needs-based (i.e. some operational need for the address space), but any change in ARIN's policy for transfers within the ARIN region should not require a change to RIPE policy for needs-based compatibility in any circumstance. > 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. Once the RIPE Inter-RIR transfer policy is determined to be needs-based and compatible, then processing of individual requests can easily be handled by RIPE NCC without any need for sharing of requesters information with other parties. This works quite well quite Inter-RIR transfers between APNIC and the ARIN region today, whereas there are likely to be potential implementation issues with your proposed approach that would need to be carefully explored; for example, ARIN has no relationship to a requestor in the RIPE region, no non-disclosure agreement, etc. > 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. I believe that all of the RIRs must rely on each other for faithful implementation of policy, but again, this has not been a problem for other Inter-RIR transfers to/from the ARIN region. FYI, /John John Curran President and CEO ARIN From tore at fud.no Tue Oct 21 17:39:16 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 21 Oct 2014 17:39:16 +0200 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> <54466D9F.2040404@fud.no> Message-ID: <54467E24.2030303@fud.no> Hi John, * John Curran > On Oct 21, 2014, at 10:28 AM, Tore Anderson wrote: >> 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. > > To be clear, ARIN policy for inter-RIR transfers does not require any > specific need period - my text was solely to be an example. There must > be policy text that refers to needs-based (i.e. some operational need > for the address space), but any change in ARIN's policy for transfers > within the ARIN region should not require a change to RIPE policy for > needs-based compatibility in any circumstance. Really? I would have thought that the periods would need to be the same for the policies to be compatible. Otherwise, we could have set a ridiculously long period like 1000 years. Even if it that would be compatible with the letter of the ARIN policy I highly doubt it would be compatible with the spirit. :-) By ensuring identical periods are used, there can be no argument that differing periods cause incompatibility or any form of loopholes. Maybe that's not a concern for compatibility with ARIN today, but it might be tomorrow with another RIR. In any case, it shouldn't hurt compatibility with ARIN's policy, right? >> 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. > > Once the RIPE Inter-RIR transfer policy is determined to be needs-based and > compatible, then processing of individual requests can easily be handled by > RIPE NCC without any need for sharing of requesters information with other > parties. This works quite well quite Inter-RIR transfers between APNIC and > the ARIN region today, whereas there are likely to be potential implementation > issues with your proposed approach that would need to be carefully explored; > for example, ARIN has no relationship to a requestor in the RIPE region, no > non-disclosure agreement, etc. Good point about the NDA. You're right, let's not go there. Then I have: ?For transfers from RIR regions which require the RIPE region to have needs-based policies, recipients must provide a plan to the RIPE NCC for the use of the transferred resource within the time period defined by the transfer policy of the other RIR?. Like I said before, it would be good to have an indication from you or another ARIN official on whether or not this would indeed be deemed as compatible with ARIN's inter-region transfer policy. That way, hopefully this WG won't have to do too many iterations of 2014-05 before settling on a piece of text that works for everyone involved. >> 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. > > I believe that all of the RIRs must rely on each other for faithful > implementation of policy, but again, this has not been a problem for > other Inter-RIR transfers to/from the ARIN region. I was not really referring to ARIN-the-RIR here, but rather individuals participating in the ARIN community, who might end up with an impression (misguided or not) that the starving RIPE region ISPs are looting ARIN's fat IPv4 stores while the RIPE NCC looks the other way... Tore From jcurran at arin.net Tue Oct 21 18:19:21 2014 From: jcurran at arin.net (John Curran) Date: Tue, 21 Oct 2014 16:19:21 +0000 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <54467E24.2030303@fud.no> References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> <54466D9F.2040404@fud.no> <54467E24.2030303@fud.no> Message-ID: <75847DC6-627D-4363-9122-AA108D24DD37@arin.net> On Oct 21, 2014, at 11:39 AM, Tore Anderson wrote: >> >> To be clear, ARIN policy for inter-RIR transfers does not require any >> specific need period - my text was solely to be an example. There must >> be policy text that refers to needs-based (i.e. some operational need >> for the address space), but any change in ARIN's policy for transfers >> within the ARIN region should not require a change to RIPE policy for >> needs-based compatibility in any circumstance. > > Really? I would have thought that the periods would need to be the same > for the policies to be compatible. Otherwise, we could have set a > ridiculously long period like 1000 years. Even if it that would be > compatible with the letter of the ARIN policy I highly doubt it would be > compatible with the spirit. :-) I imagine that ARIN community would propose a policy change in the face of such antics, but ARIN's existing Inter-RIR transfer policy language is intentionally not proscriptive in this regard. > By ensuring identical periods are used, there can be no argument that > differing periods cause incompatibility or any form of loopholes. Maybe > that's not a concern for compatibility with ARIN today, but it might be > tomorrow with another RIR. In any case, it shouldn't hurt compatibility > with ARIN's policy, right? Actually, that is not clear, as ARIN's Inter-RIR transfer policy language requires that an RIR have needs-based policy in order to be compatible for transfers to/from ARIN, and having solely a reference to the another RIR's policy could be argued (by some) to not be actual needs-based policy for RIPE. Specific needs-based language in RIPE's policy would be much cleaner, as well as having RIPE NCC implementing something defined by the RIPE community rather than criteria that may change at any time without RIPE community involvement. >> Once the RIPE Inter-RIR transfer policy is determined to be needs-based and >> compatible, then processing of individual requests can easily be handled by >> RIPE NCC without any need for sharing of requesters information with other >> parties. This works quite well quite Inter-RIR transfers between APNIC and >> the ARIN region today, whereas there are likely to be potential implementation >> issues with your proposed approach that would need to be carefully explored; >> for example, ARIN has no relationship to a requestor in the RIPE region, no >> non-disclosure agreement, etc. > > Good point about the NDA. You're right, let's not go there. Indeed, a tad messy... > Then I have: > > ?For transfers from RIR regions which require the RIPE region to have > needs-based policies, recipients must provide a plan to the RIPE NCC for > the use of the transferred resource within the time period defined by > the transfer policy of the other RIR?. > > Like I said before, it would be good to have an indication from you or > another ARIN official on whether or not this would indeed be deemed as > compatible with ARIN's inter-region transfer policy. That way, hopefully > this WG won't have to do too many iterations of 2014-05 before settling > on a piece of text that works for everyone involved. Even noting the consideration noted above, I do believe your proposed text above to be compatible, needs-based policy for purposes of ARIN's NRPM 8.4 Inter-RIR transfers. Thanks, /John John Curran President and CEO ARIN From tore at fud.no Tue Oct 21 20:58:52 2014 From: tore at fud.no (Tore Anderson) Date: Tue, 21 Oct 2014 20:58:52 +0200 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <75847DC6-627D-4363-9122-AA108D24DD37@arin.net> References: <20141017082900.ec289651d84890fcbef5f195936e1217.8cc6ddd932.wbe@email17.secureserver.net> <54466D9F.2040404@fud.no> <54467E24.2030303@fud.no> <75847DC6-627D-4363-9122-AA108D24DD37@arin.net> Message-ID: <5446ACEC.6000807@fud.no> Hi, * John Curran > Actually, that is not clear, as ARIN's Inter-RIR transfer policy language > requires that an RIR have needs-based policy in order to be compatible for > transfers to/from ARIN, and having solely a reference to the another RIR's > policy could be argued (by some) to not be actual needs-based policy for > RIPE. I see. > Specific needs-based language in RIPE's policy would be much cleaner, as > well as having RIPE NCC implementing something defined by the RIPE community > rather than criteria that may change at any time without RIPE community > involvement. Another issue that could hypothetically arise from having a hard-coded 24 month limit is if the ARIN community increases their limit. Considering that the purpose of adding the limit to 2014-05 in the first place is only be to appease the ARIN community, it would be an odd outcome if 2014-05 ends up being more strict than ARIN's policy (even if this situation only lasts for the policy cycle necessary for us to catch up with you). So, perhaps it would be better with something like ?within 24 months or the corresponding period defined in the transfer policy of the other RIR, whichever is greater?? >> ?For transfers from RIR regions which require the RIPE region to have >> needs-based policies, recipients must provide a plan to the RIPE NCC for >> the use of the transferred resource within the time period defined by >> the transfer policy of the other RIR?. > > Even noting the consideration noted above, I do believe your proposed text > above to be compatible, needs-based policy for purposes of ARIN's NRPM 8.4 > Inter-RIR transfers. Excellent. Thank you! Tore From sandrabrown at ipv4marketgroup.com Tue Oct 21 21:03:31 2014 From: sandrabrown at ipv4marketgroup.com (sandrabrown at ipv4marketgroup.com) Date: Tue, 21 Oct 2014 12:03:31 -0700 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) Message-ID: <20141021120331.ec289651d84890fcbef5f195936e1217.68f66460d5.wbe@email17.secureserver.net> Hi John, Tore, and Steve, Thanks for your excellent dialog to seek compatibility between the ARIN and RIPE inter-RIR transfer policies. >>Actually, that is not clear, as ARIN's Inter-RIR transfer policy language >>requires that an RIR have needs-based policy in order to be compatible for >>transfers to/from ARIN, and having solely a reference to the another RIR's >>policy could be argued (by some) to not be actual needs-based policy for >>RIPE. >>Specific needs-based language in RIPE's policy would be much cleaner, as >>well as having RIPE NCC implementing something defined by the RIPE community >>rather than criteria that may change at any time without RIPE community >>involvement. Understood, the requirement is for needs based language specifically in the RIPE policy, that is independent of the other RIR's policy. How about: "For transfers from RIR regions which require the RIPE region to have needs-based policies, recipients must provide a plan to the RIPE NCC for the use of at least 50% of the transferred resources within 5 years." Is this a needs based policy that is compatible with ARIN's requirement? Thanks Sandra From jcurran at arin.net Tue Oct 21 21:28:18 2014 From: jcurran at arin.net (John Curran) Date: Tue, 21 Oct 2014 19:28:18 +0000 Subject: [address-policy-wg] [policy-announce]2014-05 New Draft Document and ImpactAnalysis Published (Policy for Inter-RIR Transfers of InternetResources) (Erik Bais) In-Reply-To: <20141021120331.ec289651d84890fcbef5f195936e1217.68f66460d5.wbe@email17.secureserver.net> References: <20141021120331.ec289651d84890fcbef5f195936e1217.68f66460d5.wbe@email17.secureserver.net> Message-ID: <8913F354-8CCE-4684-8C6B-C41AF0467E3D@arin.net> On Oct 21, 2014, at 3:03 PM, sandrabrown at ipv4marketgroup.com wrote: > ... > > How about: > > "For transfers from RIR regions which require the RIPE region to have > needs-based policies, > recipients must provide a plan to the RIPE NCC for the use of at least > 50% of the transferred > resources within 5 years." > > Is this a needs based policy that is compatible with ARIN's requirement? Yes - any policy text which 'requires the recipient to have operational need for the address space, and to demonstrate that need to their RIR for transfer approval' is deemed a "compatible, needs-based" policy [1]. The specific criteria on recipients should be that which the RIPE community feels is appropriate for its region. FYI, /John John Curran President and CEO ARIN [1] As per the staff assessment of ARIN Draft Policy 2011-1 (NRPM 8.3) Dear colleagues, Later today, we will publish five policy proposals on the Address Policy Working Group Mailing List. We wanted to let you know in advance what these are about. In the Address Policy WG sessions at RIPE 67 and RIPE 68, it was discussed that the language in several RIPE Documents should be improved by changing instances of ?should? to ?must? where this was creating unwanted ambiguity. You can find more information here: https://ripe68.ripe.net/presentations/288-APWG-co-presentation-should.pdf After receiving guidance from the RIPE community, RIPE NCC has decided to start the process to clarify the language in these RIPE Documents by submitting these proposals into the PDP. For clarity, and as instructed by the community, there will be one proposal per RIPE Document. If you wish to provide your feedback to a specific proposed change, please make sure that you reply to the appropriate announcement and thread. Kind regards Marco Schmidt Policy Development Officer RIPE NCC From gert at Space.Net Thu Oct 23 14:54:50 2014 From: gert at Space.Net (Gert Doering) Date: Thu, 23 Oct 2014 14:54:50 +0200 Subject: [address-policy-wg] APWG Agenda for RIPE 69 - draft 1 Message-ID: <20141023125450.GA50180@Space.Net> Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in London in the following time slots: Wednesday, Nov 5, 09:00 - 10:30 Wednesday, Nov 5, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. The distribution of items to the two timeslot is somewhat subject to the time spent on discussion - but we'll try to stick to what's published. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection Process - presenting the current draft document - discussion C. Current Policy Topics - Marco Schmidt, NCC PDO - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE67 2014-02 Allow IPv4 PI transfer (consensus, policy) 2014-01 Abandoning the Minimum Allocation Size for IPv4 (consensus, policy) 2012-02 Policy for Inter-RIR transfers of IPv4 address space (withdrawn, replaced by 2014-05) - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima (NCC RS) (+ discussion with the group) F. Discussion of open policy proposals 2014-03 Remove Multihoming Requirement for AS Number .. (Job Snijders) 2014-04 relax IPv6 requirement for allocations from last /8 (Martin Pels) [some bits might get moved to "after coffee break" if we run out of time] ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals 2014-05 Policy for Inter-RIR Transfer of Internet Resources (Sandra Brown) 2014-07 2014-08 2014-09 2014-10 2014-11 "SHOULD" and "MUST" in the policy text (Andrea Cima, from the NCC RS, in response to the request from the WG at RIPE 68, one proposal per occurance) N.N. Transfer Policy for AS Numbers (Erik Bais) N.N. Transfer Policy for IPv6 Allocations (Erik Bais) Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." Z. AOB -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mschmidt at ripe.net Thu Oct 23 15:05:54 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Oct 2014 15:05:54 +0200 Subject: 2014-07 New Policy Proposal (Language Clarification in “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region”) Message-ID: Dear colleagues, A proposed change to RIPE Document "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-07 We encourage you to review this proposal and send your comments to before 21 November 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Oct 23 15:15:24 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Oct 2014 15:15:24 +0200 Subject: 2014-08 New Policy Proposal (Language Clarification in “Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region”) Message-ID: Dear colleagues, A proposed change to RIPE Document "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-08 We encourage you to review this proposal and send your comments to before 21 November 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Oct 23 15:28:06 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Oct 2014 15:28:06 +0200 Subject: 2014-09 New Policy Proposal (Language Clarification in “IPv6 Address Space Policy For Internet Exchange Points”) Message-ID: Dear colleagues, A proposed change to RIPE Document IPv6 Address Space Policy For Internet Exchange Points is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-09 We encourage you to review this proposal and send your comments to before 21 November 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Oct 23 15:37:23 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Oct 2014 15:37:23 +0200 Subject: 2014-10 New Policy Proposal (Language Clarification in “IPv6 Addresses for Internet Root Servers In The RIPE Region”) Message-ID: Dear colleagues, A proposed change to RIPE Document "IPv6 Addresses for Internet Root Servers In The RIPE Region" is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-10 We encourage you to review this proposal and send your comments to before 21 November 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From mschmidt at ripe.net Thu Oct 23 15:45:36 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 23 Oct 2014 15:45:36 +0200 Subject: 2014-11 New Policy Proposal (Language Clarification for “Allocating/Assigning Resources to the RIPE NCC”) Message-ID: Dear colleagues, A proposed change to RIPE Document "Allocating/Assigning Resources to the RIPE NCC" is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2014-11 We encourage you to review this proposal and send your comments to before 21 November 2014. Regards, Marco Schmidt Policy Development Officer RIPE NCC From james.blessing at despres.co.uk Thu Oct 23 17:09:12 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 23 Oct 2014 16:09:12 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-11_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_for_=E2=80=9CAllocating/Assigning_Res?= =?utf-8?q?ources_to_the_RIPE_NCC=E2=80=9D=29?= In-Reply-To: <544916ff.c49dc20a.62d6.54c1SMTPIN_ADDED_MISSING@mx.google.com> References: <544916ff.c49dc20a.62d6.54c1SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 23 October 2014 14:45, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "Allocating/Assigning Resources > to the RIPE NCC" is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-11 > > We encourage you to review this proposal and send your comments to > before 21 November 2014. Support J -- James Blessing 07989 039 476 From james.blessing at despres.co.uk Thu Oct 23 17:10:29 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 23 Oct 2014 16:10:29 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-07_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv4_Address_Allocation_a?= =?utf-8?q?nd_Assignment_Policies_for_the_RIPE_NCC_Service_Region?= =?utf-8?b?4oCdKQ==?= In-Reply-To: <544916ff.a650c20a.47a1.4610SMTPIN_ADDED_MISSING@mx.google.com> References: <544916ff.a650c20a.47a1.4610SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 23 October 2014 14:05, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region" is now available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-07 > Support J -- James Blessing 07989 039 476 From james.blessing at despres.co.uk Thu Oct 23 17:13:12 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 23 Oct 2014 16:13:12 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-09_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv6_Address_Space_Policy?= =?utf-8?q?_For_Internet_Exchange_Points=E2=80=9D=29?= In-Reply-To: <544916ff.e40bb50a.3945.ffffc30fSMTPIN_ADDED_MISSING@mx.google.com> References: <544916ff.e40bb50a.3945.ffffc30fSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 23 October 2014 14:28, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document IPv6 Address Space Policy For > Internet Exchange Points is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-09 > Support J -- James Blessing 07989 039 476 From james.blessing at despres.co.uk Thu Oct 23 17:14:38 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 23 Oct 2014 16:14:38 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-08_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CContractual_Requirements_?= =?utf-8?q?for_Provider_Independent_Resource_Holders_in_the_RIPE_NC?= =?utf-8?q?C_Service_Region=E2=80=9D=29?= In-Reply-To: <544916ff.3324b40a.0145.02acSMTPIN_ADDED_MISSING@mx.google.com> References: <544916ff.3324b40a.0145.02acSMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 23 October 2014 14:15, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "Contractual Requirements for Provider > Independent Resource Holders in the RIPE NCC Service Region" is now available > for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-08 > Support J -- James Blessing 07989 039 476 From james.blessing at despres.co.uk Thu Oct 23 17:19:35 2014 From: james.blessing at despres.co.uk (James Blessing) Date: Thu, 23 Oct 2014 16:19:35 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-10_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv6_Addresses_for_Intern?= =?utf-8?q?et_Root_Servers_In_The_RIPE_Region=E2=80=9D=29?= In-Reply-To: <544916ff.a762b40a.65ff.ffffaa28SMTPIN_ADDED_MISSING@mx.google.com> References: <544916ff.a762b40a.65ff.ffffaa28SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On 23 October 2014 14:37, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "IPv6 Addresses for Internet > Root Servers In The RIPE Region" is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-10 > Support J -- James Blessing 07989 039 476 From nick at inex.ie Thu Oct 23 21:15:27 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 23 Oct 2014 20:15:27 +0100 Subject: [address-policy-wg] Five Policy Proposals to Improve RIPE Documents In-Reply-To: <5448E2AD.3000104@ripe.net> References: <5448E2AD.3000104@ripe.net> Message-ID: <544953CF.8040107@inex.ie> On 23/10/2014 12:12, Marco Schmidt wrote: > Later today, we will publish five policy proposals on the Address Policy > Working Group Mailing List. We wanted to let you know in advance what these > are about. 2014-07: support. 2014-08: support. 2014-09: don't support. 2014-10: support. 2014-11: support. Nick From job at instituut.net Thu Oct 23 21:18:26 2014 From: job at instituut.net (Job Snijders) Date: Thu, 23 Oct 2014 21:18:26 +0200 Subject: [address-policy-wg] Five Policy Proposals to Improve RIPE Documents In-Reply-To: <544953CF.8040107@inex.ie> References: <5448E2AD.3000104@ripe.net> <544953CF.8040107@inex.ie> Message-ID: <20141023191826.GH759@Vurt.local> On Thu, Oct 23, 2014 at 08:15:27PM +0100, Nick Hilliard wrote: > On 23/10/2014 12:12, Marco Schmidt wrote: > > Later today, we will publish five policy proposals on the Address Policy > > Working Group Mailing List. We wanted to let you know in advance what these > > are about. > > 2014-09: don't support. Why? Kind regards, Job From nick at inex.ie Thu Oct 23 21:53:23 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 23 Oct 2014 20:53:23 +0100 Subject: [address-policy-wg] =?utf-8?q?2014-09_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv6_Address_Space_Policy_For_In?= =?utf-8?q?ternet_Exchange_Points=E2=80=9D=29?= In-Reply-To: <20141023145629.15BBF3406C@prometheus.inex.ie> References: <20141023145629.15BBF3406C@prometheus.inex.ie> Message-ID: <54495CB3.5030408@inex.ie> On 23/10/2014 14:28, Marco Schmidt wrote: > A proposed change to RIPE Document IPv6 Address Space Policy For > Internet Exchange Points is now available for discussion. the tl;dr for my objection on this proposal is that it doesn't make much sense from the IXP point of view. The equivalent ipv4 policy notes: "This space will be used to run an IXP peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not perfect by any means, but ok (as a reference anecdata point, INEX is still using a single /24 assigned in 2004 for both peering and management, because it was hard to justify more at the time). For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 other /64 subnets unused in the /48 assignment. For better or worse, many IXPs in the RIPE NCC service region use some of the other space in their /48 for management purposes. If this policy change goes through, then the RIPE NCC is mandating that they renumber this management into other space. The RIPE community doesn't have the authority to mandate this for existing IXPs. For future start-up IXPs, it often makes more sense to use a single prefix to provide address space for both peering and management, where management connectivity is handled by policy routing from the IXP's ASN. Maybe it might be appropriate for the IXP to use separate prefixes at the stage when an IXP has grown to the point that it attracts enough DDoS traffic directed at the IXP lan to cause trouble, but not before. Even then, this is a decision that the IXP should make: it's not the job of the RIPE community to tell the IXP how to manage their policy routing. Nick From pk at DENIC.DE Thu Oct 23 22:03:00 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 23 Oct 2014 22:03:00 +0200 Subject: [address-policy-wg] =?iso-8859-1?q?2014-10_New_Policy_Proposal_?= =?iso-8859-1?q?=28Language_Clarification_in_=E2=80=9CIPv6_Addresse?= =?iso-8859-1?q?s_for_Internet_Root_Servers_In_The_RIPE_Region=E2?= =?iso-8859-1?q?=80=9D=29?= In-Reply-To: References: Message-ID: <20141023200300.GC31543@x28.adm.denic.de> On Thu, Oct 23, 2014 at 03:37:23PM +0200, Marco Schmidt wrote: > A proposed change to RIPE Document "IPv6 Addresses for Internet > Root Servers In The RIPE Region" is now available for discussion. > http://www.ripe.net/ripe/policies/proposals/2014-10 1) the motivating pointer to RFC 2119 is misguided. RIPE documents do not make a reference to RFC 2119 in general and even less so in this particular case. There's already enough confusion in the IETF with "must" vs "MUST", i.e., when keywords do and don't bear their special meaning. 2) the change is unnecessary and does not provide clarification. The text is already clearly stating that assigned address space stays with the service and will (have to) be returned to the RIPE NCC if the service is terminated. A "should" is sufficient. 3) The status of ripe-233, especially in the light of the omnibus document ripe-623 is probably a bit vague. ripe-233 exists for historic reference, therefore any change applied by this proposal would retroactively try to change the rule for past assignments with no new assignments to be expected (for lack of policy). 4) Issuing a new document with a new timestamp is likely to cause more confusion than it strives to solve (lacking sth equivalent to a "Historic" document status and/or explanatory introductory text in the updated document). Resolved, no support -Peter From marty at akamai.com Thu Oct 23 22:36:54 2014 From: marty at akamai.com (Hannigan, Martin) Date: Thu, 23 Oct 2014 16:36:54 -0400 Subject: [address-policy-wg] =?windows-1252?q?2014-09_New_Policy_Proposal_?= =?windows-1252?q?=28Language_Clarification_in_=93IPv6_Address_Space_Polic?= =?windows-1252?q?y_For_Internet_Exchange_Points=94=29?= In-Reply-To: <54495CB3.5030408@inex.ie> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> Message-ID: <3F58D0EF-C975-47A7-9B9B-D2EE9FD1A063@akamai.com> On Oct 23, 2014, at 3:53 PM, Nick Hilliard wrote: > On 23/10/2014 14:28, Marco Schmidt wrote: >> A proposed change to RIPE Document IPv6 Address Space Policy For >> Internet Exchange Points is now available for discussion. > > the tl;dr for my objection on this proposal is that it doesn't make much > sense from the IXP point of view. > > The equivalent ipv4 policy notes: "This space will be used to run an IXP > peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not > perfect by any means, but ok (as a reference anecdata point, INEX is still > using a single /24 assigned in 2004 for both peering and management, > because it was hard to justify more at the time). > > For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 > other /64 subnets unused in the /48 assignment. For better or worse, many > IXPs in the RIPE NCC service region use some of the other space in their > /48 for management purposes. > > If this policy change goes through, then the RIPE NCC is mandating that > they renumber this management into other space. The RIPE community doesn't > have the authority to mandate this for existing IXPs. > > For future start-up IXPs, it often makes more sense to use a single prefix > to provide address space for both peering and management, where management > connectivity is handled by policy routing from the IXP's ASN. > > Maybe it might be appropriate for the IXP to use separate prefixes at the > stage when an IXP has grown to the point that it attracts enough DDoS > traffic directed at the IXP lan to cause trouble, but not before. Even > then, this is a decision that the IXP should make: it's not the job of the > RIPE community to tell the IXP how to manage their policy routing. > > Nick > +1 - the other thing I'd add is that "three ISPs" is an out of date and restrictive measure for assigning IP address space as well. I'd like to see the language reflect current standards and BCPs which define an IXP as more than 2 autonomous systems. (OIX-1 and a few BCPs floating around). Best, -M< -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From pk at DENIC.DE Thu Oct 23 22:50:39 2014 From: pk at DENIC.DE (Peter Koch) Date: Thu, 23 Oct 2014 22:50:39 +0200 Subject: [address-policy-wg] =?iso-8859-1?q?2014-08_New_Policy_Proposal_?= =?iso-8859-1?q?=28Language_Clarification_in_=E2=80=9CContractual_R?= =?iso-8859-1?q?equirements_for_Provider_Independent_Resource_Holde?= =?iso-8859-1?q?rs_in_the_RIPE_NCC_Service_Region=E2=80=9D=29?= In-Reply-To: References: Message-ID: <20141023205039.GD31543@x28.adm.denic.de> On Thu, Oct 23, 2014 at 03:15:24PM +0200, Marco Schmidt wrote: > A proposed change to RIPE Document "Contractual Requirements for Provider > Independent Resource Holders in the RIPE NCC Service Region" is now available > for discussion. > https://www.ripe.net/ripe/policies/proposals/2014-08 # Any resources allocated/assigned to the RIPE NCC will be registered in the # RIPE Database. All policies set for allocating or assigning resources to # LIRs apply equally to the RIPE NCC. The RIPE NCC as a resource holder should # fulfil the same basic requirements also expected of normal LIRs, such as returning # unused resources. As an exception from normal LIRs, RIPE NCC as a resource holder # is exempted from signing any of the normal contracts required for number resource allocation/assignment. RFC 2119, as mentioned in the introduction, is not relevant to this document (see earlier mail). In this case, the change appears straightforward even if should vs must was interpreted in a natural language context. On second thought, it remains undefined what the "basic requirements" are (leaving another ambiguity) and it isn't clear whether the list of exemptions is exhaustive. As an example: is the NCC undergoing a regular or case by case audit and who is supposed to execute that? Arbiters are supposed to evaluate requests, but how would the NCC's adherence to the "basic requirements, [...] such as returning unused resources" be supervised? There's no vox populi appeal to the arbiters. But wait, we have a general community involvement in the NCC's operation and my perception was it was considered functioning. So, I'm not really convinced that an s/should/must/ would prevent the NCC from running wild if it wanted to. On the other hand, I might be looking forward to future policy proposals and further should vs must (or similar) discussions except that the PDP rarely provides the right slot for this level of detail. In other words: what's being tried to fixed here is likely to happen again. Back to 2014-08: it's either unnecessary or incomplete. -Peter PS: Obviously in this case it is prudent for the NCC as the submitter to err on the side of caution From nick at inex.ie Thu Oct 23 23:29:08 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 23 Oct 2014 22:29:08 +0100 Subject: [address-policy-wg] 2014-10 New Policy Proposal (Language Clarification in "IPv6 Addresses for Internet Root Servers In The RIPE Region") In-Reply-To: <20141023200300.GC31543@x28.adm.denic.de> References: <20141023200300.GC31543@x28.adm.denic.de> Message-ID: <54497324.6050400@inex.ie> On 23/10/2014 21:03, Peter Koch wrote: > 1) the motivating pointer to RFC 2119 is misguided. RIPE documents do not > make a reference to RFC 2119 in general and even less so in this particular > case. There's already enough confusion in the IETF with "must" > vs "MUST", i.e., when keywords do and don't bear their special meaning. The proposal does not draw a distinction between "must" and "MUST". RIPE documents can start referencing 2119 today, if they want. > 2) the change is unnecessary and does not provide clarification. > The text is already clearly stating that assigned address space stays > with the service and will (have to) be returned to the RIPE NCC if > the service is terminated. A "should" is sufficient. "should" means: "really ought to, but if not then whatevs", which is not the intention of the policy. Probably the RIPE NCC would implement this "must" if there were a new request, so clarification of intent is not a bad idea. > 3) The status of ripe-233, especially in the light of the omnibus document > ripe-623 is probably a bit vague. ripe-233 applies solely to ipv6 space; ripe-623 applies to ipv4 space. It's not clear why this is relevant either. > ripe-233 exists for historic reference, > therefore any change applied by this proposal would retroactively try > to change the rule for past assignments with no new assignments to be > expected (for lack of policy). ripe-233 / successor exist not just for historic reference, but may apply to future assignments if there are reassignments of root servers in the future. The future is a long time. Re: retroactive changes, are there any ipv6 assignments made to root servers which use the ipv6 addresses for other purposes? I.e. is the RIPE community asking that actual behaviour be changed? > 4) Issuing a new document with a new timestamp is likely to cause more > confusion than it strives to solve (lacking sth equivalent to a > "Historic" document status and/or explanatory introductory text > in the updated document). This seems to be an argument that policy updates shouldn't happen because they might confuse people. Nick From nick at inex.ie Thu Oct 23 23:30:27 2014 From: nick at inex.ie (Nick Hilliard) Date: Thu, 23 Oct 2014 22:30:27 +0100 Subject: [address-policy-wg] 2014-08 New Policy Proposal (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region") In-Reply-To: <20141023205039.GD31543@x28.adm.denic.de> References: <20141023205039.GD31543@x28.adm.denic.de> Message-ID: <54497373.8020804@inex.ie> On 23/10/2014 21:50, Peter Koch wrote: > In this case, the change appears straightforward even if should vs must was > interpreted in a natural language context. On second thought, it remains > undefined what the "basic requirements" are (leaving another ambiguity) > and it isn't clear whether the list of exemptions is exhaustive. As an > example: is the NCC undergoing a regular or case by case audit and > who is supposed to execute that? Arbiters are supposed to evaluate > requests, but how would the NCC's adherence to the "basic requirements, [...] > such as returning unused resources" be supervised? There's no vox populi > appeal to the arbiters. > But wait, we have a general community involvement in the NCC's operation > and my perception was it was considered functioning. So, I'm not > really convinced that an s/should/must/ would prevent the NCC from running wild > if it wanted to. On the other hand, I might be looking forward to > future policy proposals and further should vs must (or similar) discussions > except that the PDP rarely provides the right slot for this level of detail. > In other words: what's being tried to fixed here is likely to happen again. Peter, You may have misunderstood this one. The change from "should" to "must" refers explicitly to the 6 points which need to be included in all end-user contracts, namely: > - Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date > - Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database > - Notice that none of the provider independent resources may be sub-assigned to a third party > - Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources > - A clear statement that the resources will return by default to the RIPE NCC if > The resource holder cannot be contacted > The annual fee to the LIR is not paid > - A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time re: > Back to 2014-08: it's either unnecessary or incomplete. It looks like an eminently reasonable proposal to me. It was never intended that these six points be optional. Nick From gert at space.net Thu Oct 23 23:30:56 2014 From: gert at space.net (Gert Doering) Date: Thu, 23 Oct 2014 23:30:56 +0200 Subject: [address-policy-wg] 2014-09 New Policy Proposal (Language Clarification in ???IPv6 Address Space Policy For Internet Exchange Points???) In-Reply-To: <54495CB3.5030408@inex.ie> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> Message-ID: <20141023213056.GN31092@Space.Net> Hi, On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote: > stage when an IXP has grown to the point that it attracts enough DDoS > traffic directed at the IXP lan to cause trouble, but not before. Even > then, this is a decision that the IXP should make: it's not the job of the > RIPE community to tell the IXP how to manage their policy routing. But it *is* the job of the RIPE community to tell receivers of address space what strings are attached to it, in no uncertain terms, where the existing text obviously wasn't clear enough. I maintain that the intention of the existing policy text for IXP prefixes and root name server prefixes was all the time "you get a special exception for that which makes you special (IXP fabric, and root name server), and for *everything* *else*, you're just a normal participant and do what any other Internet-connected company would do to get connectivity and space" - strictly a MUST in RFC2119 terms, not a "we politely ask you and if you do not want that, feel free to ignore it". But that was ages ago, so it's good to actually revisit this and decide what we want the policy to be, and make it very explicitly so. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From lists-ripe at c4inet.net Thu Oct 23 23:40:55 2014 From: lists-ripe at c4inet.net (Sascha Luck) Date: Thu, 23 Oct 2014 22:40:55 +0100 Subject: [address-policy-wg] =?unknown-8bit?Q?2?= =?unknown-8bit?Q?014-09_New_Policy_Proposal_=28Language_Clarification_in_?= =?unknown-8bit?Q?=E2=3F=3FIPv6_Address_Space_Policy_For_Internet_Exchange?= =?unknown-8bit?B?IFBvaW50c+I/Pyk=?= In-Reply-To: <54495CB3.5030408@inex.ie> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> Message-ID: <20141023214054.GA58573@cilantro.c4inet.net> On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote: >The equivalent ipv4 policy notes: "This space will be used to run an IXP >peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not >perfect by any means, but ok (as a reference anecdata point, INEX is still >using a single /24 assigned in 2004 for both peering and management, >because it was hard to justify more at the time). I would remove this prohibition in existing v4 policy as well. >For future start-up IXPs, it often makes more sense to use a single prefix >to provide address space for both peering and management, where management >connectivity is handled by policy routing from the IXP's ASN. I agree with Nick's points and oppose this proposal as well. Furthermore, I would propose that the IPv4 and IPv6 policies, as regards IXPs, be changed to explicitly permit use of the assignments for mgmt purposes. Prohibiting this creates additional work for IXPs to no apparent purpose. rgds, Sascha Luck From sander at steffann.nl Fri Oct 24 02:09:41 2014 From: sander at steffann.nl (Sander Steffann) Date: Fri, 24 Oct 2014 02:09:41 +0200 Subject: [address-policy-wg] =?utf-8?q?2014-09_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=D7=92=3F=3FIPv6_Address_Space_Policy_For?= =?utf-8?q?_Internet_Exchange_Points=C4=81=3F=3F=29?= In-Reply-To: <20141023214054.GA58573@cilantro.c4inet.net> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> <20141023214054.GA58573@cilantro.c4inet.net> Message-ID: <58DF6981-88D4-4527-B1DE-70EE1EA17072@steffann.nl> Hi, > Op 23 okt. 2014, om 23:40 heeft Sascha Luck het volgende geschreven: > > I agree with Nick's points and oppose this proposal as well. > Furthermore, I would propose that the IPv4 and IPv6 policies, as > regards IXPs, be changed to explicitly permit use of the assignments for mgmt purposes. Prohibiting this creates additional > work for IXPs to no apparent purpose. Ok, it seems that this language clarification proposal has uncovered some concerns about the current policy. If we want policy to be interpreted as 'the IXP prefix should be used for the peering LAN, but using it for IXP management purposes is also fine' then we need a policy change because as I read it the current text is explicitly saying the opposite. Any volunteers for writing a policy proposal? :) Cheers, Sander From hph at oslo.net Fri Oct 24 08:11:29 2014 From: hph at oslo.net (Hans Petter Holen) Date: Fri, 24 Oct 2014 15:11:29 +0900 Subject: [address-policy-wg] WG Chair Collective (Re: WG chair re-selection procedure) In-Reply-To: <54181BBD.8050608@inex.ie> References: <36064F33-CE66-4407-8B0E-1B356D642520@steffann.nl> <20140916075207.GR14459@Space.Net> <5417EEF5.6010107@tvt-datos.es> <5417FCF0.20701@tvt-datos.es> <8FD6BA9C-F864-48D8-8AC8-981315B7585F@rfc1035.com> <54180AFE.7000000@inex.ie> <3B5164B2-FF23-4541-AE97-84C255EAA531@rfc1035.com> <54181BBD.8050608@inex.ie> Message-ID: <5449ED91.4050308@oslo.net> On 16.09.14 20:15, Nick Hilliard wrote: > I'd like to see the ad-hoc group proposals published The proposal from the task force has now been published togehter with the minutes from the wg-chairs meetings at: http://www.ripe.net/ripe/groups/wg/cc/summaries -- Hans Petter Holen RIPE Chair | Mobile +47 45 06 60 54 | hph at oslo.net | http://hph.oslo.net From pk at DENIC.DE Fri Oct 24 08:16:12 2014 From: pk at DENIC.DE (Peter Koch) Date: Fri, 24 Oct 2014 08:16:12 +0200 Subject: [address-policy-wg] 2014-07, was [Re: 2014-08 New Policy Proposal (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region")] In-Reply-To: <54497373.8020804@inex.ie> References: <20141023205039.GD31543@x28.adm.denic.de> <54497373.8020804@inex.ie> Message-ID: <20141024061612.GE31543@x28.adm.denic.de> On Thu, Oct 23, 2014 at 10:30:27PM +0100, Nick Hilliard wrote: > You may have misunderstood this one. The change from "should" to "must" > refers explicitly to the 6 points which need to be included in all end-user > contracts, namely: thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the misapplication of RFC 2119). The comments were in response to 2014-07, "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" -Peter From gabriele.rocca at top-ix.org Fri Oct 24 08:34:45 2014 From: gabriele.rocca at top-ix.org (Gabriele Rocca) Date: Fri, 24 Oct 2014 08:34:45 +0200 Subject: [address-policy-wg] 2014-09 New Policy Proposal (Language Clarification in ???IPv6 Address Space Policy For Internet Exchange Points???) In-Reply-To: <20141023213056.GN31092@Space.Net> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> <20141023213056.GN31092@Space.Net> Message-ID: <5449F305.9030503@top-ix.org> La terza Il 23/10/2014 23.30, Gert Doering ha scritto: > Hi, > > On Thu, Oct 23, 2014 at 08:53:23PM +0100, Nick Hilliard wrote: >> stage when an IXP has grown to the point that it attracts enough DDoS >> traffic directed at the IXP lan to cause trouble, but not before. Even >> then, this is a decision that the IXP should make: it's not the job of the >> RIPE community to tell the IXP how to manage their policy routing. > But it *is* the job of the RIPE community to tell receivers of address > space what strings are attached to it, in no uncertain terms, where the > existing text obviously wasn't clear enough. > > I maintain that the intention of the existing policy text for IXP prefixes > and root name server prefixes was all the time "you get a special exception > for that which makes you special (IXP fabric, and root name server), and > for *everything* *else*, you're just a normal participant and do what any > other Internet-connected company would do to get connectivity and space" - > strictly a MUST in RFC2119 terms, not a "we politely ask you and if you > do not want that, feel free to ignore it". > > But that was ages ago, so it's good to actually revisit this and decide > what we want the policy to be, and make it very explicitly so. > > Gert Doering > APWG chair -- Ing. Gabriele Rocca Consorzio TOP-IX Via Bogino 9 - 10123 Torino - Italy Mobile: +39 3346293329 Fax: +39 0118802619 Skype: gabrieleroc LinkedIn: http://www.linkedin.com/in/rocca ? Ai sensi del D.Lgs. 196/2003 le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il loro utilizzo ? consentito esclusivamente al destinatario del messaggio, per le finalit? indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Qualsiasi utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo pi? grave illecito, ed espone il responsabile alle relative conseguenze civili e penali. From gabriele.rocca at top-ix.org Fri Oct 24 08:34:29 2014 From: gabriele.rocca at top-ix.org (Gabriele Rocca) Date: Fri, 24 Oct 2014 08:34:29 +0200 Subject: [address-policy-wg] =?utf-8?q?2014-09_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv6_Address_Space_Policy_For_In?= =?utf-8?q?ternet_Exchange_Points=E2=80=9D=29?= In-Reply-To: <3F58D0EF-C975-47A7-9B9B-D2EE9FD1A063@akamai.com> References: <20141023145629.15BBF3406C@prometheus.inex.ie> <54495CB3.5030408@inex.ie> <3F58D0EF-C975-47A7-9B9B-D2EE9FD1A063@akamai.com> Message-ID: <5449F2F5.3010806@top-ix.org> La seconda Il 23/10/2014 22.36, Hannigan, Martin ha scritto: > On Oct 23, 2014, at 3:53 PM, Nick Hilliard wrote: > >> On 23/10/2014 14:28, Marco Schmidt wrote: >>> A proposed change to RIPE Document IPv6 Address Space Policy For >>> Internet Exchange Points is now available for discussion. >> the tl;dr for my objection on this proposal is that it doesn't make much >> sense from the IXP point of view. >> >> The equivalent ipv4 policy notes: "This space will be used to run an IXP >> peering LAN; other uses are forbidden". That's kind-of ok for ipv4 - not >> perfect by any means, but ok (as a reference anecdata point, INEX is still >> using a single /24 assigned in 2004 for both peering and management, >> because it was hard to justify more at the time). >> >> For IPv6, it would be normal to assign a /64 per peering LAN, leaving 65535 >> other /64 subnets unused in the /48 assignment. For better or worse, many >> IXPs in the RIPE NCC service region use some of the other space in their >> /48 for management purposes. >> >> If this policy change goes through, then the RIPE NCC is mandating that >> they renumber this management into other space. The RIPE community doesn't >> have the authority to mandate this for existing IXPs. >> >> For future start-up IXPs, it often makes more sense to use a single prefix >> to provide address space for both peering and management, where management >> connectivity is handled by policy routing from the IXP's ASN. >> >> Maybe it might be appropriate for the IXP to use separate prefixes at the >> stage when an IXP has grown to the point that it attracts enough DDoS >> traffic directed at the IXP lan to cause trouble, but not before. Even >> then, this is a decision that the IXP should make: it's not the job of the >> RIPE community to tell the IXP how to manage their policy routing. >> >> Nick >> > > +1 - the other thing I'd add is that "three ISPs" is an out of date and restrictive measure for assigning IP address space as well. I'd like to see the language reflect current standards and BCPs which define an IXP as more than 2 autonomous systems. (OIX-1 and a few BCPs floating around). > > Best, > > -M< > > > > > -- Ing. Gabriele Rocca Consorzio TOP-IX Via Bogino 9 - 10123 Torino - Italy Mobile: +39 3346293329 Fax: +39 0118802619 Skype: gabrieleroc LinkedIn: http://www.linkedin.com/in/rocca ? Ai sensi del D.Lgs. 196/2003 le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i, sono da considerarsi strettamente riservate. Il loro utilizzo ? consentito esclusivamente al destinatario del messaggio, per le finalit? indicate nel messaggio stesso. Qualora riceveste questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Qualsiasi utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non prendere cognizione della corrispondenza tra altri soggetti, salvo pi? grave illecito, ed espone il responsabile alle relative conseguenze civili e penali. From frettled at gmail.com Fri Oct 24 12:22:05 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 24 Oct 2014 12:22:05 +0200 Subject: [address-policy-wg] =?utf-8?q?2014-07_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_in_=E2=80=9CIPv4_Address_Allocation_a?= =?utf-8?q?nd_Assignment_Policies_for_the_RIPE_NCC_Service_Region?= =?utf-8?b?4oCdKQ==?= In-Reply-To: <54491707.231db50a.6d43.ffffbb38SMTPIN_ADDED_MISSING@mx.google.com> References: <54491707.231db50a.6d43.ffffbb38SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Oct 23, 2014 at 3:05 PM, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "IPv4 Address Allocation and Assignment > Policies for the RIPE NCC Service Region" is now available for discussion. > > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-07 > > As far as I can tell, all of these changes are sensible. I support them. -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From frettled at gmail.com Fri Oct 24 12:23:37 2014 From: frettled at gmail.com (Jan Ingvoldstad) Date: Fri, 24 Oct 2014 12:23:37 +0200 Subject: [address-policy-wg] =?utf-8?q?2014-11_New_Policy_Proposal_=28Lang?= =?utf-8?q?uage_Clarification_for_=E2=80=9CAllocating/Assigning_Res?= =?utf-8?q?ources_to_the_RIPE_NCC=E2=80=9D=29?= In-Reply-To: <54491707.69dfc20a.3f3f.4061SMTPIN_ADDED_MISSING@mx.google.com> References: <54491707.69dfc20a.3f3f.4061SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: On Thu, Oct 23, 2014 at 3:45 PM, Marco Schmidt wrote: > > Dear colleagues, > > > A proposed change to RIPE Document "Allocating/Assigning Resources > to the RIPE NCC" is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2014-11 > I see where this is heading. :) I support this change as well, very sensible! -- Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Fri Oct 24 16:20:52 2014 From: nick at inex.ie (Nick Hilliard) Date: Fri, 24 Oct 2014 15:20:52 +0100 Subject: [address-policy-wg] 2014-07, was [Re: 2014-08 New Policy Proposal (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region")] In-Reply-To: <20141024061612.GE31543@x28.adm.denic.de> References: <20141023205039.GD31543@x28.adm.denic.de> <54497373.8020804@inex.ie> <20141024061612.GE31543@x28.adm.denic.de> Message-ID: <544A6044.6@inex.ie> On 24/10/2014 07:16, Peter Koch wrote: > thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the > misapplication of RFC 2119). The comments were in response to 2014-07, > "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" Uh, are you sure the comments weren't intended for 2014-11? At least one of us is thoroughly confused here, possibly both. Nick From pk at DENIC.DE Fri Oct 24 16:31:37 2014 From: pk at DENIC.DE (Peter Koch) Date: Fri, 24 Oct 2014 16:31:37 +0200 Subject: [address-policy-wg] 2014-07, was [Re: 2014-08 New Policy Proposal (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region")] In-Reply-To: <544A6044.6@inex.ie> References: <20141023205039.GD31543@x28.adm.denic.de> <54497373.8020804@inex.ie> <20141024061612.GE31543@x28.adm.denic.de> <544A6044.6@inex.ie> Message-ID: <20141024143137.GR31543@x28.adm.denic.de> On Fri, Oct 24, 2014 at 03:20:52PM +0100, Nick Hilliard wrote: > On 24/10/2014 07:16, Peter Koch wrote: > > thanks, Nick, my mistake, indeed. 2014-08 seemed OK (except for the > > misapplication of RFC 2119). The comments were in response to 2014-07, > > "Language Clarification in "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" > > Uh, are you sure the comments weren't intended for 2014-11? At least one > of us is thoroughly confused here, possibly both. you aren't, I was and that twice, which is why I decided, after noting it, to move slowly, stick to handrails all day and probably throttle postings a bit. Still I think I said what I meant and still mean w.r.t. policies affecting the NCC. Have a nice weekend, Peter From gert at space.net Fri Oct 24 17:33:11 2014 From: gert at space.net (Gert Doering) Date: Fri, 24 Oct 2014 17:33:11 +0200 Subject: [address-policy-wg] 2014-07, was [Re: 2014-08 New Policy Proposal (Language Clarification in "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region")] In-Reply-To: <20141024143137.GR31543@x28.adm.denic.de> References: <20141023205039.GD31543@x28.adm.denic.de> <54497373.8020804@inex.ie> <20141024061612.GE31543@x28.adm.denic.de> <544A6044.6@inex.ie> <20141024143137.GR31543@x28.adm.denic.de> Message-ID: <20141024153311.GQ31092@Space.Net> Hi, On Fri, Oct 24, 2014 at 04:31:37PM +0200, Peter Koch wrote: > > Uh, are you sure the comments weren't intended for 2014-11? At least one > > of us is thoroughly confused here, possibly both. > > you aren't, I was and that twice, which is why I decided, after noting it, > to move slowly, stick to handrails all day and probably throttle postings a bit. > Still I think I said what I meant and still mean w.r.t. policies affecting > the NCC. After you deconfuse yourself, please send the comments in the thread relating to that proposal, with the subject identifying the particular proposal they apply to. Otherwise it will be absolutely impossible for Sander and me later on to sort out which comment was sent to proposal X but really applies to Y or Z (and FTR, I'll formally ignore this particular subthread, since it was officially not intended for 2014-07 or 2014-08). thanks, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 811 bytes Desc: not available URL: From mschmidt at ripe.net Thu Oct 30 13:43:29 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 30 Oct 2014 13:43:29 +0100 Subject: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers) Message-ID: Dear colleagues, A proposed change to RIPE Document ripe-589, "IPv6 Address Allocation and Assignment Policy" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this proposal and send your comments to before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From ak at list.ak.cx Thu Oct 30 13:51:20 2014 From: ak at list.ak.cx (Andre Keller) Date: Thu, 30 Oct 2014 13:51:20 +0100 Subject: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers) In-Reply-To: <20141030124946.6836A4E0AD@imx002.zrh01.ndnet.ch> References: <20141030124946.6836A4E0AD@imx002.zrh01.ndnet.ch> Message-ID: <54523448.5020006@list.ak.cx> Hi, I fully support this proposal. Regards andr? From mschmidt at ripe.net Thu Oct 30 15:56:48 2014 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 30 Oct 2014 15:56:48 +0100 Subject: [address-policy-wg] 2014-13 New Policy Proposal (Allow AS Number Transfers) Message-ID: Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-13 We encourage you to review this proposal and send your comments to before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From andreas.vogler at geneon.de Fri Oct 31 08:42:59 2014 From: andreas.vogler at geneon.de (Andreas Vogler) Date: Fri, 31 Oct 2014 08:42:59 +0100 Subject: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers) In-Reply-To: <20141030125449.04D5C3B7A1@mx4.geneon.de> References: <20141030125449.04D5C3B7A1@mx4.geneon.de> Message-ID: <27CE2179D1925A4F9F4874725C3B4E0FB7D05B211F@COSMOS.nbg.geneon.de> I support this proposal. Regards Andreas Vogler Geneon GmbH I Gutenstetter Str. 8a I 90449 N?rnberg I Entwicklungszentrum Berlin I L?westr. 25 I 10249 Berlin I Tel.: +49 (0)911 36 78 88-21 I Fax: +49 (0)911 36 78 88-20 I Gesch?ftsf?hrer: Yong-Harry Steiert I Registergericht N?rnberg HRB 17193 I USt-IdNr.: DE207317266 I E-Mail: andreas.vogler at geneon.de I www.geneon.de Ein Unternehmen der Willmy MediaGroup >>> www.willmy.de -----Urspr?ngliche Nachricht----- Von: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 30. Oktober 2014 13:43 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2014-12 New Policy Proposal (Allow IPv6 Transfers) Dear colleagues, A proposed change to RIPE Document ripe-589, "IPv6 Address Allocation and Assignment Policy" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-12 We encourage you to review this proposal and send your comments to before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC From andreas.vogler at geneon.de Fri Oct 31 08:43:13 2014 From: andreas.vogler at geneon.de (Andreas Vogler) Date: Fri, 31 Oct 2014 08:43:13 +0100 Subject: [address-policy-wg] 2014-13 New Policy Proposal (Allow AS Number Transfers) In-Reply-To: <20141030150409.437B251F1@mx4.geneon.de> References: <20141030150409.437B251F1@mx4.geneon.de> Message-ID: <27CE2179D1925A4F9F4874725C3B4E0FB7D05B2120@COSMOS.nbg.geneon.de> I support this proposal. Regards Andreas Vogler Geneon GmbH I Gutenstetter Str. 8a I 90449 N?rnberg I Entwicklungszentrum Berlin I L?westr. 25 I 10249 Berlin I Tel.: +49 (0)911 36 78 88-21 I Fax: +49 (0)911 36 78 88-20 I Gesch?ftsf?hrer: Yong-Harry Steiert I Registergericht N?rnberg HRB 17193 I USt-IdNr.: DE207317266 I E-Mail: andreas.vogler at geneon.de I www.geneon.de Ein Unternehmen der Willmy MediaGroup >>> www.willmy.de -----Urspr?ngliche Nachricht----- Von: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] Im Auftrag von Marco Schmidt Gesendet: Donnerstag, 30. Oktober 2014 15:57 An: policy-announce at ripe.net Cc: address-policy-wg at ripe.net Betreff: [address-policy-wg] 2014-13 New Policy Proposal (Allow AS Number Transfers) Dear colleagues, A proposed change to RIPE Document ripe-525, "Autonomous System (AS) Number Assignment Policies" is now available for discussion. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-13 We encourage you to review this proposal and send your comments to before 28 November 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC