- db-wg - mailman.ripe.net

Re: [db-wg] NWI-10 Definition of Country
by ripedenis＠yahoo.co.uk 01 Nov '19

01 Nov '19

Hi Arash If many organisations are using these values then, unfortunately, you are basing decisions on meaningless values. The country attribute in resource objects is undefined. Users can set this to any country they wish with no meaning to anyone reading the value from the database. >From the description of the extended delegated stats fileftp://ftp.ripe.net/ripe/stats/RIR-Statistics-Exchange-Format.txt it says this about the country code:Format: registry|cc|type|start|value|date|status[|extensions...] registry = One value from the set of defined strings: {apnic,arin,iana,lacnic,ripencc}; cc = ISO 3166 2-letter country code, and the enumerated variances of {AP,EU,UK} These values are not defined in ISO 3166 but are widely used. The cc value identifies the country. However, it is not specified if this is the country where the addresses are used. There are no rules defined for this value. It therefore cannot be used in any reliable way to map IP addresses to countriesIf you were to sync the stats file with resource object data you are in effect setting an undefined field in the stats to an undefined value from the database. The purpose of NWI-10 is to create a well defined country value in both the stats file and the ORGANISATION object. The legal location of an organisation is currently the only well defined country information available. There is no information available anywhere in the database or stats file telling you where a network is being used. cheersdenis co-chair DB-WG On Friday, 1 November 2019, 05:37:28 CET, Arash Naderpour via db-wg <db-wg(a)ripe.net> wrote: Hi, I'm new to DB-WG, but want to express my opinion in this regard, from problem definition:"Historically the country code was used to refer to the location of the network" There are plenty of organization out there that are already set their network and firewalls rules to use country code value in delegation file as reference to the location of the network. Changing the rule to to something new, will cause problem for clients and providers, so I don't think it is a good idea, country code in delegation file can be synced with the country code for resource object in RIPE DB.A new attribute in organization object refers to where the resource holder is legally based is totally fine, but having the same value in delegation file can break networks and services. Regards, Arash NaderpourParsun Network Solutions

2 1

Re: [db-wg] NWI-10 Definition of Country
by Arash Naderpour 01 Nov '19

01 Nov '19

Hi, I'm new to DB-WG, but want to express my opinion in this regard, from problem definition: "Historically the country code was used to refer to the location of the network" There are plenty of organization out there that are already set their network and firewalls rules to use country code value in delegation file as reference to the location of the network. Changing the rule to to something new, will cause problem for clients and providers, so I don't think it is a good idea, country code in delegation file can be synced with the country code for resource object in RIPE DB. A new attribute in organization object refers to where the resource holder is legally based is totally fine, but having the same value in delegation file can break networks and services. Regards, Arash Naderpour Parsun Network Solutions

1 0

country attribute in aut-num
by Cynthia Revström 23 Oct '19

23 Oct '19

Hello, I ran into an issue today that was the inability to have a country attribute in the aut-num object, despite having a country code in the delegated file. I would like to see it added to WHOIS. - Cynthia

4 5

Apologies for the accidental email
by Fallon Albrecht 23 Oct '19

23 Oct '19

Dear working group, I apologise for the accidental email that was sent out, it was meant to be an internal feature request. Sorry for spamming you. Fallon

1 0

Re: [db-wg] [swe-database] Implementation -K Flag Request
by Fallon Albrecht 23 Oct '19

23 Oct '19

