RIPE 49

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

Agenda A. Administrative Matters

B. DB Operational Update (Shane Kerr, RIPE NCC)

C. ERX Report [196/8, 198/8] (Leo Vegoda, RIPE NCC)

D. IRRToolSet software maintenance (Shane Kerr, RIPE NCC)

E. Routing Registry Courses (Rumy Kanis, RIPE NCC)

F. CRISP Update (Shane Kerr, RIPE NCC)

G. IRT / Abuse-c roundup (Marco Hogewoning)

Y. Input from other WGs

Z. AOB

---------------------------


A. Administrative Matters

In the absence of Wilfried Woeber, Nigel Titley will chair this
session.

Scribe: Ziya (RIPE NCC)

Jabber scribe: Marco Hogewoning

Minutes from the previous WG session approved.


---------------------------

Action points:

46.5 (Wilfried Woeber) Coordinate with RIPE NCC to prepare a document
summarizing basic assumptions about the use of the database.

Status: ongoing.

47.1 (RIPE NCC ) Set a deadline for the commencement of work on
prototype server code, taking into account the likely availability
of standards.

Shane Kerr: We'll be giving a detailed presentation on CRISP
separately. Status: discharged.


47.3 (RIPE NCC) Write a document properly documenting the use of the
IRT object for reporting abuse.


Shane Kerr:

We talked to people who have actually written documents on how to use
IRT objects. The RIPE NCC looked through those documents, made sure
they're properly edited. We also posted links to documents describing
the best current practices on the RIPE NCC Database web pages.

Status: post pointers to these documents on the mailing list and then
the action item can be closed.



47.4 (Wilfried Woeber) To send note to DB WG mailing list to
ask how many are using the DB software, and on what platform. [Done,
but no response, closed]


48.1 (RIPE NCC) Raise the issue of making country: optional with the
Address Policy working group.

Shane Kerr: This happened a number of times, and a discussion took
place on 09-22-2004.

Leo Vegoda: the result is an Address Policy WG action point to follow
up on the list.

Status: closed.



48.2 (Shane Kerr) To publish the requirements on the DB WG list.

Shane Kerr: We had a presentation on RIPE 47 about CRISP and Joint
Whois. The community asked the RIPE NCC not to do any work on a Joint
Whois server, but focus on CRISP instead. We have done that. Other
RIRs are still interested and pursuing Joint Whois server. Because of
that interest, the RIPE NCC wrote and published some requirements on
this. Other RIRs are not comfortable with publishing the requirements
as they are right now. I would like to leave this ongoing until we
can reach an agreement in the RIR community.

Status: ongoing

48.3 (Nigel Titley) Proposal should be clarified and the minor issue
of tech-c in the poetic-form object clarified.

The issue was that the poem object was missing a technical contact
field. I have posted a proposal on the mailing list, a typo in the
original proposal document was thus fixed. It was suggested that an
IRT maintainer attribute be added to the poem object. There was no
response to this suggestion.

Action item: RIPE NCC to implement the poem object in the RIPE
Database. This also includes the migration of the currently existing
objects, about 140.



48.4 (Randy Bush, Niall O'Reilly) IRT abuse: To refine existing
proposal to take into account the discussion during the session and
try and achieve consensus on the mailing list.

Marco is going to give a detailed run-down on what has been happening
on the mailing list, in a later presentation.

48.5 (RIPE NCC) To implement whatever consensus is reached on the
mailing list regarding abuse contact.

Nigel Titley: There was no consensus reached yet. I propose we reach
consensus today. This action is thus discharged.


48.6 (RIPE NCC) To change DB behaviour to return IRT objects by
default.

Shane Kerr: this is ongoing.


48.7 (RIPE NCC) To make the PGP attribute optional on the IRT object.

Status: ongoing


48.8 (RIPE NCC) To raise the issue on the appropriate mailing lists
and seek advice on change of development model.

48.9 (RIPE NCC) To apply all available patches to RAToolset etc, and
to start a rewrite in ANSI C

48.8 and 48.9 will be presented separately in more detail and would
then be considered discharged


---------------------------

B. DB Operational Update (Shane Kerr, RIPE NCC)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-update.pdf)

A more detailed Database Handout has been posted at:
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-handout.pdf




C. ERX Phase 3 (Leo V., RIPE NCC)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-erx.pdf)

All AS numbers and legacy Class Bs have been migrated. Work must now
start on the class C radioactive swamp.


Niall O'Reilly: Glad to hear that the ERX process was tuned to address
the feedback from the users involved. There were problems introducing
name servers in the beginning because of restrictions implicitly
introduced that we didn't know about. Several of our zones were hit
by these restrictions resolving which caused us extra delays..

Leo Vegoda: I apologise for the delay. It was due to our making
changes in the internal procedures of the RIPE NCC which will improve
the process of similar projects in the future.


D. IRRToolSet software maintenance (Shane Kerr, RIPE NCC)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-irrtoolset-handover.pdf)

The IRRToolSet software has been handed over to the ISC for future
support and maintenance. The RIPE NCC will continue to provide client
support.


E. Routing Registry Courses (Rumy Kanis, RIPE NCC)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-rr-training.pdf)

