mnt-lower attribute not allowed?
Dear colleagues, yesterday I tried to apply the hierarchical authorisation scheme on route objects. However, I did not succeed. As an example, have a look at this: route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT mnt-lower: DFN-MNT changed: poldi@dfn.de 950907 changed: noc@noc.dfn.de 961001 source: RIPE password: ... resulted in: Update FAILED: [route] 193.174.0.0/15 route: 193.174.0.0/15 descr: DFN-AGG-1 origin: AS1275 mnt-by: DFN-MNT changed: poldi@dfn.de 950907 changed: noc@noc.dfn.de 961001 source: RIPE *ERROR*: attribute "mnt-lower" unknown in route object Is this just an error in typing (I took the same spelling as given in the RIPE database 2.0 workshop), or is hierarchical authorisation not done for route objects (in the workshop there was only an example for inetnum objects), or is it just not implemented yet? If it was implemented only for inetnum objects I do not see any reason why it should not be also possible for route objects. Could anybody please give a hint? Regards Joachim _____________________________________________________________________________ DFN Network Operation Center, Dr. Joachim Schmitz, (finger help@noc.dfn.de) >>>>>> mailto: noc@noc.dfn.de <<<<<< Rechenzentrum Universitaet Stuttgart, Allmandring 30, D-70550 Stuttgart Phone: 0711-685-5810, 0711-685-5576, FAX +711 6788363 (business hours) EMERGENCY phone +711 1319 139 with answering machine and pager _____________________________________________________________________________
Hi Joachim,
Joachim Schmitz writes :
yesterday I tried to apply the hierarchical authorisation scheme on route objects. However, I did not succeed. As an example, have a look at this:
This was indeed not implemented as Ambrose pointed out earlier. The reason was not technical (you will even find the hooks already in the current code). No agreement was reached on the definition for the hierarchy of route objects at the Berlin RIPE meeting. Several opinions existed and there was not enough time left to discuss the topic until agreement was reached.
From what I recall:
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 ... David K. ---
==> From: davidk@isi.edu ==> Thu, 3 Oct 1996 18:02:34 -0700 (PDT)
From what I recall:
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.. 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? Cheers, Steven
Steven Bakker <Steven.Bakker@dante.org.uk> writes: 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.. 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?
Not ludicrous but not obviously a widely accepted soloution either: It mixes allocation and routing registry which is maybe muddling things too much for us and certainly not implementable for routing-only registries. I would expect concerns from ISPs if customers have to change data in order for routing to be registrered. The expectation is that ISPs are more versed in registration issues. I believe that the originating AS should be in control of routes registered as originating from it. After all they control what they originate in reality. I therefore propose a simple two-tier hierarchy with the aut-num object controlling authorisation for creating route objects with an origin: attribute value equal to the AS irrespective of the prefixes. Note that may still be possible to create a route object in one RR that is protected by hierarchical authorisation in another. This fact is more relevant than with allocation registry authorisation since current practise for routing registry tools is to use the superset of all RRs (the IRR) in some way or other. Cheers Daniel
participants (4)
-
Daniel Karrenberg -
davidk＠isi.edu -
Schmitz＠rus.uni-stuttgart.de -
Steven Bakker