home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft__misc
/
1id-abstracts.txt
< prev
next >
Wrap
Text File
|
1997-11-02
|
735KB
|
12,871 lines
Current Internet-Drafts
This summary sheet provides a short synopsis of each Internet-Draft
available within the "internet-drafts" directory at the shadow
sites directory. These drafts are listed alphabetically by working
group acronym and start date.
The Internet and the Millennium Problem (2000)
----------------------------------------------
"The Internet and the Millenium Problem (Year 2000)", Philip Nesser II,
08/04/1997, <draft-ietf-2000-issue-00.txt>
The Year 2000 Working Group(WG) has conducted an investigation into
the millenium problem as it regards Internet related protocols.
This investigation only targeted the protocols as documented in the
Request For Comments Series (RFCs). This investigation discovered
little reason for concern with regards to the functionality of the
protocols. A few minor cases of older implementations still using
two digit years (ala RFC 850) were discovered, but almost all
Internet protocols were given a clean bill of health. Several cases
of 'period' problems were discussed where a time field would 'roll
over' as the size of field was reached. In particular, there are
several protocols which have 32 bit signed integer representations
of the number of seconds since January 1, 1970 which will turn
negative at Tue Jan 19 03:14:07 GMT 2038. Areas whose protocols
will be effected by such problems have been notified so that new
revisions will remove this limitation.
Application Configuration Access Protocol (acap)
------------------------------------------------
"ACAP -- Application Configuration Access Protocol", C Newman, J Myers,
08/26/1997, <draft-ietf-acap-spec-06.txt>
The Application Configuration Access Protocol (ACAP) is designed to
support remote storage and access of program option, configuration
and preference information. The data store model is designed to
allow a client relatively simple access to interesting data, to
allow
new information to be easily added without server re-configuration,
and to promote the use of both standardized data and custom or
proprietary data. Key features include 'inheritance' which can be
used to manage default values for configuration settings and access
control lists which allow interesting personal information to be
shared and group information to be restricted.
"ACAP TYPE Extension", R. Earhart, 04/23/1997,
<draft-ietf-acap-type-ext-00.txt>
The Application Configuration Access Protocol [ACAP] defines rough
typing information in the form of an attribute naming convention. This
extension to ACAP allows a MIME content-type/subtype with parameters to
be associated with a given piece of data, providing knowledgeable
clients with useful information in a way which maintains compatability
with innocent clients and servers.
"ACAP Datatyping and Datatyping Discovery", J. De Winter, 04/25/1997,
<draft-ietf-acap-dewinter-dtype-00.txt>
The Application Configuration Access Protocol (ACAP) is designed to
support remote storage and access of program option, configuration and
preference information. In certain circumstances, it is desirable or
necessary to deal with information that has a limit imposed on it.
While the general ACAP specification does provide for a (SYNTAX) alert
to inform the submittor that the stored information was not in a valid
syntax for that field, there is no generic method to discover that
syntax. There is strong feeling in the ACAP working group
that variable length strings should be used for data where possible,
but there is also the knowledge that ACAP will be used to configure and
access existing systems where the use of such variable length strings
may be difficult or impossible.
"Multi-Lingual String Format (MLSF)", C Newman, 06/09/1997,
<draft-ietf-acap-mlsf-01.txt>
The IAB charset workshop [IAB-CHARSET] concluded that for human
readable text there should always be a way to specify the natural
language. Many protocols are designed with an attribute-value model
(including RFC 822, HTTP, LDAP, SNMP, DHCP, and ACAP) which stores many
small human readable text strings. The primary function of an
attribute-value model is to simplify both extensibility and
searchability. A solution is needed to provide language tags in these
small human readable text strings, which does not interfere with these
primary functions. This specification defines
MLSF (Multi-Lingual String Format) which applies another layer of
encoding on top of UTF-8 [UTF-8] to permit the addition of language
tags anywhere within a text string. In addition, it defines an
alternate form which can be used to include alternative representations
of the same text in different character sets. MLSF has the property
that UTF-8 is a proper subset of MLSF. This preserves the searchability
requirement of the attribute-value model. Appendix F of this document
includes a brief discussion of the background behind MLSF and why some
other potential solutions were rejected for this purpose.
"Anonymous SASL Mechanism", C Newman, 08/26/1997,
<draft-ietf-acap-anon-01.txt>
It is common practice on the Internet to permit anonymous access
to
various services. Traditionally, this has been done with a plain
text password mechanism using 'anonymous' as the user name and
optional trace information, such as an email address, as the
password. As plaintext login commands are not permitted in new
IETF protocols, a new way to provide anonymous login is needed
within the context of the SASL [SASL] framework.
"Two Alternative Proposals for Language Taging in ACAP", M. Duerst,
06/23/1997, <draft-ietf-acap-langtag-00.txt>
For various computing applications, it is helpful to know the language
of the text being processed. This can be the case even if otherwise
only pure character sequences (so-called plain text) are handled. From
several sides, the need for such a scheme for ACAP has been claimed.
One specific scheme, called MLSF, has also been proposed, see
draft-ietf-acap-mlsf-01.txt for details. This document proposes two
alternatives to MLSF. One alternative is using text/enriched-like
markup. The second alternative is using a special tag-introduction
character. Advantages and disadvantages of the various proposals are
discussed. Some general comments about the topic of language tagging
are given in the introduction.
"ACAP Authorization Identifier Datasets", S. Hole, 07/24/1997,
<draft-ietf-acap-authid-00.txt>
Most distributed (client/server) applications require an authentication
process between the client and the server before the server will grant
access to its managed resources. Many applications provide varying
levels of access to server resources based on a combination of
authentication credentials and access control rules. The collection
of information used to control access to resources is called
'authorization information'.
"ACAP Personal Addressbook Dataset Class", C Newman, 07/29/1997,
<draft-ietf-acap-abook-00.txt>
IMAP [IMAP4] allows nomadic users to access their mailstore from
any client, but it does not support storage of personal
addressbooks. Application Configuration Access Protocol [ACAP]
provides an ideal mechanism for storage of personal addressbooks.
While ACAP permits the definition of vendor specific solutions to
this problem, having a standard addressbook dataset class permits
clients from different vendors to interoperably share the same
personal addressbooks. This specification defines a standard
dataset class for personal addressbooks.
Personal addressbooks differ from white pages services because all
the attributes and entries are controlled by the user who owns the
addressbook rather than a directory administrator. The user or
the
clients he uses may add new attributes at any time and some of
these attributes are not suitable for a white pages service.
"ACAP personal options dataset class", S. Hole, 07/30/1997,
<draft-ietf-acap-options-01.txt>
The Application Configuration Access Protocol (ACAP) is designed
to
support remote storage and access of application option,
configuration and preference information. The generalized form of
this runtime configuration is called 'options'. Options consist
consist of any type of structured or unstructured data that an
application requires to operate in a user specific manner.
Authenticated Firewall Traversal (aft)
--------------------------------------
"Challenge-Handshake Authentication Protocol for SOCKS V5", M.
VanHeyningen, 03/20/1997, <draft-ietf-aft-socks-chap-00.txt>
This document specifies the integration of the Challenge-Handshake
Authenticaton Protocol (CHAP) [RFC 1994] into SOCKS Version 5 [RFC
1928]. It is intended to provide a simple, lightweight authentication
method which is more secure than cleartext passwords but simpler than
GSSAPI-based methods. This document describes the message formats and
protocol details of incorporating CHAP into the SOCKS V5 authentication
'subnegotiation.' Support is included for authentication of server to
client as well as client to server.
"Challenge-Response Authentication Method for SOCKS V5", M. VanHeyningen,
03/20/1997, <draft-ietf-aft-socks-cram-00.txt>
This document specifies a general Challenge-Response Authentication
Method (CRAM) for use with SOCKS Version 5 [RFC 1928]. It is intended
to support various challenge-response mechanisms, such as S/KEY and OTP
[RFC 1938] as well as authentication tokens.
"Secure Sockets Layer for SOCKS Version 5", M. VanHeyningen, 03/20/1997,
<draft-ietf-aft-socks-ssl-00.txt>
This document specifies the use of SSL 3.0 and possible successor
protocols as an authentication method for SOCKS Version 5. The design
is similar to, and largely derived from, the integration of GSS-API
into SOCKS5 [RFC 1961]. A framework is provided for future extensions,
and the use of other 'subauthentication' methods inside SSL is
supported.
"SOCKS Protocol Version 5", William Perry, 07/30/1997,
<draft-ietf-aft-socks-pro-v5-01.txt>
The use of network firewalls, systems that effectively isolate an
organizations internal network structure from an exterior network, such
as the INTERNET is becoming increasingly popular.
"Feature Discovery: A Generic Extension Mechanism for SOCKS Version 5",
M. VanHeyningen, 07/23/1997, <draft-ietf-aft-socks-ext-00.txt>
This document specifies a command extension to the SOCKS Version 5
protocol which enables compliant clients to discover features supported
by the server. After discovering the support of such features, the
client may use them in subsequent connections to that server. This
mechanism does not provide for negotiation; it is a way of instructing
the client what features the server supports, not establishing which
features the client supports or wishes to use.
SNMP Agent Extensibility (agentx)
---------------------------------
"Agent Extensibility (AgentX) Protocol Version 1", Bert Wijnen, D.
Francisco, M. Daniele, 06/10/1997, <draft-ietf-agentx-ext-pro-04.txt>
This memo defines a standardized framework for extensible SNMP agents.
It defines processing entities called master agents and subagents, a
protocol (AgentX) used to communicate between them, and the elements of
procedure by which the extensible agent processes SNMP protocol
messages.
"Definitions of Managed Objects for Extensible SNMP Agents", M. Greene,
S. Gudur, 05/15/1997, <draft-ietf-agentx-mib-00.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects managing SNMP agents
that use the Agent Extensibility (AgentX) Protocol.
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
Application MIB (applmib)
-------------------------
"Definitions of System-Level Managed Objects for Applications", Jonathan
Saperia, Cheryl Krupczak, 10/31/1997,
<draft-ietf-applmib-sysapplmib-09.txt>
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the
Internet community. In particular, it describes a basic set of
managed objects for fault, configuration and performance
management of applications from a systems perspective. More
specifically, the managed objects are restricted to
information that can be determined from the system itself and
which does not require special instrumentation within the
applications to make the information available.
This memo does not specify a standard for the Internet
community.
"Definitions of Managed Objects for WWW Services", C. Kalbfleisch, H.
Hazewinkel, J. Schoenwaelder, 09/26/1997,
<draft-ietf-applmib-wwwmib-05.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet Community. In particular it describes a set of objects
for managing World-Wide Web (WWW) services. This MIB extends the
application management framework defined by the System Application
Management MIB (SYSAPPL-MIB) and the Application Management MIB
(APPLICATION-MIB). The protocol statistics defined in the WWW
Service
MIB are based on an abstract document transfer protocol (DTP). This
memo also defines a mapping of the abstract DTP to HTTP and FTP.
Additional mappings may be defined in the future in order to use
this
MIB with other document transfer protocols. It is anticipated that
such future mappings will be defined in separate RFCs.
"Application Management MIB", Jonathan Saperia, Cheryl Krupczak, Randy
Presuhn, C. Kalbfleisch, 08/04/1997, <draft-ietf-applmib-mib-04.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
Community. In particular, it defines objects used for the management
of applications. This MIB complements the System Application MIB,
providing for the management of applications' common attributes which
could not typically be observed without the cooperation of the software
being managed.
Access, Searching and Indexing of Directories (asid)
----------------------------------------------------
"A MIME Content-Type for Directory Information", Tim Howes, Mark Smith,
07/24/1997, <draft-ietf-asid-mime-direct-04.txt>
This document defines a MIME Content-Type for holding directory
information. The definition is independent of any particular directory
service or protocol. The text/directory Content-Type is defined for
holding a variety of directory information, for example, name, or email
address, or logo. The text/directory Content-Type can also be used as
the root body part in a multipart/related Content-Type for handling
more complicated situations, especially those in which non-textual
information that already has a natural MIME representation, for
example, a photograph or sound, must be represented. The
text/directory Content-Type defines a general framework and format for
holding directory information in a simple 'type: value' form.
Mechanisms are defined to specify alternate character sets, languages,
encodings and other meta-information. This document also defines the
procedure by which particular formats, called profiles, for carrying
application-specific information within a text/directory Content-Type
may be defined and registered, and the conventions such formats must
follow. It is expected that other documents will be produced that
define such formats for various applications (e.g., white pages).
"A Simple Caching Scheme for LDAP and X.500 Directories", Tim Howes, L.
Howard, 10/22/1997, <draft-ietf-asid-ldap-cache-01.txt>
This memo defines an object class and attribute type in support of
a
simple caching mechanism for use in LDAP and X.500 directories.
The
object class allows a simple 'time-to-live' attribute to be included
in
entries, enabling clients retrieving the attribute to tell when
the
other information they have retrieved from the entry should be
thrown
away. The use of this scheme does not preclude the subsequent or
addi-
tional use of other more complicated schemes, for example, allowing
dif-
ferent TTLs on individual attributes.
"WHOIS++ URL Specification", M. Hamilton, 05/15/1997,
<draft-ietf-asid-whois-url-01.txt>
This document defines a new Uniform Resource Locator (URL) scheme
'whois++', which provides a convention within the URL framework for
referring to WHOIS++ servers and the data held within them.
"Lightweight Directory Access Protocol (v3)", Steve Kille, Tim Howes, M.
Wahl, 10/20/1997, <draft-ietf-asid-ldapv3-protocol-08.txt>
The protocol described in this document is designed to provide access
to directories supporting the X.500 models, while not incurring the
resource requirements of the X.500 Directory Access Protocol (DAP).
This protocol is specifically targeted at management applications
and
browser applications that provide read/write interactive access to
directories. When used with a directory supporting the X.500
protocols, it is intended to be a complement to the X.500 DAP.
"Lightweight Directory Access Protocol (v3): Attribute Syntax
Definitions", Steve Kille, Tim Howes, M. Wahl, A. Coulbeck, 10/20/1997,
<draft-ietf-asid-ldapv3-attributes-08.txt>
The Lightweight Directory Access Protocol (LDAP) [1] requires that the
contents of AttributeValue fields in protocol elements be octet
strings. This document defines a set of syntaxes for LDAPv3, and the
rules by which attribute values of these syntaxes are represented as
octet strings for transmission in the LDAP protocol. The syntaxes
defined in this document are referenced by this and other documents
that define attribute types. This document also defines the set of
attribute types which LDAP servers should support.
"vCard MIME Directory Profile", Tim Howes, F. Dawson, 08/02/1997,
<draft-ietf-asid-mime-vcard-03.txt>
This memo defines the profile of the MIME Content-Type [MIME-DIR]
for
directory information for a white-pages person object, based on a
vCard electronic business card. The profile definition is
independent
of any particular directory service or protocol. The profile is
defined for representing and exchanging a variety of information
about an individual (e.g., formatted and structured name and
delivery
addresses, email address, multiple telephone numbers, photograph,
logo, audio clips, etc.). The directory information used by this
profile is based on the attributes for the person object defined in
the X.520 and X.521 directory services recommendations. The profile
also provides the method for including a [VCARD] representation of a
white-pages directory entry within the MIME Content-Type defined by
the [MIME-DIR] document.
"Lightweight Directory Access Protocol (v3): Extensions for Dynamic
Directory Services", Tony Genovese, M. Wahl, Y. Yaacovi, 09/29/1997,
<draft-ietf-asid-ldapv3-dynamic-06.txt>
This document defines the requirements for dynamic directory
services
and specifies the format of request and response extended operations
for supporting client-server interoperation in a dynamic directories
environment.
The Lightweight Directory Access Protocol (LDAP) [1] supports
lightweight access to static directory services, allowing relatively
fast search and update access. Static directory services store
information about people that persists in its accuracy and value
over
a long period of time.
Dynamic directory services are different in that they store
information that only persists in its accuracy and value when it is
being periodically refreshed. This information is stored as dynamic
entries in the directory. A typical use will be a client or a
person
that is either online - in which case it has an entry in the
directory, or is offline - in which case its entry disappears from
the
directory. Though the protocol operations and attributes used by
dynamic directory services are similar to the ones used for static
directory services, clients that store dynamic information in the
directory need to periodically refresh this information, in order to
prevent it from disappearing. If dynamic entries are not refreshed
within a given timeout, they will be removed from the directory.
For
example, this will happen if the client that set them goes offline.
A flow control mechanism from the server is also described that
allows
a server to inform clients how often they should refresh their
presence.
"Lightweight Directory Access Protocol (v3): UTF-8 String Representation
of Distinguished Names", Steve Kille, Tim Howes, M. Wahl, 04/30/1997,
<draft-ietf-asid-ldapv3-dn-03.txt>
The X.500 Directory uses distinguished names as the primary keys to
entries in the directory. Distinguished Names are encoded in ASN.1 in
the X.500 Directory protocols. In the Lightweight Directory Access
Protocol, a string representation of distinguished names is
transferred. This specification defines the string format for
representing names, which is designed to give a clean representation of
commonly used distinguished names, while being able to represent any
distinguished name.
"Using Domains in LDAP/X.500 Distinguished Names", Steve Kille, Rick
Huber, Sri Sataluri, A. Grimstad, M. Wahl, 09/12/1997,
<draft-ietf-asid-ldap-domains-02.txt>
The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible
distinguished names [3] for providing unique identification of
entries.
This document defines an algorithm by which a name registered with
the
Internet Domain Name Service [2] can be represented as an LDAP
distinguished name.
"Use of Language Codes in LDAPv3", Tim Howes, M. Wahl, 06/06/1997,
<draft-ietf-asid-ldapv3-lang-02.txt>
The Lightweight Directory Access Protocol [1] provides a means for
clients to interrogate and modify information stored in a distributed
directory system. The information in the directory is maintained as
attributes [2] of entries. Most of these attributes have syntaxes
which are human-readable strings, and it is desirable to be able to
indicate the natural language associated with attribute values.
This document describes how language codes [3] are carried in LDAP and
are to be interpreted by LDAP servers. All implementations MUST be
prepared to accept language codes in the LDAP protocols. Servers may
or may not be capable of storing attributes with language codes in the
directory.
"The LDAP Data Interchange Format (LDIF) - Technical Specification", G.
Good, 07/25/1997, <draft-ietf-asid-ldif-02.txt>
This document describes a file format suitable for describing directory
information or modifications made to directory information. The file
format, known as LDIF, for LDAP Data Interchange Format, is typically
used to import and export directory information between LDAP-based
directory servers, or to describe a set of changes which are to be
applied to a directory.
There are a number of situations where a common interchange format is
desirable. For example, one might wish to export a copy of the
contents of a directory server to a file, move that file to a different
machine, and import the contents into a second directory server.
Additionally, by using a well-defined interchange format, development
of data import tools from legacy systems is facilitated. A fairly
simple set of tools written in awk or perl can, for example, convert a
database of personnel information into an LDIF file, which can then be
imported into a directory server, regardless of the internal database
representation the target directory server uses. The key words
'MUST', 'MAY', and 'SHOULD' used in this document are to be interpreted
as described in [7].
"WHOIS++ templates", J. Knight, Patrik Faltstrom, M. Hamilton, Leslie
Daigle, 10/03/1997, <draft-ietf-asid-whois-schema-02.txt>
WHOIS++ is a simple Internet search and retrieval protocol,
specified in RFC 1835, which allows clients and servers to
exchange
structured data objects known as templates. In the interests of
interoperability it is desirable to have a common base schema for
these templates. This document suggests a schema drawn from
implementation and deployment experience to date with WHOIS++.
"Definition of the inetOrgPerson Object Class", Mark Smith, 08/05/1997,
<draft-ietf-asid-inetorgperson-01.txt>
While the X.500 standards [X500] define many useful attribute types and
object classes, they do not define a person object class that meets the
requirements found in today's Internet and Intranet directory service
deployments. We define a new object class called inetOrgPerson that
extends the X.521 standard organizationalPerson class to meet these
needs.
"Architecture of the WHOIS++ service", Chris Weider, Peter Deutsch,
Patrik Faltstrom, R. Schoultz, Leslie Daigle, S. Newell, 03/26/1997,
<draft-ietf-asid-whoispp-01.txt>
This document describes Whois++, an extension to the trivial WHOIS
service described in RFC 954 to permit WHOIS-like servers to make
available more structured information to the Internet. We describe an
extension to the simple WHOIS data model and query protocol and a
companion extensible, distributed indexing service. A number of
options have also been added such as the use of multiple languages and
character sets, more advanced search expressions, structured data and a
number of other useful features. An optional authentication mechanism
for protecting all or part of the associated Whois++ information
database from unauthorized access is also described.
"Definition of an Object Class to Hold LDAP Change Records", G. Good,
07/25/1997, <draft-ietf-asid-changelog-01.txt>
In order to support more flexible replication methods, it is desirable
to specify some manner in which an LDAP client may retrieve a set of
changes which have been applied to an LDAP server's database. The
client, which may be another LDAP server, may then choose to update its
own replicated copy of the data. This document specifies an object
class which may be used to represent changes applied to an LDAP server.
It also specifies a method for discovering the location of the
container object which holds these change records, so that clients and
servers have a common rendezvous point for this information.
"LDAP Control Extension for Simple Paged Results Manipulation", Chris
Weider, Tim Howes, A. Herron, 03/26/1997,
<draft-ietf-asid-ldapv3-simplepaged-01.txt>
This document describes an LDAPv3 control extension for simple paging
of search results. This control extension allows a client to control
the rate at which an LDAP server returns the results of an LDAP search
operation. This control may be useful when the LDAP client has limited
resources and may not be able to process the entire result set from a
given LDAP query, or when the LDAP client is connected over a
low-bandwidth connection. Other operations on the result set are not
defined in this extension. This extension is not designed to provide
more sophisticated result set management. The key words
'MUST', 'SHOULD', and 'MAY' used in this document are to be interpreted
as described in [bradner97].
"Lightweight Directory Access Protocol: Schema for Storing RPC Entries
in a Directory Service", P. Leach, S. Judd, S. Thatte, W. Hopkins,
03/03/1997, <draft-ietf-asid-ldap-rpcschema-00.txt>
The Lightweight Directory Access Protocol [1][2] defines a standard
protocol for accessing diverse directory services. One common use of a
directory service is the location of application services, among which
are RPC services.
This document defines a set of object classes and attributes for
storing metadata and binding information for RPC services that are
DCE-compliant or closely follow the DCE model, in directories that
support LDAP.
"LDAP Multi-master Replication Protocol", Chris Weider, J. Strassner,
07/31/1997, <draft-ietf-asid-ldap-mult-mast-rep-01.txt>
This paper defines a multi-master, incremental replication protocol
using the LDAP protocol [LDAPv3]. This protocol uses and builds upon
previous LDAP support protocols, namely the changelog [change] and LDIF
[LDIF] protocols. It defines the use of two types of transport
protocols
for replication data, and specifies the schema that must be supported
by
a server that wishes to participate in replication activities using
this
protocol.
"The LDAP URL Format", Tim Howes, Mark Smith, 08/21/1997,
<draft-ietf-asid-ldapv3-url-04.txt>
LDAP is the Lightweight Directory Access Protocol, defined in [1],
[2] and [3]. This document describes a format for an LDAP Uniform
Resource Locator. The format describes an LDAP search operation to
perform to retrieve information from an LDAP directory. This document
replaces RFC1959. It updates the LDAP URL format for version 3 of LDAP
and clarifies how LDAP URLs are resolved. This document also defines
an extension mechanism for LDAP URLs, so that future documents can
extend their functionality, for example, to provide access to new
LDAPv3 extensions as they are defined.
The key words 'MUST', 'MAY', and 'SHOULD' used in this document are to
be interpreted as described in [6].
"The String Representation of LDAP Search Filters", Tim Howes,
10/20/1997, <draft-ietf-asid-ldapv3-filter-03.txt>
The Lightweight Directory Access Protocol (LDAP) [1] defines a network
representation of a search filter transmitted to an LDAP server. Some
applications may find it useful to have a common way of representing
these search filters in a human-readable form. This document defines a
human-readable string format for representing LDAP search filters.
This document replaces RFC 1960, extending the string LDAP filter
definition to include support for LDAP version 3 extended match
filters, and including support for representing the full range of
possible LDAP search filters.
"LDAP-based Routing of SMTP Messages: Approach Used by Netscape", H.
Lachman, 03/26/1997, <draft-ietf-asid-email-routing-ns-00.txt>
Directory services based on the Lightweight Directory Access Protocol
(LDAP) [1] and X.500 [2] provide a general-purpose means to store
information about users and other network entities. One of the many
possible uses of a directory service is to store information about
users' email accounts, such as their email addresses, and how messages
addressed to them should be routed. In the interest of
interoperability, it is desirable to have a common schema for such
email-related information. This document discusses some of the
fundamental questions to be considered in the development of a common
schema for LDAP-based routing of SMTP [3] messages, presents an
approach that has been implemented and deployed, and discusses possible
extensions to that approach that may serve to make it more complete and
general. The intent is to provide information about an existing
implementation, and to stimulate discussion about whether and how to
standardize the relevant aspects of LDAP-based messaging management.
"LDAP-based Routing of SMTP Messages: Approach at Stanford University",
J. Hodges, B. Bense, 03/27/1997,
<draft-ietf-asid-email-routing-su-00.txt>
The 'Internet X.500 Schema' defines an RFC-822 email address attribute
of a person's entry, rfc822Mailbox (aka 'Mail'), but it does not
address the issues involved in routing RFC-822-based email within an
administrative domain served by an X.500/LDAP-based directory service.
Significantly, it doesn't delineate between a person's publicaly
'advertised' or 'promoted' email address and the actual 'internal to
the administrative domain' address for the person.
This memo illustrates an object class and an attendant attribute we use
at Stanford University to solve this issue. This scheme provides us
with flexible, simple to implement, distributed routing of
RFC-822-based email to people represented by entries within our
directory service. The LDAP-enabled version of sendmail we use is
freely available. Additionally, we anticipate that the
Internet community will devise conventions and perhaps support a
process for facilitating multi-vendor directory utilization. We present
an anticipated tenet and goals.
"X.500 Strong Authentication Mechanisms for LDAPv3", M. Wahl, 03/27/1997,
<draft-ietf-asid-ldapv3-strong-00.txt>
This document defines two SASL [1] authentication mechanisms which may
be used with LDAPv3 [2]. These mechanisms are only for authentication,
they have no effect on the protocol encodings and are not designed to
provide integrity or confidentiality services.
"A Summary of the Pilot X.500 Schema for use in LDAPv3", M. Wahl,
03/27/1997, <draft-ietf-asid-schema-pilot-00.txt>
This document provides an overview of attribute types and object
classes for use in piloting directory services based on X.500 and LDAP.
"A Summary of the X.500(96) User Schema for use with LDAPv3", M. Wahl,
10/20/1997, <draft-ietf-asid-ldapv3schema-x500-03.txt>
This document provides an overview of the attribute types and object
classes defined by the ISO and ITU-T committees in the X.500 documents,
in particular those intended for use by directory clients. This is the
most widely used schema for LDAP/X.500 directories, and many other
schema definitions for white pages objects use it as a basis. This
document does not cover attributes used for the administration of X.500
directory servers, nor does it include attributes defined by other
ISO/ITU-T documents.
"LDAP Control Extension for Server Side Sorting of Search Results", Tim
Howes, M. Wahl, A. Herron, 04/17/1997,
<draft-ietf-asid-ldapv3-sorting-00.txt>
This document describes two LDAPv3 control extensions for server side
sorting of search results. These controls allows a client to specify
the attribute types and matching rules a server should use when
returning the results to an LDAP search request. The controls may be
useful when the LDAP client has limited functionality or for some other
reason cannot sort the results but still needs them sorted. Other
permissible controls on search operations are not defined in this
extension. The sort controls allow a server to return a
result code for the sorting of the results that is independent of the
result code returned for the search operation.
The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to
be interpreted as described in [bradner97].
"Referrals and Knowledge References in LDAP Directories", Tim Howes, M.
Wahl, 05/01/1997, <draft-ietf-asid-ldapv3-referral-00.txt>
This document defines a 'ref' attribute and associated 'referral'
object class for representing generic knowledge information in LDAP
directories [LDAP]. The attribute uses URIs [RFC1738] to represent
knowledge, enabling LDAP and non-LDAP services alike to be referenced.
The object class can be used to construct entries in an LDAP directory
containing references to other directories or services. This document
also defines procedures directory servers should follow when supporting
these schema elements.
"Lightweight Directory Access Protocol (v3): Extension for Transport
Layer Security", B. Morgan, J. Hodges, M. Wahl, 09/04/1997,
<draft-ietf-asid-ldapv3-tls-02.txt>
This document defines the 'Start Transport Layer Security (TLS)
Operation' for LDAP [LDAPv3, TLS]. This operation provides for TLS
establishment in an LDAP association and is defined in terms of an LDAP
extended request.
The key words 'MUST', 'SHOULD', and 'MAY' used in this document are to
be interpreted as described in [Bradner97].
"Lightweight Directory Access Protocol: Dynamic Attributes", Tony
Genovese, M. Wahl, Y. Yaacovi, 07/03/1997,
<draft-ietf-asid-ldap-dynatt-00.txt>
This document defines dynamic attributes and the fashion in which they
are being set and used on entries in the directory. This document
builds heavily on the dynamic extensions to LDAP infrastructure as
defined in [1].
The Lightweight Directory Access Protocol (LDAP) [2] supports
lightweight access to static directory services, allowing relatively
fast search and update access. Static directory services store
information about people that persists in its accuracy and value over a
long period of time.
"The vCard Schema For Use In LDAPv3", F. Dawson, M. O'Brien, 07/08/1997,
<draft-ietf-asid-ldapv3schema-vcard-00.txt>
The Lightweight Directory Access Protocol (LDAP) [LDAPV3] is gaining
widespread acceptance as a method for accessing Internet directories.
Many of the LDAP clients accessing these directories also provide
support for emitting the directory information in the form of a vCard
electronic business card object. This memo defines a new X.500 object
class, called the vCardObject, that extends the X.521 standard
organizationalPerson and residentialPerson in order to provide a unique
LDAP schema for accessing Internet directories in terms of the vCard
attributes. The schema defined by this memo should
be used when accessing a directory via LDAP Version 3 and searching or
retrieving directory information based on vCard related attributes. The
schema describes the attribute types and object classes that have a
1-to-one correspondence with vCard properties. This schema may also be
used to define a set of object classes and attributes for storing
metadata and binding information for a directory entry that closely
follows the vCard object in directories that support LDAP.
"LDAP Replication Requirements", E. Stokes, R. Weiser, 07/24/1997,
<draft-ietf-asid-replica-req-00.txt>
This document discusses some of the fundamental requirements for
replication and synchronization of the LDAPv3 [LDAPv3] protocol. It is
intended to be a gathering place for general replication requirements
needed to provide interoperability between informational directories.
"The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R.
Weltman, 09/28/1997, <draft-ietf-asid-ldap-java-api-01.txt>
This document defines a java language application program interface to
the lightweight directory access protocol (LDAP), in the form of a
class
library. It complements but does not replace RFC 1823 ([9]), which
describes a C language application program interface. It updates and
replaces draft-ietf-asid-ldap-java-api-00.txt [13], in adding
clarifica-
tion on behavior under various circumstances, and in revising support
for language-sensitive attribute parsing. Other additions and correc-
tions are listed in the appendix.
"Schema for Replication Information", G. Good, U. Srinivasan, S. Jain,
10/08/1997, <draft-ietf-asid-ldap-repl-info-01.txt>
This document defines a new attribute syntax and an operational
attribute type to store replication agreements within the directory.
In addition it defines a framework to detect whether an entry is a
master or replica. The replication agreement structure defined here
includes a placeholder to specify the replication protocol associated
with an agreement. This document itself does not define any
replication protocol. Replication protocols and replication agreements
are seen as orthogonal issues.
"LDAP API Extensions for Sort and Simple Paged Results", Chris Weider,
Tim Howes, Mark Smith, M. Wahl, A. Herron, 07/30/1997,
<draft-ietf-asid-ldapv3-api-ext-00.txt>
This document defines extensions to the LDAP v3 C language API defined
in [1]. These extensions cover the sort extended control, defined in
[2],
and the simple paged results control, defined in [3]. N.B.: while the
sort extended control can be used on its own, the simple paged results
control is most useful when used on results that have already been
sorted.
"Referral Whois Protocol (RWhois) 2.0", Scott Williamson, M. Mealling,
Mark Kosters, J. Singh, Greg Pierce, D. Blacka, K. Zeilstra, 07/30/1997,
<draft-ietf-asid-rwhois-00.txt>
This memo describes Version 2.0 of the client/server interaction of
RWhois. RWhois provides a distributed system for the display of
hierarchical and non-hierarchical information. This system is primarily
hierarchical by design, allowing for the deterministic reduction of a
query and the referral of the user closer to the maintainer of the
information. It also identifies the attributes that are
non-hierarchical so that they may be indexed into a mesh.
"The C LDAP Application Program Interface", Chris Weider, Tim Howes, Mark
Smith, M. Wahl, A. Herron, 07/31/1997,
<draft-ietf-asid-ldap-c-api-00.txt>
This document defines a C language application program interface to the
lightweight directory access protocol (LDAP). This document replaces
the
previous definition of this API, defined in RFC 1823, updating it to
include support for features found in version 3 of the LDAP protocol.
New extended operation functions were added to support LDAPv3 features
such as controls. In addition, other LDAP API changes were made to
support information hiding and thread safety.
The C LDAP API is designed to be powerful, yet simple to use. It
defines
compatible synchronous and asynchronous interfaces to LDAP to suit a
wide variety of applications. This document gives a brief overview of
the LDAP model, then an overview of how the API is used by an applica-
tion program to obtain LDAP information. The API calls are described
in
detail, followed by an appendix that provides some example code demon-
strating the use of the API. This document provides information to the
Internet community. It does not specify any standard.
"Java LDAP Controls", R. Weltman, 09/28/1997,
<draft-ietf-asid-ldap-java-controls-00.txt>
This document defines support for the Preferred Language Control, the
Server Sorting Control, and the Virtual List Control in the java LDAP
API. Controls are an LDAP protocol version 3 extension, to allow pass-
ing arbitrary control information along with a standard request to a
server, and to receive arbitrary information back with a standard
result.
AToM MIB (atommib)
------------------
"Definitions of Supplemental Managed Objects for ATM Management", Kaj
Tesink, A. Smith, E. Spiegel, F. Ly, M. Noto, 08/04/1997,
<draft-ietf-atommib-atm2-11.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community.
"Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM
Management", Kaj Tesink, E. Spiegel, M. Noto, 03/06/1997,
<draft-ietf-atommib-atm2TC-06.txt>
This memo describes Textual Conventions and OBJECT-IDENTITIES used for
managing ATM-based interfaces, devices, networks and services.
"Definitions of Tests for ATM Management", Kaj Tesink, M. Noto,
06/09/1997, <draft-ietf-atommib-test-03.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing
ATM-based interfaces, devices, networks and services in addition to
those defined in the ATM MIB [1], to provide additional support for the
management of ATM Loopback Tests.
"Managed Objects for Controlling the Collection and Storage of Accounting
Information for Connection-Oriented Networks", Keith McCloghrie, Juha
Heinanen, A. Prasad, W. Greene, 06/10/1997,
<draft-ietf-atommib-acct-04.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
controlling the collection and storage of accounting information for
connection-oriented networks such as ATM. The accounting data is
collected into files for later retrieval via a file transfer protocol.
For information on data which can be collected for ATM networks, see
[9].
"Definitions of Managed Objects for ATM Management", Kaj Tesink,
02/12/1997, <draft-ietf-atommib-atm1ng-03.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing
ATM-based interfaces, devices, networks and services.
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions. This memo does not specify a standard for the Internet
community.
"Textual Conventions for MIB Modules Using Performance History Based on
15 Minute Intervals", Kaj Tesink, 05/12/1997,
<draft-ietf-atommib-perfhistTC-01.txt>
When designing a MIB module, it is often useful to define new types
similar to those defined in the SMI. In comparison to a type defined
in the SMI, each of these new types has a different name, a similar
syntax, but a more precise semantics. These newly defined types are
termed textual conventions, and are used for the convenience of humans
reading the MIB module. This is done through Textual Conventions as
defined in RFC1903[1]. It is the purpose of this document to define
the set of textual conventions to be used when performance history
based on 15 minute intervals is kept. See for example the Trunk MIB
modules [3][4][5]. This memo does not specify a standard for the
Internet community.
"Definitions of Managed Objects for the SONET/SDH Interface Type", Tracy
Brown, Kaj Tesink, 07/07/1997, <draft-ietf-atommib-sonetng-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 defines objects for managing Synchronous
Optical Network/Synchronous Digital Hierarchy (SONET/SDH) objects.
This document is a companion document with Definitions of Managed
Objects for the DS1/E1 and DS3/E3 Interface Types, RFC1406 [14] and
RFC1407 [13]. This memo specifies a MIB module in a manner that is
both compliant to the SNMPv2 SMI, and semantically identical to the
peer SNMPv1 definitions.
"Accounting Information for ATM Networks", Keith McCloghrie, Juha
Heinanen, A. Prasad, W. Greene, 06/06/1997,
<draft-ietf-atommib-atmacct-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. A separate memo [8] defines managed objects, in a manner
independent of the type of network, for controlling the selection,
collection and storage of accounting information into files for later
retrieval via a file transfer protocol. This memo defines a set of
ATM-specific accounting information which can be collected for
connections on ATM networks.
"Managed Objects for Recording ATM Performance History Data Based on 15
Minute Intervals", G. Mouradian, 06/10/1997,
<draft-ietf-atommib-atmhist-00.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects to record and
retrieve ATM performance history data recorded in 15 minute interval.
The functionality defined in this document is intended to satisfy the
requirements defined by the ATM Forum in [9].
Audio/Video Transport (avt)
---------------------------
"RTP usage with Layered Multimedia Streams", M. Speer, S. McCanne,
06/24/1997, <draft-speer-avt-layered-video-02.txt>
This draft describes how one should make use of RTP (rfc1889) when
employing layered media streams. This document is meant for
implementors of internet multimedia applications that want to use RTP
and layered media streams.
"RTP Payload Format for H.263 Video Streams", C. Zhu, 09/11/1997,
<draft-ietf-avt-rtp-payload-04.txt>
This document specifies the payload format for encapsulating an H.263
bitstream in the Real-Time Transport Protocol (RTP). Three modes are
defined for the H.263 payload header. An RTP packet can use one of the
three modes for H.263 video streams depending on the desired
network packet size and H.263 encoding options employed.
The shortest H.263 payload header (mode A) supports fragmentation
at Group of Block (GOB) boundaries. The long H.263 payload headers
(mode B and C) support fragmentation at Macroblock (MB) boundaries.
"RTP Payload Format for Bundled MPEG", R. Civanlar, G. Cash, B. Haskell,
02/27/1997, <draft-civanlar-bmpeg-01.txt>
This document describes a payload type for bundled, MPEG-2 encoded
video and audio data to be used with RTP, version 2. Bundling has some
advantages for this payload type particularly when it is used for
video-on-demand applications. This payload type is to be used when its
advantages are important enough to sacrifice the modularity of having
separate audio and video streams.
A technique to improve packet loss resilience based on 'out-of-band'
transmission of MPEG-2 specific, vital information is described also.
"Alternatives for Enhancing RTCP Scalability", B. Aboba, 01/29/1997,
<draft-aboba-rtpscale-02.txt>
This document discusses current issues with RTCP scalability as well as
describing the advantages and disadvantages of possible solutions.
"Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", V. Jacobson,
Stephen Casner, 07/14/1997, <draft-ietf-avt-crtp-03.txt>
This document describes a method for compressing the headers of
IP/UDP/RTP datagrams to reduce overhead on low-speed serial links. In
many cases, all three headers can be compressed to 2-4 bytes.
Comments are solicited and should be addressed to the working group
mailing list rem-conf@es.net and/or the author(s).
"Real-Time Transport Protocol Management Information Base", S. Naudus, M.
Baugher, J. Du, 03/26/1997, <draft-ietf-avt-rtp-mib-00.txt>
This memo defines an experimental Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing Real-Time Transport
Protocol Systems [1]. Comments should be made to the IETF Audio/Video
Transport Working Group.
This memo does not specify a standard for the Internet community.
"RTP Profile for Audio and Video Conferences with Minimal Control", H.
Schulzrinne, 07/31/1997, <draft-ietf-avt-profile-new-01.txt,.ps>
This memo describes a profile called 'RTP/AVP' for the
use of the real-time transport protocol (RTP), version 2,
and the associated control protocol, RTCP, within audio
and video multiparticipant conferences with minimal
control. It provides interpretations of generic fields
within the RTP specification suitable for audio and video
conferences. In particular, this document defines a set
of default mappings from payload type numbers to
encodings.
The document also describes how audio and video data may
be carried within RTP. It defines a set of standard
encodings and their names when used within RTP. However,
the encoding definitions are independent of the
particular transport mechanism used. The descriptions
provide pointers to reference implementations and the
detailed standards. This document is meant as an aid for
implementors of audio, video and other real-time
multimedia applications.
"RTP Payload Format for MPEG1/MPEG2 Video", D. Hoffman, G. Fernando, V.
Goyal, R. Civanlar, 06/27/1997, <draft-ietf-avt-mpeg-new-01.txt>
This memo describes a packetization scheme for MPEG video and audio
streams. The scheme proposed can be used to transport such a video or
audio flow over the transport protocols supported by RTP. Two
approaches are described. The first is designed to support maximum
interoperability with MPEG System environments. The second is designed
to provide maximum compatibility with other RTP-encapsulated media
streams and future conference control work of the IETF.
This memo is a revision of RFC 2038, an Internet standards track
protocol, prepared for publication as a revised RFC. In this revision,
the packet loss resilience mechanisms in Section 3.4 were extended to
include additional picture header information required for MPEG2.
"RTP Payload Format for QuickTime Media Streams", D. Singer, 07/23/1997,
<draft-ietf-avt-qt-rtp-00.txt>
This document specifies the payload format for encapsulating QuickTime
media streams in the Realtime Transport Protocol (RTP). This
specification is intended for QuickTime media/codec types that are not
already handled by other RTP payload specifications. Each QuickTime
media track within a movie is sent over a separate RTP session and
synchronized using standard RTP techniques. A static QuickTime payload
type (if assigned) or a dynamic payload type may be used. A QuickTime
header within the RTP payload is defined to carry the media type and
other media specific information. A packetization scheme is defined for
the media data. This specification is intended for streaming stored
QuickTime movies as well as live QuickTime content.
"RTP Payload for DTMF Digits", H. Schulzrinne, 07/31/1997,
<draft-ietf-avt-dtmf-00.txt,.ps>
This memo describes how to carry dual-tone multifrequency
(DTMF) signaling in RTP packets.
"An A/V Profile Extension for Generic Forward Error Correction in RTP",
J. Rosenberg, H. Schulzrinne, 08/04/1997, <draft-ietf-avt-fec-00.txt>
This document specifies an extension to RFC 1890 which allows for
forward correction (FEC) of continuous media encapsulated in RTP.
The
profile is engineered for FEC algorithms based on the exclusive or
(parity) operation, although it can be used with other techniques.
The profile extension allows end systems to transmit using arbitrary
block lengths and parity schemes. It also allows for the recovery of
both the payload and critical RTP header fields. It is backwards
com-
patible with existing RFC 1890 implementations, so that receivers
which do not wish to implement FEC can just ignore the extensions.
"Options for Repair of Streaming Media", O Hodson, 08/21/1997,
<draft-ietf-avt-info-repair-00.txt>
This document summarizes a range of possible techniques
for the repair of continuous media streams subject to packet
loss. The techniques discussed include redundant transmission,
retransmission, interleaving and forward error correction.
The range of applicability of these techniques is noted,
together with the protocol requirements and dependencies.
Benchmarking Methodology (bmwg)
-------------------------------
"Benchmarking Terminology for LAN Switching Devices", B. Mandeville,
09/18/1997, <draft-ietf-bmwg-lanswitch-07.txt>
This document is intended to provide terminology
for the benchmarking of local area network (LAN) switching devices.
It extends the terminology already defined for benchmarking network
interconnect devices in RFCs 1242 and 1944 to switching devices.
Although it might be found useful to apply some of the terms defined
here to a broader range of network interconnect devices, this RFC
primarily deals with devices which switch frames at the Medium
Access Control (MAC) layer. It defines terms in relation to the
traffic put to use when benchmarking switching devices, forwarding
performance, congestion control, latency, address handling and
filtering.
"Terminology for Cell/Call Benchmarking", R. Craig, 03/25/1997,
<draft-ietf-bmwg-call-01.txt>
The purpose of this draft is to add terminology specific to the cell
and call-based switch environment to that defined by the Benchmarking
Methodology Working Group (BMWG) of the Internet Engineering Task Force
(IETF) in RFC1242.
While primarily directed towards wide area switches, portions of the
document may be useful for benchmarking other devices such as ADSU's.
"A One-way Delay Metric for IPPM", Guy Almes, S. Kalidindi, 08/04/1997,
<draft-ietf-bmwg-ippm-delay-02.txt>
This memo defines a metric for one-way delay of packets across Inter-
net paths. It builds on notions introduced and discussed in the
IPPM
Framework document (currently 'Framework for IP Provider
Metrics'
<draft-ietf-bmwg-ippm-framework-01.txt>); the reader is assumed to
be
familiar with that document.
This memo is intended to be very parallel in structure to a
companion
document for Packet Loss ('A Packet Loss Metric for IPPM'
<draft-
ietf-bmwg-ippm-loss-01.txt>).
+ A 'singleton' analytic metric, called Type-P-One-way-Delay,
will
be introduced to measure a single observation of one-way delay.
+ Using this singleton metric, a 'sample', called
Type-P-One-way-
Delay-Stream, will be introduced to measure a sequence of
single-
ton delays measured at times taken from a Poisson process.
+ Using this sample, several 'statistics' of the sample will
be
defined and discussed.
This progression from singleton to sample to statistics, with
clear
separation among them, is important.
Whenever a technical term from the IPPM Framework document is
first
used in this memo, it will be tagged with a trailing asterisk,
as
with >>term*<<.
"Empirical Bulk Transfer Capacity", Matt Mathis, 08/04/1997,
<draft-ietf-bmwg-ippm-treno-btc-01.txt>
Bulk Transport Capacity (BTC) is a measure of a network's ability to
transfer significant quantities of data with a single congestion-aware
transport connection (e.g. state-of-the-art TCP). For many
applications the BTC of the underlying network dominates the the
overall elapsed time for the application, and thus dominates the
performance as perceived by a user.
The BTC is a property of an IP cloud (links, routers, switches, etc)
between a pair of hosts. It does not include the hosts themselves (or
their transport-layer software). However, congestion control is
crucial to the BTC metric because the Internet depends on the end
systems to fairly divide the available bandwidth on the basis of common
congestion behavior. The BTC metric is based on the performance of a
reference congestion control algorithm that has particularly uniform
and stable behavior.
"Framework for IP Provider Metrics", Guy Almes, J. Mahdavi, Vern Paxson,
08/01/1997, <draft-ietf-bmwg-ippm-framework-01.txt>
The purpose of this memo is to define a general framework for
partic-
ular metrics to be developed by the IETF's IP Performance
Metrics
effort, begun by the Benchmarking Methodology Working Group (BMWG)
of
the Operational Requirements Area, and being continued by the IP
Per-
formance Metrics Working Group (IPPM) of the Transport Area.
"Terminology for IP Multicast Benchmarking", Kevin Dubray, 08/02/1997,
<draft-ietf-bmwg-mcast-02.txt>
The purpose of this draft is to add terminology specific to the
benchmarking of multicast IP forwarding devices. It builds upon the
tenets set forth in RFC 1242, RFC 1944, and other IETF Benchmarking
Methodology Working Group (BMWG) effort and extends them to the
multicast paradigm.
"A Packet Loss Metric for IPPM", Guy Almes, S. Kalidindi, 08/04/1997,
<draft-ietf-bmwg-ippm-loss-01.txt>
This memo defines a metric for packet loss across Internet paths. It
builds on notions introduced and discussed in the IPPM Framework
document (currently 'Framework for IP Provider Metrics'
<draft-ietf-bmwg-ippm-framework-00.txt>); the reader is assumed to
be familiar with that document.
This memo is intended to be very parallel in structure to a companion
document for One-way Delay (currently 'A One-way Delay Metric for
IPPM' <draft-ietf-bmwg-ippm-delay-00.txt>); the reader is assumed to
be familiar with that document.
"Benchmarking Terminology for Network Security Devices", David Newman,
07/30/1997, <draft-ietf-bmwg-secperf-00.txt>
This document defines terms used in measuring the performance of
network security devices. It extends the terminology already used
for benchmarking routers and switches to network security devices.
The primary metrics defined in this document are maximum
forwarding rate and maximum number of connections.
Calendaring and Scheduling (calsch)
-----------------------------------
"Internet Calendaring and Scheduling Core Object Specification
(iCalendar)", F. Dawson, D. Stenerson, 10/31/1997,
<draft-ietf-calsch-ical-04.txt>
There is a clear need to provide and deploy interoperable
calendaring
and scheduling services for the Internet. Current group scheduling
and Personal Information Management (PIM) products are being
extended
for use across the Internet, today, in proprietary ways. This memo
has been defined to provide the a definition of a common format for
openly exchanging calendaring and scheduling information across the
Internet.
This memo is formatted as a registration for a MIME media type per
[RFC 2048]. However, the format in this memo is equally applicable
for use outside of a MIME message content type.
The proposed media type value is ''TEXT/CALENDAR''. This string
would
label a media type containing calendaring and scheduling information
encoded as text characters formatted in a manner outlined below.
This MIME media type provides a standard content type for capturing
calendar event and to-do information. It also can be used to convey
free/busy time information. The content type is suitable as a MIME
message entity that can be transferred over MIME based email systems
or using HTTP. In addition, the content type is useful as an object
for interactions between desktop applications using the operating
system clipboard, drag/drop or file systems capabilities.
This memo is based on the earlier work of the vCalendar
specification
for the exchange of personal calendaring and scheduling information.
In order to avoid confusion with this referenced work, this memo is
to be known as the iCalendar specification. This memo is based on
the
calendaring and scheduling model defined in []. The document is also
the basis for the calendaring and scheduling interoperability
protocol defined in [ITIP].
This memo also includes the format for defining iCalendar object
methods. An iCalendar object method is a set of usage constraints
for
the iCalendar object. For
"Core Object Specification - Issues Document", F. Dawson, Anik Ganguly,
D. Stenerson, 04/29/1997, <draft-ietf-calsch-ical-issues-01.txt>
This document is an IETF CALSCH working group document. The document is
used as a tool for recording issues and their resolution with mailing
list discussions.
This Issues Document is intended to track the resolution of issues
related to the 'Core Object Specification' deliverable.
The most current version of this document can be found on the IETF
CALSCH Working Group document archive at http://www.imc.org.
Issues within this document are classified as either being OPEN or
RESOLVED. Additionally, an issue may be found to no longer be a concern
and may be classified as WITHDRAWN. Issues falling into each of these
categories are listed in a separate section.
An issue is documented with a short summary title, a brief description,
and a list of identified alternatives. A resolved issue will also
include a description of the resolution and the date/venue that the
resolution was reached.
Distribution of this document is unlimited.
"Calendaring Interoperability over HTTP (CIH)", S. Hanna, 02/10/1997,
<draft-ietf-calsch-cih-00.txt>
Calendaring Interoperability over HTTP (CIH) is a technique for
exchanging calendaring information between scheduling systems using the
Hypertext Transfer Protocol (HTTP). This allows users to schedule
meetings with anyone else, no matter what scheduling software they use.
This document is a tentative exploration of whether CIH is feasible and
what the pros and cons are relative to a brand new protocol like the
Calendaring Interoperability Protocol (CIP). The primary benefit of CIH
over CIP and motivation for this project is that we avoid implementing
a whole new protocol, such as writing and debugging the protocol,
convincing vendors to write new code to support it, and then convincing
users to deploy it.
"Real-time Protocol Requirements", Anik Ganguly, 03/28/1997,
<draft-ietf-calsch-rtreq-00.txt>
The purpose of this document is to create a framework for selecting the
appropriate solution for a real-time protocol designed to allow
calendaring and scheduling systems from different vendors to
interoperate. To that end, it describes the assumptions about the
context in which this protocol will operate, and the requirements that
the protocol must meet. These requirements are not intended to apply
to a companion protocol which will use E-mail based transport to
achieve interoperability. The E-mail based protocol, which is the
subject of a different document, will not make any assumptions about
transport latency.
"iCalendar Message-based Interoperability Protocol (iMIP)", F. Dawson, S.
Mansour, S. Silverberg, 10/27/1997, <draft-ietf-calsch-imip-02.txt>
This document specifies a binding from the iCalendar Transport-
independent Interoperability Protocol [ITIP] to Internet email-based
transports. Calendaring entries defined by the iCalendar Object
Model
[ICAL] are composed using constructs from [RFC-822], [RFC-2045],
[RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].
This document is based on the calendaring and scheduling model
defined by [ICMS].
This document is based on discussions within the Internet
Engineering
Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
More information about the IETF CALSCH working group activities can
be found on the IMC website at http://www.imc.org, the IETF website
at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
the references within this document for further information on how
to
access these various documents.
Distribution of this document is unlimited. Comments and suggestions
for improvement should be sent to the authors.
"Internet Calendar Model Specification", John Noerenberg, 10/27/1997,
<draft-ietf-calsch-mod-02.txt>
Internet Calendaring and Scheduling protocols require the definition of
objects to encapsulate an event to be scheduled, a calendar on which
the event will be stored, and means for exchanging these objects across
the Internet between calendars on behalf of people for whom the
calendars are meaningful. This document gives an abstract model of the
objects and the protocols necessary to accomplish this kind of
information exchange. It will establish the context in which other
Calendaring and Scheduling RFCs can be interpreted. Included are brief
introductions to the other components of Internet calendar protocols
and definitions of nomenclature common to all documents defining these
protocols. Reading this document will enable implementors and users of
Internet Calendaring and Scheduling protocols to understand the goals
and constraints chosen for related protocols.
"iCalendar Transport-Independent Interoperability Protocol (iTIP)
Scheduling Events, BusyTime, To-dos and Journal Entries", R. Hopson, S.
Mansour, Frank Dawson Jr., S. Silverberg, 10/28/1997,
<draft-ietf-calsch-itip-01.txt>
This document specifies how calendaring systems use iCalendar objects
to interoperate with other calendar systems. It does so in a general
way so as to allow multiple methods of communication between
systems.
Subsequent documents specify interoperable methods of communications
between systems that use this protocol.
The document outlines a model for calendar exchange that defines
both
static and dynamic event, to-do, journal and free/busy objects.
Static objects are used to transmit information from one entity to
another without the expectation of continuity or referential
integrity with the original item. Dynamic objects are a superset of
static objects and will gracefully degrade to their static
counterparts for clients that only support static objects.
Common Authentication Technology (cat)
--------------------------------------
"Independent Data Unit Protection Generic Security Service Application
Program Interface (IDUP-GSS-API)", C. Adams, 10/14/1997,
<draft-ietf-cat-idup-gss-08.txt>
The IDUP-GSS-API extends the GSS-API [RFC-2078] for applications
requiring protection of a generic data unit (such as a file or
message) in a way which is independent of the protection of any
other
data unit and independent of any concurrent contact with designated
'receivers' of the data unit. Thus, it is suitable for applications
such as secure electronic mail where data needs to be protected
without any on-line connection with the intended recipient(s) of
that
data. The protection offered by IDUP includes services such as data
origin authentication with data integrity, data confidentiality with
data integrity, and support for non-repudiation services.
Subsequent
to being protected, the data unit can be transferred to the
recipient(s) - or to an archive - perhaps to be processed
('unprotected') only days or years later.
Throughout the remainder of this document, the 'unit' of data
described in the above paragraph will be referred to as an IDU
(Independent Data Unit). The IDU can be of any size (the
application
may, if it wishes, split the IDU into pieces and have the protection
computed a piece at a time, but the resulting protection token
applies to the entire IDU). However, the primary characteristic of
an IDU is that it represents a stand-alone unit of data whose
protection is entirely independent of any other unit of data. If an
application protects several IDUs and sends them all to a single
receiver, the IDUs may be unprotected by that receiver in any order
over any time span; no logical connection of any kind is implied by
the protection process itself.
As with RFC-2078, this IDUP-GSS-API definition provides security
services to callers in a generic fashion, supportable with a range
of
underlying mechanisms and technologies and hence allowing source-
level portability of applications to different environments. This
specification
"Public Key Cryptography for Initial Authentication in Kerberos",
Clifford Neuman, John Wray, B. Tung, J. Trostle, A. Medvinsky,
08/01/1997, <draft-ietf-cat-kerberos-pk-init-04.txt>
This document defines extensions (PKINIT) to the Kerberos protocol
specification (RFC 1510 [1]) to provide a method for using public
key cryptography during initial authentication. The methods
defined specify the ways in which preauthentication data fields and
error data fields in Kerberos messages are to be used to transport
public key data.
"Generic Security Service API Version 2 : C-bindings", John Wray,
03/20/1997, <draft-ietf-cat-gssv2-cbind-04.txt>
This draft document specifies C language bindings for Version 2 of the
Generic Security Service Application Program Interface (GSSAPI), which
is described at a language-independent conceptual level in other drafts
[GSSAPI]. It revises RFC-1509, making specific incremental changes in
response to implementation experience and liaison requests. It is
intended, therefore, that this draft or a successor version thereof
will become the basis for subsequent progression of the GSS-API
specification on the standards track.
The Generic Security Service Application Programming Interface provides
security services to its callers, and is intended for implementation
atop a variety of underlying cryptographic mechanisms. Typically,
GSSAPI callers will be application protocols into which security
enhancements are integrated through invocation of services provided by
the GSSAPI. The GSSAPI allows a caller application to authenticate a
principal identity associated with a peer application, to delegate
rights to a peer, and to apply security services such as
confidentiality and integrity on a per-message basis.
"Independent Data Unit Protection Generic Security Service Application
Program Interface: C-bindings", D. Thakkar, S. Klump, 04/16/1997,
<draft-ietf-cat-idup-cbind-03.txt>
The Independent Data Unit Protection Generic Security Service
Application Program Interface (IDUP-GSS-API) extends the GSS-API
[RFC-1508] for applications requiring protection of a generic data unit
(such as a file or message) in a way that is independent of the
protection of any other data unit and independent of any concurrent
contact with designated 'receivers' of the data unit. Thus, it is
suitable for applications such as secure electronic mail where data
needs to be protected without any on-line connection with the intended
recipient(s) of that data. The protection offered by the IDUP includes
data origin authentication with data integrity, data confidentiality
with data integrity, and support for non-repudiation services.
Subsequent to being protected, the independent data unit can be
transferred to the recipient(s) - or to an archive - perhaps to be
processed ('unprotected') only days or years later. The
Independent Data Unit Protection Generic Security Service Application
Program Interface for Signing and Encrypting (IDUP-SE) provides a
simplified API for the services of signing and encrypting.
"The Simple and Protected GSS-API Negotiation Mechanism", D. Pinkas, E.
Baize, 07/22/1997, <draft-ietf-cat-snego-06.txt>
This draft document specifies a Security Negotiation Mechanism for the
Generic Security Service Application Program Interface (GSS-API) which
is described in [1]. The GSS-API provides a generic interface
which can be layered atop different security mechanisms such that if
communicating peers acquire GSS-API credentials for the same security
mechanism, then a security context may be established between them
(subject to policy). However, GSS-API doesn't prescribe the method by
which GSS-API peers can establish whether they have a common security
mechanism. The Simple and Protected GSS-API Negotiation
Mechanism defined here is a pseudo-security mechanism, represented by
the object identifier iso.org.dod.internet.security.mechanism.snego
(1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band
whether their credentials share common GSS-API security mechanism(s),
and if so, to invoke normal security context establishment for a
selected common security mechanism. This is most useful for
applications that are based on GSS-API implementations which support
multiple security mechanisms.
"Extended Generic Security Service APIs: XGSS-APIs Access control and
delegation extensions", D. Pinkas, T. Parker, 03/24/1997,
<draft-ietf-cat-xgssapi-acc-cntrl-02.txt>
The Generic Security Service Application Program Interface (GSS-API),
as defined in RFC-1508, provides security services to callers in a
generic fashion, supportable with a range of underlying mechanisms and
technologies and hence allowing source-level portability of
applications to different environments. It defines GSS-API services and
primitives at a level independent of underlying mechanism and
programming language environment. The GSSAPI allows a caller
application to authenticate a principal identity associated with a peer
application, to delegate rights to a peer, and to apply security
services such as confidentiality and integrity on a per-message basis.
The primitives of the GSS-API do not currently allow support of
security attributes other than a single identity and do not allow fine
control of delegation.
"Public Key Cryptography for Cross-Realm Authentication in Kerberos", G.
Tsudik, Clifford Neuman, B. Sommerfeld, B. Tung, M. Hur, T. Ryutov, A.
Medvinsky, 08/01/1997, <draft-ietf-cat-kerberos-pk-cross-02.txt>
This document defines extensions to the Kerberos protocol
specification (RFC 1510, 'The Kerberos Network Authentication
Service (V5)', September 1993) to provide a method for using
public key cryptography during cross-realm authentication. The
methods defined here specify the way in which message exchanges
are to be used to transport cross-realm secret keys protected by
encryption under public keys certified as belonging to KDCs.
"Public Key Utilizing Tickets for Application Servers (PKTAPP)", Clifford
Neuman, M. Hur, A. Medvinsky, 02/17/1997, <draft-ietf-cat-pktapp-00.txt>
Public key based Kerberos for Distributed Authentication[1], (PKDA)
proposed by Sirbu & Chuang, describes PK based authentication that
eliminates the use of a centralized key distribution center while
retaining the advantages of Kerberos tickets. This draft describes
how, without any modification, the PKINIT specification[2] may be used
to implement the ideas introduced in PKDA. The benefit is that only a
single PK Kerberos extension is needed to address the goals of PKINIT &
PKDA.
"Kerberos Change Password Protocol", M. Horowitz, 03/10/1997,
<draft-ietf-cat-kerb-chg-password-00.txt>
The Kerberos V5 protocol [RFC1510] does not describe any mechanism for
users to change their own passwords. In order to promote
interoperability between workstations, personal computers, terminal
servers, routers, and KDC's from multiple vendors, a common password
changing protocol is required.
"Integrity Protection for the Kerberos Error Message", G. Tsudik, B.
Tung, M. Hur, A. Medvinsky, 03/26/1997,
<draft-ietf-cat-kerberos-err-msg-00.txt>
The Kerberos error message, as defined in RFC 1510, is transmitted to
the client without any integrity assurance. Therefore, the client has
no means to distinguish between a valid error message sent from the KDC
and one sent by an attacker. This draft describes a method for
assuring the integrity of Kerberos error messages, and proposes a
consistent format for the e-data field in the KRB_ERROR message. This
e-data format enables the storage of cryptographic checksums by
providing an extensible mechanism for specifying e-data types.
"The Kerberos Network Authentication Service (V5)", Theodore Ts'o,
Clifford Neuman, 07/14/1997, <draft-ietf-cat-kerberos-revisions-00.txt>
This document provides an overview and specification of Version 5 of
the Kerberos protocol, and updates RFC1510 to clarify aspects of the
protocol and its intended use that require more detailed or
clearer explanation than was provided in RFC1510. This document is
intended to provide a detailed description of the protocol, suitable
for implementation, together with descriptions of the appropriate use
of protocol messages and fields within those messages.
"Encryption using KEA and SKIPJACK", P. Yee, Russ Housley, W. Nace,
07/21/1997, <draft-ietf-cat-ftpkeasj-00.txt>
This document defines a method to encrypt a file transfer using the FTP
specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985)
and the work in progress document 'FTP Security Extensions'
draft-ietf-cat-ftpsec-09.txt[1]. This method will use the Key Exchange
Algorithm (KEA) to give mutual authentication and establish the data
encryption keys. SKIPJACK is used to encrypt file data and the FTP
command channel.
"FTP Authentication Using DSA", P. Yee, Russ Housley, W. Nace,
07/21/1997, <draft-ietf-cat-ftpdsaauth-00.txt>
This document defines a method to secure file transfers using the FTP
specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985)
and the work in progress document 'FTP Security Extensions'
Draft-ietf-cat-ftpsec-09.txt[1]. This method will use the extensions
proposed in the 'FTP Security Extensions' Draft document along with a
public/private digital signature.
"Anonymous Credentials in Kerberos", J. Cargille, M. Hur, A. Medvinsky,
09/22/1997, <draft-ietf-cat-kerberos-anoncred-00.txt>
This document defines the concept of anonymous Kerberos
credentials, and describes how such credentials can be securely
obtained from a Kerberos KDC via the PKINIT extension. This draft
defines no new mechanisms or protocols; instead, it defines the
concepts and proposes usage and naming conventions.
"Generic Security Service Application Program Interface, Version 2",,
09/23/1997, <draft-ietf-cat-rfc2078bis-00.txt>
The Generic Security Service Application Program Interface
(GSS-API),
Version 2, as defined in RFC-2078, provides security services to
callers in a generic fashion, supportable with a range of underlying
mechanisms and technologies and hence allowing source-level
portability of applications to different environments. This
specification defines GSS-API services and primitives at a level
independent of underlying mechanism and programming language
environment, and is to be complemented by other, related
specifications:
documents defining specific parameter bindings for particular
language environments
documents defining token formats, protocols, and procedures to be
implemented in order to realize GSS-API services atop particular
security mechanisms
This Internet-Draft revises RFC-2078, making specific, incremental
changes in response to implementation experience and liaison
requests. It is intended, therefore, that this draft or a successor
version thereto will become the basis for subsequent progression of
the GSS-API specification on the standards track.
"User to User Kerberos Authentication using GSS-API Preliminary Draft",
Michael Swift, 10/27/1997, <draft-ietf-cat-user2user-00.txt>
This draft proposes a simple extension to the Kerberos
GSS-API mechanism to support user to user authentication
both in the case where the client application explicitly
requests user to user authentication and when it does not
know whether the server supports user to user
authentication.
"Kerberos over IPv6", Assar Westerlund, 10/29/1997,
<draft-ietf-cat-krb5-ipv6-00.txt>
This document specifies the address types and transport types
necessary for using Kerberos [RFC1510] over IPv6 [RFC1883].
Dynamic Host Configuration (dhc)
--------------------------------
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", C. Perkins, J.
Bound, 05/28/1997, <draft-ietf-dhc-dhcpv6-10.txt>
The Dynamic Host Configuration Protocol (DHCPv6) provides a framework
for passing configuration information, via extensions, to IPv6 nodes.
It offers the capability of automatic allocation of reusable network
addresses and additional configuration flexibility. This protocol
should be considered a stateful counterpart to the IPv6 Stateless
Address Autoconfiguration protocol specification.
"Interaction between DHCP and DNS", Y Rekhter, 05/19/1997,
<draft-ietf-dhc-dhcp-dns-04.txt>
DHCP provides a powerful mechanism for IP host autoconfiguration.
However, the autoconfiguration provided by DHCP does not include
updating DNS, and specifically updating the name to address and address
to name mappings maintained by DNS.
This document specifies how DHCP clients and servers should use the
Dynamic DNS Updates mechanism to update the DNS name to address and
address to name mapping, so that the mappings for DHCP clients would be
consistent with the IP addresses that the clients acquire via DHCP.
"An Extension to the DHCP Option Codes", Ralph Droms, 07/25/1997,
<draft-ietf-dhc-options-opt127-03.txt>
The Dynamic Host Configuration Protocol (DHCP) provides a framework for
passing configuration information to hosts on a TCP/IP network. This
document defines a new option to extend the available option codes.
"An option for FQDNs in DHCP options", Ralph Droms, Y Rekhter,
07/25/1997, <draft-ietf-dhc-fqdn-opt-03.txt>
DHCP [DHCP] can be used to automate the process of configuring TCP/IP
host computers. However, some of the DHCP options carry IP addresses
rather than Fully Qualified Domain Names (FQDN). Use of IP addresses
constrains the DHCP client to use the addresses that were in use at the
time the client received its configuration information; these addresses
may change over time, (e.g., a server may be assigned a new IP
address), so that the IP addresses used by the client may become
invalid. An alternative to passing IP addresses
is to pass FQDNs instead of (numeric) IP addresses. Doing this allows
a client to defer binding between a particular network entity (e.g., a
server) and its IP address until run time. As stated in
[Carpenter:96], 'Deferring the binding avoids the risk of changed
mapping between IP addresses and specific network entities (due to
changing addressing information). Moreover, reliance on FQDNs (rather
than IP addresses) also localizes to the DNS the changes needed to deal
with changing addressing information due to renumbering.' This
document defines a new DHCP option that allows the use of FQDNs instead
of IP addresses in DHCP options.
"Authentication for DHCP Messages", Ralph Droms, 08/28/1997,
<draft-ietf-dhc-authentication-04.txt>
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. In some situations, network administrators may wish to
constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
authentication of the source and contents of DHCP messages. This
document defines a new DHCP option through which authorization
tickets can be easily generated and newly attached hosts with proper
authorization can be automatically configured from an authenticated
DHCP server.
"Extensions for the Dynamic Host Configuration Protocol for IPv6", C.
Perkins, 08/04/1997, <draft-ietf-dhc-v6exts-07.txt>
The Dynamic Host Configuration Protocol for IPv6 [4] (DHCPv6)
provides a framework for passing configuration information to hosts
on a TCP/IP network. Configuration parameters and other control
information are carried in typed data items that are stored in the
'extensions' field of the DHCPv6 message. The data items themselves
are also called 'extensions.'
This document specifies the current set of DHCPv6 extensions. This
document will be periodically updated as new extensions are defined.
Each superseding document will include the entire current list of
valid extensions.
"DHCP Options for Service Location Protocol", C. Perkins, 05/12/1997,
<draft-ietf-dhc-slp-02.txt>
The Dynamic Host Configuration Protocol provides a framework for
passing configuration information to hosts on a TCP/IP network.
Entities using the Service Location Protocol need to find out the
address of Directory Agents in order to transact messages. In certain
other instances they may need to discover the correct scope to be used
in conjunction with the service attributes which are exchanged using
the Service Location Protocol.
"The User Class Option for DHCP", Ralph Droms, G. Stump, 03/24/1997,
<draft-ietf-dhc-userclass-01.txt>
This option is used by a DHCP client to optionally identify the type or
category of user or applications it represents. The information
contained in this option is an NVT ASCII text object that represents
the user class of which the client is a member.
"DHCP Option for IEEE 1003.1 POSIX Timezone Specifications", M. Carney,
07/30/1997, <draft-ietf-dhc-timezone-03.txt>
The Dynamic Host Configuration Protocol (DHCP) [1] provides a framework
for passing configuration information to hosts on a TCP/IP network.
This document defines a new option to extend the available option codes
[3].
"An Inter-server Protocol for DHCP", Ralph Droms, R. Cole, K. Kinnear,
08/04/1997, <draft-ietf-dhc-interserver-02.txt>
The DHCP protocol is designed to allow for multiple DHCP servers, so
that reliability of DHCP service can be improved through the use of
redundant servers. To provide redundant service, multiple DHCP servers
must carry the same information about assigned IP addresses and
parameters; i.e., the servers must be configured with the same
bindings. Because DHCP servers may dynamically assign new addresses or
configuration parameters, or extend the lease on an existing address
assignment, the bindings on some servers may become out of date. The
DHCP inter-server protocol provides an automatic mechanism for
synchronization of the bindings stored on a set of cooperating DHCP
servers. The underlying capabilities of the DHCP inter-server protocol
required for multiple server cache replications are based upon the
Server Cache Synchronization Protocol (SCSP).
"DHCP Relay Agent Information Option", M. Patrick, 08/01/1997,
<draft-ietf-dhc-agent-options-02.txt>
Newer high-speed public Internet access technologies call for a
high-speed modem to have a LAN attachment to one or more user hosts.
It is advantageous to use DHCP to assign user host IP addresses in
this environment, but a number of security and scaling problems
arise
with such 'public' DHCP use. This draft calls for the definition of
a 'DHCP Relay Agent Information' option that is appended to a DHCP
packet forwarded from a client to a server by a relay agent. The
Server may or may not use the information in the the Relay Agent
Information option; in either case, it echoes back the option
verbatim in server-to-client replies.
The 'Relay Agent Information' option contains sub-options that
convey
information known by the relay agent. The initial sub-options are
defined for a relay agent that is co-located in a public circuit
access unit. These include a 'circuit ID' for the incoming circuit
and a 'remote ID' which provides a trusted identifier for the remote
high-speed modem.
"Multicast address allocation extensions options", B. Patel, M. Shah,
08/01/1997, <draft-ietf-dhc-multopt-01.txt>
This document describes host configuration options that may be used
by multicast address allocation protocols[3]. The options include
critical information such as the IP address (unicast or multicast)
of the multicast address allocation server(s) and a list of
multicast scopes supported by respective servers. These options are
designed to work with the extensions to DHCP [1] servers to support
multicast address allocation (described in a separate draft),
however, their use may not be limited to the above protocol.
"Multicast address allocation extensions to the Dynamic Host
Configuration Protocol", B. Patel, M. Shah, 08/18/1997,
<draft-ietf-dhc-mdhcp-02.txt>
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCP/IP network.
The multicast extensions to DHCP add additional capability of
dynamic allocation of the multicast addresses and additional
configuration options.
"DSCP: Dynamic Subnet Configuration Protocol", K. Taniguchi, T. Nishida,
03/24/1997, <draft-ietf-dhc-dyn-subnet-conf-00.txt>
The Dynamic Subnet Configuration Protocol (DSCP) provides a framework
for passing configuration information to administrative servers on a
TCP/IP network which allows dynamic subnet configuration. Examples of
administrative servers, which are DSCP clients, are a network
administrator's host, DHCP server, etc. DSCP is built on a client
server model. The DSCP server allocates subnet configuration
parameters to dynamically configured subnetworks. DSCP is an extension
of DHCP [1,2]. This document describes DSCP model and defines a new
DHCP options to allow the subnet configuration dynamically.
"The Server Identification Option for DHCP", G. Stump, P. Gupta,
03/24/1997, <draft-ietf-dhc-sio-00.txt>
This option is provided by DHCP servers to DHCP clients to identify the
origin of a DHCPOFFER -- on a basis other than a server's IP address --
so that a DHCP client may optionally select from among multiple offers
based on a client's preference to a particular DHCP server(s). The
information contained in this option is a hex value indicating the
assigned identification of the server originating the DHCPOFFER in
which this option is contained.
"The Server Selection Option for DHCP", G. Stump, P. Gupta, 03/24/1997,
<draft-ietf-dhc-sso-00.txt>
This option is provided by DHCP servers to DHCP clients so that clients
may optionally select from among multiple offers received from DHCP
servers in the network based on a network-administrated preference
system. The information contained in this option is a hex value that
represents the priority of the offer in which this option is contained.
"Security Architecture for DHCP", O. Gudmundsson, 08/04/1997,
<draft-ietf-dhc-security-arch-01.txt>
This document addresses the general security requirements of both v4
and v6 versions of DHCP. This document lists security requirements and
proposes as security model, which meets scaling requirements, security
requirements and efficiency requirements.
The proposed security model uses public key cryptography and a proposed
trusted key distribution mechanism to authenticate clients and servers.
The authentication protocol can also exchange keying material for more
efficiently protecting successive communication between client and
server. The security model also addresses securing relay agents.
"An Inter-server Protocol for DHCP", Ralph Droms, R. Cole, K. Kinnear,
04/14/1997, <draft-ietf-dhc-interserver-alt-00.txt>
The DHCP protocol is designed to allow for multiple DHCP servers, so
that reliability of DHCP service can be improved through the use of
redundant servers. To provide redundant service, all of the DHCP
servers must be configured with the same information about assigned IP
addresses and parameters; i.e., all of the servers must be configured
with the same bindings. Because DHCP servers may dynamically assign
new addresses or configuration parameters, or extend the lease on an
existing address assignment, the bindings on some servers may become
out of date. The DHCP inter-server protocol provides an automatic
mechanism for synchronization of the bindings stored on a set of
cooperating DHCP servers. This draft is a direct
extension of draft-ietf-dhc-interserver-00.txt, but has been renamed
draft-ietf-dhc-interserver-alt-00.txt since an alternative proposal
(also a direct extension of draft-ietf-dhc-interserver-00.txt but in a
different direction) exists named draft-ietf-dhc-interserver-01.txt.
"The Named Pool Request Option for DHCP", K. McGrew, 05/14/1997,
<draft-ietf-dhc-namedpool-00.txt>
This option is used by a DHCP client to optionally identify the
specific named pool from which it should be assigned an IP address.
The information contained in this option is an ASCII text object that
represents the named pool from which the DHCP server assign an IP
address to the DHCP client.
"Netware/IP Domain Name and Information", Ralph Droms, K. Fong,
10/30/1997, <draft-ietf-dhc-netware-options-01.txt>
The Dynamic Host Configuration Protocol (DHCP) [RFC 2131] provides a
framework for passing configuration information to hosts on a TCP/IP
network. DHCP includes options for specific configuration parameters
[RFC 2132]. This document defines options that carry NetWare/IP
domain name and NetWare/IP sub-options to DHCP clients.
"Securing DHCP", B. Patel, 07/30/1997,
<draft-ietf-dhc-securing-dhc-00.txt>
This proposal describes methods of securing DHCP based on IETF DHCP and
IPSEC protocols. This protocol achieves security goals for DHCP client
and servers without having to define a new security protocol. Instead,
it first bootstraps the DHCP client in un-trusted mode using existing
DHCP protocol and then proceeds to secure configuration of the client
using existing DHCP and IP protocol features.
"Subnet Selection Option for DHCP", P. Gupta, W. Mark Townsley,
07/30/1997, <draft-ietf-dhc-subsel-00.txt>
The Subnet Selections option is provided by a DHCP client to DHCP a
server as an indication to which subnet or subnets to select an address
from for the client's lease. When present, the DHCP server will use
this value as an indication to which configured subnet pool of
addresses to select from, effectively divorcing the giaddr of its
overloaded subnet selection function for a packet forwarded by a DHCP
relay agent. The giaddr is retains its function as the address for the
DHCP server to send replies to.
An application for this new option would be to allow a Network Access
Server (NAS) acting as DHCP proxy on behalf of a large number of
dial-in
users to obtain an address that is in the desired subnet(s) for the
dial
users without having to configure multiple giaddr values at the NAS, or
requiring the NAS to utilize an address within each subnet.
"The Domain Search Option for DHCP", G. Stump, P. Gupta, 08/04/1997,
<draft-ietf-dhc-domsrch-00.txt>
The Dynamic Host Configuration Protocol (DHCP) [1] provides a
framework for passing configuration information to hosts on a TCP/IP
network. This document defines a new option which is passed form the
DHCP server to the DHCP Client to configure the domain search list
which is used by the clients to resolve hostnames in the Domain Name
System.
Distributed Management (disman)
-------------------------------
"Definitions of Managed Objects for the Delegation of Management
Scripts", D. Levi, J. Schoenwaelder, 03/12/1997,
<draft-ietf-disman-script-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes a set of managed objects that
allows the delegation of management scripts to mid-level managers.
This memo does not specify a standard for the Internet community.
"Distributed Management Framework", Steven Waldbusser, Bob Stewart, Andy
Bierman, M. Greene, 01/03/1997, <draft-ietf-disman-framework-00.txt>
This memo defines a distributed management architecture for use with
the SNMP network management architecture.
This memo does not specify a standard for the Internet community.
"Expression MIB", Bob Stewart, 06/04/1997,
<draft-ietf-disman-express-mib-02.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing expressions of MIB objects.
"Management Target MIB", Bob Stewart, 05/02/1997,
<draft-ietf-disman-mgt-target-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing a list of network management destinations (targets) and the
information needed to get to them and to group them.
"Notification MIB", Bob Stewart, 05/02/1997,
<draft-ietf-disman-notify-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing SNMP notifications.
"Event MIB", Bob Stewart, 05/02/1997,
<draft-ietf-disman-event-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing monitoring of MIB objects and taking action through events.
DNS IXFR, Notification, and Dynamic Update (dnsind)
---------------------------------------------------
"Classless IN-ADDR.ARPA delegation", G. de Groot, P. Vixie, H. Eidnes,
05/12/1997, <draft-ietf-dnsind-classless-inaddr-03.txt>
This document describes a way to do IN-ADDR.ARPA delegation on
non-octet boundaries for address spaces covering fewer than 256
addresses. The proposed method should thus remove one of the
objections to subnet on non-octet boundaries but perhaps more
significantly, make it possible to assign IP address space in smaller
chunks than 24-bit prefixes, without losing the ability to delegate
authority for the corresponding IN-ADDR.ARPA mappings. The proposed
method is fully compatible with the original DNS lookup mechanisms
specified in [1], i.e. there is no need to modify the lookup algorithm
used, and there should be no need to modify any software which does DNS
lookups either. The document also
discusses some operational considerations to provide some guidance in
implementing this method.
"The Kitchen Sink Resource Record", Don Eastlake, 04/28/1997,
<draft-eastlake-kitchen-sink-02.txt>
Periodically people are seized with a desire to put complex, bulky,
and/or obscurely structured data into the Domain Name System (DNS).
This draft defines a kitchen sink Resource Record that will satisfy
this lust by defining a new DNS resource record for the storage of
miscellaneous structured information.
"Negative Caching of DNS Queries (DNS NCACHE)", M. Andrews, 10/27/1997,
<draft-ietf-dnsind-ncache-08.txt>
[RFC1034] provided a description of how to cache negative
responses. It however had a fundamental flaw in that it did
not
allow a name server to hand out those cached responses to
other
resolvers, thereby greatly reducing the effect of the
caching.
This document addresses issues raise in the light of
experience
and replaces [RFC1034 Section 4.3.4].
Negative caching was an optional part of the DNS
specification
and deals with the caching of the non-existence of an RRset
[RFC2181] or domain name.
Negative caching is useful as it reduces the response time
for
negative answers. It also reduces the number of messages
that
have to be sent between resolvers and name servers hence
overall
network traffic. A large proportion of DNS traffic on the
Internet could be eliminated if all resolvers implemented
negative caching. With this in mind negative caching should
no
longer be seen as an optional part of a DNS resolver.
"Test and Example Top Level Domain Names", D. Eastlake, Aliza Panitz,
10/31/1997, <draft-ietf-dnsind-test-tlds-04.txt>
To reduce the likelihood of conflict and confusion, a number of top
level domain names are reserved for use in private testing, as
examples in documentation, and the like.
"Local DNS Names", Don Eastlake, 10/15/1997,
<draft-ietf-dnsind-local-names-02.txt>
A set of second level domain names are defined under a new top level
domain name such that local private DNS zones can be maintained
similar to the private IP addresses reserved in RFC 1918 but which
locally appear to be part of the global DNS name tree. Additional
second level domain names are assigned under this TLD for loopback
addresses and IPv6 link and site local addresses.
Domain Name System Security (dnssec)
------------------------------------
"Mapping Autonomous Systems Number into the Domain Name System", Don
Eastlake, 08/02/1997, <draft-ietf-dnssec-as-map-05.txt>
One requirement of secure routing is that independent routing
entities, such as those identified by Internet Autonomous System
Numbers, be able to authenticate messages to each other. Additions
have developed to the Domain Name System to enable it to be used for
authenticated public key distribution [RFC 2065]. This draft maps
all Autonomous System numbers into DNS Domain Names so that the DNS
security can be used to distribute their public keys.
[Changes from previous version are to accommodate AS numbers larger
than 16 bits and to delegate on decimal boundaries rather than
binary
boundaries.]
"Detached Domain Name System Information", Don Eastlake, 03/26/1997,
<draft-ietf-dnssec-ddi-02.txt>
A standard format is defined for representing detached DNS information.
This is anticipated to be of use for storing information retrieved from
the Domain Name System (DNS), including security information, in
archival contexts or contexts not connected to the Internet.
"The DNS Inverse Key Domain", Don Eastlake, 03/27/1997,
<draft-ietf-dnssec-in-key-00.txt>
Proposed Standard protocol extensions now exist to the Domain Name
System (DNS) to authenticate the data in DNS and provide key
distribution services (RFC 2065). This draft proposes a special
in-key.int domain which would allow entities to be found from their
keys if they have voluntarily registered them in that domain.
"Storage of Diffie-Hellman Keys in the Domain Name System", Don Eastlake,
06/02/1997, <draft-ietf-dnssec-dhk-00.txt>
A standard method for storing Diffie-Hellman keys in the Domain Name
System is described which utilizes DNS KEY resource records.
"Domain Name System Security Extensions", Don Eastlake, 08/25/1997,
<draft-ietf-dnssec-secext2-01.txt>
Extensions to the Domain Name System (DNS) are described that provide
data integrity and authentication to security aware resolvers or
applications through the use of cryptographic digital signatures.
These digital signatures are included in secured zones as resource
records. Security can also be provided even through non-security
aware DNS servers in many cases.
The extensions provide for the storage of authenticated public keys
in the DNS. This storage of keys can support general public key
distribution services as well as DNS security. The stored keys
enable security aware resolvers to learn the authenticating key of
zones in addition to those for which they are initially configured.
Keys associated with DNS names can be retrieved to support other
protocols. Provision is made for a variety of key types and
algorithms.
In addition, the security extensions provide for the optional
authentication of DNS protocol transactions and requests.
This document incorporates feedback from implementors and potential
users to RFC 2065.
"DSA KEYs and SIGs in the Domain Name System", Don Eastlake, 09/10/1997,
<draft-ietf-dnssec-dss-00.txt>
A standard method for storing US Government Digital Signature
Algorithm keys and signatures in the Domain Name System is described
which utilizes DNS KEY and SIG resource records.
"Storing Certificates in the Domain Name System", O. Gudmundsson, D.
Eastlake, 09/12/1997, <draft-ietf-dnssec-certs-00.txt>
Cryptographic public key are frequently published and their
authenticity demonstrated by certification systems. A CERT resource
record (RR) is defined so that such certificates and certificate
revocation lists can be conveniently stored in the Domain Name
System
(DNS).
RFC 2065 specifies a Proposed Standard for storing cryptographic
public keys in the DNS via the KEY resource record (RR). In
addition to defining the CERT RR as above, a certificate flag bit is
also allocated out of the KEY RR flag field to indicate that a key
may be authenticated by one or more CERT RRs stored under the same
owner name as the KEY RR.
A separate document, draft-ietf-dnssec-indirect-key-00.txt, provides
aaditional ways of references keys or certificates within or outside
the DNS.
"Indirect Keys in the Domain Name System", D. Eastlake, 09/12/1997,
<draft-ietf-dnssec-indirect-key-00.txt>
RFC 2065 defines a means for storing cryptogrpahic public keys in
the
Domain Name System. An additional code point is defined for the KEY
resource record (RR) algorithm field to indicate that the key itself
is not stored in the KEY RR but is pointed to by the KEY RR.
Encodings to indicate different types of key and pointer formats are
specified.
Detailed Revision/Update of Message Standards (drums)
-----------------------------------------------------
"Simple Mail Transfer Protocol", John Klensin, 08/05/1997,
<draft-ietf-drums-smtpupd-06.txt>
This document is a self-contained specification of the basic protocol
for the Internet electronic mail transport, consolidating and
updating
* the original SMTP specification of RFC 821 [RFC-821],
* Domain name system requirements and implications for mail
transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC974],
* the clarifications and applicability statements in
RFC 1123 [RFC-1123], and
* material drawn from the SMTP Extension mechanisms [SMTPEXT].
It replaces RFC 821, RFC 974, and the mail transport materials of RFC
1123. However, RFC 821 specifies some features that are not in
significant use in the Internet of the mid-1990s and (in appendices)
some additional transport models. Those sections are omitted here in
the interest of clarity and brevity; readers needing them should
refer to RFC 821.
It also includes some additional material from RFC 1123 that required
amplification. This material has been identified in multiple ways,
mostly by tracking flaming on the header-people list [HEADER-PEOPLE]
and problems of unusual readings or interpretations that have turned
up as the SMTP extensions have been deployed. Where this
specification moves beyond consolidation and actually differs from
earlier documents, it supersedes them technically as well as
textually.
Although SMTP was designed as a mail transport and delivery protocol,
this specification also contains information that is important to its
use as a 'mail posting' protocol, as recommended for POP [RFC-POP2,
RFC-POP3] and IMAP [RFC-IMAP4].
Section ##2.3 provides definitions of terms specific to this
document. Except when the historical terminology is necessary for
clarity, this document uses the current 'client' and 'server'
terminology to identify the sending and receiving SMTP processes,
respectively.
A companion document discusses message bodies and formats RFC 822,
MIME, and their relationship - [MSGFMT].
"Augmented BNF for Syntax Specifications: ABNF", Dave Crocker, P.
Overell, 10/17/1997, <draft-ietf-drums-abnf-05.txt>
Internet technical specifications often need to define a format
syntax and are free to employ whatever notation their authors
deem useful. Over the years, a modified version of Backus-Naur
Form (BNF), called Augmented BNF (ABNF), has been popular among
many Internet specifications. It balances compactness and
simplicity, with reasonable representational power. In the early
days of the Arpanet, each specification contained its own
definition of ABNF. This included the email specifications,
RFC733 and then RFC822 which have come to be the common citations
for defining ABNF. The current document separates out that
definition, to permit selective reference. Predictably, it also
provides some modifications and enhancements.
The differences between standard BNF and ABNF involve naming
rules, repetition, alternatives, order-independence, and value
ranges. Appendix A (Core) supplies rule definitions and encoding
for a core lexical analyzer of the type common to several
Internet specifications. It is provided as a convenience and is
otherwise separate from the meta language defined in the body of
this document, and separate from its formal status.
"Mail and Netnews Header Registration Procedure", J. Palme, 08/21/1997,
<draft-ietf-drums-MHRegistry-01.txt>
Various IETF standards and e-mail and netnews software products
use various e-mail and netnews header fields. This document
specifies a procedure for the registration of e-mail and netnews
header field names, to reduce the risk that two different products
use the same header name in different ways (homonyms) or that
several different header names are used with identical meaning
(synonyms).
"Message Format Standard", P. Resnick, 06/24/1997,
<draft-ietf-drums-msg-fmt-02.txt>
This standard specifies a syntax for text messages that are sent
between computer users, within the framework of 'electronic mail'
messages. This standard supersedes the one specified in Request For
Comments 822, 'Standard for the Format of ARPA Internet Text Messages'.
This standard only specifies a syntax for text messages. In particular,
it makes no provision for the transmission of images, audio, or other
sorts of structured data in electronic mail messages. There are several
extensions published, such as the MIME document series [MIME-IMT,
MIME-IMB], which describe mechanisms for the transmission of such data
through electronic mail, either by extending the syntax provided here
or by structuring such messages to conform to this syntax. These
mechanisms are outside of the scope of this standard.
Note: Though this document uses the word 'standard' in both the title
and the body of the text, it is of course still an Internet Draft and
is NOT actually a standard until it has been approved and published as
an RFC.
"Use of Reply-To in Internet E-Mail messages", Robert Elz, 10/30/1997,
<draft-ietf-drums-kre-reply-to-00.txt>
This draft forms part of a discussion on the appropriate use of the
Reply-To header in e-mail messages. This draft argues for one
particular proposed definition of the Reply-To header.
It is not intended that this document ever become anything more than
an Internet-Draft. If adopted, the text here, or a modified version
of some parts of it, would be merged into the proposed replacement
for RFC822.
Electronic Data Interchange-Internet Integration (ediint)
---------------------------------------------------------
"Requirements for Inter-operable Internet EDI", Rik Drummond, M. Jansson,
C. Shih, 07/15/1997, <draft-ietf-ediint-req-03.txt>
This document is a functional specification, discussing the
requirements for inter-operable EDI, with sufficient background
material to give an explanation for the EDI community of the Internet
and security related issues.
"MIME-based Secure EDI", Rik Drummond, M. Jansson, C. Shih, 07/15/1997,
<draft-ietf-ediint-as1-04.txt>
This document describes how to securely exchange EDI documents using
MIME and public key cryptography.
Entity MIB (entmib)
-------------------
"Entity MIB Extesions for Persistent Component Identification", Keith
McCloghrie, Andy Bierman, 09/17/1997,
<draft-bierman-entmib-compid-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing physical topology identification and discovery.
Internet Fax (fax)
------------------
"Tag Image File Format (TIFF) - Application F", G. Parsons, James
Rafferty, 09/22/1997, <draft-ietf-fax-tiff-04.txt>
This document describes in detail the definition of TIFF-F that is
used to store facsimile images. The TIFF-F encoding has been
folklore with no standard reference definition before this
document.
"File Format for Internet Fax", Steve Zilles, L. McIntyre, Dennis
Venable, Robert Buckley, 10/09/1997, <draft-ietf-fax-tiffplus-02.txt>
This Internet Draft describes the TIFF (Tag Image File Format)
representation of image data specified by the ITU-T Recommendations for
black-and-white and color facsimile. It formally defines Applications
W,
F, J, C, P and M of the MIME Media Type image/tiff for use with
Internet
Fax. Applications W, F and J describe the minimal, extended and
lossless
JBIG modes for black-and-white fax. Applications C, P and M describe
the
base JPEG, lossless JBIG and Mixed Raster Content modes for color and
grayscale fax.
"Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration",
Steve Zilles, G. Parsons, James Rafferty, 09/22/1997,
<draft-ietf-fax-tiff-reg-02.txt>
This document describes the registration of the MIME sub-type
image/tiff. The baseline encoding is defined by [TIFF].
"SMTP Service Extension for Immediate Delivery", Larry Masinter, N.
Joffe, Dan Wing, 10/15/1997, <draft-ietf-fax-smtp-session-00.txt>
This memo defines an extension to SMTP which provides a mechanism for
requesting and verifying immediate message delivery over SMTP.
"PSTN and fax address format in e-mail services v3.4", C. Allocchio,
10/28/1997, <draft-ietf-fax-addressing-01.txt>
Since the very first e-mail to fax gateway objects appeared, a
number of different methods to specify a fax address into an
e-mail address have been used by implementors.
"Tag Image File Format (TIFF) - image/tiff-f MIME Sub-type
Registration", G. Parsons, James Rafferty, 09/22/1997,
<draft-ietf-fax-tiff-f-reg-00.txt>
This document describes the registration of the MIME sub-type
image/tiff-f. The baseline encoding is defined by [TIFF].
"PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL", Dave
Crocker, 10/27/1997, <draft-ietf-fax-itudc-00.txt>
F.IFax, defines the service requirement for both real-time and
store and forward facsimile over the Internet. For store and
forward facsimile this Recommendation defines addressing, MIME
encapsulation of document components and data formats for
those components..
Store and forward facsimile uses Internet mail standard
protocols for posting, relaying and delivery of store and
forward facsimile document. It requires no changes to Internet
standards or to ITU Facsimile Recommendations. Such an
approach leads to a system that can be used universally
without changes to Internet servers or other intermediate
systems between the sender and the recipient and which permits
interworking between facsimile store and forward users and
users of general Internet mail.
Common Indexing Protocol (find)
-------------------------------
"A Tagged Index Object for use in the Common Indexing Protocol", Roland
Hedberg, R. Moats, M. Wahl, B. Greenblatt, 09/23/1997,
<draft-ietf-find-cip-tagged-03.txt>
This document defines a mechanism by which information servers
can exchange indices of information from their databases by making
use of the Common Indexing Protocol (CIP). This document defines
the
structure of the index information being exchanged, as well as a the
appropriate meanings for the headers that are defined in the Common
Indexing Protocol. It is assumed that the structures defined here
can be used by X.500 DSAs, LDAP servers, whois++ servers, CCSO
servers and many others.
"A CIP-based Centroid Exchange for LDAP", M. Wahl, 02/10/1997,
<draft-ietf-find-ldapc-00.txt>
This document describes how an LDAP server (the supplier) may transmit,
through an out-of-band email, index information or attributes of its
naming context to another LDAP server (the consumer). The consumer
server will make use of this information when determining whether the
supplier server is likely to have entries in that naming context which
match a particular search filter. This assists the consumer in
processing subtree searches in distributed directories.
"CIP Index Object Format for SOIF Objects", Mike Schwartz, D. Hardy, M.
Bowman, E. Hardie, Duane Wessels, 10/31/1997,
<draft-ietf-find-cip-soif-02.txt>
The Common Indexing Protocol (CIP) allows servers to form a referral
mesh for query handling by defining a mechanism by which cooperating
servers exchange hints about the searchable indices they maintain. The
structure and transport of CIP are described in (Ref. 1), as are
general
rules for the definition of index object types. This document
describes
SOIF, the Summary Object Interchange Format, as an index object type in
the context of the CIP framework. SOIF is a machine-readable syntax
for
transmitting structured summary objects, currently used primarily in
the
context of the World Wide Web.
Query referral has often been dismissed as an ineffective strategy for
handling searches of Web resources, and Web resources certainly present
challenges not present in structured directory services like Rwhois.
In
situations where a keyword-based free text search is desired, query
referral is not likely to be effective because the query will probably
be routed to every server participating in the referral mesh. Where a
search can be limited by reference to a specific resource attribute,
however, query referral is an effective tool. SOIF can be used to
create such a known-attribute query mesh because it provides a method
for associating attributes with net-addressable resources.
Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each
contributed to the creation of the SOIF format and to the descriptions
from which this draft is drawn; errors in this description of their
work
are the responsibility of Edward Hardie and corrections should be
directed accordingly.
"Hierarchical Extensions to the Common Indexing Protocol", Chris Weider,
P. Leach, 07/15/1997, <draft-ietf-find-cip-hierarchy-01.txt>
This work explores what, in the parlance of the current CIP draft, is
called an index type -- specifically, a new kind of index that merges
indexing of hierarchically named attribute-value entities (such as in
LDAP and RWHOIS) and ones without distinguished names (such as in
WHOIS++). It is based on a previous version of the CIP specification,
but that was just a convenient syntactical jumping off point. It is
intended to be orthogonal to the FIND working group task of defining a
framing syntax and functionality for a common indexing data wrapping
protocol, and that the concepts and protocol elements in this draft
should be able to be expressed in a manner consistent with the new CIP
framework at the appropriate time.
"Registration Procedures for SOIF Template Types", E. Hardie, 05/27/1997,
<draft-ietf-find-soif-registry-00.txt>
The Summary Object Interchange Format [Ref. 1] was first defined by the
Harvest Project [Ref 2.] in January 1994. SOIF was derived from a
combination of the Internet Anonymous FTP Archives IETF Working Group
(IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.].
The combination was originally noted for its advantages of providing a
convenient and intuitive way for delimiting objects within a stream,
and setting apart the URL for easy object access or invocation, while
still preserving compatibility with IAFA templates. SOIF
uses named template types to indicate the attributes which may be
contained within a particular summary object. Within the context of a
single application, private agreement on the definition of template
types has been adequate. As SOIF objects are moved among applications,
however, the need for standard, well-specified, and easily identifiable
template types increases. This need is particularly intense in the
context of query referral, where knowledge of an attribute's definition
and the allowed data types for specific values is crucial. For a
discussion of this in the context of the Common Indexing Protocol, see
[Ref. 1].
"CIP Transport Protocols", P. Leach, J. Allen, 06/10/1997,
<draft-ietf-find-cip-trans-00.txt>
This document specifies three protocols for transporting CIP requests,
responses and index objects, utilizing TCP, mail, and HTTP. The objects
themselves are defined in [CIP-MIME] and the overall CIP architecture
is defined in [CIP-ARCH].
"MIME Object Definitions for the Common Indexing Protocol (CIP)", M.
Mealling, J. Allen, 06/11/1997, <draft-ietf-find-cip-mime-00.txt>
The Common Indexing Protocol (CIP) is used to pass indexing information
from server to server in order to facilitate query routing. The
protocol is comprised of several MIME objects being passed from server
to server. This document describes the definitions of those objects as
well as the methods and requirements needed to define a new index type.
"The Architecture of the Common Indexing Protocol (CIP)", M. Mealling, J.
Allen, 06/11/1997, <draft-ietf-find-cip-arch-00.txt>
The Common Indexing Protocol (CIP) is used to pass indexing information
from server to server in order to facilitate query routing. Query
routing is the process of redirecting and replicating queries through a
distributed database system towards servers holding the desired
results. This document describes the CIP framework, including it's
architecture and the protocol specifics of exchanging indices.
Frame Relay Service MIB (frnetmib)
----------------------------------
"Management Information Base for Frame Relay DTE Extensions for SVC's
over Frame Relay", D. Cochrane, 05/14/1997,
<draft-ietf-frnetmib-dte-svc-00.txt>
This memo defines a 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 Frame Relay Switched
Virtual Circuit's. This memo does not specify a standard for the
Internet community.
"Management Information Base for Frame Relay Data Compression", M.
Kashef, J. Colom, 07/08/1997, <draft-ietf-frnetmib-dcp-02.txt>
This memo defines a 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 Data Compression over a
Frame Relay virtual circuit. This memo does not specify a standard for
the Internet community.
"Definitions of Managed Objects for Frame Relay Service", Tracy Brown, D.
Fowler, 03/20/1997, <draft-ietf-frnetmib-frs-mib-01.txt>
This memo defines an extension to the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing the Frame Relay Service.
This memo does not specify a standard for the Internet community.
This document entirely replaces RFC 1604.
"Frame Relay Service Extensions MIB for Switched PVCs", B. Coutts,
02/10/1997, <draft-ietf-frnetmib-spvc-00.txt>
This memo defines a 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 Frame Relay Switched
Permanent Virtual Circuits (SPVCs) as extensions to RFC 1604 [1]. This
memo does not specify a standard for the Internet community.
Extensions to FTP (ftpext)
--------------------------
"Extended Directory Listing and Restart Mechanism for FTP", Robert Elz,
Paul Hethmon, 08/01/1997, <draft-ietf-ftpext-mlst-02.txt>
In order to overcome the problems caused by the undefined format of
the current FTP LIST command output, a new command is needed to
transfer standardized listing information from Server-FTP to Client-
FTP. Commands to enable this are defined in this document.
This proposal also extends the FTP protocol to allow character sets
other than US-ASCII[1] by allowing the transmission of 8-bit
characters and the recommended use of UTF-8[2] encoding.
Much implemented, but long undocumented, mechanisms to permit
restarts of interrupted data transfers in STREAM mode, are also
included here.
This version contains corrections and additions agreed on the
mailing
list. Some sections incomplete in the previous draft have been
completed. Several editorial adjustments have been made. This
version is still not nearly complete. This paragraph will be
deleted
from the final version of this document.
"Internationalization of the File Transfer Protocol", B. Curtin,
06/11/1997, <draft-ietf-ftpext-intl-ftp-02.txt>
The File Transfer Protocol, as defined in RFC 959 [RFC959] and RFC 1123
Section 4 [RFC1123], is one of the oldest and widely used protocols on
the Internet. The protocol's primary character set, 7 bit ASCII, has
served the protocol well through the early growth years of the
Internet. However, as the Internet becomes more global, there is a need
to support character sets beyond 7 bit ASCII.
This document addresses the internationalization (I18n) of FTP, which
includes supporting the multiple character sets found throughout the
Internet community. This is achieved by extending the FTP
specification and giving recommendations for proper
internationalization support.
"REST Command and Extensions to FTP", R. Adams, David Borman, 03/21/1997,
<draft-ietf-ftpext-restart-00.txt>
This memo describes changes to FTP [1], which were proposed by Rick
Adams in May of 1989, to allow the RESTART mechanism to be used with
STREAM mode transfers. Along with this, two new optional commands are
added, MODIFICATION TIME (MDTM) and SIZE OF FILE (SIZE). All these
changes have been implemented, and are in use today in many production
FTP implementations.
"Feature negotiation mechanism for the File Transfer Protocol", Robert
Elz, Paul Hethmon, 07/28/1997, <draft-ietf-ftpext-feat-01.txt>
The File Transfer Protocol is, from time to time, extended with new
commands, or facilities. Implementations of the FTP protocol cannot be
assumed to all immediately implement all newly defined mechanisms.
This document provides a mechanism by which clients of the FTP protocol
can discover which new features are supported by a particular FTP
server. A new security considerations section has been added. One
previously legal way to indicate no features has been deleted. The
usual kinds of editorial updates have been made.
G and R for Security Incident Processing (grip)
-----------------------------------------------
"Expectations for Computer Security Incident Response", Nevil Brownlee,
Erik Guttman, 09/29/1997, <draft-ietf-grip-framework-irt-08.txt>
The purpose of this document is to express the general Internet
community's expectations of Computer Security Incident Response
Teams (CSIRTs). It is not possible to define a set of requirements
that would be appropriate for all teams, but it is possible and
helpful to list and describe the general set of topics and issues
which are of concern and interest to constituent communities.
CSIRT constituents have a legitimate need and right to fully
understand the policies and procedures of 'their' Computer Security
Incident Response Team. One way to support this understanding is to
supply detailed information which users may consider, in the form of
a formal template completed by the CSIRT. An outline of such a
template and a filled in example are provided.
"Security Expectations for Internet Service Providers", Tom Killalea,
10/21/1997, <draft-ietf-grip-isp-00.txt>
The purpose of this document is to express the general Internet
community's expectations of Internet Service Providers (ISPs) with
respect to security.
It is not the intent of this document to define a set of
requirements that would be appropriate for all ISPs, but rather to
raise awareness among ISPs of the community's expectations, and to
provide the community with a framework for discussion of security
expectations with current and prospective service providers.
HyperText Transfer Protocol (http)
----------------------------------
"PEP - an Extension Mechanism for HTTP", D. Connolly, H. Nielsen, R.
Khare, 07/15/1997, <draft-ietf-http-pep-04.txt, .ps>
HTTP is used increasingly in applications that need more facilities
than the standard version of the protocol provides, ranging from
distributed authoring, collaboration, and printing, to various remote
procedure call mechanisms. The Protocol Extension Protocol (PEP) is an
extension mechanism designed to address the tension between private
agreement and public specification and to accommodate extension of
applications such as HTTP clients, servers, and proxies. The PEP
mechanism is designed to associate each extension with a URI[2], and
use a few new RFC 822[1] derived header fields to carry the extension
identifier and related information between the parties involved in an
extended transaction.
"Transparent Content Negotiation in HTTP", K. Holtman, A. Mutz,
09/15/1997, <draft-ietf-http-negotiation-04.txt>
HTTP allows web site authors to put multiple versions of the
same information under a single URL. Transparent content
negotiation is an extensible negotiation mechanism, layered on
top of HTTP, for automatically selecting the best version when
the URL is accessed. This enables the smooth deployment of
new web data formats and markup tags.
"Feature Tag Registration Procedures", K. Holtman, A. Mutz, 07/28/1997,
<draft-ietf-http-feature-reg-02.txt>
Recent Internet applications, such as the World Wide Web, tie together
a great diversity in data formats, client and server platforms, and
communities. This has created a need for various kinds of negotiation
mechanisms, which tailor the data which is exchanged, or the exchange
process, to the capabilities and preferences of the parties involved.
Extensible negotiation mechanisms need a vocabulary to identify various
things which can be negotiated on. To promote interoperability, a
registration process is needed to ensure that that this vocabulary,
which can be shared between negotiation mechanisms, is developed in an
orderly, well-specified, and public manner.
This document defines registration procedures which use the Internet
Assigned Numbers Authority (IANA) as a central registry for this
vocabulary, which is the vocabulary of feature tags.
"HTTP Remote Variant Selection Algorithm -- RVSA/1.0", K. Holtman, A.
Mutz, 07/28/1997, <draft-ietf-http-rvsa-v10-02.txt>
HTTP allows web site authors to put multiple versions of the same
information under a single URL. Transparent content negotiation is a
mechanism for automatically selecting the best version when the URL is
accessed. A remote variant selection algorithm can be used to speed up
the transparent negotiation process. This document defines the remote
variant selection algorithm with the version number 1.0.
"Problem with HTTP/1.1 Warning header, and proposed fix", Jeff Mogul, Ari
Luotonen, 07/30/1997, <draft-ietf-http-warning-00.txt>
The current HTTP/1.1 (RFC2068) specification introduces a
new Warning header, meant to carry status information
about a request that cannot or should not be carried by the
response status code. The existing specification for the
interaction between Warning and HTTP caches is faulty, in
that it may allow incorrect results after cache validation
operations. This document identifies two separate (but
related) problems, and proposes revisions of the HTTP/1.1
specification to solve these problems.
"HTTP State Management Mechanism (Rev1)", D. Kristol, L. Montulli,
10/27/1997, <draft-ietf-http-state-man-mec-04.txt,.ps>
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and Set-
Cookie2, which carry state information between participating origin
servers and user agents. The method described here differs from
Netscape's Cookie proposal, but it can interoperate with HTTP/1.0 user
agents that use Netscape's method. (See the HISTORICAL section.)
This document reflects implementation experience with RFC 2109 and
obsoletes it.
"The User Agent Hint Response Header", D. Morris, 09/16/1997,
<draft-ietf-http-uahint-01.txt>
This document proposes a HTTP response header called UA-Hint, which
can be used by applications (servers) to describe handling hints
which will allow user agents to more accurately reflect the intent
of
the web application designer for the handling and presentation of
the
response entity. The UA-Hint header is intended to be an extensible
general mechanism by which the application can suggest user agent
behaviors which alter or extend the behaviors specified in HTTP/1.1
(RFC 2068) with the express purpose of improving the usability of
the
resulting application. Intended considerations include enablement
of
a safe POST and refined handling of the traditional history buffer.
"HTTP Connection Management", A. Freier, J. Gettys, 03/26/1997,
<draft-ietf-http-connection-00.txt>
The HTTP/1.1 specification (RFC 2068) is silent about various details
of TCP connection management when using persistent connections. This
document discusses some of the implementation issues discussed during
HTTP/1.1's design, and introduces a few new requirements on HTTP/1.1
implementations learned from implementation experience, not fully
understood when RFC 2068 was issued. This is an initial draft for
working group comment, and we expect further drafts.
"HTTP Trust Mechanism for State Management", D. Jaye, 10/27/1997,
<draft-ietf-http-jaye-trust-state-01.txt>
This document specifies an addition to the state management protocol
specified in draft-ietf-http-state-man-mec-03[Kristol]. The intent is
to provide a mechanism that allows user agents to determine the privacy
practices of a server and to accept or reject cookies based on those
practices. Allowing the user to establish preferences for how to
handle
cookies based on the server's practices provides a practical mechanism
to provide users control over the privacy implications of cookies.
To provide verification of server privacy practices, we assume the
existence of one or more independent Trust Authorities. The authority
establishes PICS ratings representing server privacy practices. It then
issues trust-labels, in the form of digitally signed PICS labels, to
organizations for specific domains and paths based on the server
privacy
practices. The Trust Authority must be able to audit domains to
verify their adherence to a given level. Passing these trust-labels
along with cookies allows the user agent to support cookie handling
preferences based on trusted privacy practices.
This document describes how PICS-headers are used in conjunction with
Set-Cookie or Set-Cookie2 headers in [Kristol] to provide trust-labels
to communicate the privacy practices of servers regarding cookies.
"Scenarios for the Delivery of Negotiated Content using HTTP", E. Hardie,
07/15/1997, <draft-ietf-http-negotiate-scenario-01.txt>
This document describes various problems which have arisen in attempts
to deliver negotiated content using HTTP and examines several scenarios
by which improvements in delivery might be accomplished.
This document does not discuss how HTTP might be used to negotiate the
use of other protocols to deliver content.
"HTTP/1.1 305 and 306 Response Codes", Jeff Mogul, 06/16/1997,
<draft-cohen-http-305-306-responses-00.txt>
The HTTP/1.1 RFC specifies a response code '305 Use Proxy' which is
intended to cause a client to retry the request using a specified proxy
server. This functionality is important, but underspecified in the
current spec. The spec does not specify for how long or which URLs the
redirect applies to, or how proxies can deal with or generate similar
responses. This draft proposes a specification for both the 305
response and a new response, '306 Switch Proxy'.
"Feature Tag Scenarios", K. Holtman, A. Mutz, 07/28/1997,
<draft-ietf-http-feature-scenarios-01.txt>
Recent Internet applications, such as the World Wide Web, tie together
a great diversity in data formats, client and server platforms, and
communities. This has created a need for various kinds of negotiation
mechanisms, which tailor the data which is exchanged, or the exchange
process itself, to the capabilities and preferences of the parties
involved.
Extensible negotiation mechanisms need a vocabulary to identify various
things which can be negotiated on. To promote interoperability, a
registration process is needed to ensure that that this vocabulary,
which can be shared between negotiation mechanisms, is developed in an
orderly, well-specified, and public manner.
This document discusses requirements and scenarios the registration of
this vocabulary, which is the vocabulary of feature tags. Feature tag
registration is foreseen as an ongoing, open process which will keep
pace with the introduction of new features by software vendors, and
other parties such as standards bodies.
"An Extension to HTTP : Digest Access Authentication", J. Franks, A.
Luotonen, P. Leach, J. Hostetler, P. Hallam-Baker, 07/30/1997,
<draft-ietf-http-digest-aa-rev-00.txt>
The protocol referred to as 'HTTP/1.0' includes the specification for
a Basic Access Authentication scheme. This scheme is not considered
to be a secure method of user authentication, as the user name and
password are passed over the network as clear text. A specification
for a different authentication scheme is needed to address this
severe limitation. This document provides specification for such a
scheme, referred to as 'Digest Access Authentication'. Like Basic,
Digest access authentication verifies that both parties to a
communication know a shared secret (a password); unlike Basic, this
verification can be done without sending the password in the clear,
which is Basic's biggest weakness. As with most other authentication
protocols, the greatest sources of risks are usually found not in
the
core protocol itself but in policies and procedures surrounding its
use.
This is the final draft of any document under this name. Digest and
Basic Authentication from the HTTP/1.1 specification will be
combined
and issued as a document titled 'Authentication in HTTP'.Our intent
is that RFC 2068 and RFC 2069 will go to draft standard as a pair of
documents, but with all authentication schemes (Digest and Basic)
documented together in a single place. This transition has not yet
taken place.
"Specification of HTTP/1.1 OPTIONS messages", J Mogul, S Lawrence, J
Cohen, 08/29/1997, <draft-ietf-http-options-02.txt>
RFC2068 defined a new OPTIONS method for HTTP/1.1. The
purpose of OPTIONS is to allow a 'client to determine the
options and/or requirements associated with a resource, or
the capabilities of a server, without implying a resource
action or initiating a resource retrieval.' However,
RFC2068 did not defined a specific syntax for using OPTIONS
to make such a determination. This proposal clarifies the
original specification of OPTIONS, adds several new HTTP
message headers to provide syntactic support for OPTIONS,
and establishes new IANA registries to avoid namespace
conflicts.
"The Alternates Header Field", K. Holtman, A. Mutz, 09/15/1997,
<draft-ietf-http-alternates-00.txt>
HTTP allows web site authors to put multiple versions of the
same information under a single URL. The Alternates header
field can be used to transmit a machine-readable description
of these versions. This allows the recipient to automatically
select the most appropriate version.
"Format and Example of HTTP/1.1 Requirements Summary", J Mogul,
09/15/1997, <draft-ietf-http-req-sum-00.txt>
RFC1122 [1] introduced a ``Requirements Summary'' format,
to help implementors understand what aspects of a lengthy
specification were mandatory, recommended, or optional.
The HTTP/1.1 specification is similarly lengthy and
complicated; many implementors have asked for guidance in
understanding what they need to do. The latest draft
revision of the HTTP/1.1 specification [2] has a
placeholder section for a ``Requirements Summary'', but
there has been relatively little discussion of the format
and content of this summary in the HTTP working group.
This document proposes a specific format for the summary,
and gives an example summary for one section of the
document.
"Hypertext Transfer Protocol -- HTTP/1.1", J Mogul, Tim Berners-Lee, R.
Fielding, H. Nielsen, J. Gettys, 10/16/1997,
<draft-ietf-http-v11-spec-rev-00.txt,.ps>
The Hypertext Transfer Protocol (HTTP) is an application-
level protocol for distributed, collaborative, hypermedia
information systems. It is a generic, stateless, object-
oriented protocol which can be used for many tasks, such as
name servers and distributed object management systems,
through extension of its request methods. A feature of HTTP
is the typing and negotiation of data representation,
allowing systems to be built independently of the data
being
transferred.
IEEE 802.3 Hub MIB (hubmib)
---------------------------
"Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units
(MAUs) using SMIv2", Keith McCloghrie, Donna McMaster, Dan Romascanu, S.
Roberts, K. De Graaf, 03/03/1997, <draft-ietf-hubmib-mau-mib-04.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines objects for managing 10 and 100
Mb/second Medium Attachment Units (MAUs) based on IEEE Std 802.3
Section 30, '10 & 100 Mb/s Management,' October 26, 1995.
This memo does not specify a standard for the Internet community.
Internet Architecture Board (iab)
---------------------------------
"Improved Working Group Coordination", Brian Carpenter, 10/29/1997,
<draft-iab-wgannounce-00.txt>
This is a proposal for a pragmatic way to improve working group
coordination between various standards-related organisations, by use
of a shared mailing list for early announcement of new activities.
Inter-Domain Multicast Routing (idmr)
-------------------------------------
"Protocol Independent Multicast MIB", Keith McCloghrie, D. Farinacci, D.
Thaler, 03/26/1997, <draft-ietf-idmr-pim-mib-03.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing the Protocol Independent Multicast (PIM) protocol [5,6,7,8].
This MIB module is applicable to IP multicast routers which implement
PIM.
"Internet Group Management Protocol MIB", Keith McCloghrie, D. Farinacci,
D. Thaler, 07/21/1997, <draft-ietf-idmr-igmp-mib-05.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing the Internet Group Management Protocol (IGMP). All of this
MIB module is applicable to IP multicast routers [6,7,8,9,10]; a subset
is applicable to hosts implementing IGMPv1 [5] or IGMPv2 [11].
"IP Multicast Routing MIB", Keith McCloghrie, D. Farinacci, D. Thaler,
03/26/1997, <draft-ietf-idmr-multicast-routmib-05.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing IP Multicast Routing [5], independent of the specific
multicast routing protocol [6,7,8,9,10] in use. Managed objects
specific to particular multicast routing protocols are specified
elsewhere.
"Internet Group Management Protocol, Version 2", Bill Fenner, 10/30/1997,
<draft-ietf-idmr-igmp-v2-07.txt>
This draft documents IGMPv2, used by IP hosts to report their
multicast group memberships to routers. It replaces Appendix I of
RFC1112.
IGMPv2 allows group membership termination to be quickly reported
to the routing protocol, which is important for high-bandwidth
multicast groups and/or subnets with highly volatile group
membership.
This document is a product of the Inter-Domain Multicast Routing
working
group within the Internet Engineering Task Force. Comments are
solicited and should be addressed to the working group's mailing list
at
idmr@cs.ucl.ac.uk and/or the author(s).
"Protocol Independent Multicast Version 2, Dense Mode Specification", V.
Jacobson, D. Farinacci, L. Wei, Steve Deering, A. Helmy, 05/28/1997,
<draft-ietf-idmr-pim-dm-spec-05.txt>
This specification defines a multicast routing algorithm for multicast
groups that are densely distributed across an internet. The protocol is
unicast routing protocol independent. It is based on the PIM
sparse-mode [PIMSM] and employs the same packet formats. This protocol
is called dense-mode PIM. The foundation of this design was largely
built on [Deering91].
"Distance Vector Multicast Routing Protocol", T. Pusateri, 10/30/1997,
<draft-ietf-idmr-dvmrp-v3-05.txt,.ps>
DVMRP is an Internet routing protocol that provides an efficient
mechanism for connection-less datagram delivery to a group of hosts
across an internetwork. It is a distributed protocol that
dynamically
generates IP Multicast delivery trees using a technique called
Reverse Path Multicasting (RPM) [Deer90]. This document is an update
to Version 1 of the protocol specified in RFC 1075 [Wait88].5
"Core Based Tree (CBT) Multicast Border Router Specification", Tony
Ballardie, 10/27/1997, <draft-ietf-idmr-cbt-br-spec-00.txt>
This document specifies the behaviour of a CBT multicast border
router (BR) attaching a CBT multicast domain/region (stub or
transit)
to an inter-domain multicast tree, which may be source-rooted or
shared.
This draft assumes a CBT domain's multicast border routers have im-
plemented Multicast BGP such that they can maintain ''come from''
(mul-
ticast) paths that reflect local multicast policy. These may be
inde-
pendent of unicast (''go to'') paths and policy. Provision for this
ca-
pability in BGP is described in [1].
The document provides guidelines that are intended to be generally
aligned with the mechanisms described in the ''Interoperability
Rules
for Multicast Routing Protocols'' [3]. Certain aspects of those
rules
may be interpreted and implemented differently, and therefore some
discretion is left to the implementor.
"Core Based Trees (CBT) Multicast Routing MIB", Tony Ballardie, D.
Thaler, 07/21/1997, <draft-ietf-idmr-cbt-mib-00.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. More precisely, it describes managed objects specific to
the Core Based Trees (CBT) multicast routing protocol version 2 [5].
Managed objects which are common to all multicast routing protocols,
including CBT, can be found in [6].
This MIB module is applicable to IP multicast routers which implement
CBTv2.
"Border Gateway Multicast Protocol (BGMP): Protocol Specification",
Deborah Estrin, David Meyer, D. Thaler, 10/31/1997,
<draft-ietf-idmr-gum-01.txt>
This document describes BGMP, a protocol for inter-domain multicast
routing. BGMP builds shared trees for active multicast groups, and
allows receiver domains to build source-specific, inter-domain,
distribution branches where needed. Building upon concepts from CBT and
PIM-SM, BGMP requires that each multicast group be associated with a
single root (in BGMP it is referred to as the root domain). BGMP
assumes that at any point in time, different ranges of the class D
space
are associated (e.g., with MASC [MASC]) with different domains. Each
of
these domains then becomes the root of the shared domain-trees for all
groups in its range. Multicast participants will generally receive
better multicast service if the session initiator's address allocator
selects addresses from its own domain's part of the space, thereby
causing the root domain to be local to at least one of the session
participants.
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", Deborah Estrin, D. Farinacci, Steve Deering, D. Thaler,
A. Helmy, 09/11/1997, <draft-ietf-idmr-pim-sm-specv2-00.txt,.ps>
This document describes a protocol for efficiently routing to
multicast groups that may span wide-area (and
inter-domain)
internets.
Inter-Domain Routing (idr)
--------------------------
"A Border Gateway Protocol 4 (BGP-4)", Tony Li, Y Rekhter, 06/03/1997,
<draft-ietf-idr-bgp4-06.txt>
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing
protocol. It is built on experience gained with EGP as defined in RFC
904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092
[2] and RFC 1093 [3].
"Definitions of Managed Objects for the Fourth Version of Border Gateway
Protocol (BGP-4)", J. Burruss, Jodi Ito, Jeff Johnson, S. Willis, J. Chu,
03/15/1996, <draft-ietf-idr-bgp4-mib-02.txt>
This memo is an extension to the SNMP MIB. It specifies an IAB
standards track protocol for the Internet community, and requests
discussion and suggestions for improvements. The origin of this memo
is from RFC 1269 'Definitions of Managed Objects for the Board Gateway
Protocol (Version 3)' written by the first two authors of this memo,
which was updated to support BGP-4 in RFC 1657. This memo fixes errors
introduced when the MIB was converted to use the SNMPv2 SMI, as well as
updates references to the Draft Standard SNMPv2 SMI documents.
Distribution of this memo is unlimited. Please forward comments to
bgp@ans.net.
"A Framework for Inter-Domain Route Aggregation", J. Stewart, E. Chen,
07/30/1997, <draft-ietf-idr-aggregation-framework-01.txt>
This document presents a framework for inter-domain route
aggregation
and shows an example router configuration which 'implement' this
framework. This framework is flexible and scales well as it
emphasizes the philosophy of aggregation by the source, both within
routing domains as well as towards upstream providers, and it also
strongly encourages the use of the 'no-export' BGP community to
balance the provider-subscriber need for more granular routing
information with the Internet's need for scalable inter-domain
routing.
"Using a Dedicated AS for Sites Homed to a Single Provider", E. Chen, T.
Bates, R. Chandra, John Stewart III, 07/30/1997,
<draft-ietf-idr-as-dedicated-00.txt>
With the increased growth of the Internet, the number of customers
using BGP4 has grown significantly. RFC1930 outlines a set of guide-
lines for when one needs and should use an AS. However, the customer
and service provider (ISP) are left with a problem as a result of
this in that while there is no need for an allocated AS under the
guidelines, certain conditions make the use of BGP4 a very pragmatic
and perhaps only way to connect a customer homed to a single ISP.
This paper proposes a solution to this problem in line with
recommen-
dations set forth in RFC1930.
"Route Aggregation Tutorial", E. Chen, John Stewart III, 07/30/1997,
<draft-ietf-idr-aggregation-tutorial-00.txt>
Route aggregation is critical to the long-term viability of the
Internet. This document presents practical information that network
managers can use to both understand the concepts of aggregation as
well as put those concepts into use in order to do their part to
make
the Internet stable and allow its continued growth. The intended
audience for this document is anyone responsible for configuring a
network which has its own Autonomous System Number (ASN) and
exchanges routing information with its Internet Service Provider(s)
(ISP(s)) using the Border Gateway Protocol (BGP). This document
does
not cover multi-homing, though multi-homed sites can still benefit
from understanding this material.
"Multiprotocol Extensions for BGP-4", D Katz, Y Rekhter, T. Bates, R.
Chandra, 09/26/1997, <draft-ietf-idr-bgp4-multiprotocol-01.txt>
Currently BGP-4 [BGP-4] is capable of carrying routing information
only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
enable it to carry routing information for multiple Network Layer
protocols (e.g., IPv6, IPX, etc...). The extensions are backward
compatible - a router that supports the extensions can interoperate
with a router that doesn't support the extensions.
"Capabilities Negotiation with BGP-4", J. Scudder, R. Chandra,
09/09/1997, <draft-ietf-idr-bgp4-cap-neg-00.txt>
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
OPEN message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of
new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities,
that is expected to facilitate introduction of new capabilities in
BGP by providing graceful capability negotiation.
The proposed parameter is backward compatible - a router that
supports the parameter can maintain BGP peering with a router that
doesn't support the parameter.
Integrated Directory Services (ids)
-----------------------------------
"Introducing a Directory Service", Erik Huizer, T. Verschuren, P. Jurg,
E. Jeunink, M. Jacobs, 10/17/1995, <draft-ietf-ids-x500-intro-dir-00.txt>
This report provides a 'manual' for establishing an electronic White
Pages Directory Service within an organisation and for connecting it to
a wide-area Directory infrastructure. It is based on the experiences
from the SURFnet Directory Services pilot project. The wide-area
service is of importance to all users of e-mail services who want to
find e-mail addresses of other e-mail users (worldwide!) or any other
address information such as telephone and fax numbers. Establishing
a White Pages Directory Service within an organisation includes a
technical, legal and data management component. As the amount of work
involved in the technical component can be reduced by using standard
equipment and by good support from the provider of the wide-area
Directory infrastructure, the legal and data management issues require
more attention. Legal aspects include formal registration of the
service, informing all registered persons about the service and data
protection.
"The CCSO Nameserver (Ph) Architecture", P. Pomes, Roland Hedberg,
05/06/1997, <draft-ietf-ids-ph-03.txt>
The PH Nameserver from the [Computing and Communications Services
Office (CCSO),] University of Illinois at Urbana-Champaign has for some
time now been used by several organizations as their choice of publicly
available database for information about people as well as other
things. It is now widely felt that the Internet community would
benefit from having a more rigorous definition of the client-server
protocol, this document will hopefully achieve that goal. The Ph
service as specified in this document is built around an information
model, a client command language and the server responses.
"Best Current Practice for the Internet White Pages Service", Harald
Alvestrand, P. Jurg, 04/30/1997, <draft-ietf-ids-ds-bcp-04.txt>
The Internet is used for information exchange and communication between
its users. It can only be effective as such if users are able to find
each other's addresses. Therefore the Internet benefits from an
adequate White Pages Service, i.e., a directory service offering
(Internet) address information related to people and organizations.
"Simple Nomenclator Query Protocol (SNQP)", J. Ordille, J. Elliott,
08/04/1997, <draft-ietf-ids-snqp-01.txt>
The Simple Nomenclator Query Protocol (SNQP) allows a client to
communicate with a descriptive name service or other
relational-style
query service. The protocol is useful to services that search many
data repositories for query responses. Clients can pose queries on
relations, list descriptions of relations, and obtain advice on
reducing the search time and cost of their queries. Clients are
informed of the age of information in caches, and may request more
recent information. SNQP provides support for graphical user
interfaces. It also supports different types of comparison
operators, so services can use SNQP with a variety of back-end
servers, e.g. relational database servers, CCSO servers, and servers
providing relational views of X.500.
SNQP is an ASCII protocol in the request-reply style of SMTP. It
was
specifically designed for use with the Nomenclator name and
information service, and has been useful elsewhere.
"Internet Nomenclator Project", J. Ordille, 08/06/1997,
<draft-ietf-ids-inp-02.txt>
The goal of the Internet Nomenclator Project is to integrate the
hundreds of publicly available CCSO servers from around the world.
Each CCSO server has a database schema that is tailored to the
needs
of the organization that owns it. The project is integrating the
different database schema into one query service. The Internet
Nomenclator Project will provide fast cross-server searches for
locating people on the Internet. It augments existing CCSO
services
by supplying schema integration, more extensive indexing, and two
kinds of caching -- all this in a system that scales as the number
of CCSO servers grows. One of the best things about the system is
that administrators can incorporate their CCSO servers into
Nomenclator without changing the servers. All Nomenclator needs is
basic information about the server.
This document provides an overview of the Nomenclator system,
describes how to register a CCSO server in the Internet Nomenclator
Project, and how to use the Nomenclator search engine to find
people
on the Internet.
Distribution of this document is unlimited. Comments should be
sent
to the author.
"Naming Plan for Internet Directory-Enabled Applications", Steve Kille,
Rick Huber, Sri Sataluri, A. Grimstad, M. Wahl, 09/10/1997,
<draft-ietf-ids-dirnaming-02.txt>
Application of the conventional X.500 approach to naming has
heretofore, in the experience of the authors, proven to be an
obstacle to the wide deployment of directory-enabled applications on
the Internet. We propose a new directory naming plan that leverages
the strengths of the most popular and successful Internet naming
schemes for naming objects in a hierarchical directory. This plan
can, we believe, facilitate the creation of an Internet White Pages
Service (IWPS) and other directory-enabled applications by
overcoming
the problems encountered by those using the conventional X.500
approach to naming.
IETF Steering Group (iesg)
--------------------------
"Guidelines for Writing an IANA Considerations Section in RFCs", Harald
Alvestrand, Thomas Narten, 10/06/1997,
<draft-iesg-iana-considerations-00.txt>
Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (e.g., a
new
option type in DHCP). To insure that such quantities have unique
values, their assignment must be administered by a central
authority.
In the Internet, that role is provided by the Internet Assigned
Numbers Authority (IANA).
In order for the IANA to manage a given numbering space prudently,
it
needs guidelines describing the conditions under which new values
can
be assigned. If the IANA is expected to play a role in the
management
of a numbering space, the IANA must be given clear and concise
guidelines describing that role. This document discusses issues that
should be considered in formulating an identifier assignment policy
and provides guidelines to document authors on the specific text
that
must be included in documents that place demands on the IANA.
"MIB Interoperability Testing", Michael O'Dell, 10/27/1997,
<draft-iesg-odell-mibtest-00.txt>
This document specifies the IESG's interpretation of the Internet
Standards Process for the progression of SNMP MIB specifications to
the Draft Standard level of maturity. It discusses the rationale
for
this interpretation and details the testing which is used to satisfy
the advancement criteria.
Interfaces MIB (ifmib)
----------------------
"The Interfaces Group MIB", Frank Kastenholz, Keith McCloghrie,
10/19/1997, <draft-ietf-ifmib-mib-06.txt>
This memo defines a portion of the Management Information Base
(MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing Network Interfaces.
This memo discusses the 'interfaces' group of MIB-II, especially
the experience gained from the definition of numerous media-
specific MIB modules for use in conjunction with the 'interfaces'
group for managing various sub-layers beneath the internetwork-
layer. It specifies clarifications to, and extensions of, the
architectural issues within the previous model used for the
'interfaces' group.
"Definitions of Managed Objects for System and Interface Testing", Keith
McCloghrie, Kaj Tesink, M. Greene, 06/09/1997,
<draft-ietf-ifmib-testmib-03.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for testing
systems and interfaces. This memo replaces the objects originally
defined in the ifTestGroup of RFC1573, the IF-MIB [6], which have been
deprecated. This memo specifies a MIB module in a manner that is
both compliant to the SNMPv2 SMI, and semantically identical to the
peer SNMPv1 definitions. This memo does not specify a standard for
the Internet community.
Integrated Services (intserv)
-----------------------------
"A Measurement Based Admission Control Algorithm for Controlled-Load
Service with a Reference Implementation Framework", L. Breslau, S. Jamin,
Cheng Jin, 10/09/1997, <draft-ietf-intserv-control-flow-01.txt>
Controlled-Load Service provides data flows with an enhanced quality
of service, in the form of low packet delay and a low probability of
packet loss even under congestion. A network element providing
Controlled-Load Service can use an admission control algorithm to
limit the number of data flows receiving the service. In this
document we describe an admission control algorithm for Controlled-
Load Service. This algorithm is not intended for IETF
standardization. Rather, it is presented for informational purposes
only.
We also present a reference implementation framework for the
measurement-based admission control algorithm. Our implementation
separates the measurement from the actual admission control decision
to provide the flexibility of using different algorithms in
bandwidth
estimation and admission control.
"Integrated Services Management Information Base",, 10/13/1997,
<draft-ietf-intserv-v2-mib-00.txt>
This memo defines a 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 the interface attributes defined in the
Integrated Services Model. Comments should be made to the
Integrated Services Working Group, int-serv@isi.edu.
This memo does not, in its draft form, specify a standard for
the Internet community.
Internetworking Over NBMA (ion)
-------------------------------
"Management Information Base for Frame Relay DTEs", Fred Baker, C. Brown,
09/16/1997, <draft-ietf-iplpdn-frmib-dte-11.txt>
This memo defines a 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 Frame Relay interfaces
on DTEs.
This memo does not specify a standard for the Internet community.
"NBMA Next Hop Resolution Protocol (NHRP)", D Katz, David Piscitello, B.
Cole, J. Luciani, 10/30/1997, <draft-ietf-rolc-nhrp-12.txt>
This document describes the NBMA Next Hop Resolution Protocol
(NHRP).
NHRP can be used by a source station (host or router) connected to a
Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
internetworking layer address and NBMA subnetwork addresses of the
''NBMA next hop'' towards a destination station. If the destination
is
connected to the NBMA subnetwork, then the NBMA next hop is the
destination station itself. Otherwise, the NBMA next hop is the
egress router from the NBMA subnetwork that is ''nearest'' to the
destination station. NHRP is intended for use in a multiprotocol
internetworking layer environment over NBMA subnetworks.
Note that while this protocol was developed for use with NBMA
subnetworks, it is possible, if not likely, that it will be applied
to BMA subnetworks as well. However, this usage of NHRP is for
further study.
This document is intended to be a functional superset of the NBMA
Address Resolution Protocol (NARP) documented in [1].
Operation of NHRP as a means of establishing a transit path across
an
NBMA subnetwork between two routers will be addressed in a separate
document (see [13]).
"NHRP Protocol Applicability Statement", D. Cansever, 07/25/1997,
<draft-ietf-ion-nhrp-appl-02.txt>
As required by the Routing Protocol Criteria [RFC 1264], this draft
report discusses the applicability of the Next Hop Resolution Protocol
(NHRP) in routing of IP datagrams over Non-Broadcast Multiple Access
(NBMA) networks, such as ATM, SMDS and X.25. The final form of this
draft report is a prerequisite to advancing NHRP on the standards
track.
"Classical IP and ARP over ATM", Mark Laubach, Joel Halpern, 10/07/1997,
<draft-ietf-ion-ipatm-classic2-03.txt>
This memo defines an initial application of classical IP and ARP in
an Asynchronous Transfer Mode (ATM) network environment configured
as
a Logical IP Subnetwork (LIS) as described in Section 5. This memo
does not preclude the subsequent development of ATM technology into
areas other than a LIS; specifically, as single ATM networks grow to
replace many Ethernet local LAN segments and as these networks
become
globally connected, the application of IP and ARP will be treated
differently. This memo considers only the application of ATM as a
direct replacement for the
"Definitions of Managed Objects for Classical IP and ARP Over ATM Using
SMIv2", M. Greene, T Kuo, J. Luciani, K. White, 07/14/1997,
<draft-ietf-ion-mib-04.txt>
The purpose of this memo is to define the Management Information Base
(MIB) for supporting Classical IP and ARP over ATM as specified in
Classical IP and ARP over ATM, refer to reference [3]. Support of an
ATM interface by an IP layer will require implementation of objects
from several Management Information Bases (MIBs) as well as their
enhancement in order to enable usage of ATM transports. It is the
intent of this MIB to fully adhere to all prerequisite MIBs unless
explicitly stated. Deviations will be documented in corresponding
conformance statements. The specification of this MIB will utilize the
Structure of Management Information (SMI) for Version 2 of the Simple
Network Management Protocol Version (refer to RFC1902, reference [1]).
"Server Cache Synchronization Protocol (SCSP)", Joel Halpern, G.
Armitage, J. Luciani, 10/30/1997, <draft-ietf-ion-scsp-02.txt>
This document describes the Server Cache Synchronization Protocol
(SCSP) and is written in terms of SCSP's use within Non Broadcast
Multiple Access (NBMA) networks; although, a somewhat straight
forward usage is applicable to BMA networks. SCSP attempts to solve
the generalized cache synchronization/cache-replication problem for
distributed protocol entities. However, in this document, SCSP is
couched in terms of the client/server paradigm in which distributed
server entities, which are bound to a Server Group (SG) through some
means, wish to synchronize the contents (or a portion thereof) of
their caches which contain information about the state of clients
being served.
"ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update", M.
Perez, 10/16/1997, <draft-ietf-ion-sig-uni4.0-05.txt>
This memo describes how to efficiently use the ATM call control
signalling procedures defined in UNI Signalling 4.0 [SIG40] to
support IP over ATM environments as described in RFC XXX [LAUB97]
and
in [LUC97]. Among the new features found in UNI Signalling 4.0 are
Available Bit Rate signalling and traffic parameter negotiation.
This draft highlights the features of UNI Signalling 4.0 that
provide
IP entities capabilities for requesting ATM service in sites with
SVC
support, whether it is private ATM or publicly provisioned ATM, in
which case the SVC support is probably configured inside PVPs.
This document is only relevant to IP when used as the well known
''best effort'' connectionless service. In particular, this means
that
this document does not pertain to IP in the presence of implemented
IP Integrated Services. The topic of IP with Integrated Services
over ATM will be handled by a different specification or set of
specifications being worked on in the ISSLL WG.
This specification is follow-on to RFC 1755, ''ATM Signaling Support
for IP over ATM'', which is based on UNI 3.1 signalling [UNI95].
Readers are assumed to be familiar with RFC 1755.
"IPv6 over Non-Broadcast Multiple Access (NBMA) networks", G. Armitage,
M. Jork, P. Schulter, G. Harter, 10/13/1997, <draft-ietf-ion-ipv6-00.txt>
This document describes a general architecture for IPv6 over NBMA
networks. It forms the basis for subsidiary companion documents that
describe details for various specific NBMA technologies (such as ATM
or Frame Relay). The IPv6 over NBMA architecture allows conventional
host-side operation of the IPv6 Neighbor Discovery protocol, while
also supporting the establishment of 'shortcut' NBMA forwarding
paths
when dynamically signaled NBMA links are available. Operations over
administratively configured Point to Point NBMA links are also
described.
Dynamic NBMA shortcuts are achieved through the use of IPv6 Neighbor
Discovery protocol operation within Logical Links, and inter-router
NHRP for the discovery of off-Link NBMA destinations. Both
flow-triggered and explicitly source-triggered shortcuts are supported.
"Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol
(NHRP)", M. Greene, J. Luciani, 01/31/1997,
<draft-ietf-ion-nhrp-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects for the Next
Hop Resolution Protocol (NHRP) as defined in [1].
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions. This memo does not specify a standard for the Internet
community.
"Multiprotocol Interconnect over Frame Relay", C. Brown, A. Malis, T.
Bradley, 05/07/1997, <draft-ietf-ion-fr-update-03.txt>
This memo describes an encapsulation method for carrying network
interconnect traffic over a Frame Relay backbone. It covers aspects of
both Bridging and Routing.
Systems with the ability to transfer both the encapsulation method
described in this document, and others must have a priori knowledge of
which virtual circuits will carry which encapsulation method and this
encapsulation must only be used over virtual circuits that have been
explicitly configured for its use.
"Classical IP to NHRP Transition", J. Luciani, 05/15/1997,
<draft-ietf-ion-transition-02.txt>
This document describes methods and procedures for the graceful
transition from an ATMARP LIS[1] to an NHRP LIS[2] network model over
ATM.
"Inverse Address Resolution Protocol", C. Brown, A. Malis, T. Bradley,
05/07/1997, <draft-ietf-ion-inarp-update-01.txt>
This memo describes additions to ARP that will allow a station to
request a protocol address corresponding to a given hardware address.
Specifically, this applies to Frame Relay stations that may have a Data
Link Connection Identifier (DLCI), the Frame Relay equivalent of a
hardware address, associated with an established Permanent Virtual
Circuit (PVC), but do not know the protocol address of the station on
the other side of this connection. It will also apply to other
networks with similar circumstances.
"Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM
Networks", M. Greene, C. Chung, 09/15/1997,
<draft-ietf-ion-mars-mib-03.txt>
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community. In particular, it describes managed objects
for IP hosts and routers that use a Multicast Address Resolution
Server (MARS) to support IP multicast over ATM, as described in
'Support for Multicast over UNI 3.0/3.1 based ATM Networks' [1].
This memo specifies a MIB module in a manner that is both compliant
to the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
This memo does not specify a standard for the Internet community.
"NHRP for Destinations off the NBMA Subnetwork", Y Rekhter, 02/03/1997,
<draft-ietf-ion-r2r-nhrp-00.txt>
The NBMA Next Hop Resolution Protocol (NHRP) [NHRP] specifies a
mechanism that allows a source station (e.g., a host or a router) on an
NBMA subnetwork to find the NBMA subnetwork address address of a
destination station when the destination station is connected to the
NBMA subnetwork. For the case where the destination station is off the
NBMA subnetwork the mechanism described in [NHRP] allows to determine
the NBMA subnetwork address of an egress router from the NBMA
subnetwork that is ``nearest'' to the destination station. However,
the ability of determining the egress router is constrained to the
destinations that are directly connected to the egress router.
This document describes extensions to the NBMA Next Hop Resolution
Protocol (NHRP) [NHRP] that allow to acquire and maintain the
information about the egress router without constraining the
destination(s) to be directly connected to the egress router.
"Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM", D.
Farinacci, David Meyer, Y Rekhter, 08/22/1997,
<draft-ietf-ion-intralis-multicast-01.txt>
This document describes how intra-LIS IP multicast can be efficiently
supported among routers over ATM without using the Multicast Address
Resolution Server (MARS). The method described here is specific to
Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism
inherent in PIM-SM to notify routers when they should create group
specific point-to-multipoint VCs.
"A Distributed ATMARP Service Using SCSP", J. Luciani, B. Fox,
04/16/1997, <draft-ietf-ion-scsp-atmarp-00.txt>
This document describes a method for distributing an ATMARP service
within a LIS[1]. This method uses the Server Cache Synchronization
Protocol (SCSP)[2] to synchronize the ATMARP server databases within a
LIS. When SCSP is used to synchronize the caches of ATMARP servers in
a LIS, the LIS defines the boundary of an SCSP Server Group (SG).
"A Distributed NHRP Service Using SCSP", J. Luciani, 10/29/1997,
<draft-ietf-ion-scsp-nhrp-02.txt>
This document describes a method for distributing an NHRP service
within a LIS[1]. This method uses the Server Cache Synchronization
Protocol (SCSP)[2] to synchronize the client information databases
held by NHRP Servers (NHSs) within a LIS.
"ILMI-Based Server Discovery for ATMARP", Michael Davison, 08/20/1997,
<draft-ietf-ion-discov-atmarp-00.txt>
This memo defines how ILMI-based Server Discovery, which provides a
method for ATM-attached hosts and routers to dynamically determine
the ATM address of servers, shall be used to locate ATMARP servers.
"ILMI-Based Server Discovery for MARS", Michael Davison, 08/20/1997,
<draft-ietf-ion-discov-mars-00.txt>
This memo defines how ILMI-based Server Discovery, which provides a
method for ATM-attached hosts and routers to dynamically determine
the ATM address of servers, shall be used to locate MARS servers.
"A Distributed MARS Service Using SCSP", J. Luciani, A. Gallo,
07/25/1997, <draft-ietf-ion-scsp-mars-00.txt>
This document describes a method for distributing a MARS service within
a LIS[1]. This method uses the Server Cache Synchronization Protocol
(SCSP)[2] to synchronize the MARS Server databases within a LIS. When
SCSP is used to synchronize the caches of MARS Servers in a LIS, the
LIS defines the boundary of an SCSP Server Group (SG).
"Intra-area IP unicast among routers over legacy ATM", Juha Heinanen,
07/25/1997, <draft-ietf-ion-intra-area-unicast-00.txt>
This document describes how IP unicast can be efficiently implemented
among routers belonging to the same area of a routing domain, where the
connectivity is provided by a legacy ATM network as defined by the ATM
Forum or ITU. This proposal is designed to be complementary to IP
multicast solutions such as the one described in [1].
"ILMI-Based Server Discovery for NHRP", Michael Davison, 08/20/1997,
<draft-ietf-ion-discov-nhrp-00.txt>
This memo defines how ILMI-based Server Discovery, which provides a
method for ATM-attached hosts and routers to dynamically determine
the ATM address of servers, shall be used to locate NHRP servers.
"IPv6 over ATM Networks", G. Armitage, M. Jork, P. Schulter, G. Harter,
10/13/1997, <draft-ietf-ion-ipv6-atm-00.txt>
This document is a companion to the ION working group's architecture
document 'IPv6 over Non Broadcast Multiple Access (NBMA) networks'.
It provides specific details on how to apply the IPv6 over NBMA
architecture to ATM networks. This architecture allows conventional
host-side operation of the IPv6 Neighbor Discovery protocol, while
also supporting the establishment of 'shortcut' ATM forwarding paths
(when using SVCs). Operation over administratively configured Point
to Point PVCs is also supported.
IP Over IEEE 1394 (ip1394)
--------------------------
"Ipv4 over IEEE 1394", Peter Johansson, 10/27/1997,
<draft-ietf-ip1394-ipv4-04.txt,.ps>
This document specifies how to use IEEE Std 1394-1995, Standard for a
High Performance Serial Bus (and its supplements), for the
transport of
Internet Protocol Version 4 (IPv4) datagrams. It defines the
necessary
methods, data structures and code for that purpose and
additionally
defines a standard method for Address Resolution Protocol (ARP).
IP over Cable Data Network (ipcdn)
----------------------------------
"Cable Device Management Information Base for MCNS compliant Cable Modems
and Cable Modem Termination Systems", G. Roeck, 09/09/1997,
<draft-ietf-ipcdn-cable-device-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines a basic set of managed objects
for
SNMP-based management of MCNS compliant Cable Modems and Cable Modem
Termination Systems.
This memo specifies a MIB module in a manner that is compliant to the
SNMPv2 SMI. The set of objects is consistent with the SNMP framework
and existing SNMP standards.
This memo does not specify a standard for the Internet community.
This memo is a product of the IPCDN working group within the Internet
Engineering Task Force. Comments are solicited and should be addressed
to the working group's mailing list at ipcdn@terayon.com and/or the
author.
"Radio Frequency (RF) Interface Management Information Base for MCNS
compliant RF interfaces", G. Roeck, 09/03/1997,
<draft-ietf-ipcdn-rf-interface-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines a basic set of managed objects
for
SNMP-based management of MCNS compliant Radio Frequency (RF)
interfaces.
This memo specifies a MIB module in a manner that is compliant to the
SNMPv2 SMI. The set of objects is consistent with the SNMP framework
and existing SNMP standards.
This memo does not specify a standard for the Internet community.
This memo is a product of the IPCDN working group within the Internet
Engineering Task Force. Comments are solicited and should be addressed
to the working group's mailing list at ipcdn@terayon.com and/or the
author.
"IP Over Cable Data Networks - Terms of Reference", Mike St. Johns,
07/29/1997, <draft-ietf-ipcdn-tor-00.txt>
This document describes a number of possible architectures and design
considerations for an IP-over-Cable data system. It sets the basic
framework for discussion and creation of the document set described in
the charter for the working group.
"Logical IP Subnetworks over IEEE 802.14 Services", Mark Laubach,
08/01/1997, <draft-ietf-ipcdn-ipover-802d14-00.txt>
This memo defines an initial application of classical IP and ARP in
an IEEE 802.14 Community Access Television (CATV) Residential Access
Network environment. IEEE 802.14 services provide two independent
link layer service interfaces which are available to support IP
residential access networking services: traditional Ethernet
bridging
(via IEEE 802.1D layer services) and residential ATM networking
services.
In this memo, the term Logical IP Subnetwork (LIS) is defined to
apply to Classical IP over ATM LIS's operating over IEEE 802.14
services as well as traditional IP over Ethernet operating over IEEE
802.14 services.
The recommendations in this draft rely on existing IETF standards
for
the family of Classical IP and ARP over ATM (IPOA) services and for
IP and ARP over Broadcast Ethernet networks. The tree-based
hierarchic nature of the IEEE 802.14 MAC subnetwork permits
convenient extensions to Classical IPOA model for broadcast and
multicast in the downstream direction of the CATV plant.
"Logical IP Subnetworks over MCNS Data Link Services", Gerry White,
08/28/1997, <draft-ietf-ipcdn-ip-over-mcns-00.txt>
This memo defines an initial application of IP and ARP in an MCNS
Community Access Television (CATV) Residential Access Network
environment where the cable system is used for bi-directional data
transfer. The MCNS network provides a traditional Ethernet or 802.2
link layer service between a cable system head end and the customer
premises using the cable television system infrastructure. This
interface is available via IEEE 802.1D layer services to support IP
residential access networking services.
In this memo, the term Logical IP Subnetwork (LIS) is defined to
apply to traditional IP over Ethernet operating over MCNS services.
The recommendations in this draft rely on existing IETF standards
for
IP and ARP over Broadcast Ethernet networks.
IPNG (ipngwg)
-------------
"Generic Packet Tunneling in IPv6 Specification", A. Conta, Steve
Deering, 06/24/1997, <draft-ietf-ipngwg-ipv6-tunnel-07.txt>
This document defines the model and generic mechanisms for IPv6
encapsulation of Internet packets, such as IPv6 and IPv4. The model
and mechanisms can be applied to other protocol packets as well, such
as AppleTalk, IPX, CLNP, or others.
"Link Local Addressing and Name Resolution in IPv6", D. Harrington,
01/29/1997, <draft-ietf-ipngwg-linkname-01.txt>
This draft proposes an experimental mechanism by which IPv6 link-local
addresses and associated system names may be distributed among
interconnected hosts, for use by users and applications. It provides
an overview of the problem, a proposed solution (including suggested
protocol details), and lists various related issues. This work is
introduced to the IPng Working Group initially, although it might also
have implications or concerns relevant to individuals working on
directory services and other areas.
"IPv6 Router Alert Option", C. Partridge, D Katz, Ran Atkinson, A.
Jackson, 07/30/1997, <draft-ietf-ipngwg-ipv6router-alert-03.txt>
This memo describes a new IPv6 Hop-by-Hop Option type that alerts
transit routers to more closely examine the contents of an IP
datagram. This option is useful for situations where a datagram
addressed to a particular destination contains information that may
require special processing by routers along the path.
"IPv6 Multicast Address Assignments", Bob Hinden, Steve Deering,
07/16/1997, <draft-ietf-ipngwg-multicast-assgn-04.txt>
This document defines the initial assignment of IPv6 multicast
addresses. It is based on the 'IP Version 6 Addressing Architecture'
[ADDARCH] and current IPv4 multicast address assignment found in
ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses. It
adapts the IPv4 assignments that are relevant to IPv6 assignments. IPv4
assignments that were not relevant were not converted into IPv6
assignments. Comments are solicited on this conversion.
All other IPv6 multicast addresses are reserved.
Sections 2 and 3 specify reserved and preassigned IPv6 multicast
addresses. [ADDRARCH] defines rules for assigning new IPv6
multicast addresses.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC 2119].
"IP Version 6 over PPP", Dimitry Haskin, E. Allen, 07/02/1997,
<draft-ietf-ipngwg-ipv6-over-ppp-02.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
This document defines the method for transmission of IP Version 6 [2]
packets over PPP links as well as the Network Control Protocol (NCP)
for establishing and configuring the IPv6 over PPP. It also specifies
the method of forming IPv6 link-local addresses on PPP links.
"Management Information Base for IP Version 6: UDP and TCP Groups",
Dimitry Haskin, S. Onishi, 03/24/1997,
<draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt>
This document is one in the series of documents that define various MIB
object groups for IPv6. Specifically, the UDP and TCP groups are
defined in this document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets. This
document specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
"Management Information Base for IP Version 6: Textual Conventions and
General Group", Dimitry Haskin, S. Onishi, 06/10/1997,
<draft-ietf-ipngwg-ipv6-mib-02.txt>
This document is one in the series of documents that provide MIB
definitions for IP Version 6. Specifically, the IPv6 MIB textual
conventions as well as the IPv6 MIB General group is defined in this
document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets. This
document specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
"Management Information Base for IP Version 6: ICMPv6 Group", Dimitry
Haskin, S. Onishi, 03/24/1997, <draft-ietf-ipngwg-ipv6-icmp-mib-01.txt>
This document is one in the series of documents that define various MIB
object groups for IPv6. Specifically, the ICMPv6 group is defined in
this document.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets. This
document specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
"GSE - An Alternate Addressing Architecture for IPv6", Michael O'Dell,
02/24/1997, <draft-ietf-ipngwg-gseaddr-00.txt>
This document presents an alternative addressing architecture for IPv6
which controls global routing growth by very aggressive topological
aggregation. It includes support for scalable multi-homing as a
distinguished service. It provides for future independent evolution of
routing and forwarding models with essentially no impact on end
systems. Finally, it frees sites and service resellers from the
tyranny of CIDR-based aggregation by providing transparent re-homing of
both.
"Transmission of IPv6 Packets over Ethernet Networks", M. Crawford,
09/26/1997, <draft-ietf-ipngwg-trans-ethernet-03.txt>
This document specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on Ethernet networks. It also
specifies the content of the Source/Target Link-layer Address
option
used in Router Solicitation, Router Advertisement, Neighbor
Solicitation, Neighbor Advertisement and Redirect messages when
those messages are transmitted on an Ethernet.
This document replaces RFC 1972, 'A Method for the Transmission of
IPv6 Packets over Ethernet Networks', which will become historic.
"Transmission of IPv6 Packets over FDDI Networks", M. Crawford,
09/26/1997, <draft-ietf-ipngwg-trans-fddi-net-03.txt>
This document specifies the frame format for transmission of IPv6
packets and the method of forming IPv6 link-local addresses and
statelessly autoconfigured addresses on FDDI networks. It also
specifies the content of the Source/Target Link-layer Address
option
used in Router Solicitation, Router Advertisement, Neighbor
Solicitation, Neighbor Advertisement and Redirect messages when
those messages are transmitted on an FDDI network.
This document replaces RFC 2019, 'Transmission of IPv6 Packets Over
FDDI', which will become historic.
"Synthesis of Routing Goop and AAAA Records in IPv6", J. Bound,
03/25/1997, <draft-ietf-ipngwg-dns-rr-rgadd-00.txt>
This document is a proposal to redefine the existing DNS AAAA resource
record into two resource records: an RG record to define the routing
topology of an IPv6 address and an aAA record to define the End System
Identifier of an IPv6 address. The document will define the synthesis
of the RG and aAA record at the DNS primary server, which will return
an AAAA record to DNS resolvers. The objective of this work is to
split the AAAA record in the DNS into location and identifier to
provide future capabilities for dynamic renumbering of addresses. This
work was spawned by the GSE - Alternate Addressing Architecture
Proposal for IPv6.
"IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering,
03/26/1997, <draft-ietf-ipngwg-ipv6-arch-00.txt>
This specification defines the addressing architecture of the IP
Version 6 protocol [IPV6]. The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 nodes required addresses.
"Router Renumbering for IPv6", Bob Hinden, M. Crawford, 07/30/1997,
<draft-ietf-ipngwg-router-renum-01.txt>
IPv6 Neighbor Discovery [ND] and Address Autoconfiguration [AA]
conveniently make initial assignments of address prefixes to hosts.
Aside from the problem of connection survival across a renumbering
event, these two mechanisms also simplify the reconfiguration of
hosts when the set of valid prefixes changes.
This document defines a mechanism called Router Renumbering (RR)
which allows address prefixes on routers to be configured and
reconfigured almost as easily as the combination of Neighbor
Discovery and Address Autoconfiguration works for hosts. It
provides a means for a network manager to make updates to the
prefixes used by and advertised by IPv6 routers throughout a site.
"Separating Identifiers and Locators in Addresses: An Analysis of the
GSE Proposal for IPv6", Lixia Zhang, Allison Mankin, J. Stewart, Thomas
Narten, M. Crawford, 09/16/1997, <draft-ietf-ipngwg-esd-analysis-01.txt>
On February 27-28, 1997, the IPng Working Group held an interim
meeting in Palo Alto, California to consider adopting Mike O'Dell's
'GSE - An Alternate Addressing Architecture for IPv6' proposal
[GSE].
In GSE, 16-byte IPv6 addresses are split into three portions: a
globally unique End System Designator (ESD), a Site Topology
Partition (STP) and a Routing Goop (RG) portion. The STP corresponds
(roughly) to a site's subnet portion of an IPv4 address, whereas the
RG identifies the attachment point to the public Internet. Routers
use the RG+STP portions of addresses (called 'Routing Stuff' in this
document) to route packets to the link to which the destination is
directly attached; the ESD is used to deliver the packet across the
last hop link. An important idea in GSE is that nodes within a site
do not know the RG portion of their addresses. A border router at
the
site's Internet connect point would dynamically replace the RG part
of source addresses of all outgoing IP datagrams and the RG part of
destination addresses on incoming traffic.
This document provides a detailed analysis of the GSE plan. Much of
the analysis presented here is an expansion of official meeting
minutes, though it also includes issues uncovered by the authors in
the process of fully fleshing out the analysis. In summary, the
working group eventually decided that the full addresses of nodes
within a site should not be hidden from those nodes, so as a result
it is not necessary for routers to rewrite the Routing Goop portion
of addresses. However, other parts of the GSE plan were adopted
(e.g., having 64-bit interface identifiers with an option for
specifying them as globally unique and easing the renumbering of the
high-order portion of addresses within DNS).
In addition to analyzing the GSE proposal in particular, the
document
also studies the general issue of separating network
"IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering,
10/16/1997, <draft-ietf-ipngwg-addr-arch-v2-03.txt>
This specification defines the addressing architecture of the IP
Version 6 protocol [IPV6]. The document includes the IPv6
addressing
model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and
an
IPv6 node's required addresses.
"An IPv6 Aggregatable Global Unicast Address Format", Bob Hinden, Michael
O'Dell, Steve Deering, 07/16/1997,
<draft-ietf-ipngwg-unicast-aggr-02.txt>
This document defines an IPv6 aggregatable global unicast address
format for use in the Internet. The address format defined in this
document is consistent with the IPv6 Protocol [IPV6] and the 'IPv6
Addressing Architecture' [ARCH]. It is designed to facilitate scalable
Internet routing.
This documented replaces RFC 2073, 'An IPv6 Provider-Based Unicast
Address Format'. RFC 2073 will become historic.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC 2119].
"IPv6 Testing Address Allocation", J. Postel, Bob Fink, Bob Hinden,
07/16/1997, <draft-ietf-ipngwg-testv2-addralloc-01.txt>
This document describes an allocation plan for IPv6 addresses to be
used in testing IPv6 prototype software. These addresses are temporary
and will be reclaimed in the future. Any IPv6 system using these
addresses will have to renumber at some time in the future. These
addresses will not to be routable in the Internet other than for IPv6
testing. The address format for the IPv6 test address is
consistent with the 'Aggregatable Global Unicast Address Allocation'
[AGGR] and 'TLA and NLA Assignment Rules' [TLAASN].
This document is intended to replace RFC1897 'IPv6 Testing Address
Allocation', January 1996. RFC1897 will become historic.
The addresses described in this document are consistent with the IPv6
Addressing Architecture [ARCH]. They may be assigned to nodes
manually, with IPv6 Auto Address Allocation [AUTO], or with DHCP for
IPv6 [DHCPv6]. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and
'OPTIONAL' in this document are to be interpreted as described in [RFC
2119].
"IP Version 6 Management Information Base for the User Datagram
Protocol", M. Daniele, 06/10/1997,
<draft-ietf-ipngwg-ipv6-udp-mib-00.txt>
This document is one in the series of documents that define various MIB
objects for IPv6. Specifically, this document is the MIB module which
defines managed objects for implementations of the User Datagram
Protocol (UDP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the
applicability of RFC 2013 for implementations of IPv6. Namely, the
most of managed objects defined in RFC 2013 are independent of which IP
versions underly UDP, and only the UDP listener information is IP
version-specific.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
"IP Version 6 Management Information Base for the Transmission Control
Protocol", M. Daniele, 06/10/1997,
<draft-ietf-ipngwg-ipv6-tcp-mib-00.txt>
This document is one in the series of documents that define various MIB
objects for IPv6. Specifically, this document is the MIB module which
defines managed objects for implementations of the Transmission Control
Protocol (TCP) over IP Version 6 (IPv6).
This document also recommends a specific policy with respect to the
applicability of RFC 2012 for implementations of IPv6. Namely, the
most of managed objects defined in RFC 2012 are independent of which IP
versions underly TCP, and only the TCP connection information is IP
version-specific.
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the IPv6-based
internets.
"Transmission of IPv6 Packets over Token Ring Networks", Thomas Narten,
M. Crawford, S. Thomas, 10/27/1997,
<draft-ietf-ipngwg-trans-tokenring-03.txt>
This memo specifies the MTU and frame format for transmission
of IPv6 packets on Token Ring networks. It also specifies the
method of forming IPv6 link-local addresses on Token Ring
networks and the content of the Source/Target Link-layer
Address option used the Router Solicitation, Router
Advertisement, Redirect, Neighbor Solicitation and Neighbor
Advertisement messages when those messages are transmitted on
a Token Ring network.
"TLA and NLA Assignment Rules", Bob Hinden, Michael O'Dell, 07/16/1997,
<draft-ietf-ipngwg-tla-assignment-00.txt>
This document defines assignment rules for Top-Level Aggregation
Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as
defined in [AGGR]. These rules apply to registries allocating TLA ID's
and to organizations receiving TLA ID's.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',
'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this
document are to be interpreted as described in [RFC 2119].
"IPv6 Name Lookups Through ICMP", M. Crawford, 07/25/1997,
<draft-ietf-ipngwg-icmp-namelookups-01.txt>
IPv4 addresses are translated to fully-qualified domain names (FQDNs)
using the DNS. Experience shows that the IN-ADDR.ARPA zones used for
this translation tend to be poorly maintained in many cases. In a
larger internet with more frequent site renumbering, the maintenance of
such zones will be even more difficult.
This document describes a protocol for simply asking an IPv6 node to
supply its FQDN when needed. The DNS style of authority delegation is
thus eliminated for IPv6 address-to-name translations and the routing
infrastructure plays that role.
"Neighbor Discovery for IP Version 6 (IPv6)", W. Simpson, Thomas Narten,
Erik Nordmark, 10/06/1997, <draft-ietf-ipngwg-discovery-v2-00.txt>
This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to
discover each other's presence, to determine each other's link-layer
addresses, to find routers and to maintain reachability information
about the paths to active neighbors.
"IPv6 Stateless Address Autoconfiguration", Susan Thomson, Thomas Narten,
07/30/1997, <draft-ietf-ipngwg-addrconf-v2-00.txt>
This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they should be obtained through the
stateless mechanism, the stateful mechanism, or both. This document
defines the process for generating a link-local address, the process
for generating site-local and global addresses via stateless address
autoconfiguration, and the Duplicate Address Detection procedure.
The
details of autoconfiguration using the stateful protocol are
specified elsewhere.
"Internet Protocol, Version 6 (IPv6) Specification", Bob Hinden, Steve
Deering, 07/30/1997, <draft-ietf-ipngwg-ipv6-spec-v2-00.txt>
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
"Site prefixes in Neighbor Discovery", Erik Nordmark, 07/30/1997,
<draft-ietf-ipngwg-site-prefixes-00.txt>
This document specifies extensions to IPv6 Neighbor Discovery to
carry site-prefixes. The site prefixes are used to reduce the
effect
of site renumbering by ensuring that the communication inside a site
uses site-local addresses.
"Internet Control Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", A. Conta, Steve Deering, 10/27/1997,
<draft-ietf-ipngwg-icmp-v2-00.txt>
This document specifies a set of Internet Control Message Protocol
(ICMP) messages for use with version 6 of the Internet Protocol
(IPv6).
Internet Printing Protocol (ipp)
--------------------------------
"Requirements for an Internet Printing Protocol", F. Wright, 10/16/1997,
<draft-ietf-ipp-req-01.txt>
This document is one of a set of documents which together
describe all aspects of a new Internet Printing Protocol
(IPP).
IPP is an application level protocol that can be used for
distributed printing on the Internet. The protocol is heavily
influenced by the printing model introduced in the Document
Printing Application (ISO/IEC 10175 DPA) standard. Although
DPA
identifies the both end user and administrative features, IPP
is
initially focused only on the end user functionality.
The full set of IPP documents include:
Requirements for an Internet Printing Protocol
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Protocol Specification
Rationale for the Structure and Model and Protocol for the
Internet Printing Protocol
"Internet Printing Protocol/1.0: Model and Semantics", P. Powell, T.
Hasting, R. Herriot, S. Isaacson, R. deBry, 10/27/1997,
<draft-ietf-ipp-model-06.txt>
This document is one of a set of documents, which together
describe
all aspects of a new Internet Printing Protocol (IPP). IPP is
an
application level protocol that can be used for distributed
printing
using Internet tools and technology. The protocol is heavily
influenced by the printing model introduced in the Document
Printing
Application (DPA) [ISO10175] standard. Although DPA specifies
both
end user and administrative features, IPP version 1.0 is
focused only
on end user functionality.
"Internet Printing Protocol/1.0: Directory Schema", S. Isaacson, K.
Carter, 06/24/1997, <draft-ietf-ipp-dir-schema-01.txt>
This document is one of a set of documents which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technology. The protocol is heavily influenced
by the printing model introduced in the Document Printing Application
(ISO/IEC 10175 DPA) standard. Although DPA specifies both end user and
administrative features, IPP version 1.0 is focused on end user
functionality. Although DPA specifies both end user and administrative
features, IPP version 1.0 is focused only on end user functionality.
"Internet Printing Protocol/1.0: Security", R. deBry, J. Hadsell, D.
Manchala, X. Riley, J. Wenn, 07/31/1997, <draft-ietf-ipp-security-01.txt>
This document is one of a set of documents which together
describe all aspects of a new Internet Printing Protocol
(IPP).
IPP is an application level protocol that can be used for
distributed printing on the Internet. The protocol is heavily
influenced by the printing model introduced in the Document
Printing Application (ISO/IEC 10175 DPA) standard, which
describes a distributed printing service. The full set of IPP
documents includes:
Requirements for an Internet Printing Protocol
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Security
Internet Printing Protocol/1.0: Protocol Specification
Internet Printing Protocol/1.0: Directory Schema
This document is the `Internet Printing Protocol/1.0:
Security'
document.
"Mapping between LPD and IPP Protocols", J. Martin, T. Hasting, R.
Herriot, N. Jacobs, 07/31/1997, <draft-ietf-ipp-lpd-ipp-map-01.txt>
This Internet-Draft specifies the mapping between (1) the commands
and operands of the 'Line Printer Daemon (LPD) Protocol' specified
in RFC 1179 and (2) the operations and parameters of the Internet
Printing Protocol (IPP). One of the purposes of this document is
to compare the functionality of the two protocols. Another
purpose
is to facilitate implementation of gateways between LPD and IPP.
WARNING: RFC 1179 was not on standards track. While RFC 1179 was
intended to record existing practice, it fell short in some areas.
However, this specification maps between (1) the actual current
practice of RFC 1179 and (2) IPP. This document does not attempt
to map the numerous divergent extensions to the LPD protocol that
have been made by many implementers.
"Internet Printing Protocol/1.0: Protocol Specification", R. Turner, R.
Herriot, Sylvan Butler, Paul Moore, 10/31/1997,
<draft-ietf-ipp-protocol-02.txt>
This document is one of a set of documents, which together describe
all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technology. The protocol is heavily
influenced
by the printing model introduced in the Document Printing Application
(ISO/IEC 10175 DPA) standard [dpa]. Although DPA specifies both end
user and administrative features, IPP version 1.0 is focused only on
end
user functionality.
The full set of IPP documents includes:
Internet Printing Protocol: Requirements
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Protocol Specification
The requirements document takes a broad look at distributed printing
functionality, and it enumerates real-life scenarios that help to
clarify the features that need to be included in a printing protocol
for
the Internet. It identifies requirements for three types of users: end
users, operators, and administrators. The requirements document calls
out a subset of end user requirements that MUST be satisfied in the
first version of IPP. Operator and administrator requirements are out
of scope for v1.0. The model and semantics document describes a
simplified model with abstract objects, their attributes, and their
operations. The model introduces a Printer object and a Job object.
The
Job object supports multiple documents per job. The protocol
specification is formal document which incorporates the ideas in all
the
other documents into a concrete mapping using clearly defined data
representations and transport protocol mappings that real implementers
can use to develop interoperable client and printer (server) side
components.
This document is the ''Internet Printing Protocol/1.0: Protocol
Specification'' document.
"Rationale for the Structure of the Model and Protocol for the Internet
Printing Protocol (IPP)", Steve Zilles, 08/01/1997,
<draft-ietf-ipp-rat-01.txt>
This document is one of a set of documents which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing on
the Internet. There are multiple parts to IPP, but the primary
architectural components are the Model, the Protocol and an interface
to Directory Services. This document provides a high level overview of
the architecture and provides the rational for the decisions made in
structuring the architecture.
IP Payload Compression Protocol (ippcp)
---------------------------------------
"IP Payload Compression Protocol (IPComp)", A. Shacham, 10/01/1997,
<draft-ietf-ippcp-protocol-01.txt>
This document describes a protocol intended to provide lossless
compression for Internet Protocol datagrams in an Internet
environment.
IP Security Protocol (ipsec)
----------------------------
"Internet Security Association and Key Management Protocol (ISAKMP)", D.
Maughan, M. Schertler, M. Schneider, J. Turner, 07/29/1997,
<draft-ietf-ipsec-isakmp-08.txt,.ps>
This memo describes a protocol utilizing security concepts necessary
for establishing Security Associations (SA) and cryptographic keys in
an Internet environment. A Security Association protocol that
negotiates, establishes, modifies and deletes Security Associations and
their attributes is required for an evolving Internet, where there will
be numerous security mechanisms and several options for each security
mechanism. The key management protocol must be robust in order to
handle public key generation for the Internet community at large and
private key requirements for those private networks with that
requirement. The Internet Security Association and Key
Management Protocol (ISAKMP) defines the procedures for authenticating
a communicating peer, creation and management of Security Associations,
key generation techniques, and threat mitigation (e.g. denial of
service and replay attacks). All of these are necessary to establish
and maintain secure communications (via IP Security Service or any
other security protocol) in an Internet environment.
"The OAKLEY Key Determination Protocol", H. Orman, 07/25/1997,
<draft-ietf-ipsec-oakley-02.txt>
This document describes a protocol, named OAKLEY, by which two
authenticated parties can agree on secure and secret keying material.
The basic mechanism is the Diffie-Hellman key exchange algorithm.
The OAKLEY protocol supports Perfect Forward Secrecy, compatibility
with the ISAKMP protocol for managing security associations,
user-defined abstract group structures for use with the Diffie-Hellman
algorithm, key updates, and incorporation of keys distributed via
out-of-band mechanisms.
"The ESP Triple DES Transform", W. Simpson, Naganand Doraswamy, Perry
Metzger, 07/03/1997, <draft-ietf-ipsec-ciph-des3-00.txt>
This document describes the 'Triple' DES-EDE3-CBC block cipher
transform interface used with the IP Encapsulating Security Payload
(ESP). It provides compatible migration from RFC-1851.
"IP Authentication Header", Stephen Kent, Ran Atkinson, 10/03/1997,
<draft-ietf-ipsec-auth-header-02.txt>
The IP Authentication Header (AH) is used to provide connectionless
integrity and data origin authentication for IP datagrams (hereafter
referred to as just 'authentication'), and to provide protection
against replays. This latter, optional service may be selected, by
the receiver, when a Security Association is established. AH
provides authentication for as much of the IP header as possible, as
well as for upper level protocol data. However, some IP header
fields may change in transit and the value of these fields, when the
packet arrives at the receiver, may not be predictable by the
transmitter. The values of such fields cannot be protected by AH.
Thus the protection provided to the IP header by AH is somewhat
piecemeal.
AH may be applied alone, in combination with the IP Encapsulating
Security Payload (ESP) [KA97b], or in a nested fashion through the
use of tunnel mode (see 'Security Architecture for the Internet
Protocol' [KA97a], hereafter referred to as the Security
Architecture
document). Security services can be provided between a pair of
communicating hosts, between a pair of communicating security
gateways, or between a security gateway and a host. ESP may be used
to provide the same security services, and it also provides a
confidentiality (encryption) service. The primary difference
between
the authentication provided by ESP and AH is the extent of the
coverage. Specifically, ESP does not protect any IP header fields
unless those fields are encapsulated by ESP (tunnel mode). For more
details on how to use AH and ESP in various network environments,
see the Security Architecture document [KA97a].
It is assumed that the reader is familiar with the terms and
concepts
described in the Security Architecture document. In particular, the
reader should be familiar with the definitions of security services
offered by AH and ESP,
"The resolution of ISAKMP with Oakley", D. Carrel, D. Harkins,
07/16/1997, <draft-ietf-ipsec-isakmp-oakley-04.txt>
[MSST96] (ISAKMP) provides a framework for authentication and key
exchange but does not define them. ISAKMP is designed to be key
exchange independant; that is, it is designed to support many different
key exchanges.
[Orm96] (Oakley) describes a series of key exchanges-- called 'modes'--
and details the services provided by each (e.g. perfect forward secrecy
for keys, identity protection, and authentication).
[Kra96] (SKEME) describes a versatile key exchange technique which
provides anonymity, repudiability, and quick key refreshment.
This document describes a protocol using part of Oakley and part of
SKEME in conjunction with ISAKMP to obtain authenticated keying
material for use with ISAKMP, and for other security associations such
as AH and ESP for the IETF IPsec DOI.
"The Internet IP Security Domain of Interpretation for ISAKMP", D. Piper,
10/09/1997, <draft-ietf-ipsec-ipsec-doi-05.txt>
The Internet Security Association and Key Management Protocol
(ISAKMP) defines a framework for security association management and
cryptographic key establishment for the Internet. This framework
consists of defined exchanges, payloads, and processing guidelines
that occur within a given Domain of Interpretation (DOI). This
document defines the Internet IP Security DOI (IPSEC DOI), which
instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate
security associations.
For a description of how the IPSEC DOI fits into the overall IP
Security Documentation framework, please see [ROADMAP].
For a list of changes since the previous version of the IPSEC DOI,
please see Section 5.
"Inline Keying within the ISAKMP Framework.", B. Sommerfeld, 03/26/1997,
<draft-ietf-ipsec-inline-isakmp-01.txt>
The current proposal for IP-layer key management [ISAKMP, OAKLEY,
ISAOAK] has fairly high overhead. Before a security association can be
established, at least one pair of messages need to be exchanged between
the communicating peers. For efficiency, this suggests that ISAKMP
setup should be infrequent. However, general principles of key
management suggest that individual keys should be used as little as
practical and changed as frequently as possible. Steve Bellovin has
suggested that, ideally, different security associations should be used
for each different transport-level connection[BADESP]. This document
discusses a way of structuring a protocol to permit this to happen with
minimal overhead, both in round-trip delay at connection setup, and in
bandwidth once the connection is established. The general
concept of inline or in-band keying here was inspired by SKIP[SKIP].
However, SKIP's approach is burdened by the addition of an extra
intermediate header of perhaps 20 to 28 bytes to every protected
packet, which doubles the bandwidth overhead of protected traffic
compared with ESP with fixed keying. In order to minimise the
per-packet overhead, an inline keying header
"Implementation of Virtual Private Network (VPNs) with IP Security",
Naganand Doraswamy, 03/14/1997, <draft-ietf-ipsec-vpn-00.txt>
This document discusses methods for implementing Virtural Private
Networks (VPN) with IP Security (IPSec). We discuss different scenarios
in which VPN is implemented and the security implications for each of
these scenarios.
"The ESP RC5-CBC Algorithm", R. Baldwin, R. Pereira, 07/02/1997,
<draft-ietf-ipsec-ciph-rc5-cbc-00.txt>
This document describes the RC5 block cipher algorithm as to be used
with the IPSec Encapsulating Security Payload (ESP).
"The ESP CAST128-CBC Algorithm", G. Carter, R. Pereira, 07/03/1997,
<draft-ietf-ipsec-ciph-cast128-cbc-00.txt>
This document describes the CAST-128 block cipher algorithm as to be
used with the IPSec Encapsulating Security Payload (ESP).
"A revised encryption mode for ISAKMP/Oakley", H. Krawczyk, P. Cheng, R.
Canetti, 08/05/1997, <draft-ietf-ipsec-revised-enc-mode-01.txt>
The ISAKMP/Oakley document [HC97] describes a proposed standard for
using the Oakley Key Exchange Protocol in conjunction with ISAKMP to
obtain authenticated and secret keying material for use with ISAKMP,
and for other security associations such as AH and ESP for the IETF
IPsec DOI.
The public-key encryption method of carrying out Phase 1 of the key
exchange in the ISAKMP/Oakley document provides significant security
advantages over the other alternatives and should be the method of
choice in many implementations. Unfortunately, as currently
described in [HC97] the method requires two public key
encryption and decryption operations from both the Initiator and
the Responder. The present document describes a small modification
to this method. The resulting scheme requires only one public key
encryption and decryption operation from each party, while
maintaining
(and even improving on) the strong security properties of the
ISAKMP/Oakley public-key encryption mode.
Remark: This document is NOT self-contained, it is intended as an
addendum to the authentication methods defined in [HC97].
In particular, it uses notation and definitions of [HC97].
Thus, it is best read in conjunction with [HC97].
"The ESP DES-CBC Transform", P. Karn, W. Simpson, Perry Metzger,
07/03/1997, <draft-ietf-ipsec-ciph-des-derived-00.txt>
This document describes the DES-CBC block cipher transform interface
used with the IP Encapsulating Security Payload (ESP). It provides
compatible migration from RFC-1829.
"IP Security Document Roadmap", Rodney Thayer, Naganand Doraswamy, R.
Glenn, 07/30/1997, <draft-ietf-ipsec-doc-roadmap-01.txt>
The IPsec protocol suite is used to provide privacy and
authentication services at the IP layer. Several documents are used
to describe this protocol suite. The interrelationship and
organization of the various documents covering the IPsec protocol
are
discussed here. An explanation of what to find in which document,
and what to include in new Encryption Algorithm and Authentication
Algorithm documents are described.
"The Use of HMAC-SHA-1-96 within ESP and AH", C. Madson, R. Glenn,
07/02/1997, <draft-ietf-ipsec-auth-hmac-sha196-00.txt>
This draft describes the use of the HMAC algorithm [RFC-2104] in
conjunction with the SHA-1 algorithm [FIPS-180-1] as an authentication
mechanism within the revised IPSEC Encapsulating Security Payload [ESP]
and the revised IPSEC Authentication Header [AH]. HMAC with SHA-1
provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH
implementations is provided by [Thayer97a].
"The Use of HMAC-MD5-96 within ESP and AH", C. Madson, R. Glenn,
07/02/1997, <draft-ietf-ipsec-auth-hmac-md5-96-00.txt>
This draft describes the use of the HMAC algorithm [RFC-2104] in
conjunction with the MD5 algorithm [RFC-1321] as an authentication
mechanism within the revised IPSEC Encapsulating Security Payload [ESP]
and the revised IPSEC Authentication Header [AH]. HMAC with MD5
provides data origin authentication and integrity protection.
Further information on the other components necessary for ESP and AH
implementations is provided by [Thayer97a].
"The ESP DES-CBC Cipher Algorithm With Explicit IV", Naganand Doraswamy,
C. Madson, 07/02/1997, <draft-ietf-ipsec-ciph-des-expiv-00.txt>
This document describes the use of the DES Cipher algorithm in Cipher
Block Chaining Mode, with an explicit IV, as a confidentiality
mechanism within the context of the IPSec Encapsulating Security
Payload (ESP).
"ESP with Cipher Block Chaining (CBC)", W. Simpson, 07/03/1997,
<draft-ietf-ipsec-cbc-00.txt>
This document describes the Cipher Block Chaining (CBC) mode, used by a
number of Internet Encapsulating Security Payload (ESP) transforms.
"The ESP ARCFOUR Algorithm", Rodney Thayer, 07/03/1997,
<draft-ietf-ipsec-ciph-arcfour-00.txt>
This draft describes the use of the ARCFOUR [Kaukonen] stream cipher
algorithm to be used with the IPSec Encapsulating Security Payload
[ESP].
"The ESP DES-XEX3-CBC Transform", W. Simpson, R. Baldwin, 07/03/1997,
<draft-ietf-ipsec-ciph-desx-00.txt>
This document describes the 'DESX' DES-XEX3-CBC block cipher transform
interface used with the IP Encapsulating Security Payload (ESP).
"The ESP Blowfish-CBC Algorithm Using an Explicit IV", R. Adams,
07/17/1997, <draft-ietf-ipsec-ciph-blowfish-cbc-00.txt>
This draft describes the use of the Blowfish [Schneier] block cipher
algorithm to be used with the IPSec Encapsulating Security Payload
(ESP) [Kent97].
"The ESP 3DES-CBC Algorithm Using an Explicit IV", Rodney Thayer, R.
Pereira, 07/21/1997, <draft-ietf-ipsec-ciph-3des-expiv-00.txt>
This document describes the 'Triple' DES-EDE3-CBC block cipher
algorithm used with the IP Encapsulating Security Payload (ESP). Use
of an explicit IV is described.
"IP Encapsulating Security Payload (ESP)", Stephen Kent, Ran Atkinson,
10/06/1997, <draft-ietf-ipsec-esp-v2-01.txt>
The Encapsulating Security Payload (ESP) header is designed to
provide a mix of security services in IPv4 and IPv6.
"The ESP IDEA-CBC Algorithm Using Explicit IV", R. Adams, 07/22/1997,
<draft-ietf-ipsec-ciph-idea-cbc-00.txt>
This draft describes the use of the IDEA [Schneier] block cipher
algorithm in CBC mode with the IPSec Encapsulating Security Payload
(ESP) [Kent97].
"The ESP CAST5-128-CBC Transform", W. Simpson, Perry Metzger, 07/30/1997,
<draft-ietf-ipsec-ciph-cast-div-00.txt>
This document describes the CAST5-128-CBC block cipher transform
interface used with the IP Encapsulating Security Payload (ESP). It
provides a full-sized 128-bit key, with a more secure derived ini-
tialization variable, and a more efficient smaller datagram size.
"The ESP CBC-Mode Cipher Algorithms", R. Adams, R. Pereira, 10/02/1997,
<draft-ietf-ipsec-ciph-cbc-00.txt>
This document describes how to use CBC-mode cipher algorithms with
the IPSec ESP (Encapsulating Security Payload) Protocol. It not
only clearly states how to use certain cipher algorithms, but also
how to use all CBC-mode cipher algorithms.
"The ISAKMP Configuration Mode",, 10/02/1997,
<draft-ietf-ipsec-isakmp-mode-cfg-00.txt>
This document describes a new ISAKMP mode that allows configuration
items to be set by using both push/acknowledge and request/reply
paradigms.
Integrated Services over Specific Link Layers (issll)
-----------------------------------------------------
"Providing integrated services over low-bitrate links", C. Bormann,
07/24/1997, <draft-ietf-issll-isslow-02.txt>
This document describes an architecture for providing integrated
services over low-bitrate links, such as modem lines, ISDN B-channels,
and sub-T1 links. It covers only the lower parts of the Internet
Multimedia Conferencing Architecture [1]; additional components
required for application services such as Internet Telephony (e.g., a
session initiation protocol) are outside the scope of this document.
The main components of the architecture are: a real-time encapsulation
format for asynchronous and synchronous low-bitrate links, a header
compression architecture optimized for real-time flows, elements of
negotiation protocols used between routers (or between hosts and
routers), and announcement protocols used by applications to allow this
negotiation to take place. This document is a product of the IETF
ISSLL working group. Comments are solicited and should be addressed to
the working group's mailing list at issll@mercury.lcs.mit.edu and/or
the author.
"Interoperation of Controlled-Load and Guaranteed-Service with ATM", M.
Borden, M. Garrett, 08/04/1997, <draft-ietf-issll-atm-mapping-03.txt>
Service mappings are an important aspect of effective interoperation
between Internet Integrated Services and ATM networks. This document
provides guidelines for ATM virtual connection features and parameters
to be used in support of the IP integrated services protocols. The
specifications include IP Guaranteed Service, Controlled-Load Service
and ATM Forum UNI specification, versions 3.0, 3.1 and 4.0.
These service mappings are intended to facilitate effective end-to-end
Quality of Service for IP networks containing ATM subnetworks. We
discuss the various features of the IP and ATM protocols, and identify
solutions and difficult issues of compatibility and interoperation.
"SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over
IEEE 802-style networks", R. Yavatkar, Fred Baker, D. Hoffman, Y. Bernet,
07/25/1997, <draft-ietf-issll-is802-sbm-04.txt>
This document outlines a signaling method and protocol for RSVP-based
admission control over IEEE 802-style LANs. The proposed method is
designed to work both with the current generation of IEEE 802 LANs and
new work being defined within the IEEE 802 committee.
"A Framework for Providing Integrated Services Over Shared and Switched
LAN Technologies", Vijay Srinivasan, W. Pace, A. Ghanwani, 05/09/1997,
<draft-ietf-issll-is802-framework-02.txt>
Traditionally, LAN technologies such as ethernet and token ring have
been required to handle best effort services only. No standard
mechanism exists for providing service guarantees on these media as
will be required by emerging and future multimedia applications. The
anticipated demand for such applications on the Internet has led to the
development of RSVP, a signaling mechanism for performing resource
reservation in the Internet. Concurrently, the Integrated Services
working group within the IETF has been working on the definition of
service classes called Integrated Services which are expected to make
use of RSVP. Applications will use these service classes in order to
obtain the desired quality of service from the network. LAN
technologies such as token ring and ethernet typically constitute the
last hop in Internet connections. It is therefore necessary to enhance
these technologies so that they are able to support the Integrated
Services. This memo describes a framework for providing the
functionality to support Integrated Services on shared and switched LAN
technologies.
"The Multi-Class Extension to Multi-Link PPP", C. Bormann, 07/24/1997,
<draft-ietf-issll-isslow-mcml-02.txt>
A companion document describes an architecture for providing integrated
services over low-bitrate links, such as modem lines, ISDN B-channels,
and sub-T1 links [1]. The main components of the architecture are: a
real-time encapsulation format for asynchronous and synchronous
low-bitrate links, a header compression architecture optimized for
real-time flows, elements of negotiation protocols used between routers
(or between hosts and routers), and announcement protocols used by
applications to allow this negotiation to take place.
This document proposes the fragment-oriented solution for the real-time
encapsulation format part of the architecture. The general approach is
to start from the PPP Multilink fragmentation protocol [2] and provide
a small number of extensions to add functionality and reduce the
overhead. This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to the two working
groups' mailing lists at issll@mercury.lcs.mit.edu and
ietf-ppp@merit.edu and/or the author.
"Integrated Services over IEEE 802.1D/802.1p Networks", M. Seaman, A.
Smith, Eric Crawley, 06/23/1997, <draft-ietf-issll-802-01.txt>
This document describes the support of IETF Integrated Services over
LANs built from IEEE 802 network segments which may be interconnected
by draft standard IEEE P802.1p switches.
It describes the practical capabilities and limitations of this
technology for supporting Controlled Load [8] and Guaranteed Service
[9] using the inherent capabilities of the relevant 802 technologies
[5],[6] etc. and the proposed 802.1p queuing features in switches. IEEE
P802.1p [2] is a superset of the existing IEEE 802.1D bridging
specification. This document provides a functional model for the layer
3 to layer 2 and user-to-network dialogue which supports admission
control and defines requirements for interoperability between switches.
The special case of such networks where the sender and receiver are
located on the same segment is also discussed. This scheme
expands on the ISSLL over 802 LANs framework described in [7]. It makes
reference to an admission control signaling protocol developed by the
ISSLL WG which is known as the 'Subnet Bandwidth Manager'. This is an
extension to the IETF's RSVP protocol [4] and is described in a
separate document [10].
"PPP in a real-time oriented HDLC-like framing", C. Bormann, 07/31/1997,
<draft-ietf-issll-isslow-rtf-01.txt>
A companion document describes an architecture for providing
integrated services over low-bitrate links, such as modem lines,
ISDN
B-channels, and sub-T1 links [1]. The main components of the
architecture are: a real-time encapsulation format for asynchronous
and synchronous low-bitrate links, a header compression architecture
optimized for real-time flows, elements of negotiation protocols
used
between routers (or between hosts and routers), and announcement
protocols used by applications to allow this negotiation to take
place.
This document proposes the suspend/resume-oriented solution for the
real-time encapsulation format part of the architecture. The
general
approach is to start from the PPP Multilink fragmentation protocol
[2] and its multi-class extension [5] and add suspend/resume in a
way
that is as compatible to existing hard- and firmware as possible.
This document is a product of the IETF ISSLL working group.
Comments are solicited and should be addressed to the two working
groups' mailing lists at issll@mercury.lcs.mit.edu and ietf-
ppp@merit.edu and/or the author.
"Network Element Service Specification for Low Speed Networks", S.
Jackowski, 05/12/1997, <draft-ietf-issll-isslow-svcmap-00.txt>
This document defines the service mappings for controlled load and
guaranteed services over low-bitrate networks. These low bitrate
networks typically include components such as analog lines, ISDN
connections and sub-T1 rate links. The document specifies the
per-network element packet handling behavior, parameters required,
traffic specification, policing requirements, and traffic ordering
relationships which are required to provide both Guaranteed and
Controlled Load service capabilities. It also includes evaluation
criteria for elements providing the service. This document is
a product of the IETF ISSL working group and is based on [1] and [2]
which describe modifications to the PPP protocol to enable these
services.
"RSVP over ATM Implementation Requirements", Lou Berger, 07/11/1997,
<draft-ietf-issll-atm-imp-req-00.txt, .ps>
This note presents specific implementation requirements for running
RSVP over ATM switched virtual circuits (SVCs). It presents
requirements that ensure interoperability between multiple
implementations and conformance to the RSVP and Integrated Services
specifications. A separate document [6] provides specific guidelines
for running over today's ATM networks. The general problem is
discussed in [11]. Integrated Services to ATM service mappings are
covered in [9]. The full set of documents present the background and
information needed to implement Integrated Services and RSVP over ATM.
"A Framework for Integrated Services and RSVP over ATM", M. Borden, John
Krawczyk, Lou Berger, Eric Crawley, 07/24/1997,
<draft-ietf-issll-atm-framework-00.txt>
This document outlines the framework and issues related to providing IP
Integrated Services with RSVP over ATM. It provides an overall approach
to the problem(s) and related issues. These issues and problems are to
be addressed in further documents from the ISATM subgroup of the ISSLL
working group.
Editor's Note
This document is the merger of two previous documents,
draft-ietf-issll-atm-support-02.txt by Berger and Berson and
draft-crawley-rsvp-over-atm-00.txt by Baker, Berson, Borden, Crawley,
and Krawczyk. The former document has been split into this document
and a set of documents on RSVP over ATM implementation requirements and
guidelines.
"Integrated Service Mappings on IEEE 802 Networks", M. Seaman, A. Smith,
Eric Crawley, 07/30/1997, <draft-ietf-issll-is802-svc-mapping-00.txt>
This document describes the support of IETF Integrated Services over
LANs built from IEEE 802 network segments which may be interconnected
by
IEEE 802.1 MAC Bridges (switches) [1].
It describes the practical capabilities and limitations of this
technology for supporting Controlled Load [8] and Guaranteed Service
[9]
using the inherent capabilities of the relevant 802 technologies
[5],[6],[15],[16] etc. and the proposed 802.1p queuing features in
switches. IEEE P802.1p [2] is a superset of the existing IEEE 802.1D
bridging specification. This document provides a functional model for
the layer 3 to layer 2 and user-to-network dialogue which supports
admission control and defines requirements for interoperability between
switches. The special case of such networks where the sender and
receiver are located on the same segment is also discussed.
This scheme expands on the ISSLL over 802 LANs framework described in
[7]. It makes reference to a signaling protocol for admission control
developed by the ISSLL WG which is known as the 'Subnet Bandwidth
Manager'. This is an extension to the IETF's RSVP protocol [4] and is
described in a separate document [10].
Large Scale Multicast Applications (lsma)
-----------------------------------------
"Scenarios and Appropriate Protocols for Distributed Interactive
Simulation", Michael Myjak, W. Smith, S. Seidensticker, 07/21/1997,
<draft-ietf-lsma-scenarios-01.txt>
We describe distributed interactive simulation (DIS) scenarios from the
vantage point of hardware and software vendors who would need to
address the network implications and requirements to enable large scale
networked multiplayer virtual worlds. This document is meant to migrate
the knowledge of the traditional Department of Defense (DoD) modeling
and simulation community into tangible design metrics for the
commercial networking community [2]. [Note: The term 'DIS' is used here
generically to describe the type of simulations used to implement these
scenarios. It does not imply the use of IEEE 1278.1 protocols[1],
frequently referred to as DIS protocols.]
"Limitations of Internet Protocol Suite for Distributed Simulation in the
Large Multicast Environment", Mark Pullen, Michael Myjak, C. Bouwens,
03/26/1997, <draft-ietf-lsma-limitations-01.txt>
The Large-Scale Multicast Applications (LSMA) working group was
chartered to produce two Internet-Drafts aimed at a consensus-based
development of the Internet protocols to support large scale, real-time
distributed simulation. This draft defines aspects of the Internet
protocols that LSMA has found may need further development in order to
meet that goal.
"Taxonomy of Communication Requirements for Large-scale Multicast
Applications", P Bagnall, B Briscoe, 07/30/1997,
<draft-ietf-lsma-requirements-00.txt>
The intention of this draft is to define a classification system for
the
communication requirements of any large-scale multicast application
(LSMA). It is very unlikely one protocol can achieve a compromise
between the diverse requirements of all the parties involved in any
LSMA. It is therefore necessary to understand the worst-case scenarios
in order to minimise the range of protocols needed. Dynamic protocol
adaptation is likely to be necessary which will require logic to map
particular combinations of requirements to particular mechanisms.
Standardising the way that applications define their requirements is a
necessary step towards this. Classification is a first step towards
standardisation.
Mail and Directory Management (madman)
--------------------------------------
"Mail Monitoring MIB", Steve Kille, Ned Freed, 08/20/1997,
<draft-ietf-madman-mail-monitor-mib-05.txt>
This memo defines a portion of the Management Information Base (MIB)
for
use with network management protocols in the Internet community.
Specifically, this memo extends the basic Network Services Monitoring
MIB [8] to allow monitoring of Message Transfer Agents (MTAs). It may
also be used to monitor MTA components within gateways.
"Network Services Monitoring MIB", Steve Kille, Ned Freed, 08/20/1997,
<draft-ietf-madman-nsm-mib-06.txt>
A networked application is a realization of some well defined service
on
one or more host computers that is accessible via some network, uses
some network for its internal operations, or both.
"Directory Server Monitoring MIB", Steve Kille, Glenn Mansfield,
08/02/1997, <draft-ietf-madman-dsa-mib-1-04.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
Specifically, this memo extends the basic Network Services
Monitoring
MIB [9] to allow monitoring of Directory Servers.
"Message Tracking MIB", Gordon Jones, 08/21/1997,
<draft-ietf-madman-trackmib-00.txt>
This document defines a message tracking Management Information Base
(MIB) for electronic messaging usage. Message tracking is the ability
to find out, after the fact, the path that a particular message took
through the messaging system and the current status of that message.
Mobile Ad-hoc Networks (manet)
------------------------------
"Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues
and Evaluation Considerations", Joseph Macker, Scott Corson, 09/15/1997,
<draft-ietf-manet-issues-00.txt>
This memo describes the concept of mobile ad hoc networking--giving a
rationale for its existence and outlining the unique issues and
challenges found in this form of purely wireless, mobile networking.
"Mobile Ad Hoc Networking Terminology", C. Perkins, 10/31/1997,
<draft-ietf-manet-term-00.txt>
This document presents conventional definitions for many terms to be
used during the discussion of various algorithms for enabling ad hoc
networks of mobile computers, particularly over wireless media.
MBONE Deployment (mboned)
-------------------------
"Multicast pruning a necessity", J. Hawkinson, 08/04/1997,
<draft-ietf-mboned-pruning-02.txt>
This document calls for the MBone to be free of non-pruning
multicast
as soon as possible, due to the high cost to the Internet of the
traffic resulting from them. Consensus is that [DATE 1 month from
RFC
publication] is the goal date for elimating non-pruning multicast
routers.
It cites several ways to eliminate non-pruning multicast from a
network, allowing per-site flexibility.
"Administratively Scoped IP Multicast", David Meyer, 06/10/1997,
<draft-ietf-mboned-admin-ip-space-03.txt>
This document defines the 'administratively scoped IPv4 multicast
space' to be the range 239.0.0.0 to 239.255.255.255. In addition, it
describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes [RFC1884] and IPv4 multicast
address classes. This memo is a product of the MBONE
Deployment Working Group (MBONED) in the Operational Requirements area
of the Internet Engineering Task Force. Submit comments to
<mboned@ns.uoregon.edu> or the author.
"Introduction to IP Multicast Routing", T. Maufer, C. Semeria,
10/28/1997, <draft-ietf-mboned-intro-multicast-03.txt>
The first part of this paper describes the benefits of multicasting,
the MBone, Class D addressing, and the operation of the Internet Group
Management Protocol (IGMP). The second section explores a number of
different techniques that may potentially be employed by multicast
routing protocols:
o Flooding
o Spanning Trees
o Reverse Path Broadcasting (RPB)
o Truncated Reverse Path Broadcasting (TRPB)
o Reverse Path Multicasting (RPM)
o ''Shared-Tree'' Techniques
The third part contains the main body of the paper. It describes how
the previous techniques are implemented in multicast routing protocols
available today (or under development).
o Distance Vector Multicast Routing Protocol (DVMRP)
o Multicast Extensions to OSPF (MOSPF)
o Protocol-Independent Multicast - Dense Mode (PIM-DM)
o Protocol-Independent Multicast - Sparse Mode (PIM-SM)
o Core-Based Trees (CBT)
"Some Issues for an Inter-domain Multicast Routing Protocol", David
Meyer, 06/10/1997, <draft-ietf-mboned-imrp-some-issues-02.txt>
The IETF's Inter-Domain Multicast Routing (IDMR) working group has
produced several multicast routing protocols, including Core Based
Trees [CBT] and Protocol Independent Multicasting [PIMARCH]. In
addition, the IDMR WG has formalized the specification of the Distance
Vector Multicast Routing Protocol [DVMRP]. Various specifications for
protocol inter-operation have also been produced (see, for example,
[THALER96] and [PIMMBR]). However, none of these protocols seems
ideally suited to the inter-domain routing case; that is, while these
protocols are appropriate for the intra-domain routing environment,
they break down in various ways when applied in to the multi-provider
inter-domain case. This document considers some of
the scaling, stability and policy issues that are of primary importance
in a inter-domain, multi-provider multicast environment.
"Guidelines for Rate Limits on the MBONE", D. Junkins, 02/19/1997,
<draft-ietf-mboned-limit-rate-guide-00.txt>
Much confusion and misunderstanding exists in the Internet community on
the use of rate limits on the Multicast Backbone (MBONE). This
document dispels some of the misunderstandings of rate limits and
describes the best current practices for when to implement rate limits
on MBONE links. It is a product of the Multicast Deployment Working
Group in the Operational Requirements area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
"PIM Multicast Border Router (PMBR) specification for connecting PIM-SM
domains to a DVMRP Backbone", Deborah Estrin, D. Thaler, A. Helmy,
02/24/1997, <draft-ietf-mboned-pmbr-spec-00.txt, .ps>
This document specifies the behavior of PIM-SM Multicast Border Routers
(PMBRs) that connect PIM-SM to DVMRP networks. We assume that the
reader is familiar with the PIM-SM protocol specification.[Estrin96]
"Multicast Debugging Handbook", B. Aboba, D. Thaler, 03/26/1997,
<draft-ietf-mboned-mdh-00.txt>
This document serves as a handbook for the debugging of multicast
connectivity problems. In addition to reviewing commonly
encountered problems, the draft summarizes publicly distributable
multicast dianostic tools, and provides examples of their use, along
with pointers to source and binary distributions.
MIME Encapsulation of Aggregate HTML Documents (mhtml)
------------------------------------------------------
"Sending HTML in E-mail, an informational supplement to RFC ???: MIME
E-mail Encapsulation of Aggregate HTML Documents (MHTML)", J. Palme,
07/21/1997, <draft-ietf-mhtml-info-06.txt>
The memo 'MIME E-mail Encapsulation of Aggregate HTML Documents
(MHTML)' (draft-ietf-mhtml-spec-04.txt) specifies how to send packaged
aggregate HTML objects in MIME e-mail. This memo is an accompanying
informational document, intended to be an aid to developers. This
document is not an Internet standard.
Issues discussed are implementation methods, caching strategies,
problems with rewriting of URIs, making messages suitable both for
mailers which can and which cannot handle Multipart/related and
handling recipients which do not have full Internet connectivity.
"MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", A.
Hopmann, J. Palme, 10/27/1997, <draft-ietf-mhtml-rev-02.txt>
Although HTML [RFC 1866] was designed within the context of MIME,
more than the specification of HTML as defined in RFC 1866 is needed
for two electronic mail user agents to be able to interoperate using
HTML as a document format. These issues include the naming of
objects that are normally referred to by URIs, and the means of
aggregating objects that go together. This document describes a set
of guidelines that will allow conforming mail user agents to be able
to send, deliver and display these objects, such as HTML objects,
that can contain links represented by URIs. In order to be able to
handle inter-linked objects, the document uses the MIME type
''multipart/related'' and specifies the MIME content-headers
''Content-Location'' and ''Content-Base''. The guidelines in this
document can also be used when sending aggregate HTML objects in
other forms than e-mail, such as through HTTP or FTP.
Differences compared to the previous version of this proposed
standard, published in RFC 2110, are summarized in chapter 13.
"Content-ID and Message-ID Uniform Resource Locators", Ed Levinson,
07/25/1997, <draft-ietf-mhtml-cid-v2-00.txt>
The Uniform Resource Locator (URL) schemes, 'cid:' and 'mid:' allow
references to messages and the body parts of messages. For example,
within a single multipart message, one HTML body part might include
embedded references to other parts of the same message.
"The MIME Multipart/Related Content-type",, 09/09/1997,
<draft-ietf-mhtml-rel-v2-00.txt>
The Multipart/Related content-type provides a common mechanism for
representing objects that are aggregates of related MIME body parts.
This document defines the Multipart/Related content-type and
provides
examples of its use.
MIME - X.400 Gateway (mixer)
----------------------------
"MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and
RFC 822/MIME", Steve Kille, 03/20/1997,
<draft-kille-mixer-rfc1327bis-05.txt>
This document relates primarily to the ITU-T 1988 and 1992 X.400 Series
Recommendations / ISO IEC 10021 International Standard. This ISO/ITU-T
standard is referred to in this document as 'X.400', which is a
convenient shorthand. Any reference to the 1984 Recommendations will
be explicit. Any mappings relating to elements which are in the 1992
version and not in the 1988 version will be noted explicitly. X.400
defines an Interpersonal Messaging System (IPMS), making use of a store
and forward Message Transfer System. This document relates to the
IPMS, and not to wider application of X.400, such as EDI as defined in
X.435.
"Mapping between X.400 and RFC-822/MIME Message Bodies", Harald
Alvestrand, 04/30/1997, <draft-ietf-mixer-bodymap-07.txt>
This document is a companion to [MIXER], which defines the principles
and translation of headers for interworking between MIME-based RFC-822
mail and X.400 mail. This document defines how to map body
parts of X.400 messages into MIME entities and vice versa, including
the handling of multipart messages and forwarded messages.
A table of contents that should be quite useful for locating specific
sections is given in the back of the document.
"X.400 image body parts", Harald Alvestrand, 09/16/1996,
<draft-ietf-mixer-images-01.txt>
This document contains the body parts defined in RFC 1495 for carrying
image formats that were originally defined in MIME through an X.400
system.
This document is an Experimental standard; if it turns out to be useful
and widely deployed, it can be moved onto the standards track.
It also documents the OIDs assigned to these data formats as FTAM body
parts, which allow the MIME types to be converted to FTAM body parts;
this will probably be more useful than the new body parts defined here.
"A MIME body part for FAX", Harald Alvestrand, 02/20/1997,
<draft-ietf-mixer-fax-01.txt>
This document contains the definitions, originally contained in RFC
1494, on how to carry CCITT G3Fax in MIME, and how to translate it to
its X.400 representation.
This document is an Experimental standard; if it turns out to be useful
and widely deployed, it can be moved onto the standards track.
NOTE: At the moment, this format does not seem appropriate for a
'general purpose image format for the Internet', if such a beast can
exist. It exists only to carry information that is already in G3 Fax
format, and may be usefully converted to other formats when used in
specific contexts.
"A MIME body part for ODA", Harald Alvestrand, 02/20/1997,
<draft-ietf-mixer-oda-01.txt>
This document contains the definitions, originally contained in RFC
1495 and RFC 1341, on how to carry ODA in MIME, and how to translate it
to its X.400 representation.
This document is an Experimental standard; if it turns out to be useful
and widely deployed, it can be moved onto the standards track.
"Carrying PostScript in X.400 and MIME", Harald Alvestrand, 02/20/1997,
<draft-ietf-mixer-postscript-01.txt>
This document describes methods for carrying PostScript information in
the two standard mail systems MIME and X.400, and the conversion
between them. It uses the notational conventions of [BODYMAP], and the
conversion is further described in [MIXER].
Two ways of carrying PostScript in X.400 are described.
One is using the FTAM Body Part, and one uses the Extended Body Part
originally described in RFC 1494.
The FTAM method is recommended.
"Using the Internet DNS to Distribute MIXER Conformant Global Address
Mapping (MCGAM)", C. Allocchio, 07/11/1997,
<draft-ietf-mixer-rfc1664bis-01.txt>
This memo is the complete technical specification to store in the
Internet Domain Name System (DNS) the mapping information (MCGAM)
needed by MIXER conformant e-mail gateways and other tools to map
RFC822 domain names into X.400 O/R names and vice versa. Mapping
information can be managed in a distributed rather than a centralised
way. Organizations can publish their MIXER mapping or preferred gateway
routing information using just local resources (their local DNS
server), avoiding the need for a strong coordination with any
centralised organization. MIXER conformant gateways and tools located
on Internet hosts can retrieve the mapping information querying the DNS
instead of having fixed tables which need to be centrally updated and
distributed. This memo obsoletes RFC1664. It includes the changes
introduced by MIXER specification with respect to RFC1327: the new
'gate1' (O/R addresses to domain) table is fully supported. Full
backward compatibility with RFC1664 specification is mantained, too.
RFC1664 was a joint effort of IETF X400 operation working group
(x400ops) and TERENA (formely named 'RARE') Mail and Messaging working
group (WG-MSG). This update was performed by the IETF MIXER working
group.
"MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail", C.
Allocchio, 01/31/1997, <draft-ietf-mixer-mail11-00.txt>
This document describes a set of mappings which will enable inter
working between systems operating the ISO/IEC 10021 - CCITT (now ITU)
X.400 Recommendations on Message Handling Systems, and systems running
the Mail-11 (also known as DECnet mail or VMSmail) protocol. The
specifications are valid both within DECnet Phase IV and DECnet/OSI
addressing and routing scheme.
The complete scenario of X.400 / MIME / Mail-11 is also considered, in
order to cover the possible complex cases arising in multiple gateway
translations.
This document covers mainly the X.400 O/R address to/from Mail-11
address mapping and the RFC822 to/from Mail-11 ones; other mappings are
based on MIXER specifications. Bodypart mappings are not specified in
this document: MIXER and MIME-MHS specifications can be applied to map
bodyparts between X.400, MIME and Mail-11, too. In fact MIME encoding
can be used without modifications within Mail-11 text bodyparts. This
document obsoletes RFC 1405, which was a combined effort of TERENA
Working Group on Messaging, and the IETF X.400 Ops Working Group.
"Use of an X.500/LDAP directory to support MIXER address mapping", Steve
Kille, 07/16/1997, <draft-ietf-mixer-directory-02.txt>
This document defines how to use an X.500 or LDAP directory to support
the mapping between X.400 OR Addresses and mailboxes defined in MIXER
(RFC 1327bis) [5].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited.
"Representing Tables and Subtrees in the X.500 Directory",, 08/29/1997,
<draft-ietf-mixer-subtrees-00.txt>
This document defines techniques for representing two types of
information mapping in the OSI Directory [1].
1. Mapping from a key to a value (or set of values), as might be done
in a table lookup.
2. Mapping from a distinguished name to an associated value (or
values), where the values are not defined by the owner of the
entry. This is achieved by use of a directory subtree.
"Representing the O/R Address hierarchy in the X.500 Directory
Information Tree",, 08/29/1997, <draft-ietf-mixer-infotree-00.txt>
This document defines a representation of the O/R Address hierarchy in
the Directory Information Tree [6, 1]. This is useful for a range of
purposes, including:
o Support for MHS Routing [4].
o Support for X.400/RFC 822 address mappings [2, 5].
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<mhs-ds@mercury.udev.cdc.com>.
Multiparty Multimedia Session Control (mmusic)
----------------------------------------------
"SDP: Session Description Protocol", V. Jacobson, Mark Handley,
09/09/1997, <draft-ietf-mmusic-sdp-04.txt,.ps>
This document defines the Session Description Protocol, SDP.
SDP is intended for describing multimedia sessions for the
purposes of session announcement, session invitation, and
other forms of multimedia session initiation.
This document is a product of the Multiparty Multimedia Session
Control
(MMUSIC) working group of the Internet Engineering Task Force.
Comments
are solicited and should be addressed to the working group's
mailing
list at confctrl@isi.edu and/or the authors.
"Real Time Streaming Protocol (RTSP)", H. Schulzrinne, A. Rao, R.
Lanphier, 10/29/1997, <draft-ietf-mmusic-rtsp-05.txt,.ps>
The Real Time Streaming Protocol, or RTSP, is an application-level
protocol for control over the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as
UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 1889).
This is a snapshot of the current draft which will become the next
version of the ``official'' Internet Draft.
"SIP: Session Initiation Protocol", Eve Schooler, H. Schulzrinne, Mark
Handley, 08/02/1997, <draft-ietf-mmusic-sip-03.txt,.ps>
Many styles of multimedia conferencing are likely to co-exist on the
Internet, and many of them share the need to invite users to
participate. The Session Initiation Protocol (SIP) is a simple protocol
designed to enable the invitation of users to participate in such
multimedia sessions. It is not tied to any specific conference control
scheme, providing support for either loosely or tightly controlled
sessions. In particular, it aims to enable user mobility by relaying
and redirecting invitations to a user's current location.
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force.
Comments are solicited and should be addressed to the working group's
mailing list at confctrl@isi.edu and/or the authors.
"Specification of Security in SAP Using Public Key Algorithms", Peter
Kirstein, G. Montasser-Kohsari, E. Whelan, 10/28/1997,
<draft-ietf-mmusic-sap-sec-03.txt,.ps>
The Session Announcement Protocol (SAP) has been specified in such a
way
that authentication and privacy can be assured. However the algorithms
and mechanisms to achieve such security are not prescribed in the
current draft. This document extends the SAP protocol, by describing
specific algorithms and formats of authentication and encryption
formats
based on PGP and PKCS#7 standards. It is a companion document to
draft-ietf-mmusic-sap.
This document is a product of the Multiparty Multimedia Session Control
(MMUSIC) working group of the Internet Engineering Task Force Comments
are solicited and should be addressed to the working group's mailing
list at confctrl@isi.edu and/or the authors.
"SIP URL Scheme", H. Schulzrinne, 05/14/1997,
<draft-ietf-mmusic-sip-url-00.txt, .ps>
A family of new URL schemes, 'sip*:', is defined. It is used to
establish multimedia conferences using the Session Initiation Protocol
(SIP).
"The Internet Multimedia Conferencing Architecture", Jon Crowcroft, Mark
Handley, Joerg Ott, C. Bormann, 09/09/1997,
<draft-ietf-mmusic-confarch-00.txt>
This document provides an overview of multimedia conferencing on the
Internet. The protocols mentioned are specified elsewhere as RFCs,
Internet-Drafts, or ITU recommendations. Each of these
specifications gives details of the protocol itself, how it works
and
what it does. This document attempts to provide the reader with an
overview of how the components fit together and of some of the
assumptions made, as well as some statement of direction for those
components still in a nascent stage.
This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the
working
group's mailing list at confctrl@isi.edu and/or the authors.
IP Routing for Wireless/Mobile Hosts (mobileip)
-----------------------------------------------
"Route Optimization in Mobile IP", C. Perkins, D. Johnson, 08/04/1997,
<draft-ietf-mobileip-optim-06.txt>
This document defines extensions to the operation of the base Mobile IP
protocol to allow for optimization of datagram routing from a
correspondent node to a mobile node. Without Route Optimization, all
datagrams destined to a mobile node are routed through that mobile
node's home agent, which then tunnels each datagram to the mobile
node's current location. The protocol extensions described here
provide a means for correspondent nodes that implement them to cache
the binding of a mobile node and to then tunnel their own datagrams for
the mobile node directly to that location, bypassing the possibly
lengthy route for each datagram to and from the mobile node's home
agent. Extensions are also provided to allow datagrams in flight when
a mobile node moves, and datagrams sent based on an out-of-date cached
binding, to be forwarded directly to the mobile node's new binding.
"Mobility Support in IPv6", C. Perkins, D. Johnson, 08/01/1997,
<draft-ietf-mobileip-ipv6-03.txt>
This document specifies the operation of mobile computers using IPv6.
Each mobile node is always identified by its home address,
regardless
of its current point of attachment to the Internet. While situated
away from its home, a mobile node is also associated with a care-of
address, which provides information about the mobile node's current
location. IPv6 packets addressed to a mobile node's home address
are
transparently routed to its care-of address. The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address, and to then send packets destined for the
mobile
node directly to it at this care-of address.
"Firewall Traversal for Mobile IP: Goals and Requirements", S. Glass, V.
Gupta, 01/24/1997, <draft-ietf-mobileip-ft-req-00.txt>
This document discusses problems arising out of the use of Mobile IP in
a security conscious Internet and presents a list of solution
requirements deemed important. These problems may need to be resolved
in several stages. A priority order in which these problems should be
solved is also proposed.
All firewalls are assumed to implement standard mechanisms [RFCs
1825,1826,1827] for authentication and encryption proposed by the IPSec
working group of the IETF.
"Reverse Tunneling for Mobile IP", G. Montenegro, 08/20/1997,
<draft-ietf-mobileip-tunnel-reverse-04.txt>
Mobile IP uses tunneling from the home agent to the mobile node's
care-of address, but rarely in the reverse direction. Usually, a
mobile node sends its packets through a router on the foreign
network, and assumes that routing is independent of source address.
When this assumption is not true, it is convenient to establish a
topologically correct reverse tunnel from the care-of address to the
home agent.
This document proposes backwards-compatible extensions to Mobile IP
in order to support topologically correct reverse tunnels. This
document does not attempt to solve the problems posed by firewalls
located between the home agent and the mobile node's care-of
address.
"Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP
entities", S. Glass, V. Gupta, 03/27/1997,
<draft-ietf-mobileip-firewall-trav-00.txt>
The use of network security mechanisms such as ingress filtering,
firewall systems and private address spaces can disrupt normal
operation of Mobile IP [GuGl97]. This document outlines behavioral
guidelines for Mobile Nodes, their Home Agents and intervening
Firewalls. Compliance with these guidelines allows secure datagram
exchange between a mobile node and its home agent even across
firewalls, ingress filtering routers and distinct address spaces. To
its correspondent nodes, the mobile node appears to be connected to its
home network even while roaming on the general Internet. It enjoys the
same connectivity (modulo performance penalities) and, if desired,
privacy outside its protected domain as on the inside. The guidelines
described here solve a restricted, but still useful, variant of the
general firewall traversal problem for Mobile IP. They make the
following assumptions: (a) All intervening firewalls belong to the
mobile node's protected home domain and their existence and relative
placement, with respect to a mobile node's current location, is known a
priori. (b) Mobile nodes use co-located care-of addresses (rather than
Foreign Agents) when outside their protected home domain. (c) Firewalls
implement standard
Multiprotocol Label Switching (mpls)
------------------------------------
"A Framework for Multiprotocol Label Switching", Ross Callon, George
Swallow, N. Feldman, A. Viswanathan, P. Doolan, A. Fredette, 08/02/1997,
<draft-ietf-mpls-framework-01.txt>
This document discusses technical issues and requirements for the
Multiprotocol Label Switching working group. This is an initial
draft
document, which will evolve and expand over time. It is the intent
of
this document to produce a coherent description of all significant
approaches which were and are being considered by the working group.
Selection of specific approaches, making choices regarding
engineering tradeoffs, and detailed protocol specification, are
outside of the scope of this framework document.
Note that this document is at an early stage, and that most of the
detailed technical discussion is only in a rough form. Additional
text will be provided over time from a number of sources. A small
amount of the text in this document may be redundant with the
proposed protocol architecture for MPLS. This redundancy will be
reduced over time, with the overall discussion of issues moved to be
in this document, and the selection of specific approaches and
specification of the protocol contained in the protocol architecture
and other related documents.
"A Proposed Architecture for MPLS", Ross Callon, A. Viswanathan, E.
Rosen, 08/21/1997, <draft-ietf-mpls-arch-00.txt>
This internet draft contains a draft protocol architecture for
multiprotocol label switching (MPLS). The proposed architecture is
based on other label switching approaches [2-11] as well as on the
MPLS Framework document [1].
Next Generation Transition (ngtrans)
------------------------------------
"A proposal for an IPv6 site database object", G. de Groot, David
Kessens, 06/06/1997, <draft-ietf-ngtrans-6bone-registry-01.txt>
This proposal describes the proposed syntax of a new RIPE database
object that describes the several IPv6 sites in the world. The object
and resulting database collection will be used to facilitate the
introduction of IPv6 in the Internet.
"Site prefixes in Neighbor Discovery", Erik Nordmark, 07/30/1997,
<draft-ietf-ngtrans-header-trans-00.txt>
This document specifies a transition mechanism in addition to those
already specified in RFC 1933. The new mechanism can be used as
part
of a solution that allows IPv6 hosts that do not have a permanently
assigned IPv4 address to communication with IPv4-only hosts.
NNTP Extensions (nntpext)
-------------------------
"Network News Transport Protocol", Stan Barber, 09/10/1997,
<draft-ietf-nntpext-base-02.txt>
The Network News Transport Protocol has been in use in the
Internet for a decade and remains one of the most popular
protocols (by volume) in use today. This document is a
replacement for RFC 977 and officially updates the protocol
specification. It clarifies some vagueness in RFC 977,
includes some new base functionality and provides a
specific
mechanism to add standardized extensions to NNTP.
"Common NNTP Extensions",, 10/13/1997, <draft-ietf-nntpext-imp-00.txt>
In this document, a number of popular extensions to the NNTP
protocol defined in RFC977 are documented and discussed. While
this document is not intended to serve as a standard of any kind,
it will hopefully serve as a reference document for future
implementers of the NNTP protocol. In the role, this document
would hopefully create the possibility for some level of
interoperability among implementations that make use of extensions.
Individual Submissions (none)
-----------------------------
"Definitions of Managed Objects for the Fabric Element in Fibre Channel
Standard", K. Teow, 10/15/1997, <draft-teow-fabric-mib-03.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it defines the objects for managing the
operations of the Fabric Element portion of the Fibre Channel Methods.
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions.
"Procedures for Formalizing, Evolving, and Maintaining the Internet X.500
Directory Schema", R. Wright, Tim Howes, K. Rossen, Sri Sataluri,
06/08/1995, <draft-howes-x500-schema-03.txt>
The IETF Schema Task Force proposes a set of procedures for reviewing,
publicizing, and maintaining schema elements for use in Internet
applications using OSI Directory Services (X.500).
"Mobility Support in IPv6", C. Perkins, F. Teraoka, D. Johnson,
06/03/1997, <draft-teraoka-ipv6-mobility-sup-04.txt>
This memo describes a protocol to support mobility in IPv6. The mobile
node has an identifier (home address) and a temporary address (care-of
address). The IPv6 base header includes the temporary addresses so
that the source and destination addresses are always topologically
significant, while the identifiers are included in the Destination
Options Header. End nodes may have authentic cache information between
identifiers and addresses for routing optimization. This protocol
introduces two new destination options: `Source Identifier' and
`Destination Identifier', and also introduces two control packets using
UDP.
"Photuris: Session Key Management Protocol", P. Karn, W. Simpson,
09/03/1997, <draft-simpson-photuris-16.txt>
Photuris is a session-key management protocol intended for use with the
IP Security Protocols (AH and ESP). This document defines the basic
protocol mechanisms.
"The Auto-Submitted, Supersedes and Expires E-mail Headers", J. Palme,
09/10/1997, <draft-ietf-mailext-new-fields-10.txt>
This memo introduces three new e-mail headers, Auto-Submitted,
Supersedes, and Expires.
"Distance-Vector Multicast Routing Protocol MIB", D. Thaler, 04/30/1997,
<draft-thaler-dvmrp-mib-04.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing the Distance-Vector Multicast Routing Protocol (DVMRP)
protocol [5,6]. This MIB module is applicable to IP multicast routers
which implement DVMRP.
"Loop control for the Auto-Submitted e-mail header", J. Palme,
07/07/1997, <draft-palme-autosub-03.txt>
This memo introduces certain advanced features for the Auto-Submitted
e-mail header.
"SMTP Service Extension for Authentication", J Myers, 10/28/1997,
<draft-myers-smtp-auth-08.txt>
This document defines an SMTP service extension [ESMTP] whereby an
SMTP client may indicate an authentication mechanism to the server,
perform an authentication protocol exchange, and optionally
negotiate
a security layer for subsequent protocol interactions. This
extension is a profile of the Simple Authentication and Security
Layer [SASL].
"Tunneling SSL Through a WWW Proxy", A. Luotonen, 03/26/1997,
<draft-luotonen-ssl-tunneling-03.txt>
The wide success of SSL (Secure Sockets Layer from Netscape
Communications Corporation) has made it vital that the current WWW
proxy protocol be extended to allow an SSL client to open a secure
tunnel through the proxy.
"Common NNTP Extensions", Stan Barber, 04/14/1997,
<draft-barber-nntp-imp-07.txt>
In this document, a number of popular extensions to the NNTP protocol
defined in RFC977 are documented and discussed. While this document is
not intended to serve as a standard of any kind, it will hopefully
serve as a reference document for future implementers of the NNTP
protocol. In the role, this document would hopefully create the
possibility for some level of interoperability among implementations
that make use of extensions.
"Guidelines for IETF Meeting Sites", E. Love, Dave Crocker, Bill Manning,
Mark Prior, S. Coppins, 10/06/1997,
<draft-prior-future-host-guidelines-02.txt>
The IETF is an international group that conducts most of its
business using electronic mail however three times a year it
conducts an open meeting for one week. For the most part the actual
mechanics of the meeting are organised by the IETF secretariat but
there are some requirements placed on the local host.
This document attempts to provide some guidelines for organisations
that wish to volunteer to act as host for one of these open
meetings. As the IETF growth pattern mirrors the Internet itself
this document expresses sizes as a percentage of the expected
attendance rather than use fixed numbers as we expect these numbers
to change for each meeting. At the last meeting, in Munich Germany,
there were just over 1300 attendees.
"The META Tag of HTML", D. Musella, 03/24/1997,
<draft-musella-html-metatag-03.txt>
This document defines a strict synopsis to catalogue an HTML document
using the META tag of HTML. The given definition wants to define a
base subset of cataloguing keys to provide a preliminary classification
method.
"ICMP Security Failures Messages", P. Karn, W. Simpson, 04/30/1996,
<draft-simpson-icmp-ipsec-fail-02.txt>
This document specifies ICMP messages for indicating failures when
using IP Security Protocols (AH and ESP).
"PEM Compression Encryption Module", H. Woodward, 05/05/1997,
<draft-woodward-encryption-module-00.txt>
The Privacy-Enhanced Electronic Mail system (PEM) [1] provides an
inclusive standard as adopted by the Internet Architecture Board (IAB)
to provide secure electronic mail over the Internet. The PEM protocols
[2] provide for encryption, authentication, message integrity, and key
management. PEM's encryption [3] accomplishes privacy of messages
using DES in CBC mode; Integrity [4] via a cryptographic hash algorithm
called a Message Integrity Check (MIC)using either MD2 or MD5;
Symmetric key management [5] using DES in ECB mode or triple-DES using
two keys (EDE mode); and supports [6] public-key certificates for key
management, using the RSA algorithm and X.509 standard for certificate
structure. This document describes the use of a Spiral Network
Algorithm Compression routine integrated into the message-text
encryption routines to provide enhanced confidentiality and smaller
message size without impacting the throughput of the PEM system. It is
the intention of the author to seek guidance from the readers on
methods of testing and certification other than those listed herein.
"Layer Two Forwarding (Protocol) 'L2F'", T. Kolar, M. Littlewood, A.
Valencia, 10/07/1997, <draft-valencia-l2f-00.txt>
Virtual dial-up allows many separate and autonomous protocol domains
to share common access infrastructure including modems, Access
Servers, and ISDN routers. Previous RFCs have specified protocols
for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via
PPP [2]. This document describes the Layer Two Forwarding protocol
(L2F) which permits the tunneling of the link layer (i.e., HDLC,
async HDLC, or SLIP frames) of higher level protocols. Using such
tunnels, it is possible to divorce the location of the initial dial-
up server from the location at which the dial-up protocol connection
is terminated and access to the network provided.
"The "data" URL scheme", Larry Masinter, 03/19/1997,
<draft-masinter-url-data-03.txt>
A new URL scheme, 'data', is defined. It allows inclusion of small data
items as 'immediate' data, as if it had been included externally.
"Header Compression for IPv6", S. Pink, M. Degermark, B. Nordgren,
08/04/1997, <draft-degermark-ipv6-hc-03.txt>
This document describes how to compress IP headers per-hop over
point-to-point links. The methods can be applied to IPv6 base and
extension headers, IPv4 headers, TCP and UDP headers, and
encapsulated IPv6 and IPv4 headers.
Headers of typical UDP or TCP packets can be compressed down to 4-7
octets including the 2 byte UDP or TCP checksum. This largely
removes the negative impact of large headers and allows efficient
use
of bandwidth on low- and medium-speed links.
"Mail Ubiquitous Security Extensions (MUSE)", Don Eastlake, 05/12/1997,
<draft-eastlake-muse-02.txt>
Secure electronic mail can provide authentication of the source of mail
and confidentiality for its contents. These features are becoming
increasingly important as the Internet grows exponentially and email is
increasingly used for critical, sensitive, and confidential
communications. In addition, authentication can make mail filtering
more effective and ubiquitous encryption indirectly makes all mail more
secure be defeating traffic analysis based on distinctions between
encrypted and non-encrypted mail and defeating bulk searching through
insecure mail. However, use of secure mail is not widespread due to the
problems of key distribution and lack of migration to secure mail
enabled user agents. This draft proposes partial solutions to these
two problems by using coarser grained identity to permit some
authentication and confidentiality without user agent change, and
secure DNS for key distribution. These changes also support limited
host and domain level mail security policies.
"The Hash Convention For Mail System Status Codes (HCMSSC)", D.
Bernstein, 02/03/1997, <draft-bernstein-hcmssc-02.txt>
RFC 1893 defines codes for mail delivery failures. For example, code
5.1.1 means that the specified mailbox does not exist.
The qmail package sprays these codes all over the place, by adding a
code to the text of every error message, preceded by a hash mark and
surrounded by parentheses. It avoids using hash marks elsewhere.
"The qmail-send Bounce Message Format (QSBMF)", D. Bernstein, 02/03/1997,
<draft-bernstein-qsbmf-02.txt>
When a message transport agent (MTA) finds itself permanently unable to
deliver a mail message, it generates a new message, generally known as
a bounce message, back to the envelope sender.
Bounce messages produced by the qmail-send program display the list of
failed recipient addresses, an explanation for each address, and a copy
of the original message, in a format that is easy for both humans and
programs to read. This document defines the format.
"Easily Parsed LIST Format (EPLF)", D. Bernstein, 02/03/1997,
<draft-bernstein-eplf-02.txt>
The File Transfer Protocol (FTP) supports two commands that list files:
NLST and LIST. The NLST response is easy to parse but provides very
little information. The LIST response provides more information, but in
a format that varies from system to system. The most common LIST
formats are undocumented and impossible to parse reliably.
This document defines Easily Parsed LIST Format (EPLF), a format for
the LIST response that is usable by humans yet easy for programs to
handle. This format is supported by anonftpd, a secure FTP server.
One visible advantage of EPLF is that a browser can easily display
dates in the viewer's time zone and native language. EPLF also makes it
straightforward for an indexing program to automatically traverse an
FTP area and for a mirroring program to avoid downloading the same file
twice.
"Netstrings", D. Bernstein, 02/03/1997,
<draft-bernstein-netstrings-02.txt>
A netstring is a self-delimiting encoding of a string. Netstrings are
very easy to generate and to parse. Any string may be encoded as a
netstring; there are no restrictions on length or on allowed bytes.
Another virtue of a netstring is that it declares the string size up
front. Thus an application can check in advance whether it has enough
space to store the entire string.
Netstrings may be used as a basic building block for reliable network
protocols. Most high-level protocols, in effect, transmit a sequence of
strings; those strings may be encoded as netstrings and then
concatenated into a sequence of characters, which in turn may be
transmitted over a reliable stream protocol such as TCP.
"Tools in the War on Mail Loops", D. Bernstein, 02/03/1997,
<draft-bernstein-mail-loops-war-02.txt>
An automailer means any program that receives a mail message and
automatically sends one or more mail messages. This term is meant to
include not only a mail-based server, such as a mailing list exploder
or a vacation program, but also an SMTP server, which receives a
message from the network and relays it to a local or remote user.
In a network full of automailers, any mistake can cause a mail loop.
Since some automailers generate several outputs in response to a single
input, a loop can produce an exponential explosion of mail.
All the automailers in the qmail package follow a general philosophy
designed to prevent mail loops and limit the damage from any loops that
do occur. These automailers have been repeatedly observed to fail safe:
they stop loops in the face of typical failures by other hosts. This
document explains the philosophy and describes the automailers.
"Public Information Retrieval Protocol (PIRP)", D. Bernstein, 02/03/1997,
<draft-bernstein-pirp-02.txt>
The Public Information Retrieval Protocol (PIRP) gives Internet hosts a
simple, uniform, efficient, extensible, easily implemented method of
publishing information. This document defines PIRP and outlines the
structure of PIRP names.
Unlike FTP and HTTP, PIRP is dedicated to publication. Implementing
PIRP ought to be a small and trivial task.
"Notice-Requested-Upon-Delivery-To (NRUDT)", D. Bernstein, 02/03/1997,
<draft-bernstein-nrudt-02.txt>
The UNIX sendmail program has for many years supported a
Return-Receipt-To (RRT) header field that requests a notice of
successful final delivery. Notice-Requested-Upon-Delivery-To (NRUDT)
has the same basic function. The big difference is that RRT lists the
sender's address, while NRUDT lists the recipient's address.
This change is critical. RRT works poorly for messages to multiple
recipients, because it requests a notice from every recipient. RRT in a
message to a large mailing list produces a giant, usually
unintentional, flood of mail. This problem is so severe that RRT has
been disabled in recent versions of sendmail.
NRUDT is designed to be adopted immediately, with minimal disruption,
as a solution to the problems of RRT. Note that NRUDT is merely a
request for notification; unlike the link-level Delivery Status
Notification SMTP extension, NRUDT does not provide a guarantee of
notification.
"Photuris: Extended Schemes and Attributes", P. Karn, W. Simpson,
07/24/1997, <draft-simpson-photuris-schemes-03.txt>
Photuris is a session-key management protocol. Extensible
Exchange-Schemes are provided to enable future implementation changes
without affecting the basic protocol.
Additional authentication attributes are included for use with the IP
Authentication Header (AH).
Additional confidentiality attributes are included for use with the IP
Encapsulating Security Protocol (ESP).
"Internet Security Transform Enhancements", W. Simpson, D. Wagner,
04/30/1997, <draft-simpson-ipsec-enhancement-01.txt>
This document describes several generic security transform enhancements
for the IP Security Protocols (AH and ESP).
"IANA Charset Registration Procedures", J. Postel, Ned Freed, 09/30/1997,
<draft-freed-charset-reg-04.txt>
MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various
other modern Internet protocols are capable of using many
different charsets. This in turn means that the ability to
label different charsets is essential. This registration
procedure exists solely to associate a specific name or names
with a given charset and to give an indication of whether or
not a given charset can be used in MIME text objects. In
particular, the general applicability and appropriateness of a
given registered charset is a protocol issue, not a
registration issue, and is not dealt with by this registration
procedure.
"TFTP Blocksize Option", G. Malkin, Art Harkin, 07/24/1997,
<draft-malkin-tftpexts-blksize-opt-01.txt>
The Trivial File Transfer Protocol [1] is a simple, lock-step, file
transfer protocol which allows a client to get or put a file onto a
remote host. One of its primary uses is the booting of diskless nodes
on a Local Area Network. TFTP is used because it is very simple to
implement in a small node's limited ROM space. However, the choice of
a 512-octet blocksize is not the most efficient for use on a LAN whose
MTU may 1500 octets or greater.
This document describes a TFTP option which allows the client and
server to negotiate a blocksize more applicable to the network medium.
The TFTP Option Extension mechanism is described in [2].
"IP Authentication using Keyed SHA1 with Data Padding", W. Simpson, Perry
Metzger, 05/01/1996, <draft-simpson-ah-sha-kdp-00.txt>
This document describes the use of keyed SHA1 with the IP
Authentication Header.
"A Clarification of the STATUS Clause in SNMP MIB Modules", David
Perkins, 06/12/1997, <draft-rfced-info-perkins-02.txt>
This memo is informational. It specifies a clarification of the
meaning and use of the STATUS clause in Simple Network Management
Protocol (SNMP) Management Information Base (MIB) modules, which are
defined by the Structure of Management Information (SMI). There are
two versions of the SMI. The first, called SMIv1, is defined by RFCs
1155[1], 1212[2], and 1215[3]. The second, called SMIv2, is defined
by RFCs 1902[4], 1903[5], and 1904[6]. Many of the MIB module
constructs defined by the SMIs such as OBJECT-IDENTITY, OBJECT-TYPE,
and NOTIFICATION-TYPE contain the STATUS clause. However, the SMIs do
not provide a complete definition of the STATUS clause, nor do they
provide guidance to MIB designers and users on the interpretation and
action required dependent upon the value or change of value for a
STATUS clause. Users include agent and application developers, and
operators of SNMP-managed networks. This memo
specifies a clarification for both version 1 and version 2 of the SNMP
SMI, which is a standard for the Internet community.
"Using the MARS model in non-ATM NBMA networks.", G. Armitage,
07/10/1997, <draft-armitage-ion-mars-nbma-02.txt>
Initially developed for IP over ATM, the RFC2022 (MARS) model is also
applicable to other NBMA networks that provide the equivalent of
switched, point to multipoint connections. This short document is
intended to state the obvious equivalences, and explain the less
obvious implications. No changes to the MARS model per se are suggested
or required. RFC2022 is not required over NBMA networks that offer
Ethernet-like group addressing functionality.
"The Domestication of the Opaque Type for SNMP", David Perkins,
06/12/1997, <draft-perkins-opaque-01.txt>
This memo is informational. It specifies a clarification of the
definition and use of the Opaque type defined in Simple Network
Management Protocol (SNMP) Structure of Management Information (SMI).
"Multiple MCS support using an enhanced version of the MARS server.", M.
Ammar, R. Talpade, 12/26/1996, <draft-talpade-ion-multiplemcs-01.txt>
The basic Multicast Server architecture for layer 3 multicast over ATM
has been described in draft-ietf-ion-marsmcs-01.txt. It includes a
mechanism for fault tolerance using multiple MCSs. However no support
for sharing senders/receivers of a group across multiple MCSs has been
provided. This document aims to satisfy this need by involving an
enhanced version of the MARS in the load sharing and fault tolerance
mechanism. This approach is an improvement over the previous one as it
subverts the need for any inter-MCS synchronization mechanisms.
"Message Submission and Relay", Harald Alvestrand, R. Gellens,
05/08/1997, <draft-gellens-submit-05.txt>
SMTP was defined as a message *relay* protocol, that is, a means for
message transfer agents (MTAs) to route finished (complete) messages.
SMTP forbids MTAs from altering the message text, except to add
'Received' header fields. However, SMTP is now also widely used as a
message *submission* protocol, that is, a means for message user agents
(MUAs) to introduce new messages into the MTA routing network.
Regardless of whether this is good or bad, it is far too late to
change.
"The Public Key Login Protocol", D. Kemp, 08/01/1997,
<draft-kemp-auth-pklogin-03.txt>
This document defines the Public Key Login (PKL) protocol, a challenge-
response authentication mechanism using digital signatures. It provides
start-of-session authentication for firewall proxies, dial-up Network
Access Servers, remote email servers, and interactive protocols such as
Telnet and FTP. It provides functionality similar to One Time Passwords
and handheld authentication tokens, and it supports both one-way and
mutual authentication. PKL uses the authentication exchanges specified
in ISO/IEC 9798-3 and NIST FIPS Pub 196.
The PKL protocol provides strong authentication at the beginning of a
session, but does not by itself provide communication channel integrity
or confidentiality. PKL should be used in conjunction with a channel
integrity mechanism, for example to provide authentication of
individual
users over (host-keyed) Virtual Private Network connections.
This Internet Draft is intended to be the last version of the PKL
specification prior to publication as an Informational RFC. Comments
are
requested no later than the expiration date of this draft.
"Voice Profile for Internet Mail - version 2", G. Vaudreuil, G. Parsons,
04/18/1997, <draft-ema-vpim-05.txt>
A class of special-purpose computers has evolved to provide voice
messaging services. These machines generally interface to a telephone
switch and provide call answering and voice messaging services.
Traditionally, messages sent to a non-local machine are transported
using analog networking protocols based on DTMF signaling and analog
voice playback. As the demand for networking increases, there is a
need for a standard high-quality digital protocol to connect these
machines. The following document is a profile of the Internet standard
MIME and ESMTP protocols for use as a digital voice messaging
networking protocol. The profile is referred to as VPIM (Voice Profile
for Internet Mail) in this document. This profile is based on
earlier work in the Audio Message Interchange Specification (AMIS)
group that defined a voice messaging protocol based on X.400
technology. This profile is intended to satisfy the user requirements
statement from that earlier work with the industry standard ESMTP/MIME
mail protocol infrastructures already used within corporate intranets.
This second version of VPIM is based on implementation experience and
obsoletes RFC 1911 which describes
"A Common Internet File System (CIFS/1.0) Protocol
Preliminary Draft", P. Leach, D. Naik, 03/26/1997,
<draft-leach-cifs-v1-spec-00.txt>
This document describes the CIFS file sharing protocol, version 1.0.
Client systems use this protocol to request file and print services
from server systems over a network. It is based on the Server Message
Block protocol widely in use by personal computers and workstations
running a wide variety of operating systems.
"Redundant MARS architectures and SCSP", G. Armitage, 07/03/1997,
<draft-armitage-ion-mars-scsp-03.txt>
The Server Cache Synchronisation Protocol (SCSP) has been proposed as a
general mechanism for synchronising the contents of databases. This
document identifies a range of distributed MARS (RFC 2022) scenarios,
highlights associated problems, and describe the issues the must be
addressed when using SCSP to synchronize a distributed MARS.
"Quality of Service Extensions to OSPF or Quality Of Service Path First
Routing (QOSPF)", W. Salkewicz, Eric Crawley, Z. Zhang, C. Sanchez,
09/10/1997, <draft-zhang-qos-ospf-01.txt,.ps>
This document describes a series of extensions for OSPF[1] and MOSPF[2]
that can be used to provide Quality of Service (QoS) routing in
conjunction with a resource reservation protocol such as RSVP[4] or
other mechanisms that can notify routing of the QoS needs of a data
flow. Advertisements indicating the resources available and the
resources used are advertised to the OSPF routing domain and paths are
computed based on topology information, link resource information, and
the resource requirements of a particular data flow.
"Making Postscript and Acrobat Files International", J. Palme,
08/21/1997, <draft-palme-int-print-02.txt>
Certain text formats, for example Postscript (extension .ps, Mime-type
application/postscript) and Adobe Acrobat (extension .pdf, Mime-type
application/pdf) specify exactly the page layout of the printed
document. The commonly used paper format is different in America and
the
rest of the world. America uses the
"Compression Payload for Use with IP Security", Rodney Thayer,
03/24/1997, <draft-thayer-seccomp-01.txt>
This document describes a payload format to be used to store compressed
protocol messages within an IP packet which is using security features
as defined in [RFC-1825].
"Requirements for IETF Mailing Lists", Keith Moore, 09/26/1997,
<draft-moore-maillist-req-01.txt>
This document describes requirements for all IETF official mailing
lists, including (but not limited to) mailing lists used for working
group discussion.
"Internet Discussion Forum Protocol (IDFP)", L. Martins, 01/03/1997,
<draft-martins-forums-01.txt>
This document presents a new alternative way of implementing discussion
forums other than NNTP and mailing lists. It is largely based on
standard e-mail except for retrieval. The purpose of this new protocol
is to atenuate the bandwidth and net resources needed by either NNTP
and mailing lists.
Based on implementation experience by me and Kovisoft, the remote
moderator capabilities have been rewriten (in fact this was because I
conceived a better way).
"Dedicated Token Ring Interface MIB", K. Lee, T. Warwick, 03/05/1997,
<draft-warwick-tokenring-01.txt>
This document contains an extract from Draft 7 of the IEEE standard
802.5R 'Dedicated Token Ring'. The extract comprises the Interface
MIB for the Dedicated Token Ring interface, in SNMPv2 format. Draft 7
is now undergoing an IEEE sponsor ballot that is expected to complete
in April 1997, and has also been submitted for ballot to ISO. No major
changes to the MIB are expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use
tokens for data transmission.
"Dedicated Token Ring Concentrator MIB", K. Lee, T. Warwick, 03/05/1997,
<draft-warwick-tokenring-arch-01.txt>
This document contains an extract from Draft 7 of the IEEE standard
802.5R 'Dedicated Token Ring'. The extract comprises the MIB for the
Dedicated Token Ring Concentrator, in SNMPv2 format. Draft 7 is now
undergoing an IEEE sponsor ballot that is expected to complete in April
1997, and has also been submitted for ballot to ISO. No major changes
to the MIB are expected as a result of these ballots.
802.5R is a standard that encompasses the existing 802.5 token-passing
method of operation, and also defines a new duplex method of operation
for use only on dedicated point to point links, that does not use
tokens for data transmission.
The architecture of a DTR Concentrator is defined in the 802.5R
standard. It is a MAC layer bridging device, which uses a new set of
forwarding rules that ease interoperability between source routing and
transparent bridging in an 802.5 LAN. The DTR Concentrator MIB is
derived from the Source Routing and Transparent Bridge MIBs (RFCs 1525
and 1493).
"The Owner Hack", D. Bernstein, 02/19/1997,
<draft-bernstein-owner-hack-01.txt>
The fundamental problem in managing a large mailing list is matching
bounce messages to subscription addresses.
Often a bounce message refers to a failing address that does not appear
on the mailing list. One of the mailing list subscribers is forwarding
messages to that address. Which subscriber? As the list grows, this
question becomes more and more difficult to answer.
The owner hack completely eliminates this problem _right now_. It
automatically and reliably identifies the subscription address relevant
to each bounce message. It provides the address in a form that is
trivial for automated bounce handlers to parse. It requires support
from the local mailer, but it does not require support from any other
hosts.
"Quick Mail Transfer Protocol (QMTP)", D. Bernstein, 02/03/1997,
<draft-bernstein-qmtp-01.txt>
The Quick Mail Transfer Protocol (QMTP) is a replacement for the Simple
Mail Transfer Protocol (SMTP). QMTP eliminates any need for end-of-line
scanning between hosts with the same end-of-line convention. It
features automatic pipelining and chunking, 8-bit transmission, prior
declaration of the message size, and efficient batching. It is designed
to be very easy to implement.
"Political Disclosure Transmission Protocol (DISCLOSE)", J. Dixon,
01/16/1997, <draft-rfced-info-dixon-01.txt>
This document details a protocol which allows political candidates and
related committees to electronically transfer financial disclosure
filings (as now often required by law) to their associated governmental
entities, for the purpose of review, and then making these filings
easily publicly accessible.
"Creation of and Registration in the ".NUM" Top Level Domain", M.
Schultz, 05/07/1997, <draft-rfced-info-schultz-01.txt>
This document describes the creation, registration requirements, and
administration of the new top level domain (TLD) NUM.
"The PORT Resource Record", T. Maginnis, A. Madapoosi, 05/07/1997,
<draft-rfced-exp-maginnis-00.txt>
A contributing factor to the explosive growth in IP address allocation
is the coming together of two seeming unrelated factors. One factor is
arbitrary relationship within the Domain Name Server that requires an
unique IP address to be associated with a Domain Name. The second
factor is the public's desire to have short Domain Names unique to
their enterprise.
We believe a small modification to the Domain Name Server will break
this relationship and lessen pressure on IP address allocation. This
modification should also make system configuration easier than dealing
with IP addresses for each Domain Name supported on a given host.
One difficulty with the proposed modification is that similar 'small'
changes are required in the WWW browsers to pick up the port number and
append it to the URL.
"Ruby in the Hypertext Markup Language", M. Duerst, 03/03/1997,
<draft-duerst-ruby-01.txt>
The Hypertext Markup Language (HTML) is a markup language used to
create hypertext documents that are platform independent. Initially
HTML was designed primarily for Western European languages; most of the
issues of basic internationalization to make HTML better usable for
other languages have in the meantime been addressed. Ruby are
important phonetic annotations used mainly for ideographic characters
in East Asia. This document proposes markup for ruby in HTML and
explains its usage.
"Domain Names and Company Name Retrieval", John Klensin, T. Wolf,
07/28/1997, <draft-klensin-tld-whois-02.txt>
Location of web information for particular companies based on their
names has become an increasingly difficult problem and the Internet and
the web grow. The use of a naming convention and the domain name
system (DNS) for that purpose has caused complications for the latter
while not solving the problem. While there have been several proposals
to use contemporary, high-capability, directory service and search
protocols to reduce the dependencies on DNS conventions, none of them
have been significantly deployed.
This document proposes a company name to URL mapping service based on
the oldest and least complex of Internet directory protocols, whois, in
order to explore whether and extremely simple and widely-deployed
protocol can succeed where more complex and powerful options have
failed or been excessively delayed.
"Firewall Support for Mobile IP", G. Montenegro, V. Gupta, 08/01/1997,
<draft-montenegro-firewall-sup-01.txt>
The Mobile IP specification establishes the mechanisms that enable a
mobile host to maintain and use the same IP address as it changes
its point of attachment to the network. Mobility implies higher
security risks than static operation, because the traffic may at
times take unforeseen network paths with unknown or unpredictable
security characteristics. The Mobile IP specification makes no
provisions for securing data traffic. The mechanisms described in
this document allow a mobile node out on a public sector of the
internet to negotiate access past a SKIP firewall, and construct a
secure channel into its home network.
In addition to securing traffic, our mechanisms allow a mobile node
to roam into regions that (1) impose ingress filtering, and (2) use
a different address space.
"Tag Distribution Protocol", D Katz, Bruce Davie, Y Rekhter, E. Rosen, P.
Doolan, 05/23/1997, <draft-doolan-tdp-spec-01.txt>
An overview of a tag switching architecture is provided in [Rekhter].
This document defines the Tag Distribution Protocol (TDP) referred to
in [Rekhter].
TDP is a two party protocol that runs over a connection oriented
transport layer with guaranteed sequential delivery. Tag Switching
Routers use TDP to communicate tag binding information to their peers.
TDP supports multiple network layer protocols including but not limited
to IPv4, IPv6, IPX and AppleTalk.
We define here the PDUs and operational procedures for this TDP and
specify its transport requirements. We also define aspects of the
protocol that are specific to the case where it is run over an ATM
datalink.
"ST2+ over ATM Protocol Specification - UNI 3.1 Version", M. Suzuki,
10/14/1997, <draft-suzuki-st2-over-atm-02.txt>
This document specifies an ATM-based protocol for communication
between ST2+ agents. The ST2+ over ATM protocol supports the
matching
of one hop in an ST2+ tree-structure stream with one ATM connection.
In this document, ATM is a subnet technology for the ST2+ stream.
The ST2+ over ATM protocol is designed to achieve resource-
reservation communications across ATM and non-ATM networks, to
extend
the UNI 3.1/4.0 signaling functions, and to reduce the UNI 4.0 LIJ
signaling limitations.
The specifications of the ST2+ over ATM protocol consist of a
revision of RFC 1819 ST2+ and specifications of protocol interaction
between ST2+ and ATM on the user plane, management plane, and
control
plane which correspond to the three planes of the B-ISDN protocol
reference model.
"The TACACS+ Protocol Version 1.77", D. Carrel, L. Grant, 07/10/1997,
<draft-grant-tacacs-01.txt>
TACACS+ provides access control for routers, network access servers and
other networked computing devices via one or more centralized servers.
TACACS+ provides separate authentication, authorization and accounting
services. This document describes the protocol that is used by
TACACS+.
"EARTH - EAsy IP multicast Routing THrough ATM clouds", M. Smirnov,
03/24/1997, <draft-smirnov-ion-earth-02.txt>
The EARTH could be positioned between MARS [1] and VENUS [2], however
EARTH deals not only with address resolution but with routing issues as
well. This document describes a solution simplifying distribution of IP
multicast flows over ATM clouds with the use of point-to-multipoint
connections. The EARTH solution includes: - the notion of multicast IP
subnet over ATM; - IP multicast addresses (Class D) resolution to ATM
addresses; - support for IP multicast shortcuts over multiple LISs and
for the DVMRP capable egress routers; - support for a multicast group
management and receiver-initiated quality of service (QoS)
specification; - optional replication of EARTH servers with server
synchronisation based on SCSP [3].
The current version of EARTH proposal has an extension to solve
problems of ATM backbone for the Internet with DVMRP support over MLIS;
while retaining support for ATM subnets (LANs). Another extension
addresses redundant EARTH servers specifying, how SCSP protocol could
be re-designed to run over MLIS.
"Network Ingress Filtering: Defeating Denial of Service Attacks which
employ IP Source Address Spoofing", P. Ferguson, D. Senie, 10/09/1997,
<draft-ferguson-ingress-filtering-03.txt>
Recent occurrences of various Denial of Service (DoS) attacks
which have employed forged source addresses have proven to be a
troublesome issue for Internet Service Providers and the Internet
community overall. This paper discusses a simple, effective,
and straightforward method for using ingress traffic filtering
to prohibit DoS attacks which use forged IP addresses to be
propagated from 'behind' an Internet Service Provider's (ISP)
aggregation point.
"A Method for the Transmission of IPv6 Packets over ARCnet Networks.", I.
Souvatzis, 09/02/1997, <draft-souvatzis-ipv6-arcnet-03.txt>
This memo specifies a frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses on ARCnet
networks. It also specifies the content of the Source/Target Link-layer
Address option used by the Router Solicitation, Router Advertisement,
Neighbor Solicitation, and Neighbor Advertisement messages described in
[DISC], when those messages are transmitted on an ARCnet.
"Use of Tag Switching With ATM", Bruce Davie, George Swallow, 01/17/1997,
<draft-davie-tag-switching-atm-01.txt>
A tag switching architecture is described in [1]. Tag Switching
enables the use of ATM Switches as Tag Switching Routers. The ATM
Switches run network layer routing algorithms (such as OSPF, IS-IS,
etc.), and their data forwarding is based on the results of these
routing algorithms. No ATM-specific routing or addressing is needed.
This document describes how the tag switching architecture is applied
to ATM switches.
"FTP Extensions for Variable Protocol Specification", S. Ostermann, M.
Allman, 08/21/1997, <draft-allman-ftp-variable-05.txt>
The specification for the File Transfer Protocol assumes that the
underlying network protocols use a 32-bit network address and a
16-bit transport address (specifically IP version 4 and TCP). With
the deployment of version 6 of the Internet Protocol, network
addresses will no longer be 32-bits. This paper specifies
extensions to FTP that will allow the protocol to work over a
variety of network and transport protocols.
"The Safe Response Header Field", K. Holtman, 09/10/1997,
<draft-holtman-http-safe-03.txt>
This document defines a HTTP response header field called Safe,
which can be used to indicate that repeating a HTTP request is
safe. Such an indication will allow user agents to handle retries
of some safe requests, in particular safe POST requests, in a more
user-friendly way.
"Advanced Sockets API for IPv6", W. Stevens, M. Thomas, 07/22/1997,
<draft-stevens-advanced-api-04.txt>
Specifications are in progress for changes to the sockets API to
support IP version 6 [RFC-2133]. These changes are for TCP and
UDP-based applications and will support most end-user applications in
use today: Telnet and FTP clients and servers, HTTP clients and
servers, and the like. But another class of applications exists that
will also be run under IPv6. We call these 'advanced' applications and
today this includes programs such as Ping, Traceroute, routing daemons,
multicast routing daemons, router discovery daemons, and the like. The
API feature typically used by these programs that make them 'advanced'
is a raw socket to access ICMPv4, IGMPv4, or IPv4, along with some
knowledge of the packet header formats used by these protocols. To
provide portability for applications that use raw sockets under IPv6,
some standardization is needed for the advanced API features. There
are other features of IPv6 that some applications will need to access:
interface identification (specifying the outgoing interface and
determining the incoming interface) and IPv6 extension headers that are
not addressed in [RFC-2133]: Hop-by-Hop options, Destination options,
and the Routing header (source
"NNTP LIST Additions", B. Hernacki, 07/16/1997,
<draft-hernacki-nntplist-02.txt>
This document describes a set of enhancements to the Network News
Transport Protocol [NNTP-977] that allows extended server specific
information to be obtained by the client. These enhancements will be
made as new arguments to the existing LIST verb described in the NNTP
protocol [NNTP-977]. The availability of the extensions described
here will be advertised by the server using the extension
negotiation-mechanism described in the new NNTP protocol specification
currently being developed [NNTP-NEW].
"Wrapping MIME Objects: Application/MIME", Dave Crocker, L. Lundblade,
J. Zawinski, 07/25/1997, <draft-crocker-wrap-02.txt>
MIME permits labeling and aggregating objects into complex hierarchies.
Support for MIME mechanisms is not universal although it is growing
quickly. Consequently gateways often are required to translate
portions of a MIME object into its constituent pieces, as independent
attachments.
"Payload Format for HTTP Encoding in RTP", B. Aboba, 01/06/1997,
<draft-aboba-rtp-http-02.txt>
This document specifies a payload format for use in encoding HTTP
within RTP. This payload format can be used for unreliable multicasting
of resources such as Web pages, stock tickers, etc. As with other RTP
applications, receiver feedback and group membership information is
provided via RTCP. This specification is not expected to be used with
unicast, since unicast applications will instead use HTTP over TCP.
"Universal Format for Logger Messages", J. Abela, 07/22/1997,
<draft-abela-ulm-02.txt>
This document presents a format to describe system events for logging
purpose. Some of the features presented here are already in use with
the common syslog facility, but most of them are lost in the crowd of
syslog format freedom.
"The Multicast Dissemination Protocol (MDP) Framework", W. Dang, Joseph
Macker, 06/06/1997, <draft-macker-mdp-framework-02.txt>
This document outlines a simple protocol framework for reliable
multicast dissemination of data files. The general framework was
originally developed and used by the Image Multicaster (IMM)
application within the Internet MBone for dissemination of satellite
imagery. This document describes the more general use of the protocol
framework as a reliable bulk file transfer technique. We discuss the
present operational modes, some performance issues, and the basic
application data units (ADUs) used. This is not intended to be a
detailed protocol specification document, but rather a broad
description of the basic protocol features and a discussion of issues.
Further detailed description of the protocol implementation may be
provided in future documents.
"Network Data Management Protocol", D. Hitz, R. Stager, 09/10/1997,
<draft-stager-pdc-netapp-backup-04.txt>
The Network Data Management Protocol (NDMP) is an open protocol
for enterprise-wide network based backup. The NDMP architecture
allows network attached storage vendors to ship NDMP compliant
file servers which can be used by any NDMP-compliant backup
administration application. This same architecture is also used
for network-attached backup devices, such as tape drives and
tape libraries.
"Interoperability Rules for Multicast Routing Protocols", D. Thaler,
03/26/1997, <draft-thaler-multicast-interop-01.txt>
The rules described in this document will allow efficient
interoperation among multiple independent multicast routing domains.
Specific instantiations of these rules are given for the DVMRP, MOSPF,
PIM-DM, PIM-SM, and CBT multicast routing protocols, as well as for
IGMP-only links.
"DHCP Options for Novell Directory Services", D. Provan, 10/23/1997,
<draft-provan-dhcp-options-dir-serv-02.txt>
This document defines three new DHCP options for delivering
configuration information to clients of the Novell Directory
Services. The first option carries a list of NDS servers. The
second
option carries the name of the client's NDS tree. The third carries
the initial NDS context. These three options provide an NDS client
with enough information to connect to an NDS tree without manual
configuration of the client.
"Uniform Resource Locators (URL): Generic Syntax and Semantics", Tim
Berners-Lee, Larry Masinter, R. Fielding, 10/22/1997,
<draft-fielding-url-syntax-09.txt>
A Uniform Resource Locator (URL) is a compact string representation
of a location for use in identifying an abstract or physical
resource. This document defines the general syntax and semantics
of URLs, including both absolute and relative locators, and
guidelines for their use; it revises and replaces the generic
definitions in RFC 1738 and RFC 1808.
"NNTP Full-text Search Extension", B. Hernacki, N. Ballou, 09/19/1997,
<draft-ballou-nntpsrch-04.txt>
This document describes a set of enhancements to the Network News
Transport Protocol [NNTP-977] that allows full-text searching of
news articles in multiple newsgroups. The proposed SEARCH command
supports functionality similar to the [IMAP4] SEARCH command, minus
user specific search keys (i.e., ANSWERED, DRAFT, FLAGGED, KEYWORD,
NEW, OLD, RECENT, SEEN) and minus search keys based on headers that
do not exist in news (i.e., CC, BCC, TO).
The availability of the extensions described here will be advertised
by the server using the extension negotiation-mechanism described in
the new NNTP protocol specification currently being developed [NNTP-
NEW].
"POP3 AUTHentication command", J Myers, 10/28/1997,
<draft-myers-sasl-pop3-02.txt>
This document defines the optional AUTH command to POP3 [POP3], for
indicating an authentication mechanism to the server, performing an
authentication protocol exchange, and optionally negotiating a
security layer for subsequent protocol interactions. This extension
is a profile of the Simple Authentication and Session Layer [SASL].
"Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", Brian
Carpenter, C. Jung, 09/22/1997, <draft-carpenter-ipng-6over4-03.txt>
This memo specifies the frame format for transmission of IPv6 [IPV6]
packets and the method of forming IPv6 link-local addresses over
IPv4
domains. It also specifies the content of the Source/Target Link-
layer Address option used in the Router Solicitation, Router
Advertisement, Neighbor Solicitation, and Neighbor Advertisement
and Redirect messages, when those messages are transmitted on an
IPv4 network.
The motivation for this method is to allow isolated IPv6 hosts,
located on a physical link which has no directly connected IPv6
router, to become fully functional IPv6 hosts by using an IPv4
domain, preferably supporting IPv4 multicast, as their virtual local
link.
Originally submitted to the IPNG WG, this draft will be discussed in
the NGTRANS WG, ngtrans[-request]@sunroof.Eng.Sun.COM.
"PF_KEY Key Management API, Version 2", D. McDonald, B. Phan, C. Metz,
09/10/1997, <draft-mcdonald-pf-key-v2-04.txt>
A generic key management API that can be used not only for IP
Security [Atk95a] [Atk95b] [Atk95c] but also for other
network
security services is presented in this document. Version 1 of
this
API was implemented inside 4.4-Lite BSD as part of the U. S.
Naval
Research Laboratory's freely distributable and usable IPv6 and
IPsec
implementation[AMPMC96]. It is documented here for the benefit
of
others who might also adopt and use the API, thus providing
increased
portability of key management applications (e.g. a manual
keying
application, an ISAKMP daemon, a GKMP daemon [HM97a,HM97b],
a
Photuris daemon, or a SKIP certificate discovery protocol daemon).
"Label Switching: Label Stack Encodings", D. Farinacci, Tony Li, A.
Conta, Y Rekhter, Dan Tappan, E. Rosen, G. Fedorkow, 08/21/1997,
<draft-rosen-tag-stack-03.txt>
'Multi-Protocol Label Switching (MPLS)' [1,2,9] requires a set of
procedures for augmenting network layer packets with 'label stacks'
(sometimes called 'tag stacks'), thereby turning them into 'labeled
packets'. Routers which support MPLS are known as 'Label Switching
Routers', or 'LSRs'. In order to transmit a labeled packet on a
particular data link, an LSR must support an encoding technique
which, given a label stack and a network layer packet, produces a
labeled packet. This document specifies the encoding to be used by
an LSR in order to transmit labeled packets on PPP data links and on
LAN data links. This document also specifies rules and procedures
for processing the various fields of the label stack encoding.
"A Simple IP Security API Extension to BSD Sockets", D. McDonald,
03/20/1997, <draft-mcdonald-simple-ipsec-api-01.txt>
In order to take advantage of the IP Security Architecture [Atk95], an
application should be able to tell the system what IP-layer security
services it needs to function with some degree of confidence. A
simple API that also allows simple security association policy to be
set is presented here. This document descends from earlier work
performed in the U. S. Naval Research Laboratory's IPv6 and IP security
implementation [AMPMC96].
"The Weak Authentication and Tracing Option", Don Eastlake, 06/02/1997,
<draft-eastlake-weak-ato-01.txt>
The packet switched nature of the Internet Protocol (IP) provides no
inherent method to assure that a packet has been issued with a source
address authorized for use by the sender and no inherent method to
trace the actual source of a packet. These characteristics make it
difficult to take effective action concerning injurious packets which
may have originated, by accident or maliciously, virtually anywhere in
the Internet.
A lightweight IP level option is proposed that provides (1) some
assurance that packets are authorized by a host along the path routed
through when the packet's source address is used as a destination
address, and (2) limited statistical tracing information such that, if
many bad packets are logged, the path to their source will usually be
revealed. This would provide significantly improved protection against
packet level abuse.
"Representing the Dublin Core within X.500, LDAP and CLDAP", J. Knight,
M. Hamilton, R. Iannella, 07/28/1997, <draft-hamilton-dcxl-02.txt>
The Dublin Core is a simple resource description format which arose out
of a loose grouping of 'librarians, archivists, humanities scholars and
geographers, as well as standards makers in the Internet, Z39.50 and
Standard Generalized Markup Language (SGML) communities' [1].
This document describes a mapping from the abstract model of the Dublin
Core to the X.500 [2], LDAP [3], and CLDAP [4] directory service
protocols.
"Enhanced Communications Transport Service Definition", D. Kim,
08/21/1997, <draft-kim-jtc1-sc6-ects-02.txt>
This memo is the final Committee Draft of the Enhanced Transport
Service Definition under development within ISO/IEC JTC1/SC6/WG7
since
last several years in order to provide to the upper-layer
applications
enhanced transport services over the current OSI transport service;
major enhancements include multicast services and enhanced QoS.
This memo is distributed to possibly interested grops within IETF,
especially to experts in Transport Area, to make noticed the efforts
being made within SC6 to come up with a new transport service
definition meeting the wide range of requirements of the both current
and future multimedia multicast applications. It is to be noted that
a protocol maned ECTP(Enhanced Communications Transport Protocol)
supporting this ECTS is also under development within SC6 and will be
made public in the near future.
Experts interested in this topic might compare the services defined
by
ECTS with those provided by more known protocols including RTP, MTP,
RMP, and RAMP. The ultimate apparent objective of ECTS is the
multimedia multicast transport service with varying degrees of
reliability and multicast QoS.
"Architecture of the Resource Reservation Service for the Commercial
Internet", M. Suzuki, 10/14/1997, <draft-suzuki-res-resv-svc-arch-02.txt>
The purpose of this document is to clarify the architecture that
should be used for the resource reservation service for the
commercial Internet.
First, this document explains the basis of the tariff for current
telecommunication and Internet services. Then it clarifies problems
in the billing for Internet service, and describes how billing can
be
improved by using the resource reservation setup protocol. Finally,
it also studies technical and application models for a commercial
resource reservation service model, and clarifies an architecture
for
the resource reservation setup protocol.
"LZS Payload Compression Transform for ESP", R. Monsour, M. Sabin,
03/26/1997, <draft-sabin-lzs-payload-01.txt>
This memo proposes a 'payload compression transform' based on the LZS
compression algorithm. The transform can be used to compress the
payload field of an IP datagram that uses the Encapsulating Security
Payload (ESP) format. The compression transform proposed here is
stateless, meaning that a datagram can be decompressed independently of
any other datagram. Compression is performed prior to the encryption
operation of ESP, which has the side benefit of reducing the amount of
data that must be encrypted.
This memo anticipates a forthcoming ESP document that will supercede
[Atkins96]. The forthcoming document will allow for ESP payloads to be
compressed via transforms such as the one described in this memo.
"RMFP: A Reliable Multicast Framing Protocol", Jon Crowcroft, Zheng Wang,
A. Ghosh, C. Diot, 03/20/1997, <draft-crowcroft-rmfp-01.txt>
There has been considerable interest in reliable multicast, and a
number of reliable multicast transport applications and systems have
been built in the past years.
"Simple Unified Networking", Masataka Ohta, 03/26/1997,
<draft-ohta-sun-01.txt>
The concept of LIS for IP over ATM causes a topology mismatch between
the link and the internetworking layer. While it introduces some
inefficiency with CATENET based operation, it is not so much a problem
unless we try to solve this minor problem. Short-cutting attempts
such as NHRP can't solve the inefficiency issue at all even though, or,
just because, it utterly destroys the CATENET model, which resulted in
inelegant modifications of existing protocols, which, in turn, causes
scalability problems. Moreover, the creation of short-cut VCs
itself suffers a scalability issue. But, CSRs (Cell Switching
Routers), or RSVP-signaled ATM switches, make it possible to have
end-to-end cell-by-cell relaying over IP routers. That is, there is no
reason to have LISes and there is no inefficiency The way to go for
the Internet is Simple Unified Networking with the CATENET model.
"Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson,
08/01/1997, <draft-murray-auth-ftp-ssl-02.txt>
This document describes a mechanism that can be used by FTP clients
and servers to implement security and authentication using the TLS
protocol defined by the IETF TLS working group and the extensions to
the FTP protocol defined by the IETF CAT working group. It
describes
the subset of the extensions that are required and the parameters to
be used; discusses some of the policy issues that clients and
servers
will need to take; considers some of the implications of those
policies and discusses some expected behaviours of implementations
to
allow interoperation.
TLS is not the only mechanism for securing file transfer, however it
does offer some of the following positive attributes:-
- Flexible security levels. TLS can support privacy, integrity,
authentication or some combination of all of these. This allows
clients and servers to dynamically, during a session, decide on
the level of security required for a particular data transfer,
- Formalised public key management. By use of X.509 public
certificates during the authentication phase, certificate
management can be built into a central function. Whilst this may
not be desirable for all uses of secured file transfer, it offers
advantages in certain structured environments such as access to
corporate data sources.
- Co-existence and interoperation with authentication mechanisms
that are already in place for the HTTPS protocol. This allows
web
browsers to incorporate secure file transfer using the same
infrastructure that has been set up to allow secure web browsing.
The TLS protocol is a development of the Netscape Communication
Corporation's SSL protocol and this document can be used to allow
the
FTP protocol to be used with either SSL or TLS. The actual protocol
used will be decided by the negotiation of the protected session by
the TLS/S
"Key Derivation for Authentication, Integrity, and Privacy", M. Horowitz,
03/27/1997, <draft-horowitz-key-derivation-01.txt>
Recent advances in cryptography have made it desirable to use longer
cryptographic keys, and to make more careful use of these keys. In
particular, it is considered unwise by some cryptographers to use the
same key for multiple purposes. Since most cryptographic-based systems
perform a range of functions, such as authentication, key exchange,
integrity, and encryption, it is desirable to use different
cryptographic keys for these purposes.
This document does not define a particular protocol, but defines a set
of cryptographic transformations for use with arbitrary network
protocols and block cryptographic algorithm.
"Selectively Reliable Transport Protocol", Mark Pullen, V. Laviano,
08/04/1997, <draft-laviano-srtp-02.txt>
This memo describes a protocol for selectively reliable transmission of
Distributed Interactive Simulation (DIS) data in a wide-area multicast
environment. The Selectively Reliable Transmission Protocol (SRTP)
operates in three distinct modes: best-effort multicast, reliable
multicast using negative acknowledgements with a NAK suppression
mechanism to avoid congestion at the sender, and lightweight reliable
transaction-oriented unicast. SRTP is designed to run in user space and
form a sublayer between applications and the kernel-level Internet
protocol stack.
"The RWhois Version 1.x Uniform Resource Locator", Scott Williamson, M.
Mealling, 08/02/1997, <draft-mealling-rwhoisurl-01.txt>
RWhois is an Internet directory access protocol, defined in RFC1714 [1]
and RFC2167 [3]. This document describes a format for an RWhois Uniform
Resource Locator (URL) that will allow Internet clients to have direct
access to the RWhois protocol. An RWhois URL will represent a single
query to an RWhois server.
"Videotex URL Specification", D. Mavrakis, H. Layec, K. Kartmann,
05/20/1997, <draft-mavrakis-videotex-url-spec-01.txt>
A new URL scheme, 'videotex' is defined. It allows videotex client
software or terminals to connect to videotex services compliant to the
ITU-T and ETSI videotex standards, including among others:
- ITU/T Recommendation T.101: International Interworking for Videotex
[3] - ETS 300 072: Videotex presentation layer protocol, videotex
presentation layer data syntax [7]. - ETS 300 073: Videotex
presentation layer protocol, Geometric display [12]. - ETS 300 076:
Videotex Terminal Facility Identifier (TFI) [14] - ETS 300 149:
Videotex presentation layer protocol, Audio Syntax [16]. - ETS 300
177: Videotex presentation layer protocol, Photographic Syntax [15]. -
ANSI X3.110 - CSA T500: Videotex/Teletext Presentation Level Protocol
Syntax [17]. The well-known port number 516 has been
assigned by IANA to the videotex protocol [2].
"Internationalization of Domain Names", M. Duerst, 07/30/1997,
<draft-duerst-dns-i18n-01.txt>
Internet domain names are currently limited to a very restricted
character set. This document proposes the introduction of a new
'zero-level' domain (ZLD) to allow the use of arbitrary characters from
the Universal Character Set (ISO 10646/Unicode) in domain names. The
proposal is fully backwards compatible and does not need any changes to
DNS.
"Flow Grouping For Reducing Reservation Requirements for Guaranteed Delay
Service", R. Guerin, S. Rampal, 07/17/1997,
<draft-rampal-flow-delay-service-01.txt>
The purpose of this document is to illustrate when and how flow
aggregation can be of benefit in the context of the Guaranteed Service.
Specifically, it identifies simple cases and provides generic rules for
when grouping of flows allows a reduction in the amount of resources
(bandwidth) needed to ensure the deterministic Guaranteed Service delay
bounds of all flows. The benefits of grouping should be especially of
interest to, say, Internet Service Providers, wishing to interconnect
sites with Guaranteed Service flows. In particular, this document
shows that in the case of flows with identical traffic characteristics
and requirements, e.g., Internet voice, grouping of flows is ALWAYS
beneficial.
This technique is not intended for IETF standardization and is being
submitted for informational purposes only.
"Originator-Info Message Header", C Newman, 08/28/1997,
<draft-newman-msgheader-originfo-02.txt>
This proposal is an attempt to provide a standard header to
indicate information about the message originator without implying
that there is a deliverable mailbox or mandating that internal
network information be revealed.
"Date and Time on the Internet", C Newman, 01/27/1997,
<draft-newman-datetime-01.txt>
Date and time formats cause a lot of confusion and interoperability
problems on the Internet. This document will address many of the
problems encountered and make recommendations to improve consistancy
and interoperability when representing and using date and time in
Internet protocols.
"FTP Security Considerations", S. Ostermann, M. Allman, 08/21/1997,
<draft-allman-ftp-sec-consider-02.txt>
The specification for the File Transfer Protocol contains a number of
mechanisms that can be used to compromise network security. The FTP
specification allows a client to instruct a server to transfer files to
a third machine. This third-party mechanism, known as proxy FTP,
causes a well known security problem. The FTP specification also
allows an unlimited number of attempts at entering a user's password.
This allows brute force 'password guessing' attacks. This document
provides suggestions for system administrators and those implementing
FTP servers that will decrease the security problems associated with
FTP.
"Draft Specifications for Administration and Management of gTLDs", Dave
Crocker, 12/26/1996, <draft-iahc-gtldspec-00.txt>
The International Ad Hoc Committee (IAHC) was formed at the initiative
of the Internet Society, and at the request of the Internet Assigned
Numbers Authority (IANA). IANA has responsibility for the maintenance
of core administrative tables for Internet services, including 'top
level' domain names (TLD) and the delegation of their maintenance to
appropriate agencies. The IAHC is tasked with developing
administration and management enhancements for the general class of
TLDs that have been called 'international'.
"NAT extension for existing "external" networks", G. Gloesener,
12/30/1996, <draft-gloesener-nat-ext-00.txt>
The main use of NAT is to connect an existing internal network via an
ISP to the Internet. The current NAT RFC1631 supposes that the network
number used for the translation is not existing physically on any
network. This does not work in some circumstances where the router
connected to the ISP line is not under control of the user. This
implies that the network where the NAT router is connected to, has the
same network number than the one used by NAT.
"Multiprotocol Extensions for BGP", Dimitry Haskin, J. Stewart,
12/30/1996, <draft-stewart-bgp-multiprotocol-00.txt>
This document outlines a proposal for a BGP Version 5 (BGP5) which has
the ability to carry routing information for a variety of network
protocols. The proposed BGP modifications are intended to be simple
enough to be easily added to the existing BGP implementations and, at
the same time, provide for a longer than 16-bit AS number space.
This document only describes BGP5 support for IPv4 and IPv6 networks.
"Proposal of a suggested protocol for an interactive, real-time
cryptographic 'key' server", D. Merriman, 01/03/1997,
<draft-merriman-realtime-key-00.txt>
With the increase in privacy-enabling cryptographic software, there
exists the growing problem of verification of the 'validity' of a
cryptographic 'key'. That is, the recipient of (for example) a
PGP-signed email message from an unknown person generally has no ready,
convenient means to verify that the 'signature' on the message actually
belongs to the sender. To verify the relationship between a
cryptographic 'key' and an identity (real or anonymous), it is
necessary for an individual to contact one of several existing 'manual'
keyservers as a separate process, request the key (if it exists on that
keyserver), and retrieve it before being able to use it for any
reference or validation purposes. This draft is meant to
propose a protocol/system that would both enable the automatic
retrieval of cryptographic keys, and the exchange of keys between
servers (both new keys, and those deleted through revocation
certificates). This proposal could be extended to allow retrieval of
cryptographic certificates and/or 'credentials' with relatively minor
difficulty.
"Multiprotocol Extensions for BGP-4", D Katz, Y Rekhter, T. Bates, R.
Chandra, 07/09/1997, <draft-bates-bgp4-multiprotocol-03.txt>
Currently BGP-4 [BGP-4] is capable of carrying routing information only
for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it
to carry routing information for multiple Network Layer protocols
(e.g., IPv6, IPX, etc...). The extensions are backward compatible - a
router that supports the extensions can interoperate with a router that
doesn't support the extensions.
"Using BGP Without Consuming a Unique ASN", J. Stewart, E. Chen,
01/03/1997, <draft-stewart-bgp-without-as-00.txt>
The number of organizations that have more than one Internet connection
is increasing significantly with time. In a substantial number of
these cases, an organization's multiple connections are from the same
ISP; this type of multi-homing is localized to the organization and its
single provider, so a globally unique ASN should not be needed.
However, many ISPs can only support their customers' reliability and
load-sharing requirements by using BGP, which DOES require an ASN.
Since the needs of the ISP and its multi-homed customer are contrary to
the Internet's need to allocate the ASN space sensibly, this is a
problem. A solution to this problem has been proposed which makes use
of private ASNs, but it has several disadvantages. This paper
documents the existing solution and describes its disadvantages, then
presents another solution which doesn't share the same disadvantages.
"Guidelines and Process for new URL Schemes", Harald Alvestrand, Larry
Masinter, D. Zigmond, 03/26/1997, <draft-masinter-url-process-01.txt>
A Uniform Resource Locator (URL) is a compact string representation of
the location for a resource that is available via the Internet. [RFC
URL-SYNTAX] defines the general syntax and semantics of URLs. This
document provides guidelines for the definition of new URL schemes and
describes the process by which they are registered.
"Forcing HTTP/1.1 proxies to revalidate responses", J Mogul, 05/28/1997,
<draft-mogul-http-revalidate-01.txt>
The HTTP/1.1 specification [1] currently defines a ``proxy-revalidate''
Cache-control directive, which forces a proxy to revalidate a stale
response before using it in a reply. There is no mechanism defined
that forces a proxy, but not an end-client, to revalidate a fresh
response. The lack of such a mechanism is due to an error in drafting
RFC2068, and appears to create problems for use of the Authorization
header, the Digest Access Authentication extension [2], the State
Management Mechanism [3], and several other proposed extensions. This
document discusses the problem and several possible solutions, and
proposes to add a new ``s-maxage'' directive as the best available
solution.
"Security Industry Internet Protocol for Alarm Transmission (SIIPAT)", S.
Ryckman, 01/08/1997, <draft-rfced-info-ryckman-01.txt>
This document suggests a method for delivering alarm information over
the Internet. All communication shall use an encryption algorithm for
transmission of the data. An immediate response from the host will be
used for verification of receipt of the message.
This transmission method may be use as a backup transmission method to
traditional dial-up or leased line methods, or as a primary
transmission method with traditional methods becomming the backup.
Due to the required security of the data being transmitted, the
encryption algorithm used will only be released on a need to know basis
to software developers in the Alarm/Security Industry. A
non-disclosure agreement will be required. Terms and conditions of the
licensing will depend on the intended purpose for use and may require a
non-competition agreement or licensing fees.
The Internet Assigned Numbers Authority (IANA) has assigned port 1733
for the registered use of SIIPAT transmissions.
"The mailto URL scheme", Larry Masinter, Paul Hoffman, J. Zawinski,
10/21/1997, <draft-hoffman-mailto-url-02.txt>
This document defines the format of Uniform Resource Locators (URL)
for designating electronic mail addresses. It is one of a suite of
documents which replace RFC 1738, 'Uniform Resource Locators', and RFC
1808, 'Relative Uniform Resource Locators'. The syntax of 'mailto'
URLs from RFC 1738 is extended to allow creation of more RFC 822
messages by allowing the URL to express additional header and body
fields.
"A FTP URL Format", J. Casey, 01/09/1997, <draft-casey-url-ftp-00.txt>
This document defines the format of Uniform Resource Locators (URL) for
the File Transfer Protocol (FTP) using the general URL syntax defined
in RFC xxxx, 'Uniform Resource Locators (URL)'.
It is a one of a suite of documents which replace RFC 1738, 'Uniform
Resource Locators', and RFC 1808, 'Relative Uniform Resource Locators'.
"MIME media-types for Print Formats", R. Lutz, 01/09/1997,
<draft-lutz-print-types-00.txt>
This memo defines media-type designators for various printer control
file formats which are popularly used in the industry, and proposes a
means to correlate the printer interpreter types as specified in the
Printer MIB (RFC-1759).
"Tag Switching Architecture - Overview", D Katz, D. Farinacci, Bruce
Davie, George Swallow, Y Rekhter, E. Rosen, 08/05/1997,
<draft-rekhter-tagswitch-arch-01.txt>
This document provides an overview of tag switching. Tag switching is a
way to combine the label-swapping forwarding paradigm with network
layer routing. This has several advantages. Tags can have a wide
spectrum of forwarding granularities, so at one end of the spectrum a
tag could be associated with a group of destinations, while at the
other a tag could be associated with a single application flow. At the
same time forwarding based on tag switching, due to its simplicity, is
well suited to high performance forwarding. These factors facilitate
the development of a routing system which is both functionally rich and
scalable. Finally, tag switching simplifies integration of routers and
ATM switches by employing common addressing, routing, and management
procedures.
"POP3 Service Extensions", D. Rauschenbach, 01/10/1997,
<draft-rauschenbach-pop3-framework-00.txt>
This memo defines a framework for extending the POP3 service by
defining a means whereby a POP3 server can inform a client as to the
service extensions it supports.
"POP3 Service Extensions", D. Rauschenbach, 01/10/1997,
<draft-rauschenbach-pop3-framework-00.txt>
This memo defines a framework for extending the POP3 service by
defining a means whereby a POP3 server can inform a client as to the
service extensions it supports.
"CamCoder Control Protocol", Masataka Ohta, A. Amano, S. Shimojo, H.
Kago, H. Fujiwara, 01/16/1997, <draft-ohta-ccc-video-00.txt>
CCCP (CamCoder Control Protocol) is designed after FTP to be useful to
operate realtime/batch analog/digital video cameras and video/audio
recorders over the Internet.
"NICS Network of Identifier and Credential Servers", G. Hoare,
01/17/1997, <draft-hoare-nics-00.txt>
NICS is a proposed system which meets the requirements of large-scale,
unique principal identification, for use in conjunction with an
arbitrary set of security systems such as have been proposed by members
of the IETF. This proposal outlines the motivation for the development
of NICS, and gives a general description of its internal workings and
interfaces with higher-level protocols. It should be emphasized up
front that NICS is not a complete security system, nor does it aim to
replace any existing components of the internet which already work. The
design draws off the fact that many security systems already have
flexible name schemes, and are therefore considered components which
are used in conjunction with NICS to achieve an improved level of
service, flexibility and reliability, while introducing many desirable
features such as anonymous identifiers, self-optimization, and
low-overhead operation. For the purpose of initial evaluation, the
remainder of this paper is short and to the point, and requires a
little work on the reader's side to understand the reasoning.
Additional discussion is welcome on the mailing list.
"The Multicast Attribute Framing Protocol", Ross Finlayson, 01/17/1997,
<draft-finlayson-mafp-00.txt>
The Internet has recently seen the emergence of applications that
involve the ongoing transmission, or 'pushing', of structured data from
a server to one or more client nodes. Most current applications send
this data using unicast communications - usually over TCP connections.
However, similar applications can also be implemented using
multicast-based protocols. Multicast not only improves the
scalability of this particular class of application, but also makes
possible an additional class of application in which the participants
can act as peers - sending data as well as receiving. This Internet
Draft describes the 'Multicast Attribute Framing Protocol' (MAFP) - a
generic, attribute-based data representation, intended for a wide
variety of multicast-based applications. It is currently being used to
implement the 'multikit' generic multicast session browser
(http://www.lvn.com/multikit). This draft describes an early version
of MAFP that is likely to undergo substantial changes in the future.
However, it is being described now, in the hope that it will promote
open discussion of this and similar protocols - ideally leading to the
adoption of an open, interoperable
"Protocol Independent Multicast-Sparse Mode (PIM-SM): Implementation
Document", A. Helmy, 01/20/1997, <draft-helmy-pim-sm-implem-00.txt, .ps>
This document describes the details of the PIM-SM [1,2,3] version 2
implementation for UNIX platforms; namely SunOS and SGI-IRIX. A
generic kernel model is adopted, which is protocol independent,
however some supporting functions are added to the kernel for
encapsulation of data packets at user level and decapsulation of PIM
Registers. Further, the basic model for the user
level, PIM daemon (pimd), implementation is described.
Implementation details and code are included in supplementary
appendices.
"Network Element Object MIB (Neo-MIB)", W. Tackabury, 01/20/1997,
<draft-tackabury-neo-mib-00.txt>
This memo defines an experimental portion of the scope of the
Management Information Base (MIB) for use with Internet community
network management protocols. The particular focus of this MIB scope
extension is the presentation and management of objects for network
topology information. Constructs and encodings for these topology
objects has been specified in a manner consistent with the dictates of
the SNMP Version 2 SMI.
"Content Duration MIME Header Definition", G. Vaudreuil, G. Parsons,
07/30/1997, <draft-ema-vpim-dur-01.txt>
This document describes the MIME header Content-Duration that is
intended for use with any time varying media content (typically
audio/* or video/*). The length of time is represented in
seconds
without any units indication..
"Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration", G.
Vaudreuil, G. Parsons, 07/30/1997, <draft-ema-vpim-32kadpcm-01.txt>
This document describes the registration of the MIME sub-type
audio/32KADPCM for toll quality audio. This audio encoding is
defined by the ITU-T in Recommendation G.726. This document
refines
an earlier sub-type registration in RFC 1911.
"VPIM Voice Message MIME Sub-type Registration", G. Vaudreuil, G.
Parsons, 07/30/1997, <draft-ema-vpim-vmsg-01.txt>
This document describes the registration of the MIME sub-type
multipart/voice-message for use with the Voice Profile for
Internet
Mail (VPIM). A full description of usage can be found in the
VPIM
v2 specification [VPIM2]. This document revises an earlier
sub-type
registration in RFC 1911 [VPIM1].
"Network Tuning for Efficiency and Throughput", L. Breit, 01/23/1997,
<draft-breit-ntwrk-tuning-00.txt>
Network tuning is usually performed after the network design is
completed, but should also be done at intervals during the life cycle
of the network. There are four basic areas that directly affect the
efficiency of the network and its associated throughput: Frame and
packet size optimization Segmentation avoidance or limitation
Minimization of device delay Window sizing to avoid degradation
This draft has been written to document for the internet community a
basic overview of network tuning and its benefits.
"A Distributed MARS Protocol", G. Armitage, 01/23/1997,
<draft-armitage-ion-distmars-spec-00.txt>
The Server Cache Synchronisation Protocol (SCSP) has been proposed as a
general mechanism for synchronising the databases of IP/ATM Servers,
such as those used by NHRP and MARS. This document specifies an
application of SCSP to allow multiple MARS entities to provide fault
tolerance to MARS Clusters.
"Certificate Policy and Certification Practice Statement Framework",
Warwick Ford, S. Chokhani, 01/27/1997, <draft-chokhani-cps-00.txt>
This document presents an initial draft of a framework to assist the
writers of X.509 certificate policies or certification practice
statements for certification authorities and public key
infrastructures. In particular, the framework identifies a
comprehensive list of topics that potentially (at the writer's
discretion) need to be covered in an X.509 certificate policy or a
certification practice statement.
"Survey of Defined Managed Objects for Applications Management", H.
Hazewinkel, 07/21/1997, <draft-hazewinkel-appl-mib-01.txt>
This document was produced as the result of a survey on MIBs related to
application management. The goal was to identify overlapping or
duplicated objects and discover problems within the relationships
between those MIBs.
"Network Control Protocol for the Configuration of Mobile Wireless
Beam-formed GPS-Based Networks", S. Bush, S. Jagannath, 01/28/1997,
<draft-bush-ncp-config-00.txt>
The Network Control Protocol (NCP) facilitates the configuration and
rapid reconfiguration of mobile wireless beam-formed networks. It
controls the operation of a network of omni-directional packet radios
(orderwire) that overlays the mobile wireless network. Each network
element in this network uses Global Positioning System (GPS)
information to control a beamforming antenna subsystem which provides
for spatial reuse. The GPS information is shared among the network
elements over the orderwire and an optimal topology for the beam-formed
links is determined.
"The Definition of Managed Objects for Virtual Network Configuration", S.
Bush, S. Jagannath, 01/28/1997, <draft-bush-vnc-mib-00.txt>
This memo defines a 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 Virtual
Network Configuration (VNC) of the Rapidly Deployable Radio Network
(RDRN) Network Control Protocol (NCP).
"The Definition of Managed Objects for the Configuration of Mobile
Wire-less Beamformed GPS-Based Networks", S. Bush, S. Jagannath,
01/28/1997, <draft-bush-rdrn-mib-00.txt>
This memo defines a 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 the
Rapidly Deployable Radio Network (RDRN) Network Control Protocol (NCP).
"StarBurst Multicast File Transfer Protocol (MFTP) Specification", K.
Robertson, K. Miller, M. White, A. Tweedly, 02/13/1997,
<draft-miller-mftp-spec-02.txt>
The Multicast File Transfer Protocol (MFTP) is a protocol that operates
above UDP in the application layer to provide a reliable means for
transferring files from a sender to up to thousands (potentially
millions with network 'aggregators' or relays) of multiple receivers
simultaneously over a multicast group in a multicast IP enabled
network. The protocol consists of two parts; an administrative
protocol to set up and tear down groups and sessions, and a data
transfer protocol used to send the actual file reliably and
simultaneously to the multiple recipients residing in the group.
"AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol
Specification Version 1.2", M. Banan, J. Cheng, M. Taylor, 09/11/1997,
<draft-rfced-info-banan-esro-01.txt>
This document specifies the service model, the notation and protocol
for Efficient Short Remote Operations (ESRO). The ESRO service is
similar to and is consistent with other Remote Procedure Call services.
The emphasis of ESRO service definition and the ESRO protocol is on
efficiency. ESRO is designed specifically with wireless network (e.g.,
CDPD) usage in mind. ESRO protocol provides reliable connectionless
remote operation services on top of UDP (or any other non-reliable
connectionless transport service) with minimum overhead. ESRO protocol
supports segmentation and reassembly, concatenation and separation as
well as multiplexing for service users (applications). ESRO
allows for trade-offs between efficiency and reliability by specifying
both 2-way hand-shake and 3-way hand-shake based protocols.
Encoding mechanisms for presentation of the parameters of remote
operations are outside the scope of this document. But, identification
(tagging) of the encoding mechanism in use (e.g., XDR, BER, PER) is
supported by ESRO protocol. A variety of applications can use the
ESRO protocol. Some early applications using ESRO include efficient
short message submission and delivery, credit card
"IMAP4 Referrals", M. Gahrns, 04/22/1997,
<draft-gahrns-imap-referrals-02.txt>
When dealing with large amounts of users, messages and geographically
dispersed IMAP4 [RFC-2060] servers, it is often desirable to distribute
messages amongst different servers within an organization. For example
an administrator may choose to store user's personal mailboxes on a
local IMAP4 server, while storing shared mailboxes remotely on another
server. This type of configuration is common when it is uneconomical
to store all data centrally due to limited bandwidth or disk resources.
Additionally, users may be frequently moved from one IMAP4 server to
another because of hardware failures or organizational changes.
Referrals allow clients to seamlessly access mailboxes that are
distributed across several IMAP4 servers or to transparently connect to
an alternate IMAP4 server.
A referral mechanism can provide efficiencies over the alternative
'proxy method', in which the local IMAP4 server contacts the remote
server on behalf of the client, and then transfers the data from the
remote server to itself, and then on to the client. The referral
"Extensions to the Internet Relay Chat Protocol (IRCX)", T. Pfenning, K.
Cedola, Lisa Dusseault, 08/21/1997,
<draft-pfenning-irc-extensions-02.txt>
This document describes extensions to the Internet Relay Chat (IRC)
protocol defined in RFC 1459[1]. Only client-server interactions are
defined. The added functionality includes optional user authentication
for multiple security providers, support for UNICODE[2] characters,
multilayer security, and a unified property mechanism. Chat server
implementations can optionally support channel or server services with
full control over all messages and events. These services communicate
with the core server over an extended IRC connection.
All changes to the IRC protocol are designed in a way that existing
clients will continue to work against servers implementing the exten-
sions. Support for the extended protocol can be queried by clients to
take advantage of the added functionality or to conform to the basic
protocol as defined in RFC1459.
"Extensions for Distributed Authoring and Versioning on the World Wide
Web -- WEBDAV", Jim Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi,
03/26/1997, <draft-jensen-webdav-ext-01.txt>
WEBDAV (Web Distributed Authoring and Version control) specifies a set
of methods and content-types ancillary to HTTP/1.1 for the management
of resource meta-data, simple name space manipulation, simple resource
locking (collision avoidance) and resource version control.
"Electronic Part Catalog to Business System Interface", S. Sheppard, S.
Peoples, 02/10/1997, <draft-rfced-info-sheppard-00.txt>
This Internet-Draft specifies a standard method of transferring part
and pick list information between dealer business systems (DBS) and
electronics parts catalog (EPC) systems.
"Telnet Remote Serial Port (RSP) Option", R. Barnes, M. Bennett,
02/10/1997, <draft-rfced-info-bennett-00.txt>
This document is a submission to the Internet Engineering Task Force
(IETF) as an Internet draft standard.
"Dublin Core Metadata for Simple Resource Description", J. Kunze, S.
Weibel, C. Lagoze, 09/03/1997, <draft-kunze-dc-01.txt>
The Dublin Core Metadata Workshop Series began in 1995 with an
invitational workshop intended to bring together librarians, digital
library researchers, content experts, and text-markup experts to
promote better discovery standards for electronic resources. The
Dublin Core is a 15-element set of descriptors that has emerged from
this effort in interdisciplinary and international consensus building.
This is the first of a set of documents describing the Dublin Core.
"An Extension to the Web Robots Control Method for supporting Mobile
Agents", F. Giudici, A. Sappia, 02/18/1997,
<draft-giudici-web-robots-cntrl-00.txt>
The Web Robots Control Standard [1] is a method for administrators of
sites on the World-Wide-Web to give instructions to visiting Web
robots. This document describes an extension for supporting Robots
based on Mobile Agents, in a way that is independent of the technology
used for their actual implementation.
"Clearing the Traffic Jam at Internet Servers A Network Layer View Of
Network Traffic Consolidation", J. Mansigian, 03/03/1997,
<draft-mansigian-ntc-intro-01.txt>
The cause of the typically glacial response from popular Internet World
Wide Web servers is seldom lack of network bandwidth or any deficits in
the client's equipment. The reason for the abysmal performance is that
the accessed server is spending an inordinate amount of time managing
two problems; an unnecessarily large number of transport connections
and the transmission of masses of redundant data without optimization.
This work addresses both problems.
This document presents an introduction to the concepts and architecture
of network traffic consolidation. It is not intended to describe a
complete protocol with every ancillary feature but rather to focus on
performance driven core ideas that could become a part of emerging
commercially featured protocols.
"BOOTP and DHCP on Mixed Media Link-Layer Networks", Walt Wimer, S.
Martel, 02/20/1997, <draft-martel-bootp-mixedlinklayers-00.txt>
RFCs 951 [1], 1541 [2], and 1542 [3] describe the interactions of BOOTP
[1] and DHCP [2] client, server, and relay agents. However, further
experience with these protocols has revealed the existence of an
interoperability issue. The issue occurs when a given IP subnet is
constructed over one link-layer network inter-connected by
translational bridges to other dissimilar link-layer networks. The
following information attempts to address this problem. It is
impossible for a BOOTP or DHCP client, server, or relay agent to know
in advance whether or not it will be operating in a mixed media
link-layer network environment. Given this fact, all BOOTP and DHCP
client, server, and relay agents SHOULD adopt the recommendations
defined in this memo.
"Fine-Grained Transclusion in the Hypertext Markup Language", A. Pam,
02/25/1997, <draft-pam-html-fine-trans-00.txt>
The word 'hypertext' was coined by Theodor Holm Nelson in his paper 'A
File Structure for the Complex, the Changing and the Indeterminate',
presented at the ACM 20th national conference in 1965. One of the key
concepts in Nelson's vision of hypertext is 'transclusion' or virtual
inclusion, which permits composite documents to be constructed by
reference to the original components rather than by copying.
The Hypertext Markup Language (HTML) is a markup language used to
create hypertext documents that are platform independent. HTML
currently permits the transclusion of various content types using tags
which accept a 'SRC' attribute, such as the IMG, EMBED and APPLET tags,
but does not provide a mechanism for transcluding textual content.
This document proposes markup for text transclusions in HTML and
explains its usage.
"UUIDs and GUIDs", P. Leach, R. Salz, 02/25/1997,
<draft-leach-uuids-guids-00.txt>
This specification defines the format of UUIDs (Universally Unique
IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID
is 128 bits long, and if generated according to the one of the
mechanisms in this document, is either guaranteed to be different from
all other UUIDs/GUIDs generated until 3400 A.D. or extremely likely to
be different (depending on the mechanism chosen). UUIDs were originally
used in the Network Computing System (NCS) [1] and later in the Open
Software Foundation's (OSF) Distributed Computing Environment [2].
This specification is derived from the latter specification with the
kind permission of the OSF.
"GSE+ - An Alternate Addressing Architecture to GSE", A. Durand,
02/26/1997, <draft-durand-gse+-00.txt>
This document present an alternative addressing architecture to the GSE
proposal (draft-ipng-gseaddr-00.txt) of Mike O'dell. The basic change
is the introduction of a site identifier in the ESD.
"E-mail addressing: the worst of all worlds?", G. Klyne, 02/26/1997,
<draft-klyne-addressing-00.txt>
This memo is a critique of Internet e-mail addressing, with particular
reference to its suitability for use in a general purpose interpersonal
communication medium as opposed to its present use largely within a
restricted community.
The critique focusses on the differences between e-mail addresses and
other forms of addressing with which very many lay people are
intimately familiar.
This memo does not offer any solutions to the issues raised; rather it
is hoped to provoke some debate on the matter. The author would be
particularly interested in views from those whose natural language does
not use the Roman (western) alphabet.
"DHCP Option for Proxy Client Configuration File", S. Kwan, 02/26/1997,
<draft-kwan-proxy-client-conf-00.txt>
Application-level gateways are used on networks to provide controlled
access to the Internet. Clients in those networks must be configured
with the name or address of available proxy servers, the list of local
domain names, and other proxy client configuration information before
they can access the Internet. The defacto method of proxy client
configuration is the download of a script or configuration file named
by a URL. This document describes a DHCP option in which to transmit
this URL to a proxy client.
"Distributed Search Management Protocol", J. Floyd, 03/03/1997,
<draft-floyd-distributed-search-01.txt>
There are a number of instances in which the search for a particular
value (for instance, a cryptographic key) can be distributed across a
large number of machines, however there is not currently a standard
protocol for doing so. A great many algorithms may be used for
searches; because these algorithms may differ greatly, the protocol
used must be flexible enough to be easily extended.
"Zone KEY RRSet Signing Procedure", O. Gudmundsson, E. Lewis, 03/25/1997,
<draft-lewis-dnskey-handling-01.txt>
Under the security extensions to DNS, as defined in RFC 2065 and
draft-ietf-dnssec-update-04.txt, a secured zone will have a KEY RRSet
associated with the domain name at the apex of the zone. This document
covers the manner in which this RRSet is generated, signed, and
inserted into the name servers.
"Extended Path MTU Discovery for IP version 6", D. Sanghi, S. Shah,
03/04/1997, <draft-sanghi-pmtudisc-ext-00.txt>
This draft discusses extensions to the present Path MTU Discovery
mechanism [PMTUDISC]. It provides applications finer control over the
delay and losses incurred during the PMTU Discovery process. The
document proposes two extension header options that allow PMTU
Discovery with minimal overheads.
"Usage of H.323 on the Internet", P. Lantz, 03/04/1997,
<draft-rfced-info-lantz-00.txt>
The H.323 standard defined by the International Telecommunication Union
(ITU) describes 'Visual telephone systems and equipment for local area
networks which provide a non-guaranteed quality of service', that is to
say, video conferencing over Local Area Networks and the Internet.
Although it has been generally accepted that H.323 is an appropriate
standard for audio/video telephony on the Internet, it is a complex
standard. It describes a broad and complex set of capabilities,
including interoperation with other types of video conferencing
systems, and contains references to a number of other ITU standards.
This document describes the parts of the standard that are necessary
for Internet telephony and multipoint conferencing. It describes the
messages that are necessary to work with other H.323 implementations.
In a separate section, it also lists the messages that must be
implemented to be H.323 compliant. This document is a guide to make
the standard more accessible. It is not intended to duplicate
information in the standard. It does not contain specifications of the
messages or details of the protocol.
"Practical Approach to Improving Scalability and Interoperability of SNMP
Applications", A. Romanov, 03/04/1997, <draft-rfced-info-romanov-00.txt>
The goal of this memo is to provide a simple solution for apparent
practical problem of scalability and interoperability of network
management applications.
"Definitions of Managed Objects for IEEE 802.1q Virtual LAN Bridges", I.
Jeyasubramanian, 06/12/1997, <draft-jeya-vlan-8021q-mib-01.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular it describes objects used for managing bridges based on
the IEEE 802.1q draft standard between Local Area Network (LAN)
segments. This memo uses SNMPv2 as the basis for defining VLAN
MIB, and refers to other MIBs whose published definitions use SNMPv2
convention
"A Proposal for Internet and Public Switched Telephone Networks (PSTN)
Internetworking", Igor Faynberg, H. Lu, M. Krishnaswamy, 03/05/1997,
<draft-faynberg-telephone-sw-net-00.txt>
The purpose of this Internet Draft is to start discussion on the issues
involved in interconnecting Internet and Public Switched Networks so as
to provide more effective media than either network type can do
presently. Interworking of the Internet and PSTNs, based on open
well-defined interfaces, will promote interoperability of both the
networks and systems built by different vendors.
"Semantics of DNS NXT Resource Records", O. Gudmundsson, E. Lewis,
03/25/1997, <draft-lewis-dnsnxt-semantics-01.txt>
In 'Domain Name System Security Extensions' (RFC 2065) the NXT Resource
Record (along with SIG RR and KEY RR) is introduced to allow for secure
denial of existence of either a domain name or a RRSet belonging to an
existing domain name. The set of NXT records within a zone create a
virtual 'chain' of RRSets within a zone by indicating, for each name
within a zone, the RRSets for which it owns records and the next name
in the zone.
RFC 2065 discusses security extensions for static DNS zones. An
Internet Draft, draft-ietf-dnssec-update-04.txt, becoming an RFC
describes security in DNS zone which can be dynamically updated. In
this document, the authors build upon them to: - define some terms
used colloquially in the working group - describe the semantics of the
NXT record in greater detail than the two existing documents, in order
to achieve interoperability - introduce and discuss unresolved issues
involving NXT records
"VIPRE -- Virtual Internet Packet Relay: An Encapsulation Architecture
for Unidirectional Links", J. Stepanek, S. Schwab, 03/06/1997,
<draft-stepanek-vipre-00.txt>
This memo describes a method of incorporating unidirectional links into
an IP network in a bidirectional mode by relaying encapsulated IP
packets over a bidirectional network.
"Point-to-point Link Assembly for Simple Multiple Access (PLASMA)", K.
Fujikawa, 03/12/1997, <draft-fujikawa-plasma-00.txt>
This document describes PLASMA, which enables a simple multicast
mechanism and autoconfiguration in an IP subnet consisting of
point-to-point links, such as ATM, Frame Relay, SONET/SDH, etc. PLASMA
utilizes an L2 label switching mechanism and creates data flow paths in
a subnet using the PLASMA protocol. The PLASMA protocol is very simply
defined and works effectively within a single IP subnet. PLASMA
applications to ATM and PPP are also described.
"Update of Korean Character Encoding for Internet Messages", S. Chi, J.
Kim, S. Choi, I. Choi, S. Park, 03/14/1997, <draft-rfced-info-kim-00.txt>
Since RFC 1557, which is a Korean character encoding for internet
messages, was distributed in 1993, most mailers have been implemented
using it. However, it's been reported many occurrences of incompatible
transfer of Korean mail messages such as broken mail messages.
Therefore certain features are need to be extended, and ambiguous
contents must be clarified. This document updates RFC 1557 to resolve
above matters. This memo provides information for the Internet
community. This memo does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.
"Scalable support for multi-homed multi-provider connectivity", Y
Rekhter, T. Bates, 07/09/1997, <draft-bates-multihoming-01.txt>
This document describes addressing and routing strategies for
multi-homed enterprises attached to multiple Internet Service Providers
(ISPs) that are intended to reduce the routing overhead due to these
enterprises in the global Internet routing system.
"Reliable Multicast Transport Protocol", N. Yamanouchi, T. Shiroshita, T.
Sano, O. Takahashi, 09/03/1997, <draft-shiroshita-rmtp-spec-01.txt>
This draft presents the specifications of the 'Reliable Multicast
Transport Protocol,' which is used for information delivery such as
newspaper delivery and software updates. The protocol aims to realize
a full reliable multicast of bulk data from a server to thousands of
receivers. Scalability of the protocol, flow/congestion control
extension, and security issues are described as an addendum for the
protocol specifications. This document defines RMTP version 1
specification and also constitutes a Part 1 of RMTP version 2
specification.
"Returning Values from Forms: multipart/form-data", Larry Masinter,
08/02/1997, <draft-masinter-form-data-01.txt>
This specification defines an Internet Media Type,
multipart/form-data, which can be used by a wide variety of
applications and transported by a wide variety of protocols as a
way of returning a set of values as the result of a user filling
out a form.
"Wildcards in the Accept-Charset Header", K. Holtman, 03/20/1997,
<draft-holtman-http-wildcards-00.txt>
The HTTP/1.1 specification (RFC 2068) defines an Accept-Charset header,
but fails to define a wildcard '*' which could be used in this header
to match all character sets. This proposal corrects this omission.
"DIAMETER Authentication Extensions", Allan Rubens, Pat Calhoun,
03/21/1997, <draft-calhoun-diameter-authent-00.txt>
DIAMETER is a management protocol used between Network Access Servers
and DIAMETER Servers for authentication, authorization, accounting of
dial-up users. A considerable amount of effort was put into the design
of this protocol to ensure that an implementation could support both
DIAMETER and RADIUS at the same time.
This document details the RADIUS authentication messages and how they
may be used with the DIAMETER protocol.
"QoS Path Management with RSVP", R. Guerin, Shai Herzog, S. Kamat,
03/21/1997, <draft-guerin-qospath-mgmt-rsvp-00.txt>
This document describes a proposal aimed at allowing management through
the RSVP [RZB+96] protocol of paths selected by a QoS routing algorithm
such as those of [GOW96, ZSSC96]. The goals of the proposal are to
allow efficient management of such QoS paths with the minimum possible
impact to the RSVP protocol and the existing routing infrastructure.
Basic features of the approach include leveraging of RSVP soft state
mechanisms, and simple extensions to enable soft pinning (sticking) of
paths selected by the QoS routing algorithm. In addition, the proposal
addresses the issue of preventing the formation of data path loops, and
of avoiding potential race conditions.
"DIAMETER", Allan Rubens, Pat Calhoun, 03/21/1997,
<draft-calhoun-diameter-00.txt>
This original document was named Enhanced RADIUS and was changed at the
request of the WG since this protocol is different from the former.
This document describes a management protocol used between Network
Access Servers and DIAMETER Servers for authentication, authorization,
accounting of dial-up users. A considerable amount of effort was put
into the design of this protocol to ensure that an implementation could
support both DIAMETER and RADIUS at the same time.
"DIAMETER Extensible Authentication Protocol Support", Allan Rubens, B.
Aboba, Pat Calhoun, 03/21/1997, <draft-calhoun-diameter-eap-00.txt>
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how the EAP Protocl may be used in conjunction
with the DIAMETER protocol.
"IMAP4 ID extension", T. Showalter, 03/21/1997,
<draft-showalter-imap-id-00.txt>
The purpose of the ID extension to the IMAP4rev1 protocol is to allow
the server and client to exchange identification information on their
implementation in order to make bug reports and usage statistics more
complete.
Although the IMAP4rev1 protocol described in [IMAP4rev1] provides a
method for accessing remote mail stores, there is no facility to
advertise what program a client or server uses to provide service. This
makes it difficult for implementors to get complete bug reports from
users, as it is frequently difficult to know what client or server is
in use. Additionally, some sites may wish to assemble usage
statistics based on what clients are used, but in an an environment
where users are permitted to obtain and maintain their own clients this
is difficult to accomplish.
"Internet Public Key Infrastructure: Web-based Certificate and CRL
Repository", Y. Sameshima, H. Kikuchi, M. Sakurai, H. Hattori,
03/24/1997, <draft-kikuchi-web-cert-repository-00.txt>
This document provides a specification how to publish and retrieve
X.509 certificates and certificate revocation lists (CRLs). In the
proposed method, the World Wide Web (WWW) is used for securely
distributing certificates across a firewall in both human and machine
readable syntax. A various certificate concerning information that
includes certificates, CRLs, and certification authority (CA) policy
are retrieved from an integrated single authority access point
specified in X.509 version 3 extensions. The information access point
accepts certification and revocation requests in the uniform access
method based on the standard WWW.
"SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman,
06/02/1997, <draft-hoffman-smtp-ssl-03.txt>
This document describes an extension to the SMTP service that allows an
SMTP server and client to use transport-layer security to provide
private, authenticated communication over the Internet. This gives SMTP
agents the ability to protect some or all of their communications from
eavesdroppers and attackers.
"Simple Integrated Media Access (SIMA)", K. Kilkki, 06/18/1997,
<draft-kalevi-simple-media-access-01.txt>
The basic objectives of future Internet are to increase the network
capacity, to offer a practical real-time service, and to develop a
feasible charging scheme. These objectives introduce very strict
requirements for the traffic control system. This paper presents a new
simple approach for traffic management: Simple Integrated Media Access
(SIMA) service. According to the SIMA concept each customer shall
define only two issues before a connection establishment: a nominal bit
rate (NBR) and the selection between real-time and non-real-time
service classes. NBR has two purposes: it forms the basis of charging,
and it defines how the network capacity is divided among different
connections during overload situations. Simplicity means that, on the
one hand, the network operator does not guarantee the continuous
availability of network operator does not guarantee the continuous
availability of nominal bit rate, and on the other hand, the user is
allowed to send data with any bit rate independently of the NBR.
However, the bit rate of transmission defines the cell loss probability
in the case of network congestion. In this way a simple, but effective,
self-regulation of traffic can be
"Realizing the Benefits of Virtual LANs by Using IPv6", J. Le Boudec, T.
Kurz, H. Einsiedler, 03/25/1997,
<draft-kurz-virtual-lans-benefits-00.txt>
The benefits that Virtual LANs offer can be realized by using features
of an IPv6 network along with small enhancements the IPv6 and DHCPv6
protocol stacks.
"Host Reachability Advertisement for IPv6", J. McCann, 03/25/1997,
<draft-mccann-ipv6-hra-00.txt>
This document describes a mechanism that can be used by IPv6 hosts to
communicate information about their address configuration to
neighboring routers. In particular, this mechanism is intended to
allow multihomed hosts and hosts with anycast addresses to communicate
this information to their neighboring routers. This document defines a
new ICMPv6 informational message type, a 'Host Reachability
Advertisement' to carry this information. It also defines a second
ICMPv6 message, a 'Host Reachability Solicitation', that can be used to
trigger Host Reachability Advertisements.
"Header Compression for IPv6 over PPP", M. Engan, 03/25/1997,
<draft-engan-ipv6-hc-00.txt>
The Point-to-Point Protocol [RFC1548] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links.
Header Compression for IPv6 [IPv6HC] is a method to compress IPv6
datagram headers (any combination of IPv6, IPv4, TCP and UDP headers
can be compressed).
This document describes methods for transmission of datagrams with
headers compressed by IPv6 Header Compression over point-to-point
links.
"The Use of URLs as Meta-Syntax for Core Mail List Commands and their
Transport through Message Header Fields", J. Baer, G. Neufeld,
08/21/1997, <draft-baer-listspec-01.txt>
The mailing list command specification header fields are a simple
set
of fields to be added to email messages sent by email distribution
lists. Each field contains a URL (usually mailto) locating the
relevant information or performing the command directly. The three
core header fields described in this document are List-Help,
List-Subscribe, and List-Unsubscribe.
There are three other header fields described here which, although
not as widely applicable, will have utility for a sufficient number
of mailing lists to justify their formalization here. These are
List-Post, List-Owner and List-Archive.
By including these header fields, mail clients can provide automated
tools for performing these functions. This could take the form of a
menu item, push button, or other user interface element. The intent
is to simplify the user experience, providing a common interface to
the often cryptic and varied mailing list manager commands.
"S/MIME Message Specification", S. Dusse, L. Lundblade, Paul Hoffman, L.
Repka, B. Ramsdell, 10/21/1997, <draft-dusse-smime-msg-05.txt>
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and privacy and data security (using encryption).
"S/MIME Certificate Handling", S. Dusse, Paul Hoffman, Jeff Weinstein, B.
Ramsdell, 10/21/1997, <draft-dusse-smime-cert-04.txt>
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This draft
describes the mechanisms S/MIME uses to create and validate keys using
certificates.
"Recommendations on Queue Management and Congestion Avoidance in the
Internet", Jon Crowcroft, 03/25/1997, <draft-irtf-e2e-queue-mgt-00.txt,
.ps>
This memo presents two recommendations to the Internet community
concerning measures to improve and preserve Internet performance. It
presents a strong recommendation for testing, standardization, and
widespread deployment of active queue management in routers, to improve
the performance of today's Internet. It also urges a concerted effort
of research, measurement, and ultimate deployment of router mechanisms
to protect the Internet from flows that are not sufficiently responsive
to congestion notification.
"RSVP over ATM Implementation Guidelines", Lou Berger, 07/11/1997,
<draft-ietf-issll-atm-imp-guide-01.txt, .ps>
This note presents specific implementation guidelines for running RSVP
over ATM switched virtual circuits (SVCs). The general problem is
discussed in [8]. Implementation requirements are discussed in [3].
Integrated Services to ATM service mappings are covered in [6]. The
full set of documents present the background and information needed to
implement Integrated Services and RSVP over ATM.
"HTTP 1.1 as a Transport for the Internet Printing Protocol", R. Turner,
03/25/1997, <draft-turner-ipp-trans-develop-00.txt>
The definition of the Internet Printing Protocol (IPP) is specified
abstractly, and does not detail a particular implementation. The
abstract definition of IPP is contained within the 'IPP Model'
document, a separate document available at the Printer Working Group
IPP web page HTTP://www.pwg.org/. This document attempts to map IPP
Model operations and semantics to HTTP 1.1 equivalent operations.
"QoS Routing Mechanismsand OSPFExtensions", R. Guerin, D. Williams, T.
Przygienda, S. Kamat, A. Orda, 03/26/1997,
<draft-guerin-qos-routing-ospf-01.txt>
This memo describes extensions to the OSPF [Moy94] protocol to support
QoS routes. The focus of the document is on the algorithms used to
compute QoS routes and on the necessary modifications to OSPF to
support this function, e.g., the information needed, its format, how it
is distributed, and how it is used by the QoS path selection process.
Aspects related to how QoS routes are established and managed are also
discussed. The goal of this document is to identify a framework and
possible approaches to allow deployment of QoS routing capabilities
with the minimum possible impact to the existing routing
infrastructure.
"RIDE classes", Rick Wesson, David Kessens, D. Shah, 09/10/1997,
<draft-kessens-ride-classes-01.txt>
This document describes the attributes and classes that will be used
in the internet Registry Information Database Exchange formats
(RIDE). For now it is mostly limited to 'domain' and 'contact'
classes since they were widely considered as most urgent. Encoding
that will be used for the objects and ways to find and access
objects
are beyond the scope of this document. This will be addressed in the
future in separate drafts.
"Internet Printing Protocol/1.0: Security", R. deBry, J. Hadsell, D.
Manchala, X. Riley, J. Wenn, 03/26/1997, <draft-debry-ipp-sec-00.txt>
This document is one of a set of documents which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing on
the Internet. The protocol is heavily influenced by the printing model
introduced in the Document Printing Application (ISO/IEC 10175 DPA)
standard, which describes a distributed printing service.
"Physical Topology MIB and Discovery Protocol Proposal", Keith
McCloghrie, Andy Bierman, 03/26/1997,
<draft-bierman-ptopo-mib-proto-00.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
Base (MIB) for use with network management protocols in the Internet
managing physical topology identification and discovery.
"Multicast Chat (MCC) Protocol", K. Hay, 03/26/1997,
<draft-hay-mcc-00.txt>
This document is an rough draft for a proposed new Internet
conferencing protocol called multicast chat (MCC) which uses IP
multicast for the internet layer.
"CIFS Logon and Pass Through Authentication Preliminary Draft", P. Leach,
D. Naik, 03/26/1997, <draft-leach-cifs-logon-spec-00.txt>
This specification defines how a certain Common Internet File Systems
(CIFS) client accomplishes logging on to a CIFS server. The
specification also details how a CIFS server may accomplish pass
through authentication.
"Physical Topology Terminology", Y. Malachi, 03/26/1997,
<draft-malachi-topology-terms-00.txt>
This draft proposes a common nomenclature for use by the Physical
Topology MIB Working Group. This glossary is based on the terms used in
the various Internet Drafts submitted to this working group as well as
on some RFCs. As we move forward with the definition of a common
topology MIB this glossary will evolve to reflect the new constructs in
the MIB and this draft will probably become a section in the Physical
Topology MIB Internet Draft. Although a topology MIB will include
many terms we include here only terms which are not well-defined
elsewhere or might be confusing here.
"Age Header Field in HTTP/1.1", R. Fielding, 09/16/1997,
<draft-fielding-http-age-00.txt>
The 'Age' response-header field in HTTP/1.1 [RFC 2068] is intended to
provide a lower-bound for the estimation of a response message's age
(time since generation) by explicitly indicating the amount of time
that is known to have passed since the response message was retrieved
or revalidated. However, there has been considerable controversy over
when the Age header field should be added to a response. This document
explains the issues and provides a set of proposed changes for the
revision of RFC 2068.
"Using TTLs with Administratively Scoped IP Multicast Addresses", Ross
Finlayson, 03/26/1997, <draft-finlayson-ttl-admin-scope-00.txt>
The use of 'administratively scoped' multicast address ranges (as
described in [1]) leads to a multicast traffic scoping mechanism that
is superior to the original 'TTL scoping' mechanism.
Contrary to popular opinion, however, administrative (often abbreviated
as 'admin') scoping does not truly *replace* TTL scoping. In
particular, multicast-based applications must still be aware of which
TTL value(s) they use.
In this document, we note that each definition of a range of admin
scoped multicast addresses should be accompanied by a corresponding
'maximum effective TTL' that should be used with these addresses. We
describe how these TTL values are used by applications, and how they
may influence the configuration of multicast border routers.
"Requirements for Unreliable Multicasting of Web Resources", B. Aboba,
03/26/1997, <draft-aboba-unweb-00.txt>
This document discusses applications for unreliable multicasting of Web
resources as well as requirements for an unreliable multicast protocol
suitable for this use.
"The Receiver-Initiated Shortcut Path Protocol (RISP)", Y. Chen, J.
Ogawa, 08/28/1997, <draft-ogawa-receiver-shortcut-path-00.txt>
This memo defines the Receiver Initiated Shortcut Path (RISP)
protocol for NBMA networks. The protocol extends the NHRP message
set by adding Callback Request and Reply messages to allow the
destination host (or its corresponding egress router) to establish
a shortcut path for a data flow, using the existing NBMA signaling
protocols. Because of this receiver-initiated mechanism, a
shortcut-capable network can use just the NBMA ARP servers, such
as
the ATMARP servers, instead of the more complex Next Hop
Servers. This draft also describes how to extend NHRP with the
new,
receiver-initiated mechanism.
"A Stream Cipher Encryption Algorithm", Rodney Thayer, 04/16/1997,
<draft-thayer-cipher-01.txt>
There is a need in the Internet community for an encryption algorithm
that provides interoperable operation with existing deployed commercial
cryptographic applications. This interoperability will allow for a
smoother transition to protocols that have been developed through the
IETF standards process. This document describes an existing algorithm
that satisifies this requirement.
"Implications of the GSE Addressing Scheme to IPv6 Multicast", F. Dupont,
03/26/1997, <draft-dupont-ipv6-gse-multicast-00.txt>
This document presents some implications for the GSE Addressing Scheme
([1] draft-ietf-ipngwg-gseaddr-00.txt proposal by Mike O'Dell) on IPv6
multicast: a new scope for large structures and a clever way to compare
two addresses for the election of a designated router.
"CIFS Remote Administration Protocol
Preliminary Draft", P. Leach, D. Naik, 03/26/1997,
<draft-leach-cifs-rap-spec-00.txt>
This specification defines how an RPC like mechanism may be implemented
using the Common Internet File System (CIFS) Transact SMB. Specific
examples are provided of how a CIFS client may request a CIFS server to
execute a function. The examples show complete details of the request
sent by the CIFS client and the response from the CIFS server.
"Locating DS Entries by E-mail Address
Preliminary Draft", P. Leach, 03/26/1997,
<draft-leach-asid-ds-email-00.txt>
The LDAPv3 protocol (as specified in [1]) is designed to be a
lightweight access protocol for directory services supporting X.500
models. In addition, in an Internet context, many of the names about
which users seek information are Internet email addresses. A native
LDAP based directory service for the Internet should make it convenient
to process such names -- there is a huge social investment spanning two
decades to get to the point where names like 'john.doe@somewhere.com'
can appear in newspaper articles, TV commercials, and on billboards and
millions of people understand what do with them.
This draft defines a very simple convention for looking up information
associated with people identified by Internet email addresses - really
nothing more than identifying an existing capability of LDAP, in the
hopes that the convention can become widespread.
"CIFS Printing Specification Preliminary Draft", P. Leach, D. Naik,
03/26/1997, <draft-leach-cifs-print-spec-00.txt>
This specification defines how clients may submit print requests to a
server using SMBs . The specification also details how clients may
administer printing of the print requests they create, using SMBs
defined in the Common Internet File System specification.
"ARIS: Aggregate Route-Based IP Switching", R. Woundy, R. Boivie, N.
Feldman, A. Viswanathan, 03/26/1997,
<draft-viswanathan-aris-overview-00.txt>
IP based networks use a number of routing protocols, including RIP,
OSPF, IS-IS, and BGP, to determine how packets ought to be routed.
Among these protocols, OSPF and BGP are IETF-recommended standards that
have been extensively deployed and exercised in many networks. In this
memo, we describe a mechanism which uses these protocols as the basis
for switching IP datagrams, by the addition of a simple protocol
('ARIS') that establishes switched paths through a network. The ARIS
protocol allows us to leverage the advantages of switching technologies
in an internet network.
"ARIS Specification", N. Feldman, A. Viswanathan, 03/26/1997,
<draft-feldman-aris-spec-00.txt>
ARIS (Aggregate Route-Based IP Switching) adds the advantages of
high-speed switching to a network based on routing protocols. It
provides a means of mapping network-layer routing information to
link-layer switched paths, enabling datagrams to traverse a network at
media speeds. This memo defines the ARIS protocol and its mechanisms.
"CIFS/E Browser Protocol
Preliminary Draft", P. Leach, D. Naik, 03/27/1997,
<draft-leach-cifs-browser-spec-00.txt>
The CIFS/E (CIFS extensions for enterprise networks) family of
protocols includes a protocol for browsing. Browsing is a mechanism for
discovering servers that are running particular services (not just CIFS
file services). Servers are organized into named groups called domains,
which form browsing scopes. This document specifies version 1.15 of
the browsing protocol. It also specifies the mailslot protocol, because
the browsing protocol depends on it (and is the only CIFS/E protocol
which does).
"Soft State Switching A
Proposal to Extend RSVP for Switching RSVP Flows", A. Viswanathan, Vijay
Srinivasan, 03/27/1997, <draft-viswanathan-aris-rsvp-00.txt>
This memo describes a mechanism for establishing a switched path with
guaranteed Quality of Service for RSVP [1] flows in an integrated
switch-router environment. It proposes an extension to the RSVP
protocol that allows establishment of a sequence of virtual connections
along the hop-by-hop routed path by enabling adjacent nodes to exchange
Layer-2 labels. The labels correspond to information that identifies
the virtual connections; for example, the VPI/VCI value in the case of
an ATM-based Layer-2 infrastructure.
"Directory Entries From Email Address", B. Greenblatt, 07/23/1997,
<draft-greenblatt-defema-02.txt>
This draft describes various means for finding a user's directory entry
in a LDAP directory presuming that the user's electronic mail address
is known. This draft does not presume any specific DIT structure or
schema modifications.
"Simple Transaction Security (STS)", B. Tung, 08/01/1997,
<draft-tung-transsec-sts-01.txt>
This document describes Simple Transaction Security (STS), a
protocol for specifying services and protocols used to secure an
enclosed message. The framework is flexible enough to allow a wide
variety of protocols to be used, at the cost of some negotiation
and
the optimizations present in protocols such as S-HTTP.
"Compression in IP Security", Rodney Thayer, R. Monsour, M. Sabin, A.
Shacham, S. Anand, 03/27/1997, <draft-monsour-compr-ipsec-00.txt>
This memo discusses the application of lossless compression technology
to the IP Security Architecture [IPSecArch]. Over the last few several
months, a number of lively debates on this topic have been held on
IPSec mailing list. This memo discusses the issues raised, the
alternatives available to resolve them and provides a set of
recommendations to bring resolution to the issue.
The goals of the draft are to: (1) define the problem solved by the use
of compression in the context of IPSec, (2) review the use of
compression and security technologies as they have been applied in
other layers of the protocol stack, (3) outline a set of requirements
for applying compression to IPSec, (4) discuss alternative methods
which can be implemented to meet the requirements, and (4) propose a
set of recommendations for consideration by the working group.
"ARIS Support for LAN Media Switching", S. Blake, Vijay Srinivasan, W.
Pace, A. Ghanwani, 03/27/1997, <draft-blake-aris-lan-00.txt>
ARIS (Aggregate Route-based IP Switching) [ARIS] is a protocol which,
in coordination with network-layer routing protocols, establishes
link-layer switched paths through a network of Integrated Switch
Routers (ISR). This memo describes ARIS protocol mechanisms which
enable LAN media switching of IP packets. In addition, this memo
describes the functional behavior of ISRs which are interconnected via
LAN media (e.g., ethernet, token ring, FDDI). The proposed mechanisms
are designed to permit easy implementation using emerging LAN switching
technology.
"The Use of End System Designators in IPv6", M. Thomas, 03/27/1997,
<draft-thomas-ipv6-esd-00.txt>
There is a proposal to split unicast IPv6 addresses into two 8 byte
quantities. The first 8 bytes will contain routing information which
is used to reach a subnetwork. The last 8 bytes will contain a
identifier of a node on that subnet. This identifier is globally
unique and is called an End System Designator (ESD). The ESD (not the
entire 16 byte address) will be used to accept packets and identify
connections, among other things.
"A ``Classy'' Approach to Aggregation for Integrated Services", S.
Berson, S. Vincent, 03/27/1997, <draft-berson-classy-approach-00.txt,
.ps>
The current Integrated Services (IS) architecture has a fundamental
scaling problem in that per flow state is maintained everywhere. Our
approach is to use aggregation as a technique to address this problem.
There is a wide spectrum of approaches towards aggregation of IS state,
with different tradeoffs in the amount of state required. This draft
describes one promising approach to aggregating IS state within defined
regions of a network. Service classes are configured on all of the
routers in a region. At the edges of the region, routers keep detailed
IS state and map packets into the configured traffic service classes.
In the interior of this region, routers need keep only a bounded amount
of IS state.
"Locating Native Internet LDAP Servers
Preliminary Draft", P. Leach, 03/27/1997,
<draft-leach-asid-ldap-locating-00.txt>
The LDAPv3 protocol (as specified in [1]) is designed to be a
lightweight access protocol for directory services supporting X.500
models. This may be the X.500 directory itself, but the LDAP
specification explicitly allows it to be a different directory. Let us
define a 'native LDAP server' to be one that is not a front end to the
X.500 directory service. Let us further define an 'Internet based
organization' as one that has a domain name, and an 'Internet LDAP
server' to be one containing a directory entries for such an
organization. A native LDAP server can
not rely upon the X.500 directory's knowledge base to locate the
appropriate server to service a request on an object in a part of the
directory tree (DIT) other than the naming context(s) it stores.
This draft defines a way that native Internet LDAP servers can make use
of the DNS's knowledge base (which it stores as 'glue' records) to
perform the same function, while still supporting integration with the
X.500 directory.
"Physical Topology Framework", Ken Jones, 03/27/1997,
<draft-kjones-ptopo-framework-00.txt>
This memo defines a framework for the collection of physical topology
information. Physical topology is defined as the physical
interconnection of communication ports between communication devices.
The framework allows for topology determination within and across a
broad spectrum of devices. It establishes a set of guidelines for
topology mechanisms used to distribute and collect topology
information, and describes the behavior of a management station
required to collect topology information across a potentially large and
diverse set of communication devices. A companion memo will provide an
experimental portion of the Management Information Base (MIB) which is
derived from this framework and allows the management workstation to
gather physical topology information from the devices in the network.
"Interdomain Multicast Routing Support for Integrated Services Networks",
Deborah Estrin, S. Shenker, Bob Braden, D. Zappala, 03/27/1997,
<draft-zappala-multicast-routing-ar-00.txt, .ps>
This document describes an architecture for interdomain multicast
routing support of integrated services networks. The key features of
this architecture are a multicast route setup protocol and local route
construction agents. Together, these two components enable multicast
routing to install alternate paths and pinned routes on behalf of
receivers that request these services.
"A Route Setup Mechanism For Multicast Routing", D. Zappala, 03/27/1997,
<draft-zappala-multicast-routing-me-00.txt, .ps>
This document describes a multicast route setup protocol that can be
used to install alternate paths and pinned routes when they are
requested by receivers. We describe the protocol, derive some of its
properties, and address its applicability to unicast route setup.
"Data Over Cable Service (DOCS) Radio Frequency (RF) Interface Management
Information Base (MIB)", R. Woundy, W. Sawyer, P. Anderson, 04/14/1997,
<draft-anderson-docs-rf-mib-00.txt>
This Internet-Draft outlines the Radio Frequency (RF) Interface
Management Information Bases (MIBs) for high-speed data-over-cable
systems developed by the MCNS Data Over Cable Services working group.
Two Simple Network Management Protocol (SNMP) MIBs are defined. The
first is the MCNS Interface MIB and defines objects that enable
management of the CATV MAC and PHY layer interfaces. The second is the
MCNS Cable Modem (CM) MIB and defines objects that enable management of
CMs and Cable Modem Termination Systems (CMTSs).
"RETHER : A Protocol for Real-Time Traffic Support on Ethernet", C.
Venkatramani, T. Chiueh, 04/14/1997, <draft-chitra-rether-00.txt>
Distributed multimedia applications require performance guarantees from
the underlying network subsystem. Ethernet has been the dominant local
area network architecture in the last decade, and we believe that it
will remain popular because of its cost-effectiveness and the
availability of higher-bandwidth Ethernets. We present the design of a
software-based timed-token protocol called RETHER that provides
real-time performance guarantees to multimedia applications without
requiring any modifications to existing Ethernet hardware. RETHER
features a hybrid mode of operation to reduce the performance impact on
non-real-time network traffic, a race-condition-free distributed
admission control mechanism, and an efficient token-passing scheme that
protects the network against token loss due to node failures or
otherwise. Performance measurements from a prototype running on 10-Mbps
Ethernet and 100-Mbps Fast-Ethernet indicate that up to 60 of the raw
bandwidth can be reserved without deteriorating the performance of
non-real-time traffic significantly. This scheme is consistent with
the ISSLL over LANs framework described in [7].
"UTF-8, a transformation format of ISO 10646", F. Yergeau, 09/11/1997,
<draft-yergeau-utf8-rev-01.txt>
ISO/IEC 10646-1 defines a multi-octet character set called the Uni-
versal Character Set (UCS) which encompasses most of the world's
writing systems. Multi-octet characters, however, are not compatible
with many current applications and protocols, and this has led to
the
development of a few so-called UCS transformation formats (UTF),
each
with different characteristics. UTF-8, the object of this memo, has
the characteristic of preserving the full US-ASCII range, providing
compatibility with file systems, parsers and other software that
rely
on US-ASCII values but are transparent to other values. This memo
updates and replaces RFC 2044, in particular addressing the question
of versions of the relevant standards.
"An Approach for Using LDAP as a Network Information Service", L. Howard,
09/12/1997, <draft-howard-nis-schema-00.txt>
This document describes an experimental mechanism for mapping
entities related to TCP/IP and the UNIX system into X.500 entries so
that they may be resolved with the Lightweight Directory Access
Protocol [1]. A set of attribute types and object classes are
proposed, along with specific guidelines for interpreting them.
The intention is to assist the deployment of LDAP as an
organizational nameservice. No proposed solutions are intended as
standards for the Internet. Rather, it is hoped that a general
consensus will emerge as to the appropriate solution to such
problems, leading eventually to the adoption of standards. The
proposed mechanism has already been implemented with some success.
"Switched Fabric Connection Tap (SFCT) Protocol", K. Dobbins, T. Grant,
J. Liessner, D. Ruffen, 04/16/1997, <draft-rfced-info-grant-00.txt>
The Switched Fabric Connection Tap (SFCT) protocol is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented
switching networks. The SFCT protocol is used to monitor communication
between two end stations.
"SBCD Protocol Specification", K. Dobbins, T. Grant, D. Ruffen,
04/16/1997, <draft-rfced-info-ruffen-00.txt>
The Switch Broadcast Control and Delivery (SBCD) protocol is part of
the InterSwitch Message Protocol (ISMP). ISMP was designed to
facilitate interswitch communication within distributed
connection-oriented switching networks. The SBCD protocol is used to
reduce the amount of broadcast traffic across the switch fabric by
restricting unresolved broadcast packets to only those ports that
belong to the same VLAN as the source.
"Address Resolution and Location Discovery (ARLD) Protocol", K. Dobbins,
T. Grant, D. Ruffen, 04/16/1997, <draft-rfced-info-dobbins-00.txt>
The Address Resolution and Location Discovery (ARLD) protocol is part
of the InterSwitch Message Protocol (ISMP). ISMP was designed to
facilitate interswitch communication within distributed
connection-oriented switching networks. The ARLD protocol is used to
resolve a packet destination address when the source and destination
pair of a packet does not match a known connection. It is also used to
provide end-station address mobility between switches.
"Loop-free Interswitch Message Path (LSMP) Protocol", K. Dobbins, T.
Grant, D. Ruffen, J. Benoit, 04/16/1997, <draft-rfced-info-benoit-00.txt>
The Loop-Free Interswitch Message Path (LSMP) protocol is part of the
InterSwitch Message Protocol (ISMP). ISMP was designed to facilitate
interswitch communication within distributed connection-oriented
switching networks. The LSMP protocol is used to create and maintain
the flood path over which undirected ISMP messages are sent.
"NETBLT (Network Block Transfer Protocol)", J. White, 04/16/1997,
<draft-white-protocol-stack-00.txt>
The NETBLT protocol [RFC998] was designed as an experimental transport
layer protocol, intended for moving large quantities of data across a
wide variety of networks. It provides reliable bulk transfer with an
end-to-end flow-control mechanism meant to deal with network congestion
by throttling the rate at which data is inserted into the network.
However, experiments with NETBLT across shared links revealed problems
with fairness; traffic from one connection could hog most of a link's
bandwidth, and there seems to be no way to prevent this under the
current rate-control scheme, so further application of NETBLT was not
pursued by its original developers. However, NETBLT has a number of
characteristics which make it very attractive for use across noisy,
long-delay, slow-turnaround, or asymmetric communications links. Such
links are common in military usage, and may become more widespread with
the development of mobile computing. NETBLT's attractive
characteristics include selective retransmission of lost packets,
potentially large transmission windows, and control of transmission
from the receiving, rather than the sending side; the latter makes
NETBLT relatively insensitive to network delays. NETBLT, with minor
"HTTP based Geo-temporal Searching (HGS).", D. van Gulik, C. Best,
07/14/1997, <draft-vangulik-http-search-01.txt>
This draft specifies the first three levels of operation of an http
based distributed search protocol. It is designed for parallel
client-side searching of geospatial catalogues. An important design
objective is to minimize the impact and extra resources for catalogue
sites which already have existing WWW gateways and search interfaces.
"IPSEC Policy Import/Export Format", Rodney Thayer, Naganand Doraswamy,
06/24/1997, <draft-thayer-sec-exp-01.txt>
Under certain conditions it is necessary to configure hosts running IP
Security [RFC-1825] with security parameters and other information in
an out-of-band manner. This draft defines a file format that may be
used to exchange such information via removable media or distribution
via a web server.
THIS DOCUMENT EXPIRES DECEMBER 1997.
"Sieve -- a Mail Filtering Language", T. Showalter, 10/27/1997,
<draft-showalter-sieve-02.txt>
This document describes a mail filtering language for filtering
messages at time of final delivery. It is designed to be
independent
of protocol, and implementable on either a mail client or mail
server. It is meant to be extensible, simple, and independent of
access protocol, mail architecture, and operating system. It is
suitable for running on a mail server where users may not be allowed
to execute arbitrary programs, such as on black box IMAP servers, as
it has no variables, loops, or ability to shell out to external
programs.
"Hierarchical HTTP Routing Protocol", Jeff Mogul, V. Valloppillil,
04/22/1997, <draft-vinod-icp-traffic-dist-00.txt>
Recent interest in finding solutions for traffic problems stemming from
HTTP have centered around the use of cooperating proxy-caches.
We contend that by using a deterministic, hash-based approach for
routing URLs within an 'array' of proxy servers, many of the benefits
of alternative cache cooperation protocols (such as ICP) may be
realized. As an example of such an implementation we propose the
use of 'Proxy Client Configuration Files' between proxy servers in
order to exchange routing information. This implementation is
motivated in part by the adoption of this file by existing, popular web
browsers to provide intelligent URL request routing.
This draft discusses adopting this well-understood, widely implemented
browser protocol by web proxies in order to facilitate intelligent
routing of requests within a network of proxy servers.
"HTTP/1.1 Operation without a Clock", J Mogul, R. Gray, Ari Luotonen,
04/22/1997, <draft-lawrence-http-noclock-00.txt>
This memo describes a problem with the current Proposed Standard for
HTTP/1.1 found as a result of implementation experience. A web server
may be implemented in an embedded system as a network user interface.
Often the embedded system is one which has no other use for a real-time
clock, and/or the web interface is being added to an existing device
which has no clock. Without a clock, no accurate HTTP Date header can
be generated. This memo examines the implications of this situation
for the operation of HTTP/1.1 origin servers, proxies, and clients, and
proposes changes to the HTTP/1.1 specification to permit compliant
operation in such systems.
"The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R.
Weltman, 04/23/1997, <draft-weltman-java-ldap-00.txt>
This document defines a java language application program interface to
the lightweight directory access protocol (LDAP), in the form of a
class library. It complements but does not replace RFC 1823 ([9]),
which describes a C language application program interface.
"XODL: External Object Description Language", B. Long, 04/29/1997,
<draft-long-external-obj-lang-01.txt>
This document describes a data structure (XODL: Object Description
Language) and an associated method which, together, provide a means of
representing situations or types of situations. It can thus be used to
represent objects, events, or systems of objects and events or types of
objects, events or systems. Objects represented can be computer data
objects ('stack', 'word processor', 'user interface', etc.) or 'real'
objects such as computers, networks, users, and so on.
"Comparison of Tag Switching and Cell Switch Router", Y. Katsube, Hiroshi
Esaki, Y. Ohba, 04/25/1997, <draft-ohba-tagsw-vs-csr-00.txt>
Tag Switching and Cell Switch Router are layer integration technologies
between L2 and L3 to provide high-speed cut-through mechanisms for L3
packet transfer by mapping between L3 and L2 datagram labels. TDP and
FANP, used in Tag Switching and Cell Switch Router, respectively, are
protocols that notify the mapping information between peer routers.
Although the objectives of both technologies are the same, there are
several differences in methods for achieving the objective. This memo
compares the two technologies and discusses how to merge them.
"Schema for Storing Calendaring Information in a Directory Service", A.
Dun, D. Hennessy, 04/25/1997, <draft-dun-calsch-schema-00.txt>
The Lightweight Directory Access Protocol [1][2] defines a standard
protocol for accessing diverse directory services. One common use of a
directory service is the location of application services, among which
are a user's calendar and a user's free busy time.
This document defines a set of object classes and attributes for
storing information including URLs to the user's calendar and free/busy
time.
"E-Mail Headers to Facilitate Mailing List Subscriptions and
Unsubscriptions", B. Costales, 08/19/1997,
<draft-costales-subscribe-01.txt>
The number of ways to subscribe-to (and to unsubscribe-from) e-mail
mailing lists is as varied as the number of programmers designing
mailing list software. For some lists, for example, users (un)subscribe
by sending a request to <listname>-request@host.domain. For others
lists the address is majordomo@host.domain with the request to
(un)subscribe embedded in the message body. Yet others set up special
hosts to satisfy this need, such as <listname>@list-off.domain. In
this Internet Draft we offer two new e-mail headers intended to make
mailing list subscription and unsubscription easier and more uniform:
List-Subscribe and List-Unsubscribe.
"DHCP Options For Host System Characteristics", M. Henry, E. Dittert,
04/28/1997, <draft-dittert-host-sys-char-00.txt>
The interoperability of configuration services based on the Dynamic
Host Configuration Protocol (DHCP) [1] in an environment of
heterogeneous clients depends on clients accurately identifying
themselves and their relevant characteristics to configuration servers.
The class identifier provided through DHCP option 60 [2] helps in this
regard, but such identifiers essentially only enable clients and
servers that are 'good friends' to find each other. This draft proposes
the definition of two options that convey particular, generally useful
information about the client system. This enables all servers to
recognize this information, and is a step toward a richer form of
interoperability for configuration services.
"THE TRANSMISSION OF IP OVER THE VERTICAL BLANKING INTERVAL OF A
TELEVISION SIGNAL", R. Panabaker, C. Witty, 10/14/1997,
<draft-panabaker-ip-vbi-01.txt>
This is an Internet-Draft, which describes a method for broadcasting
multicast IP data using the vertical blanking interval of a television
signal. It includes a description for compressing multicast IP headers
on unidirectional networks, a framing protocol identical to SLIP, and a
forward error correction scheme for the NABTS standard.
"SNDM Protocol Specification", K. Dobbins, J. Livingston, D. Ruffen, T.
Grant, 04/29/1997, <draft-rfced-info-livingston-00.txt>
The Switch Neighbor Discovery and Maintenance (SNDM) protocol is part
of the InterSwitch Message Protocol (ISMP). ISMP was designed to
facilitate interswitch communication within distributed
connection-oriented switching networks. Switches use the SNDM protocol
to discover their neighboring switches and establish the topology of
the switch fabric.
"IP Header Compression over PPP", Stephen Casner, C. Bormann, M. Engan,
08/21/1997, <draft-engan-ip-compress-01.txt>
This document describes an option for negotiating the use
of
header compression on IP datagrams transmitted over the
Point-to-
Point Protocol [RFC1661]. It defines extensions to the PPP
Control
Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header
compression
may be applied to IPv4 and IPv6 datagrams in combination with
TCP,
UDP and RTP transport protocols as specified in [IPHC] and
[CRTP].
"Security-Oriented Extension to Mobile IP (SOMIP)", M. Chuah, Y. Li,
04/29/1997, <draft-chuahli-mobileip-somip-00.txt>
This document proposes an extension to the Mobile IP base protocol.
The purpose of this extension is to ease the key management problem
among mobility agents, and to reduce the number of distant
registrations.
"IMAP4 Namespace", C Newman, M. Gahrns, 10/21/1997,
<draft-gahrns-imap-namespace-04.txt>
IMAP4[RFC-2060] does not define a default server namespace. As a
result, two common namespace models have evolved:
The 'Personal Mailbox' model, in which the default namespace that is
presented consists of only the user's personal mailboxes. To access
shared mailboxes, the user must use an escape mechanism to reach
another namespace.
The 'Complete Hierarchy' model, in which the default namespace that
is presented includes the user's personal mailboxes along with any
other mailboxes they have access to.
These two models, create difficulties for certain client operations.
This document defines a NAMESPACE command that allows a client to
discover the prefixes of namespaces used by a server for personal
mailboxes, other users' mailboxes, and shared mailboxes. This
allows a client to avoid much of the manual user configuration that
is now necessary when mixing and matching IMAP4 clients and servers.
"A Protocol for the Transmission of Net News Articles over IP multicast",
H. Rupp, 09/16/1997, <draft-rfced-exp-rupp-03.txt>
Mcntp (Multicast News Transfer Protocol) provides a way to use the
IP
multicast infrastructure to transmit NetNews articles between news
servers. Doing so will reduce the bandwidth that is actually needed
for transmission of articles which is mostly done via NNTP. This
does
not affect how news reading clients communicate with servers.
"Using UTF-8 for non-ASCII Characters in URLs", Larry Masinter,
05/02/1997, <draft-masinter-url-i18n-00.txt>
Traditionally, URLs have been written in ASCII and used both as a
method of transcription and identification, but also in advertising,
magazines and newspapers. This document specifies a uniform way of
representing non-ASCII scripts in URLs so that they can be used for the
world's languages.
"PKCS #10: Certification Request Syntax
Version 1.5", B. Kaliski, 10/21/1997,
<draft-hoffman-pkcs-certif-req-03.txt>
This document describes a syntax for certification requests.
"PKCS #1: RSA Encryption Version 1.5", B. Kaliski, 10/21/1997,
<draft-hoffman-pkcs-rsa-encrypt-03.txt>
This document describes a method for encrypting data using the RSA
public-key cryptosystem.
"PKCS #7: Cryptographic Message Syntax Version 1.5", B. Kaliski,
10/21/1997, <draft-hoffman-pkcs-crypt-msg-03.txt>
This document describes a general syntax for data that may have
cryptography applied to it, such as digital signatures and digital
envelopes. The syntax admits recursion, so that, for example, one
envelope can be nested inside another, or one party can sign some
previously enveloped digital data. It also allows arbitrary
attributes, such as signing time, to be authenticated along with the
content of a message, and provides for other attributes such as
countersignatures to be associated with a signature. A degenerate
case of the syntax provides a means for disseminating certificates
and certificate-revocation lists.
"Creating 40-Bit Keys for DES", Russ Housley, Paul Hoffman, 05/14/1997,
<draft-hoffman-des40-00.txt>
This document describes an method for shortening DES keys from 56 bits
to 40 bits. The shortened keys are generally known as 'DES-40'. The
motivation for this weakening is that some localities (such as the
United States) give special preference to applications that use 40-bit
keys. The weakened keys are then used with the DES encryption algorithm
in the same manner as full-strength keys.
There are many possible methods for reducing a 56-bit key to a 40-bit
key. The method in this draft was chosen because one method is needed
for interoperability. Further, this method has been known to
occaisionally have been approved for export from the United States.
"HTTP and HTML Metadata Linking Mechanism", A. Daviel, 05/15/1997,
<draft-daviel-metadata-link-00.txt>
This memo describes a method of linking resource metadata to resource
objects using HTTP headers or HTML hyperlinks. The method uses features
which exist in HTTP/1.0 and HTML 2.0, namely the Link element, to
reference metadata of arbitrary MIME type from resources of arbitrary
MIME type.
"Dynamical routing (unicast and multicast) for the Ipv6 protocol", W.
Fritsch, H. Seifert, 05/20/1997, <draft-fritsche-ipv6-multicast-01.txt>
Future communication networks will be based more and more on a
dynamically changing network topology. Therefore it is advantageous,
to have routing mechanisms, which will dynamically adapt their routing
decisions to these topology changes. This document describes a set of
network protocols, which realize such a dynamical routing of unicast
and multicast packets within communication networks based on IPv6. All
used routing algorithms will be immediately executed at the occurrence
of any topology changes and will therefore have already complete
routing information at the receipt of data packets.
For the unicasting the Shortest Path First (SPF) routing algorithm has
be chosen. This algorithm calculates the shortest, and therefore the
optimal routing paths within the routing area, by which it is
sufficient for a router, to compute a single routing tree for the whole
area. For the multicasting the Minimum Spanning Tree
(MST) routing algorithm has been chosen. This distributed algorithm
prevents the occurrence of endless routing loops, offers for
distributed Address Groups nearly optimal results in saving network
bandwidth, and needs
"Japanese Message Signing Procedure with Security Multipart", K.
Yamamoto, 05/19/1997, <draft-kazu-jmsg-sign-secmime-00.txt>
This memo defines a signing procedure for Japanese message in the
context of security multipart. The procedure guarantees signature
validity even if messages are processed through message transfer agents
which carelessly transform character set encodings.
To sign Japanese message digitally, local forms such as EUC/Japanese,
Shift-JIS, etc., are first converted into the transfer form,
ISO-2022-JP with an appropriate set of MIME headers. Then it is
duplicated into two objects. The first object is transformed into the
signature form defined in this memo and a detached digital signature is
calculated over it. A 'Multipart/Signed' part is created with the
second object and the detached digital signature. Japanese text is
verified as the signature form instead of the transfer form.
To encrypt Japanese message, the transfer form, ISO-2022-JP with an
appropriate set of MIME headers, is used.
"Multi-signature Extensions for PGP/MIME", K. Yamamoto, 05/19/1997,
<draft-kazu-pgpmime-multisig-00.txt>
PGP/MIME provides single signature service of PGP in the context of
MIME, however, multiple signature service is desired for usability and
flexibility. For this purpose, this memo defines
'Multipart/PGP-Signature' used as the 'protocol' parameter and the
content type of the second part of 'Multipart/Signed'.
Canonical MIME format used in PGP/MIME is reasonable but it is not
enough for some kinds of MIME objects, particularly for ISO 2022 text.
Thus, this memo extends the 'micalg' parameter syntax as
'pgp-<hash-symbol>+<canform-symbol>' so that <canform-symbol> can
specify more specific canonicalization for signature calculation.
"Remote Passphrase Authentication", G. Brown, 05/19/1997,
<draft-petke-remote-pass-auth-00.txt>
Remote Passphrase Authentication provides a way to authenticate a user
to a service by using a pass phrase over an insecure network, without
revealing the pass phrase to eavesdroppers. In addition, the service
need not know and does not learn the user's pass phrase, making this
scheme useful in distributed environments where it would be difficult
or inappropriate to trust a service with a pass phrase database or to
allow the server to learn enough to masquerade as the user in a future
authentication attempt.
This scheme was inspired by Dave Raggett's Mediated Digest
Authentication, draft-ietf-http-mda-00.txt.
This specification is divided into five parts. Part Zero contains an
extended introduction to the problem and potential solutions. Part One
explains the mechanism. Part Two explains how to incorporate the
mechanism into HTTP. Part Three explains the protocol between the
service and deity. Part Four explains the GSS-API token formats. Feel
free to start with Part One; Part Zero provides background information
and is not a prerequisite for Part One.
"AP -- Access Protocol", R. Earhart, 05/19/1997,
<draft-earhart-ap-spec-00.txt>
The Access Protocol defines a standard extensible framework upon which
application-specific protocols may be layered, providing a piece of
infrastructure for a common class of internet protocols.
"VLS Protocol Specification", K. Dobbins, L. Kane, 05/21/1997,
<draft-rfced-info-kane-00.txt>
The Virtual LAN Link State Protocol (VLSP) is part of the InterSwitch
Message Protocol (ISMP). ISMP was designed to facilitate interswitch
communication within distributed determine and maintain a fully
connected mesh topology graph of the switch fabric. Each switch
maintains an identical database describing the topology.
Call-originating switches use the topology database to determine the
path over which to route a call connection.
VLSP provides support for equal-cost multipath routing, and
recalculates routes quickly in the face of topological changes,
utilizing a minimum of routing protocol traffic.
"State Tokens and Preconditions for HTTP", Jim Whitehead, Y. Goland,
05/22/1997, <draft-goland-state-token-00.txt>
There are times when a principal will want to predicate successful
execution of a method on the current state of a resource. While
HTTP/1.1 provides a mechanism for conditional execution of methods
using entity tags via the 'If-Match' and 'If-None-Match' headers, the
mechanism is not sufficiently extensible to express conditional
statements involving more generic state indicators, such as lock
tokens. This draft defines the term 'state
token' as an identifier for a state of a resource. This draft defines
requirements for state tokens and provides a state token syntax, along
with two new headers which are used to express method preconditions
using state tokens.
"Use of Label Switching With RSVP", Bruce Davie, Y Rekhter, E. Rosen,
05/28/1997, <draft-davie-mpls-rsvp-00.txt>
Multiprotocol Label Switching (MPLS) allows labels to be bound to
various granularities of forwarding information, including application
flows. In this document we present a specification for allocating and
binding labels to RSVP flows, and distributing the appropriate binding
information using RSVP messages.
"IP Address Resolution and ATM Signaling for MPLS over ATM SVC services",
Y Rekhter, Y. Katsube, Hiroshi Esaki, K. Nagami, P. Doolan, 05/29/1997,
<draft-katsube-mpls-over-svc-00.txt>
Enabling interconnection of ATM Label Switching Routers (ATM-LSRs) over
standard ATM switch networks is desirable in order to introduce MPLS
technology into emerging ATM-LAN/WAN platform. This draft describes
how ATM-LSRs may interoperate with other ATM-LSRs over ATM UNI SVC
services. The two aspects of the problem that we address are ATM
address (of target ATM-LSR) resolution and SVC to label binding.
"Media-independent Error Correction using RTP", P. Long, R. McKenzie, D.
Budge, W. Mills, W. Diss, 06/02/1997,
<draft-budge-media-error-correction-00.txt>
This document specifies a media-independent error-correction scheme
using the Real-Time Transport Protocol (RTP), along with the payload
format for encapsulating both error-correction signaling and media
bitstreams in RTP. It enables the reconstruction of lost packets across
a connectionless transport such as RTP over UDP. The goal of this
scheme is to maximize isochrony, the regular and timely delivery of
data, with minimal bandwidth, latency, and computational costs.
"Plaintext Password SASL Mechanism and Transition Codes", C Newman,
07/20/1997, <draft-newman-sasl-plaintrans-03.txt>
While plaintext passwords have very poor security characteristics
by themselves, there are a number of contexts where they are
useful
or necessary. This defines a plaintext password mechanism for
SASL
[SASL] which is intended to be used in combination with an
external
encryption layer, as a transition mechanism from a legacy
authentication database, or to use (insecurely) a legacy
authentication database which can not practically be replaced.
In hopes of promoting the future elimination of unencrypted
plaintext passwords, this defines error codes for use with POP3
and
IMAP4: one to indiciate the need for a transition to a stronger
mechanism, a second to indicate that a SASL mechanism is too weak
for per-user security policy for a given service, and a third to
indicate that a SASL mechanism is only accepted in combination
with
an external strong encryption mechanism. Any protocol offering
the
PLAIN mechanism SHOULD also support equivalent error codes.
"The IP Network Address Translator (NAT)", Pyda Srisuresh, Kjeld Egevang,
09/02/1997, <draft-rfced-info-srisuresh-03.txt>
Basic Network Address Translation or Basic NAT is a feature by
which IP addresses are mapped from one group to another, transparent
to users. Network Address Port Translation, or NAPT is an extension
to Basic NAT, in that many network addresses and their TCP/UDP ports
are translated to a single network address and its TCP/UDP ports.
"Interoperation Between Distinct Types of Label Switched Paths", Y.
Katsube, Hiroshi Esaki, 06/06/1997,
<draft-katsube-interop-between-lsps-00.txt>
Label Switching Routers are able to handle several distinct types of
Label Switched Paths (LSPs) depending on the triggers for establishing
or releasing LSPs or the granularity of the flow that are dedicated to
each of the LSPs. This memo first analyzes characteristics of
individual types of LSPs, and discusses possible interoperation
scenario between them.
"Hot Standby Router Protocol (HSRP)", Tony Li, B. Cole, D. Li, P. Morton,
10/06/1997, <draft-li-hsrp-01.txt>
The memo specifies the Hot Standby Router Protocol (HSRP). The goal
of the protocol is to allow hosts to appear to use a single router
and to maintain connectivity even if the actual first hop router
they
are using fails. Multiple routers participate in this protocol and
in concert create the illusion of a single virtual router. The
protocol insures that one and only one of the routers is forwarding
packets on behalf of the virtual router. End hosts forward their
packets to the virtual router.
The router forwarding packets is known as the active router. A
standby router is selected to replace the active router should it
fail. The protocol provides a mechanism for determining active and
standby routers, using the IP addresses on the participating
routers.
If an active router fails a standby router can take over without a
major interruption in the host's connectivity. This memo also
discusses the ARP, MAC address, and security issues with this
protocol.
"Uniform Resource Locators for Television Broadcasts", D. Zigmond,
06/10/1997, <draft-zigmond-tv-url-00.txt>
World-Wide Web browsers are starting to appear on a variety of consumer
electronic devices, such as television sets and television set-top
boxes, which are capable of receiving television programming from
either terrestrial broadcast, satellite broadcast, or cable. On these
devices, some of the URL schemes described in [1] are inappropriate.
For example, many of these devices lack local storage, so the 'file'
scheme is of little use. This draft proposes a new URL scheme for
uniquely identifying streams of television broadcasts on such devices.
"A Clarification for Textual Conventions in SMIv2", David Perkins,
06/12/1997, <draft-perkins-clartc-00.txt>
This memo is informational. It specifies a clarification of version 2
of the SNMP SMI, a standard for the Internet community, which is
defined by RFCs 1902[1], 1903[2], and 1904[3]. The clarification is to
fix a perceived inconsistency in the definition of the
TEXTUAL-CONVENTION construct. This problem is resolved by replacement
text for section 3.5 of RFC 1903.
"Support for Large Integers in SNMP", David Perkins, 06/12/1997,
<draft-perkins-bigint-00.txt>
This memo is informational. It specifies an approach to add 64-bit
signed and unsigned integer types to versions 1 and 2 of the SNMP
SMI[1][2][3][4][5][6], and versions 1 and 2 of the SNMP
protocol[7][8][9] without changes. Thus, this addition requires no
modifications to existing SNMP MIB compilers, and no changes to
existing SNMP protocol engines used in SNMP agents and SNMP management
applications. This memo does not specify a
standard for the Internet community.
"The BITS Pseudotype", David Perkins, 06/12/1997,
<draft-perkins-bits-00.txt>
This memo is informational. It specifies replacement text for version
2 of the SNMP SMI, which is defined by RFCs 1902[1], 1903[2], and
1904[3], to fix the incorrect usage of ASN.1 to specify a BITS
pseudotype. The BITS pseudotype must have the look and functions of an
ASN.1 type in the following constructs allowed in SMIv2 format MIB
modules: OBJECT-TYPE, SEQUENCE, MODULE-COMPLIANCE, AGENT-CAPABILITIES,
TEXTUAL-CONVENTION, and type assignments. The ASN.1 macros defined in
RFCs 1902, 1903, and 1904 do not support the requirements.
"Support for Floating-Point in SNMP", David Perkins, 06/12/1997,
<draft-perkins-float-00.txt>
This memo is informational. It specifies an approach to add
floating-point types to versions 1 and 2 of the SNMP
SMI[1][2][3][4][5][6], and versions 1 and 2 of the SNMP
protocol[7][8][9] without changes. Thus, this addition requires no
modifications to existing SNMP MIB compilers, and no changes to
existing SNMP protocol engines used in SNMP agents and SNMP management
applications. This memo does not specify a
standard for the Internet community.
"Firewall Traversal authorization system", M. Richardson, K. Martius,
07/10/1997, <draft-richardson-ipsec-traversal-01.txt>
This document describes a public key certificate mechanism to authorize
traversal of multiple security gateways (firewalls). This work is
independant of transport layer in concept, and could apply to IPsec,
TLS, or SecSH. It is applied here to IPsec. The SPKI certificate format
is used here.
"Description of the EP2 Cipher", Peter Gutmann, 06/16/1997,
<draft-rfced-info-gutmann-00.txt>
The EP2 cipher is a block cipher that is useful in many cryptographic
applications. It is believed to be interoperable with the RC2 cipher
froim RSA Data Security, In., which has been specified for use in many
Internet Protocols.
"Virtual Server Protocol", I. Jeyasubramanian, 06/16/1997,
<draft-jeya-virtual-server-00.txt>
This document specifies a protocol termed the 'Virtual server
protocol', which makes an end-user automatically connect to a least
loaded Server among the list of Mirror/alternate Servers available for
a particular Service, advertised in the Internet.
Using this protocol, the clients accessing the Internet no longer need
to know the existence of mirror servers available for a particular
service.
"Internet Security Label (ISL)", T. Bartee, N. Alvarez, C. Nunley,
06/23/1997, <draft-tbnadn-sec-label-00.txt>
This document describes the Internet Security Label (ISL). ISL
provides a mechanism for encoding security (sensitivity) parameters.
The ISL is intended to be a layer-independent security mechanism. It
can be used with all current versions of the Internet Protocol (IP),
including IPv4 and IPv6 as well as the IP Security Protocols (IPSEC),
the encapsulating Security Payload (ESP) and the Authentication Header
(AH). Other protocols which use a security label can also use the ISL
encoding standard including IPX.
"Application Protocol Design Principles", C Newman, 07/29/1997,
<draft-newman-protocol-design-01.txt>
There are a number of design principles which come into play over
and over again when designing application protocols. Many of
these
are entrenched in IETF lore and spread by word of mouth. Most
have
been learned the hard way many times.
This is an attempt to codify some of these principles so they can
be referenced rather than spread by word of mouth. The author has
not invented any of these ideas and while the exercise of finding
the originator of the ideas would be interesting, it is not deemed
necessary for this project.
Many of these principles have a much wider scope than application
protocol design. However, the author's primary experience is with
application protocols and examples provided usually involve
application protocols or elements.
[Disclaimer: this is a preliminary draft. Some of the case
studies
and exceptions need tuning. Suggestions welcome.]
"IETF Policy on Character Sets and Languages", Harald Alvestrand,
10/21/1997, <draft-alvestrand-charset-policy-02.txt>
The Internet is international.
With the international Internet follows an absolute requirement to
interchange data in a multiplicity of languages, which in turn
utilize a bewildering number of characters.
This document is (INTENDED TO BE) the current policies being
applied by the Internet Engineering Steering Group towards the
standardization efforts in the Internet Engineering Task Force in
order to help Internet protocols fulfil these requirements.
The document is very much based upon the recommendations of the
IAB Character Set Workshop of February 29-March 1, 1996, which is
documented in RFC 2130 [WR]. This document attempts to be concise,
explicit and clear; people wanting more background are encouraged
to read RFC 2130.
The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their
negatives, in the way described in [RFC 2119]. In this case,
"PACE(TM) Technology's Ethernet Interactive Access Algorithm", J. Hickey,
06/24/1997, <draft-rfced-info-hickey-00.txt>
PACE technology is designed to provide backwards-compatible
modifications to Ethernet to support multimedia applications. PACE
Technology's Ethernet Interactive Access [1] uses a modified 802.3 MAC
access algorithm to minimise access latency when communicating to
standard 802.3 MAC devices. This access algorithm is documented here
via pseudo code in a manner similar to the 802.3 MAC standard.
"A Description of the RC2(r) Encryption Algorithm", R. Rivest,
06/24/1997, <draft-rivest-rc2desc-00.txt>
This draft is an RSA Laboratories Technical Note. It is meant for
informational use by the Internet community.
This memo describes a conventional (secret-key) block encryption
algorithm, called RC2, which may be considered as a proposal for a DES
replacement. The input and output block sizes are 64 bits each. The key
size is variable, from one byte up to 128 bytes, although the current
implementation uses eight bytes.
The algorithm is designed to be easy to implement on 16-bit
microprocessors. On an IBM AT, the encryption runs about twice as fast
as DES (assuming that key expansion has been done).
"PPP/IPCP Extension for Word Alignment of IP Datagrams", P. Martin,
07/01/1997, <draft-rfced-info-martin-00.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. The
PPP/IPCP extension for 32 bit Alignment of IP datagrams provides a
method to negotiate and align IP datagrams on a 32 bit boundary. This
document describes the use of the Internet Protocol Control Protocol
(IPCP) [2] option and the PPP framing that is required for alignment of
all IP datagrams.
"Analysis of Services and Interfaces used when Interworking Between the
Internet and the Intelligent Network (I.N.)", R. Scholl, 07/03/1997,
<draft-conroy-interfaces-in-net-00.txt>
The plethora of networks comprising the Internet have been getting
bigger and faster in the past at a tremendous rate. In the future, to
address all of the current and future pervasive services, the Internet
will also have to get better, i.e. it will need more intelligence
created by clever software deployed throughout the network.
This Internet Draft advances the discussion on the issues involved in
interconnecting the Internet and Public Switched Telephone Networks
(PSTNs), focusing on potential interfaces between Internet-based
devices and Intelligent Network (I.N.) devices.
Services based on the interplay of PSTN / I.N. and the Internet are
discussed and classified, and an outline of a protocol architecture for
the interface between the Internet and the Intelligent Network is
given.
"Advise on the implementation of In-Reply-To, References and Supersedes
e-mail and netnews headers", J. Palme, 07/07/1997,
<draft-palme-newfields-info-00.txt>
Separate Internets standards documents define the e-mail headers
In-Reply-To, References, Supersedes and Expires. This document, which
is an informational RFC, gives some advise on the implementation of
these features.
"Transaction Internet Protocol - Requirements and Supplemental
Information", Jim Lyon, J. Klein, Keith Evans, 10/21/1997,
<draft-evans-tip-functions-02.txt>
This document describes the purpose (usage scenarios), and
requirements for the Transaction Internet Protocol [1]. It is
intended to help qualify the necessary features and functions of
the protocol. It also provides supplemental information to aid
understanding and facilitate implementation of the TIP protocol.
"Telnet Remote Serial Port (RSP) Option", R. Barnes, M. Bennett,
09/10/1997, <draft-barnes-telnet-rsp-opt-01.txt>
Many (if not all) terminal servers support the ability to set up a
telnet listener on a serial port. This allows a connection to a
port
to be made via the network, however only (two way) data can be
transferred between the client and the port.
By using the Remote Serial Port (RSP) telnet option, the client is
able to control non-data aspects of the port such as baud rate and
modem signals. This is especially important where the port is
attached to a modem and modem signals are required to hangup the
modem.
This document defines a simple protocol which allows terminal
servers
(and other systems which provide access to serial ports via a
network
connection) to provide access to these features.
"Cache Array Routing Protocol v1.1", K. Ross, V. Valloppillil,
10/20/1997, <draft-vinod-carp-v1-02.txt>
The Cache Array Routing Protocol describes a distributed caching
protocol based on
1) a known membership list of loosely coupled proxies and
2) a hash function for dividing URL space among those proxies
The Proxy Array Membership Table is defined as a plain ASCII text file
retrieved from an Array Configuration URL. This document does NOT
describe how this table is constructed, merely the format of the fields
used by agents implementing.
"Key Exchange Delegation Record for the DNS", Ran Atkinson, 07/22/1997,
<draft-rfced-info-atkinson-01.txt>
This note describes a mechanism whereby authorisation for one node to
act as key exchanger for a second node is delegated and made available
via the Secure DNS. This mechanism is intended to be used only with
the Secure DNS. It can be used with several security services. For
example, a system seeking to use IP Security [Atk95a, Atk95b, Atk95c]
to protect IP packets for a given destination can use this mechanism to
determine the set of authorised remote key exchanger systems for that
destination.
"The Compressed Payload Header", M. Thomas, 07/10/1997,
<draft-thomas-ippcp-compression-00.txt>
This doucment defines the Compressed Payload Header. The Compressed
Payload Header encapsulates payloads (TCP header and data for instance)
which have been compressed for traversal of the network. The
Compressed Payload Header is generally used in conjunction with the IP
Security Headers.
"IPSOFACTO: IP Switching Over Fast ATM Cell Transport", A. Acharya,
07/11/1997, <draft-acharya-ipsw-fast-cell-00.txt>
This document describes a method for mapping IP flows to ATM switches.
No signaling is necessary to setup a path through ATM switches. Switch
controllers run a IP routing protocol and execute IP forwarding. The
Ipsofacto component is responsible for mapping a IP flow to a switched
path. The focus of this document is primarily on switching IP
multicast. Mechanisms for switching unicast flows are also described.
"Internet Technology for Integration of Carrier Network Management (TMN)
and Enterprise Network Management", G. Bogler, 07/11/1997,
<draft-bogler-tmn-internet-00.txt>
The complexity of telecommunication networks, i.e. enterprise and
carrier networks, has grown over the last two decades. Management of
carrier networks and enterprise networks has followed different
paradigms up to now:
- In carrier networks the Telecommunications Management Network (TMN)
as created by ITU-T in the early 1980s is still being propagated.
- In enterprise networks the SNMP based approach is widely accepted.
The borders between public (carrier) and private (enterprise) networks
are becoming increasingly transparent, a distinction between both types
of networks may soon be irrelevant from a network management point of
view.
"Key Management for Multicast: Issues and Architectures", D. Wallner, E.
Harder, R. Agee, 07/11/1997, <draft-wallner-key-arch-00.txt>
This report contains a discussion of the difficult problem of key
management for multicast communication sessions. It focuses on two
main areas of concern with respect to key management, which are,
initializing the multicast group with a common net key and rekeying the
multicast group. A rekey may be necessary upon the compromise of a
user or for other reasons (e.g., periodic rekey). In particular, this
report identifies a technique which allows for secure compromise
recovery, while also being robust against collusion of excluded users.
This is one important feature of multicast key management which has not
been addressed in detail by most other multicast key management
proposals [1,2,4]. The benefits of this proposed technique are that it
minimizes the number of transmissions required to rekey the multicast
group and it imposes minimal storage requirements on the multicast
group.
"The Site Installation Handbook", J. Walker, 07/11/1997,
<draft-rfced-info-walker-00.txt>
This memo is a first attempt at providing guidance on how to deal with
the perplexity of new LAN and WAN site installs. Experienced and less
experienced network engineers often do each installation blindly
without any form or fashion. This document is an attempt to document
specific install issues, practices and procedures. It is also intended
to be a future installation reference handbook. Please email me with
any comments or additional items that may have been overlooked.
Hopefully you will see this as a starting point to collect data for the
site installation that you are completing.
"HTTP/1.1 Message Digest Attribute Request", Ari Luotonen, 07/14/1997,
<draft-lawrence-digest-request-00.txt>
This memo describes a security weakness in the current Proposed
Standard for HTTP Digest Access Authentication, and proposes a change
to that scheme to correct the deficiency. The problem is that there is
no mechanism for either party to indicate a requirement that messages
be sent with an authentication digest.
"IP Multicast over ATM MLIS using ATM Multicast Routers", N. Ishikawa,
07/15/1997, <draft-ishikawa-ion-mcatm-mlis-00.txt>
This memo describes the specification for IP multicast over ATM MLIS
using ATM multicast routers. This memo specifies the protocol for
providing the functions of IGMP [1] over the ATM networks. This is the
simplest approach among various proposals for IP multicast over the ATM
networks including MARS [2], and it is easy to implement this
specification compared with other proposals.
"IP Multicast Routing over ATM", N. Ishikawa, 07/15/1997,
<draft-ishikawa-ion-mcatm-routing-00.txt>
This memo describes the specification for IP multicast routing over
ATM. This memo specifies the architecture and the protocol for scalable
IP multicast routing over ATM, based on the shared tree architecture.
Multicast shortcuts over ATM are possible in an efficient and scalable
manner. The same messages as specified for IP multicasting over ATM
MLIS [1] are applied for IP multicast routing over ATM, with some
extensions.
"Open Software Distribution Methods", R. Meier, 07/16/1997,
<draft-meier-instructions-00.txt>
This document provides a common framework for the coordination of
standards employed in software distribution. Software distribution is
divided into consecutive steps that encapsulate the procedures
necessary to ensure interoperability.
"Path MTU discovery in the presence of security gateways", M. Richardson,
07/16/1997, <draft-richardson-ipsec-pmtu-discov-00.txt>
This document describes the problem of getting accurate Path MTU
information in the presence of untrusted routers. Typical Path MTU
discovery is done by sending packets with the don't fragment bit set,
and listening for ICMP messages from routers that want to fragment the
packets. Unfortunately, these messages could be forged, and IPsec
based security system(s) can not pass make direct use of these
messages. An alternate, backwards compatible algorithm is suggested.
"Why traceroute can not work through IPsec gateways", M. Richardson,
07/16/1997, <draft-richardson-ipsec-icmp-filter-00.txt>
This document describes the problem of doing diagnostics through IPsec
gateways (VPNs). If the gateways implement their policies to the
letter, then diagnostics are not possible.
"NNTP Generic Data Extensions", B. Hernacki, 07/17/1997,
<draft-hernacki-nntpget-00.txt>
This document describes a set of enhancements to the Network News
Transport Protocol [NNTP-977] that provide a generic mechanism by
which clients and servers can exchange configuration information. It
was originally designed as a method by which an NNTP client could
request URLs from the server in order to access out-of-band
information. It is not however limited to URLs and may be used to
communicate such things as language settings, client prefences,
formatting information, etc. The protocol additions are designed in
a manner which allows the client and server to exchange key/data pairs
of arbitrary text strings.
"Capabilities Negotiation with BGP-4", J. Scudder, R. Chandra,
07/17/1997, <draft-chandra-bgp4-cap-neg-00.txt>
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
OPEN message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of
new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities, that
is expected to facilitate introduction of new capabilities in BGP by
providing graceful capability negotiation.
The proposed parameter is backward compatible - a router that supports
the parameter can maintain BGP peering with a router that doesn't
support the parameter.
"LDAP Object Class for Application Users", B. Greenblatt, 07/21/1997,
<draft-greenblatt-ldap-applusers-00.txt>
In working with various directory enabled applications and services, it
has been noticed that several of them presume the existence of an
auxiliary object class with no attributes that is used to detect
'their' users. For example, the foo application service will use the
fooUser object class, and attach this object class to all of its user
objects in the directory in order that it may later on easily detect
'its' users, by virtue of the fact that those users are members of the
fooUser object class. This fooUser object class is a subclass of top
with no additional attributes. This specification intends to head off
the day when a user would get one of these applicationUser object class
things attached to its directory object for each application that it
uses. This would mean that that object's object class attribute would
eventually have dozens of values, which would in turn lessen the value
of this attribute.
"Guidelines for Next Hop Client (NHC) developers", L. Winkler, R.
Carlson, 07/23/1997, <draft-carlson-nhrp-00.txt>
This document provides guidelines for developers of ATM attached host
implementations of the Next Hop Resolution Protocol Client (NHC)
protocol. The intent is to define the interaction between the NHC code
and the TCP/IP protocol stack of the local operating system. The NHC
is capable of sending NHRP requests to a Next Hop Resolution Protocol
Server (NHS) to resolve both inter and intra LIS addresses. The NHS
reply may be positive (ACK) indicating a short-cut path is available or
negative (NAK) indicating that a shortcut is not available and the
routed path must be used. The NHC must cache (maintain state) for both
the ACK and NAK replies in order to use the correct short-cut or routed
path. The NAK reply must be cached to avoid making repeated requests
to the NHS when the routed path is being used.
"IMSS: IP Multicast Shortcut Service", T. Anker, D. Breitgand, D. Dolev,
Z. Levy, 07/23/1997, <draft-anker-congress-00.txt>
This memo describes an IP Multicast Shortcut Service (IMSS) over a
large ATM cloud. The service enables cut-through routing between
routers serving different Logical IP Subnets (LISs). The presented
solution is complementary to MARS [2], adopted as the IETF standard
solution for IP multicast over ATM.
IMSS consists of two orthogonal components: CONnection-oriented Group
address RESolution Service (CONGRESS) and IP multicast SErvice for
Non-broadcast Access Networking TEchnology (IP-SENATE). An IP class D
address is resolved into a set of addresses of multicast routers that
should receive the multicast traffic targeted to this class D address.
This task is accomplished using CONGRESS. The cut-through routing
decisions and actual data transmission are performed by IP-SENATE.
IMSS preserves the classical LIS model [8]. The scope of IMSS is to
facilitate inter-LIS cut-through routing, while MARS provides tools for
the intra-LIS IP multicast.
"Dynamic Tunneling Path Configuration for Uni-directional Link Routing",
A. Tosaka, H. Izumiyama, 07/23/1997, <draft-izumiyama-udlr-dtpc-00.txt>
The idea to use unidirectional link(UDL) routing without any
modifications of current routing protocols is described in [1], but any
dynamic tunneling path configuration technique was not described. This
document describe the dynamic tunneling path configuration for UDL
routing.
"An IP tunneling approach for Uni-directional Link routing", A. Kato, A.
Tosaka, H. Izumiyama, 07/23/1997, <draft-izumiyama-udlr-tunnel-00.txt>
Since digital multichannel TV broadcasting services have been started
in many areas, low cost digital data receivers are available. They can
be used for not only TV broadcasting service but also any kind of data
communication services.
A low cost receiver can receive high bandwidth traffic from a feed,
while no bandwidth from the receiver to the feed is provided.
Therefore the connection between the feed and the receiver is
unidirectional. Current routing protocols stand on a fact that any
links are bidirectional even if the bandwidth in each direction may be
different. They can not handle unidirectional links.
This document defines an idea to use unidirectional links (UDLs)
routing without any modifications of current routing protocols.
"SOCKS V5 UDP and Multicast Extensions", D. Chouinard, 07/24/1997,
<draft-chouinard-aft-socksv5-mult-00.txt>
This proposal describes extensions to the SOCKS v5 protocol [RFC-1928]
that make it more useful for networked-multimedia applications that use
UDP and multicast services. The extensions are broken into two parts:
Base-level UDP extensions, and Multicast UDP extensions.
The Base-level UDP extensions augment SOCKS V5 by addressing current
deficiencies in [RFC-1928] (such as supporting multihomed-SOCKS servers
and properly supporting fragmentation) and by adding several
performance enhancements, including the ability to control multiple UDP
associations over a single SOCKS TCP control connection.
The Multicast extensions build on the foundation provided by the
base-level UDP extensions, and allow a Multicast-capable SOCKS Client
(MSC) to send and/or receive datagrams to/from one or more multicast
groups through a Multicast-capable SOCKS Server (MSS). These protocol
extensions effectively enable the MSS to become a generic multicast
proxy server -- allowing it to enforce security policies relating to
who can send multicast traffic out, or bring multicast traffic into, an
organization.
"ESP with Cipher Block CheckSums (CBCS)", W. Simpson, 07/24/1997,
<draft-simpson-ipsec-cbcs-00.txt>
This document describes the Cipher Block Chaining mode with additional
single or double parallel CheckSums for integrity, used with a number
of Internet Encapsulating Security Payload (ESP) transforms. This
version is described in terms of 64-bit block ciphers, but can be
expanded to other block sizes.
"Guidelines for Writing RFC Text on Security Considerations", Ran
Atkinson, 07/25/1997, <draft-iab-secwks-sec-guidelines-00.txt>
The 'Security Considerations' section of an RFC is a mechanism via
which the authors/editors of an RFC communicate to the reader the
security issues (including threats) of the RFC topic and discuss
mechanisms for mitigating or eliminating those threats. Each risk
reduction mechanism not documented directly in that RFC should cite
another RFC or document which describes the risk reduction mechanism.
"Proposal for SPKI Certificate Formats and Semantics", T. Ylonen,
07/25/1997, <draft-ylonen-spki-binary-00.txt>
This document is a proposal for certificate formats and their semantics
in SPKI. This proposal it is not based on S-expressions.
"Synchronous IP Switching Protocol", I. Jeyasubramanian, 07/25/1997,
<draft-jeya-sync-ip-switch-00.txt>
The 'Synchronous IP Switching' protocol provides a framework for
synchronous communication among end stations through an ethernet
switch. This proposal enhances the capability of an ethernet switch to
forward the packets from a variety of real time applications in a
synchronous manner with less delay variations and consistent throughput
by introducing the concept of 'Time Switch'. This protocol proves its
importance, as more and more applications need constant delay,
effective bandwidth while forwarding their packets to their
destination.
"Information Exchange to Be Supported by the Service Support Transfer
Protocol (SSTP)", H. Lu, M. Krishnaswamy, 07/28/1997,
<draft-krishna-telephone-sw-net-00.txt>
This Internet Draft outlines the information to be carried by the
Service Support Transfer Protocol (SSTP) running on top of a reliable
transport layer (such as TCP). The SSTP is for interconnection between
the Internet and the Public Switched Telephone Network (PSTN),
specifically, involving Web Server in the former; and Service Node (SN)
or Service Control Point (SCP), and Service Management System (SMS) [1]
in the latter. It is to support a combination of services provided
otherwise disjointly by either of the network types. Service examples
are those integrating the traditional telephony services on the PSTN
and the World Wide Web-based services on the Internet like
click-to-dial, click-to-fax, click-to-fax-back, and
voice-access-to-content.
"Directory Schema Listing Requirements", Chris Apple, 10/13/1997,
<draft-apple-schema-rqmts-list-02.txt>
This memo documents requirements for listing directory services
schemas in a centrally operated, administered, and maintained
repository. This repository will be available as a resource to
directory protocol and service implementors to facilitate schema
discovery.
"Internet Email Subaddressing", C Newman, 07/29/1997,
<draft-newman-email-subaddr-00.txt>
It is often useful for a single user to have multiple email
addresses which can be used to assist categorizing incoming email.
One way of doing this is to divide the local-part of an email
address into a primary address and a subaddress. The primary
address is used to route the message within the specified domain
and the subaddress is used to route the message according to a
particular user's wishes.
This specification formalizes the de-facto standard for
subaddressing in use today and includes advice and requirements
for
final delivery agents, MUAs and mail list servers which wish to
support subaddressing.
"RTP Payload Format for BT.656-3 Encoding", Dermot Tynan, 07/30/1997,
<draft-tynan-rtp-bt656-00.txt>
This document specifies the RTP payload format for
encapsulating ITU Recommendation BT.656-3 video streams in
the
Real-Time Transport Protocol (RTP). Each RTP packet contains
one scan line as defined by ITU Recommendation BT.601-5, and
includes decoding and positioning information.
"End-to-End Traffic Management Issues in IP/ATM Internetworks", Nanying
Yin, Shantigram Jagannath, 07/30/1997, <draft-jagan-e2e-traf-mgmt-00.txt>
This document addresses the end-to-end traffic management issues in
IP/ATM internetworks. In the internetwork environment, the ATM
control mechanisms (e.g., Available Bit Rate (ABR) and UBR with
Early
Packet Discard (EPD)) are applicable to the ATM subnetwork, while
the
TCP flow control extends from end to end. We investigated the end to
end performance in terms of TCP throughput and file transfer delay
in
cases using ABR and UBR in the ATM subnetwork. In this document, we
also discuss the issue of trade-off between the buffer requirements
at the ATM edge device (e.g., Ethernet-ATM switch, ATM router
interface) versus ATM switches inside the ATM network.
Our simulation results show that in certain scenarios (e.g., with
limited edge device buffer memory) UBR with EPD may perform
comparably to ABR or even outperform ABR. We show that it is not
sufficient to have a lossless ATM subnetwork from the end-to-end
performance point of view. The results illustrate the necessity for
an edge device congestion handling mechanism that can couple the ABR
and TCP feedback control loops. We present an algorithm that makes
use of the ABR feedback information and edge device congestion state
to make packet dropping decisions at the edge of the ATM network.
Using the algorithm at the edge device, the end-to-end performance
in
throughput and delay are improved while using ABR as the ATM
subnetwork technology and with small buffers in the edge device.
"ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering",
C. Partridge, 07/30/1997, <draft-partridge-e2e-ackspacing-00.txt>
Suppose you want TCP implementations to be able to fill a 155 Mb/s
path. Further suppose that the path includes a satellite in a
geosynchronous orbit, so the round trip delay through the path is at
least 500 ms, and the delay-bandwidth product is 9.7 megabytes or
more.
If we further assume the TCP implementations support TCP Large
Windows and PAWS (many do), so they can manage 9.7 MB TCP window,
then we can be sure the TCP will eventually start sending at full
path rate (unless the satellite channel is very lossy). But it may
take a long time to get the TCP up to full speed.
"HTTP X-Connfrom header", J Mogul, P. Leach, Larry Harada, Hudson
Hendren, 09/15/1997, <draft-harada-http-xconnfrom-01.txt>
HTTP/1.1 defines a Connection header, allowing 'the sender
to specify options that are desired for that particular
connection and MUST NOT be communicated by proxies over
further connections.' Because HTTP/1.0 proxies would
normally forward the Connection header without obeying its
specification, a Connection header received in an HTTP/1.0
message must normally be treated as if it had been
forwarded in error. This document defines an X-Connfrom
header that identifies the sending host, and so is safe to
use in HTTP/1.0 messages. This might be useful in
experimenting with HTTP/1.0 implementations of applications
of the HTTP/1.1 Connection mechanism.
"Scalability Issues in Label Switching over ATM", G. Armitage, Zheng
Wang, 07/30/1997, <draft-wang-mpls-scaling-atm-00.txt>
The scalability of label switching over ATM is one of fundamental
issues in MPLS that has not been fully understood. Whether or not
one
should assume stream merging in ATM is a major design decision that
has many implications to MPLS protocols and ATM hardware design.
"Handling Internationalized Query Components in URLs", M. Duerst,
07/30/1997, <draft-duerst-query-i18n-00.txt>
HTTP and HTML provide the facility to query the user and return the
results. This is usually done in the query component of an URL. This
mechanisms works with full satisfaction for characters of the us-
ascii repertoire. Due to the lack of an agreed encoding for other
characters, the situation is much less satisfactory for characters
outside the us-ascii repertoire.
"Normalization of Internationalized Identifiers", M. Duerst, 07/30/1997,
<draft-duerst-i18n-norm-00.txt>
The Universal Character Set (UCS) makes it possible to extend the
repertoire of characters used in non-local identifiers beyond US-
ASCII. The UCS contains a large overall number of characters, many
codepoints for backwards compatibility, and various mechanisms to
cope with the features of the writing systems of the world. All this
together can lead to ambiguities in representation. Such ambiguities
are not a problem when representing running text. Therefore existing
standards have only defined equivalences. For the use in identi-
fiers, which are compared using their binary representation, this is
not sufficient. This document defines a normalization algorithm and
gives usage guidelines to avoid such ambiguities.
"DHCP Server Verification by Client Via DNSSEC", O. Gudmundsson, Robert
Watson, 07/30/1997, <draft-watson-dhc-serv-verify-00.txt>
The document defines a mechanism to allow a DHCP client to verify
the authenticity of a DHCP server configuration offer using
DNSSEC. Currently DHCP clients have no way to assess which of
DHCP OFFERS are from valid DHCP servers, and which are not.
Malicious DHCP servers can cause various network problems for
unsuspecting clients.
In order to support DHCP server authorization a new DNS Resource
Record type (ALLOC) is added. Using the ALLOC record in combination
with the servers KEY record the client can authoritatively assess if
the server is authorized.
"Transmission of IPv6 Packets over Frame Relay", A. Conta, Martin
Mueller, 07/30/1997, <draft-conta-ipv6-trans-fr-00.txt>
This memo describes the transmission of IPv6 packets over
Frame Relay, the IPv6 Frame Relay interface token, the IPv6 Frame
Relay link local addresses, the IPv6 Frame Relay link layer
Information formatting for Neighbor Discovery.
"Conversion of MIMEDIR content into XML", A. Hopmann, 07/30/1997,
<draft-hopmann-mimedirxml-00.txt>
This document specifies how to translate information which is
represented in the MIMEDIR format into a representation of the
identical information using the XML syntax. Using this specification,
applications which have been designed to understand MIMEDIR formatted
data should be able to interoperate using XML representations of the
same schemas.
"IPv6 Inverse Neighbor Discovery for IPv6 and IPv4 Tunnels", A. Conta,
07/30/1997, <draft-conta-ipv6-inv-nd-tun-00.txt>
This memo describes an extension mechanism to the IPv6 Neighbor
Discovery and IPv6 Inverse Neighbor Discovery [IND] that applies to
IPv6
and IPv4 tunnels. The mechanism can be used to advertise the
parameters of a tunnel to its exit point node, and to create a reverse
tunnel path between the exit point and entry point nodes of a
unidirectional tunnel. If such a bidirectional tunnel already
exists, the
mechanism can be used to learn the IPv6 address of the tunnel
pseudointerface of the exit-point node, as well as the reverse tunnel
path parameters.
"Error Record (ERR) for DNS", O. Gudmundsson, Robert Watson, 07/30/1997,
<draft-watson-dns-error-00.txt>
The DNS protocol defines a 4-bit RCODE field in the header of the DNS
envelope. This field is used to indicate the completion status of
requests. Defined values exist to describe successful completion as
well as a variety of error conditions that could result from DNS server
operations. As DNS has been expanded to perform additional functions,
the number of possible error conditions has increased significantly,
and the field no longer has space for new error codes to be added. To
address this problem, a new RR type is defined. The Error Record
contains a machine-readable extended error value, as well as an
optional
human-readable ASCII text string. Additionally, it contains a
domain-name source field to identify the entity generating the error
condition.This RR may also be used in non-error conditions to provide
extended information about server responses, such security information
on specific records in the response.
"A Stream Cipher Encryption Algorithm 'Arcfour'", Rodney Thayer, Kalle
Kaukonen, 07/30/1997, <draft-kaukonen-cipher-arcfour-01.txt>
This document describes an algorithm here called Arcfour that
is believed to be fully interoperable with the RC4 algoritm.
RC4 is trademark of RSA Data Security, Inc. There is a need
in the Internet community for an encryption algorithm that
provides interoperable operation with existing deployed
commercial cryptographic applications. This interoperability
will allow for a smoother transition to protocols that have
been developed through the IETF standards process.
"Universal Forms Description Language Specification Version 3.2",,
07/31/1997, <draft-gordon-ufdl-spec-00.txt>
The Universal Forms Description Language (UFDL) describes complex
business forms for use over the Internet. The objective of the UFDL
is to enable the creation of cross-platform Internet business forms
that (1) contain both the complex logic and precise layout that
administrators require, (2) are simple to maintain and distribute,
and (3) integrate easily with existing business systems. As more
and more business is done over the Internet, the need for a form
description language that incorporates these features grows. HTML
is designed for Internet pages, and is severely limited as a form
language. This document specifies the vocabulary, syntax, and
meaning of the UFDL.
"When TCP Starts Up With Four Packets Into Only Three Buffers", C.
Partridge, Timothy Shepard, 08/01/1997,
<draft-shepard-tcp-4-packets-3-buff-00.txt>
Sally Floyd has proposed that TCPs start their initial slow start by
sending as many as four packets (instead of the usual one packet) as
a means of getting TCP up-to-speed faster. (Slow starts instigated
due to timeouts would still start with just one packet.) Starting
with more than one packet might reduce the start-up latency over
long-fat pipes by two round-trip times. This proposal is documented
further in [1] and in [2] and we assume the reader is familiar with
the details of this proposal.
On the end2end-interest mailing list, concern was raised that in the
(allegedly common) case where a slow modem is served by a router
which only allocates three buffers per modem (one buffer being
transmitted while two packets are waiting), that starting with four
packets would not be good because the fourth packet is sure to be
dropped.
Vern Paxson replied with the comment (among other things) that the
four-packet start is no worse than what happens after two round trip
times in normal slow start, hence no new problem is introduced by
starting with as many as four packets. If there is a problem with
a
four-packet start, then the problem already exists in a normal slow-
start startup after two round trip times when the slow-start
algorithm will release into the net four closely spaced packets.
This memo is to document that in the case of a 9600 bps modem at the
edges of a fast Internet where there are only 3 buffers before the
modem (and the fourth packet of a four-packet start will surely be
dropped), no significant degradation in performance is experienced
with a four-packet start when compared with a normal slow start
(which starts with one packet).
"Uniform Resource Locators (URL): DNS URL Naming Scheme", Y. Goland,
07/31/1997, <draft-goland-url-dns-00.txt>
This document proposes mapping DNS names into the URL scheme space for
the purpose of preventing namespace collisions amongst URL schemes
whose syntax and functionality are not appropriate for standardization.
"Universal Forms Description Language Specification Version 3.2", Bill
Manning, 07/31/1997, <draft-ietf-ufdl-spec-00.txt>
The Universal Forms Description Language (UFDL) describes complex
business forms for use over the Internet. The objective of the UFDL
is to enable the creation of cross-platform Internet business forms
that (1) contain both the complex logic and precise layout that
administrators require, (2) are simple to maintain and distribute,
and (3) integrate easily with existing business systems. As more
and more business is done over the Internet, the need for a form
description language that incorporates these features grows. HTML
is designed for Internet pages, and is severely limited as a form
language. This document specifies the vocabulary, syntax, and
meaning of the UFDL.
"DHCP Option for IPv6 Transitions", D. Harrington, 08/01/1997,
<draft-harrington-ngtrans-dhcp-option-00.txt>
This draft introduces a proposed DHCP option which could be helpful
in establishing connectivity between isolated IPv6 hosts and routers
in an IPv4 network. This work is introduced to the NGTrans Working
Group initially, and will also be reviewed in the DHCP Working
Group.
"DHCP Options for Locating LDAP Servers", L. Howard, 08/01/1997,
<draft-hedstrom-dhc-ldap-00.txt>
This document defines a new DHCP option for delivering configuration
information to LDAP (Lightweight Directory Access Protocol) clients.
The information returned is represented as LDAP URLs, as specified
in
the LDAPv3 URL draft[1].
The DHCP client may use the URLs returned by the DHCP server to
locate an LDAP server for the client's network. The URL may include
the TCP port of the LDAP server, and the distinguished name which
identifies the base object for searching.
"IP Encapsulating Security Payload (ESP) for Implementors", W. Simpson,
08/01/1997, <draft-simpson-esp-v2-00.txt>
This document describes a confidentiality mechanism for IP datagrams.
Payload headers are encapsulated within an opaque envelope. Under
some circumstances, authentication and integrity are optionally
provided for IP datagrams.
"Security issues for ION protocols", G. Armitage, 10/13/1997,
<draft-armitage-ion-security-01.txt>
This document aims to assist people attempting to understand the
security limitations of existing ION working group protocols RFC
2022
(MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their
basic control message protocol(s), this document also identifies
common areas amenable to improvement using additional security TLVs.
"Assignment of Status Codes for HTTP and HTTP-Derived Protocols", H.
Schulzrinne, 08/01/1997, <draft-schulzrinne-http-status-00.txt,.ps>
A number of other protocols may make use of HTTP syntax
and facilities; this memo defines a mechanism for IANA to
allocate status codes.
"Support of Shortcuts for RSVP Flows Over ATM", Lou Berger, Vijay
Srinivasan, 08/01/1997, <draft-guerin-issll-rsvp-shortcut-00.txt>
Support for RSVP flows across an ATM network has been defined in
[BB97, GB97, Ber97a]. Although the use of shortcuts was mentioned
in
[BB97, Sec. 3.7], and [Ber97a, Sec. 3.6] the current
specifications
do not address this case in sufficient details so as to allow
interoperable implementations. The purpose of this document is to
identify issues in using ATM shortcuts for RSVP flows. For purposes
of illustrations, the NHRP protocol [LKPC97] will be assumed as
the mechanism used to discover shortcuts, and a possible interface
between RSVP and NHRP will be outlined. However, it should be noted
that other shortcut mechanisms are possible, e.g., PAR [J96], and
the general conclusions of this document should also hold in such
cases. Since the issue of shortcut discovery is significantly more
complex in the multicast case, for which in most instances has not
been defined, e.g., NHRP, this document is limited to the case of
unicast flows.
"Network Security API for Sockets", C. Metz, 08/01/1997,
<draft-metz-net-security-api-00.txt>
This API is a means for sockets applications to request
network
security services from an operating system. It is designed to
move
most of the work and intelligence of security policy processing
into
the operating system so that the burden on application authors
is
light enough to encourage the use of network security.
It is documented here for the benefit of others who might
also
adopt and use the API, thus providing increased portability
of
applications that use network security services (e.g., the
IP
Security ESP and AH protocols).
"Performance Issues in VC-Merge Capable MPLS Switches", Anwar Elwalid,
Indra Widjaja, 08/02/1997, <draft-widjaja-mpls-vc-merge-00.txt>
VC merging allows many routes to be mapped to the same VC label,
thereby providing a scalable mapping method that can support tens of
thousands of edge routers. VC merging requires reassembly buffers so
that cells belonging to different packets intended for the same
destination do not interleave with each other. This document
investigates the impact of VC merging on the additional buffer
required for the reassembly buffers and other buffers. The main
result indicates that VC merging incurs a minimal overhead compared
to non-VC merging in terms of additional buffering. Moreover, the
overhead decreases as utilization increases, or as the traffic
becomes more bursty.
"Transmission of IPv6 Packets over IPv6 and IPv4 Tunnels.", A. Conta,
08/02/1997, <draft-conta-ipv6-trans-tunnel-00.txt>
This memo describes the transmission of IPv6 packets over IPv6
and
IPv4 tunnels, and the IPv6 tunnel link local addresses.
"Portable Node Support Using Mobile IP Protocol", G. Malkin, P. Raison,
N. Kossack, 08/02/1997, <draft-malkin-pnsmip-00.txt>
This document describes an extension to the Mobile IP protocol [1]
which allows portable nodes to tunnel, through a Service Provider's
network, to their home networks without the need to implement any
special code on the portable nodes.
"Increasing TCP's Initial Window", C. Partridge, S. Floyd, M. Allman,
08/02/1997, <draft-floyd-incr-init-win-00.txt>
This is a note to suggest changing the permitted initial window in
TCP from 1 segment to roughly 4K bytes. This draft considers the
advantages and disadvantages of such a changes, as well as
outlining
some experimental results that indicate the costs and benefits of
making such a change to TCP, and pointing out remaining research
questions.
"IPv6 Neighbor Discovery Extensions for Inverse Discovery Specification",
A. Conta, 08/04/1997, <draft-conta-ipv6-nd_ext_ind-00.txt>
This memo describes a mechanism that can be seen as an extension to
the IPv6 Neighbor Discovery. It allows a node to solicit and
be
advertized an IPv6 address corresponding to a given
link-layer
address. Because the known parameter is the link layer address,
the
mechanism is called Inverse Neighbor Discovery. It
specifically
applies to Frame Relay nodes that may have a Data Link
Connection
Identifier (DLCI), the Frame Relay equivalent of a
link-layer
address, associated with an established Permanent Virtual
Circuit
(PVC), but do not know the IPv6 address of the node at the other
end
of the circuit. It may also apply to other networks with
similar
behavior.
"An Approach to Service Allocation in the Internet", David Clark, John
Wroclawski, 08/04/1997, <draft-clark-diff-svc-alloc-00.txt>
This note describes the Service Allocation Profile scheme for
differential service allocation within the Internet. The scheme
is
based on a simple packet drop preference mechanism at interior
nodes, and highly flexible service profiles at edges and inter-
provider boundary points within the net. The service profiles
capture a wide variety of user requirements and expectations, and
allow different users to receive different levels of service from
the network in a scalable and efficient manner.
The note describes the basic form of the mechanism, discusses the
range of services that users and providers can obtain by
employing
it, and gives a more detailed presentation of particular
technical, deployment, standardization, and economic issues
related to its use.
"IP Tunnel MIB", D. Thaler, 08/04/1997, <draft-thaler-tunnel-mib-00.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing tunnels of any type in IP networks, including GRE [5,6], IP-
in-IP [7], Minimal Encapsulation [8], L2TP [9], and PPTP [10] tunnels.
"An Internet Firewall Transparency Requirement", Ned Freed, Kevin
Carosso, 08/21/1997, <draft-freed-firewall-req-00.txt>
This memo defines a basic transparency requirement for
Internet firewalls. While such a requirement may seem
obvious, the fact of the matter is that firewall behavior is
currently either unspecified or underspecified, and problems
often arise in practice. This document is intended to be a
necessary first step in making the behavior of firewalls more
consistent and correct.
"Messages between Email and Netnews", J. Palme, 08/21/1997,
<draft-palme-newsmail-00.txt>
Messages can be transported through gateways between email and netnews.
Combined clients for mail and netnews can submit the same message at
the
same time to email and netnews. Many netnews clients can produce email
replies to the author of netnews articles. This standard specifies how
to handle these kinds of messages. This standard specifies three new
email headers:
"Soft State Switching A Proposal to Extend RSVP for Switching RSVP
Flows", A. Viswanathan, S. Blake, Vijay Srinivasan, 08/25/1997,
<draft-viswanathan-mpls-rsvp-00.txt>
This memo describes a mechanism for establishing a switched path with
guaranteed Quality of Service for RSVP [1] flows in a MultiProtocol
Label Switching (MPLS) environment. It proposes an extension to the
RSVP protocol that allows the establishment of a sequence of label
switched hops along the hop-by-hop routed path by enabling adjacent
nodes to exchange MPLS labels [11]. The labels may correspond to
information that identifies a layer 2 virtual connection; for
example, the VPI/VCI value in the case of an ATM-based
infrastructure.
"PPP for Asynchronous PAD to Synchronous X.25 access", Vimal Khanna,
10/03/1997, <draft-rfced-info-khana-01.txt>
The PPP protocol allows data transfer thru asynchronous or synchronous
connections. But the prevalent Public Switched Data Networks (PSDNs)
support connections between asynchronous and synchronous protocols.
This document defines extensions to the PPP protocol to support
asynchronous PAD to synchronous X.25 protocols on PSDNs.
"End-to-End Throughput and Response Time Testing With HTTP User Agents
and the JavaScript Language", Howard Stanislevic, 08/25/1997,
<draft-rfced-info-stanislevic-00.txt>
This memo describes two simple metrics and a methodology for testing
end-to-end one-way data throughput and two-way response time at the
application layer utilizing HTTP [1] (web) servers and user agents
(web browsers). Two Interactive Hypertext Transfer Test (IHTTT)
implementations are described in detail.
"MAPPING OF AIRLINE TRAFFIC OVER IP", Alain Robert, 08/25/1997,
<draft-rfced-info-robert-00.txt>
This memo specifies a protocol for the encapsulation of the airline
specific protocol over IP.
"Network Address Translation issues with IPsec", Robert Moskowitz,
09/02/1997, <draft-moskowitz-ipsec-vpn-nat-00.txt>
This document looks at a number of issues surrounding the need
for network address translation (NAT) when IPsec is used to
create virtual private networks (NAT). This document only
looks at simple VPNs. That is VPNs consisting of a single
IPsec tunnel as compared to VPNs consisting of chained
and/or nested IPsec tunnels and/or transports.
"Capabilities Exchange over SMTP", N. Joffe, Dan Wing, 08/26/1997,
<draft-Capabilities Exchange over SMTP-00.txt>
This document describes an extension to SMTP [RFC821] which provides a
mechanism for capabilities exchange so the sender knows the
capabilities
of the ultimate recipient or the ESMTP server itself.
"Capabilities Exchange over SMTP", N. Joffe, Dan Wing, 08/26/1997,
<draft-wing-smtp-capabilities-00.txt>
This document describes an extension to SMTP [RFC821] which provides a
mechanism for capabilities exchange so the sender knows the
capabilities
of the ultimate recipient or the ESMTP server itself.
"Tunnel Set-up Protocol (TSP)", G. Montenegro, 08/26/1997,
<draft-montenegro-tsp-00.txt>
Remote access over the internet and IP mobility are currently being
addressed as two separate problems. The L2TP specification is
defining a protocol, or rather a tunnel control mechanism to solve
the remote access problem. On the other hand, the Mobile IP working
group has been solving the mobility problem. Nevertheless, the same
solution applies to both problems, namely, tunneling.
This document defines a Tunnel Set-up Protocol (TSP) that solves
both problems using a common approach. TSP is heavily based on the
control messages defined by Mobile IP.
"Japanese Character Encoding for Internet Messages", Kenzaburo Tamaru,
10/08/1997, <draft-rfced-info-tamaru-01.txt>
This memo defines an encoding scheme for the Japanese Characters,
describes 'ISO-2022-JP', which is used in electronic mail[RFC 822],
and network news [RFC 1036]. Also this memo provides a listing of
the Japanese Character Set that can be used in this encoding
scheme.
"DNS Top Level Domain Name Classification and Structure", Joseph Kim,
08/26/1997, <draft-kim-tld-class-00.txt>
This document specifies a structural organization of Internet top
level domain names based on the International Schedule of Classes
of Goods and Services. This structure intends to provide a
framework for classification such that web content providers can
differentiate their goods and services and minimize the
probability
of name confusion and collision. Under each class, as specified by
the International Schedule of Classes of Goods and Services,
single
or multiple top level domain names should be specified each
appropriately partitioning the class of goods or service into an
appropriate sub-categorization. A method will further be described
to incorporate additions/modifications as becomes necessary by as
of yet unforseen future developments.
This document does not address the delegation or the
administration
of top level domain names which the author feels should be
considered separately. However, the author does acknowledge that
some form of centralized authority should be in place to properly
control the structure to be described.
"URLs for Telephony", Antti Vaha-Sipila, 10/21/1997,
<draft-antti-telephony-url-01.txt>
This document specifies URL (Uniform Resource Locator) schemes
'tel', 'fax' and 'modem' for specifying the location of a terminal
in the phone network and the connection types (modes of operation)
that can be used to connect to that entity. This specification
covers voice calls (normal phone calls, answering machines and
voice messaging systems), facsimile (telefax) calls and data
calls, both for POTS and digital/mobile subscribers.
"Protecting IMAP4 and POP3 Connections", C Newman, 08/28/1997,
<draft-newman-tls-imappop-00.txt>
The TLS protocol [TLS] (formerly known as SSL) provides a way to
secure a connection from tampering and evesdropping. Obviously,
such security is desirable for IMAP [IMAP4] and POP [POP3].
Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH]
can provide this service with less complexity than TLS, TLS is
useful in combination with plaintext password logins and other
simple mechanisms as it doesn't require a site to upgrade its
authentication database.
"Responder-Initiated Shortcut Path Protocol (RISP)", Y. Chen, J. Ogawa,
08/28/1997, <draft-ogawa-responder-shortcut-path-00.txt>
This memo describes a peer-to-peer protocol to set up shortcut
paths in an environment where an internetworking (L3) protocol,
such as IP, overlays a link-layer (L2) protocol such as ATM. In
such a network, L3 routing is the default mechanism for data
transfer but it is also possible to set up direct L2 paths such as
ATM VCs, that bypass L3 routing, so as to expedite the transfer of
data. The protocol described in this memo can be applied as an
inter-LIS (Logical IP Subnetwork) shortcut protocol when an L2
subnetwork is configured into multiple LISs. It can also be used
as an independent protocol to set up direct L2 paths. In this
way,
it operates without L2 address resolution servers and allows the
use of conventional routers (those without address resolution
function) in the network. Therefore, it is useful for networks
that
have no available L2 address resolution service.
"SPKI: ShrinkWrap", W. Simpson, Angelos Keromytis, 09/19/1997,
<draft-simpson-spki-shrinkwrap-01.txt>
This protocol facilitates the use of Simple Public Key Infrastructure
[SPKI] certificate chains with Internet Protocol Security key
management protocols.
"Mobile Network Computing Protocol (MNCP)", David Piscitello, Lisa
Phifer, R. Hovey, Yangwei Wang, 08/29/1997,
<draft-piscitello-mncp-00.txt>
This memo documents an architecture and protocol for mobile network
computing. The protocol described herein provides session control and
reliable delivery services to accommodate mobile client access to
internetworked applications within a 'client-agent-server'
architecture. Client middleware based on this architecture can operate
over wireless data networking services such as RAM, ARDIS, CDPD, PCS
data services and wireless local area networks. This client middleware
can be implemented using any standard application programming interface
to a commercial UDP/IP stack on Hand-held PC's (HPC), personal digital
assistants (PDA's), four-line browsers or 'smart' phones as well as
laptop and desktop computers.
"Hobbes' Internet Timeline", Robert Zakon, 10/07/1997,
<draft-rfced-info-hobbes-01.txt>
This document presents a history of the Internet in timeline
fashion, highlighting some of the key events and technologies
which
helped shape the Internet as we know it today. A growth summary
of the Internet and some associated technologies is also included.
"ElGamal Profile for X.509 Certificates", Peter Gutmann, 08/29/1997,
<draft-rfced-info-pgutmann-00.txt>
This document describes the ASN.1 encoding for an X.509 certificate
profiled for use with the ElGamal public key cryptosystem [1]. It is
intended to provide guidelines for those developing software that will
be used to issue and use ElGamal certificates, and to ensure that
ElGamal certificate and key information will be handled consistently
throughout the public key infrastructure.
"Reliable Multicast Transport Protocol Version 2", N. Yamanouchi, T.
Shiroshita, T. Sano, O. Takahashi, 08/29/1997,
<draft-shiroshita-rmtpv2-00.txt>
This draft presents the specifications of the 'Reliable Multicast
Transport Protocol Version 2,' which is to be used for information
delivery such as newspaper delivery and software updates.
The protocol aims to realize the completely reliable multicast
distribution of bulk data from a server to thousands of receivers.
Version 2 added new functions of information access control, rate
flow control, and suspending resume.
"Short Port Commands for FTP", C. Metz, 09/02/1997,
<draft-metz-sport-00.txt>
RFC 1639[Pis94] documents experimental long port (LPRT) and
long
passive (LPSV) commands that many IP Version 6 implementations
are
using as the replacement for the PORT and PASV commands in
FTP
[PR85]. The author believes that this is the incorrect direction
to
be heading and that the replacement for PORT and PASV should
carry
less information instead of more.
The short port command (SPORT) and short passive command (SPASV)
are replacements for the PORT and PASV commands, respectively.
The
short commands only carry port numbers and do not carry
addresses.
This makes them usable with IPv4 and IPv6. A benefit of not
carrying
addresses is that pure network address translators (NAT) do not
have
to do a search-and-replace on the TCP stream, which is an
expensive
operation. This also precludes three-way FTP, which is a rarely
used
mode of operation that leaves most existing FTP servers wide open
to
the FTP Bounce Attack [Hob95].
The short port and passive commands are implemented in the
NRL
IPv6+IPsec software distribution and the descendant
inet6-apps distribution.
"P_Mul: An Application Protocol for the Transfer of Messages over
Multicast Subnetworks and under EMCON Restrictions", Ken Copeland,
09/03/1997, <draft-riechmann-multicast-mail-00.txt>
P_Mul is a proposal for an application protocol for the transfer of
messages using a connectionless transport protocol. The objectives
of
this protocol are first to take advantage of the bandwidth saving
feature of using the multicast service as supported by modern
computer networks and second to allow message transfer under EMCON
conditions. EMCON (Emission Control) means that, although receiving
nodes are able to receive messages, they are not able to acknowledge
the receipt of messages.
The protocol described below has already been applied to the
transfer
of messages between X.400 Message Transfer Agents (MTA). But it is
not only restricted to this application and can easily be applied to
the transfer of RFC822 messages.
"Test Cases for HMAC-RIPEMD160 and HMAC-RIPEMD128", Justin Kapp,
09/03/1997, <draft-kapp-test-cases-00.txt>
This document provides two sets of test cases for HMAC-RIPEMD160 and
HMAC-RIPEMD128, respectively. HMAC-RIPEMD160 and HMAC-RIPEMD128 are
two constructs of the HMAC [HMAC] message authentication function
using the RIPEMD-160 and RIPEMD-128 [RIPE] hash functions. The test
cases and results provided in this document are meant to be used as
a
conformance test for HMAC-RIPEMD160 and HMAC-RIPEMD128
implementations.
"IMAP4 Implementation Recommendations", B. Leiba, 10/22/1997,
<draft-leiba-imap-implement-guide-03.txt>
The IMAP4 specification [RFC-2060] describes a rich protocol for use
in building clients and servers for storage, retrieval, and
manipulation of electronic mail. Because the protocol is so rich
and
has so many implementation choices, there are often trade-offs that
must be made and issues that must be considered when designing such
clients and servers. This document attempts to outline these issues
and to make recommendations in order to make the end products as
interoperable as possible.
"Labels for MPLS over LAN Media", Hiroshi Esaki, W. Pace, A. Ghanwani,
Shigeo Matsuzawa, Dick Bussiere, 09/09/1997,
<draft-srinivasan-mpls-lans-label-00.txt>
Multi Protocol Label Switching (MPLS) refers to a forwarding paradigm
for routed networks which combines the speed and simplicity of link
layer switching with the scalability and control of network layer
forwarding. Routers which support MPLS are referred to as Label
Switching Routers (LSRs). MPLS requires the distribution labels
between peer LSRs based on routing and traffic information. These
labels are then carried in packets and are used for making high
speed
forwarding decisions at the routers by eliminating the need for
conventional network layer header processing. This note discusses
the format and encapsulation of labels when using MPLS on LAN media.
"The Use of DES-MAC within ESP and AH", D. Frommer, Sara Bitan,
09/10/1997, <draft-bitan-auth-des-mac-00.txt>
This draft describes the use of the DES-MAC algorithm [Kaufman95] as
an authentication mechanism within the revised IPSEC
Encapsulating
Security Payload [ESP] and the revised IPSEC Authentication Header
[AH]. DES-MAC[Kaufman95] is based on the DES encryption algorithm
[FIPS-46, FIPS-46-1, FIPS-74, FIPS-81].
Further information on the other components necessary for ESP
and AH implementations is provided by [Thayer97a].
"Salted Challenge Response Authentication Mechanism (SCRAM)", C Newman,
10/06/1997, <draft-newman-auth-scram-01.txt>
SCRAM is a simple passphrase-based authentication mechanism
suitable for a wide variety of usage scenarios. It combines the
best properties of CRAM-MD5 [CRAM-MD5] and OTP [OTP] without a
significant increase in complexity.
This document defines the SCRAM-MD5 SASL mechanism [SASL] using
the
MD5 [MD5] and HMAC-MD5 [HMAC] algorithms. It is suitable for use
directly with protocols such as IMAP [IMAP4] and POP [POP3].
"Confirmation of Mail Message Reception", Alexandre Steinberg,
09/10/1997, <draft-rfced-exp-steinberg-00.txt>
Currently, Internet SMTP transport does not allow the sender to know
if the recipient receive or open a mail message. This limitation
frequently causes one question: did my message really arrive? This
proposes a simple solution, that could be easy implemented in the
mail software.
"The 'news' URL scheme", Alfred Gilman, 09/10/1997,
<draft-gilman-news-url-00.txt>
This document defines the format of Uniform Resource Locators
(URLs) identifying news messages and groups. The syntax of
'news' URLs from RFC 1738 is extended to allow specification of
the site from which the message is to be sought and to
incorporate protections via 'snews' URLs. This combines into the
'news' scheme enough capability so that the previously-proposed
'nntp' scheme can be retired and URL usage simplified.
"How to find LDAP servers", R. Moats, 09/26/1997,
<draft-moats-finding-01.txt>
This document discusses methods available for LDAP server discovery
and advertisement based on previous IETF and ongoing IETF work.
"Pulse-Per-Second API for UNIX", D. Mills, J Mogul, Jan Brittenson,
09/11/1997, <draft-mogul-pps-api-00.txt>
RFC1589 describes a UNIX kernel implementation model for
high-precision time-keeping. This is meant for use in
conjunction with the Network Time Protocol (NTP, RFC1305),
or similar time synchronization protocols. One aspect of
this model is an accurate interface to the high-accuracy,
one pulse-per-second (PPS) output typically available from
precise time sources (such as a GPS or GOES receiver).
RFC1589 did not define an API for managing the PPS
facility. This document specifies such an API.
"Avoiding the TCP TIME_WAIT state at Busy Servers", J. Touch, Ted Faber,
Wei Yue, 09/11/1997, <draft-faber-time-wait-avoidance-00.txt>
This document describes the problems associated with the
accumulation
of TCP TIME_WAIT states at a network server, such as a web server,
and details two methods for avoiding that accumulation. Servers
that
have many TCP connections in TIME_WAIT state experience performance
degradation, and can collapse. One solution is a TCP modification
that causes clients to enter TIME_WAIT state rather than servers.
The other is an HTTP modification that allows the client to close
the
transport connection, maintaining the TIME_WAIT state at the client.
The goal of both approaches is ensure that TIME_WAIT states accumu-
late at the less loaded endpoint.
The document also presents initial performance data from reference
implementations of these solutions, which suggest that the modifica-
tions improve HTTP connection rates at the server by as much as 50%,
and allow servers to operate at small transaction throughputs that
they cannot sustain their default configuration.
"Extending POP Version 3 To Do Mailbox Compression", Harish Pillay,
Marvin Tay, 09/11/1997, <draft-pillay-pop3-ext-00.txt>
This document suggests an extension to the Post Office Protocol
version 3 (RFC 1725) that adds an extra command to selective
compress the maildrop before transferring the mail to the
recipient.
Given the extensive and explosive growth of mobile uses of the
Internet especially the numbers of people who access their
e-mail
via dialup modems, it does not make sense to have to transfer
e-mail to the client in uncompressed form.
This draft discusses a new command that will make the pop3
server
to intelligently compress the maildrop into a single file and
then for it to be sent to the client. The client will then
process the compressed mail accordingly.
"The SRP Authentication and Key Exchange System", Tom Wu, 09/11/1997,
<draft-wu-srp-auth-00.txt>
This document describes a cryptographically strong network
authentication mechanism known as the Secure Remote Password (SRP)
protocol. This mechanism is suitable for negotiating secure
connections using a user-supplied password, while eliminating the
security problems traditionally associated with reusable passwords.
This system also performs a secure key exchange in the process of
authentication, allowing security layers (privacy and/or integrity
protection) to be enabled during the session. Trusted key servers
and certificate infrastructures are not required, and clients are
not required to store or manage any long-term keys. SRP offers
both security and deployment advantages over existing challenge-
response techniques, making it an ideal drop-in replacement where
secure password authentication is needed.
"INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", M. Crispin,
10/10/1997, <draft-crispin-imapv-02.txt>
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders. IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server (see also [IMAP-DISC]).
IMAP4rev1 includes operations for creating, deleting, and renaming
mailboxes; checking for new messages; permanently removing messages;
setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
searching; and selective fetching of message attributes, texts, and
portions thereof. Messages in IMAP4rev1 are accessed by the use of
numbers. These numbers are either message sequence numbers or
unique
identifiers.
IMAP4rev1 supports a single server. A mechanism for accessing
configuration information to support multiple IMAP4rev1 servers is
discussed in [ACAP].
IMAP4rev1 does not specify a means of posting mail; this function is
handled by a mail transfer protocol such as [SMTP].
IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
unpublished IMAP2bis protocols. In the course of the evolution of
IMAP4rev1, some aspects in the earlier protocol have become
obsolete.
Obsolete commands, responses, and data formats which an IMAP4rev1
implementation can encounter when used with an earlier
implementation
are described in [IMAP-OBSOLETE].
Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest.
"Generation of the Age header field in HTTP/1.1", J Mogul, 09/15/1997,
<draft-mogul-http-age-00.txt>
The 'Age' response-header field in HTTP/1.1 [RFC 2068] is
intended to provide a lower bound of an estimate of a
response message's age (time since generation), by
explicitly indicating the amount of time that is known to
have passed since the response message was retrieved or
revalidated. There has been considerable controversy over
when the Age header field should be added to a response.
This document explains the issues, rebuts a previous
proposal, and provides a set of proposed changes for the
revision of RFC 2068.
"Use of Label Switching With Frame Relay Specification", A. Conta, P.
Doolan, 09/15/1997, <draft-conta-mpls-fr-00.txt>
This document defines the model and generic mechanisms for
Multiprotocol Label Switching on Frame Relay networks. A
Multiprotocol Label Switching Architecture is described in [ARCH].
MPLS enables the use of Frame Relay Switches as Label Switching
Routers (LSRs). The Frame Relay Switches run network layer routing
algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is
based on the results of these routing algorithms. No Frame Relay-
specific routing is needed.
"Internet Protocol Multicast Problem Statement", Scott Bradner,
09/15/1997, <draft-bradner-multicast-problem-00.txt>
This document outlines the evolving requirements for Multicast
functionality within next generation Internet Protocol networks, and
is the product of an ad hoc Internet2 working group meeting held
August 25-27, 1997 hosted by Cisco Systems, Inc. This document is
offered to the IP community for its consideration and comments.
"Internet Protocol Quality of Service Problem Statement", Scott Bradner,
09/15/1997, <draft-bradner-qos-problem-00.txt>
This document outlines the requirements for a Quality of Service
(QoS) function for the Internet Protocol, and is the product of an
ad
hoc Internet 2 working group meeting held August 25-27, 1997 hosted
by Cisco Systems, Inc. This document is offered to the IP community
for its consideration and comments.
This document is organized as follows: Section 1 proposes a simple
classification scheme to describe QoS models. Subsequent sections
discuss requirements for Measurement, Administrative Policy,
Provisioning Issues, Network Environment and Implementation Issues.
"Telnet Authentication: SRP", Tom Wu, 09/18/1997,
<draft-wu-telnet-auth-srp-00.txt>
This document specifies an authentication scheme for the Telnet
protocol under the framework described in RFC 1416, using the
recently proposed SRP authentication mechanism.
"RIDE referencing", David R. Conrad, Wilfried Woeber, David Kessens,
09/19/1997, <draft-kessens-ride-referencing-00.txt>
This document describes two variants of a proposal on how to find
information regarding some critical resources (domain names, IP
addresses and routing registry information) on the Internet. The
proposed solution uses globally unique registry identifiers that are
derived from a domain name in use by a registry.
"RIDE functional requirements", David Kessens, 09/19/1997,
<draft-kessens-ride-requirements-00.txt>
This document describes the (functional) requirements for the RIDE
format and protocols.
"IPv6 over Point-to-Point ATM Link", K. Yamamoto, Yoshinobu Inoue,
Hiroshi Esaki, Yoshifumi Atarashi, Kenjiro Cho, 09/22/1997,
<draft-yamamoto-ipv6-over-p2p-atm-00.txt>
This memo defines a communication mechanism to exchange both IPv6
unicast and multicast packets over an ATM network used as a
point-to-point link.
"Communicating Information for External Program Use in Internet Messages:
The Process Content-Disposition Type", Curtis Whalen, 09/22/1997,
<draft-rfced-exp-whalen-00.txt>
This memo provides a mechanism whereby messages conforming to the
MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC
2049] can convey information not intended for display by the Mail
User Agent (UA), but for processing (as opposed to display) by an
external program. It specifies a new type of 'Content-Disposition'
(defined by [RFC 2183]), which is valid for any MIME entity
('message' or 'body part). When 'body part' is referred to in this
memo, it is referring to any MIME entity, except in section 2.4.
This
memo is the definition of this type, as specified by Section 9 of
[RFC 2183].
This document is intended as an extension to MIME. As such, the
reader is assumed to be familiar with the MIME specifications,
[RFC 822], and [RFC 2183]. The information presented herein
supplements but does not replace that found in those documents.
"VCID: Virtual Connection Identifier", Noritoshi Demizu, Hiroshi Esaki,
K. Nagami, P. Doolan, 10/07/1997, <draft-demizu-mpls-vcid-01.txt>
Several label switching schemes have been proposed to fuse and
integrate the cost-performance and QoS assurance of Layer 2 devices
and the flexibility and functionality of Layer 3 protocols.
Some of these proposals assume that Label Switching Routers (LSRs)
are placed in a homogeneous LSR cloud in a campus area network or a
backbone network, and they are connected directly to each other.
However, this assumption sometimes does not hold true in the real
situation. For example, some campuses will be connected via ATM SVC
service, and LSR networks will be constructed hierarchically.
To deal with Virtual Connections (VCs) in these environments, this
document proposes to identify a VC with a VCID instead of a label.
"Automated Digital Network System Description", Rex Buddenberg,
09/23/1997, <draft-rfced-info-buddenberg-00.txt>
The Navy's Automated Digital Network System (ADNS) provides a means
for ship's to centralize and automate the operation of multiple
independent radio communications systems into an efficient
communications network.
"Using LDAP for SMTP Mailing Lists & Aliases", Bruce Steinback,
09/24/1997, <draft-steinback-ldap-mailgroups-00.txt>
Directory services based on the Lightweight Directory Access
Protocol
(LDAP) [1] and X.500 [2] provide a general-purpose means to store
information about users and other network entities. One such use is
to store information on groups. There are LDAP standards
established
for this purpose, e.g. the groupOfUniqueNames [3]. However,
currently there are no standards for a very important use of Groups,
as SMTP Mailing Lists or Aliases.
This document discusses how we at Netscape have made this extension,
with the intent of providing useful information towards perhaps
creating standards for this important use of LDAP.
"SDP syntax for H.263 options", Petri Koskelainen, 09/26/1997,
<draft-koskelainen-sdp263-00.txt>
This document defines the SDP syntax for H.263 codec options and
parameters for IETF multimedia conferencing architecture. It is often
useful to know beforehand (in call setup phase) what features of H.263
the other end supports. This document specifies the format spefic
parameters for H.263, which exists in a=fmtp:<format> <format specific
parameters> as defined in the SDP document.
Chapters 4 and 5 specify their usage with two popular IETF protocols,
SIP and SAP.
"Mapping Financial Transaction Card Numbers into the Domain Name System",
Don Eastlake, 09/29/1997, <draft-eastlake-card-map-00.txt>
The SET protocol being developed by the VISA and MasterCard
associations and others assumes that a financial transaction
cardholder can locate the appropriate certification authority to
obtain a cardholder certificate. This document proposes a method
using the DNS and, in some cases the referral features of the SET
protocol, to locate such certification authorities and other
financial transaction card related facilities on the Internet by
mapping ISO 7812 derived card numbers into domain names within in
the
card.int domain.
"Use of the IPv4 TOS Octet to Support Differential Services", Juha
Heinanen, 10/02/1997, <draft-heinanen-diff-tos-octet-00.txt>
This document describes how the TOS octet in the IPv4 header can be
used to support differential Internet services. The proposal is
based on the existing format of the TOS octet as defined in [RFC791]
and [RFC1349].
"Two Modes of MPLS Explicit Label Distribution Protocol", Y. Katsube, K.
Nagami, Y. Ohba, 10/06/1997, <draft-katsube-mpls-two-ldp-00.txt>
This memo discusses characteristics of two types of MPLS protocol
operations, which we call 'Edge Control' operation and
'Distributed' operation individually, and proposes that these two
mode of protocol operations should be specified as the explicit
Label Distribution Protocol for the MPLS.
"VC Pool", Noritoshi Demizu, Hiroshi Esaki, K. Nagami, P. Doolan,
10/07/1997, <draft-demizu-mpls-vcpool-00.txt>
Several label switching schemes have been proposed to fuse and
integrate Layer 2 and Layer 3. They can be applied to various
datalinks including intermittent links such as ATM SVC.
Intermittent links require signaling to establish VCs before
employing them and to release VCs after utilizing them. Because
signaling often introduces delays and costs, some kind of
optimization is necessary.
This document proposes to introduce a VC pool to reduce the delays
and the costs of signaling.
"ATM SVC Support for ATM-LSRs", Noritoshi Demizu, Hiroshi Esaki, K.
Nagami, P. Doolan, 10/07/1997, <draft-demizu-mpls-atm-svc-00.txt>
Several label switching schemes have been proposed to fuse and
integrate Layer 2 and Layer 3. ATM Label Switching Router (ATM-LSR)
is one of the major applications of label switching. Some ATM-LSRs
will need to support ATM SVC services, which requires signaling to
establish VCs before employing them and to release VCs after
utilizing them. This document proposes procedures to deal with ATM
SVCs between ATM-LSRs.
"Registration of a Ukrainian Cyrillic Character Set KOI8-RU (as extention
to Russian KOI8-R and ISO-IR-111)", Yuri Demchenko, 10/07/1997,
<draft-rfced-info-demchenko-00.txt>
This document provides information about widely
used in Ukrainian Internet community character set for mail and news
exchange as well as for presentation WWW information resources in
Ukrainian language.
"The Boot Selection Menu Option for BOOTP/DHCP", Bharat Madan,
10/10/1997, <draft-rfced-info-madan-00.txt>
The BOOTP [1] or the Dynamic Host Configuration Protocol (DHCP) [2]
provide a framework for booting a host over a network from a remote
server. This document defines a new option which a BOOTP/DHCP client
may include in its BOOTP request or DHCPDISCOVER message. In their
replies, the recipient servers may include this option along with
the location/path information to a file ('boot.info') in the option
field. The client may use the contents of this file to select the
desired OS with which to boot along with the location/path of the
appropriate boot image file.
"A MIME Directory Profile for LDAP Schema", M. Wahl, 10/13/1997,
<draft-wahl-mime-schema-00.txt>
This document defines a MIME directory profile [1] for holding an
LDAP [2] schema. It is intended for communication with the Internet
schema listing service [3].
"Security issues for the ATMARP protocol", G. Armitage, 10/13/1997,
<draft-armitage-ion-sec-arp-00.txt>
This document discusses some security issues associated with IP over
ATM operation. RFC1577 defines the Classic IP model for sending IP
traffic over ATM. However, security issues were not addressed in the
standard. Since internet is an open architecture, security measures
to protect network integrity are essential for normal operation. The
security loopholes in the current RFC 1577 model are analyzed and
discussed. Possible solutions are proposed.
"HTTP Traffic over Satellite", Robert Pohlmann, 10/14/1997,
<draft-pohlmann-http-traffic-satellite-00.txt>
Internet use over satellites (LEO, MEO and GEO) has not
received enough attention. Satellites have an inherent
broadcasting ability useful for transmitting Internet
traffic. They can send information to many locations
simultaneously depending on the coverage beam of the
satellite. The issue of Internet use over satellites needs
to be addressed so that future implementations of networking
protocols can be used with this medium. The vast majority
of Internet traffic is TCP traffic resulting from the HTTP
protocol so this issue will be addressed here. It is hoped
that this facilitates the transition from the use of
terrestial networks, to networks incorporating satellite
links.
"Identification of messages delivered via both mail and news", J.
Zawinski, 10/14/1997, <draft-zawinski-posted-to-00.txt>
This draft defines a format to be used when delivering a single message
to multiple destinations, where some destinations are newsgroups and
some destinations are email mailboxes.
"Ukrainian Code Page KOI8-U", Roman Tkachuk, 10/14/1997,
<draft-rfced-info-tkachuk-00.txt>
This memo is the specification of the code page, which was
originally
developed for the transmission of texts in the Ukrainian language
through networks, and in particular the networks, employing Unix
operating systems. It is, however, operating-system-neutral, and is
used in various situations, just as its Russian language counterpart
KOI-8R.
With some minor exceptions, this specification can be considered
to be an extension of KOI8-R (RFC-1489). The present edition of the
specification is the result of the wide concensus reached after many
prolonged exchanges and discussions, which took place in Ukraine and
on some Usenet conferences covering Ukraine and read by the public
who employs the Ukrainian language.
"LDAP Schema for Role Based Access Control", Larry Bartz, 10/14/1997,
<draft-bartz-hyperdrive-ldap-rbac-schema-00.txt>
Role Based Access Control (RBAC) is an authorization strategy in
which an entity's permission to access and manipulate targeted
resources is determined by the entity's role or function within a
certain organizational context. RBAC's principal motivation is to
streamline security policy administration. Many discrete authoriza-
tions can be aggregated within a defined role. One or many roles may
be assigned or attributed to individuals. This draft describes LDAP
object classes and attributes which support RBAC. Adoption of this
schema across multiple LDAP implementations will enable RBAC intero-
perability among heterogeneous underlying directory services.
"Directory Schema Listing File Name Syntax", Chris Apple, 10/16/1997,
<draft-apple-schema-file-list-00.txt>
This memo specifies a file name syntax for use by the primary listing
repository operator of the directory schema listing service.
"Access Control Requirements for LDAP", B. Blakley, E. Stokes, Debbie
Byrne, Prasanta Behera, 10/17/1997,
<draft-stokes-ldapext-acl-reqts-00.txt>
This document describes the fundamental requirements of
an access control list (ACL) model for the Lightweight
Directory Application Protocol (LDAP) directory service.
It is intended to be a gathering place for access control
requirements needed to provide authorized access to and
interoperability between directories. The RFC 2119
terminology is used in this document.
"Requirements for Distinguished Names in Autonomous to Loosely-coupled
LDAP-based Directory Services", J. Hodges, 10/21/1997,
<draft-hodges-ldap-dir-dn-reqs-00.txt>
This document analyzes the issues involved in the Distinguished Name-
spaces of autonomous to loosely-coupled, LDAP-based directory services
(LLDSs). It folds in experience learned from the global X.500-based
Dis-
tinguished Name-space, and proposes requirements for the construction
of
Distinguished Names for LLDSs of varying scopes.
"URLs for GSM Short Message Service", Antti Vaha-Sipila, 10/21/1997,
<draft-antti-gsm-sms-url-00.txt>
This document specifies a URL (Uniform Resource Locator) scheme
'gsms' for specifying a recipient for an alphanumeric message
(Short Message) in a GSM-based mobile phone system. Short Messages
are two-way paging messages that can be sent from a suitable
equipped computer or a phone.
"PPP Over SONET Mapping", Jon Anderson, Al White, Demos Kostas, Brent
Allen, 10/23/1997, <draft-allen-pppsonet-mapping-00.txt>
This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and the standards work underway in T1X1 on
SONET.
"One Planet, One Net: Principles for the Internet Era", Nathaniel
Borenstein, Harry Hochheiser, 10/23/1997, <draft-cpsr-one-net-00.txt>
This document presents a suggested set of basic principles
that the authors believe should underlie all future work in
the area of Internet governance. The purpose of this
document is to work towards as broad a consensus as
possible, in the diverse Internet community, about
principles that should inform the way the Internet is
administered for the benefit of all humanity.
The principles have been drafted under the auspices of
Computer Professionals for Social Responsibility, with
several iterations internal to that organization. However,
they are still very much seen as a work in progress.
Comments are solicited from all interested parties. Future
versions will be refined based on these comments and
published as future Internet-Drafts, with a goal of
publication of a finalized version of the declaration as an
Internet RFC in summer, 1998.
All comments on this document are welcome; please send them
to onenet-comments@cpsr.org. Open discussion of this
document is encouraged on the onenet-discuss list, which is
archived at http://www.findmail.com/listsaver/onenet-
discuss.
"Self-Describing Data Representation (SDR)", Colin Low, Jim Randell, Mike
Wray, 10/23/1997, <draft-low-sdr-00.txt>
This document describes a human-readable, textual syntax for
representing self-describing structured data. This representation
was
designed as a transfer syntax for loosely-coupled distributed
applications where one cannot depend on sender(s) and receiver(s)
sharing a schema for exchanged data. The syntax is compact,
expressive, intuitive, and simple to implement.
"''shared-mtrace'': A Multicast 'traceroute' facility for Shared Trees",
Tony Ballardie, 10/27/1997, <draft-ballardie-shared-mtrace-00.txt>
''mtrace'' [1] is a very useful tool for diagnosing IP multicast
rout-
ing problems, such as multicast routing loops and misconfigured mul-
ticast routers, associated with source-rooted RPF-based distribution
trees.
For ''mtrace'' to be useful in a shared tree environment (e.g. PIM
[2],
CBT [3], GUM [4]) its behaviour must be modified. This draft speci-
fies that behaviour, which is sufficiently general to be applicable
to all shared tree types and operating modes. A new ''wildcard''
mode
of behaviour is also described, which allows a trace of a complete
shared tree. Authentication is recommended in this mode because of
its potential as a vehicle for denial of service attacks.
It is intended that this draft become a document of the Mbone
Deploy-
ment (mboned) working group of the IETF. Therefore, comments are
solicited and should be sent to mboned's mailing list <mboned@network-
services.uoregon.edu> and/or the author.
"HARP - ''Home Agent Redundancy Protocol''", Jim Binkley, Bjorn
Chambless, 10/30/1997, <draft-chambless-mobileip-harp-00.txt>
This document presents a protocol called the Home Agent Redundancy
Protocol or HARP. HARP is an optional extension to Mobile-IP [RFC-
2002]. Mobile-IP includes the notion of a Home Agent which is
a host located on the home IP subnet for Mobile Nodes. Home Agents
forward packets to Mobile Nodes that are away from home. Since
Mobile
Nodes are dependent on the Home Agent for connectivity when away
from
home, the Home Agent represents a possible single source of failure
for
the Mobile IP system.
HARP is a protocol which allows a pair (or set) of Home Agents
to cooperate and share Mobile-IP Mobile Node registration
information. If one of the HARP peers should fail, the Mobile-IP
system will not necessarily fail, hence HARP introduces Home
Agent redundancy into the Mobile-IP system. Mobile Nodes are
not aware that HARP exists, so HARP requires no changes to
Mobile-IP as a protocol. In this document, we present the HARP
architecture and protocol.
"Cryptographic Message Syntax", Russ Housley, 10/31/1997,
<draft-housley-smime-cms-00.txt>
This document describes the Cryptographic Message Syntax. This
syntax is used to digitally sign or encrypt arbitrary messages.
The Cryptographic Message Syntax is deriveded from PKCS #7 version
1.5. Wherever possible, backward compatibility is preserved;
however, changes were necessary to accomodate attribute certificate
transfer and key agreement techniques for key management.
Please send comments on this document to the ietf-smime@imc.com mail
list.
"MIME Parameter Value and Encoded Word Extensions: Character Sets,
Languages, and Continuations", Ned Freed, Keith Moore, 10/31/1997,
<draft-freed-pvcsc-new-00.txt>
This memo defines extensions to the RFC 2045 media type and
RFC 2183 disposition parameter value mechanisms to provide
(1) a means to specify parameter values in character sets
other than US-ASCII,
(2) to specify the language to be used should the value be
displayed, and
(3) a continuation mechanism for long parameter values to
avoid problems with header line wrapping.
This memo also defines an extension to the encoded words
defined in RFC 2047 to allow the specification of the language
to be used for display as well as the character set.
"DNS and URL Level Addressing for Public Circuit-Switching Network
Devices", H. Zhu, 10/31/1997, <draft-zhu-dns-url-level-addr-00.txt>
Recently there are a number of efforts [sw1, sw2, in,tpc, etc.] of
trying to
connect the packet-switching network with circuit-switching network,
especially
connecting the Internet with public telephone networks. The first
problem
of such interconnection is naming and addressing, later will come with
directory services and routing problems. This draft concentrates on
naming for DNS and URL. Other problems are discussed in other
documents
[utrpt, framework].
ONC Remote Procedure Call (oncrpc)
----------------------------------
"Authentication Mechanisms for ONC RPC", Steve Nahm, 10/22/1997,
<draft-ietf-oncrpc-auth-04.txt>
This document describes two authentication mechanisms created by Sun
Microsystems that are commonly used in conjunction with the ONC Remote
Procedure Call (ONC RPC Version 2) protocol.
"RPC: Remote Procedure Call Protocol Specification Version 2", R.
Srinivasan, Steve Nahm, 04/22/1997, <draft-ietf-oncrpc-remote-03.txt>
This document describes the ONC Remote Procedure Call (ONC RPC Version
2) protocol as it is currently deployed and accepted. 'ONC' stands for
'Open Network Computing'.
Open Shortest Path First IGP (ospf)
-----------------------------------
"OSPF for IPv6", Rob Coltun, John Moy, D. Ferguson, 03/26/1997,
<draft-ietf-ospf-ospfv6-04.txt>
This document describes the modifications to OSPF to support version 6
of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF
(flooding, DR election, area support, SPF calculations, etc.) remain
unchanged. However, some changes have been necessary, either due to
changes in protocol semantics between IPv4 and IPv6, or simply to
handle the increased address size of IPv6. Changes between OSPF for
IPv4 and this document include the following. Addressing semantics have
been removed from OSPF packets and the basic LSAs. New LSAs have been
created to carry IPv6 addresses and prefixes. OSPF now runs on a
per-link basis, instead of on a per-IP-subnet basis. Flooding scope for
LSAs has been generalized. Authentication has been removed from the
OSPF protocol itself, instead relying on IPv6's Authentication Header
and Encapsulating Security Payload. Most packets in OSPF for IPv6 are
almost as compact as those in OSPF for IPv4, even with the larger IPv6
addresses. Most field- and packet-size limitations present in OSPF for
IPv4 have been relaxed. In addition, option handling has been made
more flexible.
"The OSPF Opaque LSA Option", Rob Coltun, 05/01/1997,
<draft-ietf-ospf-opaque-01.txt>
This memo documents enhancements to the OSPF protocol to support a new
class of link-state advertisements (LSA) called Opaque LSAs. The
Opaque LSA option defines a general mechanism to allow for future
extensibility of OSPF. The information contained in Opaque LSAs may be
used directly by OSPF or by other protocols. Opaque LSAs contain some
number of octets padded to 32-bit alignment. The standard OSPF
link-state database flooding mechanisms are use for distribution of
Opaque LSAs. Opaque LSAs are flooded throughout all or some limited
portion of the OSPF topology.
"OSPF Standardization Report", John Moy, 05/02/1997,
<draft-ietf-ospf-stdreport-02.txt>
This memo documents how the requirements for advancing a routing
protocol to Full Standard, set out in [Ref2], have been met for OSPFv2.
Please send comments to ospf@gated.cornell.edu.
"The OSPF NSSA Option", Rob Coltun, Vince Fuller, P. Murphy, 06/03/1997,
<draft-ietf-ospf-nssa-update-02.txt>
This memo documents of an optional type of OSPF area which is somewhat
humorously referred to as a 'not-so-stubby' area (or NSSA). NSSAs are
similar to the existing OSPF stub area configuration option but have
the additional capability of importing AS external routes in a limited
fashion.
The OSPF NSSA Option was originally defined in RFC 1587. The
functional differences between this memo and RFC 1587 are explained in
Appendix D. All differences, while expanding capability, are
backward-compatible in nature. Implementations of this memo and of RFC
1587 will interoperate. Please send comments to
ospf@gated.cornell.edu.
"The OSPF Address Resolution Advertisement Option", Rob Coltun, Juha
Heinanen, 08/04/1997, <draft-ietf-ospf-ara-00.txt>
This document defines an OSPF option which enables routers to distri-
bute IP to link-layer address resolution information. An OSPF Address
Resolution Advertisement (ARA) may include link-layer specific func-
tionality such as a multipoint-to-point connection identifier along
with the address resolution information. The ARA option can be used
to support router-to-router inter-subnet shortcut architectures such
as those described in [HEIN]
"OSPFv2 Domain Of Interpretation (DOI) for ISAKMP", Ran Atkinson,
10/16/1997, <draft-ietf-ospf-doi-00.txt>
The Internet Security Association and Key Management
Protocol
(ISAKMP) defines a framework for security association management
and
cryptographic key establishment for the Internet. This
framework
consists of defined exchanges and processing guidelines that
occur
within a given Domain of Interpretation (DOI). This document
details the OSPFv2 DOI, which is defined to cover the use of
ISAKMP to
negotiate Security Associations for the OSPFv2 routing protocol.
"SPF over ATM and Proxy PAR", T. Przygienda, Patrick Droz, 10/31/1997,
<draft-ietf-ospf-atm-00.txt>
This draft specifes for OSPF implementors and users mechanisms
describing how the protocol operates in ATM networks over PVC and
SVC
meshes with the presence of Proxy PAR. These recommendations do not
require any protocol changes and allow for simpler, more efficient
and cost- effective network designs. It is recommended that OSPF
implementations should be able to support logical interfaces, each
consisting of one or more virtual circuits and used as numbered
logical point-to-point links (one VC) or logical NBMA networks (more
than one VC) where a solution simulating broadcast interfaces is not
appropriate. Proxy PAR can help to distribute configuration changes
of such interfaces when OSPF capable routers are reconfigured on the
ATM cloud.
One Time Password Authentication (otp)
--------------------------------------
"OTP Extended Responses", C. Metz, 09/16/1997,
<draft-ietf-otp-ext-04.txt>
This document provides a specification for a type of response to an
OTP [RFC 1938] challenge that carries explicit indication of the
response's encoding. Codings for the two mandatory OTP data formats
using this new type of response are presented.
This document also provides a specification for a response that
allows an OTP generator to request that a server re-initialize a
sequence and change parameters such as the secret pass phrase.
"OTP Verification Examples", P. Nesser, 01/16/1997,
<draft-ietf-otp-ver-01.txt>
This document provides a series of inputs and correct outputs for all
three of the defined OTP cryptographic hashes, specifically MD4, MD5,
and SHA1. This document is intended to be used by developers for
interoperability checks when creating generators or servers. Output is
provided in both hexadecimal notation and the six word encoding
documented in Appendix C.
"A One-Time Password System", Neil Haller, P. Nesser, C. Metz, M. Straw,
09/03/1997, <draft-ietf-otp-02.txt>
This document describes a one-time password authentication system
(OTP). The system provides authentication for system access (login)
and other applications requiring authentication that is secure
against passive attacks based on replaying captured reusable
passwords. OTP evolved from the S/KEY* One-Time Password System that
was released by Bellcore and is described in references [3] and [5].
Procedures for Internet/Enterprise Renumbering (pier)
-----------------------------------------------------
"IP Addresses in Applications", P. Nesser, 03/25/1997,
<draft-ietf-pier-applications-00.txt>
The Procedures for Internet/Enterprise Renumbering (PIER) Working Group
of the Internet Engineering Task Force (IETF) has been tasked with the
creation of documents to aid renumbering efforts. This document
defines a series of classes of IP address locations. Each class will
be described in a general sense, while specific examples are provided
as possible.
Public-Key Infrastructure (X.509) (pkix)
----------------------------------------
"Internet Public Key Infrastructure X.509 Certificate and CRL Profile",
D. Solo, Russ Housley, Warwick Ford, T. Polk, 10/15/1997,
<draft-ietf-pkix-ipki-part1-06.txt>
This is the sixth draft of the Internet Public Key Infrastructure
X.509 Certificate and CRL Profile. This draft is a complete
specification. This text includes minor modifications over the
previous draft. Please send comments on this document to the ietf-
pkix@tandem.com mail list.
"Internet Public Key Infrastructure Certificate Management
Protocols", C. Adams, S. Farrell, 10/15/1997,
<draft-ietf-pkix-ipki3cmp-05.txt>
This is a draft of the Internet Public Key Infrastructure (X.509)
Certificate Management Protocols. Protocol messages are defined for all
relevant aspects of certificate creation and management.
"Internet Public Key Infrastructure Operational Protocols - LDAPv2", Tim
Howes, S. Boeyen, P. Richard, 10/23/1997,
<draft-ietf-pkix-ipki2opp-04.txt>
The protocol described in this document is designed to satisfy
some
of the operational requirements within the Internet Public
Key
Infrastructure (IPKI). Specifically, this document
addresses
requirements to provide access to Public Key Infrastructure
(PKI)
repositories for the purposes of retrieving PKI information
and
managing that same information. The mechanism described in
this
document is based on the Lightweight Directory Access
Protocol
(LDAP) v2, defined in RFC 1777, defining a profile of that
protocol
for use within the IPKI and updates encodings for certificates
and
revocation lists from RFC 1778. Additional mechanisms
addressing
PKIX operational requirements are specified in separate documents.
The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED',
and
'MAY' in this document are to be interpreted as described in
RFC
2119.
Please send comments on this document to the
ietf-pkix@tandem.com
mail list.
"Internet Public Key Infrastructure Certificate Policy and Certification
Practices Framework", Warwick Ford, S. Chokhani, 10/07/1997,
<draft-ietf-pkix-ipki-part4-02.txt>
This document presents a framework to assist the writers of
certificate policies or certification practice statements
for
certification authorities and public key infrastructures.
In
particular, the framework provides a comprehensive list of
topics
that potentially (at the writer's discretion) need to be covered in
a
certificate policy definition or a certification practice
statement.
It is intended that this document, when fully developed, be
published
as an Informational RFC.
"Internet Public Key Infrastructure Part V: Time Stamp Protocols", C.
Adams, D. Pinkas, Patrick Cain, Robert Zuccherato, 07/30/1997,
<draft-ietf-pkix-ipki5tsp-00.txt>
This document describes the format of the data returned by a Time
Stamp Authority and the protocols to be used when communicating with
it.
The time stamping service can be used as a Trusted Third Party (TTP) as
one component in building reliable non-repudiation services (see
[ISONR]). We also give an example of how to place a signature at a
particular point in time, from which the appropriate CRLs may be
checked.
"Internet Public Key Infrastructure", C. Adams, Robert Zuccherato,
07/30/1997, <draft-ietf-pkix-ipki6np-00.txt>
This document describes a general notary service and the protocols to
be used when communicating with it. The Notary Authority is a Trusted
Third Party (TTP) that can be used as one component in building
reliable
non-repudiation services (see [ISONR]). We also give an example of how
to use the notary to extend the lifetime of a signature beyond key
expiry or revocation.
"Internet Public Key Infrastructure Representation of Key Exchange
Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates",
Russ Housley, William Polk, 10/15/1997, <draft-ietf-pkix-ipki-kea-01.txt>
This is the second draft of a profile for specification of Key
Exchange Algorithm (KEA) keys in Internet Public Key Infrastructure
X.509 certificates. Please send comments on this document to the
ietf-pkix@tandem.com mail list.
"Internet Public Key Infrastructure Operational Protocols: FTP and
HTTP", Russ Housley, 10/22/1997, <draft-ietf-pkix-opp-ftp-http-01.txt>
The protocol conventions described in this document satisfy some of
the operational requirements of the Internet Public Key
Infrastructure (PKI). This document specifies the conventions for
using the File Transfer Protocol (FTP) and the Hypertext Transfer
Protocol (HTTP) to obtain certificates and certificate revocation
lists (CRLs) from PKI repositories. Additional mechanisms
addressing
PKIX operational requirements are specified in separate documents.
Please send comments on this document to the ietf-pkix@tandem.com
mail list.
"Internet Public Key Infrastructure Online Certificate Status Protocol -
OCSP", M. Myers, 10/23/1997, <draft-ietf-pkix-ocsp-00.txt>
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure
(PKI). This document specifies an HTTP-based application protocol use-
ful in determining the current status of a digital certificate without
the use of CRLs. Additional mechanisms addressing PKIX operational re-
quirements are specified in separate documents.
Please send comments on this document to the ietf-pkix@tandem.com mail
list.
PacketWay (pktway)
------------------
"The End-to-End (EEP) PacketWay Protocol for High-Performance
Interconnection of Computer Clusters", Danny Cohen, C. Lund, T. Skjellum,
T. McMahon, R. George, 10/14/1997,
<draft-ietf-pktway-protocol-eep-spec-02.txt>
PktWay is an open family of specifications for inter-networking
high performance System Area Networks (SANs) and high performance
Local Area Networks (LANs) into computing clusters.
"Part-1 of The Router-to-Router (RRP) PacketWay Protocol for
High-Performance Interconnection of Computer Clusters", Danny Cohen, C.
Lund, T. Skjellum, T. McMahon, R. George, 10/23/1997,
<draft-ietf-pktway-protocol-rrp1-spec-00.txt>
The PktWay protocol is introduced in the 'The End-to-End (EEP)
PacketWay Protocol for High-Performance Interconnection of Computer
Clusters'. This document defines the basic part (Part 1) of the
Router-to-Router protocol (RRP) of PacketWay.
The shorter 'PktWay' is used for 'PacketWay'.
Process for Organization of Internet StandardS ONg (poisson)
------------------------------------------------------------
"IETF Working Group Guidelines and Procedures", Scott Bradner,
09/09/1997, <draft-ietf-poisson-wg-guide-01.txt>
The Internet Engineering Task Force (IETF) has responsibility for
developing and reviewing specifications intended as Internet
Standards. IETF activities are organized into working groups (WGs).
This document describes the guidelines and procedures for formation
and operation of IETF working groups. It also describes the formal
relationship between IETF participants WG and the Internet
Engineering Steering Group (IESG) and the basic duties of IETF
participants, including WG Chairs, WG participants, and IETF Area
Directors.
"IAB and IESG Selection, Confirmation, and Recall Process: Operation of
the Nominating and Recall Committees", James Galvin, 08/02/1997,
<draft-ietf-poisson-nomcom-02.txt>
The process by which the members of the IAB and IESG are selected,
confirmed, and recalled is specified. The evolution of the process
has relied principally on oral tradition as a means by which the
lessons learned could be passed on to successive committees. This
document is a self-consistent, organized compilation of the process
as it is known today.
Point-to-Point Protocol Extensions (pppext)
-------------------------------------------
"PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol", J.
Petty, 10/29/1993, <draft-ietf-pppext-hpppc-00.txt>
The Point-to-Point Protocol (PPP) provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol provides a method to negotiate and
utilize compression protocols over PPP encapsulated links.
This document describes the use of the HP PPC compression algorithm for
compressing PPP encapsulated packets.
"The PPP Internet Protocol Control Protocol (IPCP)", G. McGregor,
03/21/1997, <draft-ietf-pppext-ipcp-network-01.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
proposes a family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
This document defines the NCP for establishing and configuring the
Internet Protocol [2] over PPP, and a method to negotiate and use Van
Jacobson TCP/IP header compression [3] with PPP.
"PPP Extensible Authentication Protocol (EAP)", J. Vollbrecht, Larry
Blunk, 07/23/1996, <draft-ietf-pppext-eap-auth-02.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authenticating its peer
before allowing Network Layer protocols to transmit over the link.
This document defines the PPP Extensible Authentication Protocol.
"PPP EAP RSA Public Key Authentication Protocol", W. Whelan, 02/20/1997,
<draft-ietf-pppext-eaprsa-04.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authentication its peer
before allowing Network Layer protocols to transmit over the link.
PPP Extensible Authentication Protocol (EAP) [2] provides for a number
of authentication mechanisms. One of these is RSA Public Key
Authentication. This document defines RSA Public Key Authentication
Protocol within PPP EAP.
"PPP LCP Extensions", W. Simpson, 07/28/1997,
<draft-ietf-pppext-lcpext-ds-02.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links. PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document
defines additional LCP features that have been suggested over the past
few years.
"Point-to-Point Tunneling Protocol--PPTP", G. Pall, K. Hamzeh, W.
Verthein, J. Taarud, W. Little, 07/24/1997,
<draft-ietf-pppext-pptp-02.txt>
This document specifies a protocol which allows the Point to Point
Protocol (PPP) to be tunneled through an IP network. PPTP does not
specify any changes to the PPP protocol but rather describes a new
vehicle for carrying PPP. A client-server architecture is defined in
order to decouple functions which exist in current Network Access
Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP
Network Server (PNS) is envisioned to run on a general purpose
operating system while the client, referred to as a PPTP Access
Concentrator (PAC) operates on a dial access platform. PPTP specifies a
call-control and management protocol which allows the server to control
access for dial-in circuit switched calls originating from a PSTN or
ISDN or to initiate outbound circuit-switched connections. PPTP uses a
GRE-like (Generic Routing Encapsulation) mechanism to provide a flow-
and congestion-controlled encapsulated datagram service for carrying
PPP packets.
"Layer Two Tunneling Protocol 'L2TP'", William Palter, T. Kolar, G. Pall,
M. Littlewood, A. Valencia, K. Hamzeh, W. Verthein, J. Taarud, W. Mark
Townsley, 10/21/1997, <draft-ietf-pppext-l2tp-07.txt>
Virtual dial-up allows many separate and autonomous protocol
domains
to share common access infrastructure including modems, Access
Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up
via PPP [1]. This document describes the Layer Two Tunneling
Protocol (L2TP) which permits the tunneling of the link layer (i.e.,
HDLC, async HDLC) of PPP. Using such tunnels, it is possible to
divorce the location of the initial dial-up server from the location
at which the dial-up protocol connection is terminated and access to
the network provided.
"Mobile-IPv4 Configuration Option for PPP IPCP", Jim Solomon, S. Glass,
07/02/1997, <draft-ietf-pppext-ipcp-mip-02.txt>
Mobile IP [RFC 2002] defines media-independent procedures by which a
Mobile Node can maintain existing transport and application-layer
connections despite changing its point-of-attachment to the Internet
and without changing its IP address. PPP [RFC 1661] provides a
standard method for transporting multi-protocol packets over
point-to-point links. As currently specified, Mobile IP Foreign Agents
which support Mobile Node connections via PPP can do so only by first
assigning unique addresses to those Mobile Nodes, defeating one of the
primary advantages of Foreign Agents. This documents corrects this
problem by defining the Mobile-IPv4 Configuration Option to the
Internet Protocol Control Protocol (IPCP) [RFC 1332]. Using this
option, two peers can communicate their support for Mobile IP during
the IPCP phase of PPP. Familiarity with Mobile IP [RFC 2002], IPCP
[RFC 1332], and PPP [RFC 1661] is assumed.
"Semi Connected Mode for PPP links", M. Latvala, G. Liu, 03/14/1997,
<draft-ietf-pppext-scm-00.txt>
The configuration of a Point-to-Point Protocol (PPP) [1] link requires
a considerable amount of time which makes it impractical to establish a
new PPP link every time an end-user wants to send or is about to
receive data. This document proposes an LCP extension called Semi
Connected Mode. When both sides agree to use Semi Connected Mode
they can terminate and quickly re-establish the bearer service without
having to reconfigure the PPP link.
"Proposal for a PPP Network Layer Entity Selection Protocol", A. Doria,
X. Chen, 03/26/1997, <draft-ietf-pppext-nles-00.txt>
With the introduction of xDSL services into public telecommunications
networks, direct access (in contrast to dial-up access) will start to
be used as an access method for data as well as other services.
PPP has been very successful in providing connections for IP as well
as other protocols in the dial-up access network. With the advent of
direct access, changes will be need to be made for identifying the
target hosts, as it will no longer be possible to rely on the telephone
number that is dialed prior to initiating the PPP session. This
proposal indicates one method for adapting PPP to the new
requirements.
"PPP over AAL5", M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross,
09/30/1997, <draft-ietf-pppext-aal5-02.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method
for transporting multi-protocol datagrams over point-to-point
links.
This document describes the use of ATM Adaptation Layer 5 (AAL5)
for framing PPP encapsulated packets.
"Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI", M. Kaycee, N.
Arunkumar, A. Lin, T. Kwok, 03/27/1997,
<draft-ietf-pppext-l2tp-aal5-funi-00.txt>
Layer Two Tunneling Protocol describes a mechanism to tunnel PPP
sessions. The protocol has been designed to be independent of the
media it runs over. The base specification describes how it should be
implemented to run over UDP and IP. This document describes how the
Layer Two Tunneling Protocol MUST be implemented over ATM (AAL5 and
FUNI).
"PPP LCP CallBack", W. Simpson, 07/30/1997,
<draft-ietf-pppext-callback-ds-01.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document
defines the CallBack option.
"Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP
networks", Pat Calhoun, W. Mark Townsley, 10/10/1997,
<draft-ietf-pppext-l2tp-sec-02.txt>
The L2TP document [1] defines the base protocol which describes the
method of tunneling PPP [2] data. The L2TP document states that the
security mechanism used over an IP network is to use the IETF's IPSEC
protocols.
L2TP was designed in such a way as to be able to run over any
underlying layer (i.e. Frame Relay, ATM, etc.). This document
specifies extensions to the L2TP protocol in order to provide
authentication and integrity of individual packets in a tunneled
session over a network where IPSEC or another suitable security
protocol is not available.
"The PPP DES Encryption Protocol, Version 2 (DESE-bis)", Keith Sklower,
G. M. Meyer, 07/15/1997, <draft-ietf-pppext-des-encrypt-v2-00.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to
negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the DES standard
[5, 6] for encrypting PPP encapsulated packets.
"The PPP Triple-DES Encryption Protocol (3DESE)", H. Kummert, 07/21/1997,
<draft-ietf-pppext-3des-encrypt-00.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Encryption Control Protocol (ECP) [2] provides a method to
negotiate and utilize encryption protocols over PPP encapsulated links.
This document provides specific details for the use of the Triple-DES
standard (3DES) [6] for encrypting PPP encapsulated packets.
"PPP Over FUNI", M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross,
09/30/1997, <draft-ietf-pppext-funi-02.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method
for transporting multi-protocol datagrams over point-to-point
links.
This document describes the use of ATM Frame User Network
Interface
(FUNI) for framing PPP encapsulated packets.
"PPP LCP Self Describing Padding", W. Simpson, 07/29/1997,
<draft-ietf-pppext-padding-ds-00.txt>
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP
defines an extensible Link Control Protocol (LCP) for establishing,
configuring, and testing the data-link connection. This document
defines several additional LCP features that have been suggested
over
the past few years.
"Layer Two Tunneling Protocol 'L2TP' Management Information Base", Pat
Calhoun, Ross Wheeler, Gayam Reddy, 10/10/1997,
<draft-ietf-pppext-l2tp-mib-00.txt>
This memo defines a 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 networks using Layer
2
Tunneling Protocol.
This memo specifies a MIB module in a manner that is both compliant
to
the SNMPv2 SMI, and semantically identical to the peer
SNMPv1
definitions.
"PPP EAP TLS Authentication Protocol", B. Aboba, D. Simon, 10/21/1997,
<draft-ietf-pppext-eaptls-02.txt>
The Point-to-Point Protocol (PPP) provides a standard method
for
transporting multi-protocol datagrams over point-to-point links.
PPP
also defines an extensible Link Control Protocol (LCP), which
can be
used to negotiate authentication methods, as well as an
Encryption
Control Protocol (ECP), used to negotiate data encryption over
PPP
links, and a Compression Control Protocol (CCP), used to
negotiate
compression methods. The Extensible Authentication Protocol
(EAP) is
a PPP extension that provides support for additional
authentication
methods within PPP.
Transport Level Security (TLS) provides for mutual
authentication,
integrity-protected ciphersuite negotiation and key exchange
between
two endpoints. This document describes how EAP-TLS, which
includes
support for fragmentation and reassembly, provides for these TLS
mech-
anisms within EAP.
"PPP over SONET/SDH",, 10/16/1997,
<draft-ietf-pppext-pppsonet-scrambler-00.txt>
This Internet Draft addresses the PPP/SONET interface defined
in the IETF RFC 1619 and its application in public Internet backbone
networks. By experimental analysis it is found that this SONET
interface
specification is deficient in providing payload transparency. This
deficiency leads to deleterious effects in providing reliable network
operations. A simple SONET payload scrambler enhancement is proposed to
overcome this deficiency. This work has been brought to the
ANSI T1X1.5 as an action item for the addition of the RFC 1619 mapping
to T1.105 with a scrambler to be determined by T1X1.
We are submitting the same proposal to IETF now with the interest to
enhance RFC-1619 accordingly and achieve alignment with ANSI T1
standards.
To facilitate this alignment, we have recommended that T1X1 establish a
formal liaison with IETF in regard to IP/SONET interface standards
and associated IP transmission standards development.
Printer MIB (printmib)
----------------------
"Printer MIB", R. Turner, 10/16/1997,
<draft-ietf-printmib-mib-info-03.txt>
This document provides definitions of models and manageable
objects for printing environments. The objects included in
this
MIB apply to physical, as well as logical entities within a
printing device. This MIB definition makes explicit
references to
the Host Resources MIB (RFC 1514), as well as the Interfaces
Group of MIB-II (RFC 1213).
"Job Monitoring MIB - V0.85", T. Hasting, H. Lewis, S. Isaacson, R.
Bergman, 09/26/1997, <draft-ietf-printmib-job-monitor-06.txt>
This Internet-Draft specifies a small set of read-only SNMP MIB
objects for (1) monitoring the status and progress of print jobs
(2) obtaining resource requirements before a job is processed, (3)
monitoring resource consumption while a job is being processed and
(4) collecting resource accounting data after the completion of a
job. This MIB is intended to be implemented (1) in a printer or
(2) in a server that supports one or more printers. Use of the
object set is not limited to printing. However, support for
services other than printing is outside the scope of this Job
Monitoring MIB. Future extensions to this MIB may include, but
are
not limited to, fax machines and scanners.
Physical Topology MIB (ptopomib)
--------------------------------
"Physical Topology MIB", Ken Jones, Andy Bierman, 09/22/1997,
<draft-ietf-ptopomib-mib-01.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes managed objects used for
managing physical topology identification and discovery.
"Physical Topology Discovery Protocol and MIB", Keith McCloghrie, Andy
Bierman, 09/17/1997, <draft-ietf-ptopomib-pdp-01.txt>
This memo defines an experimental protocol, and an experimental portion
of the Management Information Base (MIB) for use with network
management
protocols in the Internet community. In particular, it describes a
physical topology discovery protocol and managed objects used for
QoS Routing (qosr)
------------------
"A Framework for QoS-based Routing in the Internet", R. Nair, B.
Rajagopalan, Hal Sandick, Eric Crawley, 07/30/1997,
<draft-ietf-qosr-framework-01.txt>
QoS-based routing is being recognized as the missing piece in the
evolution
of QoS-based service offerings in the Internet. This document describes
some of the QoS-based routing issues and requirements, and proposes
a framework for QoS-based routing in the Internet. This framework is
based
on extending the current Internet routing model of intra and
interdomain routing to support QoS. The ideas expressed in this
document
are subject to discussion and expected to evolve based on inputs
received over time.
Remote Authentication Dial-In User Service (radius)
---------------------------------------------------
"Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS", B. Aboba,
G. Zorn, 07/28/1997, <draft-ietf-radius-tunnel-imp-03.txt>
This document discusses implementation issues arising in the
provisioning of compulsory tunneling in dial-up networks using the PPTP
and L2TP protocols. This provisioning can be accomplished via the
integration of RADIUS and tunneling protocols. Implementation issues
encountered with other tunneling protocols are left to separate
documents.
"RADIUS Attributes for Tunnel Protocol Support", J. Shriver, D. Leifer,
G. Zorn, 08/05/1997, <draft-ietf-radius-tunnel-auth-02.txt>
This document defines a set of RADIUS attributes designed to support
the
provision of compulsory tunneling in dial-up networks.
RADIUS
attributes for both authorization and accounting are specified.
"Extensible Authentication Protocol Support in RADIUS", Allan Rubens, B.
Aboba, Pat Calhoun, 05/22/1997, <draft-ietf-radius-eap-02.txt>
The Extensible Authentication Protocol (EAP) is a PPP extension that
provides support for additional authentication methods within PPP.
This document describes how the EAP-Message and Signature attributes
may be used for providing EAP support within RADIUS.
"RADIUS Extensions", Carl Rigney, W. Willats, 01/22/1997,
<draft-ietf-radius-ext-00.txt>
This document describes additional attributes for carrying
authentication, authorization and accounting information between a
Network Access Server (NAS) and a shared Accounting Server using the
Remote Authentication Dial In User Service (RADIUS) protocol described
in RFC 2058 and RFC 2059.
"RADIUS Accounting Interim Accounting Record Extension", A. Ratcliffe,
Pat Calhoun, M. Beadles, 07/02/1997,
<draft-ietf-radius-acct-interim-00.txt>
The RADIUS Accounting document [1] defines a mechanism which is used by
a Network Access Server (NAS) to send accounting information to a
RADIUS server. The current protocol defines a Start and Stop record.
This document defines an interim record which is used to make the
RADIUS accounting protocol more robust.
"RADIUS Authentication Server MIB", B. Aboba, G. Zorn, 08/26/1997,
<draft-ietf-radius-auth-servmib-00.txt>
This memo defines a set of extensions which instrument RADIUS
authentication server functions. These extensions represent a portion
of the Management Information Base (MIB) for use with network
management protocols in the Internet community. Using these
extensions IP-based management stations can manage RADIUS
authentication servers.
"RADIUS Accounting Client MIB", B. Aboba, G. Zorn, 08/26/1997,
<draft-ietf-radius-acc-clientmib-00.txt>
This memo defines a set of extensions which instrument RADIUS
accounting
client functions. These extensions represent a portion of the
Management Information Base (MIB) for use with network management
protocols
in the Internet community. Using these extensions IP-based management
stations can manage RADIUS accounting clients.
"RADIUS Accounting Server MIB", B. Aboba, G. Zorn, 08/26/1997,
<draft-ietf-radius-acc-servmib-00.txt>
This memo defines a set of extensions which instrument RADIUS
accounting server functions. These extensions represent a portion of
the Management Information Base (MIB) for use with network management
protocols in the Internet community. Using these extensions IP-based
management stations can manage RADIUS accounting servers.
"RADIUS Authentication Client MIB", B. Aboba, G. Zorn, 08/26/1997,
<draft-ietf-radius-auth-clientmib-00.txt>
This memo defines a set of extensions which instrument RADIUS
authentication client functions. These extensions represent a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community. Using these
extensions IP-based management stations can manage RADIUS
authentication clients.
"RADIUS Attributes for MS-CHAP Support", G. Zorn, 10/23/1997,
<draft-rfced-info-zorn-00.txt>
This document describes a set of vendor-specific RADIUS
attributes
designed to support the use of Microsoft's proprietary dialect of
PPP
CHAP (MS-CHAP) in dial-up networks. MS-CHAP is derived from and
(where
possible) consistent with PPP CHAP [1]; the differences between PPP
CHAP
and MS-CHAP are significant enough to warrant the definition of
new
RADIUS attributes, however.
Receipt Notifications for Internet Mail (receipt)
-------------------------------------------------
"An Extensible Message Format for Message Disposition Notifications",
Roger Fajman, 10/23/1997, <draft-ietf-receipt-mdn-06.txt>
This memo defines a MIME content-type that may be used by a mail
user agent (UA) or electronic mail gateway to report the disposition
of a message after it has been sucessfully delivered to a recipient.
This content-type is intended to be machine-processable. Additional
message headers are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message.
The purpose is to extend Internet Mail to support functionality
often found in other messaging systems, such as X.400 and the
proprietary 'LAN-based' systems, and often referred to as 'read
receipts,' 'acknowledgements,' or 'receipt notifications.' The
intention is to do this while respecting the privacy concerns that have
often been expressed when such functions have been discussed in
the past.
Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary 'LAN-based'
systems), the MDN protocol is designed to be useful in a multi-
protocol messaging environment. To this end, the protocol described
in this memo provides for the carriage of 'foreign' addresses, in
addition to those normally used in Internet Mail. Additional
attributes may also be defined to support 'tunneling' of foreign
notifications through Internet Mail.
Routing Information Protocol (rip)
----------------------------------
"RIP Version 2 MIB Extension", G. Malkin, Fred Baker, 03/20/1997,
<draft-ietf-rip-mib-00.txt>
This memo defines a 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 RIP Version 2.
"RIPv2 Domain Of Interpretation (DOI) for ISAKMP", Ran Atkinson,
10/16/1997, <draft-ietf-rip-doi-00.txt>
The Internet Security Association and Key Management
Protocol
(ISAKMP) defines a framework for security association management
and
cryptographic key establishment for the Internet. This
framework
consists of defined exchanges and processing guidelines that
occur
within a given Domain of Interpretation (DOI). This document
details
the RIPv2 DOI, which is defined to cover the use of ISAKMP
to
negotiate Security Associations for the RIPv2 routing protocol.
RIP Version II (ripv2)
----------------------
"RIP Version 2 Carrying Additional Information", G. Malkin, 03/25/1997,
<draft-ietf-ripv2-protocol-v2-02.txt>
This document specifies an extension of the Routing Information
Protocol (RIP), as defined in [1], to expand the amount of useful
information carried in RIP messages and to add a measure of security.
A companion document will define the SNMP MIB objects for RIP-2 [2].
An additional document will define cryptographic security improvements
for RIP-2 [3].
"RIP-II MD5 Authentication", Fred Baker, Ran Atkinson, 03/07/1997,
<draft-ietf-ripv2-md5-auth-00.txt>
Growth in the Internet has made us aware of the need for improved
authentication of routing information. RIP-II provides for
unauthenticated service (as in classical RIP), or password
authentication. Both are vulnerable to passive attacks currently
widespread in the Internet. Well-understood security issues exist in
routing protocols [4]. Clear text passwords, currently specified for
use with RIP-II, are no longer considered sufficient [5].
Remote Network Monitoring (rmonmib)
-----------------------------------
"Remote Network Monitoring MIB Extensions for Switch Networks
Version 1.0", Steven Waldbusser, Dan Romascanu, W. Lahaye, R. Waterman,
10/23/1997, <draft-ietf-rmonmib-smon-04.txt>
This memo defines a 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 remote network
monitoring devices in switched networks environments.
"Remote Network Monitoring MIB Protocol Identifiers (Version 2)", C.
Bucci, R. Iddon, Andy Bierman, 10/29/1997,
<draft-ietf-rmonmib-rmonprot-v2-03.txt>
This memo describes protocol encapsulations which are referenced by the
management objects defined in the Remote Network Monitoring MIB Version
2 [RFC2021]. Additionally, this memo defines a notation describing
protocol layers in a protocol encapsulation and contains a large list
of
protocol definitions using this notation. Although related to the
original Remote Network Monitoring MIB [RFC1757], this document refers
only to objects found in the RMON-2 MIB.
"Remote Network Monitoring Management Information Base for High Capacity
Networks", Steven Waldbusser, 09/19/1997,
<draft-ietf-rmonmib-hcrmon-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
defines objects for managing remote network monitoring
devices.
This memo does not specify a standard for the Internet
community.
Roaming Operations (roamops)
----------------------------
"Dialup Roaming Requirements", B. Aboba, G. Zorn, 07/11/1997,
<draft-ietf-roamops-roamreq-05.txt>
This document describes the features required for the provision of
'roaming capability' for dialup Internet users, as well as offering
some suggestions for future protocol standardization work. 'Roaming
capability' is defined as the ability to use any one of multiple
Internet service providers (ISPs), while maintaining a formal,
customer-vendor relationship with only one. Examples of cases where
roaming capability might be required include ISP 'confederations' and
ISP-provided corporate network access support.
"The Network Access Identifier", B. Aboba, M. Beadles, 09/09/1997,
<draft-ietf-roamops-nai-07.txt>
In order to enhance the interoperability of roaming and tunneling
services, it is desirable to have a standardized method for identifying
users. This document proposes syntax for the Network Access
Identifier (NAI). It is expected that this will be of interest for
support of roaming as well as tunneling. 'Roaming capability' may be
loosely defined as the ability to use any one of multiple Internet
service providers (ISPs), while maintaining a formal, customer-vendor
relationship with only one. Examples of cases where roaming capability
might be required include ISP 'confederations' and ISP-provided
corporate network access support.
"Session Record Accounting in Roaming", J. Vollbrecht, B. Aboba, D.
Lidyard, 08/26/1997, <draft-ietf-roamops-actng-03.txt>
This document describes the problems arising in session record
accounting in roaming systems, and proposes a standard accounting
record format.
"Guidelines for the Operation of RADIUS Proxies in Roaming", J.
Vollbrecht, B. Aboba, G. Zorn, 09/10/1997,
<draft-ietf-roamops-auth-03.txt>
Today, while RADIUS proxy chaining is widely deployed for the purposes
of providing roaming services, interoperation between roaming systems
is difficult. This document provides guidelines for the operation of
RADIUS proxies within roaming systems.
"Secure Radius Server Operation Guidelines for Dial Roaming
", Y. Jiang, 10/21/1997, <draft-ietf-roamops-sec-00.txt>
Authenticating and authorizing roaming dialup users requires
messages to be exchanged among facilities managed by two or
more service providers, and secure operation of the facilities
is of vital importance. This document provides guidelines for
operating such facilities when using the Remote Authentication
Dial In User Service (RADIUS) protocol and the companion
accounting protocol for authentication and accounting message
exchange.
Routing Policy System (rps)
---------------------------
"Routing Policy Specification Language (RPSL)", Daniel Karrenberg, D.
Meyer, M. Terpstra, C. Villamizar, Cengiz Alaettinoglu, T. Bates,
08/02/1997, <draft-ietf-rps-rpsl-03.txt,.ps>
This Internet Draft is the reference document for the Routing Policy
Specification Language (RPSL). RPSL allows a network operator to be
able to specify routing policies at various levels in the Internet
hierarchy; for example at the Autonomous System (AS) level. At the
same time, policies can be specified with sufficient detail in RPSL so
that low level router configurations can be generated from them. RPSL
is extensible; new routing protocols and new protocol features can be
introduced at any time.
"Application of Routing Policy Specification Language (RPSL) on the
Internet", David Meyer, Cengiz Alaettinoglu, J. Schmitz, 03/26/1997,
<draft-ietf-rps-appl-rpsl-00.txt, .ps>
This document is a tutorial on using the Routing Policy Specification
Language (RPSL) to specify routing policies. It covers registering
policies in an Internet Routing Registry (IRR) using RPSL, and the use
of tools to generate vendor specific router configuration. It is
targeted towards an Internet/Network Service Provider (ISP/NSP)
engineer who is new to RPSL and to IRR. Readers are referred to the
RPSL reference document [1] for completeness. We recommend reading
this document before reading the reference document. We hope that for
many cases, this document will be sufficient.
"A strategy for the transition from RIPE-181 to RPSL", David Kessens,
08/02/1997, <draft-ietf-rps-transition-01.txt>
This document describes a transition strategy for the Internet routing
registries from the RIPE181 [1] routing language to RPSL [2].
Resource Reservation Setup Protocol (rsvp)
------------------------------------------
"RSVP Cryptographic Authentication", Fred Baker, 08/26/1997,
<draft-ietf-rsvp-md5-05.txt>
This document describes the format and use of RSVP's INTEGRITY
object to provide hop-by-hop integrity and authentication of
RSVP messages.
"RSVP Extensions for Policy Control", Shai Herzog, 03/20/1997,
<draft-ietf-rsvp-policy-ext-02.txt, .ps>
This memo describes a set of extensions for supporting generic policy
based admission control in RSVP. [Note 1]
These extensions include the standard format of POLICY_DATA objects, a
generic RSVP/Policy-Control interface, and a description of RSVP's
handling of policy events.
This document does not advocate particular policy control mechanisms;
however, a Router/Server Policy Protocol description for these
extensions can be found in [LPM].
"RSVP Extensions for CIDR Aggregated Data Flows", J. Boyle, 06/26/1997,
<draft-ietf-rsvp-cidr-ext-01.txt>
This document presents extensions to Version 1 of the Resource
Reservation Setup Protocol (RSVP). These extensions ameliorate RSVP
support of Large Scale Multicast Applications (LSMA) and Virtual
Private Networks (VPN). With these types of applications, several
hosts at any particular site are participating in a session. Efficient
RSVP use requires aggregation of their addresses into a single entry
for classification purposes. The extensions allow such aggregation of
state in a simple manner that requires no changes to the base RSVP
specification.
"Designing Tunnels for Interoperability with RSVP", John Krawczyk,
03/12/1997, <draft-ietf-rsvp-tunnels-interop-00.txt>
This memo provides information for designers of tunneling protocols
that use IP-in-IP encapsulation. It describes how to design a tunnel
header so that RSVP [RSVPv1] can be used to signal the Quality of
Service requirements for individual flows within an IP-in-IP tunnel.
"Open Outsourcing Policy Service (OOPS) for RSVP", R. Guerin, Shai
Herzog, R. Rajan, D. Pendarakis, 08/05/1997,
<draft-ietf-rsvp-policy-oops-01.txt,.ps>
This document describes a protocol for exchanging policy information
and decisions between an RSVP-capable router (client) and a policy
server. The OOPS protocol supports a wide range of router
configurations and RSVP implementations, and is compatible with the
RSVP Extensions for Policy Control [Ext].
"Partial Service Deployment in the Integrated Services Architecture", L.
Breslau, S. Shenker, 04/25/1997, <draft-ietf-rsvp-partial-service-00.txt>
Specifications for providing enhanced qualities of service in the
Internet have been defined in [2,4]. Technical and administrative
concerns may prevent a network element from offering one or more of
these services. In this document, we present a mechanism for dealing
with heterogeneity in the set of services offered by different network
elements. This approach enables end-to-end service to be composed of
different per-hop services while not requiring end systems to be aware
of the details of the service provided at each hop.
"RAPI -- An RSVP Application Programming Interface", Bob Braden, D.
Hoffman, 06/16/1997, <draft-ietf-rsvp-rapi-00.txt, .ps>
This memo describes version 5 of RAPI, a specific API (application
programming interface) for RSVP. The RAPI interface is one realization
of the generic API contained in the RSVP Functional Specification
document, and it is being published for information only. The RAPI
interface is based upon a client library, whose calls are described
here.
"Protocol for Exchange of PoliCy Information (PEPCI)", R. Yavatkar, Laura
Cunningham, Ron Cohen, J. Boyle, David Durham, 07/28/1997,
<draft-ietf-rsvp-pepci-00.txt>
This document describes a simple client/server model for supporting
policy for RSVP, and is designed to be extensible so that other kinds
of client types may be supported in the future. The model does not make
any assumptions about the algorithm of the policy server, but is based
on the server returning a single priority value in response to a policy
request. The objective is to use this very basic model to begin policy
experimentation.
"RSVP Management Information Base",, 10/13/1997,
<draft-ietf-rsvp-v2-mib-00.txt>
This memo defines a 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 Resource Reservation Protocol (RSVP) within the
interface attributes defined in the Integrated Services Model.
Thus, the Integrated Services MIB is directly relevant to and
cross-referenced by this MIB. Comments should be made to the
RSVP Working Group, rsvp@isi.edu.
This memo does not, in its draft form, specify a standard for
the Internet community.
Realtime Traffic Flow Measurement (rtfm)
----------------------------------------
"RTFM Working Group - New Attributes for Traffic Flow Measurement",
Gregory Ruth, Nevil Brownlee, Sig Handelman, 07/22/1997,
<draft-ietf-rtfm-new-traffic-flow-02.txt>
The Real-time Traffic Flow Measurement (RTFM) Working Group has
developed a system for measuring and reporting information about
traffic flows in the Internet. This document explores the definition
of extensions to the flow measurements as currently defined in [1] and
[5]. The new attributes described in this document will be useful for
monitoring network performance and expand the scope of RTFM beyond
simple measurement of traffic rates. Performance attributes typically
deal with throughput, packet loss, and delays. We will explore the
methods by which RTFM can extract values from flows so as to measure
these attributes. We will also look at capturing information on jitter
and congestion control. The RTFM Working Group has defined
the concept of a standardized meter which records flows from a traffic
stream according to Rule Sets which are active in the meter[1].
Implementations of this meter have been done by Nevil Brownlee in the
University of Auckland, NZ, and Stephen Stibler and Sig Handelman at
IBM in Hawthorne, NY, USA. The RTFM WG has also defined the Meter
Reader Program whose job is to fetch flow data from the Meter.
"Traffic Flow Measurement: Meter MIB", Nevil Brownlee, 09/24/1997,
<draft-ietf-rtfm-meter-mib-02.txt>
A 'Traffic Meter' collects data relating to traffic flows within a
network. This document defines a Management Information Base (MIB) for
use in controlling a traffic meter, in particular for specifying the
flows to be measured. It also provides an efficient mechanism for
retrieving flow data from the meter using SNMP. Security issues
concerning the operation of traffic meters are summarised.
"Traffic Flow Measurement: Architecture",, 09/24/1997,
<draft-ietf-rtfm-architecture-00.txt>
This document describes an architecture for the measurement and
reporting of network traffic flows, discusses how this relates to an
overall network traffic flow architecture, and describes how it can be
used within the Internet. It is intended to provide a starting point
for the Realtime Traffic Flow Measurement Working Group.
Responsible Use of the Network (run)
------------------------------------
"DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and
Postings (Spam*)", Sally Hambridge, A. Lunde, 07/15/1997,
<draft-ietf-run-spew-01.txt>
This document provides explains why mass unsolicited electronic mail
messages are not useful in the Internetworking community. It gives a
set of guidelines for dealing with unsolicited mail for users, for
system administrators, news administrators, and mailing list managers.
It also makes suggestions Internet Service Providers might follow.
Secure Shell (secsh)
--------------------
"SSH Transport Layer Protocol", T. Ylonen, 10/14/1997,
<draft-ietf-secsh-transport-02.txt>
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.
This document describes the SSH transport layer protocol which
typically
runs on top of TCP/IP. The protocol can be used as a basis for a number
of secure network services. It provides strong encryption, server
authentication, and integrity protection. It may also provide
compression.
Key exchange method, public key algorithm, symmetric encryption
algorithm, message authentication algorithm, and hash algorithm are all
negotiated.
This document also describes the Diffie-Hellman key exchange method and
the minimal set of algorithms that are needed to implement the SSH
transport layer protocol.
"SSH Authentication Protocol", T. Ylonen, Tero Kivinen, Markku Juhani
Saarinen, 10/14/1997, <draft-ietf-secsh-userauth-02.txt>
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.
This document describes the SSH authentication protocol framework and
public key, password, and host-based client authentication methods.
Additional authentication methods are deferred to separate documents.
The SSH authentication protocol runs on top the SSH transport layer
protocol and provides a single authenticated tunnel for the SSH
connection protocol.
"SSH Connection Protocol", T. Ylonen, Tero Kivinen, Markku Juhani
Saarinen, 10/14/1997, <draft-ietf-secsh-connect-02.txt>
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.
This document describes the SSH connection protocol. It provides
interactive login sessions, remote execution of commands, forwarded
TCP/IP connections, and forwarded X11 connections. All of these
channels are multiplexed into a single encrypted tunnel.
The SSH Connection Protocol has been designed to run on top of the
SSH transport layer and user authentication protocols.
"SSH Protocol Architecture", T. Ylonen, Tero Kivinen, Markku Juhani
Saarinen, 10/14/1997, <draft-ietf-secsh-architecture-00.txt>
SSH is a protocol for secure remote login and other secure network ser-
vices over an insecure network.
This document describes the architecture of the SSH protocol, and the
notation and terminology used in SSH protocol documents. It also
discusses the SSH algorithm naming system that allows local extensions.
The SSH protocol consists of three major components: Transport layer
protocol provides server authentication, confidentiality, and integrity
with perfect forward secrecy. User authentication protocol
authenticates
the client to the server. Connection protocol multiplexes the encrypted
tunnel into several logical channels. Details of these protocols are
described in separate documents.
SNA NAU Services MIB (snanau)
-----------------------------
"Definitions of Managed Objects for DLUR", Robert Moore, B. Clouston,
05/12/1997, <draft-ietf-snanau-dlurmib-02.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for monitoring and controlling
network devices with DLUR (Dependent LU Requester) capabilities. This
memo identifies managed objects for the DLUR protocol.
This memo does not specify a standard for the Internet community.
"Definitions of Managed Objects for HPR", Robert Moore, B. Clouston,
05/14/1997, <draft-ietf-snanau-hprmib-02.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for monitoring and controlling
network devices with HPR (High Performance Routing) capabilities. This
memo identifies managed objects for the HPR protocol.
This memo does not specify a standard for the Internet community.
"Definitions of Managed Objects for Extended Border Node", R. Moore, B.
Clouston, K. Lee, 09/02/1997, <draft-ietf-snanau-ebnmib-00.txt>
This memo defines a portion of the Management Information Base (MIB)
for
use with network management protocols in the Internet community. In
particular, it defines objects for monitoring and controlling network
devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border
Node) capabilities. This memo identifies managed objects for the EBN
architecture.
This memo does not specify a standard for the Internet community.
SNMP Version 3 (snmpv3)
-----------------------
"An Architecture for Describing SNMP Management Frameworks", Bert Wijnen,
Randy Presuhn, D. Harrington, 10/29/1997,
<draft-ietf-snmpv3-next-gen-arch-06.txt>
This document describes an architecture for describing SNMP
Management Frameworks. The architecture is designed to be modular
to allow the evolution of the SNMP protocol standards over time. The
major portions of the architecture are an SNMP engine containing a
Message Processing Subsystem, a Security Subsystem and an Access
Control Subsystem, and possibly multiple SNMP applications which
provide specific functional processing of management data.
"Local Processing Model for version 3 of the Simple Network Management
Protocol (SNMPv3)", Keith McCloghrie, Bert Wijnen, Randy Presuhn,
05/12/1997, <draft-ietf-snmpv3-lpm-01.txt>
This document describes the Local Processing Model (LPM) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This
document defines the Elements of Procedure for accessing local
management information. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this LPM.
"Message Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", Jeffrey Case, Bert Wijnen, Randy Presuhn, D.
Harrington, 10/30/1997, <draft-ietf-snmpv3-v3mpc-model-06.txt>
This document describes the Message Processing and Dispatching for
SNMP messages within the SNMP architecture [SNMP-ARCH]. It defines
the procedures for dispatching potentially multiple versions of SNMP
messages to the proper SNMP Message Processing Models, and for
dispatching PDUs to SNMP applications. This document also describes
one Message Processing Model - the SNMPv3 Message Processing Model.
"User-based Security Model for version 3 of the Simple Network Management
Protocol (SNMPv3)", Bert Wijnen, U. Blumenthal, 06/18/1997,
<draft-ietf-snmpv3-usec-01.txt>
This document describes the User-based Security Model (USEC) for SNMP
version 3 for use in the SNMPng architecture [SNMPng-ARCH]. This
document defines the Elements of Procedure for providing SNMP message
level security. This document also includes a MIB for remotely
monitoring/managing the configuration parameters for this Security
model.
"View-based Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)", Keith McCloghrie, Bert Wijnen, Randy Presuhn,
10/29/1997, <draft-ietf-snmpv3-acm-04.txt>
This document describes the View-based Access Control Model for use
in the SNMP architecture [SNMP-ARCH]. It defines the Elements of
Procedure for controlling access to management information. This
document also includes a MIB for remotely managing the configuration
parameters for the View-based Access Control Model.
"User-based Security Model (USM) for version 3 of the Simple Network
Management Protocol (SNMPv3)", Bert Wijnen, U. Blumenthal, 10/29/1997,
<draft-ietf-snmpv3-usm-03.txt>
This document describes the User-based Security Model (USM) for SNMP
version 3 for use in the SNMP architecture [SNMP-ARCH]. It defines
the Elements of Procedure for providing SNMP message level security.
This document also includes a MIB for remotely monitoring/managing
the configuration parameters for this Security Model.
"SNMPv3 Applications", Bob Stewart, D. Levi, P. Meyer, 10/30/1997,
<draft-ietf-snmpv3-appl-04.txt>
This memo describes five types of SNMP applications which make use
of
an SNMP engine as described in [SNMP-ARCH]. The types of
application
described are Command Generators, Command Responders, Notification
Originators, Notification Receivers, and Proxy Forwarders.
This memo also defines MIB modules for specifying targets of
management operations, for notification filtering, and for proxy
forwarding.
Simple Public Key Infrastructure (spki)
---------------------------------------
"Simple Public Key Certificate", Butler Lampson, T. Ylonen, R. Rivest, W.
Frantz, C. Ellison, B. Thomas, 07/31/1997,
<draft-ietf-spki-cert-structure-02.txt>
With the proliferation of public key cryptography on the Internet,
there arises a need for certification of keys. In the literature,
the word 'certificate' has generally been taken to mean 'identity
certificate': a signed statement which binds a key to the name of an
individual and has the intended meaning of delegating authority from
that named individual to the public key. (See, for example, RFC
1422.) This process is designed to copy a relationship between two
entities from the physical world into the digital world.
The Internet itself changed the world from the one in which identity
certificates made sense. We now deal with people we have never met
and never will, which makes their names meaningless to us, but we
still need to verify whether they are authorized to perform some
action, achieve some access, sign some document, etc.
SPKI certificates were designed to perform that function by directly
specifying the (permission,key) binding which is of interest in the
digital world. As merged with SDSI, the current certificate format
also allows someone to bind a key to a name in their own private name
space. The certificate structure presented here allows permissions
to be delegated to SDSI-named individuals or to raw keys.
"SPKI Requirements", C. Ellison, 03/19/1997,
<draft-ietf-spki-cert-req-00.txt>
The IETF Simple Public Key Infrastructure [SPKI] Working Group is
tasked with producing a certificate structure and operating procedure
to meet the needs of the Internet community for trust management in as
easy, simple and extensible a way as possible.
The SPKI WG first established a list of things one might want to do
with certificates (attached at the end of this document), and then
summarized that list of desires into requirements. This document
presents that summary of requirements.
Site Security Handbook (ssh)
----------------------------
"Users' Security Handbook", G. Malkin, Erik Guttman, 10/02/1997,
<draft-ietf-ssh-users-03.txt>
The Users' Security Handbook is the companion to the Site Security
Handbook (SSH). It is intended to provide users with the
information
they need to keep their networks and systems secure.
Guide for Internet Standards Writers (stdguide)
-----------------------------------------------
"Guide for Internet Standards Writers", Art Mellor, Peter Desnoyers, Greg
Scott, 05/28/1997, <draft-ietf-stdguide-ops-04.txt>
This document is a guide for Internet standard writers. It defines
those characteristics that make standards coherent, unambiguous, and
easy to interpret. Also, it singles out usage believed to have led to
unclear specifications, resulting in non-interoperable interpretations
in the past. These guidelines are to be used with RFC 1543,
'Instructions to RFC Authors.'
This version of the document is a draft. It is intended to generate
further discussion and addition by the STDGUIDE working group. Please
send comments to stdguide@midnight.com.
Service Location Protocol (svrloc)
----------------------------------
"Finding Stuff (How to discover services)", M. Hamilton, P. Leach, R.
Moats, 10/31/1997, <draft-ietf-svrloc-discovery-05.txt>
This document proposes a solution to the problem of finding
information about which services are being offered at a particular
Internet domain. Therefore, it is possible for clients, using this
approach, to locate services in a domain with only prior knowledge
of
the domain name.
"Service Location Modifications for IPv6", John Veizades, Erik Guttman,
02/05/1997, <draft-ietf-svrloc-ipv6-01.txt>
The Service Location Protocol provides a scalable framework for the
discovery and selection of network services. Using this protocol,
computers using the Internet no longer need so much static
configuration of network services for network based applications. This
is especially important as computers become more portable, and users
less tolerant or able to fulfill the demands of network administration.
The Service Location Protocol is well defined for use over IPv4
networks [SLP]: This document defines its use over IPv6 networks.
Since this protocol relies on UDP and TCP, the changes to support its
use over IPv6 are minor.
"Service Templates and service: Schemes", C. Perkins, Erik Guttman,
James Kempf, 10/15/1997, <draft-ietf-svrloc-service-scheme-03.txt>
The 'service:' URL scheme name is used to define URLs (called
'service: URLs' in this document) that are primarily intended to be
used by the Service Location Protocol in order to distribute service
access information. These schemes provide an extensible framework
for client-based network software to obtain configuration
information
required to make use of network services. When registering a
service: URL, the URL SHOULD be accompanied by a set of well-defined
attributes which define the service. These attributes SHOULD
convey configuration information to client software, or service
characteristics meaningful to end users.
"An API for Service Location", D. Provan, Erik Guttman, 03/25/1997,
<draft-ietf-svrloc-api-01.txt>
The Service Location Protocol coupled with the Service Location API
provide a new way for clients to dynamically discovery network
services. It is simple to offer highly available services which
require no user configuration or communication with network
administrators prior to use. The document includes examples and
applications. Client software modified to use
Service Location can make very simple requests to find service by type
or by characteristic. The latter capability allows the client to choose
intelligently between services of the same type. Service software
modified to use Service Location may dynamically advertise its
characteristics and existence.
"Advertising Services (Providing information to support service
discovery)", M. Hamilton, R. Moats, 10/15/1997,
<draft-ietf-svrloc-advertising-03.txt>
This document proposes a solution to the problem of finding
information about that services are being offered at a particular
Internet domain, based on deployment experience with the Netfind
White Pages directory software.
This approach makes it possible to supply clients with more
information than the DNS aliases that have been widely deployed in
this role - notably the port numbers being used by servers.
However,
it is not without problems, and we have tried to take account of
these.
"The 'wp:' and 'yp:' Abstract Service Types", R. Moats, 10/14/1997,
<draft-ietf-svrloc-wpyp-01.txt>
This document presents definitions for the 'wp:' (white pages) and
'yp:' (yellow pages) abstract services.
"Wide Area Network Service Location", J. Rosenberg, H. Schulzrinne,
07/25/1997, <draft-ietf-svrloc-wasrv-00.txt>
This document discusses the problem of service location in wide area
networks. This problem arises when a user wishes to locate some
service, such as a media bridge, internet telephony gateway, H.323
Gate-keeper, unicast to multicast bridge, etc, which has some desired
characteristics, but whose location (in terms of IP address, domain, or
geographical location) is completely unknown, and may be anywhere on
the public Internet. We focus on the problem of locating Internet
Telephony Gateways (devices which connect an IP host to a POTS user).
This particular location problem is characteristic of the general
problem; furthermore, location of these devices is particularly
difficult. Generally, the service location mechanisms need to be
invoked for every call setup. This implies that the call setup delays
will include the time to locate the gateway, and these delays should
therefore be kept to a minimum. With large numbers of gateways, the
location mechanisms can potentially become a network, processing, and
storage intensive operation. A solution to the gateway location problem
must therefore be efficient and scalable in use of bandwidth, CPU
power, and disk storage.
"Conversion of LDAP Schemas to and from SLP Templates", Pete St. Pierre,
08/01/1997, <draft-ietf-svrloc-template-conversion-00.txt>
LDAP and SLP are both useful mechanisms for locating service related
information on a network. While they do perform similar functions,
the way in which the information they provide is formated is very
different. This document describes a set of rules and mappings for
translating between the ASN.1 based LDAP schema and an SLP Template
as described in the ``Service Template and service: Scheme''
draft.[1]
"Definition of lpr: URLs for use with Service Location", Pete St.
Pierre, 07/31/1997, <draft-ietf-svrloc-lpr-scheme-00.txt>
This document defined the service:lpr scheme and attributes
associated with it. This template is designed to be used in
conjuction with the Service Location Protocol [1], but may be
used with any directory service supporting attribute/value pair
registration.
TCP Implementation (tcpimpl)
----------------------------
"Known TCP Implementation Problems", Scott Dawson, Vern Paxson,
07/30/1997, <draft-ietf-tcpimpl-prob-01.txt>
This memo catalogs a number of known TCP implementation problems. The
goal in doing so is to improve conditions in the existing Internet by
enhancing the quality of current TCP/IP implementations.
"Some Testing Tools for TCP Implementors", S. Parker, C. Schmechel,
07/16/1997, <draft-ietf-tcpimpl-tools-00.txt>
Available tools for testing TCP implementations are catalogued by this
memo. Hopefully disseminating this information will encourage those
responsible for building and maintaing TCP to make the best use of
available tests. The type of testing the tool provides, the type of
tests it is capable of doing, and its availability is enumerated.
TCP Large Windows (tcplw)
-------------------------
"TCP Extensions for High Performance", David Borman, V. Jacobson, Bob
Braden, 02/25/1997, <draft-ietf-tcplw-high-performance-00.txt>
This memo presents a set of TCP extensions to improve performance over
large bandwidth*delay product paths and to provide reliable operation
over very high-speed paths. It defines new TCP options for scaled
windows and timestamps, which are designed to provide compatible
interworking with TCP's that do not implement the extensions. The
timestamps are used for two distinct mechanisms: RTTM (Round Trip Time
Measurement) and PAWS (Protect Against Wrapped Sequences). Selective
acknowledgments are not included in this memo.
This memo updates and obsoletes RFC-1323, a Proposed Standard, with
small clarifications and corrections.
TCP Over Satellite (tcpsat)
---------------------------
"Enhancing TCP Over Satellite Channels using Standard Mechanisms", Dan
Glover, M. Allman, 10/02/1997, <draft-ietf-tcpsat-stand-mech-00.txt>
The Transmission Control Protocol (TCP) provides reliable delivery
of data across any network path, including network paths containing
satellite channels. While TCP works over satellite channels there
are several mechanisms that enable TCP to more effectively utilize
the available capacity of the network path. This draft outlines
some of these TCP mitigations. At this time, all mitigations
discussed in this draft are IETF standards track mechanisms.
Transaction Internet Protocol (tip)
-----------------------------------
"Transaction Internet Protocol Version 2.0", Jim Lyon, J. Klein, Keith
Evans, 10/21/1997, <draft-lyon-itp-nodes-03.txt>
In many applications where different nodes cooperate on some work,
there is a need to guarantee that the work happens atomically. That
is, each node must reach the same conclusion as to whether the work
is to be completed, even in the face of failures. This document
proposes a simple, easily-implemented protocol for achieving this
end.
"Session Control Protocol V 2.0", S. Spero, Jim Lyon, J. Klein, Keith
Evans, 05/01/1997, <draft-evans-v2-scp-00.txt>
This document describes version 2.0 of the Session Control Protocol
(SCP)[1]. SCP provides a simple mechanism for creating multiple
lightweight connections over a single TCP connection. Several such
lightweight connections can be active simultaneously. SCP provides a
byte oriented service, but allows message boundaries to be marked.
Transport Layer Security (tls)
------------------------------
"Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)",
M. Hur, A. Medvinsky, 07/25/1997,
<draft-ietf-tls-kerb-cipher-suites-01.txt>
This document proposes the addition of new cipher suites to the TLS
protocol [1] to support Kerberos-based authentication. Kerberos
credentials are used to achieve mutual authentication and to establish
a master secret which is subsequently used to secure client-server
communication.
"The TLS Protocol Version 1.0", C. Allen, T. Dierks, 10/29/1997,
<draft-ietf-tls-protocol-04.txt>
This document specifies Version 1.0 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications privacy
over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.
Telnet TN3270 Enhancements (tn3270e)
------------------------------------
"TN3270 Enhancements", B. Kelly, 05/28/1997,
<draft-ietf-tn3270e-ver2-enhance-00.txt>
This document describes a protocol that more fully supports 3270
devices than do the existing tn3270 practices. Specifically, it
defines a method of emulating both the terminal and printer members of
the 3270 family of devices via Telnet; it provides for the ability of a
Telnet client to request that it be assigned a specific device-name
(also referred to as 'LU name' or 'network name'); finally, it adds
support for a variety of functions such as the ATTN key, the SYSREQ
key, and SNA response handling. This protocol is negotiated under the
TN3270E Telnet Option, and is unrelated to the Telnet 3270 Regime
Option as defined in RFC 1041[1].
"Base Definitions of Managed Objects for TN3270E Using SMIv2", K. White,
09/15/1997, <draft-ietf-tn3270e-tn3270-mib-03.txt>
The purpose of this memo is to define a Management Information Base
(MIB) for configuring and managing TN3270E Servers.
The MIB defined by this memo is intended to provide generic
support for both Host and Gateway TN3270E server implementations.
It is the intent that the MIB defined herein be extended
by subsequent memos to provide non-generic configuration support
and to enable TN3270E Response Time Collection.
It is the intent of this MIB to fully adhere to all prerequisite MIBs
unless explicitly stated. Deviations will be documented in
corresponding conformance statements. The specification of this MIB
will utilize the Structure of Management Information (SMI) for
Version 2 of the Simple Network Management Protocol Version (refer to
RFC1902, reference [1]).
"Definitions of Managed Objects for TN3270E Response Time Collection
Using SMIv2", Robert Moore, K. White, 10/08/1997,
<draft-ietf-tn3270e-rt-mib-01.txt>
The purpose of this memo is to define the protocol and the Management
Information Base (MIB) for performing response time data collection
on TN3270 and TN3270E sessions by a TN3270E Server. The response time
data collected by a TN3270E Server is structured to support both
validation of service level agreements and performance monitoring of
TN3270 and TN3270E Sessions. This MIB has as a prerequisite the
TN3270E-MIB reference [10].
DS1/DS3 MIB (trunkmib)
----------------------
"Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface
Types", D. Fowler, 06/02/1997, <draft-ietf-trunkmib-ds1-mib-06.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS1,
E1, DS2 and E2 interfaces. This document is a companion document with
Definitions of Managed Objects for the DS0, DS3/E3 and SONET/SDH
Interface Types, rfcTBD [19], rfcTBD [17] and rfcTBD [18].
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions. This memo does not specify a standard for the Internet
community. This document entirely replaces RFC 1406.
"Definitions of Managed Objects for the DS3/E3 Interface Type", Tracy
Brown, Kaj Tesink, D. Fowler, 06/02/1997,
<draft-ietf-trunkmib-ds3-mib-05.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS3
and E3 interfaces. This document is a companion document with
Definitions of Managed Objects for the DS0, DS1/E1/DS2/E2 and SONET/SDH
Interface Types, rfcTBD [14], rfcTBD [6] and rfcTBD [7].
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions. This memo does not specify a standard for the Internet
community. This document entirely replaces RFC 1407.
"Definitions of Managed Objects for the DS0 and DS0 Bundle Interface
Type", D. Fowler, 06/02/1997, <draft-ietf-trunkmib-ds0-mib-04.txt>
This memo defines an experimental portion of the Management Information
Base (MIB) for use with network management protocols in the Internet
community. In particular, it describes objects used for managing DS0
and DS0 Bundle interfaces. This document is a companion document with
Definitions of Managed Objects for the DS1/E1/DS2/E2, DS3/E3 and
SONET/SDH Interface Types, rfcTBD [6], rfcTBD [7] and rfc1595 [8].
This memo specifies a MIB module in a manner that is both compliant to
the SNMPv2 SMI, and semantically identical to the peer SNMPv1
definitions. This memo does not specify a standard for the Internet
community.
Uniform Resource Identifiers (uri)
----------------------------------
"The Handle System", D. Ely, W. Arms, 05/05/1997,
<draft-ietf-uri-urn-handles-00.txt>
The Handle System provides identifiers for digital objects and other
resources in distributed computer systems. These identifiers are known
as handles. The system ensures that handles are unique and that they
can be retained over long time periods. Since the system makes no
assumptions about the characteristics of the items that are identified,
handles can be used in a wide variety of systems and applications.
The handle system has the following components: naming authorities,
handle generators, the global handle server, local handle servers,
caching handle servers, client software libraries, proxy servers, and
administrative tools. For reasons of performance and availability, the
global, local, and caching servers are implemented as distributed
systems comprising many server computers. All components, except the
local handle server, have been implemented and are available for
general use by the research community. The handle system provides
all the capabilities listed in RFC1737, K. Sollins, L. Masinter,
'Functional Requirements for Uniform Resource Names', 12/20/1994.
Uniform Resource Locator Registration Procedures (urlreg)
---------------------------------------------------------
"Guidelines for new URL Schemes", Harald Alvestrand, Larry Masinter, D.
Zigmond, 10/27/1997, <draft-ietf-urlreg-guide-00.txt>
A Uniform Resource Locator (URL) is a compact string representation
of the location for a resource that is available via the Internet.
[RFC URL-SYNTAX] defines the general syntax and semantics of URLs.
This document provides guidelines for the definition of new URL
schemes and describes the process by which they are registered.
Uniform Resource Names (urn)
----------------------------
"Architectural Principles of Uniform Resource Name Resolution", K.
Sollins, 09/26/1997, <draft-ietf-urn-req-frame-04.txt>
This document addresses the issues of the discovery of URN (Uniform
Resource Name) resolver services that in turn will directly translate
URNs into URLs (Uniform Resource Locators) and URCs (Uniform Resource
Characteristics). The document falls into three major parts, the
assumptions underlying the work, the guidelines in order to be a
viable Resolver Discovery Service or RDS, and a framework for
designing RDSs. The guidelines fall into three principle areas:
evolvability, usability, and security and privacy. An RDS that is
compliant with the framework will not necessarily be compliant with
the guidelines. Compliance with the guidelines will need to be
validated separately.
"Namespace Identifier Requirements for URN Services", Patrik Faltstrom,
R. Iannella, 03/27/1997, <draft-ietf-urn-nid-req-01.txt>
Services that offer to resolve Uniform Resource Names implicitly
require that they support a persistent and reliable service for an
indeterminate length of time. This draft outlines the requirements for
any such service that wishes to participate as a Namespace Identifier.
"URI Resolution Services Necessary for URN Resolution", M. Mealling, R.
Daniel, 08/09/1997, <draft-ietf-urn-resolution-services-03.txt>
Retrieving the resource identified by a Uniform Resource Identifier
(URI) [3] is only one of the operations that can be performed on a URI.
One might also ask for and get a list of other identifiers that are
aliases for the original URI or a bibliographic description of the
resource the URI denotes, for example. This applies to both Uniform
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
Resource Characteristics (URCs) are discussed in this document but only
as descriptions of resources rather than identifiers.
A service in the network providing access to a resource may provide one
or some of these options, but it need not provide all of them. This
memo
specifies an initial set of these functions, to be used to describe the
functions provided by any given access service and the requirements
that
must be met when those operations are encoded in a protocol.
"Using Existing Bibliographic Identifiers as Uniform Resource Names", C.
Lynch, C. Preston, R. Daniel, 09/26/1997, <draft-ietf-urn-biblio-02.txt>
A system for Uniform Resource Names (URNs) must be capable
of supporting identifiers from existing widely-used naming
systems. This document discusses how three major
bibliographic identifiers (the ISBN, ISSN and SICI) can be
supported within the URN framework and the currently
proposed syntax for URNs.
"URN Syntax", R. Moats, 05/05/1997, <draft-ietf-urn-syntax-05.txt>
Uniform Resource Names (URNs) are intended to serve as persistent,
location-independent, resource identifiers. This document sets forward
the canonical syntax for URNs. A discussion of both existing legacy
and new namespaces and requirements for URN presentation and
transmission are presented. Finally, there is a discussion of URN
equivalence and how to determine it.
"A URN Namespace for IETF Documents", R. Moats, 07/14/1997,
<draft-ietf-urn-ietf-02.txt>
A system for Uniform Resource Names (URNs) must be capable of
supporting new naming systems. As an example of how a new namespace
may be proposed, this document presents a naming system based on the
RFC family of documents (RFCs, STDs, and FYIs) developed by the IETF
and published by the RFC editor and the minutes of working groups (WG)
and birds of a feather (BOF) meetings that occur during IETF
conferences. This namespace can be supported within the URN framework
and the currently proposed syntax for URNs.
100VG-AnyLAN MIB (vgmib)
------------------------
"Definitions of Managed Objects for IEEE 802.12 Repeater Devices", J.
Flick, 05/20/1997, <draft-ietf-vgmib-repeater-dev-04.txt>
This memo defines a 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 network repeaters based on
IEEE 802.12.
Virtual Router Redundancy Protocol (vrrp)
-----------------------------------------
"Virtual Router Redundancy Protocol", Peter Higginson, Bob Hinden, S.
Knight, Danny Mitzel, M. Shand, D. Whipple, D. Weaver, Peter Hunt,
10/27/1997, <draft-ietf-vrrp-spec-03.txt>
This memo defines the Virtual Router Redundancy Protocol (VRRP).
VRRP specifies an election protocol that dynamically allows a set of
routers running VRRP to backup each other on a LAN. The VRRP router
controlling one or more IP addresses is called the Master router,
and
forwards packets sent to these IP addresses. The election process
provides dynamic fail over in the forwarding responsibility should
the Master become unavailable. This allows any of the VRRP routers
IP addresses on the LAN to be used as the default first hop router
by
end-hosts. The advantage gained from using the VRRP is a higher
availability default path without requiring configuration of dynamic
routing or router discovery protocols on every end-host.
WWW Distributed Authoring and Versioning (webdav)
-------------------------------------------------
"HTTP-based Distributed Content Editing Scenarios", O. Lassila,
06/03/1997, <draft-ietf-webdav-scenarios-00.txt>
This document contains examples of distributed editing conducted
through HTTP. These scenarios have been developed by the Distributed
Authoring and Versioning Group in the course of specifying requirements
for distributed editing, and aim to demonstrate the concepts of
distributed editing. The document presents a logical hierarchy of
scenarios, separating actual editing actions from document management.
"Requirements for a Distributed Authoring and Versioning Protocol for the
World Wide Web", D. Durand, Jim Whitehead, J. Slein, F. Vitali,
09/23/1997, <draft-ietf-webdav-requirements-03.txt>
Current World Wide Web (WWW or Web) standards provide simple support
for applications which allow remote editing of typed data. In practice,
the existing capabilities of the WWW have proven inadequate to support
efficient, scalable remote editing free of overwriting conflicts.
This document presents a list of features in the form of requirements
for a Web Distributed Authoring and Versioning protocol which, if
implemented, would improve the efficiency of common remote editing
operations, provide a locking mechanism to prevent overwrite conflicts,
improve link management support between non-HTML data types, provide
a simple attribute-value metadata facility, provide for the creation
and reading of container data types, and integrate versioning into
the WWW.
"Extensions for Distributed Authoring and Versioning on the World Wide
Web -- WEBDAV", Jim Whitehead, D. Jensen, S. Carter, Y. Goland, A. Faizi,
10/15/1997, <draft-ietf-webdav-protocol-04.txt>
This Document specifies a set of methods and content-types
ancillary to HTTP/1.1 for the management of resource
properties,
simple name space manipulation, simple resource locking
(collision avoidance) and resource version control.
"WebDAV Tree Operations", Y. Goland, 10/09/1997,
<draft-ietf-webdav-depth-00.txt>
The WebDAV protocol specification [Goland et al., 1997] defines the
DELETE, COPY and MOVE methods. However these methods have a scope of
a single source resource. It is common for principals to wish to
perform a DELETE, COPY or MOVE on a collection and all its internal
members. This specification defines the DELETE-TREE, COPY-TREE and
MOVE-TREE methods that perform the equivalent of DELETE, COPY and
MOVE across a collection and all its progeny.
Web Transaction Security (wts)
------------------------------
"The Secure HyperText Transfer Protocol", A. Schiffman, E. Rescorla,
03/25/1997, <draft-ietf-wts-shttp-04.txt>
This memo describes a syntax for securing messages sent using the
Hypertext Transfer Protocol (HTTP), which forms the basis for the World
Wide Web. Secure HTTP (S-HTTP) provides independently applicable
security services for transaction confidentiality,
authenticity/integrity and non-repudiability of origin.
The protocol emphasizes maximum flexibility in choice of key management
mechanisms, security policies and cryptographic algorithms by
supporting option negotiation between parties for each transaction.
"Security Extensions For HTML", A. Schiffman, E. Rescorla, 03/25/1997,
<draft-ietf-wts-shtml-03.txt>
This memo describes a syntax for embedding S-HTTP negotiation
parameters in HTML documents. S-HTTP as described by
draft-ietf-wts-shttp-03.txt contains the concept of negotation headers
which reflect the potential receiver of a message's preferences as to
which cryptographic enhancements should be applied to the message. This
document describes a syntax for binding these negotiation parameters to
HTML anchors.