December 2020 - db-wg - mailman.ripe.net

NWI reviews: NWI-2 displaying history for DB objects where available
by ripedenis＠yahoo.co.uk 11 Jan '21

11 Jan '21

Dear Colleagues This is another action point that has been open for 4 years. We either need to progress it or cancel it.https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005240.html It is basically asking for full history of existing and deleted resource objects. In the link above on this NWI it mentions some doubt over the value of full history. So the main questions are, -"is full history more useful than partial history?" -"is history of deleted objects, that don't currently exist in the database, useful?"If so then I don't see any reason not to provide it. Let me give some background on this. Objects in the database are accessed by their primary key (pkey). In the case of an INETNUM object, for instance, this is an address range. Internally to the database all objects also have an object ID. Each time an object is modified a new instance of the object is created in the database with the same pkey and object ID. (Other meta data is updated to keep the sequence of changes.) When an object is deleted and re-created with the same pkey, the new object has a new object ID. Then the sequence of changes continues with this new object. When the RIPE NCC proposed to make history of objects available an arbitrary decision was made to present the history of a currently available object with all instances having the same object ID. In other words the history presented only went back as far as the creation of the current sequence of object modifications. The object may have existed before this sequence and been deleted and re-created. That part of the history is not available by the current query mechanism. But of course that history does exist in the database. It is not difficult for the software to present the full history of an object based on the pkey, no matter how many times it has been deleted and re-created. The decision to only give history back to the most recent deletion was an arbitrary, low hanging fruit, option to get a service up and running quickly. It has just stayed that way ever since. Your comments are appreciated... cheersdenis co-chair DB-WG

4 4

proposal: new attribute 'geofeed:'
by Job Snijders 07 Jan '21

07 Jan '21

Dear DB-WG, Some colleagues are working to address the never-ending-story of 'where the heck are IPs geographically?'. This problem space has been brought up numerous times in the Database Working Group, but we never managed to solve it. As with all compsci problems adding a layer of indirection can help ;-) This current draft suggests overloading the RPSL 'remarks:' field with a structured attribute value, however I suspect we would do ourselves a disservice to overload a 'remarks:' field. Instead it would be better to add a 'geofeed:' attribute to the RPSL inetnum/inetnum6 class dictionary, which as value contains a URL with http or https scheme. The draft: https://tools.ietf.org/html/draft-ymbk-opsawg-finding-geofeeds The value of the attribute could be validated using something like "org.apache.commons.validator.UrlValidator", the attribute would look like this, only valid in the inetnum/inet6num: "geofeed: [optional] [single] [ ]" Example object: inetnum: 192.0.2.0 - 192.0.2.255 netname: EXAMPLE country: NL geofeed: https://example.com/geofeed.csv ... snip ... source: RIPE What do others think? Kind regards, Job ps. In IRRd v4.2 support for the 'geofeed:' attribute will be added https://github.com/irrdnet/irrd/issues/396

15 35

NWI-?? Rationalising contact references
by denis walker 22 Dec '20

22 Dec '20

