Index of available documents
mdavies@NRI.Reston.VA.US Wed, 24 October 1990 17:17 UTC
Received: from nri by NRI.NRI.Reston.VA.US id aa08646; 24 Oct 90 13:17 EDT
To: stevef@galadriel.bt.co.uk
cc: smds-request@NRI.Reston.VA.US
Subject: Index of available documents
Date: Wed, 24 Oct 1990 13:15:58 -0400
From: mdavies@NRI.Reston.VA.US
Message-ID: <9010241317.aa08646@NRI.NRI.Reston.VA.US>
Steve,
Hope this answers your questions, and I apologize for the delay.
Megan
----------
Current Internet Drafts
This summary sheet provides a short synopsis of each Internet Draft
available within the ``Internet-Drafts'' Directory at the NIC and NNSC.
``Assignment/Reservation of Internet Network Numbers for the
PDN-Cluster'', Carl-Herbert Rokitansky, 06/01/1989
<draft-ietf-pdn-pdnclusternetassignm-00.txt>
``Application of the Cluster Addressing Scheme to X.25 Public Data
Networks'', Carl-Herbert Rokitansky, 08/01/1989
<draft-ietf-pdn-pdncluster-00.txt>
``The Authentication of Internet Datagrams'', Jeff Schiller, 08/01/1989
<draft-ietf-auth-ipauthoption-00.txt>
This draft RFC describes a protocol and IP option to allow two
communicating Internet hosts to authenticate datagrams that
travel from one to the other. This authentication is limited
to source, destination IP address pair. It is up to host-based
mechanisms to provide authentication between separate processes
running on the same IP host. The protocol will provide for
``authentication'' of the datagram, not concealment from third
party observers. By authentication, I mean that an IP host
receiving a datagram claiming to be from some other IP host
will be able (if both hosts are set up to authenticate
datagrams between each other) to determine if in fact the
datagram is from the host claimed, and that it has not been
altered in transit.
``Internet Cluster Addressing Scheme'', Carl-Herbert Rokitansky,
11/01/1989
<draft-ietf-pdn-clusterscheme-00.txt>
``OSI Connectionless Transport Services on top of the UDP: Version 1'',
C. Shue, W. Haggerty, K. Dobbins, 11/01/1989
<draft-osf-shue-osiudp-00.txt>
This draft proposes a method for offering the OSI
connectionless transport service (CLTS) in TCP/IP-based
Internets by defining a mapping of the CLTS onto the User
Datagram Protocol (UDP). If this draft becomes a standard,
hosts on the Internet that choose to implement OSI
connectionless transport services on top of the UDP would be
expected to adopt and implement the methods specified in this
draft. UDP port 102 is reserved for hosts which implement this
draft. Distribution of this memo is unlimited.
1
``The Knowbot Information Service'', Ralph Droms, 12/01/1989
<draft-nri-droms-kis-00.txt and .ps>
Within the metanetwork of networks that exchange electronic
mail, there are many directory services that provide partial
coverage of network users; that is, directories with
information about some subset of a particular network's user
population. Searching the collection of available directories
is time-consuming and requires knowledge of each directory's
user interface. Although X.500 is currently under study as a
basis for an Internet-wide directory service, it is unlikely
that a universal user registry will be in place in the near
future. The Knowbot Information Service provides a uniform
interface to heterogeneous directory services that simplifies
the task of locating users in the combined network.
``IP Routing Between U.S. Government Agency Backbones and Other
Networks'', Scott Brim, 01/01/1990
<draft-fricc-brim-BackboneRouting-01.txt>
This is an overview of how the agency backbones route IP
(Internet Protocol) packets at this time, with any
generalizations that can be made and statements of their
differences. Also included are recommendations from the agency
backbones about how other networks that connect to them can
best set up their inter-administration routing.
``Implementation Agreements for Transport Service Bridges'', M.T. Rose,
01/01/1990
<draft-ietf-rose-tsbridge-00.txt>
This draft reports implementation experience when building
transport service bridges for OSI applications.
``A String Encoding of Presentation Address'', S.E. Kille, 01/31/1990
<draft-ucl-kille-presentationaddress-00.ps>
There are a number of Environments where a simple string
encoding of Presentation address is desirable. This
specification defines such a representation.
``An Interim Approach to use of Network Addresses'', S.E. Kille,
01/31/1990
<draft-ucl-kille-networkaddresses-00.ps>
2
The OSI Directory specifies an encoding of Presentation
Address, which utilizes OSI Network Addresses as defined in the
OSI Network Layer Standards. The OSI Directory, and any OSI
application utilizing the OSI Directory must be able to deal
with these Network Addresses. Currently, most environments
cannot cope with them. It is not reasonable or desirable for
groups wishing to investigate and use OSI Applications in
conjunction with with the OSI Directory to have to wait for the
lower layers to sort out. This note is a proposal for
mechanisms to utilize Network Addresses.
This document specifies an addressing convention to be used in
conjunction with other protocols.
``X.500 and Domains'', S.E. Kille, 01/31/1990
<draft-ucl-kille-x500domains-00.ps>
This document considers X.500 in relation to Internet/UK
Domains. A basic model of X.500 providing a higher level and
more descriptive naming structure is proposed, which gives a
range of new management and user facilities over and above
those currently available.
``An Architecture for Inter-Domain Policy Routing'', Marianne Lepp,
Martha Steenstrup, 02/20/1990
<draft-ietf-orwg-architecture-01.ps>
We present an architecture for policy routing among
administrative domains within the Internet. The objective of
inter-domain policy routing is to synthesize and maintain
routes between source and destination administrative domains,
providing user traffic with the
requested service within the constraints stipulated by the
administrative domains transited. The architecture is designed
to accommodate an Internet with tens of thousands of
administrative domains.
``Managing Asynchronously Generated Alerts'', Louis Steinberg,
03/28/1990
<draft-ietf-alertman-asyncalertman-02.txt>
This draft defines mechanisms to prevent a remotely managed
entity from burdening a manager or network with an unexpected
amount of network management information, and to ensure
delivery of ``important'' information. The focus is on
controlling the flow of asynchronously generated information,
and not how the information is generated. Mechanisms for
generating and controlling the generation of asynchronous
information may involve protocol specific issues.
3
There are two understood mechanisms for transferring network
management information from a managed entity to a manager;
request-response driven polling, and the unsolicited sending of
``alerts''. Alerts are defined as any management information
delivered to a manager that is not the result of a specific
query. Advantages and disadvantages exist within each method.
This draft discusses these in detail.
``Telnet Encryption Option'', Dave Borman, 04/01/1990
<draft-ietf-telnet-encryption-00.txt>
``Definitions of Managed Objects for the T1 Carrier Interface Type'', C
Kolb, Fred Baker, 09/26/1990
<draft-ietf-snmp-t1mib-01.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
objects for managing T1-carrier objects.
``Telnet Data Compression Option'', Dave Borman, 04/30/1990
<draft-ietf-telnet-compression-00.txt>
``A Proposed Standard for the Transmission of IP Datagrams over FDDI
Networks'', Dave Katz, 05/05/1990
<draft-ietf-fddi-ipdatagrams-01.txt>
The goal of this specification is to allow compatible and
interoperable implementations for transmitting IP datagrams and
ARP requests and replies over FDDI networks.
``Working Implementation Agreements On Network Management Functions,
Services and Protocols'', Robert Aronoff, 05/24/1990
<draft-nist-nmsig-implagreements-00.txt>
This is the Working Document of the Network Management Special
Interest Group (NMSIG) of the OSI Implementors Workshop (OIW).
The OSI Internet Management (OIM) Working Group agreements on
CMIS/CMIP reference this document.
``The Common Management Information Services and Protocols for the
Internet (CMOT and CMIP)'', U. Warrier, L. Besaw, B.D. Handspicker L.
LaBarre, 05/30/1990
<draft-ietf-oim-cmot-00.txt>
4
This memo is the output of the OSI Internet Management Working
Group. As directed by the IAB in RFC 1052, it addresses the
need for a long-term network management system based on ISO
CMIS/CMIP. This memo contains a set of protocol agreements for
implementing a network management system based on these ISO
Management standards. Now that CMIS/CMIP has been voted an
International Standard (IS), it has become a stable basis for
product development. This profile specifies how to apply CMIP
to management of both IP-based and OSI-based Internet networks.
Network management using ISO CMIP to manage IP-based networks
will be refered to as ``CMIP Over TCP/IP'' (CMOT). Network
management using ISO CMIP to manage OSI-based networks will be
refered to as ``CMIP''. This memo specifies the protocol
agreements necessary to implement CMIP and accompanying ISO
protocols over OSI, TCP and UDP transport protocols.
``Management Information Base for LAN Manager Alerts'', Jim Greuel,
Amatzia BenArtzi, 06/30/1990
<draft-ietf-lanman-alerts-00.txt>
This memo is a product of the IETF Lan Manager MIB Working
Group. It defines management objects to support the
translation of LAN Manager alerts to SNMP traps. It is a
companion document to Management Information Base for LAN
Manager Management, which defines a base set of management
objects for LAN Manager.
``Management Information Base for LAN Manager Management'', Jim Greuel,
Amatzia BenArtzi, 06/30/1990
<draft-ietf-lanman-mib-00.txt>
This memo provides a Management Information Base (MIB) for
management of LAN Manager nodes with TCP/IP-based network
management protocols. Together with documents describing the
structure of management information (RFC 1155) and the Simple
Network Management Protocol (RFC 1157) this document provides a
specification for managing LAN Manager nodes in a TCP/IP
environment.
``Authentication and Privacy in the SNMP'', James Galvin, Keith
McCloghrie, James Davin, 07/05/1990
<draft-ietf-snmpauth-authsnmp-02.txt>
The Simple Network Management Protocol (SNMP) specification
allows for the authentication of network management operations
by a variety of authentication algorithms. This memo specifies
alternatives to the trivial authentication algorithm. It also
describes an abstract Authentication Service Interface (ASI) by
5
which SNMP-based management applications or agents may--in a
convenient and uniform way--benefit from the algorithms
described here and a wide range of others. The terms of the
ASI are used to describe three distinct algorithms, including
one with support for privacy.
``Experimental Definitions of Managed Objects for Administration of
SNMPCommunities'', Keith McCloghrie, James Davin, James Galvin,
07/05/1990
<draft-ietf-snmpauth-manageobject-02.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it
describes a representation of the authentication communities
defined in the companion memo: Authentication and Privacy in
the SNMP as objects in the Internet Standard MIB. These
definitions are consistent with the administrative strategies
set forth in the companion memo: Administration of SNMP
Communities.
``Administration of SNMP Communities'', James Davin, James Galvin, Keith
McCloghrie, 07/05/1990
<draft-ietf-snmpauth-communities-01.txt>
Simple Network Management Protocol (SNMP) specification allows
for the authentication of management operations by a variety of
authentication algorithms. This memo defines two strategies
for administering SNMP communities based upon either the SNMP
authentication algorithm or the SNMP authentication and privacy
algorithm. Insofar as the administration of SNMP communities
based upon the trivial authentication algorithm may be realized
by straightforward application of familiar network management
techniques, administration of such communities is not directly
addressed in this memo.
``Gateway Congestion Control Policies'', A.J. Mankin, K.K. Ramakrishnan,
07/06/1990
<draft-ietf-pcc-gwcc-01.txt>
The growth of network intensive Internet applications has made
gateway congestion control a high priority. The IETF
Performance and Congestion Control Working Group surveyed and
reviewed gateway congestion control and avoidance approaches in
a series of meetings during 1988 and 1989. The purpose of this
paper is to present our review of the congestion control
approaches, as a way of encouraging new discussion and
experimentation. Included in the survey are Source Quench,
6
Random Drop, Congestion Indication (DEC Bit), and Fair
Queueing. The task remains for Internet implementors to
determine and agree on the most effective mechanisms for
controlling gateway congestion.
``OSI NSAP Address Format For Use In The Internet'', R Colella, R
Callon, 07/10/1990
<draft-ietf-osinsap-format-00.txt>
This document provides alignment with U.S. GOSIP Version 2.
GOSIP Version 2 has undergone the required public review and
comment period prior to becoming a Federal Information
Processing Standard (FIPS). It will be published as a FIPS by
the end of Calendar Year 1990.
``Benchmarking Terminology'', Scott Bradner, 07/13/1990
<draft-ietf-bmwg-terms-00.txt>
This memo discusses and defines a number of terms that are used
in describing performance benchmarking tests and the results of
such tests.
The terms defined in this memo will be used in additional memos
to define specific benchmarking tests and the suggested format
to be used in reporting the results of each of the tests.
``Management Services Interface'', Oscar Newkerk, 07/13/1990
<draft-ietf-msi-api-02.txt and .ps>
The Management Services API defines Application Programming
Interfaces which provide a set of services for the management
of the objects in a heterogeneous, multivendor distributed
computing environment.
The Management Services API is designed to allow for the
development of portable management applications. The
Management Services API insulate management application
developers from the details of the management protocol and from
the transport services used to route the management directives
to the managed objects. It provides facilities to manage both
local and remote objects in a seamless fashion.
``Experimental Definitions of Managed Objects for the Border Gateway
Protocol (Version 2)'', Steven Willis, John Burruss, 09/21/1990
<draft-ietf-iwg-bgp-mib-01.txt>
7
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
objects for managing the Border Gateway Protocol.
``A Proposed Standard for the Transmission of IP Datagrams over SMDS'',
Joe Lawrence, Dave Piscitello, 07/18/1990
<draft-ietf-smds-ipdatagrams-00.txt>
This memo describes an initial use of IP and ARP in an SMDS
environment configured as a logical IP subnet, LIS (described
below). The encapsulation method used is described, as well as
various service-specific issues. This memo does not preclude
subsequent treatment of SMDS in configurations other than LIS;
specifically, public or inter-company, inter-enterprise
configurations may be treated differently and will be described
in future documents.
``INTERNET OSI INTEGRATION, COEXISTENCE AND INTEROPERABILITY ISSUES'',
Robert Hagens, Rebecca Nitzan, 07/24/1990
<draft-fopg-ositransition-00.txt>
The intent of this document is to provide technical
descriptions of the issues involved in the integration of the
Open Systems Interconnect (OSI)
protocols into the operational networks which interconnect and
comprise the ``Internet''. The issues raised and solutions
discussed are a result of the Federal Networking Council (FNC)
OSI Planning Group (FOPG). The members of the FOPG represent
several Federal Government agencies such as the Department of
Energy (DOE), the National Science Foundation (NSF) the
National Aeronautics and Space Administration (NASA), the
National Institute of Standards and Technology (NIST) under the
Department of Commerce, as well as University experts.
``The OSPF Specification, Version 2'', John Moy, 07/24/1990
<draft-ietf-ospf-ospf2-00.txt>
This document is a specification of the Open Shortest Path
First (OSPF) internet routing protocol. OSPF is classified as
an Internal Gateway Protocol (IGP). This means that it
distributes routing information between routers belonging to a
single Autonomous System. The OSPF protocol is based on SPF or
link-state technology. This is a departure from the
Bellman-Ford base used by traditional internet routing
protocols.
8
``X.25 Call Setup and Charging Determination Protocol (XCDP)'', Carl-H
Rokitansky, 07/27/1990
<draft-ietf-pdnrout-x25call-00.txt>
Therefore, the X.25 Call Setup and Charging Determination
Protocol (XCDP)", described in this document, has been
developed, to support global Internet connectivity via the
system of X.25 Public Data Networks PDN (even via VAN-gateways
preventing local charges), by providing a pseudo-reverse
charging option, which is indicated in the Call User Data (CUD)
field of the call request. In addition, information about the
source and destination address of the Internet datagram to be
transmitted, can also be indicated in the user data field of
the call request.
``X.121 Address Resolution for IP Datagram Transmission Over X.25
Networks'', Carl-Herbert Rokitansky, 07/27/1990
<draft-ietf-pdn-xarp-01.txt>
``Telnet Authentication Option'', Dave Borman, 08/08/1990
<draft-ietf-telnet-authentication-01.txt>
``Telnet Environment Option'', Dave Borman, 08/08/1990
<draft-ietf-telnet-environment-01.txt>
``Telnet Linemode Option'', Dave Borman, 08/08/1990
<draft-ietf-telnet-linemodeoption-02.txt>
Linemode Telnet is a way of doing terminal character processing
on the client side of a Telnet connection. While in Linemode
with editing enabled for the local side, network traffic is
reduced to a couple of packets per command line, rather than a
couple of packets per character typed. This is very useful for
long delay networks, because the user has local response time
while typing the command line, and only incurs the network
delays after the command is typed. It is also useful to reduce
costs on networks that charge on a per packet basis.
``Privacy Enhancement for Internet Electronic Mail: Part IV --
Certifying Authority and Organizational Notary Services'', Burt Kaliski,
08/14/1990
<draft-rsadsi-kaliski-privacymail-01.txt>
This document describes two services that vendors may provide
in support of Internet privacy-enhanced mail: certifying
authority services on behalf of organizations, and
organizational notary services for users. It also specifies
9
the forms for interacting with vendors providing those
services. This document is intended as a reference for vendors
and for implementors of privacy-enhanced mail software; it is
not at the appropriate level for users. The document also
lists vendors.
``OSI Internet Management: Management Information Base'', Lee LaBarre,
08/17/1990
<draft-ietf-oim-mib2-02.txt>
This draft defines the Management Information Base (MIB) for
use with the OSI network management protocol in TCP/IP based
internets. It formats the Management Information Base (MIB-II)
in OSI templates and adds variables necessary for use with the
OSI management protocol.
``Asynchronous Discovery of an Effective Maximum Transmission Unit for
IP Datagram Delivery [MTU Discovery]'', James Sawyer, 08/17/1990
<draft-csc-sawyer-mtudisc-00.txt>
A case against IP layer fragmentation has been made, and
various methods for avoiding it proposed. This memo revisits
the effect of fragmentation on network performance, and
recounts the present methods of avoidance. A protocol is
presented which adapts to the varying circumstances
encountered, sending large datagrams whenever possible, and
reducing fragmentation when necessary to avoid retransmission
problems. A hybrid approach to MTU discovery, it utilizes one
new IP header option and four new ICMP messages. It is a
simple mechanism that discovers path MTUs without wasting
resources and that works well before all hosts and routers are
modified.
``Use of OSI IS-IS for Routing in TCP/IP and Dual Environments'', Ross
Callon, 08/27/1990
<draft-ietf-isis-spec-01.ps>
This Internet Draft specifies an integrated routing protocol,
based on the OSI Intra-Domain IS-IS Routing Protocol, which may
be used as an interior gateway protocol (IGP) to support TCP/IP
as well as OSI. This allows a single routing protocol to be
used to support pure IP environments, pure OSI environments and
dual environments. This specification was developed by the
IS-IS Working Group of the Internet Engineering Task Force.
Comments should be sent to isis@merit.edu.
``SNMP Over IPX'', Raymond Wormley, 08/27/1990
<draft-ietf-snmp-snmpoveripx-00.txt>
10
The SNMP protocol has been specified as the official network
management protocol of the Internet. Its widespread acceptance
and implementation by developers, both inside and outside the
Internet community, is fostering synergetic growth to a variety
of protocols and platforms.
This memo addresses the use of SNMP over Novell's proprietary
IPX protocol. Roughly equivalent to UDP in function, IPX
provides connectionless, unacknowledged datagram service over a
variety of physical media and protocols.
``The Finger User Information Protocol'', David Zimmerman, 09/04/1990
<draft-zimmerman-finger-03.txt>
The predecessor to this memo was RFC742, a description of the
original Finger protocol. Currently, the development and use
of the protocol has deviated from the imprecise RFC742
specifications, and the examples in RFC742 are woefully out of
date.
``Internet Stream Protocol'', C Topolcic, 09/04/1990
<draft-ietf-cip-st2-00.txt>
This memo defines the Internet Stream Protocol, Version 2
(ST-II), an IP-layer protocol which provides end-to-end
guaranteed service across an internet. This specification
obsoletes IEN 119 "ST - A Proposed Internet Stream Protocol"
written by Jim Forgie in 1979, the previous specification of
ST. ST-II represents some relatively minor changes to Version 1
of the protocol and is intended to fill in some of the areas
left unaddressed, to make it easier to implement, and to
support a wider range of applications. However, ST-II is not
compatible with the previous version of ST.
``Towards Concise MIB Definitions'', Marshall Rose, Keith McCloghrie,
09/26/1990
<draft-ietf-snmp-mibdefinitions-01.txt>
This memo describes a straight-forward approach toward
producing concise, yet descriptive, MIB modules. Use of this
approach is in every way fully consistent with the
Internet-standard network management framework.
``A Convention for Defining Traps for use with the SNMP'', Marshall
Rose, 09/26/1990
<draft-ietf-snmp-traps-01.txt>
11
This memo describes a straight-forward approach toward defining
traps used with the SNMP. It is specifically intended for use
by the authors of experimental MIBs, and emphasizes a concise
descriptive approach. Use of this approach is fully consistent
with the Internet-standard network management framework.
``Experimental Definitions of Managed Objects for the Point-to-Point
Protocol'', Frank Kastenholz, 09/11/1990
<draft-ietf-ppp-pppmib-01.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it
describes managed objects used for managing subnetworks using
the Point-to-Point Protocol.
``Extensions to the Generic-Interface MIB'', Keith McCloghrie,
09/12/1990
<draft-ietf-snmp-interfacemibext-00.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
managed object types as experimental extensions to the generic
interfaces structure of MIB-II.
This memo does not specify a standard for the Internet
community. However, after experimentation, if sufficient
consensus is reached in the Internet community, then a
subsequent revision of this document may be incorporated into
the Internet-standard MIB.
``Transmission of IP Datagrams and ARP Packets over ARCNET Networks'',
Don Provan, 09/17/1990
<draft-provan-iparcnet-00.txt>
This draft document specifies a standard method of
encapsulating Internet Protocol (IP) and Address Resolution
Protocol (ARP) datagrams using the ARCNET Packet Header
Definition Standard. This draft should obsolete RFC-1051.
RFC-1051 used a different ARCNET packet header which is
incompatible with most modern ARCNET software.
``Requirements for Internet IP Routers'', Philip Almquist, 09/17/1990
<draft-ietf-rreq-iprouters-00.txt>
This draft attempts to define and discuss requirements for
devices which perform the network layer forwarding function of
12
the Internet protocol suite. The Internet community usually
refers to such devices as "routers". This document is intended
to provide guidance for vendors, implementors, and purchasers
of IP routers.
``IEEE 802.4 Token Bus MIB'', Keith McCloghrie, Richard Fox, 09/26/1990
<draft-ietf-snmp-tokenbusmib-00.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
managed objects used for managing subnetworks which use the
IEEE 802.4 Token Bus technology.
``Definitions of Managed Objects for the Ethernet-like Interface
Types'', John Cook, 09/26/1990
<draft-ietf-snmp-ethernetmib-00.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
objects for managing ethernet-like objects.
``IEEE 802.5 Token Ring MIB'', Keith McCloghrie, Richard Fox, Eric
Decker, 09/26/1990
<draft-ietf-snmp-tokenringmib-00.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it defines
managed objects used for managing subnetworks which use the
IEEE 802.5 Token Ring technology.
-----------------
On Line IETF Information
The Internet Engineering Task Force maintains up-to-date on-line
information on all its activities. There is a directory containing
Internet-Draft documents and a directory containing IETF working group
information. All this information is available for public access at
several locations. (See section 3 of this document)
The ``IETF'' directory contains a general description of the IETF,
summaries of ongoing working group activities and provides information
on past and upcoming meetings. The directory generally reflects
information contained in the most recent IETF Proceedings and Working
Group Reports.
The ``Internet-Drafts'' directory has been installed to make available,
for review and comment, draft documents that will be submitted
ultimately to the IAB and the RFC Editor to be considered for publishing
as an RFC. Comments are welcome and should be addressed to the
responsible person whose name and email addresses are listed on the
first page of the respective draft.
1
The IETF Directory
Below is a list of the files available in the IETF directory and a short
synopsis of what each file contains.
Files prefixed with a 0 contain information about upcoming meetings.
Files prefixed with a 1 contain general information about the IETF, the
working groups, and the internet-drafts.
FILE NAME
0mtg-agenda the current agenda for the upcoming quarterly IETF
plenary, which contains what Working Groups will be
meeting and at what times, and the technical
presentations and network status reports to be given.
0mtg-logistics the announcement for the upcoming quarterly IETF
plenary, which contains specific information on the
date/location of the meeting, hotel/airline
arrangements, meeting site accommodations and travel
directions.
0mtg-rsvp a standardized RSVP form to be used to notify the
support staff of your plans to attend the upcoming IETF
meeting.
0mtg-schedule current and future meeting dates and sites for IETF
plenaries.
1id-abstracts the internet drafts current on-line in the
internet-drafts directory.
1id-guidelines instructions for authors of internet drafts.
1ietf-overview a short description of the IETF, the IESG and how to
participate.
1wg-summary a listing of all current Working Groups, the working
group chairmen and their email addresses, working group
mailing list addresses, and, where applicable,
documentation produced. This file also contains the
standard acronym for the working groups by which the
IETF and Internet-Drafts directories are keyed.
Finally, Working Groups have individual files dedicated to their
particular activities which contain their respective Charters and
Meeting Reports. Each Working Group file is named in this fashion:
<standard wg abbreviation>-charter.txt
<standard wg abbreviation>-minutes-date.txt
2
The ``dir'' or ``ls'' command will permit you to review what Working
Group files are available and the specific naming scheme to use for a
successful anonymous ftp action.
The Internet-Drafts Directory
The Internet-Drafts directory contains the current working documents of
the IETF. These documents are indexed in the file 1id-abstracts.txt in
the Internet-Drafts directory.
The documents are named according to the following conventions. If the
document was generated in an IETF working group, the filename is:
draft-ietf-<std wg abrev>-<docname>-<rev>.txt , or .ps
where <std wg abrev> is the working group acronym, <docname> is a very
short name, and <rev> is the revision number.
If the document was submitted for comment by a non-ietf group or author,
the filename is:
draft-<org>-<author>-<docname>-<rev>.txt, or .ps
where <org> is the organization sponsoring the work and <author> is
the author's name.
For more information on writing and installing an Internet-Draft, see
the file 1id-guidelines, ``Guidelines to Authors of Internet-Drafts''.
3
Directory Locations
The directories are maintained primarily at the NSFnet Service Center
(NNSC). There are several ``shadow'' machines which contain the IETF and
INTERNET-DRAFTS directories. These machines may be more convenient that
nnsc.nsf.nsf.
To access these directories, use FTP. After establishing a connection,
Login with username ANONYMOUS and password GUEST. When logged in, change
to the directory of your choice with the following commands:
cd internet-drafts
cd ietf
Individual files can then be retrieved using the GET command:
get <remote filename> <local filename>
e.g., get 00README readme.my.copy
NSF Network Service Center Address: nnsc.nsf.net
The Defense Data Network NIC Address: nic.ddn.mil
Internet-drafts are also available by mail server from this
machine. For more information mail a request:
To: service@nic.ddn.mil
Subject: Help
NIC staff are happy to assist users with any problems that they
may encounter in the process of obtaining files by FTP or
``SERVICE''. For assistance, phone the NIC hotline at
1-800-235-3155 between 6 am and 5 pm Pacific time.
Pacific Rim Address: munnari.oz.au
The Internet-drafts on this machine are stored in Unix
compressed form (.Z).
Europe Address: nic.nordu.net (192.36.148.17)
4
13
- Index of available documents mdavies