Return to Main Menu

Audit - Detect Network Intrusions
Anonymity & Privacy
ATM - Asynchronous Transfer
Biometrics
Business Continuity Planning
Cellular Communications
Computer Crime & Investigations
Computer Hardware Tutorial
Corporate Violence in Workplace
Crypto & Encryption - Part I
Crypto & Encryption - Part II
Crypto & Encryption - Part III
Disaster Recovery Planning
Downloads - - Public Domain
Downloads - Packet Storm
Downloads - Hacker Domain
Employment and Job Opportunities
Ethics Law and Security Policy
Firewalls
Frame Relay Tutorials
FreeBSD - Berkeley Unix Clone
FreeBSD - OnlineBooks to Read
General Security Related Links
Hacking - How its done Guides
Hacked Web Sites
Information Warfare
Internet Telephony & Protocols
Intrusion Detection Library
Investigations and Courtrooms
Java Security Resources
Jobs & Employment Opportunities
Legal Resources - Legal Basics
Linux Resources - Basics
Linux Resources - Online Books
Mailing List - For Newsletters
Magazine Articles - SEARCHER
Magazine Store - CheapPrices
Military & Govt Security Docs
Networking - Internet Protocols
Novell Networking Security
Online Courses -Boost Your Skills
Pager Hardware Reprogramming
Penetration Testing -Intrusions
Physical and Facility Security
Privacy & Anonymity on the Net
Programming Tutorials
Protocols - Networking - Internet
Resume and Interview Resources
Security Magazines Online
Security Reference Library I
Security Reference Library II
Security Policy Library
Security Standards & Guidelines
Smart Cards
Telecommunication & Internet
Telecommunications Tutorials
Threat Risk Assessments
Unix Security Resources
Unix Security Online Books
VPN's - Virtual Private Networks
Virus Worms Trojans Hoaxs
Voice / IP Protocols and Standards
WIN NT Assorted Files
WIN NT Security Files
WIN 2000 Operating System
Workplace Violence
Y2K Year 2000 Information

Network Protocol Bibliographies -  Protocol article references

There are approximately 200 complete or partial items listed in this listing.  80% of these links lead to the complete work and about 20% lead to identifying why you can locate the reference at your library or by using the Search Engines to hunt them down.   Unfortunately some of the more commercial web sites use the partial chapters as bait to lure you into buying the hard copy of the text - rather then putting the whole thing online and letting the consumer decide whether he/she prefers the free online version or if they wish to purchase a hard copy.

Another problem with maintaining this listing is that web sites live and die faster then fruit flies - so it is possible that links will be up one day and down the next. 

SEARCHING THIS LIST - use your browsers built in find feature

Iin order to best search this list for topics of your particular interest, use the built in feature of YOUR web browser to search the page for keywords.   On the IE Explorer the FIND feature is located in the EDIT options at the top of your browser.   On the Netscape browser you will find the FIND option also in the EDIT options at the top of your web browser.

Good luck... good hunting... and hopefully good reading !

Network Bibliography : Network Protocols

Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Anonymous Credit Cards," in submitted to 1994 IEEE Symposium on Research in Security and Privacy, (Oakland, California), 1994.

Abstract: This paper describes a novel technique for generating an anonymous credit card which combines the privacy of cash transactions with the security, record-keeping and charging mechanisms of credit cards. Using this scheme, and individual can make purchases without revealing his identity while a shop can sell items to an unknown individual without the fear of being cheated.

Keywords: electronic cash; anonymous credit cards; mercantile protocols

Steven Low, Nicholas F. Maxemchuk and Sanjoy Paul, "Collusion in a Multi-party Communications Protocol for Anonymous Credit Cards," submitted to IEEE/ACM Transactions on Networking, 1994.

Abstract: We proposed in [8] a novel scheme to implement an anonymous credit card that protects privacy while providing the security, record- keeping, and charging mechanism of conventional credit cards. The key idea is to use cryptographic techniques to allow two parties to commuincate without knowing each other. In this paper we present a formal method to study collusion in the multi-party communication protocol in [8]. Application of the method to our protocol leads to a simplified implementation of anonymous credit cards that is equally secure.

Keywords: electronic cash; anonymous credit cards; mercantile protocols

Alec F. Yasinsac and William A. Wulf, "Evaluating cryptographic protocols," Department of Computer Science, University of Virginia, Charlottesville, Virginia, no. CS-93-66, Dec. 1993.

Abstract: Cryptographic protocol (CP) analysis is a topic of intense research. Meadows describes four approaches to CP verification under investigation in (Meadows 1992) and several authors have categorized protocols based on types of errors they are subject to (Bird 1992, Syverson 1993). This paper addresses the weakness injected into protocols when information is passed in the clear or encrypted only under the private key of a public/private key pair. We also propose a method for logically analyzing protocols based on action list analysis of valid and compromised protocol runs interleaved with action lists of intruders conducting known attacks.

Keywords: cryptography; protocols; protocol verification

Dominique de Waleffe and Jean-Jacques Quisquater, "Better login protocols for computer networks," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 50--70, May 1991.

Abstract: Authenticating computer users is a fairly old problem. Password based solutions were acceptable until the growth of computer networks based on insecure communications. Today many systems still use fixed passwords as a means of authentication. We show in this paper how an old scheme by Lamport can be used to provide more security. Relying on that scheme and zero-knowledge techniques, we show extensions providing much more general access control mechanisms. Those extensions can be exploited in several ways: to authenticate users in computer networks, to provide users with access tickets or provide servers with proofs of usage. We also show how, in a single transaction, a user can prove this authenticity as well as prove his possession of a ticket. Finally, we explain how smart cards make those protocols very practical.

Keywords: security; authentication; access control; login; smart card

Johan van Tilburg, "Secret-key exchange with authentication," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 71--86, May 1991.

Abstract: This paper provides an outline for the second lecture on authentication protocols and deals with the secret-key exchange protocols. The object is to encourage the interested reader to obtain and study the original papers, and papers related to this subject.

Keywords: security; authentication; encryption; secret key; public-key; Diffie-Hellman; ElGamal; zero-knowledge

Bart De Decker, "Unix Security and Kerberos," in Computer Security and Industrial Cryptography, Preneel, Bart and Govaerts, Ren\'e and Vandewalle, Joos, ed., Berlin, pp. 257--274, May 1991.

Abstract: This paper discusses some security issues related to the UNIX operating system, which is today the de facto standard Operating System. The authentication mechanism has been focused on, both in a central system and in a networked environment. It is shown that networking makes UNIX vulnerable if no special measures are taken. One of these could be the introduction of the Kerberos authentication system which is also becoming a ``standard'' in open network environments. The Kerberos protocols are described, and their merits and limitations in a possibly hostile environment are discussed.

Keywords: security; Unix; operating systems; Kerberos; authentication; login

B. Abarbanel and S. Venkatachalam, "BGP-4 support for Traffic Engineering," Internet Engineering Task Force, Jun. 2000.

Abstract: Currently, constraint routing (CR) and traffic engineering (TE) models do not take into consideration the big picture view of IP traffic traversing multiple autonomous systems (AS). Most of the traffic and constraint routing is based on IGP protocols such as OSPF/ISIS, etc. The resulting view of the Internet is limited to one autonomous system and areas or systems within it. Hence, the routing/forwarding functions do not select the optimum path for packets that need to traverse several autonomous systems. The proposal in this draft is that the BGP protocol can be utilized to choose the best BGP routes based on traffic engineered (TE) constraint weights. This information can be propagated between all BGP peers and calculated by the BGP AS border routers before it is deployed to their forwarding tables.

J. Abela, "UTF-9, a transformation format of UCS," Internet Engineering Task Force, Dec. 1997.

Abstract: ISO/IEC 10646 defines a multi-octet character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. Multi-octet characters, however, are not compatible with many current applications and protocols, and this has led to the development of a few so-called UCS transformation formats (UTF), each with different characteristics. UTF-9, the object of this memo, has the characteristic of preserving the full ISO-Latin1 range, providing compatibility with file systems, parsers and other software that rely on ISO-Latin1 values. ISO-Latin1 is almost as widespread as ASCII in many countries, especially in most of western Europe, and is the default character set for HTML. A compatible encoding seems desirable, where possible.

B. Aboba, "IPSEC Remote Access Protocol Evaluation Criteria," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes criteria for evaluation of IPSEC Remote Access (IPSRA) protocols. In particular, this document focuses on criteria relevant to voluntary tunneling.

B. Aboba, "Extension for PPP Authentication," Internet Engineering Task Force, Nov. 1997.

Abstract: This document defines the ''PPP Authentication Operation'' for LDAP. This operation provides for PPP authentication in an LDAP association and is defined in terms of an LDAP extended operation. It is expected that this extended operation will be useful in inte- grating authentication protocols such as RADIUS and TACACS+ with LDAP- based directory services. Consolidation of information stores is desirable since it results in lessened administrative workload and a consistent view of user information throughout the enterprise.

B. Aboba, "PPP EAP GSS Authentication Protocol," Internet Engineering Task Force, Jul. 2000.

Abstract: The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of additional authentication methods within layer 2 protocols, including PPP and IEEE 802. Through the use of EAP, support for a number of authentication schemes may be added, including public key, smart cards, Kerberos, One Time Passwords, and others.

C. Adams and J. Gilchrist, "The CAST-256 Encryption Algorithm," Internet Engineering Task Force, Feb. 1999.

Abstract: There is always a desire in the Internet community for unencumbered encryption algorithms with a range of key sizes that can provide security for a variety of cryptographic applications and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. Included are a description of the cipher and the key scheduling algorithm, the s-boxes, and a set of test vectors (Appendix A).

C. Adams, "Alternative Certificate Formats for PKIX-CMP," Internet Engineering Task Force, Jul. 2000.

Abstract: The PKIX Certificate Management Protocols (PKIX-CMP) specification [1], while primarily focused on X.509v3 public-key certificates, allows the messages it defines to be used for the management of alternative certificate formats as well. This document specifies precisely how such formats may be incorporated into PKIX-CMP and provides the relevant syntax for some important certificate types.

C. Adams and R. Zuccherato, "Data Certification Server Protocols," Internet Engineering Task Force, Jun. 1998.

Abstract: This document describes a general data certification service and the protocols to be used when communicating with it. The Data Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Certification Server responsibilities in a PKI are to validate signatures and to provide up-to-date information regarding the status of public key certificates. We give examples of how to use the Data Certification Server to extend the lifetime of a signature beyond key expiry or revocation and to query the Data Certification Server regarding the status of a public key certificate. 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 [RFC2119].

C. Adams and R. Zuccherato, "Notary Protocols," Internet Engineering Task Force, Feb. 1998.

Abstract: 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]). Useful Notary Authority responsibilities in a PKI are to validate signatures and to provide up- to-date information regarding the status of certificates. We give examples of how to use the notary to extend the lifetime of a signature beyond key expiry or revocation and to query the notary regarding the status of a certificate.

C. Adams, D. Pinkas, P. Cain and R. Zuccherato, "Time Stamp Protocols," Internet Engineering Task Force, Jun. 1998.

Abstract: 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]). In order to reduce the amount of trust required of a TSA we introduce (in Appendix C) the optional Temporal Data Authority (TDA) whose function is to provide further corroborating evidence of the time contained in the token. We also give an example of how to place a signature at a particular point in time, from which the appropriate certificate status information (e.g. CRLs) may be checked.

C. Perkins and H. AFIFI, "Internet General Packet Radio Service (IGPRS); Service description," Internet Engineering Task Force, Jul. 2000.

Abstract: We propose an architecture (IGPRS) for the integration of the IPv6 protocol in the GPRS infrastructure. The data and signalling protocol suite will be based on mobile IPv6 protocol (instead of the GTP protocol). This new infrastructure will take advantage of the available internet protocols for routing and security. Since it is targetted to co-exist with the GPRS, it is a partial translation of MAP specifications to Internet protocols. This document uses some of the GPRS Service document and some of its terminology.

S. Ago, S. Moeenuddin and S. Hadvani, "NEC contribution on pre-Spirits ICW implementations," Internet Engineering Task Force, Feb. 2000.

Abstract: This document provides overview of a pre-SPIRITS Internet Call Waiting (ICW) implementation developed by NEC. The document describes the ICW service, the architecture, interface, and the protocols used in the ICW implementation. As such, this document contributes to the future SPIRITS architecture and protocol RFCs.

C. Akinlar, D. Braun and S. Mukherjee, "Multi-Router Zeroconf Network Requirements," Internet Engineering Task Force, Aug. 2000.

Abstract: Zero Configuration (Zeroconf) Networks are a particular class of TCP/IP networks that may be established in the home, in small offices or even for a variety of adhoc purposes. Zeroconf networks do not have and should not be expected to have user configurable network infrastructure such as DHCP, DNS and other administered network services. This is because typical zeroconf network users neither have the skill nor the desire to configure, administer or manage a network [1]. The IETF Zeroconf Requirements draft [1] presents the zeroconf protocol requirements for 4 areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. This draft builds on [1] and lists the zeroconf protocol requirements for IP router configuration and dynamic routing protocol in multi-router zeroconf networks. The IETF Zeroconf Requirements draft [1] presents the zeroconf protocol requirements for 4 areas: IP host configuration, domain name to IP address resolution, IP multicast address allocation, and service discovery. The most complex network topology addressed by the Zeroconf Requirements document [1] is a multi-segment zeroconf network connected by a single router. This drafts builds on that draft and lists the zeroconf protocol requirements for IP router configuration and dynamic routing protocols in multi-router zeroconf networks.

S. Ostermann and M. Allman, "FTP Extensions for Variable Protocol Specification," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.

H. Alvestrand, "IETF Policy on Character Sets and Languages," Internet Engineering Task Force, Oct. 1997.

Abstract: The Internet is international. With the international Internet follows an absolute requirement to interchange data in a multiplicity of languages, which in turn utilize a bewildering number of characters. This document is (INTENDED TO BE) the current policies being applied by the Internet Engineering Steering Group towards the standardization efforts in the Internet Engineering Task Force in order to help Internet protocols fulfil these requirements. The document is very much based upon the recommendations of the IAB Character Set Workshop of February 29-March 1, 1996, which is documented in RFC 2130 [WR]. This document attempts to be concise, explicit and clear; people wanting more background are encouraged to read RFC 2130. The document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in [RFC 2119]. In this case, 'the specification' as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process.

C. Weider, T. Howes, C. Apple and M. Wahl, "A Minimum LDAPv3 White Pages Schema," Internet Engineering Task Force, Dec. 1997.

Abstract: Many different white pages schema proposals have been published for use in LDAPv3 as well as other directory service protocols. While these proposals define schema elements that are indeed useful in the deployment of LDAPv3-based directory services, there are a few problems common to the set of such proposals currently available to implementors: inconsistent semantic and syntactic definitions of similar attributes across schema, little or no semantic extensibility of attribute definitions without changing source code for deployed implementations, lack of standard object class definitions for containing white pages meta schema elements, and lack of an attribute grouping method. This document defines an object class for holding IWPS attributes as mapped into existing and relatively few newly defined extensible attribute types.

G. Armitage, "Security issues for ION protocols," Internet Engineering Task Force, Oct. 1997.

Abstract: This document aims to assist people attempting to understand the security limitations of existing ION working group protocols RFC 2022 (MARS), and RFC xxxx (NHRP). As RFC 2022 and RFC xxxx share their basic control message protocol(s), this document also identifies common areas amenable to improvement using additional security TLVs.

T. Arnold and J. Eaton, "Simple Commerce Messaging Protocol (SCMP)Version 1 Message Specification," Internet Engineering Task Force, Jun. 2000.

Abstract: The Simple Commerce Messaging Protocol (SCMP) is a general-purpose electronic commerce message protocol for secure, real-time communication of a set of data from a sending agent's application to a receiving agent's server. Additionally the response by the receiving agent's server to the sending agent is the reply from the request represented by the set of data in the message's payload. The intent of this protocol is to define a method where trading partners can perform on-line business requests in an environment where the sending partner is fully authenticated, and the message cannot be repudiated. The taxonomy of the SCMP message payload is not in the scope of this document. The SCMP protocol does not specify payload definitions or how trading partners are expected to process the payload, beyond basic server-level functions related to processing SCMP headers. This intent is to permit trading partners the flexibility to implement either a standard commerce message format as in ANSI-X12 Electronic Data Interchange (EDI) or some other non-standard payload format. This document does give an example implementation of a payload format based on [XML]. The only requirement on the message payload is that it be prepared as specified in [MIME]. In this manner, SCMP fundamentally differs from many emerging commerce message protocols. Beyond specifying the method for encryption, authentication and handling, these other protocols specify the contents of the message and details how a server is to process and respond to a given message payload.

A. Arsenault and S. Farrell, "Securely Available Credentials - Requirements," Internet Engineering Task Force, Sep. 2000.

