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

Hi, > On 15 Dec 2023, at 15:32, Maximilian Wilhelm wrote: > > Hi folks, > > Anno domini 2023 Peter Hessler scripsit: > >> I still support the proposal as-is. The proposed change does not >> weaken any data that is in the database, and in fact may allow it to be >> more obvious that these

Re: [address-policy-wg] Address Policy WG Co-Chair - James Kennedy Steps Down

Hi! > On Tue, Nov 28, 2023 at 02:23:30PM +, Erik Bais wrote: >> We like to introduce Alex le Heux as a new Co-Chair introduce for >> the following period, so he can see what is involved in the role >> as a Co-chair. > > Support! > > (Wrote longer paragraph on "lots of experience, good

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

> - realise that the current internet is not the internet that this DB was > designed for > > Might as well stop issuing policy at all, then. The thought did cross my mind ;) Cheers! Sander -- To unsubscribe from this mailing list, get a password reminder, or change your subscription

Re: [address-policy-wg] 2023-04 Are anonymised assignment objects valid?

Hi, > I think I mostly agree with Nick here and I feel like Tore is a bit > dismissive of the concerns raised by denis. > > I don't really feel that strongly about this policy proposal in itself > but I do now see that it is a significantly larger change than Tore > suggests that it is. > I

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

Hi, > A new RIPE Policy Proposal, 2023-04, "Add AGGREGATED-BY-LIR status for IPv4 > PA assignments" > is now available for discussion. > > This proposal aims to introduce the AGGREGATED-BY-LIR status for IPv4 PA > assignments to reduce LIR efforts in registration and maintenance. I agree with

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

Hi, > Silence is consent, in other words. I have therefore intentionally not > commented on this proposal during Last Call. +1 to this, that’s how Gert and I always implemented it, and how I would like it to remain. Last call is a “speak now, or forever hold your peace” phase :) Cheers! Sander

Re: [address-policy-wg] Input Requested: How to Ensure Responsible ASN Resource Management

Hi WG, At some point in the past we had a discussion about making it easier to request ASNs, basically removing the multihoming requirement. This working group at the time decided to not do this because it *might* cause someone to ask for an insane number of ASNs and overload the RIPE NCC. A

[address-policy-wg] RIR Policy Proposal overview

Hi everybody, I created a quick overview page of all the policy proposals in the different RIRs: https://proposals.nogalliance.org/ Hope you find this useful! Cheers! Sander -- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please

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

Hi, >>> Assignments strictly larger than a /24 will only be made to IXPs that >>> offer the exchange of IPv4 routing information over IPv6 at their >>> route servers >> >> As far as I understand, this protocol is not widely deployed in IXPs, >> nor is it widely tested in inter-AS production

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

Hi, > Marco pointed out in the WG session, that we should probably start a > discussion on the lower boundary of assignments from the IXP pool. I would > like to kick off this discussion with this post. To add to this discussion: I took this to the Connect WG, and the initial feedback I got

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine

Hi Hans Petter! > I would encourage you to have a look at the article outlining some of the > alternatives: > https://labs.ripe.net/author/athina/protecting-resource-holders-in-distressed-areas/ > Yeah, I did read that. I just don’t agree with the arguments. > While this might seem like an

Re: [address-policy-wg] [ncc-announce] [news] RIPE NCC Response to Committee of the Verkhovna Rada of Ukraine

Hi Hans Petter, > Today we responded to a request from the Committee of the Verkhovna Rada of > Ukraine on Matters of National Security, Defense and Intelligence to discuss > measures to protect Internet number resources in Ukraine. We have published > this on our website: >

Re: [address-policy-wg] Potential Improvements to the Temporary Internet Number Assignment Policies

Hi, > On 12 Oct 2022, at 12:36, Nick Hilliard wrote: > > Marco Schmidt wrote on 11/10/2022 11:49: >> One possible solution would be to review the current policy and propose a >> policy change, for example the introduction of a minimum IPv4 assignment >> size. >> Does the working group agree

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

