[db-wg] Puzzled by RIPE-NCC-LOCKED-MNT

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: </ripe/mail/archives/db-wg/attachments/20161121/677f3525/attachment.html>