HI Tim
Thanks for the review. I have added a few comments below.
cheers
denis
On 11/11/2015 10:41, Tim Bruijnzeels wrote:
Dear working groups,
At RIPE 70 the RIPE Database Working group asked the RIPE NCC to work
together with Afrinic on an implementation proposal to migrate
Afrinic route(6) objects to the new Afrinic IRR as part of the IRR
Homing project. We are planning to present a proposal at the Database
Working Group session at RIPE 71.
Initially we will focus on the clear cases where Afrinic is the RIR
for both the inet(6)num and aut-num (roughly 34k object). In the
meantime we are also seeking technical alignment with Afrinic and the
other RIRs on how cross-RIR authorisation for route(6) objects can be
improved, so that we can also put forward an implementation plan for
the remaining objects (e.g. roughly 6k objects with an Afrinic
inetnum and RIPE aut-num).
Experience with the migration of Afrinic route objects can serve as a
basis to similar migrations in the future. And while the RIPE NCC and
RIPE working groups cannot set the priorities for other RIRs, they
are following these developments with interest.
All that said it is clear that the current situation is problematic
and an intermediate solution may be desired. In general the RIPE NCC
also likes the proposal for this put forward by Denis. But we have
some comments, much in line with comments made by Job. We would
propose the following:
STEP 1: reject creation of route-objects if they cover foreign
non-allocated / non-assigned space
This should be doable. The past few years the RIRs have been working
hard on cleaning up overlaps, and therefore we can now be certain
which RIR is authoritative for which resources and check this
programatically.
Someone made a comment about legacy space. Is this now shown in the
extended delegated stats? Can we determine if it is legacy space and who
is authoritative for it? Or do we need a separate rule for legacy space
ROUTE objects?
STEP 2: email confirmation link to admin-c/tech-c equivalent as
listed in the foreign RIR database to confirm creation of the
route-object in RIPE's IRR database.
Indeed as Job pointed out we may have to make a special arrangement
with other RIRs, but we are confident that we can work with them on
this.
STEP 3: continiously check if the block is allocated in the foreign
RIR database, if no longer, delete the route-object from RIPE's IRR
db.
We share concerns raised by Job. We believe this adds a lot of
complexity to the implementation, and introduces an unacceptable risk
of deleting the wrong objects. Furthermore we believe that this step
is not necessary if we implement step 5 (below).
Agreed
STEP 4: one-off cleanup: confirm with all out-of-region objects
whether the object belongs in RIPE IRR db or not, if no
confirmation is received: delete the object.
We would also echo the concerns raised by Job. And similar concerns
with complexity and risk apply as with step 3. Furthermore we believe
that this step is not necessary if we implement step 5 (below).
Agreed with a caveat that as a one of action the authoritative contacts
should be notified that a ROUTE object exists in the RIPE Database
relating to their resource. If it was maliciously or accidentally
created the authoritative registrants may not be aware of it's existence.
(Possible) STEP 5: confirm with admin-c/tech-c equivalent as listed
in the foreign database when a 'delete' request is received.
If we implement this, step 3 and 4 are not needed. Rather than trying
to determine automatically if an object is still valid - and risking
getting it wrong, this leaves both the empowerment and responsibility
to maintain this data with the current resource holders.
We would propose that out-of-region resource holders can delete
route(6) objects in the RIPE Database in a two step process: 1) try
to delete the object without authorisation - We can detect that it's
an out-of-region object and send a link to the holder similar to step
2 2) the holder can click the confirmation link
Agreed
AUT-NUM copies: delete foreign autnum copies
From our perspective we agree that we do not technically need foreign
aut-num objects if we have a different authorisation model, and it
would be better if such duplicates did not exist.
As for the clean-up we could: = disallow new out-of-region aut-num
objects = warn (email) respective holders in the authoritative
database = and delete them as a later step
Agreed
So, with the caveat about automated deletion of objects that we do
have concerns with, we think we could implement the above as an
intermediate solution. We would also like to point out that we can
build on this step by step. E.g. we can start disallowing route
objects for Afrinic resources and direct people to the Afrinic IRR,
while still applying the above strategy for resources from other
regions.
From what I understood from Gert and Randy's comments it is a user's
choice where to put a ROUTE object and there seem to be some reasons why
they sometimes choose to put it in the RIPE Database. Is there some
specific policy now that prohibits ROUTE objects in the RIPE Database
for AFRINIC resources?
It will obviously require work. Very rough initial estimates indicate
it can take up to a few months. We can refine these estimates if and
when we have a clear consensus on a go-ahead.
Kind regards,
Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
Database Group
