July 2022 - db-wg - mailman.ripe.net

NWI-14 Authenticating References to Objects
by denis walker 19 Jun '23

19 Jun '23

Colleagues The chairs propose creating NWI-14 for expanding the optional use of the "mnt-ref:" attribute to protect objects from accidental or intentional mis-representation of responsibility. See slide 14 of this presentation for the problem definition: https://ripe78.ripe.net/presentations/129-RIPE78-Operational-Update.pdf We ask the RIPE NCC to add NWI-14 to the list. cheers denis co-chair DB-WG

3 4

Recognisition of Kosovo and adding of LIR signup options with Kosovo as well as XK in inet(6)num
by William Weber 17 Nov '22

17 Nov '22

Hi, As the Netherlands recognise the Republic of Kosovo as sovereign nation (see 1), and the EU does as well (see 2) there should be a way to include the proposed 2 letter country code (XK, see 3) as option for inet(6)num objects. The EU and other multinational organisation (IMF, SWIFT etc., see 4) use this code already since independence in 2008, and it is the currently reserved ccTLD for Kosovo as well. Kosovo also has a unique phone number prefix assigned (+383) by the ITU (see 5). It makes no sense that EU and AP is available (which are not countries, AP is not even in ISO-3166-2), but XK is not. I am aware the the X* series of codes is reserved and not permanently assigned, however UN Security Council resolution 1244/99 (see 6) mandates the use binding to all UN members. Please let me know how to bring in a draft resolution to adopt the ability to use Kosovo as legitimate country option in RIPE database objects, as well as the LIR sign up. It is the ONLY country that is recognised by both the Netherlands and the EU that cannot be used to sign up as a LIR and my client - a Telecoms company in Pristina that wants to stay anonymous at this time to avoid issues with Serbia - feels their right is violated by having to use either Serbia or Albania as billing location, and sees uncertainty in applicable laws and taxation with this. Thank you, William Weber (LIR Portal user: william(a)william.si, multiple LIRs managed) 1: https://web.archive.org/web/20080430070042/http://www.minbuza.nl/en/news/ne… Kosovo.html 2: https://ec.europa.eu/neighbourhood-enlargement/countries/detailed-country-i… 3: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements 4: https://ec.europa.eu/eurostat/statistics-explained/index.php?title=Glossary… 5: https://www.itu.int/dms_pub/itu-t/oth/02/02/T02020000FD0001PDFE.pdf 6: https://www.nato.int/kosovo/docu/u990610a.htm

13 22

RIPE Database Service Criticality Questionnaire
by denis walker 10 Oct '22

10 Oct '22

