From zsako at iszt.hu Sun Apr 1 18:45:50 2018 From: zsako at iszt.hu (Janos Zsako) Date: Sun, 1 Apr 2018 18:45:50 +0200 Subject: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 Message-ID: Dear all, Several existing and potential LIRs have complained about the fact that a /22 may not be enough for starting an Internet service. While there is a general agreement that this allocation size should not be changed during the last /8 policy, it may be useful to make some exceptions in some properly justified cases. There is also a general agreement that people should take care of their health, they should eat healthy food and do sufficient physical exercise, possibly by going regularly to the gym. I have thought of a possibility to allocate up to a /20 from the last /8 pool to the companies that can prove that they encourage and help their employees to take care of their help, and that the employees themselves do take advantage of these possibilities. I already have a couple of initial suggestions for consideration, like the average number of hours of workout per employee per week, the average Body Mass Index (https://en.wikipedia.org/wiki/Body_mass_index) per employee, and a couple of similar good ways of measuring the health status at the company. I also though that computing a simple average may disadvantage larger companies, therefore some formula taking into account the size of the different departments and the values measured there could be worked out, similar to the HD ratio used in determining the address utilisation (https://www.ripe.net/publications/docs/ripe-699#hd_ratio). This could make the proposal more fair to large enterprises. There is, however, quite some work to be done to make these ideas properly implementable. I think we should set up a small task force to determine the criteria such LIRs should meet. The time is pressing, we have to act quickly in order to be able to discuss the proposal in Marseilles. Anyone who volunteers for the Task Force should contact me ASAP. We can then come up with a formal proposal and present it to the working group, by following the formal steps of the PDP. I am looking forward to being contacted by the volunteers. Best regards, Janos PS: I am sure some people, when they hear about a new policy proposal for IPv4, they will come up with the usual argument that this is like arranging the deck chairs again. I have to mention, however, that the latest scientific research proved that the sinking of the Titanic could have been delayed by several hours if the deck chairs were properly arranged in due time. Therefore, this proposal may also contribute to a better Internet on the long run. PS2: To those who had the patience to read this e-mail I wish a Happy 1 April! From jim at rfc1035.com Sun Apr 1 18:53:18 2018 From: jim at rfc1035.com (Jim Reid) Date: Sun, 1 Apr 2018 17:53:18 +0100 Subject: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 In-Reply-To: References: Message-ID: <7E595649-ED81-4B4F-BA23-309A9D4FAE3B@rfc1035.com> Janos, this policy proposal needs very careful consideration. However I think detailed discussion should wait until there?s wider adoption of RFC1437. From dominik at clouvider.co.uk Sun Apr 1 19:15:24 2018 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Sun, 1 Apr 2018 17:15:24 +0000 Subject: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 In-Reply-To: <7E595649-ED81-4B4F-BA23-309A9D4FAE3B@rfc1035.com> References: , <7E595649-ED81-4B4F-BA23-309A9D4FAE3B@rfc1035.com> Message-ID: In advance I would say I?m inclined by default to disagree with this proposal With Kind Regards, Dominik Nowacki Clouvider Limited is a limited company registered in England and Wales. Registered number: 08750969. Registered office: 88 Wood Street, London, United Kingdom, EC2V 7RS. Please note that Clouvider Limited may monitor email traffic data and also the content of email for the purposes of security and staff training. This message contains confidential information and is intended only for the intended recipient. If you do not believe you are the intended recipient you should not disseminate, distribute or copy this e-mail. Please notify abuse at clouvider.net of this e-mail immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Clouvider Limited nor any of its employees therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. On 1 Apr 2018, at 17:53, Jim Reid > wrote: Janos, this policy proposal needs very careful consideration. However I think detailed discussion should wait until there?s wider adoption of RFC1437. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun Apr 1 19:43:45 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sun, 01 Apr 2018 19:43:45 +0200 Subject: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 In-Reply-To: References: Message-ID: Hi Janos, I will be in favor of this policy proposal if it means that those LIRs are going to contribute to gym cost for end-users (non-LIRs). Have you thought about that? Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Janos Zsako Fecha: domingo, 1 de abril de 2018, 18:46 Para: "address-policy-wg at ripe.net Working Group" Asunto: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 Dear all, Several existing and potential LIRs have complained about the fact that a /22 may not be enough for starting an Internet service. While there is a general agreement that this allocation size should not be changed during the last /8 policy, it may be useful to make some exceptions in some properly justified cases. There is also a general agreement that people should take care of their health, they should eat healthy food and do sufficient physical exercise, possibly by going regularly to the gym. I have thought of a possibility to allocate up to a /20 from the last /8 pool to the companies that can prove that they encourage and help their employees to take care of their help, and that the employees themselves do take advantage of these possibilities. I already have a couple of initial suggestions for consideration, like the average number of hours of workout per employee per week, the average Body Mass Index (https://en.wikipedia.org/wiki/Body_mass_index) per employee, and a couple of similar good ways of measuring the health status at the company. I also though that computing a simple average may disadvantage larger companies, therefore some formula taking into account the size of the different departments and the values measured there could be worked out, similar to the HD ratio used in determining the address utilisation (https://www.ripe.net/publications/docs/ripe-699#hd_ratio). This could make the proposal more fair to large enterprises. There is, however, quite some work to be done to make these ideas properly implementable. I think we should set up a small task force to determine the criteria such LIRs should meet. The time is pressing, we have to act quickly in order to be able to discuss the proposal in Marseilles. Anyone who volunteers for the Task Force should contact me ASAP. We can then come up with a formal proposal and present it to the working group, by following the formal steps of the PDP. I am looking forward to being contacted by the volunteers. Best regards, Janos PS: I am sure some people, when they hear about a new policy proposal for IPv4, they will come up with the usual argument that this is like arranging the deck chairs again. I have to mention, however, that the latest scientific research proved that the sinking of the Titanic could have been delayed by several hours if the deck chairs were properly arranged in due time. Therefore, this proposal may also contribute to a better Internet on the long run. PS2: To those who had the patience to read this e-mail I wish a Happy 1 April! ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. From noc at ntx.ru Mon Apr 2 13:47:58 2018 From: noc at ntx.ru (NOC Hostmaster) Date: Mon, 2 Apr 2018 14:47:58 +0300 Subject: [address-policy-wg] Preliminary policy proposal: Exceptional /20 IPv4 allocations from the last /8 In-Reply-To: References: Message-ID: <9eeae0e8-09a0-926d-bf12-c6c93943ea96@ntx.ru> Well done! Nikolay. On 01.04.2018 19:45, Janos Zsako wrote: > Dear all, > > Several existing and potential LIRs have complained about the fact that > a /22 may not be > enough for starting an Internet service. While there is a general > agreement that this > allocation size should not be changed during the last /8 policy, it may > be useful to > make some exceptions in some properly justified cases. > > There is also a general agreement that people should take care of their > health, they > should eat healthy food and do sufficient physical exercise, possibly by > going regularly > to the gym. > > I have thought of a possibility to allocate up to a /20 from the last /8 > pool to the > companies that can prove that they encourage and help their employees to > take care of > their help, and that the employees themselves do take advantage of these > possibilities. > > I already have a couple of initial suggestions for consideration, like > the average > number of hours of workout per employee per week, the average Body Mass > Index > (https://en.wikipedia.org/wiki/Body_mass_index) per employee, and a > couple of similar > good ways of measuring the health status at the company. I also though > that computing > a simple average may disadvantage larger companies, therefore some > formula taking into > account the size of the different departments and the values measured > there could be > worked out, similar to the HD ratio used in determining the address > utilisation > (https://www.ripe.net/publications/docs/ripe-699#hd_ratio). This could > make the proposal > more fair to large enterprises. There is, however, quite some work to be > done to make > these ideas properly implementable. > > I think we should set up a small task force to determine the criteria > such LIRs should > meet. The time is pressing, we have to act quickly in order to be able > to discuss the > proposal in Marseilles. Anyone who volunteers for the Task Force should > contact me > ASAP. We can then come up with a formal proposal and present it to the > working group, > by following the formal steps of the PDP. > > I am looking forward to being contacted by the volunteers. > > Best regards, > Janos > > PS: I am sure some people, when they hear about a new policy proposal > for IPv4, they > will come up with the usual argument that this is like arranging the > deck chairs again. > I have to mention, however, that the latest scientific research proved > that the sinking > of the Titanic could have been delayed by several hours if the deck > chairs were properly > arranged in due time. Therefore, this proposal may also contribute to a > better Internet > on the long run. > > PS2: To those who had the patience to read this e-mail I wish a Happy 1 > April! > From sander at steffann.nl Wed Apr 4 12:05:44 2018 From: sander at steffann.nl (Sander Steffann) Date: Wed, 4 Apr 2018 12:05:44 +0200 Subject: [address-policy-wg] WG chair change In-Reply-To: <20180309101630.GU89741@Space.Net> References: <20180309101630.GU89741@Space.Net> Message-ID: <47862120-B6DF-4B67-B1D8-A5C08898B134@steffann.nl> 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: please speak up! Our selection process consists of trying to get consensus during the working group session on who this working group would like to appoint. To avoid spending a long time debating this in Marseille I would like to ask you to start working towards consensus here on the list. If we can't get consensus because all candidates are equally awesome then we can still fall back to the secret ballot procedure, but in the spirit of our bottom up consensus based tradition I would prefer it if we can do this by cooperation and consensus instead of voting. Cheers! Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From mschmidt at ripe.net Thu Apr 12 10:38:08 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 12 Apr 2018 10:38:08 +0200 Subject: [address-policy-wg] RIPE 75 Address Policy WG Draft Minutes Message-ID: Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 75 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-75-address-policy-working-group-minutes 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 From mschmidt at ripe.net Mon Apr 16 15:44:17 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 16 Apr 2018 15:44:17 +0200 Subject: [address-policy-wg] Proposal Implemented: 2016-04, "IPv6 Sub-assignment Clarification" Message-ID: Dear colleagues, We are pleased to announce that we have implemented the policy proposal 2016-04, "IPv6 Sub-assignment Clarification". The policy change re-defined the term "sub-assignment" for IPv6. The provision of separate addresses (/128) to customers of the assignment holder will not be considered a sub-assignment. More information, especially for IPv6 PI assignments, can be found at: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/ipv6 The archived policy proposal can be found at: https://www.ripe.net/participate/policies/proposals/2016-04 The RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available at: https://www.ripe.net/publications/docs/ripe-699 Kind regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mschmidt at ripe.net Tue Apr 17 15:55:11 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 17 Apr 2018 15:55:11 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. This proposal aims to clarify the definition of ?Assign? in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-02 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 proposer, 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 before 15 May 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From sander at steffann.nl Tue Apr 17 15:59:55 2018 From: sander at steffann.nl (Sander Steffann) Date: Tue, 17 Apr 2018 15:59:55 +0200 Subject: [address-policy-wg] Agenda for APWG at RIPE 76 in Marseille In-Reply-To: <74C49FD3-B8C9-49C3-94D9-0DFC26572CD5@steffann.nl> References: <74C49FD3-B8C9-49C3-94D9-0DFC26572CD5@steffann.nl> Message-ID: <585669C5-EF80-4459-8D81-06BB2B5DA2E1@steffann.nl> Hi APWG folks, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Marseille in the following time slots: Wednesday, May 16, 09:00 - 10:30 Wednesday, May 16, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Regards, Gert D?ring & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection - longest-serving chair (Sander Steffann) stepping down - Sander is not volunteering for another term, so we'll select a new co-chair C. The role and function of the ASO within ICANN Public consultation, Axel Pawlik D. 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 75 - brief overview of new proposals (if any) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 ---------------------------------------------------------------------- Welcome back E. Feedback From NCC Registration Service - Andrea Cima (+ discussion with the group) F. Discussion of open policy proposals 2018-01 Organisation-LIR Clarification in IPv6 Policy Jordi Palet Martinez / Erik Bais / Juri Bogdanov 2018-02 "Assignment Clarification in IPv6 Policy" Jordi Palet Martinez / Erik Bais 2018-03 Fixing Outdated Information in the IPv4 Policy Andrea Cima 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From jordi.palet at consulintel.es Tue Apr 17 16:51:45 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 17 Apr 2018 16:51:45 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: References: Message-ID: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> Hi all, As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. I was suggested that it can always be improved ... so that's what I'm doing here. I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). So basically, what I'm saying is: 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. This is an open question here, and I may be wrong. So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? Thanks! Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Marco Schmidt Fecha: martes, 17 de abril de 2018, 15:55 Para: Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Dear colleagues, A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. This proposal aims to clarify the definition of ?Assign? in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-02 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 proposer, 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 before 15 May 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. From jordi.palet at consulintel.es Tue Apr 17 16:57:20 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 17 Apr 2018 16:57:20 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> Message-ID: <14510A7B-6D66-417E-97A9-9453341FA070@consulintel.es> By the way, forgot something ... I've created an "online diff" so you can compare the actual text, with my proposal: https://www.diffchecker.com/SMXYO2rc Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de JORDI PALET MARTINEZ via address-policy-wg Responder a: JORDI PALET MARTINEZ Fecha: martes, 17 de abril de 2018, 16:52 Para: Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Hi all, As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. I was suggested that it can always be improved ... so that's what I'm doing here. I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). So basically, what I'm saying is: 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. This is an open question here, and I may be wrong. So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? Thanks! Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Marco Schmidt Fecha: martes, 17 de abril de 2018, 15:55 Para: Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Dear colleagues, A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. This proposal aims to clarify the definition of ?Assign? in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-02 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 proposer, 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 before 15 May 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. From max at rfc2324.org Tue Apr 17 17:13:57 2018 From: max at rfc2324.org (Maximilian Wilhelm) Date: Tue, 17 Apr 2018 17:13:57 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> Message-ID: <20180417151357.GG14391@principal.rfc2324.org> Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? I like the overall thing, but I don't like the DC part (as you might have guessed :)). My approach deliberately included housing/hosting as you can read in the rationale and this is something I would like to keep included for small hosters. I think the argument of scale applies here. Having only a /48 for your DC including your own infrastructure and some customer stuff won't get you far (if you don't ignore RFCs and BCPs). So for me this would be fine. If you grow, become an LIR, get a /29, be happy, everyone is happy. Best Max -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds From jordi.palet at consulintel.es Tue Apr 17 17:18:29 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 17 Apr 2018 17:18:29 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <20180417151357.GG14391@principal.rfc2324.org> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> <20180417151357.GG14391@principal.rfc2324.org> Message-ID: <6238AA79-2F33-4961-8BF5-1B05BB8FDB8D@consulintel.es> Hi Max, Thanks for the (quick) inputs! To be honest, I was not sure that you also need that for your own case (or if you know other cases that need that). I really think if you are a hosting/housing provider for third companies, you should become an LIR, but as said, this is only my personal view. Let's see what others believe. By the way, it will be interesting to compare this with IPv4. Do we allow this case in IPv4? Or we need also a policy proposal to amend that? Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de Maximilian Wilhelm Fecha: martes, 17 de abril de 2018, 17:14 Para: Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? I like the overall thing, but I don't like the DC part (as you might have guessed :)). My approach deliberately included housing/hosting as you can read in the rationale and this is something I would like to keep included for small hosters. I think the argument of scale applies here. Having only a /48 for your DC including your own infrastructure and some customer stuff won't get you far (if you don't ignore RFCs and BCPs). So for me this would be fine. If you grow, become an LIR, get a /29, be happy, everyone is happy. Best Max -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. From apwg at c4inet.net Tue Apr 17 18:53:26 2018 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 17 Apr 2018 17:53:26 +0100 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <14510A7B-6D66-417E-97A9-9453341FA070@consulintel.es> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> <14510A7B-6D66-417E-97A9-9453341FA070@consulintel.es> Message-ID: <20180417165326.GI17209@cilantro.c4inet.net> Hi Jordi, On Tue, Apr 17, 2018 at 04:57:20PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I've created an "online diff" so you can compare the actual text, with my proposal: > >https://www.diffchecker.com/SMXYO2rc I have several issues with the proposal: 1) It perpetuates what may have been a good idea in 1990, viz the PI/PA distinction, into IPv6. IMO it's long past time to stop having special classes of addresses and to treat them as what they are, numbers. 2) It looks a lot like micro-management, trying to make policy for every edge case. Having said that, it seems to be necessary as the NCC is using an unreasonable interpretation of existing policy. 3) the last sentence of the policy text: "Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication." makes neither grammatical nor technical sense. for one thing, it's always "either/or" or "neither/nor" and neither/nor mustn't be used after a preceding negative ("can't"). For the other, if this point-to-point assignment can't even *indirectly* be used for communication, it can't be used for *anything* as traffic from the downstream /64 would surely be routed via the point-to-point link, thus using its addresses... That said, I'd see no reason not to support the proposal *if* that last sentence is removed (it's unneccessarily specific and technically prohibitive) Kind Regards, Sascha Luck > > >Regards, >Jordi > > >???-----Mensaje original----- >De: address-policy-wg en nombre de JORDI PALET MARTINEZ via address-policy-wg >Responder a: JORDI PALET MARTINEZ >Fecha: martes, 17 de abril de 2018, 16:52 >Para: >Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Hi all, > > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? > > Thanks! > > Regards, > Jordi > > > ???-----Mensaje original----- > De: address-policy-wg en nombre de Marco Schmidt > Fecha: martes, 17 de abril de 2018, 15:55 > Para: > Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Dear colleagues, > > A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. > > This proposal aims to clarify the definition of ???Assign??? in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2018-02 > > 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 proposer, 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 before 15 May 2018. > > Regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > 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. > > > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >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. > > > > > From jordi.palet at consulintel.es Tue Apr 17 21:10:35 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 17 Apr 2018 21:10:35 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <20180417165326.GI17209@cilantro.c4inet.net> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> <14510A7B-6D66-417E-97A9-9453341FA070@consulintel.es> <20180417165326.GI17209@cilantro.c4inet.net> Message-ID: Hi Sascha, I see your point on the last sentence. The idea of that is avoiding someone to have the bright idea to use the point-to-point links to offer permanent service by means of "IPv6 NAT/NPT". Maybe the wording is not the best. I just figured out an alternative one: "The addressing of the point-to-point link can be permanent; however, it can't be used as an artifact to avoid provisioning IPv6 addresses to circumvent this policy." May be the NCC can check if this make sense in english, or someone else can provide some other suggestions about how to say it, withou explicit mention to "IPv6 NAT/NPT" (which are just examples, as we could though in any way of "proxying", etc., and we prefer to avoid mentioning what technology ...). Regards, Jordi ?-----Mensaje original----- De: address-policy-wg en nombre de "Sascha Luck [ml]" Fecha: martes, 17 de abril de 2018, 18:53 Para: JORDI PALET MARTINEZ CC: Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Hi Jordi, On Tue, Apr 17, 2018 at 04:57:20PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote: >I've created an "online diff" so you can compare the actual text, with my proposal: > >https://www.diffchecker.com/SMXYO2rc I have several issues with the proposal: 1) It perpetuates what may have been a good idea in 1990, viz the PI/PA distinction, into IPv6. IMO it's long past time to stop having special classes of addresses and to treat them as what they are, numbers. 2) It looks a lot like micro-management, trying to make policy for every edge case. Having said that, it seems to be necessary as the NCC is using an unreasonable interpretation of existing policy. 3) the last sentence of the policy text: "Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication." makes neither grammatical nor technical sense. for one thing, it's always "either/or" or "neither/nor" and neither/nor mustn't be used after a preceding negative ("can't"). For the other, if this point-to-point assignment can't even *indirectly* be used for communication, it can't be used for *anything* as traffic from the downstream /64 would surely be routed via the point-to-point link, thus using its addresses... That said, I'd see no reason not to support the proposal *if* that last sentence is removed (it's unneccessarily specific and technically prohibitive) Kind Regards, Sascha Luck > > >Regards, >Jordi > > >???-----Mensaje original----- >De: address-policy-wg en nombre de JORDI PALET MARTINEZ via address-policy-wg >Responder a: JORDI PALET MARTINEZ >Fecha: martes, 17 de abril de 2018, 16:52 >Para: >Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Hi all, > > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? > > Thanks! > > Regards, > Jordi > > > ???-----Mensaje original----- > De: address-policy-wg en nombre de Marco Schmidt > Fecha: martes, 17 de abril de 2018, 15:55 > Para: > Asunto: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) > > Dear colleagues, > > A new RIPE Policy proposal, 2018-02, "Assignment Clarification in IPv6 Policy" is now available for discussion. > > This proposal aims to clarify the definition of ???Assign??? in ripe-699 (section 2.6). The non-permanent provision of up to a /64 prefix to third parties shall not be considered a sub-assignment. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2018-02 > > 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 proposer, 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 before 15 May 2018. > > Regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.consulintel.es > 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. > > > > > > > > > >********************************************** >IPv4 is over >Are you ready for the new Internet ? >http://www.consulintel.es >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. > > > > > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. From wusel+ml at uu.org Tue Apr 17 23:23:41 2018 From: wusel+ml at uu.org (Kai 'wusel' Siering) Date: Tue, 17 Apr 2018 23:23:41 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> Message-ID: Moin, am 17.04.2018 um 16:51 schrieb JORDI PALET MARTINEZ via address-policy-wg: > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. From my point of view, if there's a policy that's sound and valid for other RIRs, they will adopt it over time. IF they struggle with similar issues (which I frankly don't know). > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). Above all, what exactly is unclear in "the actual interpretation" done by whom? > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. With "in a hot-spot" you refer to WiFi? The "assignment" of a specific prefix for a specific WiFi in all practical setups will be a permanent one ? no-one rotates the /64s on their WiFi APs every other week or even year. So, as we're on a clarifying mission, what constitutes a) a "permanent" and b) a "[sub-] assignment"? ripe-699 tried to ensure that RIPE NCC does not "misinterpret" third parties getting leases (or, in the SLAAC case, just grabbing the MAC-based address) from a PI assignment as a "[sub-] assignment" of said address space. If the changed text actually will work as intended is yet to be seen ? why the rush to change the policy text _again_?! It's my strong believe that adding more wording about what use isn't considered as a "[sub-] assignment" will only lead to more edge cases and more vague applications. > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that I'm not a datacenter, but I run stuff in datacenters. Are you intending to forbid this use case? Are you actively trying to make PIv6 go away completely by disallowing any practical use? > this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. A datacenter is a datacenter, an ISP is an ISP, and an End User is an End User; none of these are forced to become a LIR. Actually, PI, Provider Independent address space, can make much sense for an independent datacenter operator to run their infrastructure with ? as well as for an ambitious End User. If an End User becomes an ISP, they still may use their PI address space for their infrastructure. The same applies to an End User or ISP who becomes a LIR ... Please remember: ?LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.? It's not: ?Any ISP must be a LIR in order to assign address space to their end users.? It's neither: ?Anyone in need of IPv6 address space must become an LIR.? But let's review the suggested new policy text: ?[?] The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment.? So, if I, as the assignment holder of PIv6 space, allocate a /64 for any of my family member's devices (e. g. a /64 for my gear, a /64 for my wife's and each kid's devices) for accountability (that is: legal) reasons, that's sub-assigning (again)? After all, it's my infra they use. Is a tunnel over my DSL line to a friend a ?link operated? by me or my friend or my or his access provider? We would use :::/64 for it, so it's definately not ?permanently provided?. ?This includes, for example, guests or employees (devices or servers), hotspots, and point-to-point links or VPNs.? VPN- and P2P-links are usually configured via static, hence ?permanent?, addresses, this contradicts what was stated before. ?The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment. Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication.? How is traffic going over ?the point-to-point link? (which, actually?) not ?indirectly? making use of the ?addressing? of that link ?for the actual communication?? Without addresses, there would be no link, would there? As I said, the more fine-grained the policy text, the more issues you get, the less clear the policy becomes. Therefore I object this proposal. I'm really puzzled why no-one is aiming to simply amend ?7. IPv6 Provider Independent (PI) Assignments? by something along ?PIv6 is not to be used as ?PA lite?; use of PIv6 should be centered running assignment holder's infrastructure, not as a means to provide ISP services to end users.? To me, that's the bottom line regarding the intended use of PIv6 space. Regards, -kai FTR: https://www.ripe.net/participate/2016-04#impact-analysis gives an 404 in https://www.ripe.net/participate/policies/proposals/2018-02, proper link address seems to be https://www.ripe.net/participate/policies/proposals/2016-04#impact-analysis -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Apr 18 10:00:06 2018 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 18 Apr 2018 10:00:06 +0200 Subject: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) In-Reply-To: References: <65A84868-F6CB-499B-ADAC-1EE3C6EA23F0@consulintel.es> Message-ID: Hi Kai, Responses below, in-line. Regards, Jordi De: address-policy-wg en nombre de Kai 'wusel' Siering Organizaci?n: Unseen University, Department of Magic Mails Fecha: martes, 17 de abril de 2018, 23:24 Para: Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Moin, am 17.04.2018 um 16:51 schrieb JORDI PALET MARTINEZ via address-policy-wg: I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. >From my point of view, if there's a policy that's sound and valid for other RIRs, they will adopt it over time. IF they struggle with similar issues (which I frankly don't know). Yes, I can confirm that in the other RIRs policy there is the same sub-assignment text as we initially had, so same issues. The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). Above all, what exactly is unclear in "the actual interpretation" done by whom? If you followed the previous discussion it was clear that actual policy text talks about a single address, but then the talks about /64 ? 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. With "in a hot-spot" you refer to WiFi? The "assignment" of a specific prefix for a specific WiFi in all practical setups will be a permanent one ? no-one rotates the /64s on their WiFi APs every other week or even year. So, as we're on a clarifying mission, what constitutes a) a "permanent" and b) a "[sub-] assignment"? You?re confused here I think. We are talking about the address that get the customer of the hotspot, so what you get when you connect to that WiFi accesspoint. The access point may get a single /64 or may be is a router and is getting /56 so it has many /64s available to provisioning to each ?customers? as per RFC8273 (for example). ripe-699 tried to ensure that RIPE NCC does not "misinterpret" third parties getting leases (or, in the SLAAC case, just grabbing the MAC-based address) from a PI assignment as a "[sub-] assignment" of said address space. If the changed text actually will work as intended is yet to be seen ? why the rush to change the policy text _again_?! Because I don?t think it was a good change and I?d the option to appeal that or start a new proposal improving it. It's my strong believe that adding more wording about what use isn't considered as a "[sub-] assignment" will only lead to more edge cases and more vague applications. I think in the other way around, we are making it clearer. This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that I'm not a datacenter, but I run stuff in datacenters. Are you intending to forbid this use case? Are you actively trying to make PIv6 go away completely by disallowing any practical use? No, this is not my intent. I?m asking the WG what they think on this (and I stated that my view may be wrong). this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. A datacenter is a datacenter, an ISP is an ISP, and an End User is an End User; none of these are forced to become a LIR. Actually, PI, Provider Independent address space, can make much sense for an independent datacenter operator to run their infrastructure with ? as well as for an ambitious End User. Let?s see if the WG has that view as well. This is why I?m asking. If an End User becomes an ISP, they still may use their PI address space for their infrastructure. The same applies to an End User or ISP who becomes a LIR ... Please remember: ?LIRs are generally ISPs whose customers are primarily End Users and possibly other ISPs.? It's not: ?Any ISP must be a LIR in order to assign address space to their end users.? It's neither: ?Anyone in need of IPv6 address space must become an LIR.? But let's review the suggested new policy text: ?[?] The fact that a unique address or even a unique /64 prefix is non-permanently provided to third parties, on a link operated by the original receiver of the assignment, shall not be considered a sub-assignment.? So, if I, as the assignment holder of PIv6 space, allocate a /64 for any of my family member's devices (e. g. a /64 for my gear, a /64 for my wife's and each kid's devices) for accountability (that is: legal) reasons, that's sub-assigning (again)? After all, it's my infra they use. With previous policy that was not possible. With actual policy if it is a single address is possible. With my proposal, /64 is possible. Is a tunnel over my DSL line to a friend a ?link operated? by me or my friend or my or his access provider? We would use :::/64 for it, so it's definately not ?permanently provided?. There always ways to trick every policy, you don?t think so? ?This includes, for example, guests or employees (devices or servers), hotspots, and point-to-point links or VPNs.? VPN- and P2P-links are usually configured via static, hence ?permanent?, addresses, this contradicts what was stated before. I don?t think so, typically VPNs you have a pool of addresses for ?all the VPN customers?. It can be the other way around, and of course it can be an ?always-on? VPN. For me that is a point-to-point actually (it is a permanent link). ?The provision of addressing for permanent connectivity or broadband services is still considered a sub-assignment. Only the addressing of the point-to-point link itself can be permanent and that addressing can't be used (neither directly or indirectly) for the actual communication.? How is traffic going over ?the point-to-point link? (which, actually?) not ?indirectly? making use of the ?addressing? of that link ?for the actual communication?? Without addresses, there would be no link, would there? As I said, the more fine-grained the policy text, the more issues you get, the less clear the policy becomes. Therefore I object this proposal. I suggested in a previous email a more open text, to avoid going into too much fine-grained text. I'm really puzzled why no-one is aiming to simply amend ?7. IPv6 Provider Independent (PI) Assignments? by something along ?PIv6 is not to be used as ?PA lite?; use of PIv6 should be centered running assignment holder's infrastructure, not as a means to provide ISP services to end users.? To me, that's the bottom line regarding the intended use of PIv6 space. This was one of my first suggestions when Max started this work. Then I was convinced by the community that we should allow this ? Regards, -kai FTR: https://www.ripe.net/participate/2016-04#impact-analysis gives an 404 in https://www.ripe.net/participate/policies/proposals/2018-02, proper link address seems to be https://www.ripe.net/participate/policies/proposals/2016-04#impact-analysis ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Wed Apr 18 11:29:52 2018 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 18 Apr 2018 11:29:52 +0200 Subject: [address-policy-wg] New on RIPE Labs: So Long Last /8 and Thanks For All the Allocations Message-ID: <58d2f733-2cad-c24c-458a-103d91aa08ec@ripe.net> 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-allocations 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 From sander at steffann.nl Wed Apr 18 13:41:08 2018 From: sander at steffann.nl (Sander Steffann) Date: Wed, 18 Apr 2018 13:41:08 +0200 Subject: [address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2 In-Reply-To: <585669C5-EF80-4459-8D81-06BB2B5DA2E1@steffann.nl> References: <74C49FD3-B8C9-49C3-94D9-0DFC26572CD5@steffann.nl> <585669C5-EF80-4459-8D81-06BB2B5DA2E1@steffann.nl> Message-ID: Hi APWG folks, There were a few typos in the agenda so here is an updated version: Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Marseille in the following time slots: Wednesday, May 16, 09:00 - 10:30 Wednesday, May 16, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Regards, Gert D?ring & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection - longest-serving chair (Sander Steffann) stepping down - Sander is not volunteering for another term, so we'll select a new co-chair C. The role and function of the ASO within ICANN Public consultation, Axel Pawlik D. 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 75 - brief overview of new proposals (if any) ---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back E. Feedback From NCC Registration Service - Andrea Cima (+ discussion with the group) F. Discussion of open policy proposals 2018-01 Organisation-LIR Clarification in IPv6 Policy Jordi Palet Martinez / Erik Bais / Juri Bogdanov 2018-02 Assignment Clarification in IPv6 Policy Jordi Palet Martinez 2018-03 Fixing Outdated Information in the IPv4 Policy Andrea Cima 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From aleksbulgakov at gmail.com Wed Apr 18 17:22:38 2018 From: aleksbulgakov at gmail.com (Aleksey Bulgakov) Date: Wed, 18 Apr 2018 15:22:38 +0000 Subject: [address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2 In-Reply-To: References: <74C49FD3-B8C9-49C3-94D9-0DFC26572CD5@steffann.nl> <585669C5-EF80-4459-8D81-06BB2B5DA2E1@steffann.nl> Message-ID: Hello, WG. What is 2018-03 Fixing Outdated Information in the IPv4 Policy? I cannot find it in the NCC website. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Apr 18 17:45:48 2018 From: sander at steffann.nl (Sander Steffann) Date: Wed, 18 Apr 2018 17:45:48 +0200 Subject: [address-policy-wg] Agenda for APWG at RIPE 76 in Marseille v2 In-Reply-To: References: <74C49FD3-B8C9-49C3-94D9-0DFC26572CD5@steffann.nl> <585669C5-EF80-4459-8D81-06BB2B5DA2E1@steffann.nl> Message-ID: 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 will be published before RIPE 76 so we already tentatively added it to the agenda. Cheers! Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From mschmidt at ripe.net Tue Apr 24 15:04:53 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 24 Apr 2018 15:04:53 +0200 Subject: [address-policy-wg] 2018-03 New Policy Proposal (Fixing Outdated Information in the IPv4 Policy) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2018-03, "Fixing Outdated Information in the IPv4 Policy" is now available for discussion. This proposal aims to fix outdated information in the RIPE Policy "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region". You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-03 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 proposer, 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 before 23 May 2018. Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From farmer at umn.edu Tue Apr 24 16:25:07 2018 From: farmer at umn.edu (David Farmer) Date: Tue, 24 Apr 2018 09:25:07 -0500 Subject: [address-policy-wg] 2018-03 New Policy Proposal (Fixing Outdated Information in the IPv4 Policy) In-Reply-To: References: Message-ID: Rather than updating the reference from RFC3330 to RFC6890, by the way, RFC6890 itself has been updated by RFC8190. Further, numerous RFCs have updated the registry since its creation by RFC5736 and its expansion by RFC6890. Therefore, I think it would be better to directly reference the "IANA IPv4 Special-Purpose Address Registry" at its permanent URL ( https://www.iana.org/assignments/iana-ipv4-special-registry ), instead of referencing the RFC that created the registry. Note the registry itself references, RFC5736, RFC6980, and RFC8190 for its registry policies. Also, I think it would be useful to add a reference to RFC6598 "IANA-Reserved IPv4 Prefix for Shared Address Space" to subsection 2, where RFC1918 is discussed. Note RFC6598 is distinct from RFC1918 but has a similar purpose. Thanks. On Tue, Apr 24, 2018 at 8:04 AM, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2018-03, "Fixing Outdated Information in the > IPv4 Policy" is now available for discussion. > > This proposal aims to fix outdated information in the RIPE Policy "IPv4 > Address Allocation and Assignment Policies for the RIPE NCC Service Region". > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2018-03 > > 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 proposer, 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 at ripe.net> before 23 May 2018. > > Regards, > > Marco Schmidt > Policy Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From leo.vegoda at icann.org Tue Apr 24 16:48:57 2018 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 24 Apr 2018 14:48:57 +0000 Subject: [address-policy-wg] [Ext] Re: 2018-03 New Policy Proposal (Fixing Outdated Information in the IPv4 Policy) In-Reply-To: References: Message-ID: David Farmer wrote: > Rather than updating the reference from RFC3330 to > RFC6890, by the way, RFC6890 itself has been updated > by RFC8190. Further, numerous RFCs have updated the > registry since its creation by RFC5736 and its expansion > by RFC6890. Therefore, I think it would be better to > directly reference the "IANA IPv4 Special-Purpose > Address Registry" at its permanent URL > (https://www.iana.org/assignments/iana-ipv4-special-registry ), > instead of referencing the RFC that created the registry. This is sound. When we wrote RFC 6890 we intended to make the registry a stable and authoritative source, rather than have to update whatever the RFC was at the time that an assignment changed or a new assignment was made. Referencing the registry instead of an RFC makes sense. Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3739 bytes Desc: not available URL: From mschmidt at ripe.net Thu Apr 26 12:23:32 2018 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 26 Apr 2018 12:23:32 +0200 Subject: [address-policy-wg] 2018-04 New Proposal (PDP Clarification) to be discussed on RIPE Discussion Mailing List Message-ID: Dear colleagues, A new RIPE proposal, 2018-04, "PDP Clarification" has been published on the RIPE Discussion mailing list for discussion. This proposal aims to clarify the options available to the WG chairs at the end of the Review Phase of the RIPE Policy Development Process (PDP). Please note that since changes to the PDP can affect all RIPE Working Groups, the RIPE Chair decided to discuss this proposal on the RIPE Discussion mailing list. The RIPE Chair will also moderate the proposal discussion. We wanted to notify the Address Policy Working Group in particular, as most of the policy proposals are discussed here. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2018-04 We encourage you to review this proposal and join the discussion on the RIPE Discussion mailing list (ripe-list at ripe.net). Regards, Marco Schmidt Policy Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From andrea at ripe.net Thu Apr 26 15:31:27 2018 From: andrea at ripe.net (Andrea Cima) Date: Thu, 26 Apr 2018 15:31:27 +0200 Subject: [address-policy-wg] [Ext] Re: 2018-03 New Policy Proposal (Fixing Outdated Information in the IPv4 Policy) In-Reply-To: References: Message-ID: <4aef4f0b-c309-a063-c5e8-6330bf88a303@ripe.net> Dear David and Leo, Thank you for your feedback. The initial version of the proposal focusses only on references to obsolete RFCs. Your suggestion of a direct reference the "IANA IPv4 Special-Purpose Address Registry" instead of referencing the RFC sounds reasonable. If the Working Group feels that more updates to current references would improve the IPv4 policy, I will be happy to take this into account for an adjusted proposal version. Best regards, Andrea On 24/04/2018 16:48, Leo Vegoda wrote: > David Farmer wrote: > >> Rather than updating the reference from RFC3330 to >> RFC6890, by the way, RFC6890 itself has been updated >> by RFC8190. Further, numerous RFCs have updated the >> registry since its creation by RFC5736 and its expansion >> by RFC6890. Therefore, I think it would be better to >> directly reference the "IANA IPv4 Special-Purpose >> Address Registry" at its permanent URL >> (https://www.iana.org/assignments/iana-ipv4-special-registry ), >> instead of referencing the RFC that created the registry. > This is sound. > > When we wrote RFC 6890 we intended to make the registry a stable and > authoritative source, rather than have to update whatever the RFC was at the > time that an assignment changed or a new assignment was made. Referencing the > registry instead of an RFC makes sense. > > Kind regards, > > Leo Vegoda From paul at meanie.nl Sat Apr 28 18:12:30 2018 From: paul at meanie.nl (Paul Hoogsteder) Date: Sat, 28 Apr 2018 18:12:30 +0200 Subject: [address-policy-wg] WG Chair selection Message-ID: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Hello AP-WG, I don't think I've seen any support for either candidate for the position of WG chair on the list yet. I think Erik Bais is more than qualified for such a position, he's been active in the RIPE community and this working group for years and has made many valuable contributions. +many for Erik! Best regards, Paul Hoogsteder Meanie AS31019 Breedband Delft AS34108 From raymond.jetten at elisa.fi Sat Apr 28 18:35:30 2018 From: raymond.jetten at elisa.fi (Jetten Raymond) Date: Sat, 28 Apr 2018 16:35:30 +0000 Subject: [address-policy-wg] [SENDER UNVERIFIED] WG Chair selection In-Reply-To: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: <19C8071A87E6E1F0.8b5aac3f-cb3b-4b66-81a8-3ea86a36f2f9@mail.outlook.com> Fully agree with Paul. Erik has been a long term active and knows how the system works. +1 Cheers, Ray Sent from mobile device, pardon typos... Kohteesta: Paul Hoogsteder L?hetetty: lauantai 28. huhtikuuta klo 19.12 Aihe: [SENDER UNVERIFIED][address-policy-wg] WG Chair selection Vastaanottaja: address-policy-wg at ripe.net Hello AP-WG, I don't think I've seen any support for either candidate for the position of WG chair on the list yet. I think Erik Bais is more than qualified for such a position, he's been active in the RIPE community and this working group for years and has made many valuable contributions. +many for Erik! Best regards, Paul Hoogsteder Meanie AS31019 Breedband Delft AS34108 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Piotr.Strzyzewski at polsl.pl Sat Apr 28 23:28:22 2018 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Sat, 28 Apr 2018 23:28:22 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: <20180428212822.GA25529@hydra.ck.polsl.pl> On Sat, Apr 28, 2018 at 06:12:30PM +0200, Paul Hoogsteder wrote: > Hello AP-WG, > > I don't think I've seen any support for either candidate for the position > of WG chair on the list yet. I think Erik Bais is more than qualified for > such a position, he's been active in the RIPE community and this working > group for years and has made many valuable contributions. > > +many for Erik! Good point! +1 for Erik -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From cfriacas at fccn.pt Sun Apr 29 12:15:19 2018 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 29 Apr 2018 11:15:19 +0100 (WEST) Subject: [address-policy-wg] WG Chair selection In-Reply-To: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: +1 for Erik. Regards, Carlos On Sat, 28 Apr 2018, Paul Hoogsteder wrote: > Hello AP-WG, > > I don't think I've seen any support for either candidate for the position > of WG chair on the list yet. I think Erik Bais is more than qualified for > such a position, he's been active in the RIPE community and this working > group for years and has made many valuable contributions. > > +many for Erik! > > Best regards, > > Paul Hoogsteder > Meanie AS31019 > Breedband Delft AS34108 > > From tore at fud.no Mon Apr 30 10:45:55 2018 From: tore at fud.no (Tore Anderson) Date: Mon, 30 Apr 2018 10:45:55 +0200 Subject: [address-policy-wg] WG Chair selection In-Reply-To: <19C8071A87E6E1F0.8b5aac3f-cb3b-4b66-81a8-3ea86a36f2f9@mail.outlook.com> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> <19C8071A87E6E1F0.8b5aac3f-cb3b-4b66-81a8-3ea86a36f2f9@mail.outlook.com> Message-ID: <99690a9f-2418-1216-7473-fb2086d18291@fud.no> * Jetten Raymond > Erik has been a long term active and knows how the system works. That is true. I tried finding any evidence of past activity in the APWG by Sean Stuart, but unless my Google-fu is completely faulty, there simply is not any. So while I do appreciate Sean stepping up here, I'll go with the candidate that I know have a history of active participation. +1 for Erik. Tore From stolpe at resilans.se Mon Apr 30 11:05:08 2018 From: stolpe at resilans.se (Daniel Stolpe) Date: Mon, 30 Apr 2018 11:05:08 +0200 (CEST) Subject: [address-policy-wg] WG Chair selection In-Reply-To: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: +1 Erik has my support. On Sat, 28 Apr 2018, Paul Hoogsteder wrote: > Hello AP-WG, > > I don't think I've seen any support for either candidate for the position > of WG chair on the list yet. I think Erik Bais is more than qualified for > such a position, he's been active in the RIPE community and this working > group for years and has made many valuable contributions. > > +many for Erik! > > Best regards, > > Paul Hoogsteder > Meanie AS31019 > Breedband Delft AS34108 Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From wolfgang.tremmel at de-cix.net Mon Apr 30 12:35:31 2018 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Mon, 30 Apr 2018 10:35:31 +0000 Subject: [address-policy-wg] WG Chair selection In-Reply-To: References: <8443b42a2cf5a17177544c9e34b66eb0.squirrel@webmail.prolocation.net> Message-ID: also +1 for Erik from me -- Wolfgang Tremmel Phone +49 69 1730902 26 | Fax +49 69 4056 2716 | Mobile +49 171 8600 816 | wolfgang.tremmel at de-cix.net Geschaeftsfuehrer Harald A. Summa | Registergericht AG K?ln HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net