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