- db-wg - mailman.ripe.net

RIPE Database Usage Survey - Database Requirements Task Force
by Boris Duval 20 Jan '20

20 Jan '20

Dear Colleagues, The RIPE Database Requirements Task Force (DBTF) needs your feedback! The DBTF has just launched a survey to know more about how the RIPE Community uses the RIPE databases. The results will provide feedback to the RIPE Database Task Force to help understand the relevance of the database to the RIPE Community and to help shape future RIPE Database policy. You can take the survey at: https://www.surveymonkey.com/r/PC9HTYP <https://www.surveymonkey.com/r/PC9HTYP> The deadline to answer the survey is 31 January. Feel free to share it with your network. Many thanks! Best, Boris Communications Officer RIPE NCC

1 0

NWI-9: Making the Whois NRTM Service Public
by Edward Shryane 16 Jan '20

16 Jan '20

Dear colleagues, Last month, as part of the DB-WG NWI-9 proposal, the RIPE NCC Executive Board resolved to make the Whois NRTM Service public. The full minutes of the Board meeting are on our website: https://www.ripe.net/about-us/executive-board/minutes/2019/minutes-130th-ri… We will now start working on all aspects related to implementing this decision and will have more details for you soon. Regards Ed Shryane RIPE NCC

2 1

database support for ed25519 PGP keys
by Marco d'Itri 19 Dec '19

19 Dec '19

Can RIPE staff clarify if there are plans to support PGP authentication of database updates using ed25519 keys? This should require not much more that upgrading gnupg to a modern release. -- ciao, Marco

2 1

converting a C class from PI to PA
by Franco Tauceri 19 Dec '19

19 Dec '19

Hello. What's the right how-to convert an existing C class from PI to PA? According to this: https://www.ripe.net/manage-ips-and-asns/ipv4/converting-pi-to-pa "Members can request this update via the LIR Portal." ... but I was not able to find HOW this may be done (If I try to edit the object, the field "status" is locked, and I can't edit it anyway... while I can edit other fields as usual) Regards -- Franco Tauceri DomainRegister m: 39.3483064202 w: https://DomainRegister.international e: franco.tauceri(a)domainregister.it

3 2

Whois Release 1.96
by Edward Shryane 04 Dec '19

04 Dec '19

Dear Working Group, RIPE Database release 1.96 has been deployed to the Release Candidate environment. We plan to deploy to production on Wednesday 4th December. This release contains the following main changes since 1.95.1: * Added "country:" attribute to organisation object type * Deprecated "mnt-lower:" attribute in autnum object type * Abuse-c validation comment must refer to the LIR organisation * Limit number of results in full-text search queries * Apply query limit to version queries 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

Removing the "mnt-lower" attribute from aut-num objects
by Edward Shryane 03 Dec '19

03 Dec '19

Dear Colleagues, as presented during the DB-WG session at RIPE 79, we plan to remove the "mnt-lower" attribute from the aut-num object type. From the RIPE database documentation [0]: “mnt-lower: This attribute has no meaning in the aut-num object. In the RIPE NCC service region, we do not allocate blocks of AS numbers for users to assign from. All AS numbers are assigned by the RIPE NCC therefore there is no hierarchy to ‘maintain’ or authorise against. This attribute should be deprecated.”  We plan to implement this change in the next Whois release (we will announce this separately). We do not expect any operational impact. It is currently an optional attribute. This attribute will be removed (with a warning) from any aut-num updates. At the same time, we plan to remove this attribute from approximately 948 of 35,144 aut-num objects. We will announce separately to the db-wg and affected maintainers, before and after removal. Please let me know of any feedback or questions you may have. Regards Ed Shryane RIPE NCC [0] https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-data…

1 1

Removing the Legacy Status "remarks" attribute
by Edward Shryane 03 Dec '19

03 Dec '19

Dear Colleagues, As presented during the DB-WG session at RIPE 79, we plan to remove the legacy status "remarks" attribute from inetnum and aut-num objects in the RIPE database. This remark was added to LEGACY resources in 2015, when implementing the policy 2012-07 "RIPE NCC Services to Legacy Internet Resource Holders” [0]. The remark states: "For information on "status:" attribute read https://www.ripe.net/data-tools/db/faq/faq-status-values-legacy-resources” We now consider this remark to be obsolete, and have already performed a similar cleanup on (most) aut-num objects in August 2017. We plan to shortly remove this remark from approximately 19,059 inetnum and 15 aut-num objects, and will email affected maintainers before and after the change. Please let me know of any feedback or questions you may have. Regards Ed Shryane RIPE NCC [0] https://www.ripe.net/participate/policies/proposals/2012-07

1 1

Internationalized domain names in the data abase?
by Ronald F. Guilmette 09 Nov '19

09 Nov '19

Sorry if I am interrupting any ongoing discussion, but I just have a quick and simple question... Is it permitted to have internationalized domain names appear within the database? By that I really mean to ask if it is permissible to have there appear in the data base IDNs which are written in their UTF-8 encoded forms, rather than, say, in punycode? I have found at least one specific case where an IDN does appear in the data base as a UTF-8 encoded string, but since I had never seen that before, I just wanted to know if that was an anomalous mistake or if it was consider normal, acceptable, and routine.

4 15

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

08 Nov '19

Hi Denis, What you name it as "meaningless values" are not meaningless to the organizations that they are using it. When you request a new allocation from NCC you will be asked to *"specify the country which the allocation will be announced"*, and based on your selection the country code will be set for both the inet(6)numns and allocation entry in the delegation file. This is the way that the country code is added in first place in delegation file. A member may decides to use the allocation later in a different country, and they can update the country code for inet(6)numns in ripe db, so I think the best practice is to sync the delegation file with the database and let the members decide what value should be set. Regards, Arash Naderpour On Fri, Nov 1, 2019 at 11:50 PM denis walker <dw100uk(a)yahoo.co.uk> wrote: > 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 file > ftp://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 countries > > If 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. > > cheers > denis > > 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 Naderpour > Parsun Network Solutions >

4 6

Re: [db-wg] [Ext] Re: NWI-10 Definition of Country
by Leo Vegoda 02 Nov '19

02 Nov '19

Sanjaya wrote: > Just a thought, maybe we could redefine the RIR extended delegated > file format to incorporate both cc values of inet(6)num|autnum and > organisation Whois objects like this: > > registry|xx|type|start|value|date|status|yy-custodianid > Where: > xx = country code of inet(6)num|autnum > yy = country code of organisation > > This will require agreement among the RIRs and some adjustments > by the relying parties, but provides a clearer mapping between > Whois objects and the stats file records. My 2 cents. The stats file could have its structure adjusted but remember that "country:" is a multiple attribute, so there could technically be as many countries listed as there are valid ISO 3166 codes. Also, aligning the stats file and inet(6)numns doesn't solve the fundamental issue, which is that the "country:" attribute in inet(6)nums has never had a clearly defined meaning. Readers and writers of the data almost certainly mean and understand different things. As there is already a lack of shared understanding and a very large deployed base, which includes lots of legacy software, managing a change that leaves the structure intact while potentially changing how that data should be used sounds dangerous to me. That's the sort of change that leads to subtle, quiet errors that are hard to debug. I think it is safer to break things in a way that is very obvious, so that they get noticed and fixed. Kind regards, Leo Vegoda

1 0

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

02 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 24 Oct '19

24 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 09 Oct '19

09 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