From mir at ripe.net Thu Oct 3 14:54:00 2019 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 3 Oct 2019 14:54:00 +0200 Subject: [address-policy-wg] New on RIPE Labs: 25, 000 LIRs - An End to the Milestone Highs? Message-ID: <842ce784-e677-19bd-09aa-a24df155e5b0@ripe.net> Dear colleagues, Little more than twelve months after we passed the 20,000 active LIRs mark, the number of LIR accounts reached a new milestone. As the number of available IPv4 addresses in our pool dropped to 3 million, applications for new LIRs exploded. In July alone, we saw a record number of 788 new accounts being activated. At this new milestone, we once more look back at the historical developments, report on the run-out of available IPv4 and share some some insights on what the future might bring for our membership numbers. Please find more details on RIPE Labs: https://labs.ripe.net/Members/wilhelm/25-000-lirs-an-end-to-the-milestone-highs Kind regards, Mirjam K?hne RIPE NCC From gert at space.net Fri Oct 4 15:14:20 2019 From: gert at space.net (Gert Doering) Date: Fri, 4 Oct 2019 15:14:20 +0200 Subject: [address-policy-wg] Draft agenda for RIPE79 APWG meeting Message-ID: <20191004131420.GQ55186@Space.Net> Hi APWG folks, Below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Rotterdam in the side-room (diamond room) in the following time slots: Wednesday, Oct 16, 09:00 - 10:30 Wednesday, Oct 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 & Erik Bais, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Presentation of the NRO NC candidates - Filiz Yilmaz - Stefan Nikolov C. Panel Discussion on "IPv4 effects after RIPE NCC run-out"
---------------------------------------------------------------------- Wednesday, 11:00-12:30 ---------------------------------------------------------------------- Welcome back 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 78 - brief overview of new proposals (if any) E. Feedback From NCC Registration Service - Nikolas Pediaditis - IPv4 runout status - expectations for the waiting list phase (+ discussion with the group) F. Discussion of open policy proposals * tbd 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 Gert Doering -- NetMaster -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From andy at nosignal.org Sat Oct 5 00:36:16 2019 From: andy at nosignal.org (Andy Davidson) Date: Fri, 4 Oct 2019 22:36:16 +0000 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call Message-ID: Still support this proposal. From cfriacas at fccn.pt Sun Oct 6 17:57:12 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Sun, 6 Oct 2019 16:57:12 +0100 (WEST) Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: Message-ID: I also support this proposal. Cheers, Carlos On Fri, 4 Oct 2019, Andy Davidson wrote: > Still support this proposal. > From luca.cicchelli at top-ix.org Mon Oct 7 07:30:36 2019 From: luca.cicchelli at top-ix.org (Luca TOP-IX) Date: Mon, 07 Oct 2019 05:30:36 +0000 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: Message-ID: I support this proposal ? Luca Cicchelli www.top-ix.org ------ Original Message ------ From: "Andy Davidson" To: "address-policy-wg at ripe.net" Sent: 10/5/2019 12:36:16 AM Subject: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call >Still support this proposal. > From arnold.nipper at de-cix.net Mon Oct 7 08:08:36 2019 From: arnold.nipper at de-cix.net (Arnold Nipper) Date: Mon, 7 Oct 2019 08:08:36 +0200 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: Message-ID: I fully support this proposal Cheers Arnold On 07.10.2019 07:30, Luca TOP-IX wrote: > I support this proposal > > > ? > Luca Cicchelli > > www.top-ix.org > > ------ Original Message ------ > From: "Andy Davidson" > To: "address-policy-wg at ripe.net" > Sent: 10/5/2019 12:36:16 AM > Subject: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 > assignment policy for IXPs) - Moving to Last Call > >> Still support this proposal. >> > -- Arnold Nipper Chief Technology Evangelist and Co-Founder DE-CIX Management GmbH Lindleystra?e 12 | 60314 Frankfurt a.M. | Germany Phone +49 69 1730902 22 | Mobile +49 172 2650958 arnold.nipper at de-cix.net | www.de-cix.net Geschaeftsfuehrer Harald A. Summa and Sebastian Seifert Registergericht AG Koeln HRB 51135 Want to work at DE-CIX: https://de-cix.net/en/about-de-cix/careers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From matthias.wichtlhuber at de-cix.net Mon Oct 7 09:39:36 2019 From: matthias.wichtlhuber at de-cix.net (Matthias Wichtlhuber) Date: Mon, 7 Oct 2019 07:39:36 +0000 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: , Message-ID: <1cf515a8f87f4891940f9bfd49d5484d@de-cix.net> I also fully support the proposal. BR Matthias -- Dr.-Ing. Matthias Wichtlhuber Researcher ------------------------------ DE-CIX Management GmbH Lindleystr. 12, 60314 Frankfurt (Germany) phone: +49 69 1730902 141 mobile: +49 171 3836036 fax: +49 69 4056 2716 e-mail: matthias.wichtlhuber at de-cix.net web: www.de-cix.net ------------------------------ DE-CIX Management GmbH Executive Directors: Harald A. Summa and Sebastian Seifert Trade registry: District court (Amtsgericht) Cologne, HRB 51135 Registered office: Lichtstr. 43i, 50825 Cologne ________________________________________ Von: address-policy-wg im Auftrag von Arnold Nipper Gesendet: Montag, 7. Oktober 2019 08:08 An: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call I fully support this proposal Cheers Arnold On 07.10.2019 07:30, Luca TOP-IX wrote: > I support this proposal > > > ? > Luca Cicchelli > > www.top-ix.org > > ------ Original Message ------ > From: "Andy Davidson" > To: "address-policy-wg at ripe.net" > Sent: 10/5/2019 12:36:16 AM > Subject: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 > assignment policy for IXPs) - Moving to Last Call > >> Still support this proposal. >> > -- Arnold Nipper Chief Technology Evangelist and Co-Founder DE-CIX Management GmbH Lindleystra?e 12 | 60314 Frankfurt a.M. | Germany Phone +49 69 1730902 22 | Mobile +49 172 2650958 arnold.nipper at de-cix.net | www.de-cix.net Geschaeftsfuehrer Harald A. Summa and Sebastian Seifert Registergericht AG Koeln HRB 51135 Want to work at DE-CIX: https://de-cix.net/en/about-de-cix/careers From bijal at euro-ix.net Mon Oct 7 13:17:53 2019 From: bijal at euro-ix.net (Bijal Sanghani) Date: Mon, 7 Oct 2019 12:17:53 +0100 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: <1cf515a8f87f4891940f9bfd49d5484d@de-cix.net> References: <1cf515a8f87f4891940f9bfd49d5484d@de-cix.net> Message-ID: Happy to see this at last call, I strongly support the proposal. Kind regards, Bijal Sanghani Euro-IX > On 7 Oct 2019, at 08:39, Matthias Wichtlhuber wrote: > > I also fully support the proposal. > > BR > Matthias > > -- > Dr.-Ing. Matthias Wichtlhuber > Researcher > ------------------------------ > DE-CIX Management GmbH > Lindleystr. 12, 60314 Frankfurt (Germany) > phone: +49 69 1730902 141 > mobile: +49 171 3836036 > fax: +49 69 4056 2716 > e-mail: matthias.wichtlhuber at de-cix.net > web: www.de-cix.net > ------------------------------ > DE-CIX Management GmbH > Executive Directors: Harald A. Summa and Sebastian Seifert > Trade registry: District court (Amtsgericht) Cologne, HRB 51135 > Registered office: Lichtstr. 43i, 50825 Cologne > > ________________________________________ > Von: address-policy-wg im Auftrag von Arnold Nipper > Gesendet: Montag, 7. Oktober 2019 08:08 > An: address-policy-wg at ripe.net > Betreff: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call > > I fully support this proposal > > > Cheers > Arnold > > On 07.10.2019 07:30, Luca TOP-IX wrote: > >> I support this proposal >> >> >> ? >> Luca Cicchelli >> >> www.top-ix.org >> >> ------ Original Message ------ >> From: "Andy Davidson" >> To: "address-policy-wg at ripe.net" >> Sent: 10/5/2019 12:36:16 AM >> Subject: Re: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 >> assignment policy for IXPs) - Moving to Last Call >> >>> Still support this proposal. >>> >> > > > -- > Arnold Nipper > Chief Technology Evangelist and Co-Founder > > DE-CIX Management GmbH > Lindleystra?e 12 | 60314 Frankfurt a.M. | Germany > Phone +49 69 1730902 22 | Mobile +49 172 2650958 > arnold.nipper at de-cix.net | www.de-cix.net > Geschaeftsfuehrer Harald A. Summa and Sebastian Seifert > Registergericht AG Koeln HRB 51135 > > Want to work at DE-CIX: https://de-cix.net/en/about-de-cix/careers > > From wolfgang.tremmel at de-cix.net Mon Oct 7 14:14:40 2019 From: wolfgang.tremmel at de-cix.net (Wolfgang Tremmel) Date: Mon, 7 Oct 2019 12:14:40 +0000 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: <2FF66A76-4904-40FE-B0FD-858ACF4CA4DB@a2b-internet.com> References: <2FF66A76-4904-40FE-B0FD-858ACF4CA4DB@a2b-internet.com> Message-ID: I also strongly support this proposal. > On 7. Sep 2019, at 15:29, Erik Bais wrote: > > The next phase is Last Call. -- Wolfgang Tremmel Phone +49 69 1730902 0 | wolfgang.tremmel at de-cix.net Executive Directors: Harald A. Summa and Sebastian Seifert | Trade Registry: AG Cologne, HRB 51135 DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main | Germany | www.de-cix.net From ripe-wgs at radu-adrian.feurdean.net Mon Oct 7 14:50:14 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Mon, 07 Oct 2019 14:50:14 +0200 Subject: [address-policy-wg] =?utf-8?q?2019-05_Policy_Proposal_=28Revised?= =?utf-8?q?_IPv4_assignment_policy_for_IXPs=29_-_Moving_to_Last_Call?= In-Reply-To: References: <1cf515a8f87f4891940f9bfd49d5484d@de-cix.net> Message-ID: Strong support here too ! -- Radu-Adrian FEURDEAN From pierre at baume.org Mon Oct 7 15:37:06 2019 From: pierre at baume.org (Pierre Baume) Date: Mon, 7 Oct 2019 15:37:06 +0200 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: <1cf515a8f87f4891940f9bfd49d5484d@de-cix.net> Message-ID: Dear all, I support the proposal. Kind regards. Pierre. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apwg at c4inet.net Mon Oct 7 16:57:50 2019 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Mon, 7 Oct 2019 15:57:50 +0100 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: <2FF66A76-4904-40FE-B0FD-858ACF4CA4DB@a2b-internet.com> References: <2FF66A76-4904-40FE-B0FD-858ACF4CA4DB@a2b-internet.com> Message-ID: <20191007145750.GA2680@cilantro.c4inet.net> Fine with me. Support. rgds, Sascha Luck On Sat, Sep 07, 2019 at 01:29:04PM +0000, Erik Bais wrote: >Dear WG, > >The AP WG Chairs have seen more than sufficient support to get the policy to the next phase. >The policy proposal is about extending the IXP pool with an additional /16 from the current IP Pool at the NCC. > >The next phase is Last Call. From Piotr.Strzyzewski at polsl.pl Mon Oct 7 17:48:17 2019 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Mon, 7 Oct 2019 17:48:17 +0200 Subject: [address-policy-wg] 2019-05 Policy Proposal (Revised IPv4 assignment policy for IXPs) - Moving to Last Call In-Reply-To: References: Message-ID: <20191007154817.GA17454@hydra.ck.polsl.pl> On Mon, Oct 07, 2019 at 08:08:36AM +0200, Arnold Nipper wrote: > I fully support this proposal +1 Piotr -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From mschmidt at ripe.net Tue Oct 8 12:24:13 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 8 Oct 2019 12:24:13 +0200 Subject: [address-policy-wg] RIPE 78 Address Policy WG Draft Minutes Message-ID: Dear colleagues, The draft minutes from the Address Policy Working Group sessions at RIPE 78 have now been published: https://www.ripe.net/participate/ripe/wg/ap/minutes/ripe-78-address-policy-working-group-minutes Please let us know of any corrections or amendments. Kind regards, Marco Schmidt Policy Officer RIPE NCC From mschmidt at ripe.net Tue Oct 8 13:00:50 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 8 Oct 2019 13:00:50 +0200 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) Message-ID: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> Dear colleagues, A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 Policy" is now available for discussion. This proposal aims to remove obsoleted text and simplify the IPv6 policy. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-06 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 6 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC From sander at steffann.nl Tue Oct 8 16:01:33 2019 From: sander at steffann.nl (Sander Steffann) Date: Tue, 8 Oct 2019 16:01:33 +0200 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> References: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> Message-ID: <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> Hi, > A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 Policy" > is now available for discussion. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. I think this is a sensible update. Support. Cheers, Sander From nick at foobar.org Tue Oct 8 17:51:14 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 8 Oct 2019 16:51:14 +0100 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> References: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> Message-ID: Sander Steffann wrote on 08/10/2019 15:01: >> A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 Policy" >> is now available for discussion. >> >> This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > I think this is a sensible update. Support. agreed - this looks like a good idea, and thanks to Jordi for doing some housekeeping in this area. Nick From gert at space.net Tue Oct 8 22:56:48 2019 From: gert at space.net (Gert Doering) Date: Tue, 8 Oct 2019 22:56:48 +0200 Subject: [address-policy-wg] 2019-05 Last Call for Comments (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: <20191008205648.GA68951@Space.Net> Dear AP WG, On Mon, Sep 09, 2019 at 02:57:37PM +0700, Marco Schmidt wrote: > Proposal 2019-05, "Revised IPv4 assignment policy for IXPs", is now in > Concluding Phase. [..] > 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 8 October 2019 and must be supported by an > explanation. The Last Call phase is now over. According to the PDP, we do not need any voices of support *here*, but you decided to have some excitement on the last day and so I'm happy to state "we have fairly strong support, and no opposing voices". With that, I declare consensus and ask the RIPE NCC to go implement. *Now* we can start discussing a new proposal to change assignment sizes... :) Gert Doering -- APWG chair -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From rfg at tristatelogic.com Wed Oct 9 06:29:38 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 08 Oct 2019 21:29:38 -0700 Subject: [address-policy-wg] 62.222.0.0/15 Message-ID: <51689.1570595378@segfault.tristatelogic.com> I didn't realize till now that RIPE NCC was still giving out IPv4 /15 blocks as recently as August. Now that I know, may I have one too please? ================================================================= inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE admin-c: DW5409-RIPE tech-c: DW5409-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE From jacob at rezero.org Wed Oct 9 07:00:56 2019 From: jacob at rezero.org (Jacob Slater) Date: Wed, 9 Oct 2019 01:00:56 -0400 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <51689.1570595378@segfault.tristatelogic.com> References: <51689.1570595378@segfault.tristatelogic.com> Message-ID: According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics, this appears to have been a transfer, not a new allocation. Jacob Slater On Wed, Oct 9, 2019 at 12:30 AM Ronald F. Guilmette wrote: > I didn't realize till now that RIPE NCC was still giving out IPv4 /15 > blocks > as recently as August. > > Now that I know, may I have one too please? > > ================================================================= > inetnum: 62.222.0.0 - 62.223.255.255 > netname: IE-COOLWAVE-20010321 > country: IE > org: ORG-CCL78-RIPE > admin-c: DW5409-RIPE > tech-c: DW5409-RIPE > status: ALLOCATED PA > mnt-by: mnt-ie-coolwave-1 > mnt-by: RIPE-NCC-HM-MNT > created: 2019-08-20T11:55:01Z > last-modified: 2019-08-20T11:55:01Z > source: RIPE > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david at xtom.com Wed Oct 9 07:14:37 2019 From: david at xtom.com (David Guo) Date: Wed, 9 Oct 2019 05:14:37 +0000 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: References: <51689.1570595378@segfault.tristatelogic.com>, Message-ID: IE-COOLWAVE-20010321 use time machine and go back to year 2001 ________________________________ From: address-policy-wg on behalf of Jacob Slater Sent: Wednesday, October 9, 2019 1:00:56 PM To: Ronald F. Guilmette Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 62.222.0.0/15 According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics, this appears to have been a transfer, not a new allocation. Jacob Slater On Wed, Oct 9, 2019 at 12:30 AM Ronald F. Guilmette > wrote: I didn't realize till now that RIPE NCC was still giving out IPv4 /15 blocks as recently as August. Now that I know, may I have one too please? ================================================================= inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE admin-c: DW5409-RIPE tech-c: DW5409-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik at clouvider.co.uk Wed Oct 9 07:36:10 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Wed, 9 Oct 2019 05:36:10 +0000 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: References: Message-ID: <98D0ADE2-4012-4070-9CB5-CFCE1C8458F8@clouvider.co.uk> ?cooling? down, pun to the network name intended, is recommended before publicly accusing someone of any wrongdoing. 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 9 Oct 2019, at 06:29, David Guo via address-policy-wg wrote: ? IE-COOLWAVE-20010321 use time machine and go back to year 2001 ________________________________ From: address-policy-wg on behalf of Jacob Slater Sent: Wednesday, October 9, 2019 1:00:56 PM To: Ronald F. Guilmette Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 62.222.0.0/15 According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics, this appears to have been a transfer, not a new allocation. Jacob Slater On Wed, Oct 9, 2019 at 12:30 AM Ronald F. Guilmette > wrote: I didn't realize till now that RIPE NCC was still giving out IPv4 /15 blocks as recently as August. Now that I know, may I have one too please? ================================================================= inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE admin-c: DW5409-RIPE tech-c: DW5409-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Oct 9 07:37:34 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 08 Oct 2019 22:37:34 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: Message-ID: <51991.1570599454@segfault.tristatelogic.com> In message , Jacob Slater wrote: >According to >https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics, >this appears to have been a transfer, not a new allocation. I guess that I will have to speak to my friends in the DB working group about that, because there is *no* indication of this whatsoever in either the current -or- the historical records for the 62.222.0.0/15 block, specifically. The only historical record on file for this block is as follows: ======================================================================== % Version 1 (current version) of object "62.222.0.0 - 62.223.255.255" % This version was a UPDATE operation on 2019-08-20 13:55 inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE From rfg at tristatelogic.com Wed Oct 9 07:52:40 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 08 Oct 2019 22:52:40 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: Message-ID: <52052.1570600360@segfault.tristatelogic.com> In message , David Guo wrote: >IE-COOLWAVE-20010321 > >use time machine and go back to year 2001 Mine's in the shop, having some valves replaced. Can I borrow your's? But seriously folks, if 62.222.0.0/15 is just a merge of its two constituent /16 blocks, then why is it that the data base contains -lots- of historical records about 62.223.0.0/16, going all the way back to 2007-06-28 and yet it contains -no- historical records whatsoever regarding 62.222.0.0/16 ? From dominik at clouvider.co.uk Wed Oct 9 07:54:05 2019 From: dominik at clouvider.co.uk (Dominik Nowacki) Date: Wed, 9 Oct 2019 05:54:05 +0000 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <51991.1570599454@segfault.tristatelogic.com> References: <51991.1570599454@segfault.tristatelogic.com> Message-ID: <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk> How about if this wasn?t full allocation transfer ? You are making a query about the particular exact size of the block so it wouldn?t show? Also, baffled that you have the guts to continue on this quest following an obviously false accusation that you started it with? 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 9 Oct 2019, at 06:37, Ronald F. Guilmette wrote: ?In message , Jacob Slater wrote: According to https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/within-ripe-ncc-service-region/ipv4-transfer-statistics, this appears to have been a transfer, not a new allocation. I guess that I will have to speak to my friends in the DB working group about that, because there is *no* indication of this whatsoever in either the current -or- the historical records for the 62.222.0.0/15 block, specifically. The only historical record on file for this block is as follows: ======================================================================== % Version 1 (current version) of object "62.222.0.0 - 62.223.255.255" % This version was a UPDATE operation on 2019-08-20 13:55 inetnum: 62.222.0.0 - 62.223.255.255 netname: IE-COOLWAVE-20010321 country: IE org: ORG-CCL78-RIPE status: ALLOCATED PA mnt-by: mnt-ie-coolwave-1 mnt-by: RIPE-NCC-HM-MNT created: 2019-08-20T11:55:01Z last-modified: 2019-08-20T11:55:01Z source: RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Oct 9 07:58:33 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 08 Oct 2019 22:58:33 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <98D0ADE2-4012-4070-9CB5-CFCE1C8458F8@clouvider.co.uk> Message-ID: <52098.1570600713@segfault.tristatelogic.com> In message <98D0ADE2-4012-4070-9CB5-CFCE1C8458F8 at clouvider.co.uk>, Dominik Nowacki wrote: >?cooling? down, pun to the network name intended, is recommended before >publicly accusing someone of any wrongdoing. Where the heck did THAT come from?? Color me perplexed. Who said anything about "wrongdoing"? I merely asked if /15s were still in stock and available down at RIPE NCC Central. If so, I'd like to get in line early and often. I always hate to miss out on special Fall sales events. Regards, rfg From rfg at tristatelogic.com Wed Oct 9 08:27:58 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 08 Oct 2019 23:27:58 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk> Message-ID: <52215.1570602478@segfault.tristatelogic.com> In message <51955AEB-477D-4020-B6CD-67B8605BF0AD at clouvider.co.uk>, Dominik Nowacki wrote: >How about if this wasn?t full allocation transfer ? You are making a query >about the particular exact size of the block so it wouldn?t show? > >Also, baffled that you have the guts to continue on this quest following an >obviously false accusation that you started it with? Sir, I do think you have me mixed up with someone else. I have made no "acccusation" against anyone for anything. I think that you may perhaps be mistaking my desire to understand why the WHOIS data base queries sometimes (often?) yield results which are both surprising and entirely non-intutive, as I have just amply illustrated, I think, for something which is somehow accusatory towards some resource holder. I do think that the evidence shows that there is at least some recognizable possibility that the data base query mechanisms may be operating in a less than ideal manner, and thus producing less than ideal results. But even if that is verified to be true, then my only "quest" would be to try to get the NCC folks to fix the broken data base functionality... a laudable goal which I would hope would garner nearly universal support. Regards, rfg P.S. Perhaps I am now a victim of my own success. I am aware, as are others, I guess, that over time I have been rather successful at ferreting out instances in which various IPv4 blocks somehow ended up in the Wrong Hands. But I hope that everyone will still give me the benefit of the doubt, regadless of that, and allow for the possibility that when I raise an issue about a data base quirk, I really am only looking to discuss the data base quirk, and that I have neither any hidden meaning nor any hidden agenda. Of couse, if the simple example I posted is *not* merely a result of either my misunderstanding of the data base access methods (most likely explanation) -or- a result of an actual obscure failure of the data base or its access methods, then the only possibility left is that some party did indeed get a /15 in August of 2019, in clear contravention to established RIPE policy at the time. This is so obviously unlikely however that it can be almost entirely discounted as even being a possibility. So eiher I'm confused about how I am interpreting the data or else the data base access methods are giving confusing (and misleading?) responses. In either case, I'd like to see the problem eliminated. From ripe-wgs at radu-adrian.feurdean.net Wed Oct 9 08:50:38 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 09 Oct 2019 08:50:38 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <51991.1570599454@segfault.tristatelogic.com> References: <51991.1570599454@segfault.tristatelogic.com> Message-ID: On Wed, Oct 9, 2019, at 07:37, Ronald F. Guilmette wrote: > I guess that I will have to speak to my friends in the DB working group > about that, because there is *no* indication of this whatsoever in > either the current -or- the historical records for the 62.222.0.0/15 > block, specifically. Probably a less specific.... When a less specific is splitted for transfer, the transferred chunk (didn't check for the remaining ones, but I suppose it's the same), has the "created date" of the transfer, but the date in the netname retains the date of the initial allocation. -- Radu-Adrian FEURDEAN From david at xtom.com Wed Oct 9 08:58:22 2019 From: david at xtom.com (David Guo) Date: Wed, 9 Oct 2019 06:58:22 +0000 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <52215.1570602478@segfault.tristatelogic.com> References: <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk> <52215.1570602478@segfault.tristatelogic.com> Message-ID: Why don't you do some search? https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.0.0/16#whois inetnum: 62.222.0.0 - 62.223.255.255 org: ORG-CB2-RIPE netname: NL-COOLWAVE-20001027 country: NL admin-c: DW581-RIPE tech-c: DW581-RIPE tech-c: SM7902-RIPE status: ALLOCATED PA notify: inoc at carrier1.com mnt-by: RIPE-NCC-HM-MNT mnt-by: IBIS-MNT mnt-routes: CARRIER1-MNT created: 2002-07-25T12:34:10Z last-modified: 2017-07-10T10:10:24Z source: RIPE created: 2002-07-25T12:34:10Z Regards, David -----Original Message----- From: address-policy-wg On Behalf Of Ronald F. Guilmette Sent: Wednesday, October 9, 2019 2:28 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 62.222.0.0/15 In message <51955AEB-477D-4020-B6CD-67B8605BF0AD at clouvider.co.uk>, Dominik Nowacki wrote: >How about if this wasn?t full allocation transfer ? You are making a >query about the particular exact size of the block so it wouldn?t show? > >Also, baffled that you have the guts to continue on this quest >following an obviously false accusation that you started it with? Sir, I do think you have me mixed up with someone else. I have made no "acccusation" against anyone for anything. I think that you may perhaps be mistaking my desire to understand why the WHOIS data base queries sometimes (often?) yield results which are both surprising and entirely non-intutive, as I have just amply illustrated, I think, for something which is somehow accusatory towards some resource holder. I do think that the evidence shows that there is at least some recognizable possibility that the data base query mechanisms may be operating in a less than ideal manner, and thus producing less than ideal results. But even if that is verified to be true, then my only "quest" would be to try to get the NCC folks to fix the broken data base functionality... a laudable goal which I would hope would garner nearly universal support. Regards, rfg P.S. Perhaps I am now a victim of my own success. I am aware, as are others, I guess, that over time I have been rather successful at ferreting out instances in which various IPv4 blocks somehow ended up in the Wrong Hands. But I hope that everyone will still give me the benefit of the doubt, regadless of that, and allow for the possibility that when I raise an issue about a data base quirk, I really am only looking to discuss the data base quirk, and that I have neither any hidden meaning nor any hidden agenda. Of couse, if the simple example I posted is *not* merely a result of either my misunderstanding of the data base access methods (most likely explanation) -or- a result of an actual obscure failure of the data base or its access methods, then the only possibility left is that some party did indeed get a /15 in August of 2019, in clear contravention to established RIPE policy at the time. This is so obviously unlikely however that it can be almost entirely discounted as even being a possibility. So eiher I'm confused about how I am interpreting the data or else the data base access methods are giving confusing (and misleading?) responses. In either case, I'd like to see the problem eliminated. From rfg at tristatelogic.com Wed Oct 9 09:01:22 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 09 Oct 2019 00:01:22 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: Message-ID: <52470.1570604482@segfault.tristatelogic.com> In message , "Radu-Adrian FEURDEAN" wrote: >On Wed, Oct 9, 2019, at 07:37, Ronald F. Guilmette wrote: >> I guess that I will have to speak to my friends in the DB working group >> about that, because there is *no* indication of this whatsoever in >> either the current -or- the historical records for the 62.222.0.0/15 >> block, specifically. > >Probably a less specific.... >When a less specific is splitted for transfer... Sorry. You lost me. I thought that we were discussing something that had been -aggregated-, not split. Did I misunderstand? Regards, rfg From rfg at tristatelogic.com Wed Oct 9 09:14:23 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 09 Oct 2019 00:14:23 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: Message-ID: <52535.1570605263@segfault.tristatelogic.com> In message , David Guo wrote: >Why don't you do some search? I did. I do. I am. I have! Please excuse me for having foolishly tried to obtain actual authoritative information from the actual RIPE WHOIS server, rather than from a Wayback Machine (archive.org) copy of something that appeared on the bgpview.io web site. Regardless of what that other non-authoritative source of information may say, may I ask you to please tell me what *you* see when *you* perform the following two commands? whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15" Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in the outputs of these two commands. Maybe I'm just doing it wrong. Do I need to try using negative numbers as arguments to the --show-version option? Does that option accept imaginary numbers as arguments? Regards, rfg From me at cynthia.re Wed Oct 9 10:13:47 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Wed, 9 Oct 2019 10:13:47 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <52535.1570605263@segfault.tristatelogic.com> References: <52535.1570605263@segfault.tristatelogic.com> Message-ID: Hi, it doesn't show up in the versions because the transfer deleted the old item and created a new one. - Cynthia On Wed, 9 Oct 2019, 09:14 Ronald F. Guilmette, wrote: > In message < > TY2PR0101MB33421E6796B2013776568E52C5950 at TY2PR0101MB3342.apcprd01.prod.exchangelabs.com>, > > David Guo wrote: > > >Why don't you do some search? > > I did. I do. I am. I have! > > Please excuse me for having foolishly tried to obtain actual authoritative > information from the actual RIPE WHOIS server, rather than from a Wayback > Machine (archive.org) copy of something that appeared on the bgpview.io > web site. > > Regardless of what that other non-authoritative source of information > may say, may I ask you to please tell me what *you* see when *you* perform > the following two commands? > > whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" > whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15" > > Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in > the outputs of these two commands. > > Maybe I'm just doing it wrong. Do I need to try using negative numbers > as arguments to the --show-version option? > > Does that option accept imaginary numbers as arguments? > > > Regards, > rfg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Piotr.Strzyzewski at polsl.pl Wed Oct 9 10:22:26 2019 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 9 Oct 2019 10:22:26 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <52535.1570605263@segfault.tristatelogic.com> References: <52535.1570605263@segfault.tristatelogic.com> Message-ID: <20191009082226.GB21864@hydra.ck.polsl.pl> On Wed, Oct 09, 2019 at 12:14:23AM -0700, Ronald F. Guilmette wrote: > Regardless of what that other non-authoritative source of information > may say, may I ask you to please tell me what *you* see when *you* perform > the following two commands? > > whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" > whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15" > > Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in > the outputs of these two commands. > > Maybe I'm just doing it wrong. Do I need to try using negative numbers > as arguments to the --show-version option? > > Does that option accept imaginary numbers as arguments? Start from reading some documentation. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/types-of-queries/16-12-historical-queries "It is possible to query the history of operational data objects that still exist." It has been already pointed out that this /15 could have been part of something bigger or, quite contrary, part of two separate /16 or even something completely different, which means that the original object could be non-existent. Checking this out is left as an exercise for the reader. Piotr -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From ripe-wgs at radu-adrian.feurdean.net Wed Oct 9 10:31:40 2019 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Wed, 09 Oct 2019 10:31:40 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <52470.1570604482@segfault.tristatelogic.com> References: <52470.1570604482@segfault.tristatelogic.com> Message-ID: On Wed, Oct 9, 2019, at 09:01, Ronald F. Guilmette wrote: > I thought that we were discussing something that had been -aggregated-, > not split. Mea culpa, Still, the logic remains the same. The "created" field indicated when the record has been created (split, aggragation or transfer being reasons to create a new record), not when the space has been allocated. Allocation date does not have a field in its own, but that date is contained in the main block's "netname". -- Radu-Adrian FEURDEAN From garry at nethinks.com Wed Oct 9 11:04:28 2019 From: garry at nethinks.com (Garry Glendown) Date: Wed, 9 Oct 2019 11:04:28 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: References: <52470.1570604482@segfault.tristatelogic.com> Message-ID: <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8@nethinks.com> Could we please stop these "conspiracy theory" discussion? In essence, the initial question inferred that RIPE is still handing out IPV4 outside of current policies, which I'm pretty sure they don't. There are enough resources available at RIPE (DB, probably BGPlay?) that will prove it, if anybody still is inclined to require confirmation. And whoever might wonder, no, earth isn't flat, either! -- Mit freundlichen Gr??en, Garry Glendown --- Garry Glendown * Professional Services & Solutions NETHINKS GmbH | Bahnhofstra?e 16 | 36037 Fulda T +49 661 25 000 0 | F +49 661 25 000 49 | garry.glendown at nethinks.com Gesch?ftsf?hrer: Uwe Bergmann, Bastian Marmetschke Vorsitzender des Aufsichtsrats: Garry Glendown | AG Fulda HRB 2546 PGP Fingerprint: B1CF 4952 F6EB E060 8A10 B957 700E F97F B412 DD32 From me at cynthia.re Wed Oct 9 12:20:25 2019 From: me at cynthia.re (=?UTF-8?Q?Cynthia_Revstr=C3=B6m?=) Date: Wed, 9 Oct 2019 12:20:25 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8@nethinks.com> References: <52470.1570604482@segfault.tristatelogic.com> <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8@nethinks.com> Message-ID: On Wed, Oct 9, 2019 at 11:04 AM Garry Glendown wrote: > Could we please stop these "conspiracy theory" discussion? > +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at brenac.eu Wed Oct 9 19:12:34 2019 From: thomas at brenac.eu (thomas brenac) Date: Wed, 9 Oct 2019 19:12:34 +0200 Subject: [address-policy-wg] *****SPAM***** Re: 62.222.0.0/15 In-Reply-To: <20191009082226.GB21864@hydra.ck.polsl.pl> References: <52535.1570605263@segfault.tristatelogic.com> <20191009082226.GB21864@hydra.ck.polsl.pl> Message-ID: <99761b0e-88af-64a9-317b-4f1f37137a0f@brenac.eu> You see the year mentioned in the netname generated during the transfer by RIPE (always using original date) IE-COOLWAVE-20010321 and in RIPEstat: First ever seen announced by AS8918 , on *2001-03-24 00:00:00 UTC*. Kind regards On 09/10/2019 10:22, Piotr Strzyzewski via address-policy-wg wrote: > On Wed, Oct 09, 2019 at 12:14:23AM -0700, Ronald F. Guilmette wrote: >> Regardless of what that other non-authoritative source of information >> may say, may I ask you to please tell me what *you* see when *you* perform >> the following two commands? >> >> whois -h whois.ripe.net -- "--list-versions 62.222.0.0/15" >> whois -h whois.ripe.net -- "--show-version 1 62.222.0.0/15" >> >> Maybe I need new glasses, but I'm not seeing the year 2002 mentioned in >> the outputs of these two commands. >> >> Maybe I'm just doing it wrong. Do I need to try using negative numbers >> as arguments to the --show-version option? >> >> Does that option accept imaginary numbers as arguments? > Start from reading some documentation. > > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/types-of-queries/16-12-historical-queries > > "It is possible to query the history of operational data objects that > still exist." > > It has been already pointed out that this /15 could have been part of > something bigger or, quite contrary, part of two separate /16 or even > something completely different, which means that the original object > could be non-existent. Checking this out is left as an exercise for the > reader. > > Piotr > -- Thomas BRENAC https://www.brenac.eu +33686263575 Certified IPv4 Broker by RIPE NCC, ARIN, APNIC and LACNIC The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future. This message has been sent as a part of discussion between BRENAC EURL and the addressee whose name is specified above. Should you receive this message by mistake, we would be most grateful if you informed us that the message has been sent to you. In this case, we also ask that you delete this message from your mailbox, and do not forward it or any part of it to anyone else. Thank you for your cooperation and understanding. We?puts the security of the client at a high priority. Therefore, we have put efforts into ensuring that the message is error and virus-free. Unfortunately, full security of the email cannot be ensured as, despite our efforts, the data included in emails could be infected, intercepted, or corrupted. Therefore, the recipient should check the email for threats with proper software, as the sender does not accept liability for any damage inflicted by viewing the content of this email. The views and opinions included in this email belong to their author and do not necessarily mirror the views and opinions of the company. Our employees are obliged not to make any defamatory clauses, infringe, or authorize infringement of any legal right. Therefore, the company will not take any liability for such statements included in emails. In case of any damages or other liabilities arising, employees are fully responsible for the content of their emails. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Wed Oct 9 21:15:28 2019 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 9 Oct 2019 22:15:28 +0300 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: References: <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk> <52215.1570602478@segfault.tristatelogic.com> Message-ID: <4f7b4d8a-8c40-43a8-e6a8-dc4c964d7f93@efes.iucc.ac.il> On 09/10/2019 09:58, David Guo via address-policy-wg wrote: David, Thanks.? But shouldn't one be able to query something like this from some xxx.ripe.net site rather than depending on archive.org or bgpview.io? -Hank > Why don't you do some search? > > https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.0.0/16#whois > > inetnum: 62.222.0.0 - 62.223.255.255 > org: ORG-CB2-RIPE > netname: NL-COOLWAVE-20001027 > country: NL > admin-c: DW581-RIPE > tech-c: DW581-RIPE > tech-c: SM7902-RIPE > status: ALLOCATED PA > notify: inoc at carrier1.com > mnt-by: RIPE-NCC-HM-MNT > mnt-by: IBIS-MNT > mnt-routes: CARRIER1-MNT > created: 2002-07-25T12:34:10Z > last-modified: 2017-07-10T10:10:24Z > source: RIPE > > created: 2002-07-25T12:34:10Z > > Regards, > > David > From rfg at tristatelogic.com Wed Oct 9 22:04:29 2019 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 09 Oct 2019 13:04:29 -0700 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8@nethinks.com> Message-ID: <56902.1570651469@segfault.tristatelogic.com> In message <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8 at nethinks.com>, Garry Glendown wrote: >Could we please stop these "conspiracy theory" discussion? In essence, >the initial question inferred that RIPE is still handing out IPV4 >outside of current policies, which I'm pretty sure they don't. I'm sorry to learn that my modest attempts at wry humor have fallen so flat over on the Left Side of the Pond. Of course, NCC has not been giving out /15 blocks. (According to what I was reading just yesterday, NCC doesn't even have any such to give!) But if you look at the data base record that I posted, that is clearly the implication that would be derived from a straightforward reading of the plain text of the record in question: inetnum: 62.222.0.0 - 62.223.255.255 ... created: 2019-08-20T11:55:01Z Quite obviously, this is a data base problem. But before I hop onto the DB working group mailing list and start pointing out this self-evident problem/issue, I felt obliged to check here first, just in case, just to make absolutely and 1000% sure that this was not just some sort of fluke, or the result of some obscure special loophole in the current allocation policies (e.g. for "special hardship" or something like that) which would have authorized NCC to award a /15 just this past August. Now I am sure, because everyone has been so kind and generous to point out to me that no, this space was all already well and truly allocated, well before this past August. So I can now proceed with confidence and note this strange "created:" anomaly... which naturally might lead to entirely incorrect inferences... on the DB WG mailing list. Thank you all for your good humor and generosity and your help in clarifying for me the actual nature of the problem/issue here. Regards, rfg From Piotr.Strzyzewski at polsl.pl Wed Oct 9 22:25:12 2019 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 9 Oct 2019 22:25:12 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <56902.1570651469@segfault.tristatelogic.com> References: <3eb97f87-a3eb-de53-5d72-3c1b2a2cdad8@nethinks.com> <56902.1570651469@segfault.tristatelogic.com> Message-ID: <20191009202512.GB24561@hydra.ck.polsl.pl> On Wed, Oct 09, 2019 at 01:04:29PM -0700, Ronald F. Guilmette wrote: > >Could we please stop these "conspiracy theory" discussion? In essence, > >the initial question inferred that RIPE is still handing out IPV4 > >outside of current policies, which I'm pretty sure they don't. > > I'm sorry to learn that my modest attempts at wry humor have fallen so > flat over on the Left Side of the Pond. > > Of course, NCC has not been giving out /15 blocks. (According to what I > was reading just yesterday, NCC doesn't even have any such to give!) But > if you look at the data base record that I posted, that is clearly the > implication that would be derived from a straightforward reading of the > plain text of the record in question: > > inetnum: 62.222.0.0 - 62.223.255.255 > ... > created: 2019-08-20T11:55:01Z This is the same straightforward conclusion like the one that the speed limit is 35 km/h (and not mph) just because the road signs looks similar both in UK and France. Once again, be so kind and read the documentation. The created attribute means something completely different. Piotr -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From uros at ub330.net Thu Oct 10 03:38:25 2019 From: uros at ub330.net (Uros Gaber) Date: Thu, 10 Oct 2019 03:38:25 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <4f7b4d8a-8c40-43a8-e6a8-dc4c964d7f93@efes.iucc.ac.il> References: <51955AEB-477D-4020-B6CD-67B8605BF0AD@clouvider.co.uk> <52215.1570602478@segfault.tristatelogic.com> <4f7b4d8a-8c40-43a8-e6a8-dc4c964d7f93@efes.iucc.ac.il> Message-ID: Hank, IMHO best and quickest option is to check http://stat.ripe.net, for more detailed history results use your LIR account login. Uros On Wed, Oct 9, 2019 at 9:16 PM Hank Nussbacher wrote: > On 09/10/2019 09:58, David Guo via address-policy-wg wrote: > > David, > > Thanks. But shouldn't one be able to query something like this from > some xxx.ripe.net site rather than depending on archive.org or bgpview.io? > > -Hank > > > Why don't you do some search? > > > > > https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.0.0/16#whois > > > > inetnum: 62.222.0.0 - 62.223.255.255 > > org: ORG-CB2-RIPE > > netname: NL-COOLWAVE-20001027 > > country: NL > > admin-c: DW581-RIPE > > tech-c: DW581-RIPE > > tech-c: SM7902-RIPE > > status: ALLOCATED PA > > notify: inoc at carrier1.com > > mnt-by: RIPE-NCC-HM-MNT > > mnt-by: IBIS-MNT > > mnt-routes: CARRIER1-MNT > > created: 2002-07-25T12:34:10Z > > last-modified: 2017-07-10T10:10:24Z > > source: RIPE > > > > created: 2002-07-25T12:34:10Z > > > > Regards, > > > > David > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Thu Oct 10 09:39:26 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Thu, 10 Oct 2019 08:39:26 +0100 (WEST) Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) Message-ID: Hi, +1 support. Regards, Carlos ---------- Forwarded message ---------- Date: Tue, 8 Oct 2019 16:51:14 From: Nick Hilliard To: Sander Steffann Cc: RIPE Address Policy Working Group Subject: Re: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) Sander Steffann wrote on 08/10/2019 15:01: >> A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 >> Policy" >> is now available for discussion. >> >> This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > I think this is a sensible update. Support. agreed - this looks like a good idea, and thanks to Jordi for doing some housekeeping in this area. Nick From dfk at ripe.net Thu Oct 10 10:17:45 2019 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 10 Oct 2019 10:17:45 +0200 Subject: [address-policy-wg] 62.222.0.0/15 In-Reply-To: <4f7b4d8a-8c40-43a8-e6a8-dc4c964d7f93@efes.iucc.ac.il> References: <4f7b4d8a-8c40-43a8-e6a8-dc4c964d7f93@efes.iucc.ac.il> Message-ID: <487BEC90-7E61-40A3-8F05-1995F66B6E5E@ripe.net> xxx == stat --- Sent from a handheld device. > On 9. Oct 2019, at 21:16, Hank Nussbacher wrote: > > ?On 09/10/2019 09:58, David Guo via address-policy-wg wrote: > > David, > > Thanks. But shouldn't one be able to query something like this from some xxx.ripe.net site rather than depending on archive.org or bgpview.io? > > -Hank > >> Why don't you do some search? >> >> https://web.archive.org/web/20191009065654/https://bgpview.io/prefix/62.222.0.0/16#whois >> >> inetnum: 62.222.0.0 - 62.223.255.255 >> org: ORG-CB2-RIPE >> netname: NL-COOLWAVE-20001027 >> country: NL >> admin-c: DW581-RIPE >> tech-c: DW581-RIPE >> tech-c: SM7902-RIPE >> status: ALLOCATED PA >> notify: inoc at carrier1.com >> mnt-by: RIPE-NCC-HM-MNT >> mnt-by: IBIS-MNT >> mnt-routes: CARRIER1-MNT >> created: 2002-07-25T12:34:10Z >> last-modified: 2017-07-10T10:10:24Z >> source: RIPE >> >> created: 2002-07-25T12:34:10Z >> >> Regards, >> >> David >> > > > From mschmidt at ripe.net Thu Oct 10 12:02:30 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Thu, 10 Oct 2019 14:02:30 +0400 Subject: [address-policy-wg] 2019-05 Proposal Accepted (Revised IPv4 assignment policy for IXPs) Message-ID: Dear colleagues, Consensus has been reached on 2019-05, "Revised IPv4 assignment policy for IXPs". This proposal aimed 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 The new RIPE Document is called ripe-730 and is available at: https://www.ripe.net/publications/docs/ripe-730 We have already implemented the pool management part of this proposal (185.0.0.0/16 and the IPv4 fragments smaller than /24 have been added to the reserved IPv4 pool for IXPs). We estimate that this proposal will take around 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 us with your input. Kind regards, Marco Schmidt Policy Officer RIPE NCC From ebais at a2b-internet.com Thu Oct 10 12:04:02 2019 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 10 Oct 2019 10:04:02 +0000 Subject: [address-policy-wg] [policy-announce] 2019-05 Proposal Accepted (Revised IPv4 assignment policy for IXPs) In-Reply-To: References: Message-ID: Thanks for the update Marco. And thanks to all the WG members and the proposal authors for making this happen for the community. Regards, Erik Bais Co-chair AP-WG. ?On 10/10/2019, 12:01, "policy-announce on behalf of Marco Schmidt" wrote: Dear colleagues, Consensus has been reached on 2019-05, "Revised IPv4 assignment policy for IXPs". This proposal aimed 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 The new RIPE Document is called ripe-730 and is available at: https://www.ripe.net/publications/docs/ripe-730 We have already implemented the pool management part of this proposal (185.0.0.0/16 and the IPv4 fragments smaller than /24 have been added to the reserved IPv4 pool for IXPs). We estimate that this proposal will take around 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 us with your input. Kind regards, Marco Schmidt Policy Officer RIPE NCC From farmer at umn.edu Thu Oct 10 14:01:13 2019 From: farmer at umn.edu (David Farmer) Date: Thu, 10 Oct 2019 07:01:13 -0500 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> References: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> Message-ID: On Tue, Oct 8, 2019 at 9:01 AM Sander Steffann wrote: > Hi, > > > A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 > Policy" > > is now available for discussion. > > > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. > > I think this is a sensible update. Support. > > Cheers, > Sander > I support the update, but have a question that I hope leads to a possible further clarification; In section 5.4.2 is an end site intended to be an end-user at a single physical location, or the entirety of an end-user organization, that may exist in many locations or on a large multi-building campus, and therefore might easily justify an assignment shorter than /48. I agree it is difficult to imagine a single physical location needing more than a /48. On the other hand, a large multi-site organization, say with hundreds of locations or hundreds of buildings on a single campus can easily need a prefix significantly shorter than /48. Further, it seems like a waste of resources to have RIPE or a NIR review shorter prefix assignments when made for multi-site organizations or large campuses. Further, the definition of "End Site" doesn't really add much clarity to this question. 2.9. End Site An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment So, as currently written it seems a little ambiguous whether an end site is intended to refer to a single location or a single organization. Thanks. -- =============================================== 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 Piotr.Strzyzewski at polsl.pl Thu Oct 10 14:49:55 2019 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Thu, 10 Oct 2019 14:49:55 +0200 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: References: Message-ID: <20191010124955.GD12138@hydra.ck.polsl.pl> On Thu, Oct 10, 2019 at 08:39:26AM +0100, Carlos Fria?as via address-policy-wg wrote: > > Hi, > > +1 support. +1 Piotr -- Piotr Strzy?ewski Silesian University of Technology, Computer Centre Gliwice, Poland From jordi.palet at consulintel.es Thu Oct 10 15:57:33 2019 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 10 Oct 2019 08:57:33 -0500 Subject: [address-policy-wg] 2019-06 New Policy Proposal (Multiple Editorial Changes in IPv6 Policy) In-Reply-To: References: <76b37250-5991-f45e-8e1f-df31fcad5586@ripe.net> <6BFEE880-06B2-452B-96EF-443CAFD29EB4@steffann.nl> Message-ID: <750D6786-1DC5-45B4-AD52-32425109C867@consulintel.es> ?Hi David, Responding below, in-line. Regards, Jordi @jordipalet El 10/10/19 7:01, "address-policy-wg en nombre de David Farmer" escribi?: On Tue, Oct 8, 2019 at 9:01 AM Sander Steffann wrote: Hi, > A new RIPE Policy proposal, 2019-06, "Multiple Editorial Changes in IPv6 Policy" > is now available for discussion. > > This proposal aims to remove obsoleted text and simplify the IPv6 policy. I think this is a sensible update. Support. Cheers, Sander I support the update, but have a question that I hope leads to a possible further clarification; In section 5.4.2 is an end site intended to be an end-user at a single physical location, or the entirety of an end-user organization, that may exist in many locations or on a large multi-building campus, and therefore might easily justify an assignment shorter than /48. My intent is to support both cases. I agree it is difficult to imagine a single physical location needing more than a /48. On the other hand, a large multi-site organization, say with hundreds of locations or hundreds of buildings on a single campus can easily need a prefix significantly shorter than /48. Further, it seems like a waste of resources to have RIPE or a NIR review shorter prefix assignments when made for multi-site organizations or large campuses. Exactly, the point is that LIR must be able to do that by themselves, and only have it reviewed in case they request a further allocation or there is an explicit audit. Further, the definition of "End Site" doesn't really add much clarity to this question. 2.9. End Site An End Site is defined as an End User (subscriber) who has a business or legal relationship (same or associated entities) with a service provider that involves: that service provider assigning address space to the End User that service provider providing transit service for the End User to other sites that service provider carrying the End User's traffic that service provider advertising an aggregate prefix route that contains the End User's assignment So, as currently written it seems a little ambiguous whether an end site is intended to refer to a single location or a single organization. My Reading of ?An End Site is defined as an End User (subscriber) who has a business or legal relationship?, is that it applies the same to a single end-site or an end-user having multiple end-sites. If we believe that this is not correct, maybe we need to re-word that text as well? Thanks. -- =============================================== 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 =============================================== ********************************************** 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Tue Oct 15 14:43:10 2019 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 15 Oct 2019 14:43:10 +0200 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) Message-ID: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> Dear colleagues, A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" is now available for discussion. This proposal aims to change the default IXP assignment size from a /24 to a needs-based model, with a /27 as a minimum. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-07 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 13 November 2019. Regards, Marco Schmidt Policy Officer RIPE NCC From james.blessing at despres.co.uk Tue Oct 15 15:24:30 2019 From: james.blessing at despres.co.uk (James Blessing) Date: Tue, 15 Oct 2019 14:24:30 +0100 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> Message-ID: On Tue, 15 Oct 2019, 13:43 Marco Schmidt, wrote: > Dear colleagues, > > > This proposal aims to change the default IXP assignment size from a /24 > to a needs-based model, with a /27 as a minimum. > L Whilst I support the goal of the proposal the current wording doesn't parse particularly well. By changing 'once' to 'if' and then referencing returned addresses it (possibly) creates a confusion. I would go with... New IXPs will be assigned a /27 as a minimum. If an IXP requires a larger assignment, they must demonstrate need for at least 50% of the new assignment within two years. A maximum assignment of a /22 is available for a suitablly qualified IXP. Any existing addresses (such as PI) used for an IXP peering LAN shall be returned. Feel free to butcher the text further, but I hope I've explained the reason for the change in the change itself Thx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tore at fud.no Tue Oct 15 16:26:51 2019 From: tore at fud.no (Tore Anderson) Date: Tue, 15 Oct 2019 16:26:51 +0200 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> Message-ID: <5849733d-fae4-5559-1d7f-3f73282ff112@fud.no> * Marco Schmidt > A new RIPE Policy proposal, 2019-07, "Default assignment size for IXPs" > is now available for discussion. > > This proposal aims to change the default IXP assignment size from a /24 > to a needs-based model, with a /27 as a minimum. While I do support the proposal's aim of reducing the default assignment size, I would suggest that we make the default a /29 instead of a /27: - The reserved IXP pool currently contains prefixes sized /29 and /28. These can not be delegated under neither the current nor the proposed policy. However, small IXPs could make use of these just fine. I see why reason why we should ?lock them up and throw away the key?. - Looking at figure 2 at https://github.com/mwichtlh/address-policy-wg/ it would appear that ~43% of all IXPs would fit into a /28 including 100% overprovisioning (or into a /29 with no overprovisioning). This suggests that /29s and /28s would be useful and sufficient to a significant number of IXPs. - Lowering the default assignment size to a /29 does obviously not mean that IXPs that do require a /27 or larger should not receive it. They simply have to justify it, exactly the same as an IXP requesting a /{26..22} would have to under the proposed policy. This is not a unreasonable thing to ask, in my opinion - IPv4 is a very scarce resource, after all. - This might require growing IXPs to renumber from /29->/28->/27, which they would not have to do under the currently proposed policy. However, I do not think that is an unreasonable thing to ask. The smaller the IXP is, the easier it is to coordinate a renumbering process. Renumbering is in any case a process they will to go through as they grow out of the /27 currently proposed as the new default assignment size. Tore From nick at foobar.org Tue Oct 22 18:24:18 2019 From: nick at foobar.org (Nick Hilliard) Date: Tue, 22 Oct 2019 17:24:18 +0100 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> Message-ID: <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Marco Schmidt wrote on 15/10/2019 13:43: > This proposal aims to change the default IXP assignment size from a /24 > to a needs-based model, with a /27 as a minimum. This proposal doesn't seem well-thought-out. The first, and main, issue is that renumbering IXPs is a terrible headache and is something that should be avoided if possible. The sorts of problems that regularly erupt would include: - loss of service during renumbering, with traffic being forced over backup paths at times that may not suit - ixp participants being forced to undergo network changes outside their normal maintenance window procedures (some networks cannot do this). - problems with IXP prefix misorigination due to filters not being updated properly, which can cause loss of service problems. - other larger-scale configuration issues due to people making substantial config changes to their peering routers, which usually takes some time to iron out the bugs. I.e. this is not as simple as a global search + replace. INEX was a good internet citizen and started out with a /27 on our main peering LAN in 1996. When that ran out, we moved to a /26 and then a /25. We're now at /23. For each renumbering operation, we ran into the problems above, and a lot more. So from multiple experience, I wouldn't wish it on anyone to have to go through an IXP renumbering without good reason. It really is a thorough pain, especially for the IXP participants. The second issue is that there are ~220 IXPs operating in the countries in the ripe ncc region. This number is pulled from IXPDB (https://api.ixpdb.net/v1/provider/list), and cross-referenced against the list of RIPE NCC countries here: https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs A /15 has enough space for 512x/24 blocks, which means that this block will probably last indefinitely if the minimum assignment size is /24. By reducing this to /27, all that's going to happen is that IXPs and their participants will be dragged through unnecessary renumbering procedures; but it is unlikely to make the block last longer. I'd like to respectfully suggest that the proposal be dropped. Nick From martin+apwg at rodecker.nl Thu Oct 24 10:23:51 2019 From: martin+apwg at rodecker.nl (Martin Pels) Date: Thu, 24 Oct 2019 10:23:51 +0200 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: Hello, On 22/10/19 18:24, Nick Hilliard wrote: > INEX was a good internet citizen and started out with a /27 on our main > peering LAN in 1996.? When that ran out, we moved to a /26 and then a > /25.? We're now at /23.? For each renumbering operation, we ran into the > problems above, and a lot more.? So from multiple experience, I wouldn't > wish it on anyone to have to go through an IXP renumbering without good > reason.? It really is a thorough pain, especially for the IXP participants. Having gone through a renumbering exercise for an IXP myself (/22 to /21) I can confirm that this is a painful process. But it is certainly not an insurmountable challenge. Also, the smaller the IXP, the easier it is. Fewer participants means less coordination. The proposal already accommodates two years worth of growth, so it is not like a renumbering exercise would be needed very often. > The second issue is that there are ~220 IXPs operating in the countries > in the ripe ncc region.? This number is pulled from IXPDB > (https://api.ixpdb.net/v1/provider/list), and cross-referenced against > the list of RIPE NCC countries here: > > https://www.ripe.net/participate/member-support/list-of-members/list-of-country-codes-and-rirs > > > A /15 has enough space for 512x/24 blocks, which means that this block > will probably last indefinitely if the minimum assignment size is /24. Possibly. But there is no guarantee that the growth in the number of IXPs will remain the same. So being a bit conservative when there is little downside seems wise to me. I agree with James that the wording could be made a bit clearer. Furthermore I think it should at least be possible to assign a /28 or a /29 if an IXP requests this or if there are no larger blocks available. But I don't think there's anything wrong with the /27 default, so I support the proposed change in general. Kind regards, Martin From tore at fud.no Fri Oct 25 06:51:29 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 25 Oct 2019 06:51:29 +0200 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: * Martin Pels > On 22/10/19 18:24, Nick Hilliard wrote: >> INEX was a good internet citizen and started out with a /27 on our main >> peering LAN in 1996. When that ran out, we moved to a /26 and then a >> /25. We're now at /23. For each renumbering operation, we ran into the >> problems above, and a lot more. So from multiple experience, I wouldn't >> wish it on anyone to have to go through an IXP renumbering without good >> reason. It really is a thorough pain, especially for the IXP participants. > > Having gone through a renumbering exercise for an IXP myself (/22 to > /21) I can confirm that this is a painful process. But it is certainly > not an insurmountable challenge.Also, the smaller the IXP, the easier > it is. Fewer participants means less coordination. Precisely. Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool. Besides, by renumbering while the IXP is still small, valuable experience is gained. In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience. I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average). > The proposal already accommodates two years worth of growth, so it is > not like a renumbering exercise would be needed very often. Indeed, although it is actually *four* years, not two (assuming linear growth). >> A /15 has enough space for 512x/24 blocks, which means that this block >> will probably last indefinitely if the minimum assignment size is /24. > > Possibly. But there is no guarantee that the growth in the number of > IXPs will remain the same. So being a bit conservative when there is > little downside seems wise to me. Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism. It took the IXP community eight years to go from ?a /16 will do? (2011-05) to ?um, on second thought, make that a /15? (2019-05). There will be no third serving, so I agree fully that we should be conservative. > I agree with James that the wording could be made a bit clearer. > Furthermore I think it should at least be possible to assign a /28 or a > /29 if an IXP requests this or if there are no larger blocks available. > But I don't think there's anything wrong with the /27 default, so I > support the proposed change in general. Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment. However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value. I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever". Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion. Tore From arash_mpc at parsun.com Fri Oct 25 08:08:06 2019 From: arash_mpc at parsun.com (Arash Naderpour) Date: Fri, 25 Oct 2019 17:08:06 +1100 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: Hi, Do we know how many /29 we have available in the IXP reserved pool? if there are only few ones, it doesn't make scene to me set the default to /29 as it would be a good practice for just few allocations. Can someone from RIPE NCC provide us with an statistic on number of different prefixes in the IXP pool? Regards, Arash >I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever". -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Fri Oct 25 08:24:30 2019 From: cfriacas at fccn.pt (=?ISO-8859-15?Q?Carlos_Fria=E7as?=) Date: Fri, 25 Oct 2019 07:24:30 +0100 (WEST) Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: Greetings, /27 as default seems a sensible approach. While exponential growth is something that most IXPs would like to see, the reality is that it doesn't happen everywhere. Thus, I support 2019-07. Regards, Carlos On Fri, 25 Oct 2019, Tore Anderson wrote: > * Martin Pels > >> On 22/10/19 18:24, Nick Hilliard wrote: >>> INEX was a good internet citizen and started out with a /27 on our main >>> peering LAN in 1996. When that ran out, we moved to a /26 and then a >>> /25. We're now at /23. For each renumbering operation, we ran into the >>> problems above, and a lot more. So from multiple experience, I wouldn't >>> wish it on anyone to have to go through an IXP renumbering without good >>> reason. It really is a thorough pain, especially for the IXP participants. >> >> Having gone through a renumbering exercise for an IXP myself (/22 to >> /21) I can confirm that this is a painful process. But it is certainly >> not an insurmountable challenge.Also, the smaller the IXP, the easier >> it is. Fewer participants means less coordination. > > Precisely. > > Renumbering is annoying for everyone, but it is an necessary inconvenience in order to deal with IPv4 being in short supply. This is not an IXP specific consideration - I renumber server LANs with public IPv4 regularly, for example. It is definitively not fun, but it necessary to preserve my LIR's IPv4 pool. > > Besides, by renumbering while the IXP is still small, valuable experience is gained. > > In the case described by Nick, if INEX had started out with a /24 (per current policy), a renumbering operation would still have had to happen to go to the current /23. In other words, the largest and most difficult renumbering exercise would have had to be performed with zero prior experience. > > I am not convinced that would be a better situation to find oneself in than having previously renumbered every five years or so (on average). > >> The proposal already accommodates two years worth of growth, so it is >> not like a renumbering exercise would be needed very often. > > Indeed, although it is actually *four* years, not two (assuming linear growth). > >>> A /15 has enough space for 512x/24 blocks, which means that this block >>> will probably last indefinitely if the minimum assignment size is /24. >> >> Possibly. But there is no guarantee that the growth in the number of >> IXPs will remain the same. So being a bit conservative when there is >> little downside seems wise to me. > > Personally I take any claim that that an IPv4 resource will last indefinitely with a healthy dose of scepticism. > > It took the IXP community eight years to go from ?a /16 will do? (2011-05) to ?um, on second thought, make that a /15? (2019-05). > > There will be no third serving, so I agree fully that we should be conservative. > >> I agree with James that the wording could be made a bit clearer. >> Furthermore I think it should at least be possible to assign a /28 or a >> /29 if an IXP requests this or if there are no larger blocks available. >> But I don't think there's anything wrong with the /27 default, so I >> support the proposed change in general. > > Agreed on /29 - the IXP pool does contain /28 and /29 prefixes, so it is glaringly inconsistent that current policy disallows their assignment. > > However, once you accept that the minimum should be /29, then setting the default to /27 seems rather arbitrary. There's nothing special about /27 that makes it an obvious default value. > > I believe the logical thing to do is to put the default at the /29 as well. Having the default equal to the minimum is the most conservative and thus the best suited for making the IXP pool last "forever". > > Of course, that does not mean that an IXP will not get a larger assignment if it needs it. To qualify for an initial /27, for example, the IXP would only need to have 14 connections total (members, RSes, etc.) within two years of assignment. This is sufficiently accommodating for new IXPs, in my opinion. > > Tore > From tore at fud.no Fri Oct 25 08:30:21 2019 From: tore at fud.no (Tore Anderson) Date: Fri, 25 Oct 2019 08:30:21 +0200 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: <8895469c-88ba-5a40-dcb8-b449b9414d01@fud.no> * Arash Naderpour > Do we know how many /29 we have available in the IXP reserved pool? if there are only few ones, it doesn't make scene to me set the default to /29 as it would be a good practice for just few allocations. > > Can someone from RIPE NCC provide us with an statistic on number of different prefixes in the IXP pool? Hi Arash, While I'm not from the NCC, below is the complete list of blocks smaller than /24 currently found in the IXP pool (or could be in quarantine, but destined for the IXP pool nevertheless). I spot at least four /29s in it (193.58.0.48/29, 193.188.134.136/29, 193.188.134.200/29, 194.180.226.144/29). An additional 13 /29s are currently assigned; if returned, these will also be added to the IXP pool under current policy. Tore $ curl -s ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest | awk '-F|' '$3 == "ipv4" && $5 < 256 && $7 == "reserved"' ripencc||ipv4|193.34.193.128|128||reserved ripencc||ipv4|193.34.196.128|128||reserved ripencc||ipv4|193.34.199.128|128||reserved ripencc||ipv4|193.34.201.128|128||reserved ripencc||ipv4|193.58.0.48|8||reserved ripencc||ipv4|193.164.232.96|64||reserved ripencc||ipv4|193.164.232.224|32||reserved ripencc||ipv4|193.188.134.136|8||reserved ripencc||ipv4|193.188.134.200|56||reserved ripencc||ipv4|193.192.12.0|128||reserved ripencc||ipv4|193.201.145.128|128||reserved ripencc||ipv4|193.201.147.192|32||reserved ripencc||ipv4|193.201.148.128|64||reserved ripencc||ipv4|193.201.149.0|64||reserved ripencc||ipv4|193.201.149.128|64||reserved ripencc||ipv4|193.201.150.192|64||reserved ripencc||ipv4|193.201.151.64|128||reserved ripencc||ipv4|193.201.155.0|128||reserved ripencc||ipv4|193.201.157.128|128||reserved ripencc||ipv4|193.201.159.0|128||reserved ripencc||ipv4|193.218.207.64|16||reserved ripencc||ipv4|193.243.183.0|64||reserved ripencc||ipv4|193.243.183.128|64||reserved ripencc||ipv4|194.42.47.0|128||reserved ripencc||ipv4|194.93.123.0|128||reserved ripencc||ipv4|194.117.50.0|128||reserved ripencc||ipv4|194.117.55.0|128||reserved ripencc||ipv4|194.153.153.0|128||reserved ripencc||ipv4|194.153.157.0|128||reserved ripencc||ipv4|194.153.158.0|128||reserved ripencc||ipv4|194.153.159.128|128||reserved ripencc||ipv4|194.180.159.0|240||reserved ripencc||ipv4|194.180.226.0|152||reserved ripencc||ipv4|194.180.226.160|96||reserved ripencc||ipv4|194.246.39.0|96||reserved ripencc||ipv4|194.246.39.192|32||reserved ripencc||ipv4|195.13.37.128|128||reserved ripencc||ipv4|195.35.104.0|32||reserved ripencc||ipv4|195.60.80.0|96||reserved ripencc||ipv4|195.60.81.128|64||reserved ripencc||ipv4|195.60.83.32|32||reserved ripencc||ipv4|195.60.83.128|32||reserved ripencc||ipv4|195.60.84.128|128||reserved ripencc||ipv4|195.60.85.128|128||reserved ripencc||ipv4|195.60.88.0|128||reserved ripencc||ipv4|195.60.91.128|128||reserved ripencc||ipv4|195.60.92.192|64||reserved ripencc||ipv4|195.60.93.64|64||reserved ripencc||ipv4|195.60.94.128|128||reserved From andy at nosignal.org Fri Oct 25 12:54:32 2019 From: andy at nosignal.org (Andy Davidson) Date: Fri, 25 Oct 2019 10:54:32 +0000 Subject: [address-policy-wg] 2019-07 New Policy Proposal (Default assignment size for IXPs) In-Reply-To: <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> References: <77175ef4-a8c9-ddfc-da96-a33477c8f88d@ripe.net> <14e68e60-cc7c-4ce0-1488-eb8d9f90058c@foobar.org> Message-ID: <242C3E27-A08D-49A4-B3FD-D2D180FEC5CE@nosignal.org> Dear colleagues, ?On 22/10/2019, 17:24, Nick Hilliard wrote: > Marco Schmidt wrote on 15/10/2019 13:43: > > This proposal aims to change the default IXP assignment size from a /24 > > to a needs-based model, with a /27 as a minimum. > This proposal doesn't seem well-thought-out. [...] I strongly oppose the 2019-07 policy proposal for the reasons expressed by Nick Hilliard. I think an IXP operator should be able to request a longer prefix than a /24 in the IXP Assignment policy but the default assignment size should not change from a /24. IXPs need to operate on the principle of least surprise, especially as the experience and the expertise of networks connecting continues to expand beyond the traditional boundaries. Best wishes, Andy Davidson From phasani at ripe.net Thu Oct 31 15:40:42 2019 From: phasani at ripe.net (Petrit Hasani) Date: Thu, 31 Oct 2019 15:40:42 +0100 Subject: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List Message-ID: <19E11F70-0B23-432C-A919-447AC5AE0C4B@ripe.net> Dear colleagues, A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now available for discussion in the Routing Working Group This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2019-08 This proposed policy may be of interest to the Address Policy working group as well. Therefore, we encourage you to review this proposal and send your comments to before 29 November 2019. -- Petrit Hasani Policy Officer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From sander at steffann.nl Thu Oct 31 17:09:12 2019 From: sander at steffann.nl (Sander Steffann) Date: Thu, 31 Oct 2019 19:09:12 +0300 Subject: [address-policy-wg] [policy-announce] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) In-Reply-To: <51FFD4DD-A009-4D07-A84D-19123B403F9E@ripe.net> References: <51FFD4DD-A009-4D07-A84D-19123B403F9E@ripe.net> Message-ID: <60CAF58E-70C2-43A9-928C-9BBDF23B27D6@steffann.nl> Hi, > This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. > > You can find the full proposal at: > > https://www.ripe.net/participate/policies/proposals/2019-08 I have read the policy and I don't see any downside to doing this. Creating those ROAs reflects the intention correctly, so let's do this. Cheers, Sander From phasani at ripe.net Thu Oct 31 17:40:45 2019 From: phasani at ripe.net (Petrit Hasani) Date: Thu, 31 Oct 2019 17:40:45 +0100 Subject: [address-policy-wg] [policy-announce] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) In-Reply-To: <60CAF58E-70C2-43A9-928C-9BBDF23B27D6@steffann.nl> References: <51FFD4DD-A009-4D07-A84D-19123B403F9E@ripe.net> <60CAF58E-70C2-43A9-928C-9BBDF23B27D6@steffann.nl> Message-ID: <3D4D619D-8746-4596-BB76-AF0D81C3E37A@ripe.net> Hi Sander, This policy is being discussed in the routing working group. Please provide your your comments to . Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 31 Oct 2019, at 17:09, Sander Steffann wrote: > > Hi, > >> This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. >> >> You can find the full proposal at: >> >> https://www.ripe.net/participate/policies/proposals/2019-08 > > I have read the policy and I don't see any downside to doing this. Creating those ROAs reflects the intention correctly, so let's do this. > > Cheers, > Sander > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From randy at psg.com Thu Oct 31 17:57:27 2019 From: randy at psg.com (Randy Bush) Date: Thu, 31 Oct 2019 09:57:27 -0700 Subject: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List In-Reply-To: <19E11F70-0B23-432C-A919-447AC5AE0C4B@ripe.net> References: <19E11F70-0B23-432C-A919-447AC5AE0C4B@ripe.net> Message-ID: i support this proposal, but would oppose it in the anti-abuse wg. randy From sb at lab.dtag.de Thu Oct 31 18:55:35 2019 From: sb at lab.dtag.de (Sebastian Becker) Date: Thu, 31 Oct 2019 18:55:35 +0100 Subject: [address-policy-wg] 2019-08 New Policy Proposal (RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space) to be discussed on Routing Working Group Mailing List In-Reply-To: <19E11F70-0B23-432C-A919-447AC5AE0C4B@ripe.net> References: <19E11F70-0B23-432C-A919-447AC5AE0C4B@ripe.net> Message-ID: I support this proposal. -- Sebastian Becker sb at lab.dtag.de > Am 31.10.2019 um 15:40 schrieb Petrit Hasani : > > Dear colleagues, > > A new RIPE Policy proposal, 2019-08, "RPKI ROAs for Unallocated and Unassigned RIPE NCC Address Space", is now available for discussion in the Routing Working Group > > This proposal aims to instructs the RIPE NCC to create ROAs with origin AS0 for all unallocated and unassigned address space under its control. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2019-08 > > This proposed policy may be of interest to the Address Policy working group as well. > > Therefore, we encourage you to review this proposal and send your comments to before 29 November 2019. > > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: