<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">I would agree there is nothing special
about /21, that is just where we ended up at exhaustion. <br>
<br>
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) <br>
<br>
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. <br>
<br>
Andrew<br>
<br>
On 12/4/2017 2:47 PM, David Huberman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E25B4A36-FD4E-44DB-AF08-E24BEC062358@panix.com">
<meta http-equiv="content-type" content="text/html; charset=utf-8">
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" 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 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" 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>
<p><br>
</p>
</body>
</html>