Colleagues [Apologies to Job for copying your email from the Routing WG but you explained it well :) ] The RIPE NCC has asked the Database WG Chairs to facilitate a working group conversation on framing the RIPE Database service subcomponents in terms of criticality. At the bottom of this email is a form that focuses on three components: confidentiality, integrity and availability. Each component is split into three questions (a, b, and c), a total of 9 questions are being put forward to the working group. We envisage this process to be a public consultation: WG participants can submit (free-form) responses, and also chime in by replying to each other's responses; hopefully bringing us to a degree of consensus in the coming weeks. We believe this is a unique opportunity to help the RIPE NCC! The goal is to help the RIPE NCC develop a deeper understanding of how the moving parts fit together, which in turn helps decide where and how to invest resources. >>> Your feedback is much appreciated! <<< cheers, denis, William DB WG co-chairs ----------------------- FORM STARTS HERE ----------------------- Service Criticality Form - RIPE Database Introduction ------------ This form is used to gather input from the community on the service criticality of the RIPE database. The framework is detailed in https://labs.ripe.net/author/razvano/service-criticality-framework/ The service criticality has three components: * Confidentiality What is the highest possible impact of a data confidentiality -related incident (data leak)? * Integrity What is the highest possible impact of a data integrity -related incident (hacking)? * Availability What is the highest possible impact of a service availability -related incident (outage)? All our services are designed with at least 99% availability, so please consider outages of up to 22 hours. Service Purpose --------------- The RIPE Database is the public internet registry for the RIPE NCC region, comprised of: * Internet Number Registry * Internet Routing Registry * Reverse Delegations The critical parts of the service are: * Query (Port 43, REST API, NRTM, Web Application) * FTP dumps (whole database and split files) The non-critical part of the service is: * Update (REST API, Mailupdates, Syncupdates) Service Criticality ------------------- Please review the following three areas. (1) Global Routing Incident Severity * Low (No / negligible impact) * Medium (One or a few ASes are unavailable) * High (Many ASes in a region are unavailable) * Very High (Global Internet routing disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (2) IP addresses and AS Numbers Incident Severity * Low (No / negligible impact) * Medium (Local disruptions (registration information not being available for some entities)) * High (Regional disruptions (registration information not being available for the RIPE NCC region)) * Very High (Global disruptions (lack of registration information for all AS Numbers and IP addresses)) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter) (3) Global DNS Incident Severity * Low (No / negligible impact) * Medium (Local disruptions) * High (Regional disruptions) * Very High (Global disruptions) Please rate the incident severity (Low to Very High) in the following three areas. Please explain why. (a) Confidentiality (Impact level of incidents such as data leaks) (b) Integrity (Impact level of incidents such as hack attempts) (c) Availability (Impact level of service outage incidents, up to 22 hours per quarter)

2 2

NWI-13 Geofeed Legal Analysis
by Maria Stafyla 26 Sep '22

26 Sep '22

Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: -The RIPE Database is meant to contain specific information for its documented purposes. -Information inserted in the geofeed attribute could in some cases qualify as personal data. -The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. -This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. -The restrictions are now implemented based on the status of the registration. -If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. As mentioned in the Legal Review Impact Analysis, if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered as containing personal data and GDPR will apply. This is why we have proposed to implement restrictions. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the *currently defined* purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

16 44

Re: [db-wg] NWI-13 Geofeed Legal Analysis
by Lutz Donnerhacke 28 Jul '22

28 Jul '22