> Op 4 okt. 2022 om 17:46 heeft Randy Bush het volgende > geschreven: > >  >> >> Again we are back to asking the question, "What is the purpose of the >> RIPE Database in 2022?". > > in this case, same as it ever was. same as it ever was. And you may ask yourself “what is this RIPE

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

Hi, >> To break it down by rationale: >> >> "One of the main reasons for registering IPv4 PA assignments was that LIRs >> could show their use of IPv4 and thus justify the request for an additional >> IPv4 allocation from the RIPE NCC. However, this requirement has become >> obsolete since

Re: [address-policy-wg] ripe-587, Temporary Internet Number Assignment Policies

> Given that there seem to be people that actually get work done in their > research, using IPv4 because not all vantage points have IPv6 yet, and > that the existance of this policy seems to do little harm, I'd strongly > object to such a proposal. > > This is not the place and time to go on an

Re: [address-policy-wg] IPv4 waiting list policy

Hi Mathias, > I will be quite frank about this and say that it feel very disheartening to > essentially miss the 0 day queue allocations by 5 days. end up in a one month > long quque that just grows with no more allocations and on top of that it is > VERY obvious that these organisations uses

Re: [address-policy-wg] IPv4 waiting list policy

Hi Denis, > What is going to stop people selling these 'never to be > transferred' allocations and not recording the transfer in the RIPE > Database? The fact that the LIR can’t be closed. Having to remain a member and pay the membership fee for as long as you want to use the allocation is

Re: [address-policy-wg] IPv4 waiting list policy

Hi, >> On 7 Dec 2021, at 14:56, Gert Doering wrote: >> >> My suggestion would be along the lines what was proposed on the APWG >> meeting already - earmark these /24s as non-transferrable, ever. > > +1 WFM +1 from me as well. This would have very little (if any) impact on the newcomers for

Re: [address-policy-wg] IPv6 Stockpiling

Hi, > One reason for a LIR to have multiple /29 is when a lir (ISP in this case) > buys smaller operators and consolidates them. > Since all of these blocks had some use before consolidation and its tedious > to renumber > > I don’t see this as stockpiling, they will be even more in use in

Re: [address-policy-wg] Draft agenda AP-WG RIPE82 - virtual AP-WG

Hi chairs! On Mon, 2021-04-26 at 10:50 +, Erik Bais wrote: > Second this is going to be last WG session with our faithful Gert as > co-Chair of the WG, as he is going to step down. > And because he started RIPE 44 in Amsterdam, 2003 as chair for the > LIR-WG (now AP-WG), he is probably one of

Re: [address-policy-wg] a third WG co-chair

Hi Jim, On Fri, 2021-04-09 at 15:55 +0100, Jim Reid wrote: > Please remember that 10+ years ago -- when tinkering with IPv4 > allocation policy was at its peak -- Gert ran the WG all by himself. That is actually not true. I volunteered to become co-chair immediately after the APWG session where

Re: [address-policy-wg] WG chair rotation 2021

Hi Erik and Gert, On Fri, 2021-04-09 at 12:20 +, Erik Bais wrote: > Me and Gert had the pleasure on working with Leo and James in the > last 6 months on topics in relation on the AP-WG related stuff. > And I would suggest to the working group to extend, if the WG agrees, > to accept both

Re: [address-policy-wg] [policy-announce] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space)

Hi, > This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 > for all unallocated and unassigned address space under its control. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2019-08 I have read the policy and I don't see

Re: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy)

Hi, > A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 > Policy" > is now available for discussion. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. I think this is a sensible update. Support. Cheers, Sander

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

Hi, > Op 11 aug. 2019, om 22:16 heeft Randy Bush het volgende > geschreven: > >> I strongly agree with Nick and support version 2.0. No need to produce >> a revision changing the default away from /24. > > how about /24.5? :) Brilliant idea ;) > enough already. ship it. I agree, it's a

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

Hi, > I belive the community should focus strongly on an accurate registry as the > main principle. This ^^^ Sander signature.asc Description: Message signed with OpenPGP

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

Hi Jordi. > I know about ripe-639. > > What I’m saying is that we force the change of status from non-legacy to > legacy if addresses are transferred to a new member or an existing member, as > both of them will have all the legal bindings already with RIPE NCC. A legal entity can have zero,

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