Rumy has presented information about the Routing Registray Courses the
RIPE NCC is organising.

F. CRISP Update (Shane Kerr, RIPE NCC)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-crisp-update.pdf)

A more detailed handout on CRISP is available at:
http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-crisp-handout.pdf

The areg draft is being finalised and moved to standards-track RFC. A
server prototype is being developed by the RIPE NCC using the Verisign
reference implementation. The initial implementation will be a proxy
to the Whois database. An outreach activity to Whois client authors
is planned.


---------------------------


G. Possible Solutions for Registering Abuse Contacts: Abuse-c roundup
(Marco Hogewoning)

The Anti-spam WG asks the Database WG to take some timely action to
improve the availability of abuse contacts for IP addresses allocated
through RIPE:

1. to publish an explicit abuse contact address where possible for
every address;

2. to lower the profile of other addresses currently in the database
and published through whois, which were never intended for the abuse
function.

Proposals:

* A. modify the IRT (or other) object to include an explicit
'abuse-email' attribute and to remove the mandatory requirement for
PGP or similar authentication (or introduce a similar new object
with those properties); and

* B. modify the default behaviour of the whois interfaces to find
and present an abuse address if there is one and to suppress other
e-mail addresses.


Questions/comments

Niall O'Reilly: it is helpful that we have clear input from the
anti-spam WG. We must add a distinguished attribute to the IRT
objects and the same distinguished attribute should be added to the
person: and role: objects as well because that increases the
usefulness of the attribute for those who don't have an IRT object in
place. The amount of work needed to add the same attribute to
multiple object classes is probably not significantly higher. Adding
abuse-c: to inet[6]num: objects is a good idea for completeness, but
it would be better to take advantage of the existing aggregate points
(role:, person:) in the database.

Marco Hogewoning: wouldn't it be better to implement the attribute as
optional in inet[6]num: objects instead of tech-c:?

Niall O'Reilly: this is rather a 'completeness' thing, let's focus on
the advantage instead.

Daniel Karrenberg: isn't putting abuse-c: in inetnum: objects feature
creepism? It will create user confusion. Maybe it would be better to
implement it at the aggregation points only.

Question from Jabber: implementing the attribute in multiple ways
might be confusing for (client) tool authors. They need exactly one
way to retrieve abuse information from the database.

Niall O'Reilly: there should be a query interface (API) to the
database which hides the actual underlying database structure and
gives answers to queries for abuse information. We should promote
this 'shrink-wrapped' interface to tool writers so that they don't
have to invent multiple ways to retrieve the required information.

Niall O'Reilly: database users should not be forced to add a new
object (ie, IRT) to the database in order to publish abuse information
about they resources. abuse-email: should be part of the
person:/role: objects. Daniel Karrenberg and Randy Bush voiced their
agreement on this.

Consensus declared on proposal A (that the abuse-email: attribute
should be added to the IRT and person/role object)

Shane Kerr: I wanted to make sure we've got consensus on the proposed
modification in the server's behaviour.

Consensus declared on proposal B (that the server should suppress the
return of all email addresses by default, except the abuse-email if
present).

Niall O'Reilly: we also need to promote the new behaviour to client
tool implementers so that they can understand the change and deliver
better information to the customers of their products.

[AP49.1 RIPE NCC, ANTI-SPAM WG] To convey this new behaviour to known
contacts in the anti-spam tool writing community

Daniel Karrenberg: the WG needs a regular update on the penetration of
the abuse attribute in the DB. Also, we not only need to educate the
users about the change in the use of the database, but also put
emphasis on the importance of populating the DB with abuse records and
keeping them up to date.

[AP49.2 RIPE NCC]: give updates about the number of abuse records in
the Working Group.

Niall O'Reilly: we need to be careful when introducing and managing
these changes. There were unexpected side effects in the past when
introducing changes asked by the WG.

Shane Kerr: we are going to put together a document about how to
introduce the changes. Further discussion is going to happen on the
mailing list. We were contacted by several client authors, so we can
inform them about the changes.

[AP49.3 RIPE NCC] To produce a document detailing the programme for
introducing the changes.

Leo Vegoda: should the email addresses in mntner: objects be
suppressed as well, in addition to the int[6]num: objects?

Rüdiger Volk: email addresses should not be suppressed from domain:
objects.

Shane Kerr: the default behaviour should be changed on inet[6]num:,
route: but not on domain objects.


Consensus reached about proposals A and B.

[AP49.4 RIPE NCC] To implement the abuse-email: attribute in the irt,
person and role objects.


X. RIR Data for the IRR (Rüdiger Volk)
(http://www.ripe.net/ripe/meetings/ripe-49/presentations/ripe49-db-rir-data.pdf)

Rüdiger Volk proposed that RIRs publish relevant data using applicable
RPSL through IRR. The data would include complete list of ranges of
allocated address space, potentially including prefix lengths.

A lengthy discussion emerged but no conclusion was reached. There was
a general feeling that this was unnecessary as this data was already
available elsewhere.

The webcast archive is available at:
http://www.ripe.net/ripe/meetings/ripe-49/webcast-files/db-2.wmv

Y. Input from other WGs

No input.


Z. AOB


No other business.