- db-wg - mailman.ripe.net

Cross registry authentication BOF - rough notes
by Nigel Titley 13 May '15

13 May '15

Please find the rough notes that I took during this BOF attached Nigel

3 2

Minutes of DB-WG for the RIPE 69 meeting
by Nigel Titley 11 May '15

11 May '15

Folks I'm a bit late in sending these minutes out, for which I apologise. Please rapidly get any comments back to me. Thanks Nigel

1 0

[training] RIPE NCC Training Courses July-September 2015
by Training Services 11 May '15

11 May '15

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 Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, Amsterdam. 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 - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: https://www.ripe.net/support/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Proposal to clean up historical "abuse-mailbox:" attributes
by denis 09 May '15

09 May '15

2 4

[training] RIPE NCC Training Courses July-September 2015
by Training Services 08 May '15

08 May '15

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 Frankfurt, London, Skopje, Stockholm, Minsk, Sarajevo, Vladivostok, Tel Aviv, Tallinn, Zurich, Paris, Amsterdam. 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 - Database Training Course - Basic IPv6 Training Course - 2 day Advanced Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager

1 0

Re: [db-wg] db-wg Digest, Vol 44, Issue 7
by denis walker 08 May '15

08 May '15

Hi Piotr Just to be clear, you refer to free text attributes. This has a specific meaning in terms of database syntax checks. It applies to those attributes where no syntax checks are done, for example "address:", "descr:", "remarks:". Is your proposal only referring to these attributes? I trust you do not mean all attributes other than primary keys. Incidentally, although "person:", "role:" and "org-name:" are not primary keys, they are not free text either. Currently there are syntax checks done on these values. If you allow these in UTF8 then all these syntax checks will have to be dropped. cheersdenisindependent netizen Date: Fri, 17 Apr 2015 12:18:04 +0200 From: Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> To: db-wg(a)ripe.net Subject: [db-wg] Proposal to allow UTF8 Message-ID: <20150417101804.GD7031(a)hydra.ck.polsl.pl> Content-Type: text/plain; charset=utf-8 Dear DB-WG Members Proposal: I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Description: RIPE NCC service region covers Europe, the Middle East and parts of Central Asia. Moreover we have users from outside of this region. This means that WHOIS DB stores data for people and organizations from number of different countries using number of different alphabets. At this moment, all data in the RIPE WHOIS DB have to be stored using 7-bit plain US ASCII character set. [As a side note: It is technically possible to store some UTF8 content in some attributes, but the answer to whois query (both terminal and web based) returns "?" character in this case.] Lack of the full support for national character sets leads to some problems which includes, but is not limited to: 1. Mistakes in person/organization names due to national->english and english->national (based mostly on guess) conversion. 2. Mistakes in person/organization address due to national->english and english->national (based mostly on guess) conversion. 3. Conflict of converted words with other correct words (most visible in latin-based character sets). 4. Possible offensive word formation due to national->english conversion of names and/or addresses of person/organization. [As a side note to points no 1-3: This could lead to some problems when LEA tries to find out precisely who should be contacted in case of abuse.] On the other side, community members needs to know who is responsible for certain resource without the necessity of understanding all the others character sets. Moreover, some objects are filled with data that has to be provided in ASCII character set due to business rules (like ORGANISATION object details for LIRs). RIPE NCC has a policy to insist on latin based names for organisation objects that it verifies (allocated, and sponsored end-user space). Taking this into accout I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed at least with AA-WG and AP-WG. 2. UTF8 may cause problems for client code. Comment: The proper implementation plan and announcements schedule should be prepared. 3. UTF8 may result in contact addresses and names that are not readable by a large part of the community. Comment: Primary keys (mostly names) still have to be in ASCII character set. Moreover, LIRs data are also in ASCII character set due to business rules. 4. At this moment there are no major technical issues blocking UTF8 support in the RIPE DB back-end. However thorough checks have to be done. Looking for your comments. Piotr -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski(a)polsl.pl

4 7

Database release 1.79 deployed to RC environment
by Tim Bruijnzeels 07 May '15

