From owner-apnic-talk@ns.apnic.net Tue Feb 2 07:07:53 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id HAA07586; Tue, 2 Feb 1999 07:05:57 GMT 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-talk] [apnic-announce] Database Update - v2.2.1 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Fri Feb 5 01:18:47 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id BAA04548; Fri, 5 Feb 1999 01:15:12 GMT Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id BAA04354; Fri, 5 Feb 1999 01:11:56 GMT Received: from laina (sj-dial-1-95.cisco.com [171.68.180.96]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id RAA21708; Thu, 4 Feb 1999 17:06:35 -0800 (PST) Date: Fri, 5 Feb 99 08:26:17 From: Laina Raveendran Greene Subject: [apnic-talk] APPLe@APRICOT- Paying for the pacific links To: apnic-talk@apnic.net, sg-infotel@external.cisco.com, apple , apia-members@apia.org Cc: bdooley@cix.org, lindaam@singnet.com.sg, vernon@tas.gov.sg, foojai@tas.gov.sg, bgreene@cisco.com X-PRIORITY: 3 (Normal) X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=us-ascii Sender: owner-apnic-talk@apnic.net Precedence: bulk APPLe@APRICOT (APRICOT- POLICY TRACK) RE: INTERNATIONAL INTERNET BANDWIDTH FINANCING ISP ROUNDTABLE You may be interested to note that Mr Leong Kheng Thai, Director General of the Telecommunications Authority of Singapore will a keynote speaker on the 5th March for APRICOT, and he will speak about the issue of International Internet Bandwidth Financing within APEC (Singapore is the proposing economy who brought this issue up to APEC) (Ms Esther Dyson, Chair of ICANN will the other keynote that morning, speaking on Internet Governance issues) Following his keynote, there will be an APPLe session on this issue from 10.30-12.30 which will be co-chaired by the head of the International Affairs Department of TAS (Ms Valerie D'Costa) who is also the upcoming Chair of the APEC Telecom Working Group. The session will be set up as an ISP roundtable session where we will have invited ISP representatives and the rest will be open discussion. Let me know if you are an ISP coming to APRICOT, who would like to participate or speak in this session. I will ensure you will have time to have your views heared. Given that this meeting will be held the week before the APEC meeting in Misayaki, Japan, it is hoped that we can collect as many ISP views from this region as possible for input to the APEC meeting in Misayaki. Many of you may be coming to APRICOT, BUT may not be planning to be in the APEC meeting in Misayaki. We will arrange for the session to be transcribed so that your input can be recorded and distributed. Please support this effort to have your views on this issue heared. Keep a date with us- Room 201, Suntec City, 5th March, 10.30-12.30, Singapore. For more information about APRICOT, please check www.apng.org/apricot99 and if interested in registering for this roundtable session, please send me e-mail at laina@getit.org or call Ms Margie Ong at 738 6929 in Singapore. (APPLE@APRICOT IS SPONSORED BY THE COMMERCIAL INTERNET EXCHANGE) For your further information on other APPLe@APRICOT sessions, we will be posting details on the APPLe website shortly. A brief description is as follows: 2.00- 3.30 ISP liability for Intellectual Property Rights (includes trademark and domain name issues, and copyrights) 3.30-4.00- break 4.00- 5.30 ISP liability for content (censorship, privacy, spamming, etc) Hope to see you at APPLe@APRICOT (POLICY TRACK), 5TH MARCH, SUNTEC CITY, SINGAPORE. REgards, Laina Raveendran Greene Chair/Facilitator Asia Pacific Policy and Legal (APPLe) Forum (www.apng.org/apple or www.getit.org/apple/html/apple.html) * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@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 FAA03526; Sat, 6 Feb 1999 05:29:45 GMT 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-talk] [apnic-announce] Database Update - v2.2.1 - completed Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Sun Feb 7 05:18:22 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id FAA23491; Sun, 7 Feb 1999 05:15:00 GMT Received: from biomed.nus.edu.sg (biomed.nus.edu.sg [137.132.19.125]) by ns.apnic.net (8.9.1a/8.9.1) with SMTP id FAA23474 for ; Sun, 7 Feb 1999 05:14:57 GMT Received: from pobox.org.sg (spnp46124.spnp.nus.edu.sg [137.132.46.134]) by biomed.nus.edu.sg (8.6.4/8.6.4) with ESMTP id NAA18258; Sun, 7 Feb 1999 13:14:26 +0800 Message-ID: <36BD30D9.EFF9CA69@pobox.org.sg> Date: Sun, 07 Feb 1999 14:21:13 +0800 From: Tan Tin Wee Organization: NUS X-Mailer: Mozilla 4.06 [en] (Win95; I) MIME-Version: 1.0 To: apricot-exco@apricot.net, apnic-talk@apnic.net Subject: [apnic-talk] Final Reminder for APNG Travelling Fellowship 7 Feb 99 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-apnic-talk@apnic.net Precedence: bulk Content-Transfer-Encoding: 7bit > Subject: Final Reminder for APNG Travelling Fellowship 7 Feb 99 > To: apng-all@apng.org > Reply-to: tinwee@pobox.org.sg > > This is a final reminder that the APNG Travelling Fellowship > applications will close on 7 Feb 99. > > For more information, please see > http://www.apng.org/singapore99/fellowship.html > > We have had an excellent crop of applicants. > We apologise that APNG does not have sufficient funds to go round. > As a result the selection will be fairly stringent. > > Thank you for your attention. > See you in APNG mtgs 28th Feb - 1 Mar 4 Mar 1999 > Suntec Convention Centre, Singapore > > Dr Tan Tin Wee > Chairman > APNG * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@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 FAA23061; Mon, 8 Feb 1999 05:41:06 GMT 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-talk] [apnic-announce] Call for Comments (Policies for Address Space Management) Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@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 EAA06708; Wed, 10 Feb 1999 04:51:13 GMT 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-talk] [apnic-announce] Draft IPv6 Policy Document - Call for Comments Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Wed Feb 10 11:07:30 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id LAA11247; Wed, 10 Feb 1999 11:03:41 GMT Received: from nico.telstra.net (nico.telstra.net [139.130.204.16]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id LAA11243 for ; Wed, 10 Feb 1999 11:03:39 GMT Received: from testacc (gunk.telstra.net [203.10.60.2]) by nico.telstra.net (8.8.8/8.6.10) with SMTP id WAA01367 for ; Wed, 10 Feb 1999 22:03:37 +1100 (EST) Message-Id: <4.1.19990210215044.009e9890@nico.telstra.net> X-Sender: gih@nico.telstra.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 10 Feb 1999 22:02:05 +1100 To: apnic-talk@apnic.net From: Geoff Huston Subject: [apnic-talk] Comments on Address space policy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-apnic-talk@apnic.net Precedence: bulk I note: 7.19. Transfer of address space APNIC policy does not recognise the sale or unauthorised transfer of address space and will consider all such transfers to be invalid. APNIC will require IRs holding such transfers to return them to the appropriate IR. Yet in the very next section 7.20 it notes some conditions applying to allocations when the company is sold or merged. In practice this has become a difficult issue to resolve - while the address space held by a company can be regarded as part of the assets of the company if the entire company's assets are sold in a single transaction (my understanding of the intent of 7.20), the clause in 7.19 indicates that when the address space asset is attempted to be sold independantly of the disposal of other assets of the company, then the transaction is not recognised by the APNIC registry. While I recognise that the transferability of IP addresses and the consequent interpretation of IP addresses as a tradeable assets raises many other issues, I 'd like to simply point out that the current policy as stated in this document causes equal levels of problems. The practical result of application of this policy is a continuing series of misunderstandings, disputes, legal challenges and other sources of disruption to the integrity of the address management activity and the integrity of the Internet routing space. Perhaps we may agree to look at ways to reconise the validity of the disposal of address space through sale or transfer in cases where the transaction is independant of the disposal of other corporate assets. regards, Geoff Huston * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Fri Feb 12 21:03:08 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id TAA08849; Fri, 12 Feb 1999 19:14:42 GMT Received: from mail1.cisco.com (mail1.cisco.com [171.68.225.60]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id TAA08845; Fri, 12 Feb 1999 19:14:39 GMT Received: from laina (sj-dial-5-5.cisco.com [171.68.179.198]) by mail1.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA09561; Fri, 12 Feb 1999 11:11:00 -0800 (PST) Date: Sat, 13 Feb 99 03:01:29 From: Laina Raveendran Greene Subject: [apnic-talk] Women in IT Event at APRICOT X-PRIORITY: 3 (Normal) X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-talk@apnic.net Precedence: bulk (apologies for duplicates) FYI Women in IT (WinIT) BOF@ APRICOT. Do come and support. It is open to men and women. REgards, Laina RG --- On 12 Feb 99 18:05:10 SIN Vivien@idrc.org.sg wrote: You may be aware that Internet World Asia is being held at Suntec City the first week in March. APRICOT (Asia Pacific Regional Internet Conference on Operational Technologies) is a conference being held in tandem with Internet World. The Singapore Business & Professional Women's Assocation (SBPWA), together with the Singapore Women in IT (SWIT), are involved in organizing a "Birds-of-a-Feather" Women in IT Networking Dinner to serve as a side event of APRICOT on the evening of 4th March 1999. We are recruiting a panel of distinguished speakers from the government and private sectors. Ascend Communications, Hong Kong, has kindly agreed to sponsor the event again (they sponsored last year's event in Manila). The topic for the panel discussion is "How Technology Is Empowering Professional Women". We want to hear from the leaders in the industry, as well as have audience participation on what the key issues for women in IT. Last year, about 70 women and men attended the evening and feedback was very positive. This year we are hoping to at have the same number, if not more. The announcement is on the APRICOT web site (www.apricot.net) as well as the women-connect-asia site (www.women-connect-asia.com). This is an event you shouldn't miss as it gives women a platform to discuss IT-related issues affecting their professional and personal lives. Please RSVP before 26th February by calling Tel: 338-9395 or printing out the registration off the web and faxing it back to Tel: 336-7170. It's free attendance, and open to both men and women! As we are expecting a lot of APRICOT delegates to come, please secure your seat by booking early. Best regards, Vivien Chiam email: vivien@idrc.org.sg Tel(65)8316-828 Fax (65)2351189 Business & Partnerships Development Manager International Development Research Centre (IDRC), Singapore http://www.PanAsia.org.sg; http://www.idrc.org.sg -----------------End of Original Message----------------- ------------------------------------- Don't forget to come to APRICOT'99 For more details check- www.apng.org/apricot99 Name: Laina Raveendran Greene E-mail: laina@getit.org url: www.getit.org Date: 13/02/99 Time: 03:01:29 This message was sent by Chameleon ------------------------------------- * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@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 AAA16572; Mon, 15 Feb 1999 00:48:14 GMT 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-talk] [apnic-announce] Positions Vacant at APNIC. Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@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 FAA02746; Mon, 15 Feb 1999 05:50:57 GMT 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-talk] [apnic-announce] APNIC at APRICOT Reply-To: apnic-talk@apnic.net Sender: owner-apnic-talk@apnic.net Precedence: bulk [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 * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Tue Feb 16 06:16:56 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id GAA21967; Tue, 16 Feb 1999 06:13:46 GMT Received: from gateway (guardian.apnic.net [203.37.255.100]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id GAA21962 for ; Tue, 16 Feb 1999 06:13:45 GMT Received: (from mail@localhost) by gateway (8.8.7/SCO5) id QAA02439; Tue, 16 Feb 1999 16:13:25 +1000 (EST) Received: from hadrian.staff.apnic.net(192.168.1.1) by gateway via smap (V2.1) id xma002431; Tue, 16 Feb 99 16:13:14 +1000 Received: from localhost (anne@localhost) by hadrian.staff.apnic.net (8.9.1a/8.9.1) with SMTP id GAA12647; Tue, 16 Feb 1999 06:13:14 GMT Date: Tue, 16 Feb 1999 16:13:14 +1000 (EST) From: Anne Lord X-Sender: anne@hadrian To: khurana@del2.vsnl.net.in cc: apnic-talk@ns.apnic.net Subject: [apnic-talk] Re: FW: Comments on Policies for Address Space Management in Asia Pacific Region. In-Reply-To: <014f01be58ad$892ae9b0$4701a8c0@wilson.staff.apnic.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-apnic-talk@apnic.net Precedence: bulk Dear B.R.Khurana and D.P.De, Many thanks for your comments and review of this document. I have made a few comments in the body of your email, which I hope will be useful. Please see below for details. > -----Original Message----- > From: B.R.Khurana [mailto:khurana@del2.vsnl.net.in] > Sent: Monday, 15 February 1999 16:01 > To: apnic-talk@apnic.net > Cc: pwilson@apnic.net > Subject: Comments on Policies for Address Space Management in Asia > Pacific Region. > > > Dear Sir, > > Sub: Comments on draft document ` Policies for Address Space > Management > in Asia pacific Region' > > Ref: APNIC Account Name : DOT-IN > > > The Department of Telecommunications, a Government of India > Organisation is a large registry memeber of APNIC. On the draft > "Policies for Address Space management in Asia Pacific Region " this > Department wishes to offer the following comments: > > Section 6.9 and 7.6: > -------------------- > > India is a very large country. As the Department of > Telecommunication is the organisation which builds and maintains the > entire infrastucture for the telecommunication requirements of the > country , hence such a large country needs higher initial > allocation/reservations of Address Space. An initial allocation of /19 > will cause a large number of routing tables to be introduced at a later > date in the routers. An explicit goal of APNIC policy is to promote aggregation. Whilst not guaranteeing that subsequent allocations will be contiguous, we make every effort to ensure that this happens, so that the allocations can be combined to form one aggregate announcement. While it is APNIC policy to allocate an intial /19, the size of subsequent allocations will depend on actual address space usage. If the initial allocation is consumed quickly, then subsequent allocations will be larger according to the rate of use and providing that address space management policies and procedures have been correctly followed. > Section 6.1 and 7.19 > -------------------- > > This section does not recognise the sale or unauthorised transfer of > Address Space while at the same time wants those seeking Address Space > (say Private ISPs) to request from upstream providers rather than from > APNIC directly. However, the upstream provider spends a large sum of > money in becoming member of APNIC/maintaining IP data base etc, so > naturally he will seek monetary remuneration. When an IR is allocated address space, it is expressly authorised to make assignments in accordance with the policies laid out in this document. Therefore, this section, which deals with unauthorised transfers, does not apply in the context you describe. > Comments on ipv6 (128 bit Address) > ------------------------------------- > > The availability of ipv6 is from the end of March 99 as per the > e-mail received . This should ease all our burdens and also that of > APNIC as sufficiently large chunk of IP Addresses will then be > available. The formulation and need for the Policy document and giving > only a /19 initially in the light of ipv6 is not clearly understood. > will all allocations after March 99 be in IPv4 or IPv6 or both will run > concurrently. > This document relates only to the distribution of IPv4 address space. There is a draft document referring to the distribution of IPv6 address space which you can find at : http://www.apnic.net/ipv6draft.html In answer to your question, it is anticipated that, IPv4 allocations will continue for a long time into the future. Best wishes, Anne Lord APNIC -- * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Wed Feb 17 00:23:06 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id AAA06441; Wed, 17 Feb 1999 00:22:21 GMT Received: from avccnt.avcc.edu.au (nt.avcc.edu.au.121.21.203.in-addr.arpa [203.21.121.4] (may be forged)) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id AAA06436; Wed, 17 Feb 1999 00:22:17 GMT Received: by nt.avcc.edu.au.121.21.203.in-addr.arpa with Internet Mail Service (5.5.2232.9) id <12ZX5X9W>; Wed, 17 Feb 1999 11:22:02 +1100 Message-ID: <21A218F7BF64D211950B00C04F9A2F7706EE98@nt.avcc.edu.au.121.21.203.in-addr.arpa> From: "McLaughlin, George" To: apnic-talk@apnic.net, Paul Wilson Cc: "Turner, Glen" Subject: [apnic-talk] RE: Policies for Address Space Management Date: Wed, 17 Feb 1999 11:21:56 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-apnic-talk@apnic.net Precedence: bulk Paul Please find our comments on the "Policies for Address Space Management". These comments were prepared by Glen Turner: GENERAL COMMENTS There are many minor criticisms below. These should not be taken to mean that we disagree with the broad thrust of APNIC's address allocation policy. Many of these criticisms concern special cases that we have encountered at various times. In the past APNIC has been suitabily flexible in dealing with these special cases, and suitabily inflexible when people have presented "special cases" that are actually requests for special treatment. We hope this understanding approach continues. Most of the comments refer to effects of the proposed policies when applied to large organisations. Academic and research institutions are large enterprises that use public addressing. Most business and government enterprises choose to use private addressing. However, this is driven by current security technologies. These organisations may wish to gain public address space should security technologies change. We are appreciative of the time and energy that APNIC has put into creating and documenting the address allocation policy. SPECIFIC COMMENTS 5.1.2 Registration APNIC should attempt to ensure that the directory of allocated space is only used for its intended purpose and that opportunity for misuse of the data, such as the collation of addresses for spam e-mail, is limited. APNIC should not make the entire contents of the directory available. That is, people should be able to search the directory in order to find a suitable contact for fault-finding, but they should not be able to download or view all (or a substantial part) of the database. Fields that are collected for APNIC's use and serve no public purpose should not be made available to the public. A billing address would be such a field. 6.1 Routability not guarrunteed APNIC can significantly improve the routability of address space by: a) aligning its allocation policies with those of other registries [which it currently does] b) cooperating with those registries to produce a unified set of route filtering policies for use by backbone ISPs. At the present, information on the allocation strategies used by various registries at various times is fragmented and incomplete. This makes constructing a bug-free route filtering policy difficult. 6.8 Evaluations to be based on efficient technologies This provision does not allow for address space to be assigned for experimental purposes of limited duration. Some experimentation is essential for the progress of Internet technologies. In the past, addresses uses have come from the copious addresses assigned to academic and research institutions. However, as these institutions come to use more of their traditionally-assigned address space for other purposes, then registries should be prepared to contribute addressing. 6.8 Evaluations to be based on efficient technologies Some allowance should be made for large networks. It can take upwards of a year for a single person to visit all the networking equipment at some enterprises. In such an environment there will always be a lag between the availability of a new technology and its comprehensive use in the network. 6.10 Documentation Documentation requests should not be unreasonable. An academic instituion with a 90% full class B network faces an almost impossible documentation task to gain more address space if network diagrams are requested. 7.2 Address space lease This policy allows a lease condition to be altered with notice varying from one day to one year, depending on the date of the policy change and the date of the lease expiry. A minimum time to move to lease compliance upon the change of a lease condition should be specified. A suggested minimum is one year, as this allows for any extraordinary expenses related to achieving lease compliance to be obtained from the annual budgetting process used by most large corporate, government and academic networks. 7.6 Slow start mechanism for allocations This mechanism fails for large network conversion projects. Imagine a government department migrating from SNA to IP and using public address space. Such a migration would usually occur across a public holiday, the new networking equipment having been pre-configured in the previous months. There is no way under the suggested policy for that network to gain enough address space to pre-configure the network (as the network will have zero host addresses used) and to conduct a well-planned rollout. Allowance should be made in the allocation policy for the allocation of addressing based on firm network upgrade plans. It would be reasonable for APNIC to request budgetary documents to assure itself that the request is indeed for a sure committment to use the address space at the end of the roll-out period. 7.11 Address portability encouraged A "strong technical ground" should include addresses for important name servers, such as the .AU root. This allows the country root name server to be connected to many ISPs, increasing the robustness of the network. 7.12 Renumbering to promote aggregation The class B networks historically assigned to many academic institutions are often underutilised. Encouraging the return of these addresses for a more appropiate amount of address space is to be encouraged. 7.13 Private address space Given the debates in the Internet community about the wisdom of enterprise addressing and NAT, it is surprising to see APNIC so wholeheartedly endorse the technology. Readers should be informed of the existence of literature counter to APNIC's enthusiasm so that they can make an educated decision. 7.16.2 Registering contact persons "The administrative contact *must* be someone who is physically located at the site". This makes no sense for research outposts. Ringing a scientist in Antartica to report a network fault is fruitless, sending them a letter makes even less sense. The administrative contact is this case would better be located at the ANARE headquarters in Tasmania, Australia. 7.20 Mergers, acquisitions and takeovers These policies are welcomed and appear to be reasonable for merging academic and research institutions. 8.1 Static assignments strongly discouraged "Issues of administrative convenience will not be sufficent" neatly ignores the huge cost of moving a large statically-addressed network to a dynamically-addressed network. Although most large academic institutions are moving towards dynamic addressing, it could well take another five years before the majority of hosts in some networks gain their addresses dynamically. We fully agree that all new allocations should use dymanic addressing and that old allocations should be moving towards dymanic addressing. George McLaughlin, AARNet Tel: (02)6285 8358 Fax: (02)6285 8211 Mobile: 0411 256 370 email: gmm@avcc.edu.au * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Wed Feb 17 13:21:47 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id NAA09362; Wed, 17 Feb 1999 13:17:47 GMT Received: from mail1.geko.net.au (IDENT:root@mail1.geko.net.au [203.2.239.39]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id NAA09357 for ; Wed, 17 Feb 1999 13:17:45 GMT From: tomk@koltai.com Received: from Bravo.geko.net.au (porn.geko.net.au [203.18.92.178]) by mail1.geko.net.au (8.8.7/8.8.7) with SMTP id AAA29412; Thu, 18 Feb 1999 00:17:38 +1100 Date: Wed, 17 Feb 99 22:04:09 Subject: [apnic-talk] Policies for address space management in the Asia Pacific region To: apnic-talk@apnic.net, amandaw@mail1.geko.net.au X-MAILER: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. X-PRIORITY: 3 (Normal) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-apnic-talk@apnic.net Precedence: bulk RE: http://www.apnic.net/policydraft.html I would like to direct my comments specifically to the subject of transfer of address space in the context of liquidations, mergers and acquisitions and specifically, in the context of "unauthorised transfer". 7.19. Transfer of address space APNIC policy does not recognise the sale or unauthorised transfer of address space and will consider all such transfers to be invalid. APNIC will require IRs holding such transfers to return them to the appropriate IR. 7.20. Mergers, acquisitions and takeovers of LIRs 7.20.1. Updating registration details The new entity must register any changes to its network usage and contact personnel. If the effect of a takeover, sale, or merger is that the LIR changes name, then the LIR must provide to APNIC relevant legal documentation supporting the name change. In the Proposed policy document, it appears to me that no firm rules exist for : a) determination of dispute of ownership. b) the protection of existing customers of the merged or acquired LIR. c) the automatic transfer of admin and tech contacts in the case of a forced liquidation, or unfriendly merger or acquisition. For example, in a case that is currently before the Supreme Court, an individual trading as company A granted the right to use an IP number to another company (Company B) and in fact sold all of the assets of company A to that other company (company B). He then ceased to trade company A and concentrated all his efforts on the trading of company B (which he also owned). This was confirmed by Company A by the individual registering company B as the interest in the comments section of the assigned address. Company B was then (after 24 months) liquidated by court order. Company C purchased the physical assets from company B and then entered an additional agreement with the liquidator of Company B for the remainder of the assets, inclusive of customers, debtors etc. The individual from Company A was still the admin and tech contact on all domain names, address space and customer allocations of both names and addresses. None of the registries contacted by company C would alter the admin and tech contact details. Regardless of the clear cut nature of the liquidation. Company A clearly had not utilised the allocated address space whilst company B was utilising it. In fact Company A did not attempt to utilise the diputed address space for another nine months after Company C took over the assets of Company B. Companies D, E & F were advertising the address space at the request of Company C. Registry A allowed the admin of Company A to alter in three seperate instances the details of the address space. Registry A had already informed company C that it was unable to intercede without legal opinion. Company E & F continued to advertise the address space after encounters between various legal people. Company D sometimes advertised the address space and sometimes didnt. Company A then advised all that it would commence advertising disputed address space within two weeks. Company D allowed Company A to alter the BGP advertisements of Company C. Company D then disavowed all knowledge and advised that they could not provide audit trails and pointed at Registry A's response to Company C's plaintiff cries of "foul". Company C was forced at this stage to take suit against Company A and D. The cost of said suite is far in excess of the normal value of a single "C" class. The cause of action was required due to the disputed address space being the DNS numbers utilised by several thousand dial-up users. Now as the case is currently in session, additional discussion is not possible. Geoff Hustomn commented that 7.19 and 7.20 appeared to be odds with each other, specifically in reference to legal complications. 7.21 appears to clear up the above, however, from personal experience, I can say that it doesnt. I believe that commercial rules apply. Address space is very much an asset of the business. Address space that has been utilised by an ISP for some time should be allocated to the ISP especisally when the the original Registration was on behalf of the company. The new policy appears to be rationalising allocation of IP address space to LIR's for redistribution to IR's. It then however also calls for unused or disputed address space to be handed back. I personally like the concept of an unused resource being surrendered back to the community. I do not commercially like the concept of being forced to rejustify address mapping within an organisation that has been operational for several years, nor do I like the concept of automatically handing back disputed address space. Hopefully, the courts will indicate a clear direction for the commercial handling of IP address dispute resolution. It is unfortunate that this issue has not been addressed in more detail. vis: If a G.P.O. Box is registered by a junior employee of a company, and he/she signs the Post Office identity card with his/her signature, does the ownership of the PO Box rest in his/her name or the company ? If the company then sells it's assets to another company in a forced liquidation sale, should he/she then have the right to alter the company details on the signature card to another entity. I think not. This problem unfortunately does not merely reside with address space. It relates to Domain names and intelectual property. With Domain Names, ownership is a given and the problem is not quite so severe. However, Registries have informed me that they will not alter Tech or Admin details without a Court Order. I would like to see this problem accurately addressed in this Policy Document to prevent future ambiguity. Possibly a couple of additional fields can be added: Acquisition: Liquidation/Purchase/Merger With/Without Admin Co-operation: Name of Liquidator: Name of Solicitor: This should then be sufficient to allow the change to be effected. The distressed party (ex-admin) could then challenge in court if necessary. A methodology without granting comercial title would be to allocate the exclusive 'right to use' to the IR that had been utilising the address space for a period of say eighteen months if no lease arrangement existed between the LIR and IR. In this manner, LIR's would also become more commercial about the conservation (read subnetting) of existing address space. -------------------------------------------------- Thomas P. Koltai Phone: +61-2-9261-4884 Mobile: +61-419-333331 Facimile: +61-2-9267-0230 Email: tomk@koltai.com 222 Sussex Street, Sydney NSW Australia 2000 -------------------------------------------------- * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Thu Feb 18 07:31:57 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id HAA17921; Thu, 18 Feb 1999 07:30:56 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 HAA17916 for ; Thu, 18 Feb 1999 07:30:55 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id RAA11813 for ; Thu, 18 Feb 1999 17:30:55 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway.staff.apnic.net via smap (V2.1) id xma011811; Thu, 18 Feb 99 17:30:44 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id RAA03345; Thu, 18 Feb 1999 17:30:43 +1000 (EST) Message-Id: <199902180730.RAA03345@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-talk@apnic.net Date: Thu, 18 Feb 1999 10:09:34 +1000 (EST) Reply-To: secretariat@apnic.net X-Mailer: sendmail sed cat Subject: [apnic-talk] Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) (fwd) Sender: owner-apnic-talk@apnic.net Precedence: bulk Below are comments received on the 15th Feb from the IAB on the draft "IPv6 Assignment and Allocation Policy Document". ---------- Forwarded message ---------- Dear colleagues, Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) The IAB has been looking at this draft and here are our comments (which are not confidential in any way). It's very good to see the registries working actively on this important topic. However there are two points of concern about the current version, one political and one technical. The political one is easy to fix. Referring to ICANN is contentious in this context, and referring to IANA is not contentious. So please replace all reference to ICANN by IANA. It doesn't change anything but it will reduce argument. The technical one is more tricky. Basically the draft errs too much on the side of address conservation. While it is important to be prudent and to avoid creating an IPv6 toxic waste dump, we do have a lot more freedom than with IPv4. The draft doesn't take full advantage of this, with the paradoxical effect that aggregation is harmed and unnecessary renumbering is forced. We can afford to be more generous with subTLA space and less restrictive with slow start. The detailed comments below almost all relate to this point. > > IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Thu Feb 18 07:37:08 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id HAA18422; Thu, 18 Feb 1999 07:37:00 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 HAA18418 for ; Thu, 18 Feb 1999 07:36:59 GMT Received: (from mail@localhost) by gateway.staff.apnic.net (8.8.7/SCO5) id RAA11910 for ; Thu, 18 Feb 1999 17:36:59 +1000 (EST) Received: from julubu.staff.apnic.net(192.168.1.37) by gateway.staff.apnic.net via smap (V2.1) id xma011906; Thu, 18 Feb 99 17:36:48 +1000 Received: (from bc@localhost) by julubu.staff.apnic.net (8.8.7/SCO5) id RAA03354; Thu, 18 Feb 1999 17:36:46 +1000 (EST) Message-Id: <199902180736.RAA03354@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-talk@apnic.net Date: Thu, 18 Feb 1999 10:09:34 +1000 (EST) Reply-To: secretariat@apnic.net X-Mailer: sendmail sed cat Subject: [apnic-talk] Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) (fwd) Sender: owner-apnic-talk@apnic.net Precedence: bulk Below are comments received on the 15th Feb from the IAB on the draft "IPv6 Assignment and Allocation Policy Document". The first forward attempt was truncated due to stray '.' characters in the mail. ---------- Forwarded message ---------- Dear colleagues, Re IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) The IAB has been looking at this draft and here are our comments (which are not confidential in any way). It's very good to see the registries working actively on this important topic. However there are two points of concern about the current version, one political and one technical. The political one is easy to fix. Referring to ICANN is contentious in this context, and referring to IANA is not contentious. So please replace all reference to ICANN by IANA. It doesn't change anything but it will reduce argument. The technical one is more tricky. Basically the draft errs too much on the side of address conservation. While it is important to be prudent and to avoid creating an IPv6 toxic waste dump, we do have a lot more freedom than with IPv4. The draft doesn't take full advantage of this, with the paradoxical effect that aggregation is harmed and unnecessary renumbering is forced. We can afford to be more generous with subTLA space and less restrictive with slow start. The detailed comments below almost all relate to this point. > > IPv6 ASSIGNMENT AND ALLOCATION POLICY DOCUMENT (3rd draft) > > > > ABSTRACT > > > > This document describes the registry system for the distribution of > > globally unique IPv6 address space, which follows a hierarchical > > distribution as it does with IPv4. The distribution of IPv6 address > > space is managed by the IANA (formerly IANA) and further delegated by ..space is managed by the IANA and... (it is managed by IANA and only by IANA.) .. > > This document does not describe private IPv6 address space, or anycast There is no such thing as private IPv6 address space. There are site-local and link-local IPv6 addresses defined architecturally. .. > > 2.1.1 IANA > > > > The Internet Corporation for Assigned Names and Numbers (IANA) has Remove all mention of ICANN which is a red rag to many bulls. The Authority lies with IANA. > > authority over all number spaces used in the Internet, including IPv6 > > address space. IANA allocates parts of the IPv6 address space to > > Regional Internet Registries (IRs) according to their established > > needs. > ... > > 2.2 Goals of the Internet Registry System > > > > The remainder of this document is primarily concerned with the > > management of public IPv6 address space. Every assignment of IPv6 > > addresses should be made with the following goals in mind for it is in > > the interest of the Internet community as a whole that these goals be > > pursued. It is worth noting that "conservation" and "aggregation" are > > often conflicting goals, and therefore each assignment must be > > evaluated carefully. This is IPv4 thinking. Aggregation is what matters for IPv6. Conservation is not a major goal; avoidance of profligacy is the goal, which is much weaker. Suggested rewrite of the last sentence: Each assignment must be evaluated carefully to ensure good aggregation without being profligate with address usage. > > Moreover, these goals may occasionally be in > > conflict with the interests of individual end users or ISPs. They will be in conflict. Suggested rewrite: In the case of IPv4, the necessary heavy emphasis on address conservation, and the attempt to retrofit aggregation, have combined to cause frequent conflict betwen the interests of end users and smaller ISPs with those of the network as a whole. It has also favoured the use of private address space with its unfortunate architectural side effects. IPv6 allows this conflict to be avoided in future. > > In such > > cases, careful analysis and judgement are necessary to find an > > appropriate compromise. Delete this sentence; this compromise is not needed for v6. .. > > 2.2.3 Conservation The word "Conservation" should be replaced by "Avoidance of profligacy" in the title and everywhere else. Don't misunderstand this as being against conservation: but this draft goes overboard. .. > > For purposes of a slow start of a sub-TLA, however, a first sub-TLA > > allocation would actually always be a /35 block (13 bits instead of > > 19). There is no need to slow-start sub-TLAs; in fact it makes no sense. A sub-TLA is always going to be allocated to a single operator; backbone ISPs will certainly not want to see /35 announcements - We expect they will filter anything longer than /29. Sub-TLAs should be fully allocated. (To put it another way, Sub-TLAs *are* the slow-start mechanism.) .. > > 4.1.1 Requirements for Allocating a Sub-TLA > > > > In order to meet the conservation and aggregation goals discussed > > above, only requesting organizations that meet certain requirements > > will be allocated sub-TLA space. The requirements for an initial > > allocation to an organization are different from the requirements that > > have to be met once the initial allocation has been used and > > additional address space is requested. > > > > Whereas the requirements for an initial allocation are based on > > technical considerations, all additional address space is purely based > > on the utilization of the initial allocation. In order to meet the > > aggregation goal, requests for an initial allocation of a sub-TLA have > > to be carefully evaluated. It is not necessary for every requesting > > organization to obtain sub-TLA space. The following requirements must > > be met in order to obtain an initial allocation of sub-TLA address > > space: > > > > The requesting organization's IPv6 network must be interconnected with > > the IPv6 networks of at least three other organizations that have a > > sub-TLA allocated to them, and either: > > > > -- The requesting organization must have reassigned IPv6 > > addresses received from its upstream provider or providers > > to 100 SLA customer sites with routed networks. Dial-in > > customers do not count toward the 100 IPv6 customer sites. This is far too high a bar for at least three reasons 1. nobody can meet it during the early stages of IPv6 deployment 2. there are many examples of non-profit networks, and certainly some for-profit networks, that do not achieve this scale, but must have at least a sub-TLA to avoid horrendous aggregation problems due to multihoming. This guideline definitely hurts aggregation. 3. this criterion also makes it very unlikely that metropolitan internet exchanges would qualify, yet metro exchanges are prime candidates for TLA or sub-TLA allocation (again to enable multihoming). We suggest reducing the 100 to 10. > > Customers currently using IPv4 host addresses for dial-up > > should not be assigned an NLA or an SLA, or > This seems redundant and gratuitous. > > > > -- The requesting organization must demonstrate a clear intent > > to provide IPv6 service within 3 months after receiving > > allocated address space. This must be substantiated by such > > documents as an engineering plan or deployment plan. We think 3 months is too short, even in our business. Change to 6 months. > > > > The above criterion that requires interconnection with at least three > > other sub-TLAs creates a bootstrapping problem which can be resolved > > by the following requirements that have been defined for a > > bootstrapping period: > > This seems to say that it's impossible to try to bootstrap an IPv6-only ISP. That's restraint of trade. Anyway, given your second option above (intent to provide service) why do we need the bootstrapping mechanism at all? Intent to supply service allows bootstrapping. > > The requesting organization's network must have BGP peering > > relationships with at least three other public Autonomous Systems in > > default-free zones, > > > > The requesting organization must show that it already has issued IPv4 > > address space to 100 customer sites that can meet the criteria for a > > /48 IPv6 reassignment, and 100 is too high as noted above. > > > > The requesting organization must demonstrate a clear intent to provide > > IPv6 service within 3 months after receiving allocated address space. > > This must be substantiated by such documents as an engineering plan or > > deployment plan. > > 3 months is too short as noted above. > > The first 50 requesting organizations who obtain a sub-TLA must > > fulfill either the criteria for the bootstrapping or the general > > criteria. Only 30 out of these 50 networks/organizations can be > > located in one region. After 50 sub-TLAs have been allocated, the > > bootstrap criteria will no longer apply. We suggest 100 instead of 50, and lose the regional restriction and the next paragraph. We don't need this level of prudence. .. > > > > 4.1.2 Size for Initial Allocation/Slow-Start Mechanism > > > > The initial allocation of sub-TLA space will allow 13 bits worth of > > NLA IDs to be utilized by the organization receiving the /35 reserved > > from the sub-TLA unless the requesting organization submits > > documentation to the Regional IR to justify an exception. As noted above this is a totally inappropriate restriction. We do not need to conserve addresses to this extent. Sub-TLA assignees should get the full /29. All of the following text and the notion of extending sub-TLA allocations should be simplified and reworked to remove this whole notion. > > ...This initial > > allocation allows the organization to create a hierarchy within the > > allocation depending on their customer type (ISP or end-site) and the > > topology of their own network. For example: this allows the > > organization to receive 8,192 NLAs (a /48 each). The making of > > assignments (to ISPs or end-sites) is covered in section 4.2 in more > > detail. > > > > The size of the initial allocation has been set to 13 bits because > > this allows the TLA Registry some freedom in creating an addressing > > hierarchy. If it has other Service Providers as customers (who in turn > > have their own end-user customers), this allows the TLA Registry to > > sub-allocate smaller blocks to each of them. > There is no need to do this and it hurts aggregation. This is IPv4-centric thinking. > > 4.1.3 Requirements for Next Allocation > > > > Once an organization has used 80% of the sub-TLA address space, the > > organization may contact the Regional IR in its region to request that > > another range of addresses be allocated. The size of the next range > > depends on the utilization rate of the previous allocation. The only reasonable step is from a complete sub-TLA (/29) to a shorter prefix. Here there are two models that the IETF probably needs to look at - the next step is a complete TLA (/16), or it is new form of sub-TLA somewhere betwen /16 and /29. However this is far-future and should be left for further study. Simplify all this: allocate complete sub-TLAs and leave everything beyond this for further study. Just delete most of 4.1.3 for now. .. > > > > 4.1.3.2 Renumbering This section is useful, unlike the rest of 4.1.3. However, we will not be short of subTLAs or TLAs for many years. While it is good to make all allocations temporary, there is no need to recover subTLAs within 3 months of allocating a TLA to the same operator. Some would say this recovery should not be done at all in the early years; if it is to be done, the overlap period should be much longer, say 24 months. A minimum of 12 months should be guaranteed in perpetuity. .. > > 4.2 Assignments > > > > 4.2.1 Assignments to End-users > > > > Every end-user organization receives a /48 worth of address space (80 > > bits). Out of this, 16 bits are an SLA block used for subnetting and > > another 64 bits are used per interface. All requests for additional address > > space from the same TLA Registry must be submitted to the Regional IR > > for evaluation (a second opinion). In this case the full utilization > > of the initial SLA must be documented. The need for additional address > > space must be presented in the form of an engineering plan. Since the > > SLA part of the end-user's assignment allows for creating 65,536 > > subnets, the organization must show in what way this was not > > sufficient for their network, and must present a plan showing where > > each of the 65,536 subnets is used and why new subnets are necessary. This is plain wrong. The reason we went for 16 bits was not to allow for 65k subnets. It was to allow complex corporate networks to use the SLA space as an aggregatable address space. The last sentence should be something like Since the SLA part of the end-user's assignment allows for a 16-bit aggregatable subnet addressing scheme, the organization must show why their network topology cannot be accommodated within a 16-bit addressing scheme. .. > > 4.2.2 Assignments and Allocations to Other ISPs > > > > If the TLA Registry has ISP customers (who in turn have end-users), > > the TLA Registry could use the 13 bits of NLA address space to create This should be 19 bits as noted above. > > an addressing hierarchy for them. > > Each of the TLA Registry's own > > end-users would receive a /48 as specified above, however, the ISP > > customers (NLAs) could be "allocated" additional bits in order to > > aggregate the ISP's customers internally. A slow-start mechanism will be used > > for these NLA allocations. We agree with slow-start in this context. .. > > 4.3 Reclamation Methods/Conditions > > > > Allocations are valid only as long as the original criteria are still > > met. The criteria for allocating TLA address space may change over > > time depending on routing technology. The current target is to limit > > the global routing space to roughly 8,000 entries. If 50% of this > > limit is reached, routing technology and allocation criteria will be > > reviewed. If routing technology allows additional route entries, the > > number of possible TLAs and sub-TLAs may be increased. 8000 is very modest. Who set this goal? It is also wrong; we can have about 8k TLAs and 8k sub-TLAs, so 16k is the correct value (and extremely conservative in terms of router technology). Also this section should actually say that if the 50% limit (of 16k) is reached, the routing issues will be referred to the IETF. > > If it turns out that routing technology at that time does not allow > > additional routing entries, This won't happen, and in any case why worry about it today? Leave it all TBD. .. > > 5. ORGANIZATIONS OPERATING IN MORE THAN ONE REGION > > > > If an organization requesting sub-TLA space operates in more than one > > region, and needs separate sub-TLA blocks for routing purposes, it > > should request the address space for its entire network from only one > > of the Regional IRs. It can apply for an initial allocation that is > > larger than 13 bits if it can show that its network is divided into > > several components with each needing its own sub-TLA route (each > > component individually needs to fulfill the criteria for being a TLA > > Registry). The size of the allocation would depend on how many > > top-level routes are needed. > > > > For example, if a multinational transit provider can show that it > > needs three top-level routes, it would initially receive 15 bits of > > NLA space (a /33). It could then allocate a /35 to each of the > > top-level parts of the network and route each one separately. Each of > > these sub-allocations would need to be entered in the database of the > > Regional IR individually. This doesn't compute. We don't expect to see /35 or even /33 announcements at the default-free level. The goal is aggregation at TLA and subTLA level, with nothing smaller being advertised. We'd even expect such a provider to be multihomed with several /29s. Again, we just don't have to conserve to this degree. Regards Brian Carpenter IAB Chair * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net * From owner-apnic-talk@ns.apnic.net Wed Feb 24 07:23:48 1999 Return-Path: Received: (from majordom@localhost) by ns.apnic.net (8.9.1a/8.9.1) id HAA24140; Wed, 24 Feb 1999 07:15:30 GMT Received: from singapura.singnet.com.sg (singapura.singnet.com.sg [165.21.10.10]) by ns.apnic.net (8.9.1a/8.9.1) with ESMTP id HAA24128; Wed, 24 Feb 1999 07:15:26 GMT Received: from localhost (mathias@localhost) by singapura.singnet.com.sg (8.8.5/8.7.2) with SMTP id PAA06453; Wed, 24 Feb 1999 15:14:54 +0800 (SST) Newsgroups: linux.admin.isp,alt.security.pgp Date: Wed, 24 Feb 1999 15:14:35 +0800 (SST) From: Mathias Koerber X-Sender: mathias@singapura.singnet.com.sg Reply-To: mathias@staff.singnet.com.sg Subject: [apnic-talk] ANN: PGP Keysigning Party - APRICOT99/ICANN/DNSO/AP*/SLC, Singapore, March 1-5 1999 Message-ID: X-Disclaimer: I don't speak for anyone except for myself (and to myself sometimes) Organization: SingNet MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-apnic-talk@apnic.net Precedence: bulk Content-Transfer-Encoding: QUOTED-PRINTABLE -----BEGIN PGP SIGNED MESSAGE----- [ 1. My apologies for duplicates ... ] [ 2. Bcc: used to avoid replies to the lists :-) ] [ 3. For more information on the groups and their events=20 see these fine websites:=20 =09APRICOT:=09http://www.apricot.net =09ICANN:=09=09http://www.icann.org =09Singapore Linux=20 =09 Conference: http://slc.linux.com.sg =09 =09=09and http://www.lugs.org.sg =09AP*:=09=09http://www.apng.org =09APNIC:=09=09http://www.apnic.net =09=09] [ 4. The WWW version of this announcement is at:=20 =09http://www.apng.org/apricot99/keysignbof.html ] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - APRICOT 99, Singapore, March 1-5 1999 PGP Keysigning Party As at most IETF meeting and other regular networking events with sufficient participants, we will be holding a PGP keysigning party during this March's APRICOT/ICANN/DNSO/AP*/APNIC/etc. Meetings & Singapore Linux Conference in Singapore. Quick Facts: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Key Submission: Deadline: All keys must be received in the submission email box by Wednesday, 3 March 1999, 18:00 (Singapore Time !) Submission pgp@apricot.net email address: Subject: APRICOT PGP KEY Format: Please send your key as normal ASCII text. The keys should NOT be sent as attachments or in any proprietary format (like eg MS Word etc). PGP Formats PGP 2.6 (RSA) and PGP5 (RSA and D/H) Supported Note: Keys sent to any other address or sent with a different subject may not be included in the official Apricot 99 PGP keyring! Event details: Date:=09=09Thursday, 4 March 1999 Time:=09=0918:00 - 19:30 Venue:=09Suntec City Convention City =09=09Room MR203 (Level 2) Status:=09BOF (Birds of a Feather ...) =09=09(ie *all* are welcome, as long as your key has been received =09=09on time. No APRICOT/SLC etc registration required !) Please check the APRICOT Notice board for any changes in Room and Time ! Instructions for Participants: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D 1. Who should attend =091. All people who have a PGP key =09The PGP Keysigning Party will enable you to obtain =09additional signatures (among others by noted net- =09personalities) for your PGP key. =092. All people who have just started to use PGP =09If you just started using PGP, It is unlikely that your key =09has been signed by (m)any other PGP users so far. To ensure =09that your key is trusted by the majority of the PGP users =09all over the world, you will be interested to have well- =09known net-personalities (and other people) sign your key. =093. Those who do not have a PGP key yet =09You will need to: =09=091. read up on PGP itself =09=092. create your own PGP key =09to attend the keysigning party =094. Organizations =09Many organizations use PGP to sign official announcements =09etc. Usually these organizations publish their PGP key on =09the web. As additional security, you may want your key to be =09signed by other trusted 2. Preparation =09- extract your public key using one of the following commands =09(depending on your PGP version): =09=09-UNIX PGP 2.6* $ pgp -kxa =09=09-UNIX PGP 5.* $ pgpk -xa =09=09-Win95 or other GUI Use the export function to export your =09=09 implementation key to a text file =09For more details on the PGP commands refer to the PGP manual =09- send in your PGP public key. =09(the PUBLIC KEY!!! Never give out your PRIVATE key to =09anyone!!) to the submission email address listed above. =09Please do NOT send the key as an attachment or in any other =09format but ASCII ARMORED TEXT! You could cut and paste the =09ascii armored PGP key into the email body if necessary! =09- write down (print out) your own public key's fingerprint and =09the Key ID. =09Under UNIX, you can obtain the key ID and fingerprint using these comman= ds: =09=09-UNIX PGP 2.6* $pgp -kvc =09=09-UNIX PGP 5.* $ pgpk -ll =09=09-Win95 or other GUI Check the Key Properties (in =09=09 implementation PGPkeys) =09Here is an example of a PGP key ID and fingerprint extracted =09under UNIX (PGP 5.0i): =09=09Note: This also lists the signatures on this key, but we =09=09need only the first few lines (marked with **): =09$ pgpk -ll mathias =09Type Bits KeyID Created Expires Algorithm Use ** =09sec+ 768 0x25E082BD 1995-11-15 ---------- RSA Sign & Encrypt ** =09f16 Fingerprint16 =3D 1A 8B FC D4 93 F1 9A FC BD 98 A3 1A 0E 73 01 6= 5 =09uid Mathias Koerber =09SIG 0x25E082BD 1996-08-22 Mathias Koerber =09uid Mathias Koerber =09sig 0x101E3A11 1998-02-23 Alfonso B. Carandang =09SIG 0x25E082BD 1996-06-09 Mathias Koerber =09uid mathias@singapura.singnet.com.sg =09SIG 0x25E082BD 1995-11-17 Mathias Koerber =09uid Mathias Koerber =09SIG 0x25E082BD 1995-11-16 Mathias Koerber =09uid Mathias Koerber =09sig 0x3022C951 1995-12-18 William Allen Simpson =09sig? 0x0DBF906D 1996-03-09 (Unknown signator, can't be checked) =09sig? 0x579532CD 1995-12-08 (Unknown signator, can't be checked) =09sig? 0x7B7AE5E1 1995-12-18 (Unknown signator, can't be checked) =09sig 0x76875905 1995-12-10 Angelos D. Keromytis =09sig 0x466B4289 1995-12-07 Theodore Ts'o [SIGNATURE] =09SIG 0x25E082BD 1995-11-15 Mathias Koerber =09uid Mathias Koerber =09SIG 0x25E082BD 1995-11-15 Mathias Koerber 3. At APRICOT, before the PGP keysigning Party =09- periodically check the noticeboard, where the list of keys =09submitted for the PGP keysigning party will be posted. Your =09key must be submitted by the deadline to be called during =09the keysigning party and included in the official APRICOT =09PGP keyring. If you submitted your key, and it does not =09appear on the list, please submit it again before the =09deadline! 4. At the PGP Keysigning Party itself =09- Bring along proper PHOTO identification =09For other participants to sign your PGP key (which is =09the whole aim of this event), they must be able to =09verify that the key belongs to you and that you really =09are who you claim to be. =09- if you submitted a PGP key for your organization, please =09bring along identification which proves that you are indeed =09representing that organization =B7 letter by the president/management etc on their stationery =09 =B7 namecard =09 =B7 company pass etc =09- obtain the list of submitted keys (this will be provided =09as a printout at the beginning of the party). =09- check that YOUR OWN public key is listed on the printout, =09and check its PGP KEY FINGERPRINT. Check it carefully. The =09fingerprint must match in *every* character Procedure =3D=3D=3D=3D=3D=3D=3D=3D=3D =09- During the party, we will one by one read out aloud each =09PGP key submitted including the KeyID, the attached userIDs =09(names) and the Key Fingerprint. During this the owner of =09the key will stand up to be recognized by the crowd. =09=09(We may need each key-owner to read their own Key =09=09fingerprint etc, unless we manage to rustle up a suitable =09=09Voice program to automatically read the keys) =09- During this, each participant should =09=091. check that the userid, name, keyid and fingerprint match =09=09what is printed on your printout =09=092. ensure that the person standing up acknowledges the key as =09=09=09his own =09=093. note which keys checked out ok and which ones haven't =09- After all keys have been read, you are encouraged to =09=091. verify the owners' identities by checking their supporting =09=09documents (Photo ID) =09=092. especially carefully verify the credentials for those who =09=09=09want an organization's key signed. 5. After the PGP Keysigning Party =09- obtain the official APRICOT 99 keyring from =09=09=09http://www.koerber.org/apricot99/ =09=09This will be available sometime after the keysigning =09=09party. A more detailed announement will be posted on =09=09the APRICOT Notice Board. There will be 2 keyfiles, one =09=09with only PGP2.6 keys, the other containg all (PGP2.6 =09=09and PGP5) keys =09- decide whose keys you would want to sign (using your notes =09made during the keysigning party) =09You should only sign keys if you have *very carefully* =09verified the key's integrity and the owner's supporting =09documents (passport etc). If there is any doubt as to a =09person's identity or ownership of a key, do NOT sign =09that person's key !! =09- sign these people's keys with your own PGP PRIVATE KEY, =09using your PGP software =09- export/save the signed keys into ASCII files (see the PGP =09manual) =09- either send the signed public keys to the keys owner =09(recommended) or to one of the public PGP keyservers. =09It is recommended that you send the key to the owner, =09so that they can decide themselves which signatures to =09send to the keyservers. =09- If you had presented your own key, you may want to check =09the public pgp keyservers periodically to see whether other =09participants have sent in new signatures for your own key. =09If so, you may want to obtain you own public key from the =09server and add it (actually only the additional signatures) =09to your own keyring. If another participant has sent you =09your key with a new signature, you will want to add the new =09signature to your own keyring, and then send the key to the =09public PGP keyservers. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Background =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D What is PGP? PGP (Pretty Good Privacy) is a standard (and a program implementing that standard) providing strong authentication and encryption for email (and other networking applications such as internet phone) using a public key system. Why is PGP important? From the PGP FAQ (http://www.at.pgp.net/pgpnet/pgp-faq/): =09You should encrypt your e-mail for the same reason that you =09don't write all of your correspondence on the back of a post =09card. E-mail is actually far less secure than the postal =09system. With the post office, you at least put your letter =09inside an envelope to hide it from casual snooping. Take a =09look at the header area of any e-mail message that you =09receive and you will see that it has passed through a number =09of nodes on its way to you. Every one of these nodes =09presents the opportunity for snooping. Encryption in no way =09should imply illegal activity. It is simply intended to keep =09personal thoughts personal. Xenon puts it like this: =09Crime? If you are not a politician, research scientist, =09investor, CEO, lawyer, celebrity, libertarian in a =09repressive society, investor, or person having too much fun, =09and you do not send e-mail about your private sex life, =09financial/political/legal/scientific plans, or gossip then =09maybe you don't need PGP, but at least realize that privacy =09has nothing to do with crime and is in fact what keeps the =09world from falling apart. Besides, PGP is FUN. You never had =09a secret decoder ring? Boo! =09=09 -Xenon (Copyright 1993, Xenon) What is keysigning, and why is it important? Again, see the FAQ: http://www.at.pgp.net/pgpnet/pgp-faq/faq-06.html What is a PGP Keysigning party? A PGP keysigning party is not a party in the sense of celebration. It is unlikely that alcohol will flow or hors d'oevres be passed out. As PGP uses a public key system, it usually is easy to obtain some person's public PGP key (which is required to securely converse with that person or to verify that person's authorship or identity). The usual method for this is to either ask the person directly for their PGP key. Another method is to request it from a public PGP keyserver, which is like a worldwide replicated directory of PGP public keys. More info? You can find more information on PGP at these webpages: PGP Inc.: http://www.pgp.com PGP.net: http://www.pgp.net International PGP Homepage: http://www.ifi.uio.no/pgp/ There is a PGP discussion newsgroup named comp.security.pgp and its FAQ: http://www.at.pgp.net/pgpnet/pgp-faq/ There is a book on PGP published by O'Reilly & Associates: Simson Garfinkel: PGP: Pretty Good Privacy 1st Edition December 1994 1-56592-098-8, Order Number: 0988 430 pages, $29.95 see: http://www.oreilly.com/catalog/pgp/noframes.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~ ~~ APRICOT (Asia & Pacific Rim Internet Conference on Operational Technologies= ) Singapore March 1 - 5, 1999 - -- The Annual ISP Operations and Business Summit in Asia and Pacific -- http://www.apricot.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~ ~~ * APOPS: Asia Pacific Operations Forum * * To unsubscribe: send "unsubscribe" to apops-request@apnic.net * -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQB1AgUBNtOm7VUjujkl4IK9AQFOCgL/ep5vEkJbazm1PsquwYdA7w311Mihh4Zb sH4nr/lqV39paKxm/EH6lzWiPj0HcsWkiiFg3RyQlTXDpE6qjkWvV92s3Pk5maUq 4NXZ1m8dUItLXPe2BPoevEWEe2l44qwh =3D2yet -----END PGP SIGNATURE----- * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request@apnic.net *