February 2023 - db-wg - mailman.ripe.net

Using the RIPE Database for IPAM
by denis walker 04 Oct '23

04 Oct '23

Colleagues Do you use the RIPE Database as your IPAM solution? If so, read on.... The RIPE NCC has done a brief review of the recommendations made by the DB Task Force (DBTF). You can find it here: https://www.ripe.net/participate/ripe/tf/rdb-requirements-tf/initial-analys… There is one point in the summary that I disagree with: One recommendation can be implemented immediately by the RIPE NCC: - 3. Using the RIPE Database as an IPAM solution The recommendation from the DBTF was: "The task force recommends limiting and discouraging the use of the RIPE Database as an enterprise IPAM solution." This has not yet been discussed by the community and there is no consensus on this recommendation. So the RIPE NCC should not be doing anything to implement this recommendation. There are a number of points relating to this. The first BoF held by the DBTF had 46 participants. They had some polls about IPAM: Where do you hold your canonical IP address assignment details? (13 answers) Internal database or IPAM system (5 - 38%) RIPE Database (5 - 38%) Internal database for detailed assignments and RIPE database for allocations (3 - 23%) What should we do about the IPAM use of the RIPE Database? (12 answers) We should discourage it (3-25%) We should tolerate it but provide restrictions and best practices (5-42%) We should promote it and facilitate it (4-33%) During the BoF some comments were also made on this: Shane's comment "IPAM seems to be an important thing" Nathalie said about 50% of people attending training courses over a number of years said they use the RIPE DB for IPAM. Also trainees said open source IPAM solutions often pull data out of the RIPE DB but have no functionality to push data to the RIPE DB. During the presentation by the DBTF in the DB-WG session at RIPE 83 Shane said (on IPAM): "if you had very light requirements for IPAM then maybe it is OK, but it's not really what it's for" "unable to find out if this [response] was based on misunderstanding of the question" "we think there are probably good ways to go forward with that, for example making hooks so that external IPAM solutions can hook into it...that makes sense, there are certainly many commercial vendors that make IPAM products who would be happy to use hooks, there are many ways that third parties could use this but probably not a requirement" So it looks like there are very mixed views on the use of the RIPE Database for IPAM. Some people also expressed surprise that so many people use the database for IPAM. It is clear that we don't actually understand who, how and why people use the database for IPAM. We need a better understanding of the how and why and the number of users doing this before we can make any decision about discouraging or encouraging this use of the database. Even to consider if IPAM should be defined as a purpose of the database. As we are talking about it, maybe now is the time to start this discussion. If you use the RIPE Database as your IPAM solution maybe you can offer some more details. cheers denis co-chair DB-WG

5 5

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

Proposed Service Criticality Form
by Edward Shryane 12 May '23

12 May '23

Dear Colleagues, During RIPE 84 in May, we discussed the Service Criticality Framework. We mentioned that we would like the Database Working Group's input on the criticality rating for the RIPE Database. Thank you to the Co-chairs for asking the working group for input in July with the original form: https://www.ripe.net/ripe/mail/archives/db-wg/2022-July/007527.html Since we have yet to receive any feedback so far, we plan to share our proposed completed form with the working group on Monday, 12 December. We hope that this will invite more input. Regards Ed Shryane RIPE NCC

3 4

ORGANISATION country code
by denis walker 23 Mar '23

23 Mar '23

Colleagues We have a number of outstanding issues from RIPE 85 so let's start with NWI-10. Ed said in his update, "Country code is now editable in organisations without co-maintained resources" I think this is a really bad idea. The country codes entered into ORGANISATION objects by the RIPE NCC are well defined, verified and maintained by the RIPE NCC. If we allow users to edit this field in other ORGANISATION objects, the values they enter will be undefined, unverified and meaningless. Just like the country code in resource objects. I don't think we should allow more meaningless data to be added to the RIPE Database. Even worse, we are mixing well defined data with meaningless data in the same attribute in the same object. This will end up with some people trusting all of this data and some people not trusting any of it...confusion. I suggest we don't allow users to enter any data into this attribute and remove any data that may have already been entered. If there is a need for resource holders to enter a country code in ORGANISATION objects set up for end users, then let's define a specific attribute for that with a well defined meaning. Your thoughts are welcome... cheers denis co-chair DB-WG

11 36

Set default maintainer on locked inetnum resources
by Edward Shryane 06 Mar '23

06 Mar '23

Dear colleagues, From time to time, the RIPE NCC gets requests from LIRs to unlock their PA assignments that have RIPE-NCC-LOCKED-MNT as mnt-by. These inetnums are locked due to the deprecation of the NONE authentication scheme in 2004: https://www.ripe.net/publications/news/announcements/deprecation-of-the-non… A total of 438 ASSIGNED PA AND 13 LEGACY inetnums have both this maintainer, and a responsible LIR organisation referenced in a less-specific inetnum. The DB team wishes to update these inetnums with the responsible LIR's default maintainer, so they can be maintained by the LIR without needing to contact the RIPE NCC. We will inform the affected maintainers. Please let me know your comments. If there are no objections, I'd like to implement this in the coming weeks. Regards Ed Shryane RIPE NCC

3 6

recording ROV enforcement
by Tomas Hlavacek 03 Mar '23

03 Mar '23

