The object template includes information on how to complete the attribute values.
Status Instance Search Status rtr-set: [mandatory] [single] [primary/lookup key] descr: [mandatory] [multiple] [ ] members: [optional] [multiple] [ ] mp-members: [optional] [multiple] [ ] mbrs-by-ref: [optional] [multiple] [inverse key] remarks: [optional] [multiple] [ ] tech-c: [mandatory] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] mnt-lower: [optional] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ]
Attribute must be included in the object. Failure to do so will result in errors.
|rtr-set||The name of the set of routers. The rtr-set attribute may take two forms:
A non-hierarchical rtr-set attribute must begin with ‘RTRS-‘.
A hierarchical rtr-set attribute consists of rtr-set names and AS numbers separated by colons ‘:‘. There must
<as-number>: RTRS-<description> EXAMPLE AS1:RTRS-EXAMPLENET-FUTUNA-SITE
|descr||A short description related to the object’s purpose.
EXAMPLE Border and peering routers of Sparkynet
|tech-c||The NIC-handle of a technical contact ‘person’ or ‘role’ object. As more than one person often fulfills a role function, there may be more than one tech-c listed.
|admin-c||The NIC-handle of an on-site contact ‘person’ object. As more than one person often fulfills a role function, there may be more than one admin-c listed.
|mnt-by||Lists a registered ‘mntner’ used to authorize and authenticate changes to this object.
|changed||The email address of who last updated the database object and the date it occurred.
changed: firstname.lastname@example.org 20010921
IMPORTANT! This is NOT to be used as a contact address.
|source||The database where the object is registered.|
Attribute may be deleted from the object. To delete an optional attribute you must also remove the attribute from the object template. Failure to do so will result in errors.
|members||Explicitly lists IPv4 members of the rtr-set. Members of an rtr-set can be either: inet-rtr objects;
or other rtr-set objects.
|mp-members||This attribute performs the same function as the ‘members’ attribute above. The difference is that mp-members allows both IPv4 and IPv6 address families to be specified. Explicitly lists IPv4 or IPv6
‘members’ of the rtr-set can be:
|mbrs-by-ref||The identifier of a registered ‘mntner’ object that can be used to add members to the rtr-set indirectly.
|remarks||Information about the object that cannot be stated in other attributes. May include a URL or email address.|
|notify||The email address to which notifications of changes to this object will be sent.|
|mnt-lower||Sometimes there is a hierarchy of maintainers. In these cases, mnt-lower is used as well as ‘mnt-by’.|
Attribute value is generated by the database.
You will soon be able to updated this object in MyAPNIC.
Instances of attribute allowed
|Attribute must appear only once in the object.|
|Attribute may appear multiple times in the object. For example, you may wish to include more than one admin-c attribute.|
Attribute search status
|Primary keys distinguish an object from all other objects in the database. To update a primary key, you must delete the entire object and them create a new object with the updated information.|
|Attribute can be queried in the database to return the object. Please note, however, that a lookup key does not uniquely identify an object.|
|Attribute can be used when performing an inverse query using the -i flag. For example, the query
-i mntner <MNTNER-NAME>
will return all objects with the specified maintainer in the mnt-by attribute.
Using rtr-set objects
The rtr-set object allows you to groups routers (inet-rtr objects) with similar properties. For example, instead of updating individual router configurations, you could use automated
tools to update the configuration of all routers listed in the rtr-set object. This helps to avoid different configurations resulting from individual updates of routers across your network. This object
is most useful for larger, more complex networks with many routers or networks running their own RPSL databases to manage their internal network. For more information, see RFC 2622 – Routing Policy Specification Language (RPSL),