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/ncc-services-wg@ripe.net/
[ncc-services-wg] IP geolocation services
- Previous message (by thread): [ncc-services-wg] IP geolocation services
- Next message (by thread): [ncc-services-wg] IP geolocation services
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marco Hogewoning
marcoh at marcoh.net
Wed Oct 28 09:29:30 CET 2009
On Oct 27, 2009, at 5:36 PM, Peter Koch wrote: > Wilfried, > >> particular end-system using a particualr address, at a particular >> point in >> time, from a block registered in a particular RIR's DB as an >> assignment is >> very bad idea to begin with. >> >> At least for the RIPE-DB, there are no agreed or definend semantics >> for >> the interpretation of the country: attribute. The data is a hint, >> at best. > > agreed, but the problem in question is not necessarily related to the > RIPE DB being used as source of the geolocation information. What > seems > to be desirable is some notification of changes when a certain address > block is unassigned or, more importantly, reassigned. This doesn't > have to provide the new location information, but should initiate a > new > run of the location magic for this address range, so the GeoLoc > provider > knows when to update/refresh which information. > > Of course, we know similar demands from the domain business and these > requests aren't all free of concern, but the situation might be > different > here in the addressing world. Address blocks are quarantined for a while when they are returned, so I guess that anybody who regularly checks the database should notice they went missing and this could be a nice hint that those addresses aren't in use anymore and any data associated with it should be removed. Or are you proposing more of a push system in which the RIR tries to find and notify those people who collect these data to notify them there have been changes. A third solution would be to publish a sort of BOGON list which contains all unallocated blocks in s machine parseable format, this might even be usefull for other purposes as well, but I can aleady think of two problems: First of all there is a risk that people built filters based on this list and those might not get updated again, so we try and debogonize space forever instead just once when the /8 comes down from IANA, secondly if people are starting to use this list as a way to generate filters we again create some form of 'off button' for the internet and that might give people the wrng idea that the NCC in fact can do something about abuse or other "illegal" activities (I use quotes here because it's hard to define the term in an international situation, what may be illegal in your eyes migth be perfectly legal in other parts of the world). I can think of option 1 happening, in fact that mechanism is there, option 2 (push) is almost impossible to achieve and I don't like option 3 at all. Grtx, Marco
- Previous message (by thread): [ncc-services-wg] IP geolocation services
- Next message (by thread): [ncc-services-wg] IP geolocation services
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]