- db-wg - mailman.ripe.net

RIPE Database history - let's make a decision
by denis walker 25 Feb '21

25 Feb '21

Colleagues "NWI-2 - displaying history for DB objects where available" has been open for almost 5 years. Every time we raise this we get 1 or 2 responses, but not enough to declare a consensus on. Although no one has spoken against the idea of making (moree) history available, there is no consensus on what and how to display historical data. So lets review where we are and where we 'could' go...then make some decisions. Available data: The RIPE Database keeps every version of every object since the current RPSL database was launched in April 2001. The data set is almost a complete set. Due to a technical issue a small amount of historical data was permanently lost from the database around 2003. This data does include all deleted objects and objects that have been deleted and recreated. The primary key of any object allows for the correlation of versions across a deletion/re-creation break. However it should be realised that, even if the primary key is the same, a re-created object may not be related to a previous version that was deleted. For example, an assignment may be made to company A. It is later deleted. At some point the same addresses may be assigned to company B. This 're-creates' an INET(6)NUM object with the same primary key as the deleted one. But the two sets of data are unrelated. All of this data is technically available. Excluded data: Privacy laws are quite strict now in the EU. The 'right to be forgotten' in an age where the internet forgets very little is also a significant concern these days. Because the RIPE Database is operated by the RIPE NCC, which is a company registered in the EU, all EU privacy laws apply to all the data held in the RIPE Database. This is a fact. There is no point having any further debate on this issue. So objects that contain only personal data will never be made available through any historical data interface. This includes the PERSON object. Because the ROLE object has been used interchangeably with the PERSON object over the last 20 years it has to be assumed that they may also contain mostly personal data. These objects are excluded from historical data. Operational objects include attributes that are considered to hold personal data. For example the "nic-hdl:" and various email, phone, address attributes are deemed to potentially hold personal data. This data is redacted from historical data in query results. A question that I don't believe has been put to the legal team is whether any case can be made to allow any of the redacted data to be legally included. In other words is there any gray area here? Can an argument be made that some data items, like say "nic-hdl:" are of sufficient interest to some groups, maybe investigators of hijacking resources or LEAs, that would overcome the EU's privacy concerns? Current service: Every time we discuss this issue some people keep turning the conversation onto the current service, who, why, what... It is what it is. It was explained in detail at the time in a RIPE Labs article: https://labs.ripe.net/Members/kranjbar/proposal-to-display-history-of-objec… Lets move on and discuss what you want rather than what you now have. Possibilities: -The focus will be, as it is now, on operational object data. With the one possible caveat on redacted elements mentioned above. -We can remove the arbitrary limitation on presenting history beyond a delete/re-created boundary. -We can allow historical queries on deleted data that does not exist in the database now as a 'current' object. (deleted but not re-created). -How do you want to access historical data? *through all RIPE Database query interfaces *only through a visual representation in RIPEstat *a dedicated whowas service *should historical data be available in bulk *could historical data be a part of the NRTM (in theory if historical operational data is available through unlimited queries, including deleted data, then it would be possible to data mine the entire historical data set) With big data technology, it is technically possible to present a view across the database at a given point in time. This would allow you to query the version of all objects which existed at that point in time. Whether this could be technically managed as a public service I don't know. Anything else that you would like regarding historical data? We can make this as simple or complex as you wish...if you have a use case and subject to legal constraints and technical challenges. Discuss..... cheers denis co-chair DB-WG

2 2

DBTF Questionnaire – Deadline Extended to 22 February 2021
by Bijal Sanghani 12 Feb '21

12 Feb '21

Dear colleagues, We’ve received 20 replies so far to the RIPE Database Requirements Task Force (DBTF) questionnaire. Thank you for that and the discussion on the mailing list. As we would like more feedback on these questions, we’ve decided to extend the deadline to 22 February 2021. The questionnaire takes less than 10 minutes and really will give us valuable feedback to consider for our final draft. You can take the questionnaire here: https://www.surveymonkey.com/r/ZM222M3 Thank you for your participation and support. Have a lovely weekend! Kind regards, Bijal Sanghani RIPE DBTF Chair

1 0

The DBTF needs your feedback!
by Ronald F. Guilmette 05 Feb '21

05 Feb '21

