RE: Summary of the Migration issues
Some questions followed. Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net [snip]
---------------------------------------- 1. Route object creation (RFC2725 implications)
In order to create route object in the RIPE DB, one needs to have corresponding objects (inetnum or less specific route, and aut-num) and pass proper authorization from these objects.
The problem occurs when someone needs to register route object which has either prefix, or origin, or the both from non RIPE IP/ASN space.
Proposed solution: 1.1 An as-block object(s) encompassing the non RIPE ASN space will be created with "mnt-lower:" protected by mntner with NONE auth.
1.2 An encompassing inetnum object with "mnt-routes:" protected by mntner with NONE auth will be created. This will eliminate need for corresponding inetnum creation and will reduce amount of redundant information.
1.3 In case origin of a route object being created is from non RIPE space, users will need to create corresponding aut-num object in the RIPE DB.
Does 1.3 means RIPE is going accept non-RIPE aut-num(AN) object thus a mntner(MT) object to protect that AN thus some person(PN) objects associated with that MT ? And is RIPE going to allow the NONE auth specified in 1.1 and 1.2 to be changed to a real MT once the rightful holder created them ?
2. Updates in RIPE-181 format
How about the ftp mirror ? Will RIPE-181 format text files still be available to download after April 23, 2001 or just the RPSL format text files ? [big cut for the rest]
"Lu, Ping" wrote:
Some questions followed.
Ping Lu Cable & Wireless Global Network Tools and Analysis Group, USA W: +1-703-292-2359 E: plu@cw.net
[snip]
---------------------------------------- 1. Route object creation (RFC2725 implications)
In order to create route object in the RIPE DB, one needs to have corresponding objects (inetnum or less specific route, and aut-num) and pass proper authorization from these objects.
The problem occurs when someone needs to register route object which has either prefix, or origin, or the both from non RIPE IP/ASN space.
Proposed solution: 1.1 An as-block object(s) encompassing the non RIPE ASN space will be created with "mnt-lower:" protected by mntner with NONE auth.
1.2 An encompassing inetnum object with "mnt-routes:" protected by mntner with NONE auth will be created. This will eliminate need for corresponding inetnum creation and will reduce amount of redundant information.
1.3 In case origin of a route object being created is from non RIPE space, users will need to create corresponding aut-num object in the RIPE DB.
Does 1.3 means RIPE is going accept non-RIPE aut-num(AN) object thus a mntner(MT) object to protect that AN thus some person(PN) objects associated with that MT ?
Yes. Current version of the Database requires aut-num object to be present in order to be referenced in 'origin:' attribute. So for routes with foreign origins people should have created aut-num, mntner, person, etc. No change in fact.
And is RIPE going to allow the NONE auth specified in 1.1 and 1.2 to be changed to a real MT once the rightful holder created them ?
If the rightful holder wishes to maintain the space. Though I think we may want to look for more scalable solutions.
2. Updates in RIPE-181 format
How about the ftp mirror ? Will RIPE-181 format text files still be available to download after April 23, 2001 or just the RPSL format text files ?
After April 23, 2001 only RPSL text files will be available. It is impossible to present all objects and attributes in RIPE-181 format.
[big cut for the rest]
Regards, Andrei Robachevsky DB Group Manager RIPE NCC
participants (2)
-
Andrei Robachevsky -
Lu, Ping