Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 1id-abstracts.txt < prev next >

Wrap

Text File | 1997-08-08 | 661KB | 11,155 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", Chris Newman, J. Myers, 06/24/1997, <draft-ietf-acap-spec-04.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)", Chris 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. "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", Chris 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, 04/21/1997, <draft-ietf-applmib-sysapplmib-08.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, 08/01/1997, <draft-ietf-applmib-wwwmib-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 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) [9] and the Application Management MIB (APPL-MIB) [10]. The WWW service statistics are based on an abstract document transfer protocol (DTP). This abstract protocol can be mapped on protocols like HTTP or 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). "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, 07/14/1997, <draft-ietf-asid-ldapv3-protocol-06.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, 07/14/1997, <draft-ietf-asid-ldapv3-attributes-06.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, 05/05/1997, <draft-ietf-asid-ldapv3ext-04.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 "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. "An Approach for Using Domains in LDAP Distinguished Names", Steve Kille, M. Wahl, 02/10/1997, <draft-ietf-asid-ldap-domains-01.txt> The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible distinguished names for providing unique identification of entries. distinguished names in currently-deployed X.500 directories have the properties that they are descriptive, hierarchical, and follow common organizational models. However, there is not today a registration mechanism to permit individuals and organizations to obtain distinguished names, regardless of their physical location. This document defines a mechanism by which a name registered with the Internet Domain Name Service [1], for which there are active registration services, can be represented as a distinguished name so that it may be used with the LDAP protocol. This is not intended to have LDAP replace the DNS protocol, but to permit further deployment of LDAP into organizations connected to the Internet. This algorithm automatically assigns a distinguished name to any enterprise which has obtained a domain name for use in the Internet. This distinguished name may be used as a prefix for their names of entries in that enterprise. This document does not define how to represent objects which do not have domain names. Several RFCs, such as [3] and [4], and "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]. "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. "WHOIS++ templates", J. Knight, Patrik Faltstrom, M. Hamilton, Leslie Daigle, 07/28/1996, <draft-ietf-asid-whois-schema-01.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++. "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, 06/09/1997, <draft-ietf-asid-ldapv3-url-03.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, 05/02/1997, <draft-ietf-asid-ldapv3-filter-02.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, 07/14/1997, <draft-ietf-asid-ldapv3schema-x500-01.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. "An Approach for Using LDAP as a Network Information Service", L. Howard, 07/14/1997, <draft-ietf-asid-nis-schema-02.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. "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, 06/06/1997, <draft-ietf-asid-ldapv3-tls-01.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, 07/25/1997, <draft-ietf-asid-ldap-java-api-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. It updates and replaces draft-weltman-java-ldap-01.txt [12], in adding support for version 3 of the LDAP protocol. Other additions and corrections are listed in the appendix. "Schema for Replication Information", G. Good, U. Srinivasan, S. Jain, 07/28/1997, <draft-ietf-asid-ldap-repl-info-00.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. 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, 08/05/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 for Redundant Audio Data", Mark Handley, C Perkins, I Kouvelas, O Hodson, Jean-Chrysostome Bolot, Andres Vega-Garcia, Sacha Fosse-Parisis, 08/01/1997, <draft-ietf-avt-rtp-redundancy-01.txt,.ps> This document describes a payload format for use with the real-time transport protocol (RTP), version 2, for encoding redundant audio data. The primary motivation for the scheme described herein is the development of audio conferencing tools for use with lossy packet networks such as the Internet Mbone, although this scheme is not limited to such applications. "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", Bernard 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. Benchmarking Methodology (bmwg) ------------------------------- "Benchmarking Terminology for LAN Switching Devices", B. Mandeville, 08/07/1997, <draft-ietf-bmwg-lanswitch-06.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 document 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, 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, 08/02/1997, <draft-ietf-calsch-ical-02.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 document 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 document 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 document is to be known as the iCalendar specification. This document is based on the calendaring and scheduling model defined in [ICMS]. The document is also the basis for the calendaring and scheduling interoperability protocol defined in [ITIP-1], [ITIP-2] and [ITIP-3]. "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, 05/02/1997, <draft-ietf-calsch-imip-00.txt> This document defines an iCalendar Message-based Interoperability Protocol (iMIP), intended to be used to convey calendaring and scheduling semantics between different applications. This document is also being offered as a specification for demonstrating industry-wide, calendaring and scheduling interoperability. The message-based protocol defined by this document is useful not only in traditional electronic messaging (e-mail) transports, but also is applicable for conveying calendaring and scheduling information across any reliable transport; including memory-based clipboards, drag/drop protocols, wireless pagers, and the Infra-red Data Association (IrDA) object transfer protocol. This format is useful for both client-to-server communication, server-to-server communication, and client-to-client, peer communication (e.g., PDA synchronization with a PIM). This design document is heavily based on the prior work of the Versit Consortium's Personal Data Interchange (PDI) project team; including the vCard v2.1 and the vCalendar v1.0 specifications. More information about the PDI project and these documents can be found on the Internet Mail Consortium (IMC) website "Internet Calendar Model Specification", John Noerenberg, 08/01/1997, <draft-ietf-calsch-mod-01.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) Part Two: Scheduling To-Dos", F. Dawson, R. Hopson, 07/22/1997, <draft-ietf-calsch-itip-part2-00.txt> This set of documents, collectively called the iCalendar Transport-independent Interoperability Protocol, or iTIP, defines a transport-independent message protocol to allow for searching for busy time and the scheduling of events, journals, or journal entries on different calendaring and scheduling systems. These documents are based on earlier work documented in the iCalendar format. Because iCalendar delt mainly with the format of calendaring information and said so little about the method for conveying scheduling semantics, these documents add scheduling semantics to the base calendaring functionality defined in iCalendar. "iCalendar Transport-Independent Interoperability Protocol (iTIP) Part Three - Scheduling Journal Entries", F. Dawson, R. Hopson, 07/22/1997, <draft-ietf-calsch-itip-part3-00.txt> This set of documents, collectively called the iCalendar Transport-independent Interoperability Protocol, or iTIP, defines a transport-independent message protocol to allow for searching for busy time and the scheduling of events, journal entries, or journal entries on different calendaring and scheduling systems. These documents are based on earlier work documented in the iCalendar format. Because iCalendar delt mainly with the format of calendaring information and said so little about the method for conveying scheduling semantics, these documents add scheduling semantics to the base calendaring functionality defined in iCalendar. "iCalendar Transport-Independent Interoperability Protocol (iTIP) Part One: Scheduling Events and BusyTime", R. Hopson, S. Mansour, S. Silverberg, 07/22/1997, <draft-ietf-calsch-itip-part1-00.txt> This set of documents, collectively called the iCalendar Transportindependent Interoperability Protocol, or iTIP, defines a transport independent message protocol to allow for searching busy time and the scheduling of events, to-dos, or journal entries on different calendaring and scheduling systems. These documents are based on earlier work documented in the iCalendar format. Because iCalendar dealt mainly with the format of calendaring information and said so little about the method for conveying scheduling semantics, these documents are largely orthogonal to (rather than a revision of) iCalendar. Common Authentication Technology (cat) -------------------------------------- "FTP Security Extensions", M. Horowitz, S. Lunt, 11/26/1996, <draft-ietf-cat-ftpsec-09.txt> This document defines extensions to the FTP specification RFC 959, 'FILE TRANSFER PROTOCOL (FTP)' (October 1985). These extensions provide strong authentication, integrity, and confidentiality on both the control and data channels with the introduction of new optional commands, replies, and file transfer encodings. The following new optional commands are introduced in this specification: AUTH (Authentication/Security Mechanism), ADAT (Authentication/Security Data), PROT (Data Channel Protection Level), PBSZ (Protection Buffer Size), CCC (Clear Command Channel), MIC (Integrity Protected Command), CONF (Confidentiality Protected Command), and ENC (Privacy Protected Command). A new class of reply types (6yz) is also introduced for protected replies. None of the above commands are required to be implemented, but interdependencies exist. These dependencies are documented with the commands. Note that this specification is compatible with RFC 959. "Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API)", C. Adams, 03/25/1997, <draft-ietf-cat-idup-gss-07.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). "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. "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. "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. 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", Yakov 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, Yakov 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. "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/01/1997, <draft-ietf-dhc-mdhcp-01.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. "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. "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. "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, 07/23/1997, <draft-ietf-dhc-netware-options-00.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. "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. "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. "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. "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. "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. 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, 07/28/1997, <draft-ietf-dnsind-ncache-04.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 nullifying 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 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, 08/02/1997, <draft-ietf-dnsind-test-tlds-01.txt> To reduce the likelihood of conflict and confusion, four top level domain names are reserved for use in testing and as examples in documentation. 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", Charlie Kaufman, Don Eastlake, 07/24/1997, <draft-ietf-dnssec-secext2-00.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 still be provided even through non-security aware DNS servers in many cases. The extensions also 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 the existing Proposed Standard in RFC 2065. 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, 07/21/1997, <draft-ietf-drums-abnf-03.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 enhancements. "Mail Header Registration Procedure", J. Palme, 01/16/1997, <draft-ietf-drums-MHRegistry-00.txt> Various IETF standards and e-mail software products use various e-mail header fields. This memo specifies a procedure for the registration of e-mail header field names, to reduce the risk that two different mail products use the same header name in different ways. A proposed initial content of the header name registry at start-up is specifed in an appendix to this ietf-draft. "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. 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, 08/02/1997, <draft-bierman-entmib-compid-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 physical topology identification and discovery. Internet Fax (fax) ------------------ "Tag Image File Format (TIFF) - Application F", G. Parsons, James Rafferty, 08/01/1997, <draft-ietf-fax-tiff-03.txt> This document references the Tag Image File Format (TIFF) to formally define the application F of TIFF as a file format that may be used to store facsimile images. "File Format for Internet Fax", Steve Zilles, L. McIntyre, 07/31/1997, <draft-ietf-fax-tiffplus-01.txt> This Internet Draft describes the TIFF representation of the image data specified by the ITU-T Recommendations for black-and-white and color facsimile. The document provides a standard definition for TIFF-F (also known as TIFF Class F), which is used for a subset of black-and-white facsimile, and standard definitions for the TIFF representation of the ITU-T Recommendations for facsimile, including color facsimile. For the most part, existing TIFF constructs and fields are used; new TIFF fields are introduced as necessary. The document also describes the refinement of the registration of the MIME type image/tiff. "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", G. Parsons, James Rafferty, 08/01/1997, <draft-ietf-fax-tiff-reg-01.txt> This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. "Capabilities Exchange and Immediate Delivery over ESMTP", N. Joffe, 07/14/1997, <draft-ietf-fax-transport-00.txt> This document describes extensions to SMTP to allow capabilities exchange and immediate (session mode) delivery of messages. These extensions are intended primarily for fax, but may have other uses. Common Indexing Protocol (find) ------------------------------- "A Tagged Index Object for use in the Common Indexing Protocol", Roland Hedberg, R. Moats, M. Wahl, B. Greenblatt, 07/21/1997, <draft-ietf-find-cip-tagged-02.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 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, 05/27/1997, <draft-ietf-find-cip-soif-01.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 "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 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) -------------------------- "FTP Extensions for Variable Protocol Specification", S. Ostermann, M. Allman, 03/26/1997, <draft-allman-ftp-variable-04.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. "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. "FTP Security Considerations", S. Ostermann, M. Allman, 01/21/1997, <draft-allman-ftp-sec-consider-01.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. "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 Security Incident Response", Nevil Brownlee, Erik Guttman, 07/21/1997, <draft-ietf-grip-framework-irt-06.txt> The purpose of this document is to express the general Internet community's expectations of Security Incident Response Teams (SIRTs). 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. SIRT constituents have a legitimate need and right to fully understand the policies and procedures of 'their' 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 SIRT. An outline of such a template and a filled in example are provided. Humanities and Arts (harts) --------------------------- "Humanities and Arts: Sharing Center Stage on the Internet", W. Stickle, Janet Max, 07/25/1997, <draft-ietf-harts-guide-03.txt> This document is designed primarily for individuals who have limited knowledge of, or experience with, the Internet. The purpose of this document is to provide members of the Arts and Humanities communities with an introduction to the Internet as a valuable tool, resource, and medium for the creation, presentation, and preservation of Arts and Humanities-based content. The intended audience is practicing artists, scholars, related professionals, and others whose knowledge, expertise and support is important to ensuring that the Arts and Humanities are well-placed in the global information infrastructure. 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, 07/25/1997, <draft-ietf-http-negotiation-03.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. "Simple Hit-Metering and Usage-Limiting for HTTP", J Mogul, P. Leach, 07/07/1997, <draft-ietf-http-hit-metering-03.txt> This document proposes a simple extension to HTTP, using a new ``Meter'' header, which permits a limited form of demographic information (colloquially called ``hit-counts'') to be reported by caches to origin servers, in a more efficient manner than the ``cache-busting'' techniques currently used. It also permits an origin server to control the number of times a cache uses a cached response, and outlines a technique that origin servers can use to capture referral information without ``cache-busting.'' "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, 08/01/1997, <draft-ietf-http-state-man-mec-03.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, 03/19/1997, <draft-ietf-http-uahint-00.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 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 (Rev 1)", D. Jaye, 05/14/1997, <draft-ietf-http-jaye-trust-state-00.txt> This document specifies an addition to the state management protocol specified in RFC 2109. The intent is to provide a mechanism that allows user agents to determine the trust and privacy policies of a server and to accept or reject cookies based on that policy. Allowing the user to decide whether to accept cookies based on the server's policies and trust level provides control over privacy. To provide such information about server privacy behavior, we assume the existence of an independent Trust Authority (or authorities), such as eTrust. The authority establishes levels of 'trust' and can audit domains to determine their adherence to a given level. It then issues TrustLabels, in the form of signed PICS labels, to domains based on the trust level. Passing those TrustLabels along with cookies allows the user-agent to support cookie acceptance rules based on trust level. This document describes a new header, Set-PICS-Cookie, that extends the Set-Cookie2 header in RFC2109[Kristol] to allow PICS labels that certify trust levels of domains (which we will call TrustLabels) to be sent along with 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/04/1997, <draft-ietf-http-options-01.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. 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. Inter-Domain Multicast Routing (idmr) ------------------------------------- "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. "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. "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --", Tony Ballardie, 07/07/1997, <draft-ietf-idmr-cbt-spec-10.txt> This document describes the Core Based Tree (CBT version 2) network layer multicast routing protocol. CBT builds a shared multicast distribution tree per group, and is suited to inter- and intra-domain multicast routing. CBT may use a separate multicast routing table, or it may use that of underlying unicast routing, to establish paths between senders and receivers. The CBT architecture is described in [1]. This document is progressing through the IDMR working group of the IETF. CBT related documents include [1, 5, 6]. For all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr. "Core Based Trees (CBT) Multicast Routing Architecture", Tony Ballardie, 05/12/1997, <draft-ietf-idmr-cbt-arch-06.txt> CBT is a multicast routing architecture that builds a single delivery tree per group which is shared by all of the group's senders and receivers. Most multicast algorithms build one multicast tree per sender (subnetwork), the tree being rooted at the sender's subnetwork. The primary advantage of the shared tree approach is that it typically offers more favourable scaling characteristics than all other multicast algorithms. The CBT protocol [1] is a network layer multicast routing protocol that builds and maintains a shared delivery tree for a multicast group. The sending and receiving of multicast data by hosts on a subnetwork conforms to the traditional IP multicast service model [2]. CBT is progressing through the IDMR working group of the IETF. The CBT protocol is described in an accompanying document [1]. For this, and all IDMR-related documents, see http://www.cs.ucl.ac.uk/ietf/idmr "Internet Group Management Protocol, Version 2", Bill Fenner, 01/22/1997, <draft-ietf-idmr-igmp-v2-06.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, 02/18/1997, <draft-ietf-idmr-dvmrp-v3-04.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]. "Core Based Tree (CBT) Multicast Border Router Specification for Connecting a CBT Stub Region to a DVMRP Backbone", Tony Ballardie, 03/07/1997, <draft-ietf-idmr-cbt-dvmrp-00.txt> This document specifies the behaviour of CBT multicast border router interconnecting a CBT multicast stub domain (region) to a DVMRP [1] multicast backbone. The document provides guidelines that are intended to be generally aligned with the mechanisms described in the 'Interoperability Rules for Multicast Routing Protocols' [2]. Certain aspects of those rules may be interpreted and implemented differently, and therefore some discretion is left to the implementor. This document assumes the reader is familiar with the CBT protocol [3]. "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. "Grand Unified Multicast (GUM): Protocol Specification", Deborah Estrin, David Meyer, D. Thaler, 08/02/1997, <draft-ietf-idmr-gum-00.txt> This document describes GUM, a protocol for inter-domain multicast routing. GUM 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, GUM requires that each multicast group be associated with a single root (in GUM it is referred to as the root domain). GUM 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. Inter-Domain Routing (idr) -------------------------- "A Border Gateway Protocol 4 (BGP-4)", Yakov Rekhter, Tony Li, 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. 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. "A Common Schema for the Internet White Pages Service", Tony Genovese, B. Jennings, 06/06/1997, <draft-ietf-ids-iwps-schema-spec-06.txt> This work is the result of the IETF Integrated Directory Services (IDS) Working Group. The IDS Working Group proposes a standard specification for a simple Internet White Pages service by defining a common schema for use by the various White Pages servers. This schema is independent of specific implementations of the White Pages service. This document specifies the minimum set of core attributes of a White Pages entry for an individual and describes how new objects with those attributes can be defined and published. It does not describe how to represent other objects in the White Pages service. Further, it does not address the search sort expectations within a particular service. "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. "Use of DNS Aliases for Network Services", R. Wright, M. Hamilton, 01/31/1997, <draft-ietf-ids-dnsnames-02.txt> It has become a common practice to use symbolic names (usually CNAMEs) in the Domain Name Service (DNS - [RFC-1034, RFC-1035]) to refer to network services such as anonymous FTP [RFC-959] servers, Gopher [RFC-1436] servers, and most notably World-Wide Web HTTP [RFC-1945] servers. This is desirable for a number of reasons. It provides a way of moving services from one machine to another transparently, and a mechanism by which people or agents may programatically discover that an organization runs, say, a World-Wide Web server. Although this approach has been almost universally adopted, there is no standards document or similar specification for these commonly used names. This document seeks to rectify this situation by gathering together the extant 'folklore' on naming conventions, and proposes a mechanism for accommodating new protocols. It is important to note that these naming conventions do not provide a complete long term solution to the problem of finding a particular network service for a site. There are efforts in other IETF working groups to address the long term solution to this problem, such as the Server Location Resource Records (DNS SRV) [RFC-2052] work. "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 an Internet Directory Service", Steve Kille, Sri Sataluri, A. Grimstad, M. Wahl, 03/19/1997, <draft-ietf-ids-dirnaming-01.txt> Application of the conventional X.500 approach to naming has, in the experience of the authors, proven to be an obstacle to the creation of directory services. 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 recommended X.500 approach to naming. Interfaces MIB (ifmib) ---------------------- "The Interfaces Group MIB", Frank Kastenholz, Keith McCloghrie, 11/26/1996, <draft-ietf-ifmib-mib-05.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. "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) ----------------------------- "Network Element Service Specification Template", S. Shenker, John Wroclawski, 11/27/1996, <draft-ietf-intserv-svc-template-03.txt> This document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a 'template' which service specification documents should follow. The specification template includes per-element requirements such as the service's packet handling behavior, parameters required and made available by the service, traffic specification and policing requirements, and traffic ordering relationships. It also includes evaluation criteria for elements providing the service, and examples of how the service might be implemented (by network elements) and used (by applications). "Specification of Guaranteed Quality of Service", C. Partridge, S. Shenker, R. Guerin, 07/07/1997, <draft-ietf-intserv-guaranteed-svc-08.txt> This memo describes the network element behavior required to deliver a guaranteed service (guaranteed delay and bandwidth) in the Internet. Guaranteed service provides firm (mathematically provable) bounds on end-to-end datagram queueing delays. This service makes it possible to provide a service that guarantees both delay and bandwidth. This specification follows the service specification template described in [1]. "General Characterization Parameters for Integrated Service Network Elements", S. Shenker, John Wroclawski, 07/03/1997, <draft-ietf-intserv-charac-03.txt> This memo defines a set of general control and characterization parameters for network elements supporting the IETF integrated services QoS control framework. General parameters are those with common, shared definitions across all QoS control services. "Integrated Services Management Information Base", Fred Baker, John Krawczyk, 07/11/1997, <draft-ietf-intserv-mib-09.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. "Specification of the Controlled-Load Network Element Service", John Wroclawski, 05/29/1997, <draft-ietf-intserv-ctrl-load-svc-05.txt> This memo specifies the network element behavior required to deliver Controlled-Load service in the Internet. Controlled-load service provides the client data flow with a quality of service closely approximating the QoS that same flow would receive from an unloaded network element, but uses capacity (admission) control to assure that this service is received even when the network element is overloaded. "Integrated Services Management Information Base Guaranteed Service Extensions", Fred Baker, 01/31/1997, <draft-ietf-intserv-guaranteed-mib-03.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 Guaranteed Service of 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. "The Use of RSVP with IETF Integrated Services", John Wroclawski, 07/03/1997, <draft-ietf-intserv-rsvp-use-02.txt> This note describes the use of the RSVP resource reservation protocol with the Controlled-Load and Guaranteed QoS control services. The RSVP protocol defines several data objects which carry resource reservation information but are opaque to RSVP itself. The usage and data format of those objects is given here. "A Measurement Based Admission Control Algorithm for Controlled-Load Service", L. Breslau, S. Jamin, 04/17/1997, <draft-ietf-intserv-control-flow-00.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 must 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. Internetworking Over NBMA (ion) ------------------------------- "Management Information Base for Frame Relay DTEs", Fred Baker, C. Brown, 05/01/1997, <draft-ietf-iplpdn-frmib-dte-10.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)", Dave Katz, David Piscitello, B. Cole, J. Luciani, 03/05/1997, <draft-ietf-rolc-nhrp-11.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. "IP Broadcast over ATM Networks", G. Armitage, T. Smith, 07/22/1997, <draft-ietf-ion-bcast-04.txt> This memo describes how the IP multicast service being developed by the IP over ATM working group may be used to support IP broadcast transmission. The solution revolves around treating the broadcast problem as a special case of multicast, where every host in the subnet or cluster is a member of the group. An understanding of the services provided by RFC 2022 is assumed. "Classical IP and ARP over ATM", Mark Laubach, Joel Halpern, 04/22/1997, <draft-ietf-ion-classic2-02.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 'wires' and local LAN segments connecting IP end-stations ('members') and routers operating in the 'classical' LAN-based paradigm. Issues raised by MAC level bridging and LAN emulation are beyond the scope of this paper. This memo introduces general ATM technology and nomenclature. Readers are encouraged to review the ATM Forum and ITU-TS (formerly CCITT) references for more detailed information about ATM implementation agreements and standards. "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, 04/16/1997, <draft-ietf-ion-scsp-01.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, 05/29/1997, <draft-ietf-ion-sig-uni4.0-04.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 1577 [LAUB94] 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]. "Transient Neighbors for IPv6 over ATM", G. Armitage, M. Jork, P. Schulter, G. Harter, 07/29/1997, <draft-ietf-ion-tn-01.txt> This document describes an architecture and protocols for IPv6 over ATM. It allows conventional host-side operation of the Neighbor Discovery protocol, while also supporting the establishment of 'shortcut' ATM forwarding paths. This is achieved through the use of Redirects to create Transient Neighbors, standard IPv6 protocol operation within the IPv6 Logical Link, and inter-router NHRP for location of off-Link destinations. Shortcuts are discovered by egress routers when triggered either by detection of suitable packet flows, or source host initiation. NHRP is used to locate a better link level first hop, and the result is announced to the source host using a Neighbor Discovery Redirect message. "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, 06/23/1997, <draft-ietf-ion-mars-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 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", Yakov 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", Yakov Rekhter, D. Farinacci, David Meyer, 04/25/1997, <draft-ietf-ion-intralis-multicast-00.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, 04/16/1997, <draft-ietf-ion-scsp-nhrp-01.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. "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]. IP Over IEEE 1394 (ip1394) -------------------------- "IP over IEEE 1394 (High Performance Serial Bus) Revision 1a", Peter Johansson, 07/28/1997, <draft-ietf-ip1394-high-perform-02.txt> 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 (IP) 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) ---------------------------------- "Radio Frequency (RF) Interface Management Information Base for MCNS compliant RF interfaces", G. Roeck, 07/08/1997, <draft-ietf-ipcdn-rf-interface-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 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. "Cable Modem Management Information Base for MCNS compliant Cable Modems", G. Roeck, 07/08/1997, <draft-ietf-ipcdn-cable-modem-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 defines a basic set of managed objects for SNMP-based management of MCNS compliant Cable Modems. 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. 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, Dave 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 FDDI Networks", M. Crawford, 07/25/1997, <draft-ietf-ipngwg-trans-fddi-net-02.txt> This memo specifies the MTU and frame format for transmission of IPv6 packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the 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. 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 [KWORD]. "Transmission of IPv6 Packets over Ethernet Networks", M. Crawford, 07/25/1997, <draft-ietf-ipngwg-trans-ethernet-02.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. "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. "IPng Analysis of the GSE Proposal", Lixia Zhang, J. Stewart, Thomas Narten, M. Crawford, 03/27/1997, <draft-ietf-ipngwg-esd-analysis-00.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 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 would not need to know the RG portion of their addresses. Border routers residing between a Site and its 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. "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 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. "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. "Transmission of IPv6 Packets over Token Ring Networks", S. Thomas, 06/16/1997, <draft-ietf-ipngwg-trans-tokenring-00.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, 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)",, 07/30/1997, <draft-ietf-ipngwg-discovery-v2-02.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 Printing Protocol (ipp) -------------------------------- "Requirements for an Internet Printing Protocol", F. Wright, 03/24/1997, <draft-ietf-ipp-req-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. Although DPA identifies the both end user and administrative features, IPP is initially focused only on the end user functionality. "Internet Printing Protocol/1.0: Model and Semantics", P. Powell, T. Hasting, R. Herriot, S. Isaacson, R. deBry, 08/02/1997, <draft-ietf-ipp-model-04.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 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, 07/16/1997, <draft-ietf-ipp-protocol-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 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 only on end user functionality. "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 Using LZS", R. Monsour, 07/31/1907, <draft-ietf-ippcp-lzs-00.txt> This document describes a IP compression method based on the LZS compression algorithm. This document defines the application of the LZS algorithm to the IP Payload Compression Protocol [Thomas]. [Thomas] defines a method for applying lossless compression to the payloads of Internet Protocol datagrams. "IP Payload Compression Protocol (IPComp)", A. Shacham, 07/21/1997, <draft-ietf-ippcp-protocol-00.txt> This memo describes a protocol intended to provide compression services for IP datagrams in an Internet environment. "IP Payload Compression Protocol Architecture", R. Monsour, A. Shacham, 07/30/1997, <draft-ietf-ippcp-arch-00.txt> This memo describes an architecture for applying lossless compression to Internet Protocol datagrams. It defines several of the key architectural elements of a compression protocol and describes alternatives for each element. 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. "HMAC-SHA IP Authentication with Replay Prevention", R. Glenn, S. Chang, 11/20/1996, <draft-ietf-ipsec-ah-hmac-sha-04.txt> This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [HMAC-MD5]. An option is also specified to guard against replay attacks. "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, 07/22/1997, <draft-ietf-ipsec-auth-header-01.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. "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, 03/03/1997, <draft-ietf-ipsec-ipsec-doi-02.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 Internet IP Security DOI, which is defined to cover the IP security protocols that use ISAKMP to negotiate their security associations. "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. "HMAC-SHA-1-96 IP Authentication with Replay Prevention", R. Glenn, S. Chang, 03/20/1997, <draft-ietf-ipsec-ah-hmac-sha-1-96-00.txt> This document describes a keyed-SHA transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [RFC-2104]. A replay prevention field is also specified. "HMAC-MD5-96 IP Authentication with Replay Prevention", M. Oehler, R. Glenn, 03/21/1997, <draft-ietf-ipsec-ah-hmac-md5-96-00.txt> This document describes a keyed-MD5 transform to be used in conjunction with the IP Authentication Header [RFC-1826]. The particular transform is based on [RFC-2104]. A replay prevention field is also specified. "IP Encapsulating Security Payload (ESP)", Stephen Kent, Ran Atkinson, 03/28/1997, <draft-ietf-ipsec-new-esp-00.txt> The Encapsulating Security Payload (ESP) header is designed to provide a mix of optional security services in IPv4 and IPv6. ESP may be applied alone, in combination with the IP Authentication Header (AH) [KA97b], or in a nested fashion, e.g., through the use of tunnel mode (see below). 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. For more details on how to use ESP and AH in various network environments, see 'Security Architecture for the Internet Protocol' [KA97a]. "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. "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]. "IP Encapsulating Security Payload (ESP)", Stephen Kent, Ran Atkinson, 07/22/1997, <draft-ietf-ipsec-esp-v2-00.txt> The Encapsulating Security Payload (ESP) header is designed to provide a mix of security services in IPv4 and IPv6. "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. 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. "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. "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. "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, 03/03/1997, <draft-ietf-madman-mail-monitor-mib-03.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, 03/03/1997, <draft-ietf-madman-nsm-mib-04.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. 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, 03/20/1997, <draft-ietf-mboned-intro-multicast-02.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", Bernard 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 E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", A. Hopmann, J. Palme, 07/07/1997, <draft-ietf-mhtml-rev-00.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'. Temporary note This is a revision of RFC 2110 to take into account problems which have cropped up by developers when developing software adhering to RFC 2110. RFC 2110 is an IETF Proposed Standard, and the intention is that this document, possibly after more revisions, will either be submitted as a revised Proposed Standard or as a Draft Standard. "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. 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. "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. "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. "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. Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- "SDP: Session Description Protocol", V. Jacobson, Mark Handley, 03/26/1997, <draft-ietf-mmusic-sdp-03.txt, .ps> This document defined the Session Description Protocol, SDP. SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of 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, 08/02/1997, <draft-ietf-mmusic-rtsp-03.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 delivery mechanisms based upon RTP (RFC 1889). "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, 03/27/1997, <draft-ietf-mmusic-sap-sec-00.txt> The Session Announcement Protocol (SAP) is specified in such a way that authentication and privacy can be assured. However but 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 the 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). 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, 03/26/1997, <draft-ietf-mobileip-tunnel-reverse-02.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 net, 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. 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. Individual Submissions (none) ----------------------------- "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard", K. Teow, 02/12/1997, <draft-teow-fabric-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 defines the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standard defined in [1], [2] and [3]. 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. There is a companion memo [10], that defines the objects for managing the operations of the Node portion of the Fibre Channel Standard (FC). "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). "Routing Aspects Of IPv6 Transition", Ross Callon, Dimitry Haskin, 04/21/1997, <draft-ietf-ngtrans-routing-aspects-03.txt> This internet draft gives an overview of the routing aspects of the IPv6 transition. It is based on the protocols defined in the document 'Transition Mechanisms for IPv6 Hosts and Routers' [1]. Readers should be familiar with the transition mechanisms before reading this document. The proposals contained in this document are based on the work of the Ngtrans working group. "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, 07/24/1997, <draft-simpson-photuris-15.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, 07/07/1997, <draft-ietf-mailext-new-fields-08.txt> This memo introduces three new e-mail (RFC 822) 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, 02/27/1997, <draft-myers-smtp-auth-05.txt> This document defines an extension to the SMTP service 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, 05/06/1997, <draft-prior-future-host-guidelines-01.txt> The IETF is an international group that conducts most of it's business using electronic mail however three times a year it contacts 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. "Simple Authentication and Security Layer (SASL)", J. Myers, 05/28/1997, <draft-myers-auth-sasl-11.txt> This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection. "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. "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, 07/24/1997, <draft-freed-charset-reg-02.txt> MIME [RFC-2045, RFC-2046, RFC-2047] 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. "SMTP Service Extension for Command Pipelining", C. Allan Cargille, Ned Freed, John Klensin, 07/24/1997, <draft-freed-smtp-pipeline-02.txt> This memo defines an extension to the SMTP service whereby a server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. The present document is an updated version of RFC 1854 [3]. Only textual and editorial changes have been made; the protocol has not changed in any way. "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. "Making Postscript and Acrobat Files International", J. Palme, 01/14/1997, <draft-palme-int-print-01.txt> Certain text formats, for example Postscript (extension .ps) and Adobe Acrobat (extension .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 'Letter' format, while the rest of the world uses the 'A4' format This means that documents formatted on one continent may not be easily printable on another continent. This memo gives advice on how to produce documents which are equally well printable with the Letter and the A4 formats. By using the advice in this document, you can put up a document on the Internet, which recipients can print without problem both in and outside America. A very short summary of the advice in this document: If you are using U.S. Letter paper format, ensure that both the left and right margins are at least 21 mm (0.82 inches). If you are using A4 paper format, ensure that both the top and bottom margins are at least 35 mm (1.38 inches). "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]. "VENUS - Very Extensive Non-Unicast Service", G. Armitage, 06/17/1997, <draft-armitage-ion-venus-03.txt> The MARS model (RFC2022) provides a solution to intra-LIS IP multicasting over ATM, establishing and managing the use of ATM pt-mpt SVCs for IP multicast packet forwarding. Inter-LIS multicast forwarding is achieved using Mrouters, in a similar manner to which the `Classical IP over ATM' model uses Routers to inter-connect LISes for unicast traffic. The development of unicast IP shortcut mechanisms (e.g. NHRP) has led some people to request the development of a Multicast equivalent. There are a number of different approaches. This document focuses exclusively on the problems associated with extending the MARS model to cover multiple clusters or clusters spanning more than one subnet. It describes a hypothetical solution, dubbed `Very Extensive NonUnicast Service' (VENUS), and shows how complex such a service would be. It is also noted that VENUS ultimately has the look and feel of a single, large cluster using a distributed MARS. This document is being issued to help focus ION efforts towards alternative solutions for establishing ATM level multicast connections between LISes. "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). "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. "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. "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", Dave Katz, Yakov Rekhter, Bruce Davie, 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, 03/25/1997, <draft-suzuki-st2-over-atm-01.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 IP Source Address Spoofing Denial of Service Attacks", P. Ferguson, D. Senie, 07/02/1997, <draft-ferguson-ingress-filtering-02.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 deny 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, 07/23/1997, <draft-souvatzis-ipv6-arcnet-02.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. "NFS URL Scheme", Brent Callaghan, 10/02/1996, <draft-callaghan-url-nfs-00.txt> A new URL scheme, 'nfs:' is defined. It is used to refer to files and directories on NFS servers. The scheme uses the public filehandle and multi-component lookup to access server data with a minimum of protocol overhead. The NFS protocol provides access to shared filesystems across networks. It is designed to be machine, operating system, network architecture, and transport protocol independent. The protocol currently exists in two versions: version 2 [RFC1094] and version 3 [RFC1813], both built on ONC RPC [RFC1831] at its associated eXternal Data Representation (XDR) [RFC1832] and Binding Protocol [RFC1833]. "IMAP URL Scheme", Chris Newman, 07/10/1997, <draft-newman-url-imap-10.txt> IMAP [IMAP4] is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server. "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. "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", Ned Freed, Keith Moore, 06/06/1997, <draft-freed-pvcsc-03.txt> This memo defines extensions to the RFC 2045 media type and RFC CDISP 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. "The Safe Response Header Field", K. Holtman, 08/01/1997, <draft-holtman-http-safe-02.txt> This document proposes a HTTP response header field called Safe, which can be used to indicate that repeating the corresponding POST request is safe. Such an indication will allow user agents to present services which use safe POSTs in a more user-friendly way. Improving the user-friendliness of safe POSTs is considered important, because web internationalization will depend for a large part on the use of safe POSTs. "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. "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. "Payload Format for HTTP Encoding in RTP", Bernard 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. "Internet Cache Protocol (ICP), version 2", K. Claffy, Duane Wessels, 05/28/1997, <draft-wessels-icp-v2-03.txt> This draft document describes version 2 of the Internet Cache Protocol (ICPv2) as currently implemented in two World-Wide Web proxy cache packages[3,5]. ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object. This document describes only the format and fields of ICP messages. A companion document (RFCXXXX, <draft-wessels-icp-v2-appl-01.txt>) describes the application of ICP to Web caches. Several independent caching implementations now use ICP, and we consider it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use for their own purposes. "Transaction Internet Protocol", Jim Lyon, J. Klein, Keith Evans, 02/10/1997, <draft-lyon-itp-nodes-01.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. "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. "PDC/NetApp Backup Protocol", D. Hitz, R. Stager, 04/30/1997, <draft-stager-pdc-netapp-backup-02.txt> The Network Data Management Protocol ('NDMP') is an open protocol for enterprise-wide network based backup. The NDMP architecture allows network-attached file servers to ship with a 'universal agent,' which can be used by any NDMP-compliant backup administration application. This same universal agent architecture is also used for network-attached backup devices, such as a 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, 07/03/1997, <draft-provan-dhcp-options-dir-serv-01.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, 05/02/1997, <draft-fielding-url-syntax-05.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, B. Polk, N. Ballou, 05/01/1997, <draft-ballou-nntpsrch-03.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, 02/27/1997, <draft-myers-sasl-pop3-01.txt> This document describes the optional AUTH command, 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, 03/21/1997, <draft-carpenter-ipng-6over4-02.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'. For the purposes of this document, an IPv4 domain is a fully interconnected set of IPv4 subnets on which there is at least one IPv6 router and at least one IPv6 host conforming to this specification. This IPv4 domain could form part of the globally unique IPv4 address space, or could form part of a private IPv4 network [RFC 1918]. This memo also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an IPv4 domain. "PF_KEY Key Management API, Version 2", D. McDonald, B. Phan, C. Metz, 07/15/1997, <draft-mcdonald-pf-key-v2-03.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", Yakov Rekhter, D. Farinacci, Tony Li, E. Rosen, G. Fedorkow, 06/26/1997, <draft-rosen-tag-stack-02.txt> 'Multi-Protocol Label Switching (MPLS)' [1,2] 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. "Architecture of the Resource Reservation Service for the Commercial Internet", M. Suzuki, 03/25/1997, <draft-suzuki-res-resv-svc-arch-01.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. "Date and Time on the Internet", Chris 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. "Telnet Com Port Control Option", G. Clark, 07/17/1997, <draft-clark-telnet-control-05.txt> This memo proposes a protocol to allow greater use of modems attached to a network for outbound dialing purposes. "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. "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. "Multiprotocol Extensions for BGP-4", Dave Katz, Yakov 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. "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, 03/25/1997, <draft-hoffman-mailto-url-01.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", Dave Katz, Yakov Rekhter, D. Farinacci, Bruce Davie, George Swallow, 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, 01/29/1997, <draft-rfced-info-banan-esro-00.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, 02/17/1997, <draft-pfenning-irc-extensions-01.txt> This document describes extensions to the Internet Relay Chat protocol defined in RFC 1459[1]. 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 extensions. 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 RFC 1459. "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, 02/12/1997, <draft-kunze-dc-00.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 description 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. "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", Keith Moore, R. Troost, S. Dorner, 07/10/1997, <draft-moore-mime-cdisp-01.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 presentational information. It specifies the 'Content-Disposition' header field, which is optional and valid for any MIME entity ('message' or 'body part'). Two values for this header field are described in this memo; one for the ordinary linear presentation of the body part, and another to facilitate the use of mail to transfer files. It is expected that more values will be defined in the future, and procedures are defined for extending this set of values. This document is intended as an extension to MIME. As such, the reader is assumed to be familiar with the MIME specifications, and [RFC 822]. The information presented herein supplements but does not replace that found in those documents. This document is a revision to the Experimental protocol defined in RFC 1806. As compared to RFC 1806, this document contains minor editorial updates, adds new parameters needed to support the File Transfer Body Part, and references a separate specification for the handling of non-ASCII and/or very long parameter values. "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. "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. "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. "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. "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. "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", Yakov 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, 03/19/1997, <draft-shiroshita-rmtp-spec-00.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. "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. "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, Bernard 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. "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. "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 "Test Cases for HMAC-MD5 and HMAC-SHA-1", P. Cheng, R. Glenn, 03/24/1997, <draft-cheng-hmac-test-cases-00.txt> This document provides two sets of test cases for HMAC-MD5 and HMAC-SHA-1, respectively. HMAC-MD5 and HMAC-SHA-1 are two constructs of the HMAC [HMAC] message authentication function using the MD5 [MD5] hash function and the SHA-1 [SHA] hash function. Both constructs are used by IPSEC [OG,CG] and other protocols to authenticate messages. The test cases and results provided in this document are meant to be used as a conformance test for HMAC-MD5 and HMAC-SHA-1 implementations. "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, 03/25/1997, <draft-baer-listspec-00.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 or http) 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. 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, 07/07/1997, <draft-dusse-smime-msg-02.txt> S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a standard 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, L. Lundblade, Paul Hoffman, L. Repka, B. Ramsdell, 05/07/1997, <draft-dusse-smime-cert-01.txt> S/MIME (Secure/Multipurpose Internet Mail Extensions), described in [SMIME-MSG], provides a standard way 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, 03/26/1997, <draft-kessens-ride-classes-00.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. "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. "Age Header Field in HTTP/1.1", R. Fielding, 03/26/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", Bernard 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, 03/26/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/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. "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. "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. "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. "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. "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. "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. "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. "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]. "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). "UTF-8, a transformation format of Unicode and ISO 10646", F. Yergeau, 04/16/1997, <draft-yergeau-utf8-rev-00.txt> ISO/IEC 10646-1 and the Unicode Standard jointly define a multi-octet character set 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. "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. "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 "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. "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, 06/25/1997, <draft-showalter-sieve-01.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 which uses multiple folders. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating systems used to implement it. It is not tied to any particular system or mail architecture. 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, and 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. "Application of Internet Cache Protocol (ICP), version 2", K. Claffy, Duane Wessels, 07/09/1997, <draft-wessels-icp-v2-appl-02.txt> This document describes the application of ICPv2 (Internet Cache Protocol version 2, RFCXXXX) to Web caching. ICPv2 is a lightweight message format used for communication among Web caches. Several independent caching implementations now use ICP[3,5], making it important to codify the existing practical uses of ICP for those trying to implement, deploy, and extend its use. ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object. A companion document (RFCXXXX) describes the format and syntax of the protocol itself. In this document we focus on issues of ICP deployment, efficiency, security, and interaction with other aspects of Web traffic behavior. "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. "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. "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, 04/28/1997, <draft-costales-subscribe-00.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, 04/28/1997, <draft-panabaker-ip-vbi-00.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. Keywords: VBI, NTSC, broadcast, push, FEC, television, NABTS, IP "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, 04/29/1997, <draft-engan-ip-compress-00.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 [IPv6HC] 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", Chris Newman, M. Gahrns, 06/10/1997, <draft-gahrns-imap-namespace-01.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 user's 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. "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. "A Protocol for the Transmission of Net News Articles over IP multicast.", H. Rupp, 06/10/1997, <draft-rfced-exp-rupp-02.txt> This 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 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 #1: RSA Encryption Version 1.5", Paul Hoffman, 06/10/1997, <draft-hoffman-pkcs-rsa-encrypt-01.txt> This standard describes a method for encrypting data using the RSA public-key cryptosystem. "PKCS #7: Cryptographic Message Syntax Version 1.5", Paul Hoffman, 06/10/1997, <draft-hoffman-pkcs-crypt-msg-01.txt> This standard 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. Please note: The information in this document is historical material being published for the public record. It is not an IETF standard. The use of the word 'standard' in this document indicates a standard for RSA Laboratories and its customers, not an IETF standard. "PKCS #10: Certification Request Syntax Version 1.5", Paul Hoffman, 06/10/1997, <draft-hoffman-pkcs-certif-req-01.txt> This standard describes a syntax for certification requests. Please note: The information in this document is historical material being published for the public record. It is not an IETF standard. The use of the word 'standard' in this document indicates a standard for RSA Laboratories and its customers, not an IETF standard. "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 "IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering, 07/16/1997, <draft-ietf-ipngwg-addr-arch-v2-02.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. "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. "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. "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. "IMAP4 Login Referrals", M. Gahrns, 05/19/1997, <draft-gahrns-imap-login-referrals-00.txt> When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. For example, hardware failures or organizational changes may dictate such a move. Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed. 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 mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server. "IMAP4 Mailbox Referrals", M. Gahrns, 05/19/1997, <draft-gahrns-imap-mailbox-referral-00.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. Mailbox referrals allow clients to seamlessly access mailboxes that are distributed across several IMAP4 servers. 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 mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server. "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", Yakov Rekhter, Bruce Davie, 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", Yakov 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", Chris 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)", Paul Tsuchiya, P. Srisuresh, Kjeld Egevang, 07/08/1997, <draft-rfced-info-srisuresh-02.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, 06/09/1997, <draft-li-hsrp-00.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. "Anonymous SASL Mechanism", Chris Newman, 06/23/1997, <draft-newman-sasl-anon-00.txt> It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done within the context of a plain text password mechanism using 'anonymous' as the user name and trace information, such as an email address, as the password. As SASL [SASL] provides a framework for authentication mechanisms, a formalized anonymous mechanism is simple to add. "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", Chris 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.] "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). "IETF Policy on Character Sets and Languages", Harald Alvestrand, 06/24/1997, <draft-alvestrand-charset-policy-00.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 or other character-like representation mechanisms. 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, 'the specification' as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process. "Telnet Authentication: SRP", T. Wu, 06/27/1997, <draft-wu-telnet-option-00.txt> The ability to negotiate a common authentication mechanism between client and server is a feature of the authentication option that should be used with caution. "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", Jim Lyon, J. Klein, Keith Evans, 07/07/1997, <draft-evans-tip-functions-00.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. "Telnet Remote Serial Port (RSP) Option", R. Barnes, M. Bennett, 07/08/1997, <draft-barnes-telnet-rsp-opt-00.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.0", K. Ross, V. Valloppillil, 07/09/1997, <draft-vinod-carp-v1-00.txt> This draft documents the Cache Array Routing Protocol (CARP) v1.0 for dividing URL-space among an array of loosely coupled proxy servers. An HTTP client agent (either a proxy server or a client browser) which implements CARP v1.0 can allocate and intelligently route requests for the correct URLs to any member of the Proxy Array. Due to the resulting sorting of requests through these proxies, duplication of cache contents is eliminated and global cache hit rates are improved. "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. "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. "ODETTE File Transfer Protocol", D. Nash, 07/24/1997, <draft-rfced-info-nash-01.txt> This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. "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. "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. "A Dictionary Server Protocol", B. Martin, R. Faith, 07/28/1997, <draft-rfced-info-faith-01.txt> The Dictionary Server Protocol (DICT) is a TCP transaction based query/response protocol that allows a client to access dictionary definitions from a set of natural language dictionary databases. "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. "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. "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. "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. "ILMI-Based Server Discovery for ATMARP", Michael Davison, 07/22/1997, <draft-davison-ilmi-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, 07/22/1997, <draft-davison-ilmi-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. "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. "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. "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. "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", C. Apple, 07/28/1997, <draft-apple-schema-rqmts-list-00.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", Chris 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, 07/30/1997, <draft-harada-http-xconnfrom-00.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. "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. "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. "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. "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. "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). "Logical IP Subnetworks over IEEE 802.14 Services", Mark Laubach, 08/01/1997, <draft-laubach-ip-over-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. "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. "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. "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. "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. "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. "Security issues for ION protocols", G. Armitage, 08/01/1997, <draft-armitage-ion-security-00.txt> This document aims to assist people attempting to understand the security limitations of existing ION working group protocols RFC 1577 (ATMARP), 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. "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. "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. "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. "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. "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. ONC Remote Procedure Call (oncrpc) ---------------------------------- "Authentication Mechanisms for ONC RPC", Steve Nahm, 05/30/1997, <draft-ietf-oncrpc-auth-03.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'. "RPCSEC_GSS Protocol Specification", A. Chiu, M. Eisler, L. Ling, 06/06/1997, <draft-ietf-oncrpc-rpcsec_gss-05.txt> This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API). 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] One Time Password Authentication (otp) -------------------------------------- "OTP Extended Responses", C. Metz, 04/16/1997, <draft-ietf-otp-ext-02.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 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, C. Metz, M. Straw, 03/19/1997, <draft-ietf-otp-01.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 Part I: X.509 Certificate and CRL Profile", D. Solo, Russ Housley, Warwick Ford, T. Polk, 08/01/1997, <draft-ietf-pkix-ipki-part1-05.txt> This is the fifth draft of the Internet Public Key Infrastructure X.509 Certificate and CRL Profile. This draft is a complete specification. This text adds a new ISO-defined certificate extension, extended key usage, and clarifies the semantics of the validity fields. Other modifications and enhancements which appear in this draft include a reduced set of private extensions, conformance requirements for CAs and clients, and new examples of certificates and a CRL. This draft also defines object identifiers for use with the extended key usage certificate extension. Please send comments on this document to the ietf-pkix@tandem.com mail list. "Internet Public Key Infrastructure Part III: Certificate Management Protocols", C. Adams, S. Farrell, 08/02/1997, <draft-ietf-pkix-ipki3cmp-03.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 Part 2: Operational Protocols", Tim Howes, Russ Housley, S. Boeyen, P. Richard, M. Myers, 03/20/1997, <draft-ietf-pkix-ipki2opp-00.txt> This is the first draft of the Internet Public Key Infrastructure X.509 Operational Protocols. This document identifies candidate protocols for retrieval of X.509 v3 certificates and v2 CRLs as well as a candidate protocol for online status checking of X.509 v3 certificates. It is proposed that this document serve as the basis for the PKIX Part 2 standardization effort. Please send comments on this document to the ietf-pkix@tandem.com mail list. "Internet Public Key Infrastructure Part IV: Certificate Policy and Certification Practices Framework", Warwick Ford, S. Chokhani, 07/03/1997, <draft-ietf-pkix-ipki-part4-01.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. "Representation of Key Exchange Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates", Russ Housley, William Polk, 08/01/1997, <draft-ietf-pkix-ipki-kea-00.txt> This is the initial 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. PacketWay (pktway) ------------------ "Proposed Specification for the PacketWay Protocol", Danny Cohen, C. Lund, T. Skjellum, T. McMahon, R. George, 03/03/1997, <draft-ietf-pktway-protocol-spec-03.txt> PacketWay's goal is to move data from a 'Source' (a node on a System Area Network) to a 'Destination' (another node, probably on another System Area Network) at the high performance available on these SANs. Sources and Destinations can be physical things (a processor or a smart memory board). They can also be 'logical' things, such as a group of cooperating processes. Process for Organization of Internet StandardS ONg (poisson) ------------------------------------------------------------ "IETF Working Group Guidelines and Procedures", Scott Bradner, Dave Crocker, Erik Huizer, 03/24/1997, <draft-ietf-poisson-wg-guide-00.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)", John 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"", K. Hamzeh, W. Verthein, 06/25/1997, <draft-ietf-pppext-l2tp-04.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 and FUNI", M. Kaycee, A. Malis, A. Lin, J. Stephens, G. Gross, 07/28/1997, <draft-ietf-pppext-aal5-01.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. "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) 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). "Layer Two Tunneling Protocol "L2TP" Security Extensions for Non-IPSEC networks", Pat Calhoun, W. Mark Townsley, 07/02/1997, <draft-ietf-pppext-l2tp-sec-01.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, 07/28/1997, <draft-ietf-pppext-funi-01.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. Printer MIB (printmib) ---------------------- "Printer MIB", Steve Zilles, Joel Gyllenskog, R. Turner, R. Smith, T. Hasting, F. Wright, 07/08/1997, <draft-ietf-printmib-mib-info-02.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.83", T. Hasting, H. Lewis, S. Isaacson, R. Bergman, 08/02/1997, <draft-ietf-printmib-job-monitor-04.txt> This Internet-Draft specifies a set of 18 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, 08/02/1997, <draft-ietf-ptopomib-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 physical topology identification and discovery. "Physical Topology Discovery Protocol and MIB", Keith McCloghrie, Andy Bierman, 08/02/1997, <draft-ietf-ptopomib-pdp-00.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 managing the protocol. 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", Bernard 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, Bernard 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 Server MIB", Bernard Aboba, G. Zorn, 07/25/1997, <draft-ietf-radius-servmib-04.txt> This memo defines a set of extensions which instrument RADIUS 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 servers. "RADIUS Client MIB", Bernard Aboba, G. Zorn, 07/25/1997, <draft-ietf-radius-clientmib-04.txt> This memo defines a set of extensions which instrument RADIUS 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 clients. "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. Receipt Notifications for Internet Mail (receipt) ------------------------------------------------- "An Extensible Message Format for Message Disposition Notifications", Roger Fajman, 07/31/1997, <draft-ietf-receipt-mdn-05.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. 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, 07/22/1997, <draft-ietf-rmonmib-smon-01.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", C. Bucci, R. Iddon, Andy Bierman, 07/22/1997, <draft-ietf-rmonmib-rmonprot-v2-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 the algorithms required to identify different protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RFC2021]. 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, 07/23/1997, <draft-ietf-rmonmib-hcrmon-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices. This memo does not specify a standard for the Internet community. Roaming Operations (roamops) ---------------------------- "Dialup Roaming Requirements", Bernard 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. "Review of Roaming Implementations", Bernard Aboba, J. Ding, J. Alsop, W. Wang, J. Lu, 06/16/1997, <draft-ietf-roamops-imprev-04.txt> This document reviews the design and functionality of existing roaming implementations. '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. "The Network Access Identifier", Bernard Aboba, M. Beadles, 07/23/1997, <draft-ietf-roamops-nai-06.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. "The Accounting Problem in Roaming", Bernard Aboba, D. Lidyard, 03/26/1997, <draft-ietf-roamops-actng-02.txt> This document describes the accounting problems that arise in providing dialup roaming capabilities. These include issues relating to standardization of accounting record formats, and inter-provider transfers of accounting record bundles. Work relevant to the solution of these problems are reviewed, and recommendations are made on the direction of future standardization work. "Guidelines for the Secure Operation of RADIUS Proxies in Roaming", John Vollbrecht, Bernard Aboba, G. Zorn, 07/23/1997, <draft-ietf-roamops-auth-02.txt> Today, RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. This document provides guidelines for the secure operation of RADIUS proxies within roaming systems. 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) ------------------------------------------ "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", Lixia Zhang, Bob Braden, S. Jamin, Shai Herzog, S. Berson, 06/16/1997, <draft-ietf-rsvp-spec-16.txt, .ps> This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. "RSVP Cryptographic Authentication", Fred Baker, 07/23/1997, <draft-ietf-rsvp-md5-04.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 Management Information Base", Fred Baker, John Krawczyk, A. Sastry, 07/11/1997, <draft-ietf-rsvp-mib-09.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. "RSVP Extensions for IPSEC Data Flows", Lou Berger, T. O'Malley, 03/19/1997, <draft-berger-rsvp-ext-07.txt> This document presents extensions to Version 1 of RSVP. These extensions permit support of individual data flows using RFC 1826 IP Authentication Header (AH) or RFC 1827 IP Encapsulating Security Payload (ESP). RSVP Version 1 as currently specified can support the IPSEC protocols, but only on a per address, per protocol basis not on a per flow basis. The presented extensions can be used with both IPv4 and IPv6. "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]. "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", Lixia Zhang, Bob Braden, 11/05/1996, <draft-ietf-rsvp-procrules-00.txt, .ps> This memo contains an algorithmic description of the rules used by an RSVP implementation for processing messages. It is intended to clarify the version 1 RSVP protocol specification. "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]. "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", Lixia Zhang, Scott Bradner, Fred Baker, Abel Weinrib, 07/25/1997, <draft-ietf-rsvp-intsrv-analysis-01.txt> This document describes the applicability of RSVP along with the Integrated Services protocols and other components of resource reservation and offers guidelines for deployment of resource reservation at this time. This document accompanies the first submission of RSVP and integrated services specifications onto the Internet standards track. "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. 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, 07/08/1997, <draft-ietf-rtfm-meter-mib-01.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. 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, 07/31/1997, <draft-ietf-secsh-transport-01.txt> This document describes the SSH transport layer protocol. The protocol can be used as a basis for a number of secure network services. It provides strong encryption, server authentication, and integrity protection. "SSH Authentication Protocol", T. Ylonen, 07/31/1997, <draft-ietf-secsh-userauth-01.txt> This documents describes the SSH authentication protocol. It is used to prove that the client is authorized access the requested service with the supplied user name. This authorization can be demonstrated through possession of a password, through possession of a key, by authenticating the client host and user, by some other method, or a combination of these. "Connect", T. Ylonen, 07/31/1997, <draft-ietf-secsh-connect-01.txt> This document describes the SSH connection protocol. It multiplexes a single encrypted tunnel into a number of channels (interactive sessions, forwarded TCP/IP ports, X11 connections, etc). It is intended to run above the SSH user authentication layer. 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. SNMP Version 3 (snmpv3) ----------------------- "An Architecture for Describing Internet Management Frameworks", Bert Wijnen, D. Harrington, 07/31/1997, <draft-ietf-snmpv3-next-gen-arch-04.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 network 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 Model for version 3 of the Simple Network Management Protocol (SNMP)", Jeffrey Case, Bert Wijnen, D. Harrington, 08/01/1997, <draft-ietf-snmpv3-v3mpc-model-03.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 for the Simple Network Management Protocol (SNMP)", Keith McCloghrie, Bert Wijnen, Randy Presuhn, 07/31/1997, <draft-ietf-snmpv3-acm-02.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, 07/31/1997, <draft-ietf-snmpv3-usm-01.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, 08/01/1997, <draft-ietf-snmpv3-appl-01.txt> This memo describes the various types of SNMP applications which make use of an SNMP engine as described in [SNMP-ARCH]. There are five types of application described herein: - Applications which initiate SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command generators'. - Applications which respond to SNMP Get, GetNext, GetBulk, and/or Set requests, called 'command responders'. - Applications which generate notifications, called 'notification originators'. - Applications which forward SNMP Get, GetNext, GetBulk, and/or Set requests or notifications, called 'proxy forwarders'. This memo also defines MIBs for specifying targets of management operations, for notification filtering, and for proxy forwarding. - Applications which receive notifications, called 'notification receivers'. Simple Public Key Infrastructure (spki) --------------------------------------- "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. "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. Site Security Handbook (ssh) ---------------------------- "Site Security Handbook", Barbara Fraser, 07/28/1997, <draft-ietf-ssh-handbook-05.txt> This handbook is a guide to developing computer security policies and procedures for sites that have systems on the Internet. The purpose of this handbook is to provide practical guidance to administrators trying to secure their information and services. The subjects covered include policy content and formation, a broad range of technical system and network security topics, and security incident response. "Users' Security Handbook", G. Malkin, Erik Guttman, 07/21/1997, <draft-ietf-ssh-users-01.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, 06/18/1997, <draft-ietf-svrloc-discovery-02.txt> This document proposes a solution to the problem of finding information about that 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, 08/02/1997, <draft-ietf-svrloc-service-scheme-02.txt> Service: schemes define URLs (called 'service: URLs' in this document) which 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 with a Directory Agent, the URL may be accompanied by a set of well defined attributes which define the charateristics of the service. These attributes may convey configuration information to client software, or service characteristics meaningful to end users. This document describes how to define and standardize new service types and attributes for use with the service: scheme using Service Templates. These templates are human and machine readable. They may be used by administrative tools to parse service registration information and by client applications to provide localized translations of service attribute strings. "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, 06/06/1997, <draft-ietf-svrloc-advertising-02.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. "Defining White Pages and Yellow Pages Services", R. Moats, 02/11/1997, <draft-ietf-svrloc-wpyp-00.txt> Service scheme templates for several different 'white' and 'yellow' pages services are presented. "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. 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, 05/21/1997, <draft-ietf-tls-protocol-03.txt> This document specifies Version 1.0 of the Transport Layer Security (TLS) protocol, which is at this stage is strictly based on the Secure Sockets Layer (SSL) version 3.0 protocol, and is to serve as a basis for future discussions. 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, 06/30/1997, <draft-ietf-tn3270e-tn3270-mib-01.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 Monitoring. 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, 07/30/1997, <draft-ietf-tn3270e-rt-mib-00.txt> The purpose of this memo is to define the protocol and the Management Information Base (MIB) for performing response time data collection on 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 as well as performance monitoring of 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 Names (urn) ---------------------------- "Guidelines and a Framework for URN Resolution Systems", K. Sollins, 07/29/1997, <draft-ietf-urn-req-frame-03.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/02/1997, <draft-ietf-urn-resolution-services-02.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, 04/23/1997, <draft-ietf-urn-biblio-00.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", Bob Hinden, S. Knight, D. Whipple, D. Weaver, 07/30/1997, <draft-ietf-vrrp-spec-01.txt> This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual IP address to a single router among a collection of VRRP routers. The VRRP router controlling the virtual IP address is called the Master router, and forwards packets sent to the virtual IP address. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. The virtual IP address can then be used as the default first hop router by end-hosts. The advantage gained from using the VRRP virtual IP address 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 Distributed Authoring and Versioning on the World Wide Web", D. Durand, Jim Whitehead, J. Slein, F. Vitali, 07/25/1997, <draft-ietf-webdav-requirements-01.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 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, 08/01/1997, <draft-ietf-webdav-protocol-01.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. 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.