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

Re: [address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
by JORDI PALET MARTINEZ 15 Jul '19

15 Jul '19

Hi Jim, El 15/7/19 2:16, "Jim Reid" <jim(a)rfc1035.com> escribió: > On 14 Jul 2019, at 22:54, JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg(a)ripe.net> wrote: > > I know that every region is different, but we live in a global Internet, and it is surprising to me that we are the only out of 5 RIRs, that has not done this already. Embrace diversity! I'm fine with diversity, or course! "Because the other RIRs do it" isn't by itself a strong enough justification for the RIPE region to copy them. My point here is that I disagree with not turning non-legacy into legacy. I think this is bad for the community. So as part of the diversity, my point of view is "divergent" with the actual policy, but is the same as the other 4 RIRs. I'm sure in RIPE we have people in one side, the other side, and the middle one. In this particular case, I am not convinced the proposal has any merit. Forcing legacy space to be subject to RIR policy on transfer is just wrong. The holders got that space before the RIRs existed. Which means it's grossly unfair and unreasonable to retroactively make that space subject to RIR policy, even when that space gets transferred. If the legacy holder chooses to do that, fine. However they cannot and must not be compelled to do so. Here is where we disagree. I'm looking for what is best of the overall community, not the best of the legacy owners. I'm very honest here. It was just wrong we got legacy allocations, but it was no other way as the RIRs didn't existed. I think we can try to correct as much as possible past mistakes. Nobody is forcing the existing holders to do the transfers, they can just keep their resources and avoid that. I think is fair that destination holders are in-the-systems mandatorily. Such a policy may also be counter-productive since it (a) could discourage legacy holders from releasing unused space; (b) make such space unattractive to recipients because it would be subject to RIR policies, RIR fees might be payable, etc. (c) introduce uncertainty in the transfer market because donors and recipients get concerned that future transfers of legacy space could get singled out for yet more Bad Ideas. I think it has been demonstrated by the stats of the last 2 years, that (a) is not the reality. (b) this is a community decision, and my personal view is that it should be that way. (c) this will not be retroactive: transfers already done with the exiting policy will not turn into non-legacy (unless they get transferred again). Let's assume your hypothetical proposal became policy Jordi. Would it apply to transfers of legacy space that took place before this policy came into effect? If no, why not? If yes, it would imply all RIR policies have to be retroactively be imposed on legacy holders. I just responded to this (c) above. I'm not considering retroactivity. They will if they become transferred again. I think it's time to introduce a new policy proposal which brings about a moratorium on v4 address policy proposals. > I think this is a benefit for the global community, because ... increase the transparency and community control. Your comment about increased control is deeply troubling. Are you trying to turn the RIR system into the IP address police or the ITU? Do you want to bring about an investigation by the competition authorities? Be careful what you wish for -- you just might get it! You know may answer already: not at all. I meant control by *this* community, by our policy system. Sorry if I was not clear. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

1 0

Home Pest Control Services
by John Thomas 04 Jul '19

04 Jul '19

Exterminator bug services are the best home pest control services without any hassle. You can book our expert pest control with just a few clicks and be saved from all pest problems and trouble. We have a team of professional pest exterminators are well trained, government certified, and have years of experience in pest treatment. We provide you with 100% effective Pest Control Solutions that get rid of household pests like red ants, black ants, carpenter ants, flying ants, and cockroaches. Our expert pest exterminators can save you from diseases caused by pests and other severe damages by providing a completely safe and hassle-free Pest treatment. Pest exterminators are well trained and selected after strict scrutiny. Professional exterminators have thorough knowledge about pests and are entirely reliable and trustworthy. Their pest control services are detailed, and they also provide a free site inspection. They have become the most popular services of pest control for their customer friendly approach and prompt response. https://exterminatorbugservices.com/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

2019-02 Review Phase (IPv4 Waiting List Implementation)
by Marco Schmidt 24 Jun '19

24 Jun '19

Dear colleagues, Policy proposal 2019-02, "IPv4 Waiting List Implementation" is now in the Review Phase. This proposal aims at creating a waiting list based on an allocation size of /24 once the RIPE NCC’s free IPv4 pool is exhausted. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the differences from version v1.0 include: - New proposal title - Focus on waiting list requirements - Adjusting the moment of policy activation The RIPE NCC has prepared an impact analysis on this latest proposal version to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-02 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-02/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussion of the proposal, taking the impact analysis into consideration, and to review the full draft RIPE Policy Document. At the end of the Review Phase, the WG Chairs will determine whether the WG has reached rough consensus. It is therefore important to provide your opinion, even if it is simply a restatement of your input from the previous phase. We encourage you to read the proposal, impact analysis and draft document and send any comments to <address-policy-wg(a)ripe.net> before 4 June 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

9 8

Prefix size
by Sander Steffann 23 May '19

23 May '19

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

1 0

informal discussion about removing 5.4.2. Assignments shorter than a /48 to a single End Site
by JORDI PALET MARTINEZ 22 May '19

22 May '19

Hi all, As commented this morning at the end of the WG meeting, I've been thinking about this issue many times and in fact, in AFRINIC, APNIC and LACNIC, as part of *other* more complex IPv6 policy proposals, we successfully achieved consensus on removing the equivalent text. ARIN has also changed this. In my opinion, the way they handle it, is too complex and not needed, but if someone want to read: https://www.arin.net/participate/policy/nrpm/#6-5-8-2-2-extra-large-sites I've not (yet) done this in RIPE because I thought it is a so small change that doesn't make sense to tackle alone, but this morning I heard otherwise. So ... here we are. By the way, as I always state, I will love some other folks that are willing to contribute, if so let me know in private so we can even organize an on-site meeting. However, in this case I think this policy proposal is just an "empty" one (only remove text, so nothing to draft ...) ... see below. This is our actual text (https://www.ripe.net/publications/docs/ripe-707#assignments_shorter) *** 5.4.2. Assignments shorter than a /48 to a single End Site When a single End Site requires an assignment shorter than a /48, it must request the assignment with documentation or materials that justify the request. Requests for multiple or additional prefixes exceeding a /48 assignment for a single End Site will be processed and reviewed (i.e., evaluation of justification) at the RIR/NIR level. Note: There is no experience at the present time with the assignment of multiple network prefixes to the same End Site. Having the RIR review all such assignments is intended to be a temporary measure until some experience has been gained and some common policies can be developed. In addition, additional work at defining policies in this space will likely be carried out in the near future. *** In my opinion (as I've done in other RIRs), we should just *remove* the complete section. Extreme example case. If an LIR decides to assign /47 to all their customers, and in the future, they need to come back to the NCC for more space, they will need to justify it according to the existing policy at that time. I may understand (even if I don't agree) that somebody want to have the NCC keep doing some evaluation on this. If we want to go this way, we will need to define with a short text what we want. So, opinions? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

2 1

2019-01 Proposal Accepted and Implemented (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 20 May '19

20 May '19

Dear colleagues, Consensus has been reached on 2019-01, "Clarification of Definition for "ASSIGNED PA"". This proposal made it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 The new RIPE Document is called ripe-720 and is available at: https://www.ripe.net/publications/docs/ripe-720 This proposal is implemented with immediate effect. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

2019-01 Last Call for Comments (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 15 May '19

15 May '19

Dear colleagues, Proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"", is now in Concluding Phase. This proposal aims to make it clear in the IPv4 Policy that the status "ASSIGNED PA" can also be used for assignments to an LIR's infrastructure. The WG co-chair has declared that rough consensus has been reached and the proposal will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of this four week Concluding Phase is to give an opportunity to present well-justified objections for those who missed the previous two phases and wish to oppose the proposal. Any objection must be made by 14 May 2019 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the WG Chairs for consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-01 Please e-mail any final comments about this proposal to <address-policy-wg(a)ripe.net> before 14 May 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Agenda for APWG meeting in Reykjavik
by Gert Doering 10 May '19

10 May '19

Dear working group, dear RIPE meeting folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Reykjavik in the side-room (!) in the following time slots: Wednesday, May 22, 09:00 - 10:30 Wednesday, May 22, 11:00 - 12:30 We have two time slots, and the agenda is currently very light. So if you have something you want to see discussed (which is *address policy* related, so no member fee discussions or database stuff :-) ), please approach Erik or me to see whether this would be a good opportunity. Regards, Gert Döring & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. WG chair rotation / re-seating - longest-serving chair (Gert Döring) stepping down - finding a new one or keeping the old one 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 RIPE 77 - brief overview of new proposals (if any) D. Feedback From NCC Registration Service - Nikolas Pediaditis (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals * 2019-02 Waiting List & Reducing IPv4 Allocations to a /24 Y. Open Policy Hour The Open Policy Hour 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, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 5

Application for AS number
by Aled Morris 08 May '19

08 May '19

Hi all I'm in the process of helping a startup ISP get RIPE membership and resources and have hit against a little bit of poor wording in the AS guidelines RIPE-679, specifically: *A network must be multihomed in order to qualify for an AS Number.* The application for an AS number has been delayed because the NCC analyst working on the ticket is claiming the ISP has to be *already multihomed* before an AS can be issued. This interpretation doesn't make any sense to me. Surely the intention *to become multihomed* should be the requirement for obtaining an AS number? I don't even see how you can be properly multihomed if you don't have an AS number. Are we supposed to implement some kind of NAT multihoming first? Can we look to change the wording in RIPE-679 to make this clear? Aled

10 19

AP WG co-chair selection - call for volunteers
by Erik Bais 22 Apr '19

22 Apr '19

Dear working group, Introduction ------------ We will be starting the selection process for the RIPE Address Policy working group co-chair soon. This mail provides information about the process and the call for volunteers. Current Address Policy Working Group Chair Selection Process ------------------------------------------------- The AP working group chair selection process is documented here: https://www.ripe.net/participate/ripe/wg/ap/address-policy-wg-chair-selecti… We have 2 co-chairs and each chair's term is 2 years. About the Process -------------------- Typically until last year, Sander and Gert did this dance together and it was never an actual selection process.. That is, until Sander decided to step down and not run again. To avoid people start on the ML about who they like to support at the beginning with the initial volunteers only, we will do a short call for volunteers of 10 days, by asking the volunteers to send their motivation and intro to the AP-WG Chair email address. ( ap-wg-chairs(a)ripe.net ) Please submit an intro / bio plus motivation, that you understand the impact of being selected as Co-Chair and your intention to be present at the next RIPE meetings before : April 15, 2019 We will then release the names and statements of all applicants after the call for co-chair volunteers closes. And at that time the WG can provide input on the Mailing list on who they like to support as their co-chair. Or if there is specific opposition to a participant, that can also be voiced. For full transparency, it is possible that Gert's name will be added to the list in random order. The actual appointment will be discussed and decided at the next AP session at the RIPE meeting in Reykjavik, Iceland. The remaining chair will determine whether consensus has been reached. And if that isn't somehow possible, a secret ballot will be done by attendees IN the room and counted by the RIPE NCC staff. As always, please feel free to reach out to any of the chairs directly, to us as a group at mailto:ap-wg-chairs@ripe.net, or discuss this or any other any relevant topic on this mailing list. On behalf of your co-chairs Gert Doering and Erik Bais, Kind regards, Erik Bais

2 3