Summary of the Migration issues

Dear Colleagues,

[Apologies for duplicate messages. We suspect that this message was not
delivered to <reimp-mig-tf at ripe.net> yesterday, 19 March]


Please let me summarize the migration issues that have been discussed
already and highlight some issues that require more attention.

Best regards,

Andrei Robachevsky
DB Group Manager
RIPE NCC


----------------------------------------
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.
 

2. Updates in RIPE-181 format

Migration plan allows users to send updates in RIPE-181 format for some
time (until May 14th  to <auto-dbm at ripe.net>, from May 14th till October
15th to <auto-181 at ripe.net>) after the migration. In such case objects
are automatically converted to RPSL. However the switchover to the new
version of the RIPE Database occurs on 23 of April, and since then the
following constraints will apply:

2.1 PGP authentication 

PGP authorization scheme will not work with <auto-dbm at ripe.net> robot
after 23 April. Updates requiring PGP auth should be sent directly to
<auto-rpsl at ripe.net>.

The problem occurs because after ripe181->RPSL transformation it is
impossible to verify signature.

For this reason, some updates requiring PGP auth may be rejected during
migration. It advisable not to send such updates from 22 April, 9a.m.
till 23 April 9a.m.

2.2 New syntax rules

When processing an object after ripe181->RPSL conversion new v3.0 syntax
rules apply. The results of this will be:

- empty attributes (i.e. having no value) are not allowed;
- some attributes that were optional before are now mandatory;

Also some undocumented behaviour of the v2.x Database will not be
supported, namely:
- attribute aliases (please see list of aliases attached) are not
allowed;
- inetnum object cannot be specified in prefix notation.

2.3 New authorization rules

New authorization rules defined by RFC2725 apply to creation of aut-num
and route objects. See 1.


3. Objects with names containing reserved RPSL prefixes

They will be renamed on 2 of April. All references will be updated
accordingly.
Currently there are 6 of them in the RIPE Database.

mntner: AS-5532MNTB
mntner: AS-NETLINK-MNT
mntner: AS-THENET-MNT
mntner: AS-NEW1-MNT
mntner: RS-MNT
mntner: AS-MNT

4. Broken PGP certificates.

They will be deleted on 2 of April.


----------------------
v2.x attribute aliases (not supported in v3.0!):

Alias        Attrbute

change    -> changed
email     -> e-mail
fax       -> fax-no
remark    -> remarks
deleted   -> delete
asname    -> as-name
rev-svr   -> rev-srv
network   -> inetnum
netnum    -> inetnum