Dear colleagues, In the last few years we saw numerous experiments that strove to identify networks that enforce ROV. These works came not only from the scientific community but also from the industry, which indicates that many different parties are interested in this question and are willing to work to get the answer. This brings me to the question whether there is any structured and machine-readable way that the networks and IXPs can use to publish the fact that they enforce ROV? It seems that the logical place for this would be IRR and therefore I am off-topic here, but since I am not aware of any previous efforts to extend the RPSL for this particular purpose and I can imagine reasons against it, I was wondering if there is something else, possibly in the non-IRR part of the RIPE DB or somewhere else? Best regards, Tomas

3 3

RIPE-NONAUTH AS-SET bug fix
by denis walker 20 Feb '23

20 Feb '23

Colleagues There is some support for the idea that if AUT-NUM objects in RIPE-NONAUTH authorise the creation of AS-SET objects, these set objects will also be in RIPE-NONAUTH. There is also support for this to be considered as a bug from the implementation of 'NWI-5 Out of region ROUTE(6)/AUT-NUM objects'. So existing AS-SET objects whose creation was authorised by one of these RIPE-NONAUTH ASNs can be moved to RIPE-NONAUTH as part of a bug fix. Does anyone have any objections to such a 'bug fix'? cheers denis co-chair DB-WG On Thu, 1 Dec 2022 at 19:34, Nick Hilliard <nick(a)foobar.org> wrote: > > Cynthia Revström wrote on 30/11/2022 22:59: > > I am not sure if this feature is used or not however I think this is a > > very good reason to not go forward with a clean-up (at least until we > > have properly evaluated things). > > We will probably have to figure out some other way to deal with > > objects that are currently causing issues I think. > > the "feature" is used, yes. Some providers have customers in different > RIR service regions. Some organisations have address space registered > in different RIR service regions. It's impossible to avoid in many > situations. > > What's important right now is to close off the option to create new > unqualified as-set names, and to move the existing qualified non-RIPE > ASxxxx:as-set objects from source: RIPE to source: RIPE-NONAUTH. > > Denis was correct that this was a bug during the implementation of NWI-5 > (not ripe-731 which I mistakenly quoted). > > After that, we can afford to spend a bit of time looking at potential > clean-up options. There are 1590 empty as-set objects. 700 of these > haven't been updated in the last 5 years, and some going back 20 years. > > I wouldn't lose too much sleep about deleting empty as-sets. Contact > people, set a timeout, and then delete. Worst case, people can > reference new, qualified as-sets. > > Nick >

4 8

Whois Release 1.106
by Edward Shryane 20 Feb '23

20 Feb '23

Dear Colleagues, RIPE Database release 1.106 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 20th February. This release includes the following main changes: * NWI-19 Implement AS-SET NONAUTH source (#1169) * Implement RDAP "networks" and "autnums" elements in RDAP entity response (#1103) * RDAP Flat model, don't return as-block (#1125) * RDAP Refactor rdap errors (#1124) * RDAP Events and notices (#1112) * NRTMv4 changes (#1166, #1156, #1099) * Improve AS-SET documentation (#1147) 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 1

Newbie-ish type of questions
by Hank Nussbacher 08 Feb '23

08 Feb '23

As a LIR we want to extract all records for which we are registered as mnt-by. We tried: https://apps.db.ripe.net/db-web-ui/query?searchtext=-i%20mnt-by%20ISOC-MNT but it appears there is some limit at which point all results are blocked for an undetermined time. Also, we don't want to do copy/paste but rather would like that ability to download or API or script the results. Any clue? We also like the app: https://stat.ripe.net/widget/address-space-hierarchy but again here we didn't find a method to download/script/API the results. Any clue? Thanks, Hank

5 4

The RIPE Database needs your attention...
by denis walker 08 Feb '23

08 Feb '23

Colleagues We still have many outstanding issues, some of which have been on and off the table for years. We cannot make any progress on them as we do not have the attention of enough people in the community. It will be good if we can clear up some of these issues before the next RIPE meeting. For that to happen we need more of you to volunteer to focus a little bit of your attention on database issues over the coming months. The database may not be your highest priority, but it is still an essential tool for many LIR's business and a fundamental part of the whole registry system. If you can PLEASE offer a few moments of your attention over the coming months we can wrap up many of these outstanding issues. Often people who agree with a suggestion, or have no preference, say nothing. We need you to say something so we know you agree or don't disagree. It is not good to declare consensus based on only 3 people commenting. Maybe we can start with the recent conversation about country codes. If you look back over the DB-WG mailing list for January we more or less have a couple of people supporting and one objecting to my suggestions. My suggestions for the community to consider are these: 1/ The country: attribute in ORGANISATION objects is only used to specify the legal address country of organisations (including individuals) holding internet resources and is tied to the country values in the extended delegated stats file. These values are maintained by the RIPE NCC. This is what the community agreed to when they accepted the implementation plan for NWI-10. 2/ The country: attribute in ORGANISATION objects cannot be set by users to meaningless, undefined values for other reasons, as this was not in the agreed implementation plan. 3/ The country: attribute in INET(6)NUM objects is made optional. 4/ We define the optional country: attribute in INET(6)NUM objects to be used for geolocation purposes only 5/ If included, this country code will signal that all the addresses covered by this range/prefix are used within the geographical boundary of the country value. 6/ The geofeed: attribute can be used where a block of addresses are used in multiple countries or if more fine grained details are needed. 7/ An optional country: attribute could be added to the AUT-NUM object if anyone feels it necessary to specify a geolocation for an ASN. As always your thoughts are welcome... cheers denis co-chair DB-WG

1 0