I am attempting to fill out this apparently endless survey, and it's obvious from the get-go that this whole thing was designed as an artificial device to justify the deep-sixing of critical WHOIS information which has traditionally been kept open and public. I mean seriously, who designed these questions? The way the questions are framed, they are all quite obviously pushing one particular point of view, and one specific political agenda, namely to excuse the hiding of information which has never before been hidden... and which does not need to be hidden, except for the benefit of criminals. Here's an example of how to frame a question in a way that pre- supposes one specific outcome: *) QUESTION: What would you prefer? 1) To be beaten and strangled to death? 2) To die of a horrible communicable infectious disease? 3) To be mercifully euthanized in your sleep? How about (4) NONE OF THE ABOVE? I'd actually like to go on living, if it's all the same to you. The survey questionare is positively jam packed with questions that are framed in this same manner... questions that, in effect, ask "How much information should we hide?" How about NONE OF THE ABOVE? Here is a concrete example from the questionaire: * 16. Rank this contact information from most (1) to least (3) important to facilitate Internet operations in the RIPE Database: Email address Phone number Fax number Well, hardly anyone ever sends FAXes anymore, so that one is a no-brainer. But the way the question has been formulated, it is obvious that *someone* wants to get rid of either phone numbers or email addresses in the contact data for various assigned resources, and that answers to this carefully crafted (and methodologically bogus) questionare are going to be used as a lame excuse to do that. I, for one, have seen this movie before... https://www.youtube.com/watch?v=ic6c3WvwbAw This kind of too-clever-by-half way of formulating questions in a way so as to get some desired set of pre-determined answers is both shameful and really beneath the dignity of RIPE. I suggest that the whole thing should be thrown out and replaced by the following single question: "Are you in favor of hiding the traditionally open WHOIS infornmation?" Then the folks who are in favor of allowing criminals in the RIPE region to hide behind GDPR can simply out-vote the rest of us and we can then wrpa up this entire sham process far more quickly and efficiently, saving time for all concerned, since the outcome has already been determined. Regards, rfg P.S. Whoever designed this survey form also does not believe, apparently, that any participant has the right to NOT have an opinion on any single one of the myriad of questions set forth. Do not pass GO and do not collect $200 UNLESS you have given answers even to the questions for which you have no opinion. P.P.S. Apparently, there is no constraint whatsoever on anyone who wishes to skew the results of this "survey" by simply filling in the form several thousand times. It's 2021. People are still running online surveys that can be trivially gamed?? <<me -- shakes head>>

6 7

Deprecation of whitepages
by denis walker 01 Feb '21

01 Feb '21

Colleagues Way back in 2008 it was suggested that the RIPE Database could be used for linking people well known within the network operating industry. The concept of 'whitepages' was introduced. This was an ORGANISATION object (ORG-PAGE1-RIPE) with 'org-type: WHITEPAGES' that could be referenced by PERSON objects to override the automatic deletion of PERSON objects not referenced by any resource object. In today's privacy world, it is a bad idea to use the RIPE Database as a phone book. Currently there are only 4 people whose PERSON object references this ORGANISATION object. (There are also 5 moderators referenced in the ORGANISATION object who have probably long since forgotten they had anything to do with it :) ) I think we should now deprecate this concept. LinkedIn is much more suited to keeping in touch with networking people. Comments appreciated... cheers denis co-chair DB-WG

11 16

"Hidden" historical WHOIS records
by Ronald F. Guilmette 01 Feb '21

01 Feb '21

