Over the last year the RIPE NCC made a significant number of incremental changes to the RIPE Database user interface. The implementation of streamlined authentication using RIPE NCC Access has put us in a position where we can further improve the user experience in other areas.
One thing that many users find hard to grasp is determining which data elements you can and cannot change in the RIPE Database. Some values are managed by the RIPE NCC, some are managed by the resource holder and some are generated by the server. Some values in the RIPE Database can be changed by the resource holder, just not using the RIPE Database interface. This last area is where we focussing right now, because it causes the largest amount of confusion.
When you request resources from the RIPE NCC you need to supply some information to us, such as the maintainer you would like on the object. After your resource request is approved, we put all the information in the RIPE Registry, which is reflected in an object in the RIPE Database. For an IP address range this will be an inetnum or inet6num , and for an AS Number an aut-num object. This object is managed by the RIPE NCC, as indicated by the maintainer specified as "mnt-by: RIPE-NCC-HM-MNT". The maintainer that you specified in the resource request is added to the object as a "mnt-lower:" attribute. The result is that for inet(6)nums , you can create child objects under them—your customer assignments or DSL pool ranges for example—but you can't make changes to the object itself.
This is where the so-called LIR Portal object editors come in: as a resource holder, you were required to log into the LIR Portal, go to the object editors, select one of your allocations and make changes such as specifying another administrative or technical contact. As said, this process is very confusing to most users. User data that you expect to be able to change in the RIPE Database can only be changed through the LIR Portal, whereas other information can be edited in the RIPE Database itself.
This is why we have phased out the object editors. All of this functionality is now where it belongs and where users expect it: the RIPE Database. The way this has been implemented involves a couple of steps. The first step is to use business rules to determine which attributes you can change, and which ones can only be changed by the RIPE NCC. For example, in an inetnum for an allocation only the RIPE NCC can change the netname, but you can change the administrative and technical contacts.
The second step is setting the authorisation for the attributes that you control. The RIPE NCC already has a maintainer on the allocation, RIPE-NCC-HM-MNT. In the system we have deployed, you can select a "default" maintainer to authorise changes over the attributes that you are authoritative for. You can select this maintainer in the LIR Portal and it will be placed on all existing and new objects that have joint responsibility: allocations for IP resources and the organisation object.
In the future, we also intend to put effort into making it clearer in the user interface which data the RIPE NCC is authoritative for, and which data is managed by the resource holders. This whole package of changes will make it more logical for users who have to update the RIPE Database, and clearer for users who query it.
Comments 0
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.