[ih] IENs

Tue Apr 15 16:48:19 PDT 2025

Hmmm.  I just searched for "IEN 1" on the 'net and found IENs, starting 
with #1 in July 1977, listed today at rfc-editor.org - although the 
early ones I checked sometimes said "not available" or "contact author 
for a copy".

Some of the very early IENs (1-20 or so) I don't think I ever saw until 
today.   Of course we didn't have the Web or Search Engines in 1977 so 
maybe I just never encountered them.  The Internet really has changed 
the world and how we access information.

Other documentation of that era had limited distribution.  I recall a 
lot of QTRs capturing the work on Internet projects were distributed 
within the group that did the work as well as a small collection of 
government recipients at ARPA, DCA, and a few others.

For example, the Packet Radio work at BBN was done in a different 
Division from the one I was in, and their documents and ours didn't get 
widely distributed across the boundary.  I knew Packet Radio was 
happening in the other building at BBN, but not much of the details.  If 
you asked a friend you could probably get a copy of a report or borrow 
one and copy it.   But it didn't come automatically.   I suspect the 
researchers in the other Division had a similar experience with our work.

It was probably possible, but more difficult, to get a copy of documents 
from other members of the research community (MIT, UCLA, USC, NDRE, SRI, 
RSRE, UCL, Linkabit, UDel, Collins, etc.), but only if you knew the 
document existed.   Same for other related corporate activities, e.g., 
at PARC, Novell, etc.   Everything, especially documents with any 
graphics, pretty much travelled on paper then.

I don't remember ever having an encounter involving "your contract will 
be cancelled".

But there was significant concern in the computing world at the time 
over trade secrets and competitive advantage.  For example, when I 
agreed to work on implementing TCP for Unix, I had to sign some NDA 
document agreeing not to disclose anything about the internal design or 
mechanisms used within the Unix kernel, which ATT was protecting as a 
work product of Bell Labs.    I somehow found a document from University 
of Woolongong that described the basic structure of the Unix kernel, 
which really helped in implementing TCP.  I guessed Australia was out of 
reach of the corporate lawyers.

Someone in the government also told me once, long ago, that documents 
got loaded into DTIC only if someone in the government on the original 
distribution list made the explicit effort to send that document to DTIC 
for archiving.  That probably explains why only some of the documents, 
even ones that I remember writing, are in DTIC today.   I've tried 
searching on DTIC for early documents of Packet Radio, SATNET, and 
others but was mostly unsuccessful. Perhaps I just haven't found the 
right search term yet.

I can't recall - circa 1977 were IENs available on SRI-NIC like RFCs and 
other such core documents were at that time?  If not, anybody remember 
why not?  Perhaps SRI-NIC just wasn't on the distribution list?

/Jack

On 4/15/25 14:51, vinton cerf via Internet-history wrote:
> who ever that DARPA official might have been, it was NOT me.
>
> v
>
>
> On Tue, Apr 15, 2025 at 4:50 PM Alexander McKenzie via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>>   Folks,
>>
>> IENs are available to everyone these days, but back at the time they were
>> being written they were on a strictly-enforced limited distribution.  For
>> example, a DARPA official told one PI at BBN that his contract would be
>> cancelled if the IEN's he received leaked into the possession of another PI
>> at BBN. Therefore it is not surprising that IEN's were rarely referenced by
>> other documents.
>>
>> Cheers,
>> Alex
>>
>> On Monday, April 14, 2025 at 07:22:39 PM EDT, Greg Skinner via
>> Internet-history<internet-history at elists.isoc.org>  wrote:
>>
>>
>> On Apr 12, 2025, at 11:33 AM, Jack Haverty via Internet-history <
>> internet-history at elists.isoc.org> wrote:
>>> The 1980s era of The Internet was explicitly a time of research and the
>> "Internet Experiment".    We tried to reflect that in the documents of the
>> day, such as RFC793.
>>> The general principle was that the "on the wire" formats and meanings
>> were standardized, so that any implementation of TCP could communicate with
>> any other implementation.  Everything else was at best Recommendations.
>>> However, there were a lot of unanswered questions, such as the best way
>> to deal with network errors such as dropped, duplicated, or mangled
>> datagrams - such as discussed in IEN69.
>>> To enable research into different techniques, the specific algorithms for
>> TCP functions such as retransmission timers and strategies were explicitly
>> *not* standardized.    That encouraged experimentation with different kinds
>> of network environments and different ideas about how to cope with errors.
>> It also permitted implementations of TCP with different goals.  An
>> implementer might pursue algorithms which minimized the load on their
>> computer system.  Or load on the network.  Or rapidity of implementation.
>> Or suitability for the specific user environment involved.  Or ...
>>> No one in 1981 had any significant experience with real-world TCP
>> networks and their behavior under heavy loads.  The ARPANET was the basic
>> wide-area network in use as the substrate for The Internet, and the ARPANET
>> provided only a reliable byte-stream service that made greatly simplified
>> TCP's task.
>>> IEN 177 says that the RSRE algorithm is the "current best procedure" and
>> "will be included in the next ... specification".  I remember talking with
>> Jon and others about this.  My recollection is that such an algorithm might
>> be included as a "best practice" recommendation, not as a mandatory part of
>> the standard.  In 1981 we simply didn't know enough to nail down an
>> algorithm and there were lots of other outstanding unresolved issues that
>> might be related (such as Type Of Service, Policy Routing, etc.).
>>> In 1981, The Internet was still very much an Experiment, but being pulled
>> forward by its adoption as a DoD Standard, and later to be rocketed forward
>> by its adoption in non-military networking.  I think many of those research
>> questions were never answered.  I recall we even at one point we even
>> opined that The Internet would be fine as long as we kept enough capacity
>> in the circuits and switches to avoid overloads, while the research
>> continued, seeking the "right" answers.
>>> Jack Haverty
>> OK, that seems reasonable.  I did a little more digging, and found that IEN
>> 50 provides some “glue” by comparing some retransmission algorithms, using
>> simulations and analytical techniques to arrive at some conclusions. [1]
>> It seems unfortunate to me that some of these IENs couldn’t have been
>> included as references in RFC 793.  But as far as supporting (higher packet
>> loss) military networking went, some of these concerns (in theory) could
>> have been addressed in MIL-STD-1778 [2].  Does anyone know why they
>> weren’t? The US DoD sent people to those Internet Meetings from the late
>> 1970s and early 1980s, so (in theory) they had enough information to
>> incorporate any additional requirements into the military standard for TCP.
>>
>> --gregbo
>>
>> [1]https://www.rfc-editor.org/ien/scanned/ien50.pdf
>> [2]http://everyspec.com/MIL-STD/MIL-STD-1700-1799/MIL-STD-1778_6676/
>>
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250415/c365ebf9/attachment-0001.asc>