September 2020 - db-wg - mailman.ripe.net

NWI reviews: NWI-2 displaying history for DB objects where available
by ripedenis＠yahoo.co.uk 11 Jan '21

11 Jan '21

Dear Colleagues This is another action point that has been open for 4 years. We either need to progress it or cancel it.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005240.html It is basically asking for full history of existing and deleted resource objects. In the link above on this NWI it mentions some doubt over the value of full history. So the main questions are, -"is full history more useful than partial history?" -"is history of deleted objects, that don't currently exist in the database, useful?"If so then I don't see any reason not to provide it. Let me give some background on this. Objects in the database are accessed by their primary key (pkey). In the case of an INETNUM object, for instance, this is an address range. Internally to the database all objects also have an object ID. Each time an object is modified a new instance of the object is created in the database with the same pkey and object ID. (Other meta data is updated to keep the sequence of changes.) When an object is deleted and re-created with the same pkey, the new object has a new object ID. Then the sequence of changes continues with this new object. When the RIPE NCC proposed to make history of objects available an arbitrary decision was made to present the history of a currently available object with all instances having the same object ID. In other words the history presented only went back as far as the creation of the current sequence of object modifications. The object may have existed before this sequence and been deleted and re-created. That part of the history is not available by the current query mechanism. But of course that history does exist in the database. It is not difficult for the software to present the full history of an object based on the pkey, no matter how many times it has been deleted and re-created. The decision to only give history back to the most recent deletion was an arbitrary, low hanging fruit, option to get a service up and running quickly. It has just stayed that way ever since. Your comments are appreciated... cheersdenis co-chair DB-WG

4 4

MNTNER Naming : Consensus
by William Sylvester 19 Oct '20

19 Oct '20

db-wg members, The chairs of the database working group believe there is a consensus to have a standardised name format for creating new MNTNER objects. There was talk of a prefix (MNT-) or a suffix (-MNT). When creating a new standard it doesn't really make sense to introduce a standard with multiple formats. As there are currently 36347 MNTNERs that end with -MNT and 12480 MNTNERs that start with MNT-, we suggest that the standard should be to end with -MNT. We ask the RIPE NCC to take the next steps in moving this request forward, conducting an impact analysis, and proceed with implementation. Best regards. William & denis db-wg chairs

4 5

Whois Release 1.98
by Edward Shryane 01 Oct '20

01 Oct '20

Dear Working Group, RIPE Database release 1.98 has been deployed to the Release Candidate environment. We plan to deploy to production on Thursday 1st October. This release includes the following main changes: * NWI-11 Punycode Internationalized Domain Names in email addresses. * Return remark in RDAP response when abuse-mailbox validation has failed. * RDAP CORS changes * RDAP invalid syntax exception * A deleted object may be matched in the fulltextsearch index (fixed) In addition to other small improvements and bug fixes. The release notes are on the website: 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

NWI reviews: NWI-3 - Afrinic IRR Homing
by ripedenis＠yahoo.co.uk 01 Oct '20

01 Oct '20

Dear Colleagues This is another 4 year old task about 'encouraging' the transfer of ROUTE(6) objects for Afrinic resources from the RIPE Database to the Afrinic Database.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005241.html Is this still an ongoing task? Is there anything more that needs to be done from the RIPE region to complete this Task? Or can we consider this task as completed now? My feeling is that it was superceeded by 'NWI-5 Out of region ROUTE(6) / AUT-NUM objects', which is marked as 'Finished'https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005245.html As always, your comments are appreciated... cheersdenis co-chair DB-WG

5 7

WHOIS Referrals for transferred number resources
by Ronald F. Guilmette 30 Sep '20

30 Sep '20