So the geofeed attribute will be deleted from the database? Do you have a timeframe for this implementation? Von: db-wg <db-wg-bounces(a)ripe.net> Im Auftrag von Maria Stafyla via db-wg Gesendet: Donnerstag, 28. Juli 2022 13:33 An: db-wg(a)ripe.net Betreff: [db-wg] NWI-13 Geofeed Legal Analysis Dear colleagues, Following the legal update we provided on NWI-13: Geofeed at the DB WG session at RIPE 84, here is our analysis in case further discussion on this topic is needed. Executive Summary: - The RIPE Database is meant to contain specific information for its documented purposes. - Information inserted in the geofeed attribute could in some cases qualify as personal data. - The current purposes could explain geolocation information to be inserted only for ‘scientific research into network operations and topology’. - This purpose does not justify the processing of personal data; therefore restrictions had to be put in place to avoid the processing of unnecessary personal data. - The restrictions are now implemented based on the status of the registration. - If the purposes of the RIPE Database have changed in the meantime, this should be established via the community processes and documented. In that case we will re-evaluate the situation and the need for restrictions. Until then, the restrictions remain necessary. Legal Analysis: The RIPE Database is meant to contain specific information for the purposes that are defined in the RIPE Database Terms and Conditions. In terms of the _personal data_ inserted in there, the purpose that justifies its publication is to facilitate the coordination of network operations for the smooth and uninterrupted operation of Internet; this purpose explains why contact details of resource holders or their appointed contact persons are required. Before any new type of personal data is permitted to be inserted in the RIPE Database, we must evaluate if their processing is required for the purposes already defined and their processing can be considered in line with the basic personal data processing principles. Although it is the responsibility of the party inserting personal data to ensure that they have the appropriate legal grounds before doing so, the RIPE NCC has also shared responsibilities with regards to the personal data in the RIPE Database. This is because the RIPE NCC is the party that is making the RIPE Database available and implements the instructions given by the RIPE community. As mentioned in the Legal Review Impact Analysis, if the geofeed attribute is inserted for registrations of assignments that are reasonably assumed to be related to one individual user, then the attribute will be considered as containing personal data and GDPR will apply. This is why we have proposed to implement restrictions. These restrictions are essential to avoid any processing of personal data that is not required or necessary for the currently defined purposes of the RIPE Database and to limit the RIPE NCC's liability as a party with shared responsibilities in relation to the personal data inserted in the RIPE Database. Regarding the _(non-personal) data _inserted in the RIPE Database, it is also paramount that only data that is needed for the defined purposes of the RIPE Database is inserted. According to the RIPE Database Terms and Conditions, introducing the geofeed attribute (with restrictions) would be considered in line and acceptable to be used only for scientific research into network operations and topology (see Art. 3). We also understand that the purposes the RIPE Database must fulfil are not static but evolve over time. The RIPE Database Requirements Task Force has recently concluded its work and, with regard to geolocation, it has established that, although there is an active user group for geolocation data, geolocation itself is not an objective that the RIPE Database should fulfil. If the community's interests have changed since then and it is now agreed that geolocation is one of the purposes the RIPE Database must fulfil, this should be decided via the community's processes and reflected in the RIPE Database Terms and Conditions. In line with the data management principles proposed by the RIPE Database Requirements Task Force, it would be prudent to approach this issue holistically, taking into account that other geolocation information is already provided in the RIPE Database (i.e. geoloc, country code attributes in ORG and resource objects). On the basis of a new purpose for the geolocation information, we could then reassess the situation to understand whether the restrictions on the geofeed attribute are still necessary or whether it is justified to process personal data for this purpose. Kind regards, Maria Stafyla Senior Legal Counsel RIPE NCC

4 3

IRT object postal address
by denis walker 24 Jul '22

24 Jul '22

Colleagues During the conversion we had some time ago about contacts we concluded that no one is going to visit a contact or post them a letter. The IRT object also had a mandatory address attribute that is defined in the documentation as: "This is a full postal address for the business contact represented by this irt object." Does anyone think we actually need a postal address for a contact for a CSIRT team? Cheers denis

5 7

Re: [db-wg] IRT object postal address (denis walker)
by William Weber 22 Jul '22

22 Jul '22

