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

2019-05 New Policy Proposal (Revised IPv4 assignment policy for IXPs)
by Marco Schmidt 05 Sep '19

05 Sep '19

Dear colleagues, A new RIPE Policy proposal, 2019-05, "Revised IPv4 assignment policy for IXPs" is now available for discussion. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-05 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposers, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 27 June 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

29 70

New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations
by Mirjam Kuehne 28 Aug '19

28 Aug '19

Dear colleagues, On 17 April 2018, we allocated the last available block of 1,024 addresses in 185/8 - the last /8 we received from IANA back in 2011. This article on RIPE Labs looks at how this address space was allocated and how it is used today: https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the… It's important to keep in mind that while 185/8 is finished, we still have around nine million recovered IPv4 addresses in our available pool. Under current policy and growth rates, we expect these to last a further two years. Kind regards, Mirjam Kühne RIPE NCC

3 2

Staff participation in the IP market
by Ronald F. Guilmette 19 Aug '19

19 Aug '19

Please forgive me if this question is deemed inappropriate for this specific mailing list and working group. This seems to be the most appropriate WG for my question. I hope also that no one will take any offense nor any unstated implication from my question. I intend to put this question also to the communities of each and every one of the five global Regional Internet Registries. Nothing should be inferred from the fact that I am starting this process in the RIPE region. My question is a simple one: Are policies in place, within the RIPE region, which prohibit RIPE NCC staff members from participating in the current open market for IP addresses? I do believe that everyone on this mailing list must be well and truly aware of that fact that the buying, selling, and trading of IPv4 addresses is nowadays a lucrative and growing business. It should also be altogether clear and apparent that RIPE NCC staff could, if permitted to do so, leverage their significant and special ``insider'' knowledge to gain some advantage in this market, relative to other market participants. Thus, I wish to know simply if such participation is or is not currently prohibited or allowed by current applicable staff policy. To reiterate, nothing at all should be inferred from my question. I am most assuredly not making any allegations nor even any vague implications by my question. This general question came up in an unrelated context, and now I just want to know whether or not each of the five regions have policies in place with respect to staff participation in the burgeoning IP address market. Regards, rfg

2 2

2019-05 Review Phase (Revised IPv4 assignment policy for IXPs)
by Marco Schmidt 08 Aug '19

08 Aug '19

