[ncc-services-wg] 2016-02 New Policy Proposal (Resource Authentication Key ( RAK ) code for third party authentication)

On 05/02/2016 09:30 AM, job at instituut.net (Job Snijders) wrote:
> Hi Gert,
>
> On Mon, May 02, 2016 at 02:31:46PM +0200, Gert Doering wrote:
>> On Mon, May 02, 2016 at 02:12:40PM +0200, Marco Schmidt wrote:
>>> You can find the full proposal at:
>>>
>>>       https://www.ripe.net/participate/policies/proposals/2016-02
>>>
>>> We encourage you to review this proposal and send your comments to
>>> <ncc-services-wg at ripe.net> before 31 May 2016.
>>
>> If yes, I don't think this is a good approach - because if the RADB
>> and other operators actually were *interested* in reducing the amount
>> of crap in their database, they could cross-check RIPE route:/route6:
>> objects already today, without any new API needed.
>>
>> Evidence shows that they are not interested, even when presented with
>> "hey, there is garbage in your database, look at the RIPE DB for the
>> correct route: object" nothing happens.
>
> It is my experience with both RADB and NTTCOM that when you email the
> database operator and present them with evidence, it gets cleaned up
> (might take up to three weeks). Admittedly I've not been succesful with
> all database operators out there.


   (Apologies for belated reply -- I'm on the Database WG list, but just
recently joined the NCC Services WG list)

   Just to follow up on Job's comment. We (Merit RADB) have been
working on training our 24x7 NOC team the last couple years to provide
RADB support and integration with their existing ticketing system and
believe ourselves to be responsive to requests for clean up's.  We've
also be more proactive on monitoring new account creation requests and
looking for certain suspicious indications.


>
>> Ceterum censeo: RADB must die, and as this proposal will not speed up
>> the process, so it's not helping.
>
> We can put the third-party databases to rest once we have 100% feature
> parity in their respective replacements, those successors need to be
> accessible both in terms of reading & writing to all relevant
> stakeholders.
>
>> (NTT, on the other side, is already cross-checking - so I'm not sure I
>> see the benefit for them.  But if Job convinces me that it makes life
>> easier for them, I stand corrected)
>
> Just like RADB, NTTCOM (the IRR Registry by NTT) is _not_ doing any
> cross-checking at this moment. It's unfortunate, but any NTTCOM mntner
> can create garbage objects. When NTT staff come across garbage (or are
> made aware), the garbage is mopped up.
>
> NTTCOM & RADB use the same IRRd software. Differences are the operating
> company & staff, original database content and mirror selection
> criteria. As third-party IRR database operator, I have a strong interest
> in anything that can help improve the quality of the data. I can't
> imagine it's any different for Merit.


   We certainly agree with this statement and have resources we can
allocate to making improvements.


>
> I think you are referring "irrlockdown" which is a slightly different
> approach on route-filter generation. IRRLockdown promotes the idea of
> outright ignoring route-objects which are covered by RIPE NCC managed IP
> space, from all IRR databases except RIPE itself. Today "irrlockdown"
> has not been deployed in NTT due to certain as of yet unresolved
> software & communication challenges.
>
> I guess irrlockdown and proposal 2016-02 aim for the same result, but
> come from very different directions. One approach hinges on "don't
> publish or consume unverifiable data" the other is I guess "make it
> possible to verify data prioir to publishing and consumption".
>
> As to the policy proposal itself: I would probably benefit from a
> (highlevel) diagram displaying which interactions on which pieces of the
> data happen where and how that results in something useful.


   I can see value in this proposal and would also welcome a highlevel
diagram with some additional details of interactions.



  Regards,
   Larry Blunk
   Merit Network