Abstract: This document describes requirements to be placed on Securely Available Credentials (sacred) protocols. This is the initial draft of the sacred requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the sacred list (see http://www.imc.org/ietf-sacred for subscription information).

S. Ayandeh and Y. Fan, "MPLS Routing Dynamics," Internet Engineering Task Force, Mar. 1998.

Abstract: This Internet draft outlines how transients in protocols such as OSPF [7] (intra-domain routing) and MPLS LDP [2] can lead to periods of time with loops and other undesirable routing phenomenon. It defines a set of metrics to quantify this dynamic behavior. Quantification of these metrics, using a simulation model, for various local vs. egress label allocation schemes is used as the basis of a comparative analysis. This includes quantifying any incremental impact that MPLS may have once it is introduced into an autonomous IP routing area. The resulting insights would help develop a better understanding of routing dynamics. This includes identifying key nodal and network variables which impact routing dynamics hence guiding MPLS feature selection and IP network design.

M. Bakke and J. Muchow, "Definitions of Managed Objects for SCSI over TCP," Internet Engineering Task Force, Aug. 2000.

Abstract: 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 a client using the SCS over TCP (aka iSCSI) protocol.

S. Bakker, "AAA Considerations for Middleware," Internet Engineering Task Force, Jun. 1999.

Abstract: The IETF AAA Working Group is currently looking at defining the requirements for Authentication, Authorization and Accounting. Various documents have already been written that outline AAA requirements for various services and protocols. This document falls into that category, as it outlines some ideas for middleware that have specific AAA requirements.

T. Nishida and A. Bakre, "IP Multicast over ATM Networks with Cut-through Forwarding for Inter LIS Traffic," Internet Engineering Task Force, Dec. 1997.

Abstract: This document proposes a scheme for IP multicasting in ATM networks, which can achieve cut-through forwarding for inter LIS multicast traffic using ATM protocols.

O. Aboul-Magd and others, "Signaling Requirements at the Optical UNI," Internet Engineering Task Force, Jul. 2000.

Abstract: This draft considers the optical network service model referred to as the 'domain services' model [1]. Under this model, the optical network provides a set of well-defined services to clients (IP and others). The signaling and routing interface between the client and optical networks is referred to as the User-Network Interface (UNI). This draft describes the services provided over the UNI, and the requirements on any signaling protocol used to invoke the services. This draft reflects ongoing work at the Optical Interworking Forum (OIF) and the Optical Domain Service Interconnect (ODSI) coalition on the optical UNI [2]. The relevance of this draft to the IETF is two-fold. First, for the signaling portion of the optical UNI, extensions of two MPLS signaling protocols are presently under consideration in the OIF: RSVP with TE extensions and LDP. The objective of this draft is to guide the adaptation of these protocols for UNI signaling. Second, to harmonize the signaling of UNI originated lightpath requests and peer model lightpath establishment mechanisms [1], alignment between OIF, ODSI and IETF lightpath parameters and signaling functionality is desirable. This draft aims to serve this purpose. The content of this draft is expected to evolve as work progresses on the optical UNI.

H. Balakrishnan and S. Seshan, "The Congestion Manager," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes the Congestion Manager (CM), an end-system module that (i) enables an ensemble of multiple concurrent flows from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and (ii) allows applications to easily adapt to network congestion. This CM framework integrates congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-flow bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions. This document focuses on applications and transport protocols with their own independent per-byte or per-packet sequence number information, and does not require modifications to the receiver protocol stack. The receiving application must provide feedback to the sending application about received packets and losses, and the latter uses the CM API to update CM state. This document does not address networks with reservations or service discrimination.

B. Baldwin, A. Wilson, S. Nishimura and M. Yurovitsky, "BSAFE CRYPTOGRAPHIC SECURITY COMPONENTS," Internet Engineering Task Force, May 1999.

Abstract: This Internet-Draft describes protocols, procedures, and conventions to be employed by peers implementing a generic cryptographic application program interface. Version 4.0 of this API was implemented inside RSA Data Security, Inc.'s BSAFE product. The API provides a model for implementing symmetric ciphers, message digests, message authentication, random number generation, public-key algorithms, digital signatures, and secret sharing. The API is documented here for the benefit of others who might also adopt and use the API, thus providing increased portability of security applications.

A. Banerjea, M. Faloutsos and R. Pankaj, "Designing QoSMIC: A Quality of Service sensitive Multicast Internet protoCol," Internet Engineering Task Force, May 1998.

Abstract: We present, QoSMIC, a multicast protocol for the Internet that supports QoS-sensitive routing, and minimizes the importance of a priori configuration decisions (such as core selection). The protocol is resource-efficient, robust, flexible, and scalable. In addition, our protocol is provably loop-free. Our protocol starts with a resources-saving tree (Shared Tree) and individual receivers switch to a QoS-competitive tree (Source-Based Tree) when necessary. In both trees, the new destination is able to choose the most promising among several paths. An innovation is that we use dynamic routing information without relying on a link state exchange protocol to provide it. Our protocol limits the effect of pre- configuration decisions drastically, by separating the management from the data transfer functions; administrative routers are not necessarily part of the tree. This separation increases the robustness, and flexibility of the protocol. Furthermore, QoSMIC is able to adapt dynamically to the conditions of the network. The QoSMIC protocol introduces several new ideas that make it more flexible than other protocols proposed to date. In fact, many of the other protocols, (such as YAM, PIM-SM, BGMP, CBT) can be seen as special cases of QoSMIC. The goal of this document is to present the motivation behind, and the design of QoSMIC, and to provide both analytical and experimental results to support our claims. NOTE: The text version of the draft is missing several figures, that facilitate the understanding of the work. For this, the authors suggest the postscript version.

D. Basak, D. Awduche, J. Drake and Y. Rekhter, "Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Cross-connects," Internet Engineering Task Force, Feb. 2000.

Abstract: This document describes the domain specific enhancements required to adapt MPLS traffic engineering control plane constructs to control optical cross-connects in emerging automatically switched optical transport networks. These enhancements are within the framework of Multiprotocol LAMBDA switching proposed in [1]. Specifically, this memo investigates the behavior of the MPLS based control plane technique for OXCs, and identifies required enhancements to both OXCs and to existing MPLS traffic engineering control plane objects (routing and signaling protocols) to support the application to OXCs.

J. Beck, "ResCap Requirements," Internet Engineering Task Force, Jun. 1999.

Abstract: A variety of resource identifiers have been widely deployed on the Internet as a means of identifying various resources, services, and destinations. However, a means of attaching a set of attributes or characteristics to a given resource identifier and subsequently assessing those attributes or characteristics has not been specified and deployed. A particularly important resolution service of this general type is one which, when given a mail address identifying a particular mail recipient, will return a series of attributes describing the capabilities of that recipient. This differs from a directory service in that no searching or other advanced query operations are involved. Two tasks are envisioned. The first task will be to define a general resolution protocol that will translate resource identifiers to a list of attributes. The second task will be to define an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. This document defines the requirements for these two protocols.

K. McCloghrie, P. Langille, A. Rijsinghani, A. Smith and L. Bell, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: 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 MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SNMP SMI [3].

B. Bell, "IPDC Device Management Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Device Signaling Transport protocol presented here, the media gateway can receive a signaling from a circuit switched network and deliver the signaling to a media gateway controller on an intervening IP network. The media gateway controller can also send signaling to a media gateway for delivery on a circuit switched network.

S. Bellovin and R. Moskowitz, "Client Certificate and Key Retrieval for IKE," Internet Engineering Task Force, Feb. 2000.

Abstract: (Insert justification, possibly copied wholesale from section 1.1 and maybe 2.1/2.2 of draft-kelly-ipsra-userauth-00.txt) We consider inadvisable to change IKE [RFC2409] to meet these needs. IKE is a complex protocol; adding more features to it is a bad idea. Instead, we propose a layered approach: use standard IKE, with certificates, but provide a simple mechanism to provide clients with keys and certificates. A number of objections have been raised to using certificates. The most important is that we lack a public key infrastructure (PKI). We do not agree that this is an obstacle. Our proposal provides a simple mechanism for certificate generation and retrieval, while still relying on legacy authentication infrastructures. Furthermore, we provide for an easy migration path to certificate use once organizational PKIs are deployed. Our purpose at this point is not to present a firm protocol. Rather, we sketch several ideas for what such a protocol could look like. Final details can be determined if and when the working group opts for this path. In the interests of simplicity, we have chosen to reuse standard protocols and components. In particular, we use HTTP [RFC2616] for transport, HTML [RFC1866] as a data representation and TLS [RFC2246] for confidentiality. However, we do not mandate (or even necessarily encourage) use of a actual Web browser for certificate retrieval. As an alternative, we present a transient shared secret generation mechanism for IKE.

L. Berger and J. Jeffords, "MPLS/IP Header Compression over PPP," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes an option for negotiating the use of MPLS and IP header compression over the Point-to-Point Protocol [STD51]. It defines extensions to the PPP Control Protocol for MPLS [LABELS]. It is based on, and borrows heavily from, IP Header Compression over PPP [RFC2509]. MPLS/IP header compression is defined in [CMPLS] and may be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols

L. Berger and T. O'Malley, "RSVP Extensions for IPSEC Data Flows," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.

Y. Bernet, D. Durham and F. Reichmeyer, "Requirements of Diff-serv Boundary Routers," Internet Engineering Task Force, Nov. 1998.

Abstract: This draft discusses requirements of routers that serve as ingress/egress points to/from differentiated services (diff-serv) networks. We discuss the traffic conditioning components required and associated configuration mechanisms and protocols. We also discuss admission control to diff-serv networks in support of signaled QoS.

G. Bernstein and V. Sharma, "Some Comments on GMPLS and Optical Technologies," Internet Engineering Task Force, Nov. 2000.

Abstract: GMPLS [2] is being considered as an extension to the MPLS framework to include optical, non-packet switched technologies. This draft reviews the motivation for doing so from an end-userĘs perspective and points out some key requirements/impacts that this will have on the extensions to the routing and label distribution/signaling protocols.

B. Beser, "Codec Capabilities Attribute for SDP," Internet Engineering Task Force, Mar. 2000.

Abstract: The need for assured communication arisen protocols like RSVP [2] and SBM [3] which are linked to access technologies to guarantee the delay and drop probabilities of a given IP flow. One of the side-effects of the assurance is that when the bandwidth of the IP flow goes outside the contracted region then the IP flow will be disturbed and the communication will be effected. This document discusses the effects of assured communication to SDP protocol, identifies the weaknesses and proposes a new attribute to rectify these weaknesses.

S. Bhattacharyya and others, "A Framework for Source-Specific IP Multicast Deployment," Internet Engineering Task Force, Jul. 2000.

Abstract: This document provides an overview of the Source-Specific Multicast (SSM) service model which supports source-based multicast trees across multiple domains in the Internet. SSM realizes components of the EXPRESS [HOLB99] multicast service model in which there is a single source for every multicast channel, and channel membership is based on the unique combination of multicast group address (G) as well as the source's unicast address (S). End-hosts use version 3 of the IGMP protocol (IGMPv3) to register their interest in a particular source-group (S,G) pair. The PIM-SM protocol is then used to construct the multicast forwarding tree rooted at the source S. This document is intended as a starting point for implementing and deploying SSM services. It provides a brief architectural overview of SSM described in more detail in [HOLBOO] and describes associated deployment challenges. It summarizes changes to protocols and applications both at end-hosts and routers, with pointers to more detailed documents, wherever appropriate. Issues of interoperability with the current multicast architecture are also discussed.

A. Bierman, "Remote Monitoring MIB Extensions for Differentiated Services Enabled Networks," Internet Engineering Task Force, Jun. 1999.

Abstract: 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 monitoring Differentiated Services Codepoint usage in IP packets, utilizing the monitoring framework defined in the RMON-2 MIB [RFC2021].

K. McCloghrie and A. Bierman, "Entity MIB Extesions for Persistent Component Identification," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.

A. Bierman, "Application Performance Measurement Capabilities MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: 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 classifying and characterizing the application performance measurement (APM) capabilities of various standard and proprietary APM techniques.

A. Bierman, "Remote Monitoring MIB Extensions for Virtual Data Sources," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 defining virtual data monitoring sources for use with existing RMON MIBs.

M. Blaze, J. Feigenbaum, J. Ioannidis and A. Keromytis, "The KeyNote Trust-Management System," Internet Engineering Task Force, Apr. 1999.

Abstract: this memo describes version 2 of the KeyNote trust-management system. It specifies the syntax and semantics of KeyNote `assertions,' describes `action attribute' processing, and outlines the application architecture into which a KeyNote implementation can be fit. The KeyNote architecture and language are useful as building blocks for the trust management aspects of a variety of Internet protocols and services.

M. Borella, D. Grabelsky, I. Sidhu and B. Petry, "Distributed Network Address Translation," Internet Engineering Task Force, Oct. 1998.

Abstract: NAT (Network Address Translation) has been proposed to extend the lifetime of IPv4 by allowing one or more subnets to exist behind a single IP address. It is desirable to support dozens, if not hundreds, of nodes on a NAT subnet. As it is currently defined, NAT may not gracefully scale beyond networks containing a few dozen nodes. In particular, the computational burden placed on the NAT router may be significant, especially if the router is shared by several NAT-enabled subnets. Additionally, NAT requires that support for many protocols be specifically programmed into the translation mechanism. In this document, we introduce DNAT (Distributed Network Address Translation), an alternative to NAT. In particular, DNAT will eliminate all address and port translation at the router, providing an application independent mechanism for sharing an IP address amongst many hosts while providing end-to-end connectivity.

C. Bormann, "Network News Distribution Protocol: Architecture and Design Guidelines," Internet Engineering Task Force, Mar. 1998.

Abstract: This document describes an architecture and a set of protocols for distributing Netnews [RFC0977, RFC1036] via IP multicast enabled networks. The architecture is designed to be useful in the global Internet. In particular, it allows multiple news servers to cooperate on multicasting each new article only once. To facilitate scalability to tens of thousands of news servers, it also provides for receive-only multicast participants (that continue to send articles via conventional NNTP). This document is a submission to the IETF MNNP working group. Comments are solicited and should be addressed to the working groups' mailing list at ietf-mnnp@va.pubnix.com and/or the author.}

C. Bormann, J. Ott and N. Seifert, "MTP/SO: Self-Organizing Multicast," Internet Engineering Task Force, Jul. 1999.

Abstract: MTP/SO is a reliable multicast protocol based on the earlier protocols MTP (RFC1301) and MTP-2, simplifying the protocol considerably while adding self-organization of the members of the group into a hierarchy of local regions, local retransmissions, local NAK damping, and both global and local forward error correction. MTP/SO retains the coordinated many-to-many multicast model of MTP-2 while improving scalability.

J. Bouwen, B. Van Doorselaer and M. Dekeyser, "Issues for Megaco - Sigtran Interworking in ISDN Access Gateways," Internet Engineering Task Force, Jul. 2000.

Abstract: This document introduces the concept of an ISDN access gateway in the context of Megaco/H.248 and Sigtran protocols. For these ISDN access gateways, the ISDN B channels may be controlled by the Media Gateway Controller using megaco/H.248 while the User-to-Network signaling running over the D channels may be relayed to the Media Gateway Controller using either megaco/H.248 or the Sigtran protocols. The main issues involved are: * Megaco/H.248 and Sigtran protocols may interwork in different ways in ISDN access gateways, leaving room for non - interoperable solutions; * Megaco needs additional packages in order to support ISDN terminations in the ISDN access gateway; * A data service may be offered to ISDN users via the ISDN D- channel, introducing the need to introduce a NAS package for the D-channel. This document addresses these issues, proposes and explains different solutions and suggests best practice guideline for megaco / sigtran interworking in ISDN access gateways.

S. Bradner, "OSI connectionless transport services on top of UDP Applicability Statement for Historic Status," Internet Engineering Task Force, Jan. 1999.

Abstract: RFC 1240, 'OSI connectionless transport services on top of UDP', was published as a Proposed Standard in June 1991 but at this time there do not seem to be any implementations which follow RFC 1240. In addition there is a growing concern over using UDP-based transport protocols in environments where congestion is a possibility.

A. Farrel, P. Brittain and P. Matthews, "Fault Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Jul. 2000.

Abstract: MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit fault tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP.

N. Brown and C. Kindel, "Distributed Component Object Model Protocol -- DCOM/1.0," Internet Engineering Task Force, Mar. 1998.

Abstract: The Distributed Component Object Model protocol is an application-level protocol for object-oriented remote procedure calls useful for distributed, component-based systems of all types. It is a generic protocol layered on the distributed computing environment (DCE) RPC specification and facilitates the construction of task-specific communication protocols through features such as: a platform neutral argument/parameter marshaling format (NDR), the ability for objects to support multiple interfaces with a safe, interface- level versioning scheme suited to independent evolution by multiple parties, the ability to make authenticated connections and to choose levels of channel security, and a transport-neutral data representation for references (including by-value) to objects.

A. Brusilovsky, E. Gausmann, V. Gurbani and A. Jain, "A Proposal for Internet Call Waiting Service using SIP An Implementation Report," Internet Engineering Task Force, Jan. 1999.

Abstract: The purpose of this Internet Draft is to start discussion on the issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the services offered to the end Subscriber. It is the support of these services that necessitates the proposed internetworking project. Section 3 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and Figure A.

A. Brusilovsky, V. Gurbani, A. Jain and D. Varney, "Need for PSTN Internet Notification (PIN) ServiceA Proposal for a new Working Groups," Internet Engineering Task Force, Feb. 1999.

Abstract: The purpose of this Internet Draft is to start discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN Events Notification, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the PIN services. Section 3 describes the scope of the proposed project by introducing its overall architecture and identifying the interfaces to be standardized. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document.

A. Brusilovsky, J. Buller, L. Conroy, V. Gurbani and L. Slutsman, "PSTN Internet Notification (PIN) Architecture, Services and Protocols (A Provisional Framework)," Internet Engineering Task Force, Jun. 1999.

Abstract: The purpose of this Internet Draft is to continue discussion on the issues involved in PSTN Internet Notification (PIN), as part of interconnecting IP and Public Switched Telephone Network (PSTN) with the intent of converging existing and creating new hybrid PSTN and IP services. PSTN initiated Service Requests, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an Informational RFC.

b. Buffam, B. Thompson and T. Koren, "IP/UDP/RTP Header Compression over AAL2," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes a method to carry compressed and uncompressed traffic over AAL2. This proposal uses AAL2 frame mode SSCS to carry uncompressed protocols directly. The proposal also includes a new SSCS for carriage of compressed protocols over AAL2 frame mode to improve the bandwidth efficiency of RTP streams over an ATM network using compression and multiplexing. This proposal advocates the use of compressed RTP and multiplexing over ATM Adaptation Layer Type 2 (AAL2) frame mode. RTP traffic is first compressed, the resulting CRTP stream is then processed by the AAL2 CRTP Service Specific Convergence Sub-layer (AAL2 CRTP SSCS), to be multiplexed onto an AAL2 CPS-PDU frame mode stream. The resulting multiplexed stream is carried end-to-end through an ATM network and then mapped in reverse back into CRTP at the far end to be presented to the upper layer IP/UDP/RTP protocol stack.

H. Basilier, P. Calhoun, M. Holdrege, T. Johansson and J. Kempf, "AAA Requirements for IP Telephony/Multimedia," Internet Engineering Task Force, Jul. 2000.

Abstract: The AAA Working Group has been defining requirements for Network Access in an Inter-Domain (roaming) network, both Mobile IP and NASREQ. Some of these requirements were input from work done in the 3rd Generation wireless SDOs. These same SDO's have a need to tie their IP Intelligent Servers (e.g. Softswitches, Call Agents, SIP Servers, etc.) to their AAA infrastructure. This specification defines some requirements for both the AAA and IP Telephony protocols (SIP, MEGACO, etc.) This first Internet Draft is intended to simulate discussions within the SIP Working Group, in order to come up with a set of requirements that could then be used to begin protocol design.

M. Calsyn, L. Dusseault and G. Mohr, "RVP: A Presence Notification Protocol," Internet Engineering Task Force, Mar. 1998.

Abstract: A new kind of application is emerging on the Internet, driven by the desire of individuals to know instantly whether another individual is online, to be notified when another individual arrives online, and to send messages in \021real time\022. These are all special cases of the more general problem of Internet-wide notification. This protocol for facilitating rendezvous between users, known herein as RVP, is designed to enable such notifications and messages across a loosely coupled (federated) constellation of servers. RVP is designed to address the need for notification in a secure, reliable and scaleable fashion. RVP encompasses the client-server and server-server interactions. The authors recognize that there is significant overlap with between RVP and HTTP, though there are also significant differences. We expect RVP to evolve and either converge or diverge with HTTP and/or other existing protocols. The protocol described in this document represents a very viable starting point for a discussion of a standardized solution to the problem. Comments on this draft are solicited and should be sent to the authors or the RVP discussion list. To join the RVP discussion list, send email with the body 'subscribe' to rvp- request@iastate.edu

G. Camarillo and A. Roach, "Best Current Practice for ISUP to SIP mapping," Internet Engineering Task Force, Mar. 2000.

Abstract: This document describes a way to perform the mapping between two signalling protocols: SIP and ISUP.

K. Carlberg and I. Brown, "Framework for Supporting IEPS in IP Telephony," Internet Engineering Task Force, Nov. 2000.

Abstract: This document presents a framework for supporting authorized emergency-related communication within the context of IP telephony. We present a series of objectives that reflect a general view of how authorized emergency service, in line with International Emergency Preparedness Scheme (IEPS), should be realized within today's IP architecture and service models. From these objectives, we present a corresponding set of functional requirements, which provide a more specific set of recommendations regarding existing IETF protocols. Finally, we present two scenarios that act as guiding models for the objectives and functions listed in this document. These, models, coupled with an example of an existing service in the PSTN, contribute to a constrained solution space.

A. Casati and C. Perkins, "Generic Tunneling Protocol (GTP)," Internet Engineering Task Force, Mar. 2000.

Abstract: Some discussion has been lately going on on the standardization of GRE within the IETF. GRE has an Impact on standard track protocols such as Mobile IP. A Generic Tunneling Protocol (GTP) sharing the same format and byte order of the 3GPP GTP protocol ( 3G TS 29.060) benefits from the commonality of the encapsulation format used in IP mobility support protocols in different families of 3G standards.

D. Chadwick, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3," Internet Engineering Task Force, Jun. 1999.

Abstract: This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs.

S. Chisholm, "Alarm MIB," Internet Engineering Task Force, Oct. 2000.

Abstract: 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 management objects used for maintaining a list of alarms currently active on a network element.

S. Christey, "The Infinite Monkey Protocol Suite (IMPS)," Internet Engineering Task Force, Mar. 2000.

Abstract: This draft describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. The suite includes communications and control protocols for monkeys and the organizations that interact with them.

P. Cordell, "Conversational Multimedia URLs," Internet Engineering Task Force, Dec. 1997.

Abstract: The evolving technologies for real-time conversation over the Internet require URLs to provide user contact information. As there are many protocols (including some that are not Internet based) that can be used for inter-user conversation, this document describes a two stage transaction process for obtaining a URL that can be used to initiate conversation. The first stage involves retrieving a list of protocol specific URLs in a MIME encoded file. The MIME type enables an appropriate application to be launched which will analyse the presented URLs and select the most appropriate one. The second stage involves interpreting the protocol specific URL and initiating the conversation. The protocol specific URLs are encoded in a URL form so that they can be embedded directly into HTML pages. This allows the first stage to be omitted. The document describes the format of the MIME encoded list of URLs, and the format of a number of protocol specific URLs.

D. Cromwell and M. Durling, "Requirements For Control Of A Media Services Function," Internet Engineering Task Force, Nov. 1998.

Abstract: This document describes the functional requirements for protocol used by a call processing agent in a packet network to control an media services function located in the same packet network or at the inter- face of the packet network and the traditional telephone network. The primary focus of the protocol is on audio, however the protocol could be extended in the future to support other media streams such as video. The protocol provides the standard audio operations of play audio, collect DTMF, and record speech. It supports direct references to simple audio as well as indirect references to simple and complex audio. It provides multi-language audio variables, interruptibility of audio, digit buffer control, special key sequences, and support for reprompting during data collection. The approach used in specifying protocol functionality was to look at several existing protocols currently in use in the telephone network, taking the best concepts from each and attempting to avoid any limi- tations. The following protocols were examined: ITU CS1-R [2], Nor- tel Extended CS1-R [3], Bellcore GR-1129 [4], and Bellcore SR-3511 [5]. The protocol described in this document provides at a minimum a superset of the functionality of these protocols.

J. Crowcroft, H. Fuchs, T. Turletti, A. Ghosh, Z. Wang, L. Vicisano and C. Diot, "RMFP: A Reliable Multicast Framing Protocol," Internet Engineering Task Force, Mar. 1998.

Abstract: 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, e.g. [PGM], [RMDP], [RMTP], [SRM]. A survey of most of current reliable multicast protocols is available in [Diot97].

J. Crowcroft, "RTCP location reports," Internet Engineering Task Force, Feb. 1999.

Abstract: This note is a proposal to add lat/long data to RTCP reports to enable transport protocols, and applications to carry out a number of useful tasks.

C. Sapuntzakis and D. Cheriton, "TCP RDMA option," Internet Engineering Task Force, Feb. 2000.

Abstract: The TCP option introduced in this draft reduces the overhead of receiving data with TCP-based protocols such as NFS and HTTP. It enables the construction of a simple hardware accelerator that copies data directly from the incoming packet into application buffers, avoiding expensive copies in the protocol stack. Even without hardware acceleration, the option enables the protocol stack to decrease the number of copies it must do.

J. Cucchiara, J. Luciani and H. Sjostrand, "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)," Internet Engineering Task Force, Aug. 1998.

Abstract: 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 Multiprotocol Label Switching, Label Distribution Protocol (LDP) as defined in [17]. This memo does not specify a standard for the Internet community.

L. Daigle and R. Hedberg, "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," Internet Engineering Task Force, Jun. 2000.

Abstract: The strength of the TISDAG project's DAG proposal is that it defines the necessary technical infrastructure to provide a single-access-point service for information on Swedish Internet users. The resulting service will provide uniform access for all information - the same level of access to information (7x24 service), and the same information made available, irrespective of the service provider responsible for maintaining that information, their directory service protocols, or the end- user's client access protocol.

M. Daniele, "IANA Address MIB," Internet Engineering Task Force, Sep. 1998.

Abstract: This document contains an initial version of a MIB module for commonly used network addressing information. It defines a registry for identifiers that identify protocols and a set of textual conventions for representing addresses. This document also establishes IANA as the maintainer of this registry.

M. Day and D. Gilletti, "Content Distribution Network Peering Scenarios," Internet Engineering Task Force, Nov. 2000.

Abstract: This document sets forth several logical and detailed scenarios to be considered when evaluating systems and protocols for CDN peering.

M. Day, "''HTTP Envy'' and Presence Information Protocols," Internet Engineering Task Force, Mar. 1998.

Abstract: There are a variety of proposals [Calsyn, Mohr] for building a presence information protocol as a variant or version of HTTP. This document summarizes why I believe that is not a good idea.

T. Hasting, F. Wright, H. Lewis, S. Isaacson, R. deBry, C. Kugler and S. Gebert, "The Use of Post: A Response to draft-cohen-http-postal-00.txt," Internet Engineering Task Force, Feb. 1998.

Abstract: A recent Internet Draft [1] argues that the common use of POST to proide a uniform method of passing blocks of data to an application, is being misused in the definition of new application protocols, such as the Internet Printing Protocol. Cohen et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft argues that the existing POST method proides all of the required functionality for back end applications, such as Print, without sacrificing the leels of security that customers expect. More importantly, from the customer\022s point of iew, it does this without any impact to existing, installed network components.

N. Demizu, H. Esaki, K. Nagami and P. Doolan, "Virtual Connection Identifier," Internet Engineering Task Force, Oct. 1997.

Abstract: Several label switching schemes have been proposed to fuse and integrate the cost-performance and QoS assurance of Layer 2 devices and the flexibility and functionality of Layer 3 protocols. Some of these proposals assume that Label Switching Routers (LSRs) are placed in a homogeneous LSR cloud in a campus area network or a backbone network, and they are connected directly to each other. However, this assumption sometimes does not hold true in the real situation. For example, some campuses will be connected via ATM SVC service, and LSR networks will be constructed hierarchically. To deal with Virtual Connections (VCs) in these environments, this document proposes to identify a VC with a VCID instead of a label.

N. Demizu and H. Izumiyama, "Dynamic Tunnel Configuration Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: As the Internet grows, the importance of Uni-Directional Links such as satellite links has been increasing. However, most of existing routing protocols assume that datalinks are bi-directional. To incorporate UDLs into the Internet, an IP tunneling approach has been proposed, where tunnels are set up as a virtual back-channel of a UDL to carry routing information between Feeders and Receivers. Dynamic Tunnel Configuration Protocol (DTCP) supports to setup tunnels dynamically between Feeders and Receivers in such environments.

S. Dharanikota and S. Venkatachalam, "OSPF, IS-IS, RSVP, CR-LDP Extensions to Support inter-Area Traffic Engineering Using MPLS TE," Internet Engineering Task Force, Nov. 2000.

Abstract: In this draft, we propose the extensions required to the routing protocols, signaling protocols, and the MIB to support the idea of inter-area LSPs. A companion document [INTER_AREA_FWK] provides the architectural requirements for such a concept. This document also provides the signaling extensions to support the crankback as defined in the architecture document [INTER_AREA_FWK].

R. Dietz, "Remote Monitoring MIB Extensions or Application Performance Metrics," Internet Engineering Task Force, Jul. 1999.

Abstract: This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets.

R. Dietz, "Transport Performance Metrics MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and transport protocol states.

B. Dolnik, "Definitions of Managed Objects for the Universal Serial Bus (USB) Interface," Internet Engineering Task Force, Aug. 2000.

Abstract: 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 managing Universal Serial Bus (USB) interfaces.

A. Doria, T. Worster and K. Sundell, "Applicability of GSMP as an IETF Protocol," Internet Engineering Task Force, Oct. 1998.

Abstract: This memo discusses the applicability of the General Switch Management Protocol, GSMP, to network control protocols such as Multiprotocol Label Switching (MPLS). It discusses the need for this protocol to be standardized and discusses areas where development is still necessary. Finally, it recommends that the IETF establish a working group with the objective of furthering the protocol and working toward making it a standard. A PDF version of this draft can be found at: http://www. apocalypse.org/~avri/draft-doria-gsmp-applicability-00.pdf

M. Duerst and M. Davis, "Character Normalization in ITEF Protocols," Internet Engineering Task Force, Sep. 2000.

Abstract: The Universal Character Set (UCS) [ISO10646, Unicode] covers a very wide repertoire of characters. The IETF, in [RFC 2277], requires that future IETF protocols support UTF-8 [RFC 2279], an ASCII-compatible encoding of UCS. The wide range of characters included in the UCS has lead to some cases of duplicate encodings. This document proposes that in IETF protocols, the class of duplicates called canonical equivalents be dealt with by using Early Uniform Normalization according to Unicode Normalization Form C, Canonical Composition (NFC) [UTR15]. This document describes both Early Uniform Normalization and Normalization Form C.

A. Dugan, "IPDC Connection Control Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross- connect. Using the IP Connection Control protocol presented here, the media gateway controller can setup, modify and teardown connections within or between media gateways.

A. Durand, "MIME TYPE definition for IP in IP tunnels," Internet Engineering Task Force, Jul. 2000.

Abstract: IP in IP tunnels are very common in the Internet. They are often used to deploy new technologies such as multicast or IPv6 when the underlying infrastructure is not ready to natively support those new protocols. Virtual Private Network are also often build using IP in IP tunnels. This document describe a MIME type that provide configuration information about IP in IP tunnels.

W. Weiss, D. Durham and A. Westerinen, "Network Information Model Requirements," Internet Engineering Task Force, Jul. 2000.

Abstract: As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These very from Web based products, standard management protocols, and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the programmatics, with proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that a single application such as DHCP or Differentiated Services may be represented in many different inconsistent fashions. Even the existing standard descriptive technologies have not been focussed on re-use across domains and commonality. The situation would be significantly improved if there were to be a common representation of data (an 'information model') from which technology-specific data models can be derived to suit application- specific configuration and management needs. This would allow the industry to build common descriptions, resulting in consistency across the paradigms, and better interoperability. Such an 'information model' would also assist other IETF working groups by reducing the work needed to determine how to represent those parts of their technology that are already in the common model.

L. Dusseault and M. Calsyn, "Presence Information Protocol Requirements," Internet Engineering Task Force, Feb. 1998.

Abstract: Online users have demonstrated a desire to know instantly whether another individual is online, to be notified when another individual arrives online, and to send instant messages. These applications currently use independent, non-standard and usually non-interoperable protocols. The goal is to define a standard protocol so that independently written client and server implementations can participate in a global network of ''online'' users. This draft outlines requirements for a Presence Information Protocol to support these applications. Distribution of this document is unlimited. Please send comments to the RVP discussion list at rvp@iastate.edu, which may be joined by sending a message with subject ''subscribe'' to rvp- request@iastate.edu. Archives of past messages are available. Send the single word \021help\022 to rvp-request@iastate.edu for more information

R. Earhart, "Application Core Protocol," Internet Engineering Task Force, Mar. 1999.

Abstract: This document specifies a textual protocol intended as a framework for applications-layer protocols. While complete, it does not do anything in and of itself; it's meant to be extensible to particular applications.

R. Earhart, "Access Protocol," Internet Engineering Task Force, Jan. 1998.

Abstract: 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.

R. Earhart, "A POP3 URL Interface," Internet Engineering Task Force, Jan. 1998.

Abstract: It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The POP3 URL scheme allows a URL to specify a POP3 [POP3] server, allowing other protocols to use a general ''URL to be used for mail access'' in place of an explicit reference to POP3.

R. Earhart, "An SMTP URL Interface," Internet Engineering Task Force, Dec. 1997.

Abstract: It is occasionally useful to be able to reference a generic server to be used for message submission. URLs provide a good mechanism for refering to arbitrary network resources. The SMTP URL scheme allows a URL to specify an SMTP server, thus allowing other protocols to use a general ''URL to be used for message delivery'' in place of an explicit reference to SMTP.

D. Eastlake, "ISO 7812/7816 Numbers and the Domain Name System (DNS)," Internet Engineering Task Force, Jul. 2000.

Abstract: There are a variety of servers, web pages, and the like, which holders of ISO 7812 financial transaction identification card (i.e., credit/debit card) numbers and ISO 7816 smart card or related numbers may need to locate on the Internet. For example, some systems assume a smart card holder can contact the issuer of a smart card application for maintenance and update functions and the payment protocols may assume that a card holder can locate the appropriate certification authority to obtain a card holder certificate. This document specifies a method using the DNS as an important element in locating card related facilities on the Internet by mapping ISO 7812 and ISO 7816 number systems into domain names within in the card.reg.int domain.

Donald E. Eastlake, "Universal Payment Preamble," Internet Engineering Task Force, Oct. 1996.

Abstract: The Internet is becoming an increasingly commercial arena in which payments are rendered for goods, information, and services. To support such commerce, various incompatible Internet payment protocols have been proposed or adopted by a variety of organizations. There appears to be little prospect of merger of all or abandonment of most of these protocols. A header syntax, the Universal Payment Preamble (UPP), is presented for parties to negotiate payment alternatives at any point in shopping, until a final hand-off to a particular chosen payment system. The chosen payment system, not UPP, is responsible for the security of any actual transmission of funds.

Keywords: payment protocol; electronic commerce

R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering Task Force, Apr. 2000.

Abstract: The purpose of this draft is to provide an extensive comparison between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic Authentication, Authorization and Accounting (AAA) protocols. The protocols will further be verified on their compliance to the NAS requirements described in [TBA] and roaming requirements described in RFC 2477.

R. Ekstein, Y. T'Joens, B. Sales and O. Paridaens, "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.," Internet Engineering Task Force, Jan. 2000.

Abstract: The purpose of this draft is to provide an extensive comparison between the RADIUS, DIAMETER and COPS protocols as these are positioned as generic Authentication, Authorization and Accounting (AAA) protocols. The protocols will further be verified on their compliance to the NAS requirements described in [TBA] and roaming requirements described in RFC 2477.

I. Elliott, "IPDC Media Control Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: The protocol described in this document is a member of the IP Device Control (IPDC) family of protocols. The IPDC protocols are proposed as a protocol suite, components of which can be used individually or together to perform connection control, media control, and signaling transport for environments where the service control logic is separated from the network access server. Please see the references section for other IPDC documents. The protocol specification presented here is intended for use between a media gateway controller and a media gateway. The media gateway may be capable of acting as a voice over IP gateway, voice over ATM gateway, dialup modem media gateway, circuit switch, or cross-connect. Using the IP Media Control protocol presented here, the media gateway controller can send messages to the media gateway to cause events such as tones to be generated or detected within a media stream.

G. Vaudreuil and G. Parsons, "Voice Profile for Internet Mail - version 2," Internet Engineering Task Force, Nov. 1999.

Abstract: Voice messaging evolved as telephone answering service into a full send, receive, and forward messaging paradigm with unique message features, semantics and usage patterns. Voice messaging was introduced on special purpose computers that interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent from one voice messaging system to another were transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there was a need for a standard high-quality digital protocol to connect these machines. VPIM has successfully demonstrated its usefulness as this new standard. VPIM is widely implemented and is seeing deployment in early adopter customer networks. This document clarifies ambiguities found in the earlier specification and is consistent with implementation practice. The profile is referred to as VPIM (Voice Profile for Internet Mail) in this document. This second revision of the version 2 of obsoletes RFC 2421 which less precisely describes version 2 of the profile.

S. Casner, C. Bormann and M. Engan, "IP Header Compression over PPP," Internet Engineering Task Force, Dec. 1997.

Abstract: This document describes an option for negotiating the use of header compression on IP datagrams transmitted over the Point-to- Point Protocol [RFC1661]. It defines extensions to the PPP Control Protocols for IPv4 and IPv6 [RFC1332, RFC2023]. Header compression may be applied to IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols as specified in [IPHC] and [CRTP]. [Note to IANA, to be removed before publication: The PPP protocol type assignments suggested in this document were selected from those unassigned in http://ftp.isi.edu/in-notes/iana/assignments/ppp-numbers on December 7, 1997. These selections were presented to the PPPEXT working group at IETF in Washington, DC on December 9, 1997 and were approved as being in the appropriate ranges for this protocol.]

D. Farinacci, L. Wei and J. Meylor, "Use of Anycast Clusters for Inter-Domain Multicast Routing," Internet Engineering Task Force, Mar. 1998.

Abstract: Anycast Clusters is a proposal to connect multiple ISP sparse-mode PIM domains together. The environment we anticipate is multiple interconnection points among a set of ISPs when they are unable to colocate their respective RPs at the same dense-mode interconnect point. This is an alternative to the Multi-Level RP design and requires less new code in routers. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment and is upward compatible with the IDMR protocols being proposed for subsequent phases.

D. Farinacci, P. Lothberg, Y. Rekhter, H. Kilmer and J. Hall, "Multicast Source Discovery Protocol (MSDP)," Internet Engineering Task Force, Jun. 1998.

Abstract: This proposal describes a mechanism to connect multiple PIM-SM domains together. Each PIM-SM domain uses it's own independent RP(s) and do not have to depend on RPs in other domains. This proposal is being submitted as a method for the initial phase of Inter-Domain Multicast deployment in the Internet and may be upward compatible with the IDMR protocols being proposed for subsequent phases.

A. Farrel and P. Brittain, "Fault Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Feb. 2000.

Abstract: MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high-availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP.

G. Fiaschi, F. Poggi and G. Rolandelli, "A proposal to provide QoS capability for PPP," Internet Engineering Task Force, Jul. 2000.

Abstract: Quality of Service in the IP protocol has been proposed in some service definitions (Int-Serv and Diff-Serv) and in a variety of schemes and supporting protocols (RSVP). These schemes assume, of course, that all the protocols supporting IP links in turn provide a well-defined degree of QoS the IP schemes can rely upon. One of the most common link protocols is PPP. The PPP protocol provides a standard method for transporting multi-protocol datagrams over point-to-point links. It was designed to be used in serial point-to-point links. These ones can be for example PSTN circuits, characterized by a fixed bandwidth and fixed delay. Hence, there was no need to specify QoS mechanisms for PPP: the IP layer (or more generally the network layer) did not take into account the data-link layer to calculate the available resources.

R. Finlayson, "The Multicast Attribute Framing Protocol," Internet Engineering Task Force, Jan. 1998.

Abstract: 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 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 standard for this class of application.

E. Fleischman, "Advanced Streaming Format (ASF) Specification," Internet Engineering Task Force, Feb. 1998.

Abstract: The Advanced Streaming Format (ASF) is an extensible file format designed to store synchronized multimedia data. It supports data delivery over a wide variety of networks and protocols while still proving suitable for local playback. ASF supports advanced multimedia capabilities including extensible media types, component download, scaleable media types, author-specified stream prioritization, multiple language support, and extensive bibliographic capabilities, including document and content management.

S. Floyd, "Congestion Control Principles," Internet Engineering Task Force, Jun. 2000.

Abstract: The goal of this document is to explain the need for congestion control in the Internet, and to discuss what constitutes correct congestion control. One specific goal is to illustrate the dangers of neglecting to apply proper congestion control. A second goal is to discuss the role of the IETF in standardizing new congestion control protocols. This document draws heavily from earlier RFCs, in some cases reproducing entire sections of the text of earlier documents [RFC2309, RFC2357]. We have also borrowed heavily from earlier publications addressing the need for end-to-end congestion control [FF99].

B. Foster, "MGCP CAS Packages," Internet Engineering Task Force, Oct. 2000.

Abstract: This document contains a collection of media gateway CAS packages for R1 CAS, North American CAS, CAS PBX interconnect as well as basic FXO support. Included are six packages. The 'MS' package covers MF single stage dialing trunks. This includes wink start and immediate start PBX DID/DOD trunks as well as basic R1 and Feature Group D (FGD) Terminating protocol [3]. The 'DT' package covers immediate start and basic DTMF and dial-pulse trunks and the 'BL' package covers the interface to a basic PBX (digital or FXS interface). In addition to the Terminating protocol, there are three other FGD protocols described in [3]. These include EAIN and EANA which is covered by the enclosed 'MD' package and the Operator Service Signaling protocol which is handled by the 'MO' package. Support for basic FXO interconnect is provided by 'DO' package.

J. Postel and N. Freed, "IANA Charset Registration Procedures," Internet Engineering Task Force, Sep. 1997.

Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other modern Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This registration procedure exists solely to associate a specific name or names with a given charset and to give an indication of whether or not a given charset can be used in MIME text objects. In particular, the general applicability and appropriateness of a given registered charset is a protocol issue, not a registration issue, and is not dealt with by this registration procedure.

N. Freed and J. Postel, "IANA Charset Registration Procedures," Internet Engineering Task Force, Jul. 2000.

Abstract: MIME [RFC-2045, RFC-2046, RFC-2047, RFC-2184] and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential.

W. Fritsch and H. Seifert, "Dynamical routing (unicast and multicast) for the Ipv6 protocol," Internet Engineering Task Force, Nov. 1997.

Abstract: 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 also only a single routing tree for the whole area. This version 02 of the draft mainly corrects some minor errors of version 01.

R. Gellens, "POP URL Scheme," Internet Engineering Task Force, Mar. 1998.

Abstract: [POP3] is a widely-deployed mail access protocol. Many programs access POP3 message stores, and thus need POP3 configuration information. Since there are multiple configuration elements which are required in order to access a mailbox, a single string representation is convenient. A POP3 mailbox (like an [IMAP4] mailbox) is a network resource, and URLs are a widely-supported generalized representation of network resources. A means of specifying a POP3 mailbox as a URL will likely be useful in many programs and protocols. [ACAP] is one case where a string encapsulation of elements required to access network services is needed. For example, an [IMAP4] message store is usually specified in ACAP datasets as an [IMAP-URL].

J. Gettys and H. Nielsen, "The WebMUX Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: This document defines the experimental multiplexing protocol referred to as 'WebMUX'. WebMUX is a session management protocol separating the underlying transport from the upper level application protocols. It provides a lightweight communication channel to the application layer by multiplexing data streams on top of a reliable stream oriented transport. By supporting coexistence of multiple application level protocols (e.g. HTTP and HTTP/NG), WebMUX should ease transitions to future Web protocols, and communications of client applets using private protocols with servers over the same TCP connection as the HTTP conversation. WebMUX is intended for, but by no means restricted to, transport of Web related protocols; the name has been chosen to reduce confusion with other existing multiplexing protocols. This document is part of a suite of documents describing the HTTP-NG design and prototype implementation: * HTTP-NG Short- and Longterm Goals, ID * HTTP-NG Architectural Model, ID * HTTP-NG Wire Protocol, ID * The Classic Web Interfaces in HTTP-NG, ID * Description of the HTTP-NG Testbed, ID

N. Ghani, Z. Zhang, L. Zhang and J. Fu, "COPS Usage for ODSI," Internet Engineering Task Force, Jul. 2000.

Abstract: ODSI is a framework of protocols designed to allow internetworking devices to dynamically request bandwidth from optical networks. Within this framework, a protocol is required for policy provisioning inside the optical domain. This documents defines the application of the IETF Common Open Policy Service (COPS) protocol for this purpose and details its interworking with the ODSI framework.

S. Giacalone, "Scored Fair Metric Calculation," Internet Engineering Task Force, Aug. 2000.

Abstract: This memo defines a modular metric calculation system termed Scored Fair Metric Calculation (SFMC). SFMC can be integrated with Link State and Distance Vector routing protocols and their extensions [1,4,5,6,7], enabling them to find network paths that support the highest possible number of best metrics across a network. SFMC makes it possible to support and mix large sets of heterogeneous network features and capabilities. SFMC solves many of the issues inherent in routing protocols that attempt to use complex sets of metrics by decoupling raw metric data from the input side of routing protocols. Unlike the past, SFMC regards all metrics all the time, while treating all metrics equally (by default). Additionally, the SFMC architecture provides a simple and flexible interface for extensive manipulation of path selection. Please send comments to ospf@discuss.microsoft.com.}

B. Chen, H. Frystyk, L. Girod and J. Mallery, "WIRE - W3 Identifier Resolution Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: WIRE extends HTTP with a new type of redirect response that permits a resolver to explicitly delegate a resolution to other resolvers and protocols. WIRE is an effort to make delegation more explicit, redirection more flexible, and resolution processes more efficient through the use of hints. This document defines WIRE and describes the expected behaviors of resolvers and clients using WIRE. WIRE is an extension of the HyperText Transfer Protocol (HTTP), and is intended to be compatible with HTTP/1.0 and above [4][5]. WIRE encourages use of long-lived URIs and at the same time supports protocol evolution without having to change currently deployed URIs or URI schemes. The extension is based on a simple URI resolution model that allows an application to dynamically request metadata describing where and how to access a resource. The model can use any generic metadata description language (e.g. RDF) and as the metadata itself is interpreted as a first class resource, metadata resources are no different than any other resource on the Web.

G. Mansfield, K. Ohta and T. Ika, "A Directory for organizations and services from DNS and WHOIS.," Internet Engineering Task Force, Nov. 1997.

Abstract: An Internet Directory is a necessity. The lack of an Internet Directory is posing serious problems. There are several Directory Protocols ready for deployment in the Internet. But, among other factors, content generation for the directory has been a major stumbling block. A simple and straight-forward method of generating contents for a directory of organizations and their network services using information from the Domain Name System (DNS) and the WHOIS servers is described in this memo.

G. Mansfield and D. Gupta, "Intrusion Detection Message MIB," Internet Engineering Task Force, Jan. 2000.

Abstract: 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 the contents of messages that will be exchanged among intrusion detection systems when an intrusion is detetcted.

K. Grace, "Mobile Mesh Border Discovery Protocol," Internet Engineering Task Force, Sep. 2000.

Abstract: The Mobile Mesh Border Discovery Protocol (MMBDP) enables a mobile adhoc network to utilize a fixed/wired network for dissemination of routing information and for forwarding of data. MMBDP is one protocol in a set of related Mobile Mesh protocols that also includes the Mobile Mesh Link Discovery Protocol (MMLDP) and the Mobile Mesh Routing Protocol (MMRP). Together, these protocols provide a flexible, extensible mobile adhoc networking capability.

K. Grace, "Mobile Mesh Link Discovery Protocol," Internet Engineering Task Force, Sep. 2000.

Abstract: The Mobile Mesh Link Discovery Protocol (MMLDP) provides a media independent mechanism for discovering neighbors in a mobile adhoc network, and is capable of determining whether links are unidirectional or bidirectional. MMLDP is one protocol in a set of related Mobile Mesh protocols that also includes the Mobile Mesh Routing Protocol (MMRP) and the Mobile Mesh Border Discovery Protocol (MMBDP). Together, these protocols provide a flexible, extensible mobile adhoc networking capability.

C. Grall, "Firewall Management Information Base," Internet Engineering Task Force, Apr. 1998.

Abstract: This document 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 monitoring firewall devices.

M. Green, B. Cain and G. Tomlinson, "CDN Peering Architectural Overview," Internet Engineering Task Force, Oct. 2000.

Abstract: This memo presents the general architecture and core building blocks used in the peering of content distribution networks (CDNs). This involves the interconnection of CDNs to create larger virtual CDNs with greater reach, while still retaining the same simple interface to both content providers and viewers. The scope of this work is limited to external interconnections between CDNs and does not address internal mechanisms used within CDNs, which for the purpose of the document are considered to be black boxes. This work is intended to establish an abstract architectural framework to be used in the development of protocols, interfaces and system models for standardized, interoperable, peering among CDNs, and peering of CDNs with content providers. The term 'peering' used within this memo is defined as the coupling and interaction between CDNs in order to build internetworks of CDNs.

B. Greenblatt, "LDAP Object Class for Holding Certificate Information," Internet Engineering Task Force, Feb. 2000.

Abstract: This draft describes a means for LDAP applications to store large numbers of certificates for a single user, and to still have individual certificates easily retrievable without the need for any extensions to the LDAP v2 or v3 protocols.

C. Huitema, M. Holdrege, N. Greene, L. Ong and F. Cuervo, "SS7-Internet Interworking - Architectural Framework," Internet Engineering Task Force, Aug. 1998.

Abstract: This document describes an architectural framework for SS7-Internet interworking, onto which existing protocols and future protocols in this space can be mapped. It also provides an ordering of importance for the standardization of these protocols.

S. Guthery, Y. Baudoin, J. Posegga and J. Rees, "IP and ARP over ISO 7816-3," Internet Engineering Task Force, Feb. 2000.

Abstract: ISO/IEC 7816-3 [4] describes a half-duplex character transmission protocol called 'T=0' between a terminal and an integrated circuit card ('ICC' or 'smart card'). ISO/IEC 7816-3 Amendment 1 [5] describes a half-duplex block transmission protocol called 'T=1' also between a terminal and an ICC. We shall refer to these two protocols generically as the ISO 7816-3 data-link protocols. For the purpose of this note, a terminal together with all the ICCs inserted into it is taken to be a data-link layer subnetwork wherein the terminal acts as the gateway router for this subnetwork.

T. Harding, "Extensible Protocol," Internet Engineering Task Force, Feb. 1999.

Abstract: This memo defines the Extensible Protocol (XP). XP is a generic application-level protocol meant to serve as the foundation for specific protocols, in a manner analogous to the way in which the Extensible Markup Language (XML) recommendation of the World Wide Web Consortium serves as the foundation for specific markup languages. XP is a bidirectional protocol on which XML documents are exchanged between two endpoints.

M. Hattig, "Home Network Requirements," Internet Engineering Task Force, Jun. 1999.

Abstract: Current home networking protocols consist of home automation protocols, consumer electronics protocols for audio/video systems, and TCP/IP for data networking. This document focuses on TCP/IP protocols for home networking. Specifically in this document, home networking is TCP/IP data networking between devices in a single home, between devices in separate homes, between devices in the home and on the Internet, and between devices in the home and on a secure corporate network. This document provides requirements for this type of home networking.

R. Agarwal, J. Ayars, B. Hefta-Gaub and D. Stammen, "RealMedia File Format," Internet Engineering Task Force, Mar. 1998.

Abstract: The RealMedia File Format (RMFF) is designed to be a generic container for streaming media data. This data may then be played back locally or streamed over a network using protocols such as RTSP and RTP. The format is data-independent, allowing any data type to be recorded, manipulated and played back. Note: This document is intended to be informational in nature of what the file format in use by RealNetworks' RealServer and RealPlayer implementations. Though we think that there are a lot of important concepts embodied in this specification, and that it may even make the basis of a ''standard'' file format, this is intended to eventually end up as an Informational RFC.

J. Heinanen, D. Allan, A. Lin and P. Shieh, "PPP Internet Protocol Control Protocol Extensions for IP Subnet," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2] by defining an IP Subnet configuration option.

