[db-wg] Re: ERX of v4 address space proposal

Dear Jim Fleming,

Jim Fleming wrote:
> From: "Andrei Robachevsky" <andrei at ripe.net>
> "A total of 47 /8's with 8030 records have to be transferred."
> 
> Which /8s ?
> http://www.iana.org/assignments/ipv4-address-space

The ipv4 address ranges that are subject to the ERX will be published by 
the end of the next week. Thanks for bringing this up.

Regards,

Andrei Robachevsky
RIPE NCC

> 
> 
> ----- Original Message ----- 
> From: "Andrei Robachevsky" <andrei at ripe.net>
> To: <db-wg at ripe.net>; <lir-wg at ripe.net>
> Sent: Monday, November 04, 2002 11:01 AM
> Subject: ERX of v4 address space proposal
> 
> 
> 
>>Dear Colleagues,
>>
>>Please find attached the proposal for the ERX of IPv4 address space for 
>>your review. This proposal was reviewed by the ERX-Taskforce that was 
>>set-up at the RIPE 43 meeting. Comments received were summarised and 
>>sent to both Database and LIR Working Group mailing lists.
>>
>>We would appreciate your feedback on this proposal no later than 
>>Wednesday, 13 November 2002. A timeline for this project will be issued 
>>along with final project description.
>>
>>Regards,
>>
>>Andrei Robachevsky
>>RIPE NCC
>>
>>
>>
>>ERX of v4 address space
>>-----------------------
>>
>>INTRODUCTION
>>
>>When ARIN began operations, it inherited classful blocks of
>>addresses ("legacy" space) that were issued to organisations not
>>in ARIN's region. The Regional Internet Registries (RIRs) are
>>co-ordinating the transfer of these records from the ARIN Database
>>to RIPE Database or APNIC Database, as appropriate. This is based
>>on geographic location of each resource holder. The affected
>>records include class B networks and class C ranges, particularly
>>those issued from 192/8. ARIN also maintains reverse delegation
>>for all legacy address space. Once the transfer is complete, this
>>responsibility will be distributed among the RIRs according to
>>their respective regions.
>>
>>BENEFITS
>>
>>This will enable resource holders to maintain all their records
>>in one database and End Users to interface with just one RIR for
>>all database and reverse delegation matters. This effort will also
>>help to locate address holders and recover unused or underutilised
>>address space.
>>
>>IMPACT ON RESOURCE HOLDERS
>>
>>Entities holding legacy space to be transferred can expect the
>>process to be largely transparent. While it will not affect network
>>status in any way, resource holders might be required to create
>>contact identifiers with the proper registry if they do not already
>>exist. Queries made in WHOIS for an IP block that has been
>>transferred to another RIR will be directed to the appropriate RIR.
>>
>>APPROACH
>>
>>The plan is to perform the transfer by /8. For each /8 the following
>>tasks have to be performed:
>>
>>1.  Conflicts (contacts and description) to be resolved
>>2.  Records and associated documentation to be transferred
>>3.  Reverse delegation to be set up
>>
>>A total of 47 /8's with 8030 records have to be transferred.
>>
>>CONFLICTS
>>
>>The following types of conflicts have been identified:
>>
>>C1.  Record exists in ARIN DB only. There is no exact matching (range
>>      wise) record in the RIPE DB.
>>
>>Proposal: to update internal documentation, create the record in the
>>RIPE DB and protect with a unique generated mntner.
>>
>>C2.  Range matches records in both ARIN and RIPE DBs. Meaning that
>>      contact and description may be different. Most cases indicate out
>>      of date information in one of the Databases, not real conflicts
>>      or attempts to hijack address space. What happened in most
>>      cases is that people started maintaining their allocation or
>>      assignement in the RIPE DB, especially since RIPE DB started to
>>      support the Routing Registry.
>>
>>Proposal: Notify conflicts and give time to reach consensus. After
>>the deadline merge those who haven't responded, but _do_not_lock_
>>(keep the same mntner).
>>
>>C3.0  Record exists in the RIPE DB only.
>>
>>C3.1. One reason why such situation may exist is that this is a valid
>>       RIPE NCC allocation.
>>
>>Proposal: To preserve information in the RIPE DB.
>>
>>C3.2 Another situation is that the registration data are simply garbage.
>>
>>Proposal: Notify, give time for explanations and clean up in the end.
>>
>>PROCEDURE for a /8
>>
>>1.  Pre transfer
>>1.1 Initial dump is prepared for transfer by ARIN
>>1.2 Announcement is sent to ARIN's contacts
>>1.3 Reverese delegation domain space is cleaned up in the RIPE DB
>>     (reverse domain objects for which no delegation was provided are
>>     deleted)
>>
>>2.  Transfer
>>2.1 Final dump is prepared by ARIN
>>2.2 C1 group: database records are imported, documentation is updated,
>>     contacts are notified
>>2.3 C2 group: contacts (ARIN+RIPE) are asked to reach consensus.
>>2.4 C3.2 group: contacts are notified of possible deletion.
>>2.5 DNS is updated: domain objects are generated, zone (full or partial)
>>     is generated.
>>
>>3.  Conflict resolution
>>3.1 C2 group: non responding records are merged but _not_locked_.
>>3.2 C3.2 group: records without good reasons are deleted.
>>
>>-------
>>
> 


-- 
Andrei