From denis at ripe.net Tue May 8 17:17:47 2012 From: denis at ripe.net (Denis Walker) Date: Tue, 08 May 2012 17:17:47 +0200 Subject: [ncc-services-wg] Scheduled Maintenance on RIPE Database Update Server - 10 May, at 14:00 UTC Message-ID: <4FA9391B.5030207@ripe.net> [Apologies for duplicate emails] Dear colleagues, On Thursday, 10 May at 14:00 UTC (16:00 CEST), we will migrate the update service to a new server as part of our RIPE Database infrastructure upgrade. We expect the migration to take up to four hours. Part of this migration requires us to reload both the live and test database contents onto the new server. ----------------------------------- No changes during migration window ----------------------------------- No changes can be made to the RIPE Database or TEST Database during the migration. This includes the use of Syncupdates, Webupdates, RESTful API and the use of object editors provided through the LIR Portal. ----------------------------------- Hold off on sending email updates ----------------------------------- We also kindly request that you hold off on sending updates to the email update service (, ) during the migration window to allow us to make a clean restart of the new server and perform significant testing before processing any live updates. If any updates are sent to the email update service, they will be queued and run following the migration. If you do submit email updates during this time we recommend that you check the results later. ---------------------------------- RIPE Database queries unaffected ---------------------------------- Querying the RIPE Database will not be affected as this service is completely separated from the update service. However it will not be possible to query the TEST Database. We appreciate your cooperation and apologise for any inconvenience this may cause. Regards, Denis Walker Business Analyst RIPE NCC Database Group From denis at ripe.net Thu May 10 20:21:25 2012 From: denis at ripe.net (Denis Walker) Date: Thu, 10 May 2012 20:21:25 +0200 Subject: [ncc-services-wg] Scheduled Maintenance on RIPE Database Update Server - successful Message-ID: <4FAC0725.4020407@ripe.net> [Apologies for duplicate emails] Dear Colleagues, The migration of the RIPE Database update service, and the content of the RIPE and TEST Databases, to a new server has been successful. If you experience any issues with the new update service please contact our Customer Services on ripe-dbm at ripe.net. Any update sent to the email interface during the migration should have been completed. We suggest you check the database to confirm the success of those updates in case you did not get an acknowledgement message. We appreciate your cooperation and apologise for any inconvenience this may have caused. Regards, Denis Walker Business Analyst RIPE NCC Database Group From alexlh at ripe.net Wed May 16 17:33:26 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 16 May 2012 17:33:26 +0200 Subject: [ncc-services-wg] Extended delegated statistics Message-ID: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> Dear Colleagues, Since 2003, the RIPE NCC and the other RIRs have published daily files detailing all assigned and allocated IP resources. These are also known as the "delegated files" In 2011, a RIPE Labs article was published describing an extension to these files. This article is available at: https://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports Starting from Wednesday 23 May 2012, the extended delegated files will be published at the following URL: ftp://ftp.ripe.net/pub/stats/ripencc The extended delegated files will list all resources managed by the RIPE NCC, including those which make up part of the free pool. The resources will be listed like this: ripencc||ipv4|5.22.224.0|73728||available We have overhauled the code that generates the regular delegated files. One area which has been improved is the accuracy of the country code attribute for all entries, especially for direct assignments such as PI and AS Numbers. For all resources the country code was lifted from the RIPE Database object describing the resource. This was done as a one-time import and stored in our internal records. This has resulted in a massive decrease in the occurrence of the catch-all country code "EU" in both the regular and extended delegated files. However, it is still possible that there are inaccuracies with regards to the country code for some entries. Please contact lir-help at ripe.net in such cases. Regards, Alex Le Heux Policy Implementation & Coordination RIPE NCC From hank at efes.iucc.ac.il Wed May 23 10:45:07 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 23 May 2012 11:45:07 +0300 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> Message-ID: <5.1.1.6.2.20120523114344.0285f9a0@efes.iucc.ac.il> At 17:33 16/05/2012 +0200, Alex Le Heux wrote: >Dear Colleagues, > >Since 2003, the RIPE NCC and the other RIRs have published daily files >detailing all assigned and allocated IP resources. These are also known >as the "delegated files" > >In 2011, a RIPE Labs article was published describing an extension to >these files. This article is available at: > >https://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports > >Starting from Wednesday 23 May 2012, the extended delegated files will >be published at the following URL: > >ftp://ftp.ripe.net/pub/stats/ripencc I am looking at ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-20120523 and find it hasn't been updated. -Hank >The extended delegated files will list all resources managed by the RIPE >NCC, including those which make up part of the free pool. The resources >will be listed like this: > >ripencc||ipv4|5.22.224.0|73728||available > >We have overhauled the code that generates the regular delegated files. >One area which has been improved is the accuracy of the country code >attribute for all entries, especially for direct assignments such as PI >and AS Numbers. For all resources the country code was lifted from the >RIPE Database object describing the resource. This was done as a >one-time import and stored in our internal records. This has resulted in >a massive decrease in the occurrence of the catch-all country code "EU" >in both the regular and extended delegated files. > >However, it is still possible that there are inaccuracies with regards >to the country code for some entries. Please contact lir-help at ripe.net >in such cases. > >Regards, > >Alex Le Heux >Policy Implementation & Coordination >RIPE NCC From alexlh at ripe.net Wed May 23 11:13:32 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Wed, 23 May 2012 11:13:32 +0200 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <5.1.1.6.2.20120523114344.0285f9a0@efes.iucc.ac.il> References: <5.1.1.6.2.20120523114344.0285f9a0@efes.iucc.ac.il> Message-ID: <3FAD0F78-28E3-4511-BF56-D5EF6EB9B4DC@ripe.net> > I am looking at > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-20120523 > and find it hasn't been updated. Dear Hank, The files are generated in the evening. Apologies that I did not make this more clear in the announcement. Best regards, Alex Le Heux Policy Implementation & Coordination RIPE NCC From tore.anderson at redpill-linpro.com Thu May 24 07:24:26 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 24 May 2012 07:24:26 +0200 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> References: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> Message-ID: <4FBDC60A.7080809@redpill-linpro.com> * Alex Le Heux > Starting from Wednesday 23 May 2012, the extended delegated files will > be published at the following URL: > > ftp://ftp.ripe.net/pub/stats/ripencc Hello, There are some problems with the delegated-ripencc-20120423 and delegated-ripencc-extended-20120423 currently available on the FTP: Firstly, the headers in both files indicate that they are current as of 20120424, which obviously is an impossiblity since that's today and at the time of writing, the NCC hasn't even opened yet. Secondly, and more importantly, both files are missing recent delegations. The most recent delegations listed in the files are dated 20120504. The NCC has certainly made plenty of delegations since 20120504, though. For what it's worth, the 2012/delegated-ripencc-20120523.bz2 file does not suffer from either of these problems. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From hank at efes.iucc.ac.il Thu May 24 07:47:17 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 24 May 2012 08:47:17 +0300 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <4FBDC60A.7080809@redpill-linpro.com> References: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> Message-ID: <5.1.1.6.2.20120524084301.026b5688@efes.iucc.ac.il> At 07:24 24/05/2012 +0200, Tore Anderson wrote: >* Alex Le Heux > > > Starting from Wednesday 23 May 2012, the extended delegated files will > > be published at the following URL: > > > > ftp://ftp.ripe.net/pub/stats/ripencc > >Hello, > >There are some problems with the delegated-ripencc-20120423 and >delegated-ripencc-extended-20120423 currently available on the FTP: Another problem is that the previous file was sorted by IP and now it is sorted by allocated/assigned field and then only by IP so one needs to know whether the IP block is allocated or assigned and jumping back and forth between the 2 sections. Can the file be sorted once gain by IP? Thanks, Hank >Firstly, the headers in both files indicate that they are current as of >20120424, which obviously is an impossiblity since that's today and at >the time of writing, the NCC hasn't even opened yet. > >Secondly, and more importantly, both files are missing recent >delegations. The most recent delegations listed in the files are dated >20120504. The NCC has certainly made plenty of delegations since >20120504, though. > >For what it's worth, the 2012/delegated-ripencc-20120523.bz2 file does >not suffer from either of these problems. > >Best regards, >-- >Tore Anderson >Redpill Linpro AS - http://www.redpill-linpro.com/ From alexlh at ripe.net Thu May 24 10:28:13 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Thu, 24 May 2012 10:28:13 +0200 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <4FBDC60A.7080809@redpill-linpro.com> References: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> <4FBDC60A.7080809@redpill-linpro.com> Message-ID: Dear Tore, > There are some problems with the delegated-ripencc-20120423 and > delegated-ripencc-extended-20120423 currently available on the FTP: Thank you for reporting these issues. We hope to have these fixed today. Best regards, Alex Le Heux RIPE NCC IP Resource Analyst From jose.pinto at pt.ibm.com Thu May 24 17:01:22 2012 From: jose.pinto at pt.ibm.com (Jose Manuel Pinto) Date: Thu, 24 May 2012 16:01:22 +0100 Subject: [ncc-services-wg] AUTO: Jose Manuel Pinto is out of the office (returning 08/06/2012) Message-ID: I am out of the office until 08/06/2012. Estou ausente at? dia 08 Jun. 2012. MC, Jos? Pinto Note: This is an automated response to your message "ncc-services-wg Digest, Vol 7, Issue 5" sent on 24/5/2012 11:00:05. This is the only notification you will receive while this person is away. From tore.anderson at redpill-linpro.com Fri May 25 08:02:23 2012 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 25 May 2012 08:02:23 +0200 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: References: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> <4FBDC60A.7080809@redpill-linpro.com> Message-ID: <4FBF206F.4010303@redpill-linpro.com> * Alex Le Heux > Thank you for reporting these issues. > > We hope to have these fixed today. I can see that they are, thanks! I have a couple questions regarding some changes from the "beta" delegated-extended files (that were available from http://albatross.ripe.net/delegated-extended/): 1) A new status field "reserved" has appeared. Most (all?) of the IPv4 resources with this status was "available" in the beta files. A couple of random examples: >From beta file: ripencc||ipv4|5.10.0.0|16384||available ripencc||ipv4|194.145.208.0|512||available >From new file: ripencc||ipv4|5.10.0.0|16384||reserved ripencc||ipv4|194.145.208.0|512||reserved Am I correct in assuming that reserved resources are either deemed to problematic for delegation by the debogon project, or recently returned resources placed in a temporary quarantine? Are there any other reasons why (IPv4) resources may end up as reserved? Will all of these reserved resources be automatically freed up and delegated by the NCC prior to implementing the last /8 policy, or will they be considered unavailable for the purpose of determining whether or not the last /8 policy's trigger criteria, ?RIPE NCC is required to make allocations from the final /8 it receives from the IANA?, is met? 2) Available resources are no longer split into CIDR boundaries. Not a big deal, but I must admit I preferred the old way from the beta file, so I am wondering if this is an intentional change or if would be possible to get the old way back. Random example: >From beta file: ripencc||ipv4|194.153.156.64|64||available ripencc||ipv4|194.153.156.128|128||available >From new file: ripencc||ipv4|194.153.156.64|192||available Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ From alexlh at ripe.net Fri May 25 11:55:42 2012 From: alexlh at ripe.net (Alex Le Heux) Date: Fri, 25 May 2012 11:55:42 +0200 Subject: [ncc-services-wg] Extended delegated statistics In-Reply-To: <4FBF206F.4010303@redpill-linpro.com> References: <2DED30C6-7F42-4DF9-81C0-57D9DE93F24A@ripe.net> <4FBDC60A.7080809@redpill-linpro.com> <4FBF206F.4010303@redpill-linpro.com> Message-ID: Dear Tore, > 1) A new status field "reserved" has appeared. Most (all?) of the IPv4 > resources with this status was "available" in the beta files. A couple > of random examples: > [...] > > Am I correct in assuming that reserved resources are either deemed to > problematic for delegation by the debogon project, or recently returned > resources placed in a temporary quarantine? Are there any other reasons > why (IPv4) resources may end up as reserved? IPv4 resources end up reserved because they are either in quarantine or because they are part of a special block not available for "normal" assignments or allocations, such as the space that is reserved for temporary assignments. Space that is actively being debogonised is listed as 'allocated'. > Will all of these reserved resources be automatically freed up and > delegated by the NCC prior to implementing the last /8 policy, or will > they be considered unavailable for the purpose of determining whether or > not the last /8 policy's trigger criteria, ?RIPE NCC is required to make > allocations from the final /8 it receives from the IANA?, is met? All space that is not part of a block that is reserved for use after we reach the last /8, such as the temporary assignment pool and the last /8 itself, will be freed up and assigned and/or allocated before we reach the last /8. > 2) Available resources are no longer split into CIDR boundaries. Not a > big deal, but I must admit I preferred the old way from the beta file, > so I am wondering if this is an intentional change or if would be > possible to get the old way back. Random example: > >> From beta file: > ripencc||ipv4|194.153.156.64|64||available > ripencc||ipv4|194.153.156.128|128||available > >> From new file: > ripencc||ipv4|194.153.156.64|192||available The file format specifically does not define entries as CIDR ranges, but as startIP+size blocks. In the "old" statistics files, some entries were split on CIDR boundaries and others were not. With the new implementation, it was decided to list entries consistently as non-CIDR ranges. Best regards, Alex Le Heux RIPE NCC From training at ripe.net Tue May 29 11:47:41 2012 From: training at ripe.net (Training Mailbox) Date: Tue, 29 May 2012 11:47:41 +0200 Subject: [ncc-services-wg] RIPE NCC Training Courses July-September 2012 - FR, AT, AZ, RU, DE, LT, CH, UK, SE, GR, IT, NL In-Reply-To: <4F423861.9090900@ripe.net> References: <4F423861.9090900@ripe.net> Message-ID: <4FC49B3D.8070208@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Marseilles, Vienna, Baku, St. Petersburg, Berlin, Vilnius, Bern, London, Stockholm, Athens, Rome and Amsterdam. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry and Resource Certification Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager From hank at efes.iucc.ac.il Thu May 31 09:29:27 2012 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 31 May 2012 10:29:27 +0300 Subject: [ncc-services-wg] Fwd: Re: Extended delegated statistics Message-ID: <5.1.1.6.2.20120531102800.026dcd10@efes.iucc.ac.il> >Date: Thu, 24 May 2012 08:47:17 +0300 >To: Tore Anderson , Alex Le Heux > >From: Hank Nussbacher >Subject: Re: [ncc-services-wg] Extended delegated statistics >Cc: ncc-services-wg at ripe.net > >At 07:24 24/05/2012 +0200, Tore Anderson wrote: >>* Alex Le Heux >> >> > Starting from Wednesday 23 May 2012, the extended delegated files will >> > be published at the following URL: >> > >> > ftp://ftp.ripe.net/pub/stats/ripencc >> >>Hello, >> >>There are some problems with the delegated-ripencc-20120423 and >>delegated-ripencc-extended-20120423 currently available on the FTP: > >Another problem is that the previous file was sorted by IP and now it is >sorted by allocated/assigned field and then only by IP so one needs to >know whether the IP block is allocated or assigned and jumping back and >forth between the 2 sections. Can the file be sorted once gain by IP? > >Thanks, >Hank I see that the file is still sorted by allocated/assigned and then by IP. Why was this changed and why can't it be changed back to the way it was? -Hank From Niall.oReilly at ucd.ie Thu May 31 18:14:27 2012 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 31 May 2012 17:14:27 +0100 Subject: [ncc-services-wg] Legacy resources: some idea of what will be in the policy proposal Message-ID: <29DFD71F-698F-42F1-ACDC-4A7C0B245EA5@ucd.ie> The transcript of the RIPE NCC Services WG session at RIPE 64 (https://ripe64.ripe.net/archives/steno/16/) records the following exchange: > AUDIENCE SPEAKER: Nigel Titley, Chairman of the board of the RIPE NCC. Just a very quick note. The charging scheme task force has delivered its report. The board is due to consider that report starting in June of this year. Could I urge you to at least give us some idea of what your policy might say fairly early on so that we can consider that? > > NIALL O'REILLY: Noted. The group of us working on drafting a policy proposal have identified most of the key elements which will be included, but a presentable proposal won't be ready without some more work. In order not to miss the opportunity which Nigel kindly took care to point out, here is "some idea of what [the] policy [proposal] might say". I expect that the main elements of the forthcoming policy proposal will include the following. Current inaccuracies in the RIPE database should be corrected without additional formality, and specifically without forcing a contractual relationship. Each legacy resource holder should have the choice of registering holdings either directly as a "small" member or indirectly as a customer of a sponsoring LIR. We understand that this matches current NCC thinking. Clarity is needed as to which RIR policies will apply to legacy resources. It is not sufficient to declare these resources subject to "all" policies, as the RIR may not have authority to apply certain policies in respect of legacy resources. It will be necessary to itemize which policies are applicable. Whenever an "obvious" potential sponsoring LIR can be identified, the NCC should request this LIR to make contact with the resource holder rather than do so directly. Such cases might be identified either from existing RIPE DB records or from current routing information. There is specific concern in the NREN community that NCC members' relationships with their customers be respected in this way. We gave more detailed attention to the question of charging, as we understand that this is a current priority of the RIPE NCC Board. We are aware of two current documents relating to charging: one, the report of the Charging Scheme Task Force (CSTF); the other, a limited-circulation document co-authored by a group for which Daniel Karrenberg has been acting as editor. The latter document may perhaps be most conveniently described as a memorandum for the Board, giving an example of how the recommendations of the CSTF might concretely be implemented. We welcome the specific attention given in this "Karrenberg document" to the situation of legacy resource holders, and particularly the idea of encouraging engagement of legacy resource holders by waiving the sign-up fee. We also appreciate the suggestion made at the TERENA conference in Reykjav?k recently by Mirjam K?hne, representing the RIPE NCC, that fees would not be charged in respect of legacy resources. Some clarification as to the conditions attached to this offer, including an indication of how long it will continue, would be helpful. Although it is certain to be superseded, we have used RIPE-499, which documents the 2011 charging scheme, as the starting point for indicating how we feel that legacy resources should be assessed in case a resource accounting assessment model is to be used in the new charging scheme. We propose that legacy address blocks are assessed with a score of one eighth of the score assessed for a PA block of equal size. We also suggest a modification to the "Karrenberg document" so that a sponsoring LIR will not be inhibited from accommodating legacy resource holders by concern over a possible change of charging band. Attached are modified versions of Appendix 1 of RIPE-499 and of Appendix F of the "Karrenberg document" which make these suggestions explicit. Best regards, Niall O'Reilly -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: legacy-holders-charging-proposal.pdf Type: application/pdf Size: 97950 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: