# Descriptions of Secondary Objects

# Description of the AS-BLOCK Object

Below is the object template for the as-block object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
as-block:       mandatory  single     primary/lookup
descr:          optional   multiple  
remarks:        optional   multiple  
org:            optional   multiple   inverse
notify:         optional   multiple   inverse
mnt-lower:      optional   multiple   inverse
mnt-by:         mandatory  multiple   inverse
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

An as-block object delegates a range of AS Numbers to a given RIR. Only the RIPE Database Administrators can create as-block objects. The set of as-block objects covers the full range of 16-bit and 32-bit AS Numbers. These objects prevent anyone other than the RIPE Database administrators from creating aut-num objects in the RIPE Database for AS Numbers that are administered by the RIPE NCC. The authorisation is set up so that anyone can create aut-num objects in the RIPE Database as copies of AS Numbers administered by other RIRs.

The primary key value will be in this format:

‘ASn - ASm' where n and m is a 32-bit unsigned, numbers in the range 0: 4,294,967,295. The values of n and m can be the same representing a block of one AS Number.

Leading zeroes (AS1 - AS065536) are not allowed and will be removed (AS1 - AS65536) by the database software.

Description of Attributes Specific to the AS-BLOCK Object

  • "as-block:" – the range of AS Numbers covered by this block.
  • "descr:" - A short description related to the object.
  • "mnt-lower:" – This attribute controls who is able to create aut-num objects in the RIPE Database for the range of AS Numbers covered by this as-block object. See the section 'Authorisation' for more information.

# Description of the IRT Object

Below is the object template for the irt object. It lists all possible attributes that are allowed in this object type.

Attribute Name   Presence   Repeat     Indexed
irt:            mandatory  single     primary/lookup key
address:        mandatory  multiple  
phone:          optional   multiple  
fax-no:         optional   multiple  
e-mail:         mandatory  multiple   lookup key
signature:      optional   multiple  
encryption:     optional   multiple  
org:            optional   multiple   inverse key
admin-c:        mandatory  multiple   inverse key
tech-c:         mandatory  multiple   inverse key
auth:           mandatory  multiple   inverse key
remarks:        optional   multiple  
irt-nfy:        optional   multiple   inverse key
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

The irt object was introduced to represent a Computer Security Incident Response Team (CSIRT). This object includes security information for use by CSIRT teams as they communicate with each other.

The irt object may only be referenced from inetnum and inet6num objects to show which CSIRT is responsible for handling computer and network incidents for that address range. Use is made of the hierarchical nature of address space. Any reference in an inet(6)num object to an irt object applies not only to the referencing object but also to all more specific address space. So the more specific objects inherit the reference to the irt object. When querying address space for an irt reference, the query software takes account of this inheritance and queries up the hierarchy looking for the nearest applicable irt object reference. This information is returned when any more specific inet(6)num object is queried. Where irt references are made at multiple points in an address space hierarchy, the closest less specific reference applies.

Adding a reference to an irt object requires authorisation from the maintainer of the irt object. This is handled using the "auth:" attribute of the irt object. Although the reference to an irt object from an inet(6)num object is made using the "mnt-irt:" attribute, it should be clear that the irt object is not a mntner object. The irt object contains contact information and is more similar to a role object than a mntner object.

The contact details provided by an irt object must be business information and must not contain any personal information.

Description of Attributes Specific to the IRT Object

  • "irt:" – This attribute is a single word name for the response team starting with ‘IRT-‘.
  • "address:" - This is a full postal address for the business contact represented by this irt object.
  • "phone:" – This is a phone number for the business contact represented by this irt object. It specifies a telephone number in international format. It must start with a '+' followed by the international country code, area code and number, optionally followed by an extension number.
  • "fax-no:" - This is a fax number for the business contact represented by this irt object.
  • "e-mail:" – This is an email address of a business role, organisation or CSIRT team represented by this irt object.
  • "signature:" – This attribute references a key-cert object in the RIPE Database representing a public key used by the CSIRT team to sign their correspondence.
  • "encryption:" – This attribute references a key-cert object in the RIPE Database representing a public key used to encrypt correspondence sent to the CSIRT team.
  • "auth:" – This attribute defines the authentication scheme to be used to authorise the addition of a reference to this irt object. It has the same authentication options as described in the the sub-section 'Description of the mntner Object'.
  • "irt-nfy:" – This attribute specifies a business email address to be notified when a reference to this irt object is added or removed.
  • "mnt-ref:" – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this irt object in any other object.