J. Heinanen, D. Allan, P. Helenius and A. Lin, "PPP Internet Protocol Control Protocol Extensions for IP Subnet," Internet Engineering Task Force, Mar. 2000.

Abstract: 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 and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2] by defining an IP Subnet configuration option.

H. Holbrook and B. Cain, "Source-Specific Multicast for IP," Internet Engineering Task Force, Mar. 2000.

Abstract: IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOCATION]. This document defines the semantics of source- specific multicast addresses and specifies the policies governing their use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host extensions to support this service. Appendix I of this document describes changes to the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source- specific multicast.

H. Holbrook and B. Cain, "Source-Specific Multicast for IP," Internet Engineering Task Force, Jul. 2000.

Abstract: IP addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols [IANA-ALLOCATION]. This document defines the semantics of source- specific multicast addresses and specifies the policies governing their use. It defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this service. A companion document, [IGMPSSM], describes how the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] can be adapted to support source-specific multicast.

K. Holtman, A. Mutz and E. Hardie, "The Alternates Header Field," Internet Engineering Task Force, Mar. 1999.

Abstract: This document proposes a header, Alternates, which is intended to provide a common method for Internet-based application protocols to indicate that a particular resource exists in multiple forms. The Alternates header provides a machine-readable indication of the bases on which the different forms vary and how the the recipient of the header can select among them.

N. Shen and H. Smit, "Calculating IGP routes over Traffic Engineering tunnels," Internet Engineering Task Force, Jun. 1999.

Abstract: This document describes how conventional hop-by-hop link-state routing protocols interact with new Traffic Engineering capabilities. Such capabilities are specified in [1], [2], [3] and [4]. In particular this document describes how Dijkstra's SPF algorithm should be adapted so that link-state IGPs will calculate IP routes to forward traffic over tunnels that are set up by Traffic Engineering.

G. Hudson, "Instant Messaging / Presence Architecture," Internet Engineering Task Force, Dec. 1999.

Abstract: This document proposes an architecture for the protocols to be produced by the IMPP working group.

G. Hudson, "Security in the Instant Message and Presence Protocols," Internet Engineering Task Force, May 2000.

Abstract: This document describes the security issues and options associated with instant messaging and transmission of presence as they are being considered in the IMPP working group. This document uses many terms described in [RFC 2778], which describes a model for instant messaging.

G. Hudson, "Instant Message and Presence Transfer Protocols," Internet Engineering Task Force, May 2000.

Abstract: This document specifies transfer protocols for instant messages and presence information. The Presence Information Transfer Protocol (PITP) allows clients to set presence information for presentities they control and to request presence information from other presentities. The Instant Message Transfer Protocol (IMTP) allows clients to send and receive instant messages. Both protocols can also be used to relay instant message and presence requests between servers as necessary. These protocols are specified in the same document because they have very similar structure. However, they are two logically separate protocols. Sections specific to one or the other protocol will be recognizeable by a leading 'PITP' or 'IMTP'.

M. Arango, A. Dugan, I. Elliott, C. Huitema and S. Pickett, "Media Gateway Control Protocol (MGCP)," Internet Engineering Task Force, Feb. 1999.

Abstract: This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gate- ways from external call control elements. MGCP assumes a call control architecture where the call control 'intelligence' is outside the gateways and handled by external call control elements. The document is structured in 6 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP: Notifications Request, Notification, Create Connection, Modify Con- nection, Delete Connection, AuditEndpoint, AuditConnection and Res- tartInProgress. * The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC). * The event packages section provides an initial definition of pack- ages and event names. * The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 0.1.

M. Arango and C. Huitema, "Simple Gateway Control Protocol (SGCP)," Internet Engineering Task Force, Sep. 1998.

Abstract: This document describes an application programming interface (SGCI) and a corresponding protocol (SGCP) for controlling Voice over IP (VoIP) Gateways from external call control elements. The SGCP assumes a call control architecture where the call control 'intelligence' is outside the gateways and handled by external call control elements. The document is structured in 5 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the SGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the five procedurs that compose SGCP: Notifications Request, Notification, Create Connection, Modify Con- nection and Delete Connection. * The protocol description section presents the SGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of SGCP, and its usage of IP security services (IPSEC). * An example section presents two detailed examples of call set up procedures using SGCP. * The description of the changes between version 1.0 and version 1.1

L. Daigle, "A Tangled Web:issues of I18N, domain names, and the other Internet protocols," Internet Engineering Task Force, Apr. 2000.

Abstract: The goals of the work to 'internationalize' Internet protocols include providing all users of the Internet with the capability of using their own language and its standard character set to express themselves, write names, and to navigate the network. This impacts the domain names visible in e-mail addresses and so many of today's URLs used to locate information on the World Wide Web, etc. However, domain names are used by Internet protocols that are used across national boundaries. These services must interoperate worldwide, or we risk isolating components of the network from each other along locale boundaries. This type of isolation could impede not only communications among people, but opportunities of the areas involved to participate effectively in e-commerce, distance learning, and other activities at an international scale, thereby retarding economic development. There are several proposals for internationalizing domain names, however it it is still to be determined whether any of them will ensure this interoperability and global reach while addressing visible-name representation. Some of them obviously do not. This document does not attempt to review any specific proposals, as that is the work of the Internationalized Domain Name (IDN) Working Group of the IETF, which is tasked with evaluating them in consideration of the continued global network interoperation that is the deserved expectation of all Internet users. This document elaborates the scope of the problem outside of the domain name system (DNS).

S. Bellovin, "Security Mechanisms for the Internet," Internet Engineering Task Force, Nov. 1998.

Abstract: Many different mechanisms can be used to provide security for protocols. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

D. Mitzel, "Overview of 2000 IAB Wireless Internetworking Workshop," Internet Engineering Task Force, Aug. 2000.

Abstract: This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evalu- ate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sec- tors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community. Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mail- ing list.}

T. Narten and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs," Internet Engineering Task Force, Sep. 1998.

Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.

K. Moore, "Privacy Considerations for the Use of Hardware Serial Numbers in End-to-End Network Protocols," Internet Engineering Task Force, Jan. 1999.

Abstract: This memo describes privacy risks associated with the use of hardware serial numbers in network protocols, and some countermeasures which can ameliorate those risks.

K. Moore and P. Faltstrom, "On the use of HTTP as a Substrate for Other Protocols," Internet Engineering Task Force, Aug. 1998.

Abstract: Recently there has been widespread interest in using Hypertext Transport Protocol (HTTP) as a substrate for other applications-level protocols. This document relates current IESG and IAB thinking on technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. This thinking is subject to change as discussion continues and more experience is gained with such use.

P. Nesser II, "The Internet and the Millenium Problem (Year 2000)," Internet Engineering Task Force, Jan. 1999.

Abstract: The Year 2000 Working Group(WG) has conducted an investigation into the millennium 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 discovered, 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.

N. Brownlee and A. Blount, "Accounting Attributes and Record Formats," Internet Engineering Task Force, Jun. 2000.

Abstract: This draft summarises IETF and ITU-T documents related to Accounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats for Accounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This draft discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described.

J. Vollbrecht, P. Calhoun, S. Farrell, M. Holdrege, G. Gross, L. Gommans, B. de Bruijn and D. Spence, "AAA Authorization Architecture and Requirements," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols. The authorization needs of several different applications are considered in a lengthy appendix.

B. Aboba, P. Calhoun and others, "Criteria for Evaluating AAA Protocols for Network Access," Internet Engineering Task Force, Aug. 2000.

Abstract: This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ, ROAMOPS, and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents.

D. Mitton and others, "Authentication, Authorization, and Accounting:Protocol Evaluation," Internet Engineering Task Force, Oct. 2000.

Abstract: This document represents the preliminary findings of the AAA WG panel evaluating protocols proposed against the AAA Network Access Require- ments. Due to time constraints this document is not as fully developed as desired. And may be updated on the working group list. This document is a draft submission of the Authentication, Authoriza- tion, and Accounting (AAA) Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list aaa-wg@merit.edu.}

D. Mitton, "Proxy Nodes in AAA Configurations," Internet Engineering Task Force, Nov. 2000.

Abstract: This document describes the issues and gives examples of typical proxy systems in AAA applications. The purpose of this effort is to set the reference space evaluating and improving AAA protocols, such as the Diameter protocol, currently being reviewed in this WG. This first version sets out some of the issues and requirements. The next version will add some solution proposals.

C. Newman, "Anonymous SASL Mechanism," Internet Engineering Task Force, Aug. 1997.

Abstract: It is common practice on the Internet to permit anonymous access to various services. Traditionally, this has been done with a plain text password mechanism using 'anonymous' as the user name and optional trace information, such as an email address, as the password. As plaintext login commands are not permitted in new IETF protocols, a new way to provide anonymous login is needed within the context of the SASL [SASL] framework.

B. Ray and R. Abbi, "Definitions of Managed Objects for HDSL2 and SHDSL Lines," Internet Engineering Task Force, Oct. 2000.

Abstract: This document defines an experimental portion of the Management Information Base (MIB) MIB module for use with network management protocols in the Internet community. In particular, it describes objects used for managing HDSL2 and SHDSL interfaces. 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.

D. Miller, "GSS-API Authentication Method for SOCKS Version 5," Internet Engineering Task Force, Jun. 1999.

Abstract: The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and in particular, the use of the Simple and Protected GSS API Negotiation (SPNEGO) mechanism. Use of the SPNEGO pseudo- mechanism is intended to maximize the chance of agreement of a security mechanism, and hence maximize interoperability. A message protection subnegotiation protocol is also specified, allowing peers to agree on which message protection services GSS-API encapsulated messages will be protected with: integrity, or integrity and confidentiality. Other GSS-API security services, normally optional with GSS-API, are specified for use with SOCKS 5.

J. Michener and D. Fritch, "Multi-Authentication Framework Method for SOCKS V5," Internet Engineering Task Force, Mar. 1998.

Abstract: SOCKS V5 [RFC 1928] provides a means to select one from among a number of authentication methods, but does not provide any means for utilizing multiple authentication methods to obtain desired authentication properties. This document specifies the Multi- Authentication Framework Method (MAF) which is a method extension to SOCKS Version 5 to support the efficient management of composite authentication protocols composed of more than one authentication methods. MAF is a client-initiated but server managed framework. MAF relies upon a trusted Authentication Management Server (AMS) to select the authentication methods to be invoked, order them as appropriate, and assign integrity grades to the final authentication after all methods invoked have been completed.

L. Heintz, S. Gudur and M. Ellison, "Definitions of Managed Objects for Extensible SNMP Agents," Internet Engineering Task Force, Jun. 1999.

Abstract: 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. This memo does not specify a standard for the Internet community.

C. Kalbfleisch, C. Krupczak, R. Presuhn and J. Saperia, "Application Management MIB," Internet Engineering Task Force, Nov. 1998.

Abstract: 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.

J. Saperia and C. Krupczak, "Definitions of System-Level Managed Objects for Applications," Internet Engineering Task Force, Oct. 1997.

Abstract: 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.

C. Kalbfleisch, H. Hazewinkel and J. Schoenwaelder, "Definitions of Managed Objects for WWW Services," Internet Engineering Task Force, Mar. 1999.

Abstract: 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.

C. Weider, B. Huston and J. Strassner, "LDAP Multi-Master Replication Protocol," Internet Engineering Task Force, Nov. 1997.

Abstract: 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. In addition, it specifies a conflict resolution mechanism for integrating updates from multiple servers.

G. Good, U. Srinivasan and S. Jain, "Schema for Replication Information," Internet Engineering Task Force, Oct. 1997.

Abstract: 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.

S. Kille, T. Howes and M. Wahl, "UTF-8 String Representation of Distinguished Names," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

B. Aboba, "Extension for PPP Authentication," Internet Engineering Task Force, Nov. 1997.

Abstract: This document defines the ''PPP Authentication Operation'' for LDAP. This operation provides for PPP authentication in an LDAP association and is defined in terms of an LDAP extended operation. It is believed that an LDAP extended operation is the appropriate mechanism for pro- viding this support, since current LDAP security mechanisms do not support PPP authentication methods. In addition, requiring a BIND and UNBIND for each authentication results in an unacceptable level of overhead. It is expected that this extended operation will be useful in inte- grating authentication protocols such as RADIUS and TACACS+ with LDAP- based directory services. Consolidation of information stores is desirable since it results in lessened administrative workload and a consistent view of user information throughout the enterprise.

S. Kille, T. Howes and M. Wahl, "Lightweight Directory Access Protocol (v3)," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

K. McCloghrie, J. Heinanen, W. Greene and A. Prasad, "Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks," Internet Engineering Task Force, Oct. 1998.

Abstract: 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 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 [19].

K. Tesink, "Definitions of Managed Objects for ATM Management," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 ATM-based interfaces, devices, networks and services. This memo replaces RFC1695[24].Changes relative to RFC1695 are summarized in the MIB module's REVISION clause. Textual Conventions used in this MIB are defined in [6] and [19].

K. McCloghrie, J. Heinanen, W. Greene and A. Prasad, "Accounting Information for ATM Networks," Internet Engineering Task Force, Oct. 1998.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. A separate memo [16] 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.

J. Johnson, M. Thatcher and J. Kuhfeld, "Definitions of Managed Objects for SONET Linear APS Architectures," Internet Engineering Task Force, Nov. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing networks using SONET linear Automatic Protection Switching (APS) architectures.

K. Tesink, "Definitions of Managed Objects for the SONET/SDH Interface Type," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) interfaces. This document is a companion to the documents that define Managed Objects for the DS1/E1/DS2/E2 and DS3/E3 Interface Types [24][25]. Textual Conventions used in this MIB are defined in [6] and [36]. This memo replaces RFC1595 [30]. Changes relative to RFC1595 are summarized in the MIB module's REVISION clause.

M. Noto and K. Tesink, "Definitions of Tests for ATM Management," Internet Engineering Task Force, Dec. 1999.

Abstract: 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 ATM-based interfaces, devices, networks and services in addition to those defined in the ATM MIB [RFC2515], to provide support for the management of on-demand ATM Loopback Tests.

