October 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

How does reverse delegation work for legacy resources across RIR?
by Yang Yu 11 Nov '20

11 Nov '20

According to https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml 147/8 Administered by ARIN 1993-05 whois.arin.net https://rdap.arin.net/registry http://rdap.arin.net/registry LEGACY > $ dig 147.in-addr.arpa. ns ; <<>> DiG 9.16.1-Ubuntu <<>> 147.in-addr.arpa. ns ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20223 ;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;147.in-addr.arpa. IN NS ;; ANSWER SECTION: 147.in-addr.arpa. 86400 IN NS r.arin.net. 147.in-addr.arpa. 86400 IN NS u.arin.net. 147.in-addr.arpa. 86400 IN NS x.arin.net. 147.in-addr.arpa. 86400 IN NS y.arin.net. 147.in-addr.arpa. 86400 IN NS z.arin.net. 147.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net. ;; Query time: 75 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: Thu Oct 29 15:02:58 PDT 2020 ;; MSG SIZE rcvd: 165 >another example $ dig 196.in-addr.arpa. ns +short ns1.afrinic.net. ns2.afrinic.net. ns3.lacnic.net. ns3.afrinic.net. ns4.apnic.net. tinnie.arin.net. afrinic.authdns.ripe.net. For legacy /8 that exists today in multiple RIRs, what is the process to make sure rDNS gets delegated correctly and avoid split views? Is there some mechanism to sync the zone across RIRs? How long does it typically take for this type of reverse delegation update to get reflected in DNS zone? When I created a domain object for 208.75.147.in-addr.arpa., it didn't show up in DNS until the next day. Yang

2 2

Re: [db-wg] Interest to continue NWI-9
by denis walker 07 Nov '20

07 Nov '20

Hi Job I would agree that NWI-9 is finished, according to the way it is worded. I would suggest we create NWI-12 to move forward with a new version of NRTM. Perhaps you could write the first draft of the problem statement? cheers denis co-chair DB-WG On Thu, 29 Oct 2020 at 18:09, Job Snijders <job(a)ntt.net> wrote: > > Dear group, > > I think NWI-9 needs to be reworded, it in part has been over taken by > current events. Rereading https://www.ripe.net/ripe/mail/archives/db-wg/2019-April/006236.html > what is described there actually already has completed. > > RIPE NCC's NRTM servers are open to the public (this was not the case in > april 2019 yet). The NRTM servers can be used to *subscribe* to changes > in the RIPE database. When the NRTM client remains connected, it will > receive NRTM updates as they come in. THIS IS IN-BAND, AND FAST. The > rate of object change is very low compared to most information systems. > > Looking at https://ripe79.ripe.net/presentations/118-NWI-9_S.Konstantaras_DB-WG.pdf > it is not clear to me what the problem definition is and how it relates > to the wording of NWI-9. The proposed optimisations are either not in > the RIPE IRR -> Cache layer (as NRTM is really near-real-time when > implemented correctly) but elsewhere in the end-to-end route server > functionality. From this perspective NWI-9 has already been completed! > > Now, there is plenty to be left desired about NRTM v3. Even though it is > both a push and pull protocol and very fast (the push can measured in > single digit seconds), NRTM v3 clearly is an ancient protocol and the > operational community would benefit from a re-design of NRTM. > > WORK IS UNDER WAY: LACNIC has committed funding for IRRd's NRTM v4 > implementation. RIPE NCC's 'good for the Internet' community fund has > also been requested. That decision is still pending with the committee > operating that fund. > > So what we have so far: > > - A collective desire to replace NRTM v3 with something else > - The *only* two IRR server code bases of this industry have > (partial) funding to make changes possible: IRRd and RIPE WHOIS server > - A standardisation forum to publish the new spec: IETF > - Multiple forums for input: RIPE DB-WG, IETF, *NOG, IRC, etc > > If NWI-9 is kept open I would request it is reworded to the extend that > this working group requests RIPE NCC to commit to help design, > implement, test & adhere to what will become "NRTM v4". > > I read Stavros' presentation where the above plan is listed as > 'Langzaam' :-) but the characterization may be a little bit off: there > is no Legal aspect to deal with: RIPE NCC made NRTM freely, > contract-less, publicly and in real-time available already. Also keep in > mind that any new protocol will indeed need to be tested (even if > general purpose components such as JSON, HTTPS and WebSockets are > used!). > > NRTM v4's design will have nothing to do with how NRTM v3 looks and > feels. NRTM v4 will be HTTPS based, I guarantee it! This project has > 'NRTM v4' as name to make it clear to the IRR operational community > where in the internet-stack this protocol belongs, but that it is an > improvement over version 3. > > NRTM v4 can easily be something that is finished and deployed in 2021. > What needs to be done is fairly straight-forward, and lots of existing > tools can be used to make the job easier (like HTTPS and JSON). > > Kind regards, > > Job > > On Thu, Oct 29, 2020 at 05:22:10PM +0100, denis walker via db-wg wrote: > > Hi Stavros > > > > Thanks for the comment. I have let Ed know about your interest. > > > > cheers > > denis > > co-chair DB-WG > > > > On Thu, 29 Oct 2020 at 17:11, Stavros Konstantaras via db-wg > > <db-wg(a)ripe.net> wrote: > > > > > > Hi WG chairs, > > > > > > > > > I would like to declare that from our side we are still interested to team up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item > > > in order to modernise the NRTM service with something better and more suitable for our current needs. > > > > > > As far as I can recall, Ed and his team have several ideas to proceed forward with this subject, so I believe that we would be able to draw a clear development plan. > > > And as a kind reminder, not only us (AMS-IX) but the European IXP community has expressed interest on proceeding with that subject. > > > > > > > > > Thank you and we are looking forward to discuss further steps on the subject. > > > > > > > > > > > > Best regards, > > > > > > Stavros Konstantaras | Sr. Network Engineer | AMS-IX > > > M +31 (0) 620 89 51 04 | T +31 20 305 8999 > > > ams-ix.net > > > > >

