The Chair introduced the SIG and explained the agenda.
Open action items
Xing Li, Cernet
Presentation [pdf | ppt]
Action db-16-001: Proposed "Policy for mirroring on IRR" (prop-003-v001), to be sent to the database mailing list for further discussion.
Update: Closed. Modified proposal to be presented later in the SIG.
Action db-16-002: Secretariat to implement proposal "Privacy of customer assignment records" (prop-007-v001) in three months
Update: Open. Not yet implemented. Status report to be presented later in the SIG.
Action db-16-003: Secretariat to implement proposal "Protecting resource records in APNIC Whois Database" (prop-010-v001). This will involve changing the maintainer of objects protected by MAINT-NULL to the maintainer of the parent object as well as deprecating NONE in the maintainer's auth attribute.
Update: Closed. Status report to be presented later in the SIG. Top
A proposal to protect historical records in APNIC Whois Database (prop-018-v001)
Sanjaya, APNIC
Presentation [pdf | ppt]
This proposal suggested that all historical records in the APNIC Whois Database be protected by an APNIC-HM maintainer.
Historical records form 1.5% of the records in the APNIC Whois Database. The presenter discussed the problems experienced with historical records in the APNIC Whois Database, such as abusive activities using the resources. The presenter explained that problems arise because, unlike APNIC delegated resources, historical records are not protected by an APNIC maintainer. As a result, any person can attempt to change historical records. Under the proposal, resource holders can still use the resource, but must sign a formal agreement with APNIC to maintain their records. To cover administrative costs, it was proposed that a US$100 fee apply for each maintainer. The speaker noted that the Secretariat would need seven months to implement the proposal.
Questions and discussion
- A JPNIC representative commented that it would be useful if the APNIC Secretariat could create a list of objects held by NIR members affected by the proposal and provide them to the appropriate NIR.
- There was comment that there are objects that are included in both in the JPNIC and APNIC databases. These objects represent APNIC delegated resources, not JPNIC delegated resources. A JPNIC representative requested that APNIC provide a list of those resources affected by the proposal so the JPNIC database could be updated accordingly. The APNIC Secretariat agreed to this.
- The JPNIC representative suggested that some Japanese organisations may wish to change the maintainer to a JPNIC maintainer instead of APNIC-HM. The presenter responded that this was a possible option and that JPNIC would not be charged for using the JPNIC maintainer on historical records.
- It was clarified that members of NIRs would be able to approach either the NIR or APNIC directly in relation to the management of resources affected by the proposal.
- It was noted that the proposed formal agreement to be signed by holders of historical resources proposed was separate from the APNIC membership agreement. It was also clarified that while a maintainer fee would apply, no membership fee needed to be paid. It was noted that the agreement was that part of the non-member fee structure.
- The Chair asked for a show of hands and noted consensus in favour of accepting the proposal.
Action items
- db-17-001: Pending approval at each remaining stage of the policy proposal process, proposal to protect historical records with an APNIC maintainer (prop-018-v001) to be implemented by Secretariat.
Top
A proposal of "IRR mirroring policy" (prop-003-v002)
Junichi Matsumoto, JPNIC IRR planning team
Presentation [pdf | ppt]
This proposal was a modified version of the proposal presented at APNIC 16 and proposed that IRRs implement formal mirroring policies to prevent unauthorised distribution of IRR data and to simplify the transfer of IRR data between IRRs.
The presenter summarised the issues involved in mirroring IRR data. Issues included the need for individual negotiations with multiple sources of IRR data, distribution of IRR data from one authorised mirror to other IRRs that the original source may not wish to have its data accessible to. The proposal was formed to address these problems.
Questions and discussion
- There was a comment that while the proposal was a sound model, a fundamental problem was that the RIPE and ARIN communities have a different view of the interaction between address holders and would not support the proposal. It was acknowledged that while the proposal would streamline processes, ISPs in Europe and America did not wish to adopt this kind of behaviour. It was suggested that the proposal could be adopted in the AP region, but that wider adoption would be difficult.
- It was noted that discussions at NANOG and other RIR meetings have not supported the concept behind the proposal.
- The presenter agreed that the other regions felt differently. But he noted that he had been approached by people wishing to register routing information but who did not know where to register the information so that is would be available globally.
- It was questioned why there was a need to put routing information in more than one of the existing IRRs. It was commented that while centralisation has some good features, and distributed systems can be chaotic, the Internet has shown distributed systems to be more resilient.
- There was a question why the proposer thought there was a need for a single global database. It was commented that the community have multiple IRRs set up and that the only section of routing registries that network operators wanted to know was their neighbouring networks' routing data. Previous attempts to create a global IRR, which took place approximately ten years ago, did not succeed. While the current proposal does allow for a structure that allows mirroring, it was suggested that it is missing the motivation to establish it.
- The presenter acknowledged there was a difference between local and community use of IRR data. The presenter asked SIG participants for their opinion on the usefulness of a global routing registry.
- There was a response that most people use IRR to autoconfigure filters on their routers, and that therefore, global data was not relevant. Only the routing data at the edge of their network is relevant. It was noted that data in IRR is incomplete, inaccurate, and only updated sporadically. The situation is unlikely to change any time soon, so it was questioned whether it was worth spending a lot of time creating a global IRR that would not be an accurate mirror of the routing system.
- The presenter explained that the aim of the proposal was to raise the reliability of IRR data.
- There was a comment that the proposal was addressing the desire to access IRR data from a single server, and that if there was another solution to this problem, the proposers were willing to accept it. It was noted that the proposal developed out of the discussions of the Japanese routing community, where other solutions could not be found. The SIG participants were asked for any other proposals that could solve this problem.
- There was a comment that no matter whether the IRR data is centralised or decentralised, certain networks would never register their routing data.
- The proposer was asked by a SIG participant why he was having problems accessing data from distributed servers. It was commented that there are tools that allow data to be accessed from distributed IRRs. The SIG participant commented that the Internet works because of the distributed system and that the problem with a single system is that if there is a problem, the entire system falls apart because there is no redundancy.
- It was suggested that the accuracy of the data in IRRs, rather than the distribution of the data, is the problem that needs to be addressed.
- The presenter asked attendees if they thought the concept of a global routing database was useful. There were no comments from attendees.
- The proposers requested that a decision on the proposal at the meeting be deferred and that the proposal be sent to the mailing list for further discussion.
Action items
- db-17-002: Proposal for IRR mirroring policy (prop-003-v002) to be returned to the Database mailing list for further discussion.
Top
Privacy of customer assignments status report
Sanjaya, APNIC
Presentation [pdf | ppt]
This presentation summarised the APNIC Secretariat's activities to implement action items db-16-002 and db-16-003.
Activities for db-16-003 will be completed by the end of April.
In the proposal prop-007-v001, discussed in action item db-16-002, the initial proposal included an attribute called "hidden". The presented noted that this has now been changed to be "public", and that all customer assignments will be hidden unless LIRs choose to denote the record as "public". The speaker noted that the initial projected three-month implementation period was optimistic due to technical issues, and that the expected completion is now the third quarter of 2004. A master database is being created to hold all data, and only the "public: yes" data will be available via whois.
Questions and discussion
Action items
Top
Early registration transfer project
George Michaelson, APNIC
Presentation [pdf | ppt]
This presentation summarised the issues involved in managing the records for resources allocated before the RIR system was established.
The speaker noted that AS numbers were transferred without difficulty in 2002.
One /8 was transferred from ARIN to JPNIC directly.
The RIRs have received records for entire /8s as part of the project. The more complex /8s, which have/24 records to be distributed amongst all RIRs, have been left to the later stages of the transfer.
Currently, records from 2 /8s are being transferred to the RIRs approximately every two weeks. At the end of April, the simpler part of the ERX transfer will be completed.
For the swamp space of /24s, a different process will be implemented to help each RIR manage the relevant records more effectively.
Questions and discussion
- An NIR representative requested that NIRs be notified of NIR-associated resources before the transfer date. The presenter agreed to this and suggested that the notification could help to streamline the process APNIC hostmasters use to locate the networks responsible for the records.
- It was questioned if the APNIC Secretariat had taken steps to ensure that the original dates of allocation were retained in the transfers. The presenter explained that early in the transfer, the date of transfer was used rather than the original allocation date, but that this is now being corrected. The speaker clarified that the current process was to use the original allocation date on the transferred records if a clear allocation date was available. However, if there is no allocation date available, the oldest update date was used. In the absence of allocation or update dates, the speaker acknowledged that there is a problem selecting a date to include in the record.
Top
