- 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

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

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

ORG-TKDS1-RIPE - VECTRA S.A. - Spam filters & abuse reporting addresses
by Ronald F. Guilmette 04 Dec '20

04 Dec '20

Based on my experience, if one is reporting spam to most typical networks, the network operators generally like to actually -see- the spam being reported. Thus, I always include a copy. It is Good that RIPE resource holders now all have abuse reporting addresses in their WHOIS records. It is also Good that RIPE NCC is now checking these abuse reporting contact email addresses to insure that they actually function, at least minimally. What is un-good, in my opinion, is for any network to have an abuse reporting address set up with *content based* anti-spam filters. To illustrate this point, I have recently received a spam from an IP address that is currently being routed by AS29314 - Vectra S.A., located in Poland. I duly forwarded a full copy of that spam to the abuse reporting address provided in the RIPE WHOIS for AS29314, i.e. abuse(a)vectra.pl. That message was rejected with the following SMTP reject message: <abuse(a)vectra.pl>: host smtp.vectra.pl[88.156.64.22] said: 554 Spam. Email Session ID: 86748699 (in reply to end of DATA command) Given that outcome, I now feel compelled to locally blacklist all IP space associated with ORG-TKDS1-RIPE (VECTRA S.A.) until such time as some kind soul provides the operators of this network with some education on the topic of how to operate an abuse reporting address. The space in question is as follows: 31.11.128.0/17 31.22.96.0/21 31.135.168.0/21 37.8.192.0/18 37.77.152.0/21 46.36.224.0/19 62.122.112.0/21 77.222.224.0/19 78.31.152.0/21 78.31.209.0/24 78.88.0.0/16 82.139.0.0/18 83.143.40.0/21 83.143.136.0/21 83.243.104.0/21 88.156.0.0/16 89.151.0.0/18 91.192.76.0/22 91.230.159.0/24 91.230.162.0/23 91.230.164.0/22 91.231.116.0/23 91.238.232.0/22 93.105.0.0/16 94.231.48.0/20 95.160.0.0/16 109.107.0.0/19 109.197.56.0/21 109.197.64.0/21 109.241.0.0/16 178.235.0.0/16 185.51.180.0/22 192.166.120.0/23 193.108.228.0/23 193.201.18.0/23 194.54.188.0/22 195.26.72.0/22 195.28.170.0/23 195.95.170.0/24 195.191.162.0/23 195.225.92.0/22 195.242.252.0/22

1 0

Fwd: Multi tenancy in a LIR?
by denis walker 20 Nov '20

20 Nov '20

Hi Hank Your scenario is not clear. When you say "each has their own resources", how did they get those resources? Were they separate LIRs that have received allocations, have there been mergers, were they all allocated to the parent organisation's LIR and distributed to sub organisations? Or do you mean they each want to have their own resources? As far as the database is concerned, address space resources allocated to the parent organisation's LIR can be distributed to sub organisations as LIR-PARTITIONED or ALLOCATED-BY-LIR. The sub organisations can separately manage their resources. If you want exclusive management control by the sub organisations you can set the MNTNER attributes accordingly. But ultimately they are still the parent organisations resources. They could be reclaimed by the parent organisation. The organisation reference in the allocations will always be the parent organisation that was allocated the resources by the RIPE NCC. That cannot be changed. cheers denis co-chair DB-WG On Thu, 19 Nov 2020 at 16:28, Hank Nussbacher via db-wg <db-wg(a)ripe.net> wrote: > > Can a LIR account handle multi-tenancy? > > > What if you had a parent organization and a few sub-organizations and each has their own resources (ASN + inetnum) that they wish to manage independently (objects, RPKI, etc) without the other sub-organizations of parent organization able to affect the resources. > > Is that at all possible or is the only solution to create a new LIR account? > > > Thanks, > Hank > Caveat: The views expressed above are solely my own and do not express the views or opinions of my employer

3 5

Multi tenancy in a LIR?
by Hank Nussbacher 19 Nov '20

19 Nov '20

2 1

Problem definition for new NWI (12?) - NRTM service
by Stavros Konstantaras 19 Nov '20

19 Nov '20

Dear db-wg community, Please find below the problem definition for the (upcoming) NWI-12 item as we have discussed it and envisioned it for this project. Problem definition: Back on October 2019 during the RIPE 79 meeting in Rotterdam, we discussed about the need to move forward with a next generation of NRTM service. Upon the completion of NWI-9 and the lifting of the legal restrictions, we can now proceed to design the new solution. As we discussed preciously, the version 3 of the current NRTM solution is not suitable anymore for network operations on 2020. A summary of the reasons are: -Is a Telnet based protocol, thus: • No keep alive mechanism is adopted, • It provides plain text/unencrypted transport of data -The bootstrap process is not always trivial and sometimes is slow -Long time synchronisation is complicated and users need to re-synchronise after a couple of weeks. -No well specified protocol (There is just a PDF doc that describes it) For all the reasons above (and reasons that we might have not think about yet but you are welcome to share), it becomes a necessity for the community to proceed with a new implementation that will be easily adopted by modern tools and last for the years to come. I hope the above text is sufficient for the db-wg chairs to kick off the process and the community to share its feedback. Best regards, Stavros Konstantaras | Sr. Network Engineer | AMS-IX M +31 (0) 620 89 51 04 | T +31 20 305 8999 ams-ix.net

