-------------------------------------------------------------------
APNIC Document identity

 Title:    APNIC Maintainer Object Request Form
 
 Short title:			  maintainer-request
 Document ref:  		  APNIC-026
 Version:   			  001
 Date of original publication:    1 September 1995
 Date of this version:   	  1 September 1995
 Review scheduled:  		  n/a                
 Obsoletes: 			  APNIC-018
 Status:  			  Obsolete
 Comments:  			  Obsoleted by APNIC-035
--------------------------------------------------------------------

				   
		 APNIC Maintainer Object Request Form

		      Issued: September 1, 1995
		      Expires: January 31, 1996



Please see comments 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-5276-6239

or in type written English via postal mail (as a last resort) to:

	Asia Pacific Network Information Center
	c/o The United Nations University
	    53-70, Jingumae 5-Chome,
	    Shibuya-ku, Tokyo 150, Japan

If you have any questions, 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-5276-3973.  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:2.0]#

acct-no:
mntner:		
descr:		
descr:		
admin-c:	
tech-c:		
upd-to:		
auth:		
remarks:	
notify:		
mnt-by:
changed:	
source:		APNIC

#[PERSON TEMPLATE V:3.0]#

person:
address:
address:
phone:
fax-no:
e-mail:
nic-hdl:
changed:
notify:
mnt-by:
source: 	APNIC

#[PERSON TEMPLATE V:3.0]#

person:
address:
address:
phone:
fax-no:
e-mail:
nic-hdl:
changed:
notify:
mnt-by:
source: 	APNIC

#[TEMPLATES END]#

Comments:








- - - - - - - - - - - - - -  CUT HERE - - - - - - - - - - - - - - - - -

Instructions For Completing This Form
-------------------------------------

For details on how to fill out the person template, please see
ftp://archive.apnic.net/apnic/docs/apnic-025.txt.  IF YOU HAVE AN
APNIC ISSUED NIC HANDLE, PLEASE USE IT INSTEAD OF FILLING IN THE REST
OF THE PERSON TEMPLATE.  If you have filled in NIC handles for the
admin-c and tech-c fields of the MAINTAINER template and no aspect of
the person's contact information has changed, you do NOT need to
complete the PERSON templates -- please leave the fields blank.

Below are the instructions for filling in the MAINTAINER template for
a Maintainer Object Request form.  Please provide attributes for the
tags listed correctly.  Failure to do so may result in delays in
service.  All information provided in this form will be made available
to the Internet via the APNIC Registration database.

As always, if you have any questions or comments regarding
this form, please contact hostmaster@apnic.net at your convenience.

Maintainer Object Details
-------------------------

acct-no:

Please provide your APNIC account number if you have one.  If you do
not have an APNIC account number, please see APNIC-030 available from:

	ftp://archive.apnic.net/apnic/docs/apnic-030.txt

Example:
	
	acct-no: 208789233

mntner:

Please provide a symbolic name for this maintainer object.  The name
should be an upper case text string consisting of alphanumeric
characters or a "-" (dash) which is not the same as any maintainer
name already defined.  The name must be unique with regard to other
maintainer names and NIC handles only.  It can be the same as network
names, autonomous system or community names, etc.  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.  The full postal address is not needed as this
will be required in a person template.  Please provide sufficient
detail as to distinguish your organization from others in the APNIC
database, i.e., "descr: Computer Center" is not sufficient.  Also,
please limit the number of descr: lines to 5.  At least one descr: tag
is required for all MAINTAINER objects.

Example:

        descr:   Terabit Labs Inc.
        descr:   Network Bugs Feeding Facility
        descr:   Northtown

admin-c:

Please provide the name or NIC handle of the person who is the
administrative contact for the objects guarded by this maintainer
object.  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 has administrative control
over the guarded objects.  If you specify a name instead of a NIC
Handle, 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.  In addition, please do not add periods
between the names or initials 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).  At least one admin-c: tag is required for all
MAINTAINER templates.

Example:

        admin-c: John E Doe

or with a NIC handle (preferred)

        admin-c: JD1-HK

tech-c:

