Subject: RE: IPv6 WG Last Call:draft-ietf-ipv6-unique-local-addr-02.txt

From: "Christian Huitema" <[email-masked]>
Date: Mon, 2 Feb 2004 10:48:45 -0800

> Well, I just feel quite uncertain of the current model -- we're
> basically telling IANA to find someone to build a monopoly by selling
> IP addresses.  Not so different from what RIRs do, of course, but at
> least they pretend the addresses don't cost anything.  Here we WANT
> them to cost money.  Monopolies and money for (pretty much) nothing
> seems like a bad idea.

I am also not sure that the specification should mention monetary
exchanges. It should be sufficient to mention the operational goal, i.e.
make sure that addresses are not hoarded and/or wasted.

> The only thing that seems to cost a significant amount of money in the
> proposal is to have a possibility to get the addresses over phone,
> fax, or whatever -- so that they cannot be processed automatically.

If the goal is just to prevent hoarding, then there are several
alternatives to monetary exchanges. The registry could implement a
"human test" to check that the numbers are actually requested by a human
being rather than a machine. The registry could also require solving a
computer puzzle of some kind, to attach a computing cost to the request.

-- Christian Huitema

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 5 Feb 2004 22:11:14 -0800

> Is it only I that find it odd that talking about Multicast DNS
> is viewed to be in-scope for this document, while talking about the
> applicability issues for the addresses *defined by this document*
> is stated to be out of scope??

I agree with Erik on this point.

> > >    For future study names with Local IPv6 addresses may be
resolved
> > >    inside of the site using dynamic naming systems such as
Multicast
> > >    DNS.
> > >
> > >==> this seems irrelevant and should be removed; above, it already
> > >states someting general about local naming systems.
> >
> > I don't see it doing any harm either.

When in doubt, leave it out. It does not bring anything to the document,
and any non-trivial assertion about operation of the DNS ends up
creating controversies.

-- Christian Huitema

---

From: Bob Hinden <[email-masked]>
Date: Fri, 06 Feb 2004 02:05:58 -0800

Christian,

>and any non-trivial assertion about operation of the DNS ends up

Agreed.  I will remove it.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Fri, 06 Feb 2004 02:09:56 -0800

Christian,

At 10:07 PM 2/5/2004, Christian Huitema wrote:
> From what I have read so far, the monetary payment appears to be one of
>the weakest point of the proposal. I suggest that the monetary
>consideration in the draft be removed, and that the precise method used
>to implement the registration be left to the registry. Specifically, I
>suggest in section "
>3.2.1 Centrally Assigned Global IDs" to replace the phrase:
>
>       - One time non-refundable allocation fee per allocation that is
>         affordable by a broad spectrum of end users when considered
>         globally.
>
>By:
>
>       - Allocation on a permanent basis, without any need for renewal
>and
>         without any procedure for de-allocation.
>
>I would also delete the phrase: "They should also accept a variety of
>payment methods and currencies."
>
>Then, I would replace the paragraph:
>
>    The reason for the use of an allocation fee for each prefix is to
>    allow this service function to operate on a cost recovery basis. An
>    acknowledged side-effect of such a mechanism is that it provides some
>    impediment to any hoarding of the these allocations.  The
>    consideration of affordability is intended to keep the cost low
>    enough so as not create a barrier to anyone needing one.  The charge
>    is one time to eliminate the need for an ongoing relationship with
>    the allocation authority, while acknowledging the service costs for
>    both the registration function and the enduring escrow service.  The
>    charge is non-refundable in order to keep overhead low.
>
>By a more neutral:
>
>    The allocation service should include sufficient provisions to avoid
>    hoarding of numbers. This can be accomplished by various ways, e.g.,
>    requiring an exchange of documents, a verbal contact, or a proof that
>
>    the request is on behalf of a human rather than a machine. The
>service
>    may charge a small fee in order to cover its costs, but the fee
>should
>    be low enough to not create a barrier to anyone needing one. The
>precise
>    mechanisms should be decided by the registration authority.
>
>Doing these edits will clearly express our intent, without dictating how
>the registration service chooses to operate. For all we know, we may
>find a volunteer who runs the service for free.

I agree it will remove a sticking point from the document while still 
expressing our intent.  Unless someone objects, I will make this change.

Bob

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 10 Feb 2004 15:17:05 -0500 (EST)

Alain Durand <[email-masked]> wrote:

|On Feb 8, 2004, at 3:02 PM, Dan Lanciani wrote:
|>
|> In the past we were unable to come up with a value for ``long enough'' 
|> which
|> is in any meaningful way different from ``forever.''
|
|There is a simple business model to solve this problem:
|long enough == as long as you pay for it.

There is a much simpler model that does not create an artificial profit stream:
long enough = forever.

|This is the same as any other utility. You get gaz, water & electricity
|as long as you pay for it.

And if the address allocation entity were to send me fresh new addresses to
add to my collection each month I might want to pay them on that basis.  But
they aren't sending me anything.  You are trying desperately to create an
ongoing revenue stream out of the ether.  Certainly this has been done before,
but at least there were technical excuses to make it seem more legitimate.
This time it's purely economic.

