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/address-policy-wg@ripe.net/
[address-policy-wg] Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
- Previous message (by thread): [address-policy-wg] Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
- Next message (by thread): [address-policy-wg] Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Florian Weimer
fw at deneb.enyo.de
Sat Jul 12 10:29:28 CEST 2008
* Shane Kerr: > I also don't speak for any member, but I think revoking assignments is > a fantastic idea. > > In fact, I don't see how it makes sense to do otherwise. I think it depends on the question whether address space is a scarce resource. Current RIPE policies do not actually treat it as such. And if IPv6 is inevitable, it's not really cost-effective to scrape together legacy resources. You burn through RIPE funds to gain perhaps a year or two during which you can carry on with the legacy assignment processes. But nobody knows how many disputes will occur--it could happen that RIPE NCC believes that it's still got legacy resources distribute, but know wants to touch them with a three-meter pole. > Someone claims to be the authorized user of some addresses. *Nobody* > has any relationship wth this person. The only evidence you have is > that at one time in the past someone was assigned the addresses. If there's no other claim to those addresses, what harm is done? > Sure, I can call the people peering with the originator of the > advertisement, and see why they are carrying the traffic. They might > or might not be willing to give me that information, or privacy or > business reasons. Also, all because it is convenient for them to carry > the advertisements does not mean somebody else won't do the same > thing for the same space for a different originator. And finally, we > have a perfectly workable system so I don't *have* to go through this > kind of nonsense: the RIR system. The RIR system does not prevent address space hijacking. I don't think I can call RIPE NCC and demand that they stop it if it affects one of my prefixes. RIPE NCC hasn't got a routing police. > If people are unwilling to sign a contract which basically says, "I am > using this address space", then take their space back. It's not scary, > really. We don't know what will be in the contract. I can't envision how many PI-space owners would agree to things like this: | Notice that none of the provider independent resources may be | sub-assigned to a third party | Notice that the resource holder is obliged to pay an annual fee to the | LIR for the resources | A clear statement that the use of resources is subject to RIPE | policies as published on the RIPE web site and which may be amended | from time to time First point seems to imply that I can't run certain services (e.g. hosting) from PI space. Second point requires me to set up billing procedures which might not exist yet. Third point subjects me to the whim of the RIPE processes (which might implement yearly fees payable to RIPE in the future, for instance). I don't think it's a good idea to give resources to end users without any means of contacting them after the assignment. But I think the current proposal is not ready for implementation.
- Previous message (by thread): [address-policy-wg] Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
- Next message (by thread): [address-policy-wg] Revised 2007-01 moved back to Review Period (Direct Internet Resource Assignments to End Users from the RIPE NCC)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]