As cybercriminal i wholeheartedly support the idea of removing all personal data from the RIPE DB. That would make my life so much easier. -- William On Fri, Jul 22, 2022 at 12:00 PM <db-wg-request(a)ripe.net> wrote: > Send db-wg mailing list submissions to > db-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/db-wg > or, via email, send a message with subject or body 'help' to > db-wg-request(a)ripe.net > > You can reach the person managing the list at > db-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of db-wg digest..." > > > Today's Topics: > > 1. Re: IRT object postal address (denis walker) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Jul 2022 15:41:58 +0200 > From: denis walker <ripedenis(a)gmail.com> > To: "Ronald F. Guilmette" <rfg(a)tristatelogic.com> > Cc: Database WG <db-wg(a)ripe.net> > Subject: Re: [db-wg] IRT object postal address > Message-ID: > < > CAKvLzuE+RoNgGXL8TU3r4E5dOtOd3uweB9UzFJhgnOmpBruU+g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Ronald > > (For those who don't read long emails...) The bottom line is that this > proposal recommends to remove postal addresses of contacts, not > publish the 'full' postal address of natural persons holding > resources, replace personal data with business data and generally > bring the contents of the RIPE Database into line with the defined > purposes. > > --- > Now to answer Ronald's points... > > You have your own (hidden) agenda Ronald, which is fine. But don't > expect everyone to fall into line behind you. Most people know your > tactics. Repeat the same nonsense and conspiratorial theories over and > over and over again until people believe they must be true. You lock > onto a phrase or even a word and create an entire fear mongering story > around it. Then keep asking the same irrelevant questions and > demanding answers. This is not how to have a professional discussion, > it is a Trump/Johnson style campaign. > > Let's kill off some of your fear stories. I am NOT against > accountability, NOT helping cybercriminals, NOT proposing anonymity, > NOT obfuscating half the database, NOT proposing secrecy and NOT > avoiding transparency. > > As for GDPR, the only person obsessed with it is you Ronald. It is not > even mentioned in the proposed policy text. You use it to confuse all > discussions on the content of the database. GDPR is only one of the > factors concerning the content of the RIPE Database. There are defined > purposes for the database. As the RIPE Database Task Force pointed > out, we should minimise the amount of data needed to fulfil those > defined purposes. That is the overriding principle governing what > should go into the database and what remains in the database. > > Most people did accept that in order to resolve internet operational > issues (one of the main purposes of the database) no one is going to > visit or post a letter to a contact in the RIPE Database. Therefore > contacts don't need postal addresses. Whilst you may feel there is a > need for a postal address for a contact for an IRT object, as Nick > said, the opinions of CSIRT teams are more relevant. > > You have said yourself many times that the database is full of > garbage. When you demand irrelevant data and force people to enter > information they prefer not to provide which is not even covered by > the database purposes, you increase the chances of some people > entering false or misleading information. The only 'crusade' I am on > is to bring the contents of the RIPE Database into line with the > minimum information required to fulfil the defined purposes of the > database and any legal requirements. We can have a healthy discussion > on interpretations of that minimum information, but we should not be > arguing over the principle. Forcing people (with mandatory attributes) > to enter 'interesting' but not relevant information leads to a corrupt > and diluted database that is less useful to anyone. Even optional > attributes that are not relevant, dilute the important information. > > You can wish for any information you like to be in the RIPE Database > Ronald, but if it is not essential for the defined purposes, it is not > going to be there. Feel free to propose your own policies to change > the purposes of the database and store certified photos of all > contacts and their families if you believe that is necessary for your > use of the database...or set up your own database. > > cheers > denis > proposal author > > On Thu, 21 Jul 2022 at 06:01, Ronald F. Guilmette via db-wg > <db-wg(a)ripe.net> wrote: > > > > In message < > CAKw1M3MEHHC63+BfS7P365F0Cw6hcGuOKKq0ZaTS+evtdiZDoQ(a)mail.gmail.com> > > =?UTF-8?Q?Cynthia_Revstr=C3=B6m?= <me(a)cynthia.re> wrote: > > > > >> *) Why is the hiding of information even a priority? > > > > > >Hiding information is good from a privacy standpoint so you have to > > >weigh the benefit of having the data public against the privacy > > >implications of publishing it. (and consider any potential legal > > >issues/requirements) > > > > Transparency is good from an accountability standpoint. And in my > opinion, > > we have far far too little accountability on the Internet. Practically > > every day now one can find stories about "hackers" and "cybercriminals" > > and everyone just shrugs and goes back to work as if this is the way that > > thing have to be, or that they are supposed to be. > > > > My position is simple: If youy want to be anonymous, then get yourself a > > pseudonym account on Twitter, or Facebook, or YouTube, or whatever, and > > then blast away. Or alternatively, get yourself a domain name with all > > of the WHOIS data redacted and then arrange wweb site hosting for that, > > either on one IP of one hosting company, or several. But somewhere up > > the chain there needs to be accountability, always. It is *not* a God- > > given right to have an IP address block or an ASN. It is a privilege. > > And that special privilege should be reserved for those who are willing > > to be held accountable for what goes on upon their networks. > > > > You and Denis are trying to _remove_ accountability from the equation, > and > > I remain steadfast in asserting that this will only benefit criminals. > > > > >> *) Are these deliberate obfsucation steps still being justified on > the > > >> basis of GDPR, or do you now accept as fact that GDPR is irrelevant in > > >> the context of the RIPE data base, and that it does not currently > compel > > >> RIPE to make any changes to the public WHOIS data base whatsoever? > > > > > >Denis has already mentioned in an email regarding 2022-01 that he will > > >not address any more GDPR issues until there has been a legal review > > >as many of us are not lawyers. > > > > I'm sure that I saw someone post here quite recently that he had checked > with > > RIPE legal already, and had already been assured that RIPE is _not_ > facing > > any current or imminent legal jeopardy with the status quo as it now > exists, > > either in relation to GDPR or in relation to any other applicable law or > > regulation. If you need me to do so, I will find that posting in the > archives > > and I'll copy it here. > > > > >While I can't speak for Denis, you have not convinced me that GDPR is > > >somehow irrelevant > > > > I don't see how or why it should be incumbant upon either me or anyone > else > > to persuade either you or Denis that no change needs to be made. You > and he > > are putting forward and supporting this proposal for a _change_ in the > > current status quo. It is thus necessary for you folks to make a > persuasive > > case that a change _is_ needed, rather than for me or anyone else to > make a > > case that it isn't. > > > > >> *) If the goal is to hide information, then why not just take the > entire > > >> RIPE WHOIS data base offline and hide the whole thing behind some > sort of > > >> permission-wall that can only be pierced with a legal warrant? > > >> > > >> (That last question is, of course, the essential point, since that > endpoint > > >> seems rather clearly to be the direction in which this is all headed.) > > > > > >This question is not really an "essential point" in my opinion as > > >there is a big difference between hiding postal addresses and hiding > > >abuse email addresses and route(6) objects. > > > > You are doing just what Denis has done so far in relation to this whole > > thing... You are evading the question. If transparency is "bad" and > > secrecy is "good" then why not take that general principal to its final > > and logical conclusion? Why not just take the whole WHOIS data base > > offline entirely? > > > > It's a simple question. I'd like to see either you or Denis answer it, > > rather than evade it. > > > > > > Regards, > > rfg > > > > -- > > > > To unsubscribe from this mailing list, get a password reminder, or > change your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > > > > ------------------------------ > > Subject: Digest Footer > > -- > > To unsubscribe from this mailing list, get a password reminder, or change > your subscription options, please visit: > https://lists.ripe.net/mailman/listinfo/db-wg > > > ------------------------------ > > End of db-wg Digest, Vol 131, Issue 14 > ************************************** >