5 8

Re: [db-wg] Interest to continue NWI-9
by Job Snijders 29 Oct '20

29 Oct '20

Dear group, I think NWI-9 needs to be reworded, it in part has been over taken by current events. Rereading https://www.ripe.net/ripe/mail/archives/db-wg/2019-April/006236.html what is described there actually already has completed. RIPE NCC's NRTM servers are open to the public (this was not the case in april 2019 yet). The NRTM servers can be used to *subscribe* to changes in the RIPE database. When the NRTM client remains connected, it will receive NRTM updates as they come in. THIS IS IN-BAND, AND FAST. The rate of object change is very low compared to most information systems. Looking at https://ripe79.ripe.net/presentations/118-NWI-9_S.Konstantaras_DB-WG.pdf it is not clear to me what the problem definition is and how it relates to the wording of NWI-9. The proposed optimisations are either not in the RIPE IRR -> Cache layer (as NRTM is really near-real-time when implemented correctly) but elsewhere in the end-to-end route server functionality. From this perspective NWI-9 has already been completed! Now, there is plenty to be left desired about NRTM v3. Even though it is both a push and pull protocol and very fast (the push can measured in single digit seconds), NRTM v3 clearly is an ancient protocol and the operational community would benefit from a re-design of NRTM. WORK IS UNDER WAY: LACNIC has committed funding for IRRd's NRTM v4 implementation. RIPE NCC's 'good for the Internet' community fund has also been requested. That decision is still pending with the committee operating that fund. So what we have so far: - A collective desire to replace NRTM v3 with something else - The *only* two IRR server code bases of this industry have (partial) funding to make changes possible: IRRd and RIPE WHOIS server - A standardisation forum to publish the new spec: IETF - Multiple forums for input: RIPE DB-WG, IETF, *NOG, IRC, etc If NWI-9 is kept open I would request it is reworded to the extend that this working group requests RIPE NCC to commit to help design, implement, test & adhere to what will become "NRTM v4". I read Stavros' presentation where the above plan is listed as 'Langzaam' :-) but the characterization may be a little bit off: there is no Legal aspect to deal with: RIPE NCC made NRTM freely, contract-less, publicly and in real-time available already. Also keep in mind that any new protocol will indeed need to be tested (even if general purpose components such as JSON, HTTPS and WebSockets are used!). NRTM v4's design will have nothing to do with how NRTM v3 looks and feels. NRTM v4 will be HTTPS based, I guarantee it! This project has 'NRTM v4' as name to make it clear to the IRR operational community where in the internet-stack this protocol belongs, but that it is an improvement over version 3. NRTM v4 can easily be something that is finished and deployed in 2021. What needs to be done is fairly straight-forward, and lots of existing tools can be used to make the job easier (like HTTPS and JSON). Kind regards, Job On Thu, Oct 29, 2020 at 05:22:10PM +0100, denis walker via db-wg wrote: > Hi Stavros > > Thanks for the comment. I have let Ed know about your interest. > > cheers > denis > co-chair DB-WG > > On Thu, 29 Oct 2020 at 17:11, Stavros Konstantaras via db-wg > <db-wg(a)ripe.net> wrote: > > > > Hi WG chairs, > > > > > > I would like to declare that from our side we are still interested to team up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item > > in order to modernise the NRTM service with something better and more suitable for our current needs. > > > > As far as I can recall, Ed and his team have several ideas to proceed forward with this subject, so I believe that we would be able to draw a clear development plan. > > And as a kind reminder, not only us (AMS-IX) but the European IXP community has expressed interest on proceeding with that subject. > > > > > > Thank you and we are looking forward to discuss further steps on the subject. > > > > > > > > Best regards, > > > > Stavros Konstantaras | Sr. Network Engineer | AMS-IX > > M +31 (0) 620 89 51 04 | T +31 20 305 8999 > > ams-ix.net > > >

