- db-wg - mailman.ripe.net

Last call and final reminder for nominations to the 2022 Rob Blokzijl Award
by Carsten Schiefner 14 Mar '22

14 Mar '22

[Apologies for cross-posting to various RIPE lists] Dear DB WG members - this is the last call and final reminder for nominations to the 2022 Rob Blokzijl Award that will be accepted until this Friday, 18th March, at 23:59 UTC. In seeking nominations for this prestigious award, which was created to celebrate Rob's contributions to the development of the Internet, the Award Committee (https://rob-blokzijl-foundation.org/2021/11/22/2022-award-committee/) is interested to receive nominations of those who have reflected Rob's approach in either a technical or operational capacity. Please give some consideration to nominating individuals - but also teams and groups of people! - in your own community and/or the wider industry in the RIPE region who, in your opinion, deserve to be recognised for their work to make the internet and/or internet community better. To specifically have this emphasised again after some according queries: nominations of teams and groups of people are very well possible and wished for as well in case their collective work would match the criteria of the call as laid out! The Award Committee is particularly interested to receive nominations of contributors who, in addition to their own contributions, have also supported and enabled others anywhere in the world. Also, the Award Committee would like to encourage those making nominations to consider not only the community members in the later stages of their careers or who are widely known but also those who may have contributed greatly in the springtime of their career or discreetly for the greater good or who may be considered to be part of an unrepresented group. And last but not least: those of you who previously have made a nomination other than Wilfried Woeber, the 2018 awardee, may want to consider resubmitting a nomination. The complete details of the call and the nomination process can be found at: https://rob-blokzijl-foundation.org/2021/11/25/call-for-nominations-2022/ Best wishes and kind regards Carsten (on behalf of the Award Committee)

1 0

Removing Apache Proxy Servers from DB Services
by Edward Shryane 02 Mar '22

02 Mar '22

Dear Colleagues, Next Tuesday, 1st March, the DB team plan to remove the Apache httpd proxy servers for the following services: * https://apps.db.ripe.net/ * https://rdap.db.ripe.net/ * https://rest.db.ripe.net/ * https://syncupdates.db.ripe.net/ This will allow us to simplify our production environment, reducing operational work and maintenance. Be aware that URL validation will be stricter after this change. For example, the following will return a 400 Bad Request: * Empty path segments (i.e. '//') * Encoded path separators (i.e. %2F for '/') * Encoded query separator (i.e. %3F for '?') Please test your client using the TEST environment: https://www.ripe.net/manage-ips-and-asns/db/ripe-test-database or the Release Candidate environment: https://www.ripe.net/manage-ips-and-asns/db/release-notes/rc-release-candid… Regards Ed Shryane RIPE NCC

1 1

Clear up of old issues - Whiepages
by denis walker 01 Mar '22

01 Mar '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. The first issue is Whitepages. This is a feature from about 10+ years ago. It was intended to preserve the PERSON object in the RIPE Database and protect it from automatic deletion if it is not referenced from any operational data. It was to use the RIPE Database as a phone book for well known people in the industry who may not be resource holders. There are many other ways to provide such contact details today. It was only ever used by a handful of people. The RIPE NCC now has other ways to preserve ROLE objects if needed, for example if used by RIPE Atlas users. The chairs recommend removing this feature from the RIPE Database. If you need a ROLE object to be preserved, contact ripe-dbm(a)ripe.net to discuss. cheers denis co-chair DB-WG

4 8

geofeed issue: can't add geofeed attribute to PI /48
by Job Snijders 28 Feb '22

28 Feb '22

Dear all, Like all good netizens, I tried to align information I publish in the RIPE database to reality, but there is an obstacle: https://sobornost.net/~job/geofeed.png """Adding or modifying the "geofeed:" attribute of an object with a prefix length greater or equal to 48 is not allowed.""" No such restriction exists if you use the 'remarks: Geofeed' approach, as demonstrated here: $ whois -h whois.ripe.net 2001:67c:208c::/48 | grep Geofeed remarks: Geofeed https://sobornost.net/geofeed.csv I appreciate concerns about privacy, but I'm not wholly convinced restricting /48s from having a proper 'geofeed:' attribute is the best path forward. How does the working group feel about this restriction? Is it useful? Should it be lifted? If the latter, what would be the process? Kind regards, Job

14 52

Clear up of old issues - NWI-4 role of status: field
by denis walker 28 Feb '22

28 Feb '22