Hi Kai, > I don't see this either, hence, while I agree that there should be some > wording about the way the (already implicit) waiting list will be > implemented/handled, I reject the proposal as-is due to the reduction of the > assignment size. > > Reducing the assignment for new LIRs from

[address-policy-wg] Prefix size

Hi, Yesterday in the APWG session I promised to go to the routing WG and notify them of the possibility of IPv4 prefix lengths growing longer than /24 in the future. I think Geoff Huston just already made an excellent presentation that included that point, so thank you Geoff! Cheers, Sander

Re: [address-policy-wg] Application for AS number

Hi Paul, > I personally have no problem with making it easier to obtain an AS if you > intend to multihome at some point in the future (measured in years if > necessary - let people who want to do the Right Thing from day one do that). > There are plenty of 32 bit AS numbers available, they

Re: [address-policy-wg] PA – life after death

> We did not convert to PA. But unfortunately they did not know that it was > necessary to keep Sponsoring with a third party. I'm a bit confused. What exactly are you doing? - Is the legal entity that was an LIR stopping? If the legal entity disappears then the resources go back to the NCC -

Re: [address-policy-wg] IPv6 PI justification requirements

Hi, > As I attempted to explain this was 3 separate uses that required separate > announcements. To keep things more clear, maybe it's easier to send three separate requests. Each for a /48 with the description where/how that one is going to be used. Combining things into one request might

Re: [address-policy-wg] IPv6 PI justification requirements

Hi Cynthia, > I have also been informed that this might be a rather unique case in regards > to having multiple physical locations requiring PI space. Not unique at all. That is why the explicit "different routing requirements" rule was included in the policy :) Cheers, Sander

Re: [address-policy-wg] IPv6 PI justification requirements

Hi Cynthia, > I am in the process of requesting 3x /48 of IPv6 PI for a customer, and what > confuses me is that the NCC requires way more justification for 3x /48 of PI > than for 2x /29 of PA. > > I do think that saying something like net1 will be used in the Netherlands, > net2 in London,

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

Hi, > I oppose this proposal, unless at least RIPE NCC will charge members based on > how much IPv4 space they have. Sorry, membership fee structure is out of scope there. The NCC members decided years ago to adopt a membership-based-fee instead of a resource-based-fee. It's not up to this

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

Hi Michiel, > Just another point for discussion: what to do when this /24-only policy is in > effect and RIPE NCC happens to recover a large chunk (e.g. /16 or more) and > is able to hand-out multiple /22's again? The policy explicitly states that once the waiting list policy is in effect the

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

Hello working group, The first comments I got back on this proposal all seemed to miss the point of it. Let me explicitly state what this policy is NOT about: - it is NOT about conserving IPv4 addresses - it is NOT about postponing the runout date - it is NOT about extending the lifetime of IPv4

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

Hi Martin, > I don't think that we have to change current policy at all. > > Current policy allows to get /22 divided to smaller blocks, so it doesn't > have to be changed just because of this. > > My personal opinion on IPv4 exhaustion is that it would be better to come > sooner than later.

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

Hi Jim, > A policy to deal with whatever /24s the NCC might find stuffed down the back > of the sofa will be more bother than its worth. Unless someone can provide > compelling arguments -- ie there’s still a lot of v4 for the NCC to allocate > -- I just don’t see the point. Sorry. > > How

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

Hi Raymond, > The current policy does not become useless: > > "In case an allocation of a single /22 as per clause 1 can no longer be made, > multiple allocations up to an equivalent of a /22 in address space will be > made to fulfill a request." is in the current proposal. Ok, that will

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

Hello Francis and Jim, > We do not agree with this proposal. > > Sooner or later RIPE IPv4 address space will run out. Moving from /22 > to /24 will not change that, which is the essence of the question, but > doing so will create more fragmentation (BGP, smaller LIRS, cost > unfairness between

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

Hi Raymond, > To make it more clear what I mean, a /24 will not be enough to connect a say > /29 IPv6 to the v4 world, a /22 ( or any range of addresses up to a /22 in > size ) is not enough either. Therefore I support the current policy, and am > against the new proposal. Can you please

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

Hi Denis, > This sounds reasonable to me. > Newcomers can still get a share while transitionning to IPv6 :) > > Is there an incentive to make ops accept longer-than-/24 as a next step ? No, at the last RIPE meeting consensus was that longer-than-/24 was not worth it. Cheers, Sander

