[ppml] tying back to 2005-1

[Owen DeLong]

--On Friday, May 20, 2005 13:56 -0400 Edward Lewis <Ed.Lewis at neustar.biz> 
wrote:

> I'm assuming that the mega-thread "IPv6>>32" and it's threadlets are
> related to the proposed policy 2005-1.
>
Only in so much as they are both IPv6 oriented.  They do not attempt to, in
any way, address the same issue that 2005-1 was aimed at.

> I have a few questions in that context.
>
> Is the policy's reference to "minimum size" saying that the allocation is
> to be a prefix of /48?
>
The 2005-1 reference to minimum size is intended to be non-specific so that
if ARIN changes the minimum allocation unit, generally, it will change for
this policy as well.  Under current guidelines, yes, it would be a /48.

> "If the organization grows to require more space" - does this mean that
> the organization has hit the HD ratio limit?  Does the organization have
> to register all of it's used addresses (SWIP?) to indicate this?
>
Since this is an end site and an assignment, not an allocation, SWIP would
not be applicable.  Yes, it would require at least meeting the HD ratio
limit, but, I would tend to think that the following criteria
would apply:

	Need for more subnets than can be contained in current
	assignment (e.g. if /48 is current assignment, org would
	have to show need for more than 65,536 subnets.

OR
	Need for more than 64 bits per subnet such that a smaller number
	of subnets would still encompass a /48).

> Will such address allocations be "non-aggregatable?"  Is the intent to
> allocate these addresses from one segment of address space range because
> of that?

2005-1 provides for assignments, not allocations.  I'm not sure what you
mean by non-aggregatable.  If you mean "Is the expectation that these
assignments will probably be advertised with a unique routing policy?", 
then,
the answer is yes.

As to the second part of your question, I think that is the kind of thing
that would usually be left up to ARIN staff.  If you feel it's important, 
you
could propose it as an amendment to the policy and we could see how people
feel about it.  I tend to think staff would probably do that anyway, just to
make their workflow more efficient if nothing else.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050523/5edaecfd/attachment.sig>