# Description of the KEY-CERT Object

Below is the object template for the key-cert object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
key-cert:       mandatory  single     primary/lookup key
method:         generated  single    
owner:          generated  multiple  
fingerpr:       generated  single     inverse key
certif:         mandatory  multiple  
org:            optional   multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
admin-c:        optional   multiple   inverse key
tech-c:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A key-cert object holds a public key certificate, available by querying the RIPE Database. Anyone who needs to use authorisation in the RIPE Database and who has a private key can store their public key in a key-cert object. It is used with the mntner and irt objects. You cannot create a public/private key pair using the RIPE Database software. You must use some external software to create your keys and then copy the certificate data into the key-cert object.

Currently, the RIPE Database supports two types of keys, PGP and X.509.

The PGP certificate can be used to authorise updates to the RIPE Database and for signing and encrypting correspondence with a CSIRT using an irt object (see the sub-sections 'Description of the irt Object' and ‘Description of the mntner Object' for more details). The "key-cert:" attribute takes the format ‘PGP-nnnnnnnn' where the key-id nnnnnnnn is a hexadecimal number. These keys are compliant with the Open PGP Message Format. PGP keys using an Elliptic Curve algorithm are not currently supported (e.g. Curve 25519, NIST, SECG, ECC Brainpool etc.).

The X.509 certificate can be used to sign and encrypt correspondence with a CSIRT using an irt object. It may work in some circumstances for authorising updates to the RIPE Database but we cannot guarantee this. The "key-cert:" attribute takes the format ‘X509-nnn' where key-id nnn is an integer number starting with 1. If you want to create an X.509 key-cert object you must follow this appendix.

The "method:", "owner:" and "fingerpr:" attributes are all generated by the software. It is not necessary to include these attributes when you create or modify one of these objects. If any of them are supplied, the software will check the values. If the value is wrong for any reason, the software will replace the supplied values with generated values. In this case, a warning will be returned to the user.

In case of performing REST updates using this authentication method Client Certificate Authentication API needs to be used.

Description of Attributes Specific to the KEY-CERT Object

  • "key-cert:" – This attribute specifies the key-id. This is used in "auth:" attributes of the mntner and irt objects.
  • "method:" – This attribute defines the type of the public key. Currently, only PGP and X509 are supported.
  • "owner:" – This attribute specifies the owner of the public key. This information must be supplied when you create the key. The RIPE Database software extracts this information from the key data when the key-cert object is created.
  • "fingerpr:" – This attribute is an identifier of the public key. The RIPE Database software extracts this information from the key data when the key-cert object is created.
  • "certif:" – The value of the public key should be supplied either using multiple "certif:" attributes, or in one "certif:" attribute. In the first case, this is easily done by exporting the key from your local key ring in ASCII-armored format and adding the string "certif:" to the start of each line of the key. In the second case, line continuation should be used to represent an ASCII-armored format of the key. All the lines of the exported key must be included, not forgetting the begin and end markers and the empty line that separates the header from the key body.

# Description of the MNTNER Object

Below is the object template for the mntner object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
mntner:         mandatory  single     primary/lookup key
descr:          optional   multiple  
org:            optional   multiple   inverse key
admin-c:        mandatory  multiple   inverse key
tech-c:         optional   multiple   inverse key
upd-to:         mandatory  multiple   inverse key
mnt-nfy:        optional   multiple   inverse key
auth:           mandatory  multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key 
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

Objects in the RIPE Database are protected using mntner objects. A mntner object is an anonymous box containing the credentials needed to authorise creation, deletion or modification of any objects that it protects by whomever maintains this data. Currently, these credentials are MD5 passwords or PGP keys or Single Sign-On user names from the RIPE NCC Access system. The syntax also allows for X.509 certificates, but these are not fully implemented throughout the whois software.

Objects are protected by a mntner, if they contain a reference to the mntner in the object. This is done by including a "mnt-by:" attribute. Other "mnt-xxx:" attributes offer hierarchical protection. The "mnt-by:" attribute is mandatory in all object types.

A mntner object can be referenced either as a single mntner or comma-separated list of mntners.

Most users set the "mnt-by:" value in a mntner to reference itself. That makes it maintain itself. But this is not always the case. There are situations where someone wants to control who maintains a set of objects. This can be done by using mnt-a to maintain mnt-b. The object mnt-b contains the credentials to maintain a set of data. These credentials are set up by mnt-a.

To update an object protected by a mntner the authorisation must be passed from one of the "auth:" values in the mntner object referenced in one of the "mnt-by:" attributes of the updated object. This means that the correct credential for one of the "auth:" values must be supplied as part of the update. If an object references more than one mntner in the "mnt-by:" attributes, they act as a logical 'OR'. If the authorisation is passed by any "auth:" value from any of the referenced *mntner objects, then the update will be authorised.

The "mnt-lower:", "mnt-routes:" and "mnt-domains:" attributes all provide for hierarchical authorisation. These also work in a logical 'OR' when multiple values are included in an object. How they are used is described in the object descriptions where these attributes are valid.

For more detailed information about using mntner attributes, see the section ‘Authorisation'.

Description of Attributes Specific to the MNTNER Object

  • "mntner:" – This attribute specifies the name of the mntner object. It should end in ‘-mnt', but the software has never enforced this.
  • "descr:" – A short description related to the object.
  • "upd-to:" – This attribute specifies an email address where a notification will be sent when an attempt to update an object protected by this mntner is unsuccessful due to authorisation failure. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • "mnt-nfy:" – This attribute specifies the email address where a notification will be sent when an object protected by this mntner is successfully updated. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • "mnt-ref:" – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this mntner object in any other object.
  • "auth:" – This attribute defines an authentication scheme to be used. Any of the current authentication schemes used by the RIPE Database are allowed.

# Description of the ORGANISATION Object

Below is the object template for the organisation object. It lists all possible attributes that are allowed in this object type.

Attribute Name    Presence   Repeat     Indexed
organisation:     mandatory  single     primary/lookup key
org-name:         mandatory  single     lookup key
org-type:         mandatory  single    
descr:            optional   multiple  
remarks:          optional   multiple  
address:          mandatory  multiple 
country:          optional   single 
phone:            optional   multiple  
fax-no:           optional   multiple  
e-mail:           mandatory  multiple   lookup key
geoloc:           optional   single    
language:         optional   multiple  
org:              optional   multiple   inverse key
admin-c:          optional   multiple   inverse key
tech-c:           optional   multiple   inverse key
abuse-c:          optional   single     inverse key
ref-nfy:          optional   multiple   inverse key
mnt-ref:          mandatory  multiple   inverse key
notify:           optional   multiple   inverse key
mnt-by:           mandatory  multiple   inverse key
created:          generated  single
last-modified:    generated  single
source:           mandatory  single

The organisation object provides information about an organisation that has registered an Internet resource in the RIPE Database. This may be a company, non-profit group or individual. It was introduced as a means to link together all of the human and Internet resources related to one organisation.

This object is the central starting point for managing data in the RIPE Database. All your other objects are related to this object. If you manage any aspect of any resource then you should have an organisation object so that other people know who you are, what you maintain and how to contact you.

The organisation object should only contain business information. Even if the organisation is an individual, it should not include any personal information.

Adding references to an organisation object requires authorisation from the organisation. Removing them does not need any authorisation. The maintainer of the organisation object can choose to be notified when any reference is added or removed.

This object is created for new members by the RIPE NCC with "org-type: LIR". These objects are required to include an "abuse-c:" attribute referencing an abuse contact object.

The member organisation objects are partly managed by the RIPE NCC and partly by the member. Because of this joint management, with the RIPE NCC mntner as the "mnt-by:", these objects are locked out of normal updates by members. The parts that the member can change can only be edited in the LIR Portal (opens new window) Object Editors.

Description of Attributes Specific to the ORGANISATION Object

  • "organisation:" – This attribute specifies the ID of an organisation object. When creating an object, you must specify an "AUTO" ID by setting the value of the attribute to "AUTO-1" or "AUTO-1<letterCombination>" ,so the database will assign the ID automatically. The ID will always start with the string ‘ORG-‘ prefix, followed by 2 to 4 letters, digits, a dash and the database source. If deleted, it is not possible to recreate an organisation object with the same ID.
  • “org-name:” – This attribute specifies the name of the organisation that this organisation object represents in the RIPE Database.
  • “org-type:” – This attribute specifies the type of the organisation. It takes one of the following fixed values. Uses can only create organisation objects with the type ‘OTHER'. The rest of the values can only be set by the RIPE NCC.
    • 'IANA' – Only used for Internet Assigned Numbers Authority
    • 'RIR' – Only used for the five Regional Internet Registries
    • 'NIR' – This is for National Internet Registries (there are no NIRs in the RIPE NCC service region, but it is used by APNIC)
    • 'LIR' – This represents all the Local Internet Registries (the RIPE NCC members)
    • 'WHITEPAGES' – A little-used historical idea for people who have a ‘significant' presence in the industry but who don't manage any resources in the RIPE Database.
    • 'DIRECT_ASSIGNMENT' – Used for organisations who have a direct contract with RIPE NCC
    • 'OTHER' – This represents all organisations that do not fit any of the above categories.
  • “descr:” – A short description related to the object.
  • "country:" - This is the country for the organisation. Can only be added, modified or removed by the RIPE NCC if the organisation is referenced from RIPE NCC (jointly) maintained resources.
  • “phone:” – This is a phone number for the business contact represented by this organisation object. It specifies a telephone number in international shorthand. It must start with a '+' followed by the international country code, area code and number, optionally followed by an extension number.
  • “fax-no:” – This is a fax number for the business contact represented by this organisation object.
  • “e-mail:” – This is a business email address for the organisation represented by this object.
  • “geoloc:” – The geolocation coordinates for the resource in decimal degrees notation. Format is latitude followed by longitude, separated by a space. Latitude ranges from [-90,+90] and longitude from [-180,+180].
  • “language:” – Identifies the language as a two-letter code from the ISO 639-1 language code list.
  • “abuse-c:” – This attribute references an abuse contact object. This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).
  • “ref-nfy:” – This attribute specifies an email address where a notification will be sent when a reference to an organisation object is added or removed. If there are multiple attributes, all specified email addresses will receive a direct email to that address.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this organisation object in any other object.
  • “address:” – This is a full postal address for the business contact represented by this organisation object.