Colleagues The co-chairs recently had a zoom meeting with the RIPE NCC. One of the things we discussed was clearing up a number of old issues. We need to clear the deck and move on with new and perhaps more relevant issues. We will address a number of issues for the last time. In some cases the chairs will make a recommendation. As these are quite old issues, we will take silence as consensus for the chair's recommendation. NWI-4 https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html This item has been 'open' for 6 years, and it was talked about before then. So we do need to come to a decision on how to move forward or drop it and just accept the constraints. To describe it in simple terms, it is about documenting an assignment the same size as an allocation. One idea that was put forward was to allow a twin attribute primary key for the INETNUM object: range/status similar to the primary key of a ROUTE object: prefix/origin. The RIPE NCC's impact analysis ruled out this option. This change would cut so deep into the software, changing core functionality of the data model with a ripple effect right across the system. The only other option currently on the table is one I put forward to allow the "status:" attribute to be 'multiple'. Business rules would then limit the use of this feature to only one use case. If the status is 'ALLOCATED PA' a second "status:" attribute would be allowed with the value 'ASSIGNED PA'. I don't think any other use case would require it. Where 2 status attributes exist, only the one with 'ASSIGNED PA' could be removed. This would be a relatively straightforward change to the software. Whilst "descr:", "country:", "admin-c:" and "tech-c:" are already multiple attributes, "org:" and "abuse-c:" are only single. They could also be made multiple in this one use case but that may have further consequences. It depends how far you want to go in fully defining an assignment or just documenting the fact that this allocation is also an assignment. Any change to allow a range to be dually represented as both an allocation and an assignment may break scripts people use to parse the objects returned by a database query. That is unavoidable. But it may affect some users' views on whether or not this is a sufficiently important problem that needs to be solved. Perhaps now there are so many /24 allocations, it raises the importance of being able to document an allocation as an assignment. There is of course an even simpler (pseudo) option, following on from the geofeed discussion, to define a convention to add: "remarks: status: ASSIGNED PA" Which throws us straight back into the debate on parsing "remarks:" attributes. The database software should not do so. But users querying this data can do whatever they wish. As Randy says, its interpretation is in the eye of the beholder. The chairs make no recommendation on this item. But if there is no discussion we will simply mark NWI-4 as cancelled. cheers denis co-chair DB-WG

1 1

Re: [db-wg] geofeed issue: can't add geofeed attribute to PI /48
by Jeroen Massar 14 Feb '22

14 Feb '22