4 3

Re: [db-wg] [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call
by ripedenis＠yahoo.co.uk 17 Nov '20

17 Nov '20

Hi Lee With the current data model it is not possible to have two independent objects with the same primary key. Creating 2 smaller objects is a work around. Having 2 status attributes is another work around. The question is, which work around is preferable? cheersdenis co-chair DB-WG On Tuesday, 17 November 2020, 14:25:35 CET, Howard, Lee <leehoward(a)hilcostreambank.com> wrote: That sounds like it would be confusing to me. I’d want to see both the allocation to the LIR and the assignment to the end user independently. Lee From: address-policy-wg <address-policy-wg-bounces(a)ripe.net>On Behalf Of ripedenis--- via address-policy-wg Sent: Monday, November 16, 2020 7:57 AM To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] NWI-4 - role of status: field in multivalued status context -- Last call Colleagues We have not had enough comment on this to make a decision if any change is needed. So can we have a last round of comment to decide if this is a sufficiently important issue to make a change or if we just close this action item? In brief: when assigning a whole allocation should we be able to give the INET(6)NUM object 2 status values to reflect it being both an allocation and an assignment, rather than splitting it into two smaller assignment objects? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:48:34 CEST, ripedenis--- via address-policy-wg <address-policy-wg(a)ripe.net> wrote: Colleagues I was about to post this to the DB-WG but it may be more appropriate to include it as part of this discussion... Yet another 4 year old NWI that needs to be progressed or closed. The details are here: https://www.ripe.net/ripe/mail/archives/db-wg/2016-May/005242.html In summary it concerns the assignment of a whole allocation. Because the range is the primary key (pkey) in the database you cannot have an allocation object and an assignment object with the same pkey. A common work around is to split the allocation and make two assignments. The suggestion is to allow "status:" to be a multiple attribute. This could be done quite easily and constrained in it's use by business rules in the database software. So the syntax could be changed in INET(6)NUM objects to: status: [mandatory] [multiple] [ ] The business rules could make this multiple option only allowed in very limited situations. For example if an INETNUM object has 'status: ALLOCATED PA' it could be possible to add a second value 'status: ASSIGNED PA' or 'status: SUB-ALLLOCATED PA'. If the status in an INET6NUM object is 'status: ALLOCATED-BY-RIR' it could be possible to add a second value 'status: ALLOCATED-BY-LIR' or 'status: ASSIGNED'. The business rules could prevent any other multiple status values. The "descr:" attribute is already multiple so it can describe both the allocation and the assignment. Is this still considered to be an issue? cheers denis co-chair DB-WG On Monday, 5 October 2020, 16:13:53 CEST, Erik Bais <ebais(a)a2b-internet.com> wrote: Dear WG, I want to bring the following email and questions of our PDO - Petrit Hasani to your attention that might have slipped over the vacation period. Please have a look at this discussion again and provide input if you can. Regards, Erik Bais Co-chair AP-WG. ( on behalf of the AP-WG Chair collective ) On 02/07/2020, 13:36, "address-policy-wg on behalf of Petrit Hasani" <address-policy-wg-bounces(a)ripe.net on behalf of phasani(a)ripe.net> wrote: Dear colleagues, Thank you to everyone who responded to our earlier questions on the intent of the policy regarding IPv4 status hierarchies. While this was helpful, it would be great if we could have input from a wider group of people: - Should inetnums with these statuses be allowed to be created inside one another? - Should there be a limit on the minimum size of a sub-allocation? - Do we need a policy update? https://www.ripe.net/ripe/mail/archives/address-policy-wg/2020-June/013195.… We look forward to hearing from you. Cheers, -- Petrit Hasani Policy Officer RIPE NCC > On 16 Jun 2020, at 15:36, Petrit Hasani <phasani(a)ripe.net> wrote: > > Dear colleagues, > > We are reviewing IPv4 status hierarchies in the RIPE Database (looking at objects with the same status as their less-specifics). > > Some cases are clear - "ASSIGNED PA" shouldn't be allowed under "ASSIGNED PA", for example. Other statuses might need a closer look and we would like guidance from this working group. > > The RIPE Database does not currently have any limitations on creating inetnums that have the status "SUB-ALLOCATED PA" or "LIR-PARTITIONED PA" under inetnums with the same status. This often results in chains of inetnums that have the same status, sometimes ending with the sub-allocation of a single IP address. > > Although this might not seem useful at first glance, there might be practical uses for a few levels of sub-allocation. For example, a global company could give sub-allocations to its national branches, which make smaller sub-allocations to their multiple daughter companies. These daughter companies could then create and maintain assignments for their actual networks. > > However, this is not allowed under a strict reading of the policy, as only the LIR itself can make sub-allocations, and these must be used for assignments. > > Section 5.3 "Sub-allocations" of the IPv4 Address Allocation and Assignment Policies (ripe-733) states: > > "Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". > > [...] > > LIRs may make sub-allocations to multiple downstream network operators." > > https://www.ripe.net/publications/docs/ripe-733#54 > > Before making any changes, we want to be sure that we understand the intent of the policy and what the community wants us to do. Thus, we would like to hear from the Address Policy Working Group: > > - Should inetnums with these statuses be allowed to be created inside one another? > - Should there be a limit on the minimum size of a sub-allocation? > - Do we need a policy update? > > We look forward to your guidance. > > Kind regards, > -- > Petrit Hasani > Policy Officer > RIPE NCC > > > > >

