Your IP Address is: 52.14.85.76
Tip: try using "quotes around your search phrase"
You're viewing an archived page. It is no longer being updated.
RIPE Meeting: |
55 |
Working Group: |
Database |
Status: |
Draft |
Revision Number: |
2 |
http://www.ripe.net/ripe/meetings/ripe-55/presentations/titley-action-points.pdf
[AP54.1 RIPE NCC] To go ahead with final implementation of whois IRT query behaviour (-c), within 4 weeks. Deployed on 1st August after testing.
Complete.
[AP54.2 RIPE NCC + Chairs] To check through and decide how to split the Database manuals into RIPE and non-RIPE documents. Placeholder document RIPE-419 now points to technical manual.
Complete
[AP54.3 RIPE NCC] To go ahead and investigate ensuring that all objects are maintained, including timeline and notifications. Submit proposal to the Working Group.
Discussion continues on when to implement (hopefully soon).
[AP54.4 RIPE NCC] To investigate the provision of a "white pages" facility for industry related persons.
Ongoing
[AP54.5 DP-TF] To analyse better the function of the country attribute in inetnum and inet6num. Possibly related to the restructuring of the addressing information. However still unclear. Suggested that it should be related to the ultimate point of management of the resource.
Ongoing.
[AP54.6 RIPE NCC] To summarise the discussion on orphaned objects and write up for the mailing list
Ongoing. No objection to proceding with Phase 2 and 3 and removing the objects.
[AP54.7 RIPE NCC] To prepare a plan for removal of the rev-srv attribute from the inetnum, inet6num objects.
Ongoing
http://www.ripe.net/ripe/meetings/ripe-55/presentations/boumans-db-pdate.pdf
http://www.ripe.net/ripe/meetings/ripe-55/presentations/shirasaki-high-availability.pdf
This is important in relation to a research project on anti prefix hijacking. Used RIPE whois-server as base system due to its speed and scalability.
Uses NDBCluster to provide high availability database. However current performance still not adequate. Memory and CPU upgrades should help (4 -> 8GB RAM). Will be implementing offsite redundancy soon.
Coverage is basically for Japanese prefixes at the moment but will be extended. In use by several JP ISPs at the moment to filter hijacked prefixes.
http://www.ripe.net/ripe/meetings/ripe-55/presentations/jetten-auth-num.pdf
1075 peering session, 509 unique AS:ses
Extensively peered, so aut-num object maintenance is an major overhead. Tool XIRR gives contact information, traffic and advertisement information NRTM needed in order to keep the local copy up to date.
http://www.ripe.net/ripe/meetings/ripe-55/presentations/koch-revisiting-changed.pdf
Syntax, semantics, quality of info in changed: ?
Problem with changed: attribute. If it is present (even historical copies) then no new changed: line is needed. This casts some doubt on the utility of the changed: line. It cannot be relied upon as a reliable change history of the object or even as the latest change of the object.
It is suggested that the changed: attribute should be changed: maybe by enforcing a timestamp for non-null changes. Maybe just maintain the creation and last modification dates? What about ensuring accuracy (a timestamp to say "this record was accurate on this date"). What about data protection issues on personal data?
It is possible to produce virtually any variant of this from the database. A full audit trail of object modifications is maintained within the database but is generally only produced in response to a court order.
Note that hostmasters actually use these attributes despite their dubious value.
[AP55.2 Peter K] To find out what the changed: line is used for and come up with a possible way forward.
Will need coordination with the DP-TF.
End of session.