07 May '15

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.79 to the Release Candidate (RC) environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… <https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir…> This release introduces the new attributes "created:" and "last-modified:" as part of the first phase of the deprecating the changed attribute in the RIPE Database. You can find more information about the three phases of this effort here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… <https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-…> It should be noted however that: = The new attributes will only be enabled in output this Thursday 2 April (because updating all objects with initial values takes a long time) = We have found that we needed to use the 1970-01-01T00:00:00Z instead of 0000-00-00T00:00:00Z (because it's invalid, and we observed inconsistencies in dealing with year 0 AD different libraries) We will update the referenced article shortly to reflect these changes. This release also changes attribute "referral-by" from mandatory to optional. This attribute is part of a mntner object for historical reasons and will be deprecated. Detailed release notes are published here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79 <https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.79> Documentation for this release is published here: https://www.ripe.net/data-tools/support/documentation/ripe-database-documen… <https://www.ripe.net/data-tools/support/documentation/ripe-database-documen…> Please let us know if you find any issues with this release. We plan to deploy this release to the production environment on Tuesday 28 April, and we plan to enable the new "created:" and "last-modified:" attributes the following Monday 4 May - after the initial values have been added for all objects. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

5 12

Re: [db-wg] Proposal regarding Orphaned Objects
by denis walker 07 May '15

07 May '15

HI Shane is correct. This functionality already exists and allows resource holders of resources allocated or assigned by the RIPE NCC to delete any operational object within their address space. Note that this functionality does not apply to any objects containing personal or contact details. Also it only applies to resource objects where the RIPE NCC has a contractual relationship with the resource holder (or their sponsoring organisation) for that resource. Just to add a caveat regarding orphaned objects, just because an object has not been updated in a very long time does not make it orphaned, even if the original maintainers are unresponsive. cheersdenisindependent netizen Date: Fri, 1 May 2015 09:02:23 +0000 From: Shane Kerr <shane(a)time-travellers.org> To: William Sylvester <william.sylvester(a)addrex.net> Cc: db-wg(a)ripe.net Subject: Re: [db-wg] Proposal regarding Orphaned Objects Message-ID: <20150501090223.0427845f(a)vulcan.home.time-travellers.org> Content-Type: text/plain; charset=US-ASCII William, On Tue, 28 Apr 2015 14:32:33 -0400 William Sylvester <william.sylvester(a)addrex.net> wrote: > Currently, when a number block holder wishes to update their number > block they are unable to do so directly. They must contact the > maintainer of the old object. Many of the older maintainers do not > have current contact or have been acquired by another company and > left in an unknown orphaned status. These maintainers can be > difficult or impossible to contact. RIPE NCC then must be engaged to > make the change to an object the number block holder should have had > online access to manage directly in the first place. As I understand it, the database allows the maintainer of less-specific ("parent") inetnum or inet6num objects to delete more-specific ("child") objects. So, the recipient of either an allocation or assignment from the RIPE NCC already has the power to clean up their space. I believe this sort of delete functionality also applies to route and related domain (meaning reverse DNS) objects. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… As I understand it, your proposal has already been implemented, with the difference that maintainers can only delete, not modify objects that they do not directly maintain but are in their space. Cheers, -- Shane End of db-wg Digest, Vol 45, Issue 1 ************************************

7 15

public password issues
by denis walker 04 May '15

04 May '15

Hi All There was a lot of talk about the MNTNER with a public password during the last RIPE Meeting. Everyone agreed that something needs to be done, but there has been little discussion since. I have written an article on RIPE Labs summarising a few of the issues and added some thoughts about them. I hope it will be useful for the discussions at RIPE 70. https://labs.ripe.net/Members/den_is/security-and-trust-in-the-internet-rou… cheersDenis WalkerIndependent Netizen

1 0

Proposal regarding Orphaned Objects
by William Sylvester 01 May '15

01 May '15

Dear Database Working Group Members, There are many old records that have become orphaned. Examples of orphaned objects might include a routing or reverse dns object that exist in the database but are not currently maintained by an active maintainer. Many of these records have not been updated in a very long time. This proposal intends to enable number block holders to have a greater ability to manage their own resources. Currently, when a number block holder wishes to update their number block they are unable to do so directly. They must contact the maintainer of the old object. Many of the older maintainers do not have current contact or have been acquired by another company and left in an unknown orphaned status. These maintainers can be difficult or impossible to contact. RIPE NCC then must be engaged to make the change to an object the number block holder should have had online access to manage directly in the first place. I propose that the maintainer of a number block shall have full control over the contacts, routing, and reverse dns entries related to the number block held. In the event an object currently has a maintainer different than the holder of the number block the maintainer of the number block will be provided an upper maintainer status with rights to manage or delete associated blocks. The number block maintainer will have an ability to delete a related object through the LIR Portal, Webupdates, and related systems. At the inception of this policy the database should be updated to identify objects without a maintainer chain to the number block holder. Any identified objects should have the maintainer of the number block added as an upper maintainer to the related blocks. When a maintainer is removed from the number block, this maintainer should also be removed as an upper maintainer of the object this should work in a similar fashion when a maintainer is added to the number block. The upper maintainer will have an ability to remove the relationship between a number block and associated contacts, routing, and reverse dns objects. Open items to discuss; 1) What is the best mechanism to enable the association of existing objects and does it make sense to have the inetnum object be the central object? 2) What objects should be included? Should any be excluded? 3) What is the right hierarchy for the objects? 4) What is a reasonable schedule for announcements and implementation? Thank you for your consideration and I look forward to your comments. Billy William Sylvester william.sylvester(a)addrex.net <mailto:william.sylvester@addrex.net>

