Re: [address-policy-wg] 2023-04 Proposal Accepted (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi there, * APEX NCC ORG Can you provide an example of using and registering an AGGREGATED-BY-LIR object for IPV4? Who is this for and when? It has exactly the same use case as AGGREGATED-BY-LIR for IPv6. It is primarily intended for LIRs which need to make a large number of essentially

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

* Brian Storey I only have a short window to reply, however I would clarify that I fall in to the " Registering a PA Assignment with something like "CUSTOMER-1234" and an email address pointing to the LIR has been acceptable for all this time.»" category. I am therefore looking at this through

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

* Brian Storey: There is a subtly here which I don't think is fully appreciated. I previously highlighted my surprise to the RIPE NNCs interpretation of the existing policy; as have others. Why is that? I think it's very important to recognise that LIRs act and publish certain End User data

Re: [address-policy-wg] Last Call - 2023-04 (Add AGGREGATED-BY-LIR status

* Carlos Friaças via address-policy-wg: So in order to make it clear for the co-chairs, i do oppose this proposal, on the grounds that the quality of publicly available registration data is likely to decrease if this proposal is approved. Hi Carlos, This concern has been addressed at length

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Good morning Jan, On 12/01/24 07:25, Jan Ingvoldstad wrote: I also do not understand what makes it so hard to say that: "Yes, the current policy does state something else than NCC's interpretation of it does, (…) We do not make statements that we do not believe to be true. In our opinion,

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Jan, On 11/01/24 13:27, Jan Ingvoldstad wrote: On Thu, Jan 11, 2024 at 1:11 PM Tore Anderson wrote: After all, any LIR which prefers the RIPE NCC interpretation of the policy in this regard is may simply adhere to it and act accordingly, and this is commonly done today. Thus

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Jan, On 11/01/24 10:19, Jan Ingvoldstad wrote: On Thu, Jan 11, 2024 at 9:45 AM Tore Anderson wrote: On 11/01/24 03:20, denis walker wrote: > This is total madness. You keep saying you have no intention of > changing anything else. You keep saying the wording change ac

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Denis, On 11/01/24 03:20, denis walker wrote: On Wed, 10 Jan 2024 at 13:02, Tore Anderson wrote: On 10/01/24 11:25, Jan Ingvoldstad wrote: Or you could take the other stance and stop publishing *any* contact details regarding an object, because you cannot know whether the information

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hello Denis, On 11/01/24 01:40, denis walker wrote: So personal data does not always need consent of the data subject. But you only ever refer to (a) consent. There are indeed other possible lawful bases than consent, and this fact is precisely why I wrote (emphasis added): «Publishing

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hello again Jan, On 10/01/24 11:25, Jan Ingvoldstad wrote: Basically, any public company register would be illegal according to the interpretation you lean on here. Public company registries also need a lawful basis for processing. The Norwegian public company registry, for example, uses the

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi again Jan, On 09/01/24 13:38, Jan Ingvoldstad wrote: It is important to also consider the cases where the End Users are organisations that do not have non-PII role addresses. Consider for example a small one-person business, let's say a farm owned by «Farmer Fred». This

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Jan, On 09/01/24 10:51, Jan Ingvoldstad wrote: On Sat, Dec 16, 2023 at 7:55 PM Tore Anderson wrote: The second – alleged – change is the one that has been discussed the most on the mailing list. The argument here is that your two ASSIGNED PA objects above are actually

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

On 20/12/23 17:27, denis walker wrote: Most of these allocations are /24. So if 4551 of these /24 allocations have no assignments, and the increase in allocations without assignments is only 3536, then we actually have more allocations with assignments than we had before, putting aside the /24

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

Hello again Denis, On 16/12/23 19:53, Tore Anderson wrote: On Fri, 2023-12-15 at 14:20 +0100, denis walker wrote: On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: «As of August 2023, there were 19,221 PA allocations without any child PA assignments held by 10,052 LIRs (…) Since the RIPE

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Jan, On Fri, 2023-12-15 at 14:58 +0100, Jan Ingvoldstad wrote: > Can the proposers please clarify how a change, that is claimed to > change nothing, is a necessary change? > > Unless this is resolved, I oppose the change. Certainly - we are happy to clarify. We believe we are actually

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

uments presented, so anyone reading this should feel free to skip the rest of this message. > On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > > > «As of August 2023, there were 19,221 PA allocations without any child > > PA assignments held by 10,052 LIRs (…) Since the RIP

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

Hi Denis, On Fri, 2023-12-15 at 11:45 +0100, denis walker wrote: > On Thu, 14 Dec 2023 at 16:34, Tore Anderson wrote: > > > > Did this consultation take the information in the Impact Analysis into > > account – in particular the clarification made by the RIPE NCC

Re: [address-policy-wg] @EXT: Inputs/observations from EUROPOLon proposal 2023-04

Hello Emmanuel, and thank you for your message! Please find our comments and questions inline below: On Wed, 2023-12-13 at 20:30 +, Kessler, Emmanuel wrote: > With this message, I would like to express from Europol perspective, > our questions and some clear concerns about the measure

Re: [address-policy-wg] 2023-04 Review Phase (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

On Wed, 2023-11-29 at 12:28 +0100, Peter Hessler wrote: > I mentioned this during the WG session but want to bring it up on the > mailing list, what is the definition of assignment-size. > > In the IPv6 implementation of AGGREGATED-BY-LIR there is an > assignment-size attribute, which is

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Denis, It would appear to me that your opposition to 2023-04 is largely based on the premise that it introduces a new possibility for anonymous assignments, a change which you do not want to see happen. This premise also appears to underpin many of your musings in your «The bigger picture»

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Denis, > This is where the implications get interesting. Each of the objects > in the example I gave is in itself individually aggregatable. There > is nothing in your policy proposal that says an aggregate must cover > multiple assignments to multiple End Users. You say: > "In case of an

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi again Brian, * Brian Storey > I'm conscious you've gone to a great deal of effort to respond back > to me promptly and I've not come back to you sooner. Sorry to keep > you waiting for at least an acknowledgement. > > Firstly, thank you for taking us through this example. I can see >

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hello Cynthia, * Cynthia Revström > After reading denis's response I realized that I responded a bit too > hastily with my +1. > I am going to retract my support for this proposal as I really don't > get why you would need this without the "assignment-size" attribute. > I might have missed

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hello Denis, Let me start off by clearing up a misunderstanding: My brief example did not mean to convey that non-uniform contact information is the only thing that could make a set of objects non- uniform and thus unsuitable for AGGREGATED-BY-LIR. Rather, the exact opposite was the intended

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

Hi Brian, * Brian Storey > Thanks for explaining this particular use case. > > Reading the proposed New Policy Text, it provides the LIR with an > adminsitrative choice. Whilst I understand this choice, the > rantionale behind the proposal is to find a reasonable way to fill > the gap for the

Re: [address-policy-wg] 2023-04 New Policy Proposal (Add AGGREGATED-BY-LIR status for IPv4 PA assignments)

* APEX NCC ORG > Hello, Team! > I read the offer provided: > https://www.ripe.net/participate/policies/proposals/2023-04 > three times. > However, I still don't understand the real reason for introducing the > AGGREGATED-BY-LIR status > The text of the proposal contains only general provisions. >

Re: [address-policy-wg] 2023-02 Last Call for Comments (Minimum Size for IPv4 Temporary Assignments)

* Erik Bais > Please be aware that the Last Call for Comments of the min. size for > IPv4 temp assignments is about to end ..  ( June 13 2023 – aka > tomorrow ) >   > As chairs we would like to receive a bit more comments / support > during last call, as it has been silent ..  >   > To reach

Re: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26)

On Wed, 2023-07-05 at 16:52 +0200, Angela Dall'Ara wrote: >  The requirement in the current policy (ripe-733) [1] that “After one > year the utilisation of the new assignment must be at least 50%, > unless special circumstances are defined" is implemented the way > Marco previously explained: the

Re: [address-policy-wg] 2023-01 Review Phase (Reducing IXP IPv4 assignment default size to a /26)

* Matthias Wichtlhuber > Hi Nick, all, > > > 1. problematic edge cases in section 5 due to the magic figure of 50% > > utilisation > > 2. what is a "special circumstance"? > > The proposal does not modify existing numbers (50%) or the "special > circumstances". Both are in the current policy

Re: [address-policy-wg] 2023-02 Extended Review Phase (Minimum Size for IPv4 Temporary Assignments)

On Tue, 2023-05-09 at 16:31 +0200, Angela Dall'Ara wrote: > The policy proposal 2023-02, "Minimum Size for IPv4 Temporary > Assignments" is now in the extended Review Phase in an updated > version. > > Following up on the feedback received, the wording was simplified > without changing the

Re: [address-policy-wg] 2023-01 Extended Discussion Phase (Reducing IXP IPv4 assignment default size to a /26)

On Mon, 2023-04-24 at 09:01 +0200, Angela Dall'Ara wrote: > The policy proposal 2023-01, "Reducing IXP IPv4 assignment default > size to a /26" is now in the extended Discussion Phase. > > This proposal modifies the default size of IPv4 assignments for IXPs > from a /24 to /26 and clarifies the

Re: [address-policy-wg] Checking interest in the community for changing IPv4 assignments policy

On Tue, 2023-05-16 at 02:08 +0200, denis walker wrote: > What is the real reason for this push to dump assignments? I just > don't buy these arguments. Hi Denis, The reason / rationale is as stated. There is no "real" reason apart from that. Of course, the formal proposal will elaborate

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

* Matthias Wichtlhuber > regarding 6.1(4) - (default is /26, /25 is handed out upon request): > > The idea behind this part of the proposal is that there are two kinds > of IXPs, one that is founded due to the need to interconnect a few > networks in a specific region and no intent of growth and

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

* Wolfgang Tremmel > > > > > a) a new IXP can simply ask for an initial /25 and receive it, no > > > questions asked? > > yes. But if a new IXP requests an initial /25 they at least have done > some homework about what to expect. And I expect that homework to be > shown to the RIPE NCC to get

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

Forgot to mention one thing, see below. (I am quoting my entire previous message so both can be replied to in-line at once.) * Tore Anderson > * Angela Dall'Ara > > > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > > default size to a /2

Re: [address-policy-wg] 2023-01 New Policy Proposal (Reducing IXP IPv4 assignment default size to a /26)

* Angela Dall'Ara > A new RIPE Policy Proposal, 2023-01, "Reducing IXP IPv4 assignment > default size to a /26" > is now available for discussion. > > The goal of this proposal is to extend the lifetime of the IXP IPv4 > address pool and to motivate IXPs to implement the exchange of IPv4 >

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Nick Hilliard > this is kinda the problem with RFC 5549, no?  I.e. it deals only with > signaling rather than transport. So even if it's deployed, the IXP > will still need to provide ipv4 addresses for transport purposes. Apart from the BGP session itself (which supports multi-AF), the

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Will Hargrave > On the issue of assignment size, it does seem we can’t go on with > assigning more /24s as the minimum. Not sure if there’s a land-grab > going on but just today alone another four /24s were handed out to an > operator for use in the Nordic region - with two /24s for Norway >

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Matthias Wichtlhuber > I don't get the point of the /29 discussion anyways. It is based on > the false assumption that we need to stretch the pool to eternity and > beyond. We need to stretch the pool until we can test and establish > IPv4 over IPv6 peering LANs. A /26 default is perfectly fine

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Marcus Stoegbauer > In the case of IXPs I consider larger assignments up to a certain > point as a technical necessity rather than a situation we need to > rectify. Handing out /29s to a new IXP IMO puts a large burden on > newly founded IXPs (since they would need to renumber earlier) which >

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Radu-Adrian FEURDEAN > On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote: > > Actually, I do have some real-life experience here as I/AS39029 was > > part of the NIX renumbering process back in 2017. The whole > > operation was rather straight-forward and went very sm

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Aleksi Suhonen > I feel that /26 is the smallest reasonable subnet size for an IXP, no > matter how small the IXP is initially. If it starts growing, it will > quickly grow past /27, but might just stay inside the /26. This is > based on empirical experience over the decades. Could you please

Re: [address-policy-wg] IXP pool lower boundary of assignments

* David Farmer > You seem to want to optimize for the smallest of the small IXPs, tiny > IXPs as you put it. How about we optimize for just plain small IXPs? No, what I want is to optimise equally for all sizes of IX-es. It is the current optimisation of (read: overassignment to) small IX-es I

Re: [address-policy-wg] IXP pool lower boundary of assignments

* David Farmer > So, if an IXP starts with three(3) participants, per policy, with a > /29, it is already at 50% full, leaving 3 addresses for growth, and > that doesn't include any infrastructure IP addresses, like a route > server(s), etc... Exactly, a tiny IXP with three founding members

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Wolfgang Tremmel > > No. But renumbering an IX is *pain*. A lot of pain. You want to > > avoid that if possible. > > A /26 allows (given that the IX uses about 2-4 IPs itself) about 60 > > customers. > > > > So according to the numbers, for 70% of the IXes this will never > > fill up, so no

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Matthias Wichtlhuber > Moreover, I have updated the analysis to include /29s (which I > previously cut off). Only ~25% of all IXPs would fit into such a > small peering LAN. Setting the default to /29 will likely cripple the > growth of IXes. There is also no benefit in retaining these

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Matthias Wichtlhuber > While I think a /29 would be too radical (renumbering peering LANs > can be a real headache, you don't want to do that more often than > needed), a /26 as a default might be a good compromise. 62 usable > addresses are still enough for ~70% of all IXes including 100% over

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

* Jérôme Nicolle > Thank you for your honest statement. I feel likewise. > > Le 31/10/2022 à 14:41, Tore Anderson a écrit : > > Playing devil's advocate, I would argue that the moment some broadband > > subscriber decides to set up a port forwarding of 443/tcp to some web

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

* Gert Doering > On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote: > > I never quite understood why we appear to be totally OK with not > > requiring each individual IPv6 customer assignment to be registered in > > the database, while we continue to require it fo

Re: [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)

* Gert Doering > On Mon, Oct 24, 2022 at 04:02:19AM -0700, Leo Vegoda wrote: > > As I read the proposal, it is intended to allow LIRs to prune the > > records they believe do not add value. It would enable discretion, > > rather than blind obedience. Is that a negative? If so, why? > > This puts

Re: [address-policy-wg] IXP pool lower boundary of assignments

* Matthias Wichtlhuber > As per my analysis, there has been a ~40% increase in IXPs world-wide > over the last three years (see my initial mail). Given that number, I > don't think we should wait and continue wasting space with too large > assignments until 2027. I agree, but as I also said back

Re: [address-policy-wg] IPv4 PA assignments policy change draft proposal

* Gert Doering > I am not convinced why adding a special-case "may" for "LIR to itself" > while keeping the "must" for "LIR to others" would be a good idea of any > sorts. Maybe a compromise would be to add a «LIR to many others [with identical contact info]» type of database entry, analogous

Re: [address-policy-wg] 2019-06 Last Call for Comments (Multiple Editorial Changes in IPv6 Policy)

* Petrit Hasani > Proposal 2019-06, "Multiple Editorial Changes in IPv6 Policy", is now in > Concluding Phase. > Please e-mail any final comments about this proposal to > before 11 March 2020. Support. Tore

Re: [address-policy-wg] 2019-06 Review Phase Extended (Multiple Editorial Changes in IPv6 Policy)

* Gert Doering > So, please have a look and express your opinion - continued support, or > disagreement. Support. Tore

Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

* Arash Naderpour > Do we know how many /29 we have available in the IXP reserved pool? if there > are only few ones, it doesn't make scene to me set the default to /29 as it > would be a good practice for just few allocations. > > Can someone from RIPE NCC provide us with an statistic on

Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

* Martin Pels > On 22/10/19 18:24, Nick Hilliard wrote: >> INEX was a good internet citizen and started out with a /27 on our main >> peering LAN in 1996. When that ran out, we moved to a /26 and then a >> /25. We're now at /23. For each renumbering operation, we ran into the >> problems

Re: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs)

* Marco Schmidt > A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" > is now available for discussion. > > This proposal aims to change the default IXP assignment size from a /24 > to a needs-based model, with a /27 as a minimum. While I do support the proposal's aim of

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Gert Doering > Also, you are certainly all aware that if we do another version of this > proposal with changes and a new impact analysis, we'll have run out of > IPv4 before this can be implemented (thus: no extra address space for > IXPs). The IA states that the NCC can set aside the required

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Sascha Luck [ml] > On Fri, Aug 09, 2019 at 02:40:03PM +0200, Tore Anderson wrote: >> Repeating myself a bit[1], I'd say the default should be /29. This because >> the /29s are the smallest fragments left behind in the NCC inventory. > > I can't see how an IXP with 6 mem

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Dominik Nowacki > Same here, +1 for /25 Repeating myself a bit[1], I'd say the default should be /29. This because the /29s are the smallest fragments left behind in the NCC inventory. As the NCC's impact analysis states, these currently have no policy that allows for their use, so they'd

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

* JORDI PALET MARTINEZ via address-policy-wg > -> Because I think when there is an unfair situation (some folks bound to > rules/policies, others not), there is a problem. ... > -> Because is not subjected to the same rules (policies) as the non-legacy > one. That's unfair. Thank you for

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

* JORDI PALET MARTINEZ via address-policy-wg > I think my previus email just explained it. Not really... > The motivation is my personal view that we have a problem (as a community) by > not bringing into the system the legacy resources. I understand that you have that view. What I fail to

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

* Gert Doering > On Sat, Jul 13, 2019 at 01:37:19PM +0200, JORDI PALET MARTINEZ via > address-policy-wg wrote: >> I keep thinking that ripe-682 (RIPE resource transfer policies), should have >> a provision (as it is the case in all the other RIRs), in order to "convert" >> the legacy resources

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Matthias Wichtlhuber > I have compiled an in-depth analysis of peeringdb data. You can find a > full description of the method, scripts, data and the main results on > github: > > https://github.com/mwichtlh/address-policy-wg/ Very nice work! Thank you for sharing this! > Some interesting

Re: [address-policy-wg] 2019-02 Review Phase (IPv4 Waiting List Implementation)

* Marco Schmidt > Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the > Review Phase. Support. Tore

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Wolfgang Tremmel > when opening a new exchange there are no customers connected yet, all you > have is a business plan. So everything is kind of speculative and you can > easily adjust your plan that you need a /24 - so why add additional workload > to the NCC to review business plans?

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Gert Doering > On Fri, May 31, 2019 at 09:08:30AM +0200, Tore Anderson wrote: >> Also, I am wondering about the thinking behind giving out /24s >> by default when the minimum assignment size is reduced /27. Why not >> right-size the assignment all the way down to the minim

Re: [address-policy-wg] 2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)