# Description of the PERSON Object

Below is the object template for the person object. It lists all possible attributes that are allowed in this object type.

Attribute Name    Presence   Repeat     Indexed 
person:           mandatory  single     lookup key
address:          mandatory  multiple  
phone:            mandatory  multiple  
fax-no:           optional   multiple  
e-mail:           optional   multiple   lookup key
org:              optional   multiple   inverse key
nic-hdl:          mandatory  single     primary/lookup key
remarks:          optional   multiple  
notify:           optional   multiple   inverse key
mnt-by:           mandatory  multiple   inverse key
mnt-ref:          optional   multiple   inverse key
created:          generated  single
last-modified:    generated  single
source:           mandatory  single

The person object provides information about a real person. The original intention was that this should only be used for contacts responsible for technical or administrative issues relating to Internet resources registered in the RIPE Database. However, the business model used by many resource holders is to also document End User customers who have been assigned a resource. One of its purposes is defined as a contact database for people who manage resources. It is not easy to distinguish between customers and contacts from the person object, unless it is documented in "remarks:". The person object is the only object in the RIPE Database that should contain any personal information. The "person:" attribute is not the primary key of this object, even though it is the first attribute. The name in the "person:" attribute can be changed by the user.

The person and role objects are the only objects where the first attribute is not (even part of) the primary key of the database object. For these objects the primary key is the "nic-hdl:" attribute. Both these objects ‘share' the use of the primary key. So it is not possible to have a person object with the same “nic-hdl:” value as a role object. The two objects have become almost interchangeable and in most situations either can be used. But it is not possible to convert one into the other. It is not possible to determine if an object is a person or role object from the “nic-hdl:”.