D. Hoffman, G. Fernando, V. Goyal and R. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video," Internet Engineering Task Force, Nov. 1997.

Abstract: 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 pro- tocol, 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. A new section on security considerations for this payload type is added.

M. Baugher, I. Suconick and B. Strahm, "Real-Time Transport Protocol Management Information Base," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 managing Real-Time Transport Protocol(RTP) systems [RFC1889].

B. Thompson, T. Koren and D. Wing, "Tunneling multiplexed Compressed RTP ('TCRTP')," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes a method to improve the end-to-end bandwidth utilization of RTP streams over an IP network using compression and multiplexing. Several application level compression/multiplexing solutions have been evaluated so far in the IETF AVT Working Group. This proposal differs from other solutions in that neither compression nor multiplexing needs to be done at application level. Because of this, existing RTP based applications do not need to change to support this encapsulation format. Instead of proposing a new encapsulation format for end to end multiplexing, this document describes the application of existing protocols for compression, multiplexing, and end to end tunneling.

J. Dunn and C. Martin, "Framework for Router Benchmarking," Internet Engineering Task Force, Jul. 2000.

Abstract: This memo discusses and proposes a framework for the development of IP performance benchmarking methodologies in the case of systems under test (SUT) running IETF routing protocols. The intent of this document is to facilitate the use of existing metrics developed by the BMWG and other working groups. This will be accomplished by specifying router configuration and state parameters and characterizing their effect on IP packet forwarding in terms of these existing metrics. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 2285, and 2544 and 2761. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF).

L. Bell, A. Smith, P. Langille, A. Rijsinghani and K. McCloghrie, "Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions," Internet Engineering Task Force, Jun. 1999.

Abstract: 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 MAC bridges based on the IEEE 802.1D-1998 MAC Bridges and IEEE 802.1Q-1998 Virtual LAN (VLAN) standards for bridging between Local Area Network (LAN) segments. Provisions are made for support of transparent bridging. Provisions are also made so that these objects apply to bridges connected by subnetworks other than LAN segments. This memo also includes several MIB modules in a manner that is compliant to the SNMPv2 SMI [5].

B. Mahoney, A. Taler and G. Babics, "Implementors' Guide to Internet Calendaring," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes the relationship between the various internet calendaring and scheduling protocols defined by RFC 2445 (iCalendar), RFC 2446 (iTIP), and RFC 2447 (iMIP), as well as the works in progress,'iCalendar Real-time Interoperability Protocol' (iRIP), and 'Calendar Access Protocol' (CAP). It's intention is to provide a context for these protocols, assist in their understanding, and ultimately help implementors in the design of their internet calendaring and scheduling systems. [Note: in the past there has been some discussion as to whether iRIP was a live effort, given that interest has waned and some functionality has been moved to CAP. What's the status?] This document also describes issues and problems which are not solved by these protocols, and could be targets for future work.

S. Silverberg, S. Mansour, F. Dawson Jr. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries," Internet Engineering Task Force, Sep. 1998.

Abstract: This document specifies how calendaring systems use iCalendar objects to interoperate with other calendar systems. It does so in a general way so as to allow multiple methods of communication between systems. Subsequent documents specify interoperable methods of communications between systems that use this protocol. The document outlines a model for calendar exchange that defines both static and dynamic event, to-do, journal and free/busy objects. Static objects are used to transmit information from one entity to another without the expectation of continuity or referential integrity with the original item. Dynamic objects are a superset of static objects and will gracefully degrade to their static counterparts for clients that only support static objects. This document specifies an Internet protocol based on the iCalendar object specification that provides scheduling interoperability between different calendar systems. The Internet protocol is called the 'iCalendar Transport-Independent Interoperability Protocol (iTIP)'. iTIP complements the iCalendar object specification by adding semantics for group scheduling methods commonly available in current calendar systems. These scheduling methods permit two or more calendar systems to perform transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. iTIP is defined independent of the particular transport used to transmit the scheduling information. Companion memos to iTIP provide bindings of the interoperability protocol to a number of Internet protocols.

J. Noerenberg, "Internet Calendar Model Specification," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

J. Wray, "Generic Security Service API Version 2 : C-bindings," Internet Engineering Task Force, Nov. 1998.

Abstract: This draft document specifies C language bindings for Version 2 of the Generic Security Service Application Program Interface (GSS-API), 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, GSS-API callers will be application protocols into which security enhancements are integrated through invocation of services provided by the GSS-API. The GSS-API 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.

J. Cargille, M. Hur and A. Medvinsky, "Anonymous Credentials in Kerberos," Internet Engineering Task Force, Sep. 1997.

Abstract: This document defines the concept of anonymous Kerberos credentials, and describes how such credentials can be securely obtained from a Kerberos KDC via the PKINIT extension. This draft defines no new mechanisms or protocols; instead, it defines the concepts and proposes usage and naming conventions.

T. Yu, "The Kerberos Version 5 GSSAPI Mechanism, Version 2," Internet Engineering Task Force, Mar. 2000.

Abstract: This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (as specified in RFC 2743) when using Kerberos Version 5 technology (as specified in RFC 1510). This obsoletes RFC 1964.

J. Linn, "Generic Security Service Application Program Interface Version 2, Update 1," Internet Engineering Task Force, Dec. 1998.

Abstract: The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications: documents defining specific parameter bindings for particular language environments documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms This Internet-Draft revises [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this draft or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.

J. Myers, "SASL GSSAPI mechanisms," Internet Engineering Task Force, Sep. 2000.

Abstract: The Simple Authentication and Security Layer [SASL] is a method for adding authentication support to connection-based protocols. This document describes the method for using the Generic Security Service Application Program Interface [GSSAPI] in the Simple Authentication and Security Layer [SASL]. This document amends section 7.2 of RFC 2222 [SASL], the definition of the 'GSSAPI' SASL mechanism.

G. Klyne, "An algebra for describing media feature sets," Internet Engineering Task Force, Aug. 1998.

Abstract: A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2]. Part of this framework is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for registering media features are presented in [3]. This document describes an algebra and syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. This document also outlines an algorithm for feature set matching.

G. Klyne, "A syntax for describing media feature sets," Internet Engineering Task Force, Dec. 1998.

Abstract: A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact [1]. A framework for such negotiation is described in [2], part of which is a way to describe the range of media features which can be handled by the sender, recipient or document transmission format of a message. A format for a vocabulary of individual media features and procedures for feature registration are presented in [3]. This document introduces and describes a syntax that can be used to define feature sets which are formed from combinations and relations involving individual media features. Such feature sets are used to describe the media feature handling capabilities of message senders, recipients and file formats. An algorithm for feature set matching is also described here.

G. Klyne, "Protocol-independent content negotiation framework," Internet Engineering Task Force, Mar. 1999.

Abstract: A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. MIME media types [1,2] provide a standard method for handling one major axis of variation, but resources also vary in ways which cannot be expressed using currently available MIME headers. This draft sets out terminology, an abstract framework and goals for protocol-independent content negotiation, and identifies some technical issues which may need to be addressed. The abstract framework does not attempt to specify the content negotiation process, but gives an indication of the anticipated scope and form of any such specification. The goals set out the desired properties of a content negotiation mechanism.

W. Lazear, "The Autonomous System Option for DHCP," Internet Engineering Task Force, Feb. 1998.

Abstract: This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the autonomous system in which the host resides and may be required by routing protocols.

A. McAuley, S. Das, S. Baba and Y. Shobatake, "Requirements for Extending DHCP into New Environments," Internet Engineering Task Force, Mar. 2000.

Abstract: The Dynamic Host Configuration Protocol (DHCP) provides a widely deployed framework for host registration and configuration [DHC]. DHCP, however, was designed only for fixed hosts on physically secure LANs. Other protocols fill some of the gap. PPP [PPP] is a good solution for many commercial service providers (where framing is needed). Mobile IP [MIP] is ideal for registering and configuring roaming users (when transparent address binding is needed). This still leaves many environments where there is no ideal solution, such as: roaming users who do not need transparent address binding e.g., a mobile web browser), and commercial service providers who want to support home networking with multiple nodes. This draft proposes DHCP as the best protocol to meet these new needs, because it leave open how (and whether) to provide other functions, such as framing (e.g., PPP), locating (e.g., Mobile IP in co-located mode), inter-domain AAA (e.g., [AAAR]), or address distribution (e.g., [DAAP]). We describe and solicit feedback on seven new requirements that would be placed on DHCP to meet these needs.

W. Lazear, "The Server Range Option for DHCP," Internet Engineering Task Force, Feb. 1998.

Abstract: This document describes a configuration option that may be used by hosts acting as IP forwarders. The option contains information about the networks adjacent to the host and may be required by routing protocols.

B. Patel, "Securing DHCP," Internet Engineering Task Force, Jul. 1997.

Abstract: 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.

R. Hibbs and G. Waters, "Dynamic Host Configuration Protocol (DHCP) Server MIB," Internet Engineering Task Force, Nov. 2000.

Abstract: 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 Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers.

R. Kavasseri and B. Stewart, "Event MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 that can be used to manage and monitor MIB objects and take action through events. The Event MIB provides the ability to monitor MIB objects on the local system or on a remote system and take simple action when a trigger condition is met.

R. Kavasseri and B. Stewart, "Distributed Management Expression MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 expressions of MIB objects. The results of these expressions become MIB objects usable like any other MIB object, such as for the test condition for declaring an event.

R. Kavasseri and B. Stewart, "Notification Log MIB," Internet Engineering Task Force, Oct. 2000.

Abstract: 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 logging SNMP Notifications.

D. Levi and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 set of managed objects that are used to schedule management operations periodically or at specified dates and times.

D. Levi and J. Schoenwaelder, "Definitions of Managed Objects for Scheduling Management Operations," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 set of managed objects that are used to schedule management operations periodically or at specified dates and times.

D. Levi and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts," Internet Engineering Task Force, Feb. 1999.

Abstract: 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 set of managed objects that allow the delegation of management scripts to distributed managers.

D. Levi and J. Schoenwaelder, "Definitions of Managed Objects for the Delegation of Management Scripts," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 set of managed objects that allow the delegation of management scripts to distributed managers.

R. Austein and H. Alvestrand, "A Proposed Enhancement to the EDNS0 Version Mechanism," Internet Engineering Task Force, Jul. 2000.

Abstract: EDNS0 [EDNS0] specifies a general framework for extending the packet format used by the Domain Name System protocols. The framework includes a simple version numbering scheme to allow the parties in a DNS protocol exchange to determine which extension features the other party understands. While having the advantage of simplicity, the version numbering scheme as specified has drawbacks: - It provides no way to deprecate a protocol feature; - It provides no way to deploy experimental protocol features. This note proposes to replace the monolithic version numbering mechanism with a mechanism for listing an explicit set of protocol features that a particular implementation supports. We retain version numbering as a way of abbreviating the feature sets that we expect to see in common use.

M. Ohta, "Incremental Zone Transfer in DNS," Internet Engineering Task Force, Jun. 2000.

Abstract: This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism.

D. Eastlake, "Domain Name System Security Extensions," Internet Engineering Task Force, Dec. 1998.

Abstract: Extensions to the Domain Name System (DNS) are described that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. These digital signatures are included in secured zones as resource records. Security can also be provided through non-security aware DNS servers in some cases. The extensions provide for the storage of authenticated public keys in the DNS. This storage of keys can support general public key distribution services as well as DNS security. The stored keys enable security aware resolvers to learn the authenticating key of zones in addition to those for which they are initially configured. Keys associated with DNS names can be retrieved to support other protocols. Provision is made for a variety of key types and algorithms. In addition, the security extensions provide for the optional authentication of DNS protocol transactions and requests. This document incorporates feedback on RFC 2065 from early implementers and potential users.

G. Schadow, M. Tucker and W. Rishel, "Secure HL7 Transactions using Internet Mail," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo describes the applicability of the Internet standardization efforts on secure electronic data interchange (EDI) transactions for Health Level-7 (HL7), an EDI standard for healthcare used worldwide. This memo heavily relies on the work in progress by the IETF EDIINT working group. It is in most parts a restatement of the EDIINTs requirements document and application statement 1 (AS#1) tailored to the needs of the HL7 audience. We tried to make this document as self consistent as possible. The goal is to give to the reader who is not a security or Internet standards expert enough foundational and detail information to enable him to build communication software that complies to the Internet standards. Even though we rely on and promote the respective Internet standards and drafts, we did not withstand from commenting on and criticising this work where we see upcoming problems in use with HL7 or other EDI protocols that have not been in the initial focus of the EDIINT working group. We make suggestions to add parameters to the specification of the MIME type for EDI messages [RFC 1767] in order to enhance functionality. We give use cases for a larger subset of disposition types and modifiers of message disposition notifications. One key issue where this memo goes beyond the current EDIINT drafts is the concept of non-repudiation of commitment to an EDI transaction. Secure EDI transactions should be regarded as ``distributed contracts,'' i.e. not only the sending and receiving of single messages should be non-refutable but also the connection between messages interchanges. In anticipation of this requirement HL7 usually requires a response message to be sent to acknowledge every transaction. We therefore have the requirement to securely couple an EDI response message to its request message. Given the current shape of RFC 1767 this is generally possible only if a response message is coupled with an MDN receipt and the combi

K. McCloghrie and A. Bierman, "Entity MIB Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: 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 multiple logical and physical entities managed by a single SNMP agent.

K. McCloghrie and A. Bierman, "Entity MIB using SMIv2 (Version 2)," Internet Engineering Task Force, Jun. 1999.

Abstract: 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 multiple logical and physical entities managed by a single SNMP agent.

A. Gallant, "The Number Portability Supplement to ITU-T Recommendation E.164," Internet Engineering Task Force, Jul. 2000.

Abstract: This document contains a text version of the Number Portability Supplement (11/98) to ITU-T Recommendation E.164 (The international public telecommunication numbering plan, 05/97) [2]. That Supplement [3] defined terminology for number portability within an E.164 numbering scheme; identified formats, call flows, architectures, and routing approaches for some methods; and gave examples of some processes needed to implement number portability. A January 2000 workshop on IP-Telecomms interworking (focused on numbering, naming, addressing, and routing) identified issues to be addressed by the IETF and/or the ITU [4]. This Supplement was noted as a document related to a joint IETF/ITU issue on E.164 number portability. A text version was posted on the ITU's web site in March 2000 and notified to the itu+ietf and enum mailing lists. This Internet Draft is being submitted to support work of the ENUM (Telephone Number Mapping) Working Group on impacts of local number portability on a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g., URLs) [5].

A. Brown, "ENUM Requirements," Internet Engineering Task Force, Jun. 2000.

Abstract: This paper defines the requirements for a DNS-based architecture and protocols for mapping a telephone number to a set of attributes (e.g., URLs) which can be used to contact a resource associated with that number. There are many possible protocols that can be considered for a telephone number mapping service. The purpose of this document is to focus discussion on a DNS-based solution. The intention is to enumerate the expectations of such a solution and to clarify the scope.

L. Masinter, "Terminology and Goals for Internet Fax," Internet Engineering Task Force, Sep. 1998.

Abstract: This document defines a number of terms useful for the discussion of Internet Fax. In addition, it describes the goals of the Internet Fax working group and establishes a baseline of desired functionality against which protocols for Internet Fax can be judged. It encompasses the goals for all modes of facsimile delivery, including 'real-time', 'session', and 'store and forward'. Different levels of desirability are indicated throughout the document.

D. Crocker, "PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL," Internet Engineering Task Force, Oct. 1997.

Abstract: F.IFax, defines the service requirement for both real-time and store and forward facsimile over the Internet. For store and forward facsimile this Recommendation defines addressing, MIME encapsulation of document components and data formats for those components. Store and forward facsimile uses Internet mail standard protocols for posting, relaying and delivery of store and forward facsimile document. It requires no changes to Internet standards or to ITU Facsimile Recommendations. Such an approach leads to a system that can be used universally without changes to Internet servers or other intermediate systems between the sender and the recipient and which permits interworking between facsimile store and forward users and users of general Internet mail.

K. Toyoda, H. Ohno, J. Murai and D. Wing, "A Simple Mode of Facsimile Using Internet Mail," Internet Engineering Task Force, Jul. 2000.

Abstract: This specification provides for 'simple mode' carriage of facsimile data over the Internet. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Facsimile [5,6,19]. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in . 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 [7].

D. Wing, "Expressing Fax Capabilities in Internet Protocols," Internet Engineering Task Force, Aug. 1998.

Abstract: This document describes how the DIS Standard Capabilities and Non-Standard Capabilities (NSF) of [T.30] can be expressed using the format described by the IETF Content Negotiation Working Group [MEDIA-FEATURES, FEATURE-ALGEBRA, FEATURE-REG]. The format described in this document, and the format described in [FEATURE-ALGEBRA] is intended to be usable in many Internet protocols and by a variety of methods. The specific methods are not described by this document.

J. Allen, P. Leach and R. Hedberg, "CIP Transport Protocols," Internet Engineering Task Force, Mar. 1999.

Abstract: 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].

R. Steinberger and O. Nicklass, "Definitions of Managed Objects for Frame Relay Service Level Definitions," Internet Engineering Task Force, Sep. 2000.

Abstract: This memo defines an extension 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 Frame Relay Service Level Definitions. This memo does not specify a standard for the Internet community.

K. Rehbehn and D. Fowler, "Definitions of Managed Objects for Frame Relay Service," Internet Engineering Task Force, Jun. 2000.

Abstract: 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.

R. Steinberger and O. Nicklass, "Definitions of Managed Objects for Circuit to Interface Translation," Internet Engineering Task Force, Aug. 2000.

Abstract: This memo defines an extension 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 insertion of interesting Circuit Interfaces into the ifTable. This memo does not specify a standard for the Internet community.

B. Coutts, "Frame Relay Switched PVC MIB," Internet Engineering Task Force, Nov. 1998.

Abstract: 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). This memo does not specify a standard for the Internet community.

M. Allman, S. Ostermann and C. Metz, "FTP Extensions for IPv6," Internet Engineering Task Force, Sep. 1998.

Abstract: The specification for the File Transfer Protocol assumes that the underlying network protocol uses a 32-bit network address (specifically IP version 4). 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 IPv4 and IPv6. In addition, the framework defined can support additional network protocols in the future.

H. Sjostrand, J. Buerkle and B. Srinivasan, "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)," Internet Engineering Task Force, Nov. 2000.

Abstract: 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 for the General Switch Management Protocol (GSMP).

T. Hardie, K. Holtman and A. Mutz, "The Alternates Header Field," Internet Engineering Task Force, Nov. 1997.

Abstract: This document proposes a header, Alternates, which is intended to provide a common method for Internet-based application protocols to indicate that a particular resource exists in multiple forms. The Alternates header provides a machine-readable indication of the bases on which the different forms vary and how the the recipient of the header can select among them.

J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication," Internet Engineering Task Force, Sep. 1998.

Abstract: '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 (unless used in conjunction with some external secure system such as SSL [5]), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as 'Digest Access Authentication'. It is therefore also intended to serve as a replacement for RFC 2069 [6]. Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added -for compatibility, those new elements have been made optional, but are strongly recommended. 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.

J. Franks, A. Luotonen, P. Leach and J. Hostetler, "An Extension to HTTP : Digest Access Authentication," Internet Engineering Task Force, Jul. 1997.

Abstract: 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.

E. Hardie, "Scenarios for the Delivery of Negotiated Content," Internet Engineering Task Force, Nov. 1997.

Abstract: A number of Internet application protocols have a need to provide content negotiation for the resources with which they interact. While MIME media types [1] provide a standard method for handling one major axis of variation, resources also vary in ways which cannot be expressed using currently available MIME headers. This paper asserts that a cross-protocol negotiation framework is needed, both to leverage work already done for specific protocols and to allow for content negotiation when resources will pass through several protocols on their way from provider to recipient. To justify the need, this paper puts forward several content negotiation scenarios and discusses how they affect the requirements for such a framework.

J. Flick, "Definitions of Object Identifiers for Identifying Ethernet Chip Sets," Internet Engineering Task Force, May 1999.

Abstract: This memo defines OBJECT IDENTIFIER values for use with network management protocols in the Internet community. In particular, it contains registered OID values for use with the dot3StatsEtherChipSet object in the EtherLike-MIB [16]. These registrations have been split from [16] into a separate document for maintenance purposes. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com.}

J. Johnson and J. Flick, "Definitions of Managed Objects for the Ethernet-like Interface Types," Internet Engineering Task Force, Jun. 1998.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1650 ''Definitions of Managed Objects for the Ethernet-like Interface Types using SMIv2.'' This memo extends that specification by including management information useful for the management of 100 Mb/s Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflect a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com.}

J. Johnson and J. Flick, "Definitions of Managed Objects for the Ethernet-like Interface Types," Internet Engineering Task Force, May 1999.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 2358 ''Definitions of Managed Objects for the Ethernet-like Interface Types''. This memo extends that specification by including management information useful for the management of 1000 Mb/s and full-duplex Ethernet interfaces. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com.}

K. McCloghrie, D. McMaster, D. Romascanu, S. Roberts and K. De Graaf, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

K. McCloghrie, D. McMaster, D. Romascanu, S. Roberts, A. Smith, J. Flick and K. De Graaf, "Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2," Internet Engineering Task Force, May 1999.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 2239, ''Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2''. This memo extends that specification by including management information useful for the management of 1000 Mb/s MAUs. Ethernet technology, as defined by the 802.3 Working Group of the IEEE, continues to evolve, with scalable increases in speed, new types of cabling and interfaces, and new features. This evolution may require changes in the managed objects in order to reflect this new functionality. This document, as with other documents issued by this working group, reflects a certain stage in the evolution of Ethernet technology. In the future, this document might be revised, or new documents might be issued by the Ethernet Interfaces and Hub MIB Working Group, in order to reflect the evolution of Ethernet technology. Distribution of this memo is unlimited. Please forward comments to hubmib@hprnd.rose.hp.com.}

S. Bellovin, "Security Mechanisms for the Internet," Internet Engineering Task Force, Jun. 1999.

Abstract: Many different mechanisms can be used to provide security for protocols. The precise one that is appropriate in any given situation can vary. We review a number of different choices, explaining the properties of each.

D. Thaler and B. Cain, "BGP Attributes for Multicast Tree Construction," Internet Engineering Task Force, Mar. 1999.

Abstract: The Multiprotocol Extensions for BGP-4 [MBGP] allow Network Layer Reachability Information to contain prefixes used for multicast forwarding. This document defines extensions to BGP-4 [BGP-4] which can be used to annotate such prefixes with information that can be used by multicast routing protocols when constructing trees.

N. Yamanouchi, O. Takahashi and N. Ishikawa, "IGMP Extension for Authentication of IP Multicast Senders and Receivers," Internet Engineering Task Force, Aug. 1998.

Abstract: The security enhancement is one of the most important enhancements to IP multicast. IP multicast requires many security functions that include user authentication of IP multicast, encryption of IP multicast datagrams and key management protocols for IP multicast. Among them, the user authentication function for IP multicast is considered one of the most important security functions for IP multicast. This document describes the extension to IGMP, version 2 (IGMPv2) [1] for the authentication of IP multicast senders and receivers, which prevents an unauthorized user from sending and receiving IP multicast datagrams.

K. McCloghrie, D. Farinacci and D. Thaler, "Internet Group Management Protocol MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 the Internet Group Management Protocol (IGMP).

B. Cain, S. Deering, I. Kouvelas and A. Thyagarajan, "Internet Group Management Protocol, Version 3," Internet Engineering Task Force, Jun. 2000.

Abstract: This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. 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 authors.}

K. McCloghrie, D. Farinacci and D. Thaler, "IPv4 Multicast Routing MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 for IPv4, independent of the specific multicast routing protocol in use.

K. McCloghrie, D. Farinacci, D. Thaler and B. Fenner, "Protocol Independent Multicast MIB for IPv4," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 the Protocol Independent Multicast (PIM) protocol.

Z. Wenzel and J. Seng, "Requirements of Internationalized Domain Names," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names.

J. Seng, "Requirements of Internationalized Domain Names," Internet Engineering Task Force, Feb. 2000.

Abstract: This document describes the requirement for encoding international characters into DNS names and records. This document is guidance for developing protocols for internationalized domain names.

D. Oscarsson, "Simple ASCII Compatible Encoding (SACE)," Internet Engineering Task Force, Aug. 2000.

Abstract: This document describes a way to encode non-ASCII characters in host names in a way that is completely compatible with the current ASCII only host names that are used in DNS. It can be used both with DNS to support software only handling ASCII host names and as a way to downgrade from 8-bit text to ASCII in protocols.

M. Blanchet, "Handling versions of internationalized domain names protocols," Internet Engineering Task Force, Oct. 2000.

Abstract: This document describes some issues related to handling changes in the codepoints and other features in the chars space of an internationalized domain name as well as changes in the protocol that supports it (whatever that be). It also presents some solutions to these issues.

D. Katz, Y. Rekhter, T. Bates and R. Chandra, "Multiprotocol Extensions for BGP-4," Internet Engineering Task Force, Jan. 1998.

Abstract: 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.

T. Bates, R. Chandra, D. Katz and Y. Rekhter, "Multiprotocol Extensions for BGP-4," Internet Engineering Task Force, Mar. 2000.

Abstract: 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.

R. Wright and M. Hamilton, "Use of DNS Aliases for Network Services," Internet Engineering Task Force, Aug. 1997.

Abstract: 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 programmatically 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.

K. McCloghrie and F. Kastenholz, "The Interfaces Group MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II [17], especially the experience gained from the definition of numerous media-specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub- layers beneath the internetwork-layer. It specifies clarifications to, and extensions of, the architectural issues within the MIB-II model of the 'interfaces' group. This memo obsoletes RFCs 1573 and 2233, the previous versions of the Interfaces Group MIB.

K. McCloghrie and G. Hanson, "The Inverted Stack Table Extension to the Interfaces Group MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: 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 which provide an inverted mapping of the interface stack table used for managing network interfaces.

F. Kastenholz and K. McCloghrie, "The Interfaces Group MIB," Internet Engineering Task Force, Oct. 1997.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Network Interfaces. This memo discusses the 'interfaces' group of MIB-II, especially the experience gained from the definition of numerous media- specific MIB modules for use in conjunction with the 'interfaces' group for managing various sub-layers beneath the internetwork- layer. It specifies clarifications to, and extensions of, the architectural issues within the previous model used for the 'interfaces' group.

M. Greene, K. McCloghrie and K. Tesink, "Definitions of Managed Objects for System and Interface Testing," Internet Engineering Task Force, Dec. 1999.

Abstract: This memo defines an 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 defines the following: o A general mechanism to initiate tests o A capability to provide and store test results o A capability to inventory the tests that are supported by an agent This memo does not specify individual tests. Such tests are subject of separate system- or media-specific specifications. This memo replaces the objects defined in the ifTestGroup of RFC2233[RFC2233] which have been deprecated.

D. Thaler, "IP Tunnel MIB," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo defines a 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 over IPv4 networks. Extension MIBs may be designed for managing protocol- specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non- IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs.

M. Day and J. Rosenberg, "A Model for Presence and Instant Messaging," Internet Engineering Task Force, Jun. 1999.

Abstract: This document defines an abstract model for a presence and instant messaging system. It defines the various entities involved, defines terminology, and outlines the services provided by the system. The goal is to provide a common vocabulary for further work on requirements for protocols and markup for presence and instant messaging.

H. Sugano, C. Vermeulen and R. Osborne, "Presence Information Data Format for IMPP," Internet Engineering Task Force, Mar. 2000.

Abstract: This document is the output from the PIDF team working on the definition of the Presence Information Data Format for conveying PRESENCE INFORMATION between PRESENTITIES, PRESENCE SERVICE and WATCHERS on top of the PRESENCE INFORMATION TRANSPORT PROTOCOL of the IMPP set of protocols. It describes the current status of discussion on the IMPP mailing list in relation to the scope of PIDF as well as its concrete format. The discussion is on-going at present and future versions of this Internet-Draft will further specify the concrete format of PIDF in conformance with the IMPP Requirements RFC.