* Marco Schmidt > A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for > IXPs" is now available for discussion. I am positive to this policy proposal. A suggestion, though: use the /16 set aside in «5.2 Unforeseen circumstances» for expanding the IXP pool. The unforeseen

Re: [address-policy-wg] 2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")

* Marco Schmidt > Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is > now in the Review Phase. Supported. Tore

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

* ga...@nethinks.com > But in order to not punish late entries to the market, it should also include > a fixed timeframe when EVERYBODY has to stop using v4 (at least on the public > Internet) ... We don't have the authority to impose such a timeframe on «EVERYBODY». Late entrants are going to

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

* Carlos Friaças via address-policy-wg > > On Tue, 5 Feb 2019, Tore Anderson wrote: > >> - I don't quite believe that the waiting list would grow indefinitely >>  (regardless of the allocation size being /22 or /24). Keep in mind >>  that only new and IPv4-less

Re: [address-policy-wg] 2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)

* Marco Schmidt > A new RIPE Policy proposal, 2019-02, "Reducing IPv4 Allocations to a /24" > is now available for discussion. > > This proposal aims to reduce the IPv4 allocation size to a /24 once the > RIPE NCC is unable to allocate contiguous /22 ranges. I support this proposal. Some random

Re: [address-policy-wg] WG Chair selection

