[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 ]
denis
ripedenis at yahoo.co.uk
Mon Nov 21 03:30:24 CET 2016
Hi Ronald On 21/11/2016 02:46, Ronald F. Guilmette wrote: > > OK, so this all is starting to make a little bit more sense now, > however I am still puzzled. If I've understood correctly, then > RIPE-NCC-RPSL-MNT was depreciated starting in 2004. And there is No. The MNTNER 'ripe-ncc-none-mnt' was deprecated in 2004 and any object referencing only that MNTNER was locked at that time. The MNTNER 'ripe-ncc-rpsl-mnt' is still in use now as a means of bypassing authorisation for out of region resources to allow these ROUTE objects to be created in the RIPE Database. > even a comment block in the WHOIS record for RIPE-NCC-RPSL-MNT > telling people NOT to use that. And it appears that that comment, > and indeed the entire record for RIPE-NCC-RPSL-MNT were last > modified way back in 2006. So would I be correct if I said that > people were told, very explicitly, not to use RIPE-NCC-RPSL-MNT > anymore, starting from around the 2004-2006 time frame? And if > everbody was told that, explicitly, for the last 10+ years, then > why were people still using that handle as the mnt-by on their > newly created route objects... and why were they even -allowed- > to continue using that... right up until as recently as 2016-03-12? The comment says "Do NOT use this maintainer as 'mnt-by'". It was never intended to be used in that way but many people did as a convenience. Early this year users were prevented from using this MNTNER in the "mnt-by:" attributes of other objects and any objects that still referenced it were locked. The comment also says descr: This maintainer may be used to create objects to represent descr: routing policy in the RIPE Database for number resources not descr: allocated or assigned from the RIPE NCC. This still IS the intended use of this MNTNER object. > > I mean I understand that often times, not everybody "gets the memo" > telling them "Don't do that anymore. Do this new thing instead." > So, people being people, if you allow them to keep on doing the old > thing, some of them inevitably will. The real mystery is why > RIPE NCC effectively depreciated the use of RIPE-NCC-RPSL-MNT more > than ten years ago, but then continued to allow people to use it > anyway, apparently until just earlier this year. > > I understand the concept of a "grace period" and of a "transition > period", but TEN YEARS?? Wasn't that a bit, um, excessive? > > In short, I'm not sure I understand why -new- uses of RIPE-NCC-RPSL-MNT > were not simply made impossible on the day in 2004 when it was finally > resolved that RIPE-NCC-RPSL-MNT should indeed be retired, going forward. > > But I guess that's all water under the bridge now. I'm just saying > that it doesn't make a lot of sense to me. But then I wasn't there > at the time, so maybe in some obscure way it seemed to make sense at > the time... and for 10+ year therafter, apparently. > > Anyway, my real concern, which you didn't address, is still this one: > >>> ME: You should not be allowing your peer/customer to announce >>> route A.B.C.D/nn. >>> >>> HIM: We filter by using the RIPE route registry. There is a route >>> object in the RIPE data base that says that our peer/customer >>> can announce A.B.C.D/nn. >>> >>> I am concerned that in some cases the RIPE data base contains some route >>> objects that should not have been allowed in there in the first place, >>> and that to make matters worse, some of these now have mnt-by set to >>> RIPE-NCC-LOCKED-MNT which has _two_ possible ill effects, i.e. (1) it >>> hides the identity of the party who put the route object into the data >>> base in the first place and (2) it in effect freezes in place some >>> improper route objects that should never have gotten into the data base >>> in the first place. And in some cases, for some of the providers who >>> may be checking the routes that they either originate or pass against >>> the RIPE data base, this may have the effect of permanently legitimizing >>> bogus and perhaps even illicit routes. >>> >>> I would like to know if anyone other than me thinks this might be an >>> issue. I mean how will the bogus route objects ever be removed if they >>> are set to RIPE-NCC-LOCKED-MNT? > Am I correct that at the current point in time, nobody actually even > knows for sure who actually put the former RIPE-NCC-RPSL-MNT and now > RIPE-NCC-LOCKED-MNT route objects into the data base and that thus, > nobody even knows for sure who to ask whether or not those are even > still needed or whether any of them are of any onoing usefulness? See my previous response. > > I don't imagine that at this point in time anyone has the stomach for > simply purging all of the RIPE-NCC-LOCKED-MNT routes out of the data base > (because there would probably be blood in the streets if that happened) Many of these objects are there for a valid reason. cheers denis > but I again, looking back with 20/20 hindsight, it would appear that > the task could have been made a lot less onerous all around if direct > use of either RIPE-NCC-RPSL-MNT and/or RIPE-NCC-LOCKED-MNT by anyone > other than NCC staff had simply been disallowed starting back 12 years > ago. > > (Oh! And while I'm at it, I'd also like to suggest that aluminum-powder > based paint should not be used to coat the outside of the Hindenburg > zeppelin, and that the Titanic be outfitted with a bigger rudder.) > > > Regards, > rfg > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.ripe.net/ripe/mail/archives/db-wg/attachments/20161121/677f3525/attachment.html>
- 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 ]