Skip to main content

You're viewing an archived page. It is no longer being updated.

RIPE 54

RIPE Meeting:

54

Working Group:

Database

Status:

Final

Revision Number:

2

RIPE 54 Database Working Group Minutes
Tallinn - Friday, 26 October 09:00-10:30

A. Administrative Matters

  • Scribe - Nigel Titley
  • Distribute participants list
  • Finalise agenda - Accepted
  • Approve minutes from RIPE 53 - Minutes accepted

Review of action list

[53.5 WW144]
Wait for the formal consensus of the ENUM Working Group on renaming NON-REGISTRY to OTHER (in the org object type) and then ask the RIPE NCC to make the change. [Done]

[53.4 WW144]
Alert Routing Working Group about the implications of the ASN16 to ASN32 transition on tools. [Done]

[53.3 RIPE NCC]
To make sure that if there is a "flag day" for ASN32 behaviour then the planning and introduction for this is done properly and advertised appropriately. [Done]

[53.2 RIPE NCC]
To check and point out this requirement to various software developers: including but not limited to IRRToolSet, Quagga etc. [Done, but see below]

[53.1 WW144]
Close AP50.1 (To make the country attribute on inetnum and inet6num optional and multiple) and properly reformulate it. [Done 2/1/2007]

[51.9 RIPE NCC]
To contact a subset of the spam tool writers and make sure that they are aware of the change in behaviour as required by AP51.8 [Done]

[51.8 RIPE NCC]
To properly implement database behaviour to always return irt object on address queries, if it exists. [Done, but see below]

Remote Participation

  • Jabber chat provided by RIPE NCC

B. Database Update - Jos Boumans, RIPE NCC

  • Database Team
    • Two new members of the team
  • 32-bit ASN
    • Has been done to support new numbers. FLAG day was 2 January 2007. 14 are in use currently. Quagga now supports it.
  • Query behaviour for IRT Objects
    • Changes still in process. Only 1% of inetnums are actually covered by irt objects with "abuse-mailbox:". Final change to add -c flag is backward incompatible and needs discussion.
  • CRYPT- PW: Deprecation
    • Started 30 November 2006. 3,900 initially in database. 550 conversions in two days. CRYPT-PW finally removed 22 February 2007.
  • Documentation
    • Manuals have been brought up-to-date and one new manual written. It is proposed that the manuals are not released as RIPE Documents to enable more timely release of the manuals. There was general support for this. It was also suggested that, if necessary, sections could be left as RIPE Documents. For example the User Reference Manual sections could remain as RIPE Documents.

[AP54.2 RIPE NCC + Chairs]
To check through documents and decide how to split manuals into RIPE and non-RIPE Documents.

  • Whois IPv6
    • Now fully integrated into whois.
  • Operational Update
    • Slight increase in queries but otherwise business as usual.
  • RIPE-DBM
    • Two new members of the team. See presentation for details.

It was noted (Gert Doering) that the lack of references to IRT objects are due to the lack of -c behaviour and that we should go ahead with the implementation of this by default. This action has taken considerable time and we would like to have a flag day very shortly.

[AP54.1 RIPE NCC]
To go ahead with final implementation of IRT query behaviour, within four weeks.

C. Task-Force on Data Protection Issues - Jochem de Ruig, RIPE NCC

  • First meeting 7 May in Tallinn during RIPE 54.
  • The whole thing has been made necessary by changes to EU data protection laws.
  • Proposal to ensure that every object has a maintainer.

[AP54.3 RIPE NCC]
Go ahead and investigate ensuring that all objects are maintained, including timeline and notifications. Submit proposal to the working group.

  • It may be necessary to de-automate the creation of maintainer objects.
  • An opt in 'white pages' facility within the RIPE Database for industry-related persons was suggested. Some expressions of support for this.

[AP54.4 RIPE NCC]
To investigate the provision of a 'white pages' facility for industry-related persons.

Discussion on the "country:" attribute.

  • Support was expressed for retaining the mandatory status of the "country:" field as it is valuable information. On the other hand the data is being used to generate other sets of data and hence is being processed in a data protection sense. The fact that this information is of suspect value was also raised. The issue was raised (Leo Vegoda) that the purpose of the data is unknown and undocumented and therefore the information in the database can be used to derive unwarranted and unsupported conclusions. He suggested that the relevant information be provided from the organisation object, where of course it is optional. Perhaps what we are looking for is an optional "location:" attribute. The location information is also obtainable from the ORG object and perhaps this should be mandatory. The RIPE NCC has found the "country:" attribute useful during the ERX project. We need to define better the actual required function of this attribute. It was noted that the "country:" attribute is extremely helpful for research purposes (for producing the IPv6 report for example) and this information is generally helpful for the operation of the network.

[AP54.5 DP-TF]
To analyse better the function of the country attribute in inetnum and inet6num.

D. Treatment of Orphaned Objects - Denis Walker, RIPE NCC

Originates from the data protection issue (data must be relevant to the purpose of the RIPE Database).

Steady rise in unreferenced objects. It was noted that a small number of people actually want to be in the database and that the removal notice should offer the means to remain in the database for those who want to remain in the database just so that people can remain if they wish. A work-around to retain your person object might be to create a poem object. Reuse of NIC handles caused some comment, as maintainers might use a NIC handle not understanding that they had possibly changed. It was suggested that objects should be quarantined rather than deleted.

Concern was expressed that there may be external references into the database. The issue of NIC handles shared with the ARIN database was also raised.

General consensus was that we do need to get rid of the unreferenced objects but there was no consensus.

[AP54.6 RIPE NCC]
To summarise the discussion and write up for the mailing list

Y. Input From Other Working Groups/Task Forces

Resource Certification Task Force: Iimpact on RIPE Database, if any - Nigel Titley.

  • There will probably be an effect, but this is not yet known.

DNS Working Group: Retire "rev-srv:" Attribute in inetnum - Peter Koch, DENIC

  • Summary is that this is no longer needed as it also appears in the domain object.
  • The top five maintainers account for the majority of objects mainly because this is hard-coded in their software.

[AP54.7 RIPE NCC] To prepare a plan for removal of the "rev-srv:" attribute from the inetnum, inet6num objects.

Z. A.O.B

WW144 asked if the mandate and/or the chairs of the group needed changing. There was no enthusiasm for replacing the clown at the front or of changing his mandate.