Re: [address-policy-wg] Policy violation

Hi Aleksey, > On the 7th of September the NCC implemeted the document > https://www.ripe.net/publications/docs/ripe-709#transfer35 (The document is > published on the 21th of September). The support clarify it that you cannot > merge one LIR into the second LIR in case of M procedure because

Re: [address-policy-wg] country code in ORGANISATION object

Hi Denis, > The DB part is simply to add an attribute. The mechanics of that is pretty > straight forward. The reason for adding it and its strict definition and > perhaps status as a 'fixed' attribute value are more address policy or > services. I don't think it fits in APWG. It doesn't

Re: [address-policy-wg] [CFP] ACM/IEEE IPSN 2019 in CPSWeek

Hi Nick, > Could the chairs please be more proactive about ensuring that APWG's > anti-spam policy is applied? > > IEEE conference spam in particular seems to be a problem going back many > years. As an ex-chair I can assure you no such message goes unanswered. Every single one of them gets

Re: [address-policy-wg] Feedback needed for 2018-03 (Fixing Outdated Information in the IPv4 Policy)

Hi Andrea, > Policy proposal 2018-03 aims at fixing outdated information in IPv4 Policy, > like outdated references or values of inetnum objects in the RIPE Database. > > While I am aware this is not the most exciting of the current policy > proposals, it is important to keep the content of

Re: [address-policy-wg] WG chair change

Hi Sean, > In the interest of easing consensus in the address policy community, I would > like to withdraw my candidacy for WG chair. I strongly encourage everyone to > support Erik as the future WG chair based on the significant work he has done > for the community over the last several

Re: [address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2

Hi, > What is 2018-03 Fixing Outdated Information in the IPv4 Policy? > > I cannot find it in the NCC website. We gave the RIPE NCC an action item to look at outdated information/references/etc in the policy. This proposal will be their suggested fix. It's not published yet, but we know it

[address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2

If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Regards, Gert Döring & Sander Steffann, APWG chairs -- Wednesday, 09:00-1

[address-policy-wg] Agenda for APWG at RIPE 76 in Marseille

to change anything, please let us know. Regards, Gert Döring & Sander Steffann, APWG chairs -- Wednesday, 09:00-10:30 -- A. Administrative Matters (wel

Re: [address-policy-wg] WG chair change

Hello working group! As Gert has announced last month: I'm stepping down as co-chair of APWG at the next RIPE meeting in Marseille. So far we have two candidates who have volunteered to serve you all as new co-chair: - Erik Bais - Sean Stuart If there are more people willing to volunteer:

Re: [address-policy-wg] [CFP] 2nd Asia-Pacific Workshop on Networking (APNet 2018)

Hello, The RIPE Address Policy working group mailing list is for discussions regarding policy proposals for the RIPE region. Please refrain from posting CFPs to this list. Sincerely, Sander Steffann Address Policy WG co-chair > Op 21 feb. 2018, om 18:31 heeft ap net <apne...@gmail.co

Re: [address-policy-wg] inconsistency in 2016-04

Hi, > Below in-line. Please use normal quoting, I have trouble reading your emails. > Right, but 6) IA say: "... There are cases where a /64 is needed per customer > to provide a separate address ..." and 8) IA say: "... by using single IPv6 > addresses for End User devices and services ..."

Re: [address-policy-wg] inconsistency in 2016-04 (was: what does consensus mean)

Hi Jim, > PLEASE put those comments in a different thread which makes it clear you're > discussing detail about 2016-4 (or whatever). Thanks. > > This thread's supposed to be about an entirely different topic. Indeed, my apologies. There were so many things going on that I lost track as well

Re: [address-policy-wg] what does consensus mean

Hi, > 1) Temporary always ? clearly not for point-to-point links, no-sense for data > centers? Indeed, this is what I asked Marco. > 2) Single address (/128) for a single device (so the device can't use > privacy? Utopia!), or do we allow if the devices get a single-prefix, it uses >

Re: [address-policy-wg] what does consensus mean

Hi Jordi, > 1) Policy text say: "... separate addresses (not prefixes) ...". > 2) Max proposal say: "... or anything alike where devices of non-members of > the organisation would get assigned an IP out of the organisation’s prefix > ..." > 3) Max proposal say: "... Explicitly allowing another

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

