[DBWG] All AFRINIC-administered IP space

[Ronald F. Guilmette]

In message <54D06B77-EAEA-4597-91C6-1E033D2046B6 at controlfreak.co.za>, 
"Nishal Goburdhan" <nishal at controlfreak.co.za> wrote:


>> Are some members clairvoiant?  Can they magically predict which specific

>> IP address blocks some RIR will assign to them NEXT MONTH?

>

>no.  but members might know if they are changing origin-as next month.

>afrinic won't.  and can not be expected, to know.


I think that we are talking past one another.  Let me try again to explain
what I was actually proposing.

The idea was (and is) simple enough, I think.  Step one would be to generate
three lists as follows:

    (*)  A list of all those route objects currently present within the
         RADB data base that refer to IPv4 address space which is both
         (a) currently assigned by IANA to AFRINIC and also (b) currently
         *not* assigned by AFRINIC to any resource member.

    (*)  A list of all those route6 objects currently present within the
         RADB data base that refer to IPv6 address space which is both
         (a) currently assigned by IANA to AFRINIC and also (b) currently
         *not* assigned by AFRINIC to any resource member.

    (*)  A list of all those route/route6 objects currently present within
         the RADB data base that refer to AS numbers that are both
         (a) currently assigned by IANA to AFRINIC and also (b) currently
         *not* assigned by AFRINIC to any resource member.

(I should soon have the necessary software tools in place to generate all
three of the above lists, afresh, and on a daily basis, if need be.  It
is also my intention to share those software tools publicly and with
everyone.  They are not big, they are not complicated, and anyone with
even a little skill should be able to use them.)

Step two would be to send all three lists (of RADB bogon route objects) to
AFRINIC and to ask them to ask the RADB folks to delete all of the
corresponding (bogon) route objects from their {RADB} data base.

Step three would be to wait and hope that AFRINIC would actually do that,
and that RADB would in fact delete the (bogon) route objects.

There is nothing here that would prevent or inhibit any party from creating
or maintaining, in the RADB data base, any route object that makes reference
to *any* AS number that *is* in fact allocated and assigned TO ANY PARTY
at the present time.  So, using your hypothetical, if someone is maintaining
a route object `R' in the RADB data base, and that route object currently
specifies an origin ASN of `X' and if the maintainer of that object changes
it so that henceforth refers to ASN `Y', then there is no problem as long
as ASN `Y' is in fact already allocated, at present, by the relevant RIR to
*somebody* (i.e. anybody).

In short, what you seem to believe may be a problem does not in fact appear
to be a problem... unless of course resource holders *are* actually
clarivoiant, and if they can reliably predict ahead of time what new AS
numbers will be assigned to them, by some RIR, next week or next month,
and if they begin using those yet-to-be-assigned AS numbers in their
RADB route objects.


>the post that i responded to, suggested that afrinic contact the RADB to 

>deal with "remove all IRR's objects [..] incorrectly created [..] 

>attached to AfriNIC's delegated INRs pools".

>my reply was intended to convey that AFRINIC themselves are not clairvoyant


They don't need to be.  Anyone who has created a route object in *any* IRR
(either the ones that are run by the five RIR or the one that is run by
Merit, Inc. and that is called RADB) should NOT be making reference within
any such route object to any Internet Number Resource which has not (yet)
been assigned by any RIR to any resource member.  It's just that simple.


>> .. I would hereby like to WITHDRAW my request to AFRINIC staff

>> that they provide this information, either as a "one off" on on a 

>> continuing basis.

>

>that's a pity.  like you, i agree that it's not difficult to extrapolate such a list.


I like you too Nishal, and yes, it is, in relative terms, rather easy to
generate, programatically, a list of all AFRINIC-administered IPv4 address
space starting from just the AFRINIC daily stats file.


>but an individual's ability to extrapolate this evidence, is not the 

>same as the curator of this space displaying {the list of AFRINIC-

>administered IPv4 CIDRs}.


I both agree and disagree.  Yes, in an ideal universe where manpower and
labor are infinite, it would be best if AFRINIC would post simple and easy
to understand lists of all of the number resources that are under their
administration on any given day.  In practice however, I just want to be
respectful of the AFRINIC staff and their time, and (thus) I don't want
to ask them to do things that I can do for myself.  (This tradition of
"self reliance" was taught to me at an early point in my career in software
and it has always served me well.)

Shortly, I will post here links to some rather simple Perl scripts that
anyone can use to derive the kinds of lists (of IANA delegated number
resources) starting from the daily "stats" file that AFRINIC is already
maintaining and publishing on a daily basis.  If you or anyone else wants
to take the matter further and request staff to publish summary listings
of AFRINIC-administered number resources... well then by all means, please
be my guest.


>i, on the other hand, would *still* like to see afrinic publish this.


See above.  I have on objections.  I personally just always try to minimize
the amount of stuff that I ask other people to do for me.  This is especially
true when it comes to software development.  (My career was/is in software
development and I cannot tell you the number of times that I was given
colossal and complex assignments, only to be told... by others who were
-not- resonsible for doing the actual work... how "simple" and "easy" the
assigned tasks were.  So I try to never give some other software engineer
a task to do while telling him or her "Please do this.  It's easy!")


>i don't think it would cost them significant development time.


See above.

In my long career, I have learned that it is always possible to judge that
any given software development task is simple and easy as long as you are
not the one actually doing the work.


>i am patient.  by way of example, my ticket for requesting 2FA, only 

>took 7years.


Yet another argument in favor of being self-reliant, whenever one can be.


Regards,
rfg