The RIPE Database Working Group requested the RIPE NCC to replace the “changed:” attribute in the RIPE Database with “created:” and “last-modified:”. Following discussions at RIPE 69, the RIPE NCC has met with the working group chairs and finalised an implementation plan consisting of three phases: 1) introduce the new attributes “created:” and “last-modified:”, 2) make the "changed:" attribute optional, 3) deprecate the "changed:" attribute. Please find the details in this article.
Replacing “changed:” Attribute in RIPE Database with “created:” and “last-modified:”
Last spring, a community member proposed replacing the attribute “changed:” with “created:” and “last-modified:”. This would better document changes to objects in the RIPE Database.
The issue with "changed:" is that although at least one "changed:" attribute is required there is no guarantee that a "changed:" attribute is added for every modification. It is not a reliable indicator of when the object was last modified, or what was modified.
The server will automatically apply these new “created:” and “last-modified:” attributes when a change is made to an object. The "last-modified:" attribute will accurately reflect when the object was last changed. Furthermore the "--list-versions" option can be used to list all versions of an object, and the "-show-version" option can be used to see the content of a specific version.
After the RIPE Database Working Group Co-Chairs declared consensus on the proposal, the RIPE NCC was asked to take action and we drafted an implementation plan that was discussed on the mailing list and at RIPE 69.
After further feedback, we met with the working group chairs and together we finalised the implementation plan based on the input from the working group.
The technical details are provided below so that RIPE Database users can assess the impact on their operations and have an opportunity to test these changes properly as soon as a new release is deployed to the Release Candidate (RC) environment for each phase.
Phase 1: Introduce New Attributes: “created:” and “last-modified:”
30 March 2015: Deploy to RC and update objects
2 April 2015: Enable " created:" and "last-modified:" in output
28 April 2015: Production (four weeks of RC)
4 May 2015:
Enable " created:" and "last-modified:" in output
In this phase, "last-modified:" and "created:" are added to each object in the output as server-generated attributes. Generating these attributes for all objects in the database takes a long time, and because we feel that it would be best to have consistent output for all objects these attributes are only enabled in the output after the updates have finished.
In order to optimise the response time in case enabling these attributes should lead to problems we have decided to do this step on the first Monday after the script has finished in production.
NRTM
All objects in the database will be updated in this phase, but we believe that the change is minor and actual sending of all these updates to clients will result in performance problems for many clients. Therefore these changes will not be included in the NRTM feed. However, if an object is changed at a later time, an update will of course be sent as usual, and it will then include these attributes.
NRTM clients who wish to have these attributes in all objects are advised to perform a full re-synchronisation after the attributes have been enabled in output.
Format
The date and time format follows the ISO 8601 [1] standard of date, hours, minutes and seconds in UTC, including the special UTC designator ‘Z’: YYYY-MM-DDTHH:MM:SSZ. The "last-modified" attribute should be presented above and close to the "source:" attribute, for example:
last-modified: 2014-04-15T13:15:30Z
“created:”
The "created:" attribute reflects when the object was created in the RIPE Database. But because a large number of objects were imported in bulk into a previous incarnation of the RIPE Database on 21 September 2001, the actual "created" time for these objects is very difficult or even impossible to find. Because ISO 8601 does not support an "undefined" notation, we agreed with the working group chairs that in this case the following date and time would be used:
created: 1970-01-01T00:00:00Z
The RIPE NCC has internal records for the registration date of some 14,000 inetnum objects that were imported on 21 September 2001. We agreed that the created date for these objects would be back-dated to the registration date.
“last-modified:”
The "last-modified:" attribute reflects when it was last changed. If an object has never been changed, the value of this attribute will be the same as the "created:" attribute. If an object was bulk imported on 21 September 2001 and never modified, the original import date and time will be used for this attribute. Finally, the RIPE NCC will make sure that this attribute is not modified in case of bulk changes that have no semantic meaning, for example when an attribute is deprecated and removed altogether.
Impact on users when updating the RIPE Database
The "changed:" attribute is not affected in this phase so we still require at least one “changed:” attribute when an object is updated, however, RIPE Database users should start migrating their tools to rely on "created:" and “last-modified:".
As the “created” and “last-modified” fields are automatically generated when an object is updated, there is no need for manual input. However, as it’s common practice for users to copy a complete existing database object, modify a single line and submit it in an update, a user will see a “warning” when these attribute fields are filled out (as is the case with other auto-generated attributes). The changes will be accepted but the values for the auto-generated attributes will be discarded.
Impact on users when reading/parsing the RIPE Database
In anticipation of "changed:" becoming optional and then deprecated in the next phases of this implementation, anyone using the "changed:" attribute should update their tools to rely on the "last-modified:" and/or "created:" attributes instead.
Users that do not use the "changed:" attribute should not be affected as adding new attributes is RFC compliant and parsers should ignore it if they don't understand it. Users are still encouraged to test this change in the RC environment.
Phase 2: “changed:” Becomes Optional
1 June 2015: RC
13 July 2015: Production
The "changed:" attribute may no longer be present in some objects after this phase. The RC period for this release is longer than usual given the potential impact for some users.
Impact on users when updating the RIPE Database
Even though updates including "changed:" are still accepted during this phase, such updates will be rejected in the next phase. We very strongly recommended that users modify their tools and stop including “changed:” attributes when submitting objects.
The “changed:” attribute is now marked as 'optional' in the RPSL schema. A warning is generated when a “changed:” attribute is submitted but the update is still accepted.
Impact on users when reading/parsing the RIPE Database
Tools/scripts relying on “changed:” may start to fail at this point because an increasing number of objects will no longer contain this attribute now that it's optional. We strongly encourage you to migrate from “changed:” to “created:” and “last-modified:”.
Phase 3: “changed:” is Deprecated
21 December 2015: RC
1 February 2016: Production
[Additional information 30 October 2015:] Tentative deployment to Release Candidate is planned now for December 2015. The exact date will be announced to the RIPE Database working group and the ncc-announce mailing list. Production is planned for 6 weeks later.
The "changed:" attribute will be removed from all objects in the RIPE Database and updates including "changed:" will no longer be accepted. The RC period for this release is longer than usual given the impact for users.
Impact on users when updating the RIPE Database
We agreed that in order to deprecate the use of the "changed:" attribute completely, updates including "changed:" would no longer be accepted. This means that *all* automated tools that submit updates to the RIPE Database have to be modified to exclude this attribute.
[Additional information 14 January 2016:] The RIPE Database will not reject objects if they include the “changed:” attribute. Instead, we will remove the “changed:” attribute from the object and issue a warning, but accept the remaining object (provided it passed other validation rules). The reason for this is that we still see a large number of updates that include the “changed:” attribute. We expect this number to go down over time when the “changed:” attribute is removed from the object templates, and when the attribute is no longer present on objects that are being updated. We will monitor this carefully over the coming months before implementing stricter regulations concerning the attribute.
However, users are still strongly advised to exclude the "changed:" attribute in updates, but rather to rely on "created:" and "last-modified:", or use "remarks:" instead.
Impact on users when reading/parsing the RIPE Database
In Phase 3, “changed:” is removed from *all* objects. Users that have not yet updated their tools to use "last-modified:" and/or "created:" during Phase 1 or 2 must do so now.
Comments 4
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Zanni Elisabetta •
I should like to know : 1) the exact date of October when the attribute "changed" will not be accepted. 2) attribute "created" and "last modified" are mandatory or optional ? 3) attribute "created" and "last modified" have to be filled mandatory for update and delete ?
Tim Bruijnzeels •
@1: the exact date of October when the attribute "changed" will not be accepted Unfortunately the release to the RC environment has suffered some delays because we needed to prioritise work on maintainer passwords, and more recently in support of inter-RIR resource transfers. We now expect to release phase 3 to the RC environment around mid October, and deploy to the production environment 6 weeks later. Once the release to the RC environment is done we will know for sure and inform the community. @2: attribute "created" and "last modified" are mandatory or optional As described in phase 1 above, these attributes are server-generated. So they are always there, but do not need to be specified when an object is created. In fact if they are specified, they will be ignored and a warning is issued. @3: attribute "created" and "last modified" have to be filled mandatory for update and delete As described in phase 1, these attributes will be ignored and a warning is issued. They can be included, but are not needed for updates or deletes.
Fabrizio Vianello •
Any news about the exact date for phase 3 installation in production environment?
Tim Bruijnzeels •
We were planning to release changed phase 3 to RC in August, but we had to postpone the work because of other issues: we needed to support inter-RIR transfer processes and have had to move planned work on upgrading the server hardware forward. Our tentative expectation is that we will be able to release this change to RC early december, but this date too is still dependent on some unknown factors. In particular we may wish to avoid having too many releases and include other changes like limiting the use of the RPSL maintainer and making the "descr:" attribute optional (and no longer enforce organisation names in descr for resource objects). We will announce the release to the Database Working Group mailing list as well as ncc-announce and use a long period in the RC environment to ensure that everyone can test. Hope this clears it up. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC Database Group