This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[db-wg] RE: Changing/Adding route objects
- Previous message (by thread): [db-wg] RE: Changing/Adding route objects
- Next message (by thread): [db-wg] [ncc-announce] Re: Network Maintenance - Tuesday, 5 June 2007
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Wilfried Woeber, UniVie/ACOnet
Woeber at CC.UniVie.ac.at
Tue Jun 5 08:59:58 CEST 2007
Michael Markstaller wrote: > Hi, > > getting back on this topic from quite a while ago, I just found it while having exactly this problem.. > > >>On Wed, Apr 05, 2006 at 08:28:29AM +0200, Ihler, Hermann wrote: >> >>>if OLD-ISP updates his objects as follows it also will >>>work: >> >>But that's winfried's point: the old ISP need to actively enable >>creation of the new route object. > > > And/or it needs, as in my case, being able to actually do this in time. My favorite answer for today, waiting since Friday, is "This is an automated system, I cannot do this. I can only delete the object" (Which means in my basic understanding of IRR, if I don't create the new one in time, I'll be filtered by anybody doing best practice and use IRR..) > > This makes me waiting this night for this magic change to happen sometime.. I somehow don't trust on what this change from an "automated system" being oparted by poeple that don't have the mntner theirselve (maybe for some good reason) will actually do.. > > So I'm with the inital suggestion: the mntner of the inetnum should be able to override/make changes to the route-object of his own network, regardless which mntner is sitting on it. > If there are good reasons against this, I'm happy to learn the these. well, there are a couple of reasons: - provisions in RPSS (iirc, have to double-check), but could be amended, minor - all sorts of unwanted ineraction (potential misuse) of this capability: accepting or de/configuring a route for a prefix requires the consent by both parties: . the holder of the address space (otherwise it becomes easy to DoS by blackholing a prefix) . the ISP to carry the packets (otherwise it becomes easy to obtain some connectivity or transit without the ISP knowing/consenting. In particular for those situations where filters are built automatically from the IRR > regards > > Michael Markstaller Btw, and somewhat OT, I ran into a similar problem myself, a short whie ago, with the robot for reverse DNS delegation. Initially, my reaction was exactly like yours. After having a night's worth of sleep I realized that allowing me to delete the delegation - and then registering a new one - was the appropriate way of doing it. But yes, there's the risk of the window where the old config may already be gone and the new one not yet in effect. Wilfried.
- Previous message (by thread): [db-wg] RE: Changing/Adding route objects
- Next message (by thread): [db-wg] [ncc-announce] Re: Network Maintenance - Tuesday, 5 June 2007
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]