The Co-Chairman's declaration that my prior post was off-topic for this mailing list... an assertion that I take strong exception to... has at least had the salutary effect of reminding me of a number of what I consider to be "open issues" -- issues which ARE quite unambiguously on-topic for this mailing list, and which I first broached here way back around December 3rd: https://www.ripe.net/ripe/mail/archives/db-wg/2020-December/006736.html At that time and ever since I do not believe that I have seen any resoponse to the clear and pointed questions I posed in the message linked to above. I thus am now obliged to restate and reiterate those still-pending questions. As part of my effort to clarify my goals, vis a vis historical WHOIS transparency, back on December 3rd I threw out what I felt would be a perfectly ludicrous and absurd suggestion, just for retorical purposes, in order to try to make a point. I said something along the lines of "Hey why don't you all just make the entire RIPE WHOIS data base private rather than public?" I felt sure that when I did this that at least some of the denizens of this list... at least the few who might still care about either transparency or accountability... would immediately recognize the utter absurdity of my retorical suggestion, and that those folks, at least, would get up on their hind legs to vigorously protest any such move away from the longstanding and historical open and public nature of the WHOIS data base in all five regions. I was thus shocked and more than a little dismayed to see some of the folks here on this list taking my suggestion as something other than the lame joke and retorical device it was intended to be. Some folks here, it seems, would be entirely fine with hiding literally *everything* from the eyes of outside and independent investigators, including but not limited to me personally -- outside and independent investigators who's only goals are honesty, fairness, and a lack of thievery and self-dealing on the part of RIPE "insiders". I will not mince words. I find this type of position and this type of orientation, in favor of secrecy and against transparency, to be nothing less than shameful. Who does secrecy and darkness help other than the criminal element within the RIPE region? Some of you may still remember the discussion which I engaged in here, on and around December 3rd. For those that do not, the above link may be helpful in refreshing your memories. At that time the subject at hand was the availability, or lack thereof, of access to historical RIPE records, in particular (a) access to records that have since been purged from the data base and also (b) access to the historical versions of various ostensibly "privileged" record types, specifically PERSON, ROLE, and MNTNER records. As noted above, to this day I have never seen an answer to the basic question that I had asked, back on December 3rd about access to either or both of these two broad categories of historical data, and more specifically, who, if anyone, decided or approved, unilaterally or otherwise, the notion that either of these two broad categories of historical data should be made unavailable. Thus, I ask yet again, who made these decisions to hide what was at one time open and public WHOIS data? I certainly do not wish to draw any improper or unjustified inference from the lack of response on this key point, but it quite certainly does seem to be the case, from where I am sitting, that nobody much wants to talk about how these decisions were made, let alone who made them. So, once again: Who exactly decided that these two categories of historical WHOIS records should be unavailable? Was this a decision of the membership and/or the community? Were these decision points / policy points debated openly and fairly, taking into account what may perhaps be multiple divergent views on the matter? Or did certain people in positions of power just make these decisions entirely unilaterally and without ever consulting anyone? I look forward to some clarity here as regards to how these decisions were made and who made them. I hope that others on this list, even if you may disagree with my personal preference for total openness and transparency of the data base, will at least join me in hoping that all -decisions- relating to data base access should at least be made in the clear light of day, and in an open and transparent manner. Regards, rfg P.S. I remind everyone that during the discussion back in early December it was noted that a relevant policy proposal had already been lingering in a state of suspended animation for some years already. Perhaps someone can help me out here. I have been searching for the reference to the specific (still pending?) policy proposal in question but I can't seem to find it now.

4 3

The DBTF needs your feedback!
by Bijal Sanghani 01 Feb '21

01 Feb '21

Dear colleagues, The DBTF (RIPE Database Requirements Task Force) would like to thank those that have given feedback so far on the published draft document - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… We appreciate the feedback given so far, however need a little bit more clarity on some aspects and have therefore published a new questionnaire to collect further feedback. Please can you take a few moments to compete this survey - https://www.surveymonkey.com/r/ZM222M3 You have until Monday, 15 February 2021 and the results will be reviewed and integrated by the task force in the final draft. More information about the task force is available at - https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf Thank you for your participation! Kind regards, Bijal Sanghani RIPE DBTF Chair

1 0

Re: [db-wg] Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
by Marco Schmidt 30 Jan '21

30 Jan '21

Dear Nick, Thanks for your email. We are planning a clean-up of these ROUTE objects. As we wanted to avoid deleting any legitimate objects of third parties, we checked with AFRINIC and they have now confirmed that these ROUTE(6) objects can be deleted. We also performed a check on all of the NONAUTH database for any ROUTE(6) objects (using the prefix only), we found 81 routes (out of 56,379) and 37 ROUTE6 (out of 1,568) that are not "allocated", "assigned", "available", "reserved" in any region. We will now inform the object holder and remove these objects. We don’t think a policy is necessary for this work, but we strongly believe we need an approach similar to NWI-5: "Inform the object holder that these IRR object(s) refer to an unallocated space. We will then delete them after a reasonable notification." This gives people time to react in cases of incorrect de-registration. We will initiate a discussion with the other RIRs to find a joint approach on how we deal with similar incidents in the future. We have also looked into publishing a list of deregistered resources and this will require some review internally if we plan to go down that route. A more straightforward approach might be for the RIRs to proactively highlight where we see objects in each others IRRs. Kind regards, Marco Schmidt Registry Services Assistant Manager RIPE NCC > From: *Nick Hilliard via db-wg* <db-wg(a)ripe.net <mailto:db-wg@ripe.net>> > Date: Fri, Jan 22, 2021, 17:21 > Subject: Re: [db-wg] [anti-abuse-wg] 196.52.0.0/14 > <http://196.52.0.0/14> revoked, cleanup efforts needed > To: Niall O'Reilly <niall.oreilly(a)ucd.ie <mailto:niall.oreilly@ucd.ie>> > Cc: Database WG <db-wg(a)ripe.net <mailto:db-wg@ripe.net>>, Mirjam > Kuehne <chair(a)ripe.net <mailto:chair@ripe.net>> > > > Niall O'Reilly wrote on 22/01/2021 09:55: > > Creating a policy seems to me to be too heavy an approach in this case. > > > > I would think that a simple request from the DB WG to the NCC > > should be enough. > > > > If a greater degree of formality were considered necessary, > > a new NWI could be created. > > there are two issues here: the immediate one relates to removal of these > particular objects, but there's a longer term issue of whether the NCC > needs to be asked by the community to delete all objects which are > deregistered from the other LIRs on an ongoing basis. Honestly I would > have thought probably not because this sounds like the sort of thing > that falls into general garbage cleanup, i.e. normal stewardship of > resources. > > Could someone from the NCC clarify what the current situation with this > is? Is this something which is currently dealt with, and if not, could > it be? > > The reverse is also relevant. I.e. the RIPE NCC probably needs to > publish lists of resources which have been deregistered so that other > RIRs / IRRDBs can delete objects which refer to those resources which > date from before the date of deregistration. > > Nick > >