Hi Ed, I have some feature requests: 1. To have a perma link option for full text search. 2. If a SSO account is associated with the mnt-by of the inetnum and they query the allocation that they also can see all the more specific objects. 3. If the SSO account is a Ripe NCC email address and you login that the functionality “do not retrieve related objects” is disabled. That is’t for now. Thank you! Fallon > On 23 Oct 2019, at 11:20, Valentino Dijkstra <vdijkstra(a)ripe.net> wrote: > > Hi Ed, > > Thank you for the reply. > > That is ok for us, in case we are receiving any other future request I will let you know. > > Cheers, > > Valentino > > >> On 22 Oct 2019, at 17:21, Edward Shryane <eshryane(a)ripe.net> wrote: >> >> Thanks Valentino, >> >> I added a story to the DB team's backlog for this feature request: "db-web-ui: Support the --primary-keys/-K flag on the Query Page" (https://jira.ripe.net/browse/DB-2659) >> >> We are busy with other work, but we'll review when we're next working on new website functionality. >> >> The DB team doesn't need a "feature request" tag in Zendesk (unless CS needs it), as we're tracking everything in one place (Jira) already. >> >> Just send us the request and I'll add it to our backlog. You can then close the Zendesk ticket. >> >> We add a ticket # to the story (or bug) in Jira, so we remember to contact the user again once it's done. >> >> Regards >> Ed >> >> >> >> >>> On 22 Oct 2019, at 16:40, Valentino Dijkstra <vdijkstra(a)ripe.net> wrote: >>> >>> Dear Team, >>> >>> >>> In the last couple of weeks we did not receive any particular future request. >>> >>> The only request came from ticket 219462 requesting to have the -K flag implemented in order to >>> retrieve all the route objects related to a certain range. >>> >>> Also I will make sure that we will have a “future request” tag in the DB queue so it will be easy to retrieve the tickets in the future. >>> >>> Let me know if this can be done in a short period of time. For further questions feel free to contact me. >>> >>> Cheers, >>> >>> Valentino >>> CS_______________________________________________ >>> swe-database mailing list >>> swe-database(a)ripe.net >>> https://intlists.ripe.net/mailman/listinfo/swe-database >> >

1 0

Set Default Maintainer on all Top-level Resources
by Edward Shryane 22 Oct '19

22 Oct '19

Dear Colleagues, as presented during the DB-WG session at RIPE 79, we wish to extend the "Default Maintainer" functionality for LIR organisations. Firstly, to set the Default Maintainer (with an mnt-by: attribute) on *all* top-level resources (where the org: reference is the LIR itself): - IPv4 and IPv6 allocations (the current behaviour) - ASNs - IPv4 and IPv6 assignments - IPv4 LEGACY resources Secondly, to automatically (re-)set the Default Maintainer on a nightly basis, on *all* top-level resources: - Fix inconsistencies due to manual updates - Add the default maintainer (with an mnt-by: attribute), and remove other user maintainer(s) Please let me know of any feedback or questions you may have. Regards Ed Shryane RIPE NCC

3 4

Cleanup Locked Person Objects - Implementation Plan
by Edward Shryane 21 Oct '19

21 Oct '19

Dear Colleagues, As presented during the DB-WG session at RIPE 79, we will shortly begin to cleanup locked person objects in the RIPE database. We will select person objects maintained by RIPE-NCC-LOCKED-MNT, which are referenced by inetnum allocations or assignments, and re-assign them to the resource maintainer. The goals of this cleanup are: - Align with RIPE-730 Policy - “Registration data (range, contact information, status etc.) must be correct at all times (i.e. they have to be maintained).” - Align with GDPR - assign responsibility for contact details to the correct maintainer - Cleanup 90% of locked person objects in the RIPE database (the remainder will be cleaned up separately) We will implement this cleanup as follows: - Announce to ncc-announce, ncc-services-wg and db-wg beforehand - Perform the cleanup one LIR at a time - Email the affected LIR and assignment maintainers beforehand to explain the change, including a list of planned updates - Set the locked persons mnt-by to the assignment maintainer, where we are sure of a link between them (e.g., if the objects were originally created together, and if the assignment maintainer has not changed since (this applies to two thirds of all locked persons)). - Otherwise, set the locked persons mnt-by to the LIR maintainer (for one third of all locked persons). - Email the LIR and assignment maintainers afterwards, and ask them to validate the contact details on their resources. Please let me know of any feedback or questions you may have. Regards Ed Shryane RIPE NCC

1 0

Agenda RIPE79 - Database Working Group
by William Sylvester 10 Oct '19

10 Oct '19

DB-WG Members, Here is our agenda for the RIPE meeting next week. Best regards, DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. DB Requirements Tast Force Update – 5 mins D. NWI-8 LIR’s SSO Authentication Groups Demonstration – 5 mins Mahesh Aggrwal, RIPE NCC E. NWI-3 RIPE-NONAUTH perspective, still needed? – 15 mins Job Snijders, NTT F. NWI-9 In-Band Notification Mechanism – 15 mins TBD G. NWI - Open Proposals – 15 mins Z. AOB (open discussion)

1 0