> Hi Job, Colleagues, > > On 3 Jan 2022, at 13:36, Job Snijders via db-wg <db-wg at ripe.net> wrote: > > > > ... > > I appreciate concerns about privacy, but I'm not wholly convinced > > restricting /48s from having a proper 'geofeed:' attribute is the best > > path forward. > > > > How does the working group feel about this restriction? Is it useful? > > Should it be lifted? If the latter, what would be the process? > > > I will ask our Legal team to re-examine the prefix size restriction and keep you and the DB-WG informed. > Regards Ed Shryane RIPE NCC Hi Ed, Did something come out of this? It is a very silly restriction, especially for PI /48's but also for the simple fact that one can register very small prefixes (I've done IPv4 /28 and IPv6 /56) in the actual geofeeds file. Greets, Jeroen

2 1

update on draft-spaghetti-grow-nrtm-v4-00
by Sasha Romijn 04 Feb '22

04 Feb '22

Hello all, FYI, following up on various discussions and the BoF we had on this list about NRTMv4 and NWI-12, a draft has now been submitted. If you’re interested in discussing further details of the proposed protocol, do send your questions and comments to that mailing list. Sasha Forwarded message: > From: Sasha Romijn > To: grow(a)ietf.org > Subject: [GROW] draft-spaghetti-grow-nrtm-v4-00 > Date: Fri, 04 Feb 2022 13:04:48 +0100 > > Hello, > > We’ve submitted a draft for the Near Real Time Mirroring Protocol (NRTM) version 4: https://datatracker.ietf.org/doc/draft-spaghetti-grow-nrtm-v4/ > > This document specifies a one-way synchronization protocol for Internet Routing Registry (IRR) records. The protocol allows instances of IRR database servers to mirror IRR records, specified in in the Routing Policy Specification Language (RPSL), between each other. > > NRTMv4 is intended as a replacement of current synchronization methods mainly based on FTP downloads and NRTM version 3, which have many problems that are addressed in NRTMv4. > > The need for this originated from experiences by users of IRRD v4, and discussions in the RIPE Database working group, tracked under NWI-12: > https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html > > The broad strokes of this draft were previously discussed in a BoF in the RIPE Database wg, which included several operators of IRR databases, and responses were overall positive. I am also the maintainer of IRRD v4, one of the most widely used IRR database servers, and will implement it in there. > > I’m proposing this draft for adoption by this working group. I would also be happy to present it in the IETF 113 session. > > Sasha Romijn > > _______________________________________________ > GROW mailing list > GROW(a)ietf.org > https://www.ietf.org/mailman/listinfo/grow

2 1

RDAP Conformance Level "cidr0"
by Benjamin Pereto 26 Jan '22

26 Jan '22

Dear RIPE DB wg, The RDAP for querying ip and network information on rdap.db.ripe.net is really useful. Currently you support the rdapConformance level "rdap_level_0" and this is missing the CIDR or Prefix Information about the Length/Mask. Other RIR have implemented a rdap conformance level "cidr0" for this: * https://rdap.arin.net/registry/ip/9.9.9.9 * https://rdap.apnic.net/ip/1.1.1.1 with the desired information: "cidr0_cidrs": [ { "v4prefix": "1.1.1.0", "length": 24 } ] Information about the Origin ASN is also available by arin with "arin_originas0", which is also very helpful, but the format seems to be arin specific and not standardized. May I suggest to also implement the cidr0 level, or even additionally the "origin as" for the RIPE DB RDAP? Kind regards, Benjamin

2 1

RIPE Database Quarterly Planning Q1 2022
by Edward Shryane 11 Jan '22

11 Jan '22

Dear colleagues, We have now published our Q1 2022 planning for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning/ This is the second quarterly plan we have published. The previous plan for Q4 2021 is also available so you can see how we progressed and see what was completed and what will continue in Q1 2022: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning/archived-pla… If you have comments or questions around our plans, we hope you'll discuss with us on the list or you can always contact us directly at ripe-dbm(a)ripe.net. Regards, Ed Shryane RIPE NCC

1 0

Whois Release 1.102.2
by Edward Shryane 20 Dec '21

20 Dec '21

Dear Colleagues, We have deployed Whois release 1.102.2 to production to fix further vulnerabilities in the Log4j library. The only change from Whois release 1.102.1 is to update the log4j dependency from 2.15.0 to 2.17.0. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.102.1
by Edward Shryane 13 Dec '21

13 Dec '21

Dear Colleagues, We have deployed Whois release 1.102.1 to production to fix the Log4Shell vulnerability: https://www.lunasec.io/docs/blog/log4j-zero-day/ The only change from Whois release 1.102 is to update the log4j dependency from 2.14.1 to 2.15.0. We previously put a workaround in place last Friday morning to mitigate this vulnerability, we don't believe it has been exploited. Regards Ed Shryane RIPE NCC

1 0

Whois Release 1.102
by Edward Shryane 07 Dec '21

07 Dec '21

Dear Colleagues, RIPE Database release 1.102 has been deployed to the Release Candidate environment. We plan to deploy to production on Tuesday 7th December. This release includes the following main changes: * NWI-13: Geofeed (#937) * Support base64 encoded signed update messages (sent by Thunderbird 78+) (#942) * Updated "geoloc:" help text (#929) * Support IDN in outgoing mail update notifications (#888) 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 2

RIPE Database Purposes - Video presentation
by denis walker 23 Nov '21

23 Nov '21

Colleagues In advance of my presentations tomorrow, if you have a spare 15 minutes please watch the pre-recorded presentation: https://ripe83.ripe.net/wp-content/uploads/presentations/DB_WG-Denis_Walker… cheers denis co-chair DSB-WG

1 0

NWI-13: Geofeed Impact Analysis
by Edward Shryane 17 Nov '21

17 Nov '21

2 3

Agenda RIPE83 - Database Working Group
by William Sylvester 15 Nov '21

15 Nov '21

Dear Database Working Group Members, Below is the agenda for the Database Working Group for RIPE83. 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 & Cloud Migration Update– 15 mins Edward Shryane, RIPE NCC C. UI Update – 15 mins Rehan Syed, RIPE NCC D. Database Task Force Update – 15 mins Shane Kerr, Database Task Force E. RIPE Database Purposes – 10 mins Denis Walker, Co-Chair DB-WG Z. AOB (open discussion)

2 1

NRTM v4 Requirements Gathering BoF
by Edward Shryane 01 Nov '21

01 Nov '21

Dear Colleagues, I'd like to hold a BoF meeting next week to gather requirements for NRTM v4 and look for a way forwards to an implementation. For background reading on NRTM v4, please read the NWI-12 Problem Definition: https://www.ripe.net/ripe/mail/archives/db-wg/2020-November/006720.html If you are interested in this discussion, please register your interest using this optional Doodle pool to indicate any convenient time(s) for you: https://doodle.com/poll/bfmcaxuyb5v8iwsu?utm_source=poll&utm_medium=link I will close the poll on this Wednesday evening and reply to the DB-WG with a meeting request. You don't need to register to attend. Regards Ed Shryane RIPE NCC

2 3

RIPE Database Requirements Task Force: Final Draft Published
by Bijal Sanghani 26 Oct '21

26 Oct '21

Dear Colleagues, We have now published the final draft of the RIPE Database Requirements Task Force: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/requirements-f… This version takes into account the feedback received from the community on our intermediate draft published in July. Thank you all for providing feedback. Here are the main changes/additions; - Added a word about ENUM and geolocation - Added a section to explain the document structure - Clarified when the historical data was first added to the RIPE Database and when it was made available to users - Rephrased the research purpose and added a separate section Please note that each recommendation will be considered separately by the community and the relevant working groups. Kind regards, Bijal Sanghani For the RIPE Database Requirements Taskforce

3 2

NWI-12 NRTM v4 Solution Definition
by Edward Shryane 19 Oct '21

19 Oct '21

Dear Colleagues, Following the Requirmements Gathering BoF yesterday, I'd like to propose Sasha Romijn's NRTM v4 protocol as a Solution Definition for NWI-12 "NRTM v4". Please see https://github.com/mxsasha/nrtmv4/ for more details and feel free to comment on it. Once this draft proposal is finalised, and if we have consensus from the DB-WG, the RIPE NCC will work on an implementation analysis. Regards Ed Shryane RIPE NCC

1 0

Bogon route object cleanup
by Ronald F. Guilmette 08 Oct '21

08 Oct '21

It seems that we never really settled the question of route objects that make reference to the following reserved IP blocks. 192.31.196.0/24 192.88.99.0/24 2001::/32 2002::/16 2011:4188::/48 Note that route objects referring to these IP blocks are *not* present in the route registries of any RIR other than RIPE. I am in favor of including route objects that reference any of these reserved blocks in the ongoing cleanup. My recollection is that Cynthia Revstr�m also expressed support for including any and all such route objects in the current ongoing route object cleanup. Are there any objections at the present time to including such route objects in the ongoing cleanup? Regards, rfg

6 6

RIPE Database Requirements Task Force – Draft Report Published
by Bijal Sanghani 04 Oct '21

04 Oct '21

Dear colleagues, The RIPE Database Requirements Task Force has just published a draft report for your review: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/the-ripe-datab… In this third draft, we’ve added new recommendations and edited our document based on feedback received via emails, survey and during our third BoF in May. Please review this draft and share any comments on the ripe-list before Friday, 13 August 2021. The task force will reconvene in August to discuss the feedback received and work on its final report that will be published ahead of RIPE 83. We look forward to your feedback. Best Regards, Bijal Sanghani

5 9

Two Proposals
by Ronald F. Guilmette 01 Oct '21

01 Oct '21

PROPOSED 1) RIPE NCC shall be tasked to begin updating the following file on a near real-time basis, as number resource assignments are transferred either into or out of the authority of RIPE: ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest 2) RIPE NCC shall be tasked to begin making the above file available for incremental remote update via the rsync protrocol. RATIONALE Background At the present time the most reliable and up-to-the-minute information indicating which RIR any given number resource is being administered by is contained within the so-called "daily stats files" that are generated and published by the five RIRs: ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-latest ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest ftp://ftp.apnic.net/public/apnic/stats/apnic/delegated-apnic-extended-latest ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest ftp://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-latest Additionally, a single file representing the union of all of the above five files, along with additional data relating to (some but not all) IANA reserved number resources is also available: https://nro-extended-stats-from-rpki-team-prod.s3.eu-west-1.amazonaws.com/n… Note however that the data in this (NRO stats) file lags behind the contents of the five RIR daily stats files, and the content of this file is therfore often less fresh and up-to-date than the information contained in the five RIR stats files. Problem Statement (Proposal 1) Because the five RIR stats files are only updated once a day, and at different times for each RIR, and because number resources are, with increasing frequency, being transfered between regions, it is nowadays frequently the case that there will be, in effect, instances of "version skew" between the five RIR stats files. Instance of such inter-RIR stats files version skew can render it impossible to know, based on the stats files, which RIR currently administers a given number resource. Instances of internet-RIR stats file version skew can arise, and in practice they actually do arise as follows: *) RIR 'A' transfers a number resource `R' to RIR `B'. *) RIR `B' records its administration of `R' in its stats file which is then published within 1 hour. *) RIR `A' records the fact that it no longer administers `R' by removing the associated line from its stats file, and RIR `A's stats file is then published 23 hours later. Under the above scenario, the union of all five of the daily RIR stats files will indicate that *both* RIR `A" and also RIR `B' are the responsible RIRs for the resource `R' for a period of 22 hours. An actual example: As of approximately 07:13 (-0700 / PDT) on 2021-09-17 the following blocks were listed in *both* the stats file for ARIN and also the stats file for RIPE: 140.228.32.0/19 140.228.64.0/19 (Evidence indicates that these 2 block have just been transferred from administration by the ARIN region to administration by the RIPE region.) The problem of version skew between the various daily stats files that are currently published by the various RIRs could be largely or entirely eliminated if all five RIRs henceforth began to update these files on a near real-time basis. RIPE can and should begin doing this as an example to the other RIRs, which may then follow suit. Problem Statement (Proposal 2) The RIR daily stats files, including the one that is generated and published by RIPE NCC, consist of plain text files which are themselves composed of a sequence of plain text lines. As a general matter, very few of these lines change, even over time scales as long as a month. Changes to these files, if any, are entirely minimal when viewed over even shorter time scales, e.g. a day or less. The rsync protocol and rsync servers and clients are especially adept at keeping remote copies of exactly such plain text files up-to-date and synchronized with a master copy stored elsewhere on the Internet. They do so while minimizing bandwidth usage by transfering only those portions of a given file that have changed since the last time a local mirrored copy of the file was updated. Publishing RIPE's stats file via rsync would thus be beneficial to all concerned by minimizing bandwidth usage on both the sending and receiving end. Ideally, RIPE NCC could and should take the lead in making its stats file available via rsync. Once it has done so, other RIRs can be encouraged to follow suit and do likewise with their own daily stats files. Regards, rfg P.S. On a personal note I find it nearly unfathomable that these "daily" stats files are being updated and published only once a day. This seems to me almost reminicent of technological solutions considered appropriate in the prior century.

