[ppml] In$entive$

[heh heh]

Actually they can and do. Try getting an allocation (non legacy) updated or
transfered without making the payments. The contract that a company signs
spells it out that you may not sell the addresses. This is the place where
addresses could be reclaimed and current usage is audited. This is were the
policing can/should be done. Policing maybe to strong of a word, open to
suggestions. This then opens up to litigation.

Aaron

On 3/22/07, Owen DeLong <owen at delong.com> wrote:
>
> The RIRs cannot, do not, and will not police it.  There is no police
> function
> here, at least not at the RIR level or the address assignment/
> registration
> level.
>
> The RIRs provide a very specific service. They guarantee that whatever
> numbers they issue to you will not be issued to anyone else by them or
> by any other RIR.  They don't guarantee anyone will route those numbers
> for you.  They don't guarantee you that no one else will use those
> numbers
> in their router.  They don't promise you that there is no competing
> parallel address registry.
>
> For the RIRs, there's nothing to police other than their own
> allocation/assignment practices.
>
> Now, if you want to talk about how those numbers are used, that's
> a different story, and, the RIRs are actually not involved.  That falls
> to the ISPs and other peers a given entity may wish to exchange routes
> with.
>
> Until now, the generally connected internets (the semi-contiguous
> collection of networks speaking IPv4 protocol which, generally provide
> for the ability of a packet to get from nearly any point A to nearly any
> point B within the collection (firewalls, policy, etc. notwithstanding))
> have functioned because there is general agreement that addresses
> delegated by RIRs (or applicable subordinate delegation) are
> legitimate whereas numbers presented by an organization which
> cannot trace their delegation back to an RIR are considered not
> legitimate.  It is my sincere hope that this model will continue to
> function for the foreseeable future.
>
> If a day comes when a significant portion of the generally connected
> internets choose not to follow this policy, then the face of IP
> addressing
> will change dramatically and in an manner I cannot predict. I do not
> believe it would be a beneficial change.
>
> I guess the key point I'm trying to make here is that there is no
> tangible
> asset or value in a number.  The value comes in the willingness of
> others to consider that number uniquely delegated to a given
> organization.  It's very hard for me to imagine a way in which you
> can barter/trade/sell other people's willingness to do so, absent some
> form of generally agreed upon marketplace for the trade of such
> willingness.
>
> Since there is significant opposition to the idea of an address
> commodity market by a substantial portion of the people actually
> in charge of the routers that would be affected by such an idea,
> I don't think that the scenarios of black-market address trading
> are likely to actually prove useful in significant measure.
>
> I'm not saying it doesn't happen now or won't happen in the
> future, just that it is hard for me to picture a world in which such
> a market controls a significant portion of the address space
> in the absence of a major attitude/policy shift in the network
> operations community.
>
> As such, I don't believe that IPv4 free-space exhaustion requires
> any substantive change in RIR policy or conduct.  I don't believe
> that RIRs should start trying to extract addresses from address
> holders by force.  I certainly don't believe that arbitrarily pricing
> address registrations in such a way to force smaller players
> out of the market in favor of larger ones is a good idea. Finally,
> I don't believe that an address market will succeed, nor do I
> believe that if such a thing were adopted that it would be a
> good thing for the stability of the internet.
>
> Owen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070322/4ccc2f15/attachment.htm>