- db-wg - mailman.ripe.net

Whois Release 1.94.1
by Edward Shryane 08 Jul '19

08 Jul '19

Dear Working Group, RIPE Database release 1.94.1 has been deployed to the Release Candidate environment. This is a bug-fix release, with no new features. If no issues are found, we plan to deploy to production on Monday, 8th July. This release contains two main changes: - Consistent substitution of invalid latin-1 characters (e.g. control characters) and non-latin-1 characters across all Whois Update APIs (e.g. Syncupdates, Mailupdates, REST API). Following this release, we will also cleanup existing objects to be consistent. - Improvements to the RDAP protocol implementation (https://rdap.db.ripe.net). For a full list of changes, refer to the release notes: https://www.ripe.net/manage-ips-and-asns/db/release-notes/ripe-database-rel… More information on the Release Candidate environment can be found on our website: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Please let us know if you find any issues with this release in the RC environment. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Search
by Cynthia Revström 05 Jul '19

05 Jul '19

Hello DB-WG, not sure if this is the correct place but anyways... The WHOIS search bar on https://www.ripe.net works but not on https://apps.db.ripe.net/db-web-ui/#/query <https://apps.db.ripe.net/db-web-ui/#/query?searchtext=as56789> In both cases I am talking about the search bar on the top of the page not the one in the middle. - Cynthia

2 2

Out-Of-Region routes ?
by Ronald F. Guilmette 03 Jul '19

03 Jul '19

My recollection is that there came a time ... I can no longer remember if that was just last year or the year before... when it was decided and implmented that the RIPE DB would no longer allow the addition of route objects for out-of-region address space. Somebody please refresh my memory. At that time, how was it decided that pre-existing route objects for out-of-region IP address locks would be handled? I gather than those were not in fact ejected from the data base, but rather that it was decided... I seem to recall... to simply mark them in some distinctive way. Is that correct? And if so, what was/is that distinctive marking?

2 2

--list-versions
by Ronald F. Guilmette 26 Jun '19

26 Jun '19

I am having some trouble applying the --list-versions option to some things that are either (a) the first IPv4 address of an inetnum: object and/or (b) a netname: object. Is this option even supposed to work on such things? Examples: --list-versions 194.162.0.0 --list-versions DE-ECOTEL-950515 I am having serious trouble understanding why this isn't working. If someone could explain, I'd appreciate it. Regards, rfg P.S. Yes, I am aware already that --list-versions and --show-version options do not work on person & role objects.

5 7

Whois Release Process
by Cynthia Revström 24 Jun '19

24 Jun '19

Hello DB-WG, Ed proposed a change to the WHOIS release process at the DB-WG session @ RIPE78. This change would be to immediately deploy bug fixes without a release candidate. I would just like to voice my opinion on it, so my thought is that maybe give the db-wg 24h to voice opinions or something like that. Just a thought but anyways. - Cynthia

4 5

RIPE Database Questionnaire
by Sandra Bras 05 Jun '19

05 Jun '19

Hello everyone, As a follow-up to my short presentation in the RIPE Database Working Group session during RIPE 78, I would like to share the link to our questionnaire. We’re currently developing the RIPE Database exam for the RIPE NCC Certified Professionals programme. It is crucial that we align not only our learning content, but also the exam questions, with the tasks you regularly carry out in the RIPE Database. It is important for us that, as an experienced user of the RIPE Database, you help us ensure that our testing is robust and relevant, by completing this short questionnaire (only four questions): https://www.ripe.net/support/certified-professionals/ripe-database-question… <https://www.ripe.net/support/certified-professionals/ripe-database-question…> Read more about the RIPE NCC Certified Professionals programme in this RIPE Labs article: https://labs.ripe.net/Members/sandra_bras/ripe-ncc-certified-professionals-… <https://labs.ripe.net/Members/sandra_bras/ripe-ncc-certified-professionals-…> And sign up to take part in the pilot RIPE Database exam and become one of our first RIPE NCC Certified Professionals: https://www.ripe.net/support/certified-professionals <https://www.ripe.net/support/certified-professionals> Please do contact me if you would like any further information. Warm regards, Sandra Brás E-Learning Programme Manager RIPE NCC

2 1

Authenticating References to Objects
by Edward Shryane 04 Jun '19

04 Jun '19

Dear Working Group, as mentioned at last week's DB-WG meeting, I'd like to propose extending authenticating references to other objects. Currently, only references to organisation objects can be protected with the mnt-ref attribute. However, we could extend this protection to other types of objects: - Abuse-c role - Technical contact, admin contact, zone contact etc. (person/role) - Organisation maintainer(s) This would prevent unauthorised references to an organisation's objects (e.g. to impersonate a third party or mis-direct abuse email). Please let me know your feedback on this proposal. Regards Ed Shryane RIPE NCC

8 10

NWI-9 In-band notification mechanism - proposed Solution Definition
by Edward Shryane 28 May '19

28 May '19

Dear Working Group, given the Problem Definition for NWI-9: "There is a need within the routing community to have changes to all/nominated routing data objects in the RIPE Database pushed out to them, regardless of membership status." As presented at last week's DB-WG meeting, I'd like to propose a Solution Definition: (1) The current NRTM service is not suitable. The current NRTM is a member-only service, with a separate agreement: https://www.ripe.net/manage-ips-and-asns/db/nrtm-mirroring The work needed to change this (including technical changes to open the service) is greater than providing a re-implementation. The existing service will remain available on the same terms. (2) Implement a replacement NRTM interface The current NRTM is a custom protocol, which is complicated to use, and not easy to extend without breaking existing clients. Instead implement a replacement NRTM interface, based on modern standards. - The interface is generally available without needing to be a member, or to sign an agreement. - The protocol uses HTTPS and WebSockets, with object data in JSON format. - A client can request the current available range of updates, and also request a closed or open range of updates. - A separator comment is inserted between updates, with an 'end of stream' comment after each group of updates. - All object updates are returned, except for person and role objects. - Personal data is filtered from all object updates, consistent with the other query interfaces. - A client can optionally request filtering updates by object type. - A client can optionally identify themselves by providing credentials. - The interface can be extended later by adding more request parameters. Please let me know what you think. Regards Ed Shryane RIPE NCC

3 2

Suggestion further validity-checking
by Jens Ott - Opteamax GmbH 28 May '19

28 May '19

Dear DB-WG, I am newly subscribed to this mailing-list although I am already active in RIPE-community for quite some time. Some of you might know me in person. To be honest, I am not sure if this is the right place to send my mail to and if it's not I'd be happy to be told who to address better. For debugging our prefix-list-generator I increased verbosity of the tool a little. As side-effekt I was also pointed to a route-object in the ripe-database which contains a "hole"-definition where the netmask doesn't match (X.Y.226.0/21) and actually is the same size as the entire route-object. I already contacted the maintainer of that object but think it might be a good idea to add a validity-check on adding new objects to prevent this kind of faulty objects in the DB. Best regards -- Jens Ott Geschäftsführer Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo(a)opteamax.de HRB: 23144, Amtsgericht Montabaur Geschäftsführer: Jens Ott Umsatzsteuer-ID.: DE264133989

6 10

NWI-8: LIR's SSO Authentication Groups - Implementation Plan
by Edward Shryane 27 May '19

27 May '19

Dear working group, here is the RIPE NCC's proposed implementation plan for NWI-8: LIR's SSO Authentication Groups. Scope - To simplify the implementation, synchronisation will be done using the existing SSO authentication method. - Authentication groups (and any new authentication method) will be deferred until later. Introduction - The synchronisation of non-billing users with the RIPE database will be done with a default maintainer. - Setting a default maintainer for the organisation is a pre-requisite for synchronisation. - A default maintainer is already able to maintain the organisation object and top-level resources. - Extending this existing mechanism simplifies the synchronisation of users. Implementation - A new checkbox will be added to the Account Details page in the LIR Portal, in the Maintainer section. - "Synchronise non-billing users with the default maintainer". - If no default maintainer is set, the checkbox is disabled. - The synchronise checkbox is not checked by default (the user must confirm this action first). - When the user enables the synchronise checkbox, they must first authenticate with the default maintainer. - The user must prove they control the maintainer before user accounts are added to it. - If the user's account is already present on the maintainer, this authentication is automatic. - Otherwise if the maintainer contains any password credentials, the user will be asked for a password. - Otherwise the user is asked to first add their credentials to the maintainer separately. - Once the checkbox is enabled, synchronisation is performed. - Any existing user accounts are removed from the maintainer. - Any non-billing user accounts are added to the maintainer. - Any other credentials (passwords or PGP keys) are not affected. - After synchronisation is enabled - Whenever a non-billing user is added or removed from the organisation, the default maintainer is updated accordingly. - A default maintainer can only be synchronised with a single organisation. - If a user is removed from one organisation, but remains in a different organisation, this would create a conflict when synchronising. - If synchronisation is disabled - Users are no longer synchronised with the default maintainer, but existing user accounts are not removed. - Notifications - To receive email notifications when the default maintainer is updated, use the notify: and/or mnt-nfy: attribute(s) on the maintainer itself. Regards Ed Shryane RIPE NCC

3 3