<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=ISO-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.23487">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff text=#000000>
<DIV><FONT size=2 face=Arial>Hi David,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>All that is being demonstrated by your 
research below is that operational need was a principle of allocation of 
addresses *from the free pool*.</FONT></DIV>
<DIV><FONT size=2 face=Arial>And that makes perfect sense to everybody. You had 
to have some means to fairly distribute the addresses, and the lightest touch of 
the steward would be to just give them away for free to anyone. Of course that 
would allow anybody to claim all the addresses, so the lightest workable touch 
then became giving them away for free to anyone who needed them. And that's what 
we have done, and it has served us well.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>With a transfer market, pricing enforces 
conservation with the lightest touch from ARIN stewards. </FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The whole point here is that RFC2050 is outdated, 
right? I agree- it was the product of a mindset which did not conceive of a life 
after the free pool exhausts. There is no concept of a transfer market in 
RFC-2050, so why draw the inference that the principle of conservation of free 
pool addresses should be extended to transfers?</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>The purpose of a market is to allocate scarce 
resources.  It does this through pricing the resource. Now that we have 
this conservation force working for us, it is our responsibility as stewards to 
step back, pat ourselves on the back for a job well done with the free pool 
allocations, and concentrate our resources on our primary role as 
registrars.  This means we do not create or maintain policies that provide 
an incentive for transfers to occur which are not booked in Whois, such as 
need tests for transfers. </FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I am opposed to 2013-4.</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 Burns</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV>----- Original Message ----- </DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV 
  style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> 
  <A title=farmer@umn.edu href="mailto:farmer@umn.edu">David Farmer</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=bill@herrin.us 
  href="mailto:bill@herrin.us">William Herrin</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Cc:</B> <A title=arin-ppml@arin.net 
  href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, June 03, 2013 7:11 PM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [arin-ppml] Against 
  2013-4</DIV>
  <DIV><BR></DIV>
  <DIV class=moz-cite-prefix>On 6/3/13 15:52 , William Herrin wrote:<BR></DIV>
  <BLOCKQUOTE 
  cite=mid:CAP-guGWCmn+wduZ=zotzFiJxcDn5O0vya0nZ=tJdcKXhDGc07A@mail.gmail.com 
  type="cite"><PRE wrap="">On Mon, Jun 3, 2013 at 4:24 PM, John Osmon <A class=moz-txt-link-rfc2396E href="mailto:josmon@rigozsaurus.com>"><josmon@rigozsaurus.com></A> wrote:
</PRE>
    <BLOCKQUOTE type="cite"><PRE wrap="">When (say) MIT asked for space, Class B was too small their needs and
Class A was the only larger size available.  They didn't request a /8,
they requested a netblock that fit their needs and got a Class A.  The
needs assessment at the time was simply different.
</PRE></BLOCKQUOTE><PRE wrap="">Hi John,

Not exactly. IIRC (and the old fogies are free to correct me here) the
predecessor to IPv4 had exactly 256 addresses. When IPv4 was deployed,
each prior user was automatically assigned the /8 corresponding to
their prior address. MIT is one of the organizations which had a
computer using the prior Internet protocol, so they automatically
received a /8</PRE></BLOCKQUOTE>I'm not really an old fogie, at least I don't 
  think I am.  However, since I work for an organization with significant 
  Legacy resources, I've done a bit of research looking through the RFCs that 
  document the earliest IPv4 assignments, including several for my employer. 
    See, RFCs 790, 820, 870, 900, 923, 943, 960, 990, 997, 1020, 
  1166.  <BR><BR>Comparing <A href="http://tools.ietf.org/html/rfc776">RFC 
  776</A> and <A href="http://tools.ietf.org/html/rfc790">RFC 790</A> it is easy 
  to infer what you say is what happened in MIT's case, and a few others.  
  However, John is also right, if you demonstrated need you could get a class A, 
  at least for a some while.  This can also be inferred by comparing <A 
  href="http://tools.ietf.org/html/rfc790">RFC 790</A> and <A 
  href="http://tools.ietf.org/html/rfc820">RFC 820</A>, note several class As 
  were assigned between these two RFCs.  Also, along the way through this 
  series RFCs class As were assigned, <A 
  href="http://tools.ietf.org/html/rfc1166">RFC 1166</A> is I think the last RFC 
  that documented address assignments in an RFC. <BR>
  <BLOCKQUOTE 
  cite=mid:CAP-guGWCmn+wduZ=zotzFiJxcDn5O0vya0nZ=tJdcKXhDGc07A@mail.gmail.com 
  type="cite"><PRE wrap="">Very few /8's were assigned after that. Anybody who wanted more than a
class B received multiple class B's, not a class A.</PRE></BLOCKQUOTE>Eventually, 
  yes that was the case, and was definitely the case by the time <A 
  href="http://tools.ietf.org/html/rfc1366">RFC 1366</A> was published, However 
  it was still technically possible to get a class A even then, look at <A 
  href="http://tools.ietf.org/html/rfc1366#section-4.1">Section 4.1</A>. 
  <BR><BR>Finally, as was pointed out earlier, operational need was required for 
  all assignments.  It was noted that even for a class C you had to 
  estimate how many hosts were going to be connected, initially, and at one, two 
  and five years.  As a thought experiment, what do you think John Postel 
  would have said, if you answered that question with zero(0), especially for 
  the one, two and five year parts of the question.  Do you think it might 
  have been "come back later"? <BR><BR>The bar was low, but there was a bar even 
  for class Cs, and that bar was that you were going to use them in a network, 
  "operational need"<BR><BR>Therefore, I believe operational need is a principle 
  that MUST be included.  There are valid policy questions of what the 
  proper measure of operational need for the current times and current protocols 
  are.  I believe the measure of operational need will properly change over 
  time, and for IPv4 such a time is likely here or upon us very soon.  But, 
  a principle that assignments or allocations are made for operational need is 
  valid and technically necessary.  Equally, we need policies and procedure 
  that interpret this principle in the light of today's protocols and 
  operational realities, is also valid and necessary, and the whole point of 
  documenting operational need as principle.<BR><BR><BR><PRE class=moz-signature cols="72">-- 
================================================
David Farmer               Email: <A class=moz-txt-link-abbreviated href="mailto:farmer@umn.edu">farmer@umn.edu</A>
Office of Information Technology
University of Minnesota   
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================ </PRE>
  <P>
  <HR>

  <P></P>_______________________________________________<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>http://lists.arin.net/mailman/listinfo/arin-ppml<BR>Please 
  contact info@arin.net if you experience any issues.</BLOCKQUOTE></BODY></HTML>