M. Day, S. Aggarwal, G. Mohr and J. Vincent, "Instant Messaging / Presence Protocol Requirements," Internet Engineering Task Force, Dec. 1999.

Abstract: Presence and Instant Messaging have recently emerged as a new medium of communications over the Internet. Presence is a means for finding, retrieving, and subscribing to changes in the presence information (e.g. 'online' or 'offline') of other users. Instant messaging is a means for sending small, simple messages that are delivered immediately to online users. Applications of presence and instant messaging currently use independent, non-standard and non-interoperable protocols developed by various vendors. The goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to define a standard protocol so that independently developed applications of instant messaging and/or presence can interoperate across the Internet. This document defines a minimal set of requirements that IMPP must meet.

G. Klyne, "Security Framework for Instant Messaging and Presence Protocol," Internet Engineering Task Force, Mar. 2000.

Abstract: This memo describes the security framework for the Instant Messaging and Presence Protocols. It identifies the entities that use IMPP protocol elements, the trust relationships between them, security threats that are against which defence is to be provided, and the consequent security responsibilities of the active entities. Specific cryptographic and other security mechanisms are NOT defined here. NOTE: The security framework for IMPP is inherently bound up with the IMPP protocol design, and this memo is expected to evolve as decisions are made about the protocol design. In its current form, this memo makes some assumptions about the IMPP structure that must be reviewed as design proceeds.

F. Baker, "Integrated Services Management Information Base Guaranteed Service Extensions," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.}

F. Baker and J. Krawczyk, "Integrated Services Management Information Base," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.}

F. Baker and J. Krawczyk, "Integrated Services Management Information Base," Internet Engineering Task Force, Oct. 1997.

Abstract: 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.}

M. Greene and C. Chung, "Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks," Internet Engineering Task Force, Apr. 1998.

Abstract: 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 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.

D. Grossman and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo describes two encapsulations methods for carrying network interconnect traffic over AAL type 5 over ATM. The first method allows multiplexing of multiple protocols over a single ATM virtual connection whereas the second method assumes that each protocol is carried over a separate ATM virtual connection.

M. Greene, J. Cucchiara and J. Luciani, "Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)," Internet Engineering Task Force, Jun. 1999.

Abstract: 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 for the Next Hop Resolution Protocol (NHRP) as defined in RFC 2332.

A. Przygienda and P. Droz, "Proxy PAR," Internet Engineering Task Force, Feb. 2000.

Abstract: Proxy-PAR is a minimal version of PAR (PNNI Augmented Routing) that gives ATM-attached devices the ability to interact with PNNI devices without the necessity to fully support PAR. Proxy-PAR is designed as a client/server interaction, of which the client side is much simpler than the server side to allow fast implementation and deployment. The purpose of Proxy-PAR is to allow non-ATM devices to use the flooding mechanisms provided by PNNI for registration and automatic discovery of services offered by ATM attached devices. The first version of PAR pri- marily addresses protocols available in IPv4. But it also contains a generic interface to access the flooding of PNNI. In addition, Proxy- PAR-capable servers provide filtering based on VPN IDs [1], IP protocols and address prefixes. This enables, for instance, routers in a certain VPN running OSPF to find OSPF neighbors on the same subnet. The protocol is built using a registration/query approach where devices can register their services and query for services and protocols registered by other clients.

S. Green, "Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus," Internet Engineering Task Force, Jun. 2000.

Abstract: 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 a set of managed objects for SNMP-based management of the Baseline Privacy Plus features [17] of DOCSIS1.1-compliant[16] Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. 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 authors.}

M. St. Johns, "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems," Internet Engineering Task Force, Apr. 1999.

Abstract: 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 a basic set of managed objects for SNMP-based management of DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards. 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.}

M. StJohns, "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems," Internet Engineering Task Force, Jul. 2000.

Abstract: This memo is a draft revision of the standards track RFC-2669. Please see 'Revision Descriptions' below for a description of changes. This document or its successor will obsolete RFC-2669 when accepted. 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 a basic set of managed objects for SNMP-based management of DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards.

A. Valentine, "DVB Cable Network Interface Unit MIB for EuroModem compliant Cable Modems," Internet Engineering Task Force, Nov. 2000.

Abstract: 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 a basic set of managed objects for SNMP- based management of EuroModem v1.0 compliant Cable Network Interface Units. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[RFC2578][RFC2579][RFC2580]. The set of objects is consistent with the SNMP framework and existing SNMP standards.

R. Woundy, "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems," Internet Engineering Task Force, Nov. 2000.

Abstract: 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 a basic set of managed objects for SNMP- based management of the Baseline Privacy Interface, which provides data privacy for DOCSIS 1.0 compliant Cable Modems and Cable Modem Termination Systems. This MIB is defined as an extension to the DOCSIS Radio Frequency Interface MIB, RFC 2670.

M. St. Johns, "Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces," Internet Engineering Task Force, Feb. 1999.

Abstract: 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 a basic set of managed objects for SNMP-based management of MCNS/DOCSIS compliant Radio Frequency (RF) interfaces. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group within the Internet Engineering Task Force.

W. Sawyer and M. StJohns, "Management Information Base for DOCSIS Cable Modem Termination Systems for Subscriber Management," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 set of managed objects for SNMP-based management of DOCSIS-compliant[16] Cable Modem Termination Systems. These managed objects facilitate protection of the cable network from misuse by subscribers. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects are consistent with the SNMP framework and existing SNMP standards. 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 authors.}

S. Adiraju and J. Fijolek, "Telephony-Return Interface (TRI) Management Information Base for DOCSIS-compliant Telephony-Return Cable Modems and Cable Modem Termination Systems," Internet Engineering Task Force, Apr. 1999.

Abstract: 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 DOCSIS compliant Cable Modems and Cable Modem Termination Systems. This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2[5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo is a product of the IPCDN working group.

K. Teow, "Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard," Internet Engineering Task Force, Jan. 2000.

Abstract: 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 the objects for managing the operations of the Fabric Element portion of the Fibre Channel Standards.

M. Rajagopal, R. Bhagwat and W. Rickard, "IP and ARP over Fibre Channel," Internet Engineering Task Force, Apr. 1999.

Abstract: Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and Internet Protocol(IP). Until now, SCSI has been the only widely used protocol over FC. Existing FC standards [3] do not adequately specify how IP packets may be transported over FC and how IP addresses are resolved to FC addresses. The purpose of this document is to specify a way of encapsulating IP and Address Resolution Protocol(ARP) over Fibre Channel and also to describe a mechanism(s) for IP address resolution.

K. Banker, "Fibre Channel Interconnect MIB," Internet Engineering Task Force, Aug. 1998.

Abstract: 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 the operations of any Fibre Channel Interconnection device, or set of devices. An example of a Fibre Channel Interconnection would be a FC-AL repeater (or hub) or a FC Fabric Switch.

R. Draves, "Default Address Selection for IPv6," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa.

D. Haskin and S. Onishi, "Management Information Base for IP Version 6: ICMPv6 Group," Internet Engineering Task Force, Jan. 1998.

Abstract: 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.

D. Haskin and S. Onishi, "Management Information Base for IP Version 6: Textual Conventions and General Group," Internet Engineering Task Force, Feb. 1998.

Abstract: This document is one in the series of documents that provide MIB definitions for 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.

D. Haskin and E. Allen, "IP Version 6 over PPP," Internet Engineering Task Force, Feb. 1998.

Abstract: 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.

M. Daniele, "IP Version 6 Management Information Base for the Transmission Control Protocol," Internet Engineering Task Force, Jul. 1998.

Abstract: 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, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie 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 IPv6-based internets.

M. Daniele, "IP Version 6 Management Information Base for the User Datagram Protocol," Internet Engineering Task Force, Jul. 1998.

Abstract: 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, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie 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 IPv6-based internets.

B. Haberman and R. Worzella, "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol," Internet Engineering Task Force, Oct. 2000.

Abstract: This document defines a portion of the Management Information Base (MIB) for use with network management protocols in Internet Protocol Version 6 internets. Specifically, this document is the MIB module that defines managed objects for implementations of the Multicast Listener Discovery Protocol [RFC2710].

D. Johnson and S. Deering, "Reserved IPv6 Subnet Anycast Addresses," Internet Engineering Task Force, Jan. 1999.

Abstract: The IP Version 6 addressing architecture defines an 'anycast' address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the 'nearest' interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses.

R. Stevens, M. Thomas and E. Nordmark, "Advanced Sockets API for IPv6," Internet Engineering Task Force, Nov. 2000.

Abstract: A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those 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-2553]: The Routing header (source routing), Hop-by-Hop options, and Destination options. This document provides API access to these features too.

R. Herriot, T. Hastings, N. Jacobs and J. Martin, "Mapping between LPD and IPP Protocols," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 technologies. This document gives some advice to implementers of gateways between IPP and LPD (Line Printer Daemon). This document describes the mapping between (1) the commands and operands of the 'Line Printer Daemon (LPD) Protocol' specified in RFC 1179 and (2) the operations, operation attributes and job template attributes of the Internet Printing Protocol/1.0 (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 the IETF 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.

J. Satran and others, "iSCSI," Internet Engineering Task Force, Nov. 2000.

Abstract: The Small Computer Systems Interface (SCSI) is a popular family of protocols for communicating with I/O devices, especially storage devices. This memo describes a transport protocol for SCSI that operates on top of TCP. The iSCSI protocol aims to be fully compliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document

S. Kent and R. Atkinson, "Security Architecture for the Internet Protocol," Internet Engineering Task Force, Aug. 1998.

Abstract: This memo specifies the base architecture for IPsec compliant systems. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. This document describes the goals of such systems, their components and how they fit together with each other and into the IP environment. It also describes the security services offered by the IPsec protocols, and how these services can be employed in the IP environment. This document does not address all aspects of IPsec architecture. Subsequent documents will address additional architectural details of a more advanced nature, e.g., use of IPsec in NAT environments and more complete support for IP multicast. The following fundamental components of the IPsec security architecture are discussed in terms of their underlying, required functionality.

S. Floyd, D. Black and K. Ramakrishnan, "IPsec Interactions with ECN," Internet Engineering Task Force, Dec. 1999.

Abstract: IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that provides notification of onset of congestion to delay- or loss- sensitive applications. ECN provides congestion notifications to enable adaptation to network conditions without the impact of dropped packets [RFC 2481]. The use of two bits in the IPsec header for ECN experimentation conflicts with header processing at IPsec tunnel endpoints in a manner that makes ECN unusable in the presence of IPsec tunnels. This document considers issues related to this conflict, describes two alternative solutions, and updates the IPsec architecture [RFC 2401] to include these alternatives. Support for one or the other of these alternatives is REQUIRED to remove the underlying conflict.

T. Kivinen, "ISAKMP & IKE Extensions Methods," Internet Engineering Task Force, Nov. 1999.

Abstract: This document describes multiple extension methods of the ISAKMP [RFC 2408] and IKE [RFC 2409] protocols and how the older versions should respond when they receive such extensions. This document mainly tries to describe the best practice of extensions handling in ISAKMP [RFC 2408] and IKE [RFC 2409], so that a future version can be made without break- ing the old existing versions.

M. Blaze, A. Keromytis, M. Richardson and L. Sanchez, "IPsec Policy Architecture," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes an IP Security Policy architecture that conforms to the requirements set forth in [IPSP-REQ]. The architecture defines the mechanisms and protocols needed for discovering, accessing, and processing security policy information of varying granularity. The architecture accommodates topology and policy changes without need of manual reconfiguration of clients and security gateways.

D. Hampton, D. Oran, H. Salama and D. Shah, "The IP Telephony Border Gateway Protocol(TBGP)," Internet Engineering Task Force, Jun. 1999.

Abstract: This document presents the architecture of the IP Telephony Border Gateway Protocol (TBGP). TBGP is an inter-domain protocol, for routing voice calls through the IP network towards their destinations, which may be inside the IP network, IP destinations, or outside it, PSTN destinations. TBGP's operation is independent of any VoIP call signaling protocols (H.323, SIP, MGCP, ...), but it can serve as the call routing protocol for any of these signaling protocols. TBGP is based on the Border Gateway Protocol 4 (BGP-4).

J. Rosenberg, H. Salama and M. Squire, "Telephony Routing over IP (TRIP)," Internet Engineering Task Force, Jul. 2000.

Abstract: This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIPĘs operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. The Border Gateway Protocol (BGP-4) is used to distribute routing information between administrative domains. TRIP is used to distribute telephony routing information between telephony administrative domains. The similarity between the two protocols is obvious, and hence TRIP is modeled after BGP-4.

D. Katz and R. Saluja, "Three-Way Handshake for IS-IS Point-to-Point Adjacencies," Internet Engineering Task Force, Jul. 2000.

Abstract: The IS-IS routing protocol (ISO 10589) requires reliable protocols at the link layer for point-to-point links. As a result, it does not use a three-way handshake when establishing adjacencies on point-to-point media. This paper defines an backward-compatible extension to the protocol that provides for a three-way handshake. It is fully interoperable with systems that do not support the extension. Additionally, the extension allows the robust operation of more than 256 point-to-point links on a single router. This extension has been implemented by multiple router vendors; this paper is provided as information to the Internet community in order to allow interoperable implementations to be built by other vendors.

J. Parker, "Management Information Base for IS-IS," Internet Engineering Task Force, Jun. 2000.

Abstract: This document describes a management information base for the IS-IS Routing protocol, as described in ISO 10589 [2], when it is used to construct routing tables for IP networks, as described in RFC 1195 [3]. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo is based on an IETF draft by Chris Gunner [1]. This version has been modified to include MIB-II syntax, to exclude portions of the protocol that are not relevant to IP, such as the ES-IS protocol, and to add management support for current practice.

M. Borden and M. Garrett, "Interoperation of Controlled-Load and Guaranteed-Service with ATM," Internet Engineering Task Force, Jun. 1998.

Abstract: This document provides guidelines for mapping service classes, and traffic management features and parameters between Internet and ATM technologies. The service mappings are useful for providing effective interoperation and end-to-end Quality of Service for IP Integrated Services networks containing ATM subnetworks. The discussion and specifications given here support the IP integrated services protocols for Guaranteed Service (GS), Controlled-Load Service (CLS) and the ATM Forum UNI specification, versions 3.0, 3.1 and 4.0. Some discussion of IP best effort service over ATM is also included.

A. Smith and R. Pabbati, "Definitions of Managed Parameters for SBM network nodes," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo includes a list of manageable parameters for RSVP/SBM server implementations. These are in addition to those already described in RFC 2206 and RFC 2213. Specifically, it describes parameters for control of the base signaling protocols themselves, as well as some of the admission control decisions. These definitions are not intended to be exhaustive but they have been identified as useful for practical implementations.

C. Bormann, "Providing integrated services over low-bitrate links," Internet Engineering Task Force, Jun. 1999.

Abstract: 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.

C. Bormann, "The Multi-Class Extension to Multi-Link PPP," Internet Engineering Task Force, Jun. 1999.

Abstract: 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.

C. Bormann, "PPP in a real-time oriented HDLC-like framing," Internet Engineering Task Force, Jun. 1999.

Abstract: 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.

B. Davie, E. Crawley, S. Jackowski and D. Putzolu, "Integrated Services Mappings for Low Speed Networks," Internet Engineering Task Force, May 1999.

Abstract: A set of companion documents describe an architecture for providing integrated services over low-bitrate links, such as modem lines, ISDN B-channels, and sub-T1 links [1, 2, 3, 4]. The main components of the architecture are: a set of real-time encapsulation formats 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 defines the service mappings of the IETF Integrated Services for low-bitrate links, specifically the controlled load [5] and guaranteed [6] services. The approach takes the form of a set of guidelines and considerations for implementing these services, along with evaluation criteria for elements providing these services.

E. Caves, P. Calhoun and R. Wheeler, "Layer Two Tunneling Protocol 'L2TP' Management Information Base," Internet Engineering Task Force, Mar. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

M. Wahl and T. Howes, "Use of Language Codes in LDAP," Internet Engineering Task Force, Jul. 1998.

Abstract: 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.

D. Boreham, J. Sermersheim, A. Anantha and M. Armijo, "LDAP Extensions for Scrolling View Browsing of Search Results," Internet Engineering Task Force, Apr. 2000.

Abstract: This document describes a Virtual List View control extension for the LDAP Search operation. This control is designed to allow the 'virtual list box' feature, common in existing commercial e-mail address book applications, to be supported efficiently by LDAP servers. LDAP servers' inability to support this client feature is a significant impediment to LDAP replacing proprietary protocols in commercial e-mail systems. The control allows a client to specify that the server return, for a given LDAP search with associated sort keys, a contiguous subset of the search result set. This subset is specified in terms of offsets into the ordered list, or in terms of a greater than or equal comparison value.

E. Stokes, R. Harrison and G. Good, "Extended Operations for Framing LDAP Operations," Internet Engineering Task Force, Mar. 2000.

Abstract: Certain types of LDAP applications can benefit from the ability to specify the beginning and end of a related group of operations. For example, the LDUP multimaster update protocol [ARCHITECTURE] requires that two servers agree to begin a session to transfer pending replication updates. This document provides a framework for constructing protocols that feature a framed set of related operations. It defines a pair of LDAPv3 extended operations that provide begin-end framing, and a pair of extended operations used to respond the begin-end framing operations. The nature of the actual LDAP operations carried inside these framing operations is not specified in this document. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. Certain terms used in this document are defined in the document 'LDAP Replication Architecture' [ARCHITECTURE].

M. Pullen, M. Myjak and C. Bouwens, "Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment," Internet Engineering Task Force, Nov. 1998.

Abstract: The Large-Scale Multicast Applications (LSMA) working group was chartered to produce Internet-Drafts aimed at a consensus-based development of the Internet protocols to support large scale multicast applications including real-time distributed simulation. This draft defines services that LSMA has found to be required, and aspects of the Internet protocols that LSMA has found to need further development in order to meet these requirements.

P. Bagnall, B. Briscoe and A. Poppitt, "Taxonomy of Communication Requirements for Large-scale Multicast Applications," Internet Engineering Task Force, May 1999.

Abstract: 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.

S. Kille and G. Mansfield, "Directory Server Monitoring MIB," Internet Engineering Task Force, Feb. 1999.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. This memo obsoletes RFC 1567 'X.500 Directory Monitoring MIB'. This memo extends that specification to a more generic MIB for monitoring one or more directory servers each of which may support multiple access protocols. The MIB defined in this memo will be used in conjunction with the NETWORK-SERVICES-MIB [19] for monitoring Directory Servers.

N. Freed and S. Kille, "Mail Monitoring MIB," Internet Engineering Task Force, Jan. 2000.

Abstract: 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 defined in RFC XXXX [16] to allow monitoring of Message Transfer Agents (MTAs). It may also be used to monitor MTA components within gateways.

S. Kille and N. Freed, "Mail Monitoring MIB," Internet Engineering Task Force, Dec. 1997.

Abstract: 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.

D. Thaler, "Multicast Address Allocation MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 multicast address allocation.

C. Perkins, E. Royer and S. Das, "Ad Hoc On Demand Distance Vector (AODV) Routing," Internet Engineering Task Force, Jul. 2000.

Abstract: The Ad Hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast between sources and destinations. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), solving problems (such as ``counting to infinity'') associated with classical distance vector protocols.

S. Corson and V. Park, "An Internet MANET Encapsulation Protocol (IMEP) Specification," Internet Engineering Task Force, Dec. 1997.

Abstract: This memo describes a multipurpose network-layer protocol---named the Internet MANET Encapsulation Protocol (IMEP)---designed to support the operation of many routing algorithms or other upper layer protocols intended for use in Mobile Ad hoc Networks (MANET). The protocol incorporates mechanisms for supporting link status sensing, control message aggregation and encapsulation, broadcast reliability, network-layer address resolution and provides hooks for interrouter security authentication procedures. The IMEP also puts forth a framework or architecture for MANET router and interface identification and addressing. The present specification is high-level and incomplete, giving only a behavioral protocol description and proposed packet format. This version of this draft is intended primarily to acquaint readers with the concept of the protocol. A subsequent revision will detail the protocol's mechanisms and data structures.

S. Corson and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations," Internet Engineering Task Force, Oct. 1998.

Abstract: This memo first describes the characteristics of Mobile Ad hoc Networks (MANETs), and their idiosyncrasies with respect to traditional, hardwired packet networks. It then discusses the effect these differences have on the design and evaluation of network control protocols with an emphasis on routing performance evaluation considerations.

C. Toh, "Long-lived Ad Hoc Routing based on the Concept of Associativity," Internet Engineering Task Force, Mar. 1999.

Abstract: This document describes the associativity-based long-lived routing (ABR) protocol for ad hoc mobile networks. It is a simple and bandwidth-efficient distributed routing protocols which does not attempt to consistently maintain routing information in every node. In an ad hoc wireless network where mobile hosts are acting as routers and where routes are made inconsistent by mobile hosts' movement, we propose an Associativity-based routing scheme where a route is selected based on nodes having associativity states that imply periods of spatial, temporal, connection and signal stability. In this manner, the routes selected are likely to be long-lived and hence there is no need to restart frequently, resulting in higher attainable throughput. Our proposed protocol is based on source-initiated on-demand routing. Route requests are broadcast on a per-need basis. To discover shorten the route discovery time when the association property is violated, the localized- query and quick-abort mechanisms are respectively incorporated into the protocol. The association property also allows the integration of ad hoc routing into a base station oriented wireless LAN environment, providing the fault tolerance in times of base station failures. This draft will describe the protocol functions and information about packet headers and routing tables.

D. Meyer, "Some Issues for an Inter-domain Multicast Routing Protocol," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

T. Maufer and C. Semeria, "Introduction to IP Multicast Routing," Internet Engineering Task Force, Oct. 1997.

Abstract: 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). Distance Vector Multicast Routing Protocol (DVMRP) o Multicast Extensions to OSPF (MOSPF); Protocol-Independent Multicast - Dense Mode (PIM-DM); Protocol-Independent Multicast - Sparse Mode (PIM-SM); Core-Based Trees (CBT)

B. Cain, "Connecting Multicast Domains," Internet Engineering Task Force, Mar. 2000.

Abstract: New deployment of multicast routing in Internet Service Provider networks is through the use of the PIM-SM [PIMSM], MSDP [MSDP], and MBGP [MBGP] protocols. This informational document describes several solutions for the connection of different types of multicast routing domains. In particular, the problems and solutions for the connection of a stub intra-domain multicast routing domain to a transit (ISP) PIM-SM domain are addressed.

H. LaMaster, S. Shultz, J. Meylor and D. Meyer, "Multicast-Friendly Internet Exchange (MIX)," Internet Engineering Task Force, Dec. 1998.

Abstract: This document describes an architecture for a Multicast-friendly Internet eXchange (MIX), and the actual implementation at the NASA Ames Research Center Federal Internet eXchange (FIX-West, or FIX). The MIX has three objectives: native IP multicast routing, scalable interdomain policy-based route exchange, and to allow a variety of IGP protocols and topologies for intra-domain use. In support of these objectives, the MIX architecture defines the following components: a peer-peer routing protocol, a method for multicast forwarding, a method for exchanging information about active sources, and a medium which provides native multicast. This document describes the protocols and configurations necessary to provide a current, working multicast-friendly internet exchange, or MIX. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to

K. Almeroth and L. Wei, "Justification for and use of the Multicast Routing Monitor (MRM) Protocol," Internet Engineering Task Force, Mar. 1999.

Abstract: This document motivates the need for the Multicast Routing Monitor (MRM) [MRM] protocol by describing the niche that exists for a router-based multicast management protocol. Using the 'sufficient and necessary' argument, we suggest that existing protocols and techniques lack important management functionality. This document briefly describes the methodology used by MRM, justifies the existence of MRM, and describes some of the scenarios in which MRM will be of value.

M. Arango, A. Dugan, I. Elliott, C. Huitema and S. Pickett, "Media Gateway Control Protocol (MGCP)," Internet Engineering Task Force, Feb. 1999.

Abstract: This document describes an application programming interface and a corresponding protocol (MGCP) for controlling Voice over IP (VoIP) Gate- ways from external call control elements. MGCP assumes a call control architecture where the call control 'intelligence' is outside the gate- ways and handled by external call control elements. The document is structured in 6 main sections: * The introduction presents the basic assumptions and the relation to other protocols such as H.323, RTSP, SAP or SIP. * The interface section presents a conceptual overview of the MGCP, presenting the naming conventions, the usage of the session description protocol SDP, and the procedures that compose MGCP: Notifications Request, Notification, Create Connection, Modify Con- nection, Delete Connection, AuditEndpoint, AuditConnection and Res- tartInProgress. * The protocol description section presents the MGCP encodings, which are based on simple text formats, and the transmission procedure over UDP. * The security section presents the security requirement of MGCP, and its usage of IP security services (IPSEC). * The event packages section provides an initial definition of pack- ages and event names. * The description of the changes made in combining SGCP 1.1 and IPDC to create MGCP 0.1.

J. Palme, A. Hopmann and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)," Internet Engineering Task Force, Sep. 1998.

Abstract: HTML [RFC 1866] defines a powerful means of specifying multimedia documents. These multimedia documents consist of a text/html root resource (object) and other subsidiary resources (image, video clip, applet, etc. objects) referenced by Uniform Resource Identifiers (URIs) within the text/html root resource. When an HTML multimedia document is retrieved by a browser, each of these component resources is individually retrieved in real time from a location, and using a protocol, specified by each URI. In order to transfer a complete HTML multimedia document in a single e-mail message, it is necessary to: a) aggregate a text/html root resource and all of the subsidiary resources it references into a single composite message structure, and b) define a means by which URIs in the text/html root can reference subsidiary resources within that composite message structure. This document a) defines the use of a MIME multipart/related structure to aggregate a text/html root resource and the subsidiary resources it references, and b) specifies one MIME content-headers (Content-Location) that allow URIs in a multipart/related text/html root body part to reference subsidiary resources in other body parts of the same multipart/related structure. While initially designed to support e-mail transfer of complete multi-resource HTML multimedia documents, these conventions can also be employed by other transfer protocols such as HTTP and FTP to retrieve a complete multi-resource HTML multimedia document in a single transfer or for storage and archiving of complete HTML-documents. Differences between this and a previous version of this standard, which was published as RFC 2110, are summarized in chapter 12.

M. Handley, J. Crowcroft, C. Bormann and J. Ott, "The Internet Multimedia Conferencing Architecture," Internet Engineering Task Force, Jul. 2000.

Abstract: This document provides an overview of multimedia conferencing on the Internet. The protocols mentioned are specified elsewhere as RFCs, Internet-Drafts, or ITU recommendations. Each of these specifications gives details of the protocol itself, how it works and what it does. This document attempts to provide the reader with an overview of how the components fit together and of some of the assumptions made, as well as some statement of direction for those components still in a nascent stage.

R. Ramjee, T. La Porta, S. Thuel, K. Varadhan and L. Salgarelli, "IP micro-mobility support using HAWAII," Internet Engineering Task Force, Jul. 2000.

Abstract: In this contribution, we present HAWAII: a domain-based approach for supporting mobility. HAWAII uses specialized path setup schemes which install host-based forwarding entries in specific routers to support intra-domain micro-mobility and defaults to using Mobile-IP for inter-domain macro-mobility. These path setup schemes deliver excellent performance by reducing mobility related disruption to user applications, and by operating locally, reduce the number of mobility related updates. Also, in HAWAII, mobile hosts retain their network address while moving within the domain, simplifying Quality of Service support. Furthermore, reliability is achieved through maintaining soft-state forwarding entries for the mobile hosts and leveraging fault detection mechanisms built in existing intra-domain routing protocols.

G. Troxel and L. Sanchez, "Rapid Authentication for Mobile IP," Internet Engineering Task Force, Dec. 1997.