2 1

New Version of the RIPE Database Documentation is Available
by Edward Shryane 20 Jul '22

20 Jul '22

Dear Colleagues, The DB team are pleased to announce that a new version of the RIPE Database documentation is now available: https://apps.db.ripe.net/docs/ We are using a common framework that we have across many RIPE NCC technical services, such as RIPEstat, RIPE Atlas, RIS and RIPE IPmap. This framework has some advantages: * Allows us to use a more modern layout that is common across these services. * A built-in search field is now available at the top of each page. * The documentation is stored in Markdown format, making it easier for the team to make changes, and accept outside contributions. * We are now able to deploy changes together with a Whois or DB web application release. Under the hood, the new documentation uses the VuePress framework: https://vuepress.vuejs.org If you prefer not to use JavaScript, or to print or save the entire documentation, it is also available on a single page: https://apps.db.ripe.net/docs/entire-documentation-(HTML) The documentation contents are published on GitHub, please create a pull request or an issue to contribute improvements: https://github.com/RIPE-NCC/ripe-database-documentation Finally, we plan to migrate (redirect) the existing RIPE Database Documentation pages to the new site. https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… Regards Ed Shryane RIPE NCC

2 6

Impact Analysis for Removing Whois Object Tags
by Edward Shryane 14 Jul '22

14 Jul '22

