Dear Registries, We have found that the number of typos made in assignments and database updates is increasing too much lately. Especially mixing 192.x.y and 193.x.y is very popular. Also, we see a lot of 193 assignments send to <ripe-dbm>, and normal updates send in to <assign> We have for that purpose put some more strict checking on entries send in to <assign@ripe.net>. For each net that is being send in the <assign@ripe.net> we now check whether or not that network is already in the RIPE/MERIT/DDN database. If it is, it will be initially rejected and an error will be send to the NCC staff. The NCC staff will find out whether this is a typo, or just usage of the wrong e-mail address. In the latter case, we will forward the update to ripe-dbm@ripe.net, and it will be processed. If however a typo seems to be made, we will contact the person that send in the entry and try to resolve the issue. Long story short: - only NEW 193.x.y assignments to <assign@ripe.net> - ALL updates and other new entries to <ripe-dbm@ripe.net> -Marten
Marten,
We have found that the number of typos made in assignments and database updates is increasing too much lately. Especially mixing 192.x.y and 193.x.y is very popular. unfortunately typos are hitting all of the data bases:-(
- only NEW 193.x.y assignments to <assign@ripe.net> - ALL updates and other new entries to <ripe-dbm@ripe.net> The initial announcement for <assign@ripe.net> probably was not perfectly clear to restrict the use of this address to 193.x.y AND I remember that for some other reassignments (well, not my own) sent directly to DDN-NIC it was requested to channel all European reassignments via the NCC.
Thus I have been using assign@RIPE.net for updates which I intended to "write-through" to DDN-NIC (all messages including records for "old" blocks included a remark telling so). If we would know a little more about the state of how data base alignment between DDN-NIC and RIPE-NCC actually works or what the intended ways are, it might become easier for local registries to avoid misinterpretation of procedures. Sure, I know, that unfortunately progress on the data base alignement/exchange issue has been lagging far behind behind our hopes and needs for improvement, and I sure can appreciate some of the problems standing in the way (including the courtesy not explain all the problems in public). Well, we hope that with the INTERNIC service contracts now in place t will get easier to establish a smooth data flow - and make it known to the registries. Probably some folks will be discussing some of this somewhere in Ohio in a weeks time... (unapproved, closed mini-BOF in the 1:00 to 3:30 AM time after the social event? :-) CU, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386
rv@deins.informatik.uni-dortmund.de writes: * The initial announcement for <assign@ripe.net> probably was not perfectly cl * ear * to restrict the use of this address to 193.x.y AND I remember that for som * e * other reassignments (well, not my own) sent directly to DDN-NIC it was reque * sted * to channel all European reassignments via the NCC. * * Thus I have been using assign@RIPE.net for updates which I intended to * "write-through" to DDN-NIC (all messages including records for "old" * blocks included a remark telling so). * * If we would know a little more about the state of how data base alignment * between DDN-NIC and RIPE-NCC actually works or what the intended ways are, * it might become easier for local registries to avoid misinterpretation * of procedures. Sure, I know, that unfortunately progress on the data base * alignement/exchange issue has been lagging far behind behind our hopes * and needs for improvement, and I sure can appreciate some of the problems * standing in the way (including the courtesy not explain all the problems * in public). OK, here;s a small update. The database alignment is in a stage where the exchange format is finished, and first tests with incorporating each others information in exchange format has begun. This week we will start using the exchange format database that MERIT generates in the RIPE database, to replace the current information with source MERIT. The NIC has had a big file with all 193 nets and contact people a few weeks ago from the NCC to test the interaction tools they have written for their databases. We have not yet had any results from those tests. The procedure for aligning databases has not yet been established. We are not quite sure whether to do this incremental or just a full update. My guess is that this will be discussed at the SWIP BOF at the IETF next week. If people have problems that result from the fact that the different databases are not aligned we would like to hear from them, so we can take action. * Well, we hope that with the INTERNIC service contracts now in place Not yet. They start 1st of April. * t will get easier to establish a smooth data flow - and make it known to the * registries. Probably some folks will be discussing some of this somewhere * in Ohio in a weeks time... (unapproved, closed mini-BOF in the 1:00 to 3:3 * 0 AM * time after the social event? :-) Fine with me ;-) -Marten
The procedure for aligning databases has not yet been established. We are not quite sure whether to do this incremental or just a full update. My guess is that this will be discussed at the SWIP BOF at the IETF next week. If people have problems that result from the fact that the different databases are not aligned we would like to hear from them, so we can take action. The one thing I would like to be able is to send a list of NIC handles, or person names, or network numbers and trigger DDN-NIC (or INTERNIC) to align to the current RIPE records (including reverse mapping servers if
* Well, we hope that with the INTERNIC service contracts now in place
Not yet. They start 1st of April. I think a major problem was uncertainty of potentially involved parties during the time that it was known that NSF would issue an RFP and the time
Marten, thanks for the status report. present in the records). If the lists specified at our end are carefully definied this would limit the danger of overwriting large parts of the target data base unexpectedly (which easily can happen with complete alignment - in presence of any number of typos in all data bases). So I think we could improve much by just starting to have some way of incremental update. the contracts were awarded... Sure not everybody is yet up to speed... Cheers, Ruediger Ruediger Volk Universitaet Dortmund, Informatik IRB DE-NIC Postfach 500 500 D-W-4600 Dortmund 50 Germany E-Mail: rv@Informatik.Uni-Dortmund.DE Phone: +49 231 755 4760 Fax: +49 231 755 2386
participants (2)
-
Marten Terpstra -
rv＠deins.informatik.uni-dortmund.de