Abstract: This document describes a mechanism that provides Mobile IP nodes and agents with the necessary keys and information needed to establish mobility security associations within a foreign network. This mechanism aims at reducing the latency and computational burden introduced by public-key based key management protocols in network topologies where visiting mobile nodes register with their respective home agents several times through different foreign agents requiring Mobile-Foreign Authentication. This mechanism employs a key distribution center capable of generating the security contexts needed to authenticate Mobile IP control messages. This mechanism, designed as an extension to the Mobile IP protocol, preservs backward compatibility and interoperability with RFC2002 compliant implementations of Mobile IP.

M. Johnsson, "Simple Mobile IP (SMIP)," Internet Engineering Task Force, Jun. 1999.

Abstract: This document describes an alternative to the support for IP mobility compared to the solution outlined and specified in [MobIP]. As the title of the solution implies, it addresses the problems with the overall complexity of the current Mobile IP solution including some of the proposed extensions as outlined in [RouteOpt], [3G-IMT]. This more simplistic approach relies on two basic prerequisites: Development made in recent years, and also development foreseen in a near-term future, regarding certain key protocols and techniques for name-to-address resolution, directory services, address assignment, and roaming support; and also the fact that the solution is suited for usage within one organizational scope.

K. Kompella, Y. Rekhter and A. Kullberg, "Signalling Unnumbered Links in CR-LDP," Internet Engineering Task Force, Nov. 2000.

Abstract: Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to CR-LDP, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.

T. Nadeau, C. Srinivasan and A. Viswanathan, "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base Using SMIv2," Internet Engineering Task Force, Sep. 2000.

Abstract: 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 defining FEC-to-NHLFE mapping and corresponding actions for use with Multiprotocol Label Switching (MPLS).

L. Berger and J. Jeffords, "MPLS/IP Header Compression over PPP," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes an option for negotiating the use of MPLS and IP header compression over the Point-to-Point Protocol [STD51]. It defines extensions to the PPP Control Protocol for MPLS [LABELS]. It is based on, and borrows heavily from, IP Header Compression over PPP [RFC2509]. MPLS/IP header compression is defined in [CMPLS] and may be applied to MPLS datagrams transporting IPv4 and IPv6 datagrams in combination with TCP, UDP and RTP transport protocols.

A. Farrel, P. Brittain, P. Matthews and E. Gray, "Fault Tolerance for LDP and CR-LDP," Internet Engineering Task Force, Oct. 2000.

Abstract: MPLS systems will be used in core networks where system downtime must be kept to an absolute minimum. Many MPLS LSRs may, therefore, exploit Fault Tolerant (FT) hardware or software to provide high availability of the core networks. The details of how FT is achieved for the various components of an FT LSR, including LDP, CR-LDP, the switching hardware and TCP, are implementation specific. This document identifies issues in the CR-LDP specification [2] and the LDP specification [4] that make it difficult to implement an FT LSR using the current LDP and CR-LDP protocols, and proposes enhancements to the LDP specification to ease such FT LSR implementations. The extensions described here are equally applicable to CR-LDP.

J. Cucchiara, H. Sjostrand and J. Luciani, "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)," Internet Engineering Task Force, Aug. 2000.

Abstract: 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 for the Multiprotocol Label Switching, Label Distribution Protocol (LDP).

C. Srinivasan, A. Viswanathan and T. Nadeau, "MPLS Label Switch Router Management Information Base Using SMIv2," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 modeling a Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Label Switch Router (LSR).

D. Ooms, B. Sales, W. Livens, A. Acharya, F. Griffoul and F. Ansari, "Framework for IP Multicast in MPLS," Internet Engineering Task Force, May 2000.

Abstract: This document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered.

K. Kompella and Y. Rekhter, "Signalling Unnumbered Links in RSVP-TE," Internet Engineering Task Force, Nov. 2000.

Abstract: Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to RSVP-TE, one of the MPLS TE signalling protocols, that are needed in order to support unnumbered links.

C. Srinivasan, A. Viswanathan and T. Nadeau, "MPLS Traffic Engineering Management Information Base Using SMIv2," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 Multi-Protocol Label Switching (MPLS) [MPLSArch] [MPLSFW] based traffic engineering.

B. Fenner and D. Thaler, "Multicast Source Discovery protocol MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 Multicast Source Discovery Protocol (MSDP) [17] speakers.

B. Fenner and D. Thaler, "Multicast Source Discovery protocol MIB," Internet Engineering Task Force, Apr. 1999.

Abstract: 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 Multicast Source Discovery Protocol (MSDP) [17] speakers.

M. Beadles and D. Mitton, "Criteria for Evaluating Network Access Server Protocols," Internet Engineering Task Force, Jun. 2000.

Abstract: This document defines requirements for protocols used by Network Access Servers (NAS). Protocols used by NAS's may be divided into four spaces: Access protocols, Network protocols, AAA protocols, and Management pro- tocols. Primary attention is given to setting requirements for AAA protocols, since that space is currently the least well defined.

D. Mitton, "Network Access Servers Requirements: Extended RADIUS Practices," Internet Engineering Task Force, May 2000.

Abstract: This document describes current practices implemented in NAS products that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The pur- pose of this effort is to give examples that show the need for address- ing and standardizing these types of ad-hoc functions. Since many of these features require a matching server support component, the ability to deploy and manage interoperable NAS and AAA server products is severely hindered. These practices are documented here to show functions that are obviously desired in developing future AAA protocols for NAS deployment. This document is a draft submission of the Network Access Server Requirements (NASREQ) Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mailing list nasreq@tdmx.rutgers.edu.}

D. Mitton and M. Beadles, "Network Access Server Requirements Next Generation (NASREQNG)NAS Model," Internet Engineering Task Force, May 2000.

Abstract: This document describes the terminology and gives a model of typical Network Access Server (NAS). The purpose of this effort is to set the reference space for describing and evaluating NAS service protocols, such as RADIUS (RFC 2138, 2139)[1],[2] and follow-on efforts like AAA Working Group, and the Diameter protocol [3]. These are protocols for carrying user service information for authentication, authorization, accounting, and auditing, between a Network Access Server which desires to authenticate its incoming calls and a shared authentication server.

P. Srisuresh, "IP Network Address Translator Application Programming Interface," Internet Engineering Task Force, Nov. 1998.

Abstract: NAT provides routing transparency for hosts in disparate routing realms to communicate with each other. However, external agents such as Application Level Gateways (ALGs), Host-NAT-clients and Management applications need to interact with NAT and influence its operations. The document identifies the resources and other elements controlled by a NAT device, with specific focus on areas subject to influence from external agents. An Application Programming Interface (API) framework by which external agents could interact with NAT is presented. The intent of this document is to leverage the API specification as a base to identify requirements for the development of one or more protocols by which external agents could interact with NAT.

D. Senie, "NAT Friendly Application Design Guidelines," Internet Engineering Task Force, Jul. 2000.

Abstract: While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. This document discusses those things which application designers might wish to consider when designing new protocols. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT.

J. Lo and K. Taniguchi, "IP Host Network Address (and Port) Translation," Internet Engineering Task Force, Nov. 1998.

Abstract: Network Address Translation has become a popular technique that allows private addresses unregistered with Internet Assigned Number Authority (IANA) to be used by organizations within a private routing realm. These private addresses must not be advertised in the public Internet. Hence network address translator (NAT) are placed at the private routing realm border to translate private addresses to globally unique addresses and vice versa before packets are exchanged between the disparate routing realms. These modifications of the packet header by the NAT cause problems with the use of end-to-end security protocols such as IPSec and DNSSEC because network address translation does exactly what the security protocols are trying to prevent. Host Network Address Translation (HNAT) and Host Network Address Port Translation (NAPT), on the other hand, enable end hosts to carry out address (and port) translations before applying security algorithms. To make dynamic HNAT and HNAPT possible, three conditions are essential. First, there must exist a way for end hosts to discover the IP address of Host-NA(P)T-Server. Second, there must be a way for externally destined packets to be routed in the private domain between the Host -NA(P)T-Client and Host-NA(P)T-Server. Lastly, Host-NA(P)T-Client must be able to obtain an address (and port) binding from the Host-NA(P)T -Server dynamically. This draft aims to address these issues to a considerable extent. Methods suggested are by no means exhaustive in coverage and implementation specifics may vary from vendor to vendor.

P. Srisuresh, "Framework for interfacing with Network Address Translator," Internet Engineering Task Force, Jul. 2000.

Abstract: NAT provides routing transparency for hosts in disparate address realms to communicate with each other. However, external agents such as Application Level Gateways (ALGs), Realm Specific IP RSIP) clients and Management applications need to interact with NAT and influence its operations. The document identifies NAT managed resources and ways by which these resources may be controlled from external agents. The resource control mechanism is illustrated functionally through an Application Programming Interface (API). However, it is not the intent of this document to standardize the API. Rather, use the API as basis to illustrate and provide a basis for the development of one or more protocols by which external agents could interact with NAT. Identification of NAT controlled resources also provides a basis to generate NAT Management Information Base (MIB).

M. Holdrege and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)," Internet Engineering Task Force, Oct. 2000.

Abstract: Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of NAT enroute to bridge the realms. NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.

M. Borella, J. Lo, D. Grabelsky and G. Montenegro, "Realm Specific IP: A Framework," Internet Engineering Task Force, Jul. 2000.

Abstract: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end-to- end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.

A. Durand and B. Buclin, "6Bone Routing Practice," Internet Engineering Task Force, May 1998.

Abstract: The 6Bone is an environment supporting experimentation with the IPv6 protocols and products implementing it. As the network grows, the need for common operation rules emerged. In particular, operation of the 6Bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies guidelines on how 6Bone sites might operate, so that the 6Bone can remain a quality experimentation environment and to avoid pathological situations that have been encountered in the past. It defines the 'best current practice' acceptable in the 6Bone for the configuration of both Interior Gateway Protocols (such as RIPng [RFC 2080]) and Exterior Gateway Protocols (like BGP4+ [RFC 2283]).

A. Durand and B. Buclin, "IPv6 routing issues," Internet Engineering Task Force, Apr. 1998.

Abstract: Operation of the 6bone backbone is a challenge due to the frequent insertion of bogus routes by leaf or even backbone sites. This memo identifies some pathological cases and gives some guidelines on how 6bone sites should handle them. It defines the 'best current practice' acceptable in the 6bone for the config- uration of both Interior Gateway Protocols (like RIPng) and Exterior Gateway Protocols (like BGP4+).

P. Nesser II, "Survey of IPv4 Addresses in Currently Deployed IETF Standards," Internet Engineering Task Force, Apr. 2000.

Abstract: This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at leasy dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, Proposed and Experimental) will be survey and any dependencies will be documented.

H. Kitamura, "A SOCKS-based IPv6/IPv4 Gateway Mechanism," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes a SOCKS-based IPv6/IPv4 gateway mechanism that enables smooth heterogeneous communications between the IPv6 nodes and IPv4 nodes. It is based on the SOCKS protocol [SOCKSv5]. By applying the SOCKS mechanism to the heterogeneous communications and relaying two 'terminated' IPv4 and IPv6 connections at the 'application layer' (the SOCKS server), the SOCKS-based IPv6/IPv4 gateway mechanism is accomplished. Since it is accomplished without introducing new protocols, it provides the same communication environment that is provided by the SOCKS mechanism. The same appearance is provided to the heterogeneous communications. No conveniences or functionalities of current communications are sacrificed.

J. Hagino and K. Yamamoto, "An IPv6-to-IPv4 transport relay translator," Internet Engineering Task Force, May 2000.

Abstract: The memo describes an IPv6-to-IPv4 transport relay translator (TRT). It enables IPv6-only hosts to exchange {TCP,UDP} traffic with IPv4-only hosts. A TRT system, which locates in the middle, translates {TCP,UDP}/IPv6 to {TCP,UDP}/IPv4, or vice versa. The draft talks about how to implement a TRT system using existing technologies. It does not define any new protocols.

S. Barber, "Network News Transport Protocol," Internet Engineering Task Force, Nov. 2000.

Abstract: The Network News Transport Protocol has been in use in the Internet for a decade and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977 and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality and provides a specific mechanism to add standardized extensions to NNTP.

A. Zinin and M. Shand, "Flooding optimizations in link-state routing protocols," Internet Engineering Task Force, Nov. 2000.

Abstract: The flooding algorithm is one of the most important parts of any link state routing protocol. It ensures that all routers within a link state domain converge on the same topological information within a finite period of time. To ensure reliability, typical implementations of the flooding algorithm send new information via all interfaces other than the one the new piece of information was received on. This redundancy is necessary to guarantee that flooding is performed reliably, but implies considerable overhead of utilized bandwidth and CPU time if neighboring routers are connected with more than one link. This document describes a method that reduces this overhead.

S. Giacalone, D. Joyal, R. Coltun and F. Baker, "OSPF Version 2 Management Information Base," Internet Engineering Task Force, Sep. 2000.

Abstract: 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 Open Shortest Path First Routing Protocol. This memo is intended to update and possibly obsolete RFC 1850, however, it is designed to be backwards compatible. The functional differences between this memo and RFC 1580 are explained in Appendix B. Please send comments to ospf@discuss.microsoft.com.}

D. Joyal, "Management Information Base for OSPFv3," Internet Engineering Task Force, Apr. 2000.

Abstract: This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. In particular, it defines objects for managing the Open Shortest Path First Routing Protocol for IPv6. 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. Please send comments to ospf@discuss.microsoft.com.}

A. Zinin, "Guidelines for Efficient LSA Refreshment in OSPF," Internet Engineering Task Force, Jul. 2000.

Abstract: OSPF, an IGP widely deployed in IP networks today, requires each LSA to be refreshed by the originating router every 30 minutes. This method increases the protocol's robustness and solves potential problems that may be caused by software bugs, as well as some properties of the protocol itself. Though OSPF expects each LSA to be refreshed independently, ABRs and ASBRs tend to originate Type 3/4/5 LSAs within a short period of time, thus causing periodical network resource exhaustion by LSA refreshments. This document discusses the techniques that can be used to remedy this problem and provide smooth protocol operation. It must be noted that discussed methods can be applied to other link-state routing protocols, such as IS-IS.

C. Newman, "The One-Time-Password SASL Mechanism," Internet Engineering Task Force, May 1998.

Abstract: OTP [OTP] provides a useful authentication mechanism for situations where there is limited client or server trust. Currently, OTP is added to protocols in an ad-hoc fashion with heuristic parsing. This specification defines an OTP SASL [SASL] mechanism so it can be easily and formally integrated into many application protocols.

S. Dawkins, G. Montenegro, M. Kojo, V. Magret and N. Vaidya, "End-to-end Performance Implications of Links with Errors," Internet Engineering Task Force, Oct. 2000.

Abstract: The rapidly-growing Internet is being accessed by an increasingly wide range of devices over an increasingly wide variety of links. At least some of these links do not provide the reliability that hosts expect, and this expansion into unreliable links causes some Internet protocols, especially TCP [RFC793], to perform poorly.

J. Touch, M. Montpetit, J. Mahdavi, G. Montenegro, D. Grossman and G. Fairhurst, "Advice for Internet Subnetwork Designers," Internet Engineering Task Force, Jul. 2000.

Abstract: This document provides advice to the designers of digital communication equipment, link layer protocols and packet switched subnetworks (collectively referred to as subnetworks) who wish to support the Internet protocols but who may be unfamiliar with the architecture of the Internet and the implications of their design choices on the performance and efficiency of the Internet.

H. Sandick, G. Kump and B. Haberman, "Protocol Independent Multicast Routing in the Internet Protocol Version 6 (IPv6)," Internet Engineering Task Force, Mar. 2000.

Abstract: This document outlines recommendations in the use of the Protocol Independent Multicast routing protocol to support Internet Protocol version 6. It describes the changes needed in order to handle the differences between IPv6 and IPv4 and conform to the logic introduced by other routing protocols enabled for IPv6.

S. Petrack, "Basic Service Requirements, Definitions, and Architecture," Internet Engineering Task Force, Nov. 1997.

Abstract: This document specifies those PSTN services which will be accessible from the Internet via the PINT protocols. It defines these services in terms of a simple set of architectural elements and atomic services. It gives some concrete examples of these services, and indicates how to build the examples out of the presented atomic services.

A. Brusilovsky, E. Gausmann, V. Gurbani and A. Jain, "A Proposal for Internet Call Waiting Service using SIP An Implementation Report," Internet Engineering Task Force, Nov. 1998.

Abstract: The purpose of this Internet Draft is to start discussion on the issues involved in Internet Call Waiting Service (ICW), as part of interconnecting IP and Global Switched Telephone Network (GSTN) with the intent of providing ICW service that is much needed by numerous dial-up Internet users. Interworking of the IP network and GSTN, based on open well-defined protocols, will promote interoperability of both the networks and systems built by different vendors. This Internet Draft is submitted with the goal of becoming an informational RFC. The rest of this document is as follows: Section 2 briefly describes the services offered to the end Subscriber. It is the support of these services that necessitates the proposed internetworking project. Section 3 describes the scope of the proposed project by introducing its overall architecture, identifying the interfaces to be standardized, describing experience with SIP for ICW. Sections 4, 5, and 6 respectively address security considerations, supply references, and provide the authors address, as required by [1]. Section 7 acknowledges individuals providing assistance in the creation of this document. Section 8 is the Appendix, which contains IN Tutorial and Figure A.

L. Conroy and S. Petrack, "The PINT Profile of SIP and SDP: a Protocol for IP Access to Telephone Call Services," Internet Engineering Task Force, Mar. 1999.

Abstract: This document contains the specification of the PINT Profile 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP 2.0 protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors.}

S. Petrack and L. Conroy, "The PINT Service Protocol:Extensions to SIP and SDP for IP Access to Telephone Call Services," Internet Engineering Task Force, Feb. 2000.

Abstract: This document contains the specification of the PINT Service Protocol 1.0, which defines a protocol for invoking certain telephone services from an IP network. These services include placing basic calls, sending and receiving faxes, and receiving content over the telephone. The protocol is specified as a set of enhancements and additions to the SIP 2.0 and SDP protocols. This document is intended for the PSTN-Internet Interworking (PINT) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at pint@lists.research.bell-labs.com and/or the authors.}

J. Buller, "A proposal for the provisioning of PSTN initiated services running on the Internet," Internet Engineering Task Force, Mar. 1999.

Abstract: This Internet Draft has arisen out of work concentrating on the interconnection of IP and the Public Switched Telephone Network (PSTN) undertaken within the PINT working group. Efforts within this group have, to date, concentrated on the initiation of PSTN services from the Internet. This Internet Draft aims to describe a possible architecture for the implementation of services initiated from the PSTN such as, but not limited to, Internet Call Waiting (ICW). It also identifies the possibility of using this class of service, in conjunction with the PINT work already undertaken, in order to provide a third flavour of service. This Internet Draft deliberately does not to define the protocols for these kinds of services, although descriptions contained within it do use Session Initiation Protocol (SIP) terminology. The purpose of this Internet Draft is to ascertain the level of interest in pursuing this area of work. It is submitted with the goal of forming the basis of an Informational RFC and thereby further work on the standardisation of the provision of these kinds of services.

S. Farrell and R. Housley, "An Internet Attribute Certificate Profile for Authorization," Internet Engineering Task Force, Aug. 2000.

Abstract: This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPSec, and WWW security applications.

A. Kapoor and R. Tschalar, "Transport Protocols for CMP," Internet Engineering Task Force, Oct. 2000.

Abstract: This document describes how to layer Certificate Management Protocols [CMP] over various transport protocols.

C. Adams, P. Sylvester, M. Zolotarev and R. Zuccherato, "Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols," Internet Engineering Task Force, Oct. 2000.

Abstract: This document describes a general Data Validation and Certification Server (DVCS) and the protocols to be used when communicating with it. The Data Validation and Certification Server is a Trusted Third Party (TTP) that can be used as one component in building reliable non-repudiation services (see [ISONR]). Useful Data Validation and Certification Server responsibilities in a PKI are to assert the validity of signed documents, public key certificates, and the possession or existence of data.

S. Boeyen, T. Howes and P. Richard, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2," Internet Engineering Task Force, Sep. 1998.

Abstract: The protocol described in this document is designed to satisfy some of the operational requirements within the Internet X.509 Public Key Infrastructure (IPKI). Specifically, this document addresses requirements to provide access to Public Key Infrastructure (PKI) repositories for the purposes of retrieving PKI information and managing that same information. The mechanism described in this document is based on the Lightweight Directory Access Protocol (LDAP) v2, defined in RFC 1777, defining a profile of that protocol for use within the IPKI and updates encodings for certificates and revocation lists from RFC 1778. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. The key words 'MUST', 'REQUIRED', 'SHOULD', 'RECOMMENDED', and 'MAY' in this document are to be interpreted as described in RFC 2119. Please send comments on this document to the ietf-pkix@imc.org mail list.}

C. Adams and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols," Internet Engineering Task Force, Jan. 1999.

Abstract: This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].

D. Chadwick, "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3," Internet Engineering Task Force, Sep. 2000.

Abstract: This document describes the features of the Lightweight Directory Access Protocol v3 that are needed in order to support a public key infrastructure based on X.509 certificates and CRLs.

R. Housley and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP," Internet Engineering Task Force, Jul. 1998.

Abstract: The protocol conventions described in this document satisfy some of the operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the File Transfer Protocol (FTP) and the Hypertext Transfer Protocol (HTTP) to obtain certificates and certificate revocation lists (CRLs) from PKI repositories. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. Please send comments on this document to the ietf-pkix@imc.org mail list.}

S. Boeyen and P. Hallam-Baker, "Internet X.509 Public Key Infrastructure Repository Locator Service," Internet Engineering Task Force, Jul. 2000.

Abstract: This document defines a PKI repository locator service. The service makes use of DNS SRV records defined in accordance with RFC 2782. The service enables certificate using systems to locate PKI repositories based on a domain name, identify the protocols that can be used to access the repository, and obtain addresses for the servers that host the repository service.

C. Adams and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that 'certificate' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM].

C. Adams, P. Cain, D. Pinkas and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time Stamp Protocols (TSP)," Internet Engineering Task Force, Oct. 2000.

Abstract: A time stamping service supports assertions of proof that a datum existed before a particular time. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security- relevant requirements for TSA operation, with regards to processing requests to generate responses. A TSA may be operated as a Trusted Third Party (TTP) service, though other operational models may be appropriate, e.g. an organization might require a TSA for internal time stamping purposes. Non-repudiation services [ISONR] require the ability to establish the existence of data before specified times. This protocol may be used as a building block to support such services. An example of how to prove that a digital signature was generated during the validity period of a public key certificate is given in an annex.

S. Reddy, "WEB based Certificate Access Protocol-- WebCAP/1.0," Internet Engineering Task Force, Apr. 1998.

Abstract: This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Access Protocols. Protocol messages are defined for all relevant aspects of certificate creation and management. Note that ''certificate'' in this document refers to an X.509v3 Certificate as defined in [COR95, X509-AM]. This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 to publish, retrieve X.509 certificates and Certificate Revocation Lists. This protocol also facilitates determining current status of a digital certificate without the use of CRLs. This protocol defines new methods, request and response bodies, error codes to HTTP/1.1 protocol for securely publishing, retrieving, and validation certificates across a firewalls.

J. Strassner and S. Schleimer, "Policy Framework Definition Language," Internet Engineering Task Force, Nov. 1998.

Abstract: Recently, the IETF has developed protocols that classify packets in order to treat certain classes or flows of packets in a particular way compared to other classes or flows of packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to different types of network devices as well as hosts and servers that participate in policy decision making, administration, distribution and control. There is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy. This document defines a language, called the Policy Framework Definition Language (PFDL), that maps requirements for services to be provided by the network as defined in a business specification (e.g., an SLA) to a common vendor- and device-independent intermediate form. This enables policy information and specifications to be shared among the heterogeneous components that comprise the policy framework, and allows multiple vendors to use multiple devices to implement that framework. The PFDL is the common 'currency' that is exchanged between these heterogeneous components to enable them all to perform their function in providing, securing, distributing, and administering policy. The PFDL becomes the way to ensure that multiple vendors interpret the policy the same way while enabling vendors to provide value-added services.

J. Strassner and E. Ellesson, "Terminology for describing network policy and services," Internet Engineering Task Force, Jun. 1999.

Abstract: Recent work in the IETF has led to multiple protocols which support the classification of packets for the purposes of treating certain classes or flows of packets in a particular way compared to other packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to the multiple devices in the network which perform the classification and packet conditioning or treatment. As a result, there is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy.

H. Kummert, "The PPP Triple-DES Encryption Protocol (3DESE)," Internet Engineering Task Force, Jul. 1998.

Abstract: 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.

M. Higashiyama and F. Baker, "PPP Bridging Control Protocol (BCP)," Internet Engineering Task Force, May 2000.

Abstract: The Point-to-Point Protocol (PPP) [6] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols for establishing and configuring different network-layer protocols. This document defines the Network Control Protocol for establishing and configuring Remote Bridging for PPP links. This document obsoletes RFC 1638, which was based on the IEEE 802.1D-1993 MAC Bridge[3]. This document extends that specification by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9] standards. This document also improves the protocol in order to support high-speed switched LANs.

J. Zmuda and W. Nace, "PPP Certificate Exchange Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: 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 of its peer before allowing Network Layer protocols to transmit over the link. The Certificate exchange protocol is an extension to PPP that is in the form of an additional phase, called the certificate exchange phase, that would allow for a PPP entity to request certificates from a peer. If configured, this phase would be negotiated during the LCP exchange. This exchange of certificates is aimed at easing configuration issues by providing for the exchange of certificate path information in a standard manner across different strong, or public-key certificate-based, authentication protocols. The certificate exchange protocol accomodates arbitrary sized certificates.

K. Sklower and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)," Internet Engineering Task Force, Jul. 1998.

Abstract: 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.

J. Vollbrecht and L. Blunk, "PPP Extensible Authentication Protocol (EAP)," Internet Engineering Task Force, Jan. 1998.

Abstract: 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.

J. Zmuda and W. Nace, "PPP EAP DSS Public Key Authentication Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: 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 of 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. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the DSS Public Key Authentication Protocol within PPP EAP.

P. Yee, J. Zmuda and W. Nace, "PPP EAP KEA Public Key Authentication Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: 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 of 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. This document specifies yet another authentication mechanism that may be used within the EAP framework. This document defines the KEA Public Key Authentication Protocol within PPP EAP. A side effect of KEA public key authentication is the creation of a session key for encryption of data on the PPP link.

J. Zmuda and W. Nace, "PPP Fortezza Encryption Encapsulation Protocol," Internet Engineering Task Force, Dec. 1997.

Abstract: 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 of its peer before allowing Network Layer protocols to transmit over the link. One of the Authentication protocols that can be negotiated is the EAP. The EAP can be used in any of a number of variants. When the EAP is used in it's KEA variant, this results in mutual authentication and key generation. This key is available for use during the PPP data transfer phase by an encryption encapsulation. The encryption encapsulation that is described in this memo is one possible encapsulation that can use the keying material generated by the EAP KEA protocol.

E. Caves, P. Calhoun and R. Wheeler, "Layer Two Tunneling Protocol 'L2TP' Management Information Base," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions.

P. Calhoun, W. Townsley, S. Vakil and D. Grosser, "Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks," Internet Engineering Task Force, Jul. 1998.

Abstract: 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.

R. Shea, "L2TP Dynamic Data Window Adjustment," Internet Engineering Task Force, Nov. 1998.

Abstract: The Layer Two Tunneling Protocol (L2TP) defines the specification of congestion window sizes for data sessions. In addition, an LNS is given the capability to turn off sequence number processing for a data session, provided the LAC did not include the Sequencing Required AVP during session setup. This document specifies a mechanism whereby an L2TP peer can dynamically change the maximum window size values being used for a data session, in order to provide the flexibility to operate with smaller window sizes when history-bound protocols are operating over a session, and larger window sizes when no history-bound protocols are operating over a session.

G. Zorn, "PPP LCP Internationalization Configuration Option," Internet Engineering Task Force, Nov. 1998.

