Transferring InterNIC space from ARIN Database to other RIR databases

At 03:52 PM 24-04-02 +0200, Joao Luis Silva Damas wrote:
>Dear all,
>
>Sometime ago we started a thread about distributing address space issued 
>prior to the existence of the RIRs, which is currently registered at the 
>ARIN database (imported from the InterNIC's database), to the RIR that now 
>operates in the region where the address space is registered as used.
>
>Doing this would simplify processes such as modifying the name servers for 
>in-addr.arpa for those addresses, changing contact information, etc as the 
>user will issue requests for change to the RIR in their region, the one 
>with which they will normally be more familiar.
>
>Both ARIN and the RIPE NCC are now ready to proceed with this.

As someone who has already undergone forced migration of my IP space from 
ARIN to RIPE I can make some comments.


>There are some aspects, however, where community input is required and I 
>would like to ask you to comment on the proposal below.
>
>Note: the examples at the bottom are just examples. We do not want to 
>imply there is anything wrong with the objects mentioned.
>
>Best regards,
>Joao Damas
>RIPE NCC
>
>--------------------------------------------
>Proposed procedure for migration of legacy objects from ARIN Database
>
>When moving data from the ARIN database into the RIPE Database the 
>situation is not, unfortunately, always without conflicts.
>Some data that is in the ARIN database also has an entry in the RIPE database.
>
>While the ARIN database is the one which contains the authoritative 
>information for the set of name servers used in in-addr.arpa resolution 
>for the addresses in question (the in-addr.arpa zone file is generated 
>from that data), sometimes the administrative contacts seem to be more up 
>to date in the RIPE database.
>
>Below are a set of proposals for actions when transferring the data:
>
>
>I. inetnum objects
>
>1. There are several types of conflicts with the data in the RIPE
>Database:

I would suggest to contact those with conflicts.  Often, the contact info 
is out of date, so try sending email to both the ARIN and RIPE contacts.

>1.1 Exact matches with RIPE networks (4325)
>    *Proposal: to override data in the RIPE Database with ARIN's.
>       If the object in the RIPE database has a "changed" date more
>       recent than the object in the ARIN database, contact information
>       from the RIPE database is kept and the nameservers are the
>       ones in the ARIN database.
>1.2 ARIN network contains a RIPE network(s) (169)
>    1.2.1. ARIN's allocation, while multiple assignments are registered
>           in the RIPE Database
>    *Proposal: to keep RIPE's and ARIN's data
>    1.2.2. Minor Mismatch
>    *Proposal: to override data in the RIPE Database with ARIN's
>1.3 ARIN network is contained in a RIPE network (3060)
>    *Proposal: to keep ARIN's data and delete RIPE network

I don't understand this.  If ARIN has a /24 that is part of a /16 
registered in RIPE, you propose to delete the /16?!

What has happened often is the following: the ISP had a /16 from ARIN.  The 
ISP was in Europe so they did all their updates to RIPE.  They assigned 
/24s to customers.  These customers, on their own, went and registered 
these /24s in ARIN without the ISP knowing.  Later on (years), the customer 
leaves the ISP, the ISP updates the RIPE database but doesn't know about 
ARIN entries.  The ARIN entry exists as a /24 poked into the /16.  It 
should be deleted.  The RIPE data should not be deleted!

>1.4. Objects in the ARIN database only
>    *Proposal: to put ARIN's data in the RIPE Database
>
>2. Protection of the transferred inetnums
>    *Proposal:
>To create a mntner object for each ARIN's 'coordinator'. Syntax could
>be:
>
>mntner: <coord hic hdl>-MNT
>mnt-by: <coord hic hdl>-MNT
>auth:   MAIL-FROM <coord e-mail address>
>...
>
>Then we protect inetnums 'owned' by the coordinator with this
>maintainer. Should be the same level of security as currently at ARIN.
>Note: it could be different if the POC is merged/replaced by existing
>RIPE person object (see further discussion).
>
>II. POC objects
>1. Try to match POCs from ARIN DB to the existing person objects in the
>RIPE DB (762)
>The implication is that we use the person's e-mail address as authorization
>(see proposal above)
>    * Proposal: to contact all affected persons in advance and have a more 
> clear
>picture before the transfer. Questions to ask:

Excellent!

>      - Do both records represent the same person?
>      - Would (s)he like to merge the contact data, in what manner?
>After an answer to these questions is received:
>      - Discuss protection issue (existing maintainer, coordinator's
>maintainer, auth).
>
>Needs human work.
>
>2. Protection of the transferred POCs
>    * Proposal: to add mnt-by referencing a respective coordinator's
>maintainer.
>
>
>----------------
>Examples
>
>
>I.1.2.1
>inetnum:      130.242.0.0 - 130.243.255.255
>netname:      SUNETREGAB-RIPE
>descr:        European Regional Internet Registry/RIPE NCC
>descr:        These addresses have been further assigned
>descr:        to European users. Contact information can
>descr:        be found in the RIPE database at whois.ripe.net

Perhaps they can fix (spelling, typos) all the existing entries that have 
already moved and read like this now:

European Regional Internet Registry/RIPE NCC (NET-IL-ISOC-RIPE)
    These addresses have been further assigned to European users. Contact 
informatio
    be found in the RIPE database, whois.ripe.net
    NL

Or even better, the "pointer" info should be unified and not different 
depending on which block you ask for:

European Regional Internet Registry/RIPE NCC (NETBLK-RIPE-C3)
    These addresses have been further assigned to European users.
    Contact info can be found in the RIPE database, via the
    WHOIS and TELNET servers at whois.ripe.net, and at
    http://www.ripe.net/perl/whois/
    NL

On a different matter, why just inetnum?  What about ASNs?  Same issues 
exist and there are hundreds of ASNs originally allocated by ARIN and now 
being handled in RIPE.

-Hank

>country:      NL
>admin-c:      RIPE-NCC-ARIN
>rev-srv:      sunic.sunet.se
>rev-srv:      falun.dns.swip.net
>rev-srv:      ns.ripe.net
>status:       ALLOCATION
>changed:      hostmaster at arin.net 20000329
>source:       ARIN
>
>...
>inetnum:      130.242.43.0 - 130.242.43.255
>netname:      SE-TEKNISKAMUSEET
>descr:        Tekniska Museet
>country:      SE
>admin-c:      HALI1-RIPE
>tech-c:       HALI1-RIPE
>status:       ASSIGNED PA
>mnt-by:       SUNET-MNT
>changed:      fredrik at sunet.se 19981022
>source:       RIPE
>
>inetnum:      130.242.48.0 - 130.242.48.255
>netname:      SE-ARMEMUSEUM
>descr:        Statens Forsvarshistoriska Museer
>country:      SE
>admin-c:      BOMI1-RIPE
>tech-c:       LEPE1-RIPE
>status:       ASSIGNED PA
>mnt-by:       SUNET-MNT
>changed:      fredrik at sunet.se 19981022
>source:       RIPE
>...
>
>I.1.2.2
>inetnum:      131.117.0.0 - 131.117.128.255
>netname:      ZUERI
>descr:        Municipality of Zuerich
>descr:        Wilhelmstr. 10
>descr:        Zurich, 8021
>descr:        CH
>country:      CH
>admin-c:      BM153-ARIN
>status:       ASSIGNMENT
>changed:      hostmaster at arin.net 19980824
>source:       ARIN
>
>inetnum:      131.117.0.0 - 131.117.127.255
>netname:      ZUERI-NET
>descr:        Municipality of Zuerich
>descr:        Zuerich, Switzerland
>country:      CH
>admin-c:      BM16-RIPE
>tech-c:       BM16-RIPE
>changed:      huber at switch.ch 19950412
>source:       RIPE
>
>
>I.1.3
>
>inetnum:      130.138.0.0 - 130.140.255.255
>netname:      PHILIPS
>descr:        Philips C&P/NBS
>descr:        Eindhoven
>country:      NL
>admin-c:      HS6189-RIPE
>tech-c:       HS6189-RIPE
>notify:       H.Sanders at mpn.cp.philips.com
>changed:      geertj at ripe.net 19940106
>changed:      H.Sanders at mpn.cp.philips.com 19960131
>changed:      ripe-dbm at ripe.net 19990706
>changed:      ripe-dbm at ripe.net 20000225
>source:       RIPE
>
>inetnum:      130.138.0.0 - 130.138.255.255
>netname:      PHILIPS-SERI-1
>descr:        Philips Components BV
>descr:        Building BC136
>descr:        Hurkesestraat 9
>descr:        5600 MD Eindhoven
>descr:        THE NETHERLANDS
>country:      NL
>admin-c:      OK6-ARIN
>status:       REASSIGNMENT
>changed:      hostmaster at arin.net 19930413
>source:       ARIN
>
>II.1
>
>person:       Antonio_Blasco Bonito
>address:      Rodinet S.a.s.
>address:      Via Cavour 6
>address:      I-54033 Carrara
>address:      Italy
>phone:        +39 0585 779435
>fax-no:       +39 0585 757385
>e-mail:       Antonio-Blasco.Bonito at rodinet.com
>nic-hdl:      ABB2
>changed:      blasco at rodinet.com 19990310
>source:       RIPE
>
>
>person:       A. Blasco Bonito
>address:      GARR-NIS
>address:      c/o CNR-Istituto CNUCE
>address:      via Santa Maria 36
>phone:        +39 50 593246
>fax-no:       +39 50 904052
>e-mail:       bonito at NIS.GARR.IT
>nic-hdl:      ABB2-ARIN
>changed:      hostmaster at arin.net 19931201
>source:       ARIN