<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Andrew,<div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Happy to hear and be swayed by data or other arguments.</div><div><br></div><div>David <br><br><div id="AppleMailSignature">Sent from my iPhone</div><div><br>On Dec 4, 2017, at 4:30 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net">andrew.dul@quark.net</a>> wrote:<br><br></div><blockquote type="cite"><div>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div class="moz-cite-prefix">Scott, how would you feel about this
proposed updated problem statement which focuses on the current
issue rather than the past.<br>
<br>
Andrew<br>
<br>
<p><strong>Problem Statement: </strong></p>
<p>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. <br>
</p>
<br>
<br>
On 11/21/2017 9:19 PM, Scott Leibrand wrote:<br>
</div>
<blockquote type="cite" cite="mid:053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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. <br>
<br>
<div id="AppleMailSignature">
<div>Scott</div>
</div>
<div><br>
On Nov 21, 2017, at 7:28 PM, Andrew Dul <<a href="mailto:andrew.dul@quark.net" moz-do-not-send="true">andrew.dul@quark.net</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<meta http-equiv="content-type" content="text/html;
charset=utf-8">
<div>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.</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">Assuming we harmonize the problem
statement, would you prefer the /24 as initial no questions
asked size or a /21?</div>
<div id="AppleMailSignature"><br>
</div>
<div id="AppleMailSignature">What do others prefer?</div>
<div id="AppleMailSignature"><br>
.Andrew</div>
<div><br>
On Nov 21, 2017, at 2:52 PM, Scott Leibrand <<a href="mailto:scottleibrand@gmail.com" moz-do-not-send="true">scottleibrand@gmail.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">I believe this problem statement is
incorrect, and therefore oppose the policy proposal
as-is.
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>8.5.5 reads "8.5.5. Block size</div>
<div>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."</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>-Scott</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Nov 21, 2017 at 2:40
PM, ARIN <span dir="ltr"><<a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Draft Policy ARIN-2017-9 is below and can be found
at:<br>
<a href="https://www.arin.net/policy/proposals/2017_9.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pr<wbr>oposals/2017_9.html</a><br>
<br>
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:<br>
<br>
* Enabling Fair and Impartial Number Resource
Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The PDP can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pd<wbr>p.html</a><br>
<br>
Draft Policies and Proposals under discussion can be
found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.arin.net/policy/pr<wbr>oposals/index.html</a><br>
<br>
Regards,<br>
<br>
Sean Hopkins<br>
Policy Analyst<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
<br>
Draft Policy ARIN-2017-9: Clarification of Initial
Block Size for IPv4 ISP Transfers<br>
<br>
Problem Statement:<br>
<br>
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.<br>
<br>
Policy statement:<br>
<br>
Add the following to 8.5.4<br>
<br>
ISP organizations without direct assignments or
allocations from ARIN qualify for an initial
allocation of up to a /21.<br>
<br>
Comments:<br>
<br>
a. Timetable for implementation: Immediate<br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are
subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription
at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank" moz-do-not-send="true">info@arin.net</a>
if you experience any issues.<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>PPML</span><br>
<span>You are receiving this message because you are
subscribed to</span><br>
<span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).</span><br>
<span>Unsubscribe or manage your mailing list subscription
at:</span><br>
<span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml" moz-do-not-send="true">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
<span>Please contact <a href="mailto:info@arin.net" moz-do-not-send="true">info@arin.net</a> if you
experience any issues.</span></div>
</blockquote>
</div>
</blockquote>
</blockquote>
<p><br>
</p>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</span></div></blockquote></div></body></html>