January 2021 - db-wg - mailman.ripe.net

Org-types
by Cynthia Revström 20 Jan '21

20 Jan '21

Hi DB-WG, This may have been discussed in the past but a quick search didn't yield much. Is there any reason for why ORG-NCC1-RIPE is marked as an LIR and not an RIR? Does RIR imply another RIR? I personally feel like marking the NCC as a member of itself is a bit odd, but honestly this is so minor so I understand if it was just not considered much. I noticed that there is currently only one RIR org (ORG-AFNC1-RIPE) which I assume came about as a result of the ERX process. (sidenote: ORG-AFNC1-RIPE is not referenced by anything except the role object anymore, so it might be somewhat redundant at this point) Other related info I found: Aside from the org-types of "LIR" and "OTHER" there are ~2300 orgs. There is a RIR, an IANA, and a WHITEPAGES. But the rest are "OTHER" but with differing capitalization (mainly Other and other). -Cynthia

4 5

Creating route objects without mnt on existing ones
by Patrick Velder 16 Jan '21

16 Jan '21

Hi there It seems to be impossible to create route objects for inet(6)nums, if there are other route objects to which your maintainer has no access. Even if you have mnt-by + mnt-routes on the inet(6)nums. Due to that, it's much more difficult to create new route objects for our customers, as we have to contact the maintainer of all existing objects in order to get mnt-by/mnt-routes on their route objects. In my opinion, that makes zero sense. If you have mnt-by/mnt-routes on an inetnum, you should be able to create objects, regardless of existing ones. Best regards Patrick

3 3

Re: [db-wg] Fwd: proposal: new attribute 'geofeed:
by hank＠interall.co.il 12 Jan '21

12 Jan '21

I guess I am not understanding something. Why do we need a geofeed attribute? What problem are we trying to solve? I understand why each block of IPs needs to be associated with a country, so that certain language specific auto-customizations will work. But what purpose is there to know that a /24 is in central Amsterdam? Is the purpose to assist marketers in geo-targetted sales? Is the purpose for network engineering (not sure what major problem we have that needs this)? Is the purpose to know where you are so that in the event of an emergency (terror, tornado, etc) you can get emergency targeted alerts? If so, then the geofeed has to be at the /32 level and since many if not most IPs are mobile, and that is where you will get the alert from - from your cellphone provider, I still don't quite understand the reason for a geofeed tag. Can someone clue me in? Thanks, Hank Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer

8 13

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

Cleanup of trailing dot in "nserver:" attributes in domain objects in the RIPE database
by Edward Shryane 07 Jan '21

07 Jan '21

Dear colleagues, The RIPE NCC database team have found some syntactically incorrect "nserver:" attributes in domain objects in the RIPE database, which contain a trailing dot ('.') character (signifying a fully qualified name). The convention since 2012 has been to strip out this trailing dot in the "nserver:" attribute on update, but a cleanup of existing data was not done when the syntax changed. We now plan to remove this trailing dot from these "nserver:" attributes later today, affecting approximately 544 domain objects (out of approx. 814K total domain objects), in order to make them syntactically correct. We will notify all maintainers of affected objects regarding this change by email. This is informational only, and users do not need to take any action. Regards Ed Shryane RIPE NCC

1 0