* Jetten Raymond > Erik has been a long term active and knows how the system works. That is true. I tried finding any evidence of past activity in the APWG by Sean Stuart, but unless my Google-fu is completely faulty, there simply is not any. So while I do appreciate Sean stepping up here,

Re: [address-policy-wg] 2016-04 New Policy Proposal (IPv6 PI Sub-assignment Clarification)

Hi Kai, * Kai 'wusel' Siering > (Which, btw, means there's no difference between PA and PI here. > Thus, End Users must not use DHCPv6 nor WiFi, with NCC'scurrent > interpretation. Eeks.) > > [...] > > And 3rd party usage of IPv6 PI addresses is currently not allowed. > > Well, if reading

Re: [address-policy-wg] 2016-03 New Version and Impact Analysis Published (Locking Down the Final /8 Policy)

* Gert Doering > I consider myself still suitable as a WG chair for the address policy > WG. +1 Tore

Re: [address-policy-wg] 2016-03 Discussion Period extended until 15 July 2016 (Locking Down the Final /8 Policy)

* Elvis Daniel Velea > Additionally, it would still apply retroactively and people which since > 2012 until 'yesterday' were allocated PA/transferable IPs (2 years after > the moment of the allocation) will end up with an allocation that is no > longer transferable. Elvis,

