[arin-ppml] Against 2013-4

[David Farmer]

On 6/3/13 15:52 , William Herrin wrote:
> On Mon, Jun 3, 2013 at 4:24 PM, John Osmon <josmon at rigozsaurus.com> wrote:
>> 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.
> 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
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.

Comparing RFC 776 <http://tools.ietf.org/html/rfc776> and RFC 790 
<http://tools.ietf.org/html/rfc790> 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 
<http://tools.ietf.org/html/rfc790> and RFC 820 
<http://tools.ietf.org/html/rfc820>, note several class As were assigned 
between these two RFCs.  Also, along the way through this series RFCs 
class As were assigned, RFC 1166 <http://tools.ietf.org/html/rfc1166> is 
I think the last RFC that documented address assignments in an RFC.
> 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.
Eventually, yes that was the case, and was definitely the case by the 
time RFC 1366 <http://tools.ietf.org/html/rfc1366> was published, 
However it was still technically possible to get a class A even then, 
look at Section 4.1 <http://tools.ietf.org/html/rfc1366#section-4.1>.

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"?

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"

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.


-- 
================================================
David Farmer               Email: farmer at umn.edu
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
================================================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130603/fba06b7c/attachment.htm>