|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: I T
Length: 29945 (0x74f9)
Types: TextFile
Names: »IDEA-INDEX-ABS.TXT.1«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦this⟧ »EurOpenD3/documents/nic.ddn.mil/IDEA-INDEX-ABS.TXT.1«
(updated 06/11/88)
The Internet Design, Engineering and Analysis noteS (IDEAS)
--- -------- ------- ----------- --- -------- ----- -------
The Internet Design, Engineering and Analysis noteS (IDEAS) are draft
documents of the Internet Engineering Task Force (IETF or INENG). IDEAS
are generally contributed by INENG Working Groups (or by individuals
participating in the INENG) on short- and mid-term issues in network,
internetwork and protocol engineering. However, thoughtful papers from
any responsible source on any related issue will be considered. The
INENG chairman is the nominal editor of the series and can be reached
by emailing to gross@gateway.mitre.org.
Since this is a draft document series, with the goal of giving wider
exposure to the technical issues, minimal editing has been done for
form or style. The basic format is the same as that of the Requests
For Comments (RFC's--published by ISI and the NIC), since some IDEAS
may ultimately be submitted as RFC's.
Constructive comments on all IDEAS are greatly encouraged. Such comments
can be addressed directly to the author or, preferably, can be expressed
in the INENG interest mailing list (ineng-interest@venera.isi.edu).
The current listing of IDEAS is below:
o IDEA0001-00.TXT - `The Internet Engineering Task Force', Phill Gross (Mitre)
(Not yet available)
Description of goals, history, charter and organization of
the Internet Engineering Task Force.
o IDEA0002-00.TXT - `A Comparison of "Link State" and "Distance Vector"
Routing Algorithms', Ross Callon (BBN)
From the document:
"Recently, there has been considerable work towards development
of new standard routing protocols both in ANSI task group X3S3.3
and in the Internet Engineering Task Force (IETF). The work in
ANSI on development of an intra-domain routing protocol is the
most fully developed of these efforts. The considerations
described in this paper are based largely on the work within ANSI,
as well as earlier work at BBN and elsewhere."
o IDEA0003-00.TXT - `Guidelines for the use of Internet-IP addresses in the
ISO Connectionless-Mode Network Protocol', Ross Callon
(BBN) and Hans-Werner Braun (U Mich)
This IDEA is a proposed revision of RFC986.
From the document:
"This RFC suggests a method to allow the existing IP addressing,
including the IP protocol field, to be used for the ISO
Connectionless Network Protocol (CLNP). This is a draft solution
to one of the problems inherent in the use of "ISO-grams" in the
DOD Internet. Related issues will be discussed in subsequent RFCs.
This RFC suggests a proposed protocol for the ARPA-Internet community,
and requests discussion and suggestions for improvements.
Distribution of this memo is unlimited.
This RFC has been revised in order to allow the addressing used
in the CLNP in the DOD Internet to be potentially useful for
routing in the context of a new inter-autonomous system routing
protocol, and in the context of large numbers of networks and
autonomous systems. This is important due to the rapid growth
currently being experienced in the Internet."
o IDEA0004-00.TXT - `Routing Information Protocol', Chuck Hedrick (Rutgers)
From the document:
"This IDEA describes a protocol for exchanging routing
information among gateways and other hosts. It is intended
to be used as a basis for developing gateway software for use
in the Internet community. This is a draft. It is being
circulated in order to solicit comments and suggestions for
improvement."
o IDEA0005-00.TXT - `Requirements for an Open Internal Gateway Protocol',
edited by John Moy (Proteon) for the Open IGP WOrking Group
This is the initial draft of a requirements paper from the
Open Interior Gateway Routing (IGP) Group. This paper deals
with routing within an administrative domain of gateways.
(This distinguishs it from IDEA0007-00 by the Open Routing group
which is concerned with routing between administrative domains
of gateways.)
From the document:
"This document states the requirements expected of the OIGP
Internal Routing Protocol). Also the specific non-goals of
the protocol are discussed, along with the general design
guidelines. Some design decisions (such as choosing an SPF
base) are not defended here due to lack of space and time."
o IDEA0006-00.TXT - `ISO Presentation Services on top of TCP/IP-based
Internets', Marshall Rose (TWG)
From the document:
"[RFC1006] describes a mechanism for providing the ISO transport
service on top of the Transmission Control Protocol (TCP)
[RFC793] and Internet Protocol (IP) [RFC791]. Once this method
is applied, one may implement "real" ISO applications on top of
TCP/IP-based internets, by simply implementing OSI session,
presentation, and application services on top of the transport
service access point which is provided on top of the TCP. Although
straight-forward, there are some environments in which the
richness provided by the OSI application layer is desired, but
it is nonetheless impractical to implement the underlying OSI
infrastructure (i.e., the presentation, session, and transport
services on top of the TCP). This IDEA describes an approach
for providing "stream-lined" support of OSI application services
on top of TCP/IP-based internets for such constrained environments."
o IDEA0007-00.TXT - `Requirements for Inter-Autonomous Systems Routing',
edited by Ross Callon (BBN) for the Open Routing Working
Group
This is the initial draft of a requirements paper from the
Open Routing Group. This paper deals with distributing
routing information between administrative domains of gateways.
(This distinguishs it from IDEA0005-00 by the Open IGP group which
is concerned with routing within an administrative domain of
gateways.)
From the document:
"This IDEA presents the draft requirements for Inter-Autonomous
Systems Routing. It is intended that these requirements will
form the basis for the future development of a new Inter-Autonomous
Systems Routing Architecture and Protocol. This draft is being
circulated to the IETF for comment. Distribution of this memo is
unlimited. Comments should be sent to: open-rout-editor@bbn.com."
o IDEA0008-00.TXT - `The Responsible Person Resource Record', edited by
Louis Mamakos (U of Md) for the Name Domain Working Group
From the document:
"The purpose of this RFC is to focus discussion on a particular
aspect of the domain name system described in RFCs 882, 883 and
973. An extension to the system is proposed to allow identification
of the person or persons responsible for an entity in the domain
name system."
o IDEA0009-00.TXT - `Exterior Gateway Protocol (EGP), Version 3', Marianne
Gardner (BBN) and Mike Karels (UCBerkeley)
From the document:
"EGP, as specified in RFC 904 and here, exists in order to
convey network-reachability information between neighboring
gateways, possibly in different autonomous systems. The protocol
includes mechanisms to acquire neighbors, monitor neighbor
reachability, and exchange network reachability information. The
protocol is based on periodic polling both to determine neighbor
reachability and to exchange network reachability information.
This document differs from RFC 904 in providing for version
negotiation and incremental routing updates and using
Poll/Updates as Hellos and IHYs. The finite state machine of RFC
904 is essentially unchanged. This paper directly addresses the
problem caused when growth of the Internet outpaced the size of a
single routing update by providing for incremental updates.
Version negotiation permits more extensive revisions to EGP in
the future, including a possible relaxation of the tree topology
restriction. Finally, this RFC addresses the problem of
excessive overhead traffic by combining Polls and Hellos, and
allowing Hellos to be Polls containing data. The elimination of
Hellos and IHYs should provide a dramatic reduction in the number
of messages exchanged in EGP interactions between gateways."
o IDEA0010-00.TXT - `A Laboratory For Testing DOD Protocol Implementations:
It's Architecture And Methodologies', John Swanson and
Jose Rodriguez (UNISYS McLean Research Center)
From the document:
"In the early 1980s, the Department of Defense (DoD) molded
a subset of the ARPA Internet into the Defense Data Network (DDN)
and issued Military Standards (MIL-STDs) for the ARPA Internet
protocol suite [...]
DoD standardization of the protocols brought the issue of
protocol testing into sharper focus. Historically, a protocol
implementation's compliance with the ARPA specifications was
often determined on an ad hoc basis using other known working
implementations on the ARPANET [....] On the DDN, however,
where protocol implementations are encouraged by the Defense
Communications Agency (DCA) to be compliant with the MIL-STDs,
DoD customers frequently must field implementations purchased
from third-party vendors. This situation prompted DCA to
establish a Protocol Laboratory to test vendor implementations of
the DoD protocols and certify their compliance to the standards.
Unisys Defense Systems has successfully developed this Protocol
Laboratory at the Defense Communications Engineering Center
(DCEC) in Reston, Virginia. Operational "clones" of the
Laboratory will soon be established at various sites around the
country as part of the National Bureau of Standards' (NBS)
National Voluntary Laboratory Accreditation Program (NVLAP)"
o IDEA0011-00.TXT - `A Simple Network Management Protocol',
Jeffrey Case (U of TN), Mark Fedor (NYSERnet Inc.),
Martin Schoffstall (RPI), and James Davin (Proteon Inc.)
From the document:
"This memo defines a simple protocol by which management
information for a network element may be inspected or altered
by logically remote users.
This proposal is an upwardly-compatible extension of the
Simple Gateway Monitoring Protocol [1], with four major
functional extensions: 1) the ability to do alterations (SETS)
within a standardized authentication protocol, 2) the support
of proxy commands by a centralized server, 3) significant
extensions to the variable space both for gateways and other
network elements. 4) the separation of trap processing to a
different UDP port."
o IDEA0011-01.TXT - `A Simple Network Management Protocol',
Jeffrey Case (U of TN), Mark Fedor (NYSERnet Inc.),
Martin Schoffstall (RPI), and James Davin (Proteon Inc.)
From the document:
"As reported in RFC 1052, IAB Recommendations for the Develop-
ment of Internet Network Management Standards [1], the Inter-
net Activities Board has directed the Internet Engineering
Task Force (IETF) to create two new working groups in the area
of network management. One group is charged with the further
specification and definition of elements to be included in the
Management Information Base (MIB). The other is charged with
defining the modifications to the Simple Network Management
Protocol (SNMP) to accommodate the short- term needs of the
network vendor and operations communities, and to align with
the output of the MIB working group.
The MIB working group has produced two memos, one which
defines a Structure for Management Information (SMI) [2] for
use by the managed objects contained in the MIB. A second
memo [3] defines the list of managed objects.
The output of the SNMP Extensions working group is this memo,
which incorporates changes to the initial SNMP definition [4]
required to attain alignment with the output of the MIB work-
ing group. The changes should be minimal in order to be con-
sistent with the IAB's directive that the working groups be
"extremely sensitive to the need to keep the SNMP simple."
Although considerable care and debate has gone into the
changes to the SNMP which are reflected in this memo, the
resulting protocol is not backwardly-compatible with its
predecessor, the Simple Gateway Monitoring Protocol (SGMP)
[5]. Although the syntax of the protocol has been altered,
the original philosophy, design decisions, and architecture
remain intact. In order to avoid confusion, new UDP ports
have been allocated for use by the protocol described in this
memo."
o IDEA0012-00.TXT - 'Network Management for TCP/IP Network: An Overview',
A. Ben-Artzi (Sytek)
From the document:
"This paper describes a model of network management that
includes the services and protocols required for building a
network management system (NMS). While the management appli-
cations themselves are not included in the scope of this work,
the model provides all the tools required by a developer to
develop such applications. Applications are explicitly left
as a competitive issue for network developers and providers.
As will become evident, security issues and multiple- manage-
ment domains are not covered by this architecture. The impor-
tance of these issues is well recognized, and should be
covered in subsequent documents.
The services and protocols defined by the NMS are proposed as
standard tools to be implemented in the Internet, as well as
the commercial TCP/IP community, in order to achieve uniform
management capability in a multi-vendor environment.
As the network management system proposed here is based on ISO
standards, the reader is assumed to be familiar with CMIS/CMIP
and ACSE."
o IDEA0013-00.TXT - 'Structure and Identification of Management
Information for the Internet', Lee LaBarre (MITRE)
From the document:
"This memorandum describes the common structures and
identification scheme for the definition of manage-
ment information used in managing the TCP/IP Internet with
the ISO network management models and protocols.
Included are descriptions of an object information
model for network management, and ASN.1 notational conven-
tions and a set of generic types used to describe management
information. It defines the semantics of the operations
associated with the management information, and the
abstract syntax and encodings used for its transfer."
o IDEA0014-00.TXT - `Kerberos Authentication and Authorization System',
S. P. Miller, B. C. Neuman, J. I. Schiller, and
J. H. Saltzer (all of MIT)
From the document:
"This document describes the assumptions, short and
long term goals, and system model for a network authentica-
tion system, named Kerberos, for the Athena environment.
An appendix specifies the detailed design and proto-
cols to support these goals, and a set of UNIX manual
pages, not included here, describes an implementation
for Berkeley 4.3 UNIX of both user interface commands and
also library interfaces for clients and servers. The
next section of the technical plan, E.2.2, describes a set
of network applications that use Kerberos for authentica-
tion.
Most conventional time-sharing systems require a
prospective user to identify him or herself and to authenti-
cate that identity before using its services. In an
environment consisting of a network that connects pros-
pective clients with services, a network service has a
corresponding need to identify and authenticate its
clients. When the client is a user of a time-sharing sys-
tem, one approach is for the service to trust the
authentication that was performed by the time-sharing sys-
tem. For example, the network applications lpr and rcp pro-
vided with Berkeley 4.3 UNIX trust the user's time-sharing
system to reliably authenticate its clients.
In contrast with the time-sharing system, in which
a protection wall separates the operating system from its
users, a workstation is under the complete control of its
user, to the extent that the user can run a private version
of the operating system, or even replace the machine itself.
As a result, a network service cannot rely on the
integrity of the workstation operating system when it (the
network service) performs authentication.
This plan extends the conventional notions of
authentication, authorization, and accounting to the
network environment with untrusted workstations. It estab-
lishes a trusted third-party service named Kerberos that
can perform authentication to the mutual satisfaction of
both clients and services. The authentication approach
allows for integration with authorization and account-
ing facilities. The resulting design is also applicable to
a mixed time-sharing/network environment in which a net-
work service is not willing to rely on the authentica-
tion performed by the client's time-sharing system."
1
UNIX is a trademark of AT&T Bell Laboratories
o IDEA0015-00.TXT - `Host Extensions for IP Multicasting',
S. E. Deering (Stanford)
From the document:
"This memo specifies the extensions required of a host
implementation of the Internet Protocol (IP) to support
multicasting. It is proposed as a standard for IP multi-
casting in the ARPA-Internet. This specification is a major
revision of RFC-988; changes from RFC-988 are listed in an
Appendix."
o IDEA0016-00.TXT - `TELNET LOCALEDIT OPTION', Dave Borman (Cray Research)
From the document:
"This RFC describes a proposed standerd for doing Line mode
TELNET. It has unlimited distribution for discussion pur-
poses. After the first round of discussion, values for the
options will be requested from the NIC.
With increasing TELNET usage, it has become apparent that the
ability to do command line processing on the local machine and
send completed lines to the remote machine is a feature neces-
sary in several environments. First, in the case of a connec-
tion over long delay equipment, it is very frustrating to the
user to have the echoing of his data take several seconds.
Second, some supercomputers, due to their nature, are not good
at handling and processing single character input. For these
machines, it is better to have the front end computer do the
character processing, and leave the supercomputer's cycles
available for doing vectorized number crunching.
After examining several implementations, it has become clear
that the correct thing to do is to implement new options to
enhance the current TELNET specification so that it can sup-
port local line editing in a reasonable, reliable, and con-
sistent manner."
o IDEA0017-00.TXT - `ISO Presentation Services on top of TCP/IP-based
Internets', Marshall T Rose (The Wollongong Group)
From the document:
"[RFC1006] describes a mechanism for providing the ISO tran-
sport service on top of the Transmission Control Protocol
(TCP) [RFC793] and Internet Protocol (IP) [RFC791]. Once this
method is applied, one may implement "real" ISO applications
on top of TCP/IP-based internets, by simply implementing OSI
session, presentation, and application services on top of the
transport service access point which is provided on top of the
TCP. Although straight-forward, there are some environments in
which the richness provided by the OSI application layer is
desired, but it is nonetheless impractical to implement the
underlying OSI infrastructure (i.e., the presentation, ses-
sion, and transport services on top of the TCP). This memo
describes an approach for providing "stream-lined" support of
OSI application services on top of TCP/IP-based internets for
such constrained environments."
o IDEA0018-00.TXT - `System Load', Inder Sidhu, N Arunkumar (Bridge
Communications)
From the document:
"Loading files for software distribution is a frequently per-
formed function that falls under the purview of network
management. This RFC proposes a standard to perform this func-
tion for the Internet community, and requests discussion and
suggestions. It is one of a set of RFCs created by the NETMAN
working group of the IETF for management of the TCP/IP Inter-
net. This draft version of the RFC is being submitted as an
IDEA. It contains two proposals, of which only one is to be
adopted and included in the final RFC.
Nodes on a network may require a portion of their local
address space to be loaded using information held on a remote
node. Standardized mechanisms to achieve this functionality
are desirable in multi-vendor networks. This RFC proposes a
standard to be used for performing system load. Heterogeneous
systems that use the standard can then load each other.
The standard proposed here derives from the IEEE 802.1 System
Load Protocol [9]. The RFC, however, also takes into account
previous work in the Internet community in this area
(BOOTP/TFTP, etc. [2, 3, 8]). As far as possible, compatibil-
ity with the past is maintained, and future ISO orientation is
pursued."
o IDEA0019-00.TXT - `Multi-Homed Hosts in an IP Network', J. Lekashman (NASA
Ames GE)
From the document:
"A multi-homed host is a computer system which has more than
one network interface. It is distinguished from a gateway in
that the requirements placed upon a multi-homed host are for
servicing requests for network resources with itself as desti-
nation or source, whereas the requirements placed upon a gate-
way are for servicing transit traffic.
This is not to conclude that a given computer system cannot
have both gateway and multi-homed host characteristics. The
characteristics of a gateway are outlined in RFC 1009 [1].
This is intended to show that configuration requirements are
for multi-homed host and gateway behavior are different, and
how this should be handled by a host. Some of the ideas
presented are applicable to gateways also, especially in the
area of multiple interfaces on the same network."
o IDEA0020-00.TXT - `Comparison to the DEC IS-IS Proposal', J. Moy (Proteon)
From the document:
"The Open SPF-based Internal Gateway Protocol (OSPFIGP) is an
internet routing protocol currently in the design stage. It
will draw on existing SPF routing technology, notably the work
done by BBN for the Arpanet and the DEC IS-IS ANSI pro-
posal. We will refer to the DEC IS-IS ANSI Proposal [DEC]
as the ANSI proposal throughout this paper. Since both the
OSPFIGP and the ANSI proposal are IS-IS routing protocols
they will be quite similar. This paper describes the expected
differences between the two protocols. We assume the reader
is familiar with the ANSI proposal."
o IDEA0021-00.TXT - `EGP and Policy Based Routing in the New NSFNET Backbone',
Jacob Rehkter (IBM)
From the document:
"The NSFNET backbone routes packets between the Regionals
Networks to which it is connected, i.e., the packets arriving
at a backbone entry node are routed to an exit node. How they
travel through the network is determined by two components:
the NSFNET backbone routing protocol/algorithm and
additional information about the externally connected
networks
This paper is concerned with how reachability information
between the external networks and the NSFNET backbone
is exchanged so that packets can be routed to the correct
destination by using a reasonable path."
o IDEA0022-00.TXT - `The NSFNET Routing Architecture', Hans-Werner Braun
(MERIT)
From the document:
"This document describes the routing architecture for the
NSFNET centered around the new NSFNET Backbone, with specific
emphasis on the interface between the backbone and its
attached networks. It reflects and augments thoughts
described in (1), discussions during the Internet
Engineering Task Force meeting at the San Diego
Supercomputing Center in March 1988, discussions on mail-
ing lists, especially on a backbone/regional network working
group mailing list, and a final discussion held at the IBM
T.J. Watson Research Center in Yorktown, NY, on the 21st of
March 1988. The Yorktown meeting was attended by
Hans-Werner Braun (Merit), Scott Brim (Cornell Univer-
sity), Mark Fedor (NYSERNet), Jeff Honig (Cornell Univer-
sity), and Jacob Rekhter (IBM). Thanks also to them, Milo
Medin (NASA), John Moy (Proteon) and Greg Satz (Cisco) for
discussing this document by email and/or phone.
Understanding of (1) is highly recommended prior to read-
ing this document."
o IDEA0023-00.TXT - `Structure and Identification of Management Information
for TCP/IP based internets', Marshall T. Rose, Keith
McCloghrie (both of The Wollongong Group)
From the document:
"This memo describes the common structures and identification
scheme for the definition of management information used in
managing TCP/IP-based internets. Included are descriptions of
an object information model for network management along with
a set of generic types used to describe management informa-
tion. Formal descriptions of the structure are given using
Abstract Syntax Notation One (ASN.1) [1].
This memo is largely concerned with organizational concerns
and administrative policy: it neither specifies the objects
which are managed, nor the protocols used to manage those
objects. These concerns are addressed by two companion memos:
one describing the Management Information Base (MIB) [2], and
the other describing the Simple Network Management Protocol
(SNMP) [3].
This memo is based in part on IETF IDEA 13, Structure and
Identification of Management Information for the Internet [4].
This memo uses a skeletal structure derived from IDEA 13, but
differs in one very significant way: IDEA 13 focuses entirely
on the use of OSI-style network management. As such, it is
not suitable for use in the short-term for which a non-OSI
protocol, the SNMP, has been designated as the standard."
o IDEA0024-00.TXT - 'Management Information Base for Network Management
of TCP/IP-based internets', K. McCloghrie, M.T. Rose
(both of The Wollongong Group)
This document proposes a standard for the Internet community.
From the document:
"This memo provides the initial version of the Management
Information Base (MIB) for use with network management proto-
cols in TCP/IP-based internets in the short-term. In particu-
lar, together with its companion memos which describe the
structure of management information along with the initial
network management protocol, these documents provide a simple,
workable architecture and system for managing TCP/IP-based
internets and in particular the DARPA/NSF Internet.