3 5

Upcoming Usability improvements to the RIPE Database Web Search page
by Edward Shryane 01 Oct '21

01 Oct '21

Dear colleagues, In the RIPE NCC's Activity Plan 2021, we planned to make usability improvements to the RIPE database, including the web search feature. My colleague Rehan Syed Muhammad has now published a RIPE Labs article detailing some upcoming improvements: https://labs.ripe.net/author/rehan_syed_muhammad/four-ideas-for-quicker-que… We plan to make incremental changes to the search page in the coming months. We will keep the community informed, and we welcome any feedback. Regards Ed Shryane RIPE NCC

1 1

RIPE Database Planning Q4 2021
by Edward Shryane 30 Sep '21

30 Sep '21

Dear colleagues, We are now publishing our quarterly planning for the RIPE Database: https://www.ripe.net/manage-ips-and-asns/db/quarterly-planning Our goals here are to make it clear what we are working on in the coming months, and also to get discussion around those plans so we can make developments based on community input. If you have comments or questions around this, we hope you'll let us know on the list or you can always contact me and the team directly at <ripe-dbm(a)ripe.net>. Kind regards, Ed Shryane Senior Technical Analyst RIPE NCC

2 1

Cosmetic changes to the RIPE Database
by denis walker 19 Sep '21

