Dear colleagues,
At RIPE90 I presented a proposal to deprecate the RIPE-NONAUTH database:
https://ripe90.ripe.net/wp-content/uploads/presentations/120-RIPE90-DB-WG-O… (slide 20)
The objects in the RIPE-NONAUTH database are not authoritative, and were created anonymously with a well-known password as out-of-region data in the RIPE IRR database. We don’t know who created this data or whether it is still valid. There are very few (< 100) updates per year, which suggests the data is not being maintained. The RIPE-NONAUTH database has only reduced in size by about 10% since it was created in 2018. The existing cleanup jobs and maintainers are not deleting much data.
Ruediger Volk pointed out that ARIN had only very recently introduced their NONAUTH database, so it was a very short-term temporary source, and that does not predict anything about the longstanding data that has been split out into RIPE-NONAUTH. He suggested that the RIPE NCC analyse whether something that’s supposed to go away is still being used, or else there is a pretty big danger that someone is actually depending on it.
I now present some analysis of the RIPE-NONAUTH database for review. Perhaps we should not retire the RIPE-NONAUTH database completely as we don't know how it is being used, but we could take action to further reduce its size. Your feedback is appreciated.
Should RIPE-NONAUTH Objects Be Returned By Default?
---------------------------------------------------
The RIPE-NONAUTH database is included by default in Whois queries.
This means that any matching object in the RIPE-NONAUTH database is automatically returned in the Whois query response. That includes as-set, aut-num, route and route6 object types. For example, when querying for "AS2561", the matching aut-num object in the RIPE-NONAUTH database is returned.
Additionally, *related* matching objects in the RIPE-NONAUTH database will also be returned by default. For example, when querying for the IPv4 prefix "200.30.0.0/18", the related route object "200.30.0.0/18AS5511" in the RIPE-NONAUTH database is returned.
We found that RIPE-NONAUTH objects are returned only in a small number of cases (about 0.006% of all queries), but there is a risk that clients will inadvertently trust non-authoritative data if the "source:" attribute is not checked. As a workaround, clients can use the "-s RIPE" flag to only query the RIPE database.
Should objects in the RIPE-NONAUTH database continue to be returned by default?
Near Realtime Mirroring (NRTM)
------------------------------
Approximately 20% of NRTM requests query for updates to the NONAUTH database.
Should we continue to support mirroring the NONAUTH database, considering the non-authoritative nature of the data and low rate of updates?
Should RIPE-NONAUTH objects with an exact match in another RIR database be deleted?
-----------------------------------------------------------------------------------
Approximately 31,930 out of 45,754 route(6) objects in the RIPE-NONAUTH database have a matching route(6) object (i.e. matching origin ASN and exactly matching or less-specific prefix) in another RIR’s IRR database.
Approximately 13 out of 67 as-set objects in the RIPE-NONAUTH database have an exactly matching as-set in another RIR’s database.
Approximately 1,840 out of 2,073 aut-num objects in the RIPE-NONAUTH database have an exactly matching aut-num object in another RIR’s database.
Should we delete RIPE-NONAUTH objects which duplicate identically named objects in an authoritative RIR’s database?
Should unrouted RIPE-NONAUTH route(6) objects be deleted?
---------------------------------------------------------
Approximately 33,912 out of 44,647 RIPE-NONAUTH route(6) objects appear in the global routing table (as of 12th July).
Should we remove any NONAUTH route(6) objects which are not announced? Do they serve any useful purpose?
Regards
Ed Shryane
RIPE NCC
Hi,
A while back Cynthia, Dmitry and I looked at the possibility of adding
new contact methods. Dmitry presented this at RIPE 88:
https://ripe88.ripe.net/archives/video/1347/
I've tried to put this into a more complete NWI and offer it for
discussion. The TLDR is:
1) Align the requirement levels for contact methods
2) Let people use new contact methods, like Signal
We hope that by offering the methods people want to use, the contact
data in the RIPE Database can be as useful as is possible.
Kind regards,
Leo
## Problem statement
The requirement level for contact methods for person and role objects
are inconsistent. This is both confusing and inconvenient. This is a
proposal to add flexibility to the contact methods offered at the
database level. It is not a proposal to change policy requirements for
contact methods.
This proposal is limited to admin-c and tech-c contact types.
Our world offers more contact methods than were available when the
currently supported methods were chosen for the RIPE Database. User
acceptance of these methods differ by country and generation.
Whether this proposal is accepted or not, it is good to review the
rationale for these rules and have an updated rationale published.
1. Person and role objects have four contact methods. A postal address
is mandatory for both. A phone is mandatory for person objects but not
role objects. E-mail is mandatory for role but not person objects.
2. Postal mail is less useful than it was 20 years ago. Some countries
are reducing the frequency of postal deliveries. And geographically
distributed teams find postal mail less useful.
3. The telephone is becoming less useful, too. Call volumes are
dropping and popular psychology publications explain why calls are
less likely to be answered:
- https://www.statista.com/statistics/551035/finland-call-volume-by-type-of-c…
- https://www.bbc.com/news/articles/ckg8jllq283o
- https://www.psychologytoday.com/intl/blog/un-numb/202405/why-gen-zers-keep-…
## Proposal
We should provide contacts with more flexibility. We should also add
new options that were not available when the RIPE Database's contact
methods were last reviewed.
The three elements below follow on from NWI-15, which is based on the
RIPE Database Requirements Task Force recommendations for what should
be published about resource holders. The registry needs to retain the
full set of required data. The DBTF report did not mention contacts
methods for the resources.
1. Align the contact method requirements between role and person
objects used in admin-c and tech-c attributes. Make all contact
methods optional for the public RIPE Database as long as one is
chosen. There is no point publishing a contact method that will not be
used. That would just waste the time of people trying to make contact.
2. Add support for new contact methods in the RIPE Database, including
SIP (RFC 3969), Signal, Telegram, and WhatsApp.
3. Add support for RFC 8605 (ICANN Extensions for the Registration
Data Access Protocol) and show the HTTPS intermediary and/or private
URI where one is available.
Making these changes will require updates to the RPSL and RDAP
publication methods. The RIPE NCC should manage the specifics of the
design and implementation.
## Recommendation for Impact Assessment
The impact assessment provided by the RIPE NCC should note any contact
method requirements specified in policy. It should also note where the
policy does not specify a contact method requirement.
The RIPE NCC might want to note the impact of enforcing policy
requirements when more user choice is offered at the database layer.
