Hi Ronald, APNIC implemented the organization object in June 2017. All organizations that joined APNIC after this date had their organization objects automatically created and associated with their resources. We reached out to our members who joined prior to this date and helped them make this update after confirming the contact details for their organization object.
All resources delegated to APNIC Members now have an organization object, except delegations made to NIR members and historical resources that are not managed under an APNIC account. We have work scheduled next year with the NIRs, however as per our policy, we can't update historical information in the APNIC Whois until the resource holder demonstrates the organization's right to the resources and enters a formal agreement with APNIC Information about resource holders are also published in the description attribute of parent inetnum objects. By default the country attribute here represents the economy where the resource holder is legally registered, however in some cases the country value has been changed to reflect the location of their network. The country value published in our delegated stats file is a more reliable source to determine the economy where the resource holder is located. http://ftp.apnic.net/stats/apnic/delegated-apnic-extended-latest Thanks Vivek On 19/11/20, 4:29 pm, "Ronald F. Guilmette" <[email protected]> wrote: In message <[email protected]>, you wrote: >The duplicate domain objects have been removed and we will add checks >to avoid this from happening again. Thank you Vivek. On a related topic... I have been doing a lot of work lately to try to bullt a (simple?) software tool that can take any IPv4 address that has been allocated to a real person/entity by any one of the five Regional Internet Registries and which will, using WHOIS data from the five RIRs, map that IPv4 address into a data item pair consisting of (a) the corresponding organization name for whatever organization has been given the largest (least specific) containing allocation directly by one of the five RIRs, and (b) the two-letter ISO 3166 country code of that organization. Such a tool has applications for mapping and reporting, on a global scale, of network events, including but not limited to network abuse. One hard part of building such a tool is to figure out which of the WHOIS servers for which one of the five Regional Internet Registries the necessary WHOIS query/queries should be directed to. But fortunately, I have already largely solved that part of the problem. Other than that, most of five RIR WHOIS servers are very cooperative and allow me to easily get the name and country code for the "top level" allocation holder corresponding to any single IPv4 address. In particular, the WHOIS servers of ARIN, LACNIC, and AFRINIC give me what I want with no fuss or bother. In the case of the RIPE WHOIS server, it -mostly- provides the answers that I need, but there is a set of about 122 "top level" legacy IPv4 allocations within the RIPE data base that simply have no org: field within their inetnum: records, and these are problematic. (I will be taking this matter up at length with the RIPE engineers & community, even those it is only very rarely a problem for the software tool I have been building.) The most thorny problem that I have had so far in constructing what should have been a "simple" tool to do this one simple job is that there are -numerous- "top level" direct IPv4 block allocations that have been issued by APNIC where the inetnum: record for that allocation fails to contain an org: field. This problem is quite widespread within the APNIC WHOIS data base and given that it substantially impairs automated processing of the inetnum: records within the APNIC WHOIS data base, I would like to inquire if there is a snowball's chance in hell of ever seeing this problem fixed. In an ideal world, *all* of the inetnum: records (or equivalent) that represent "top level" direct allocations issued directly by any one of the five RIRs should include a org: field. I mean why wouldn't they? It isn't as if any of the RIRs do not know who they have issued IPV4 space to (or who their legacy block holders are)! In many cases involving APNIC inetnum: records, there is no org: field but there is instead an irt: field that can sometimes (but not always) be used as a substitute to obtain the name and country of the registrant of the correspsonding IPv4 allocation. Even in these cases however, either the organization name and/or its country code is missing from the relevant irt: record. And anyway, on the face of it it is rather nonsensical to have an IPv4 allocation where the APNIC data base provides information about the IRT (Incident Response Team) that may handle "incidents" for the given IPv4 block, but where there is -zero- clear indication of who the block is actually assigned to. I can provide many many specific examples of these kinds of problems in the APNIC WHOIS data base and will be only too happy to do so upon request. (I have been having to put numerous hacks/kludges into my code as work-arounds for each of these individual cases as I come upon them.) Meanwhile however, I would like to pose the simple question: Could the APNIC WHOIS data base (please) be brought into conformity with the WHOIS data bases of the other four regions, specifically by adding org: fields at least to just those inetnum: records that represent "top level" allocations issued directly by APNIC or some other RIR? I wish to stress again that it at least -seems- rather entirely nonsensical, to me anyway, that APNIC has assigned great big swaths of IPv4 address space to various organizations within the APNIC region and yet in many cases it is either not simple, or actually impossible to figure out from APNIC WHOIS records, who or what actually "owns" those IPv4 blocks. And this problem is a serious impediment to any kind of global analysis, e.g. of the distribution of security and/or network abuse incidents, or whatever. Regards, rfg _______________________________________________ apnic-talk mailing list [email protected] https://mailman.apnic.net/mailman/listinfo/apnic-talk