If a person object is deleted, it is not possible to recreate it with the same NIC Handle. This rule was only introduced in 2009. Before that date, the NIC Handles could be re-used. Some caution should be exercised when looking at the history of objects that reference NIC Handles. A person or role object in the database that currently has that NIC handle may not be the same person or contact as the one using this NIC Handle in the historical reference.

Description of Attributes Specific to the PERSON Object

  • "person:" – This attribute specifies the full name of the contact person. It must have at least two words in the name.
  • “address:” – This is a full postal address for the contact represented by this object.
  • “phone:” – This is a phone number for the contact represented by this object. It specifies a telephone number in international format. It must start with a '+' followed by the international country code, area code and number., optionally followed by an extension number.
  • “fax-no:” – This is a fax number for the contact represented by this object.
  • “e-mail:” – This is an email address for the contact represented by this object.
  • “nic-hdl:” – This attribute specifies the ID of a person object. When creating an object, you can specify an "AUTO" ID by setting the value of the attribute to ‘AUTO-1' or ‘AUTO-1<letterCombination>', so the database will assign the ID automatically. If an AUTO ID is requested, it will always end with the source name, e.g. ‘-RIPE'. If you choose the value yourself you can use a two-letter international country code instead of the source at the end or you can just leave out this suffix. For example DW-RIPE, DW-NL and DW are all valid NIC Handles.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this person object in any other object.