GDPR and the RIPE Database
by Edward Shryane 08 Oct '19

08 Oct '19

Dear Working Group, as mentioned in last week's DB-WG meeting, we will shortly be implementing the following changes: - Do not include personal data in historical queries (notify, e-mail, address attributes). - Do not include person/role references in historical queries (admin-c, tech-c, ping-hdl, zone-c). A legal review found we should not return historical contact details, as they may contain personal data, which is not in line with the purpose of the RIPE database or data protection legislation. For background, Maria Stafyla from RIPE NCC Legal presented on this topic at RIPE 76: https://ripe76.ripe.net/presentations/101-GDPR-Database-WG-RIPE-76.pdf Regards Ed Shryane RIPE NCC

4 8

NWI-10 Definition of Country
by ripedenis＠yahoo.co.uk 08 Oct '19

08 Oct '19

Colleagues The DB-WG chairs have agreed to create "NWI-10 Definition of Country". This is an issue that has been debated many times over many years and needs a solution. The Solution Definition below is based on a presentation made at RIPE 78 by the RIPE NCC. There has been very little discussion on this since RIPE 78 so perhaps we can have a final round of pros and cons over this next week and then see if we have a consensus. cheersdenis co-chair DB-WG NWI-10 Definition of Country Problem DefinitionThere is no clarity for the meaning of the country code attribute in the RIPE Database and the Extended Delegated statistics. This creates confusion and inconsistencies. Historically the country code was used to refer to the location of the network. Until recently this location was, in most cases, identical to the legal presence of the resource holder. However, in recent years there has been a growing number of resource holders that have, for various reasons, their legal presence in one country, but the network located in another country. There is also a growing number of out-of-region members resulting in an increase in requests to update the country code in the Extended Delegated Statistics for different purposes (e.g. commercial). While the country code attribute in the RIPE Database can be updated directly by the resource holder, the Extended Delegated Statistics are maintained by the RIPE NCC and they were created as part of a joint effort from the RIRs with a specific purpose. Solution Definition1. The country code for resource objects in the RIPE Database should remain as it is currently, ie the resource holder remains responsible for maintaining this attribute and deciding what the country code should be, according to whatever criteria best suits their needs. 2. A new attribute should be added to the ORGANISATION object, which contains a country code that refers to where the resource holder is legally based. The RIPE NCC would be responsible for this field and would only make updates to this field after being provided with documentation that proves the resources holder is legally-based in another country. This would essentially be the same process for updating an organisation's legal name currently. 3. The new country code value in the ORGANISATION object would then be reflected in the Extended Delegated Statistics – so that this file will show where the holder of a resource is legally based and will not make any claims about where the resources are being used. This will ensure the Extended Delegated Statistics file is consistent with those published by the other RIRs. This may mean there is a greater divergence between the country code contained in resource objects in the RIPE Database and those listed in the statistics file. As the country code in the resource objects only has meaning to the resource holder, which should be made clear, this should not be a problem.

9 13

Synchronising Users from the LIR Portal to the Default Maintainer in the RIPE Database
by Edward Shryane 23 Sep '19

23 Sep '19

Dear colleagues, Following a request by the Database Working Group earlier this year, we have implemented a new feature to synchronise users from the LIR Portal to the Default Maintainer in the RIPE Database. More information can be found in the Labs article: https://labs.ripe.net/Members/ed_shryane/synchronising-users-from-the-lir-p… The discussion by the DB-WG was defined as the Numbered Work Item NWI-8 : https://www.ripe.net/manage-ips-and-asns/db/numbered-work-items We plan to deploy this new feature to production next Monday, 23rd September. Regards, Ed Shryane RIPE NCC

1 1

Whois Release 1.95
by Edward Shryane 18 Sep '19

18 Sep '19

Dear Working Group, RIPE Database release 1.95 has been deployed to the Release Candidate environment. If no issues are found, we plan to deploy to production on Monday, 9th September. This release contains two main changes: - Whois queries are now normalised to the latin-1 character set, in the same way as for Whois updates (any non-latin-1 input is normalised into latin-1, or substituted with a question mark). If any normalisation is performed, an extra comment is added to the response to inform the user. - Attributes which can contain personal data (address, e-mail and notify) are filtered out from historical object versions (i.e. when using the --show-version and --diff-versions flags). For a full list of changes, refer to the release notes: 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 2