Hi Jordi, > “Providing another entity with separate addresses (up to /64) from a subnet > used on a link operated by the assignment holder is not considered a > sub-assignment. This includes for example, letting visitors and/or employees > (BYOD) connect to the assignment holder's network,

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

Hi Jordi, > [Jordi] I think we are in-sync, but your response clearly demonstrates that > there is a need for clarifying the text. > -> Policy proposal “Providing another entity with separate addresses (not > prefixes)” > -> a /64 is a prefix Technically, because the router is the PI holder's,

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

Hi, > My reading of PDP 2.4 is [..] Please stop being a lawyer. I have told you how we do things in this working group. Please listen to what the chairs are telling you. > My reason to re-raise those now, is because they become evident when you > compare the proposed 2.6 change with the

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

Hi Jordi, > The point is not only the PDP, as I believe we are still on time to correct > the policy proposal, which I think is broken and contradicting itself. > > See my last email on the details, and a proposed text to resolve it, which > according to the PDP, we can still apply I think We

Re: [address-policy-wg] 2016-04 To Last Call (IPv6 Sub-assignment Clarification)

Hi Jordi, > I participate on IETF, and I know RFC7282, however I fail to see in our PDP > that we are bound to that RFC? As Jim has said, the definition of consensus is determined by consensus :) And for this working group the chairs apply consensus roughly based on that RFC. > I also just

Re: [address-policy-wg] what does consensus mean

Hi Jordi, > I agree that is not “unanimity”, but I don’t think there is consensus on this > proposal, and even less I think is fair to extend the review period “because” > a proposal has been brought in the last minute to another fora, when the > chairs already declared “that we don’t have

Re: [address-policy-wg] 2016-04 Review Phase (IPv6 Sub-assignment Clarification)

Hi Jordi, > I think Jan comments (in the meeting, hopefully he can repeat here) are very > relevant, and I’ve a draft policy proposal in that direction, I’m waiting for > my co-author review to submit it. If you are talking about a RIPE policy proposal: please don't. Having multiple

Re: [address-policy-wg] Agenda for APWG in Dubai (v1)

Noted, we'll refer people to anti abuse when discussing open policy proposals. Marco: I assume this is already on your list, but please double check :) Cheers, Sander > Op 25 sep. 2017 om 14:02 heeft Malcolm Hutty het volgende > geschreven: > > Dear WG Chairs, > > This is

Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi, > Op 24 sep. 2017, om 20:42 heeft Randy Bush het volgende > geschreven: > They are beyond help >>> >>> not at all. the vendors are more than happy to sell them CGNs, and >>> other NATs of many flavors. >> >> Sorry, I should have specified "from a IPv4 allocation

Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi, > Op 24 sep. 2017, om 04:55 heeft Randy Bush het volgende > geschreven: > >> They are beyond help > > not at all. the vendors are more than happy to sell them CGNs, and > other NATs of many flavors. Sorry, I should have specified "from a IPv4 allocation policy point of

Re: [address-policy-wg] 2017-03, New Policy Proposal (Reducing Initial IPv4 Allocation, aiming to preserve a minimum of IPv4 space)

Hi, > So again, why do they rely on v4 (only) ? I really want to understand > hurdles on european continent. I think the hurdles are roughly the same in all regions. Relying on only IPv4 is insanity, and those that do so deserve no sympathy. But as you have personally experienced IPv6 isn't

Re: [address-policy-wg] Agenda for APWG in Dubai (v1)

d by the RIPE NCC, who will then pass it on to the DTCM. The data will be permanently deleted from the RIPE NCC infrastructure one week after the RIPE 75 Meeting. Cheers, Sander Steffann APWG co-chair signature.asc Description: Message signed with OpenPGP

