<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [arin-ppml] Integrating Draft Policy ARIN-2011-1 into NRPM 8.3</TITLE>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19046">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Bill,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>My point is that the guidelines you posted are
already obseleted by current transfer requirements involving not 12 months,
but three months of usage in the current needs test.</FONT></DIV>
<DIV><FONT size=2 face=Arial>Could RIPE refuse to transfer to us because we are
violating the "values" of RFC2050 by not allowing a 12 months of
need?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>So attempting to claim that RFC2050 somehow clears
up the uncertainty about the word "compatible" doesn't suffice.</FONT></DIV>
<DIV><FONT size=2 face=Arial>And as far as cherry picking, my quote of 4.1 says
"the primary", while you degrade that language to "a primary" in your
reply.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>And anyway, what is the point of trying to use RFC
2050 to justify or explain language that could be clearly inserted in the
NRPM?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>This is similar to when I pointed out that section
12 of the NRPM would not give ARIN the right to revoke addresses for utilization
as it is written now, and John proffered RFC2050 as providing that
justification, which is lacking in the current NRPM language.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>That is like using the Declaration of Independence
to make a legal finding absent from the Constitution. Sure it can give guidance,
but the actual rules are better clearly established in the NRPM, if that is an
option.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Regards,</FONT></DIV>
<DIV><FONT size=2 face=Arial>Mike</FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B>
<A title=BillD@cait.wustl.edu href="mailto:BillD@cait.wustl.edu">Bill
Darte</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=mike@nationwideinc.com
href="mailto:mike@nationwideinc.com">Mike Burns</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=arin-ppml@arin.net
href="mailto:arin-ppml@arin.net">ARIN-PPML List</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, May 27, 2011 11:11 AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [arin-ppml] Integrating
Draft Policy ARIN-2011-1 into NRPM 8.3</DIV>
<DIV><BR></DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial>Mike,</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial>Please don't cherry-pick the guidance of RFC
2050.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial>It also says, more pertinent and fundamental to the issues
of transfers and efficiency....</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><FONT color=#0000ff
size=2 face=Arial></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=218355914-27052011><PRE>1. Introduction</PRE><PRE><PRE> Internet address space is distributed according to the following
three goals:
</PRE>
1) Conservation: Fair distribution of globally unique Internet address
space according to the operational needs of the end-users and Internet
Service Providers operating networks using this address space.
Prevention of stockpiling in order to maximize the lifetime of the Internet address space.</PRE><PRE> 2) Routability: Distribution of globally unique Internet addresses
in a hierarchical manner, permitting the routing scalability of
the addresses. This scalability is necessary to ensure proper
operation of Internet routing, although it must be stressed that
routability is in no way guaranteed with the allocation or
assignment of IPv4 addresses.
3) Registration: Provision of a public registry documenting address
space allocation and assignment. This is necessary to ensure
uniqueness and to provide information for Internet trouble shooting
at all levels.<BR>
Conservation is the first principle, registration services is a primary duty of the RIR, to be sure, but its goals are not record keeping <BR></SPAN><SPAN class=218355914-27052011><FONT face="Courier New">alone, but for the purposes of achieving the goals otherwise described</FONT></SPAN><SPAN class=218355914-27052011><FONT face="Courier New">.<BR></FONT></SPAN><SPAN class=218355914-27052011><BR><BR></SPAN></PRE><PRE><SPAN class=218355914-27052011>Moreover, </SPAN></PRE><PRE><SPAN class=218355914-27052011><PRE>3.1 Common Registry Requirements
Because the number of available IP addresses on the Internet is
limited, the utilization rate of address space will be a key factor
in network number assignment. Therefore, in the best interest of the
Internet as a whole, specific guidelines have been created to govern
the assignment of addresses based on utilization rates.
Although topological issues may make exceptions necessary, the basic
criteria that should be met to receive network numbers are listed
below:
25% immediate utilization rate
50% utilization rate within 1 year</PRE><PRE><PRE> The utilization rate above is to be used as a guideline, there may be
be occasions when the 1 year rate does not fall exactly in this
range. Organizations must exhibit a high confidence level in its 1
year utilization rate and supply documentation to justify the level
of confidence.
Organizations will be assigned address space based on immediate
utilization plus 1 year projected utilization. A prefix longer than
/24 may be issued if deemed appropriate. Organizations with less
than 128 hosts will not be issued an IP address directly from the
IRs. Organizations may be issued a prefix longer than /24 if the
organization can provide documentation from a registry recognized ISP
indicating the ISP will accept the long prefix for injection into the
global routing system.
Exceptions to the criteria will not be made based on insufficient
equipment without additional detailed justification. Organizations
should implement variable length subnet mask (VLSM) internally to
maximize the effective utilization of address space. Address
assignments will be made under the assumption that VLSM is or will be
implemented.
IP addresses are valid as long as the criteria continues to be met.
The IANA reserves the right to invalidate any IP assignments once it
is determined the the requirement for the address space no longer
exists. In the event of address invalidation, reasonable efforts
will be made by the appropriate registry to inform the organization
that the addresses have been returned to the free pool of IPv4
address space.
</PRE></PRE></SPAN></PRE><PRE><SPAN class=218355914-27052011><PRE>4. Operational Guidelines For Registries
</SPAN><SPAN class=218355914-27052011> 7. The transfer of IP addresses from one party to another must be
approved by the regional registries. The party trying to obtain
the IP address must meet the same criteria as if they were
requesting an IP address directly from the IR.
</PRE></PRE><PRE>Clearly, the guidelines call for efficient utilization by entities that have need and can justtify the need<BR>and transfers would be according to local policies of RIRs....which have all agreed to conform to these principles.</PRE><PRE>bd</PRE></SPAN></DIV><BR>
<BLOCKQUOTE
style="BORDER-LEFT: #0000ff 2px solid; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV dir=ltr lang=en-us class=OutlookMessageHeader align=left>
<HR tabIndex=-1>
<FONT size=2 face=Tahoma><B>From:</B> Mike Burns
[mailto:mike@nationwideinc.com] <BR><B>Sent:</B> Friday, May 27, 2011 9:16
AM<BR><B>To:</B> Bill Darte; Chris Grundemann<BR><B>Cc:</B> ARIN-PPML
List<BR><B>Subject:</B> Re: [arin-ppml] Integrating Draft Policy ARIN-2011-1
into NRPM 8.3<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><FONT size=2 face=Arial>Hi Bill,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>It's still not clear to me.</FONT></DIV>
<DIV><FONT size=2 face=Arial>Referencing "values" of an RFC is not terribly
clarifying when attempting to match transfer needs requirements which
already are out of sync with RFC2050's 1 year window.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>And anyway, I say that requiring a needs test
is *NOT* consistent with the values expressed here in RFC2050:</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV>4. Operational Guidelines For Registries<BR><BR>
1. Regional Registries provide registration services as
its<BR> primary function.</DIV>
<DIV> </DIV>
<DIV><FONT size=2 face=Arial>By requiring a needs test for inter-RIR
transfers, we run the risk of driving these transfers off the books in
contravention of our PRIMARY function as stewards.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Just so we all understand. </FONT></DIV>
<DIV><FONT size=2 face=Arial>APNIC has a great need, and probably less
underutilized addresses in its market to supply that need.</FONT></DIV>
<DIV><FONT size=2 face=Arial>A good chunk of available space is likely to be
found in the legacy pools which are overrepresented in our
region.</FONT></DIV>
<DIV><FONT size=2 face=Arial>The majority of this legacy space is not under
any RSA with any RIR.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>You can route legacy space from inside
Asia.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>A likely action that will occur is the
purchases of address blocks from legacy holders which will be routed in Asia
by network operators there, but ARIN will not be notified and Whois will not
be updated.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I have said that I think we are moving into a
future with more, rather than less, conflict over IPv4 address control. This
is only to be expected, as the availability of free pool addresses has
always provided a replacement option for any addresses in conflict. In
addition, the underlying monetary value of address control, once understood,
provides ample motive to drive conflict.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>In an age of conflict, the accuracy of Whois
will be related to the level of trust afforded to it. The absence of a
strong trust authority could open the doors to a private
registry.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Suppose there is conflict between private
organizations over address control. Then add to that conflict between
RIRs over which registry is the authoritative. What is to stop a real
international trust authority, say Lloyds of London, from using its trust to
establish a pricey but generally recognized registry?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Or even worse, what if the door is opened to
the ITU to claim the RIR system was failing in a post-exhaust era, and seek
to create its own registry system, or otherwise take control?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Once again, I make the point that a market in
IPv4 addresses, such as envisaged in 8.3 or in the APNIC transfer policy,
meets the stewardship goal of conservation through natural market
forces.</FONT></DIV>
<DIV><FONT size=2 face=Arial>If we ladle on an extra helping of steward
meddling, we are taking action in contravention of our primary duty to
maintain a viable and trusted registry.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>So I would support the proposal if the
requirement was simply that both RIRs approve, leaving off the "signal" sent
by the needs language, which signal reads like a shot across the bow to
me.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Regards,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Mike</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT><BR> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px"
dir=ltr>
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B>
<A title=BillD@cait.wustl.edu href="mailto:BillD@cait.wustl.edu">Bill
Darte</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A title=mike@nationwideinc.com
href="mailto:mike@nationwideinc.com">Mike Burns</A> ; <A
title=cgrundemann@gmail.com href="mailto:cgrundemann@gmail.com">Chris
Grundemann</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=arin-ppml@arin.net
href="mailto:arin-ppml@arin.net">ARIN-PPML List</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Friday, May 27, 2011 7:38
AM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: [arin-ppml] Integrating
Draft Policy ARIN-2011-1 into NRPM 8.3</DIV>
<DIV><BR></DIV><!-- Converted from text/plain format -->
<P><FONT size=2>The word you say is subjective...'compatible'... in the DP
is interpreted by..<BR>'that exercise Internet stewardship consistent with
the values expressed in RFC2050'<BR><BR><BR>-----Original
Message-----<BR>From: <A
href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</A> on
behalf of Mike Burns<BR>Sent: Thu 5/26/2011 4:28 PM<BR>To: Chris
Grundemann<BR>Cc: ARIN-PPML List<BR>Subject: Re: [arin-ppml] Integrating
Draft Policy ARIN-2011-1 into NRPM 8.3<BR><BR>> What is to be gained by
including that language, except to engender<BR>> Inter-RIR
conflict?<BR>> The wording already includes both RIRs to approve the
transfer.<BR>> There is no definition in the policy or elsewhere in the
NRPM of<BR>> "compatible" needs policies.<BR>> I don't see the point
in including it.<BR><BR>The point of that statement is to signal the
intentions of the ARIN<BR>community both to ARIN staff and to other RIRs.
It provides guidance<BR>to ARIN staff that they should not agree to any
transfer that does not<BR>include needs-based policy on the recipient end.
It also ensures that<BR>recipients in other regions will not be surprised
when a transfer is<BR>denied for lack of said needs-based policies. The
point, in short, is<BR>clarity and
transparency.<BR><BR>Cheers,<BR>~Chris<BR><BR><BR>Hi Chris,<BR><BR>But how
clear is it exactly?<BR>Do you mean it to signal that *any* needs test is
compatible?<BR>If that is the intent, then I think the language can be
clearer.<BR>If you want clarity, then using a subjective word like
"compatible" which is<BR>undefined in the proposal is
sub-optimal.<BR>Since its definition and application is left to ARIN
staff, and ARIN staff<BR>is required to decide on transfer approval
anyway, I don't see any great<BR>clarity or transparency.<BR>What I do see
reads like a political statement added onto a policy proposal,<BR>to no
real effect except to exacerbate inter-RIR tensions.<BR>What better way to
incite the APNIC stewards to unilaterally decide to<BR>accept transfers
into their region of legacy space with no RSA in place?<BR>This is
currently a lacuna in policy awaiting a test case, as far as I
know.<BR><BR>It's not like there are hundreds of different transfer
policies, I'm sure<BR>those requesting inter-RIR transfers will be aware
of the current policies<BR>without brandishing our disdain for their
version of stewardship in<BR>additional and functionally inoperative
language.<BR><BR>Regards,<BR>Mike<BR><BR>_______________________________________________<BR>PPML<BR>You
are receiving this message because you are subscribed to<BR>the ARIN
Public Policy Mailing List (ARIN-PPML@arin.net).<BR>Unsubscribe or manage
your mailing list subscription at:<BR><A
href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</A><BR>Please
contact info@arin.net if you experience any
issues.<BR><BR></FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>