2 1

Re: [db-wg] AFRINIC Audit report
by denis walker 30 Jan '21

30 Jan '21

Hi All Your post, Ronald, also has nothing to do with the RIPE Database. Please contact the webmaster(a)ripe.net if you have some issues with the web site. There is no need for either of you to reply to this email. Let's close this discussion on this mailing list. cheers denis co-chair DB-WG On Sat, 30 Jan 2021 at 00:52, Elad Cohen <elad(a)netstyle.io> wrote: > > Hi Denis, > > And what Ronald wrote has something to do with the RIPE database? him crying for not receiving "credits" (for his imagination) in his misery life and crying that he couldn't post a comment in RIPE website ... > > Kind Regards, > Elad > ________________________________ > From: denis walker <ripedenis(a)gmail.com> > Sent: Saturday, January 30, 2021 1:38 AM > To: Elad Cohen <elad(a)netstyle.io> > Cc: anti-abuse-wg(a)ripe.net <anti-abuse-wg(a)ripe.net>; db-wg(a)ripe.net <db-wg(a)ripe.net>; Ronald F. Guilmette <rfg(a)tristatelogic.com> > Subject: Re: [db-wg] AFRINIC Audit report > > HI Elad > > As co-chair of the DB-WG I would like to point out that what you are > talking about.has nothing to do with the RIPE Database. Please don't > use this mailing list for these discussions. > > cheers > denis > co-chair DB-WG > > On Fri, 29 Jan 2021 at 20:30, Elad Cohen via db-wg <db-wg(a)ripe.net> wrote: > > > > Yes Ronald, good job for causing Afrinic to spend $150k of their members money for legal expenses that you created with your proofless imaginative theories, and Afrinic will lose due to it, because unlike public perception which is based on "+1's" , in court what count is only facts and data. > > > > and good job by showing us how powerful your friends of spamhaus and ops-trust (https://portal.ops-trust.net/) are, that they can put a sword on the neck of any RIR in order for the RIR to give any head that they will like. > > > > Afrinic with all of their actions and all of their "report", didn't touch the company Cloud Innovation Ltd that didn't purchase legacy netblocks for money, but received two /11's and massive number of /16's for "free" from Afrinic, for the purposes of leasing worldwide, part of them can be seen in the link: https://bgp.he.net/cc#_prefixes > > Maybe it is because that the owner of Cloud Innovation Ltd, knows who to pay, such as Owen DeLong that admitted in Afrinic community-discuss that he received money from Cloud Innovation Ltd and also Owen DeLong wrote in Afrinic community-discuss mailing list the text "Nothing to see here" when people tried to raise questions regarding Cloud Innovation Ltd. > > > > Owen DeLong is a Ops-Trust community member, and also a friend of Ronald Guilmette. > > > > ---- > > > > To remind to you and to everyone, Mr. Jan Vermeulen interfered with the latest RIPE NCC Executive Board elections, by doing it he hurt the rights of all of RIPE community members. > > > > > > Last comment: > > Any ops-trust member or spamhaus university loser, please spare the brainwashing +1's. > > > > ________________________________ > > From: db-wg <db-wg-bounces(a)ripe.net> on behalf of Ronald F. Guilmette via db-wg <db-wg(a)ripe.net> > > Sent: Friday, January 29, 2021 7:20 PM > > To: anti-abuse-wg(a)ripe.net <anti-abuse-wg(a)ripe.net>; db-wg(a)ripe.net <db-wg(a)ripe.net> > > Subject: [db-wg] AFRINIC Audit report > > > > The following has recebntly been posted to the RIPE web site: > > > > https://labs.ripe.net/Members/alun_davies/outcome-of-the-afrinic-audit > > > > I have attempted to lodge the following comment, but apparently my comment > > is being held for review, presumably to insure that it does not contain > > any four letter words, nor any material that might violate GDPR, another > > four letter word. > > > > When I and my journalistic colleague, Jan Vermeulen of MyBroadband.co.za > > began our investigations into this colossal and truly epic malfeasance > > and theft of valuable IPv4 resources in mid 2019, the notion of either > > of us becoming famous or of receiving any credit for unraveling and > > publicly documenting this gigantic scandal was not what motivated us, > > nor has it been, since the beginning. Rather, we merely wished to right > > some wrongs and return to the people of Africa some valuable IP resources > > critically needed for the ongoing development of the Internet in Africa. > > Nonetheless, it would have been, I think, at least minimally respectful > > if either AFRINIC or (now) RIPE had taken a moment to at least mention > > our names and our very evident, abundant, and key contributions towards > > exposing this whole huge mess. Neither organization, it seems, has thus > > far elected to do so publicly. Such is the reward, or lack thereof, of > > a job well done. > > > > > > Regards, > > rfg > >