Re: [address-policy-wg] IPv4 reserved space

* Mikael Abrahamsson <swm...@swm.pp.se> > On Tue, 14 Jun 2016, Tore Anderson wrote: > > > The /3 would then within six months be split up into five equal parts > > and be distributed to each RIR over a period of a few years. ~6.4 /8s > > Well, it's only 16 /

Re: [address-policy-wg] IPv4 reserved space

Good morning Arash, * "Arash Naderpour" > My question is that is this working group the right place to discuss > about the 240/3 or it should be done in higher level like between > RIRs or IANA? RIPE AP-WG is not the right place to begin this process, the IETF is. The

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

* Aled Morris > So for all those people who argue we should be preserving the remaining > address space in order to allow for new ISPs entering the market for as > long as possible (which I agree with), we need to be realistic about end > users who want (what was once called) PI space and not

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

* Riccardo Gori > Hi again Tore, > > Il 22/05/2016 12:01, Tore Anderson ha scritto: > > * Riccardo Gori > > > >> and we turn minimum request to a /24 > >> we can address this kind of problem while slowing down LIRs sign up rate > >> to obta

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

* Riccardo Gori > I think I answered, It's not nice to have, It's business demand and LIRs > should be able to offer... with a /22 I can serve just up to 2 or 3 of > my tipical business customers. > This is lack of competitiveness. So, let me get this straight: In order to facilitate growing

