<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<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>
</body>
</html>