October 2008 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 16 May '18

16 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

ANNOUNCEMENT: RIPE NCC Training Courses
by Training 30 Oct '08

30 Oct '08

[Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The DNS for LIRs Training Course This course teaches LIRs about the RIPE NCC's DNS-related services. A course outline is available at: http://www.ripe.net/training/dns/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: http://www.ripe.net/cgi-bin/trainingform.pl.cgi If you have any questions please do not hesitate to contact us at <training(a)ripe.net>. Kind regards, Rumy Kanis Training Services Manager RIPE NCC

2 2

Re: Draft minutes from RIPE 56
by Malcolm Hutty 30 Oct '08

30 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Nigel, your minutes contain the following note under "Follow-ups": "* Resource Certification Project The point was raised that the CA-TF work was a focus for actions by lawful authority to remove items from the database. Would we want to record all such actions. This is properly the domain of the DP-TF and some progress on similar topics has already been made. [AP56.1 DP-TF] To consider the action to be taken when legal authority requests the removal of data from the database, and in particular whether records of such actions should be recorded. It was noted that 2008-04 will result in more ROA data for the DB using data derived from the certification effort." http://www.ripe.net/ripe/maillists/archives/db-wg/2008/msg00027.html During the WG meeting at RIPE57 I would like to ask for an update (and since the WG clashes with the Cooperation WG I will probably have to do so via a sock-puppet). My interest isn't merely in whether such forced-deletions would be recorded, but also whether they would be announced publicly, whether the affected assignee would be informed, and indeed whether they should be done at all (and if not, what steps the NCC should take in advance to protect itself from facing legally enforceable demands. The reasons why this is an issue are more clearly minuted in the AOB section to the minutes to RIPE55, as follows: "* External object removal requests (Malcom H.) The issue here is where a legal request might arrive to remove an item from the DB. If this is likely to happen, how should the RIPE NCC respond? At present there is no law that might mandate this, but one might come along. The RIPE DB covers far more than the EU, and this could create a conflict of interest (or even a diplomatic incident). Important that all be aware that this sort of thing is being proposed by certain elements within the EU and we should perhaps think about this." There is clearly a job for the RIPE NCC communications group to make it clear to appropriate bodies what the function of the database actually is [AP55.3 RIPE NCC]. Current RIPE NCC policy on information requests is to first point to the public data, and then if more is required, then require a court order from a Dutch judge. We clearly need to discuss this, but it probably needs discussing in a wider scope but it is very important to have arguments prepared beforehand." http://www.ripe.net/ripe/maillists/archives/db-wg/2007/msg00170.html I believe this is likely to become an important policy issue if certification is a success (meaning, if people start to treat with suspicion routing announcements for address blocks for which the announcer cannot produce a RIPE-NCC-signed certificate). It strikes me that there are four strategies available to the NCC: i) cooperate cheerfully with legal requests to delete objects/revoke certificates; ii) seek to persuade legal authorities to forebear from making such requests voluntarily; iii) locate the database in a jurisdiction where such requests are predicted to be unlikely/rare; iv) reengineer the database so that it is split between competing jurisdictions, such that legal authorities in multiple jurisdictions would need to cooperate in order to compromise the database integrity effectively. The RIPE55 minutes indicate that the NCC is currently pursuing the second strategy. None of these are likely to be risk-free. I can imagine pursuing the fourth strategy would be highly politically controversial. On the other hand, I can imagine an existential political threat were the NCC ever to succumb to a request from a Dutch/European court to revoke an address block allocation (/ certificate) for a non-EU address block. I think the WG should consider carefully whether the current approach is sufficient, and how we should react if it fails. Regards, Malcolm. - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkFxrwACgkQJiK3ugcyKhTVJACgkkWkugFNkbWINAz2/4unFrcN q2oAn0QvFt9X3sGHAW5kki2DZJxZF1Z5 =maMo -----END PGP SIGNATURE-----

1 1

Outage Report for RIPE Database Updates
by Agoston Horvath 28 Oct '08

28 Oct '08

[Apologies for duplicate mails] Dear Colleagues, Between approximately 20:05 - 23:14 (UTC) on Monday, 27 October 2008, we experienced an outage in our RIPE Database updates service. During this period, it was not possible to connect to the syncupdates or webupdates services. During the outage, all the messages received by auto-dbm(a)ripe.net were stored on our mail server. If you sent an email update to the RIPE Database during the outage, you will have already received an acknowledgment. There is no need to re-send any update messages. We apologise for any inconvenience that this may have caused. Regards, Agoston Horvath Database Group RIPE NCC

1 0

2008-09 New Policy Proposal (ASPLAIN Format for the Registration of 4-byte ASNs)
by Filiz Yilmaz 28 Oct '08

28 Oct '08

PDP Number: 2008-09 ASPLAIN Format for the Registration of 4-byte ASNs Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-09.html We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 17 November 2008. Regards Filiz Yilmaz RIPE NCC Policy Development Officer

12 14

irt-nfy field
by Andre Koopal 20 Oct '08

20 Oct '08

Hi, After getting some abuse complaints again on the wrong address, I noticed that with a whois without options that the irc-nfy: field is not suppressed. Seems to me that this was an oversight in the implementation of not showing any e-mail addresses except for abuse-mailbox by default. Can this be fixed? Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - European O&T Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands VNET: 711 6990 tel : +31 (0)20 711 6990 fax : +31 (0)20 711 2519 Verizon Business - global capability. personal accountability. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Verizon Nederland B.V. - H.J.E. Wenckebachweg 123, 1096 AM, Amsterdam, the Netherlands - Commercial Register No. 34199467

1 0

Fwd: [routing-wg]Representation of four byte AS numbers.
by Wilfried Woeber, UniVie/ACOnet 19 Oct '08

19 Oct '08

Dear DB-WG partcipants, please have a look at the message below. This issue is expected to appear on our "plate" pretty soon, either in Dubai or during the subsequent RIPE meeting. In particualr I'd suggest you have a look at the URL poinitng to the proposal write-up in the APNIC region, regarding the whois/DB behaviour. Bestregards, Wilfried. -------- Original Message -------- Subject: [routing-wg]Representation of four byte AS numbers. Date: Sun, 19 Oct 2008 10:47:56 +0100 From: Rob Evans <rhe(a)nosc.ja.net> To: routing-wg(a)ripe.net Hi all, At some point in the coming week I expect to see a new policy proposal hit the policy-announce and address-policy mailing lists that we might want to be aware of here. In past working group sessions we've already discussed the benefits and disadvantages of the various methods of representing 32 bit ASNs (i.e. 'asplain,' 'asdot'). There is now an internet-draft recommending asplain (which is just a single 32 bit integer) in last call at the IETF which can be obtained from the following URL: http://www.ietf.org/internet-drafts/draft-ietf-idr-as-representation-01.txt A related policy proposal reached consensus at the last APNIC meeting and is now in last call there: http://www.apnic.net/policy/proposals/prop-065-v001.html Whilst we already have a presentation on experiences of using a 32 bit ASN scheduled for the Routing working group session, the policy is being discussed in the Address Policy working group. At the moment it will be presented during the session just before lunch on Tuesday morning. At the same time there will also be a presentation on the proposal for certification of PA resources, which you may also be interested in. All the best, Rob

1 0

Deleting unreferenced PERSON objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, We announced at RIPE 56 that the RIPE NCC would soon start to delete unreferenced PERSON and ROLE objects. This will begin in late November 2008. There are some people involved in the Internet industry who do not directly manage Internet resources but who have PERSON objects in the RIPE Database. If you fall into this category and you believe your PERSON object should not be deleted, you have the option to join the RIPE Database White Pages. This will prevent your PERSON object from being deleted. For further details, please see this web page: http://www.ripe.net/db/support/white-pages-instructions.pdf Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Maintaining DOMAIN objects
by Denis Walker 16 Oct '08

16 Oct '08

[Apologies for duplicate emails] Dear Colleagues, The RIPE Data Protection Task Force advised the RIPE NCC that all objects in the RIPE Database should be maintained. Maintaining Routing Policy Specification Language (RPSL) objects in the RIPE Database was optional for PERSON, ROLE and DOMAIN objects. All the DOMAIN objects in the RIPE Database are now maintained and protected. As there may have been a possibility to exploit this data if any advance warning had been made, the RIPE NCC did not publicly announce that it was going to add maintainers to unmaintained DOMAIN objects before doing so. For further details of what was done, please see this web page: http://www.ripe.net/db/support/security/domain/syntax.html Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

RIPE57 DB-WG Draft Agenda V1
by Wilfried Woeber, UniVie/ACOnet 16 Oct '08

16 Oct '08

Dear DB-WG folks, Chairpersons, "Meeting"! This is the (very rough) 1st draft of an agenda for the DB-WG at RIPE57 in Dubai, October 2008. For time slot allocations please refer to the most up-to-date meeting plan at http://www.ripe.net/ripe/meetings/ripe-57/meeting-plan.html Attention please: this time the DB-WG meeting is again scheduled for th last day of the meeting, *Thursday* at 9 AM in the morning! Please note that, for our convenience, the time slot map becomes clickable for those sessions which have already submitted a (draft) agenda! This time Nigel Titley will manage the meeting as I can't be in Dubai. Best regards, Wilfried. ________________________________________________________________________ A. Administrative Matters . Welcome . select scribe . finalise agenda . approval of minutes from RIPE 56 . review of action list B. Data Base Update (Jos I. B., RIPE NCC) C. Follow-Up/Closure of Task-Force on Data Protection Issues (N.N., RIPE NCC) Y. Input from other WGs and TFs . ASN32 . DNS [t.b.c.] Z. AOB ________________________________________________________________________

1 0