Colleagues I would like to propose a new NWI about contact references in the RIPE Database. Something that has needed to be cleaned up for a very long time. I have written a draft Problem Statement and Solution Definition below. Your comments are appreciated. cheers denis co-chair DB-WG Problem Statement The RIPE Database only uses inheritance for references to abuse contacts. The admin, tech and zone contacts all use local direct references in every resource object. This has resulted in millions of unnecessary, repetitive, redundant references throughout the database. This can make the data difficult to manage and keep up to date if any referenced contact is replaced. A common problem was referencing a PERSON object in thousands of resource objects. When that person leaves the company it requires a mass data update. Adding inheritance to all contact attributes allows for a cleanup and removal of massive amounts of redundant data references. There are millions of assignments to end users with contact references pointing back to the resource holders contacts. It is confusing to have unnecessary, repeated contact references in these assignments. This would simplify the basic structure of the database. I see this simplification as a first step towards removing unnecessary personal data from the database. Solution Definition I would like to suggest adding inheritance to the other three contacts for admin, tech and zone. The only syntactical changes needed are to make "admin-c:", "tech-c:" and "zone-c:" 'optional' in INET(6)NUM, AUT-NUM and DOMAIN objects and add "zone-c:" as an optional attribute in the ORGANISATION object. At the time of implementation nothing needs to be changed. Next time an ORGANISATION object is updated it needs to have a default "admin-c:", "tech-c:" and "zone-c:" added (if it doesn't already have them) if it is a resource holders object (ie if it has an "abuse-c" attribute). Creating new resource objects, eg assignments, or receiving new allocations, won't need to have these contact attributes included if they are the same as a parent object or the default values in the ORGANISATION object. A standard query for a resource object will return the object as it is, including any optional contact attributes contained within that object. Three new query flags, '--admin', '--tech' and '--zone' added to a query for a resource object will return the correct hierarchical contacts for that resource. The RIPE NCC can provide tools for doing cleanups of resource hierarchies to remove redundant contact attributes with an option to list specific objects that should keep their local values.

1 0

New on RIPE Labs: Impact of NWI-10 on Country Codes in Delegated Statistics
by Boris Duval 22 Dec '20

22 Dec '20

Dear colleagues, In this new article on RIPE Labs, Rene Wilhelm and Stefania Fokaeos quantify the changes that were made to the Extended Delegated Statistics after the RIPE NCC implemented phase 1 of Numbered Work Item 10 (NWI-10): https://labs.ripe.net/Members/wilhelm/impact-of-nwi-10-on-country-codes-in-… Kind regards, Boris Duval RIPE NCC

1 0

Whois Release 1.99
by Edward Shryane 21 Dec '20

21 Dec '20

Dear Working Group, RIPE Database release 1.99 has been deployed to the Release Candidate environment. We plan to deploy to production on Monday 21st December. This release includes the following main changes: * NWI-10: require -mnt suffix * Filter out sensitive information in API response on exception * Return 'invalid option supplied' on invalid version number given to --diff-version * Allow *any* CORS origin on RDAP GET requests by default (as recommended by RFC 7480). * New dummifier for RC environment * Enable TCP_NODELAY in NRTM and query connections In addition to other small improvements and bug fixes. 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

2 3

NWI-10: Phase 1 Implemented
by Stefania Fokaeos 19 Dec '20

19 Dec '20

Dear colleagues, We are pleased to announce that we have implemented Phase 1 of NWI-10: Definition of Country. The following updates took place as part of the implementation: 1. ORGANISATION objects with "org-type:" 'LIR' have been updated to include a new "country:" attribute. The Country Code displayed in this attribute is the country in which the resource holder is legally based 2. The Country Code (CC) has also been updated in the Extended Delegated Statistics file when there was a mismatch between the file and the new attribute. These resources have now as "CC" the same Country Code that is visible in the respective ORGANISATION object If you notice that your Country Code is incorrect, you can contact us. Please note that we might ask you for supporting documentation to justify the update. In the meantime, we are continuing to work towards Phase 2 of NWI-10 and will keep you updated about our progress. You can read more about our implementation plan and the different phases of NWI-10 on RIPE Labs: https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes If you have any questions about the implementation of NWI-10, please send an email to <support(a)ripe.net> or <policy-implementation(a)ripe.net>. Happy Holidays and warm wishes for 2021! Kind regards, Stefania Stefania Fokaeos RIPE NCC

3 2

Weirdness in DB files
by Cynthia Revström 17 Dec '20

17 Dec '20

Hi DB-WG, I just noticed that the (at the time of writing, serial 49363913) latest aut-num split db file (possibly elsewhere too) sort of just seems to break at some point. The lines like below simply stop appearing: % Tags relating to 'AS3333' % RIPE-REGISTRY-RESOURCE Here's a section where you can see it happening: https://gist.githubusercontent.com/bitcynth/d81688c6b7587e0179d55b8324535ff… Any clue why this is occurring? or is it just a bug? - Cynthia

3 4

Domain Object Cleanup in the RIPE Database
by Edward Shryane 14 Dec '20

14 Dec '20

Dear colleagues, As mentioned in the Operational update during the DB-WG session at RIPE81, the RIPE NCC will shortly clean up (delete) domain objects without a mandatory "nserver:" attribute. This will affect approximately 1,600 domain objects in the RIPE database, which have not been updated since September 2012. We plan to notify the maintainers of affected objects today, and ask them to add "nserver:" attributes to any objects they wish to keep. We will then delete any remaining domain objects without a mandatory "nserver:" attribute in two weeks from now (on 14th December). Regards Ed Shryane RIPE NCC

1 1

Historical records... what is and isn't available
by Ronald F. Guilmette 08 Dec '20

08 Dec '20

I bumped my head on something unexpected a day or two ago, and I would now just like to ask a question, to find out if what I seemed to see was just a product of my own programming mistake, or if it is fact the way things were intended to be. So, true or false? The --list-versions and --show-version options are not supported for person:, role:, and mntner: records. To be clear I am *not* asking if the data returned when the --show-version option is applied to one of the types of records I've just listed is merely redacted of all personal information relating to natural persons. Rather, I am asking if I should in fact be expecting to get absolutely -nothing- back when/if I try to use --show-version on any of the aforementioned record types, regadless of of whether the requested historical information contains 100% personal information or alternatively, if it contains 0% personal information, or anything in between. Regards, rfg

6 9

Proposal to revert NWI-10
by Cynthia Revström 07 Dec '20

07 Dec '20

Apologies if this email is a bit impolite. >From the start NWI-10 seemed like a pointless policy to me and just a policy that was made because the db-wg wanted to make more policies. But as it has already messed up the data on my resources, I see it as a policy that messes up data and wastes time for no real advantage. Hence I suggest that we revert NWI-10 unless someone actually has a good reason for why the legal address needs to match the delegated file, and how to implement it in a non-messy way. - Cynthia

4 10