It has already been submitted in the RIPE and APNIC regions with the language I submitted here.<div>Stacy<br><br><div class="gmail_quote">On Wed, Jun 3, 2009 at 1:35 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com">owen@delong.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I don't believe this has been submitted to any of the other RIRs<br>
as yet, so, I think that the change I proposed would not slow it down.<br>
In fact, I think it might actually help it get through faster.<br><font color="#888888">
<br>
Owen</font><div><div></div><div class="h5"><br>
<br>
On Jun 1, 2009, at 8:52 AM, David Williamson wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I support the policy as written.  I think Owen has a great idea, but<br>
the timeline is a problem for changes.  It would be possible to start a<br>
new policy to correct this one with Owen's suggested changes, but let's<br>
fast track this one *as is*.<br>
<br>
I'd even support this as written if it was declared to be a Board<br>
response to an emergency.  Unless there are compelling arguments in<br>
dissent, this should simply move forward.<br>
<br>
-David<br>
<br>
On Fri, May 29, 2009 at 03:01:35PM -0500, Scott Leibrand wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One thing to keep in mind here is that, because this is a Global Policy,<br>
and because of the extremely tight timeframe, we need to agree on the<br>
text of the proposal right away, and make sure the same text gets put<br>
forward in each region.  Even if everyone approves it their first time<br>
around, and LACNIC approves it through their fast-track process (since<br>
it'll be exactly a year until their next meeting), we're still looking<br>
at sometime in 2010 before the policy can be ratified by the ASO-AC and<br>
ICANN.  That will mean we will have several months (at least) of RIRs<br>
being unable to get more 16-bit ASNs from the IANA before this policy<br>
could go through and make it possible again.  I've heard some very good<br>
arguments in the last week that the simpler we make the change, the less<br>
likely we are to run into problems that cause delays in getting this<br>
approved in time for it to be useful...<br>
<br>
How important do you think it is to preserve the 16bit/32bit ASN<br>
distinction past 1 Jan 2011?  Is it worth the increased risk of delay in<br>
passing such a revised global policy?<br>
<br>
(As you probably figured out from my comments above, I personally<br>
support this policy.)<br>
<br>
-Scott<br>
<br>
Owen DeLong wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While I do not support changing the RIR policy on the issuance of ASNs,<br>
I do support this policy proposal.  I think that modifying the IANA->RIR<br>
distribution rules to accommodate the needs of RIRs to better serve their<br>
constituents makes sense. Further, having 16-bit ASNs trapped in the<br>
IANA free pool because 32-bit ASNs are not being accepted by recipients<br>
is absurd and poor stewardship. We should go ahead and issue 16-bit<br>
ASNs until they run out.<br>
<br>
I would suggest that this proposal, rather than removing the distinction<br>
in 2010 should be modified to extend the IANA->RIR duality until such<br>
time as there are no more 16-bit ASN blocks in the IANA pool.<br>
<br>
Owen<br>
<br>
On May 29, 2009, at 8:11 AM, Member Services wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ARIN received the following policy proposal and is posting it to the<br>
Public Policy Mailing List (PPML) in accordance with Policy Development<br>
Process.<br>
<br>
This proposal is in the first stage of the Policy Development Process.<br>
ARIN staff will perform the Clarity and Understanding step. Staff does<br>
not evaluate the proposal at this time, their goal is to make sure that<br>
they understand the proposal and believe the community will as well.<br>
Staff will report their results to the ARIN Advisory Council (AC) within<br>
10 days.<br>
<br>
The AC will review the proposal at their next regularly scheduled<br>
meeting (if the period before the next regularly scheduled meeting is<br>
less than 10 days, then the period may be extended to the subsequent<br>
regularly scheduled meeting). The AC will decide how to utilize the<br>
proposal and announce the decision to the PPML.<br>
<br>
In the meantime, the AC invites everyone to comment on the proposal on<br>
the PPML, particularly their support or non-support and the reasoning<br>
behind their opinion. Such participation contributes to a thorough<br>
vetting and provides important guidance to the AC in their<br>
deliberations.<br>
<br>
The ARIN Policy Development Process can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
<br>
Mailing list subscription information can be found<br>
at:<a href="https://www.arin.net/mailing_lists/" target="_blank">https://www.arin.net/mailing_lists/</a><br>
<br>
Regards,<br>
<br>
Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Policy Proposal: Internet Assigned Numbers Authority (IANA) Policy for<br>
Allocation of ASN Blocks (ASNs) to Regional Internet Registries<br>
<br>
Proposal Originator: Stacy Hughes and Andrew de la Haye<br>
<br>
Proposal Version: 1.0<br>
<br>
Date: 29 May 2009<br>
<br>
Proposal type: modify<br>
<br>
Policy term: permanent<br>
<br>
Policy statement:<br>
<br>
Modification of NRPM section 10.3 extending the deadline for an<br>
undifferentiated ASN pool by 1 year to read:<br>
<br>
1. Allocation Principles<br>
<br>
IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the<br>
term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2010,<br>
allocations of 16-bit and 32-bit only ASN blocks will be made separately<br>
and independent of each other [1].<br>
<br>
This means until 31 December 2010, RIRs can receive two separate ASN<br>
blocks, one for 16-bit ASNs and one for 32-bit only ASNs from the IANA<br>
under this policy. After this date, IANA and the RIRs will cease to make<br>
any distinction between 16-bit and 32-bit only ASNs, and will operate<br>
ASN allocations from an undifferentiated 32-bit ASN allocation pool.<br>
<br>
Rationale:<br>
<br>
a. Arguments supporting the proposal<br>
<br>
Due to operational issues external to the IANA/RIR policy process,<br>
32-bit only ASNs are not being issued by the RIRs at the anticipated<br>
rate. As it stands, RIRs will likely not be able to justify a new block<br>
of ASNs from the IANA after 31 December 2009 due to a glut of free 32<br>
bit only ASNs in the RIR’s pool. This leaves available, essential 16-bit<br>
ASNs stranded in the IANA free pool. This proposal seeks to remedy the<br>
potential problem by extending the deadline for differentiation by one<br>
year.<br>
<br>
With this proposal the policy will be aligned with the actual reality in<br>
regards to 32-bit ASN deployment and usage.<br>
<br>
The subject was raised during RIPE 58 and a presentation was made:<br>
<a href="http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf" target="_blank">http://www.ripe.net/ripe/meetings/ripe-58/content/presentations/asn32-take-up-report.pdf</a><br>
<br>
<br>
The feedback in this session suggested that a global policy proposal<br>
should be developed and should be discussed.<br>
<br>
b. Arguments opposing the proposal<br>
<br>
Some may think that extending the previously set timeline can be<br>
perceived as some discouragement for the deployment of 32-bit ASNs. One<br>
counter argument to this is that RIRs and Internet community have some<br>
other mechanisms and activities to raise awareness for 32-bit ASN pool<br>
(via public presentations and trainings). These activities will continue<br>
while 16-bit ASN blocks are still allocated to RIRs by the IANA as they<br>
are available and they are needed.<br>
<br>
Timetable for implementation: Immediately upon ratification by ICANN<br>
Board<br>
<br>
<br>
<br>
_______________________________________________<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">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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote>
<br>
_______________________________________________<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">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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote>
_______________________________________________<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">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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></blockquote>
<br>
_______________________________________________<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">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" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br></div>