19 Sep '21

Colleagues There have been a number of cosmetic changes to the RIPE Database in recent months. There is no agreed procedure for making these type of changes. In particular the extent to which the community is informed. Examples of the type of changes we are talking about are: 1/ When the ORGANISATION object addresses were synced with the internal registry the address lines were entered in the wrong order. The RIPE NCC did a cosmetic update to reverse the order of the address lines. It had no operational impact at all. 2/ Capitalisation of status values. Again this had no operational impact at all. We would like some feedback from the community about how you want these type of cosmetic changes announced. We see four possible options: 1/ individual notification in advance to all affected maintainers plus general announcement on the mailing list plus update notifications (full disclosure) 2/ general announcement on the mailing list plus update notifications 3/ general announcement on mailing list and silent update (no notifications) 4/ no announcement, no notifications, just do it without disturbing anyone (totally silent) Some points to note: -In all cases the object history will show the changes. -There is also an option to not change the "last-modified:" attribute if you don't want that to reflect cosmetic changes. -The full disclosure option (1) can sometimes lead to considerable extra work load for the RIPE NCC. If people are individually told in advance of a change they don't always realise it has no operational impact and ask questions. Every question opens a ticket that needs to be manually addressed. -Perhaps options 2 or 3 are the most practical? Your feedback is welcomed... cheers denis co-chair DB-WG

