Dear Curtis, you wrote:
Here is an example. The registries approve of the top level blocks, that is the aggregates (or blocks that should be announced as aggregates). Whoever the aggregate is allocated to creates the top level route object and can delegate below that. For example, ANS has 207.24/14. There were two route objects needed to handle multihomed (a /22 and a /24) prefixes. The usual way a provider would delegate would be to reference more than one maintainer in the route object (the provider and the customer, and probably the other provider if the route object had a unique origin AS).
This scheme sounds reasonable but it raises the question of coordination among different registries...
I would not expect to see the same address space allocated by more than one registry. All registries would have a top level 0/0 route object which prevents registry of bogons. RIPE would have a hierarchy under 0/0 and the RA would have a hierarchy tracking InterNIC assigned addresses. I would not expect the two to overlap, therefore there is no real coordination problem beyond initial setup or new blocks allocated to a registry.
This is more difficult than it looks from the beginning. As an example we ourselves register all our objects (inetnum, routes, persons...) in RIPE database (because we are in Europe). However, among others we peer with MCI and MCI insists on having route objects in their registry in order to allow routing. If the route objects are secured by hierarchical authorisation in the RIPE database we would also like to have them secured in the MCI registry. Following the scheme above MCI would have to include inetnums (while it is a pure routing registry) *and* would have to generate top level route objects allowing specific access by us to our route objects (this is a very tiring job especially regarding "the swamp" 192.x). Of course, they could copy from RIPE database... (ask them why they don't...) I guess, this problem may only be resolved by the GRR (which is yet to come) From the ongoing disussion I conclude for myself (at the current state of the discussion) that we can not impose a strict security mechanism at the time being without breaking too many things. Maybe, I am too dumb to see a simple solution which might be just at hand... I will summarise the things said here on the mailing list for the routing wg session next week and try to think some more about it (I guess, Daniel was right from the start when he said that we should begin with a bare notification mechanism...) Regards Joachim _____________________________________________________________________________ Dr. Joachim Schmitz schmitz@noc.dfn.de DFN Network Operation Center Rechenzentrum der Universitaet Stuttgart ++ 711 685 5553 voice Allmandring 30 ++ 711 678 8363 FAX D-70550 Stuttgart FRG (Germany) _____________________________________________________________________________