This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
Migration issues: route creation
- Previous message (by thread): Migration issues: route creation
- Next message (by thread): Planned maintenance
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Andrei Robachevsky
andrei at ripe.net
Thu Feb 15 17:24:33 CET 2001
"Lu, Ping" wrote: > > Comment followed. > > > > > You can configure the software to resolve these references internally > > (by creating "dummy" objects). However, you cannot request "selective > > mirroring" for a particular types of objects. > > > > What happen if you don't want to share some of the person objects ? > At least, I believe APNIC has a policy to guard private information so they > may not want > to mirror the maintainer and person objects. I think one can filter out these objects from the mirroring stream while maintaining the correct sequence of serials. > > > Referential integrity needs to be satisfied only within a > > single source. > > That is TEST1-MNT with RADB source and TEST1-MNT with the RIPE one are > > in fact different objects. > > > > How about AS3561 in RIPE, ARIN and APNIC ? In reality this is the same AS > ( assigned by ARIN but need to be present in RIPE and APNIC as well ) > And this will be a route creation problem, we will need to register some > route > objects in RIPE that originates from AS3561 very soon. > In current version of the database you also need to register the aut-num referenced by the origin attribute of a route object in order to register the object. Which leads to duplication of data for those ISPs that have address space and aut-num registered in different registries. Not perfect, I agree. But the problem with route creation in the new version of the database is that if we maintain the same level of security for the whole database (which means protecting the whole ASN space with as-block objects and IP space with corresponding inetnum objects) it will be _impossible_ to register respective aut-num or inetnum object in a normal way to authorize route creation (RFC2725). Another option could be that in order to allow "foreign" registrations we will maintain different levels of security (no as-block for ARIN ASNs, for example). Only routes from the RIPE address space and RIPE ASN will be properly authenticated and authorised. > Ping Lu > Cable & Wireless USA > Network Tools and Analysis Group > W: +1-703-292-2359 > E: plu at cw.net Regards, Andrei Robachevsky DB Group Manager RIPE NCC
- Previous message (by thread): Migration issues: route creation
- Next message (by thread): Planned maintenance
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]