Dear Colleagues, Following is an impact analysis for removing Whois object tags from the RIPE database. Please reply with any questions or comments. Whois object tags was added as a beta feature in 2013: https://labs.ripe.net/author/kranjbar/presenting-object-metadata-in-the-rip… All resources were tagged at that time (inetnum, inet6num and aut-num), but the data was never updated since then. We plan to remove this feature in the next Whois release, both the query flags and tag data. This will impact the RIPE database in the following ways. (1) Tag Data The following tags exist: RIPE Database: RIPE-REGISTRY-RESOURCE and RIPE-USER-RESOURCE AFRINIC Mirror Database: AFRINIC-USER-RESOURCE and AFRINIC-REGISTRY-RESOURCE APNIC Mirror Database: APNIC-USER-RESOURCE and APNIC-REGISTRY-RESOURCE ARIN Mirror Database: ARIN-REGISTRY-RESOURCE and ARIN-USER-RESOURCE Once support for tags are removed, all tag data will be removed from all databases. (2) Whois Query Flags Four query flags were added to support tags: % --no-tag-info % Switches off tagging information. % % --show-tag-info % Switches on tagging information. % % --filter-tag-include % Show only objects with given tag(s) % % --filter-tag-exclude % Do not show objects with given tag(s) Tags are not returned in port 43 queries by default. I have not found these flags in recent query logs for port 43, i.e. they are not used. Once support for tags are removed, an error will be returned if they are used in a query, e.g. % Invalid option: --no-tag-info % %ERROR:111: invalid option supplied % % Use help query to see the valid options. (3) REST API The query flags for tags are not supported by the Whois REST API. If any are included in the "flags" query parameter in a search, a 400 Bad Request is returned. However tags are returned by the Whois search and lookup endpoints by default, if present, within the /whois-resources/objects/object/tags/tag element. Once support for tags are removed, they will not be returned by the Whois REST API. (4) Web Application Query and Lookup The DB web application query and lookup pages uses the Whois REST API. However tags are not displayed if returned by the REST API. (5) Database Dump and Split Files The nightly database dump and split files contain tags as a comment following some resources, e.g. % Tags relating to 'AS3333' % RIPE-REGISTRY-RESOURCE Once support for tags are removed, these comments will not appear between RPSL objects. Regards Ed Shryane RIPE NCC

1 0

Non-RIPE INRs in an Example returned by RIPE Whois DB Query Service
by Sylvain Baya 12 Jul '22

12 Jul '22

Dear DB-WG, Hopefully this email finds you in good health! While exploring some RIPE Whois DB classes [1], i discovered some examples, i thought to be inappropriate [3]. ...i would like to draw to your attention, on the presence of some INRs [2] managed [3] by an other RIR, which appear in content returned when the RIPE Database is queried [2]. __ [1]: <paste1> cacty@shalom:~$ whois -h whois.ripe.net -t route | grep --regexp="^holes" --after-context=0 holes: [optional] [multiple] [ ] </paste1> [2]: <paste2> cacty@shalom:~$ whois -h whois.ripe.net -v route | grep --regexp="^holes$" --after-context=11 holes Lists the component address prefixes that are not reachable through the aggregate route(perhaps that part of the address space is unallocated). An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers. </paste2> [3]: <https://www.iana.org/assignments/ipv4-address-space/> Maybe it's the only description which contains such non-RIPE INRs; other than of RFC 5737 [4]... __ [4]: <https://www.iana.org/assignments/iana-ipv4-special-registry/> ...but perhaps someone, from the Staff, should check? Thanks. Shalom, --sb. -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] |cmNOG's Structure <https://www.cmnog.cm/dokuwiki/Structure>|cmNOG's Surveys <https://survey2.cmnog.cm/> Subscribe to the cmNOG's Mailing List <https://lists.cmnog.cm/mailman/listinfo/cmnog/> __ *#‎LASAINTEBIBLE‬|‪#‎Romains15‬:33«*Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!*»‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬«*Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!*» (#Psaumes42:2)*

3 6