Call for Presentations / Draft Agenda RIPE79 - Database Working Group
by William Sylvester 16 Sep '19

16 Sep '19

Dear Working Group Members, Below is the proposed agenda for the Database Working Group for RIPE79. If you would like to present please submit your content as soon as possible to the chairs. If you have any questions, comments, or requested changes please let the chairs know. Best regards, William & Denis DB-WG Chairs A. Introduction - 5 min * Welcome * Scribe * Jabber * Agenda B. Operational Update RIPE Database – 20 mins Edward Shryane, RIPE NCC C. Proposed Presentations HERE – 60 mins D. NWI - Open Proposals – 5 mins Z. AOB (open discussion)

1 0

Fw: parms for simple answer
by ripedenis＠yahoo.co.uk 27 Aug '19

27 Aug '19

Hi Randy You can also use the restful API described here:https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe… for your specific query it returns this: denis$ curl 'http://rest.db.ripe.net/ripe/inetnum/147.28.0.0/16?unfiltered' <?xml version="1.0" encoding="UTF-8"?> <whois-resources xmlns:xlink="http://www.w3.org/1999/xlink"> <objects> <object type="inetnum"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/inetnum/147.28.0.0 - 147.28.255.255"/> <source id="ripe"/> <primary-key> <attribute name="inetnum" value="147.28.0.0 - 147.28.255.255"/> </primary-key> <attributes> <attribute name="inetnum" value="147.28.0.0 - 147.28.255.255"/> <attribute name="netname" value="RG79-147-28"/> <attribute name="country" value="US"/> <attribute name="org" value="ORG-RO47-RIPE" referenced-type="organisation"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/organisation/ORG-RO47-RIPE"/> </attribute> <attribute name="admin-c" value="RB45695-RIPE" referenced-type="person"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/RB45695-RIPE"/> </attribute> <attribute name="tech-c" value="RB45695-RIPE" referenced-type="person"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/person/RB45695-RIPE"/> </attribute> <attribute name="status" value="LEGACY"/> <attribute name="mnt-by" value="MAINT-RGNET" referenced-type="mntner"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/MAINT-RGNET"/> </attribute> <attribute name="mnt-domains" value="MAINT-RGNET" referenced-type="mntner"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/MAINT-RGNET"/> </attribute> <attribute name="mnt-routes" value="MAINT-RGNET" referenced-type="mntner"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/MAINT-RGNET"/> </attribute> <attribute name="mnt-by" value="RIPE-NCC-LEGACY-MNT" referenced-type="mntner"> <link xlink:type="locator" xlink:href="http://rest.db.ripe.net/ripe/mntner/RIPE-NCC-LEGACY-MNT"/> </attribute> <attribute name="created" value="2016-03-16T15:16:35Z"/> <attribute name="last-modified" value="2019-08-08T01:21:04Z"/> <attribute name="source" value="RIPE"/> </attributes> </object> </objects> <terms-and-conditions xlink:type="locator" xlink:href="http://www.ripe.net/db/support/db-terms-conditions.pdf"/> </whois-resources> cheersdenis co-chair DB-WG On Tuesday, 27 August 2019, 14:43:41 CEST, Randy Bush via db-wg <db-wg(a)ripe.net> wrote: hi shane, > The '-r' flag seems to disable related answers and is not > type-specific. ``` ran.psg.com:/home/randy> uname -a Linux ran.psg.com 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ran.psg.com:/home/randy> whois -h whois.ripe.net -r 147.28.0.0/16 % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '147.28.0.0 - 147.28.255.255' % Abuse contact for '147.28.0.0 - 147.28.255.255' is 'blackhole(a)bogus.com' inetnum: 147.28.0.0 - 147.28.255.255 netname: RG79-147-28 country: US org: ORG-RO47-RIPE admin-c: RB45695-RIPE tech-c: RB45695-RIPE status: LEGACY mnt-by: MAINT-RGNET mnt-domains: MAINT-RGNET mnt-routes: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT created: 2016-03-16T15:16:35Z last-modified: 2019-08-08T01:21:04Z source: RIPE % Information related to '147.28.0.0/16AS3130' route: 147.28.0.0/16 descr: RGnet/PSGnet origin: AS3130 mnt-by: MAINT-RGNET created: 1970-01-01T00:00:00Z last-modified: 2003-12-22T01:59:14Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.94.1 (ANGUS) ```