3 2

AFRINIC Audit report
by Ronald F. Guilmette 30 Jan '21

30 Jan '21

The following has recebntly been posted to the RIPE web site: https://labs.ripe.net/Members/alun_davies/outcome-of-the-afrinic-audit I have attempted to lodge the following comment, but apparently my comment is being held for review, presumably to insure that it does not contain any four letter words, nor any material that might violate GDPR, another four letter word. When I and my journalistic colleague, Jan Vermeulen of MyBroadband.co.za began our investigations into this colossal and truly epic malfeasance and theft of valuable IPv4 resources in mid 2019, the notion of either of us becoming famous or of receiving any credit for unraveling and publicly documenting this gigantic scandal was not what motivated us, nor has it been, since the beginning. Rather, we merely wished to right some wrongs and return to the people of Africa some valuable IP resources critically needed for the ongoing development of the Internet in Africa. Nonetheless, it would have been, I think, at least minimally respectful if either AFRINIC or (now) RIPE had taken a moment to at least mention our names and our very evident, abundant, and key contributions towards exposing this whole huge mess. Neither organization, it seems, has thus far elected to do so publicly. Such is the reward, or lack thereof, of a job well done. Regards, rfg

3 3

Re: [db-wg] Deprecation of whitepages
by Randy Bush 30 Jan '21

30 Jan '21

>>> The DB team maintains this list and will exclude an object on request. >> please exclude all objects i might wish to look up. perhaps i was being too subtle. the original purpose of the whois database was for operators to contact each other for coordination and sharing of exciting events. some of us dinosaurs still use it for these mundane purposes. > Blanket whitelisting won't work it is what we have today. the proposal is to change that. i am trying to understand how this would make my (a paying customer's) job easier. randy

2 1

Fwd: proposal: new attribute 'geofeed:
by Maria Stafyla 27 Jan '21

27 Jan '21

Hi Denis, all Please allow us some time to look into this and we will get back to you with our feedback next week. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC > ---------- Forwarded message --------- > From: denis walker <ripedenis(a)gmail.com> > Date: Thu, 7 Jan 2021 at 15:59 > Subject: Re: [db-wg] Fwd: proposal: new attribute 'geofeed: > To: Hank Nussbacher <hank(a)interall.co.il>, <legal(a)ripe.net> > Cc: Database WG <db-wg(a)ripe.net> > > > HI Hank, colleagues > > Whilst I can't answer your basic question, I could say that if the > IETF approves a change to RPSL, with the RIPE Database data model > based on RPSL, in principle we should implement the RPSL change. > > Perhaps another question, to the RIPE NCC legal team, if I have a > fixed IP address or block of addresses, is this geofeed location data > personal data under the terms of GDPR? > > cheers > denis > co-chair DB-WG > > On Wed, 6 Jan 2021 at 07:01, hank--- via db-wg <db-wg(a)ripe.net> wrote: >> I guess I am not understanding something. >> Why do we need a geofeed attribute? What problem are we trying to solve? >> >> I understand why each block of IPs needs to be associated with a >> country, so that certain language specific auto-customizations will >> work. But what purpose is there to know that a /24 is in central >> Amsterdam? Is the purpose to assist marketers in geo-targetted sales? >> Is the purpose for network engineering (not sure what major problem >> we have that needs this)? >> >> Is the purpose to know where you are so that in the event of an >> emergency (terror, tornado, etc) you can get emergency targeted >> alerts? If so, then the geofeed has to be at the /32 level and since >> many if not most IPs are mobile, and that is where you will get the >> alert from - from your cellphone provider, I still don't quite >> understand the reason for a geofeed tag. >> >> Can someone clue me in? >> >> Thanks, >> Hank >> >> Caveat: The views expressed above are solely my own and do not express >> the views or opinions of my employer >> >>