2 2

RIPE 70 DB-WG agenda V2
by Piotr Strzyzewski 29 Apr '15

29 Apr '15

Dear DB-WG Members This is the 2nd draft of an agenda for the DB-WG Meeting at RIPE70 at the Hotel Okura in Amsterdam, Netherlands. This version include new proposal made by William Sylvester. The DB-WG Meeting is scheduled as usual for Thursday, May 14th, starting at 16:00 local time, after the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 70 meeting plan please refer to its most up-to-date version at https://ripe70.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Amsterdam. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Data Base Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~20 min] (proposed, test, deployment) . referral-by deprecation - where are we now? - what are next steps (timeline) . from "changed:" to "last-modified:" / "created:" - where are we now? - what are next steps (timeline) . RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute . restrict usage of RIPE-NCC-RPSL-MNT . new MNTNER - RIPE-NCC-LEGACY-MNT . other aspects D. Personalised authentication (Tim Bruijnzeels, RIPE NCC) [~10 min] E. New proposals (Piotr Strzyżewski) [~10 min] . UTF-8 in the DB . same INET(6)NUM objects with different status . cleanup some hacks with status values . make phone number optional in person objects F. Orphaned Objects (William Sylvester) [~5 min] G. Using RPKI for signing RPSL objects (Robert Kisteleki, RIPE NCC) [~5 min] H. "source: field for non RIPE address space" (Job Snijders) [~10 min] I. continue promotion of the the new Afrinic RR (Job Snijders) [~5 min] Y. Input from other Working Groups and/or Task Forces . Cross-registry Authentication for IRR Data BoF (Job Snijders) [~10 min] Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] Proposal to allow UTF8
by George Michaelson 23 Apr '15

23 Apr '15

