The maintainer (mntner) object is used to protect other objects in the RIPE Database. This is done by referring to the maintainer from the object you want to protect, using the "mnt-by:" attribute. The maintainer contains one or more authentication methods that you can use to authorise making changes to your objects.
Maintainers are anonymous. Other than the authentication references they contain, there is nothing that ties them to a specific person, group or organisation. Authentication is handled as a "logical OR", meaning that if you know one of several credentials associated with a maintainer, you can make changes to the objects that refer to it. In the example above, two people can use their RIPE NCC Access (single sign-on) account to make changes to the inet6num object, or the PGP key can be used. Which authentication method is best for your use case is explained in a separate section: Protecting your data in the RIPE Database.
Most commonly, a maintainer object is maintained by itself, meaning that the "mnt-by:" attribute of the maintainer refers to the same object. If you want to edit details, for example add or remove an authentication, you simply need to use one of the existing authentication methods. In the example above, one of the three authentications can be used to add a forth, such as a new colleague joining the team.
What makes the maintainer system flexible is the fact that you have a lot of freedom in:
- The number of maintainer objects you create
- The number of maintainers you refer to from each RIPE Database object
- The kind and number of authentication methods you use in each maintainer
- Delegation of authorisation to a specific person or group
- Controlling what kind of objects a certain group can create (such as route(6), domain and inet(6)num objects)
Given this flexibility, you must ensure you make the right choices when setting up authorisation. There are some important concepts and best practices to keep in mind which are explained in each of the following sections.
The LIR Portal Object Editors have been deprecated and replaced with the Default Maintainer. Please read the section below carefully.
If you are an LIR and you have received Internet Number Resources, several objects are created by the RIPE NCC in the RIPE Database to reflect this. These objects are managed by the RIPE NCC, but you have control over some of the attributes, such as setting the administrative and technical contact person. In order to allow you to make these changes, an additional maintainer will be present on the object, the so-called "default" maintainer. You have to select this maintainer on the LIR Portal account details page and this will be reflected on all existing and new objects that have joint responsibility: allocations for IP resources and the organisation object.
After selecting the default maintainer, you can change all of the attributes you could previously modify by using the Object Editors—such as technical, administrative and abuse contact details—through the RIPE Database itself. You can use any update method you like, e.g. webupdates, syncupdates or email updates.
Some RIPE Database objects should only be editable by you alone. A good example of this is your person object. Because only you should be allowed to make changes to this, it should be protected by a maintainer that only you can use to authenticate. This means when you start using the RIPE Database, your first step would be to create a person and maintainer pair for yourself.
Most other objects, especially the ones that are related to your resources, should be editable by you and your colleagues in the IT department or Network Operations Centre. For these objects you should be using a single maintainer that is shared by a group of people. In most cases, this maintainer was created when you registered as a RIPE NCC member or became a resource holder in another way. If not, it is always possible to create a shared maintainer at a later point.
Keep in mind that sharing a maintainer doesn't mean sharing the credentials as well, such as a password or a key. As explained earlier, a maintainer can contain multiple authentication attributes, so each person that has access to it can use their own set of credentials.
The idea behind delegation of authorisation is that you can authorise a certain group (either within or outside your organisation) to create objects under a certain parent object that you control. For example, your can allow your colleagues who are responsible for the BGP routing configuration to create route(6) objects to register the announcement in the Internet Routing Registry (IRR), and nothing else. Likewise, you can authorise your DNS group to request Reverse Delegation by creating a domain object and nothing else.
For this purpose, three attributes exist:
- "mnt-lower:", for hierachical control over one level more specific objects
- "mnt-routes:", for the creation of route(6) objects in the IRR
- "mnt-domains:", for requesting Reverse Delegation of DNS by creating a domain object
The "mnt-lower:" attribute specifies an existing mntner object used for hierarchical authorisation. It controls creation of objects one level more specific in the hierarchy of an object type (this only applies to inetnum, inet6num, as-block, aut-num, route, route6 or domain objects).
The most common ocurrance of the "mnt-lower:" attribute is in the IP address allocation(s) that you have received from the RIPE NCC. For example, if you are an LIR and you have an IPv6 allocation, it is represented in the RIPE Database as an inet6num object. Because the allocation is managed by the RIPE NCC, one of the "mnt-by:" attributes is set to RIPE-NCC-HM-MNT and the other is set by you after choosing the default maintainer. These are some of the attributes you would see:
The RIPE-NCC-HM-MNT maintainer prevents you from making changes to some of the attributes that are part of the RIPE NCC's registry management, such as the "netname:". Your LIR's default maintainer allows you to make changes to attributes you manage, such as the "admin-c:" and "tech-c:". In addition, it allows you to create assignments, as well as route(6) and domain objects under this parent block. However, if you wish to delegate the creation of child resource objects to a separate group, you can do so by creating an additional maintainer for them and specify it as "mnt-lower:":
Likewise, you can delegate control over the creation of route(6) and domain objects by adding a "mnt-routes:" and "mnt-domains:" attribute to the allocation. Keep in mind that you first have to select a default maintainer before you can do this. The resulting allocation object would look something like this:
After you have done this, you can can achieve fine-grained control over the creation of inet(6)num, route(6) and domain objects.
In this example, route and domain objects are managed by separate maintainers: LIR-RTRMGMT-MNT and LIR-DNSMGMT-MNT respectively, as specified in the allocation. In addition, a "mnt-lower:" was specified in the aggregate prefix for the broadband pool (2001:db8::/36). This allows for the creation of more specific objects below it by LIR-BROADBAND-MNT:
In general, keep in mind that when an inet(6)num, route(6) or a domain object is created, authentication is required from the parent object. If the parent has a "mnt-lower:", "mnt-routes:" or "mnt-domains:" attribute, this is the mntner that will need to be authenticated against. Otherwise the parent "mnt-by:" attribute is used.