This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[ncc-services-wg] Extended delegated statistics
- Previous message (by thread): [ncc-services-wg] Extended delegated statistics
- Next message (by thread): [ncc-services-wg] AUTO: Jose Manuel Pinto is out of the office (returning 08/06/2012)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Alex Le Heux
alexlh at ripe.net
Fri May 25 11:55:42 CEST 2012
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
- Previous message (by thread): [ncc-services-wg] Extended delegated statistics
- Next message (by thread): [ncc-services-wg] AUTO: Jose Manuel Pinto is out of the office (returning 08/06/2012)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]