5 5

Fwd: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed
by Nick Hilliard 22 Jan '21

22 Jan '21

196.52.0.0/14 seems to have been revoked by afrinic: > $ whois -h whois.afrinic.net " --list-versions 196.52.0.0/14" | grep -i delete > % This object was deleted on 2021-01-16 05:56 > $ Regarding cleanup of route: objects for this this (and other) unregistered address space in the ripe irrdb, can this just be done? Or is it necessary to create a policy to ask the NCC to do it? Nick -------- Forwarded Message -------- Subject: [anti-abuse-wg] 196.52.0.0/14 revoked, cleanup efforts needed Date: Wed, 20 Jan 2021 05:00:49 +0400 From: Ostap Efremov <kkind690(a)gmail.com> To: anti-abuse-wg(a)ripe.net Hi, 196.52.0.0/14 <http://196.52.0.0/14> was recently revoked. Before it was revoked, the whois for this /14 was: inetnum: 196.52.0.0 - 196.55.255.255 netname: LogicWeb-Inc descr: LogicWeb Inc. descr: 3003 Woodbridge Ave descr: Edison, NJ 08837 country: ZA remarks: ============REMARK==================== remarks: The custodianship of this IP prefix is presently remarks: in dispute. A police investigation is on-going remarks: and AFRINIC reserves the right to remarks: reclaim this IP prefix at anytime. remarks: ============REMARK=================== However, now, this /14 has been revoked by AFRINIC. Do a whois on it and you will see, it's unallocated. I believe this /14 was under control from our big friend from Israel, but I don't remember. This does not matter however. But, sadly there are about 367 ip ranges being announced from this /14 https://pastebin.com/raw/MHaW3nPe From about 71 unique ASN's This is a BOGON, unallocated space. I would appreciate if any network that is on that list and on this mailing list, would stop announcing parts of this hijacked /14. I reached out to RADB to remove all the radb entries concerning this /14, however after 72 hours they still haven't. This is not an ignored ticket, we have escalated internally with our RADb admins and they are looking into it. I will let them know that you are looking for a update and we will provide it as soon as possible. How is it possible that they can't just delete all entries? It is UNALLOCATED SPACE, it shouldn't be routed, it shouldn't have radb. https://www.radb.net/query?advanced_query=1&keywords=-M+196.52.0.0%2F14&-T+… I have also tried to post about this massive source of BOGONS on the nanog mailing list, however, they rejected my posts. Most likely because it possibly concerns "that one guy from Israel", however the nanog moderators refused to comment while continuing to reject my posts. Their self-censorship is very destructive and harmful. I hope that if this list is moderated, I will not have any trouble posting about this issue. Greetings, Ostap.

3 3

Address Assignment Practices in IPv4 and IPv6
by Stephen D. Strowes 21 Jan '21

21 Jan '21

Hi all, We've published a study on the stability of IPv4/IPv6 assignments in domestic ISPs, and the size of the IPv6 prefixes that networks typically assign to subscribers. We look at this from two different angles: what can we measure from RIPE Atlas, and what do operators state in the RIPE Database? In particular, understanding the size of IPv6 delegated prefixes is important for applications such as host reputation & blocklists, geolocation, and research on network measurement. The RIPE Database offers the community a way to share information on their prefix delegations, and deserves some attention! Read more here: https://labs.ripe.net/Members/stephen_strowes/address-assignment-practices-… Cheers, S.

1 0

Org-types
by Cynthia Revström 20 Jan '21

20 Jan '21

