- db-wg - mailman.ripe.net

AUT-NUM authorization on ROUTE(6) objects
by Sander Steffann 27 Aug '19

27 Aug '19

Hi, I was looking at https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… That page still documents that "the creation of a route object also needs authorisation from the AS Number that originates the route". I thought that requirement got removed some time ago. Am I confused or does the documentation need updating? Cheers, Sander

4 4

Extending Unreferenced Object Cleanup
by Edward Shryane 21 Aug '19

21 Aug '19

Dear Working Group, as presented at last week's DB-WG meeting, I'd like to extend the current Unreferenced Object Cleanup: https://www.ripe.net/manage-ips-and-asns/db/support/clean-up-of-unreference… which deletes the following unreferenced objects after 90 days: - organisation, mntner, person, role objects - mntner - person/role pairs to also delete the following groups of unreferenced objects after 90 days: - mntner - organisation pairs - organisation - person/role pairs - mntner - person/role - organisation groups This change affects a small number of objects in the database, but is consistent with the goal of removing unnecessary data. Please give me your feedback on this proposal, in particular if there are operational reasons to retain this data. Regards Ed Shryane RIPE NCC

4 4

ORG record vetting ?
by Ronald F. Guilmette 05 Aug '19

05 Aug '19

Just a point of curiosity... For each newly created ORG record that is put into the data base, if the ORG record represents something other than a natural person, does NCC staff make any effort to check to make sure that the alleged non-person entity actually exists, I mean, you know, as a legal entity, somewhere on planet earth? Or is this just another one of those niceties that cannot, in practice, be performed within the RIPE region because the membership has not explicitly approved it? Regards, rfg

10 35

ORG vetting redux
by Ronald F. Guilmette 02 Aug '19

02 Aug '19

I have a trivial little Perl program called "dupcount" that does exactly what its name implies. I ran it on a fresh copy of the database, as part of a command pipeline as follows: % gzcat ripe.db.gz | grep '^org-type:' | dupcount Results were as follows: 99651 org-type: OTHER 24055 org-type: LIR 1131 org-type: Other 1034 org-type: other 3 org-type: OTher 1 org-type: RIR 1 org-type: IANA 1 org-type: WHITEPAGES 1 org-type: OTHEr I gather from this that case should generally be ignored when parsing this field value. Would it also be appropriate to assume that LEGACY number resources have generally been associated with ORG records of type OTHER? Have any or all of those ORGs ever been vetted in any way? And what about number resources that are presently associated with no ORG whatsoever, for example, the following ones? I am having a bit of trouble understanding how a <<void>> organization gets (or got) vetted by NCC. (I should perhaps clarify that of the following 120 ASNs, fully 108 of them are listed as status: LEGACY, however that leaves another 12 wih status: ASSIGNED, and for those, and also the LEGACY ones, the vetting, if any, that has been applied seems to me to be a at least a bit ambiguous.) AS248 AS249 AS250 AS528 AS529 AS544 AS590 AS593 AS697 AS709 AS710 AS712 AS761 AS764 AS777 AS1110 AS1112 AS1114 AS1115 AS1116 AS1118 AS1119 AS1121 AS1122 AS1123 AS1124 AS1126 AS1135 AS1137 AS1203 AS1234 AS1241 AS1253 AS1257 AS1270 AS1271 AS1272 AS1273 AS1274 AS1279 AS1290 AS1304 AS1318 AS1342 AS1352 AS1353 AS1653 AS1654 AS1663 AS1732 AS1739 AS1748 AS1752 AS1774 AS1780 AS1833 AS1835 AS1837 AS1889 AS1893 AS1903 AS1921 AS1922 AS1923 AS1960 AS1961 AS1962 AS1967 AS2004 AS2012 AS2016 AS2017 AS2026 AS2028 AS2029 AS2036 AS2045 AS2049 AS2147 AS2148 AS2481 AS2487 AS2494 AS2529 AS2530 AS2578 AS2609 AS2643 AS2921 AS3151 AS3843 AS3917 AS3918 AS4148 AS4457 AS4458 AS4524 AS4588 AS4589 AS4974 AS6067 AS6168 AS6412 AS8093 AS8346 AS8452 AS11341 AS11660 AS15808 AS18732 AS19376 AS20598 AS21042 AS21174 AS21491 AS22627 AS24691 AS25429 AS29032 AS29039

2 2

WHOIS client(s) and Windows ?
by Ronald F. Guilmette 28 Jul '19

