From owner-apnic-announce@ns.apnic.net Tue Feb 2 06:38:28 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id GAA04143; Tue, 2 Feb 1999 06:00:26 GMT Received: from gateway.staff.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id FAA04104 for ; Tue, 2 Feb 1999 05:59:49 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id PAA03226 for ; Tue, 2 Feb 1999 15:59:41 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by gateway.staff.apnic.net via smap (V2.1) id xma003223; Tue, 2 Feb 99 15:59:33 +1000 Received: from localhost (paulg@localhost) by hadrian.staff.apnic.net (8.9.1a/8.9.1) with SMTP id FAA22597 for ; Tue, 2 Feb 1999 05:59:31 GMT Date: Tue, 2 Feb 1999 15:59:31 +1000 (EST) From: Paul Gampe X-Sender: paulg@hadrian To: apnic-announce@ns.apnic.net Subject: [apnic-announce] Database Update - v2.2.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] Dear Members, APNIC will be upgrading to release 2.2.1 of the RIPE Whois Database, during the February 6th maintenance window between 8:00 - 12:00 UTC+10. Included for your reference are the release notes describing the changes that are introduced with this version. We will be delaying the introduction of support for PGP authentication for a few weeks while we explore alternative licensing scenarios. Another announcement will be made when PGP authentication is to be made available. Regards, Paul Gampe. RELEASE NOTES for RIPE Database 2.2.1 This is a bugfix release with a very little new functionality added. There are some operational changes which should be transparent to the end user but ease the database maintenance. SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES Domain name queries ------------------- The behaviour of domain name queries has been changed. When a domain object cannot be found in the database, the search string is stripped towards higher level domains (xxx.yyy.zzz -> yyy.zzz) and the lookup is repeated until a domain object is found or the search string becomes empty. If a domain object with stripped domain name exists in the database and it does not contain a referral attribute the server response is "No entries found ..." and reflects the fact that the domain name originally queried doesn't exist. This is opposite to the behaviour of the previous software version which in this situation returned the higher level domain object if there was one. Referral mechanism ------------------ When referral is made the originally queried domain name is passed to the authoritative server instead of the domain name of the object containing the actual referral. If while doing an inverse query the referral mechanism is activated and the referred server is of type RIPE, the -r flag is passed to it and the -i flag is not passed. This means that the authoritative server's domain object is displayed instead of the local copy in an inverse query response when applicable. The new configuration variable REFERRALENDTXT contains text to be displayed as an end of referred query reponse marker. It is useful for inverse queries when the referred query response can be intermixed with local server responses. A limit for length of referred query response has been implemented, configurable via REFERRALMAXLINES variable. The goal was to prevent badly behaved remote servers from flooding the local server with a huge amount of data. When a referred query response gets truncated a warning message is displayed. Message text is the value of the REFERRALTRUNCTXT configuration variable. MAINTENANCE RELATED CHANGES Timeout for reading from remote server for referred queries implemented. Timing added to processing of overflow index files. If processing of overflow file takes more than 5 second, its time is logged to audit log. Timing of queries implemented. Time info written to query log. Messages about lock contention and time spent waiting for a lock added to audit log. Mechanism for disabling integrity checks implemented. It is needed in some pathological cases involving legacy data. Warnings are still generated though. Debugging printout facility added. It is activated with -b flag and is now separate from verbose output (-V). BUG FIXES PGP error "This signature applies to another message" is now catched properly. There were performance problems related to file locking and opening of multiple databases at the same time. These have been fixed. Syntax checks error messages clarified for admin-c, tech-c, zone-c and author attributes. Previously it was possible to create top level domain automatically (hierarchical authorisation didn't work in this case). It is not possible any more - requests for top level domain creation are refused now. Previously domain creation was refused due to hierarchical authorisation procedure when there was no higher level domain object found. It is fixed now. AUTO1 (actually AUTO\d*) is not treated as a valid nic handle any more. It is a reserved word. Previously when a delete request was sent with a missing source attribute it caused dbupdate process to return with an error code and a bounce sent to update originator. It is corrected now. Previously it was not possible to add a nic handle attribute to an existing person object without a nic handle. Such an update was interpreted as the creation of a new person object which led to a situation when two essentially identical person objects exist in the database. This behaviour has been fixed. Now, it is possible to add a nic-handle attribute to an existing person object. Previously it was not possible to update the values of changed attribute only. An attempt to do so resulted in NOOP error. This is corrected now and changed attribute values are now taken into account when comparing objects. RELEASE NOTES for RIPE Database 2.2 SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES PGP authentication support -------------------------- Support for authentication with PGP signatures has been added. The following modifications are related to this: - A new object "key-cert" has been introduced to allow supplying and storing of PGP public keys on the server. - A new attribute type "generated" has been added to support automatically generated fields of the "key-cert" object. Attributes of this type are ignored in the user input and replaced by the server. - A new possible value for the "auth" attribute of "mntner" object: PGPKEY- where is the PGP key ID to be used for authentication. This string is also the primary key of the "key-cert" object database. - Messages with PGP encoded parts are passed to PGP process for analysis in the first steps of dbupdate which handles incoming update messages. Results of this examination are used later if the object to be updated is protected with a maintainer with "auth: PGPKEY-". - A new script "pgpdata2ring" is installed in the tools directory. It can be used to convert existing key-cert object database to a simple file with all the ASCII-armored PGP keys in it. It can be used to re-create the server's PGP key ring from the key-cert database if the ring gets corrupted or when boot-strapping the system from existing key-cert database. - Three new configuration verbs have been added: PGPV the full name of PGP 5.0 pgpv binary PGPK the full name of PGP 5.0 pgpk binary PGPPATH the directory where the server's key rings are stored Please note that the software probably only works with PGP 5.0[i]. The implementation is not very clean because there is currently no clean way to communicate with the PGP process. Please don't even try with older versions. If you don't want to have PGP support enabled, just comment these lines out. - A new directory is created in the installation process: "$INSTALLDIR/.pgp". This is the same directory which is specified with PGPPATH in the configuration. Please also notice the following implementation details: - The server keeps two copies of the PGP keys. One copy is in the "key-cert" object database and the other is in PGP's key ring. Copies in the key ring are actually used for verifying signatures. - Mirrors of the database which are being updated with syncdb, blindly trust their masters -- they don't do any PGP authentication checks but they still update the local PGP key ring by starting PGP process every time when "key-cert" object is modified. - Multiple PGP-encoded or non-encoded parts can be supplied in a single update message; each part gets processed separately. So, you can supply several objects which are protected by different PGP keys in a single update message, but you cannot use any "magic" references like AUTO-1 nic-handles between these parts. - PGP encoded parts with an invalid signature are dropped in all cases, even if the object is not protected by PGP authentication. - PGP encoded parts can be supplied in cleartext and non-cleartext modes as long as ASCII armoring is used. - RPSL line continuation is not supported, so multiple lines in the "certif" attribute of "key-cert" object must be specified by prepending "certif:" to every line of the ASCII armored PGP key. For other details please see: draft-ietf-rps-dbsec-pgp-authent-00.txt or its successor in the usual internet-drafts repositories. Referral mechanism for domains ------------------------------ Referral mechanism has been implemented to provide redirection of domain name queries to appropriate database server when RIPE database doesn't contain authoritative answer for given domain. Following change has been made to processing of query for domain objects: when domain object with name equal to query's search string is not found in the database domain name is stripped towards higher level domains (xxx.yyy.zzz -> yyy.zzz) and lookup is repeated until a domain object is found or search string becomes empty. Only when the top level domain zzz is not present in the database the "No entries found ..." answer is given. When a domain object is finally found the proper referral mechanism comes to work. If found domain object does _not_ contain referral it is displayed as a query result just as it was in the prevoius software version. When the referral is present a whois query is made to referred (aka authoritative) host and its answer is displayed preceded by a note that this data doesn't come from the RIPE database but from a authoritative server. Local object is not displayed in that case. When a query to a referred host fails an error message is given and the local object is not displayed. There is a simple mechanism to prevent referral loops. Locally present domain object containing referral can only be shown when specifically requested by using new -R option to whois client. Referral mechanism is implemented via new domain object's attribute "refer" which is single and optional: refer: where is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. is the DNS name of the whois service. is the TCP port number (optional: 43 is the default). New configuration variables were added: REFERRALTXT - text printed as a header when displaying results of referred query from authoritative server REFERRALERRORTXT - error message printed when whois connection to remote server failed REFERRALLOOPERRORTXT - erro message printed when referral loop detected REFERRALTIMEOUTTXT - value of referral timeout in seconds Referential integrity checks ---------------------------- New checks are implemented when doing creation/modification of objects referencing other objects and when deleting objects being referenced by other objects. While creating or modifying object which has references to other objects in its admin-c, tech-c, zone-c, cross-nfy, mnt-by, cross-mnt, or origin attributes it is checked whether referenced objects exist in the database. Update is refused if reference to nonexisting object is found. While deleting person, role, maintainer or aut-num object reverse lookup is performed to find objects possibly referencing the object being deleted. If there are any objects found referencing object in question then delete operation is refused and error message is displayed stating the number and types of objects referencing object being deleted. Only RIPE database is checked for references now - other sources (RADB etc) are not searched. New syntax checks ----------------- admin-c, tech-c, zone-c attributes and author attributes must now have a valid nic handle as a value. Date in changed field is now automatically converted to long 8 digit format. Status attribute is now mandatory in inetnum objects. Valid values are: ASSIGNED PI ASSIGNED PA ALLOCATED PI ALLOCATED PA UNSPECIFIED Other checks ------------ While creating person object a check is performed whether there exist another person object with the same name in the database and warning is issued if it does. It is also checked if contact data in both objects are identical - address, phone and fax fields are compared after compressing whitespace and uppercasing strings. Behaviour of this check is configurable via new configuration variable DUPLICATEPERSONCHECK. When it is not defined the whole check is not performed. When it is defined and not equal to "strict" then both name comparison and contact data comparison is done and only warnings are issued. When value of DUPLICATEPERSONCHECK is "strict" and there is a person object in the database with the same name _and_ contact data as the one being created then the creation operation is refused. Changed attribute behaviour changed back ---------------------------------------- Changed attribute is now shown by default in query result. For backward compatibility the -c flag is accepted and quietly ignored. There is no way to suppress output of changed lines now. Improved parsing of subject line keywords ----------------------------------------- The code for parsing subject line keywords has been fully rewritten. Keywords will trigger options ONLY if there arey are alone in subject line, i.e. no non-keyword words are found. Otherwise, *whole* subject line will be ignored and a warning message will be issued. The following keywords are recognized: NEW make sure the object does not exist HELP send help text HOWTO send help text ASSIGN (*) make sure the inetnum does not exist LONGACK (**) send long acknowledgment (*) ASSIGN is now obsolete. This functionality has been dropped, since a general NEW keyword exists. If ASSIGN is found in subject line, it will be ignored and a warning message will be issued. (**) LONGACK is now the default behaviour of the database, so the keyword is silently ignored. In addition, to prevent ambiguity when multiple keywords are specified, a list of allowed combinations of keywords has been defined. If the combination of recognized keywords is not one of: ASSIGN NEW LONGACK NEW HELP HOWTO *whole* subject line will be ignored and a warning message will be issued. BUG FIXES Y2K fixes --------- All the dates generated by the software are now in Y2K compliant YYYYMMDD format. This also includes the log files, so when upgrading the software please also update your log-rotating support scripts or whatever to reflect this change. Six digit dates supplied by the user in the "changed" and "withdrawn" attributes are always first converted to 8 digit format. Date comparison has been fixed to correctly compare two dates when one is in 6 digit format and another is in 8 digit format. This bug made it previously impossible to use 6 digit dates in the "changed" attribute any more if there was already one such attribute with date specified with 8 digits. Generally, all years specified with two digits are handled in the following way: nn >= 70 becomes 19nn nn < 70 becomes 20nn Portability fixes ----------------- Non-portable ioctl() call in the server setup has been replaced with more appropriate POSIX::setsid(). MISC Whois access list ----------------- The mechanism has been implemented to block whois queries from hosts known for their abusive or copyright-violating behaviour. A note explaining why access has been blocked is displayed instead of a query result. It is implemented via a new configuration variable DENYWHOISACCESS which can have a regular expression as a value. It is matched against the IP address of the querying host. New newdb program ----------------- An upgraded newdb program is provided to facilitate creation of empty database and index files. Its usage is described in greater detail in the INSTALL file. New whois client ---------------- New whois client program understands the -R option used to suppress referral mechanism. * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * From owner-apnic-announce@ns.apnic.net Sat Feb 6 05:33:51 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id FAA03172; Sat, 6 Feb 1999 05:23:21 GMT Received: from gateway.staff.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id FAA03164 for ; Sat, 6 Feb 1999 05:23:20 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id PAA03205 for ; Sat, 6 Feb 1999 15:23:19 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by gateway.staff.apnic.net via smap (V2.1) id xma003202; Sat, 6 Feb 99 15:23:12 +1000 Received: from localhost (paulg@localhost) by hadrian.staff.apnic.net (8.9.1a/8.9.1) with SMTP id FAA26012 for ; Sat, 6 Feb 1999 05:23:12 GMT Date: Sat, 6 Feb 1999 15:23:12 +1000 (EST) From: Paul Gampe X-Sender: paulg@hadrian To: apnic-announce@ns.apnic.net Subject: [apnic-announce] Database Update - v2.2.1 - completed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] Dear Members, The upgrade to release 2.2.1 of the RIPE Whois Database, scheduled for today has been completed successfully. Should you encounter any problems with this new version please notify apnic-dbm@apnic.net. Regards, Paul Gampe. -------------------------------------------------------------------------- Dear Members, APNIC will be upgrading to release 2.2.1 of the RIPE Whois Database, during the February 6th maintenance window between 8:00 - 12:00 UTC+10. Included for your reference are the release notes describing the changes that are introduced with this version. We will be delaying the introduction of support for PGP authentication for a few weeks while we explore alternative licensing scenarios. Another announcement will be made when PGP authentication is to be made available. Regards, Paul Gampe. RELEASE NOTES for RIPE Database 2.2.1 This is a bugfix release with a very little new functionality added. There are some operational changes which should be transparent to the end user but ease the database maintenance. SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES Domain name queries ------------------- The behaviour of domain name queries has been changed. When a domain object cannot be found in the database, the search string is stripped towards higher level domains (xxx.yyy.zzz -> yyy.zzz) and the lookup is repeated until a domain object is found or the search string becomes empty. If a domain object with stripped domain name exists in the database and it does not contain a referral attribute the server response is "No entries found ..." and reflects the fact that the domain name originally queried doesn't exist. This is opposite to the behaviour of the previous software version which in this situation returned the higher level domain object if there was one. Referral mechanism ------------------ When referral is made the originally queried domain name is passed to the authoritative server instead of the domain name of the object containing the actual referral. If while doing an inverse query the referral mechanism is activated and the referred server is of type RIPE, the -r flag is passed to it and the -i flag is not passed. This means that the authoritative server's domain object is displayed instead of the local copy in an inverse query response when applicable. The new configuration variable REFERRALENDTXT contains text to be displayed as an end of referred query reponse marker. It is useful for inverse queries when the referred query response can be intermixed with local server responses. A limit for length of referred query response has been implemented, configurable via REFERRALMAXLINES variable. The goal was to prevent badly behaved remote servers from flooding the local server with a huge amount of data. When a referred query response gets truncated a warning message is displayed. Message text is the value of the REFERRALTRUNCTXT configuration variable. MAINTENANCE RELATED CHANGES Timeout for reading from remote server for referred queries implemented. Timing added to processing of overflow index files. If processing of overflow file takes more than 5 second, its time is logged to audit log. Timing of queries implemented. Time info written to query log. Messages about lock contention and time spent waiting for a lock added to audit log. Mechanism for disabling integrity checks implemented. It is needed in some pathological cases involving legacy data. Warnings are still generated though. Debugging printout facility added. It is activated with -b flag and is now separate from verbose output (-V). BUG FIXES PGP error "This signature applies to another message" is now catched properly. There were performance problems related to file locking and opening of multiple databases at the same time. These have been fixed. Syntax checks error messages clarified for admin-c, tech-c, zone-c and author attributes. Previously it was possible to create top level domain automatically (hierarchical authorisation didn't work in this case). It is not possible any more - requests for top level domain creation are refused now. Previously domain creation was refused due to hierarchical authorisation procedure when there was no higher level domain object found. It is fixed now. AUTO1 (actually AUTO\d*) is not treated as a valid nic handle any more. It is a reserved word. Previously when a delete request was sent with a missing source attribute it caused dbupdate process to return with an error code and a bounce sent to update originator. It is corrected now. Previously it was not possible to add a nic handle attribute to an existing person object without a nic handle. Such an update was interpreted as the creation of a new person object which led to a situation when two essentially identical person objects exist in the database. This behaviour has been fixed. Now, it is possible to add a nic-handle attribute to an existing person object. Previously it was not possible to update the values of changed attribute only. An attempt to do so resulted in NOOP error. This is corrected now and changed attribute values are now taken into account when comparing objects. RELEASE NOTES for RIPE Database 2.2 SUPPORTED SYSTEMS This release has been tested with perl 5.004_04 on bsdi3.1 and Solaris 2.6 systems. Please let us know if you have problems running it on other systems. NEW FEATURES PGP authentication support -------------------------- Support for authentication with PGP signatures has been added. The following modifications are related to this: - A new object "key-cert" has been introduced to allow supplying and storing of PGP public keys on the server. - A new attribute type "generated" has been added to support automatically generated fields of the "key-cert" object. Attributes of this type are ignored in the user input and replaced by the server. - A new possible value for the "auth" attribute of "mntner" object: PGPKEY- where is the PGP key ID to be used for authentication. This string is also the primary key of the "key-cert" object database. - Messages with PGP encoded parts are passed to PGP process for analysis in the first steps of dbupdate which handles incoming update messages. Results of this examination are used later if the object to be updated is protected with a maintainer with "auth: PGPKEY-". - A new script "pgpdata2ring" is installed in the tools directory. It can be used to convert existing key-cert object database to a simple file with all the ASCII-armored PGP keys in it. It can be used to re-create the server's PGP key ring from the key-cert database if the ring gets corrupted or when boot-strapping the system from existing key-cert database. - Three new configuration verbs have been added: PGPV the full name of PGP 5.0 pgpv binary PGPK the full name of PGP 5.0 pgpk binary PGPPATH the directory where the server's key rings are stored Please note that the software probably only works with PGP 5.0[i]. The implementation is not very clean because there is currently no clean way to communicate with the PGP process. Please don't even try with older versions. If you don't want to have PGP support enabled, just comment these lines out. - A new directory is created in the installation process: "$INSTALLDIR/.pgp". This is the same directory which is specified with PGPPATH in the configuration. Please also notice the following implementation details: - The server keeps two copies of the PGP keys. One copy is in the "key-cert" object database and the other is in PGP's key ring. Copies in the key ring are actually used for verifying signatures. - Mirrors of the database which are being updated with syncdb, blindly trust their masters -- they don't do any PGP authentication checks but they still update the local PGP key ring by starting PGP process every time when "key-cert" object is modified. - Multiple PGP-encoded or non-encoded parts can be supplied in a single update message; each part gets processed separately. So, you can supply several objects which are protected by different PGP keys in a single update message, but you cannot use any "magic" references like AUTO-1 nic-handles between these parts. - PGP encoded parts with an invalid signature are dropped in all cases, even if the object is not protected by PGP authentication. - PGP encoded parts can be supplied in cleartext and non-cleartext modes as long as ASCII armoring is used. - RPSL line continuation is not supported, so multiple lines in the "certif" attribute of "key-cert" object must be specified by prepending "certif:" to every line of the ASCII armored PGP key. For other details please see: draft-ietf-rps-dbsec-pgp-authent-00.txt or its successor in the usual internet-drafts repositories. Referral mechanism for domains ------------------------------ Referral mechanism has been implemented to provide redirection of domain name queries to appropriate database server when RIPE database doesn't contain authoritative answer for given domain. Following change has been made to processing of query for domain objects: when domain object with name equal to query's search string is not found in the database domain name is stripped towards higher level domains (xxx.yyy.zzz -> yyy.zzz) and lookup is repeated until a domain object is found or search string becomes empty. Only when the top level domain zzz is not present in the database the "No entries found ..." answer is given. When a domain object is finally found the proper referral mechanism comes to work. If found domain object does _not_ contain referral it is displayed as a query result just as it was in the prevoius software version. When the referral is present a whois query is made to referred (aka authoritative) host and its answer is displayed preceded by a note that this data doesn't come from the RIPE database but from a authoritative server. Local object is not displayed in that case. When a query to a referred host fails an error message is given and the local object is not displayed. There is a simple mechanism to prevent referral loops. Locally present domain object containing referral can only be shown when specifically requested by using new -R option to whois client. Referral mechanism is implemented via new domain object's attribute "refer" which is single and optional: refer: where is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. is the DNS name of the whois service. is the TCP port number (optional: 43 is the default). New configuration variables were added: REFERRALTXT - text printed as a header when displaying results of referred query from authoritative server REFERRALERRORTXT - error message printed when whois connection to remote server failed REFERRALLOOPERRORTXT - erro message printed when referral loop detected REFERRALTIMEOUTTXT - value of referral timeout in seconds Referential integrity checks ---------------------------- New checks are implemented when doing creation/modification of objects referencing other objects and when deleting objects being referenced by other objects. While creating or modifying object which has references to other objects in its admin-c, tech-c, zone-c, cross-nfy, mnt-by, cross-mnt, or origin attributes it is checked whether referenced objects exist in the database. Update is refused if reference to nonexisting object is found. While deleting person, role, maintainer or aut-num object reverse lookup is performed to find objects possibly referencing the object being deleted. If there are any objects found referencing object in question then delete operation is refused and error message is displayed stating the number and types of objects referencing object being deleted. Only RIPE database is checked for references now - other sources (RADB etc) are not searched. New syntax checks ----------------- admin-c, tech-c, zone-c attributes and author attributes must now have a valid nic handle as a value. Date in changed field is now automatically converted to long 8 digit format. Status attribute is now mandatory in inetnum objects. Valid values are: ASSIGNED PI ASSIGNED PA ALLOCATED PI ALLOCATED PA UNSPECIFIED Other checks ------------ While creating person object a check is performed whether there exist another person object with the same name in the database and warning is issued if it does. It is also checked if contact data in both objects are identical - address, phone and fax fields are compared after compressing whitespace and uppercasing strings. Behaviour of this check is configurable via new configuration variable DUPLICATEPERSONCHECK. When it is not defined the whole check is not performed. When it is defined and not equal to "strict" then both name comparison and contact data comparison is done and only warnings are issued. When value of DUPLICATEPERSONCHECK is "strict" and there is a person object in the database with the same name _and_ contact data as the one being created then the creation operation is refused. Changed attribute behaviour changed back ---------------------------------------- Changed attribute is now shown by default in query result. For backward compatibility the -c flag is accepted and quietly ignored. There is no way to suppress output of changed lines now. Improved parsing of subject line keywords ----------------------------------------- The code for parsing subject line keywords has been fully rewritten. Keywords will trigger options ONLY if there arey are alone in subject line, i.e. no non-keyword words are found. Otherwise, *whole* subject line will be ignored and a warning message will be issued. The following keywords are recognized: NEW make sure the object does not exist HELP send help text HOWTO send help text ASSIGN (*) make sure the inetnum does not exist LONGACK (**) send long acknowledgment (*) ASSIGN is now obsolete. This functionality has been dropped, since a general NEW keyword exists. If ASSIGN is found in subject line, it will be ignored and a warning message will be issued. (**) LONGACK is now the default behaviour of the database, so the keyword is silently ignored. In addition, to prevent ambiguity when multiple keywords are specified, a list of allowed combinations of keywords has been defined. If the combination of recognized keywords is not one of: ASSIGN NEW LONGACK NEW HELP HOWTO *whole* subject line will be ignored and a warning message will be issued. BUG FIXES Y2K fixes --------- All the dates generated by the software are now in Y2K compliant YYYYMMDD format. This also includes the log files, so when upgrading the software please also update your log-rotating support scripts or whatever to reflect this change. Six digit dates supplied by the user in the "changed" and "withdrawn" attributes are always first converted to 8 digit format. Date comparison has been fixed to correctly compare two dates when one is in 6 digit format and another is in 8 digit format. This bug made it previously impossible to use 6 digit dates in the "changed" attribute any more if there was already one such attribute with date specified with 8 digits. Generally, all years specified with two digits are handled in the following way: nn >= 70 becomes 19nn nn < 70 becomes 20nn Portability fixes ----------------- Non-portable ioctl() call in the server setup has been replaced with more appropriate POSIX::setsid(). MISC Whois access list ----------------- The mechanism has been implemented to block whois queries from hosts known for their abusive or copyright-violating behaviour. A note explaining why access has been blocked is displayed instead of a query result. It is implemented via a new configuration variable DENYWHOISACCESS which can have a regular expression as a value. It is matched against the IP address of the querying host. New newdb program ----------------- An upgraded newdb program is provided to facilitate creation of empty database and index files. Its usage is described in greater detail in the INSTALL file. New whois client ---------------- New whois client program understands the -R option used to suppress referral mechanism. * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * From owner-apnic-announce@ns.apnic.net Mon Feb 8 05:45:21 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id FAA22737; Mon, 8 Feb 1999 05:34:32 GMT Received: from gateway.staff.apnic.net (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id FAA22732 for ; Mon, 8 Feb 1999 05:34:31 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id PAA27221 for ; Mon, 8 Feb 1999 15:34:30 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway.staff.apnic.net via smap (V2.1) id xma027216; Mon, 8 Feb 99 15:34:11 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id PAA00830; Mon, 8 Feb 1999 15:34:10 +1000 (EST) Message-Id: <199902080534.PAA00830@julubu.staff.apnic.net> X-Authentication-Warning: julubu.staff.apnic.net: bc set sender to secretariat@apnic.net using -f From: APNIC Secretariat Date: Mon Feb 08 15:34:10 1999 To: apnic-announce@ns.apnic.net X-Mailer: sendmail sed cat Subject: [apnic-announce] Call for Comments (Policies for Address Space Management) Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] -- ******************************************************* CALL FOR COMMENTS ******************************************************* APNIC is pleased to announce that the draft document "Policies for Address Space Management in the Asia Pacific Region" is now available for public comment at . This is the first public draft of this working document, which aims to set out a clear and consistent framework of policies for allocations and assignments of address space in the Asia Pacfic region. This document represents current APNIC practices and policies, which have not been previously been codified in a single document. Once the final form of these policies has been agreed upon, APNIC will commence a review of all of its other documents. Public address space is a resource belonging to whole Internet community and, therefore, its management involves implementing policies which achieve the best possible balance of the needs of all those who use it. APNIC encourages you, as a member of the Asia Pacific Internet community, to read this document and consider its implications. We invite you to make any comments you feel would be constructive to the development of a further draft. The deadline for comments on this draft of the document is 17 February 1999. APNIC will carefully consider all comments made prior to releasing a subsequent draft of this document. That subsequent draft will be made available by 22 February 1999 and will be one of the items for approval on the agenda of the APNIC Members' Meeting (AMM) to be held in Singapore on 6 March 1999 (see for more information about the AMM). Please address your comments to the mailing list. Subscription to apnic-talk is handled by emailing majordomo@apnic.net with 'subscribe apnic-talk' in the body of the message. If, however, you would like to make comments privately, please email Paul Wilson, Director General of APNIC at . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * From owner-apnic-announce@ns.apnic.net Wed Feb 10 04:53:05 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id EAA06517; Wed, 10 Feb 1999 04:46:24 GMT Received: from gateway (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id EAA06513 for ; Wed, 10 Feb 1999 04:46:23 GMT Received: (from mail@localhost) by gateway (8.8.7/SCO5) id OAA05088 for ; Wed, 10 Feb 1999 14:46:22 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway via smap (V2.1) id xma005084; Wed, 10 Feb 99 14:46:13 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id OAA26140; Wed, 10 Feb 1999 14:46:13 +1000 (EST) Message-Id: <199902100446.OAA26140@julubu.staff.apnic.net> X-Authentication-Warning: julubu.staff.apnic.net: bc set sender to secretariat@apnic.net using -f From: APNIC Secretariat Date: Wed Feb 10 14:46:13 1999 To: apnic-announce@apnic.net X-Mailer: sendmail sed cat Subject: [apnic-announce] Draft IPv6 Policy Document - Call for Comments Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] -- ******************************************************* Draft IPv6 Policy Document - Call for Comments ******************************************************* APNIC is pleased to make available the following Draft "IPv6 Assignment and Allocation Policy Document" for your information. This document (http://www.apnic.net/ipv6draft.html) is the result of a collaborative effort of all the Regional Internet Registries (APNIC, ARIN and RIPE) and aims to provide a responsible, globally consistent framework for the management of IPv6 address space. IPv6 address space is a public resource and, therefore, its management involves developing policies which achieve the best possible balance of the needs of all members of the Internet community. APNIC encourages you, as a member of the Internet community, to read this document and consider its implications. We invite you to make any comments you feel would be constructive to the development of a further draft. Please note that for use within the Asia-Pacific region, APNIC would propose to adapt this document to ensure consistency with the newly-developed policy document "Policies for Address Space Management in the Asia Pacific Region", which has just been released in draft form . In such an adaptation however, the basic global principles and procedures relating to IPv6 allocation and assignment would remain as they are described here. Please address your comments to the mailing list (subscribe via majordomo@apnic.net>). If, however, you would like to make comments privately, please email Anne Lord . The deadline for comments to be considered for the next draft of the document is the 17th of February 1999. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * From owner-apnic-announce@ns.apnic.net Mon Feb 15 00:50:56 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id AAA16272; Mon, 15 Feb 1999 00:42:24 GMT Received: from gateway (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id AAA16266 for ; Mon, 15 Feb 1999 00:42:23 GMT Received: (from mail@localhost) by gateway (8.8.7/SCO5) id KAA12287 for ; Mon, 15 Feb 1999 10:42:22 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway via smap (V2.1) id xma012285; Mon, 15 Feb 99 10:42:16 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id KAA16519; Mon, 15 Feb 1999 10:42:16 +1000 (EST) Message-Id: <199902150042.KAA16519@julubu.staff.apnic.net> X-Authentication-Warning: julubu.staff.apnic.net: bc set sender to employment@apnic.net using -f From: APNIC Secretariat To: apnic-announce@apnic.net Date: Mon Feb 15 10:42:16 1999 X-Mailer: sendmail sed cat Subject: [apnic-announce] Positions Vacant at APNIC. Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] POSITIONS VACANT - ASIA PACIFIC NETWORK INFORMATION CENTRE (APNIC) Brisbane, Australia. APNIC is one of the three Internet Address Registry organisations which exist in the world today. It has responsibility for allocation of Internet resources across the Asia-Pacific. We work actively with networking organisations in this region, and with the international community of Internet organisations, on a not-for-profit basis in the service of the Internet community in the Asia-Pacific. APNIC offers a unique international working environment, attractive remuneration and travel opportunities. We are an equal opportunity employer. Asian language skills would be an advantage. Hostmasters With responsibility for evaluating applications for Internet resources, a Hostmaster needs detailed knowledge of networking fundamentals, ISP operations, and TCP/IP routing and protocols. Positions are available at junior and more senior levels. A minimum of one year's ISP or WAN networking experience is, however, desirable. Further details can be found at http://www.apnic.net/. Interested and qualified candidates should complete the application form on the web site and send it to or by post to "Positions Vacant", APNIC, PO Box 2131, Milton, Queensland, Australia. The closing date for receiving applications is Monday 15th March 1999. Interviews will be held during the week beginning Monday 22nd March 1999. -- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net * From owner-apnic-announce@ns.apnic.net Mon Feb 15 05:51:06 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id FAA02636; Mon, 15 Feb 1999 05:48:28 GMT Received: from gateway (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id FAA02632 for ; Mon, 15 Feb 1999 05:48:27 GMT Received: (from mail@localhost) by gateway (8.8.7/SCO5) id PAA22160 for ; Mon, 15 Feb 1999 15:48:26 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway via smap (V2.1) id xma022153; Mon, 15 Feb 99 15:48:25 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id PAA17189; Mon, 15 Feb 1999 15:48:25 +1000 (EST) Message-Id: <199902150548.PAA17189@julubu.staff.apnic.net> X-Authentication-Warning: julubu.staff.apnic.net: bc set sender to secretariat@apnic.net using -f From: APNIC Secretariat To: apnic-announce@apnic.net Date: Mon Feb 15 15:48:25 1999 X-Mailer: sendmail sed cat Subject: [apnic-announce] APNIC at APRICOT Sender: owner-apnic-announce@apnic.net Precedence: bulk Reply-To: apnic-talk@apnic.net [Note "reply-to:" field] APNIC at APRICOT Dear APNIC member As you know, APNIC will be holding its Annual Members' Meeting during the APRICOT week, on Saturday 6 March. All APNIC members are invited and encouraged to join us for this meeting. As you may also know, APNIC is acting as a major (Platinum) Sponsor of APRICOT this year, and we are planning a big presence throughout the whole week of APRICOT. Here is a summary of what we are currently planning. 1. APNIC Members' Meeting - see http://www.apnic.net/agenda.html for details. You have already received a number of documents relating to this meeting. All these and more will be included within your meeting kit. Registered meeting attendees should feel free to submit written questions in advance of the meeting. Questions received by Friday 27 February will be printed and included in the meeting kits and, time and agenda permitting, will be addressed formally during the meeting. You have received a message previously about EC nominations, and you are reminded to please submit these on time, along with Proxy forms (also available on the meeting web site, above). 2. APNIC Booth at APRICOT From 3 March to 5 March, APNIC will have an exhibition booth within the APRICOT exhibition area. This booth will be staffed throughout the meeting period and will provide the opportunity for you to meet APNIC staff, collect your APNIC meeting materials, and make appointments for meetings. 3. APNIC Hostmaster Clinic APNIC Hostmaster staff will be available during the APRICOT week, to discuss in detail the requirements of APNIC members for Internet resource allocations. A private meeting room will be available, and appointments can be made at the APRICOT booth between 3 and 5 March, or by email to in advance of these dates. 4. APNIC Tutorial APNIC will be conducting a one-day tutorial on Tuesday 2 March which will cover in detail APNIC policies and procedures relating to resource allocations. This tutorial is free to members, and further details are available at http://www.apnic.net/apnic-apricot.html Tutorial registrations are at http://www.apng.org/apricot99/apricot.html 5. RPSL Tutorial APNIC members are likely to be interested in the APRCIOT tutorial "Routing Policy Specification Language and Analysis Tools" on 1 March. This tutorial is being sponsored by APNIC, and is free of charge to APNIC members. Further details are available at http://www.apnic.net/apnic-apricot.html Tutorial registrations are at http://www.apng.org/apricot99/apricot.html + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + APNIC Secretariat Tel: +61-7-3367-0490 Asia Pacific Network Information Centre (APNIC) Ltd Fax: +61-7-3367-0482 Level 1, 33 Park Road, PO Box 2131, Milton, QLD 4064, Australia + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request@apnic.net *