Transferring InterNIC space from ARIN Database to other RIR databases
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. 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: 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 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: - 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 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@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@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@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@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@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@mpn.cp.philips.com changed: geertj@ripe.net 19940106 changed: H.Sanders@mpn.cp.philips.com 19960131 changed: ripe-dbm@ripe.net 19990706 changed: ripe-dbm@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@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@rodinet.com nic-hdl: ABB2 changed: blasco@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@NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster@arin.net 19931201 source: ARIN
Dear Joao, first of all, let me say, I'm very happy to read your mail! About your proposal, the great problem of the Arin DB is that the data are connected to a person and not to a Maintainer / LIR. So, in some cases, people changed, email adresses changed, but ARIN data were the same. I think it's easy (for a lot of these objects) to understand what is the RIPE maintainer/LIR of reference. After understanding that, you can 1) ask each one how they want to do the transition; (too difficult?) 2) ask them to modify or add data in RIPE DB and after, delete data in ARIN DB. About person objects, I think a lot of ARIN data are old and incorrect (Antonio_Blasco Bonito is a good example) and it's better to prefer RIPE data and delete the ARIN data. kind regards, Gabriella -- Gabriella Paolini ------------------------------------------------- GARR - The Italian Academic and Research Network http://www.garr.it INFN-GARR Via Tiburtina, 770 I-00159 Rome - Italy tel: +39 06 433614 33 fax: +39 06 433614 44 m@il: gabriella.paolini@garr.it ------------------------------------------------- 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.
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: 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 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: - 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 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@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@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@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@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@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@mpn.cp.philips.com changed: geertj@ripe.net 19940106 changed: H.Sanders@mpn.cp.philips.com 19960131 changed: ripe-dbm@ripe.net 19990706 changed: ripe-dbm@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@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@rodinet.com nic-hdl: ABB2 changed: blasco@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@NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster@arin.net 19931201 source: ARIN
Hi, I may not have had my attention in focus when this was discussed the last time around, so I hope you will excuse me for asking some simple questions which may already have been given their reply. I understand that what is happening is that the "master source" for the affected registrations is being moved from (in our case) ARIN to the RIPE NCC. o I suppose this means that in-addr.arpa updates will after this change be done only against the RIPE database for those pieces of address space which is transferred? o Can the RIPE NCC shed some light on how the in-addr.arpa zone generation will happen "behind the scenes" after this change? E.g. what would the typical latency be between "update of registration data in the RIPE DB" to "visibility in the DNS"? o After the move of the authority for the data, what information will the ARIN database return when queried via whois? A pointer to the RIPE NCC (as happens now for the larger RIPE address blocks), or a "slave" copy of of the data from the RIPE database? I think this looks otherwise fine -- I suspect some of us will have to do some tidy-up work in the aftermath of the move no matter what. Regards, - Håvard
Hi Håvard, At 0:52 +0200 25/4/02, Havard Eidnes wrote:
Hi,
I may not have had my attention in focus when this was discussed the last time around, so I hope you will excuse me for asking some simple questions which may already have been given their reply.
I understand that what is happening is that the "master source" for the affected registrations is being moved from (in our case) ARIN to the RIPE NCC.
o I suppose this means that in-addr.arpa updates will after this change be done only against the RIPE database for those pieces of address space which is transferred?
Yes, the main goal of the exercise is to simplify the current process, which is a hassle for everyone involved.
o Can the RIPE NCC shed some light on how the in-addr.arpa zone generation will happen "behind the scenes" after this change? E.g. what would the typical latency be between "update of registration data in the RIPE DB" to "visibility in the DNS"?
The in-addr.arpa zone will (already has?) 256 entries, with delegations to nameservers of the RIRs for each /8. For each /8 one of the RIRs will be the primary. Which it is will be decided by counting the number of registrations on each /8 (ARIN has already done this). If there are registrations for several RIRs in a particular /8 then the RIR that are not the primary will send information to the primary for inclusion in the zone file. The proposed frequency of update is, I recall correctly, at least twice a day.
o After the move of the authority for the data, what information will the ARIN database return when queried via whois? A pointer to the RIPE NCC (as happens now for the larger RIPE address blocks), or a "slave" copy of of the data from the RIPE database?
A pointer seems to be the more favoured approach right now.
I think this looks otherwise fine -- I suspect some of us will have to do some tidy-up work in the aftermath of the move no matter what.
A good thing, even though it is a bit of a pain. regards João
At 11:08 25/04/2002 +0200, Joao Luis Silva Damas wrote:
o After the move of the authority for the data, what information will the ARIN database return when queried via whois? A pointer to the RIPE NCC (as happens now for the larger RIPE address blocks), or a "slave" copy of of the data from the RIPE database?
A pointer seems to be the more favoured approach right now.
A pointer would be the right thing to do, IMO. There are already several address blocks from 192/8 which are registered in the RIPE database but are listed as unassigned in ARIN's database. This creates the appearance of a conflict and will probably confuse some people. philip --
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@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@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@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@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@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@mpn.cp.philips.com changed: geertj@ripe.net 19940106 changed: H.Sanders@mpn.cp.philips.com 19960131 changed: ripe-dbm@ripe.net 19990706 changed: ripe-dbm@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@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@rodinet.com nic-hdl: ABB2 changed: blasco@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@NIS.GARR.IT nic-hdl: ABB2-ARIN changed: hostmaster@arin.net 19931201 source: ARIN
Hello all, First, I'm very delighted to see some official action with this issue to happen. Here are some comments and experiences to share. Our LIR has been dealing with this InterNIC-space issue some time already. We started our individual transfer process back 1999 and now it is almost completed. There were other off topic things than plain address transfers, that is why it has taken so long time. We have now moved five /16 allocations from ARIN to RIPE-db but there are some individual, not very well aggregatable /24's still remaining in ARIN-db and of course the reverse information is still there. From my personal experience I think the following points among others already mentioned should be noted, when transfers are planned or made: - Good coordination between ARIN,RIPE-NCC and LIR, maybe some dedicated hostmaster(s) to dig into this from RIRs part, because this project needs lots of interaction. Some documentation or FAQ for LIRs/users would be nice, how to start and proceed. Also ARIN's way of presenting db-data is somewhat different compared to RIPE. Not all LIR's and especially not customers are familiar of it at first glance. Db-reports provided by ARIN-staff proved to be very helpfull when we did the cross referencing between RIPE-db and ARIN-db. -Only one ticketing point should be used, it was frustrating to track things between two RIRs, especially when they were not so very well aware of each others doings. Not to blaim them, on the contrary, they were very helpfull in general. - LIRs should be prepared to do some detective work, because many of the individual networks are not more in the hands they were originally given and maybe even not in use at all or visible in the public network at the time of transfer moment, but some customers may still use it inside or wants to use it as a public address space in the near future. They may even have the original documentation for the address space, but they didn't knew how to update the data in ARIN-db or whom to contact. How to decide what to do with these "black" networks ? Leave as they are or delete ? Some public announcement to reach the real users ? (yes, I fully understand, the problem isn't new and the transfer isn't a solution for unmaintained LIR-independant data, but we shouldn't really add more carbage in the RIPE-db) - Status of the old networks (PA/PI), how to determine that, can we just make new PI-assignments to RIPE-db ??? - Reverse transfers should be done and timing planned with care and the confirmation is needed from the customers/LIRs, because wrongly pasted/copied data causes BIG troubles, (We unfortunately experienced this with one update) - Care should be taken not to loose the original dates with same customers in ARIN-db, otherwise it will distract the AW-tools RIPE-NCC has. Back to the original proposal.
* Proposal: to contact all affected persons in advance and have a more clear picture before the transfer. Questions to ask: - 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).
These are important and time consuming things to solve, all LIRs don't have so many staff to do this.
Needs human work.
Yes, this is _very_ true and can't be avoided :) Just my five euro cents... Kristian Rastas, Sonera Local Internet Registry
participants (6)
-
Gabriella Paolini -
Hank Nussbacher -
Havard Eidnes -
Joao Luis Silva Damas -
Kristian Rastas -
Philip Smith