28 Jul '19

I myself am an old school die hard UNIX guy from way back, but recently I have been wanting to shared certain information relating to certain WHOIS records with some other folks, some of whom are strictly and only Windows users. Are there any WHOIS clients available for Windows that provide the full range of RIPE WHOIS options? If not why not? (Sad as it may be, Windows is still used by about 90% of everybody, so it seems odd that WHOIS clients are only built for UNIX and UNIX-like systems.) Has anyone ever tried to build the RIPE WHOIS client, from sources, on Windows? If so, what was the result? I have been telling my Windows-only friends to try to get WHOIS info from, for example, whois.ripe.net, by just using telnet and connecting to port 43 and then typing in their options and search keys, but as I have learned, the results in that case are entirely sub-optimal. If you do this, you will get a "stairstep" set of output lines, apparently because the output of whois.ripe.net, like most other WHOIS servers, assumes that ends-of-lines should be represented by just <LF> and not by the <CR><LF> sequence that is formally required for most other protocols. (The latter is fine for UNIX and UNIX-like systems, while the former is generally needed for Windows systems.) The original RFCs covering WHOIS (RFC 812 and RFC 954) were rather entirely ambiguous about how response lines should be terminated, however the newer RFC 3912, Section 3, strongly hints that response lines should be terminated with <CR><LF> even though it fails to ever come out and say that explicitly. So, is the whois.ripe.net WHOIS server failing to be standard confoming? Regardless of whether it is or isn't I really do need a WHOIS client that I can give to my various Windows-only friends. Any advice or suggestions would be appreciated. Regards, rfg

3 3

Country Codes and that lack thereof
by Ronald F. Guilmette 28 Jul '19

28 Jul '19

