Restricting WHOIS searches to type: netname
One of the helpful options provided by the RIPE WHOIS server is the --types option which provides a list of what specific object types a given set of query results may be restricted to. That list is as follows: inetnum inet6num as-block aut-num as-set route route6 route-set inet-rtr filter-set peering-set rtr-set domain poetic-form poem mntner irt key-cert organisation role person Can anyone explain to me why "netname" is not on the above list? I would like to be able to query the data base for "ABC" but restrict the query so that I only get back the records for the dozen or so IP blocks whose registrants have (unwisely?) elected to label their networks as "ABC", while NOT also getting back all 16 or so of the organisation objects whose org-name: field contains the substring "ABC", much less the numerous and additional person and role records whose person: and role: fields also and likewise contain the substring "ABC". If I can selectively query just for poems, is there some reason why netnames deserve less respect? And as long as we are on the subject, may I safely infer from the presence, in the data base, of a dozen different networks named "ABC" that no attempt has ever been made to insure uniqueness of netnames within the data base? Are netnames even restricted, as they seem to be, to having a form which is rather strikingly reminicent of actual unique data base handles, i.e. consisting of only alphanumerics and hyphens? Regards, rfg P.S. I do not mean to pick on RIPE specifically here. A quick check reveals that whois.apnic.net and whois.afrinic.net also fail to support selective querying for just netnames... although in those two cases selective quering for poems is also not an option... a sad fact that has left me rather entirely bereft, as I'm sure you can all imagine.
On Fri, May 28, 2021 at 3:19 PM Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote: [...]
And as long as we are on the subject, may I safely infer from the presence, in the data base, of a dozen different networks named "ABC" that no attempt has ever been made to insure uniqueness of netnames within the data base? Are netnames even restricted, as they seem to be, to having a form which is rather strikingly reminicent of actual unique data base handles, i.e. consisting of only alphanumerics and hyphens?
Not only is uniqueness not required, the manual advises against it: "“netname:” – This is a name given to a range of IP address space. A netname is made up of letters, digits, the underscore character and the hyphen character. The first character of a name must be a letter, and the last character of a name must be a letter or a digit. It is recommended that the same netname be used for any set of assignment ranges used for a common purpose, such as a customer or service." https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-datab...
In message <CAPfiqjaLRwCwbnwbHDk_DEodCdCkjLhZ03DgSy=rAiO6BZdzWw@mail.gmail.com>, Leo Vegoda <leo@vegoda.org> wrote
Not only is uniqueness {of netnames} not required, the manual advises against it:
I expressed myself badly. Let me try again. Yes, I understand that it is both customary and advisable for a given organization to label all of its address block allocations with a single common netname. That having been said, it seems to me that the value of having netnames exist in the data base AT ALL is rather entirely nullified by either or both of the following two factors, at present: (*) A given unique netname, once selected and used by some given organisation, may then be -reused-, ad infinitum, by other and entirely unrelated organisations, to label *their* netblocks. (Example: "ABC" which appears to have been overloaded/reused by around a dozen different and unrelated organisations.) (*) It is not possible, at present, to perform selective WHOIS queries for *just* those inetnum/inet6num objects whose netname: fields exactly match some given specific netname. Because of the above two factors, I am not seeing any real usefulness of netnames within the data base AT ALL. On that basis, I would propose that either (a) RIPE should remove all netnames from the data base entirely (i.e. because they are clearly unnecessary flotsam/jetsam) or alternatively (b) RIPE should start supporting netnames properly. When I say "start supporting them properly" I mean of course (a) supporting selective searches for *just* netnames in the WHOIS server and also (b) creating a system whereby these symbolic names would be issued, by NCC in much the same (exclusive) way that NCC currently issues other types of guaranteed-unique data base handles, i.e. uniquely and exclusively, on on a per-organization basis. Regards, rfg
Hi Ronald The query option '--types' or '-T' refers to object types. The list you gave is the list of all object types. The 'netname' is an attribute in the INET(6)NUM object types. It is not, itself, an object type. It is possible to search on netname using the full text search https://apps.db.ripe.net/db-web-ui/fulltextsearch Choose 'Advanced Search' then select the object type (INETNUM or INET6NUM) then select the field 'netname'. cheers denis co-chair DB-WG On Sat, 29 May 2021 at 01:18, Ronald F. Guilmette via db-wg <db-wg@ripe.net> wrote:
In message <CAPfiqjaLRwCwbnwbHDk_DEodCdCkjLhZ03DgSy=rAiO6BZdzWw@mail.gmail.com>, Leo Vegoda <leo@vegoda.org> wrote
Not only is uniqueness {of netnames} not required, the manual advises against it:
I expressed myself badly. Let me try again.
Yes, I understand that it is both customary and advisable for a given organization to label all of its address block allocations with a single common netname.
That having been said, it seems to me that the value of having netnames exist in the data base AT ALL is rather entirely nullified by either or both of the following two factors, at present:
(*) A given unique netname, once selected and used by some given organisation, may then be -reused-, ad infinitum, by other and entirely unrelated organisations, to label *their* netblocks. (Example: "ABC" which appears to have been overloaded/reused by around a dozen different and unrelated organisations.)
(*) It is not possible, at present, to perform selective WHOIS queries for *just* those inetnum/inet6num objects whose netname: fields exactly match some given specific netname.
Because of the above two factors, I am not seeing any real usefulness of netnames within the data base AT ALL.
On that basis, I would propose that either (a) RIPE should remove all netnames from the data base entirely (i.e. because they are clearly unnecessary flotsam/jetsam) or alternatively (b) RIPE should start supporting netnames properly.
When I say "start supporting them properly" I mean of course (a) supporting selective searches for *just* netnames in the WHOIS server and also (b) creating a system whereby these symbolic names would be issued, by NCC in much the same (exclusive) way that NCC currently issues other types of guaranteed-unique data base handles, i.e. uniquely and exclusively, on on a per-organization basis.
Regards, rfg
hi, On Fri, May 28, 2021 at 03:19:18PM -0700, Ronald F. Guilmette via db-wg wrote:
One of the helpful options provided by the RIPE WHOIS server is the --types option which provides a list of what specific object types a given set of query results may be restricted to.
That list is as follows:
inetnum inet6num [..] Can anyone explain to me why "netname" is not on the above list?
If I'm not misunderstanding you, what you want to see is these objects: inetnum: 82.108.52.0 - 82.108.53.255 netname: ABC so that's the "type" you need to specify: "inetnum". "netname:" is not an object type, but an attribute. $ whois3 -r -T inetnum ABC -> 15 objects (-r restricts returning of referred person: objects) Or do you want to restrict your search to "only match ABC in the netname: attribute"? I'm not sure if it can be done, but that's not what "--type" is for in any case. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
participants (4)
-
denis walker -
Gert Doering -
Leo Vegoda -
Ronald F. Guilmette