Alain Durand <[EMAIL PROTECTED]> wrote:
|I think people are confusing the notion of 'permanent' and 'stable'
|addresses.
On the contrary, I think that it has not yet been demonstrated that they
are different for practical purposes. An address that has been around for
100 years but which disappears 24 hours after you start using it is not
stable.
|The case made for those local addresses was to be independent from ISP,
|either to isolate from ISP changes or in the case of intermittent
|connection.
The case was made for addresses that are independent of address renting
entities that can (by error or intent) invalidate the addresses at any
time. It just happens that at the moment the ISPs are the primary source
of rented addresses for most end users.
|This require 'stable' addresses. i.e addresses that are stable for a
|long enough period of
|time, here define long enough by for the lifetime of your operations.
|This has nothing to do with 'permanent', which means until the end of
|the times.
In the past we were unable to come up with a value for ``long enough'' which
is in any meaningful way different from ``forever.''
|So, I argue that 'permanent' is not a technical requirement.
Are you are prepared to come up with a useful definition of ``long enough''
to replace ``permanent?'' Or do you just want to remove ``permanent'' from
the requirements with no replacement, IMHO destroying the value of these
addresses? If you do have a useful definition, why didn't you propose it
when this issue was being discussed?
|Now, if we have multiple registries, it is up to them to find a
|business model
|that makes sense for them. If it is easier/simpler to come with a one
|time fee
|model, fine. If they think they cannot recover the costs of operation
|like that,
|they may opt for a recurrent fee model.
And of course, the logical extension of this is to note that you can already
rent a block of addresses from an ISP so we really don't need these new
non-permanent addresses at all. We've been down this road before.
|This would not mean that the
|prefixes won't
|be stable, they would be as long as their owner keeps maintaining the
|subscription.
You are making the standard fallacious assumption that the allocation service/
ISP/whatever is infallible and philanthropic. What happens when the service
goes bankrupt? Don't imagine that the bankruptcy court is going to ignore that
subscription income and just let the customers keep their addresses. What
happens when the service gets greedy and (after enough people are dependent)
raises the rates? You think that can be avoided by contract? That brings us
back to the question of how long a contract is ''long enough?''
|So I argue that the choice of a one time fee vs recurrent fee is an
|operational/economical
|discussion that would be better kept out of this document.
I argue that allowing recurring fees destroys the value of these addresses.
|As a side note, there are several issues with the 'permanent
|allocation, one time fee' model:
|
|- This is really symptomatic of a consumer society where people do not
|think about waste management,
| where resources are perceived unlimited and it is free spending.
This whole endless addressing debate is symptomatic of a society that has
discovered a way to create ongoing revenue streams from abstract number
allocations by artificially limiting their availability--and is loathe to
give it up. The scarcity argument worked (with a lot of help from "reserved"
blocks) for IPv4. IPv6 was supposed to eliminate the address scarcity, but
outdated routing scaling arguments kept that vast new address space out of
the hands of end users, preserving the rental status quo. Now finally we
have an address format that effectively costs too little to measure and we
are falling back to ecological ``waste'' arguments to jack up its price.
This is really scraping the bottom of the barrel.
|- The business model is based on the assumption that the new comers
|will pay for the
| management of the database so the previous customer won't have to pay
|for it.
| I think this is completely broken, as it is fundamentally a pyramid
|scheme.
| Remember those chain letters asking you to send money to 10 people
|and forward it to 20 others?
Your analogy is so wrong that it is difficult to know where to begin to explain
its flaws. Consider that the per-victim promised outlay in a pyramid scheme
remains more-or-less constant as the number of victims grows without bounds.
The per-address cost of maintaining a database shrinks rapidly as the number
of addresses grows because it is the *total* cost that remains more-or-less
constant. For the database in question, the total cost is small enough in the
first place that the per-address cost is likely too small to measure accurately,
assuming any reasonable number of subscribers. (And if there are no subscribers
we really don't care about the whole thing.) In any case, the actual cost of
maintaining an individual address would be swamped by the costs of billing the
renter for that address.
But even the premise behind your analogy is wrong. A one-time payment does
not in any way imply that ``new comers'' are paying to support previous
customers. The future value of money is well understood. If the cost of
maintaining an address in the database can be expressed as a recurring fee
then it can also be expressed as a one-time fee. A recurring fee is just a
way to hide the true cost from the customer. It also decouples the fee
from the cost of maintaining the database (because the billing and other
administrative overhead will dominate the computation), allowing lots of
wiggle room for little extra expenses. And most people won't even do the
annuity calculation to determine their equivalent up-front cost.
|- It is unclear what happen when a company is acquired by another one
|or when
| the addresses are registered to a person and that person dies.
| Are those addresses considered as part of the assets of the
|company/person? Are they transferable?
The answers must be yes & yes if this proposal is to be useful.
|- It would be the first time that the IETF would sanctify the sale (and
|not the stewardship) of
| chunks of address space. This is a fundamental departure from what
|has been done
| in the past.
In the beginning, address assignments were in effect permanent. The whole
multi-level-marketing address rental system (which itself was a fundamental
departure from what had been done in the past) grew out of a supposed need to
conserve routing table space. The reason was later changed to a need to
conserve actual address space and recently has again become a routing argument
(this time computation). None of these excuses apply to the local address
format being discussed, and the argument that it is now tradition to deny end
users address space is not compelling.
Dan Lanciani
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
