-------------------------------------------------------------------
APNIC Document identity
Title: APNIC Maintainer Object Request Form
Short title: maintainer-request
Document ref: APNIC-069
Version: 002
Date of original publication: August 1998
Date of this version: 11 February 2002
Review scheduled: n/a
Obsoletes: APNIC-056
Status: Obsolete
Comments: This document also exists as an
online web form (with appropriate
modifications).
--------------------------------------------------------------------
APNIC Maintainer Object Request Form
This form is intended to be used by people or organizations wishing to
request a maintainer object to enhance the authentication and
authorization control over modifications to their records in the APNIC
Registration database. All people and organizations with records in
the APNIC Reigstration database are STRONGLY encouraged to obtain a
maintainer object, particularly one with an authentication mechanism
other than "NONE".
Please see instructions at the bottom of this form regarding how to
complete this application. Note that this form is parsed by machine
and modification of lines starting with #[ or the field names will
likely result in strange errors being returned to you and your request
not being processed.
After completing this form, please submit it via email to:
apnic-dbm@apnic.net
or in type written English via fax (discouraged) to:
+61-7-3858-3199
or in type written English via postal mail (as a last resort) to:
Asia Pacific Network Information Center
Level 1, 33 Park Road
P. O. Box 2131
Milton, QLD 4064
Australia
If you have any questions regarding this form, you may contact us via
email at apnic-dbm@apnic.net (preferred), fax at the above number,
postal mail at the above address or via telephone at +61-7-3858-3100
between the hours of 9:00 AM to 5:00 PM Australian Eastern Standard
Time. Note that we do not accept maintainer requests via telephone.
Please allow up to one week for processing electronic mail requests
and up to one month for other forms of submission.
NOTE: IT IS NOT NECESSARY TO INCLUDE THIS HEADER NOR THE INSTRUCTIONS
AT THE BOTTOM OF THIS FORM WITH YOUR APPLICATION.
- - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - -
#[MAINTAINER TEMPLATE V:3.0]#
#acct-name:
mntner:
descr:
descr:
country:
admin-c:
tech-c:
upd-to:
auth:
remarks:
mnt-by:
changed:
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
changed:
mnt-by:
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
changed:
mnt-by:
source: APNIC
#[TEMPLATES END]#
Additional Comments:
- - - - - - - - - - - - - - CUT HERE - - - - - - - - - - - - - - - - -
1. Instructions For Completing This Form
----------------------------------------
Below are the instructions for filling in an Maintainer Object Request
form. It is *EXTREMELY* important you provide attributes for the tags
listed below correctly. Failure to do so WILL result in delays in
service and thus may delay when you will receive your maintainer ID.
Information provided in the MAINTAINER and PERSON templates will be
made available over the Internet via WHOIS to whois.apnic.net and
other mechanisms. This information is provided to the Internet
community to aid in diagnosing and resolving issues related to the
operation of the Internet. Any use outside of this context is
expressly prohibited without written permission from APNIC Pty Ltd.
As APNIC applications are machine processed, application forms *MUST*
be submitted in plain ASCII, do not use MIME encoding unless that MIME
encoding can be viewed without any form of decoding. In particular,
do NOT encode your application using BASE64 encoding techniques. In
addition, do not attempt to format your application in any fashion,
e.g., do not justify text or insert extra blank lines between lines in
a template. Failure to observe these restrictions will likely result
in syntax errors being returned to you as the automated parsing system
is not prepared to handle large deviations from the format presented
in the form above. An example of a completed form is provided below.
As always, if you have any questions or comments regarding this form,
please contact apnic-dbm@apnic.net at your convenience.
2. Maintainer Object Request Details
------------------------------------
ACCT-NAME:
Please provide your APNIC account name. If you do not have an account
name but wish to become an APNIC member, please see the "APNIC
Membership Application" form available at
ftp://ftp.apnic.net/apnic/docs/membership-application
If you do not wish to become a member, please see the "APNIC
Non-Member Resource Request Application" form available at:
ftp://ftp.apnic.net/apnic/docs/non-member-application
In no case will an address request form be accepted without a
completed account field. Note that applications will not be processed
until APNIC has received payment in either the member or non-member
cases.
Example:
acct-name: APNIC-AP
MNTNER:
Please provide a short but meaningfully descriptive name for this
maintainer object which will be used in MNT-BY fields. The name
should be an upper case text string consisting of alphanumeric
characters or a "-" (dash) which is unique within the APNIC database.
You must have only one MNTNER tag per MAINTAINER object.
Example:
mntner: FOO-NOC
DESCR:
Please complete with a short description of the organization,
including the location. Please provide sufficient detail as to
distinguish your organization from others in the APNIC database, i.e.,
"descr: Computer Center" is not sufficient. Do NOT put advertising
information such as "The best internet provider in Foo" in your
description and please limit the number of DESCR lines to 5. This tag
is required for all MAINTAINER templates.
Example:
descr: Terabit Labs Inc.
descr: Network Bugs Feeding Facility
descr: Northtown
COUNTRY:
Please give the two letter ISO 3166 country code appropriate for the
organization requesting the maintainer. Do NOT provide the country
name or the three letter ISO 3166 country code. If you do not know
the appropriate ISO 3166 code for your country, please see the table
of ISO 3166 codes maintained on APNIC at
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
We are aware listing a country may be ambiguous for networks crossing
national boundaries, so choose the most appropriate country based on
the location of the administrative contact. This tag is required for
all NETWORK templates, with only one COUNTRY tag permitted.
Example:
country: JP
ADMIN-C:
Please provide the APNIC NIC handle (NIC handles from other registries
are not currently accepted) of the person who is the administrative
contact for the network. If you do not have an APNIC NIC handle,
please see the section below entitled "Obtaining an APNIC NIC
Handle". The administrative contact must be someone who is physically
located at the site of the network. Unlike other objects in the APNIC
database, the ADMIN-C tag is optional.
Example:
admin-c: JD1-AP
TECH-C:
Please provide the APNIC NIC handle (other registry NIC handles are
not currently accepted) of the person who is the technical contact for
the network. If you do not have an APNIC NIC handle, please see the
section below entitled "Obtaining an APNIC NIC Handle". The technical
contact need not be physically located at the site of the network, but
rather is the person who is responsible for the day-to-day operation
of the network. The TECH-C tag is optional.
Example:
tech-c: MS4-AP
UPD-TO:
Please indicate the RFC 822 compliant email address using a fully
qualified domain name to which mail should be sent whenever any
unauthorized update request of an object maintained by this maintainer
object is made. The email address should correspond to someone who
will be capable of understanding and acting on the unauthorized
request. There can be one or more UPD-TO tags per MAINTAINER object.
Example:
upd-to: noc@foobar.net
AUTH:
Please specify which scheme will be used identify and authenticate
update requests from this maintainer. The format for this tag is:
auth: <scheme-id> <auth-info>
where
<scheme-id> is one of NONE, MAIL-FROM, CRYPT-PW
<auth-info> is dependent on the choice of <scheme-id>.
For NONE, no authentication mechanism will be used thus, no value is
necessary for <auth-info>. For MAIL-FROM you will need a regular
expression which describes the RFC 822 email addresses which are
acceptable for updating guarded objects. These regular expressions
will be applied to the email address the mail is coming from to verify
the request is appropriate. For CRYPT-PW, a standard Unix encrypted
password must be supplied. When an update is submitted, the field
password: <plain text password>
will be included. The plain text password will then be encrypted and
compared against the value supplied in <auth-info> of the CRYPT-PW
field. At least one AUTH tag is required for all MAINTAINER objects.
The AUTH attribute is not protected information in any way; it is
returned normally like any attribute by the whois server and available
in stored copies of the database. The strength of an authentication
scheme thus has to lie in the scheme itself and cannot be based on the
obscurity of the AUTH attribute. See the section about authentication
schemes for more details.
NOTE: If you wish to use the APNIC web forms to update objects
protected by a maintainer object, you _must_ use CRYPT-PW
authentication.
Examples:
auth: NONE
auth: CRYPT-PW dhjsdfhruewf
auth: MAIL-FROM .*@apnic.net
REMARKS:
The remarks attribute contains any remarks about this maintainer that
cannot be expressed in any of the other attributes. Although multiple
lines are allowed, it should be only be used if it provides extra
information to users of the database, and usage should be kept to a
minimum.
Example:
remarks: protecting person objects only
CHANGED:
Please indicate the e-mail address of the person who is completing the
template followed by the current date in the format of YYYYMMDD (YYYY
is the current year, MM is the month and DD is the day, all values 0
filled). You should supply exactly one CHANGED tag per NETWORK
template if this is an application for a new provider block.
Example:
changed: johndoe@terabit.na 19950225
MNT-BY:
Please provide the appropriate maintainer ID. You may specify the
maintainer ID you are creating with this application as used in the
MNTNER field.
Example:
mnt-by: MAINT-FOO-AP
SOURCE:
Source of the information. For the purposes of APNIC forms, it will
always be APNIC. This information is always required in the database
and has been added to the forms already.
Example:
source: APNIC
3. PERSON Object Details
------------------------
PERSON:
Please give the full name of the person this template will represent.
Do not use formal titles like `Dr' or `Prof.' or `Sir' and please
provide full names, not initials. The name should be provided as the
person would be addressed in a letter salutation (e.g., given name
followed by family name or family name followed by given name
depending on the custom in your country). There can be exactly one
PERSON field in a PERSON template.
Example:
person: John E Doe
ADDRESS:
Please complete with the full postal address written as you would for
international postal mail (albeit without the country which is
provided using the COUNTRY field described below) using one line for
each part of the address as shown below.
Example:
address: Terabit Labs Inc.
address: Industrial Estate North
address: North Perpendicular Road 12
address: NL-1234 Northtown
COUNTRY:
Please give the two letter ISO 3166 country code appropriate for the
contact person. Do NOT provide the country name or the three letter
ISO 3166 country code. If you do not know the appropriate ISO 3166
code for this person's address, please see the list of ISO 3166 codes
maintained on APNIC at
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
This tag is required for all PERSON templates, with only one COUNTRY
tag permitted per template.
Example:
country: JP
PHONE:
Please provide the work telephone number of the person specified above
as it would be dialed internationally in your country (WITHOUT the
prefix necessary to reach an international line). Please do not
include the leading zero when specifying their area/city code unless
it is required to correctly dial the number internationally. The
format for the telephone number is:
+<country code>-<area/city code>-<exchange>-<subscriber>
If an extension is necessary, please add "ext <extension>". Please do
not put 'x' or other abbreviations for "extension". More than one
telephone number is fine; each telephone number should be put on a
separate line and written in order of the most appropriate number for
the person to the least.
Example:
phone: +81-20-1233-4676
phone: +81-20-1233-4677 ext 4711
FAX-NO:
Please complete with the facsimile number of the person as it would be
dialed internationally (WITHOUT the prefix necessary to reach an
international line) in your country. Please do not include the
leading zero when specifying their area/city code unless it is
required to correctly dial the number internationally. The format for
the facsimile number is:
+<country code>-<area/city code>-<exchange>-<subscriber>
More than one facsimile number is fine. Each facsimile number should
be put on a separate line and written in order of the most appropriate
to the least. If the person does not have a facsimile number, please
leave blank.
Example:
fax-no: +81-20-1233-4678
E-MAIL:
Please supply the electronic mail address for the person. The
electronic mail address MUST be a valid Internet reachable RFC-822
address with a fully qualified domain name. If you do not have
Internet reachable e-mail connectivity, please leave this field blank.
Multiple e-mail addresses may be specified, with each on a separate
line and written in order of the most appropriate to the least.
Example:
e-mail: johndoe@terabit.na
NIC-HDL:
A NIC Handle is a unique identifier used within the Internet registry
database to differentiate between people with the same names. NIC
handles are assigned by registries -- if you do not have one, please
do not make one up, a handle will be automatically generated for you
if you follow the procedures described below in the section entitled
"Obtaining an APNIC NIC Handle". If you have an APNIC NIC handle but
do not remember it, please make a note of this in the ADDITIONAL
COMMENTS section of the application form and leave this field blank.
If you have a NIC handle assigned by another registry, e.g., InterNIC,
please provide a full person template anyway using the auto-generating
handles as described below -- the regional registries are currently
investigating ways in which information such as this can be shared,
but no solution has yet been implemented.
Example:
nic-hdl: JD401-AP
CHANGED:
Please indicate the e-mail address of the person who is completing the
template followed by the current date in the format of YYYYMMDD (YYYY
is the current year, MM is the month and DD is the day, all values 0
filled). You should supply exactly one CHANGED tag per PERSON
template if this is a new person object.
Example:
changed: johndoe@terabit.na 960501
MNT-BY:
Please provide the appropriate maintainer ID. You may specify the
maintainer ID you are creating with this application or any other
maintainer ID that already exists in the APNIC database.
Example:
mnt-by: MAINT-FOO-AP
SOURCE:
Source of the information. For the purposes of APNIC forms, it will
always be APNIC. This information is always required in the database
and has already been added to the forms.
Example:
source: APNIC
4. Supporting Notes
-------------------
4.1 Authorization Model
The model for authorization of changes to the database is fully
integrated into the database model and applies to any object.
Optionally each database object can be associated with one or more
maintainers who are authorized to make changes. Only those
maintainers and APNIC are then authorized to change or delete the
object. Each maintainer is also represented in the database by its
own mntner: object which stores information such as contact persons,
authorization and notification details. Whenever a change to an
object is attempted the mnt-by: attribute of the current database
object is examined.
If there is no MNT-BY attribute, the update always proceeds. This is
a perfectly legitimate authorization model for those objects that do
not need sophisticated authorization. Also we would like to stress
that using stronger authorization requires timely processing of update
requests. An unresponsive maintainer preventing others from making
updates frequently is a worse solution than no authorization.
If the update is originated by a maintainer referenced in a MNT-BY
attribute, the update also proceeds causing the necessary
notifications. There are various methods to authenticate the origin
of an update request described in detail in a later section.
If a new object with a MNT-BY attribute is added to the database or a
MNT-BY attribute is added to an object that previously had no such
attribute, the authorization step is performed on the maintainer to be
added.
If authentication fails, the update request is forwarded to the
mailbox listed in the UPD-TO attribute of the maintainer(s) of the
object for processing and the originator of the request is notified.
No other notifications are performed in this case. If an update is
not authorized and no appropriate maintainer can be identified the
request will be forwarded to APNIC for action.
See the separate section below for details on authentication methods
and related matters.
4.2 The Maintained-By Attribute
Each APNIC database object has an optional attribute called MNT-BY
(maintained by). The value of the MNT-BY attribute is a reference to
a MNTNER object in the database which describes those authorized to
make changes to the object.
Multiple MNTNER objects can be referenced by separating them with
blanks, which is preferred, or by using multiple MNT-BY attributes
per object. In this case all maintainers referenced are equally
authorized to make changes to the object. For instance this is
applicable to person objects maintained by both a top-level domain
registry and a local address space registry. Because close
coordination is required if an object is to be maintained by multiple
maintainers, this is expected to be the exception rather than the
rule.
When responding to queries, the APNIC whois server will not
automatically return the associated MNTNER object with any matching
object as is done with contact persons.
4.3 Maintainer Object
The MNTNER object represents an entity maintaining objects in the
APNIC database. The maintainer is identified and referred to by a
unique maintainer name. The MNTNER object is used every time a
database object with a MNT-BY attribute is added, updated or deleted
to determine whether the originator of the update request is
authorized to make the update.
Adding a new MNTNER object will be authorized manually by APNIC staff.
Updates to MNTNER objects follow the normal authorization rules but
may receive special scrutiny by APNIC staff as well.
4.4 Authentication Schemes
The authorization model supports multiple authentication schemes.
Currently only relatively weak authentication is defined. It is
entirely possible to use stronger authentication schemes based privacy
enhanced mail (PEM, PGP). It is expected that such schemes will be
defined as the need arises.
Please note again that the authentication scheme and the additional
<auth-info> is public information available in the database. The
strength of an authentication scheme must be inherent in that scheme
and not be based on keeping this information secret. The reason for
this is that it is very difficult to keep the information confidential
and thus the APNIC cannot take this responsibility.
The following <scheme-id>s are defined:
NONE
This is the simplest authentication scheme. No authentication
is provided, i.e. it is assumed that all update requests
originate from an authorized maintainer or are at least
coordinated with one. Anyone in doubt whether it is OK to
issue update requests should check with the maintainer
concerned first, preferably at the mailbox specified in the
UPD-TO attribute. When making any changes the MNT-BY
attribute should not be changed without explicit consent from
the current maintainer.
This scheme is for those who want to give everyone the
possibility to make changes while at the same time using the
MNT-BY attribute for its notification and documentation
features. A good reason to use this scheme is that the
maintainer cannot guarantee timely processing of updates
himself.
MAIL-FROM
This authentication method checks the content of the RFC822
From: header of an update request against the regular
expression specified as <auth-info>. If the regular
expression matches the content of the From: header the update
request is authenticated successfully. The regular
expressions supported are described in POSIX 1003.2 section
2.8. As it is expected that most regular expressions will
either be literals or of a form similar to
.*@some\.domain\.or\.other an extensive description of the
possibilities will not be given. Note that the matching is
applied to the whole content of the From: header including
comments if present. No attempt is made to isolate the
mailbox part.
It should be stressed that this authentication scheme is very
weak. Forging RFC822 headers does not take much effort or
ingenuity. The reason for the scheme's existence is that it
easily prevents accidental updates rather than allowing them
first and fixing them later when notified.
This scheme is for those who want to prevent accidental
updates by others and are able to process update requests in a
timely manner.
CRYPT-PW
This scheme uses the Unix crypt(3) routine, which is also used
for login passwords under Unix. This routine provides a so
called "trap door" function, the inverse of which is somewhat
hard to calculate. The password provided by the user is
encrypted with this function and stored in its encrypted form
only. When the user later provides the password again for
authentication, the encryption is repeated and the results are
compared. Since the original (clear text) password cannot
easily be computed from the encrypted version the encrypted
password does not have to be kept secret.
The <auth-info> is the encrypted password. This can either be
obtained locally with the appropriate Unix tools or on e-mail
request from <apnic-dbm@apnic.net>. When sending in update
requests the clear text password must be provided in the
message body by specifying
password: cleartext-password
at the beginning of a line and preceding any update requests
to be thus authenticated. The password will remain valid for
all requests following it in the same e-mail message or until
another password is specified.
This scheme is slightly stronger than the MAIL-FROM scheme.
It is by no means meant to keep out a determined malicious
attacker. The crypt function is vulnerable to exhaustive
search by (lots of) fast machines and programs to do the
searching are widely available. For this reason it is strongly
discouraged to use encrypted passwords also used for other
purposes such as Unix login accounts in this scheme. As you
are publishing the encrypted password in the database it is
open to attack. The usual caveats about crypt passwords
apply, so is not very wise to use words or combinations of
words found in any dictionary of any language. See
[R. Morris, K. Thompson: Password Security: A Case History]
for more details about the scheme and its vulnerabilities.
Multiple authentication methods can be specified in the same MNTNER
object. These will be used alternatively, i.e. any one of the
authenticators is sufficient to authenticate the update request from
the maintainer. If multiple maintainers maintain an object this
feature should not be used. Multiple maintainers should be
represented by multiple mntner objects referenced in the MNT-BY
attribute. There is no way in the current model to require a
combination of multiple authenticators to authenticate a request.
5. Obtaining an APNIC NIC Handle
--------------------------------
If you are completing a person template or want to reference a person
in an another object in the APNIC registration database, you should
use an APNIC NIC handle ('nic-hdl:'). NIC handles will give you a
unique identifier attached to a person which you can use as a
reference in those cases where multiple individuals have the same
name. You can obtain an APNIC NIC handle by putting the following in
the NIC-HDL field:
nic-hdl: AUTO-1
(that's a one, not the letter 'ell'). This will result in the
database software deriving creating an APNIC handle from your first
and last initials. For example, if you submitted the following person
object (please don't):
person: David Conrad
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
[...]
nic-hdl: AUTO-1
[...]
the database software would generate a NIC handle of the form
DC###-AP
where ### is the next available number that insures the APNIC NIC
handle starting with DC would be unique.
Alternatively, you can specify the initials to use as the prefix for
the handle instead of having the database software generate them
itself. If you specify the NIC-HDL as:
nic-hdl: AUTO-1<initials>
where <initials> (without the '<' and '>') are no more than 4
characters, the database software will use those initials to create
the handle. For example:
person: David Conrad
address: Asia Pacific Network Information Center
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
[...]
nic-hdl: AUTO-1RC
[...]
the database software would generate a NIC handle of the form
RC###-AP
where ### is the next available number that insures the NIC handle
starting with RC.
You can use the same identifiers (AUTO-1 or AUTO-1<initials>) in the
same update message in other objects as a reference. The database
software will then fill in the freshly assigned NIC handles in the
objects. Note that you can also use other numbers (example: AUTO-2) so
that you can update more person objects and objects that reference the
persons in one E-mail message. For example:
[...]
admin-c: AUTO-1
tech-c: AUTO-2
[...]
person: David Conrad
[...]
nic-hdl: AUTO-1
[...]
person: Yoshiko Chong
[...]
nic-hdl: AUTO-2
[...]
will result in two new handles being created, one of the form DC###-AP
filled in for the ADMIN-C and David Conrad's NIC-HDL fields and the
other, YC###-AP filled in for the TECH-C and Yoshiko Chong's NIC-HDL
fields.
6. Examples
-----------
Use of the authorization and notification scheme described in this
document is totally optional. So the current object below remains
fully valid:
inetnum: 202.0.0.0 - 203.255.255.0
netname: APNIC-AP
descr: Asia Pacific Network Information Center
country: AU
admin-c: DC23-AP
tech-c: DC23-AP
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 19950802
source: APNIC
But even if notification is the only feature desired, adding a
maintainer object can be useful. It documents who the maintainer is
and it puts the e-mail addresses for notification in one place only:
inetnum: 202.0.0.0 - 203.255.255.0
netname: APNIC-AP
descr: Asia Pacific Network Information Center
country: AU
admin-c: DC23-AP
tech-c: DC23-AP
mnt-by: MAINT-APNIC-AP
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 19950802
source: APNIC
acct-name: APNIC-AP
mntner: MAINT-APNIC-AP
descr: Asia Pacific Network Information Center
country: AU
admin-c: DC23-AP
tech-c: DC23-AP
upd-to: staff@apnic.net
auth: NONE
mnt-by: MAINT-APNIC-AP
changed: davidc@apnic.net 19950530
source: APNIC
Note that the MNTNER object itself is maintained by MAINT-APNIC-AP
too, so notification will also happen if the object itself is changed.
Changing the addresses can then be done by changing just the mntner:
object and not all objects referring to the address. It is also easy
to switch on authentication for all objects at once if needed:
acct-name: APNIC
mntner: MAINT-APNIC-AP
descr: Asia Pacific Network Information Center
admin-c: DC23-AP
tech-c: DC23-AP
country: AU
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: MAIL-FROM .*@apnic.net
changed: davidc@apnic.net 19950530
source: APNIC
If stronger authorization is needed it can be switched on with a
single update to the MNTNER object again.
acct-name: APNIC
mntner: MAINT-APNIC-AP
descr: Asia Pacific Network Information Center
admin-c: DC23-AP
tech-c: DC23-AP
country: AU
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: CRYPT-PW 949WK1mIRby6c
changed: davidc@apnic.net 19950530
source: APNIC
Note that any update of this object must now be preceded by a line of
the form
password: YeahRite
to be properly authenticated.
Specifying alternative authentication methods is allowed. So if (for
example) either of two passwords should be used to authenticate update
requests this can be represented like this:
acct-name: APNIC
mntner: MAINT-APNIC-AP
descr: Asia Pacific Network Information Center
admin-c: DC23-AP
tech-c: DC23-AP
country: AU
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: CRYPT-PW 949WK1mIRby6c
auth: CRYPT-PW 95sF/QAyIMtgg
changed: davidc@apnic.net 19950530
source: APNIC
If on the other hand one object is maintained by multiple maintainers
this should be expressed by using multiple MNTNER objects. These will
be equivalent in authentication checking. It speaks for itself that
good coordination between the multiple maintainers of an object is an
absolute necessity:
inetnum: 202.0.0.0 - 203.255.255.0
netname: APNIC-AP
descr: Asia Pacific Network Information Center
country: AU
admin-c: DC23-AP
tech-c: DC23-AP
mnt-by: MAINT-APNIC-AP MAINT-DRC
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 19950802
source: APNIC
7. Acknowledgements
-------------------
This document in derived in large part from documents written by the
staff of the European Registry, RIPE-NCC <ncc@ripe.net>, particularly,
RIPE-120.