I have been writing a modest little software tool recently that seeks to ferret out the identity of the "top level" registrant organization for any given assigned IPv4 address. In this context by "top level" I mean the entity that obtained the relevant IP address assignment directly, either from one of the five regional Internet registries or else from some subserviant national Internet registry. This softare tool always starts by querying whois.iana.org in order to obtain a first-order referral to one of the WHOIS servers belonging to of the five regional Internet registries... usually and often the correct one that actually holds the desired information. Due to various inter-region transfers that have taken place over time however, the first-order referral given by whois.iana.org is often simply wrong, and it is really some other WHOIS server of some other one of the five regional Internet registries that actually contains the information sought. Conveniently, in the case of the ARIN WHOIS server and the APNIC WHOIS server, even in those cases where these respective WHOIS servers do not contain the data sought, e.g. due to some inter-region transfer, these WHOIS servers are at least helpful enough to provide in their responses explict referrals to the proper regional Internet registry WHOIS server where the desired data can in fact be obtained. I would like to request that NCC staff administering the RIPE WHOIS data base likewise incoroprate some such helpful explicit referral text into the WHOIS responses for all number resources where whois.iana.org believes that the resources are under the administration of RIPE, but where in fact the number resources in question have been transferred to some different region. During the early testing of my small software tool I have already encountered a number of such cases. In each of these cases I had to sort out the problem by hand -- I had to ferret out the correct RIR WHOIS server by other means, the responses from whois.ripe.net being of no help whatsoever in this regard, and I then had to program in some "manual overide" work-arounds in my code in order to deal with these cases: 51.79.0.0/16 51.81.0.0/16 51.161.0.0/16 51.162.0.0/17 51.222.0.0/16 151.101.0.0/16 151.139.0.0/16 151.164.0.0/16 151.190.0.0/16 185.105.7.0/24 185.150.189.0/24 185.150.190.0/23 185.171.208.0/22 194.204.192.0/18 I have some faith and hope that the community, the members, and the staff of the RIPE region will wish to be at least as helpful with repect to this WHOIS referral issue as their North American and Asia/Pacific counterparts. Given the expected increases in inter-regional transfers it seems that the time is... well... ripe, to address this small but consequential issue within the data base. Regards, rfg

2 3

Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Hi Lutz Good try but this script does not do it. Firstly, if you start with the allocation object it needs to be -rM in the first query. Then you are only looking for the "org:" attribute. The INET(6)NUM object may have an "abuse-c:" attribute in the object. It may have both in which case the local attribute overrides the "abuse-c:" in the referenced ORGANISATION object. Also to manage this feature it is not just about producing a list of abuse email addresses. It is knowing where these are referenced within a hierarchy and knowing which parts of the hierarchy are covered by which addresses. I agree that most resources will only have a single abuse contact referenced from their single ORGANISATION object. However, we were pushed hard by the community to allow "abuse-c:" to be added to the INET(6)NUM objects. I assume therefore that this feature has been used. So we already have a mix of abuse contacts referenced from both ORGANISATION and resource objects. When this was asked for the emphasis was on 'ease of use' to add these contacts. Probably no one gave much thought to how these contacts will be cleaned up when no longer relevant. It's most likely that someone will ask someone to remove it. Knowing human nature it is more likely some will just be forgotten about. If the contact is still there it is still active, but maybe no one is reading that email address any longer. I am not an operator so I don't know how many end user customers in large networks handle their own abuse reports. Or how many sub allocations handle abuse with their own customers handling abuse. So I don't know how complex this will get and maybe all operators already have good procedures in place to manage all this. That is why I am asking the question...is such a visualisation tool needed, useful or a waste of time? As an analyst, I can only see how complex this 'could' become over time. Unless we go back to the drawing board and redesign the abuse contact system (again) this is not going to be simplified any time soon. cheersdenis co-chair DB-WG On Thursday, 24 September 2020, 15:32:09 CEST, Lutz Donnerhacke via db-wg <db-wg(a)ripe.net> wrote: > > We need to take some action on these old NWIs. Either we move forward > with them or we cancel them. It is difficult to draw a consensus on 2 > comments. Can you please give us a couple of minutes of your time and > let us know if this NWI-1 is needed, useful or a waste of time. > > I share the view already expressed. If we need a tool, maybe the problem > is somewhere else. I support any proposal, that comes to the same result as the ripe whois database tool. It's not really hard to do correctly. #! /bin/sh getripe="whois -h whois.ripe.net --" $getripe -rL -T inetnum,inet6num "$1" | egrep '^org:' | while read ot ov; do $getripe -r -T organisation $ov | egrep '^abuse-c:' | while read at av; do $getripe -r $av | fgrep abuse-mailbox done done | tail -1 In order to fix the issue on the database side, it's necessary to prevent any occurrence of "abuse-mailbox" in all objects beside an newly created "abuse-contact" type, which is only allowed to referenced in the "abuse-c". See here for a corner case: https://lutz.donnerhacke.de/eng/Blog/Antispammers-and-Abuse-C

2 1

Fw: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes
by ripedenis＠yahoo.co.uk 24 Sep '20

24 Sep '20

