I started looking at syncing the 2 sections, but I found the sections are
not as much in sync as it was suggested, and my attempts to refer one to
the other were not that successful.
For example, 8.5.4 Initial block appears to refer to the similar section 4
passage 4.2.2, which is much more detailed than the section 8 passage.
Section 8.5.3 specifies the minimum block to be transfered while 4.2.1.5
talks of the minimum block to be allocated. Both are /24. They are
similar but not the same, so no real opportunity here.
Section 4.2.2 specifies a 24 month window of utilization, whereas 8.5.6
the similar passage has no time standard.
Other passages that I checked do not line up as well as these examples.
I tried to figure how to line up and simplify the two sections, but it
really is not going to be that easy.
And as pointed out, there are micro allocations and v6 blocks that are not
addressed in section 8. SWIP and reassignment rules are not addressed in
section 8 as well, so regardless of effort, these parts of section 4 would
need to remain.
I suggest that we wait to a future time when v4 might not be used much at
all before suggesting removal of section 4. I vote to abandon.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Thu, 20 Jul 2017, Owen DeLong wrote:
On Jul 17, 2017, at 12:32 , Chris Woodfield <[email protected]> wrote:
Hello,
Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response
to the proposal in its current state appears to be universally negative.
Having read the comments on this proposal, it could be plausible that an
alternate solution to the problem statement could be that in lieu of retiring
most of the section, specific sections could be substantially simplified by
pointing to the currently-duplicated clauses in Section 6, eliminating the need
to manually keep these sections in sync by applying similar policy to both
where warranted (in particular, the sections around utilization justification
seem like the best candidates).
I think you mean section 8 as section 6 applies to IPv6 policy and would be
absurd if applied to IPv4.
Does the community feel that this is a viable route to explore, which would
simplify Section 4 while keeping the necessary relevant sections, in lieu of
the original proposal?
Perhaps. Or perhaps we just abandon this proposal.
Owen
Thanks,
-Chris
On Jun 21, 2017, at 12:16 PM, Austin Murkland <[email protected]
<mailto:[email protected]>> wrote:
I do not support this policy for the reasons Kevin and Albert outlined. This
seems a bit premature.
Thanks,
Austin Murkland
On Tue, Jun 20, 2017 at 1:40 PM, ARIN <[email protected] <mailto:[email protected]>>
wrote:
On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire
Obsolete Section 4 From the NRPM" to Draft Policy status.
Draft Policy ARIN-2017-7 is below and can be found at:
https://www.arin.net/policy/proposals/2017_7.html
<https://www.arin.net/policy/proposals/2017_7.html>
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/policy/pdp.html <https://www.arin.net/policy/pdp.html>
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
<https://www.arin.net/policy/proposals/index.html>
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2017-7: Retire Obsolete Section 4 from the NRPM
Problem Statement:
Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The
community elected, instead of revamping and modernizing section 4 in light of
this to, instead, recreate the relevant parts of section 4 in section 8.5. As a
result, section 4 is generally obsolete and can be mostly retired. Since some
small amounts of space do occasionally recreate the free pool, a mechanism for
addressing this must remain and therefore a much reduced section 4 is proposed
here instead of outright retirement.
Policy statement:
Replace section 4 of the NRPM with the following:
4. IPv4
4.1 IPv4 Requests
4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall
be evaluated based on the criteria for transfer recipients contained in section
8.5.
4.1.2 Any approved requests which cannot be met from the ARIN free pool shall
be handled according to section 4.2.
4.2 Unmet requests
In the event that ARIN does not have a contiguous block of addresses of
sufficient size to fulfill a qualified request, ARIN will provide the
requesting organization with the option to specify the smallest block size
they'd be willing to accept, equal to or larger than the applicable minimum
size specified elsewhere in ARIN policy. If such a smaller block is available,
ARIN will fulfill the request with the largest single block available that
fulfills the request. If no such block is available, the organization will be
provided the option to be placed on a waiting list of pre-qualified recipients,
listing both the block size qualified for and the smallest block size
acceptable.
Repeated requests are not allowed: an organization may only receive one
allocation, assignment, or transfer every 3 months, but ARIN, at its sole
discretion, may waive this requirement if the requester can document a change
in circumstances since their last request that could not have been reasonably
foreseen at the time of the original request, and which now justifies
additional space.
Qualified requesters whose request cannot be immediately met will also be
advised of the availability of the transfer mechanism in section 8.3 as an
alternative mechanism to obtain IPv4 addresses.
4.2.1. Waiting list
The position of each qualified request on the waiting list will be determined
by the date it was approved. Each organization may have one approved request on
the waiting list at a time.
4.2.2. Fulfilling unmet needs
As address blocks become available for allocation, ARIN will fulfill requests
on a first-approved basis, subject to the size of each available address block
and a timely re-validation of the original request. Requests will not be
partially filled. Any requests met through a transfer will be considered
fulfilled and removed from the waiting list.
Comments:
a. Timetable for implementation: Immediate
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
<http://lists.arin.net/mailman/listinfo/arin-ppml>
Please contact [email protected] <mailto:[email protected]> if you experience any
issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]
<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
<http://lists.arin.net/mailman/listinfo/arin-ppml>
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
