North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: IRR listing of IANA-reserved, a question..
We need to be careful, at the RIR level, that data being published doesn't get mucked up. If a RIR publishes a netblock as "unallocated" and that happens to knock people off the net, then the RIR's need to be willing to solve that problem 7x24x365. Having the IANA, or other entity publishing a list of blocks that have not been allocated to any RIR is much less of a risk, and much less likely to cause operational outage issues. At the RIR level, it would be far more useful to have accurate data on who the registrant / user of the space it. I know the RIR's are working very hard at getting the legacy data in better condition. john brown as a person, and nothing else On Wed, Sep 04, 2002 at 12:46:13PM +0200, Daniel Karrenberg wrote: > > Speaking for myself too: > > I have been wanting an *authoritative* *single* listing of unallocated address space > for at least 6 years. Note that this is at a finer granularity than the IANA > allocations list and it would have much more frequent changes than the IANA list > as address space is allocated to local registries. > > However it could include a more coarse data set that changes less frequently for those > that do not want or need the higher granularity. > > The only way to make this happen is for the RIRs to collect this data among themselves > and publish it regularly. Because of the possible ramifications of errors in this list > it is not as simple to do that reliably as it may seem at first glance; but it should > be done. > > I know that the RIRs have efforts underway to publish such authoritative lists. > I do not know the exact status of this work. But I fully agree with your requirement > for a *single* *authoritative* list. > > Of course I would use it in the routers I operate. However these are not significant > to many peoiple these days. > > Daniel > > PS: I do not care at all about the format as long as it is readily machine parseable. > > Daniel >