[arin-ppml] Is Emergency action warranted for Policy Proposal 123: Reserved Pool for Critical Infrastructure?

Jack Bates jbates at brightok.net
Tue Dec 14 16:16:08 EST 2010


On 12/14/2010 2:34 PM, Sweeting, John wrote:
> To All Subscribers of PPML,
>
> *   ARIN-prop-125. Efficient Utilization of IPv4 Requires
> Dual-Stack<https://www.arin.net/policy/proposals/policy_proposal_archive.html>
>

Oppose 125, Documentation and proof of following the policy is near
impossible. It is very specific in how things should be which doesn't
match all topology types; especially pool related requirements in
eyeball networks.

It also misses the fact that many IPv4 requests may often be due to
legacy equipment which cannot handle IPv6 yet and may be in transitional
periods. There are also uses for v4 where there is no need to dual stack
and renumbering mpls infrastructure or cpe management to rfc1918 should
not be a requirement.

> *   ARIN-prop-124. Clarification of Section
> 4.2.4.4<https://www.arin.net/policy/proposals/policy_proposal_archive.html>



oppose 124. While I believe strongly that the policy at the time of the
request should be the ruling policy, there is a great fear that there
will be a last minute rush just prior to the 10.4.2.2 taking effect.
This rush could cause a severe backup in the queue to the degree that
the remaining space is fully allocated before the queue is clear.

I would support any request which was submitted at a time frame prior to
the actual execution of 10.4.2.2 (ie, 1-3 weeks prior or in an escalated
state).

> *   ARIN-prop-123. Reserved Pool for Critical
> Infrastructure<https://www.arin.net/policy/proposals/policy_proposal_archive.html>
>

support prop 123, though I'd feel better if Critical Infrastructure has
a test mechanism that ARIN could use to qualify who will receive space
from the reserved pool.

> *   ARIN-prop-122. Reserved Pool for Future Policy
> Development<https://www.arin.net/policy/proposals/policy_proposal_archive.html>


support prop 122. It allows time for ARIN to decide what is appropriate 
for the space at a later time when a better understanding is available. 
I do believe it needs a monthly review of possible uses.

>
>
> *   ARIN-prop-121. Sensible IPv6 Allocation for
> ISPs<https://www.arin.net/policy/proposals/policy_proposal_archive.html>
>

Support prop 121. It is much more sensible than what we have. It may 
need some review in areas, but it is a good start and will fix some 
serious issues that currently exist in v6 adoption. This is not an 
emergency proposal.


>
> *   ARIN-prop-120. Protecting Number
> Resources<https://www.arin.net/policy/proposals/policy_proposal_archive.html>

support the concept of prop 120, though I believe it needs more wording 
and guidelines to appropriate fit better. I also don't classify it as 
emergency.


> *   ARIN-prop-119. Globally Coordinated Transfer
> Policy<https://www.arin.net/policy/proposals/policy_proposal_archive.html>
>
>
  Support concept of prop 119, though I believe it needs more wording, 
and a better understanding of how transfers between RIR would take place 
or how such could be managed given our current hierarchical model. This 
is especially important, given the IANA assignment table.

>
> Which of these proposals should the BoT consider under the Emergency
> PDP? And what is the criteria you used to come to this conclusion.
>

122 and 123 for sure. They are not harmful policies, and even if enacted 
on emergency, they can be released or utilized at a later time if 
necessary. They are precautionary policies which are only useful if 
enacted quickly.

Though I oppose its current state, 124. I prefer limitations or wording 
to avoid the "It's about to happen, everyone email in a request tonight 
to get the 24 months." Other than that, it's only useful if applied as 
an emergency action.

I don't see any other proposals which justify emergency evaluation. 
Arguably 125, but I do not believe that 125 should be allowed to be 
implemented on emergency basis. It needs serious evaluation and 
community input.


Jack



More information about the ARIN-PPML mailing list