RIPE 59

• content to the Chair of the working group.
• format to [email protected].

Database-WG meeting: RIPE 59 (Lisbon)
Draft Minutes V0.2

A. Administrative Matters

• Welcome
• Select scribe (Nigel Titley)
• Finalise agenda
• Agenda accepted -approval of minutes from previous WG meeting(s)
  Minutes have been circulated and
• Review of action list

AP54.3 Add MNT-by on Person/Role objects (Completed, see below)
AP54.6 Removal of Orphan objects (Ongoing)
AP54.7 Conversion of rev-srv attribute to remark (Completed, see below)
AP58.1 Check that ASUSED can support IPv6 (Ongoing)

B. Database Update (Paul Palse, RIPE NCC)

See presentation for full details.

Good news is that IPv6 queries have increased markedly. IPv6 has risen from <1% to >6%. It was noted that this is tremendously encouraging.

Still need a final review of the Database AUP.

Forward domain objects need to be finally removed and cleaned up.

Reverse delegation safeguards need to be put in to prevent sub delegations of /24s below /16s. This also affects IPv6. [RIPE NCC AP59.1]

C. Status Data Protection TaskForce (WW144, all)

This is winding down. There are still two documents to review:

1. Database AUP
2. Proxy Access Service agreement

D. Impact of removal of unreferenced contact objets

- do we need an info or "marketing" campaign?

Note that all unreferenced person, role and maintainer objects will be removed.

The process has been suspended, but will now go ahead. However the fact that this is happening needs to be more widely advertised.

[AP59.2 RIPE NCC] Make sure that a wide announcement goes out before the removal continues.

E. Usefulness of additional format(s) of DB on-line documentaion

See Shane's comments on the WG mailing list

He is suggesting that different formats for the on-line documentation would be helpful, such as HTML in various forms. PDF looks pretty but is less useful
on a day to day basis.

[AP59.3 RIPE NCC] Release the documentation in HTML form.

F. Review of Use and Security Aspects of "RIPE-NCC-RPSL-MNT" - Piotr Strzyzewski

Brought up on the mailing list.

This object is used for "protecting" non-RIPE objects but it has been pointed out
that is confers little protection as the password is published in its remarks. Should
this obect be locked to prevent it being used for protecting new objects?

No one present had any strong feelings about it. So it was agreed to acknowledge it
but that no action needs taking.

G. Key-cert Owner Search and mnt-ref, ref-nfy for Person and Role- Piotr Strzyzewski

Key Cert search

See presentation

The proposal is to allow searching of the key-cert object on the owner attribute using various match types (email, name, CN value and full value). This will need some changes
to allow partial searches and this may affect other searches.

It was thought this was possibly a good idea, but that the implications need looking at very closely before implementing, especially if allowing partial matches.

There was also concern that allowing searching on what amounts to personal data might have data protection implications.

[AP59.4 RIPE NCC] Investigate amount of effort needed to implement this
[AP59.5 Piotr S] Raise the proposal on the DB-WG mailing List
[AP59.7 RIPE NCC] Investigate the Data Protection issues of allowing such searching

Mnt-ref and ref-nfy for person and role

See presentation.

Proposal is to add a mnt-ref or ref-nfy optional attribute to person and role objects to prevent authorisation problems. This would prevent objects refering to person or role objects without authorisation. This may be accidental, malicious or just plain lazy.

RIPE NCC is aware of this but sees some problems. There are considerable operational implications which might cause proliferation of personal objects and which also might
impede law enforcement searches on the DB as information in person/role objects can easily be copied giving multiple copies of objects with the same data.

It was questioned whether this is a major problem or not. Is there any evidence that we actually have a problem? The problem is that there is no real way of extracting this information directly from the database, so we cannot actually measure this.

It was pointed out that if access to the database were solely through the portal then it is much easier to ensure that data is clean *prior* to insertion into the database. Is it perhaps time to take a step back and look at the access mechanisms to the DB? However, it was noted that still at least 75% of updates come in via email and changes
would have profound operational implications.

Cross maintainer references might be used to get a sense of the size of the problem.

[AP59.6 WW114] Refer question to NCC Services working group

• Y. Input from other WGs and TFs
  
  
  • AA-WG: regarding abusix.org proposal t.b.c.
    AA-WG has not met yet. No one from Abusix is present so it seems likely that little discussion will take place. If necessary it will be raised on the mailing list.
  • Services-WG: adding reference to sponsoring LIR for PI resources t.b.c.
    A proposal was made to link independent resources to the sponsoring LIR. Discussion will take place on the Services-WG list and will be referred to DB-WG if necessary.
  • Routing-WG
    New version of the IRR-Toolset has just been made.

Z. AOB

Nothing further raised.