1 0

parms for simple answer
by Randy Bush 27 Aug '19

27 Aug '19

is there no parm to whois which results only in the specific answer, not also the org: person: and grandmother: objects? i want it irrespective of object type i am looking up. ``` whois -h whois.ripe.net -r -T inetnum 147.28.0.0/16 | egrep -v '^($|%)' ``` is opbject-type specific randy

4 5

AUT-NUM authorization on ROUTE(6) objects
by Sander Steffann 27 Aug '19

27 Aug '19

Hi, I was looking at https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data… That page still documents that "the creation of a route object also needs authorisation from the AS Number that originates the route". I thought that requirement got removed some time ago. Am I confused or does the documentation need updating? Cheers, Sander

4 4

Extending Unreferenced Object Cleanup
by Edward Shryane 21 Aug '19

21 Aug '19

Dear Working Group, as presented at last week's DB-WG meeting, I'd like to extend the current Unreferenced Object Cleanup: https://www.ripe.net/manage-ips-and-asns/db/support/clean-up-of-unreference… which deletes the following unreferenced objects after 90 days: - organisation, mntner, person, role objects - mntner - person/role pairs to also delete the following groups of unreferenced objects after 90 days: - mntner - organisation pairs - organisation - person/role pairs - mntner - person/role - organisation groups This change affects a small number of objects in the database, but is consistent with the goal of removing unnecessary data. Please give me your feedback on this proposal, in particular if there are operational reasons to retain this data. Regards Ed Shryane RIPE NCC

4 4

ORG record vetting ?
by Ronald F. Guilmette 05 Aug '19

05 Aug '19

Just a point of curiosity... For each newly created ORG record that is put into the data base, if the ORG record represents something other than a natural person, does NCC staff make any effort to check to make sure that the alleged non-person entity actually exists, I mean, you know, as a legal entity, somewhere on planet earth? Or is this just another one of those niceties that cannot, in practice, be performed within the RIPE region because the membership has not explicitly approved it? Regards, rfg

10 35

ORG vetting redux
by Ronald F. Guilmette 02 Aug '19

02 Aug '19

I have a trivial little Perl program called "dupcount" that does exactly what its name implies. I ran it on a fresh copy of the database, as part of a command pipeline as follows: % gzcat ripe.db.gz | grep '^org-type:' | dupcount Results were as follows: 99651 org-type: OTHER 24055 org-type: LIR 1131 org-type: Other 1034 org-type: other 3 org-type: OTher 1 org-type: RIR 1 org-type: IANA 1 org-type: WHITEPAGES 1 org-type: OTHEr I gather from this that case should generally be ignored when parsing this field value. Would it also be appropriate to assume that LEGACY number resources have generally been associated with ORG records of type OTHER? Have any or all of those ORGs ever been vetted in any way? And what about number resources that are presently associated with no ORG whatsoever, for example, the following ones? I am having a bit of trouble understanding how a <<void>> organization gets (or got) vetted by NCC. (I should perhaps clarify that of the following 120 ASNs, fully 108 of them are listed as status: LEGACY, however that leaves another 12 wih status: ASSIGNED, and for those, and also the LEGACY ones, the vetting, if any, that has been applied seems to me to be a at least a bit ambiguous.) AS248 AS249 AS250 AS528 AS529 AS544 AS590 AS593 AS697 AS709 AS710 AS712 AS761 AS764 AS777 AS1110 AS1112 AS1114 AS1115 AS1116 AS1118 AS1119 AS1121 AS1122 AS1123 AS1124 AS1126 AS1135 AS1137 AS1203 AS1234 AS1241 AS1253 AS1257 AS1270 AS1271 AS1272 AS1273 AS1274 AS1279 AS1290 AS1304 AS1318 AS1342 AS1352 AS1353 AS1653 AS1654 AS1663 AS1732 AS1739 AS1748 AS1752 AS1774 AS1780 AS1833 AS1835 AS1837 AS1889 AS1893 AS1903 AS1921 AS1922 AS1923 AS1960 AS1961 AS1962 AS1967 AS2004 AS2012 AS2016 AS2017 AS2026 AS2028 AS2029 AS2036 AS2045 AS2049 AS2147 AS2148 AS2481 AS2487 AS2494 AS2529 AS2530 AS2578 AS2609 AS2643 AS2921 AS3151 AS3843 AS3917 AS3918 AS4148 AS4457 AS4458 AS4524 AS4588 AS4589 AS4974 AS6067 AS6168 AS6412 AS8093 AS8346 AS8452 AS11341 AS11660 AS15808 AS18732 AS19376 AS20598 AS21042 AS21174 AS21491 AS22627 AS24691 AS25429 AS29032 AS29039