Re: [address-policy-wg] 2016-03 New Policy Proposal (Locking Down the Final /8 Policy)

* Radu-Adrian FEURDEAN > As you may know, the "multiple LIRs" is for the moment least expensive > way of getting around the "one /22" restriction. Combined withe the > removal of "need checking", this very much looks like selling /22 to > anybody willing to pay a sign-up and at least one year of

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

* Gert Doering > OTOH, I'm not sure if I see a pressing need here - LIRs that haven't > asked for their /22 yet because they don't need it might just never > show up, because they don't need it... Absolutely true. However, in my opition it would be more about fixing a couple of perception

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 June 2016 (Last /8 Allocation Criteria Revision)

* Riccardo Gori > and we turn minimum request to a /24 > we can address this kind of problem while slowing down LIRs sign up rate > to obtain a /23 or /24 to address this kind of requests This, in isolation, I think is idea worth exploring further. The minimum allocation size started out as a

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

* Riccardo Gori > Thank you to all old LIRs that didn't request their last /22 so I had > the oportunity to request for it early Jan/2015. Marco estimated that the pool would last for around five years under the current policy[1]. For the sake of the argument, let's assume he's spot on, to the

Re: [address-policy-wg] agreement

* Radu-Adrian FEURDEAN > - Second, right now the NCC is just handing out /22 to whoever can > pay for them (with only a small extra administrative restriction > during the last 6 months). For me this is plain "selling IP > addresses" (concept that the NCC avoided like hell int the past), and > it

