2 December 2025 NRO Resource Changes nro-resource-changes Abstract Each RIR publishes an extended delegation statistics file once per day, which contains details on the disposition of the resources for which that RIR is responsible. However, the file simply describes the state of a resource, rather than the way in which the resource reached that state. Some RIR community members have noted that access to the actual operations that caused the state change would be useful for research and related purposes. This document defines a format for recording and publishing those state changes. Table of Contents 1. Introduction 1.1. Conventions Used in This Document 2. Resource Changes File Format 2.1. Preliminary 2.2. Metadata Record 2.3. Changes 2.3.1. Common Members 2.3.2. Change Types 2.3.2.1. received-from-iana 2.3.2.2. returned-to-iana 2.3.2.3. delegated 2.3.2.4. terminated 2.3.2.5. freed 2.3.2.6. redelegated 2.3.2.7. transferred 2.3.2.8. transferred-from-rir 2.3.2.9. transferred-to-rir 2.3.2.10. reserved 2.3.2.11. claimed 2.3.2.12. cc-changed 2.3.2.13. status-changed 2.3.3. Reversals 2.3.3.1. received-from-iana 2.3.3.2. returned-to-iana 2.3.3.3. delegated 2.3.3.4. terminated 2.3.3.5. freed 2.3.3.6. redelegated 2.3.3.7. transferred 2.3.3.8. transferred-from-rir 2.3.3.9. transferred-to-rir 2.3.3.10. reserved 2.3.3.11. claimed 2.3.3.12. cc-changed 2.3.3.13. status-changed 2.4. Overrides 3. Resource Changes File Publication 4. Operational Considerations 5. References 5.1. Normative References 5.2. Informative References Author's Address 1. Introduction Each RIR publishes an extended delegation statistics (EDS) file once per day, which contains details on the disposition of the resources for which that RIR is responsible. However, the file simply describes the state of a resource, rather than the way in which the resource reached that state. For example, resource delegation is indistinguishable from resource redelegation, and also from a successful claim for historical resources. Similarly, a transfer to another RIR is indistinguishable from a return of resources to IANA. Some RIR community members have noted that access to the actual operations that caused the state change would be useful for research and related purposes. Publication of these operations will also help to improve registry transparency. To address these concerns, this document defines a format for recording and publishing those state changes. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Indentation and whitespace in examples are provided only to illustrate element relationships, and are not a REQUIRED feature of this protocol. "..." in examples is used as shorthand for elements defined outside of this document. 2. Resource Changes File Format 2.1. Preliminary The Resource Changes file is in JSON Text Sequence [RFC7464] format. The first record in the file contains metadata, while the remaining records represent changes to the resource disposition at the registry during the period between the generation of the specified beginning and ending delegation statistics files. The changes are ordered in the file per their original application to the registry state at the RIR. This order may not be the same as that per the timestamps of the changes. Each change type describes the effects it has on the EDS file. By applying all of the changes to the 'stats-begin' file, a client can compare the resulting state with the 'stats-end' file as a check over the validity of the Resource Changes file. 2.2. Metadata Record The metadata record contains the following members: 'version': The version of the specification for the Resource Changes file. 'timestamp': The time at which the Resource Changes file was generated. 'count': The number of individual change records in the Resource Changes file. 'stats-begin': A link to the EDS file that contains the state immediately prior to the first change in the Resource Changes file. 'stats-end': A link to the EDS file that contains the state immediately after the last change in the Resource Changes file. The version of this specification is "0.1". Increments to the first number are major version updates, and may be backwards-incompatible with previous versions. Increments to the second number are minor version updates, and are guaranteed to be backwards-compatible with previous versions. For all record types, clients MUST ignore members that are not documented in this specification. The 'stats-begin' and 'stats-end' links may point to plain-text files (no extension), or files compressed using gzip ('.gz' extension) or bzip2 ('.bz2' extension). 2.3. Changes 2.3.1. Common Members 'type': The type of the change. See Section 2.3.2. 'timestamp': The time at which the change took place (YYYY-MM-DD HH:MM:SS). Offset at UTC. 'resources': The Internet Number Resources (INRs) relevant to the change. 2.3.2. Change Types 2.3.2.1. received-from-iana Represents the receipt of resources from IANA. This change does not contain any additional members. The resources contained within this change should not appear within the EDS file as at the time of application of this change. When this change is applied, the resources should be marked as "available" in the EDS file. 2.3.2.2. returned-to-iana Represents the return of resources to IANA. This change does not contain any additional members. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resources should be removed from the EDS file. 2.3.2.3. delegated Represents a delegation of resources from the RIR to a custodian. Additional members: 'custodian': A unique identifier for the recipient of the delegation. 'status': A description for the type of delegation. Either 'allocated' or 'assigned'. 'cc': The country code of the custodian to which the delegation is made. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resources should be marked per the "custodian", "status", "cc", and "timestamp" members. 2.3.2.4. terminated Represents the revocation of a custodian's entitlement to use the resources by way of their return to the registry. This can happen for various reasons: e.g., the custodian may voluntarily reliniquish their entitlement, or the registry may revoke the entitlement due to delinquency. Additional members: 'custodian': A unique identifier for the custodian of the delegation. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned", and the custodian referenced in the change. When this change is applied, the resources should be marked with a status of "reserved", and the date of delegation and custodian members should be cleared. Generally, resources that are terminated will be marked as "reserved" for a period of time, during which they may be redelegated to the original custodian (e.g. once outstanding invoices have been paid). While in this state, these resources will not be used for new resource delegations. 2.3.2.5. freed Represents the return of reserved resources to the registry's pool of available resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "reserved". Note that resources can reach the "reserved" state by way of both the "terminated" change and the "reserved" change. When this change is applied, the resources should be marked with a status of "available". 2.3.2.6. redelegated Represents the return of terminated resources to the custodian who previously held those resources. Additional members: 'custodian': A unique identifier for the custodian of the delegation. 'status': A description for the type of delegation. Either 'allocated' or 'assigned'. 'cc': The country code of the custodian to which the delegation is made. 'original_delegation_date': The original date on which the resources were delegated. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "reserved". A client with knowledge of the previous "terminated" change for this resource may also verify that the custodian for that "terminated" change is the same as the custodian for this "redelegated" change. When this change is applied, the resources should be marked per the "custodian", "status", "cc", and "original_delegation_date" members. Note that "status" and "cc" can change on redelegation. 2.3.2.7. transferred Represents the transfer of delegated resources from one custodian to another. Additional members: 'source': The custodian who holds the resources prior to the transfer. 'recipient': The custodian who holds the resources after the transfer. 'transfer_type': A type from the NRO Transfer Log. For resource transfers that do not fit within one of those types, the type 'OTHER' should be used. 'status': An optional status for the resources post-transfer. 'cc': An optional country code for the resources post-transfer. 'update_date': Whether to update the record's date to match the transfer's timestamp. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned", and with the transfer "source" as the custodian. When this change is applied, the resources should be marked per the "recipient", "status", and "cc" members. If "update_date" is set to true, then the date for the resources should be updated to match the date from the transfer's timestamp. 2.3.2.8. transferred-from-rir Represents the transfer of resources from another RIR to a custodian of this RIR. Additional members: 'source_rir': The RIR from which the resources are being transferred. One of 'AFRINIC', 'APNIC', 'ARIN', 'LACNIC', or 'RIPE'. 'recipient': The custodian who holds the resources after the transfer. 'original_delegation_date': The original date of delegation for the resources. 'status': The status for the resources post-transfer. 'cc': The country code for the resources post-transfer. 'update_date': Whether to update the record's date to match the transfer's timestamp. The resources contained within this change should not appear within the EDS file as at the time of application of this change. When this change is applied, the resources should be marked per the "recipient", "status", "cc", and "original_delegation_date" members. If "update_date" is set to true, then the date for the resources should be updated to match the date from the transfer's timestamp. 2.3.2.9. transferred-to-rir Represents the transfer of resources from a custodian of the current RIR to another RIR. Additional members: 'recipient_rir': The RIR to which the resources are being transferred. One of 'AFRINIC', 'APNIC', 'ARIN', 'LACNIC', or 'RIPE'. 'source': The custodian who holds the resources prior to the transfer. The resources contained within this change should appear within the EDS file as at the time of application of this change, with the transfer "source" as the custodian. When this change is applied, the resources should be removed from the EDS file. 2.3.2.10. reserved Represents the reservation of the specified resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resources should have their "status" value changed to "reserved". 2.3.2.11. claimed Represents a claim over historical/legacy resources. Additional members: 'custodian': A unique identifier for the custodian of the claimed resources. 'status': The status for the resources. Either "allocated" or "assigned". 'cc': The country code for the resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "reserved" or "available". When this change is applied, the resources should have their "custodian", "cc", and "status" values updated per the change. 2.3.2.12. cc-changed Represents a change of country code for the specified delegated resources. Additional members: 'cc': The new country code for the resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should have their "cc" value updated per the change. Each RIR in their EDS files omits country codes for resources with the status "reserved" or "available". For those resources, this change has no effect. 2.3.2.13. status-changed Represents a change of status for the specified delegated resources. Additional members: 'status': The new status for the resources. Either "allocated" or "assigned". The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should have their "status" value updated per the change. 2.3.3. Reversals An RIR may need to reverse a previous change. To do this, the RIR uses one of the following reversal change types. These have the same "type" member as one of the previously-defined change types, but include an additional "reversal" member with a true value, and have different sets of members (though in some cases the set of members coincides with that of the original change type). In some instances, a client may be able to further verify the reversal past the behaviour described for each of the change types in the following sections. For example, with the reversal of a termination, if the client has a contiguous history of the changes from the time of the last termination of the resources up until the reversal, and the last termination is for a custodian different from that listed in the change, the client may warn the user about that inconsistency. A reversal is in the nature of a rescission, in that after receiving the reversal, the original change is treated as though it never happened. A delegation followed by a termination indicates that the delegation actually happened, in the sense that it was an intentional action on the part of somebody with the appropriate authorisation, and the delegation was subsequently revoked. A delegation followed by a reversal is meant to cover the case where the delegation was due to operator mistake or similar. 2.3.3.1. received-from-iana The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resources should be removed from the EDS file. 2.3.3.2. returned-to-iana The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resources should be removed from the EDS file. 2.3.3.3. delegated Additional members: 'custodian': A unique identifier for the current holder of the resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned", and the custodian referenced in the change. When this change is applied, the resources should be marked with a status of "available", and the date of delegation, country code, and custodian members should be cleared. 2.3.3.4. terminated Additional members: 'custodian': A unique identifier for the holder of the resources. 'status': A description for the type of delegation. Either 'allocated' or 'assigned'. 'cc': The country code of the custodian to which the delegation is made. 'original_delegation_date': The original date on which the resources were delegated. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "reserved". When this change is applied, the resources should be marked per the "custodian", "status", "cc", and "original_delegation_date" members. 2.3.3.5. freed The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "available". When this change is applied, the resource status should be changed to "reserved". 2.3.3.6. redelegated The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resource status should be changed to "reserved". 2.3.3.7. transferred Additional members: 'source': The custodian who held the resources prior to the transfer. 'recipient': The custodian who holds the resources after the transfer. 'status': An optional status for the resources after the reversion of the transfer. 'cc': An optional country code for the resources after the reversion of the transfer. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned", and held by the original transfer recipient. When this change is applied, the resources should be marked per the "custodian", "status", and "cc" members. Note that the date of the resource should not be affected by the transfer, since it is the original delegation date of the resources. 2.3.3.8. transferred-from-rir The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should be removed from the EDS file. 2.3.3.9. transferred-to-rir Additional members: 'source': The custodian who held the resources prior to the transfer. 'status': The status of the resources after the reversion of the transfer. 'cc': The country code of the resources after the reversion of the transfer. 'original_delegation_date': The original delegation date of the resources. The resources contained within this change should not be present within the EDS file as at the time of application of this change. When this change is applied, the resources should be marked per the "custodian", "status", "cc", and "original_delegation_date" members. 2.3.3.10. reserved The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "reserved". When this change is applied, the resources should be changed to have a status of "available". 2.3.3.11. claimed Additional members: 'status': The status prior to the claim. Either "available" or "reserved". The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should be changed per the "status" member, with all other members being cleared. 2.3.3.12. cc-changed Additional members: 'cc': The new country code for the resources. The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should have their "cc" value updated per the change. 2.3.3.13. status-changed Additional members: 'status': The new status for the resources. Either "allocated" or "assigned". The resources contained within this change should appear within the EDS file as at the time of application of this change, with a status of "allocated" or "assigned". When this change is applied, the resources should have their "status" value updated per the change. 2.4. Overrides An RIR may need to override the state of a resource for various reasons. For example, a resource may be present in the EDS file, but delegated to the wrong custodian, and the only thing known about the resource is that it was delegated to some other custodian at some specific point in time. Rather than attempting to reconstruct a correct history by way of purported reversal changes, the RIR can simply add a new "delegated" change that represents the "correct" state. To distinguish regular changes from override changes, the RIR adds an "override" member with a true value, and an "override_timestamp" member indicating the time at which the override takes effect. A client processes such a change in the same way as for a non-override change, save that there is no need to verify the pre-change state. Any non-reversal change can be marked as an override change. 3. Resource Changes File Publication On publishing an EDS file, the RIR should also publish a Resource Change file covering the period between the generation time of the previous EDS file and the generation time of the new EDS file. This file should be published on the same server where the EDS file is published, at the path "/pub/ stats/{rir}/changes/{year}/changes_{timestamp}.json", where "{rir}" is the name of the RIR, "{year}" is the year in which the EDS file was generated, and "{timestamp}" is the time at which the EDS file was generated ("YYYYMMDDTHHMMSSZ", offset at UTC). One or more signatures over that file should also be published, having a filename which comprises the filename of the Resource Change file with the relevant signature extension appended to it. When a new Resource Change file is published, it should also be made available at the path "/pub/stats/{rir}/changes/changes_latest.json". Similar paths should be added for each signature. The Resource Change file should be retrievable by way of the same mechanisms as the EDS files. This set of mechanisms MUST include HTTPS. 4. Operational Considerations There are many ways to get an EDS file into a particular state. For example, the "freed" change and the reversal "reserved" change both cause a reserved resource to be marked as available. RIRs should take care to ensure that the published changes represent actual registry operations, rather than simply employing changes in order to secure outcomes in the EDS file. As a last resort, overrides can be used to this end, since they at least indicate that the registry is unsure of the exact history of the resource. Certain changes may lead to the splitting of resources within the EDS file. Clients should be prepared to handle this splitting by preserving the unreferenced resources with their previous values in the EDS file. While it is not intended that Resource Change files will be modified after publication, this specification does not require that they not be modified in this way. However, RIRs SHOULD take steps to minimise the chance of this happening. It is possible for a single Resource Change file to contain a set of changes, where applying those changes has no effect on the resulting state. The simplest example of this is a delegation followed by a reversal of that delegation. RIRs SHOULD include such sets of changes in their Resource Change files, since those changes may be useful for clients notwithstanding that the resulting state is unaffected. A scenario where an RIR would omit such sets of changes is where they are due to bugs or similar problems, and the number of records is extremely large. Custodian codes are only guaranteed to be valid within the scope of a single EDS file. The custodian codes used for a Resource Change file are those from the 'stats-end' file listed in the metadata record. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7464] Williams, N., "JavaScript Object Notation (JSON) Text Sequences", RFC 7464, DOI 10.17487/RFC7464, February 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, .