[ripe-db-requirements-tf] Notes from 16 April 2021 Meeting

Dear all,

Here's the meeting notes from our last call. Let me know if something’s missing.

*RIPE Requirements Database Task Force Meeting Notes*
16 April 2021 Meeting

Attendees: Boris Duval, James Kennedy, Shane Kerr, Peter Koch, Bijal Sanghani, Ed Shryane

1. Reviewing and editing the routing requirements
The task force reviewed the routing requirements from its current draft.

-- Requirement: "The RIPE Database will provide routing information for:
- Internet number resources delegated by the RIPE NCC.
- Internet number resources which fall under the terms of the "RIPE NCC Services to Legacy Internet Resource Holders" policy.
- Other Internet number resources which already have routing information in the RIPE Database."

Shane mentioned that the last point, “Other Internet number resources which already have routing information in the RIPE Database”, was an attempt to capture all information not covered by the points above. James proposed to ask the RIPE NCC Registry Services department to double check if there was such information in the RIPE Database. Boris will follow up with Registry Services.


-- Requirement: “The holders of these resources will be authenticated by the RIPE NCC and only they will be authorised to manage routing information for the resources that they hold.”

Shane clarified that some of the language in the requirements such as “authenticated” and “authorised” refer to generic computing terms and are not specific to the current RIPE Database processes. James and Ed proposed to specify who is covered by this requirement. Shane suggested the following text:

“The holders of these resources will be authenticated by the RIPE NCC or by the holders of parent resources, and only the holders will be authorised to manage routing information for the resources that they hold.”

-- Requirement: “It should not be possible to add new routing information to the RIPE Database for address resources delegated by other Regional Internet Registries.”

Shane asked if this there was already a policy for this. Ed confirmed that there was one.


-- Routing origin information
Shane mentioned that it’s important to include RPKI in this section. James and Ed mentioned that there are interlinks between the RIPE Database and RPKI and that should be taken into account when drafting the requirements. Shane added the following text to clarify these connections:
“Maintaining accurate routing origin (address prefix and autonomous system number) information is a requirement of the RIPE Database.

	• Routing origin information is published via route: / route6: objects in the RIPE Database.
	• ROA are created in RPKI to represent routing origin information.

In the RIPE Database, this routing information is stored using certain Routing Policy Specification Language (RPSL). Routing origin information is also stored in the RPKI Database. There is no direct link between these two databases, although both support authorization from address. (Although both address and ASN are needed for routing origination, only the address holder’s authorisation is used currently.)”


-- Routing relationship information
James pointed out that a lot of import/export lines in aut-nums are not maintained. Shane mentioned that it’s hard to analyse usage. Ed volunteered to check the query logs to see if there are queries for this object. Bijal proposed to ask the Routing Working Group about this topic and suggested phasing it out if that’s not being used. Shane will work on developing the text.


-- RPSL
Shane proposed to find a better way to represent routing policies than RPSL as it’s an outdated code language which is notoriously hard to work with. He also suggested to mention that RPSL was not a requirement of the RIPE Database. Bijal added that there was not a lot of support for RPSL in the community. Ed mentioned that it’s also possible to represent routing in JSON and XML. Ed also asked if the task force should document the drawbacks of RPSL or if this was already too detailed.

Peter mentioned that if we were to recommend an alternative, we will have to be careful about not getting too much into details (e.g. object level) as this will be out of scope for the task force.

Bijal mentioned that is will be worth looking at the advantages of RPSL instead of the drawbacks to save time.

Shane suggested the following text:
“RPSL is not a requirement for the RIPE Database. It is an old standard that never fully matured and has not been maintained over the decades. As such, the RIPE Routing working group should look at formal deprecation of RPSL, with the co-operation of the RIPE Database working group. The specific recommendation is not to adopt a new syntax such as XML or JSON, but rather to consider what routing information is useful to operators and design a way of representing that. Until RPSL is re-evaluated, the RIPE Database must continue to support it.”


-- RPKI Database
Shane and Peter mentioned that the RIPE community should consider whether or not RPKI is best treated as a community resource - like the RIPE Database - or as a RIPE NCC service. This should be highlighted in the document. Ed mentioned that there was an on-going effort to delegate RPKI to resource holders.



2. Next Meeting
The next meeting will take place on 20 April 2021.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: </ripe/mail/archives/ripe-db-requirements-tf/attachments/20210503/a89cb432/attachment.sig>