Subject: Re: [NRO comment on ULA 3] Needed changes

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Jul 2004 17:25:51 +0200

Dan Lanciani wrote:
> |        It may be that this issue of assignments performed in perpetuity
> |        vs fixed period renewable assignments should be a matter of
> |        choice by the client as the time of assignment, and that charge
> |        applicable to this service reflect the different cost structure
> |        of secure maintenance of assignment records for a fixed period vs
> |        costs for this record maintenance to be undertaken in perpetuity.
> 
> This would appear to be a serious change in the nature of the addresses
> contemplated by the draft.  I think we need to discuss how to implement
> the addresses as specified, not how to make them more like existing rental
> space.  I also suggest that these types of concerns (which are inevitable
> if the existing RIRs handle the allocations) are a strong reason to consider
> using a separate allocation authority.

We should hold the line on perpetuity. These things are cheap and plentiful,
so I just don't see any of the arguments against perpetuity as valid.

    Brian

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

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Jul 2004 13:23:52 -0400

> |and the principle that the charges of 
> |registration under any given registration model should reflect the costs 
> |associated with the operation of the service,

> One of the big benefits of the permanently allocated addresses being
> discussed is that the costs of maintaining their database can be
> made extremely small.  The registration charge (if any) should
> reflect that low cost of operation.

One thing that needs to be considered (by the entity providing this
service) is how it can recover costs on an on-going basis over the
long term (say, 15 years from now). If there are a lot of
registrations up front (first 5 years) and then they slowly drop off
to a trickle, who is going to pay for the recurring costs in the years
that follow?  They may be relatively small, but they are not 0. What I
think the RIRs are saying is that they can't provide this service by
having its costs subsidized by some other RIR income not related to
these addresses (its membership would rightly object). Indeed, the
number of organizations willing to take on such a burden is probably
somewhat limited.

So, while the registration fee should be as low as reasonable, it also
needs to be realistic, in the sense that the long-term funding model
for the service needs to be stable.

Looked at in this light, a recurring cost model may not be so
horrible. The key is minimizing the cost/hassle of renewals. And even
the costs/terms could be adjusted over time (e.g., downward) as it
becomes more clear just what the actual costs of the service are and
(more importantly) just how many subscribers there are. It's hard to
say at this point whether there will be 10K such assignments or 1M or
more. It may turn out to be much lower than we think, if the randomly
generated approach is viewed as adequate in practice.

(Note: I'm not necessarily advocating that a leased model is an
appropriate one, but feel obligated to point out that the business
model for providing the service where there is a single one-time fee
does raises considerations about long-term stability of income
source.)

Thomas

---

From: Dan Lanciani <[email-masked]>
Date: Fri, 2 Jul 2004 16:28:53 -0400 (EDT)

Thomas Narten <[email-masked]> wrote:

|> |and the principle that the charges of 
|> |registration under any given registration model should reflect the costs 
|> |associated with the operation of the service,
|
|> One of the big benefits of the permanently allocated addresses being
|> discussed is that the costs of maintaining their database can be
|> made extremely small.  The registration charge (if any) should
|> reflect that low cost of operation.
|
|One thing that needs to be considered (by the entity providing this
|service) is how it can recover costs on an on-going basis over the
|long term (say, 15 years from now). If there are a lot of
|registrations up front (first 5 years) and then they slowly drop off
|to a trickle, who is going to pay for the recurring costs in the years
|that follow?

This question (which has been raised before) seems to be based on the
assumption that current revenue has to be spent or distributed rather
than invested to pay for future costs.

|They may be relatively small, but they are not 0.

Perhaps we should try to quantify them a little better.  My feeling is that
they can be so low that the interest on the money garnered from a reasonable
number of initial registrations will handle the costs indefinitely.  Further
revenue would be gravy.  (I know this begs the question of what is reasonable.)

|What I
|think the RIRs are saying is that they can't provide this service by
|having its costs subsidized by some other RIR income not related to
|these addresses (its membership would rightly object).

The difficulty of distinguishing between this position and the similar
position that all allocations must be as profitable (in a "non-profit"
sense) as current allocations is, IMHO, a reason for concern.

|Indeed, the
|number of organizations willing to take on such a burden is probably
|somewhat limited.

Of course, if the job is offered only to the RIRs we will never know this
for sure...

|So, while the registration fee should be as low as reasonable, it also
|needs to be realistic, in the sense that the long-term funding model
|for the service needs to be stable.
|
|Looked at in this light, a recurring cost model may not be so
|horrible.

The problem is that the administrative overhead for recurring billing (and
the associated record keeping) is going to swamp the actual cost of maintaining
a record no matter how much you streamline the former.  The RIRs already have
a pretty good idea of this overhead based on their current models.  Isn't
it inevitable that if they handle these new allocations in a similar way they
will arrive at a similar cost/price?  To do otherwise would be to admit that
the existing charges aren't really based on cost recovery.

				Dan Lanciani
				ddl@danlan.*com

---

From: Derek Fawcus <[email-masked]>
Date: Sun, 4 Jul 2004 22:45:29 +0100

On Wed, Jun 30, 2004 at 11:28:39PM -0400, Dan Lanciani wrote:
> 
> That's why it would be best to distribute the data to the prefix holders in
> the form of some sort of signed certificates.  The registar need only maintain
> a fixed-size bitmap of allocated/available prefixes.

Quite.

Actually if we could get 32 volunteers (hmm),  then this could be reasonably
implemented in a distributed fashion.  That's 'cause the numbers work out well;
2^40 is a bitmap of ~ 128G,  given DVD-R's hold about 4G, that would be 32 DVDs.

How about this...

So say the customer runs the allocation algorithm and generates a 40 bit number,
generates a certificate signed with a key they hold,  and send that together with
the public key to the appropriate registrar.

The registrar sends back an ack/nak for if the number is allocated.  The customer
retries until he finds an unallocated number.  A registrar on indicating a number
is unallocated will mark it as 'busy' till the rest of the transaction completes
or times out.

The customer then pays the registrar,  and (eventually) receives back a copy of their
certificate signed by a key the registrar holds.  The registrars associated public
key is well known,  so anyone can verify the certificate.

The registrar then records that the number is allocated.

If the customer can't run the above algorithm,  then a registrar can simply be
arbitrarily picked to do it all for him - but probably at more cost.

I suspect that other than initial costs (software,  hardware) the major part of
the running cost will be in getting the payment from the customer - but I guess
people could utilise some online system ala paypal (or whatever).

So a simple matter of programming.   Do you think we can find 32 volunteers?

DF