[address-policy-wg] Agenda for APWG in Dubai (v1)

planning to present their policy. Attendees speaking at the microphones during the Q are explicitly not considered as speakers. Regards, Gert Doering & Sander Steffann, APWG chairs ---

[address-policy-wg] 2016-05 going to last-call (Synchronising the Initial and Subsequent IPv6 Allocation Policies)

consensus and asked the RIPE NCC to move the proposal to the Last Call phase. The positive feedback to the current version was from: - John Collins - Ian Dickinson - Sascha Knabe - Martin Krengel - Frank Meyer - Mathew Newton Thanks to the working group for working on this proposal, Sander Steffann

[address-policy-wg] Proceeding with proposal 2016-04 (IPv6 PI Sub-assignment clarification)

Hello working group, The end of the discussion phase of proposal 2016-04 (IPv6 PI Sub-assignment clarification) has been reached. At this point in the PDP the proposer, in agreement with the working group chairs, decides whether to move forward. The chairs have determined that we have general

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

Hi Ciprian, > Actually there were cases where we did like that, being put as a contact for > the LIR. I don't think this should be the solution as it doesn't seem > adequate at least. There were also cases where we would have to "speak" on > behalf of both parties so it would be awkward if not

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

Hi Ciprian, > There is, though, an important thing which I think the policy needs to > address. The broker should be allowed to discuss with ripe on behalf of his > customers. It has happened several times that we had customers who don't > understand english very well and many times they would

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

Hi Ciprian, > I've heared this story over and over. Let's protect the pool, let's not waste > it and now, after 4 years the pool is almost the same size. The only reason that the pool is the size it is is because we received some last scraps from IANA. The number of addresses coming from IANA

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

Hi Radu-Adrian, > ... and this is where technical implementation comes and messes things > up > If you are functioning in "subscriber management" mode, you equipment > may impose you that each subscriber has its own subnet for > interconnection (mine does) - obvious choice being a /64. I

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

Hi Arash, > I understand your point, but this already happened with other RIRs and they > have no "cheap" pool to fulfil new requests, what happened them and to the > prices in their region? Do we have many intra-RIR transfers from RIPE region > to other RIRs today? Good question. I'm sure the

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

Hi Kai, > So, since anything _above_ /64 (e. g. /65 to /128) would be whitewashed by > the proposal, using a whole /48 PA or PI for /64s for WiFis would be ok, as > long as each WiFi user only gets less than a /64 »assigned«? That's what the proposal currently says. > Proposal states:

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

Hi Leo, > So prefix delegation is OK as long as the prefix is longer than a /64? Technically that's what the proposal is currently proposing. I'm curious about the opinions of working group members about that. Cheers, Sander

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

Sorry, bad auto correct: > [...] need to come up with arguments and valid training That should be "reasoning" > that can be discussed. Your message only contains ad hominem attacks and wild > and inaccurate statements and is therefore for useful That should be "not useful" > for the policy

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

Hi, > Yes, thanks to old members who didn’t care about the future of others and > made this mess. Please read my previous post. > Thanks to members like http://ipv4.stil.dk and many many more who requested > huge amount of IP space without a real need, now selling them for profit. > > Thanks

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

Hi Arash, > If old businesses depend on selling IPv4 address to new comers and now > looking to put some more value on their old blocks, their strategy should > not be supported by 2016-03. I'm sorry, but it's doing the opposite: it will make sure that the remaining pool is not drained by

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

Hi Erik, > Going into that kind of thinking would be similar to not allowing external > voice calls to IPv6 PI assigned phones, because some third party should be > able to make use of it.. > > This discussion is different if we are actually (commercially) hosting > services on a

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

Hello Ciprian, > It is also beyond the scope of this policy regulating what can be done with > resources and we're still discussing it. Let's stick to the policy's scope > and start a new one with proper debates over this issue. Please leave it to the chairs to determine what is in scope for

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

Hi Mikael, > These post-2012 members would have ZERO IPv4 addresses from RIPE NCC if it > wasn't for the Last /8 policy, we would have completely exhausted in 2012 > without this policy. > > So they were only able to get addresses at all because these addresses were > saved to be used under

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