Colleagues We need to take some action on these old NWIs. Either we move forward with them or we cancel them. It is difficult to draw a consensus on 2 comments. Can you please give us a couple of minutes of your time and let us know if this NWI-1 is needed, useful or a waste of time. cheersdenis co-chair DB-WG ----- Forwarded message ----- From: ripedenis--- via anti-abuse-wg <anti-abuse-wg(a)ripe.net>To: anti-abuse-wg(a)ripe.net <anti-abuse-wg(a)ripe.net>Sent: Tuesday, 22 September 2020, 22:50:52 CESTSubject: [anti-abuse-wg] NWI reviews: NWI-1 staying on top of abuse contact changes Colleagues This is now a very old NWI that never got out of the starting blocks. I am posting this to the AA-WG as I think the discussion is more relevant to this community given the impact of not properly managing this data. https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005234.html Since I raised this point the world has moved on and the situation is now even more complex. The "abuse-c:" attribute can be added to:-the resource holders primary ORGANISATION object-any secondary ORGANISATION object referenced from any point in the address hierarchy-any resource object at any point in the address hierarchy-all, or any combination, of the above These (multiple) "abuse-c:" attributes can reference the same or multiple ROLE objects. These (multiple) ROLE objects can include "abuse-mailbox:" attributes referencing the same or multiple email addresses. Over time, with large hierarchies, we could end up with very complex arrangements with objects, attributes and values that have been overlooked and forgotten about. Even though they may have been forgotten about they are still 'active' and queries will return the most appropriate abuse contact details, even if it is the wrong contact. There is no simple query that will return the details of such a complex structure of abuse contact data in the RIPE Database. So there is no easy way for a resource holder to review or manage these abuse contacts. Although most resources will only ever have one abuse contact for the whole hierarchy, over several years we could end up with the kind of data swamp we had before we introduced the "abuse-c:" attribute for the larger networks. Any user could write their own script to do more specific queries, parse the returned objects and work out the abuse contact data structure for their resource. It would require detailed knowledge of the RIPE Database structure, the abuse contact rules and would involve multiple queries just to get the data, which you then have to visualise. My reason for this NWI-1 was to suggest the RIPE NCC creates a tool or RIPEstat widget that would take in a resource and map out the abuse contact details for the whole hierarchy including that resource. Would this be useful, is it necessary or a waste of time? Please discuss.... cheersdenis co-chair DB-WG

3 2

Re: [db-wg] 57.224.0.0/11
by Lutz Donnerhacke 23 Sep '20

23 Sep '20

> In message <20200923071702.GA5107(a)hydra.ck.polsl.pl>, > Piotr Strzyzewski <Piotr.Strzyzewski(a)polsl.pl> wrote: > >Let me add some little humour here: > > > >$ dig txt gb. +short > >"This domain is frozen and will be phased out" > >"For details see the web page on: www.nic.uk" > >"Domain names for United Kingdom go under .uk" > > > >It is "phased out" for many years already. ;-) To make it even more funny: In the ICANN32 meeting in Paris in 2008, the IDN ccTLD fast track session was heavily heating, because only non-latin scripts should qualify for this "fast track" procedure. So the GAC member from UK stand up and insisted, that they need to have geographic region TLDs, too. The response from the plenum was ... "You insisting in obey the rules, word by word?" - "Yes." - "So your ISO 3166 code is GB, but you are using UK, which violates the rules. I'd suggest to clean up you mess first, ..." - the GAC member sat down, redfaced.

1 0

57.224.0.0/11
by Ronald F. Guilmette 23 Sep '20

23 Sep '20

I admit to being a bit naive and uneducated, so perhaps someone here will take pity on me and explain this to me. I was under the impression that the world was running out of IPv4 addresses. But regardless of that, it seems that a old line French company that has been in business since 1949 was awarded an entire /11 block by RIPE NCC as recently as February of this year. I confess that this leaves me a bit perplexed. If someone will explain, I'll appreciate it. And, oh, by the way, yes, I do see the word "LEGACY" there. But I also see two different created: lines and their associated field values, both of which appear to tell a rather different story. inetnum: 57.224.0.0 - 57.255.255.255 netname: SITA-NET country: BE org: ORG-SIDT4-RIPE admin-c: SITA tech-c: SITA status: LEGACY mnt-by: SITA-MNT mnt-by: RIPE-NCC-LEGACY-MNT created: 2020-02-04T16:41:22Z last-modified: 2020-02-04T16:41:22Z source: RIPE organisation: ORG-SIDT4-RIPE org-name: Societe Internationale de Telecommunications Aeronautiques org-type: LIR address: Chemin de Joinville 26 address: 1216 address: Geneva address: SWITZERLAND phone: +41227476000 e-mail: info(a)sita.aero abuse-c: SITA mnt-ref: RIPE-NCC-HM-MNT mnt-ref: SITA-MNT mnt-by: RIPE-NCC-HM-MNT mnt-by: SITA-MNT created: 2015-06-10T15:19:37Z last-modified: 2016-08-24T10:21:24Z source: RIPE

5 12

Call for Presentations / DRAFT Agenda RIPE81 - Database Working Group
by William Sylvester 14 Sep '20

14 Sep '20

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE81. 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 – XX mins Edward Shryane, RIPE NCC C. Proposed Presentations HERE – YY mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0