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

Shane Kerr:

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

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

47.4 (Wilfried Woeber) To send note to DB WG mailing list toask 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 theAddress Policy working group.

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

Leo Vegoda: the result is an Address Policy WG action point to followup 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 JointWhois. The community asked the RIPE NCC not to do any work on a JointWhois server, but focus on CRISP instead. We have done that. OtherRIRs are still interested and pursuing Joint Whois server. Because ofthat interest, the RIPE NCC wrote and published some requirements onthis. Other RIRs are not comfortable with publishing the requirementsas they are right now. I would like to leave this ongoing until wecan reach an agreement in the RIR community.

Status: ongoing

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

The issue was that the poem object was missing a technical contactfield. I have posted a proposal on the mailing list, a typo in theoriginal proposal document was thus fixed. It was suggested that anIRT maintainer attribute be added to the poem object. There was noresponse to this suggestion.

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

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

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

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

Niall O'Reilly: Glad to hear that the ERX process was tuned to addressthe feedback from the users involved. There were problems introducingname servers in the beginning because of restrictions implicitlyintroduced that we didn't know about. Several of our zones were hitby these restrictions resolving which caused us extra delays..

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

The areg draft is being finalised and moved to standards-track RFC. Aserver prototype is being developed by the RIPE NCC using the Verisignreference implementation. The initial implementation will be a proxyto the Whois database. An outreach activity to Whois client authorsis planned.

2. to lower the profile of other addresses currently in the databaseand published through whois, which were never intended for the abusefunction.

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 theanti-spam WG. We must add a distinguished attribute to the IRTobjects and the same distinguished attribute should be added to theperson: and role: objects as well because that increases theusefulness of the attribute for those who don't have an IRT object inplace. The amount of work needed to add the same attribute tomultiple object classes is probably not significantly higher. Addingabuse-c: to inet[6]num: objects is a good idea for completeness, butit 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 asoptional in inet[6]num: objects instead of tech-c:?

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

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

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

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

Niall O'Reilly: database users should not be forced to add a newobject (ie, IRT) to the database in order to publish abuse informationabout they resources. abuse-email: should be part of theperson:/role: objects. Daniel Karrenberg and Randy Bush voiced theiragreement on this.

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

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

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

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

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

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

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

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

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

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

Leo Vegoda: should the email addresses in mntner: objects besuppressed 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.

The RIPE NCC uses cookies. Some of these cookies may have been set already. More information about our cookies can be found in our privacy policy. You can accept our cookies either by clicking here or by continuing to use the site.