I have a number of very useful Perl scripts now that can and do parse and then do interesting and useful things with RIPE WHOIS records, and also with WHOIS records from other regions. In particular, I have a tool that, if given a sizable IPv4 address range, can show the names *and* ISO-3166 two-letter country codes for all of the ASNs that are routing parts of the given IP range, in a nice pretty table. Mostly, this just works, but as I have learned, there are sizable number of cases within the RIPE WHOIS data base where the relevant home country for the ASN is not present in the WHOIS record for the ASN, and where figuring out the home country requires a lot of educated guesswork (e.g. if DO NOT see a country: line but you DO see the name "Sophia" in an address: field, then you can guess that the home coutry is Bulgaria, and that thus, the apprtopriate ISO-3166 code is "BG". I would like to know if I am the only person on the planet who has a concern about this issue/problem. If so, then I will just slink back into my hole and be quiet. If not however, and if others also feel that every organization and resource record present within the RIPE dat abase really should have a contry: line that clarifies where the bloody thing should, nominally, be considered to exist, then I have a good deal more to say on this topic. First, I'd like to say ARIN seems to have solved this problem long ago, in the case of their data WHOIS data base. My Perl script has yet to encounter a single ARIN WHOIS record for a number resource that does not contain an explicit Country: line. But the absence of country: lines in RIPE WHOIS records is, I'm sorry to say, quite extensive. Second, I'd like to ask the obvious question: How did things get like this in the RIPE data base in the first plac? When a party is creating a RIPE WHOIS record for some resource, are they allowed to enter essentially any bloody thing they like, including even leaving out such important information as the home country where the resource is based or where it will primarily be used? If so, why? Why isn't there a form on the RIPE web site, which resource holders must fill out in order to create a new record, and that simply does not allow the user to proceed unless and until the country information has been provided? This is not a debatable policy matter. This is just common sense, I think. And it isn't as if such a web form would be at all difficult to implement. Thirdly, I'd like to just state for the record that in essentially all of the cases I have sewen so far where RIPE WHOIS records lack country: information, it is, in general, reasonably easy to infer such information from other hints in the record itself, as noted above. Thus, NCC staff could... and I believe should... go through all of the records that are currently missing this country: infromation and manually insert it themselves, on behalf of the resource holder. (This would be neither hard nor wexcessively time consuming, as the number of records that lack the country: information appear to me to be a tiny minority of the total number of records within the data base.) Lastly, because I have already found a lot of these problematic WHOIS records that lack the country: information, and because I have already taken the time to scrutinize then all, and make the necessary inferences to determine the likely country codes, I would like to offer myself as a volunteer assistant to the NCC staff for this small project, i.e. of cleaning up the existing records and insuring that they all do have at least some indications of the relevant country in each case. I will be only too happy to lend my assistance towards this worthwhile goal. Of course, some troublemaker will undoubtedly now pop up here to claim that reasonable inforences cannot be made about the primary country that should be associated with any given resource, and/or that many resources are in fact used in a manner that crosses national boundaries. I disagree with the former point, based on my experience so far, and would point out that all resource records are *supposed* to have *some* address for the resource holder in them anyway, and whatever that mailing address is, for each resource record, that mailing address can and should suffice as the best approximation of the "home country" for the resource. Likewise, even though a given resource may be used in a multi-national way, I would argue that it would still be better to have *some* country indicated for it, rather than none, as is currently the case in many records. The perfect is the enemy of the good, and none of this has to be perfect in any sense. A best guess for the county in each case where the resource holder has not supplied that information is necessarily going to be better than nothing in most cases. I look forward to comments on this simple suggestion. Quite simply, I am suggesting that every resource record and every ORG record should include a country: line which itself should specify an ISO-3166 standardized country code, no exceptions. Most already do, or else have a fully spelled-out country names, and it appears to an outsider, such as myself, that the fact that something slightly less than 100% of these records have this country information is just a matter of sloppy DB maintenance which can be and should be corrected. I hope you will all agree. Regards, rfg

2 1

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

Agenda RIPE78 - Database Working Group
by William Sylvester 16 May '19

16 May '19

Database WG Members, Please find the attached agenda for the RIPE Database Working group meeting in Iceland. Regards, William & Denis A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. Personal Data in the RIPE Database – 15 mins Denis Walker D. Cleaning Up Locked Persons – 10 mins Edward Shryane, RIPE NCC E. Country Codes Proposal – 10 mins Nikolas Pediaditis, RIPE NCC F. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Whois Release 1.94
by Edward Shryane 08 May '19

08 May '19

Dear Working Group, RIPE Database release 1.94 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Wednesday, 8th May. Release 1.94 includes the following changes: * Notify the user in the abuse-c comment if address validation has not been completed. * Improved email address validation. * Perform daily limit accounting for personal data in the Full Text Search interface. * Do not remove an abuse-mailbox attribute from a role object, if that role is referenced in a resources' abuse-c attribute. The complete list of changes in this release can be found in GitHub: https://github.com/RIPE-NCC/whois/blob/master/changes.txt The release notes have been published: https://www.ripe.net/manage-ips-and-asns/db/release-notes 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

NWI-9 In-band notification mechanism? ???
by ripedenis＠yahoo.co.uk 16 Apr '19

16 Apr '19

Colleagues Problem Definition 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. Last week Aris was the only person to confirm that he wants this feature. If we are to move forward with this feature can a few more people wave their hands in the air, or send a +1 email. cheersdenis co-chair DB-WG

6 5

NWI-8 LIR´s SSO Authentication Groups
by ripedenis＠yahoo.co.uk 15 Apr '19

15 Apr '19

Colleagues I think we have now agreed on these problem and solution definitions: Problem Definition LIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account will be contained in a default authentication group -Non billing users added or removed through the portal UI will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service Stage 2 -Non billing Users listed in an LIR´s portal account can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method The chairs will now ask the RIPE NCC to work from these definitions in preparing their implementation plan. cheersdenis co-chair DB-WG

2 1

NWIs update
by ripedenis＠yahoo.co.uk 10 Apr '19

10 Apr '19

Colleagues We would like some feedback on the following NWIs and their current status. I would also like to remind colleagues that we have posted a couple of questions on the Address Policy WG mailing list about policy requirements for contact details. We would appreciate some feedback on those questions on that mailing list. cheersdenisco-chair DB-WG NWI-7 abuse-c implementation If the RIPE NCC can confirm that the cleanup of PERSON, ORGANISATION, MNTNER and IRT objects has been done to remove any "abuse-mailbox:" attributes and the 'person' keyword has been updated to take account of the "abuse-c:", we would like to mark NWI-7 as 'Finished'. NWI-8 LIR´s SSO Authentication Groups We agreed on this problem definition: Problem DefinitionLIRs would like a mechanism to easily add/remove users to centralised SSO authentication groups for maintaining objects in the RIPE Database. Do we agree on this (staged) solution definition?(Draft) Solution Definition Stage 1 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, will be contained in a default authentication group -Non billing users added or removed through the portal UI, who have an SSO authentication account, will be automatically adjusted in this group -This authentication group can be referenced in MNTNER objects by a new authentication method -These authentication groups for LIRs will be stored in a way that updates to the RIPE Database is not dependent on the availability of the portal service -(Non billing users who did not have an SSO authentication account who then create one, will be automatically adjusted in this group - NCC, is this feasable?) -(Non billing users who are listed in the LIR's authentication group who then delete their SSO authentication account, will be automatically adjusted in this group - NCC, is this feasable?) Stage 2 -Non billing Users listed in an LIR´s portal account, who have an SSO authentication account, can be added to and removed from user defined SSO authentication groups -Each User can be a member of any number of named groups -The authentication groups can be configured using the portal UI -These groups can be referenced in MNTNER objects by the new authentication method NWI-9 In-band notification mechanism? ???Is there a wish to create this issue as an NWI with the following problem definition? Problem DefinitionThere 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.

9 25

Call for Presentations / Draft Agenda RIPE78 - Database Working Group
by William Sylvester 09 Apr '19

09 Apr '19

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE78. If you would like to present please submit your content as soon as possible to the chairs. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 50 mins Edward Shryane, RIPE NCC C. Proposed Presentation HERE – 10 mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

NRTM Open access
by Cynthia Revström 03 Apr '19

03 Apr '19

Hello db-wg, This is sort of a follow up on a previous discussion. I would just like to say that in a project I am working on as a volunteer I would like to have NRTM, but really we can't mess around with the agreements and such for how NRTM currently is at RIPE. So I would really like the NRTM access to be open. Because if you look at it like this, you can very easily download the entire database that is updated every 24h, but not get NRTM access which is the same but realtime. How does this make sense? - Cynthia

1 0

personal data...next step?
by ripedenis＠yahoo.co.uk 25 Mar '19

25 Mar '19

Colleagues I made a presentation at RIPE 77 last year about personal data in the RIPE Database. Whilst I have been thinking a lot about this since then, and some other comments have been made on different mailing lists recently, no action has yet been considered. This is not a trivial issue to fix and there are a number of points to consider. It will most likely require some semantic changes to the RIPE Database, and possibly the internal Registry Database and member portal may need some changes, as well as some work to be done by resource holders. It may also be an appropriate moment to review the requirements for contacts and contact data in both databases. The optimal solution is to manage the changes necessary to be compliant with privacy laws and practices with the least technical changes and work required by resource holders within a reasonable time frame. I see two approaches to doing this, a lightweight and a heavyweight option. The lightweight option is for myself, working with a couple of members who are interested in finding solutions for this issue, to look at all the concerns, raise points with the community for clarification and work towards a policy proposal on personal data in the RIPE Database. The heavyweight option is to set up a task force to look at the whole issue surrounding contacts and personal data, consider possible solutions and report back to the community at a future RIPE Meeting. My personal preference is for the lightweight option. Whilst it is an issue suitable for a Task Force to consider, history shows that Task Forces often take years to reach conclusions and workable solutions. The previous Data Protection Task Force met for 3 years and the recent Accountability Task Force has been meeting for over 2 years, whilst BCOP has been in operation for more than 5 years. I feel this issue needs a solution implementing this year. I would like to hear opinions from the community on which way to go.... cheersdenisco-chair DB-WG

4 4

In-band notification mechanism?
by Aris Lambrianidis 24 Mar '19

24 Mar '19

Dear all, Back in the day, RFC1996 introduced the NOTIFY mechanism in DNS, which significantly helped with information propagation delay, as it facilitated the transition from a pull (poll) to a push (interrupt) model. The problem we, as AMS-IX, are facing is quite similar when it comes to polling the RIPE database for changes. This seems inefficient. Although the analogy breaks down quickly, as there are no RIPE database "clients" similar to DNS slave servers parsing NOTIFY messages, we would love to see any RIPE API created or extended, or any other mechanism implemented by which a client "registers interest" for any objects it wants to be notified of changes. As a simple example, if we were to "register interest" (e.g. via a REST POST or PUT method) for the AS-AMS-IX-SET as-set object, we would be programmatically notified whenever the "last-modified" field of the as-set was changed. Based on the above, I have 3 questions: 1. Does something like what is described above already exist? 2. If it doesn't exist, would others be interested on such functionality? 3. If it doesn't exist, while knowing that this is only a high level overview of the concept and many details are missing, is this generally feasible? Kind regards, Aris Lambrianidis AMS-IX

7 20