4 5

running in whios-circles...?
by Frank Habicht 18 Sep '21

18 Sep '21

Hi, so on my self-hosted MTA I got an email [unsure about good intentions, thus checking origin] from 82.156.114.62 Whois directed to ripe, ripe said it's iana, iana said it's ripe [ BGP said ..... 4134 23724 45090 ] and ..... there's a route object in APNIC: route: 82.156.0.0/15 origin: AS45090 descr: Tencent Cloud Computing (Beijing) Co., Ltd 309 West Zone, 3F. 49 Zhichun Road. Haidian District. mnt-by: MAINT-TENCENT-CN last-modified: 2020-02-24T07:34:42Z source: APNIC and also "inetnum: 82.156.0.0 - 82.157.255.255" (in APNIC) So, I tend to believe that I'm on the wrong list here, because my question turns out to be: can I trust whois.iana.org ? It seems to tell me something different from what APNIC is saying. PS: a prefix containing IP in question is not seen in https://www.iana.org/assignments/ipv4-recovered-address-space/ipv4-recovere… am i right to be confused by the iana answer? who should get 'encouraged' to change something? Thanks, Frank [frank@fisi ~]$ whoisiana 82.156.114.62 [Querying whois.iana.org] [whois.iana.org] % IANA WHOIS server % for more information on IANA, visit http://www.iana.org % This query returned 1 object refer: whois.ripe.net inetnum: 82.0.0.0 - 82.255.255.255 organisation: RIPE NCC status: ALLOCATED whois: whois.ripe.net changed: 2002-11 source: IANA [frank@fisi ~]$ whois 82.156.114.62 [Querying whois.ripe.net] [whois.ripe.net] % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '82.156.0.0 - 82.157.255.255' % No abuse contact registered for 82.156.0.0 - 82.157.255.255 inetnum: 82.156.0.0 - 82.157.255.255 netname: NON-RIPE-NCC-MANAGED-ADDRESS-BLOCK descr: IPv4 address block not managed by the RIPE NCC remarks: ------------------------------------------------------ remarks: remarks: For registration information, remarks: you can consult the following sources: remarks: remarks: IANA remarks: http://www.iana.org/assignments/ipv4-address-space remarks: http://www.iana.org/assignments/iana-ipv4-special-registry remarks: http://www.iana.org/assignments/ipv4-recovered-address-space remarks: remarks: AFRINIC (Africa) remarks: http://www.afrinic.net/ whois.afrinic.net remarks: remarks: APNIC (Asia Pacific) remarks: http://www.apnic.net/ whois.apnic.net remarks: remarks: ARIN (Northern America) remarks: http://www.arin.net/ whois.arin.net remarks: remarks: LACNIC (Latin America and the Carribean) remarks: http://www.lacnic.net/ whois.lacnic.net remarks: remarks: ------------------------------------------------------ country: EU # Country is really world wide admin-c: IANA1-RIPE tech-c: IANA1-RIPE status: ALLOCATED UNSPECIFIED mnt-by: RIPE-NCC-HM-MNT created: 2019-01-07T10:49:20Z last-modified: 2019-01-07T10:49:20Z source: RIPE role: Internet Assigned Numbers Authority address: see http://www.iana.org. admin-c: IANA1-RIPE tech-c: IANA1-RIPE nic-hdl: IANA1-RIPE remarks: For more information on IANA services remarks: go to IANA web site at http://www.iana.org. mnt-by: RIPE-NCC-MNT created: 1970-01-01T00:00:00Z last-modified: 2001-09-22T09:31:27Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.101 (ANGUS) [frank@fisi ~]$

11 28