The Chair introduced the meeting and explained the agenda.
- APNIC Internet Routing Registry
[Presentation]
George Michaelson, APNIC
This presentation outlined APNIC's development of the APIRR (Asia Pacific Internet Routing Registry).
Questions and discussion
There was a question about whether networks who are currently mirroring APNIC would be affected by the migration from RIPE v2 to v3. It was explained that APNIC would make sure that any external networks that would be affected would be notified of the changeover (probably in mid-2002).
It was suggested that the possible development of an AUP for using the APIRR was an interesting point that could be taken on board by other routing registries.
It was suggested that there should be a mechanism for removing stale data after a specified time to prevent inaccurate data.
There was a question about how the accuracy of the APIRR would be maintained. It was explained that networks would always have to apply a distinction between public information and private routing policies. APIRR would reflect public registered assignments, allocations, and public announcements of routing but that ISPs would always be free to implement other policy in their routing.
It was noted that there were two conflicting goals for a database: the registries are obliged to provide information in their database for troubleshooting network problems, but networks require a certain degree of privacy. It was agreed that the membership of a registry should steer the direction of this discussion.
It was noted by an ISP representative that their routing registry was easier to keep up to date as the customers had a commercial relationship with the network. However, it was noted that a regional registry held a public database and had less ability to make sure routing changes were updated regularly.
There was clarification of the NOPEER option. NOPEER does not need, use or interact with a routing registry. It is a method for ISPs to modify BGP behaviour separate from any registry declaration. It was noted that this method is on the standards track in IETF and should be seen as complementary to IRR activity.
Top
- RIPE Database: Transition to RPSL and new server features
[Presentation]
Andrei Robachevsky, RIPE NCC
This presentation outlined the transition of the RIPE database to RPSL and the functions and advantages of the new version, which include stronger security features. The presentation also outlined future developments for the database.
Questions and discussion
There was a question about the transaction model and SQL engine used. It was confirmed that the transaction model was implemented above SQL, and was not specific to any one database back-end.
It was established that training was available for all NIR hostmasters.
Top
- To assign an AS Origin field into APNIC Address Allocation Database
[Presentation]
Shuang Zhu, Xing Li, CERNET
This presentation outlined inconsistencies and issues not currently dealt with by the APNIC Whois Database, such as identification of multihomed, portable and non-portable address space and inconsistencies between object fields in the RIPE NCC and APNIC databases. The presentation suggested inserting an AS origin in the inetnum object of the APNIC Whois Database.
Questions and discussion
There was discussion about the use of terms such as portable, non-portable, PA, PI in relation to the proposal. It was suggested that while the language was important to resolve, it was not an issue related to the database.
It was noted that the presentation had stated "APNIC is the authority for routing AS origin". It was explained that this was just a suggestion, not the present situation.
It was suggested that the presentation had blurred the distinction of the functions of routing and inetnum databases. It was suggested that while it was very important that inetnum objects be correct, routing objects are known to be not always correct. It was suggested that introducing a routing field into the inetnum object may lower the reliability of the inetnum details.
In discussion about the application of secure BGP, it was noted that signed routing assertions would be more trustable than this mechanism. It was suggested that a more important issue is to ensure that people cannot hijack routing without proper authority.
There was discussion about how to tie the RIRs' role in with the routing registries. It was explained that the RIRs should provide a neutral source for queries, but could not provide an authoritative source for routing data.
Top
- UWHO Requirement process
[Presentation]
Andrew Newton, Verisign
This presentation outlined the proposal of a universal whois mechanism, including potential requirements and stakeholder needs.
Questions and discussion
There was a question about the requirements of government and legal authorities for the database as opposed to the requirements of the average user. It was explained that while legal bodies would want open access to all data, Verisign did not intend to become involved in the policies behind the project. Verisign planned to focus on the mechanisms and leave the policies for others to decide.
It was suggested that the presentation was not explicit enough about some of the differences across existing whois databases. For example, routing and address assignment registries perform a different role to DNS name registries. There were questions about the degree of convergence possible in light of these differences.
It was clarified that the universal whois would allow users to use the one interface to query all databases. It was explained that the UWHOIS would be a centralised view on decentralised whois systems.
It was agreed that the system would have to be flexible enough to cope with differing data privacy requirements in each country.
It was also explained that Verisign is also developing pilots at the present to investigate whether the tools could work.