Hi DB-WG, This may have been discussed in the past but a quick search didn't yield much. Is there any reason for why ORG-NCC1-RIPE is marked as an LIR and not an RIR? Does RIR imply another RIR? I personally feel like marking the NCC as a member of itself is a bit odd, but honestly this is so minor so I understand if it was just not considered much. I noticed that there is currently only one RIR org (ORG-AFNC1-RIPE) which I assume came about as a result of the ERX process. (sidenote: ORG-AFNC1-RIPE is not referenced by anything except the role object anymore, so it might be somewhat redundant at this point) Other related info I found: Aside from the org-types of "LIR" and "OTHER" there are ~2300 orgs. There is a RIR, an IANA, and a WHITEPAGES. But the rest are "OTHER" but with differing capitalization (mainly Other and other). -Cynthia

4 5

Creating route objects without mnt on existing ones
by Patrick Velder 16 Jan '21

16 Jan '21

Hi there It seems to be impossible to create route objects for inet(6)nums, if there are other route objects to which your maintainer has no access. Even if you have mnt-by + mnt-routes on the inet(6)nums. Due to that, it's much more difficult to create new route objects for our customers, as we have to contact the maintainer of all existing objects in order to get mnt-by/mnt-routes on their route objects. In my opinion, that makes zero sense. If you have mnt-by/mnt-routes on an inetnum, you should be able to create objects, regardless of existing ones. Best regards Patrick

3 3

Re: [db-wg] Fwd: proposal: new attribute 'geofeed:
by hank＠interall.co.il 12 Jan '21

12 Jan '21

I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve? I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)? Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag. Can someone clue me in? Thanks, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer

8 13

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

proposal: new attribute 'geofeed:'
by Job Snijders 07 Jan '21

07 Jan '21

Dear DB-WG, Some colleagues are working to address the never-ending-story of 'where the heck are IPs geographically?'. This problem space has been brought up numerous times in the Database Working Group, but we never managed to solve it. As with all compsci problems adding a layer of indirection can help ;-) This current draft suggests overloading the RPSL 'remarks:' field with a structured attribute value, however I suspect we would do ourselves a disservice to overload a 'remarks:' field. Instead it would be better to add a 'geofeed:' attribute to the RPSL inetnum/inetnum6 class dictionary, which as value contains a URL with http or https scheme. The draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds The value of the attribute could be validated using something like "org.apache.commons.validator.UrlValidator", the attribute would look like this, only valid in the inetnum/inet6num: "geofeed: [optional] [single] [ ]" Example object: inetnum: 192.0.2.0 - 192.0.2.255 netname: EXAMPLE country: NL geofeed: https://example.com/geofeed.csv ... snip ... source: RIPE What do others think? Kind regards, Job ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added https://github.com/irrdnet/irrd/issues/396

15 35

Cleanup of trailing dot in "nserver:" attributes in domain objects in the RIPE database
by Edward Shryane 07 Jan '21

07 Jan '21

Dear colleagues, The RIPE NCC database team have found some syntactically incorrect "nserver:" attributes in domain objects in the RIPE database, which contain a trailing dot ('.') character (signifying a fully qualified name). The convention since 2012 has been to strip out this trailing dot in the "nserver:" attribute on update, but a cleanup of existing data was not done when the syntax changed. We now plan to remove this trailing dot from these "nserver:" attributes later today, affecting approximately 544 domain objects (out of approx. 814K total domain objects), in order to make them syntactically correct. We will notify all maintainers of affected objects regarding this change by email. This is informational only, and users do not need to take any action. Regards Ed Shryane RIPE NCC

1 0

NWI-?? Rationalising contact references
by denis walker 22 Dec '20

22 Dec '20

