This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Previous message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Next message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ronald F. Guilmette
rfg at tristatelogic.com
Mon Nov 21 03:48:40 CET 2016
In message <d4986f5c-1160-b35f-7b9a-cf5a15ba47bf at yahoo.co.uk>, denis <ripedenis at yahoo.co.uk> wrote: >I have added some more comments below about this specific ROUTE object >you gave as an example. For the record, I didn't deliberately select that one as being in any way exemplary of anything special... just a random route which is listed as being maintained by RIPE-NCC-LOCKED-MNT. (In fact, I think that that one just happened to be the very last one on my creation-date sorted list of RIPE-NCC-LOCKED-MNT maintained routes.) >This is what we refer to as an 'out of region' ROUTE object. Yes. So it would appear. >This is one >of the more extreme cases where both the prefix and ASN are outside the >RIPE region. But the RIPE Database allows creation of such objects. >Currently there is no authorisation done by the real resource holders >and no notifications are sent to them that this object has been created >in the RIPE Database. The resource holders in APNIC and LACNIC regions >may not know this ROUTE object exists. Anyone can create such an object. I understand what you've just told me, and I appreciate you telling me (because I did not know these facts until now), but I hope and trust that you will understand it if I say that the facts you have just related to me are rather deeply disappointing. Setting my disappointment aside for a moment, I hope that you can help me to further understand your assertion that "Anyone can create such an object." I am anyone. How would *I* go about creating such an object in the RIPE data base, exactly? Is there a web form someplace that one simply fills out and then presto! >This issue has been discussed at several recent RIPE Meetings but no >consensus has been reached on how to move forward. As in all such cases, my guess is that the absence of consensus probably has less to do with the technicalities of the various proposals than it has to do with the definition of the term "forward" in this context. (My own view is that parties allowed to put information in the data base... information that other people may then rely on... should at least be "known" and/or at least "identifiable", i.e. for some value of "known" or "identifiable". If that is not the case, then it is not clear what materially separates the RIPE data base from a dumping ground for random gibberish, a la 4chan.) >But as you point out, >there is an added complication now with some of these objects being >locked. This was not part of the previous discussion on the subject. So >no one is maintaining these objects, no one can delete them and maybe no >one wants it to be there. And as you point out below, some people may >give this (rogue) object credibility because it exists. Whoever created >this object is unlikely to ask the RIPE NCC to unlock it as they may not >have any valid reason for it being there. So this object is stuck in >limbo... Thank you for confirming the essence of my concern. Obviously, I'm not happy that such an issue exists, but it is at least of some minor comfort to know that I am not entirely alone in seeing that there could be an annoying issue here, albeit one that, to my knowledge, is, most probably, quite limited in scope. >Perhaps if one of the resource holders asks the RIPE NCC to >delete it they will do, but someone has to tell the resource holders it >exists. Well, now that I think about it, the problem is actually not materially different from the case where a route is listed as being maintained by someone/something -other than- RIPE-NCC-LOCKED-MNT, but where the maintainer cannot not be located or contacted after a reasonable effort to do so (e.g. died, became a Tibetan Monk, got hooked on crack and no longer uses the Internet, etc.) The problem, of course, is less about the identity of the pro forma mnt-by person or entity than it is about the response, if any, by NCC staff to a report of a bogus route, in particular where sorting out truth from fiction is difficult, e.g. where the legitimate registrant of the relevant space has himself (or itself) long ago died and gone on to the personal or corporate hearafter. (And of course it doesn't help the investigation any when the registrant in question is/was in a whole different region.) In my country (USA), with respect to real estate, we have something called a "title search". It costs some modest amount of money to have it done, i.e. for a given specific piece of property. I don't know all the details, but I gather that they check some number of data sources, and when they have done that, if no red flags pop up, then the search is considered "done" and the property is transferred. I assume that a similar process is applied, e.g. in the case where a person or company has died, without a will, and -the government- then has to come in and take over the remaining abandoned property. Maybe I'm stating the obvious, but I think that "Internet governance", such as it is, is going to have to formalize this kind of a process at some point, and in fact, it is somewhat remarkable that this hasn't already occurred. There's already lots of dead wood in all of the RIR WHOIS data bases... stuff left over from about 30 years of births and deaths... and I don't think that just leaving it all to rot in place is in any sense a solution. It is all starting to become rather, um, aromatic. Regards, rfg
- Previous message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
- Next message (by thread): [db-wg] Puzzled by RIPE-NCC-LOCKED-MNT
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]