its only my opinion, but I believe one of the primary uses of whois these days is Law Enforcement Agencies (LEA), and since overwhelmingly this is done by MLAP processes, the primary path is the ->local<- law enforcement people. (MLAP is when the overseas LEA asks the national LEA in question to do something on their behalf. its MultiLateral Legal Assistance Programme) Whilst in local language is a barrier to entry for outsiders, I think for the effective and real maintenance of current information, it would possibly be a huge win. -For this community at least. Other consumers of the WHOIS could feel differently about it. -George On 23 April 2015 at 15:27, Tim Bruijnzeels <tim(a)ripe.net> wrote: > Hi WG, > > >> On 17 Apr 2015, at 12:18, Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> wrote: >> >> Dear DB-WG Members >> >> Proposal: >> >> I propose to allow UTF8 in all free text attributes of all DB objects >> except in primary keys. >> >> Description: >> >> RIPE NCC service region covers Europe, the Middle East and parts of >> Central Asia. Moreover we have users from outside of this region. This >> means that WHOIS DB stores data for people and organizations from number >> of different countries using number of different alphabets. >> >> At this moment, all data in the RIPE WHOIS DB have to be stored using >> 7-bit plain US ASCII character set. >> >> [As a side note: It is technically possible to store some UTF8 content >> in some attributes, but the answer to whois query (both terminal and web >> based) returns "?" character in this case.] > > Technically it's Latin-1 at the moment, so it's a bit more than US ASCII, but does not include e.g. cyrillic. > >> >> Lack of the full support for national character sets leads to some >> problems which includes, but is not limited to: >> >> 1. Mistakes in person/organization names due to national->english and >> english->national (based mostly on guess) conversion. >> 2. Mistakes in person/organization address due to national->english and >> english->national (based mostly on guess) conversion. >> 3. Conflict of converted words with other correct words (most visible in >> latin-based character sets). >> 4. Possible offensive word formation due to national->english >> conversion of names and/or addresses of person/organization. >> >> [As a side note to points no 1-3: This could lead to some problems when >> LEA tries to find out precisely who should be contacted in case of >> abuse.] >> >> On the other side, community members needs to know who is responsible >> for certain resource without the necessity of understanding all the >> others character sets. Moreover, some objects are filled with data that >> has to be provided in ASCII character set due to business rules (like >> ORGANISATION object details for LIRs). RIPE NCC has a policy to insist >> on latin based names for organisation objects that it verifies >> (allocated, and sponsored end-user space). >> >> Taking this into accout I propose to allow UTF8 in all free text >> attributes of all DB objects except in primary keys. >> >> Some possible issues to be addressed: >> >> 1. When this proposal will be supported by the DB-WG, then it has to be >> discussed at least with AA-WG and AP-WG. > >> >> Lack of the full support for national character sets leads to some >> problems which includes, but is not limited to: >> >> 1. Mistakes in person/organization names due to national->english and >> english->national (based mostly on guess) conversion. >> 2. Mistakes in person/organization address due to national->english and >> english->national (based mostly on guess) conversion. >> 3. Conflict of converted words with other correct words (most visible in >> latin-based character sets). >> 4. Possible offensive word formation due to national->english >> conversion of names and/or addresses of person/organization. >> >> [As a side note to points no 1-3: This could lead to some problems when >> LEA tries to find out precisely who should be contacted in case of >> abuse.] >> >> On the other side, community members needs to know who is responsible >> for certain resource without the necessity of understanding all the >> others character sets. Moreover, some objects are filled with data that >> has to be provided in ASCII character set due to business rules (like >> ORGANISATION object details for LIRs). RIPE NCC has a policy to insist >> on latin based names for organisation objects that it verifies >> (allocated, and sponsored end-user space). >> >> Taking this into accout I propose to allow UTF8 in all free text >> attributes of all DB objects except in primary keys. >> >> Some possible issues to be addressed: >> >> 1. When this proposal will be supported by the DB-WG, then it has to be >> discussed at least with AA-WG and AP-WG. > > Yes, also from RIPE NCC's perspective it's important that this is done before any final technical decision is made here. > > >> 2. UTF8 may cause problems for client code. >> >> Comment: The proper implementation plan and announcements schedule >> should be prepared. > > Ack. We will probably get a number of support requests because of this, but provided that we have a clear mandate from the community (including AA-WG and AP-WG), we can address this with an implementation plan, announcements and RC. > >> >> 3. UTF8 may result in contact addresses and names that are not readable >> by a large part of the community. > > This is why the AA-WG and AP-WG should be in the loop. The main concern is what users expect from the content of the registry with regards to abuse or contact related information for resources. > > Arguments can be made for both cases (accurate representation of names vs a representation that is more easily recognisable by most users). As far as we are concerned we are impartial in this, but need a clear community mandate on the way forward. > >> Comment: Primary keys (mostly names) still have to be in ASCII character >> set. Moreover, LIRs data are also in ASCII character set due to business >> rules. > > At least with regards to resources allocated or assigned through the RIPE NCC (possibly through a sponsoring LIR) our current interpretation of related policies is that latin-1 is expected. I.e. people can deal with some variations on basic ascii, but nothing too exotic. Another concern is that it is not feasible for us to accurately verify names in all possible non-latin character sets, and of course it's very important to our function as a registry that this is done properly. > > That said we can also apply this to the specific information that is verified by the RIPE NCC, such as names and addresses for organisations, even if the database technically allows UTF-8 in other places: e.g. person names or names for organisations not associated with resources that the RIPE NCC allocated or assigned. > > >> 4. At this moment there are no major technical issues blocking UTF8 >> support in the RIPE DB back-end. However thorough checks have to be >> done. > > Agreed. There is no technical showstopper from our perspective. > > Kind regards, > > Tim Bruijnzeels > > Assistant Manager Software Engineering > RIPE NCC > >> >> Looking for your comments. >> >> Piotr >> >> -- >> gucio -> Piotr Strzyżewski >> E-mail: Piotr.Strzyzewski(a)polsl.pl >> > >

