RIPE 52

• content to the Chair of the working group.
• format to webmaster@ripe.net.

RIPE 52 Database WG minutes (Draft 2)

A. Administrative Matters

Scribe - Nigel Titley
List of Participants
Agenda (accepted)
Minutes
"Remote participation"

Actions

47.3 RIPE NCC Write a document properly documenting the use of the IRT
object for reporting abuse. Covered by
AP51.8. Superceded

50.1 WW144 Take proposal to make the country attribute optional and
multiple for inetnum and inet6num objects to the
mailing list. Ongoing

51.1 NT13 To watch list, fold in updates to RIPE-50 minutes and
release after 2 weeks. Discharged

51.2 RIPE NCC Check gnupgp compatibility before release of dated PGP
signing functionality. Ongoing

51.3 Peter Koch Formulate a proposal on the mailing list to deprecate
CRYPT-PW. Covered by agenda item. Discharged.

51.4 RIPE NCC Check that the mapping of contacts under IRIS is indeed
not properly supported in IRIS (admin-c and
tech-c). These attributes are actually
supported. Discharged.

51.5 RIPE NCC Check and see if there are any other missing IRIS
attributes that are needed for the RIPE community. This
should be on the whole community who should now be
checking the IRIS server. Ongoing but change ownership
to ALL.

51.6 Matt (ARIN) To find out if any of the other routing registries
have the ability to store RPSL-ng. RADB suuports,
APNIC nearly supports. Discharged.

51.7 RIPE NCC Make sure that the proposed DNS Security changes are
implemented. Discharged.

51.8 RIPE NCC To properly implement DB behaviour to always return irt:
object on address queries, if it exists. See agenda
item.

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. See agenda item.

B. DB Update (RIPE NCC)

See presentation on website. Andre gave this as Shane has left
the RIPE NCC. There are some data protection issues,
particularly of personal data. There are several thoughts for
improvement

Terms and Conditions
Protection of Personal contact data
Develop a Privacy statement
Merge the various copyright statements
Revise AUP and get agreement from members

There is no intention at the moment to suppress personal
information. Provided the use is well documented there is no
legal issue. Note that the RIPE NCC has comply with Dutch
law. As long as the procedures and documentation is accurate
and up to date there should be no problem. APNIC have had to
actually remove some ownership (commercial) data to comply
with their regional requirements.

[AP52.1 WW144] Put out a
call for a task force to help the RIPE NCC in this task.



C. ENUM Delegations (Input from DNS-WG)

Requirement to support glue records properly in order to
support ENUM properly. It is proposed to use the nserver:
attribute and slightly modify the semantics of the object. See
presentation for details.

[AP52.2 RIPE NCC] To send the proposal to the WG-DB and DNS-DB mailing
lists.

D. Proposal to retire CRYPT-PW (Peter Koch, DENIC.DE + WW144)

Discussion with wg chair and other chairs suggested a full
policy proposal (as per PDP) was not necessary, since the
proposed change is operational and not policy in the formal
sense. Dates need to be set of last day to accept new objects
and how to phase out old ones (if we do). Objects which have
multiple methods are easy. What do we do with objects which
only have CRYPT-PW?

[AP52.4 RIPE NCC] To produce statistics showing how many objects are
only protected by CRYPT-PW. It was pointed out that for
dictionary words CRYPT-MD5 isn't secure either. However
changing both at once might be over-stressing the
community. At least CRYPT-MD5 allows longer passwords. Note
that to create a maintainer object you need CRYPT-MD5 to
bootstrap it. Another option is to hide the hash, but this has
been tried before and has proved operationally difficult. Rob
B felt that this didn't need a PDP as it is just fixing a
broken tool.

[AP52.5 RIPE NCC + WW144 + Peter K] To produce a proposal with
timescales for removing CRYPT-PW and circulate to the mailing
list.

E. "51.8 RIPE NCC" (return irt: by default) revisited (RIPE NCC)

This proposal actually requires a substatantial code change so
it was proposed to come back to the WG to check first. See
presentation for details.

The initial NCC proposal was to make the -c flag would return
the irt object (if it exists) for the current object or the
nearest less specific object, and to have the -r object return
no person, role or irt objects. -rc will will return irt but
no person or role objects. Otherwise no irt object is
returned. It was suggested that the use of the -m flag would
allow an irt object for a more specific object to be returned,
but there was not a great deal of support for this view.
However it was eventually decided that the RIPE NCC web client
software would add the -c flag to default queries, but that
default direct whois behaviour would remain as it is for the
moment. After a suitable period of time, it might be possible
to make the -c behaviour the default.

[AP52.3 WW144 + NT14] To reformulate proposal and post to DB-WG
mailing list

F. Modify checks for creation of route: (input from Routing-WG)

The checks at the moment are fully compliant with the RFCs so
we should perhaps change the RFCs. It was suggested that maybe
we should be looking at the model proposed for the PKI to
allow the overall holder of a block of address space to allow
objects to be created, but that the onus finally rests on the
holder of the AS number object. It was agreed to take the
discussion to the mailing list, as there was little discussion
in the WG session.

G. DB issues when recycling AS numbers (Leo Vegoda, RIPE NCC)

See presentation.

The main problem is that data will exist in other IRR databases. The
RIPE NCC does not and cannot check them all. Because of the
cleanup work people are not handing AS numbers back. RIPE NCC
has some 35 AS numbers in quarantine at the moment. Questions
for the WG are: how important are stale references, can stale
AS numbers safely be reassigned. It was suggested that
reclamation of AS numbers was pretty low down on the list of
priorities and there was some agreement with this view from
the WG. Some discussion took place on how to find out whether
an AS number is actually in use and assigned. Rudiger V
suggested that an AS-set of all assigned numbers be published
and that this was an extremely useful, if not vital. This was
supported strongly. The issue should be discussed on the list.

H. Client software to use the Routing Registry (Ruediger V, T-Com)

Presentation on website.

IRRToolset has been around a long time, but there are
sometimes problems adapting them to local requirements. The
speaker presented a list of required software functions. He
also mentioned a list of packages that have been found and
asked the question as to whether there are any others and
suggests the creation of a website with a list of tools. It
was noted from ISC that they are making a concerted effort to
clean up IRRToolset and will make a new release.

Y. Input from other WGs

Address Policy (andreas B, denic) New tag of ASSIGNED ANYCAST
for inet[6]num. Proposal on AP website.

http://www.ripe.net/ripe/policies/proposals/2005-2.html


Z. AOB