Abstract: 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 (LCP), which allows negotiation of an Authentication Protocol for authenticating its peer before allowing Network Layer protocols to transmit over the link. Both LCP and Authentication Protocol packets may contain text which is intended to be human-readable [2,3,4]. This document defines an LCP configuration option for the negotiation of character set and language usage, as required by RFC 2277 [5].

G. Pall and G. Zorn, "Microsoft Point-To-Point Encryption (MPPE) Protocol," Internet Engineering Task Force, Nov. 2000.

Abstract: The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP- encapsulated packets.

G. Zorn, "Derivating Keys for use with Microsoft Point-to-Point Encryption (MPPE)," Internet Engineering Task Force, Nov. 2000.

Abstract: The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links.

G. Zorn and S. Cobb, "Microsoft PPP CHAP Extensions," Internet Engineering Task Force, Mar. 1998.

Abstract: 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 and a family of Network Con- trol Protocols (NCPs) for establishing and configuring different net- work-layer protocols. This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which extends the user authentication functionality provided on Windows net- works to remote workstations. MS-CHAP is closely derived from the PPP Challenge Handshake Authentication Protocol described in RFC 1994 [2], which the reader should have at hand. The algorithms used in the generation of various MS-CHAP protocol fields are described in an appendix.

G. Zorn, "Microsoft PPP CHAP Extensions, Version 2," Internet Engineering Task Force, Apr. 1999.

Abstract: 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 and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document describes version two of Microsoft's PPP CHAP dialect (MS- CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1, described in [9]). In particular, certain protocol fields have been deleted or reused but with different semantics. In addition, MS-CHAP-V2 features mutual authentication. The algorithms used in the generation of various MS-CHAP-V2 protocol fields are described in section 8. Negotiation and hash generation examples are provided in section 9.

G. Zorn, "Deriving MPPE Keys From MS-CHAP V1 Credentials," Internet Engineering Task Force, Sep. 1998.

Abstract: The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. The Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) [3] is a Microsoft-proprietary PPP authentication protocol, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks. Microsoft Point to Point Encryption (MPPE) [4] is a means of represent- ing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the session key to be used for initializing encryption tables can be negotiated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive the initial MPPE ses- sion keys from MS-CHAP credentials. The algorithm used to change ses- sion keys during a session is described in [4].

G. Zorn, "Deriving MPPE Keys From MS-CHAP V2 Credentials," Internet Engineering Task Force, Nov. 1998.

Abstract: The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Compression Control Protocol [2] provides a method to negotiate and utilize compression protocols over PPP encapsulated links. Version 2 of the Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP-2) [3] is a Microsoft-proprietary PPP authentication protocol, providing the functionality to which LAN-based users are accustomed while integrating the encryption and hashing algorithms used on Windows networks. Microsoft Point to Point Encryption (MPPE) [4] is a means of representing PPP packets in an encrypted form. MPPE uses the RSA RC4 [5] algorithm to provide data confidentiality. The length of the ses- sion key to be used for initializing encryption tables can be negoti- ated. MPPE currently supports 40-bit and 128-bit session keys. MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet. MPPE is negotiated within option 18 [6] in the Compression Control Protocol. This document describes the method used to derive the initial MPPE ses- sion keys from MS-CHAP-2 credentials. The algorithm used to change ses- sion keys during a session is described in [4].

R. Bergman, "Job Submission Protocol Mapping Recommendations for the Job Monitoring MIB," Internet Engineering Task Force, Sep. 1998.

Abstract: This document defines the recommended mapping for many currently popular Job submission protocols to objects and attributes in the Job Monitoring MIB.

A. Bierman and K. Jones, "Physical Topology MIB," Internet Engineering Task Force, Jun. 2000.

Abstract: 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 physical topology identification and discovery.

A. Bierman and K. McCloghrie, "Physical Topology Discovery Protocol and MIB," Internet Engineering Task Force, Nov. 1998.

Abstract: 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.

B. Aboba and G. Zorn, "RADIUS Accounting Client MIB," Internet Engineering Task Force, Apr. 1999.

Abstract: This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients.

G. Zorn and B. Aboba, "RADIUS Accounting Server MIB," Internet Engineering Task Force, Apr. 1999.

Abstract: This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers.

B. Aboba and G. Zorn, "RADIUS Authentication Client MIB," Internet Engineering Task Force, Apr. 1999.

Abstract: This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients.

G. Zorn and B. Aboba, "RADIUS Authentication Server MIB," Internet Engineering Task Force, Apr. 1999.

Abstract: This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers.

G. Zorn, "Microsoft Vendor-specific RADIUS Attributes," Internet Engineering Task Force, Oct. 1998.

Abstract: This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft propri- etary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-spe- cific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products.

B. Aboba and G. Zorn, "Implementation of L2TP Compulsory Tunneling via RADIUS," Internet Engineering Task Force, Oct. 1998.

Abstract: This document discusses implementation issues arising in the provi- sioning of compulsory tunneling in dial-up networks using the L2TP protocol. 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.

J. Boyle, R. Cohen, D. Durham, S. Herzog, R. Rajan and A. Sastry, "The COPS (Common Open Policy Service) Protocol," Internet Engineering Task Force, Nov. 1999.

Abstract: This document describes a simple client/server model for supporting policy control over QoS signaling protocols. The model does not make any assumptions about the methods of the policy server, but is based on the server returning decisions to policy requests. The model is designed to be extensible so that other kinds of policy clients may be supported in the future. However, this document makes no claims that it is the only or the preferred approach for enforcing future types of policies.

A. Smith, D. Partain and J. Seligson, "Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients," Internet Engineering Task Force, Jun. 2000.

Abstract: 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 a client of the Common Open Policy Service (COPS) protocol. This memo includes a MIB module in a manner that is compliant to the SNMPv2 SMI [V2SMI].

K. Chan and others, "The Policy Device Auxiliary MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 Policy Client devices, including the relationship between device interfaces and policy role combinations. Policy role combinations are used as part of the data model for policy information when a Policy Client is provisioned using the COPS protocol [COPS-PR] and a Policy Information Base (PIB) [FRAMEPIB].

S. Herzog, "Signaled Preemption Priority Policy Element," Internet Engineering Task Force, Mar. 1999.

Abstract: This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow.

S. Herzog, "Signaled Preemption Priority Policy Element," Internet Engineering Task Force, Jul. 2000.

Abstract: This document describes a preemption priority policy element for use by signaled policy based admission protocols (such as [RSVP] and [COPS]). Preemption priority defines a relative importance (rank) within the set of flows competing to be admitted into the network. Rather than admitting flows by order of arrival (First Come First Admitted) network nodes may consider priorities to preempt some previously admitted low priority flows in order to make room for a newer, high- priority flow. This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment error in RFC 2751.

J. Beck, "ResCap Requirements," Internet Engineering Task Force, Dec. 1999.

Abstract: A variety of resource identifiers have been widely deployed on the Internet as a means of identifying various resources, services, and destinations. However, a means of attaching a set of attributes or characteristics to a given resource identifier and subsequently assessing those attributes or characteristics has not been specified and deployed. Two tasks are envisioned. The first task will be to define a general resolution protocol that will translate resource identifiers to a list of attributes. The second task will be to define an administrative model and update protocol that can be used to set up and maintain the information the resolution protocol accesses. This document defines the requirements for these two protocols.

S. Waldbusser, "Application Performance Measurement MIB," Internet Engineering Task Force, Mar. 2000.

Abstract: 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 measuring the application performance as experienced by end- users.

S. Waldbusser, "Application Performance Measurement MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 measuring the application performance as experienced by end- users.

A. Bierman, C. Bucci, R. Dietz and A. Warth, "Remote Monitoring MIB Extensions for Identifying Application Protocol Verbs," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 protocol operations (verbs) within the protocol encapsulations managed with the Remote Network Monitoring MIB Version 2 [RFC2021].

A. Bierman, "Remote Monitoring MIB Extensions for Differentiated Services," Internet Engineering Task Force, Jun. 2000.

Abstract: 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 monitoring Differentiated Services Codepoint usage in IP packets, utilizing the monitoring framework defined in the RMON-2 MIB [RFC2021].

S. Waldbusser, "Remote Network Monitoring Management Information Base for High Capacity Networks," Internet Engineering Task Force, Jul. 1999.

Abstract: 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 for use on high speed networks. This memo does not specify a standard for the Internet community.

D. Romascanu, "Remote Monitoring MIB Extensions for Interface Parameters Monitoring," Internet Engineering Task Force, Oct. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The document proposes an extension to the Remote Monitoring MIB [RFC2819] with a method of sorting the interfaces of a monitored device according to values of parameters specific to this interface. Distribution of this memo is unlimited.

A. Bierman, "Performance Measurement Capabilities MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 classifying and characterizing the performance measurement (PM) capabilities of various standard and proprietary PM techniques.

S. Waldbusser, "Remote Network Monitoring Management Information Base," Internet Engineering Task Force, Jul. 1999.

Abstract: 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.

S. Waldbusser, "Remote Network Monitoring Management Information Base," Internet Engineering Task Force, Jan. 2000.

Abstract: 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. This memo obsoletes RFC 1757. This memo extends that specification by documenting the RMON MIB in SMIv2 format while remaining semantically identical to the existing SMIv1-based MIB.

S. Waldbusser, "Remote Network Monitoring Management Information Base," Internet Engineering Task Force, Jul. 1999.

Abstract: 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.

A. Bierman, C. Bucci and R. Iddon, "Remote Network Monitoring MIB Protocol Identifier Macros," Internet Engineering Task Force, Jun. 1999.

Abstract: This memo contains various protocol identifier examples, which can be used to produce valid protocolDirTable INDEX encodings, as defined by the Remote Network Monitoring MIB Version 2 [RFC2021] and the RMON Protocol Identifier Reference [RMONPROT_REF]. This document contains protocol identifier macros for well-known protocols. A conformant implementation of the RMON-2 MIB [RFC2021] can be accomplished without the use of these protocol identifiers, and accordingly, this document does not specify any IETF standard. It is published to encourage better interoperability between RMON-2 agent implementations, by providing a great deal of RMON related protocol information in one document. The first version of the RMON Protocol Identifiers Document [RFC2074] has been split into a standards-track Reference portion [RMONPROT_REF], and an 'RMON Protocol Identifier Macros' document (this document) which contains the non-normative portion of that specification.

R. Waterman, W. Lahaye, D. Romascanu and S. Waldbusser, "Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0," Internet Engineering Task Force, Feb. 1999.

Abstract: 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.

S. Waldbusser, "Token Ring Extensions to the Remote Network Monitoring MIB," Internet Engineering Task Force, Sep. 2000.

Abstract: 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 extensions to the Remote Network Monitoring MIB for managing 802.5 Token Ring networks.

R. Dietz, "Application Performance Measurement Framework Transport Performance Metrics MIB," Internet Engineering Task Force, Jul. 2000.

Abstract: This memo defines an experimental portion of the Management Informa- tion Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring selectable performance metrics and statistics derived from the monitoring of network packets and transport protocol states.

R. Kermode and L. Vicisano, "Author Guidelines for RMT Building Blocks and Protocol Instantiation documents," Internet Engineering Task Force, Jul. 2000.

Abstract: This document provides general guidelines to assist the authors of reliable multicast transport (RMT) building block and protocol instantiation definitions. The purpose of these guidelines is to ensure that any building block and protocol instantiation definitions produced contain sufficient information to fully explain their operation and use. If followed these guidelines will result in clearly defined RMT building blocks and protocol instantiation definitions that can be refined and augmented to create new protocols for use in new scenarios for which any existing protocols were not designed.

B. Cain, D. Chiu, M. Kadansky, S. Koh, B. Levine, G. Taskale and B. Whetten, "Reliable Multicast Transport Building Block: Tree Auto-Configuration," Internet Engineering Task Force, Jul. 2000.

Abstract: The Reliable Multicast Transport Working Group has been chartered to standardize multicast transport services. This working group expects to initially standardize three protocol instantiations. This draft is concerned with the requirements of the tree-based ACK protocol. In particular, it is concerned with defining the building block for auto-configuration of the logical ACK-tree. According to the charter, a building block is 'a coarse-grained modular component that is common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.' For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [WLKHFL00][HWKFV00].

B. Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd and M. Luby, "Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer," Internet Engineering Task Force, Oct. 2000.

Abstract: This document describes a framework for the standardization of bulk-data reliable multicast transport. It builds upon the experience gained during the deployment of several classes of contemporary reliable multicast transport, and attempts to pull out the commonalities between these classes of protocols into a number of building blocks. To that end, this document recommends that certain components that are common to multiple protocol classes be standardized as 'building blocks.' The remaining parts of the protocols, consisting of highly protocol specific, tightly intertwined functions, shall be designated as 'protocol cores.' Thus, each protocol can then be constructed by merging a 'protocol core' with a number of 'building blocks' which can be re-used across multiple protocols.

B. Cain, T. Speakman and D. Towsley, "Generic Router Assist (GRA) Building Block Motivation and Architecture," Internet Engineering Task Force, Mar. 2000.

Abstract: Generic Router Assist (GRA) is a network-based service that enables end-to-end multicast transport protocols to take advantage of infor- mation distributed across the network elements in a given multicast distribution tree. The service consists of a canonical set of simple functions which network elements may apply to selected packets in the transport session as they traverse the distribution tree. The choice of function and the packet parameters to which it is applied can be defined and customized for a given transport session in a highly con- trolled fashion that still permits enough flexibility for GRA to be used to address a wide range of multicast transport problems not amenable to end-to-end solution. This document provides the motiva- tion and an architecture for GRA.

B. Adamson, C. Bormann, S. Floyd, M. Handley and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Protocol Building Blocks," Internet Engineering Task Force, Aug. 2000.

Abstract: This memo describes issues related to the creation of negative- acknowledgment (NACK) oriented reliable multicast (NORM) protocols. The general goals and assumptions for NORM are defined. The tech- nical challenges related to NACK-oriented (and in some cases gen- eral) reliable multicast protocol design are identified. These challenges are resolved into a set of applicable 'building blocks' which are described in further detail. It is anticipated that these building blocks (as they are further refined and defined in future revisions of this document) will be useful in generating different instantiations of reliable multicast protocols.

B. Whetten, D. Chiu, S. Paul, M. Kadansky and G. Taskale, "TRACK ARCHITECTURE A SCALEABLE REAL-TIME RELIABLE MULTICAST PROTOCOL," Internet Engineering Task Force, Jul. 2000.

Abstract: One of the protocol instantiations the RMT WG is chartered to create is a TRee-based ACKnowledgement protocol (TRACK). Rather than create a set of monolithic protocol specifications, the RMT WG has chosen to break the reliable multicast protocols in to Building Blocks (BB) and Protocol Instantiations (PI). A Building Block is a specification of the algorithms of a single component, with an abstract interface to other BBs and PIs. A PI combines a set of BBs, adds in the additional required functionality not specified in any BB, and specifies the specific instantiation of the protocol. For more information, see the Reliable Multicast Transport Building Blocks and Reliable Multicast Design Space documents [2][3].

B. Aboba and D. Lidyard, "The Accounting Data Interchange Format (ADIF)," Internet Engineering Task Force, Apr. 2000.

Abstract: This document describes an extensible human-readable accounting record format, the Accounting Data Interchange Format (ADIF). Based on MIME, ADIF is designed to compactly represent accounting data from any protocol using attribute/value pairs or object identifiers. While in many cases Accounting Servers will produce ADIF records based on data from accounting protocols, it is also possible for devices to store data in ADIF format and transfer ADIF records to the accounting server. The latter approach has the advantage of offloading the Accounting Server from the task of transcribing interim or session records, thus improving scalability. This approach also enables the transport of data from multiple sources within the same set of records. Where a record format is employed that supports batching, the transport of multiple records within the same accounting packet is enabled.

G. Zorn, "An LDAP Schema for Phone Books," Internet Engineering Task Force, Mar. 1998.

Abstract: This document describes an LDAP schema for the attributes to be included in the standard phone book. Goals of this document include: - Creating a flexible, extensible and robust framework upon which to build a standard phone book - Promoting a standard phone book format, to enhance interoperability between ISPs and roaming consortia Non-goals of this document include: - Attempting to create a ''Swiss army knife'', with phone book attributes to please everyone on Earth - Definition of either server-server or client-server phone book update or transfer protocols

B. Aboba, "Roaming Support in Mobile IP," Internet Engineering Task Force, Jun. 1999.

Abstract: RFC 2002 describes the framework for Mobile IP, while RFC 2290 describes how a mobile node and a peer negotiate the appropriate use of Mobile IP over a PPP link. RFC 2477 describes the roaming architecture as well as criteria for evalution of roaming protocols, which include reconciliation between roaming and mobile IP.

D. Meyer, C. Alaettinoglu and D. Kessens, "Guidelines for Extending RPSL," Internet Engineering Task Force, Nov. 1997.

Abstract: This Internet Draft describes guidelines for extending the Routing Policy Specification Language (RPSL) [3, 4]. Our experiences with PRDB [2], RIPE-81 [6], and RIPE-181 [5] taught us that RPSL had to be extensible. These languages were not extensible and each transition to a new language turned out to be quite painful. As a result, extensibility was a primary design goal for RPSL. New routing protocols or new features to existing routing protocols can be easily handled using RPSL's dictionary class. New classes or new attributes to the existing classes can also be added.

E. Gerich, D. Karrenberg, D. Meyer, M. Terpstra, C. Villamizar, C. Alaettinoglu and T. Bates, "Routing Policy Specification Language (RPSL)," Internet Engineering Task Force, Nov. 1997.

Abstract: 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. RPSL is a replacement for the current Internet policy specification language known as RIPE-181 [4] or RFC-1786 [5]. RIPE-81 [6] was the first language deployed in the Internet for specifying routing policies. It was later replaced by RIPE-181 [4]. Through operational use of RIPE-181 it has become apparent that certain policies cannot be specified and a need for an enhanced and more generalized language is needed. RPSL addresses RIPE-181's limitations.

C. Alaettinoglu, C. Villamizar, E. Gerich, D. Kessens, D. Meyer, T. Bates, D. Karrenberg and M. Terpstra, "Routing Policy Specification Language (RPSL)," Internet Engineering Task Force, Apr. 1999.

Abstract: 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.

F. Baker, J. Krawczyk and A. Sastry, "RSVP Management Information Base," Internet Engineering Task Force, Aug. 1997.

Abstract: 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.}

F. Baker, J. Krawczyk and A. Sastry, "RSVP Management Information Base," Internet Engineering Task Force, Apr. 1998.

Abstract: 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.}

D. Zappala and J. Kann, "RSRR: A Routing Interface For RSVP," Internet Engineering Task Force, Jul. 1998.

Abstract: This memo describes version 2 of RSRR, a routing interface for RSVP. By using this interface, RSVP may obtain forwarding information from routers and use it to place reservation state within the network. Version 1 of this interface was designed primarily for RSVP interaction with IPv4 multicast routing protocols. Version 2 adds support for IPv4 unicast as well as IPv6 unicast and multicast routing. A backwards compatibility mechanism is provided.

F. Baker, J. Krawczyk and A. Sastry, "RSVP Management Information Base," Internet Engineering Task Force, Oct. 1997.

Abstract: 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.}

A. Arsenault and S. Farrell, "Securely Available Credentials - Requirements," Internet Engineering Task Force, Nov. 2000.

Abstract: This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols. This is the initial draft of the SACRED requirements specification and is therefore highly likely to change substantially. Discussion of this draft is taking place on the SACREDmailing list of the IETF SACRED working group (see http://www.imc.org/ietf-sacred for subscription information).

T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. Lehtinen, "SSH Protocol Architecture," Internet Engineering Task Force, May 2000.

Abstract: SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the architecture of the SSH protocol, and the notation and terminology used in SSH proto- col documents. It also discusses the SSH algorithm naming system that allows local extensions. The SSH protocol consists of three major com- ponents: Transport layer protocol provides server authentication, confi- dentiality, and integrity with perfect forward secrecy. User authentica- tion protocol authenticates the client to the server. Connection proto- col multiplexes the encrypted tunnel into several logical channels. Details of these protocols are described in separate documents.

T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne and S. Lehtinen, "SSH Connection Protocol," Internet Engineering Task Force, May 2000.

Abstract: SSH is a protocol for secure remote login and other secure network ser- vices over an insecure network. This document describes the SSH connec- tion protocol. It provides interactive login sessions, remote execution of commands, forwarded TCP/IP connections, and forwarded X11 connec- tions. All of these channels are multiplexed into a single encrypted tunnel. The SSH Connection Protocol has been designed to run on top of the SSH transport layer and user authentication protocols.

I. Rytina and L. Ong, "Framework for SIGTRAN Common Transport Protocol," Internet Engineering Task Force, Jul. 1999.

Abstract: This document outlines a framework for the Sigtran protocol that consists of a modular, extensible structure with a common reliable transport protocol used for all signaling transport. This structure initially allows for narrowband SCN signalling protocols to be transported over an IP network in order to support TDM to IP interworking of voice and data services, and allows the protocol to be extended for future use as required.

L. Ong, I. Rytina, M. Garcia, H. Schwarzbauer, L. Coene, H. Lin, I. Juhasz, M. Holdrege and C. Sharp, "Architectural Framework for Signaling Transport," Internet Engineering Task Force, Jun. 1999.

Abstract: This document defines an architecture framework and functional requirements for transport of signaling information over IP. The framework describes relationships between functional and physical entities exchanging signaling information, such as Signaling Gateways and Media Gateway Controllers. It identifies interfaces where signaling transport may be used and the functional and performance requirements that apply from existing Switched Circuit Network (SCN) signaling protocols.

T. Bova and T. Krivoruchka, "RELIABLE UDP PROTOCOL," Internet Engineering Task Force, Feb. 1999.

Abstract: This Internet Draft discusses Reliable UDP (RUDP). RUDP is a simple packet based transport protocol. RUDP is based on RFCs 1151 and 908 - Reliable Data Protocol. RUDP is layered on the UDP/IP Protocols and provides reliable in-order delivery (up to a maximum number of retransmissions) for virtual connections. RUDP has a very flexible design that would make it suitable for a variety of transport uses. One such use would be to transport telecommunication signaling protocols.

D. Auerbach, D. Berg and K. Morneault, "Session Manager," Internet Engineering Task Force, Feb. 1999.

Abstract: This Internet Draft discusses a protocol layer, Session Manager, that provides network redundancy and redundant Media Gateway Controller configurations for signaling protocol applications. Session Manager provides this support transparently. Network and Media Gateway Controller redundancy are important for providing highly reliable commercial applications that provide transportation of signaling protocols over packet networks.

D. Auerbach, D. Berg and K. Morneault, "SIGNALING BACKHAUL PROTOCOL," Internet Engineering Task Force, Feb. 1999.

Abstract: This Internet Draft discusses a framework for transporting signaling protocols (SS7, ISDN and DPNSS) over packet networks. The framework is referred to as signaling 'backhaul'. The backhaul takes place between a Media Gateway (MG) or Signaling Gateway (SG), which interfaces between the circuit world (PSTN) and the packet world (IP/ATM), and a Media Gateway Controller (MGC), which provides call processing. It is referred to as 'backhaul' because the gateway terminates the lower layers of the protocol (i.e. Layer 1 and 2) and backhauls the other layers to the MGC.

A. Johnston, S. Donovan, R. Sparks, C. Cunningham, D. Willis, J. Rosenberg, K. Summers and H. Schulzrinne, "SIP Telephony Call Flow Examples," Internet Engineering Task Force, Jul. 2000.

Abstract: This document gives examples of SIP (Session Initiation Protocol) call flows for IP telephony. Elements in these call flows include SIP User Agents and Clients, SIP Proxy and Redirect Servers, and Gateways to the PSTN (Public Switch Telephone Network). IP telephony scenarios include SIP Registration, SIP to SIP calling, SIP to Gateway, Gateway to SIP, and Gateway to Gateway via SIP. Call flow diagrams and message details are shown. PSTN telephony protocols are illustrated using ISDN (Integrated Services Digital Network), ANSI ISUP (ISDN User Part), and FGB (Feature Group B) circuit associated signaling. PSTN calls are illustrated using global telephone numbers from the PSTN and private extensions served on by a PBX (Private Branch Exchange). Example SIP messages used for testing during SIP 'bakeoff' events include SIP 'torture test' messages, and messages with invalid parameters, methods, and tags.

K. Lingle, J. Maeng and D. Walker, "Management Information Base for Session Initiation Protocol," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 set of managed objects that are used to manage Session Initiation Protocol(SIP) [17] devices, which include User Agent, Proxy server, Redirect server and Registrar.

P. Hoffman, "Examples of S/MIME Messages," Internet Engineering Task Force, Oct. 2000.

Abstract: This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at .}

R. Moore and B. Clouston, "Definitions of Managed Objects for APPN," Internet Engineering Task Force, Jul. 1998.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Networking) capabilities. This memo identifies managed objects for the APPN protocol.

B. Clouston and R. Moore, "Definitions of Managed Objects for APPN TRAPS," Internet Engineering Task Force, Sep. 1998.

Abstract: 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 receiving notifications from network devices with APPN (Advanced Peer-to-Peer Network) and DLUR (Dependent LU Requester) capabilities. This memo identifies notifications for the APPN and DLUR architecture. This memo does not specify a standard for the Internet community.

R. Moore and B. Clouston, "Definitions of Managed Objects for Extended Border Node," Internet Engineering Task Force, May 1998.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for monitoring and controlling network devices with APPN (Advanced Peer-to-Peer Network) EBN (Extended Border Node) capabilities. This memo identifies managed objects for the EBN architecture. This memo does not specify a standard for the Internet community.

B. Clouston and R. Moore, "Definitions of Managed Objects for APPN/HPR in IP Networks," Internet Engineering Task Force, Oct. 1998.

Abstract: 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 HPR (High Performance Routing) network devices which have the capability to communicate in IP (Internet Protocol) networks. This memo identifies managed objects for the HPR in IP network communications.

S. Waldbusser, J. Saperia and T. Hongal, "Policy Based Management MIB," Internet Engineering Task Force, Oct. 2000.

Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, this MIB defines objects that enable policy-based configuration management of SNMP infrastructures.

R. Presuhn, J. Case, K. McCloghrie, M. Rose and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol," Internet Engineering Task Force, Aug. 2000.

Abstract: This document defines the transport of SNMP messages over various protocols. This document obsoletes RFC 1906.

P. St. Pierre, "URLs for use with Service Location," Internet Engineering Task Force, Nov. 1997.

Abstract: This document defines the printer service type and the 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. The printer service type is designed as an abstract service type. It is expected that printers advertised with the printer type may be accessible by one or more protocols. IPP and lpr are a two examples of printing protocols that may be used to perform the actual printing function.

P. St. Pierre, S. Isaacson and I. McDonald, "Definition of the Printer Abstract Service Type v2.0," Internet Engineering Task Force, Mar. 2000.

Abstract: This document is a product of the Service Location and Internet Printing Protocol Working Groups of the Internet Engineering Task Force (IETF). Comments should be sent to the srvloc@srvloc.org and ipp@pwg.org mailing lists. This document defines the 'service:printer:' abstract type and the attributes associated with it. This 'service:printer:' template is designed to be used in conjunction with the Service Location Protocol, Version 2 (SLPv2) [13], but may be used with any directory service which supports attribute/value pair registration, such as the Lightweight Directory Access Protocol, Version 3 (LDAPv3 [16]). The 'service:printer:' type is specified as an abstract service type. Printers advertised with the 'service:printer:' abstract type may be accessible by one or more print protocols, such as IPP [3] and LPR [2].}

K. Kompella, "A Traffic Engineering MIB," Internet Engineering Task Force, Sep. 2000.

Abstract: 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 Traffic Engineered Tunnels, for example, Multi-Protocol Label Switched Paths ([1], [2]).

S. Farrell, "An Internet AttributeCertificate Profile for Authorization," Internet Engineering Task Force, Sep. 1998.

