-------------------------------------------------------------------
APNIC Document identity
Title: APNIC Maintainer Object Request Form
Short title: maintainer-request
Document ref: APNIC-056
Version: 001
Date of original publication: 30 May 1997
Date of this version: 30 May 1997
Review scheduled: n/a
Obsoletes: APNIC-045
Status: Obsolete
Comments: Obsoleted by APNIC-069
--------------------------------------------------------------------
APNIC Maintainer Object Request Form
Issued: May 30, 1997
Expires: December 31, 1997*
*) This form is valid until superseded by another form. After the
date specified, please check the APNIC document store located at
ftp://ftp.apnic.net/apnic/docs/maintainer-request for a later
version of this 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:
maint-request@rs.apnic.net
or in type written English via fax (discouraged) to:
+81-3-5500-0481
or in type written English via postal mail (as a last resort) to:
Asia Pacific Network Information Center
Tokyo Central Post Office Box 351
Tokyo, 100-91, Japan
If you have any questions regarding this form, you may contact us via
email at hostmaster@apnic.net (preferred), fax at the above number,
postal mail at the above address or via telephone at +81-3-5500-0480.
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.0 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, WAIS to
wais.apnic.net (database APNIC), and ftp from the following URL:
ftp://ftp.apnic.net/apnic/dbase/data/apnic.db
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, 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 hostmaster@apnic.net at your convenience.
2.0 Maintainer Object Request Details
-------------------------------------
ACCT-NAME:
Please provide your APNIC account name if you have one. If you do not
have an APNIC account name, please see the APNIC Membership
Application form available from:
ftp://ftp.apnic.net/apnic/docs/membership-application
Note that applications without account name will not be processed.
Example:
acct-name: APNIC-AP
MNTNER:
Please provide a symbolic name for this maintainer object which will
be referenced 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. Note that in order to mark your maintainer
object as being maintained within the APNIC registry database, we will
append "-AP" to the end of your maintainer object name.
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 NETWORK templates.
Example:
descr: Terabit Labs Inc.
descr: Network Bugs Feeding Facility
descr: Northtown
COUNTRY:
Please give the two letter country code (ISO 3166) which is
appropriate for the organisation requesting address space. Do NOT
provide the country name or the three letter ISO 3166 country code.
Please see the table of ISO 3166 codes maintained on APNIC at
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
if you do not know the appropriate ISO 3166 code for your country. 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 permited.
Example:
country: JP
ADMIN-C:
Please provide the NIC handle of the person who is the administrative
contact for the network or the name of the person matching *EXACTLY*
the name to be provided in a subsequent PERSON template if you do not
have a NIC handle. The NIC handle (if known) is greatly preferred and
will result in minimal delays when processing your request. The
administrative contact must be someone who is physically located at
the site of the network. If you specify a name instead of a NIC
Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir' as the
words which comprise a name are indexed and there are many people with
the same titles. Further, please provide full given names, not
initials as single characters are not indexed within the database.
Please list the name as you 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). The ADMIN-C
field is optional.
Example:
admin-c: JD1-AP
admin-c: Jon Q Doe
TECH-C:
Please provide the NIC handle of the person who is the technical
contact for the network or the name of the person matching *EXACTLY*
the name to be provided in a subsequent PERSON template if you do not
have a NIC handle. The NIC handle (if known) is greatly preferred and
will result in minimal delays when processing your request. 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. If you specify a name instead of
a NIC Handle, please do NOT use titles like `Dr' or `Prof.' or `Sir'
as the words which comprise a name are indexed and there are many
people with the same titles. Further, please provide full given
names, not initials as single characters are not indexed within the
database. Please list the name as you 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). The
TECH-C field is optional.
Example:
tech-c: MS4-AP
tech-c: Mark A Smith
UPD-TO:
Please indicate the RFC 822 compliant email address using a fully
qualified domain name to which mail should be sent whenever any
unauthorised 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 unauthorised
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
acceptible 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 crypted
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 crypted 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.
Note: 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.
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 YYMMDD (YY is
the current year, MM is the month and DD is the day, all values 0
filled). If you do not have e-mail connectivity please leave blank
and it will be filled in for you. Do not put "Please Assign" or
similar for this field. If you have an e-mail address, you should
supply exactly one CHANGED tag per MAINTAINER template if this is an
application for a new maintainer object.
Example:
changed: johndoe@terabit.na 950225
MNT-BY:
Please provide the appropriate maintainer ID. You may specify the
maintainer ID you are creating with this application, but please
remember to append the APNIC supplied "-AP" to your MNTNER name.
Example:
mnt-by: MAINT-FOO-AP
SOURCE:
Source of the information. For the purposes of APNIC forms, it will
always be APNIC. This is information which is always required in the
database, so it has been added to the forms already.
Example:
source: APNIC
PERSON Object Details
---------------------
PERSON:
Please give the full name of the person this template will represent.
If you have provided in the person's name in the ADMIN-C or TECH-C
fields of the network template (i.e., the person does not yet have a
NIC handle), the names MUST be written identically to those provided
in the fields. Please do not use formal titles like `Dr' or `Prof.'
or `Sir' as the words which comprise a name is indexed and there are
many people with the same titles and list the name as you 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). Further, as single characters are not indexed, please
provide the full given name. 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 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 country code (ISO 3166) which is
appropriate for the contact person. Do NOT provide the country name
or the three letter ISO 3166 country code. Please see the table of
ISO 3166 codes maintained on APNIC at
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
if you do not know the appropriate ISO 3166 code for this person's
address. This tag is required for all PERSON templates, with only one
COUNTRY tag permited.
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 an Internet reachable valid 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 identifer 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. APNIC will provide you with one or you can
reserve one for yourself using the procedures described in
ftp://ftp.apnic.net/docs/database-update-info. 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. If you have a
NIC handle assigned by another registry, e.g., InterNIC, please
provide a full person template anyway and leave the NIC-HDL field
blank -- the regional registries are currently investigating ways in
which information such as this can be shared, but no solution has yet
been implemented. If you do not have a NIC handle, please leave the
field blank -- do NOT put 'Please Assign' or similar for this field.
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 YYMMDD (YY is
the current year, MM is the month and DD is the day, all values 0
filled). If you do not have e-mail connectivity please leave blank
and it will be filled in for you. Do not put "Please Assign" or
similar for this field. If you have an e-mail address, 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, but please
remember to append the APNIC supplied "-AP" to your MNTNER name.
Example:
mnt-by: MAINT-FOO-AP
SOURCE:
Source of the information. For the purposes of APNIC forms, it will
always be APNIC. This is information which is always required in the
database, so it has been added to the forms already.
Example:
source: APNIC
Supporting Notes
----------------
1. Authorization Model
The model for authorisation 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 authorised 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.
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 toplevel 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.
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 authorised manually by APNIC staff.
Updates to MNTNER objects follow the normal authorisation rules but
may receive special scrutiny by APNIC staff as well.
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 authorised 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 (cleartext) 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
cleartext 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. 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
descr: Telecom Center East 4th Floor, Mailbox 1017
descr: 2-38 Aomi, Koto-ku, Tokyo 135-70
country: JP
admin-c: DC396
tech-c: DC396
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 950802
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
descr: Telecom Center East 4th Floor, Mailbox 1017
descr: 2-38 Aomi, Koto-ku, Tokyo 135-70
country: JP
admin-c: DC396
tech-c: DC396
mnt-by: MAINT-APNIC-AP
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 950802
source: APNIC
acct-name: APNIC
mntner: MAINT-APNIC-AP
descr: Asia Pacific Network Information Center
country: JP
admin-c: DC396
tech-c: DC396
upd-to: staff@apnic.net
auth: NONE
mnt-by: MAINT-APNIC-AP
changed: davidc@apnic.net 950530
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: DC396
tech-c: DC396
country: JP
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: MAIL-FROM .*@apnic.net
changed: davidc@apnic.net 950530
source: APNIC
If stronger authorisation 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: DC396
tech-c: DC396
country: JP
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: CRYPT-PW 949WK1mIRby6c
changed: davidc@apnic.net 950530
source: APNIC
Note that any update of this object must now be preceded by
a line of the form
password: NCC-PASS
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: DC396
tech-c: DC396
country: JP
upd-to: ops@apnic.net
mnt-by: MAINT-APNIC-AP
auth: CRYPT-PW 949WK1mIRby6c
auth: CRYPT-PW 95sF/QAyIMtgg
changed: davidc@apnic.net 950530
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
descr: c/o The United Nations University
descr: 53-70 Jingumae 5-chome
descr: Shibuya-ku, Tokyo 150, Japan
country: JP
admin-c: DC396
tech-c: DC396
mnt-by: MAINT-APNIC-AP MAINT-UNU-JP
notify: dbmon@apnic.net
changed: hostmaster@apnic.net 950802
source: APNIC
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.