A couple of quick comments <disclaimer> I didn't read through all the reasoning in detail yet, due to lack of time </disclaimer> Daniel Roesen wrote:
On Wed, Apr 05, 2006 at 12:32:58PM +0200, Gert Doering wrote:
From my gut feeling, I'd say that for route object creation, it should be sufficient if you have authenticated against the maintainer of the inetnum (mnt-by/mnt-routes) and against the maintainer of the new AS.
I support this proposal.
I'm sure I'm overlooking something, which would explain why it is the way it is...?
One of the basic intentions was to have (a set of tools that allows to maintain) a routing registry that matches "reality" as close as possible. Looking at the situation from a routing perspective, you need cooperation form both the old and the new ISP in real life. Asking a 3rd party to remove a route object from the DB does not necessarily mean that the "old" announcement is going to disappear. The old ISP may still advertise the prefix! Of course some ISPs may filter according to the RR (and maybe ignore the "old" stuff, but others might not. What I do not undertstand fully right now is the potential impact on the operation of configuration tools if they start to see more than 1 origin entry for a particular prefix from diferent ASes. I also have to still think through the security aspect of _indiscriminately_ allowing the creation or deletion of DB objects without consent/cooperation of the parties involved. I presume the NCC does some sanity checking before honouring "manual" requests?
Good question, I'm also trying to come up with a good reason... and I guess the one who designed this auth scheme had something in mind...
While I do not at all object to revisit this problem (may I suggest to take it through Routing and/or Address-Policy firts?) my _feeling_ is that we won't see a much better machinery by bending the DB code left and right, but rather by trying to make progress in developing and properly deploying (some sort of) Routing Layer Security? Some of the prerequisites are already being developed.
Best regards, Daniel
Wilfried.