[ppml] IPv6 Assignment Guidelines, Straw Man #2

[Brian Dickson]

Leo Bicknell wrote:
>
> The feedback is pretty clear, and so I'd like to offer up a straw
> man for a potentially better proposal.  It's quite clear people
> want a simple rule, and want a /48 to be allowed.
>   
Uh, it doesn't seem you got my feedback, or didn't read it.

Allow me to express my opinion clearly, then, up front, so you include
it in your summary.

I don't believe any LIRs should be given more than one PI block from
which to allocate PA space.
And, as such, this has two requirements to be a reasonable suggestion:

    * LIRs should be free to request PI space (the one block they get)
      that meets their forseeable needs (10 years at least).
    * LIRs should be free to assign PA space from their PI block as they
      see fit, with no further oversight needed

ARIN staff should never need to evaluate anything other than initial IPv6
requests, and should be extremely lenient in allocating those. Any
justification that passes the giggle test, should be fine.

There is no need for any metric, HD or otherwise. The restriction of one
new IPv6 block per ASN will keep the DFZ small,
the rate of growth limited, and will encourage sensible PA assignment
policies.

If an LIR gives away all its space, that is its problem to deal with. It
should be reasonable to expect it to claw-back some of its space in such
an instance.
But having the LIR recognize that the resource allocated to *it* is
extremely finite, pushes the problem out of the DFZ space.

Since this would be a new policy, and given the very limited number of
PI blocks in the DFZ currently, I would propose that any LIR whose
previous allotments were insufficient, be allowed to request one more
block subsequent to enactment of this policy. It would not be fair to
make the policy retroactive, and the impact of at most 300 or so
additional PI blocks, ever, is not so much of a burden as to make it
untenable.

Brian Dickson

P.S. Under this proposal, an alternative to the current "straw man",
Randy would be free to assign half his space to one of his customers.
-------------- 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/20070820/601692ec/attachment.vcf>