Re: [address-policy-wg] 2015-05 Discussion Period extended until 13 May 2016 (Last /8 Allocation Criteria Revision)

* "Niall O'Reilly" > On 14 Apr 2016, at 17:01, Jim Reid wrote: > > > I strongly disagree with the proposal > > what Jim said, which you don't need to see again. > Well said, Jim. +1 Tore

Re: [address-policy-wg] 2015-04 New Draft Documents and Impact Analysis Published (RIPE Resource Transfer Policies)

* Gert Doering > On Wed, Feb 03, 2016 at 02:59:06PM +0100, Marco Schmidt wrote: > > The draft documents for version 3.0 of the policy proposal 2015-04, > > "RIPE Resource Transfer Policies" > > have now been published, along with an impact analysis conducted by the > > RIPE NCC. > > So this

Re: [address-policy-wg] address-policy-wg

* Gert Doering > On Thu, Oct 29, 2015 at 05:59:44PM +, Nick Hilliard wrote: > > On 29/10/2015 14:38, Gert Doering wrote: > > > Call to order. Wishing for non-existant technologies to overcome > > > IPv4 shortage is totally off-topic here. > > > > Can I also humbly suggest

Re: [address-policy-wg] 2015-05 New Policy Proposal (Revision of Last /8 Allocation Criteria)