Dear colleagues, Policy proposal 2019-05, "Revised IPv4 assignment policy for IXPs" is now in the Review Phase. This proposal aims to increase the reserved IPv4 pool for IXPs to a /15 and finetune assignment criteria. The proposal has been updated following the last round of discussion and is now at version v2.0. Some of the changes made to version v1.0 include: - The maximum assignment size to IXPs remains /22 - Defines that IPv4 ranges smaller than /24 will be added to the IXP pool 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-05 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-05/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 Working Group (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 6 September 2019. Kind regards, Marco Schmidt Policy Officer RIPE NCC

1 0

2019-02 Proposal Accepted (IPv4 Waiting List Implementation)
by Marco Schmidt 31 Jul '19

31 Jul '19

Dear colleagues, Consensus has been reached on 2019-02, "IPv4 Waiting List Implementation". This proposal aimed at creating a waiting list based on an allocation size of /24 once the RIPE NCC’s free IPv4 pool is exhausted. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 The new RIPE Document is called ripe-725 and is available at: https://www.ripe.net/publications/docs/ripe-725 We estimate that this proposal will take around one to two months to fully implement. We will send another announcement once the implementation is complete and the new procedures are in place. Thank you to everyone who provided input. Kind regards, Marco Schmidt Policy Officer RIPE NCC

2 2

2019-02 Last Call for Comments (IPv4 Waiting List Implementation)
by Marco Schmidt 26 Jul '19

26 Jul '19

Dear colleagues, Proposal 2019-02, "IPv4 Waiting List Implementation", is now in Concluding 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 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 24 July 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 co-chairs for final consensus. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-02 Please e-mail any final comments about this proposal to <address-policy-wg(a)ripe.net> before 24 July 2019. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?
by JORDI PALET MARTINEZ 24 Jul '19

24 Jul '19

Hi all, 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 to non-legacy, when they got transferred. I don't really recall if this was discussed during the relevant proposal discussion, and it will be great if someone can summarize it (I guess the author or chairs, or even the staff). I think we should consider amend that, unless the reasons it was not done at that time, persist today, or even if those reasons persist, may be the community has a different view. I think the text should be something such as: IPv4 legacy resources will no longer be regarded as legacy resources: - In the case of intra-RIR transfers. - In the case of inter-RIR, when incoming to RIPE service region. I think this is a benefit for the global community, because with that, we bring into the RIR system more and more legacy IPv4 resources, which increase the transparency and community control. In a presentation from ARIN for the 2016-2018 period it has been mention: - Overall space managed by ARIN decreased by ~14 million IPv4 addresses, due to Inter-RIR transfers - Overall ARIN issued space increased by ~30 million IPv4 addresses, due primarily to conversion of legacy space via in-region transfers Opinions? Regards, Jordi @jordipalet ********************************************** 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.

19 70

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

Clarification of Address Policy wording, Take 3...
by ripedenis＠yahoo.co.uk 22 Apr '19

22 Apr '19

Colleagues We really need some help from you guys who understand, and possibly wrote, (parts of) the IPv4 address policy. The most confusing part is this: 6.2 Network Infrastructure and End User Networks When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. Perhaps to some of you the intent of this is clear. But when I read these words I see ambiguity. Does the policy only require (tech/admin/abuse) contacts, or does it require publishing some details about who is operating the network? Help desks can be outsourced. So tech/admin/abuse contacts may not directly relate to the 'End User'. The policy appears to ask for contact details of the 'End User'. Also the second sentence is referring to the 'End User' as an individual or an organisation. Substitute that back into the first sentence and this policy is asking for 'contact details of the individual or organisation'. This is not the same as the tech/admin/abuse contacts. So what does anyone else understand from this wording? Or maybe the question should now be 'what details need to be published in the RIPE Database about these End Users, for what purpose and who needs it?'. cheersdenis co-chair DB-WG

3 3

2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")
by Marco Schmidt 13 Apr '19

13 Apr '19

Dear colleagues, Policy proposal 2019-01, "Clarification of Definition for "ASSIGNED PA"" is now in the Review 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 RIPE NCC has prepared an impact analysis to support the community’s discussion. You can find the full proposal and impact analysis at: https://www.ripe.net/participate/policies/proposals/2019-01 And the draft documents at: https://www.ripe.net/participate/policies/proposals/2019-01/draft As per the RIPE Policy Development Process (PDP), the purpose of this four week Review Phase is to continue discussing 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 9 April 2019. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

14 13

Clarification of policy requirements for contact information
by ripedenis＠yahoo.co.uk 12 Apr '19

12 Apr '19

Colleagues, Elvis, James and myself have started talking about personal data in the RIPE Database. I said we would bring sub issues to the community when we need direction or clarification. We looked at three policy documents maintained by AP-WG and have a few questions. Before we look at WHERE and HOW the data is stored, we would like to get community feedback on exactly WHAT contact details should be published as per current policies? Below are the quotes and links to the 3 policy documents we looked at. cheersdenisco-chair DB-WG In the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" (ripe-708) [1] first mention about contact data is 4.0: "4.0 Registration Requirements All assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations. Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained)." and then in 6.2: "6.2 Network Infrastructure and End User Networks IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure. These addresses do not have to be registered with the End User's contact details but can be registered as part of the service provider's internal infrastructure. When an End User has a network using public address space this must be registered separately with the contact details of the End User. Where the End User is an individual rather than an organisation, the contact information of the service provider may be substituted for the End Users. [...]" In the "IPv6 Address Allocation and Assignment Policy" (ripe-707) [2] the requirement is even more vague in 3.3: "3.3. Registration Internet address space must be registered in a registry database accessible to appropriate members of the Internet community. This is necessary to ensure the uniqueness of each Internet address and to provide reference information for Internet troubleshooting at all levels, ranging from all RIRs and IRs to End Users. The goal of registration should be applied within the context of reasonable privacy considerations and applicable laws." The "Autonomous System (AS) Number Assignment Policies" [3] does not mention anything about contact data requirements. [1] https://www.ripe.net/publications/docs/ripe-708[2] https://www.ripe.net/publications/docs/ripe-707[3] https://www.ripe.net/publications/docs/ripe-679

5 6

RIPE 77 Address Policy WG Draft Minutes
by Marco Schmidt 21 Mar '19

21 Mar '19

Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 77 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-77-address-policy-… Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

2019-02 New Policy Proposal (Reducing IPv4 Allocations to a /24)
by JORDI PALET MARTINEZ 16 Mar '19

16 Mar '19

Same here, sorry, I've not participated in the discussion, a bit overloaded with daily work, but just read all the thread, and I'm supporting it. Further I can add some data. I've participated in APNIC 47, and prop-127, which is mention in this proposal, reached consensus. I've also discussed the same topic in the LACNIC mailing list, and I'm considering a similar proposal there. To be clear, I'm talking about the same as APNIC prop-127, which is moving the maximum allocation from /22 to /23. 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.

1 0

2019-01 Review Phase (Clarification of Definition for "ASSIGNED PA")
by JORDI PALET MARTINEZ 16 Mar '19

16 Mar '19

Sorry, I've not participated in the discussion, but just read all the thread and the impact analysis, and I'm supporting as well. 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.

1 0

PA – life after death
by Maxim A Piskunov 13 Mar '19

13 Mar '19

Hi Guys! As I understand "NetUP Ltd." will loose their PA-addresses if LIR status will not recovered and customers will should renumbering their networks. I have one simple question: why not specified procedure of keeping originally allocated addresses for case when LIR-status under cancellation and LIR can't transfer PA to another LIR. Or I miss something and chance to keep addresses is exists?

15 35

2018-02 Policy Proposal Withdrawn (Assignment Clarification in IPv6 Policy)
by Marco Schmidt 12 Mar '19

12 Mar '19

Dear colleagues, The policy proposal 2018-02, "Assignment Clarification in IPv6 Policy" has been withdrawn. This proposal aimed to clarify the definition of "Assign" in the IPv6 Policy (section 2.6). The proposal is archived and can be found at: https://www.ripe.net/participate/policies/archived-policy-proposals/archive… Reason for withdrawal: The proposer decided it was best to find agreement on a problem statement before developing new policy text. Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0