I find it interesting the idea of privileging the pool dedicated to
facilitate IPv6 Deployment and I also agree with the comments below in
the sense that it's not very beneficial do most ARIN members due to max
size, /22, cannot be holding more than a /20.
However one point I couldn't identify is where the new entrants stand in
this new possible scenario ? Will they only be able to apply under the
4.10 reserved pool ? If so for a access/broadband ISPs may be easier to
fit, but not necessarily for other scenarios and types of ISPs.
Therefore if I didn't miss anything these returned addresses should also
be able to go to new entrants, not only to 4.10 reserved pool conditions.
Best regards
Fernando Frediani
On 25/07/2019 17:32, Tom Fantacone wrote:
I found the wording of the Problem Statement on this one a bit
confusing. However, after deciphering the effect of the actual policy
change I support it.
Essentially, all returned IPv4 space will no longer go to the waiting
list but will supplement the 4.10 reserved pool used to enhance IPv6
deployment. This essentially kills off the waiting list.
The recent restrictions placed on the waiting list to reduce fraud
have hobbled it to the point where it's not very beneficial to most
ARIN members. (Max size, /22, cannot be holding more than a /20).
It's essentially only useful to new entrants, but those that go on it
still have to wait many months to receive their small allocation. If
they justify need now, but have to wait that long, how critical is
their need if they're willing to wait that long? Small blocks are not
terribly expensive and can be quickly gotten on the transfer market.
I can understand waiting that long for a large block needed for a
longer term project due to prohibitive cost, but I don't see a great
benefit to the waiting list as it stands.
Also, if there's any fraud left on the waiting list, this would kill it.
I would hope, however, that if implemented, those currently on the
waiting list would be grandfathered in. I do think some entities with
legitimate need got burned on the last change made to the waiting list.
At 04:05 PM 7/23/2019, ARIN wrote:
On 18 July 2019, the ARIN Advisory Council (AC) accepted
"ARIN-prop-276: Returned Addresses to the 4.10 Reserved Pool" as a
Draft Policy.
Draft Policy ARIN-2019-17 is below and can be found at:
https://www.arin.net/participate/policy/drafts/2019_17/
You are encouraged to discuss all Draft Policies on PPML. The AC will
evaluate the discussion in order to assess the conformance of this
draft policy with ARIN's Principles of Internet number resource
policy as stated in the Policy Development Process (PDP).
Specifically, these principles are:
* Enabling Fair and Impartial Number Resource Administration
* Technically Sound
* Supported by the Community
The PDP can be found at:
https://www.arin.net/participate/policy/pdp/
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/participate/policy/drafts/
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2019-17: Returned Addresses to the 4.10 Reserved Pool
Problem Statement:
An inconsistent and unpredictable stream of address space is an
unsuitable method of populating the waiting list (4.1.8.1) and
fulfilling subsequent requests.
Policy statement:
Change "4.10. Dedicated IPv4 Block to Facilitate IPv6 Deployment" to
"4.10 Dedicated IPv4 Pool to Facilitate IPv6 Deployment"
Change" When ARIN receives its last /8 IPv4 allocation from IANA, a
contiguous /10 IPv4 block will be set aside and dedicated to
facilitate IPv6 deployment. Allocations and assignments from this
block " to "In addition to the contiguous /10 IPv4 block set aside
and dedicated to facilitate IPv6 deployment, all returns and
revocations of IPv4 blocks will be added to the pool of space
dedicated to the facilitation of IPv6 deployment. Allocations and
assignments from this pool "
Change "This block will be subject to a minimum size allocation of
/28 and a maximum size allocation of /24. ARIN should use sparse
allocation when possible within that /10 block." to "This pool will
be subject to a minimum size allocation of /28 and a maximum sized
allocation of /24. ARIN should use sparse allocation when possible
within the pool."
Comments:
Timetable for implementation: Immediate
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
