In message
<CAPfiqjaLRwCwbnwbHDk_DEodCdCkjLhZ03DgSy=raio6bzd...@mail.gmail.com>,
Leo Vegoda <[email protected]> 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
