We have some automation in place that queries RDAP to retrieve contacts in order to validate BGP announcements. We've been running into issues with one contact in particular: https://rdap.db.ripe.net/entity/KR4422-RIPE However, WHOIS returns valid responses for this https://apps.db.ripe.net/db-web-ui/query?searchtext=KR4422-RIPE RIPE support suggested that this was a known issue but didn't really offer any suggestions as to when (if ever?) it's going to be fixed. Is this being tracked somewhere?
Hi Brian, The DB team publishes a list of known issues with our RDAP implementation in our repository: https://github.com/RIPE-NCC/whois/blob/master/README.RDAP.md We've been making improvements to our RDAP implementation over time, in cooperation with the other RIRs (to resolve ambiguities in the spec for example). We improved the behaviour where multiple objects match an entity key in Whois 1.95.1 last September, by only matching on an object's primary key (we were previously also matching secondary attributes such as netname). However, an entity key can still match multiple objects (organisation, mntner, person, role), since the syntax for each object type's primary key is not completely distinct. When this happens, we return a 500 Internal Server Error, including a "title" element "Unexpected result size" in the response body. For example, the entity KR4422-RIPE is both a mntner and a person. I restored this issue to the RDAP README, and we will investigate what further improvement we can make in this situation. Regards Ed Shryane RIPE NCC
On 16 Jun 2020, at 15:15, Brian Rak via db-wg <db-wg@ripe.net> wrote:
We have some automation in place that queries RDAP to retrieve contacts in order to validate BGP announcements. We've been running into issues with one contact in particular: https://rdap.db.ripe.net/entity/KR4422-RIPE
However, WHOIS returns valid responses for this https://apps.db.ripe.net/db-web-ui/query?searchtext=KR4422-RIPE
RIPE support suggested that this was a known issue but didn't really offer any suggestions as to when (if ever?) it's going to be fixed.
Is this being tracked somewhere?
participants (2)
-
Brian Rak
-
Edward Shryane