# Description of the POEM Object

Below shows the object template for the poem object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
poem:           mandatory  single     primary/lookup key
descr:          optional   multiple  
form:           mandatory  single     inverse key
text:           mandatory  multiple  
author:         optional   multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  single     inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A poem object contains a poem that is submitted by a user. It has no operational use and reflects the humorous side of industry representatives.

Description of Attributes Specific to the POEM Object

  • "poem:" – This attribute specifies the title of the poem.
  • “descr:” – A short description related to the object.
  • “form:” – This attribute specifies the identifier of a registered poem type. These are set by the poetic-form objects.
  • “text:” – This attribute specifies the body of the poem. It must be humorous, but not malicious or insulting. It should be written in the style of the "form:".
  • “author:” – This attribute is the NIC Handle of the person who entered the poem.

# Description of the POETIC-FORM Object

Below is the object template for the poetic-form object. It lists all possible attributes that are allowed in this object type.

Attribute Name  Presence   Repeat     Indexed
poetic-form:    mandatory  single     primary/lookup key
descr:          optional   multiple  
admin-c:        mandatory  multiple   inverse key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
mnt-by:         mandatory  single     inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A poetic-form object defines the supported poem types. A new ‘poetic form' must be approved by the community ‘style council'. For more details, contact the RIPE Database Working Group or RIPE NCC Customer Services (opens new window).

Description of Attributes Specific to the POETIC-FORM Object

  • "poetic-form:" – This attribute starts with "FORM-". It is followed by the name of an internationally recognised poetic format of humorous writing. For example, limerick or haiku.
  • “descr:” – This attribute describes the style of the poetic form, written in the form style. For example, if it is a FORM-LIMERICK, the description will be written as a limerick.
  • "mnt-by:" - The poetic-form object must contain a single "mnt-by:" attribute. The object must be maintained by RIPE-DBM-MNT.

# Description of the ROLE Object

