<p dir="ltr">Mike,<br>
Operational need was also intended transfers per RFC 2050.</p>
<p dir="ltr">RFC 2050 section 4:</p>
<p dir="ltr">   7.  The transfer of IP addresses from one party to another must be<br>
       approved by the regional registries.  The party trying to obtain<br>
       the IP address must meet the same criteria as if they were<br>
       requesting an IP address directly from the IR.<br></p>
<p dir="ltr">___Jason</p>
<p dir="ltr">On Jun 3, 2013 7:43 PM, "Mike Burns" <<a href="mailto:mike@nationwideinc.com">mike@nationwideinc.com</a>> wrote:<br>
><br>
> Hi David,<br>
>  <br>
> All that is being demonstrated by your research below is that operational need was a principle of allocation of addresses *from the free pool*.<br>
> 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.<br>

>  <br>
> With a transfer market, pricing enforces conservation with the lightest touch from ARIN stewards.<br>
>  <br>
> 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?<br>

>  <br>
> 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. <br>

>  <br>
> I am opposed to 2013-4.<br>
>  <br>
> Regards,<br>
> Mike Burns<br>
>  <br>
>  <br>
>  <br>
>  <br>
>  <br>
> ----- Original Message -----<br>
>><br>
>> From: David Farmer<br>
>> To: William Herrin<br>
>> Cc: <a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
>> Sent: Monday, June 03, 2013 7:11 PM<br>
>> Subject: Re: [arin-ppml] Against 2013-4<br>
>><br>
>> On 6/3/13 15:52 , William Herrin wrote:<br>
>>><br>
>>> On Mon, Jun 3, 2013 at 4:24 PM, John Osmon <<a href="mailto:josmon@rigozsaurus.com">josmon@rigozsaurus.com</a>> wrote:<br>
>>>><br>
>>>> When (say) MIT asked for space, Class B was too small their needs and<br>
>>>> Class A was the only larger size available.  They didn't request a /8,<br>
>>>> they requested a netblock that fit their needs and got a Class A.  The<br>
>>>> needs assessment at the time was simply different.<br>
>>><br>
>>> Hi John,<br>
>>><br>
>>> Not exactly. IIRC (and the old fogies are free to correct me here) the<br>
>>> predecessor to IPv4 had exactly 256 addresses. When IPv4 was deployed,<br>
>>> each prior user was automatically assigned the /8 corresponding to<br>
>>> their prior address. MIT is one of the organizations which had a<br>
>>> computer using the prior Internet protocol, so they automatically<br>
>>> received a /8<br>
>><br>
>> 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 RFC 776 and RFC 790 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 RFC 790 and RFC 820, note several class As were assigned between these two RFCs.  Also, along the way through this series RFCs class As were assigned, RFC 1166 is I think the last RFC that documented address assignments in an RFC. <br>

>>><br>
>>> Very few /8's were assigned after that. Anybody who wanted more than a<br>
>>> class B received multiple class B's, not a class A.<br>
>><br>
>> Eventually, yes that was the case, and was definitely the case by the time RFC 1366 was published, However it was still technically possible to get a class A even then, look at Section 4.1. <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>
>> -- <br>
>> ================================================<br>
>> David Farmer               Email: <a href="mailto:farmer@umn.edu">farmer@umn.edu</a><br>
>> Office of Information Technology<br>
>> University of Minnesota   <br>
>> 2218 University Ave SE     Phone: 1-612-626-0815<br>
>> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952<br>
>> ================================================ <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">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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<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">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">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
</p>