RIPE 47

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

RIPE 47 Amsterdam, Netherlands
A. Administrative Matters

- Scribe Nigel Titley (FLAG Telecom)

- List of participants - Announcements (live on net)

- Agenda Was distributed on the mailing list Additional item on
database usability (Randy Bush)

- Minutes Draft minutes accepted as true record. All presentations
can be found at: http://www.ripe.net/ripe/meetings/ripe-47/presentations/index.html#db

Outstanding Actions

[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. status: Closed

[AP-43.7 Dave Beaumont (C&W)] To produce a short report on
what would be useful regarding external references and how to
start. status: Closed

[AP-45.5 RIPE NCC] To document proposal on organisation object and
re-circulate on mailing list. status: Will be ready in 2 weeks or
so. Ongoing.

[AP-45.6 RIPE NCC] To collate responses (to organisation object)
and make a start on implementation. status: Ongoing

[AP-46.1 RIPE NCC] Send the RIR requirements for CRISP to the
database working group list. status: Closed as superceded by
presentation.

[AP-46.2 RIPE NCC] Prepare documentation on how to handle reverse
DNS for the address space transferred by ERX. status:
Notification text to ERX transferees has been improved, and
general reverse DNS will be improved. Closed.

[AP-46.3 RIPE NCC] Add reverse lookup feature for key-cert
objects. status: DONE.

[AP-46.4 RIPE NCC] Implement a tag in the database to denote that
the network range is no longer valid. status: No
progress. Closed.

[AP-46.5 Wilfried Woeber] Coordinate with RIPE NCC to prepare a
document summarizing basic assumptions about the use of the
database. status: Presentation this session by WW144. Ongoing.


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

See presentation. DB query response time is still well under a
second. Note that the increase in ipv6 is not an indication of
growth, just much delayed documentation of existing inet6nums.
Note the removal of cross notify attributes in February 2004 Note
that overlapping objects may no longer be created. Owners of
existing objects will be contacted to get them tidied up.


C. ERX (Leo V., RIPE NCC)

See presentation 29 /8s have been transferred to date. The rest
will be complete by late spring. Approx 3000 registrations to be
done after that.


D. X.509 support implementation (Shane Kerr, RIPE NCC)

See presentation This should be the last presentation in this
extended series. The RIPE NCC is ready to implement. No comments,
so this proposal has been accepted by the group.

E. CRISP/Joint-Whois status (Shane Kerr, Engin Gunduz, RIPE NCC)

See presentation CRISP/joint-whois allows for a single query to
determine information about an IP address range. This is
particularly apposite since ERX. CRISP is a new protocol to
replace whois. Joint-whois attempts to generate a short-term fix
by implementing referral-only servers (joint.<rir>.net).

Concern was expressed (Randy Bush) that joint-whois was yet
another interim solution and that focussing on CRISP might be a
better use of resources. There appeared to be some support for
this view. Operators would probably benefit less from joint-whois
than end users, who mainly want the information to complain to the
wrong place about spam. CRISP is intended to replace the whois
protocol altogether. Currently in Draft format. Will be XML
based. IRIS has been chosen as the protocol (which is XML
based). Referrals will be client-side so much more scaleable.
This implies (possibly) a central referral server, which could be
an NRO function.

It was hoped to have the drafts ready by end March. RIPE NCC may
commit resources to providing a "snapshot" CRISP server.
IRIS is scheduled for full verification in August 2004. It was
noted that the problem with CRISP may well be the availability of
the clients. However the sooner servers are up and running, the
sooner the clients will start to be developed.

It was suggested that the way forward for the CRISP standard was
for the community to comment on the draft proposals, although some
doubt was expressed that anything would come of this and that the
RIRs should be expending effort on the draft standards. [AP-47.1
RIPE NCC] Set a deadline for the commencement of work on prototype
server code, taking into account the likely availability of
standards.

F. Getting rid of auth NONE (N.N., RIPE NCC)

See presentation

General concensus seemed to be to accept this proposal (and remove
auth: NONE with no warning).


G. irt: / abuse:

- populating inet[6]nums w/ irt links, DFN, SURFnet (Ulrich
K./Marko T.)

See presentation

- documentation available (WW144 How-to, FAQ)

Useful technical HOW-TO published on setting up an IRT object and
how to link it to inet6num object. (DFN) http://www.dfn-cert.de/team/matho/irt-object/irt-object-howto.html

FAQ on what an IRT object is and how to use it. (SURFnet)

http://www.surfnetters.nl/meijer/tf-csirt/irt-object-faq.html

- abuse-c: discussion and proposal summary (MarcoH, mch2-ripe)

See presentation

The proposal was to add a new attribute "admin" to
inetnum, inet6num, mnt. This would be a single email address. It
was suggested that since the irt object already exists, that more
documentation on how to find the correct responsible person/role
for a particular IP address would be the useful thing to do.
Caution was raised about needing to liase with other WGs before
taking action.

Attention was drawn to possibly changing the response from the
database to make the irt object more easily visible. The irt
object could have an "abuse" attribute, and this would
be the most appropriate place for it. It was pointed out that
abuse encompasses more than just spam, but also includes security
aspects. The current irt object is really intended to address
this second aspect.

More "user" contact is needed. This may be addressed by
proper documentation. The issue of whther to provide multiple
contacts (with hints) for abuse, or whether to provide a single
contact, where the triage is done internally.

The multiple contact route needs careful definition, or it
becomes difficult to automate the raising of complaints. It was
pointed out that the average "user" is not at all au
fait with the workings and attributes of the DB, and this must be
addressed in some way. Concern was raised that using a
referenced object to contain the abuse attribute was too
complicated for the average user.

It was also felt that setting up an irt object was too
complicated.

[AP-47.2 Randy Bush, Niall O'Reilly] Create a short proposal on
setting up an appropriate scheme for a simple abuse contact
(either "abuse" or "abuse-c")

[AP-47.3 RIPE NCC] Write a document properly documenting the use
of the IRT object for reporting abuse.

- whois server: review of (default) behaviour & format
(WW144) Omitted as covered in other items

- how to get the other WGs involved? Spam? Routing? (WW144)
Omitted as covered in other items

H. RPSLng status and deployment (Simon L., SWITCH)

See presentation

RPSLng is usable for multiple protocols RIPE NCC offers a test
database, but there are very few (4) real aut-num objects using
the new policy attributes.

Still needs a bit of work to tidy up the syntax, and operator
input is seriously needed.

It was noted (Randy) that the operators who use tools to extract
their routing configs from the database need to be involved. It
was also noted that since changes will take place in the future
we should start to think about versioning. Please start trying
to use RPSLng. It is not too late to update the specification.


I. S/MIME support (Denis W., RIPE NCC)

See presentation

Note, use only for signing, not encryption.

J. Do we need a BCP on "Proper Use of the Registry
Database"?? (WW144)

Omitted as covered in other items.


K. Usability of the DB as a proper package

Randy has set up a small instance of the RIPE DB. He has had
problems with building the DB, and with populating the empty
database. The question is how much support the RIPE NCC should
provide to other users of the software.

The response from the RIPE NCC is that they try and limit the
amount of support that they provide, as their resources are
limited, and support is on a best effort basis only.

Concern was expressed about tardy releases of new features in the
software available on the ftp site.

Questions were raised as to how large the potential user base for
the software is? If the software was easier to use would this be
wider? And if this is so, is it the RIPE NCC's responsibility to
do this. There are no reliable estimates of how many copies are
in use, although probably 30 public registries are available

[AP-47.4 WW144] To send note to DB WG mailing list to ask how
many are using the DB software, and on what platform

Y. Input from other WGs

None noted.

Z. AOB

None

Actions from this Meeting


[AP-47.1 RIPE NCC] Set a deadline for the commencement of work on
prototype server code, taking into account the likely availability of
standards.

[AP-47.2 Randy Bush, Niall O'Reilly] Create a short proposal on
setting up an appropriate scheme for a simple abuse contact (either
"abuse" or "abuse-c")

[AP-47.3 RIPE NCC] Write a document properly documenting the use of
the IRT object for reporting abuse.

[AP-47.4 WW144] To send note to DB WG mailing list to ask how many are
using the DB software, and on what platform