On 25 Jul 2021, at 17:54, Sylvain Baya wrote:
Maybe i failed to state it clearly...i add my support
for a request from the DBWG to the AfriNIC's Staff,
so that they could handle a formal cleanup request
directed to RADb in order to remove all IRR's
objects (including route: and route6:) incorrectly
created in their Database; whereas those objects
are attached to AfriNIC's delegated INRs pools.
i feel obliged to point out that this won’t actually return the result
that you think it will.
the afrinic team has *no* way of creating a verifiable index of what is
correct; at least not from their members’ perspectives. they also
have no way of knowing what is intended to be correct (ie. what the
member is planning for tomorrow/next week/month/..). that’s simply
isn’t how routing registries works. and i’ll pre-empt the
inevitable: “all afrinic space should be in the afrinic IRR”
because if anyone is thinking that, then you’re just plain wrong.
the afrinic team can request that eg. the RADB remove entries for bogon
space (ie. unallocated space) that is tied to afrinic’s
IANA-allocated space. that’s easy to justify; the space hasn’t
been allocated. period. but once space is allocated, the afrinic team
can *not* with any degree of certainty, predict what the origin-as is,
or will that will be in the future. and i don’t want them to try!
one of the longer term working items that we are led to believe is
coming in myafrinic v2.x is a dashboard for members to see what IRR
objects tie to their allocated space. i’m actually fine with waiting
for the afrinic team to deliver that to members, since, a member will
(should?) know what the intended origin-as is (and is intended to be),
and can choose to act as appropriate, or not. and i know i (at least)
have suggested ways to the afrinic team on how they can incentivise
members to keep this sort of information accurate (ie. dashboard =
green).
...yes, it's more than what you asked...that's how
things work...then the DBWG has to agree or not :-)
*my* interest - and, the way that i read the OP’s request was a
simple: “please publish the authoritative set of all your address
space.” i think that’s easy enough to do, and won’t cost the
afrinic team too much in development cycles. i think i counted
frank’s personal +1 to that request. still, i would hardly call that
consensus, but let’s hope that the afrinic team see that this is an
entirely common-sense request, and needn’t wait for the entire working
group to vote on this. :-)
but i don’t see a call to have afrinic act as the police for the RADB.
that’s both outside the mandate of *this* working group, and,
frankly, an investment of afrinic’s time that doesn’t offer a high
ROI.
i’m all for getting the afrinic team to deliver on services that add
value to their membership; what you’re asking for, however, is not
one of those. instead, i read the outcome of this thread as:
#1 - publish the set of afrinic’s address space
#2 - run periodic consistency checks against afrinic’s space, to
identify if there are any objects that reference bogons (because, if you
don’t, then RFG is just going to do it anyway! :-))
#3 - remove bogons from your IRR, and institute a periodic process to
request others clean their’s
hth,
-n.
_______________________________________________
DBWG mailing list
[email protected]
https://lists.afrinic.net/mailman/listinfo/dbwg
