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

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

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.

-- Christian Huitema

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

---

From: Alain Durand <[email-masked]>
Date: Fri, 06 Feb 2004 09:24:03 -0800

While doing those edits, why not also remove the dictate to give 
permanent allocations from this document?
After all, this is also an operational/business discussion, not a 
technical one.

	- Alain.

On Feb 5, 2004, at 10:07 PM, Christian Huitema wrote:

> rder to keep overhead low.
>
> By a more neutral:
>

---

From: Hans Kruse <[email-masked]>
Date: Fri, 06 Feb 2004 12:40:33 -0500

I disagree; the technical issue is stability.  We want these allocations to 
be permanent to make them attractive in a technical analysis -- this 
encourages their use in those cases where we believe they should be used 
(as opposed to having users preferentially use self-assigned prefixes which 
they perceive to be permanent).

--On Friday, February 06, 2004 09:24 -0800 Alain Durand 
<[email-masked]> wrote:

> permanent allocations from this document? After all, this is also an
> operational/business discussion, not a technical one.
>
> 	- Alain.
>
>

Hans Kruse, Associate Professor
J. Warren McClure School of Communication Systems Management
Adjunct Associate Professor of Electrical Engineering and Computer Science
Ohio University, Athens, OH, 45701
740-593-4891 voice, 740-593-4889 fax

---

From: Zefram <[email-masked]>
Date: Fri, 6 Feb 2004 20:05:17 +0000

>After all, this is also an operational/business discussion, not a 

It looks pretty technical to me.  Permanent versus temporary allocation
fundamentally affects the ways the prefix can be used.  This is quite
unlike the issue of the allocation procedure.

By the way, do you see any redeeming features in the idea of temporary
allocation of these prefixes?  I see only greater complexity and reduced
utility.

-zefram

---

From: Tim Chown <[email-masked]>
Date: Fri, 6 Feb 2004 21:19:20 +0000

> allocation of these prefixes?  I see only greater complexity and reduced

One snag is that if they are temporary, it will inevitably lead to "returns"
that don't happen, and the original and new "owners" both using the prefix,
which will cause confusion/ambiguity/lack of uniqueness, which is thus breaking
the original goal of the draft.   There's enough under the /7 to not need to 
have temporary allocations.

Tim

---

From: Alain Durand <[email-masked]>
Date: Fri, 06 Feb 2004 22:38:43 -0800

Trying to make a synthesized  answer...

I think people are confusing the notion of 'permanent' and 'stable' 
addresses.
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.
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.

So, I argue that 'permanent' is not a technical requirement.

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. This would not mean that the 
prefixes won't
be stable, they would be as long as their owner keeps maintaining the 
subscription.

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.

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.

- 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?

- 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?

- 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.

	- Alain.

---

From: Bill Manning <[email-masked]>
Date: Sat, 7 Feb 2004 05:45:40 -0800 (PST)

% One snag is that if they are temporary, it will inevitably lead to "returns"
% that don't happen, and the original and new "owners" both using the prefix,
% which will cause confusion/ambiguity/lack of uniqueness, which is thus breaking
% the original goal of the draft.   There's enough under the /7 to not need to 
% have temporary allocations.

	actaully, all delegations are temporary, unless we are creating
	property/ownership rights.

% Tim

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Alain Durand <[email-masked]>
Date: Mon, 09 Feb 2004 08:27:04 -0800

> 	property/ownership rights.

Bill,

This is exactly what the local addr draft is all about with the current 
text that makes
allocation permanent.

As a side note, the document talks about allocations, not delegations.

	- Alain.

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Feb 2004 17:20:33 +0000

> As a side note, the document talks about allocations, not delegations.

OK, but I think we can have some statement to say that there is a tradeoff
when you reuse previous temporary allocations because such reuse may lead
to ambiguity.   With 1,000 billion /48's available under a /8 you have a 
lot of capacity before you need to re-allocate.   You could say that "returns"
should not be reused until those 1,000 billion /48's have been allocated
from under the FC00::/8 prefix?  (Though that would be a kind of excuse for
sites to not pay recurrent registration fees :)

Tim