In NRPM, I see 3 different IPv4 sizes mentioned. They are the /27
mentioned in section 4, the /24 mentioned in section 8, and the /22
mentioned for the block still available and reserved for IPv6 trans tech.
I say that we set the section 4 standard to /24 same as section 8, as this
allows us to serve more people on the wait list, than if each can ask for
a /21. I strongly think we are not serving very many people via the wait
list anyway, as much of the space that would otherwise be returned, is
ending up in the section 8 transfer process instead.
If they need more, they either need a section 8 transfer, or consider what
doing what we all need to do, which is to move to IPv6 and apply for a /22
for trans tech for short term IPv4 need until we all move.
Under section 8, I really do not see what is burdensome in having an
officer attest to the need. ARIN needs this policy to prevent speculation
in number resources.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 5 Dec 2017, Scott Leibrand wrote:
Section 8 as discussed on PPML and as written gives anyone the ability to
transfer a /24 without justification and requires officer-attested
justification for anything larger.
If there are organizations transferring blocks larger than a /24 for
whom officer-attested justification is burdensome (to them or to ARIN)
I???d like to understand what is burdensome, so we can figure out how to
reduce that burden. If not, then implementing section 8 as written seems
appropriate until we identify a reason to change it.
Scott
On Dec 5, 2017, at 8:40 AM, Andrew Dul <[email protected]> wrote:
I would agree there is nothing special about /21, that is just where we
ended up at exhaustion.
It is possible this draft policy doesn't do what the community wants us
to do. I wrote this draft as a followup to the policy experience
report to continue the conversation about the issue and to correct the
inconsistency. (Normally, I think of inconsistencies as a "bad" thing
in policy)
Perhaps what we really do want is a more strict interpretation of the
new section 8 transfer policy? If so we need a way to signal that to
staff. I'd think that could happen here on this list or at a meeting
and thus no policy change is needed.
Andrew
On 12/4/2017 2:47 PM, David Huberman wrote:
Andrew,
It???s unclear to me that /21 is the correct boundary, especially (as Scott
Leibrand asked for) absent statistics from the staff (if any such stats make
sense). With section 8 policy now wholly separated from section 4 policy, I
sort of think that it???s the staff who should change their practices, and
follow section 8 policy as written.
Further to your problem statement, ISPs should NOT be applying under
section 4 anymore. We know, however, from staff reports at the recent ARIN
meeting that they still are applying. That???s a definite problem, but it
feels to me to be a different problem than what you are tackling in this draft
policy proposal.
Happy to hear and be swayed by data or other arguments.
David
Sent from my iPhone
On Dec 4, 2017, at 4:30 PM, Andrew Dul <[email protected]> wrote:
Scott, how would you feel about this proposed updated problem statement which
focuses on the current issue rather than the past.
Andrew
Problem Statement:
It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in
the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size
should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer
size" which is effectively a /24. This causes ISP organizations to be approved for
different initial block size depending on if they first apply apply for a transfer
directly under section 8 or if they apply for a block under section 4. This policy is
intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It
was noted that ARIN staff current operational practice is to allow all ISPs an initial
/21 for Section 8 transfers.
On 11/21/2017 9:19 PM, Scott Leibrand wrote:
I???d be ok with a /21, but there???s nothing magical about that size in a
post-exhaustion world. I???d rather base a loosening on actual transfer
statistics, and consider doing so for both allocations and assignments.
Scott
On Nov 21, 2017, at 7:28 PM, Andrew Dul <[email protected]> wrote:
It sounds like our recollections of what we intended for ISP initial
allocations have diverged. I will admit when I drafted the problem statement I
did not go back through email to see if there was anything about this issue.
Assuming we harmonize the problem statement, would you prefer the /24 as
initial no questions asked size or a /21?
What do others prefer?
.Andrew
On Nov 21, 2017, at 2:52 PM, Scott Leibrand <[email protected]> wrote:
I believe this problem statement is incorrect, and therefore oppose the policy
proposal as-is.
8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled
up) to allow ISPs to transfer a /24 without justification. It was *not* intended to
"match the previous policy" in 4.2.2.
8.5.5 reads "8.5.5. Block size
Organizations may qualify for the transfer of a larger initial block, or an
additional block, by providing documentation to ARIN which details the use of at
least 50% of the requested IPv4 block size within 24 months. An officer of the
organization shall attest to the documentation provided to
ARIN."
The intention was that any ISP needing a /21 would need to "provide documentation to
ARIN which details the use of at least 50% of the requested IPv4 block size within 24
months", with officer attestation to same.
If that policy is deemed insufficient, and we believe it's better to allow
transfers of up to /21 without providing documentation to ARIN and officer
attestation of such, then this proposal would need to be re-written with a new
problem statement justifying that.
-Scott
On Tue, Nov 21, 2017 at 2:40 PM, ARIN <[email protected]> wrote:
On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244:
Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status.
Draft Policy ARIN-2017-9 is below and can be found at:
https://www.arin.net/policy/proposals/2017_9.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
Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html
Regards,
Sean Hopkins
Policy Analyst
American Registry for Internet Numbers (ARIN)
Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP
Transfers
Problem Statement:
It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in
the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size
should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer
size" which is effectively a /24. The intent of the new 8.5.4 was to match the
previous policy. This policy is intended to clarify this issue. It was noted that ARIN
staff current operational practice is to allow ISPs an initial /21 for Section 8
transfers.
Policy statement:
Add the following to 8.5.4
ISP organizations without direct assignments or allocations from ARIN qualify
for an initial allocation of up to a /21.
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]).
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.
_______________________________________________
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.