2 2

WHOIS client(s) and Windows ?
by Ronald F. Guilmette 28 Jul '19

28 Jul '19

I myself am an old school die hard UNIX guy from way back, but recently I have been wanting to shared certain information relating to certain WHOIS records with some other folks, some of whom are strictly and only Windows users. Are there any WHOIS clients available for Windows that provide the full range of RIPE WHOIS options? If not why not? (Sad as it may be, Windows is still used by about 90% of everybody, so it seems odd that WHOIS clients are only built for UNIX and UNIX-like systems.) Has anyone ever tried to build the RIPE WHOIS client, from sources, on Windows? If so, what was the result? I have been telling my Windows-only friends to try to get WHOIS info from, for example, whois.ripe.net, by just using telnet and connecting to port 43 and then typing in their options and search keys, but as I have learned, the results in that case are entirely sub-optimal. If you do this, you will get a "stairstep" set of output lines, apparently because the output of whois.ripe.net, like most other WHOIS servers, assumes that ends-of-lines should be represented by just <LF> and not by the <CR><LF> sequence that is formally required for most other protocols. (The latter is fine for UNIX and UNIX-like systems, while the former is generally needed for Windows systems.) The original RFCs covering WHOIS (RFC 812 and RFC 954) were rather entirely ambiguous about how response lines should be terminated, however the newer RFC 3912, Section 3, strongly hints that response lines should be terminated with <CR><LF> even though it fails to ever come out and say that explicitly. So, is the whois.ripe.net WHOIS server failing to be standard confoming? Regardless of whether it is or isn't I really do need a WHOIS client that I can give to my various Windows-only friends. Any advice or suggestions would be appreciated. Regards, rfg

3 3

Country Codes and that lack thereof
by Ronald F. Guilmette 28 Jul '19

28 Jul '19