2 1

Proposal to allow UTF8
by Piotr Strzyzewski 23 Apr '15

23 Apr '15

Dear DB-WG Members Proposal: I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Description: RIPE NCC service region covers Europe, the Middle East and parts of Central Asia. Moreover we have users from outside of this region. This means that WHOIS DB stores data for people and organizations from number of different countries using number of different alphabets. At this moment, all data in the RIPE WHOIS DB have to be stored using 7-bit plain US ASCII character set. [As a side note: It is technically possible to store some UTF8 content in some attributes, but the answer to whois query (both terminal and web based) returns "?" character in this case.] Lack of the full support for national character sets leads to some problems which includes, but is not limited to: 1. Mistakes in person/organization names due to national->english and english->national (based mostly on guess) conversion. 2. Mistakes in person/organization address due to national->english and english->national (based mostly on guess) conversion. 3. Conflict of converted words with other correct words (most visible in latin-based character sets). 4. Possible offensive word formation due to national->english conversion of names and/or addresses of person/organization. [As a side note to points no 1-3: This could lead to some problems when LEA tries to find out precisely who should be contacted in case of abuse.] On the other side, community members needs to know who is responsible for certain resource without the necessity of understanding all the others character sets. Moreover, some objects are filled with data that has to be provided in ASCII character set due to business rules (like ORGANISATION object details for LIRs). RIPE NCC has a policy to insist on latin based names for organisation objects that it verifies (allocated, and sponsored end-user space). Taking this into accout I propose to allow UTF8 in all free text attributes of all DB objects except in primary keys. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed at least with AA-WG and AP-WG. 2. UTF8 may cause problems for client code. Comment: The proper implementation plan and announcements schedule should be prepared. 3. UTF8 may result in contact addresses and names that are not readable by a large part of the community. Comment: Primary keys (mostly names) still have to be in ASCII character set. Moreover, LIRs data are also in ASCII character set due to business rules. 4. At this moment there are no major technical issues blocking UTF8 support in the RIPE DB back-end. However thorough checks have to be done. Looking for your comments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

7 6

RIPE 70 DB-WG agenda V1
by Piotr Strzyzewski 21 Apr '15

21 Apr '15

Dear DB-WG Members This is the 1st draft of an agenda for the DB-WG Meeting at RIPE70 at the Hotel Okura in Amsterdam, Netherlands. The DB-WG Meeting is scheduled as usual for Thursday, May 14th, starting at 16:00 local time, after the coffee break. The length of our timeslot is 90 minutes. For the overall RIPE 70 meeting plan please refer to its most up-to-date version at https://ripe70.ripe.net/programme/meeting-plan/ Please feel free to comment agenda items or propose additional topics to be discussed both on the mailing list or direct to the WG Chairs at db-wg-chairs(a)ripe.net Looking forward to see you all in Amsterdam. All the best, Job, Nigel & Piotr ________________________________________________________________________ A. Administrative Matters [~5 min] . Welcome . select scribe (thanks to Nigel for volunteering again!) . finalise agenda . approval of minutes from previous WG meeting(s) . review of action list (Nigel Titley) B. Data Base Operational Update (Tim Bruijnzeels, RIPE NCC) [~10 min] C. New DB-Software functionality (Tim Bruijnzeels, RIPE NCC) [~25 min] (proposed, test, deployment) . referral-by deprecation - where are we now? - what are next steps (timeline) . from "changed:" to "last-modified:" / "created:" - where are we now? - what are next steps (timeline) . RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute . restrict usage of RIPE-NCC-RPSL-MNT . new MNTNER - RIPE-NCC-LEGACY-MNT . other aspects D. Personalised authentication (Tim Bruijnzeels, RIPE NCC) [~10 min] E. New proposals (Piotr Strzyżewski) [~10 min] . UTF-8 in the DB . same INET(6)NUM objects with different status . cleanup some hacks with status values . make phone number optional in person objects F. Using RPKI for signing RPSL objects (Robert Kisteleki, RIPE NCC) [~5 min] G. "source: field for non RIPE address space" (Job Snijders) [~10 min] H. continue promotion of the the new Afrinic RR (Job Snijders) [~5 min] Y. Input from other Working Groups and/or Task Forces . Cross-registry Authentication for IRR Data BoF (Job Snijders) [~10 min] Z. AOB __________________________________________ -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Proposal to accept same INET(6)NUM objects with different status
by Piotr Strzyzewski 19 Apr '15

