[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NRO comment on ULA 3] Needed changes

Geoff Huston <gih@telstra.net> wrote:

|At 06:21 AM 1/07/2004, 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.
|In reading this comment its not easy to understand what argument is being 
|raised here in support of the assertion that  this represents a serious 
|change in the nature of the addresses contemplated,

Permanent allocation with its associated simplifications (e.g., no need for
central owner registry or deallocation/revocation procedures) is a seminal
characteristic of the class of addresses being created.  It is also the
main characteristic that distinguishes these addresses from all the other
ranges currently available.  Could you please explain how you can consider
making even some of the allocations temporary (and thus effectively burdening
the entire range with the associated administrative overhead) anything other
than a serious change?

|and that, by 
|implication, an in perpetuity registration service should be the only 
|available mode of registration?

I thought that it would go without saying that temporary registration is
not an appropriate model for registering permanent objects.

|It is evident that this comment is 
|voicing  opposition to the concept of a choice of assignment models,

Not at all.  The purpose of these new addresses is to provide a choice.
Currently there is no choice.  All address assignments are temporary.
The new range of addresses adds the new choice of permanent assignment.

|concept that a 'in perpetuity' registration be one of a number of 
|alternative registration models,

The "in perpetuity" registration model is exactly the alternative that will
be added by the draft.  It will be one of a number of registration models.

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

|but there is no explanation 
|in the note of the reasoning behind suchviews.

Perhaps because I do not hold the views that you find so "evident."

|A discussion on this topic 
|is no doubt the reason why the NRO note was passed to the working group, 
|and this is as good a starting point as any, but I hold the personal view 
|that the discussion needs a more substantive foundation that trading 
|unfounded assertions about the attributes of allocation entities.

That the allocation entities are raising these types of concerns is prima
facie evidence that the allocation entities are raising these types of
concerns, and thus the assertion is not unfounded.  That this was inevitable
is, of course, a matter of opinion.  It is also largely irrelevant since the
concerns have already been raised.  Whether you consider these concerns a
problem is again a matter of opinion, but it isn't an attribute of the
allocation entities.

				Dan Lanciani

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6