Dear routing folks !
Just wanted to let you know that we've just started a discussion on how to
properly maintain route: objects on the DB-WG list.
You're more than welcome to join in on db-wg(a)ripe.net
(or we could move the discussion to the routing-wg list :-)!
Wilfried.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Subj: Re: mnt-lower attribute not allowed?
Hi Steven et.al. !
=>
=> The AS object that matches the origin AS of a route object could be the
=> parent object of the route object, but then people are still able to put
=> route objects in with another origin AS which might not be desired by the
=> owner of the non-portable CIDR address space. Furthermore, a second
=> hierarchy exists: the IP prefix tree.
=>
=> You might want to try to formulate a proposal that is not too
=> complicated and also addresses the concerns of most people ...
=
=How about making the inetnum object the parent of the route object?
=I think it would make sense to allow the "owner" of the inetnum to create
=the route objects..
I'm not convinced that this is the way to go.
For two major reasons:
- in many environments the routing is handled differently from the address
allocation. In particular, where filters or other things are
(semi-)automatically derived from objects in the DB, it's certainly not
feasable to have the customers ("owner" of the address space) change
things without coordination. If they do, it might not reflect reality at
all or it might interfere with local logistics. And there's the issue of
porting PA address space for a limited amount of time to a different ISP.
- I think we should come up with a concept that works as well outside
the RIPE-coordinated address space and the central registry concept.
I think we should
. come up with a solution that works for routing-registries that do not
include an address registry in the same DB,
. find a solution that works uniformly across all parts of the address
space (A, B, C-19[3-5], TWD, et.al.)
= You can also keep the owner in the "notify:" field of
=the route object, so once you delegate maintenance of the route object to
=someone else, you can still keep track of what's happening with it.
=
=Or does this sound ludicrous?
No, it made me think, thus it was a very useful approach :-)
I'd favour an approach that is (conceptually) similar to the handling of
domain objects - something like an upstream search based on the AS #.
Although I haven't a clear picture of how it could work in reality, because
the "tree" is certainly less well-defined than in the DNS namespace.
Another idea would be to have a registry-pointer in the inetnum objects
that identifies a articular regsitry object. This in turn could be used
to describe the desired maintainance. We might want to have that linkage
anyway?
I'm not sure whether that meets David's criteria of
"not too complicated and also addresses the concerns of most people" :-)
Cheers,
Wilfried.
--------------------------------------------------------------------------
Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at
Computer Center - ACOnet :
Vienna University : Tel: +43 1 4065822 355
Universitaetsstrasse 7 : Fax: +43 1 4065822 170
A-1010 Vienna, Austria, Europe : NIC: WW144
--------------------------------------------------------------------------