19 Apr '15

Dear DB-WG Members Proposal: I propose to allow two INET(6)NUM objects with the same value of inet(6)num attribute and different status to be put into the DB. Problem description: According to current DB/business rules it is impossible to put into the database two INET(6)NUM objects with the same value of inet(6)num attribute and different status. This situation is quite problematic when an LIR which receive /22 from the last /8 cannot put this exact /22 with "ASSIGNED PA" status into the DB (this will result with en error). The current practice is way from being ideal - one have to divide this /22 to at least two smaller assignments. This problem is more relevant but not limited to the new LIRs which receive their initial and only allocation and assign it as one single block to themselves. Some possible problems to be addressed: 1. Should this be limited to certain top/bottom status pairs (like ALLOCATED PA->ASSIGNED PA). IMHO yes. 2. Shoud DB return both INET(6)NUM object matching the query? I'm open to both options (special query flag could be introduced if necessary). 3. How to delete/modify correct INET(6)NUM object. While deleting, exact copy must match. While modifying, status line select the one to be modified. Looking for your comments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

2 1

Proposal: make phone number optional in person objects
by Shane Kerr 17 Apr '15

17 Apr '15

All, Piotr's set of proposed improvements to the RIPE database has inspired me! Proposal: Make the phone number optional in person objects. Motivation: For ages the "phone" attribute has been mandatory in person objects (since 1995 with document RIPE 49 at least). But I don't see any reason that this should be mandatory. Many people prefer to be contacted via e-mail or some other method. Oddly, "phone" is optional on role objects, which would seem to be the ideal place for help desks and the like. (I am NOT proposing that we change this.) Cheers, -- Shane

3 4

Proposal to cleanup some hack's with status values
by Piotr Strzyzewski 16 Apr '15

16 Apr '15

Dear DB-WG Members Proposal: I propose to introduce some new status lines for INET(6)NUM objects to cleanup some hacks. Problem description: Right now we have at least four category of hacks in the status lines: 1. ::/0 inet6num: ::/0 netname: IANA-BLK (...) status: ALLOCATED-BY-RIR remarks: This network in not allocated. This object is here for Database consistency and to allow hierarchical authorisation checks. (...) 2. 0/0 inetnum: 0.0.0.0 - 255.255.255.255 (...) status: ALLOCATED UNSPECIFIED (...) 3. IPv6 allocations made by IANA to RIPE NCC inet6num: 2001:600::/23 (this is just an example) (...) status: ALLOCATED-BY-RIR # This block was actually allocated by the IANA (...) 4. IPv4 allocations made by IANA to RIPE NCC inetnum: 185.0.0.0 - 185.255.255.255 (this is just an example) (...) status: ALLOCATED UNSPECIFIED (...) Hacks no 1 and 3 looks easy. Those are definately not ALLOCATED-BY-RIR. So I propose to introduce two new status values: IPV6 for ::/0 and ALLOCATED-BY-IANA for IANA IPv6 allocations. Hacks no 2 and 4 are bit tricky. According to "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region": "ALLOCATED UNSPECIFIED: This address space has been allocated to an LIR or RIR. Assignments may be PA or PI. This status is intended to document past allocations (...)" It is quite obvious that 0/0 is not "past allocation". So I propose to introduce new status value: IPV4 for 0/0. Moreover, it looks like "ALLOCATED UNSPECIFIED" has been overused also. For example 185/8 has been allocated to RIPE NCC on 2011-02-08. This was done after many of the previous versions of the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" which include quoted definition have been published. So I propose to introduce new status value ALLOCATED IANA for such cases. Some possible issues to be addressed: 1. When this proposal will be supported by the DB-WG, then it has to be discussed with AP-WG and IPv6-WG. 2. There are two more hacks which could be discussed: IETF reserved blocks and legacy allocations under various RIR administration. Looking for your comments. Piotr -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski(a)polsl.pl

1 0