1 0

Interest to continue NWI-9
by Stavros Konstantaras 29 Oct '20

29 Oct '20

Hi WG chairs, I would like to declare that from our side we are still interested to team up with Ed and RIPE NCC colleagues to continue the work on NWI-9 item in order to modernise the NRTM service with something better and more suitable for our current needs. As far as I can recall, Ed and his team have several ideas to proceed forward with this subject, so I believe that we would be able to draw a clear development plan. And as a kind reminder, not only us (AMS-IX) but the European IXP community has expressed interest on proceeding with that subject. Thank you and we are looking forward to discuss further steps on the subject. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net

2 1

Agenda RIPE81 - Database Working Group
by William Sylvester 25 Oct '20

25 Oct '20

Db-wg members, Here’s the database working group agenda for our meeting this week. Best regards, DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 15 mins Edward Shryane, RIPE NCC C. NWI - Open Proposals – 10 mins Denis Walker, DB-WG Co-Chair D. Cloud Migration – 20 mins Sander Buskens, RIPE NCC Z. AOB (open discussion)

1 0

in-addr.arpa glue?
by Randy Bush 23 Oct '20

23 Oct '20

domain: 0.28.147.in-addr.arpa descr: RG79-147-28-0 admin-c: RB45695-RIPE tech-c: RB45695-RIPE zone-c: RB45695-RIPE nserver: rip.psg.com nserver: nlns.globnix.net mnt-by: MAINT-RGNET source: RIPE ***Error: No response from nameserver for zone 28.147.in-addr.arpa when trying to fetch glue. ***Error: Not enough data about 0.28.147.in-addr.arpa was found to be able to run tests. not aware of glue in in-addr.arpa zones does it want me to delete the 28.147.in-addr.arpa parent zone first? that seems scary. randy

3 3

New on RIPE Labs: Our Plan to Fix Country Codes - NWI-10
by Stefania Fokaeos 23 Oct '20

23 Oct '20

Dear colleagues, As part of our preparation for the implementation of NWI-10, we've written an article on RIPE Labs in which we look at our plans for fixing country codes in the RIPE Database. https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes <https://labs.ripe.net/Members/stefania_fokaeos/our-plan-to-fix-country-codes> During the RIPE Database WG session next Thursday at RIPE 81 all NWIs will be discussed and if needed my colleague Ed Shryane can provide more details. Kind regards, Stefania Fokaeos RIPE NCC

1 0

MNTNER Naming : Consensus
by William Sylvester 19 Oct '20

19 Oct '20

db-wg members, The chairs of the database working group believe there is a consensus to have a standardised name format for creating new MNTNER objects. There was talk of a prefix (MNT-) or a suffix (-MNT). When creating a new standard it doesn't really make sense to introduce a standard with multiple formats. As there are currently 36347 MNTNERs that end with -MNT and 12480 MNTNERs that start with MNT-, we suggest that the standard should be to end with -MNT. We ask the RIPE NCC to take the next steps in moving this request forward, conducting an impact analysis, and proceed with implementation. Best regards. William & denis db-wg chairs

4 5