Dear Curtis, dear David, you both wrote:
Your black hat example is also flawed. At the top of the heirachy can be 0/0 registered to IANA and withdrawn (not announced). The registries themselves can have top level objects below that. In order to make any changes, you need to have been given authorization from a higher level. You can then assign authorization to lower blocks to other parties.
This works for IP network objects since the registries need to add these objects manually anyway.
This is not that obvious for 'route' objects. Are you proposing that the registries have to approve (manually) all the route objects that are in the route hierarchy directly below their own allocated space ?
Tie the hierarchy to the inetnums. Continue to flog the InterNIC for non-participation in the IRR. The maintainer of a database such as the RADB that uses InterNIC as the number registry may have to take InterNIC data (ftp) and load it into inetnum records. I wonder about the effort necessary to do this. Moreover, we should not forget about pure routing registries - they would be forced to include inetnums as well (and I wonder whether they are willing to do so)
An inetnum references one or more maintainer (in mnt-by). To create a route object, you must satisfy one of the criteria:
1. You must be in the maintainer field in a less specific route object (used to create route objects for more specific prefixes; hopefully these get aggregated somewhere ).
2. You must be in a maintainer for the exact inet-num and for the AS that you are putting in the route object (used after the initial top level route object is created).
Once a top level route object is created, a more specific route object can be created and the mnt-by field can reference more than one maintainer.
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... 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) _____________________________________________________________________________