[db-wg] Announcement: IPv4 Early Registration Transfer Test

[leo vegoda leo@localhost]

Dear Collegues,

Following from the work of the ERX Task Force in October,
the four RIRs will begin a test transfer on Monday, 9 
December 2002.

   <http://www.ripe.net/db/erx/>

The objective of the test transfer is to estimate time and 
resources needed to carry out the whole project as well as 
further elaborate procedures and identify issues.

43 networks from one range (129.0.0.0/8) will be transferred 
to the RIPE Database during this test phase according to 
the timeline below. A detailed list of the networks can be 
found at: 

   <http://www.ripe.net/db/erx/erx-ip/network-129.html>

Since this is an ARIN majority /8, the transfer will be of 
networks within the /8, rather than the /8 itself.

Contacts for networks to be transferred to the RIPE Database 
will be notified by e-mail on 11 December 2002. Each network 
will use a single ticket number. Please do not remove the 
ticket number from the Subject header when replying to the 
e-mail.

If you have questions regarding the process, please contact
er-transfer@localhost.

Kind regards,

-- 
leo vegoda
RIPE NCC
Registration Services


The transfer process is as below:

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

CONFLICTS

The following types of conflicts have been identified:

C1.  Record exists in ARIN Database only. There is no exact 
     matching (range wise) record in the RIPE Databas

Proposal: to update internal documentation, create the 
record in the RIPE Database and protect with a unique 
generated maintainer. The inetnum will be created with a 
status attribute value of "EARLY-REGISTRATION"(*)

C2.  Range matches records in both ARIN and RIPE Databases. 
     Meaning that contacts 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 Database, especially since RIPE Database 
     started to support the Routing Registry.

Proposal: Notify the contacts and give them time to reach 
consensus. After the deadline merge the records whose 
contacts have not responded. Database objects will not be 
locked by either ARIN or the RIPE NCC during the transfer 
process.  The RIPE NCC will not change the maintainer on 
objects following the transfer process.

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. The 
existing value of the status attribute will be preserved. 
If the existing inetnum object does not have a status 
attribute a status attribute with a value of 
"EARLY-REGISTRATION"(*) will be inserted.

C3.2 Another situation is that the registration data are 
     simply garbage.

Proposal: Notify contacts and give them time to explain 
the situation. Where no explanation is forthcoming or the 
contacts explain that the registrations are 'garbage' the 
records will be deleted.


(*) The status of "EARLY-REGISTRATION"(*) is a special 
    value proposed for the ERX networks. It has no policy 
    implications and objects with this status can be 
    created only by the Database Administration.



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 Reverse delegation domain space is cleaned up in the 
    RIPE Database (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.

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.

TIMELINE

1   Happens on 9 December 2002
2   Happens on day 10 January and only takes 1 day. At 
    this point we are done with this /8 from ARIN's point 
    of view.
3   May continue after 10 January if necessary