[ppml] Allocation and reallocation

Leo Bicknell bicknell at ufp.org
Mon Oct 27 11:15:34 EST 2003

In a message written on Mon, Oct 27, 2003 at 11:02:28AM -0500, jlewis at lewis.org wrote:
> Are you talking about ASSIGNMENT|ALLOCATION by ARIN or in general?  When I
> allocate IPs to an ISP customer, ARIN creates an ORG ID (i.e. we're INCC)  
> for the holder of the allocation, allowing them to submit swips.  If ARIN
> had to do this for every customer we assign (in the generic, not ARIN
> meaning) IPs to, most of whom will never submit a swip, the number of ORG
> IDs would skyrocket for no good reason.

I'm thinking a little more general, as there are a number of "under
the hood" details that would need to be worked out.

Basically I think all blocks should be the same.  If you submit a
swip, on that swip you can either mark it "simple" (that person has
it and can't do anything else with it), or "subdivideable", in which
case they get an org id and can swip parts of that block (perhaps
all simple, or perhaps they can still set simple and subdivideable).

Then, separate from this single policy for addresses given out would
be a fee structure based on something like the size of the block.
It could be based on the number of SWIP's (direct database cost),
but I don't like that as it may discourage people from SWIP'ing in
some cases.

Anyway, what I was really getting at is are there tehnical policy
reasons why one group can SWIP space, and one group can't SWIP space?
For instance, do we not trust "end users" (to use current terms) to
SWIP space if they later end up with a "customer"?  Or is it just a
way to charge "end users" a lower fee?

       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20031027/71d8fb48/attachment-0001.sig>

More information about the ARIN-PPML mailing list