Colleagues I would like to propose a new NWI about contact references in the RIPE Database. Something that has needed to be cleaned up for a very long time. I have written a draft Problem Statement and Solution Definition below. Your comments are appreciated. cheers denis co-chair DB-WG Problem Statement The RIPE Database only uses inheritance for references to abuse contacts. The admin, tech and zone contacts all use local direct references in every resource object. This has resulted in millions of unnecessary, repetitive, redundant references throughout the database. This can make the data difficult to manage and keep up to date if any referenced contact is replaced. A common problem was referencing a PERSON object in thousands of resource objects. When that person leaves the company it requires a mass data update. Adding inheritance to all contact attributes allows for a cleanup and removal of massive amounts of redundant data references. There are millions of assignments to end users with contact references pointing back to the resource holders contacts. It is confusing to have unnecessary, repeated contact references in these assignments. This would simplify the basic structure of the database. I see this simplification as a first step towards removing unnecessary personal data from the database. Solution Definition I would like to suggest adding inheritance to the other three contacts for admin, tech and zone. The only syntactical changes needed are to make "admin-c:", "tech-c:" and "zone-c:" 'optional' in INET(6)NUM, AUT-NUM and DOMAIN objects and add "zone-c:" as an optional attribute in the ORGANISATION object. At the time of implementation nothing needs to be changed. Next time an ORGANISATION object is updated it needs to have a default "admin-c:", "tech-c:" and "zone-c:" added (if it doesn't already have them) if it is a resource holders object (ie if it has an "abuse-c" attribute). Creating new resource objects, eg assignments, or receiving new allocations, won't need to have these contact attributes included if they are the same as a parent object or the default values in the ORGANISATION object. A standard query for a resource object will return the object as it is, including any optional contact attributes contained within that object. Three new query flags, '--admin', '--tech' and '--zone' added to a query for a resource object will return the correct hierarchical contacts for that resource. The RIPE NCC can provide tools for doing cleanups of resource hierarchies to remove redundant contact attributes with an option to list specific objects that should keep their local values.

1 0

New on RIPE Labs: Impact of NWI-10 on Country Codes in Delegated Statistics
by Boris Duval 22 Dec '20

22 Dec '20

Dear colleagues, In this new article on RIPE Labs, Rene Wilhelm and Stefania Fokaeos quantify the changes that were made to the Extended Delegated Statistics after the RIPE NCC implemented phase 1 of Numbered Work Item 10 (NWI-10): https://labs.ripe.net/Members/wilhelm/impact-of-nwi-10-on-country-codes-in-… Kind regards, Boris Duval RIPE NCC

1 0

Whois Release 1.99
by Edward Shryane 21 Dec '20

21 Dec '20

Dear Working Group, RIPE Database release 1.99 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 21st December. This release includes the following main changes: * NWI-10: require -mnt suffix * Filter out sensitive information in API response on exception * Return 'invalid option supplied' on invalid version number given to --diff-version * Allow *any* CORS origin on RDAP GET requests by default (as recommended by RFC 7480). * New dummifier for RC environment * Enable TCP_NODELAY in NRTM and query connections 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

2 3

NWI-10: Phase 1 Implemented
by Stefania Fokaeos 19 Dec '20

19 Dec '20

Dear colleagues, We are pleased to announce that we have implemented Phase 1 of NWI-10: Definition of Country. The following updates took place as part of the implementation: 1. ORGANISATION objects with "org-type:" 'LIR' have been updated to include a new "country:" attribute. The Country Code displayed in this attribute is the country in which the resource holder is legally based 2. The Country Code (CC) has also been updated in the Extended Delegated Statistics file when there was a mismatch between the file and the new attribute. These resources have now as "CC" the same Country Code that is visible in the respective ORGANISATION object If you notice that your Country Code is incorrect, you can contact us. Please note that we might ask you for supporting documentation to justify the update. In the meantime, we are continuing to work towards Phase 2 of NWI-10 and will keep you updated about our progress. You can read more about our implementation plan and the different phases of NWI-10 on RIPE Labs: https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes If you have any questions about the implementation of NWI-10, please send an email to <support(a)ripe.net> or <policy-implementation(a)ripe.net>. Happy Holidays and warm wishes for 2021! Kind regards, Stefania Stefania Fokaeos RIPE NCC

3 2

Weirdness in DB files
by Cynthia Revström 17 Dec '20

17 Dec '20

Hi DB-WG, I just noticed that the (at the time of writing, serial 49363913) latest aut-num split db file (possibly elsewhere too) sort of just seems to break at some point. The lines like below simply stop appearing: % Tags relating to 'AS3333' % RIPE-REGISTRY-RESOURCE Here's a section where you can see it happening: https://gist.githubusercontent.com/bitcynth/d81688c6b7587e0179d55b8324535ff… Any clue why this is occurring? or is it just a bug? - Cynthia

3 4

Domain Object Cleanup in the RIPE Database
by Edward Shryane 14 Dec '20

14 Dec '20

Dear colleagues, As mentioned in the Operational update during the DB-WG session at RIPE81, the RIPE NCC will shortly clean up (delete) domain objects without a mandatory "nserver:" attribute. This will affect approximately 1,600 domain objects in the RIPE database, which have not been updated since September 2012. We plan to notify the maintainers of affected objects today, and ask them to add "nserver:" attributes to any objects they wish to keep. We will then delete any remaining domain objects without a mandatory "nserver:" attribute in two weeks from now (on 14th December). Regards Ed Shryane RIPE NCC

1 1