Hello Sergey, > If I am not wrong, the main idea of the NCC is to switch to IPv6 > networks. But it strongly tries to stretch this process. You seem to misunderstand how this works. It is the community that sets these policies, not the NCC. The RIPE NCC implements what the internet community

Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

Hello Elvis, > Therefore, I think that the RIPE NCC should talk to every single company > holding a PI assignment from an ALLOCATED PI/UNSPECIFIED block and give > them the option to give up on the maintenance of the IPs (and the right > to transfer/sell) and transform them into ASSIGNED PA, or

[address-policy-wg] ALLOCATED PI / UNSPECIFIED next action

Hello working group, The discussion on how the RIPE NCC should deal with ALLOCATED PI / ALLOCATED UNSPECIFIED has died down a couple of weeks ago. We therefore think that it is time to draw conclusions. A total of 16 people and the working group chairs participated in the discussion following

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

Hello Marius, > Thank you for the explanations, but I believe you haven't really addressed > the issues I mentioned. > The first issue is ABOUT Transfer Policies, to pay the annual membership fee > after you TRANSFER ALL YOUR RESOURCES and maybe even close your Company, is > about Transfer

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

Hi, > Op 19 okt. 2016, om 14:59 heeft Peter Hessler het > volgende geschreven: > > Ciprian > > You have invoked Nazis and Hitler in two different emails to this list. > > This is incredibly offensive, for so many reasons. Ok, this is indeed going too far. Time for an

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

Hello Marius, > Over the last years RIPE NCC has imposed a "rule" that when the last IPs are > transferred the transferring LIR has to pay the full annual membership fee > (even if the LIR was not a member of RIPE for that entire year). I think that > if this is something everybody agrees

Re: [address-policy-wg] Idea for aggregating IP addresses

Hi, > "non-continuous IPv4 blocks be exchanged for the equivalent size in a single > continuous IPv4 block" I think the problem with this is that it let's spammers exchange dirty blocks for clean blocks. Cheers, Sander smime.p7s Description: S/MIME cryptographic signature

Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED

Hi Ingrid, > If there is a /16 “ALLOCATED UNSPECIFIED” block that contains "real" Provider > Independent assignments, that /16 would indeed be split in order to carve out > that assignment. The LIR would end up with multiple PA allocations instead of > one /16. The PI resource holder would be

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

Hi Elvis, >> I've had easier discussion to judge, and less repetitive-nonsensical ones. > > it says awaiting decision from proposer and not from WG Chairs. That is why I > was asking the proposer. Just for clarity, this is what the PDP says: > [RIPE-642 section 2.2] > At the end of the

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

Hi, > Ah, that one. Thanks for the link-local I was getting confused by the mixed > arguments about ALLOCATED PI. My auto-complete is getting too used to IPv6 terminology ;) s/-local/./ Cheers, Sander signature.asc Description: Message signed with OpenPGP using GPGMail

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

Hi Radu, >>> PI can be converted in PA easily in RIPE >> >> ??? > > https://www.ripe.net/manage-ips-and-asns/resource-management/converting-pi-to-pa > > ASSIGNED PI -> ALLOCATED PA on request. Ah, that one. Thanks for the link-local I was getting confused by the mixed arguments about

Re: [address-policy-wg] another way to achieve the original motives of post-exhaustion policy

Hi Mikael, > I just had a thought. > > What we're trying to do is to make sure there are IPv4 addresses available to > new entrants. We're trying to do this by making a LIR get one post-exhaustion > /22 each. The LIR fee is the limiting factor in trying to stop people from > getting many

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

Hi Randy, > i have had an epiphany! RIR stands for Rinse and Infinite Repeat. this > expains it all. i feel much better now. Good one ;) Sander signature.asc Description: Message signed with OpenPGP using GPGMail

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

Hi Patrick, > What about assignments from the ALLOCATED FINAL? Will it be "ASSIGNED FINAL"? > Or partitioned space "LIR-PARTITIONED FINAL" :-) Nope, only the allocation will get a different status. The LIR can still use it like before, assign from it etc. Cheers, Sander signature.asc

  1   2   >