1 0

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

12 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 Job Snijders 09 Nov '20

09 Nov '20

Hi Cynthia, The NRTM v4 initiative is in an awkward early stage where various parties (with *no* obligations towards each other!) are attempting to set the stage for the future existence of an inter-operable successor to the NRTM v3 protocol. As indicated before, the nature of this call was informal, akin to a hallway meeting at a conference. Decisions about the RIPE NCC database are made on the db-wg(a)ipe.net mailing list. It was a courtesy to this group to indicate some volunteers would have a call to help progress things. You too were free to join. Hallway meetings are not recorded. I'm interested to hear your opinions on-list or off-list! :-) Kind regards, Job On Sat, Nov 07, 2020 at 10:36:43AM +0100, Cynthia Revström wrote: > I would like to see more here on the mailing list, so I would request that > any future calls be recorded and published. > > I have opinions on this subject and I don't think me missing the call > should leave me out of the loop. > > - Cynthia > > On Fri, Nov 6, 2020, 11:31 Stavros Konstantaras < > stavros.konstantaras(a)ams-ix.net> wrote: > > > Hi Cynthia, > > > > Yes the call happened and the problem description is almost ready. Soon > > will be published here in the mailing list so the DB-WG chairs can > > officially create a new NWI and submit it to RIPE NCC developers > > > > Thank you for your support and your interest on that :) > > > > > > Best regards, > > > > Stavros Konstantaras | Sr. Network Engineer | AMS-IX > > M +31 (0) 620 89 51 04 | T +31 20 305 8999 > > ams-ix.net > > > > On 6 Nov 2020, at 02:51, Cynthia Revström via db-wg <db-wg(a)ripe.net> > > wrote: > > > > I also support creating a new NWI for a modernized NRTM like service. > > > > - Cynthia > > > > On Fri, 6 Nov 2020, 02:50 Cynthia Revström, <me(a)cynthia.re> wrote: > > > >> Hi Job, > >> > >> Was there a call about this yet? > >> > >> And if so, was there any outcome? > >> > >> - Cynthia > >> > >> On Thu, 29 Oct 2020, 20:38 Job Snijders via db-wg, <db-wg(a)ripe.net> > >> wrote: > >> > >>> On Thu, Oct 29, 2020 at 06:30:28PM +0100, denis walker wrote: > >>> > 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? > >>> > >>> Given that more people than just myself were engaged with this subject > >>> so far... maybe Stavros, Emil, a DB-WG chair, myself and any other > >>> interested parties can have a 1 hour group phone call to formulate an > >>> updated problem statement for NWI-12? > >>> > >>> Perhaps next week, November 4th, 15:00 UTC? Consider it a "hallway > >>> chat", not something formal. The chairs can report back to the mailing > >>> list. > >>> > >>> Kind regards, > >>> > >>> Job > >>> > >>> > >

4 4

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

pri.authdns.ripe.net
by Ronald F. Guilmette 05 Nov '20

05 Nov '20

Does this server/service have a corresponding equivalents in the other five regions? If so, what are their names? If I could consistantly do dig/axfr to get all of the reverse DNS delegation data globally, that would be almost convenient and easy to script.

2 2

missing data
by Ronald F. Guilmette 05 Nov '20

05 Nov '20

Can someone (anyone) please explain to me why the following file does not exist? ftp://ftp.ripe.net/pub/zones/185.in-addr.arpa-RIPE Who is responsible for generating the files in this directory? What is the process by which they are generated? What went wrong and who is going to fix it? And more to the point, where may I find the real, actual, and complete set of zone files? Are they hidden away behind some curtain, or in some secret room? Who do I have to know in order to be invited to view the real zonefiles that are actually being used for delegation?

5 7

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