Please provide the name or NIC handle of the person who is the
technical contact for the objects guarded by this maintainer object.
The NIC handle (if known) is greatly preferred and will result in
minimal delays when processing your request.  The technical contact
need not be someone physically located at the site(s) in question, but
must be someone who can resolve technical issues such as network
problems.  If you specify a name instead of a NIC Handle, 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.  In addition, please do not add periods between the names or
initials 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).  At
least one tech-c: tag is required for all MAINTAINER templates.

Example:
         tech-c: Mark A Smith

or with a NIC handle (preferred)

        tech-c: MS4-NZ

upd-to:

Please indicate the RFC 822 fully qualified email address to which
mail is 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:

	<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 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.  For
CRYPT-PW, a standard Unix crypted password must be supplied.

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.  At least one auth: tag
is required for all MAINTAINER objects.

Examples:

          auth: NONE
          auth: CRYPT-PW dhjsdfhruewf
          auth: MAIL-FROM .*@apnic.net

changed:

Please indicate the email address of the person who is completing the
template, followed by the current date in the format of YYMMDD (YY is
the last 2 digits of the current year, MM is the month and DD is the
day, all values 0 filled).  If you do not have email 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 email
address, you should supply exactly one changed: tag per MAINTAINER
template.

Example:

        changed: johndoe@terabit.na 950225

notify: 

Please provide a electronic mailbox of who should be notified when
this record changes.  This can be useful if more than one person
manage the same object.  When a record is altered, either through the
action of APNIC staff or via the database update mechanisms described
in APNIC-019, an advisory email will be sent by the database system.
If the update is not appropriate, you should immediately contact the
APNIC database manager apnic-dbm@apnic.net.  The format of this field
is one RFC822 electronic mail address per line. Although multiple
lines are allowed, usage should be kept to a minimum.  Please put
'dbmon@apnic.net' into this field if you do not wish to be notified of
changes.  If you specify a mailbox other than dbmon@apnic.net, be sure
that the person at the other end of the mailbox understands what the
update advisories mean.  There should be at least one notify: tag per
MAINTAINER template.

Example:

	notify: dbmon@apnic.net

mnt-by:

Please provide the APNIC allocated maintainer ID which will guard the
MAINTAINER object.  You may specify the MAINTAINER object being
created.  There can be zero or more mnt-by: tags per MAINTAINER
object, however each additional maintainer object specified must
already exist in the APNIC Registration Database.

Example:

	mnt-by: MAINT-FOO-JP

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 causing
any notifications specified in notify: attributes of the object.  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.

In addition the mntner: object provides the same kind of notification
ability that is also available with the notify: attribute.  When using
the notify: attribute, the user must specify who to notify in every
object that he is responsible for. If he wants to change who is
notified, every object must be changed. By putting this notification
information in the mntner: object, that information is centralized and
can be managed more easily.

Adding a new mntner: object will be authorised manually by APNIC
staff.  Updates to mntner: objects follow the normal authorisation
rules but 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:       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
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:

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
notify:      dbmon@apnic.net
changed:     hostmaster@apnic.net 950802
source:      APNIC


mntner:      MAINT-APNIC-AP
descr:       Asia Pacific Network Information Center
admin-c:     DC396
tech-c:      DC396
upd-to:      staff@apnic.net
mnt-by:	     MAINT-APNIC-AP
auth:        NONE
notify:      dbmon@apnic.net
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:

mntner:      MAINT-APNIC-AP
descr:       Asia Pacific Network Information Center
admin-c:     DC396
tech-c:      DC396
upd-to:      ops@apnic.net
mnt-by:	     MAINT-APNIC-AP
auth:        MAIL-FROM .*@apnic.net
notify:      dbmon@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.


mntner:      MAINT-APNIC-AP
descr:       Asia Pacific Network Information Center
admin-c:     DC396
tech-c:      DC396
upd-to:      ops@apnic.net
mnt-by:	     MAINT-APNIC-AP
auth:        CRYPT-PW 949WK1mIRby6c
notify:      dbmon@apnic.net
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:


mntner:      MAINT-APNIC-AP
descr:       Asia Pacific Network Information Center
admin-c:     DC396
tech-c:      DC396
upd-to:      ops@apnic.net
mnt-by:	     MAINT-APNIC-AP
auth:        CRYPT-PW 949WK1mIRby6c
auth:        CRYPT-PW 95sF/QAyIMtgg
notify:      dbmon@apnic.net
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:


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.