|> 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?''
|
|This is the exact reason why we should not create a monopoly but foster 
|healthy
|competition.

Previously you argued that a registry might need recurring fees in order to
recover its costs of operation.  Now you are talking about competition.
Cost-recovery operation and competition are not particularly compatible.
Competition typically requires profit since there is little incentive in
competing if you don't get anything by being better.  I'll assume that when
you said, ``recover the costs of operation'' you really meant to say, ``make
a profit''.

Now, let's assume that we have created this environment of healthy competition
that you espouse.  Who gets to decide who is allowed to compete by being a
registry?  It can't be a free-for-all because then anyone could bypass the fees
of existing registries by declaring herself a registry and allocating addresses
for free.  I'll bet your answer is that the registries should themselves pay
recurring fees to a higher authority for the privilege of being in this
profitable business that we have created.  That also conveniently locks out
anyone who might want to offer addresses for a small one-time fee (or perhaps
for no fee at all) and maintains the MLM status quo.

|If you're not happy with network solution for your DNS name
|danlan.com, you can switch to another one. We can have the same model 
|here.

And how exactly do you know to switch right before the bankruptcy?  What's the
cost of your time tracking such events?  For DNS names there is a technical
excuse for ongoing maintenance because the owner has to interact with the
registry and the registry has to interact with the root name servers.  (These
interactions--"updates"--were exactly what the initial domain name fees were
alleged to cover.  That was before folks had been acclimated to the idea that
there should be recurring fees for all manner of things and that they were not
owners but renters.)  Those excuses do not apply in the case of the addresses
under discussion.  Your analogy, while not quite as bad as your previous
comparison to a pyramid scheme, is still flawed.

|>  In any case, the actual cost of
|> maintaining an individual address would be swamped by the costs of 
|> billing the
|> renter for that address.
|
|Billing & recurrent fees is a way to guaranty that the database will be 
|maintainable.

Nonsense.  Recurring fees are a way to guarantee that someone can make (more)
money.  They guarantee nothing about the database.  The maintainers can
squander the recurring fees just as well as they can squander the one-time fee.

The way to guarantee the maintainability of the database is to make it largely
independent of the allocator.  Allocations could be self-proving and held by
the owners.  This could be achieved with public key crypto, for example.

|With permanent allocation, the day you get close to exhausting the pool
|of new subscribers, the rate of new subscription may not be enough to 
|recover the
|cost of maintaining the database.

This is just your broken pyramid scheme analogy again, based on the assumption
that only ongoing user fees can pay for ongoing costs.  Did it ever occur to
you that the allocator could invest most of the one-time fee and use the return
on that investment to pay ongoing costs?  Now, you may say, with the example of
Enron and friends we can assume that they won't do that but will instead take
the fee out in executive compensation and such.  This may well be true, but the
solution is not to throw even more money (in the form of recurring fees) at
them.  If they appropriate the one-time fee they will appropriate the recurring
fees as well.  All the recurring fee model does is give them the opportunity
to go back to the well over and over again, increasing fees as they squander
more and more money.

|> 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.
|
|I'm not sure the future value of money is that well understood for 
|infinite length of time...
|Actually, I'm sure of the opposite.

A little while ago you seemed sure that the one-time fee model was equivalent
to a chain letter scheme even though the math is totally different.  Your
economic analysis is, at best, questionable.

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 10 Feb 2004 15:29:58 -0500 (EST)

Zefram <[email-masked]> wrote:

|The allocation bitmap would be 128GiB.  That fits onto one current
|commodity hard disk.  Are we really quibbling over who's going to have
|to pay for eternal reliable storage of such a trifling dataset?

Not really.  It's just folks grasping at straws in a desperate effort to
turn something simple into something complicated and expensive.  It will
be interesting to see if they are allowed to succeed.

|When this issue was raised on one of the previous occasions, some months
|ago, I considered setting up a proof-of-concept automated registry
|for 36-bit random numbers (thus scaled down by a mere factor of 16)
|on my home equipment.  Regrettably I never got round to doing that, but
|it seems it might still be of use.  Operating such a thing might also
|have useful lessons for the operation of the eventual prefix registry.
|Thoughts, anyone?

As I recall, at one point someone set up a proof-of-concept auto-allocator
just to show how easy it was to hand out prefixes.  It was shut down very
quickly. :(  I'd like to know who ``requested'' this...

				Dan Lanciani
				ddl@danlan.*com

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 10 Feb 2004 19:23:32 -0500 (EST)

|Dan Lanciani wrote:
|>As I recall, at one point someone set up a proof-of-concept auto-allocator
|>just to show how easy it was to hand out prefixes.  It was shut down very
|>quickly. :(  I'd like to know who ``requested'' this...
|
|As I recall, it was claiming to actually allocate prefixes.

Interesting.  That was not the impression I got when I tested it, but obviously
I knew in advance what to expect.

|I don't
|intend to make any such unfounded claim.

I'm sure you will get all the disclaimers just right so there will be no
possible reason to object to the demonstration.

				Dan Lanciani
				ddl@danlan.*com