Hi David, * David Monosov > The last /8 allocation criteria is there to ensure an orderly > transition is possible for as long as possible, and the fact we now > expect it to last longer than originally anticipated is further > demonstration of its efficacy. I'm

Re: [address-policy-wg] Policy Proposal Implemented: 2014-05, "Policy for Inter-RIR Transfers of Internet Resources"

* Nikolas Pediaditis > The moratorium that the APNIC EC had set for inter-RIR transfers with > the RIPE NCC has been officially lifted as of early September and it > was announced during APNIC 40. > > The transcript of the APNIC 40 AMM session is available at: >

Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

* "Radu-Adrian FEURDEAN" <ripe-...@radu-adrian.feurdean.net> > On Mon, Sep 14, 2015, at 11:09, Tore Anderson wrote: > > Is there any urgency in getting closer to full exhaustion (i.e., no > > remaining austerity pool)? Is full exhaustion somehow less painful

Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

* "Radu-Adrian FEURDEAN" > 1. Separate pools or single pool > a. have a "last /8 pool" which is 185.0.0.0/8 (strictly one /22 per > LIR) and a "recovered space pool" containing all space received from > IANA as "recovered and redistributed space" (for

Re: [address-policy-wg] "last /8" allocation size - community feedback request before engaging PDP

* "Radu-Adrian FEURDEAN" > > > 3. Further allocation(s) (after the first /22) > > None of the above. My preference is to maintain the status quo - no > > additional allocations. I do not quite see why we should change the > > «last /8» policy which in my view

Re: [address-policy-wg] RIPE IPv4 Allocation Policy

* SBS - Support supp...@sonabusiness.nl That is like running away from responsibility of policing usage based on need and promoting illicit IP trading. If need is justified there has to be a process to allocate additional IP resources. Where do you propose we locate these mythical «additional

Re: [address-policy-wg] RIPE IPv4 Allocation Policy

* SBS - Support supp...@sonabusiness.nl The RIPE policy of allocating only a PA /22 to new LIR's and not allocating any further IPv4 resources is highly detrimental to the growth of new upcoming organisations and protects legacy Telco operators, what are your thoughts on reviewing this and

Re: [address-policy-wg] 2015-01 Proposal Accepted and Implemented?(Alignment of Transfer Requirements for IPv4 Allocations)

* Gert Doering (Funny that people didn't complain when we changed the IPv6 allocation policy to permit /35 holders to extend their existing allocation to a /32 just by asking for it - *that* was a retroactive change of policy...) Indeed. Or when we allowed transfers in the first place. Or

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)

Hi Jens, * Opteamax GmbH as far as I am informed each V6- allocation made by RIPE had always a reserved space after the actual allocation which allows extending upto /27 ... so returning seems not to be necassary ... at least not as long as /27 is sufficient. Actually, the reservation is

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)

* Marco Schmidt You can find the full proposal and the impact analysis at: https://www.ripe.net/participate/policies/proposals/2015-03 I'm generally positive to this proposal, but the impact analysis made me realise that it only applies to *initial* allocations. That causes the new

Re: [address-policy-wg] 2015-03 New Draft Document and Impact Analysis Published (Assessment Criteria for IPv6 Initial Allocation Size)

* Mathew Newton This policy proposal is indeed not intended to cater for those situations and is focussed only on initial allocations. It might sound selfish [...] Not at all. We all scratch our own itches. Been there, done that. :-) In any case, I don't see much of a downside with this

  1   2   >