Skip to main content

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


RIPE Meeting:


Working Group:




Revision Number:


RIPE 44 Database Working Group Minutes

A. Administrative issues

. scribe (Tiago Antao)
. circulate list of participants
. status of minutes

B. Action Items

[AP-41.3 RIPE-NCC] Create Documentation and BCP for IRT object.
Complete. Closed.

[AP-41.4 ALL] Create IRT object and tag inetnum for all appropriate
Complete. Closed.

[AP-41.5 WW] To put together a group to put together a short guidance
document to guide reference document writers. This team to
include Ruediger.
Closed. Overtaken by events.

[AP-41.6 RIPE-NCC] Put up a mailing list for the above purpose and
advertise to the db-wg list.
Closed. Overtaken by events.

[AP-41.9 RIPE-NCC] To document the mirroring protocol and the
operational requirements of using it.
Ongoing. Some work done.

[AP-41.12 RIPE-NCC] Look at general password authentication methods.
[AP-42.3 RIPE-NCC] To investigate the issues involved in shadow
passwords and multiple level authentication schemes.
Removed. To be included in the more broader discussion of authentication.

[AP-42.4 Larry Blunk (LB)] To investigate the problems of multiple hashed
passwords and the possibilities of embedding an ID within the hash and
to submit a proposal to the working group.
A proposal came from Janos to embed such information in the remarks
Randy Bush (RB): A solution should never be done by giving semantics
to comments. We could use the RPSL revision for IPv6.
LB: A clear solution in RPSL terms would be good.

[AP43.3 RIPE NCC] Provide detailed action plan for the ERX transfer
to the WG before implementing Phase 2.
Complete. Closed.

[AP43.4 RIPE NCC] To produce a list of requirements for a list of
IP objects that will be transfered.
Complete. Closed.

[AP43.5 WW] Set up a task force to go through some ERX test cases before
Complete. Closed.

[AP-43.6 ALL] Users of IRRToolSet to send requirements and suggestions.
[AP-43.9 RIPE NCC] To try and track down some of the outdated references
to the IRRToolset out on the web and get them corrected.
Ongoing and Combined.

[AP-43.7 Ruediger Volk] To produce a short report on what would be
useful regarding external references and how to start.
[AP-43.8 RIPE NCC] To investigate how much effort would be required to
add this functionality to the RIPE DB.

C. DB Update - Shane Kerr (SK)

. Statistics
--> available online
. Operations Report
--> Performance issue with long queries solved
--> Load is doubling over year but the perceived performance maintains
--> Smaller nightly maintenance window will be implemented
. ripe-dbm user support
--> Create awareness of existing user support
--> Around 50 requests/day
. Clean up of reference by name in the database
. Developments
--> Improved query processing
--> More protection against DoS
--> Web updates in production
> No PGP support
--> IPv6 access via proxy
. Future plans
--> Improved update processing
> Better user reporting
> Less buggy input processing
--> RPSLng
> IRRToolSet
> IPv6 routing and multicast
--> Unreferenced person/role cleanup
--> Update processing semantic changes

Wilfred Woeber (WW): Regarding Cleanup of reference by name, is it possible
to get person/role information up to date?
SK: If there is interest we can pursue that, take the discussion to the
db-wg mailing list.

D. ERX - Andrei Robachevksy (AR)

. Version 2 of presentation in Rhodes
. Introduction
--> Definition of Goal: Transfer data to correct RIR regarding region
> AS transfer
> IPv4 space transfer
> DNS Reverse delegations
--> IPv4 conflicts
> ARIN only data
> ARIN and RIPE data with the same ranges but conflicting contact info
> ARIN and RIPE data with conflicting ranges
. Trial
--> First trial 1 /8 with ARIN majority
--> Another trial to be done, several /8s test other majorities

