[ppml] Policy Proposal: IPv6 Assignment Guidelines - version 3

[Brian Dickson]

Leo Bicknell wrote:
> In a message written on Fri, Aug 24, 2007 at 04:35:34PM +0100, michael.dillon at bt.com wrote:
>   
>> How about allowing any LIR to receive a second allocation under the
>> "first allocation" rules if they provide a signed statement that the
>> earlier allocation was used only for testing and trial purposes and that
>> they will return the earlier allocation to ARIN within 6 months?
>>     
>
> http://www.arin.net/policy/irpep_template.html
>
> I support the concept; but I also believe it is orthogonal to this
> policy.
>   
I am afraid I have to categorically refute that statement.

Here are the two choices:
(1) adopt a policy that applies (retroactively) to all recipients of
IPv6 space, including already assigned space.
(2) adopt a policy that applies only to new assignments.

And having rules that say, our response to any new request (after the
adoption date of the policy) will differ depending on whether  you
already have some space assigned under a prior policy, means the rules
are of type (1).

Michaels suggestion/proposition basically modifies the original proposal
to make it (2). As it stands, it is (1). And (1) is not orthogonal, by
definition - it is embodied whole hog in the proposed policy.

I believe that the best result for the DFZ is achieved by (2), i.e. the
suggestion Michael made. I would be a bit more flexible, and say merely
"will withdraw all announcements covered by the earlier allocation, from
the DFZ" within <insert timeframe here>.

No damage is done by the existence of unannounced prefixes - the only
issue is announced prefixes.
And, making it easier for "experimenters" / "early adopters" to adjust
their assignment to better fit their needs, which may (far) exceed
reserved space that ARIN may have kept as a buffer, is in everyone's
interest.

Keep in mind, we are at present talking about only 848 prefixes. Making
exceptions for this tiny number, to avoid policies which might otherwise
be bad in the long term, is something we should be prepared to do.

Brian Dickson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: briand.vcf
Type: text/x-vcard
Size: 232 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070824/99610f9e/attachment.vcf>