Below is the object template for the role object. It lists all possible attributes that are allowed in this object type. Required attributes are shown as ‘mandatory'.

Attribute Name  Presence   Repeat     Indexed
role:           mandatory  single     lookup key
address:        mandatory  multiple  
phone:          optional   multiple  
fax-no:         optional   multiple  
e-mail:         mandatory  multiple   lookup key
org:            optional   multiple   inverse key
admin-c:        optional   multiple   inverse key
tech-c:         optional   multiple   inverse key
nic-hdl:        mandatory  single     primary/lookup key
remarks:        optional   multiple  
notify:         optional   multiple   inverse key
abuse-mailbox:  optional   single     inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-ref:        optional   multiple   inverse key
created:        generated  single
last-modified:  generated  single
source:         mandatory  single

A role object is similar to a person object. However, instead of describing a single person, it describes a role performed by one or more people. This might be a help desk, network monitoring centre, team of system administrators, etc. A role object is useful since often a person performing a specific function may change while the role itself remains.

The role object should only include business information about the role. It should not contain any personal information, although it can reference person objects. The original intention was that the role object should be used in every other object where contacts are referenced. The person object was only intended to be referenced by the role object. However, business rules were never built into the software to enforce this. As a consequence, the person and role objects have been used inter changeably in almost any situation where contacts are referenced. The "role:" attribute is not the primary key of this object, even though it is the first attribute. The name in the “role:” attribute can be changed by the user.

The person and role objects are the only objects where the first attribute is not (even part of) the primary key of the database object. For these objects the primary key is the “nic-hdl:” attribute. Both these objects ‘share' the use of the primary key. So it is not possible to have a person object with the same “nic-hdl:” value as a role object. The two objects have become almost interchangeable and in most situations either can be used. But it is not possible to convert one into the other. It is not possible to determine if an object is a person or role object from the “nic-hdl:”.

If a role object is deleted, it is not possible to recreate it with the same NIC Handle. This rule was only introduced in 2009. Before that date, the NIC Handles could be re-used. Some caution should be exercised when looking at the history of objects that reference NIC Handles. A person or role object in the database now with that NIC handle may not be the same person or contact as the one using this NIC handle in the historical reference.

References to person objects is optional. A help desk can be represented by a role object. The role contains all the details needed to contact the help desk. It may not be necessary to identify the individuals who make up a team to provide support. Anyone with a problem will contact the help desk and ‘someone' will respond and provide support. Therefore, no person objects need to be referenced by this help desk role object.

Description of Attributes Specific to the ROLE Object

  • "role:" – This attribute specifies a name for the role. As this is business data rather than personal data, the structure of the “role:” value is similar to the “org-name:” in the organisation object.
  • “address:” – This is a full postal address for the role represented by this object.
  • “phone:” – This is a phone number for the role represented by this object. It specifies a telephone number in international shorthand. It must start with a '+' followed by the international country code, area code and number, optionally be followed by an extension number.
  • “fax-no:” – This is a fax number for the role represented by this object.
  • “e-mail:” – This is an email address for the role represented by this object.
  • “abuse-mailbox:” – The role object is the only place that this attribute should be used. It represents the email address to be used when someone wants to report abuse from an Internet resource. A role object with an “abuse-mailbox:” attribute can be referenced by an “abuse-c:” attribute in an organisation object. For more details see the section on Abuse Handling.
  • “nic-hdl:” – This attribute specifies the ID of a role object. When creating an object, you can specify an "AUTO" ID by setting the value of the attribute to ‘AUTO-1' or ‘AUTO-1<letterCombination>', so the database will assign the ID automatically. If an AUTO ID is requested, it will always end with the source name, e.g. ‘-RIPE'. If you choose the value yourself you can use a two-letter international country code instead of the source at the end or you can just leave out this suffix. For example DW-RIPE, DW-NL and DW are all valid NIC handles.
  • “mnt-ref:” – This attribute references mntner objects that provide a set of authorisation tokens used for creating references to this role object in any other object.