Abstract: Authorization support is required for various Internet protocols, for example, TLS, CMS and their consumers, and others. The X.509 AttributeCertificate provides a structure which can form the basis for such services [X.509]. This specification defines two profiles (a simple one and a 'full' one) for the use of X.509 AttributeCertificates to provide such authorization services.

D. Fowler, "Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type," Internet Engineering Task Force, Jul. 1998.

Abstract: 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, RFC XXXX [6], RFC XXXX [7] and RFC XXXX [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.

D. Fowler, "Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types," Internet Engineering Task Force, Feb. 1998.

Abstract: 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.

D. Fowler, "Definitions of Managed Objects for the DS3/E3 Interface Type," Internet Engineering Task Force, Feb. 1998.

Abstract: 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.

A. Tosaka and H. Izumiyama, "Dynamic Tunneling Path Configuration for Uni-directional Link Routing," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

W. Dabbous and E. Duros, "Supporting Unidirectional Paths in the Internet," Internet Engineering Task Force, Nov. 1997.

Abstract: Many distributed applications may benefit from a high bandwidth connection to the Internet. However, this requires high bandwidth links between remotes sites. A low-cost solution to deliver high bandwidth services over wide geographical areas via the use of broadcast satellite networks has been proposed by [ASBD]. However, this solution is based on low cost receivers with zero bandwidth return. Connection over the satellite link is therefore unidirectional. The integration of these satellite networks with the Internet requires changes in common routing protocols.

E. Duros, W. Dabbous, H. Izumiyama, N. Fujii and Y. Zhang, "A Link Layer Tunneling Mechanism for Unidirectional Links," Internet Engineering Task Force, Nov. 2000.

Abstract: This document describes a mechanism to emulate bidirectional connectivity between nodes that are directly connected by a unidirectional link. The 'receiver' uses a link layer tunneling mechanism to forward datagrams to 'feeds'over a separate bidirectional IP network. As it is implemented at the link layer, protocols in addition to IP may also be supported by this mechanism.

A. Kato, A. Tosaka and H. Izumiyama, "An IP tunneling approach for Uni-directional Link routing," Internet Engineering Task Force, Nov. 1997.

Abstract: 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.

C. Faerber, "Guidelines for the Generation of Message IDs and Similar Unique Identifiers," Internet Engineering Task Force, Sep. 1998.

Abstract: [RFC822] and [RFC1036] define so-called 'Message-IDs' that represent a unique identifier for email and netnews messages. A similar identifier is also used by [RFC2045] for the 'Content-ID' label. For each of these protocols, uniqueness of the identifiers generated is more or less essential. Unfortunately, the original Message-ID specification requires that the generator have an own, non-temporary full qualified domain name available, which does not allow hosts that are connected via dialup lines and get dynamically assigned IP addresses (and hostnames) to generate unique IDs offline. This memo provides recommendations for the generation of such IDs without risking non-uniqueness.

P. Higginson, B. Hinden, S. Knight, A. Lindem, D. Mitzel, M. Shand, D. Whipple, D. Weaver and P. Hunt, "Virtual Router Redundancy Protocol," Internet Engineering Task Force, Mar. 1998.

Abstract: This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

S. Knight, D. Weaver, D. Whipple, B. Hinden, D. Mitzel, P. Hunt, P. Higginson, M. Shand and A. Lindem, "Virtual Router Redundancy Protocol," Internet Engineering Task Force, Jan. 2000.

Abstract: This memo defines the Virtual Router Redundancy Protocol (VRRP). VRRP specifies an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The VRRP router controlling the IP address(es) associated with a virtual router is called the Master, and forwards packets sent to these IP addresses. The election process provides dynamic fail over in the forwarding responsibility should the Master become unavailable. This allows any of the virtual router IP addresses on the LAN to be used as the default first hop router by end-hosts. The advantage gained from using VRRP is a higher availability default path without requiring configuration of dynamic routing or router discovery protocols on every end-host.

I. Cooper, I. Melve and G. Tomlinson, "Internet Web Replication and Caching Taxonomy," Internet Engineering Task Force, Jul. 2000.

Abstract: This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed today. It introduces standard concepts and protocols used today within this application domain. Currently deployed solutions employing these technologies are presented to establish a standard taxonomy. Known problems with caching proxies are covered in an accompanying document[23], and are not part of this document. This document presents open protocols and points to published material for each protocol.

M. Hattig, "ZeroConf Requirements," Internet Engineering Task Force, Sep. 2000.

Abstract: Many common TCP/IP protocols such as DHCP [RFC 2131], DNS [RFC 1034, RFC 1035], MADCAP [RFC 2730], and LDAP [RFC 1487] must be configured and maintained by an administrative staff. This is unacceptable for emerging networks such as home networks, automobile networks, airplane networks, or adhoc networks at conferences, emergency relief stations, and many others. Such networks may be nothing more than two isolated laptop PCs connected via a wireless LAN. For all these networks, an administrative staff will not exist and the users of these networks neither have the time nor inclination to learn network administration skills. Instead, these networks need protocols that require zero user configuration and administration. This document is part of an effort to define such zero configuration (zeroconf) protocols.

J. Luciani, B. Rajagopalan, B. Cain, B. Jamoussi and D. Awduche, "IP over Optical Networks - A Framework," Internet Engineering Task Force, Mar. 2000.

Abstract: The Internet transport infrastructure is moving towards a model of high-speed routers interconnected by optical core networks. A consensus is emerging in the industry on utilizing IP-centric protocols for the optical control plane [9, 10], as well as for dynamic bandwidth provisioning for IP services. Also, there has recently been significant activity in defining models for IP transport over optical networks, specifically, the routing and signaling aspects [2,6,7]. This draft attempts to define a framework for IP over Optical networks, considering both the IP control plane for optical networks as well as IP transport over optical networks (together referred to as 'IP over optical networks'). Within this framework, we develop a common set of terms and concepts which allows to discuss these IP over optical technologies in a consistent fashion. Additionally, this draft surveys some architectural frameworks that might be useful and appropriate for the deployment of IP over hybrid optical networks that contain IP routers, WDM multiplexers, and optical cross-connects (OXCs). This document is complementary to the framework of Multiprotocol Lambda Switching proposed in [2].

S. Floyd, D. Black and K. Ramakrishnan, "IPsec Interactions with ECN," Internet Engineering Task Force, Apr. 1999.

Abstract: IPsec supports secure communication over potentially insecure network components such as intermediate routers. IPsec protocols support two operating modes, transport mode and tunnel mode. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that provides indication of onset of congestion to delay- or loss- sensitive applications. ECN provides the congestion indication so as to enable adaptation to network conditions without the impact of dropped packets [RFC 2481]. Currently, the way ECN is specified does not conform to the manner in which IPsec tunnels are defined to be used. This document considers issues related to interactions between ECN and IPsec tunnel mode, and proposes two alternative solutions.

J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA Authorization Framework," Internet Engineering Task Force, Apr. 2000.

Abstract: This memo serves as the base requirements for Authorization of Internet Resources and Services (AIRS). It presents an architectural framework for understanding the authorization of Internet resources and services and derives requirements for authorization protocols.

S. Farrell, J. Vollbrecht, P. Calhoun, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege and D. Spence, "AAA Authorization Requirements," Internet Engineering Task Force, Apr. 2000.

Abstract: This document specifies the requirements that AAA protocols must meet in order to support authorization services in the Internet. The requirements have been elicited from a study of a range of applications including mobile-IP, roamops and others.

F. Strauss, J. Schoenwaelder and K. McCloghrie, "SMIng - A new Structure of Management Information," Internet Engineering Task Force, Nov. 2000.

Abstract: This memo presents an object-oriented language for various kinds of management information specifications. It is independent of management protocols and applications. Protocol mappings are defined as extensions to this language in separate memos. However, the primarily targeted applications of this language are SNMP and COPS-PR in a way that this language can replace the SMIv2 and SPPI.

R. Canetti, P. Rohatgi and P. Cheng, "Multicast Data Security Transformations: Requirements, Considerations, and Proposed Design," Internet Engineering Task Force, Jul. 2000.

Abstract: In the framework document , the Secure Multicast Group (SMuG) has identified three functionalities that deal with security transformations for the multicasted data. These are data encryption, source authentication, and group authentication. This document expands on the issues to be taken into consideration when designing transforms that realize these functionalities. These issues include the order of applying the transforms, their placement in the communication layers, possible aggregation of several functionalities in a single transform, and the relationships with other protocols (such as reliable multicast protocols). Next a specific design is proposed, that attempts to meet the requirements of prominent application in a simple yet flexible way.

M. Baugher, T. Hardjono and B. Weis, "Group Domain of Interpretation for ISAKMP," Internet Engineering Task Force, Sep. 2000.

Abstract: This document presents an ISAKMP Domain of Interpretation (DOI) for secure group communications. The 'Group DOI,' or 'Group ISAKMP,' borrows definitions from GSAKMP [HH], incorporates the Phase 1 SA of the Internet DOI [RFC2407, RFC2409], and proposes new payloads and exchanges according to the ISAKMP standard [RFC2408, p.14]. Group ISAKMP manages group security associations, which are used by security protocols running at the IP [RFC2406] or application layers [AMESP]. These security associations protect one or more key-encrypting keys, traffic- encrypting keys, or data shared by group members. Comments on this draft document should be addressed to smug@cs.umass.edu.}

N. Yamanouchi, O. Takahashi and N. Ishikawa, "IGMP Extension for Authentication of IP Multicast Senders and Receivers," Internet Engineering Task Force, Aug. 1998.

Abstract: The security enhancement is one of the most important enhancements to IP multicast. IP multicast requires many security functions that include user authentication of IP multicast, encryption of IP multicast datagrams and key management protocols for IP multicast. Among them, the user authentication function for IP multicast is considered one of the most important security functions for IP multicast. This document describes the extension to IGMP, version 2 (IGMPv2) [1] for the authentication of IP multicast senders and receivers, which prevents an unauthorized user from sending and receiving IP multicast datagrams.

S. Bradner, "An agreement between the Internet Society, the IETF and Sun Microsystems, Inc. in the matter of NFS V.4 protocols," Internet Engineering Task Force, Mar. 1998.

Abstract: This Request for Comments records an agreement between Sun Microsystems, Inc. and the Internet Society to permit the flow of Sun's Network File System specifications into the Internet Standards process conducted by the Internet Engineering Task Force. Note: This RFC is NOT a standard. It is an official public record of an agreement between Sun Microsystems and the Internet Society. The referenced RFCs 1094 dated March 1989 (''NFS: Network File System Protocol Specification'') and 1813 dated June 1995 (''NFS Version 3 Protocol Specification'') are not attached to the document below, but are incorporated by reference.

F. Vakil, A. Dutta, J. Chen, S. Baba, Y. Shobatake and H. Schulzrinne, "Mobility Management in a SIP Environment Requirements, Functions and Issues," Internet Engineering Task Force, Apr. 2000.

Abstract: Mobility is rapidly becoming a rule rather than an exception in communication services and SIP is gaining widespread acceptance as the signaling protocol for multimedia applications on the Internet. Thus, it is essential to develop a mobility management scheme that utilizes salient features and capabilities of SIP as well as other protocols (e.g., mobile IP) to support mobile services efficiently. Without providing any specific solution, this document presents preliminary requirements and identifies the issues that need to be resolved in order to develop a mobility management scheme for supporting multimedia applications in a SIP signaling and control environment.

S. Jacobs and S. Corson, "MANET Authentication Architecture," Internet Engineering Task Force, Mar. 1999.

Abstract: The Internet MANET Encapsulation Protocol (IMEP) is designed to support the operation of many routing algorithms or other Upper Layer Protocols (ULP) in Mobile Ad hoc Networks (MANET). The MANET computing environment is very different from the ordinary computing environment in that these mobile computers will be connected to the network via wireless links. Such links are particularly vulnerable to eavesdropping, replay, spoofing, and other attacks. The use of IMEP results in a mobile node relying on other MANET nodes to perform routing operations on behalf of the transmitting node. This routing function constitutes a significant vulnerability if the IMEP management messages are not authenticated. The risk of attacks on MANET routing control messages necessitates a MANET Authentication Architecture to protect these messages in some networking contexts. Consequently all MANET nodes SHOULD be able to perform authentication. The MANET Authentication Architecture provides MANET routers with the ability to choose between multiple authentication options ranging from simple to complex, while leaving the option of no authentication in some contexts. IMEP messages between MANET routers are authenticated with the IMEP Authentication object. This document describes how MANET nodes using IMEP and desiring authentication SHOULD authenticate IMEP messages. Mechanisms described herein will allow these nodes to use either secret key type cryptosystems or public key type cryptosystems (with digital certificates and digital signatures) for authenticating IMEP management messages. The use of of secret key mechanisms will facilitate research and experimentation of MANET networks while the use of public key cryptosystems will allow MANET to scale to thousands of MANET mobile nodes.

R. Jain, T. Raleigh, M. Bereschinsky and C. Graff, "Mobile IP with Location Registers (MIP-LR)," Internet Engineering Task Force, Feb. 2000.

Abstract: This document is intended only to provide information to the Internet community. The Mobile IP (MIP) protocol for IP version 4 provides continuous Internet connectivity to mobile hosts, without requiring any changes to existing routers and higher-layer applications. This document describes an alternative protocol, Mobile IP with Location Registers (MIP-LR), where the sender first queries a database, called a Location Register, to obtain the recipients current location. MIP-LR is designed for operation in tactical military environments, enterprise environments or within logical administrative domains, as it requires a sending host to be aware which hosts implement the MIP-LR protocol. MIP-LR gives up the transparency of MIP for several benefits in the areas of survivability, performance and interoperability. MIP-LR improves survivability for situations where the mobile's home network is particularly vulnerable (e.g. in the forward area of a battlefield), by allowing location registers to be placed and replicated outside the home network. This document describes how replicated location registers can be managed by Translation Server or Quorum schemes. In terms of performance, MIP-LR avoids triangle routing and tunneling, and reduces the load on the home network as well as the home agents. MIP-LR provides improved interoperability with protocols such as RSVP for providing QoS guarantees. Finally, MIP-LR is interoperable with MIP, such that hosts which implement only MIP can continue to operate as expected (provided the provisions required by MIP, such as Home and Foreign Agents, are appropriately provided) without gaining any of the benefits of MIP-LR. We have developed a working version of the MIP-LR protocol running on Linux hosts.

N. Feldman, L. Andersson and B. Jamoussi, "MPLS Ships in the Night Operation with ATM," Internet Engineering Task Force, Aug. 1998.

Abstract: Multi-Protocol Label Switching (MPLS) can have several modes of operation over ATM. The MPLS Framework document [1] indicates that MPLS MUST allow 'ships in the night' (SIN) operation with existing L2 switching protocols (e.g., ATM Forum Signaling). This document identifies the technical requirements that have to be resolved in order to allow for a successful SIN operation between MPLS and ATM Forum protocol stack. Solutions to the various challenges are proposed.

S. Jedrysiak, "Definitions of Managed Objects for Spatial Reuse Protocol (SRP)," Internet Engineering Task Force, Apr. 2000.

Abstract: 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 networks using SRP interfaces.

T. Jenkins, "IPSec Re-keying Issues," Internet Engineering Task Force, May 2000.

Abstract: This document discusses issues associated with the use of protocols developed in the IETF's IPsec working group, specifically, RFC 2409 [IKE] and RFC 2408 [ISAKMP]. It is expected that the reader is familiar with those documents. As stated earlier, this document does not specify standards of any kind, and is intended as information for IPsec implementers.

M. Jibiki and A. Iwata, "Inter-Domain Multicast Forwarding (IDMF)," Internet Engineering Task Force, Mar. 2000.

Abstract: This draft proposes a new inter-domain multicast forwarding (IDMF) mechanism for PIM-SM multicast routing protocol. Although there have been various inter-domain multicast routing and forwarding protocols, they still have a limitation for handling policy routing, QoS routing, accounting and security, which network administrators are willing to use in their network. In order to solve this limitation, we propose a novel approach to create an inter-domain multicast forwarding tree (or routing table) among multiple PIM-SM domains with logical unicast paths over which multicast packets are forwarded or flooded. The logical unicast paths are created by either IP-in-IP tunneling method , IP masquerade-like method, and MPLS label switched path (LSP) method, which can easily reuse policy routing and QoS routing for unicast routing. These logical unicast paths are established among IDMF capable nodes or proxies, which are located within each PIM-SM domain, either manually or by a dynamic IDMP tree construction protocol. The IDMP capable nodes can also behave a proxy sender of multicast packets. It can prevent a multicast receiver from changing a RP-tree into a global SP-tree, and also can help to reduce virtually the number of multicast sources for a particular multicast group. This property can be effectively used for accounting, security and scalability enhancement required for interdomain communication. The proposed mechanism is a general framework for inter-domain multicast forwarding and can be also used as a MSDP based forwarding mechanism.

M. Jibiki and A. Iwata, "MSDP Specific Forwarding Extension for Inter-Domain Multicast Forwarding," Internet Engineering Task Force, Jul. 2000.

Abstract: This draft proposes a general inter-domain multicast forwarding (IDMF) mechanism for the PIM-SM multicast routing protocol and its application to the MSDP specific forwarding extension (MSDP-FE). Although there have been various inter-domain multicast routing and forwarding protocols, they are still limited in their capacity to handle policy routing, QoS routing, accounting and security, which network administrators are willing to use in their network. In order to overcome this limitation, we propose a novel approach to create an inter-domain multicast forwarding tree (or routing table) among multiple PIM-SM domains with logical multicast paths over which multicast packets are forwarded or flooded. The logical multicast paths are created by either the IP-in-IP tunneling method, the IP masquerade-like method, or the MPLS label switched path (LSP) method, which can easily reuse policy routing and QoS routing for unicast routing. These logical multicast paths are established among IDMF- capable nodes, which are located within each PIM-SM domain, either manually or by a dynamic IDMF tree construction protocol. This general framework for IDMF can be used as an MSDP based forwarding mechanism. Furthermore, the IDMF-capable nodes (i.e., MSDP-FE-capable nodes) can also function as a proxy sender of multicast packets. This can prevent a multicast receiver from changing an RP-tree into a global SP-tree, and also can help to reduce, on the surface, the number of multicast sources for a particular multicast group. This property can be effectively used for accounting, security, and scalability enhancement required for inter-domain communication.

A. Jinzaki and S. Kobayashi, "SOCKS64: An IPv4-IPv6 intercommunication gateway using SOCKS5 protocol," Internet Engineering Task Force, Nov. 1998.

Abstract: This memo describes an IPv4-IPv6 intercommunication method based on the SOCKS5 protocol. The method is called SOCKS64, and was first announced in the 40th IETF meeting at Washington DC in December 1997 as one of three translators being developed in the WIDE Project. SOCKS64 is a gateway system that accepts SOCKS5 connections from IPv4 hosts and relays it to IPv4/IPv6 hosts using proper protocols. We have designed and implemented a prototype SOCKS64 system and have been testing the prototype in many environments. Also we are distributing the prototype as a KAME distribution package. This article describes the SOCKS64; its principle, implementation, experimental results and comparison to other IPv4-IPv6 intercommunication methods.

T. Johnson and M. Yafchak, "The ViDe Reference Model for Internet-extensible H.323 Communications," Internet Engineering Task Force, Apr. 2000.

Abstract: This paper discusses H.323 communication as it is being developed and implemented within the context of today's Internet (I1 and I2). As such it suggests a model that the authors believe can be developed using current thinking, protocols, and practices. It is also intended to support a vision for future communication development that will allow multi-mode communication to become more universally useful for end-users while becoming more sophisticated and reliable in its technological foundation. The authors see the concepts emerging within and around the development of the H.323 standard as some of the most promising today for enabling Internet-extensible multi-mode global communication. After a brief presentation of a communication model, several problems and concerns with the present state of H.323 communication are presented along with specific recommendations for changes in these areas.

L. Jonsson, K. Svanbro and H. Hannu, "Profiles and Parameters in ROHC," Internet Engineering Task Force, Aug. 2000.

Abstract: The RObust Header Compression WG (ROHC) is developing compression schemes initially for IP/UDP/RTP header compression [ROHC]. The group is also chartered to develop compression for IP/TCP and after re- chartering it is possible (probable) that also compression of other protocols will follow. Compression and decompression must always follow well defined rules but there exist a number of variables that will affect details in the way compression should be carried out and how these rules are set. The purpose of this document is to identify such variables and outline a way to make ROHC both adaptable to various conditions and possible to extend for future needs.

F. Cuervo, B. Hill, N. Greene, C. Huitema, A. Rayhan, B. Rosen and J. Segers, "UTF-5, a transformation format of Unicode and ISO 10646 Author(s : J. Seng,M. Duerst, T. Tan," Internet Engineering Task Force, Jan. 2000.

Abstract: A new transformation format, called UTF-5 for Unicode is proposed. The resulting string of this UTF is within a [A-V][0-9] alphanumeric range. This enables legacy systems or protocols designed for alpha- numerical character set only to be multilingual enabled and inter- nationalized immediately. Example of such systems are the domain name system and email addresses.

M. Just, K. Leclair, J. Sermersheim and M. Smith, "LDAPv3 Result Codes: Definitions and Appropriate Use," Internet Engineering Task Force, Apr. 2000.

Abstract: The purpose of this document is to describe, in some detail, the meaning and use of the result codes used with the LDAPv3 protocol. Of particular importance are the error codes, which represent the majority of the result codes. This document provides definitions for each result code, and outlines the expected behaviour of the various operations with respect to how result codes and in particular, error conditions should be handled and which specific error code should be returned. The LDAPv3 RFC [RFC2251] states that 'An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.' The goal of this document is to transfer the applicable information from X.511 to this document, and expand upon it for LDAP.

M. Kadansky, D. Chiu, J. Wesley and J. Provino, "Tree-based Reliable Multicast (TRAM)," Internet Engineering Task Force, Jan. 2000.

Abstract: This paper describes TRAM, a scalable reliable multicast transport protocol. TRAM is designed to support bulk data transfer from a single sender to many receivers. A dynamically formed repair tree provides local error recovery allowing the multicast group to support a large number of receivers. TRAM provides flow control, congestion control, and other adaptive techniques necessary to operate efficiently with other protocols. Several bulk data applications have been implemented with TRAM. TRAM has been tested and simulated in a number of network environments. This update contains a new flow and congestion control section, an updated and expanded security section, updated packet formats to accommodate IPV6 addressing, and several other minor updates.

C. Kalbfleisch, R. Cole and D. Romascanu, "Definition of Managed Objects for Synthetic Sources for Performance Monitoring algorithms," Internet Engineering Task Force, Jul. 2000.

Abstract: 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 for configuring Synthetic Sources for Performance Monitoring algorithms (SSPM). This memo specifies a MIB module in a manner that is both compliant to the SMIv2, and semantically identical to the peer SMIv1 definitions.

C. Kaler, "Versioning Extensions to WebDAV," Internet Engineering Task Force, Aug. 1998.

Abstract: This document describes a set of methods, headers, and properties that extend the HTTP and WebDAV protocols to support versioning and variant authoring of Web resources. Operations are provided to perform both basic versioning and parallel versioning. This document is a stawman proposal and does not have the endorsement of the WebDAV working group authors.

R. Thayer and K. Kaukonen, "A Stream Cipher Encryption Algorithm 'Arcfour'," Internet Engineering Task Force, Jul. 1997.

Abstract: 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.

K. Chapman, "Textual Conventions for MIB Modules Using Performance History Based on 24 Hour Intervals," Internet Engineering Task Force, Jul. 1998.

Abstract: 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 tectual conventions used to define 24 hour inteval counters which supplement the interval counters defined in the 15 Minute Based Performance History TCs MIB [1]. See for example the DS1/E1, DS2/E2, DS3/E3 and SONET/SDH supplemental MIBs [2][3][4]. This MIB is designed to provide support for ASNI T1.231-1997 [6] 1-day registers.

K. Chapman, "Definitions of Supplemental Managed Objects for the SONET/SDH Interface Type," Internet Engineering Task Force, Jul. 1998.

Abstract: 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 supplemental objects used for managing SONET and SDH interfaces. This document is a companion document to the definitions of managed objects and supplemental managed objects for the DS1/E1, DS2/E2, DS3/E3 and SONET/SDH interface types: [1], [2], [3], [4] and [5]. This MIB is designed to provide support for ASNI T1.231- 1997 [6] standard information not already supported by . Support for this MIB is optional.

J. Kempf, "iSLP: Resource Discovery on the Internet with Service Location Protocol," Internet Engineering Task Force, Apr. 1999.

Abstract: The danger in defining a new protocol specifically for discovering resources on the Internet is that, like DNS, the protocol would probably be deployed internally as well. Developers would then have the opportunity to use the protocol to perform service discovery on the client side by downloading resources and inferencing over them rather than using protocols such as Service Location Protocol (SLP) or Lightweight Directory Access Protocol (LDAP) that inference on the server side. Besides the increased amount of network traffic involved in transferring attributes rather than the smaller query, every client would need to incorporate its own inferencing code. In this document, we discuss how the requirements for wide area resource discovery can be met by slightly modifying SLP to remove features more appropriate for internal networks and by establishing a few naming conventions. An added benefit of this design is that Internet clients can perform service discovery as well as simple resource discovery. It should be noted the proposals in this document are not meant to suggest that SLP is the only or even the best candidate for Internet resource discovery among existing protocols. The point of this paper is to emphasize the need for a concerted effort to make an existing discovery or directory services protocol fill the Internet resource discovery niche, rather than inventing yet another protocol offering discovery or directory services capabilites.

R. Kermode, "Scoped Address Discovery Protocol (SADP)," Internet Engineering Task Force, Nov. 1998.

Abstract: Administrative scoping [RFC2365] provide a useful means for limiting the spread of IP multicast traffic acros the Internet. Unlike Time- To-Live (TTL) scoping, administrative scoping provides the means to ensure that, for a given scope and ignoring packet loss, the same set of nodes will receive a message, regardless of which node sent the message. Thus, the use of administrative scoping greatly simplifies the design of multicast protocols that require localization, since the non-reception of sent packets is solely due to loss and not design. The Multicast Zone Announcement Protocol (MZAP) [MZAP] will provide applications with the means for discovering the various scopes that are locally visible at each point in the Internet. In addition, MZAP will also provide the means for determining and announcing which scope zones completely encapsulate others. This additional ability will allow scope zones to be arranged into hierarchies which applications can then used expanding zone searches instead of less efficient and more problematic expanding-ring (TTL) searches. One example of how expanding-zone searches provide increased localization can be found in the Scoped Hybrid Automatic Repear reQuest with Forward Error Correction (SHARQFEC) reliable multicast protocol [SHARQFEC].

D. Kessens, "RIDE functional requirements," Internet Engineering Task Force, Sep. 1997.

Abstract: This document describes the (functional) requirements for the RIDE format and protocols.

K. Khanna, "Flexible proxy of mail protocols," Internet Engineering Task Force, Sep. 2000.

Abstract: This document details the problem associated with the proxy of the mail protocols (SMTP, POP3 and IMAP), and suggests a means by which their proxy, by compliant proxy servers, can be made highly flexible, compared to how they are proxied today.

D. Kim, "Enhanced Communications Transport Service Definition," Internet Engineering Task Force, Jul. 1998.

Abstract: This memo is the final Committee Draft of the Enhanced Transport Service Definition under development within ISO/IEC JTC1/SC6/WG7 since last several years in order to provide to the upper-layer applications enhanced transport services over the current OSI transport service; major enhancements include multicast services and enhanced QoS. This memo is distributed to possibly interested grops within IETF, especially to experts in Transport Area, to make noticed the efforts being made within SC6 to come up with a new transport service definition meeting the wide range of requirements of the both current and future multimedia multicast applications. It is to be noted that a protocol maned ECTP(Enhanced Communications Transport Protocol) supporting this ECTS is also under development within SC6 and will be made public in the near future. Experts interested in this topic might compare the services defined by ECTS with those provided by more known protocols including RTP, MTP, RMP, and RAMP. The ultimate apparent objective of ECTS is the multimedia multicast transport service with varying degrees of reliability and multicast QoS.