I have a number of very useful Perl scripts now that can and do parse and then do interesting and useful things with RIPE WHOIS records, and also with WHOIS records from other regions. In particular, I have a tool that, if given a sizable IPv4 address range, can show the names *and* ISO-3166 two-letter country codes for all of the ASNs that are routing parts of the given IP range, in a nice pretty table. Mostly, this just works, but as I have learned, there are sizable number of cases within the RIPE WHOIS data base where the relevant home country for the ASN is not present in the WHOIS record for the ASN, and where figuring out the home country requires a lot of educated guesswork (e.g. if DO NOT see a country: line but you DO see the name "Sophia" in an address: field, then you can guess that the home coutry is Bulgaria, and that thus, the apprtopriate ISO-3166 code is "BG". I would like to know if I am the only person on the planet who has a concern about this issue/problem. If so, then I will just slink back into my hole and be quiet. If not however, and if others also feel that every organization and resource record present within the RIPE dat abase really should have a contry: line that clarifies where the bloody thing should, nominally, be considered to exist, then I have a good deal more to say on this topic. First, I'd like to say ARIN seems to have solved this problem long ago, in the case of their data WHOIS data base. My Perl script has yet to encounter a single ARIN WHOIS record for a number resource that does not contain an explicit Country: line. But the absence of country: lines in RIPE WHOIS records is, I'm sorry to say, quite extensive. Second, I'd like to ask the obvious question: How did things get like this in the RIPE data base in the first plac? When a party is creating a RIPE WHOIS record for some resource, are they allowed to enter essentially any bloody thing they like, including even leaving out such important information as the home country where the resource is based or where it will primarily be used? If so, why? Why isn't there a form on the RIPE web site, which resource holders must fill out in order to create a new record, and that simply does not allow the user to proceed unless and until the country information has been provided? This is not a debatable policy matter. This is just common sense, I think. And it isn't as if such a web form would be at all difficult to implement. Thirdly, I'd like to just state for the record that in essentially all of the cases I have sewen so far where RIPE WHOIS records lack country: information, it is, in general, reasonably easy to infer such information from other hints in the record itself, as noted above. Thus, NCC staff could... and I believe should... go through all of the records that are currently missing this country: infromation and manually insert it themselves, on behalf of the resource holder. (This would be neither hard nor wexcessively time consuming, as the number of records that lack the country: information appear to me to be a tiny minority of the total number of records within the data base.) Lastly, because I have already found a lot of these problematic WHOIS records that lack the country: information, and because I have already taken the time to scrutinize then all, and make the necessary inferences to determine the likely country codes, I would like to offer myself as a volunteer assistant to the NCC staff for this small project, i.e. of cleaning up the existing records and insuring that they all do have at least some indications of the relevant country in each case. I will be only too happy to lend my assistance towards this worthwhile goal. Of course, some troublemaker will undoubtedly now pop up here to claim that reasonable inforences cannot be made about the primary country that should be associated with any given resource, and/or that many resources are in fact used in a manner that crosses national boundaries. I disagree with the former point, based on my experience so far, and would point out that all resource records are *supposed* to have *some* address for the resource holder in them anyway, and whatever that mailing address is, for each resource record, that mailing address can and should suffice as the best approximation of the "home country" for the resource. Likewise, even though a given resource may be used in a multi-national way, I would argue that it would still be better to have *some* country indicated for it, rather than none, as is currently the case in many records. The perfect is the enemy of the good, and none of this has to be perfect in any sense. A best guess for the county in each case where the resource holder has not supplied that information is necessarily going to be better than nothing in most cases. I look forward to comments on this simple suggestion. Quite simply, I am suggesting that every resource record and every ORG record should include a country: line which itself should specify an ISO-3166 standardized country code, no exceptions. Most already do, or else have a fully spelled-out country names, and it appears to an outsider, such as myself, that the fact that something slightly less than 100% of these records have this country information is just a matter of sloppy DB maintenance which can be and should be corrected. I hope you will all agree. Regards, rfg

2 1

Whois Release 1.94.1
by Edward Shryane 08 Jul '19

08 Jul '19

Dear Working Group, RIPE Database release 1.94.1 has been deployed to the Release Candidate environment. This is a bug-fix release, with no new features. If no issues are found, we plan to deploy to production on Monday, 8th July. This release contains two main changes: - Consistent substitution of invalid latin-1 characters (e.g. control characters) and non-latin-1 characters across all Whois Update APIs (e.g. Syncupdates, Mailupdates, REST API). Following this release, we will also cleanup existing objects to be consistent. - Improvements to the RDAP protocol implementation (https://rdap.db.ripe.net). For a full list of changes, refer to the release notes: 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

RIPE Database Search
by Cynthia Revström 05 Jul '19

05 Jul '19

Hello DB-WG, not sure if this is the correct place but anyways... The WHOIS search bar on https://www.ripe.net works but not on https://apps.db.ripe.net/db-web-ui/#/query <https://apps.db.ripe.net/db-web-ui/#/query?searchtext=as56789> In both cases I am talking about the search bar on the top of the page not the one in the middle. - Cynthia

2 2

Out-Of-Region routes ?
by Ronald F. Guilmette 03 Jul '19

03 Jul '19

My recollection is that there came a time ... I can no longer remember if that was just last year or the year before... when it was decided and implmented that the RIPE DB would no longer allow the addition of route objects for out-of-region address space. Somebody please refresh my memory. At that time, how was it decided that pre-existing route objects for out-of-region IP address locks would be handled? I gather than those were not in fact ejected from the data base, but rather that it was decided... I seem to recall... to simply mark them in some distinctive way. Is that correct? And if so, what was/is that distinctive marking?

2 2

--list-versions
by Ronald F. Guilmette 26 Jun '19

26 Jun '19

I am having some trouble applying the --list-versions option to some things that are either (a) the first IPv4 address of an inetnum: object and/or (b) a netname: object. Is this option even supposed to work on such things? Examples: --list-versions 194.162.0.0 --list-versions DE-ECOTEL-950515 I am having serious trouble understanding why this isn't working. If someone could explain, I'd appreciate it. Regards, rfg P.S. Yes, I am aware already that --list-versions and --show-version options do not work on person & role objects.

5 7