Re: [db-wg] [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment
by * IP - Detal 10 Apr '15

10 Apr '15

Dear Colleagues from RIPE NCC, Thank you for information. <http://www.google.pl/url?source=transpromo&rs=rssf&q=//translate.google.com…> In relation to the following e-mail we have a question. We are one of the largest ISP in Poland (we have a huge number of object registered in ripe database). We do not understand how we would add so many attributes "last-modified:" and "created:" to tens of thousands our records registered in ripe database? It takes a long time and we are obliged to modify it to the end of July 2015. The "created" and "last-modified" fields can be automatically generated to new records, but how to updated the already registered objects without manual input ? We are waiting to your reply. Kind regards, Ewa Hilmantel - Debska pl.tpsa ________________________________ From: ncc-announce [mailto:ncc-announce-bounces@ripe.net] On Behalf Of Tim Bruijnzeels Sent: Thursday, April 02, 2015 5:15 PM To: ncc-announce(a)ripe.net Subject: [ncc-announce] [news] Phase 1 of Deprecation of "changed:" Attribute Deployed to RIPE Database Release Candidate Environment Dear colleagues, The RIPE Database Working Group has asked the RIPE NCC to replace the "changed:" attribute in the RIPE Database with "created:" and "last-modified:". We want to inform the wider community, in case you have any feedback you would like to share with the Database WG. Following discussions at RIPE 69, we met with the WG chairs and finalised an implementation plan consisting of three phases: 1) Introduce the new attributes "created:" and "last-modified:" 2) Make the "changed:" attribute optional 3) Deprecate the "changed:" attribute Details of this implementation plan can be found here: https://labs.ripe.net/Members/tim/deprecating-the-changed-attribute-in-the-… We recently informed the Database WG that Phase 1 of this implementation had been deployed to the Release Candidate environment. We are planning to deploy this to the production environment on 28 April: <https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html>https://www.ripe.net/ripe/mail/archives/db-wg/2015-March/004504.html If you have any questions or comments, please raise them on the RIPE Database WG mailing list at <db-wg(a)ripe.net<mailto:db-wg@ripe.net>>. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

2 1

RIPE-NCC-LEGACY-MNT
by Hank Nussbacher 07 Apr '15

07 Apr '15

Not sure which list is appropriate so please reply only to the list that people point out as the one which should handle the following issue: I have modified a number of objects to be now LEGACY objects. inet-nums and aut-nums. When the object is processed and converted into a LEGACY object, RIPE auto-adds the following line to each object: mnt-by: RIPE-NCC-LEGACY-MNT This is documented here: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.77 Policy 2012-07: Legacy holder organisations cannot change their organisation name in their org object if it is referenced by an INETNUM or AUTNUM that is maintained by RIPE-NCC-LEGACY-MNT. I then noticed I needed to delete some import and export lines on my aut-num policy. No can do any more. I now get the error: Authorisation for [aut-num] AS378 failed using "mnt-by:" not authenticated by: RIPE-NCC-LEGACY-MNT, AS378-MNT So this now means *every* change to any legacy IP block or ASN has to go via RIPE. But I have been unable to find how to go about informing RIPE that I need to make an object modification. Any pointers would be helpful. Regards, Hank

2 2

[training] RIPE NCC Webinars - new dates
by Training Services 30 Mar '15

30 Mar '15

Dear colleagues, We are pleased to announce the launch of new dates for our Webinars. The RIPE NCC Webinars are live and take only one hour. You can interact with our trainers without leaving your desk. We focus on the topics and issues most important for LIRs. Register now at https://www.ripe.net/lir-services/training/e-learning/webinars Participation is limited to 20 people, so don't hesitate if you want to take part! If you have questions, please email <training(a)ripe.net>. We look forward to seeing you online. Kind regards, RIPE NCC Training Services

1 0

Call for agenda items DB-WG meeting during RIPE70, Amsterdam, NL
by Job Snijders 23 Mar '15

23 Mar '15

Dear DB-WG participants, We are reaching out to you for agenda items for the Database Working Group session during the RIPE70 meeting in Amsterdam, Netherlands 11-15 May 2015. Some of the current topics are: - 'source:' differentiation - RIPE-NCC-RPSL-MNT - UTF-8 in the DB - cross-registry authorisation - updates from RIPE NCC - .... your topic? Please submit your items or topic suggestions to the chairs directly or to the list for public discussion. Soon we'll publish a draft agenda, waste no day if you want microphone time! :-) The Database Working Group session is scheduled Thursday 14 May, from 16:00 till 17:30. Looking forward to a successful session and see you soon in the beautiful city of Amsterdam! Kind regards, Job, Piotr & Nigel

1 0

RIPE NCC to remove mnt-lower RIPE-NCC-END-MNT from ASSIGNED PI objects
by Tim Bruijnzeels 06 Mar '15

06 Mar '15

Dear colleagues, Sub-assignments of ASSIGNED PI objects are technically possibly in the RIPE Database, but not allowed by RIPE policy. And to prevent that such sub-assignments are created, the RIPE NCC has been including "mnt-lower: RIPE-NCC-END-MNT" on ASSIGNED PI Objects. Nowadays however we prefer to enforce such policy restrictions by the use of special "business rules" and a rule has already been implemented for this particular case. Therefore the RIPE NCC would like to do a bulk change on all ASSIGNED PI objects in the RIPE Database and remove "mnt-lower: RIPE-NCC-END-MNT" where it's present. Since we feel that this operation does not significantly alter the affected objects we plan to suppress sending out notify messages regarding this change, and we will make sure that this change is excluded when the "last-modified:" attribute is added in future. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

4 5

Monthly open-items summary
by Nigel Titley 02 Mar '15

02 Mar '15

Folks, The WG chairs have decided that a monthly "open-items" list might be useful to the WG. I'm doing the first and it will then rotate around the other chairs on a monthly basis. - "source: field for non RIPE address space", this proposal needs to be reworked to accommodate the large transfer of route objects from RIPE to the new AFRINIC DB - "restrict usage of RIPE-NCC-RPSL-MNT" we need to continue this discussion and request action from RIPE NCC - proposal for latin1 primary keys, utf8 allowed in user modifiable data - cross routing registry authorisation. This is a long term project which will ultimately allow authorisation between registries and will allow de-duplication of data across the registry system as a whole. This will be progressed as a BOF at RIPE 70 meeting if possible. - continue promotion of the the new Afrinic RR If I've missed anything please let me know. Nigel

1 0

RIPE NCC to stop enforcing accurate organisation names in "descr:" attribute
by Tim Bruijnzeels 26 Feb '15

26 Feb '15

Dear colleagues, The "org:" attribute now provides a consistent way to find the organisation for all resources in the RIPE Database. The RIPE NCC is planning to stop enforcing the organisation name in the "descr:" attribute for those resources allocated or assigned by it. There was a time when the "org:" attribute was not mandatory for INETNUM, INET6NUM and AUT-NUM objects. And to make it clear which organisation is the holder of a resource, the RIPE NCC has been enforcing that the first "descr:" line of these objects reflects the organisation name for resources that are allocated or assigned by the RIPE NCC. But this limit was never enforced on resources not allocated or assigned by the RIPE NCC, such as sub-assignments and legacy resources. Nowadays these object types do have a mandatory "org:" attribute, and today the RIPE NCC also enforces that the organisation referenced here, and its name, reflect the registry records for these resources. For resources not allocated or assigned by the RIPE NCC it's the responsibility of resource holders to ensure that the referenced organisation accurately reflects the holder of e.g. sub-assignments and legacy resources. Please let us know if you have any comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

4 4

RIPE Database Release 1.78 Deployed to Release Candidate Environment
by Tim Bruijnzeels 23 Feb '15

23 Feb '15

Dear colleagues, The RIPE NCC is pleased to announce the deployment of RIPE Database software release 1.78 to the Release Candidate (RC) environment. Please note that the previous release candidate, 1.77, was rolled back because of an issue with concurrent updates that only became apparent in the production environment. Release 1.78 includes a fix for this issue. Extensive automated tests have been added to prevent similar issues from happening again. This release includes all features and fixes from release 1.77. In addition, release 1.78 of the RIPE Database software also includes a number of other improvements: = We added a dry-run option for the REST API = We improved the error message when creating an organisation object without and AUTO primary key = Fix for Issue #286: Pending create route requests are not removed when the route is created Detailed release notes are published on the web site: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.78 We invite all users of the RIPE Database to review the new release in the RC environment: https://www.ripe.net/data-tools/db/release-notes/rc-release-candidate-envir… Please let us know if you find any issues. We plan to deploy this release to the production environment on Monday 23 February. We look forward to any questions or comments you might have. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC

1 1