March 2012 - db-wg - mailman.ripe.net

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

17 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

RIPE NCC Training Courses April-June 2012 - IL, BE, IS, PL, RU, FI, NL, DE, ES, HR
by Training Mailbox 08 Oct '12

08 Oct '12

Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Tel Aviv, Brussels, Reykjavik, Belfast, Gdansk, Yekaterinburg, Helsinki, Amsterdam, Munich, Seville and Croatia. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - IPv6 for LIRs Training Course - Routing Registry Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 4

Draft Minutes RIPE 63
by Nigel Titley 20 Mar '12

20 Mar '12

Folks, It looks to me as though I didn't send out the minutes for the DB-WG last November. Apologies for this. Please find them attached. Nigel

1 0

RIPE Database Access Control
by Denis Walker 09 Mar '12

09 Mar '12

Dear Colleagues As part of the redevelopment project for the RIPE Database, we re-implemented the Access Control List (ACL) mechanism. We simplified the process and have some questions to ask the community. 1/ Should we change the default query behaviour so personal data must be explicitly requested? 2/ Should we block access to personal data only and still allow access to operational data? 3/ Should there be more transparency of limits with some user options? More details about the new ACL and these three questions are provided below. As the RIPE NCC continues to progress with the redevelopment project, we will have more of these questions. The wider the community feedback on these questions, the easier it will be for us to build a RIPE Database service that satisfies your needs. Regards, Denis Walker Business Analyst RIPE NCC Database Group Overview of new ACL To make it very easy to understand what is happening, we have redefined the algorithm for blocking and unblocking. Now, when you hit a set limit for accessing personal data sets within a day, you will be temporarily blocked from accessing the RIPE Database. This temporary block will be removed at midnight (UTC). If you are temporarily blocked 10 times in a rolling 30 day period, you will be permanently blocked. A permanent block can only be removed by contacting Customer Services at <ripe-dbm(a)ripe.net> and discussing the situation. This is, in principle, the same as the current behaviour but with simplified time periods and reset points. Background to questions 1/ The current default behaviour on any query is to always return personal data referenced in any other data that is returned by the query. This is one of the main causes for temporary blocking of access to the RIPE Database. Personal data is often returned when it was not needed. To prevent the personal data being accounted, a query must include the '-r' option. Many users think an option like '-T INETNUM' will only return the INETNUM objects and no personal data will be involved. Unfortunately, '-T' is not a true query option. It is a filter. So the personal data is still queried and then filtered out of the results set. This causes the personal data to still be accounted for as if you had received it. We would like to suggest reversing the default query behaviour. This way no personal data will be returned unless you include a new query flag explicitly requesting it. 2/ The current blocking mechanism works on the basis of all or nothing. If you are not blocked, you can successfully query for any data in the RIPE Database. If you are blocked (either temporarily or permanently), any query from you is rejected with a "Denied access" error message. We would like to propose a middle road. Blocking can be set to only apply to personal data. So, after being blocked, you can still query for any operational data in the RIPE Database. But all personal data will be filtered out of the results set, even if you explicitly request it. If the community likes this idea, a further choice is possible. One option is to apply this middle road to both temporary and permanent blocks. Another is to only apply this to temporary blocks and keep a permanent block as a complete "Denied access" error. 3/ A final question regards information about the limits. In the past, details of limits and when they were reset were not clearly published in any document. But it is not difficult to determine them with a little trial and error. Perhaps the community would prefer complete transparency on this. We can publish all the limits in a revised Acceptable Use Policy (AUP) document and even provide a query option to let a user know how much of their daily limit they have already used.

6 8

Forward DOMAIN Object Cleanup and Syntax Changes
by Denis Walker 08 Mar '12

08 Mar '12

[Apologies for duplicate emails] Dear colleagues, At RIPE 57, the RIPE NCC was asked to remove all forward domain data from the RIPE Database. The last two ccTLD operators' data was removed today, 31 January 2011. The RIPE NCC can now confirm the completion of action point AP57.2 from the RIPE Database Working Group. At RIPE 62, the RIPE NCC was asked to look at the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data, we no longer see any use case for the "mnt-lower:" attribute. Other attributes that it has been suggested were used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed at the bottom of this email show how many of these attributes have been added to ENUM and reverse delegation DOMAIN objects. It has also been suggested that the "nserver:" optional attribute could be made a "required" attribute in reverse delegation DOMAIN objects. It could remain optional in ENUM DOMAIN objects or it could be disallowed. The RIPE NCC asked the community in July 2011 if anyone saw any justification for the use of these attributes in ENUM or reverse delegation DOMAIN objects. We did not receive any feedback on this. If there is no justification, the syntax of the DOMAIN object can be adjusted to deprecate these attributes. Then all current DOMAIN objects in the RIPE Database can be "cleaned" to remove this data. Business rules can be added to make the "nserver:" attribute required or disallowed in different types of DOMAIN objects, if this is considered useful. To keep the discussion focused, please send any comments or feedback to the DNS Working Group mailing list. Regards, Denis Walker Business Analyst RIPE NCC Database Group Statistics (as at July 2011) ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2,219 unique maintainers = 140 "mnt-lower:" = 46,485 unique maintainers = 4,208

9 11