Philip Smith (PS): It was noticed on IP space analysis, a positive development.
Gert Doering (GD): A good thing.
AR: No operational impact for LIRs.
Izume (from the APNIC region): Who will manage reverse DNS delegation?
AR: It will be moved to the relevant LIR (from ARIN)
WW: Must LIRs be involved in data change?
AR: The normal procedure applies (Yes)

E. organization: object (SK)

E1. Creating an organization: object
. Solution is presented
--> Not for individuals
--> 2 new attribute types: organization and ref-notify
--> Hierarchical naming allowed
Janos Zsako (JZ): How does hierarchical naming works? What about
hierarchical extensions to person objects?
--> org: attribute available to other object types to refer to the
belonging organization.
--> Querying
> Inverse querying is possible
> More and less specific query is possible

JZ: Useful for LIR. What about having several org references?
SK: You can use an hierarchy. Multiple organizations would be like "granting"
the object.
JZ: But authentication is still via maintainer, so that problem is mitigated.
How does hierarchy work?
SK: You can have several organizations below your LIR.

E2. Not creating an organization: object
. Solution proposed
--> Use role
--> have held-by: instead of org:
--> had still ref-notify:
--> add query behavior
--> No hierarchy
--> Less explicit
--> No maintainer required
WW: Continue investigation before going ahead. What is the real purpose?
Solution might vary according the purpose.
WW: The organization: object might also be used to move some LIR information to
the database.
SK: APNIC wants organization: object.
WW: Input is requested from the audience to the mailing list.


Permitting ISP to give maintenance part of their space to costumers.
Discussion done with next point.

G. reclaim: attribute (GD)

Change the maintainer for sub-allocated, reclaim allows remove objects
available on RPSS standard.
RIPE DB doesn't implement it.
SK: Problem with RPSS, not very useful for reclaiming sub-allocated objects.
Proposed difference: if you have permissions to create then you should have
permissions to delete. Will try to implement this quickly.
WW: From a previous discussion: claim need for 2 sets of credentials for
deletion, some persons think that you need to delete 2+ credentials
SK: only mnt-by is checked.
WW: Please evaluate this.

H. Allowing "generated" attributes in updates (WW)

Some objects have generated attributes. On an update generated attributes
should not be included. This is sometimes inconvinient (eg PGP key id).
Proposal: allow the submitting of generated attributes if and only if
they are equal to the generated.

*AP 44.1 - SK* Research if its possible to solve and do it.

I. Key Certificates to person role (WW)

There is no mechanical way of relating a key-cert: object to a person:
of role: object. Current hack with comments/remarks.

Ulf Kieber (UK): Know more people with the same problem. An auth attributs can
be an inverse key if and only if it refers to a key. Not possible to remove
the object because it cannot be found (references).
WW: We want then a inverse query facility.
Larry Blunk (LB): RFC2725 has a mechanism to tie keys to person/role object.
Its not implemented. Maybe research this?

*AP 44.2 - SK* Is this the only case of needed inverse queries?
What can be done here in regard to RFC2725?

J. IPv6 and the DB (WW)

Whois access to IPv6 is available.
What else might need to be done? referral nrtm update

SK: regarding referrals: we use private address space for mapping. Some
ccTLDs deny it. We might replace the address and pass our address.
WW: This breaks the logging procedure. Different names for IPv6 connectivity.
GD: There are good reasons to go both ways.
David Kessens (DK): Separate domain for IPv4/v6 for debugging purposes.

SK: Its possible, As soon as someone asks will do it.
WW: I can be an interesting party.
*AP 3 - WW* possibility of doing nrtm client with IPv6.

AR: structural plan on the RIPE NCC to give IPv6 access to all services.

Y. Input from other WGs

Not collected


Rodney Tillotson (RT): IRT, machinery is there Its not obvious how this
will be used.
WW: We had a IRT CERT meeting, we identified: work on the web interface to
get IRT related information. Talk to the "consumer" community, educate them
to use the functionality
WW: web query interface for IRT
RT: IRT should reference a live link