DAEMON

 
Poster un nouveau sujet   Répondre au sujet    politikar Index du Forum -> politikar -> politikar
Sujet précédent :: Sujet suivant  
Auteur Message
MARIO KEKIC
Administrateur

Hors ligne

Inscrit le: 25 Mar 2009
Messages: 908
Localisation: PARIS
Masculin Bélier (21mar-19avr) 馬 Cheval
Point(s): 115
Moyenne de points: 0,13

MessagePosté le: Ven 16 Avr - 15:13 (2010)    Sujet du message: DAEMON Répondre en citant

[code:1:efa1c2914a] Current Internet-Drafts This summary sheet provides a short synopsis of each Internet-Draftavailable within the "internet-drafts" directory at the shadowsites directory. These drafts are listed alphabetically by workinggroup acronym and start date.Authentication, Authorization and Accounting (aaa)-------------------------------------------------- "Requirements for Internet-Scale Accounting Management", Jari Arkko, 01/19/2000, <draft-arkko-acctreqlis-00.txt> Over the years, as Internet services have evolved, sophisticated inter-domain applications such as roaming, voice over IP, Internet fax, and QoS provisioning have arisen. This document discusses whether accounting for these services services can be reliably and securely accomplished using established techniques, and explores the requirements for Internet-scale Accounting Management. "Criteria for Evaluating AAA Protocols for Network Access", Bernard Aboba, G Dommety, 08/25/2000, <draft-ietf-aaa-na-reqts-07.txt> 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. "Introduction to Accounting Management", Bernard Aboba, David Harrington, Jari Arkko, 06/22/2000, <draft-ietf-aaa-acct-06.txt> The field of Accounting Management is concerned with the collection of resource consumption data for the purposes of capacity and trend analysis, cost allocation, auditing, and billing. This document describes each of these problems, and discusses the issues involved in design of modern accounting systems. Since accounting applications do not have uniform security and reliability requirements, it is not possible to devise a single accounting protocol and set of security services that will meet all needs. Thus the goal of accounting management is to provide a set of tools that can be used to meet the requirements of each application. This document describes the currently available tools as well as the state of the art in accounting protocol design. A companion document, draft-ietf-aaa-accounting-attributes-03.txt, reviews the state of the art in accounting attributes and record formats. "Authentication, Authorization, and Accounting:Protocol Evaluation ", David Mitton, 07/24/2000, <draft-ietf-aaa-proto-eval-00.txt> 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. "AAA Problem Statements", Pat Calhoun, 10/19/2000, <draft-ietf-aaa-issues-00.txt> The AAA Evaluation Team's recommendation document raised some issues with the DIAMETER protocol. The AAA WG has created a design team to address these issues. This document is an attempt to describe the problems, which the WG can then concentrate on solving. Application Configuration Access Protocol (acap)------------------------------------------------ "ACAP Authorization Identifier Datasets Classes", Steve Hole, Alexey Melnikov, 05/01/2000, <draft-ietf-acap-authid-02.txt> Most distributed (client/server) applications require an authenti- cation process between the client and the server before the server will grant access to its managed resources. Many applications pro- vide varying levels of access to server resources based on a combi- nation of authentication credentials and access control rules. The collection of information used to control access to resources is called 'authorization information'. The authorization identifer datasets contain lists of users and groups of users that can be used by applications for authorization purposes. Access control mechanisms can be abstracted from under- lying authentication mechanisms and credential formats. They can be extended to include group memberships in dynamic calculations for access rights to resources or in definition of one time autho- rization certificates. The Application Configuration Access Protocol (ACAP) supports the remote storage and access of many types of structured configuration information. The authorization identifier datasets specification describes the 'userid' and 'groupid' datasets which contain the authorization information. It also describes ACAP server capabili- ties that advertise a server's support for authorization user and group semantics. "ACAP Application Options Dataset Class", Steve Hole, Alexey Melnikov, 05/01/2000, <draft-ietf-acap-option-03.txt> The Application Configuration Access Protocol (ACAP) is designed to support remote storage and access of application option, configuration and preference information. The generalized form of this runtime configuration is called ''options''. Options consist of any type of structured or unstructured data that an application requires to operate in a user specific manner. "ACAP Bookmarks Dataset Class", R Gellens, 07/20/2000, <draft-ietf-acap-book-04.txt> Storing URLs [URL] for later access has become common in Internet applications (for example, web browsers, FTP clients); these saved URLs have become known as bookmarks. It would be desirable to access one's bookmarks from multiple clients and multiple machines. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of bookmarks, providing for ease of coordination and synchronization of bookmarks between diverse applications and systems, as well as for hierarchy, inheritance, and sharing between users. This specification defines a standard ACAP dataset class for bookmarks. "ACAP Email Account Dataset Class", R Gellens, 02/28/2000, <draft-ietf-acap-email-03.txt> It has become common for Internet mail users to have more than one account where mail is received, to access multiple accounts from the same machine, to access the same accounts from different machines, and to use multiple programs which require email account configuration information. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of email account data. This specification defines a standard ACAP dataset class for email accounts, and a common option for indicating a default email account. "ACAP Email Personality Dataset Class", R Gellens, 02/28/2000, <draft-ietf-acap-pers-03.txt> It has become common for Internet mail users to receive and compose mail in the capacity of different roles or identities (for example, personal and work), to receive and compose mail at different machines, and to use multiple programs which require mail composition configuration information. These different roles or identities have become known as email personalities. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of email personality data. This specification defines a standard ACAP dataset class for email personalities, and a common option for indicating a default. ADSL MIB (adslmib)------------------ "Definitions of Extention Managed Objects for ADSL Lines", Faye Ly, Greg Bathrick, 06/09/2000, <draft-ietf-adslmib-adslext-05.txt> This document defines a standard SNMP MIB for additional functions not covered by the ADSL Line MIB [1]. "Definitions of Managed Objects for HDSL2 and SHDSL Lines", Bob Ray, Rajesh Abbi, 10/16/2000, <draft-ietf-adslmib-hdsl2-04.txt> 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. Authenticated Firewall Traversal (aft)-------------------------------------- "SOCKS Protocol Version 5", Marc VanHeyningen, 06/27/2000, <draft-ietf-aft-socks-pro-v5-05.txt> This document is a revision of RFC 1928, the SOCKS version 5 protocol. SOCKS is a generic proxying protocol for traversing firewalls and other trust boundaries; version 5 of the protocol adds new features such as authentication and UDP support. Changes from the RFC in this draft include formatting cleanups, authentication clarification, and fixing UDP-related problems found during implementation. AToM MIB (atommib)------------------ "Definitions of Managed Objects for SONET Linear APS Architectures", Jeff Johnson, Michael Thatcher, J Kuhfeld, 04/10/2000, <draft-ietf-atommib-sonetaps-mib-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing networks using SONET linear Automatic Protection Switching (APS) architectures. Audio/Video Transport (avt)--------------------------- "RTP Profile for Audio and Video Conferences with Minimal Control", Stephen Casner, H. Schulzrinne, 07/21/2000, <draft-ietf-avt-profile-new-09.txt> This memorandum is a revision of RFC 1890 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1890 are marked by change bars. This document describes a profile called 'RTP/AVP' for the use of the real-time transport protocol (RTP), version 2, and the associated control protocol, RTCP, within audio and video multiparticipant conferences with minimal control. It provides interpretations of generic fields within the RTP specification suitable for audio and video conferences. In particular, this document defines a set of default mappings from payload type numbers to encodings. This document also describes how audio and video data may be carried within RTP. It defines a set of standard encodings and their names when used within RTP. The descriptions provide pointers to reference implementations and the detailed standards. This document is meant as an aid for implementors of audio, video and other real-time multimedia applications. "RTP: A Transport Protocol for Real-Time Applications", V. Jacobson, Stephen Casner, R. Frederick, H. Schulzrinne, 07/21/2000, <draft-ietf-avt-rtp-new-08.txt,.ps> This memorandum is a revision of RFC 1889 in preparation for advancement from Proposed Standard to Draft Standard status. Readers are encouraged to use the PostScript form of this draft to see where changes from RFC 1889 are marked by change bars. This memorandum describes RTP, the real-time transport protocol. RTP provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. RTP does not address resource reservation and does not guarantee quality-of- service for real-time services. The data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery in a manner scalable to large multicast networks, and to provide minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "RTP Payload Format for MPEG-4 Streams", Stephen Casner, R. Civanlar, Colin Perkins, Andrea Basso, Carsten Herpel, 07/14/2000, <draft-ietf-avt-rtp-mpeg4-03.txt> This document describes a payload format for transporting MPEG-4 encoded data using RTP. MPEG-4 is a recent standard from ISO/IEC for the coding of natural and synthetic audio-visual data. Several services provided by RTP are beneficial for MPEG-4 encoded data transport over the Internet. Additionally, the use of RTP makes it possible to synchronize MPEG-4 data with other real-time data types. This specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force and ISO/IEC MPEG-4 ad hoc group on MPEG-4 over Internet. Comments are solicited and should be addressed to the working group's mailing list at rem-conf@es.net and/or the authors. "RTP Interoperability Statement", Colin Perkins, 08/11/2000, <draft-ietf-avt-rtp-interop-04.txt> It is required to demonstrate interoperability of RTP implementations in order to move the RTP specification to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. "RTP Payload Format for DV Format Video", Stephen Casner, Carsten Bormann, Katsushi Kobayashi, Akimichi Ogawa, 06/26/2000, <draft-ietf-avt-dv-video-03.txt> This document specifies the packetization scheme for encapsulating the compressed digital video data streams commonly known as 'DV' into a payload format for the Real-Time Transport Protocol (RTP). There are two kinds of DV, one for consumer use and the other for professional. The original 'DV' specification designed for consumer- use digital VCRs is approved as the IEC 61834 standard set. The specifications for professional DV are published as SMPTE 306M(D-7) and 314M(D-9). Both are based on consumer DV. The RTP payload format specified in this document supports IEC 61834 consumer DV and professional SMPTE 306M and 314M(DV-Based) formats. "RTP Testing Strategies", Jonathan Rosenberg, H. Schulzrinne, Colin Perkins, 07/13/2000, <draft-ietf-avt-rtptest-03.txt> This memo describes a possible testing strategy for RTP implementations. It is intended as an aid to implementors and does not specify a standard of any kind. "MIME Type Registration of RTP Payload Formats", Stephen Casner, Philipp Hoschka, 07/21/2000, <draft-ietf-avt-rtp-mime-03.txt> This document defines the procedure to register RTP Payload Formats as audio, video or other MIME subtype names. This is useful in a text-based format or control protocol to identify the type of an RTP transmission. This document also registers all the RTP payload formats defined in the RTP Profile for Audio and Video Conferences as MIME subtypes. Some of these may also be used for transfer modes other than RTP. "SDP Bandwidth Modifiers for RTCP Bandwidth", Stephen Casner, 03/13/2000, <draft-ietf-avt-rtcp-bw-01.txt> This document defines an extension to the Session Description Pro- tocol (SDP) to specify two additional modifiers for the bandwidth attribute. These modifiers may be used to specify the bandwidth allowed for RTCP packets in a Real-Time Transport Protocol (RTP) session. "RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio", Stephen Casner, Carsten Bormann, Katsushi Kobayashi, Akimichi Ogawa, 06/26/2000, <draft-ietf-avt-dv-audio-02.txt> This document specifies the packetization scheme for encapsulating the 12-bit nonlinear, 20-bit linear and 24-bit linear audio data streams into a payload of the Real-time Transport Protocol (RTP). This draft also specifies the way of SDP announcement, when the audio data is preemphasized before sampling. The treatment of preemphasized audio data specified this document could be used in other audio formats such as L16. "A More Loss-Tolerant RTP Payload Format for MP3 Audio", Ross Finlayson, 08/07/2000, <draft-ietf-avt-rtp-mp3-03.txt> While the RTP payload format defined in RFC 2250 is generally applicable to all forms of MPEG audio or video, it is less suitable for MPEG 1 or 2, layer III audio (commonly known as 'MP3'). The reason for this is that an MP3 frame is not a true 'Application Data Unit' - it contains a back-pointer to data in earlier frames, and so cannot be decoded independently of these earlier frames. Because RFC 2250 defines that packet boundaries coincide with frame boundaries, it handles packet loss inefficiently when carrying MP3 data. The loss of an MP3 frame will render some data in previous (or future) frames useless, even if they are received without loss. In this document we define an alternative RTP payload format for MP3 audio. This format uses a data-preserving rearrangement of the original MPEG frames, so that packet boundaries now coincide with true MP3 'Application Data Units', which can also (optionally) be rearranged in an interleaving pattern. This new format is therefore more data-efficient than RFC 2250 in the face of packet loss. "RTP Audio/Video Profile Interoperability Statement", Colin Perkins, 08/11/2000, <draft-ietf-avt-profile-interop-02.txt> It is required to demonstrate interoperability of implementations in order to move the RTP audio/video profile to draft standard. This memo outlines those features to be tested, as the first stage of an interoperability statement. "Registration of parityfec MIME types", Jonathan Rosenberg, H. Schulzrinne, 03/13/2000, <draft-ietf-avt-fecmime-01.txt> The RTP payload format for generic forward error correction allows RTP participants to improve loss resiliency through the use of traditional parity based channel codes. This payload format requires four new MIME types, audio/parityfec, video/parityfec, text/parityfec and application/parityfec. This document serves as the MIME type registration for those formats. "RTP payload format for MPEG-4 Audio/Visual streams", Yoshimitsu Kikuchi, T Nomura, S Fukunaga, Y Matsui, H Kimata, 10/12/2000, <draft-ietf-avt-rtp-mpeg4-es-05.txt> This document describes RTP payload formats for carrying each of MPEG-4 Audio and MPEG-4 Visual bitstreams without using MPEG-4 Systems. For the purpose of directly mapping MPEG-4 Audio/Visual bitstreams onto RTP packets, it provides specifications for the use of RTP header fields and also specifies fragmentation rules. It also provides specifications for MIME type registrations and the use of SDP. "RTP Payload for Comfort Noise ", Robert Zopf, 03/08/2000, <draft-ietf-avt-rtp-cn-00.txt> This document describes an RTP [2] payload format for transporting comfort noise (CN). The CN payload type is primarily for use with audio codecs that do not support comfort noise as part of the codec itself such as ITU-T Recommendations G.711 [3], G.726 [4], G.727 [5], G.728 [6], and G.722 [7]. "RTP Payload Format for MPEG-4 with Flexible Error Resiliency ", Paul Christ, Anders Klemets, Christine Guillemot, Stefan Wesner, 03/13/2000, <draft-ietf-avt-mpeg4streams-00.txt> This document describes a payload format, which can be used for the transport of both MPEG-4 Elementary Streams (ES), i.e audio, visual, BIFS and OD streams and MPEG-4 Sync Layer and Flexmux packet streams, in RTP [1] packets. The payload format allows for protec- tion against loss in a generic way. The mechanisms proposed can op- erate both on full and partial MPEG-4 ES Access Units, on Sync Layer packets, or Flexmux packets. These mechanisms can cover a broad range of protection schemes and avoid extra connection management complexity - e.g. for separate FEC channels - in MPEG-4 applications with a potentially high number of streams. "Extension of RTP payload Type for Multiple Program MPEG Transport Stream", Hong Liu, 03/13/2000, <draft-ietf-avt-rtp-mp2t-00.txt> This document is to define a dynamic payload type that extends the payload type of 33, defined in RFC1890 [4] for MPEG2 transport streams. The usage of payload type of 33 is defined in RFC2250 [1]. This purpose of this extension is to enhance the RTP protocol in such way that it can be used to deliver multiple program MPEG transport stream as well. "Tunneling multiplexed Compressed RTP ('TCRTP')", Dan Wing, B Thompson, Tmima Koren, 07/18/2000, <draft-ietf-avt-tcrtp-01.txt> 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. "RTP Payload Format for ITU-T Recommendation G.722.1", Patrick Luthi, 08/11/2000, <draft-ietf-avt-rtp-g7221-01.txt> ITU-T Recommendation G.722.1 [2] is a wide-band audio codec, which operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet [3]. Also included here are the necessary details for the use of G.722.1 with MIME [4] and SDP [5]. "RTP Payload Format for SMPTE 292M", Ladan Gharai, David Richardson, Gary Goncher, 07/14/2000, <draft-ietf-avt-smpte292-video-00.txt> This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 292M [1] into a payload format for the Real-Time Transport Protocol (RTP). The RTP packet counter is extended to 26 bits to accommodate SMPTE 292M's 1.485Gb/s data rate, and additional positioning information is added to the payload header. "Enhancements to IP/UDP/RTP Header Compression", Stephen Casner, A. Tweedly, Dan Wing, P Ruddy, B Thompson, Tmima Koren, John Geevarghese, 07/18/2000, <draft-ietf-avt-crtp-enhance-00.txt> This document describes enhancements to CRTP, the header compression algorithm for RTP streams described in [RFC2508]. Each enhancement addresses issues with RFC2508 in different deployment scenarios. Each section below provides a description of the proposed enhancement, the scenario where it is useful and the justification for its use. Each of these enhancements could be evaluated separately. The enhancements are applicable both for IPv4 and IPv6. The IPCP option 'IP header compression' (described in RFC2509) is also extended to negotiate using the CRTP enhancements. "RTP Profile for RTCP-based Retransmission Request for Unicast session. ", S. McCanne, Matthew Podolsky, Koichi Yano, 07/19/2000, <draft-ietf-avt-rtprx-00.txt> This document specifies a new RTP profile for retransmission of lost packets of unicast multimedia sessions. We refer to this profile as 'RTP/AVP-RX'. This profile follows RFC 1889 as it is for data exchange. Specifically for unicast session, it changes the RTCP interval and defines a new RTCP packet type for retransmission requests. This document also describes how retransmission requests and retransmission data may be sent within RTP. "RTP payload format for AMR", Petri Koskelainen, Magnus Westerlund, Ari Lakaniemi, Johan Sjoberg, B Wimmer, Tim Fingscheidt, 10/04/2000, <draft-ietf-avt-rtp-amr-01.txt> This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. Blocks Extensible Exchange Protocol (beep)------------------------------------------ "The Blocks eXtensible eXchange Protocol Framework", Marshall Rose, 10/16/2000, <draft-ietf-beep-framework-05.txt> This memo describes a generic application protocol framework for connection-oriented, asynchronous interactions. The framework permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages "Mapping the BXXP Framework onto TCP", Marshall Rose, 10/11/2000, <draft-ietf-beep-tcpmapping-04.txt> This memo describes how a BXXP session is mapped onto a single TCP connection. Border Gateway Multicast Protocol (bgmp)---------------------------------------- "Border Gateway Multicast Protocol (BGMP): Protocol Specification", Deborah Estrin, David Meyer, Dave Thaler, 03/15/2000, <draft-ietf-bgmp-spec-01.txt> This document describes BGMP, a protocol for inter-domain multicast routing. BGMP builds shared trees for active multicast groups, and allows receiver domains to build source-specific, inter-domain, distribution branches where needed. Building upon concepts from CBT and PIM-SM, BGMP requires that each multicast group be associated with a single root (in BGMP it is referred to as the root domain). BGMP assumes that at any point in time, different ranges of the class D space are associated (e.g., with MASC [MASC]) with different domains. Each of these domains then becomes the root of the shared domain-trees for all groups in its range. Multicast participants will generally receive better multicast service if the session initiator's address allocator selects addresses from its own domain's part of the space, thereby causing the root domain to be local to at least one of the session participants. Benchmarking Methodology (bmwg)------------------------------- "Terminology for Frame Relay Benchmarking", Cynthia Martin, Jeffrey Dunn, 07/17/2000, <draft-ietf-bmwg-fr-term-04.txt> This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of frame relay switching devices. The terms defined in this memo will be used in addition to terms defined in RFCs 1242, 1944 and 2285. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force(IETF). "Methodology for IP Multicast Benchmarking", Debra Stopp, Hardev Soor, Ralph Daniels, 07/10/2000, <draft-ietf-bmwg-mcastm-04.txt> The purpose of this draft is to describe methodology specific to the benchmarking of multicast IP forwarding devices. It builds upon the tenets set forth in RFC 2544, RFC 2432 and other IETF Benchmarking Methodology Working Group (BMWG) efforts. This document seeks to extend these efforts to the multicast paradigm. The BMWG produces two major classes of documents: Benchmarking Terminology documents and Benchmarking Methodology documents. The Terminology documents present the benchmarks and other related terms. The Methodology documents define the procedures required to collect the benchmarks cited in the corresponding Terminology documents. "Methodology for ATM Benchmarking", Cynthia Martin, Jeffrey Dunn, 07/17/2000, <draft-ietf-bmwg-atm-method-02.txt> This document discusses and defines a number of tests that may be used to describe the performance characteristics of ATM based switching devices. In addition to defining the tests this document also describes specific formats for reporting the results of the tests. Appendix A lists the tests and conditions that we believe should be included for specific cases and gives additional information about testing practices. This memo is a product of the Benchmarking Methodology Working Group (BMWG) of the Internet Engineering Task Force (IETF). "Terminology for ATM ABR Benchmarking", Cynthia Martin, Jeffrey Dunn, 07/17/2000, <draft-ietf-bmwg-atm-term-abr-02.txt> This memo discusses and defines terms associated with performance benchmarking tests and the results of these tests in the context of Asynchronous Transfer Mode (ATM) based switching devices supporting ABR. 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). "Terminology for Forwarding Information Base (FIB) based Router Performance Benchmarking", Guy Trotter, 07/10/2000, <draft-ietf-bmwg-fib-term-00.txt> This document defines terms that are to be used in a methodology that determines the IP packet forwarding performance of IP routers as a function of the forwarding information base installed within the router. The objective of this methodology is to evaluate the performance levels of IP routers as forwarding information bases continue to grow in size and complexity of structure. This methodology utilizes the packet forwarding performance measurements described in [2]; reference will also be made to the associated terminology document [3] for these terms. "Framework for Router Benchmarking", Cynthia Martin, Jeffrey Dunn, 07/17/2000, <draft-ietf-bmwg-rtr-framework-00.txt> 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). "Benchmarking Methodology for Firewalls", T Martin, B Hickman, 07/20/2000, <draft-ietf-bmwg-firewall-00.txt> This document is intended to provide methodology for the benchmarking of firewalls. It provides methodologies for benchmarking forwarding performance, connection performance, latency and filtering. In addition to defining the tests, this document also describes specific formats for reporting the results of the tests. A previous document, 'Benchmarking Terminology for Firewall Performance' [1], defines many of the terms that are used in this document. The terminology document SHOULD be consulted before attempting to make use of this document. Calendaring and Scheduling (calsch)----------------------------------- "Calendar Access Protocol (CAP)", Paul Hill, F. Dawson, S. Mansour, Doug Royer, Alexander Taler, 03/14/2000, <draft-ietf-calsch-cap-02.txt> The Calendar Access Protocol (CAP)is an Internet protocol that permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an [RFC2445] based Calendar Store (CS). This memo defines the CAP specification. "Implementors' Guide to Internet Calendaring", Bob Mahoney, Alexander Taler, George Babics, 07/14/2000, <draft-ietf-calsch-imp-guide-01.txt> 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. Common Authentication Technology (cat)-------------------------------------- "Access Control Framework for Distributed Applications", Clifford Neuman, T. Ryutov, 07/21/2000, <draft-ietf-cat-acc-cntrl-frmw-04.txt> This document describes a unified model to support authorization in a wide range of applications, including metacomputing, remote printing, video conference, and any other application which will require interactions between entities across autonomous security domains. "Generic Authorization and Access control Application Program Interface C-bindings", Clifford Neuman, T. Ryutov, 07/22/2000, <draft-ietf-cat-gaa-cbind-04.txt> The Generic Authorization and Access control Application Programming Interface (GAA API) provides access control services to calling applications. It facilitates access control decisions for applications and allows applications to discover access control policies associated with a targeted resource. The GAA API is usable by multiple applications supporting different kinds of protected objects. The GAA API design supports: - a variety of security mechanisms based on public or secret key cryptosystems - different authorization models - heterogeneous security policies - various access rights This document specifies C language bindings for the GAA API, which is described at a language-independent conceptual level in draft-ietf-cat-acc-cntrl-frmw-01.txt "SASL GSSAPI mechanisms", J Myers, 09/12/2000, <draft-ietf-cat-sasl-gssapi-02.txt> 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. "The Secure Remote Password GSS-API Mechanism (SRPGM)", Keith Burdis, 01/14/2000, <draft-ietf-cat-srpgm-02.txt> This document describes a password-based low-infrastructure GSS-API mechanism based on the Secure Remote Password protocol (SRP) and the existing Simple Public Key Mechanism (SPKM). This mechanism is suitable for establishing a secure context between two entities that have established a shared secret as per the SRP protocol. Common Name Resolution Protocol (cnrp)-------------------------------------- "CNRP PROTOCOL SPECIFICATION", Michael Mealling, Nicolas Popp, Marshall Moseley, 10/17/2000, <draft-ietf-cnrp-06.txt> People often refer to things in the real world by a common name or phrase, e.g., a trade name, company name, or a book title. These names are sometimes easier for people to remember and type than URLs. Furthermore, because of the limited syntax of URLs, companies and individuals are finding that the ones that might be most reasonable for their resources are being used elsewhere and so are unavailable. For the purposes of this document, a 'common name' is a word or a phrase, without imposed syntactic structure, that may be associated with a resource. "The 'go'URI Scheme for the Common Name Resolution Protocol", Michael Mealling, 10/17/2000, <draft-ietf-cnrp-uri-04.txt> This document defines a URI scheme, 'go:' to be used with the Common Name Resolution Protocol. Specifically it lays out the syntactic components and how those components are used by URI Resolution to find the available transports for a CNRP service. Care should be taken with several of the URI components because, while they may look like components found in other URI schemes, they often do not act like them. The 'go'scheme has more in common with the location independent 'news' scheme than any other URI scheme. Web Versioning and Configuration Management (deltav)---------------------------------------------------- "Versioning Extensions to WebDAV", Jim Whitehead, Christopher Kaler, Geoffrey Clemm, Jim Amsden, 10/06/2000, <draft-ietf-deltav-versioning-10.txt> This document specifies a set of methods, headers, and resource-types that define the WebDAV Versioning extensions to the HTTP/1.1 protocol. WebDAV Versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV Versioning includes: - core versioning with automatic versioning for versioning-unaware clients, - workspace, activity and baseline management, - URL namespace versioning. Dynamic Host Configuration (dhc)-------------------------------- "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", C Perkins, Jim Bound, M. Carney, 05/08/2000, <draft-ietf-dhc-dhcpv6-15.txt> The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters using extensions to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [15], and can be used separately or concurrently with the latter to obtain configuration parameters. "Interaction between DHCP and DNS", Y Rekhter, Mark Stapp, 03/16/2000, <draft-ietf-dhc-dhcp-dns-12.txt> DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies how DHCP clients and servers should use the Dynamic DNS Updates mechanism in [RFC2136] to update the DNS name to address and address to name mappings so that the mappings for DHCP clients will be consistent with the IP addresses that the clients acquire via DHCP. "Authentication for DHCP Messages", Ralph Droms, William Arbaugh, 07/06/2000, <draft-ietf-dhc-authentication-14.txt> The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. In some situations, network administrators may wish to constrain the allocation of addresses to authorized hosts. Additionally, some network administrators may wish to provide for authentication of the source and contents of DHCP messages. This document defines a new DHCP option through which authorization tickets can be easily generated and newly attached hosts with proper authorization can be automatically configured from an authenticated DHCP server. "Extensions for the Dynamic Host Configuration Protocol for IPv6", C Perkins, Jim Bound, M. Carney, 05/08/2000, <draft-ietf-dhc-dhcpv6exts-12.txt> The Dynamic Host Configuration Protocol for IPv6 [4] (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the 'extensions' field of the DHCP message. The data items themselves are also called 'extensions.' This document specifies the initial set of DHCP extensions, which will be periodically updated as new extensions are defined until this document reaches proposed standard. "The User Class Option for DHCP", Ralph Droms, Ann Demirtjis, G. Stump, Ye Gu, Burcak Beser, Ramesh Vyaghrapuri, Jerome Privat, 08/21/2000, <draft-ietf-dhc-userclass-10.txt> This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. "DHCP Relay Agent Information Option", M. Patrick, 10/11/2000, <draft-ietf-dhc-agent-options-12.txt> Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. "DHCP Failover Protocol", Ralph Droms, Bernard Volz, K. Kinnear, Arun Kapur, Mark Stapp, Greg Rabil, Mike Dooley, Steve Gonczi, 07/20/2000, <draft-ietf-dhc-failover-07.txt> DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. This document is a substantial reorganization as well as a technical and editorial revision of draft-ietf-dhc-failover-05.txt. "DHCP Continuation Option Code", Angelos Keromytis, William Arbaugh, 01/04/2000, <draft-ietf-dhc-options-cont-01.txt> The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Currently options are limited to an information size of 256 bytes because of the one-octet size of the length field. This document defines a new option that permits the continuation of the previous option information. "DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients", Ryan Troll, 02/23/1999, <draft-ietf-dhc-autoconfig-04.txt> Operating Systems are now attempting to support ad-hoc networks of two or more systems, while keeping user configuration at a minimum. To accommodate this, in the absence of a central configuration mechanism (DHCP), some OS's are automatically choosing a link-local IP address which will allow them to communicate only with other hosts on the same link. This address will not allow the OS to communicate with anything beyond a router. However, some sites depend on the fact that a host with no DHCP response will have no IP address. This document describes a mechanism by which DHCP servers are able to tell clients that they do not have an IP address to offer, and that the client should not generate an IP address it's own. "Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network", Ryan Troll, 03/14/2000, <draft-ietf-dhc-ipv4-autoconfig-05.txt> With operating systems appearing in more and more devices, as well as computers appearing in more and more aspects of everyday life, communication between networked devices is increasingly important. The communication mechanism between these devices must be able to not only support the office LAN environment, but must also scale to larger WANS and the internet. This draft describes a method by which a host may automatically give itself a link-local IPv4 address, so that it will be able to use IP applications in the absence of an IP address management mechanism, such as DHCP. This mechanism is in use today by a few operating systems, and additional information on those implementations is also provided. "The Subnet Selection Option for DHCP", G. Waters, 09/11/2000, <draft-ietf-dhc-subnet-option-07.txt> This memo defines a new DHCP option for selecting the subnet on which to allocate an address. This option would override a DHCP server's normal methods of selecting the subnet on which to allocate an address for a client. "New Option Review Guidelines and Additional Option Namespace", M. Carney, 03/16/2000, <draft-ietf-dhc-option-review-and-namespace-02.txt> This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. "DHCP Schema for LDAP", A. Wayne Bennett, Bernard Volz, 03/10/2000, <draft-ietf-dhc-schema-02.txt> This document presents an LDAP schema to represent the configuration of the DHCP protocol within a TCP/IP network. It can be used to represent the configuration(s) of an entire enterprise network, a subset of the network, or even a single server "DHC load balancing algorithm", Bernard Volz, Rick Stevens, Ted Lemon, Steve Gonczi, 07/14/2000, <draft-ietf-dhc-loadb-02.txt> This draft proposes a method of algorithmic load balancing. It enables multiple, cooperating servers to decide which one should service a client, without exchanging any information beyond initial configuration. The server selection is based on the servers hashing client MAC addresses, when multiple DHCP servers are available to service DHCP clients. The benefits are similar to those enumerated in [SSO-03], but this draft does not require modifications to existing DHCP clients. The same method is proposed to select the target server of a forwarding agent such as a BOOTP relay. "DHCP Next Server Option", Michael Borella, Jerome Privat, 03/14/2000, <draft-ietf-dhc-nextserver-02.txt> This proposal allows host configuration to be split between two different address servers, potentially under different administration. This ability may be useful to satisfy specific regulatory, operational or business model requirements, as well as to provide support for secondary address servers. This draft proposes a new DHCP option called the DHCP Next Server option. A DHCP server can use this option to redirect clients to a secondary server. "The Classless Static Route Option for DHCP", Ted Lemon, 06/20/2000, <draft-ietf-dhc-csr-02.txt> This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure a list of static routes in the client. This option supersedes the Static Route option (option 33) defined in [2]. "Dynamic host configuration : DHCP reconfigure extension", Yves T''''Joens, Peter De Schrijver, Christian Hublet, 06/20/2000, <draft-ietf-dhc-pv4-reconfigure-01.txt> This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address). This is achieved by introducing a unicast DHCP FORCERENEW message which forces the client to the RENEW state. "Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP", Anthony McAuley, Y. Shobatake, S Das, S Baba, 03/10/2000, <draft-ietf-dhc-aaa-requirements-00.txt> The AAA working group is currently defining the requirements for Authentication, Authorization, and Accounting (AAA). This draft lists the AAA requirements to aid roaming nodes using a dynamic address configuration protocol such as DHCP. The node may or may not be using Mobile IP [3] (with co-located care-of-address) or other dynamic address binding protocol. "Requirements for Extending DHCP into New Environments", Anthony McAuley, Y. Shobatake, S Das, S Baba, 03/10/2000, <draft-ietf-dhc-enhance-requirements-00.txt> 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. "DHCP Option for PacketCable VoIP Client Configuration", Burcak Beser, 03/13/2000, <draft-ietf-dhc-packetcable-00.txt> The Voice over IP work carried over in the PacketCable project conducted by CableLabs. The configuration of the PacketCable Voice over IP client is achieved using DHCP messaging. This document contains the definition of PacketCable VoIP Client configuration option. "The DHCP Client FQDN Option", Y Rekhter, Mark Stapp, 07/21/2000, <draft-ietf-dhc-fqdn-option-00.txt> DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, or 'FQDN'. "Resolution of DNS Name Conflicts Among DHCP Clients", Mark Stapp, 07/24/2000, <draft-ietf-dhc-ddns-resolution-00.txt> DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. "New Option Review Guidelines for DHCP", M. Carney, 07/25/2000, <draft-ietf-dhc-new-opt-review-00.txt> This document outlines deficiencies that have become evident since RFC 2131 and RFC 2132 were published regarding the allocation of new option codes, the review of drafts covering these new option codes, and the availability of option codes for new parameters. The document then presents proposals for correcting these deficiencies. Differentiated Services (diffserv)---------------------------------- "A Conceptual Model for Diffserv Routers", Daniel Grossman, Andrew Smith, S. Blake, Y. Bernet, 07/19/2000, <draft-ietf-diffserv-model-04.txt> This memo proposes an informal management model of Differentiated Services (Diffserv) routers for use in their management and configuration. This model defines functional datapath elements (e.g. classifiers, meters, actions (e.g. marking, absolute dropping, counting, multiplexing), algorithmic droppers, queues and schedulers. It describes possible configuration parameters for these elements and how they might be interconnected to realize the range of traffic conditioning and per- hop behavior (PHB) functionalities described in the Diffserv Architecture [DSARCH]. "Management Information Base for the Differentiated Services Architecture", Fred Baker, Andrew Smith, Kwok Chan, 07/19/2000, <draft-ietf-diffserv-mib-04.txt> This memo describes a SMIv2 MIB for a device implementing the Differentiated Services Architecture [DSARCH], described in detail by the Differentiated Services Router Conceptual Model [MODEL]. "New Terminology for Diffserv", Daniel Grossman, 08/21/2000, <draft-ietf-diffserv-new-terms-03.txt> This memo captures Diffserv working group agreements concerning new and improved terminology. It is intended as a living document for use by the Diffserv working group, and especially for use of authors of Diffserv drafts. It is expected that the terminology in this memo will be incorporated into the existing Diffserv RFCs when they are updated. "Differentiated Services Quality of Service Policy Information Base", Keith McCloghrie, John Seligson, Andrew Smith, S Hahn, Francis Reichmeyer, Kwok Chan, Mike Fine, 07/21/2000, <draft-ietf-diffserv-pib-01.txt> [SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB). This document specifies a set of policy rule classes specifically for configuring QoS Policy for Differentiated Services [DSARCH]. One way to provision policy is by means of the COPS protocol [COPS] with the extensions for provisioning [COPS-PR]. This protocol supports multiple clients, each of which may provision policy for a specific policy domain such as QoS. The PRCs defined in this DiffServ QoS PIB are intended for use by the COPS-PR QoS client type. Furthemore, these PRCs are in addition to any other PIBs that may be defined for the QoS client type in the future, as well as the PRCs defined in the Framework PIB [FR-PIB] "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", Brian Carpenter, Kathleen Nichols, 06/23/2000, <draft-ietf-diffserv-pdb-def-00.txt> The diffserv WG has defined the general architecture for differen- tiated services (RFC 2475) and has been focused on the definition and standardization of the forwarding path behavior required in routers, known as 'per-hop forwarding behaviors' (or PHBs) (RFCs 2474, 2597, and 2598). The differentiated services frame- work creates services within a network by applying rules at the network edges to create traffic aggregates and coupling these with a specific forwarding path treatment for the aggregate. The WG has also discussed the behavior required at diffserv network edges or boundaries for conditioning packet aggregates, such elements as policers and shapers [MODEL, MIB]. A major feature of the diffserv architecture is that only the components applying the rules at the edge need to be changed in response to short-term changes in QoS goals in the network, rather than reconfiguring the interior behaviors. "The `Virtual Wire' Per-Domain Behavior", V. Jacobson, Kathleen Nichols, Kedernath Poduri, 07/21/2000, <draft-ietf-diffserv-pdb-vw-00.txt> This document describes an edge-to-edge behavior, in diffserv terminology a per-domain behavior, called `Virtual Wire' (VW) that can be constructed in any domain supporting the diffserv EF PHB plus appropriate domain ingress policers. The VW behavior is essentially indistinguishable from a dedicated circuit and can be used anywhere it is desired to replace dedicated circuits with IP transport. Although one attribute of VW is the delivery of a peak rate, in VW this is explicitly coupled with a bounded jitter attribute. The document is a edited version of the earlier draft-ietf-diff- serv-ba-vw-00.txt with a new name to reflect a change in Diffserv WG terminology. A pdf version of this document is available at ftp://ftp.packet- design.com/ietf/vw_pdb_0.pdf Distributed Management (disman)------------------------------- "Event MIB", Bob Stewart, Ramanathan Kavasseri, 07/05/2000, <draft-ietf-disman-event-mib-10.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects 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. "Distributed Management Expression MIB", Bob Stewart, Ramanathan Kavasseri, 07/05/2000, <draft-ietf-disman-express-mib-12.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing 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. "Notification Log MIB", Bob Stewart, Ramanathan Kavasseri, 10/13/2000, <draft-ietf-disman-notif-log-mib-17.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for logging SNMP Notifications. "Definitions of Managed Objects for Scheduling Management Operations", D. Levi, J. Schoenwaelder, 07/10/2000, <draft-ietf-disman-schedule-mib-v2-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that are used to schedule management operations periodically or at specified dates and times. "Definitions of Managed Objects for the Delegation of Management Scripts", D. Levi, J. Schoenwaelder, 07/10/2000, <draft-ietf-disman-script-mib-v2-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a set of managed objects that allow the delegation of management scripts to distributed managers. DNS Extensions (dnsext)----------------------- "Domain Name System Security (DNSSEC) Signing Authority", B. Wellington, 10/05/2000, <draft-ietf-dnsext-signing-auth-02.txt> This document proposes a revised model of Domain Name System Security (DNSSEC) Signing Authority. The revised model is designed to clarify earlier documents and add additional restrictions to simplify the secure resolution process. Specifically, this affects the authorization of keys to sign sets of records. "Secure Domain Name System (DNS) Dynamic Update", B. Wellington, 10/05/2000, <draft-ietf-dnsext-simple-secure-update-02.txt> This document proposes a method for performing secure Domain Name System (DNS) dynamic updates. The method described here is intended to be flexible and useful while requiring as few changes to the protocol as possible. The authentication of the dynamic update message is separate from later DNSSEC validation of the data. Secure communication based on authenticated requests and transactions is used to provide authorization. "DNS Security Extension Clarification on Zone Status", Ed Lewis, 09/19/2000, <draft-ietf-dnsext-zone-status-03.txt> The definition of a secured zone is presented, clarifying and updating sections of RFC 2535. RFC 2535 defines a zone to be secured based on a per algorithm basis, e.g., a zone can be secured with RSA keys, and not secured with DSA keys. This document changes this to define a zone to be secured or not secured regardless of the key algorithm used (or not used). To further simplify the determination of a zone's status, 'experimentally secure' status is deprecated. "A Proposed Enhancement to the EDNS0 Version Mechanism", Harald Alvestrand, Rob Austein, 07/13/2000, <draft-ietf-dnsext-edns0dot5-01.txt> 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. "A DNS RR Type for Lists of Address Prefixes (APL RR)", Peter Koch, 06/22/2000, <draft-ietf-dnsext-apl-rr-01.txt> The Domain Name System is primarily used to translate domain names into IPv4 addresses using A RRs. Several approaches exist to describe networks or address ranges. This document specifies a new DNS RR type 'APL' for address prefix lists. "DNS Zone Transfer Protocol Clarifications", Andreas Gustafsson, 03/03/2000, <draft-ietf-dnsext-axfr-clarify-00.txt> In the Domain Name System, zone data is replicated among authoritative DNS servers by means of the "Incremental Zone Transfer in DNS", Masataka Ohta, 06/01/2000, <draft-ietf-dnsext-ixfr-01.txt> This document proposes extensions to the DNS protocols to provide an incremental zone transfer (IXFR) mechanism. "DNSSEC and IPv6 A6 aware server/resolver message size requirements", Olafur Gudmundsson, 09/28/2000, <draft-ietf-dnsext-message-size-01.txt> This document mandates support for EDNS0 in DNS entities claiming to support DNS Security Extensions and A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fallback to TCP will happen, having a detrimental impact on query latency and DNS server load. "GSS Algorithm for TSIG (GSS-TSIG)", S. Kwan, James Gilroy, Praerit Garg, Levon Esibov, 07/20/2000, <draft-ietf-dnsext-gss-tsig-00.txt> The TSIG protocol provides transaction level authentication for DNS. TSIG is extensible through the definition of new algorithms. This document specifies an algorithm based on the Generic Security Service Application Program Interface (GSS-API) (RFC2743). "A DNS RR for encoding DHCP information", Mark Stapp, Andreas Gustafsson, 07/24/2000, <draft-ietf-dnsext-dhcid-rr-00.txt> A situation can arise where multiple DHCP clients request the same DNS name from their (possibly distinct) DHCP servers. To resolve such conflicts, 'Resolution of DNS Name Conflicts'[7] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients 'owning' them. This memo defines a distinct RR type for use by DHCP servers, the 'DHCID' RR. "DNS Security Document Roadmap ", Scott Rose, 08/17/2000, <draft-ietf-dnsext-dnssec-roadmap-00.txt> DNS Security (DNSSEC)technology is composed of extensions to the Domain Name System (DNS) protocol that provide data integrity and authentication to security aware resolvers and applications through the use of cryptographic digital signatures. Several documents exist to describe these extensions and the implementation specific details regarding specific digital signing schemes. The interrelationship between these different documents is discussed here. A brief overview of what to find in which document and author guidelines for what to include in new DNS Security documents, or revisions to existing documents, is described. "Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records)", Simon Josefsson, 08/24/2000, <draft-ietf-dnsext-not-existing-rr-00.txt> This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified. One solution, the NO record, is presented. The NO record differ from the NXT record by using a cryptographic hash value instead of the domain name. This prevent an adversery from collecting information by 'chaining' through a zone. It also remove delegation point concerns in NXT records. The document also describe hash truncation and record merging that reduces storage/network load. "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", Donald Eastlake 3rd, 09/11/2000, <draft-ietf-dnsext-rsa-01.txt> Since the adoption of a Proposed Standard for RSA signatures in the DNS [RFC 2537], advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG resource records (RRs). The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security. "Indicating Resolver Support of DNSSEC", David R. Conrad, 09/05/2000, <draft-ietf-dnsext-dnssec-okbit-00.txt> In order to deploy DNSSEC operationally, DNSSEC aware servers should only respond with DNSSEC RRs when there is an explicit indication that the resolver can understand those RRs. This document proposes the use of a bit in the EDNS0 header to provide that explicit indication and the necessary protocol changes to implement that notification. Domain Name Server Operations (dnsop)------------------------------------- "Handling of DNS Zone Signing Keys", Ed Lewis, 04/14/2000, <draft-ietf-dnsop-keyhand-02.txt> DNS Security Extensions require a greater interaction between zone administrations sharing a zone cut. The center of the interaction is the handling of the zone keys of the child and the signature applied by the parent. DNSSEC does not include a protocol for this, but the means of this interaction need definition to maintain the security of DNS. "Distributing Root or Authorittative Name Servers via Shared Unicast Addresses", Ted Hardie, 06/07/2000, <draft-ietf-dnsop-hardie-shared-root-server-02.txt> This memo describes a set of practices intended to enable an authoritative name server operator to provide access to a single named server in multiple locations. It was originally written to apply particularly to root server operations and later expanded to include the more general case of authoritative name servers. In both cases, the primary motivation for the development and deployment of these practices is to increase the distribution of DNS servers to previously under-served areas of the network topology and to reduce the latency for DNS query responses in those areas. This document presumes a one-to-one mapping between named authoritative servers and administrative entities (operators). This document contains no guidelines or recommendations for caching name servers. "Domain Name System (DNS) Security Key Rollover ", Mark Andrews, D Eastlake, 07/18/2000, <draft-ietf-dnsop-rollover-00.txt> Deployment of Domain Name System (DNS) security with good cryptologic practice will involve large volumes of key rollover traffic. A standard format and protocol for such traffic will be necessary for this to be practical and is specified herein. [Note: The previous version of this draft was draft-ietf-dnsind- rollover-00.txt and before that draft-ietf-dnssec-rollover-00.txt.] "Root Name Servers with Inter Domain Anycast Addresses ", Masataka Ohta, 07/19/2000, <draft-ietf-dnsop-ohta-shared-root-server-00.txt> This memo describes an operational guideline for root name servers to share unicast (interdomain anycast) addresses. "Testing Root Name Servers with Inter Domain Anycast Addresses ", Masataka Ohta, 07/19/2000, <draft-ietf-dnsop-ohta-shared-root-server-test-00.txt> This memo describes an environment to test a proposal to have root name servers with shared unicast addresses described in <draft-ietf- dnsop-ohta-shared-root-server-00txt>. "Requiring DNS IN-ADDR Mapping", D. Senie, 08/10/2000, <draft-ietf-dnsop-inaddr-required-00.txt> The Domain Name Service has provision for providing mapping of IP addresses to host names. It is common practice to ensure both name to address, and address to name mappings are provided for networks. This practice, while documented, has never been documented as a requirement placed upon those who control address blocks. This document fills this gap. Detailed Revision/Update of Message Standards (drums)----------------------------------------------------- "Simple Mail Transfer Protocol", John Klensin, 09/27/2000, <draft-ietf-drums-smtpupd-13.txt> This document is a self-contained specification of the basic protocol for the Internet electronic mail transport, consolidating and updating: - the original SMTP specification of RFC 821 [RFC-821], - domain name system requirements and implications for mail transport from RFC 1035 [RFC-DNS] and RFC 974 [RFC-974], - the clarifications and applicability statements in RFC 1123 [RFC-1123], and - material drawn from the SMTP Extension mechanisms [SMTPEXT]. "Internet Message Format", Pete Resnick, 09/11/2000, <draft-ietf-drums-msg-fmt-09.txt> This standard specifies a syntax for text messages that are sent between computer users, within the framework of 'electronic mail' messages. This standard supersedes the one specified in Request For Comments 822, 'Standard for the Format of ARPA Internet Text Messages' [RFC-822], updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs [STD-3]. Endpoint Congestion Management (ecm)------------------------------------ "The Congestion Manager", Srinivasan Seshan, Hari Balakrishnan, 10/16/2000, <draft-ietf-ecm-cm-02.txt> This document describes the Congestion Manager (CM), an end-system module that: (i) Enables an ensemble of multiple concurrent streams 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. Electronic Data Interchange-Internet Integration (ediint)--------------------------------------------------------- "Requirements for Inter-operable Internet EDI", Rik Drummond, T Harding, C. Shih, 10/12/1999, <draft-ietf-ediint-req-08.txt> This document is a functional specification, discussing the requirements for inter-operable EDI, with sufficient background material to give an explanation for the EDI community of the Internet and security related issues. "MIME-based Secure EDI", Rik Drummond, T Harding, C. Shih, 10/12/1999, <draft-ietf-ediint-as1-11.txt> This document describes how to securely exchange EDI and other business related documents using MIME and public key cryptography. "HTTP Transport for Secure EDI", Dick Brooks, Rik Drummond, Dale Moberg, 07/17/2000, <draft-ietf-ediint-as2-07.txt> This document describes how to exchange structured business data securely using HTTP transport for EDIFACT, X12, XML or other used for business to business data interchange. The data is packaged using standard MIME content-types. Authentication and privacy are obtained by using CMS (S/MIME) or OpenPGP security body parts. Authenticated acknowledgements make use of multipart/signed replies to the HTTP POST requests. Telephone Number Mapping (enum)------------------------------- "ENUM Requirements", Anne Brown, 06/13/2000, <draft-ietf-enum-rqmts-01.txt> 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. "The Number Portability Supplement to ITU-T Recommendation E.164", Andrew Gallant, 07/11/2000, <draft-ietf-enum-e164s2-np-00.txt> 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]. "ENUM Service Specific Provisioning: Principles of Operation", G Vaudreuil, Anne Brown, 07/14/2000, <draft-ietf-enum-operation-00.txt> This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. "Number Portability in the GSTN: An Overview ", Michael Foster, Tom McGarry, James Yu, 07/24/2000, <draft-ietf-enum-e164-gstn-np-00.txt> This document provides an overview of E.164 telephone number portability (NP) in the Global Switched Telephone Network (GSTN). There are three types of number portability: service provider number portability (SPNP), location portability, and service portability. Service provider portability, the focus of the present draft, is a regulatory imperative in many countries seeking to liberalize local telephony service competition, by enabling end-users to retain pre- existing telephone numbers while changing service providers. Implementation of NP within national GSTN entails potentially significant changes to numbering administration, network element signaling, call routing and processing, billing, service management, and other functions. NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address, thereby requiring the transparent translation of the later to the former. In addition, there are various regulatory constraints which establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, the implementation of NP behavior consistent with applicable regulatory constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. Internet Fax (fax)------------------ "A Simple Mode of Facsimile Using Internet Mail", Jun Murai, Hiroyuki Ohno, Kiyoshi Toyoda, Dan Wing, 07/12/2000, <draft-ietf-fax-service-v2-02.txt> 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 <http://www.ietf.org/ipr.html>. 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]. "File Format for Internet Fax", Steve Zilles, Glenn Parsons, James Rafferty, L. McIntyre, Dennis Venable, Robert Buckley, 10/19/2000, <draft-ietf-fax-tiff-fx-08.txt> This document is a revised version of RFC 2301. The revisions, summarized in the list attached as Annex C to this document, are based on the discussions and suggestions for improvements that have been made since RFC 2301 was issued in March 1998, and on the results of independent implementations and interoperability testing. This RFC 2301 revision describes the TIFF (Tag Image File Format) representation of image data specified by the ITU-T Recommendations for black-and-white and color facsimile. This file format specification is commonly known as TIFF-FX. It formally defines minimal, extended and lossless JBIG profiles (Profiles S, F, J) for black-and-white fax, and base JPEG, lossless JBIG and Mixed Raster Content profiles (Profiles C, L, M) for color and grayscale fax. These profiles correspond to the content of the applicable ITU-T Recommendations. Files formatted according to this specification use the image/tiff MIME Content Type. "Minimal GSTN address format in Internet Mail", Claudio Allocchio, 09/11/2000, <draft-ietf-fax-minaddr-v2-02.txt> This memo describes a simple method of encoding GSTN addresses (commonly called 'telephone numbers') in the local-part of Internet email addresses, along with an extension mechanism to allow encoding of additional standard attributes needed for email gateways to GSTN-based services. As with all Internet mail addresses, the left-hand-side (local-part) of an address generated according to this specification, is not to be interpreted except by an MTA that handles messages for the domain given in the right-hand-side. "Minimal FAX address format in Internet Mail", Claudio Allocchio, 09/14/2000, <draft-ietf-fax-faxaddr-v2-02.txt> This memo describes a simple method of encoding GSTN addresses of facsimile devices in the local-part of Internet email addresses. As with all Internet mail addresses, the left-hand-side (local- part) of an address generated according to this specification, is not to be interpreted except by the MTA that is named on the right-hand-side (domain). "Content Negotiation for Internet Messaging Services", Dave Crocker, G. Klyne, Ryuji IWAZAKI, 10/10/2000, <draft-ietf-fax-content-negotiation-03.txt> This memo describes a content negotiation mechanism for facsimile, voice and other messaging services that use Internet e-mail. Services such as facsimile and voice messaging need to cope with new message content formats, yet need to ensure that the content of any given message is renderable by the receiving agent. The mechanism described here aims to meet these needs in a fashion that is fully compatible with the current behaviour and expectations of Internet e-mail. "Implementers Guide for Facsimile Using Internet Mail", Dan Wing, Vivian Cancio, Mike Moldovan, Hiroshi Tamura, 09/25/2000, <draft-ietf-fax-implementers-guide-03.txt> This document is intended for the implementers of software which uses email to send to facsimiles using RFC 2305 and 2532. This is an informational document and its guidelines do not supersede the referenced documents. "Timely Delivery for Internet Messaging Services", G. Klyne, 10/10/2000, <draft-ietf-fax-timely-delivery-01.txt> This proposal describes a way to request timely delivery for facsimile, voice and other messaging services that use Internet e-mail. It provides a deterministic service quality response, while preserving the traditional roles and responsibiltiies of the agents involved in e-mail transfers. It is essentially a profile of the DSN and DELIVERBY extentions for ESMTP, and a new COMPLIANCE extension for establishing the deterministic service quality response. "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", Steve Zilles, Glenn Parsons, James Rafferty, 05/08/2000, <draft-ietf-fax-tiff-regbis-01.txt> This document describes the registration of the MIME sub-type image/tiff. The baseline encoding is defined by [TIFF]. This document refines an earlier sub-type registration in RFC 1528 [TPC.INT]. "Internet FAX Gateway Protocol", Katsuhiko Mimura, K Yokoyama, T Satoh, C Kanaide, 08/16/2000, <draft-ietf-fax-gateway-protocol-01.txt> An Internet FAX Gateway provides functions which translate facsimile between the general switched telephone network (GSTN) the Internet. This document provides information on recommended behaviors for Internet FAX Gateways Protocol. In this context, an Offramp means facsimile data transmission to the GSTN from the Internet, and onramp means facsimile data transmission to Internet from the GSTN. This document covers the delivery-process of the data among equipment which may include Internet Fax terminals, PCs on the Internet and FAX terminal on GSTN. Frame Relay Service MIB (frnetmib)---------------------------------- "Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function", Kenneth Rehbehn, Bob Lynch, P Pate, 10/09/2000, <draft-ietf-frnetmib-mfrmib-04.txt> This memo defines a Management Information Base (MIB) for monitoring and controlling a UNI/NNI Multilink Frame Relay Function as defined in Frame Relay Forum FRF.16. This MIB also include conformance and notification information. "Definitions of Managed Objects for Frame Relay Service Level Definitions", Orly Nicklass, Robert Steinberger, 09/19/2000, <draft-ietf-frnetmib-frmrelay-service-02.txt> 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. "Definitions of Managed Objects for Circuit to Interface Translation", Orly Nicklass, Robert Steinberger, 08/29/2000, <draft-ietf-frnetmib-frsi-00.txt> 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. Extensions to FTP (ftpext)-------------------------- "Extensions to FTP", Robert Elz, Paul Hethmon, 09/19/2000, <draft-ietf-ftpext-mlst-12.txt> In order to overcome the problems caused by the undefined format of the current FTP LIST command output, a new command is needed to transfer standardized listing information from Server-FTP to User- FTP. Commands to enable this are defined in this document. In order to allow consenting clients and servers to interact more freely, a quite basic, and optional, virtual file store structure is defined. This proposal also extends the FTP protocol to allow character sets other than US-ASCII[1] by allowing the transmission of 8-bit characters and the recommended use of UTF-8[2] encoding. Much implemented, but long undocumented, mechanisms to permit restarts of interrupted data transfers in STREAM mode, are also included here. G & R for Security Incident Processing (grip)--------------------------------------------- "Recommended Internet Service Provider Security Services and Procedures", Tom Killalea, 10/06/2000, <draft-ietf-grip-isp-expectations-06.txt> The purpose of this document is to express what the engineering community as represented by the IETF expects of Internet Service Providers (ISPs) with respect to security. It is not the intent of this document to define a set of requirements that would be appropriate for all ISPs, but rather to raise awareness among ISPs of the community's expectations, and to provide the community with a framework for discussion of security expectations with current and prospective service providers. "Guidelines for Evidence Collection and Archiving", Tom Killalea, Dominique Brezinski, 07/13/2000, <draft-ietf-grip-prot-evidence-01.txt> The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence. General Switch Management Protocol (gsmp)----------------------------------------- "General Switch Management Protocol V3", Avri Doria, Kenneth Sundell, Tom Worster, Fiffi Hellstrand, 07/07/2000, <draft-ietf-gsmp-06.txt> This memo provides the sixth draft of the standards track specification of the General Switch Management protocol (GSMP). This release is intended for working group last call. "Definitions of Managed Objects for the General Switch Management Protocol (GSMP)", John Burke, Hans Sjostrand, Balaji Srinivasan, 07/12/2000, <draft-ietf-gsmp-mib-02.txt> This memo defines a portion of the Management Information Base (MIB)for use with network management protocols in the Internet community. In particular, it describes managed objects for the General Switch Management Protocol (GSMP). "GSMP Packet Encapsulations for ATM, Ethernet and TCP", Avri Doria, Tom Worster, 07/12/2000, <draft-ietf-gsmp-encaps-02.txt> This memo specifies the encapsulation of GSMP packets in ATM, Ethernet and TCP. "General Switch Management Protocol Applicability", Avri Doria, Kenneth Sundell, 07/12/2000, <draft-ietf-gsmp-applicability-01.txt> This memo provides an overview of the GSMP protocol and includes information relating to its deployment in a MPLS environment. Internet Architecture Board (iab)--------------------------------- "The Case for IPv6", Bob Fink, Dimitry Haskin, C Perkins, Ruth Fax, Wenken Ling, Thomas Meehan, Steve King, 06/23/2000, <draft-iab-case-for-ipv6-06.txt> This document outlines the business and technical case for IPv6. It is intended to acquaint both the existing IPv4 community with IPv6, to encourage its support for change, and to attract potential future users of Internet technology. "Architectural Implications of NAT", Tony Hain, 08/10/2000, <draft-iab-nat-implications-09.txt> In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631. "Next Steps for the IP QoS Architecture", Geoff Huston, 08/07/2000, <draft-iab-qos-02.txt> While there has been significant progress in the definition of QoS architectures for internet networks, there are a number of aspects of QoS that appear to need further elaboration as they relate to translating a set of tools into a coherent platform for end-to-end service delivery. This document highlights the outstanding architectural issues relating to the deployment and use of QoS mechanisms within internet networks, noting those areas where further standards work may assist with the deployment of QoS internets. "Overview of 2000 IAB Wireless Internetworking Workshop", Danny Mitzel, 08/21/2000, <draft-iab-wirelessws-01.txt> 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. Inter-Domain Multicast Routing (idmr)------------------------------------- "A ''traceroute'' facility for IP Multicast.", Stephen Casner, Bill Fenner, 07/20/2000, <draft-ietf-idmr-traceroute-ipm-07.txt> This draft describes the IGMP multicast traceroute facility. Unlike unicast traceroute, multicast traceroute requires a special packet type and implementation on the part of routers. This speci- fication describes the required functionality in multicast routers, as well as how management applications can use the new router func- tionality. "Distance Vector Multicast Routing Protocol", T. Pusateri, 08/09/2000, <draft-ietf-idmr-dvmrp-v3-10.txt,.ps> DVMRP is an Internet routing protocol that provides an efficient mechanism for connection-less datagram delivery to a group of hosts across an internetwork. It is a distributed protocol that dynamically generates IP Multicast delivery trees using a technique called Reverse Path Multicasting (RPM) [Deer90]. This document is an update to Version 1 of the protocol specified in RFC 1075 [Wait88]. "Domain Wide Multicast Group Membership Reports", Bill Fenner, 07/12/2000, <draft-ietf-idmr-membership-reports-05.txt,.ps> When running a multi-level multicast routing protocol, upper levels need to know about group memberships in lower levels in a protocol- independent fashion. Domain Wide Multicast Group Membership Reports allow this information to be learned in a fashion similar to IGMP[Fenn97] at the domain level. This document is a product of the IDMR working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the author. "Internet Group Management Protocol, Version 3", Steve Deering, Brad Cain, A. Thyagarajan, I Kouvelas, 06/05/2000, <draft-ietf-idmr-igmp-v3-04.txt> 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. "IGMP Multicast Router Discovery", Brad Cain, Shantam Biswas, Brian Haberman, 10/05/2000, <draft-ietf-idmr-igmp-mrdisc-05.txt> Companies have been proposing IGMP snooping schemes for layer-2 bridging devices. A method for discovering multicast capable routers is necessary for these schemes. An IGMP query message is inadequate for discovering multicast routers as one querier is elected. In order to 'discover' multicast routers, we introduce two new types of IGMP messages: Multicast Router Advertisement and Multicast Router Solicitation. These two messages can be used by any device which listens to IGMP to discovery multicast routers. Multicast Router Solicitation messages may be used by any network device (e.g. layer-2 switch) to solicit discovery messages from multicast routers. "IGMP-based Multicast Forwarding ('IGMP Proxying')", Bill Fenner, 07/12/2000, <draft-fenner-igmp-proxy-03.txt,.ps> In certain topologies, it is not necessary to run a multicast rout- ing protocol. It is sufficient to learn group membership informa- tion and simply forward based upon that information. This draft describes a mechanism for forwarding based solely upon IGMP member- ship information. This document is a product of an individual. Comments are solicited and should be addressed to the author. "Socket Interface Extensions for Multicast Source Filters", Bill Fenner, Dave Thaler, Bob Quinn, 07/13/2000, <draft-ietf-idmr-msf-api-01.txt> IGMPv3 for IPv4 adds the capability for applications to express source filters on multicast group memberships, which allows receiver applications to determine the set of senders (sources) from which to accept multicast traffic. This capability also simplifies support of one-to-many type multicast applications. It is expected that in the future, the same capability will be available in IPv6 as well. This document specifies new socket options and ioctl commands to manage source filters for IP Multicast group memberships. It also defines the socket structures to provide input and output arguments to these new APIs. These extensions are designed to provide access to the source filtering features, while introducing a minimum of change into the system and providing complete compatibility for existing multicast applications. "Distance Vector Multicast Routing Protocol Applicability Statement", T. Pusateri, 08/09/2000, <draft-ietf-idmr-dvmrp-v3-as-00.txt,.ps> This document provides a framework for the use of Distance Vector Multicast Routing Protocol (DVMRP) Version 3 within a multicast routing domain. It is an interior gateway protocol designed to be used within an autonomous system. Internationalized Domain Name (idn)----------------------------------- "Requirements of Internationalized Domain Names", James Seng, Z Wenzel, 07/06/2000, <draft-ietf-idn-requirements-03.txt> 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. "Comparison of Internationalized Domain Name Proposals", Paul Hoffman, 07/12/2000, <draft-ietf-idn-compare-01.txt> The IDN Working Group is working on proposals for internationalized domain names that might become a standard in the IETF. Before a single full proposal can be made, competing proposals must be compared on a wide range of requirements and desired features. This document compares the many parts of a comprehensive protocol that have been proposed. It is the companion document to 'Requirements of Internationalized Domain Names' [IDN-REQ], which lays out the requirements for the internationalized domain name protocol. "RACE: Row-based ASCII Compatible Encoding for IDN", Paul Hoffman, 10/16/2000, <draft-ietf-idn-race-02.txt> This document describes a transformation method for representing non-ASCII characters in host name parts in a fashion that is completely compatible with the current DNS. It is a potential candidate for an ASCII-Compatible Encoding (ACE) for internationalized host names, as described in the comparison document from the IETF IDN Working Group. This method is based on the observation that many internationalized host name parts will have all their characters in one row of the ISO 10646 repertoire. "Preparation of Internationalized Host Names ", Paul Hoffman, Marc Blanchet, 07/06/2000, <draft-ietf-idn-nameprep-00.txt> This document describes how to prepare internationalized host names for transmission on the wire. The steps include excluding characters that are prohibited from appearing in internationalized host names, changing all characters that have case properties to be lowercase, and normalizing the characters. Further, this document lists the prohibited characters. "Internationalized domain names using EDNS (IDNE)", Paul Hoffman, Marc Blanchet, 07/11/2000, <draft-ietf-idn-idne-01.txt> The current DNS infrastructure does not provide a way to use internationalized domain names (IDN). This document describes an extension mechanism based on EDNS which enables the use of IDN without causing harm to the current DNS. IDNE enables IDN host names with a as many characters as current ASCII-only host names. It fully supports UTF-8 and conforms to the IDN requirements. "Using the Universal Character Set in the Domain Name System (UDNS)", Dan Oscarsson, 08/28/2000, <draft-ietf-idn-udns-01.txt> Since the Domain Name System (DNS) [RFC1035] was created there have been a desire to use other characters than ASCII in domain names. Lately this desire have grown very strong and several groups have started to experiment with non-ASCII names. This document defines how the Universal Character Set (UCS) [ISO10646] can be used in DNS without extending the current [RFC1035] protocol and how DNS is extended to overcome length limits in the future. "Architecture of Internationalized Domain Name System", Seungik Lee, Dongman Lee, Eunyong Park, Sungil Kim, Hyewon Shin, 07/20/2000, <draft-ietf-idn-icu-00.txt> For restrict use of Domain Name System (DNS) for domain names with alphanumeric characters only, there needs a way to find an Internet host using multi-lingual domain names: Internationalized Domain Name System (IDNS). This document describes how multi-lingual domain names are handled in a new protocol scheme for IDNS servers and resolvers in architectural view and it updates the [RFC1035] but still preserves the backward compatibility with the current DNS protocol. "The DNSII Multilingual Domain Name Protocol", Edmon Chung, David Leung, 08/25/2000, <draft-ietf-idn-dnsii-mdnp-01.txt> Historically, the DNS is capable of handling only names within the basic English alphanumeric character set (plus the hyphen), yet the standards were so elegantly and openly designed that the extension of the DNS into a multilingual and symbols based system proves to be possible with simple adjustments. These adjustments will be made on both the client side and the server side. However, DNSII works on the principal that it is preferable to make the transition to multilingual domain names seamless and transparent to the end-user. Which means initially the server, or more specifically, the resolver, SHOULD take the primary responsibility for the technical implementation of the changes required for a multilingual Internet. The DNSII protocol is designed to allow the preservation of interoperability, consistency and simplicity of the original DNS, while being expandable and flexible for the handling of any character or symbol used for the naming of an Internet domain. DNSII intends to provide a platform for the implementation of multilingual domain names. Besides the original specifications therefore, four alternatives are included for discussion purposes in this document. "Internationalized Host Names Using Resolvers and Applications (IDNRA) ", Paul Hoffman, Patrik Faltstrom, 08/21/2000, <draft-ietf-idn-idnra-00.txt> The current DNS infrastructure does not provide a way to use internationalized host names (IDN). This document describes a mechanism that requires no changes to any DNS server that will allow internationalized host names to be used by end users with changes only to resolvers and applications. It allows flexibility for user input and display, and assures that host names that have non-ASCII characters are not sent to servers. "DNSII Multilingual Domain Name Resolution", Edmon Chung, David Leung, 08/25/2000, <draft-ietf-idn-dnsii-mdnr-00.txt> The Internet-Draft for DNSII-MDNP was focused purely on discussing the ultimate packet protocol that is being sent around the Internet for multilingual domain names. This paper complements the previous paper by outlining the contemplated resolution process with the DNSII protocol throughout the DNS name resolution process. The DNSII-MDNR outlines a resolution process that forms a framework for the resolution of multilingual domain names. Whether the DNSII protocol is implemented exactly as specified in DNSII-MDNP is less relevant, rather it is the idea of having a multilingual packet identifier and the fall back process that matters. The DNSII-MDNR successfully addresses the transitional issues at each node of the DNS resolution process providing a clear migration path and strategy for the deployment of a multilingual enabled DNS system. It also outlines the conformance levels required for basic or complete implementations for applications, resolvers and name servers. This document also introduces a tunneling mechanism for the short-run to transition the system through to a truly multilingual capable name space. "Simple ASCII Compatible Encoding (SACE)", Dan Oscarsson, 08/28/2000, <draft-ietf-idn-sace-00.txt> 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. "Internationalizing Host Names In Applications (IDNA) ", Paul Hoffman, Patrik Faltstrom, 09/13/2000, <draft-ietf-idn-idna-00.txt> The current DNS infrastructure does not provide a way to use internationalized host names (IDN). This document describes a mechanism that requires no changes to any DNS server or resolver that will allow internationalized host names to be used by end users with changes only to applications. It allows flexibility for user input and display, and assures that host names that have non-ASCII characters are not sent to DNS servers or resolvers. "Han Ideograph (CJK) for Internationalized Domain Names", James Seng, 09/13/2000, <draft-ietf-idn-cjk-00.txt> During the development of Internationalized Domain Name (IDN), it is discovered that there is a substantial lack of information and misunderstanding on Han ideographs and its folding mechanism. This document attempts to address some of the issues on doing han folding with respect to IDN. Hopefully, this will dispel some of the common misunderstanding of this problem and to discuss some of the issues with han ideograph and its folding mechanism. This document addresses very specific problem to IDN and thus is not meant as a reference for generic Han folding. Generic Han folding are much more complicated and certainly beyond this document. However, the use of this document may be applicable to other areas that are related with names, e.g. Common Name Resolution Protocol [CNRP]. "DNSII Transitional Reflexive ASCII Compatible Encoding (TRACE)", Edmon Chung, David Leung, 09/14/2000, <draft-ietf-idn-dnsii-trace-00.txt> ASCII Compatible Encoding (ACE) schemes should only be used as a transitional strategy with a well-defined way forward to the eventual enabling of a truly multilingual name space for the DNS. The previous DNSII documents surrounding multilingual domain names have focused on the ultimate form with the DNSII-MDNR suggesting possible tunneling techniques where ACE may be used. This document furthers the discussion on an ACE system, which not only provides a pathway towards the ultimate DNSII scheme but also an interim solution taking care of the immediate needs. A reflexive CNAME process RENAME is introduced where non-ASCII incoming queries will be automatically CNAMEd to its ASCII counterpart without requiring an actual lookup. The resolver will then be responsible for recursively looking up the corresponding translated alphanumeric name. This document does not attempt to create another ACE scheme, instead it discusses the way an ACE scheme could be used as a transition towards the ultimate goal of a true multilingual name on the wire. "BRACE: Bi-mode Row-based ASCII-Compatible Encoding for IDN version 0.1.2", Adam Costello, 09/19/2000, <draft-ietf-idn-brace-00.txt> BRACE is a reversible function from Unicode (UTF-16) [UNICODE] text strings to host name labels. Host name labels are defined by [RFC952] and [RFC1123] as case-insensitive strings of ASCII letters, digits, and hyphens, neither beginning nor ending with a hyphen. [RFC1034] restricts the length of labels to 63 characters. Inter-Domain Routing (idr)-------------------------- "A Border Gateway Protocol 4 (BGP-4)", Tony Li, Y Rekhter, 05/01/2000, <draft-ietf-idr-bgp4-10.txt> The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol. It is built on experience gained with EGP as defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as described in RFC 1092 [2] and RFC 1093 [3]. "Cooperative Route Filtering Capability for BGP-4", Y Rekhter, Enke Chen, 10/17/2000, <draft-ietf-idr-route-filter-01.txt> This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Autonomous System Confederations for BGP", J. Scudder, P. Traina, Danny McPherson, 10/18/2000, <draft-ietf-idr-bgp-confed-rfc1965bis-01.txt> The Border Gateway Protocol [1] is an inter-autonomous system routing protocol designed for TCP/IP networks. BGP, as defined in [1], requires that all BGP speakers within a single AS must be fully meshed. This represents a serious scaling problem that has been well documented in a number of proposals [3,5]. Intrusion Detection Exchange Format (idwg)------------------------------------------ "Intrusion Detection Exchange Format Requirements", Mark Wood, 10/26/1999, <draft-ietf-idwg-requirements-02.txt> The purpose of the Intrusion Detection Exchange Format is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. This Internet-Draft describes the high-level requirements for such communication, including the rationale for those requirements. Scenarios are used to illustrate the requirements. "Intrusion Detection Exchange Format Data Model", Ming-Yuh Huang, David Donahoo, Hervé Debar, 06/15/2000, <draft-ietf-idwg-data-model-03.txt> The purpose of the Intrusion Detection Exchange Format is to define data formats and exchange procedures for sharing information of interest with intrusion detection and response systems, and with the management sys- tems that may need to interact with them. This Internet-Draft describes a proposed data model to represent the information exported by the intrusion-detection systems, including the rationale for this model. This information is herein refered to as 'Alert', in accordance with the definition given in the IDWG requirements draft [1]. Examples are given to illustrate the use of the model. "IAP: Intrusion Alert Protocol", Dipankar Gupta, 04/11/2000, <draft-ietf-idwg-iap-01.txt> The Intrusion Alert Protocol (IAP) is application-level protocol for exchanging intrusion alert data. The protocol is designed to provide the necessary transport and security properties to allow sensitive alert data to be sent across IP networks. In addition, the protocol is designed so that future extensions may use the application layer for configuring intrusion detection sensor/analyzers or sending responses. "Intrusion Detection Message Exchange Format Extensible Markup Language (XML) Document Type Definition", David Curry, 07/12/2000, <draft-ietf-idwg-idmef-xml-01.txt> The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. The goals and requirements of the IDMEF are described in [2]. This Internet-Draft describes a proposed implementation of the data format component of the IDMEF, using the Extensible Markup Language (XML) [3] to represent the class hierarchy defined by Debar, Huang and Donahoo [4]. The rationale for choosing XML is explained, a Document Type Definition (DTD) is developed, and examples are provided. An earlier version of this implementation was reviewed, along with other proposed implementations, by the IDWG at its September, 1999 and February, 2000 meetings. At the February meeting, it was decided that the XML solution was best at fulfilling the IDWG requirements. "Intrusion Detection Message Exchange Format Comparison of SMI and XML Implementations", David Curry, Glenn Mansfield, 09/27/2000, <draft-ietf-idwg-xmlsmi-01.txt> The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. The goals and requirements of the IDMEF are described in [2]. Two implementations of the IDMEF data format have been proposed: one using the Structure of Management Information (SMI) to describe a MIB, and the other using a Document Type Definition (DTD) to describe XML documents. Both representations appear to have their good and bad traits, and deciding between them is difficult. To arrive at an informed decision, the working group tasked the authors to identify and analyze the pros and cons of both approaches, and to present the results in the form of an Internet-Draft. The initial version of this draft was reviewed by the IDWG at the February, 2000 interim meeting where it was tentatively decided that the XML/DTD solution was best at fulfilling the IDWG requirements. This decision was finalized at the March, 2000 IETF IDWG meeting. Internet Message Access Protocol Extension (imapext)---------------------------------------------------- "INTERNET MESSAGE ACCESS PROTOCOL - SORT EXTENSION", M. Crispin, Ken Murchison, 08/29/2000, <draft-ietf-imapext-sort-05.txt> This document describes an experimental server-based sorting extension to the IMAP4rev1 protocol, as implemented by the University of Washington's IMAP toolkit. This extension provides substantial performance improvements for IMAP clients which offer sorted views. A server which supports this extension indicates this with a capability name of 'SORT'. Client implementations SHOULD accept any capability name which begins with 'SORT' as indicating support for the extension described in this document. This provides for future upwards-compatible extensions. At the time of this document was written, the IMAP Extensions Working Group (IETF-IMAPEXT) was considering upwards-compatible additions to the SORT extension described in this document, tenatively called the SORT2 extension. "IMAP4 ACL extension", John Myers, 05/24/2000, <draft-ietf-imapext-acl-00.txt> The ACL extension of the Internet Message Access Protocol [IMAP4] permits access control lists to be manipulated through the IMAP protocol. "IMAP ANNOTATE Extension", R Gellens, Cyrus Daboo, 07/18/2000, <draft-ietf-imapext-annotate-00.txt> The ANNOTATE extension to the Internet Message Access Protocol [IMAP4] permits clients and servers to maintain "IMAP VIEW Extension ", M. Crispin, Mark Pustilnik, Cyrus Daboo, 07/18/2000, <draft-ietf-imapext-view-00.txt> The VIEW extension to the Internet Message Access Protocol [IMAP4] permits a subset of messages in the mailbox to be processed separately from the entire set of messages in the mailbox. This allows a client to restrict its view to only the messages appearing in this set. The subset of messages also need not be returned in order of their sequence numbers, allowing clients to access messages in a particular sort order. The subsetting and sorting of messages is handled by existing [IMAP4] commands that return a set of messages as their result. This extension takes the set returned from such a command and applies the VIEW methodology to it. "IMAP Regular Expressions SEARCH Extension", R Gellens, 07/27/2000, <draft-ietf-imapext-regex-00.txt> This memo describes a regular-expression search facility for the [IMAP] protocol. A server advertises support for this facility by the capability name REGEX. "INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION", M. Crispin, Ken Murchison, 10/10/2000, <draft-ietf-imapext-thread-04.txt> This document describes the server-based threading extension to the IMAP4rev1 protocol. This extension provides substantial performance improvements for IMAP clients which offer threaded views. A server which supports this extension indicates this with more or more capability names consisting of 'THREAD-' followed by a supported threading algorithm name as described in this document. This provides for future upwards-compatible extensions. "IMAP4 LIST Command Extensions", B. Leiba, 10/03/2000, <draft-ietf-imapext-list-extensions-00.txt> IMAP4 has two commands for listing mailboxes: LIST and LSUB. As we add extensions that require specialized lists (see [MboxRefer] for an example) we expand the number of list commands, as each extension must add its function to both LIST and LSUB. This document describes extensions to the LIST command that allow these additions to be done in mutually compatible options to the LIST command, avoiding the exponential increase in specialized list commands. Instant Messaging and Presence Protocol (impp)---------------------------------------------- "Security Framework for Instant Messaging and Presence Protocol", Graham Klyne, 03/07/2000, <draft-ietf-impp-security-framework-01.txt> 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. "Message Information Data Format", John Stracke, 01/19/2000, <draft-ietf-impp-midf-01.txt> This document specifies that instant messages are to be [MIME] messages. It is anticipated that this document will eventually become a paragraph or two in [IMPP-MITP]. "Transport Protocol for Presence Information/ Instant Messaging", John Stracke, Sonu Aggarwal, C Vermeulen, Colin Benson, 03/10/2000, <draft-ietf-impp-pitp-mitp-01.txt> 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. A goal of the Instant Messaging and Presence Protocol (IMPP) Working Group is to produce an Internet Standard for Presence and Instant Messaging. "Presence Information Data Format for IMPP", Hiroyasu Sugano, C Vermeulen, Robert Osborne, 03/14/2000, <draft-ietf-impp-pidf-01.txt> 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. Integrated Services (intserv)----------------------------- "Integrated Services in the Presence of Compressible Flows", David Oran, Stephen Casner, Bruce Davie, John Wroclawski, Carol Iturralde, 02/28/2000, <draft-ietf-intserv-compress-02.txt> An Integrated Services router performs admission control and resource allocation based on the information contained in a TSpec (among other things). As currently defined, TSpecs convey information about the data rate (using a token bucket) and range of packet sizes of the flow in question. However, the TSpec may not be an accurate representation of the resources needed to support the reservation if the router is able to compress the data at the link level. This specification describes an extension to the TSpec which enables a sender of potentially compressible data to provide hints to int-serv routers about the compressibility they may obtain. Routers which support appropriate compression take advantage of the hint in their admission control decisions and resource allocation procedures; other routers ignore the hint. An initial application of this approach is to notify routers performing RTP header compression that they may allocate fewer resources to RTP flows. IP over Cable Data Network (ipcdn)---------------------------------- "Baseline Privacy Interface Management Information Base for DOCSIS Compliant Cable Modems and Cable Modem Termination Systems", Richard Woundy, 02/17/2000, <draft-ietf-ipcdn-mcns-bpi-mib-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for SNMP-based management of 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. This memo specifies a MIB module in a manner that is compliant to the SNMPv2 SMI. The set of objects is consistent with the SNMP framework and existing SNMP standards. This memo does not specify a standard for the Internet community. This memo is a product of the IPCDN working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at ipcdn@terayon.com and/or the author. "Data Over Cable System Quality of Service Management Information Base (DOCSIS-QOS MIB)", M. Patrick, 10/20/2000, <draft-ietf-ipcdn-qos-mib-04.txt> This document defines a basic set of managed objects for SNMP-based management of extended QOS features of Cable Modems (CMs) and Cable Modem Termination Systems (CMTSs) conforming to the Data over Cable System (DOCSIS) standard version 1.1. "Management Information Base for DOCSIS Cable Modem Termination Systems for Subscriber Management", W. Sawyer, Michael StJohns, 07/13/2000, <draft-ietf-ipcdn-subscriber-mib-02.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines 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. "Management Information Base for DOCSIS Cable Modems and Cable Modem Termination Systems for Baseline Privacy Plus", S. Green, 06/23/2000, <draft-ietf-ipcdn-bpiplus-mib-03.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines 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. "DVB Cable Network Interface Unit MIB for EuroModem compliant Cable Modems ", Andrew Valentine, 05/18/2000, <draft-ietf-ipcdn-dvbnetint-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines 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. "Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems ", Michael StJohns, 07/20/2000, <draft-ietf-ipcdn-device-mibv2-00.txt> 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. IP over Fibre Channel (ipfc)---------------------------- "Fibre Channel Management Framework Integration MIB", Steven Blumenau, 06/01/2000, <draft-ietf-ipfc-fcmgmt-int-mib-04.txt> The goal of this document is to fill in missing pieces necessary to enable an enterprise class storage network. One of the more important features of an enterprise class storage network is management; this document gives a framework MIB that will provide an integrated management environment for the enterprise customer. An enterprise class storage network is comprised of elements (i.e., hubs, switches, converters, gateways, and HBAs) that are developed by many different vendors. The large number of vendors that can exist in a storage network makes mangement a very hard and complicated problem. The main goal of this document's MIB is to enable interoperability among the various vendors involved in the Fibre Channel marketplace. "A Framework for Fibre Channel MIBs", Mark Carlson, Lee Hu, Gavin Bowlby, 07/17/2000, <draft-ietf-ipfc-mib-framework-03.txt> This document discusses technical issues and requirements for the management information base (MIB) for Fibre Channel and storage network applications. This document is likely to be expanded to include management of specific Fibre Channel device types in the future. The purpose is to have an overall structure and view of Fibre Channel MIBs for consistency and interoperability. This document does not try to cover the details of each individual MIB. This is an initial draft document, which will evolve and expand over time. It is the intent of this document to produce a coherent description of a framework for various MIB development which was and is being considered by the working group. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. "Fibre Channel Over IP (FCIP)", Monica Krueger, Raj Bhagwat, Murali Rajagopal, Wayne Rickard, Elizabeth Rodriguez, 07/19/2000, <draft-ietf-ipfc-fcoverip-02.txt> Fibre Channel(FC) is a dominant technology used in Storage Area Networks(SAN). The purpose of this draft is to specify a standard way of encapsulating FC frames over IP and to describe mechanisms that allow islands of FC SANs to be interconnected over IP-based networks running over very reliable data links. FC over IP relies on IP-based network services to provide the connectivity between the SAN islands over LANs, MANs, or WANs. While the FC over IP specification is independent of the link level transport protocol, it assumes a high bandwidth, high reliability, low loss link level transport such as Gigabit Ethernet, SONET, ATM, or DWDM. This specification treats all classes of FC frames the same -- as datagrams. IPNG (ipngwg)------------- "IPv6 Node Information Queries", M. Crawford, 08/29/2000, <draft-ietf-ipngwg-icmp-name-lookups-07.txt> This document describes a protocol for asking an IPv6 node to supply certain network information, such as its fully-qualified domain name. IPv6 implementation experience has shown that direct queries for a DNS name are useful, and a direct query mechanism for other information has been requested. "Site prefixes in Neighbor Discovery", Erik Nordmark, 04/06/2000, <draft-ietf-ipngwg-site-prefixes-04.txt> This document specifies extensions to IPv6 Neighbor Discovery to carry site prefixes. The site prefixes are used to reduce the effect of site renumbering by ensuring that the communication inside a site uses site-local addresses. This protocol requires that all IPv6 implementations, even those that do not implement this protocol, ignore all site-local addresses that they retrieve from the DNS when the AAAA or A6 RRset contain both global and site-local addresses. If the RRset contains only site- local addresses those addresses can be used. "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", A. Conta, 07/13/2000, <draft-ietf-ion-ipv6-ind-04.txt> This memo describes extensions to the IPv6 Neighbor Discovery that allow a node to solicit and be advertised an IPv6 address corresponding to a given link-layer address. These extensions are called Inverse Neighbor Discovery. They specifically apply to Frame Relay networks but they may also apply to other networks with similar behavior. "IP Version 6 Management Information Base for the Multicast Listener Discovery Protocol", Randall Worzella, Brian Haberman, 07/25/2000, <draft-ietf-ipngwg-mld-mib-04.txt> This document defines an experimental 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 which defines managed objects for implementations of the Multicast Listener Discovery Protocol [MLD]. "Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification", A. Conta, Steve Deering, 06/29/1999, <draft-ietf-ipngwg-icmp-v3-00.txt> This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", Thomas Narten, Richard Draves, 09/20/2000, <draft-ietf-ipngwg-addrconf-privacy-03.txt> Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. "An Extension of Format for IPv6 Scoped Addresses", A. Onoe, Tatsuya Jinmei, 06/28/2000, <draft-ietf-ipngwg-scopedaddr-format-02.txt> This document defines an extension of the format for IPv6 scoped addresses. In the format, a scope identifier is attached to a scoped address in order to supplement the ambiguity of the semantics of the address. Using the format with some library routines will make scope-aware applications simpler. "Default Address Selection for IPv6", Richard Draves, 07/20/2000, <draft-ietf-ipngwg-default-addr-select-01.txt> 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. "IPv6 Multihoming with Route Aggregation", Jessica Yu, 08/24/2000, <draft-ietf-ipngwg-ipv6multihome-with-aggr-01.txt> With the growing requirements for reliable Internet connectivity, increasing number of enterprises choose to acquire Internet connectivity from more than one Internet Service Providers (ISPs) for the purpose of connectivity redundancy and traffic load distribution. The potential of large number of multi-connection sites impose direct challenge on routing aggregation and consequently on scalability of the global Internet routing. Hence a solution is highly desirable which provides the benefit of multi-connection as well as the better scalability of the global routing system. In addition, such solution needs to be simple enough to be operationally manageable. With the fast growth of ISP networks as well as enterprise networks, network manageability is becoming an increasingly important requirement. This document describes a solution which achieves the stated goals. "IP Version 6 Addressing Architecture", Bob Hinden, Steve Deering, 10/05/2000, <draft-ietf-ipngwg-addr-arch-v3-02.txt> This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. "IP Version 6 Scoped Address Architecture", Steve Deering, Brian Zill, Brian Haberman, 06/27/2000, <draft-ietf-ipngwg-scoping-arch-01.txt> This document specifies the architectural characteristics, expected behavior, and usage of IPv6 addresses of different scopes "Basic Socket Interface Extensions for IPv6", Robert Gilligan, W. Stevens, Jim Bound, Susan Thomson, 05/11/2000, <draft-ietf-ipngwg-rfc2553bis-00.txt> The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. "IPv6 multihoming support at site exit routers", Jun-ichiro Hagino, 06/26/2000, <draft-ietf-ipngwg-ipv6-2260-00.txt> The document describes a mechanism for basic IPv6 multihoming support, and its operational requirements. The mechanism can be combined with more sophisticated (or complex) multihoming support mechanisms, and can be used as a foundation for other mechanisms. The document is largely based on RFC2260 [Bates, 1998] by Tony Bates. "Unicast-Prefix-based IPv6 Multicast Addresses", Brian Haberman, Dave Thaler, 09/27/2000, <draft-ietf-ipngwg-uni-based-mcast-00.txt> This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. Internet Printing Protocol (ipp)-------------------------------- "Internet Printing Protocol: Requirements for IPP Notifications", T. Hastings, H. Lewis, R. deBry, 07/07/2000, <draft-ietf-ipp-not-04.txt> This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing on the Internet. There are multiple parts to IPP, but the primary architectural components are the Model and Semantics, and the Encoding and Transport documents. This document provides a statement of the requirements for notifications as part of an IPP Service. "Internet Printing Protocol(IPP:IPP Event Notification Specification", J. Martin, T. Hastings, R. Herriot, S. Isaacson, R. deBry, R. Bergman, Michael Shepherd, 09/01/2000, <draft-ietf-ipp-not-spec-05.txt> This document describes an extension to the IPP/1.0, IPP/1.1, and future versions. This extension allows a client to subscribe to printing related Events. Subscriptions are modeled as Subscription Objects. The Subscription Object specifies that when one of the specified Event occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Delivery Method (i.e., protocol). A client associates Subscription Objects with a particular Job by performing the Create-Job-Subscriptions operation or by submitting a Job with subscription information. A client associates Subscription Objects with the Printer by performing a Create-Printer- Subscriptions operation. Four other operations are defined for Subscription Objects: Get-Subscriptions-Attributes, Get-Subscriptions, Renew-Subscription, and Cancel-Subscription. "Internet Printing Protocol/1.1: Implementer's Guide", T. Hastings, Carl-Uno Manros, Carl Kugler, Henrik Holst, Peter Zehler, 06/08/2000, <draft-ietf-ipp-implementers-guide-v11-01.txt> This document is one of a set of documents, which together describe all aspects of a new Internet Printing Protocol (IPP). IPP is an application level protocol that can be used for distributed printing using Internet tools and technologies. This document contains information that supplements the IPP Model and Semantics [IPP-MOD] and the IPP Transport and Encoding [IPP-PRO] documents. It is intended to help implementers understand IPP/1.1, as well as IPP/1.0, and some of the considerations that may assist them in the design of their client and/or IPP object implementations. For example, a typical order of processing requests is given, including error checking. Motivation for some of the specification decisions is also included. "Internet Printing Protocol(IPP): Notifications over SNMP via Job Monitoring MIB Traps", T. Hastings, Ira McDonald, 08/10/2000, <draft-ietf-ipp-not-over-snmp-04.txt> This document is a submission to the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF). This document is intended for eventual publication as an IETF Informational RFC. Comments should be submitted to the ipp@pwg.org mailing list. This document specifies an OPTIONAL mapping of IPP notifications over SNMP via new service and job trap extensions to the original Job Monitoring MIB [RFC-2707]. This mapping may be used to deliver printer notifications for any printer (not just IPP-capable ones) and also to deliver job notifications for any job (not just ones submitted via IPP). This document specifies (4) new object groups and (4) new SNMP traps for addition to the Job Monitoring MIB [RFC 2707]. A working copy of these extensions inserted in the original Job Monitoring MIB ASN.1 is at: ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/jmp-trap-000808.mib "Internet Printing Protocol(IPP): Job and Printer Administrative Operations", T. Hastings, H. Lewis, Carl Kugler, 08/17/2000, <draft-ietf-ipp-ops-set2-02.txt> This document is a submission to the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF). After approval, it is intended to be on the IETF standards track. Comments should be submitted to the ipp@pwg.org mailing list. "Internet Printing Protocol(IPP): The 'collection' attribute syntax", T. Hastings, R. Herriot, R. deBry, Kirk Ocke, Peter Zehler, 07/06/2000, <draft-ietf-ipp-collection-03.txt> This document specifies an OPTIONAL attribute syntax called 'collection' for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and subsequent versions. A 'collection' is a container holding one or more named values, which are called 'member' attributes. A collection allows data to be grouped like a PostScript dictionary or a Java Map. This document also specifies the conformance requirements for a definition document that defines a collection attribute. "Internet Printing Protocol (IPP): Job and Printer Set Operations", T. Hastings, R. Herriot, H. Lewis, Carl Kugler, 04/18/2000, <draft-ietf-ipp-job-printer-set-ops-02.txt> This document specifies 3 additional OPTIONAL operations for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566], IPP/1.1 [ipp-mod, ipp-pro], and future versions. The end user, operator, and administrator Set-Job-Attributes and Set-Printer-Attributes operations are used to modify IPP Job objects and Printer objects, respectively. The third administrator Get-Printer-Supported-Values operation returns values that the IPP Printer will accept for setting its 'xxx-supported' attributes. "Internet Printing Protocol (IPP): LDAP Schema for Printer Services", K Jones, H. Lewis, Ira McDonald, P Fleming, 08/09/2000, <draft-ietf-ipp-ldap-printer-schema-03.txt> This document is a product of the Internet Printing Protocol Working Group, chartered by the IETF. Comments should be sent to the ipp@pwg.org mailing list and the principal editor flemingp@us.ibm.com. This document defines a common printer schema for use with LDAP directories (a directory service supporting the Lightweight Directory Access Protocol (LDAP)). Using this common printer schema enables client applications to use LDAP to search for printers using application or user specified search criteria. Searches are defined based on the entry's type and attributes independent of the LDAP directory being used. "Internet Printing Protocol (IPP): The 'ipp-get' Notification Delivery Method", T. Hastings, R. Herriot, H. Lewis, Carl-Uno Manros, 08/16/2000, <draft-ietf-ipp-notify-poll-02.txt> The notification extension document [ipp-ntfy] defines operations that a client can perform in order to create Subscription Objects in a Printer and carry out other operations on them. A Subscription Object represents a Subscription abstraction. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Delivery Method (i.e., protocol). The notification extension document [ipp-ntfy] specifies that each Delivery Method is defined in another document. This document is one such document, and it specifies the 'ipp-get' delivery method. "Internet Printing Protocol (IPP): The 'mailto:' Delivery Method for Event Notifications", T. Hastings, R. Herriot, Carl-Uno Manros, Henrik Holst, 09/01/2000, <draft-ietf-ipp-notify-mailto-03.txt> The notification extension document [ipp-ntfy] defines operations that a client can perform in order to create Subscription Objects in a Printer and carry out other operations on them. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Delivery Method (i.e., protocol). The notification extension document [ipp-ntfy] specifies that each Delivery Method is defined in another document. This document is one such document, and it specifies the 'mailto' delivery method. For this Delivery Method, when an Event occurs, the Printer immediately sends an Event Notification via an email message to the Notification Recipient specified in the Subscription Object. The message body of the email consists of Human Consumable text that is not intended to be parsed by a machine. "Internet Printing Protocol (IPP):The INDP Notification Delivery Method and Protocol/1.0", T. Hastings, Hugo Parra, 09/01/2000, <draft-ietf-ipp-indp-method-03.txt> The IPP notification extension document [ipp-ntfy] defines operations that a client can perform in order to create Subscription Objects in a Printer and carry out other operations on them. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Delivery Method (i.e., protocol). "Internet Printing Protocol (IPP):IPP Notification Delivery Protocol (INDP) ", T. Hastings, Hugo Parra, 03/14/2000, <draft-ietf-ipp-indp-00.txt> The IPP event notification specification [ipp-ntfy] is an OPTIONAL extension to IPP/1.0, IPP/1.1, and future versions. [ipp-ntfy] which enables IPP clients to request notification of printer and job events. The IPP notification extension gives IPP Printers the flexibility to choose how many Subscriptions objects (individual requests for notification), what delivery methods, and what natural languages to support, among others. In practice, it's the working environment where an IPP Printer is deployed what ultimately dictates the notification requirements for that printer. Notification Delivery Services exist to help event producers, such as IPP Printers, meet the varying notification needs of disparate environments. Specifically, an IPP Notification Delivery Service may extend the notification capabilities of IPP Printers and help customize the type of notification required in a highly specialized environment. This documents defines the IPP Notification Delivery Protocol (INDP), a protocol for IPP Printers to communicate with Notification Delivery Services using 'application/ipp' as the encoding mechanism and HTTP as the transport. The definition of INDP lends itself nicely for use by IPP Printers and Notification Delivery Services for dispatching IPP Notifications to Notification Recipients as well. "Internet Printing Protocol (IPP): Job Progress Attributes", T. Hastings, H. Lewis, R. Bergman, 09/11/2000, <draft-ietf-ipp-job-prog-01.txt> This document defines four new Job Description attributes for monitoring job progress to be registered as extensions to IPP/1.0 [RFC2566] and IPP/1.1 [ipp-mod]. These attributes are drawn from the PWG Job Monitoring MIB [rfc2707]. The new Job Description attributes are: 'job-collation-type' (type2 enum) 'sheet-completed-copy-number' (integer(0:MAX)) 'sheet-completed-document-number' (integer(0:MAX)) 'impressions-completed-current-copy' (integer(0:MAX)) This document also defines a new 'sheet-collate' Job Template attribute to control sheet collation and to help with the interpretation of the job progress attributes. These new attributes may also be used by themselves in combination with the IPP/1.1 'job-impressions-completed' attribute as useful job progress monitoring attributes and/or may be passed in an IPP Notification (see [ipp-ntfy]). "Internet Printing Protocol (IPP): Resource Objects", T. Hastings, Ira McDonald, 09/11/2000, <draft-ietf-ipp-get-resource-01.txt> This document is a submission to the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF). The open issues in this document each begin 'ISSUE_n:'. Comments should be submitted to the ipp@pwg.org mailing list. "Internet Printing Protocol (IPP): Printer Installation Extension", Hugo Parra, Ted Tronson, 07/19/2000, <draft-ietf-ipp-install-00.txt> Various client platforms require that some setting up take place at the workstation before the client can properly submit jobs to a specific printer. This setup process is sometimes referred to as printer installation. Most clients need some information about the printer being installed as well as support files to complete the printer installation. The nature of the support files varies depending on the specific client platform, from simple configuration files to highly sophisticated printer drivers. This document refers to these support files as 'client print support files'. Traditionally, the selection and installation of the correct client print support files has been error prone. The selection and installation process can be simplified and even automated if the workstation can learn some key information about the printer. This document describes the IPP extensions that enable workstations to obtain the information needed to perform a proper printer driver installation using IPP. "Internet Printing Protocol (IPP): Requirements for Job, Printer, and Device Administrative Operations", T. Hastings, H. Lewis, Carl Kugler, 08/17/2000, <draft-ietf-ipp-ops-admin-req-00.txt> This document is a submission to the Internet Printing Protocol Working Group of the Internet Engineering Task Force (IETF). After approval, it is intended to be an Informational RFC. Comments should be submitted to the ipp@pwg.org mailing list. This document specifies the requirements and use cases for some OPTIONAL administrative operations for use with the Internet Printing Protocol/1.0 (IPP) [RFC2565, RFC2566] and IPP/1.1 [ipp-mod, ipp-pro]. Some of these administrative operations operate on the IPP Job and Printer objects. The remaining operations operate on a new Device object that more closely models a single output device (see [ipp-mod]). "Internet Printing Protocol (IPP): The 'ippget' Event Notifications Delivery Method", R. Herriot, Harry Lewis, Carl Kugler, 09/19/2000, <draft-ietf-ipp-notify-get-00.txt> The notification extension document [ipp-ntfy] defines operations that a client can perform in order to create Subscription Objects in a Printer and carry out other operations on them. A Subscription Object represents a Subscription abstraction. The Subscription Object specifies that when one of the specified Events occurs, the Printer sends an asynchronous Event Notification to the specified Notification Recipient via the specified Delivery Method (i.e., protocol). The notification extension document [ipp-ntfy] specifies that each Delivery Method is defined in another document. This document is one such document, and it specifies the 'ippget' delivery method. IP Performance Metrics (ippm)----------------------------- "Instantaneous Packet Delay Variation Metric for IPPM", Philip Chimento, Carlo Demichelis, 07/24/2000, <draft-ietf-ippm-ipdv-05.txt> This memo refers to a metric for variation in delay of packets across Internet paths. The metric is based on statistics of the difference in One-Way-Delay of consecutive packets. This particular definition of variation is called 'Instantaneous Packet Delay Variation (ipdv)'. The metric is valid for measurements between two hosts both in the case that they have synchronized clocks and in the case that they are not synchronized. In the second case it allows an evaluation of the reciprocal skew. Measurements performed on both directions (Two-ways measurements) allow a better estimation of clock differences. The precision that can be obtained is evaluated. "One-way Loss Pattern Sample Metrics", Ravadurgam Ravikanth, Rajeev Koodli, 07/24/2000, <draft-ietf-ippm-loss-pattern-03.txt> The Internet exhibits certain specific types of behavior (e.g., bursty packet loss) that can affect the performance seen by the users as well as the operators. Currently, the focus has been on specifying base metrics such as delay, loss and connectivity under the framework described in [frame-work]. It would be useful to capture specific Internet behaviors under the umbrella of IPPM framework, specifying new concepts while reusing existing guidelines as much as possible. This draft proposes the use of 'derived metrics' to accomplish this, specifically providing means for capturing the loss pattern on the Internet. "Network performance measurement for periodic streams", Vilho Raisanen, Glenn Grotefeld, 07/12/2000, <draft-ietf-ippm-npmps-02.txt> This document describes some of the issues associated with application-level measurements of network performance for periodic streams. An example application would be the testing of Dst-Src routes for use as bearer for multimedia streams. In this document, the reader is assumed to be familiar with the terminology of the Framework for IP Performance Metrics RFC 2330 [1]. This document is parallel to A One-way Delay Metric for IPPM RFC 2679[2]. A sample metric is described that is suitable for application-level measurement for streaming multimedia over IP. Using such a measurement, transmission service of a network is probed with a traffic stream similar to that of the application of interest, which is likely to be very dissimilar to the Poisson inter-arrival interval described in [2].IP Security Protocol (ipsec)---------------------------- "A GSS-API Authentication Method for IKE", D. Piper, Brian Swander, 07/24/2000, <draft-ietf-ipsec-isakmp-gss-auth-06.txt> This document describes an alternate authentication method for IKE which makes use of GSS-API to authenticate the Diffie-Hellman exchange. The mechanism described here extends the authentication methods defined in RFC-2409 without introducing any modifications to the IKE key exchange protocol. "DHCP Configuration of IPSEC Tunnel Mode in IPv4", Bernard Aboba, B. Patel, V. Gupta, Scott Kelly, 10/20/2000, <draft-ietf-ipsec-dhcp-07.txt> In many remote access scenarios, a mechanism for making the remote host appear to be present on the local corporate network is quite useful. This may be accomplished by assigning the host a 'virtual' address from the corporate network, and then tunneling traffic via Ipsec from the host's ISP-assigned address to the corporate security gateway. The Dynamic Host Configuration Protocol (DHCP) provides for such remote host configuration. This draft explores the requirements for host configuration in IPSEC tunnel mode, and describes how the DHCP protocol may be leveraged for configuration in this case. "A Hybrid Authentication Mode for IKE", Moshe Litvin, Roy Shamir, Tamir Zegman, 08/10/2000, <draft-ietf-ipsec-isakmp-hybrid-auth-05.txt> This document describes a set of new authentication methods to be used within Phase 1 of the Internet Key Exchange (IKE). The proposed methods assume an asymmetry between the authenticating entities. One entity, typically an Edge Device (e.g. firewall), authenticates using standard public key techniques (in signature mode), while the other entity, typically a remote User, authenticates using challenge response techniques. These authentication methods are used to establish, at the end of Phase 1, an IKE SA which is unidirectionally authenticated. To make this IKE bi-directionally authenticated, this Phase 1 is immediately followed by an X-Auth Exchange [XAUTH]. The X-Auth Exchange is used to authenticate the remote User. The use of these authentication methods is referred to as Hybrid Authentication mode. This proposal is designed to provide a solution for environments where a legacy authentication system exists, yet a full public key infrastructure is not deployed. "A Framework for Group Key Management for Multicast Security", Naganand Doraswamy, Brad Cain, Thomas Hardjono, 08/15/2000, <draft-ietf-ipsec-gkmframework-03.txt> This document provides a framework for group key management for multicast security, motivated by three main considerations, namely the multicast application, scalability and trust-relationships among entities. It introduces two planes corresponding to the network entities and functions important to multicasting and to security. The key management plane consists of two hierarchy-levels in the form of a single 'trunk region' (inter-region) and one or more 'leaf regions' (intra-region). The advantages of the framework among others are that it is scalable, it has reduced complexity and allows the independence in regions of group key management. "A PKIX Profile for IKE", C. Kunzinger, Rodney Thayer, Paul Hoffman, 07/11/2000, <draft-ietf-ipsec-pki-req-05.txt> The IKE protocol allows the use of the PKIX profile of X.509v3 certificates for encryption and authentication. Common practice in the IPsec community differs in some ways from these specifications made in the PKIX format specification and other specifications that have come from the PKIX WG. In order to promote interoperability in the IPsec market, this document lays out a profile for using PKIX in IKE. "Intra-Domain Group Key Management Protocol", Brad Cain, Indermohan Monga, Thomas Hardjono, 02/23/2000, <draft-ietf-ipsec-intragkm-02.txt> This document describes a protocol for intra-domain group key management for IP multicast security, based on the framework of [HCD99]. In order to support multicast groups, the domain is divided into a number of administratively-scoped 'areas'. A host-member of a multicast group is defined to reside within one (and only one) of these areas. The purpose of placing host-members in areas is to achieve flexible and efficient key management, particularly in the face of the problem of changes (joining, leaving, ejections) in the membership of a multicast group. A separate administratively-scoped area control-group is defined for each (data) multicast group, for the express purpose of key management and other control-message delivery. "IPSec Monitoring MIB", J. Shriver, Tim Jenkins, 07/13/2000, <draft-ietf-ipsec-monitor-mib-03.txt> This document defines low level monitoring and status MIBs for IPsec security associations (SAs). It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec. Further, it does not provide policy information. The purpose of the MIBs is to allow system administrators to determine operating conditions and perform system operational level monitoring of the IPsec portion of their network. Statistics are provided as well. Additionally, it may be used as the basis for application specific MIBs for specific uses of IPsec SAs. "IPsec DOI Textual Conventions MIB", J. Shriver, 06/14/2000, <draft-ietf-ipsec-doi-tc-mib-03.txt> This memo defines textual conventions for use in monitoring, status, and configuration MIBs for IPSec. It includes a MIB module that defines those textual conventions. "IPsec Interactions with ECN", K.K. Ramakrishnan, Sally Floyd, David Black, 12/08/1999, <draft-ietf-ipsec-ecn-02.txt> 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. "Additional ECC Groups For IKE", Prakash Panjwani, Yuri Poeluev, 06/01/2000, <draft-ietf-ipsec-ike-ecc-groups-02.txt> This document describes new ECC groups for use in IKE [IKE] in addition to the Oakley groups included therein. These groups are defined to align IKE with other ECC implementations and standards, and in addition, some of them provide higher strength than the Oakley groups. It should be noted that this document is not self-contained. It uses the notations and definitions of [IKE]. "ISAKMP DOI-Independent Monitoring MIB", J. Shriver, Tim Jenkins, 07/13/2000, <draft-ietf-ipsec-isakmp-di-mon-mib-02.txt> This document defines a DOI (domain of interpretation) independent monitoring MIB for ISAKMP. The purpose of this MIB is to be used as the basis for protocol specific MIBs that use ISAKMP as the basis for key exchanges or security association negotiation. As such, it has no DOI-dependent objects. "Content Requirements for ISAKMP Notify Messages", Tero Kivinen, Scott Kelly, 07/06/2000, <draft-ietf-ipsec-notifymsg-03.txt> The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status message types for use in ISAKMP NOTIFY messages, but in some cases do not specify that any additional clarifying data be carried in the messages. In these cases, it is difficult to determine which SA corresponds to the received NOTIFY message. While the DOI RFC specifies content and formats for additional data in the currently defined IPSEC status messages, no such requirements are currently specified for ISAKMP NOTIFY messages. This document provides content and format recommendations for those messages. "IKE Base Mode", Sara Bitan, Yael Dayan, 01/19/2000, <draft-ietf-ipsec-ike-base-mode-02.txt> This document describes a new Phase I mode for IKE [RFC-2409] based on the ISAKMP [RFC-2408] Base Exchange. The purpose of this new exchange is to allow support of all authentication methods with fixed and non-fixed IP addresses, while offering protection against a denial of service attack aimed at costly operations. It also enables negotiation capabilities beyond those offered by Aggressive Mode (DH/EC group). The exchange consists of only four messages and therefor is useful when performance is crucial. "IKE Monitoring MIB", J. Shriver, Tim Jenkins, 07/13/2000, <draft-ietf-ipsec-ike-monitor-mib-01.txt> This document defines monitoring and status MIBs for use when the (Internet Key Exchange) IKE protocol [IKE] is used to create IPsec security associations (SAs). As such, the MIBs provide the linkage between IKE (phase 1) SAs and the IPsec (phase 2) SAs created by those SAs. It does not define MIBs that may be used for configuring IPsec implementations or for providing low-level diagnostic or debugging information. It assumes no specific use of IPsec SAs, except that they were created using IKE. Further, it does not provide policy information. "Fixing IKE Phase 1 & 2 Authentication HASH", Tero Kivinen, 03/08/2000, <draft-ietf-ipsec-ike-hash-revised-01.txt> This document defines new method of calculating the authentication HASH of the IKE [RFC-2409] protocol. It fixes known problems with the IKE. The way the HASH is currently defined in the [RFC-2409] does not authen- ticate the generic ISAKMP [RFC-2408] header, nor does it authenticate any extra payloads inside phase 1 packets. This causes a security prob- lem when using extra payloads as already defined in the IKE and DOI [RFC-2407] (vendor ID payload, INITIAL-CONTACT notification etc). This document defines three methods how to negotiate the new HASH method. All methods tries to be backward compatible as much as possible. Only one of those methods must be selected by the working group and all the other should be removed from this document. There is also suggestion how to fix the Phase 2 authentication hashes so that they will also authenti- cate the generic ISAKMP header. "OpenPGP Key Usage in IKE", Will Price, 01/07/2000, <draft-ietf-ipsec-openpgp-00.txt> This document defines a profile for the usage of OpenPGP keys within the IKE [IKE] protocol. The ISAKMP [ISAKMP] protocol on which IKE is based defines an identifier for the use of OpenPGP [OPENPGP] keys, but does not define how they should be used. "Using Isakmp Heartbeats for Dead Peer Detection", Tero Kivinen, Andrew Krywaniuk, 07/21/2000, <draft-ietf-ipsec-heartbeats-01.txt> This document describes a method for sending heartbeat packets (sometimes called keep-alives) across an ISAKMP SA in order to detect when a peer has crashed or has become otherwise unreachable. A method for negotiating the heartbeat parameters is also provided. "The Candidate AES Cipher Algorithms and Their Use With IPsec ", R. Glenn, Sheila Frankel, Scott Kelly, 03/08/2000, <draft-ietf-ipsec-ciph-aes-cbc-00.txt> This document describes the use of the AES Cipher Algorithms in Ci- pher Block Chaining Mode, with an explicit IV, as a confidentiality mechanism within the context of the IPsec Encapsulating Security Pay- load (ESP). This Internet Draft specifies the use of each of the 5 AES finalist candidates in the ESP Header. Once the AES cipher is chosen, this document will be changed to reflect that choice. "IKE Authentication Using ECDSA", P. Fahn, 03/09/2000, <draft-ietf-ipsec-ike-auth-ecdsa-00.txt> This document describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the Internet Key Exchange (IKE) protocol. ECDSA provides authentication and non-repudiation with benefits of computational efficiency, small signature sizes, and minimal bandwidth, compared to other available digital signature methods. This document adds ECDSA capability to IKE without introducing any changes to existing IKE operation. "More MODP Diffie-Hellman groups for IKE", Tero Kivinen, Markku Kojo, 10/16/2000, <draft-ietf-ipsec-ike-modp-groups-00.txt> This document defines new MODP groups for the IKE [RFC-2409] protocol. It documents the well know and used 1536 bit group 5, and also defines new 2048, 3072, and 4096 bit Diffie-Hellman groups. The groups are gen- erated using the guidelines defined in the [RFC-2412]. IP Security Policy (ipsp)------------------------- "Security Policy Specification Language", Charles Lynn, John Zao, Matt Condell, 03/09/2000, <draft-ietf-ipsp-spsl-00.txt> This document describes the Security Policy Specification Language (SPSL), a language designed to express security policies, security domains, and the entities that manage the policies and domains. The syntax and semantics of the language are presented here. SPSL currently supports policies for packet filtering, IP Security (IPsec), and IKE exchanges. However, it may easily be extended to express other types of policies. "IPsec Configuration Policy Model", Jamie Jason, 07/12/2000, <draft-ietf-ipsp-config-policy-model-01.txt> This document presents an object-oriented model of IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [IKE] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [COMP, ESP, AH, DOI]. It is based upon the core policy classes as defined in the Policy Core Information Model (PCIM) [PCIM]. "Security Policy Protocol ", Luis Sanchez, Matt Condell, 07/12/2000, <draft-ietf-ipsp-spp-00.txt> This document describes a protocol for discovering, accessing and processing security policy information of hosts, subnets or networks of a security domain. The Security Policy Protocol defines how the policy information is exchanged, processed, and protected by clients and servers. The protocol is extensible and flexible. It allows the exchange of complex policy objects between clients and servers. "IPsec Policy Architecture", Angelos Keromytis, Luis Sanchez, Matt Blaze, Michael Richardson, 07/18/2000, <draft-ietf-ipsp-arch-00.txt> 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. "IPSP Requirements", Angelos Keromytis, Luis Sanchez, Matt Blaze, Michael Richardson, 07/20/2000, <draft-ietf-ipsp-requirements-00.txt> This document describes the problem and solution requirements for the IPsec Policy Protocol. "IPSec Policy Information Base ", Avri Doria, David Arneson, Jamie Jason, Man Li, 07/21/2000, <draft-ietf-ipsp-ipsecpib-00.txt> This document specifies a set of policy rule classes (PRC) for configuring IPSec services. Instances of these classes reside in a virtual information store called IPSec Policy Information Base (PIB). The COPS protocol [COPS] with the extensions for provisioning [COPS- PR] may be used to transmit this IPSec policy information to IPSec- enabled devices (e.g., gateways) in order to configure VPN services. The PRCs defined in this IPSec PIB are intended for use by the COPS- PR IPSec client type. They complement the PRCs defined in the Framework PIB [FR-PIB]. "A Roadmap for IPsec Policy Management", Hilarie Orman, Luis Sanchez, 10/06/2000, <draft-ietf-ipsp-roadmap-00.txt> This document describes the approach that the IPSP WG will follow to resolve the challenges that IPsec compliant devices phase with respect to modeling, specifying, translating, provisioning, exchanging, negotiating, checking and enforcing IPsec policies. IP Security Remote Access (ipsra)--------------------------------- "Requirements for IPsec Remote Access Scenarios", Scott Kelly, Sankar Ramamoorthi, 07/21/2000, <draft-ietf-ipsra-reqmts-01.txt> IPsec offers much promise as a secure remote access mechanism. However, there are a significant number of remote access scenarios, each having some shared and some unique requirements. A thorough understanding of these requirements is necessary in order to effectively evaluate the suitability of a specific set of mechanisms for any particular remote access scenario. This document enumerates the requirements for a number of common remote access scenarios. "PIC, A Pre-IKE Credential Provisioning Protocol", H. Krawczyk, Yaron Sheffer, 09/01/2000, <draft-ietf-ipsra-pic-01.txt> This document presents a method to bootstrap IPSec authentication via an 'Authentication Server' (AS) and legacy user authentication (e.g., RADIUS). The client machine communicates with the AS using a key exchange protocol authenticated by the server only, and the derived keys are used to protect the legacy user authentication. Once the user is authenticated, the client machine obtains credentials from the AS that can be later used to authenticate the client in a standard IKE exchange with an IPSec-enabled security gateway. The later stage does not require user intervention. The proposed server- authenticated key exchange uses an ISAKMP-based protocol, similar to a simplified IKE exchange, and arbitrary legacy authentication is supported via the use of the standard EAP protocol. IP Telephony (iptel)-------------------- "CPL: A Language for User Control of Internet Telephony Services", H. Schulzrinne, Jonathan Lennox, 07/24/2000, <draft-ietf-iptel-cpl-02.txt,.ps> The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. "Telephony Routing over IP (TRIP)", Jonathan Rosenberg, Matt Squire, Hussein Salama, 07/17/2000, <draft-ietf-iptel-trip-03.txt> 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. IS-IS for IP Internets (isis)----------------------------- "Three-Way Handshake for IS-IS Point-to-Point Adjacencies", D Katz, Rajesh Saluja, 07/14/2000, <draft-ietf-isis-3way-03.txt> 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. "Management Information Base for IS-IS", Jeff Parker, 06/28/2000, <draft-ietf-isis-wg-mib-03.txt> 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. "Optional Checksums in ISIS", Antoni Przygienda, 07/11/2000, <draft-ietf-isis-wg-snp-checksum-02.txt> This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. "IS-IS Cryptographic Authentication", R. Atkinson, Tony Li, 04/11/2000, <draft-ietf-isis-hmac-01.txt> This document specifies an algorithm-independent cryptographic authentication mechanism for use with the IS-IS routing protocol. "IS-IS extensions for Traffic Engineering", Tony Li, Henk Smit, 09/05/2000, <draft-ietf-isis-traffic-02.txt> This document describes extensions to the IS-IS protocol to support Traffic Engineering [1]. The IS-IS protocol is specified in [2], with extensions for supporting IPv4 specified in [3]. This document extends the IS-IS protocol by specifying new information that a Intermediate System (IS) [router] can place in Link State Protocol Data Units (LSPs). This information describes additional information about the state of the network that is useful for traffic engineering computations. "Extended Ethernet Frame Size Support", Jennifer Hsu, Jed Kaplan, Mike O'Dell, John Hayes, Ted Schroeder, P.J. Singh, Daemon Morrell, 05/26/2000, <draft-kaplan-isis-ext-eth-02.txt> This document presents an extension to current Ethernet Frame standards to support payloads greater than 1500 Bytes for Ethernet_II and 802.3 frames. This is useful for Gigabit Ethernet technology, providing a means to carry large MTU packets without fragmentation over a high-speed broadcast network. "Routing IPv6 with IS-IS", Chris Hopps, 07/12/2000, <draft-ietf-isis-ipv6-01.txt> This draft specifies a method for exchanging IPv6 routing information using the IS-IS routing protocol [0]. The method utilizes the same mechanisms described in RFC 1195 [1]. This is accomplished by adding 2 new TLVs and defining their use. These new TLVs are patterned from the ones described in 'IS-IS extensions for Traffic Engineering' [2]. Just as in RFC 1195 [1] with IPv4 and OSI, this method allows one to route both IPv4 and IPv6 using a single intra-domain routing protocol. "IS-IS Extensions in Support of Generalized MPLS", Y Rekhter, E. Mannie, John Drake, Debanjan Saha, Don Fedyk, Kireeti Kompella, Vishal Sharma, Greg Bernstein, Ayan Banerjee, 09/14/2000, <draft-ietf-isis-gmpls-extensions-00.txt> This document specifies extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (previously known as Multi-Protocol Lambda Switching). Integrated Services over Specific Link Layers (issll)----------------------------------------------------- "A Framework For Integrated Services Operation Over Diffserv Networks", Lixia Zhang, R. Yavatkar, Fred Baker, Bruce Davie, Peter Ford, Bob Braden, John Wroclawski, M. Speer, Y. Bernet, Eyal Felstaine, 05/24/2000, <draft-ietf-issll-diffserv-rsvp-05.txt> The Integrated Services architecture provides a means for the delivery of end-to-end QoS to applications over heterogeneous networks. To support this end-to-end model, the Intserv architecture must be supported over a wide variety of different types of network elements. In this context, a network that supports Differentiated Services (Diffserv) may be viewed as a network element in the total end-to-end path. This document describes a framework by which Integrated Services may be supported over Diffserv networks. "Format of the RSVP DCLASS Object", Y. Bernet, 10/27/1999, <draft-ietf-issll-dclass-01.txt> RSVP signaling may be used to request QoS services and enhance the manageability of application traffic's QoS in a differentiated service (diff-serv or DS) network. When using RSVP with DS networks it is useful to be able to carry carry Differentiated Services Code Points (DSCPs) in RSVP message objects. One example of this is the use of RSVP to arrange for the marking of packets with a particular DSCP upstream from the DS network's ingress point, at the sender or at a previous network's egress router. The DCLASS object is used to represent and carry DSCPs within RSVP messages. This draft specifies the format of the DCLASS object and briefly discusses its use. "Specification of the Null Service Type", Bruce Davie, Andrew Smith, Y. Bernet, 09/15/1999, <draft-ietf-issll-nullservice-00.txt> In the typical RSVP/Intserv model, applications request a specific Intserv service type and quantify the resources required for that service. For certain applications, the determination of service parameters is best left to the discretion of the network administrator. For example, ERP applications are often mission critical and require some form of prioritized service, but cannot readily specify their resource requirements. To serve such applications, we introduce the notion of the 'Null Service'. The Null Service allows applications to identify themselves to network QoS policy agents, using RSVP signaling. However, it does not require them to specify resource requirements. QoS policy agents in the network respond by applying QoS policies appropriate for the application (as determined by the network administrator). This mode of RSVP usage is particularly applicable to networks that combine differentiated service (diffserv) QoS mechanisms with RSVP signaling [intdiff]. In this environment, QoS policy agents may direct the signaled application's traffic to a particular diffserv class of service. "RSVP Reservations Aggregation", Fred Baker, Bruce Davie, Francois Le Faucheur, Carol Iturralde, 03/13/2000, <draft-ietf-issll-rsvp-aggr-02.txt> A key problem in the design of RSVP version 1 is, as noted in its applicability statement, that it lacks facilities for aggregation of individual reserved sessions into a common class. The use of such aggregation is required for scalability. This document describes the use of a single RSVP reservation to aggregate other RSVP reservations across a transit routing region, in a manner conceptually similar to the use of Virtual Paths in an ATM network. It proposes a way to dynamically create the aggregate reservation, classify the traffic for which the aggregate reservation applies, determine how much bandwidth is needed to achieve the requirement, and recover the bandwidth when the sub-reservations are no longer required. It also contains recommendations concerning algorithms and policies for predictive reservations. "Integrated Service Mappings for Differentiated Services Networks", John Wroclawski, Anna Charny, 03/15/2000, <draft-ietf-issll-ds-map-00.txt> This document describes mappings of IETF Integrated Services onto IETF differentiated services networks. These mappings allow appropriately engineered and configured differentiated service network clouds to play the role of 'network elements' in the Integrated Services framework, and thus to be used as components of an overall end-to-end Integrated Services QoS solution. "Capability Negotiation: The RSVP CAP Object", Syed Hamid, 09/11/2000, <draft-ietf-issll-rsvp-cap-00.txt> The DCLASS object is proposed in [DCLASS] to represent and carry Differentiated Services Code Points (DSCPs) within RSVP messages. The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. A network element in the DS network determines the value for DSCP which is further carried as a DCLASS object in RSVP RESV message to the sender host. Kerberized Internet Negotiation of Keys (kink)---------------------------------------------- "Kerberized Internet Negotiation of Keys", Michael Thomas, 10/05/2000, <draft-ietf-kink-reqmt-00.txt> The KINK working group is chartered to create a standards track protocol to facilitate centralized key management for IPsec security associations as defined in RFC 2401, as an alternative to IKE (RFC 2409). Participating systems will use the Kerberos architecture as defined in RFC 1510 (and its successors) for key management. The goal of the working group is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. The working group will not require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). "Kerberized Internet Negotiation of Keys (KINK)", M. Thomas, M. Hur, Sasha Medvinsky, David McGrew, Mike Froh, J Vilhuber, 10/05/2000, <draft-ietf-kink-kink-00.txt> The KINK Working Group will create a standards track protocol to facilitate centralized key exchange in an application independent fashion. Participating systems will use the Kerberos architecture as defined in RFC 1510 for key management and the KINK protocol between applications. The goal of KINK is to produce a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol that is flexible enough to be able to be extended for many applications. Kerberos WG (krb-wg)-------------------- "Public Key Cryptography for Initial Authentication in Kerberos", John Wray, J Trostle, M. Hur, A. Medvinsky, Sasha Medvinsky, 07/20/2000, <draft-ietf-cat-kerberos-pk-init-12.txt> This document defines extensions (PKINIT) to the Kerberos protocol specification (RFC 1510 [1]) to provide a method for using public key cryptography during initial authentication. The methods defined specify the ways in which preauthentication data fields and error data fields in Kerberos messages are to be used to transport public key data. "Public Key Cryptography for Cross-Realm Authentication in Kerberos", G. Tsudik, Clifford Neuman, Bill Sommerfeld, Brian Tung, M. Hur, T. Ryutov, A. Medvinsky, 04/06/2000, <draft-ietf-cat-kerberos-pk-cross-06.txt> This document defines extensions to the Kerberos protocol specification [1] to provide a method for using public key cryptography to enable cross-realm authentication. The methods defined here specify the way in which message exchanges are to be used to transport cross-realm secret keys protected by encryption under public keys certified as belonging to KDCs. "Public Key Utilizing Tickets for Application Servers (PKTAPP)", Clifford Neuman, M. Hur, A. Medvinsky, Alexander Medvinsky, 07/21/2000, <draft-ietf-cat-kerberos-pk-tapp-03.txt> Public key based Kerberos for Distributed Authentication[1], (PKDA) proposed by Sirbu & Chuang, describes PK based authentication that eliminates the use of a centralized key distribution center while retaining the advantages of Kerberos tickets. This draft describes how, without any modification, the PKINIT specification[2] may be used to implement the ideas introduced in PKDA. The benefit is that only a single PK Kerberos extension is needed to address the goals of PKINIT & PKDA. "The Kerberos Network Authentication Service (V5)", Theodore Ts''o, Clifford Neuman, George Kohl, 07/21/2000, <draft-ietf-cat-kerberos-revisions-06.txt> This document provides an overview and specification of Version 5 of the Kerberos protocol, and updates RFC1510 to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC1510. This document is intended to provide a detailed description of the protocol, suitable for implementation, together with descriptions of the appropriate use of protocol messages and fields within those messages. This document is not intended to describe Kerberos to the end user, system administrator, or application developer. Higher level papers describing Version 5 of the Kerberos system [NT94] and documenting version 4 [SNS88], are available elsewhere. "Initial Authentication and Pass Through AuthenticationUsing Kerberos V5 and the GSS-API (IAKERB)", J Trostle, Michael Swift, 07/24/2000, <draft-ietf-cat-iakerb-04.txt> This document defines an extension to the Kerberos protocol specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for services where: (1) The client knows its principal name and password, but not its realm name (applicable in the situation where a user is already on the network but needs to authenticate to an ISP, and the user does not know his ISP realm name). (2) The client is able to obtain the IP address of the service in a realm which it wants to send a request to, but is otherwise unable to locate or communicate with a KDC in the service realm or one of the intermediate realms. (One example would be a dial up user who does not have direct IP connectivity). (3) The client does not know the realm name of the service. "The Kerberos Version 5 GSSAPI Mechanism, Version 2", Tom Yu, 03/06/2000, <draft-ietf-cat-krb5gss-mech2-03.txt> 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. "Distributing Kerberos KDC and Realm Information with DNS", Ken Hornstein, Jeffrey Altman, 03/14/2000, <draft-ietf-cat-krb-dns-locate-02.txt> Neither the Kerberos V5 protocol [RFC1510] nor the Kerberos V4 proto- col [RFC????] describe any mechanism for clients to learn critical configuration information necessary for proper operation of the pro- tocol. Such information includes the location of Kerberos key dis- tribution centers or a mapping between DNS domains and Kerberos realms. "Kerberos Set/Change Password: Version 2", John Brezak, J Trostle, Michael Swift, Bill Gossman, 04/19/2000, <draft-ietf-cat-kerberos-set-passwd-03.txt> The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), does not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal extends [4] to allow password setting. The changes are: adding new fields to the request message to indicate the principal which is having its password set, not requiring the initial flag in the service ticket, using a new protocol version number, and adding three new result codes. We also extend the set/change protocol to allow a client to send a sequence of keys to the KDC instead of a cleartext password. If in the cleartext password case, the cleartext password fails to satisfy password policy, the server should use the result code KRB5_KPASSWD_POLICY_REJECT. Layer Two Tunneling Protocol Extensions (l2tpext)------------------------------------------------- "L2TP Session Information (``SESINFO'')", William Palter, 02/28/2000, <draft-ietf-l2tpext-sesinfo-01.txt> The Layer 2 Tunneling Protocol ('L2TP') [1] defines a mechanism for tunneling PPP sessions. The current RFC is lacking a way for the LAC to provide the LNS with data about the PPP session which can be useful for accounting and debugging purposes. This is especially a problem when the session transverses several L2TP tunnels before it is finally terminated (sometimes called 'tunnel switching' or 'Multihop'). This draft provides additional AVPs that MAY be used to provide port type and port identication information to the terminating LNS, for accounting and debugging use. "Layer Two Tunnelling Protocol : ATM access network extensions.", Bernard Sales, Paolo Crivellari, Yves T''''Joens, 07/18/2000, <draft-ietf-l2tpext-atmext-03.txt> L2TP [RFC2661] specifies a protocol which permits the tunnelling of the link layer of PPP over packet based networks, to support remote access (mainly) by ISDN and PSTN networks. This document augments the procedures described in [RFC2661] to further support ATM SVC or PVC based access networks. The extensions defined within this document allow for asymmetric bi-directional call establishment and service selection in the ATM access network. "L2TP Over AAL5 and FUNI", A. Lin, Michael Davison, J. Stephens, Rene Tio, Ajoy Singh, Rollins Turner, Janakiraman Senthilnathan, 07/19/2000, <draft-ietf-l2tpext-l2tp-atm-01.txt> The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for transporting the link layer of PPP [2] between a dial-up server and a Network Access Server, using a network connection in lieu of a physical point to point connection. This document describes the use of an ATM network for the underlying network connection. Both ATM UNI [3] with ATM Adaptation Layer 5 [4] (AAL5) and ATM with Frame based User-to-Network Interface (FUNI) [5] are supported as interfaces to the ATM network. "L2TP Header Compression ('L2TPHC')", A. Valencia, 06/28/2000, <draft-ietf-l2tpext-l2tphc-02.txt> The Layer 2 Tunneling Protocol ('L2TP') [RFC2661] defines a mechanism for tunneling PPP sessions over arbitrary media. There exists a class of specific media applications for which protocol overhead may be optimized, and where such reduction results in improved operation. This document describes the solution space addressed, its underlying motivations, and the protocol modifications required. The enhancement to the L2TP protocol is called L2TP Header Compression, or 'L2TPHC'. "Securing L2TP using IPSEC", Bernard Aboba, Glen Zorn, B. Patel, Skip Booth, William Dixon, 08/09/2000, <draft-ietf-l2tpext-security-01.txt> This document discusses how L2TP may utilize IPSEC to provide for tunnel authentication, privacy protection, integrity checking and replay protection. Both the voluntary and compulsory tunneling cases are discussed. "Layer Two Tunneling Protocol 'L2TP' IP Differentiated Services Extension", Ken Peirce, Pat Calhoun, 03/03/2000, <draft-ietf-l2tpext-ds-00.txt> The L2TP document [1] defines the base protocol which describes the method of tunneling PPP data. The L2TP base protocol does not address any Differentiated Services extensions. The ability to outsource dial access with Quality of Service assurances is important to internet applications development. This draft addresses this issue by allowing each L2TP Data Session to be assigned an appropriate differentiated services indicator. "Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension ", Ken Peirce, Pat Calhoun, 03/03/2000, <draft-ietf-l2tpext-mpls-00.txt> The L2TP document [1] defines the base protocol which describes the method of tunneling PPP data. The L2TP base protocol does not address any MPLS extensions. The goal of MPLS is to speed forwarding of packets by reducing the lookup required in routing. This draft proposes a method to allow L2TP Data Sessions to be assigned an MPLS Label Switched Path Id (LSPID)[3] for an explicit route (ER). Assignment of such an ER is necessary for traffic engineering. "Layer Two Tunneling Protocol 'L2TP' Management Information Base ", Evan Caves, Pat Calhoun, Ross Wheeler, 03/07/2000, <draft-ietf-l2tpext-l2tp-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using Layer 2 Tunneling Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. "L2TP Disconnect Cause Information", James Carlson, Rohit Verma, Madhvi Verma, 06/01/2000, <draft-ietf-l2tpext-ppp-discinfo-00.txt> The Layer 2 Tunneling Protocol ('L2TP') defines a mechanism for tunneling PPP sessions. The current RFC lacks a mechanism for the LNS to provide PPP related disconnect cause information to the LAC. This information, provided by the extension described in this document, can be useful for accounting and debugging purposes. "Layer Two Tunneling Protocol (L2TP) over Frame Relay", Rene Tio, Rohit Verma, Vipin Rawat, 07/18/2000, <draft-ietf-l2tpext-fr-00.txt> Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over Frame Relay PVCs and SVCs. "Layer Two Tunneling Protocol 'L2TP'", Allan Rubens, Glen Zorn, G. Pall, A. Valencia, W. Mark Townsley, B Palter, 07/19/2000, <draft-ietf-l2tpext-l2tpbis-00.txt> This document describes the Layer Two Tunneling Protocol (L2TP). RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP facilitates the tunneling of PPP packets across an intervening network in a way that is as transparent as possible to both end-users and applications "L2TP Service Type ", Danny McPherson, Suhail Nanji, 09/27/2000, <draft-ietf-l2tpext-svctype-00.txt> The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a standard method for tunneling PPP [RFC 1661] packets. This document describes an extension to L2TP which provides a mechanism to support tunneling of additional payload types over individual sessions within an L2TP tunnel. These extensions provide added functionality which is optional and preserves backwards compatibility. LDAP Extension (ldapext)------------------------ "The Java LDAP Application Program Interface", Tim Howes, Mark Smith, R. Weltman, Christine Tomlinson, Jim Sermersheim, Miodrag Kekic, 07/17/2000, <draft-ietf-ldapext-ldap-java-api-11.txt> This document defines a Java language application program interface to the lightweight directory access protocol (LDAP), in the form of a class library. It complements but does not replace RFC 1823 ([7]), which describes a C language application program interface. It updates the previous draft in correcting a few minor errors which are listed in appendix B. It also includes the asynchronous layer of the API which was previously defined in draft-ietf-ldapext-ldap-java-api- asynch [10]. "Persistent Search: A Simple LDAP Change Notification Mechanism", Tim Howes, Mark Smith, G. Good, R. Weltman, 03/07/2000, <draft-ietf-ldapext-psearch-02.txt> This document defines two controls that extend the LDAPv3 [LDAP] search operation to provide a simple mechanism by which an LDAP client can receive notification of changes that occur in an LDAP server. The mechanism is designed to be very flexible yet easy for clients and servers to implement. Since the IETF is likely to pursue a different, more comprehensive solution in this area, this document will eventually be published with Informational status in order to document an existing practice. "LDAP Extensions for Scrolling View Browsing of Search Results", A Anantha, David Boreham, Jim Sermersheim, Michael Armijo, 04/11/2000, <draft-ietf-ldapext-ldapv3-vlv-04.txt> 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. "Access Control Model for LDAP", B. Blakley, E. Stokes, Debbie Byrne, D Rinkevich, 07/19/2000, <draft-ietf-ldapext-acl-model-06.txt> This document describes the access control model for the Lightweight Directory Application Protocol V3 (LDAPv3) directory service. It includes a description of the model, the LDAP controls, and the extended operations to the LDAP protocol. The current LDAP APIs are sufficient for most access control operations. An API (in a separate document) is needed for the extended operation getEffectiveAccess. A separate requirements document for access control exists [REQTS]. The access control model used the requirements documents as a guideline for the development of this specification and are reflected in this specification to the extent that the working group could agree on an access control model. "X.509 Authentication SASL Mechanism", Steve Kille, 02/24/2000, <draft-ietf-ldapext-x509-sasl-03.txt> This document defines a SASL [1] authentication mechanism based on X.509 strong authentication [3], providing two way authentication. This mechanism is only for authentication, and has no effect on the protocol encodings and is not designed to provide integrity or confidentiality services. "LDAP Control for a Duplicate Entry Representation of Search Results", Jim Sermersheim, 07/12/2000, <draft-ietf-ldapext-ldapv3-dupent-04.txt> This document describes a Duplicate Entry Representation control extension for the LDAP Search operation. By using the control with an LDAP search, a client requests that the server return separate entries for each value held in the specified attributes. For instance, if a specified attribute of an entry holds multiple values, the search operation will return multiple instances of that entry, each instance holding a separate single value in that attribute. "Returning Matched Values with LDAPv3", David Chadwick, Sean Mullan, 10/16/2000, <draft-ietf-ldapext-matchedval-04.txt> This document describes a control for the Lightweight Directory Access Protocol v3 that is used to return a subset of attribute values from an entry, specifically, only those values that match a 'values return' filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally. "A Taxonomoy of Methods for LDAP Clients Finding Servers", Roland Hedberg, R. Moats, 10/09/2000, <draft-ietf-ldapext-ldap-taxonomy-04.txt> There are several different methods for a LDAP client to find a LDAP server. This draft discusses these methods and provides pointers for interested parties to learn more about implementing a particular method. "Discovering LDAP Services with DNS", P Leach, Michael Armijo, Levon Esibov, R Morgan, 08/29/2000, <draft-ietf-ldapext-locate-04.txt> A Lightweight Directory Access Protocol (LDAP) request must be directed to an appropriate server for processing. This document specifies a method for discovering such servers using information in the Domain Name System. "Connection-less Lightweight Directory Access Protocol", Roland Hedberg, Leif Johasson, 05/31/2000, <draft-ietf-ldapext-cldap-00.txt> This memo describes modifications to LDAP version 3[1] to allow transport of a subset of the LDAP protocol over connection-less transport. The case of UDP/IP is covered in detail in this memo but other transport layers are possible. "Referrals in LDAP Directories", Roland Hedberg, 07/13/2000, <draft-ietf-ldapext-refer-00.txt> This document defines two reference attributes and associated 'referral' object class for representing generic knowledge information in LDAP directories [RFC2251]. The attribute uses URIs [RFC1738] to represent knowledge, enabling LDAP and non-LDAP services alike to be referenced. The object class can be used to construct entries in an LDAP directory containing references to other directories or services. This document also defines procedures directory servers should follow when supporting these schema elements and when responding to requests for which the directory server does not contain the requested object but may contain some knowledge of the location of the requested object. LDAP Duplication/Replication/Update Protocols (ldup)---------------------------------------------------- "LDUP Update Reconciliation Procedures", Steven Legg, A Payne, 07/05/2000, <draft-ietf-ldup-urp-03.txt> This document describes the procedures used by directory servers to reconcile updates performed by autonomously operating directory servers in a distributed, replicated directory service. "LDAPv3 Replication Requirements", R. Moats, E. Stokes, R. Weiser, Richard Huber, 09/13/2000, <draft-ietf-ldup-replica-req-04.txt> This document discusses the fundamental requirements for replication of data accessible via the LDAPv3 [RFC2251] protocol. It is intended to be a gathering place for general replication requirements needed to provide interoperability between informational directories. "LDAP Replication Architecture", Ed Reed, U. Srinivasan, John Merrells, 07/10/2000, <draft-ietf-ldup-model-04.txt> This architectural document outlines a suite of schema and protocol extensions to LDAPv3 that enables the robust, reliable, server-to-server exchange of directory content and changes. "LDUP Replication Information Model", Ed Reed, 03/16/2000, <draft-ietf-ldup-infomod-01.txt> [LDUP Model] describes the architectural approach to replication of LDAP directory contents. This document describes the information model and schema elements which support LDAP Replication Services which conform to [LDUP Model]. Directory schema is extended to provide object classes, subentries, and attributes to describe areas of the namespace which are under common administrative authority, units of replication (ie, subtrees, or partitions of the namespace, which are replicated), servers which hold replicas of various types for the various partitions of the namespace, which namespaces are held on given servers, and the progress of various namespace management and replication operations. Among other things, this knowledge of where directory content is located will provide the basis for dynamic generation of LDAP referrals for clients who can follow them. "LDAP Subentry Schema", Ed Reed, 07/14/2000, <draft-ietf-ldup-subentry-03.txt> This document describes an object class called ldapSubEntry which MAY be used to indicate operations and management related entries in the directory, called LDAP Subentries. This version of this document is updated with an assigned OID for the ldapSubEntry object class. "The LDUP Replication Update Protocol", G. Good, E. Stokes, 07/20/2000, <draft-ietf-ldup-protocol-02.txt> The protocol described in this document is designed to allow one LDAP server to replicate its directory content to another LDAP server. The protocol is designed to be used in a replication configuration where multiple updatable servers are present. Provisions are made in the protocol to carry information that allows the server receiving updates to apply a total ordering to all updates in the replicated system. This total ordering allows all replicas to correctly resolve conflicts that arise when LDAP clients submit changes to different servers that later replicate to one another. All protocol elements described here are LDAP Version 3 extended operations. LDAP Version 3 is described in RFC 2251 [LDAPv3]. "Extended Operations for Framing LDAP Operations", G. Good, E. Stokes, Rod Harrison, 03/17/2000, <draft-ietf-ldup-framing-00.txt> 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]. Multicast-Address Allocation (malloc)------------------------------------- "Multicast Address Allocation MIB", Dave Thaler, 07/10/2000, <draft-ietf-malloc-malloc-mib-03.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing multicast address allocation. "Multicast Address Allocation Protocol (AAP)", Mark Handley, Steve Hanna, 06/29/2000, <draft-ietf-malloc-aap-04.txt> The document defines a Multicast Address Allocation Protocol (AAP) that forms a part of the Internet Multicast Address Allocation Architecture being defined by the IETF Multicast Address Allocation Working Group. AAP addresses the specific issue of coordination among Multicast Address Allocation Servers within a domain. "Dynamic Allocation Guidelines for IPv6 Multicast Addresses", Brian Haberman, 07/13/2000, <draft-ietf-malloc-ipv6-guide-01.txt> This document specifies guidelines to be used when allocating IPv6 multicast addresses. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the MAC layer of media that utilizes IEEE 802 addressing. Mobile Ad-hoc Networks (manet)------------------------------ "Ad Hoc On Demand Distance Vector (AODV) Routing", Santanu Das, C Perkins, Elizabeth Royer, 07/19/2000, <draft-ietf-manet-aodv-06.txt> 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. "On-Demand Multicast Routing Protocol (ODMRP) for Ad-Hoc Networks", Mario Gerla, Sung-Ju Lee, William Su, 01/05/2000, <draft-ietf-manet-odmrp-02.txt> On-Demand Multicast Routing Protocol (ODMRP) is a multicast routing protocol designed for ad-hoc networks with mobile hosts. ODMRP is a mesh-based, rather than a conventional tree-based, multicast scheme and uses a Forwarding Group concept (only a subset of nodes forwards the multicast packets via scoped flooding). It applies on-demand procedures to dynamically set up routes and maintain multicast group membership. ODMRP is well suited for ad-hoc wireless networks with mobile hosts where bandwidth is limited, topology changes frequently and rapidly, and power is constrained. "Optimized Link State Routing Protocol", Amir Qayyum, Philippe Jacquet, Paul Muhlethaler, 07/21/2000, <draft-ietf-manet-olsr-02.txt> This document describes the Optimized Link State Routing (OLSR) protocol for mobile ad hoc networks. The protocol is an optimization of the pure link state algorithm tailored to the requirements of a mobile wireless LAN. The key concept used in the protocol is that of multipoint relays (MPRs) [1] & [2]. MPRs are the selected nodes which forward the broadcast packets during the flooding process. This technique substantially reduces the packet overhead as compared to pure flooding mechanism where every node retransmits the packet when it receives the first copy of the packet. In OLSR protocol, the information flooded in the network 'through' these multipoint relays is also 'about' the multipoint relays. Hence, a second optimization is achieved here by minimizing the 'contents' of the control packet flooded in the network. Hence, as contrary to the classic link state algorithm, only a small subset of links with the neighbor nodes are declared instead of all the links. This information is then used by OLSR protocol for route calculation, and therefore the routes contain only the MPRs as the intermediate nodes from Source to Destination. It results in providing the optimal routes (in terms of number of hops), and hence another optimization. The protocol is particularly suitable for the large dense networks as the technique of multipoint relays works well in this context. "Differential Destination Multicast (DDM) Specification", Scott Corson, Lusheng Ji, 07/21/2000, <draft-ietf-manet-ddm-00.txt> This draft describes a multicast routing protocol for mobile ad hoc networks (MANETs). The protocol---termed Differential Destination Multicast (DDM)---differs from common approaches proposed for ad hoc multicast routing in two ways. Firstly, instead of distributing membership control throughout the network, DDM concentrates this authority at the data sources (i.e. senders) thereby giving senders knowledge of group membership. Secondly, differentially-encoded, variable-length destination headers are inserted in data packets which are used in combination with unicast routing tables to forward multicast packets towards multicast receivers. Instead of requiring that multicast forwarding state be stored in participating nodes, this approach also provides the option of stateless multicasting. Each node independently has the choice of maintaining cached forwarding state, or requesting its upstream neighbor to insert this state into self-routed data packets, or some combination thereof. The protocol is best suited for use with small multicast groups operating in dynamic networks of any size. "Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing", C Perkins, Elizabeth Royer, 07/25/2000, <draft-ietf-manet-maodv-00.txt> The multicast operation of the Ad hoc On-Demand Distance Vector (AODV) routing protocol (MAODV) 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, and low network utilization. It creates bi-directional shared multicast trees connecting multicast sources and receivers. These multicast trees are maintained as long as group members exist within the connected portion of the network. Each multicast group has a group leader whose responsibility is maintaining the group sequence number, which is used to ensure freshness of routing information. "Topology Broadcast based on Reverse-Path Forwarding (TBRPF)", Fred Templin, Bhargav Bellur, Richard Ogier, 08/31/2000, <draft-ietf-manet-tbrpf-00.txt> Topology Broadcast based on Reverse-Path Forwarding (TBRPF) is a link-state routing protocol designed for use in a mobile ad-hoc network (MANET) or an internet. TBRPF provides each node with the state of each link in the network, but does so much more efficiently than flooding (e.g., OSPF). TBRPF uses the concept of reverse-path forwarding to efficiently and reliably broadcast each link-state update along the minimum-hop-path tree rooted at the source of the update. The broadcast trees (one tree per source) are updated dynamically using the topology information that is received along the trees themselves, thus requiring very little additional overhead for maintaining the trees. This document describes TBRPF and discusses details for the implementation of TBRPF in IPv4-based MANETs. MBONE Deployment (mboned)------------------------- "Multicast Debugging Handbook", Bernard Aboba, Dave Thaler, 05/08/2000, <draft-ietf-mboned-mdh-04.txt> This document serves as a handbook for the debugging of multicast connectivity problems. In addition to reviewing commonly encountered problems, the draft summarizes publicly distributable multicast diagnostic tools, and provides examples of their use, along with pointers to source and binary distributions. "IP Multicast Applications: Challenges and Solutions", Kevin Almeroth, Bob Quinn, 07/01/1999, <draft-ietf-mboned-mcast-apps-01.txt> This document describes the challenges involved with designing and implementing multicast applications. It is an introductory guide for application developers that highlights the unique considerations of multicast applications as compared to unicast applications. To this end, the document presents a taxonomy of multicast application I/O models and examples of the services they can support. It then describes the service requirements of these multicast applications, and the recent and ongoing efforts to build protocol solutions to support these services. "Anycast RP mechanism using PIM and MSDP", Dino Farinacci, David Meyer, D. Kim, Hank Kilmer, 01/07/2000, <draft-ietf-mboned-anycast-rp-05.txt> This document describes a mechanism to allow for an arbitrary number of RPs per group in a single shared-tree PIM-SM domain. 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 <mboned@ns.uoregon.edu> or the authors. "Connecting Multicast Domains", Brad Cain, 03/02/2000, <draft-ietf-mboned-mcast-connect-00.txt> 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. Media Gateway Control (megaco)------------------------------ "Megaco/H.248 R2 Package", Vikas Bajaj, Sandhip Ranjhan, Prashant Jain, Madhu Babu, Kushanava Laha, 04/11/2000, <draft-ietf-megaco-r2package-01.txt> This document defines a R2 package in association with the MEGACO Protocol that can be used to control a Media Gateway (MG) from an external controller, called a Media Gateway controller (MGC). "Megaco IP Phone Media Gateway Application Profile", Peter Blatherwick, Phil Holland, Robert Bell, 08/25/2000, <draft-ietf-megaco-ipphone-03.txt> This document specifies a particular application of the Megaco/H.248 Protocol [3] for control of Internet telephones and similar appliances: the Megaco IP Phone Media Gateway. The telephone itself is a Media Gateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media Gateway Controller (MGC). To achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of Terminations and Packages, and a Protocol Profile are described. The approach makes use of existing Protocol features and user interface related Packages [4], and is thus a straight-forward application of the Megaco/H.248 Protocol. "MEGACO Packages Not Included In MEGACO/H.248 White Draft", Tim Taylor, Bob Bell, M Kalla, Kieran Hoffmann, Richard Bach, J Mitchell, 01/31/2000, <draft-ietf-megaco-otherpkgs-00.txt> This document is work in progress. It gathers together all packages that have not yet been included in Annex E of Megaco/H.248 White Draft. It proposes additional text for MEGACO/H.248. This document is expected to be used at the Adelaide IETF meeting. "Fax, Modem, Text Telephone Determination using Megaco/H.248", Roy Spitzer, Glenn Parsons, James Rafferty, Gunnar Hellstrom, J Mitchell, 02/04/2000, <draft-ietf-megaco-fmtdeterm-00.txt> This document discusses the dynamic determination of Voice/Modem/FAX/Text Telephone over a single port using Megaco and refers to the packages described for Megaco. The document aims to become an Appendix to Megaco and to be the base for the 'application guide'. "Megaco/H.248 NAS Package", R. Subramaniam, M Kalla, J Mitchell, Alan Whitton, 09/27/2000, <draft-ietf-megaco-naspkg-01.txt> This document is work in progress, intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document [5]. It defines five packages: - the base NAS package contains properties and events supported by all NAS terminations; - the NAS Incoming package contains properties and events supported by NAS terminations involved in calls initiated by the circuit network; - the NAS Outgoing package contains properties supported by NAS terminations involved in calls outgoing to the circuit network; - the NAS Control package contains an event supported by a NAS Control termination, which allows the MG to indicate a request to initiate a data connection to a terminal served by the switched circuit network; - the NAS ROOT package contains properties supported by an MG which is also capable of supporting at least the NAS and NAS Incoming packages. "Megaco Protocol (With erratta folded in)", C Huitema, N Greene, F Cuervo, J Segers, Brian Rosen, Abdallah Rayhan, 06/14/2000, <draft-ietf-megaco-merged-01.txt> This document reflects the application of the changes proposed in draft-ietf-megaco-errata-03.txt to the base protocol document draft- ietf-megaco-protocol-08.txt, plus a number of editorial changes that do not affect the substance of the document. It thus has common text with the document that is about to be decided by ITU-T Study Group 16 as Recommendation H.248. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. "H.248 Annex G (Pre-Decision White Document) ", Peter Blatherwick, Michael Brown, 07/10/2000, <draft-ietf-megaco-h248g-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex G, which is scheduled for decision in Geneva in November 2000. H.248 Annex G provides packages for 'User Interface Elements and Actions'. Specifically, the packages in Annex G include: - Display - Key - Keypad - Label key - Function key - Indicator - Soft key - Ancillary input This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. "H.248 Annex H (Pre-Decision White Document)", Alf Heidermark, 07/10/2000, <draft-ietf-megaco-h248h-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex H, which is scheduled for decision in Geneva in November 2000. H.248 Annex H describes procedures for transport of the Megaco protocol over SCTP [4]. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. "H.248 Annex I (Pre-Decision White Document)", Alf Heidermark, 07/10/2000, <draft-ietf-megaco-h248i-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex I, which is scheduled for decision in Geneva in November 2000. H.248 Annex H describes procedures for transport of the Megaco protocol over ATM. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. "H.248 Annex J (Pre-Decision White Document)", Selvam Rengasami, J Mitchell, 07/10/2000, <draft-ietf-megaco-h248j-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex J, which is scheduled for decision in Geneva in November 2000. H.248 Annex J provides the Dynamic Tone Generation package. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. "H.248 Annex K (Pre-Decision White Document)", Selvam Rengasami, 07/10/2000, <draft-ietf-megaco-h248k-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex K, which is scheduled for decision in Geneva in November 2000. H.248 Annex K provides the Generic Announcement package. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. "H.248 Annex F (Pre-Decision White Document) ", Gunnar Hellstrom, 07/18/2000, <draft-ietf-megaco-h248f-00.txt> This document reproduces the content of the ITU-T Study Group 16 White Document draft of H.248 Annex F, which is scheduled for decision in Geneva in November 2000. H.248 Annex F provides packages for faxsimile, text conversation, and call discrimination. This document is submitted for IETF comment prior to ITU-T decision, in accordance with procedures currently being negotiated between ITU-T Study Group and ISOC on behalf of the IETF. Multiparty Multimedia Session Control (mmusic)---------------------------------------------- "The Internet Multimedia Conferencing Architecture", Jon Crowcroft, Mark Handley, Joerg Ott, Carsten Bormann, 07/18/2000, <draft-ietf-mmusic-confarch-03.txt> This document provides an overview of multimedia conferencing on the Internet. The protocols mentioned are specified elsewhere as RFCs, Internet-Drafts, or ITU recommendations. Each of these specifications gives details of the protocol itself, how it works and what it does. This document attempts to provide the reader with an overview of how the components fit together and of some of the assumptions made, as well as some statement of direction for those components still in a nascent stage. "A Message Bus for Local Coordiantion", Joerg Ott, Colin Perkins, Dirk Kutscher, 07/18/2000, <draft-ietf-mmusic-mbus-transport-02.txt> In a variety of conferencing scenarios, a local communication channel is desirable for conference-related information exchange between co- located but otherwise independent application entities, for example those taking part in application sessions that belong to the same conference. In loosely coupled conferences such a mechanism allows for coordination of applications entities to e.g. implement synchronization between media streams or to configure entities without user interaction. It can also be used to implement tightly coupled conferences enabling a conference controller to enforce conference wide control within a end system. The local Message Bus (Mbus) provides a means to achieve the necessary amount of coordination between co-located conferencing applications for virtually any type of conference as postulated in a a companion requirement document[11]. The Message Bus comprises two logically distinct parts: a message transport infrastructure and a set of common as well as protocol/ media/tool-specific messages along with a conference-specific addressing scheme. This document deals with message addressing, transport, and security issues and defines the message syntax for the Mbus. It does not define application oriented semantics and procedures for using the message bus. Application specific command sets and procedures for applications using the Mbus are expected to be defined in follow-up documents. This document is intended for discussion in the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "Describing session directories in SDP", Ross Finlayson, 06/22/2000, <draft-ietf-mmusic-sdp-directory-type-01.txt> A directory containing a set of media sessions - each described using the Session Description Protocol (SDP) [1] - can itself be treated as a media session, with its own SDP description. This document shows how a session directory can be described, using SDP, within one or more other session directories. This increases the flexibility and scalability of the directory system. "SDP Source-Filters", Bob Quinn, 05/04/2000, <draft-ietf-mmusic-sdp-srcfilter-00.txt> This document describes how to adapt the Session Description Protocol (SDP) to express one or more source addresses as a source filter for one or more destination 'connection' addresses. It defines the syntax and semantics for an SDP 'source-filter' attribute that may reference either IPv4 or IPv6 address(es) as either an inclusive or exclusive source list for either multicast or unicast destinations. Receiver applications are expected use the SDP source-filter information to identify traffic from legitimate senders and discard traffic from illegitimate senders. Applications and hosts may also share the source-filter information with network elements (e.g., with routers using IGMPv3) so they can potentially perform the traffic filtering operation further 'upstream,' closer to the source(s). "Conventions for the use of the Session Description Protocol (SDP)for ATM Bearer Connections", Rajesh Kumar, Mohamed Mostafa, 10/02/2000, <draft-ietf-mmusic-sdp-atm-01.txt> This document describes conventions for using the Session Description Protocol (SDP) described in RFC2327 [1] for controlling ATM Bearer Connections, and any associated ATM Adaptation Layer (AAL). The AALs addressed are Type 1, Type 2 and Type 5. This list of conventions is meant to be exhaustive. Individual applications can use subsets of these conventions. Further, these conventions are meant to comply strictly with the SDP syntax as defined in rfc2327. IP Routing for Wireless/Mobile Hosts (mobileip)----------------------------------------------- "Route Optimization in Mobile IP", C Perkins, D. Johnson, 02/11/2000, <draft-ietf-mobileip-optim-09.txt> Using the base Mobile IP protocol, all datagrams destined to a mobile node are routed through that mobile node's home agent, which then tunnels each datagram to the mobile node's current location. This document defines Route Optimization messages and extensions to the base protocol to optimize datagram routing to a mobile node. Using these protocol extensions, correspondent nodes may cache the binding of a mobile node, and then tunnel their datagrams for the mobile node directly to the care-of address, bypassing the mobile node's home agent. Extensions are also provided to allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. "Mobility Support in IPv6", C Perkins, D. Johnson, 04/28/2000, <draft-ietf-mobileip-ipv6-12.txt> This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines four new IPv6 destination options, including one that MUST be supported in packets received by any node, whether mobile or stationary. "Registration Keys for Route Optimization", C Perkins, D. Johnson, N Asokan, 07/24/2000, <draft-ietf-mobileip-regkey-03.txt> Route optimization defines extensions to Mobile IP Registration Requests that allow datagrams in flight when a mobile node moves, and datagrams sent based on an out-of-date cached binding, to be forwarded directly to the mobile node's new binding. These extensions for smooth handoff require a registration key to be established between the mobile node and foreign agent. This document defines additional extensions to the registration requests to allow for the establishment of single-use registration keys between a mobile node and foreign agent. "Mobile IP Challenge/Response Extensions", C Perkins, Pat Calhoun, 07/19/2000, <draft-ietf-mobileip-challenge-13.txt> Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. "Mobile IP Regional Registration", C Perkins, G Montenegro, Pat Calhoun, 07/25/2000, <draft-ietf-mobileip-reg-tunnel-03.txt> Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a new kind of 'regional' registration, i.e., registration local to the visited domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. "AAA Registration Keys for Mobile IP", C Perkins, Pat Calhoun, 01/28/2000, <draft-ietf-mobileip-aaa-key-01.txt> AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP requires strong authentication between the mobile node and its home agent. When the mobile node shares a security association with its home AAA server, however, it is possible to use that security association to create derivative security associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering a care-of address to the mobile node. This document specifies extensions to the Mobile IP Registration Reply packet that can be used to distribute such security information to the mobile node. "Mobile IP Vendor/Organization-Specific Extensions", Kent Leung, G Dommety, 09/11/2000, <draft-ietf-mobileip-vendor-ext-11.txt> This document proposes two new extensions to Mobile IP [1]. These extensions will facilitate equipment vendors and organizations to make specific use of these extensions as they see fit for research or deployment purposes. "IP Mobility Support for IPv4, revised", C Perkins, 09/21/2000, <draft-ietf-mobileip-rfc2002-bis-03.txt> This document specifies protocol enhancements that allow transparent routing of IP datagrams to mobile nodes in the Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about its current point of attachment to the Internet. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. "Mobile IP Authentication, Authorization, and Accounting Requirements", S. Glass, Colin Perkins, Tom Hiller, Stuart Jacobs, 07/06/2000, <draft-ietf-mobileip-aaa-reqs-04.txt> The Mobile IP and AAA working groups are currently looking at defining the requirements for Authentication, Authorization, and Accounting. This document contains the requirements which would have to be supported by a AAA service to aid in providing Mobile IP services. "Mobile IP Based Micro Mobility Management Protocol in The Third Generation Wireless Network", Peter Wenzel-Constabel, Rajesh Bhalla, Carey Becker, Peter McCann, Byung-Keun Lim, Mark Lipford, Yingchun Xu, Ed Campbell, G Dommety, Karl Freter, Eileen Hadwen, Kirit Joshi, Parviz Yegani, Jay Jayapalan, Thomas Towle, Takeo Matsumura, Atsushi Teshima, Lee Hyun, Naoto Itoh, Kimihiro Ohki, J Jiang, Woojune Kim, Yong Chang, Frederic Leroudier, Jim Gately, 06/28/2000, <draft-ietf-mobileip-3gwireless-ext- This document defines extensions to the Mobile IP protocol [1] to allow mobility management for the interface between a radio network and a packet data network in the third generation cdma2000 network. Mobile IP requires link layer connectivity between the Mobile Node and the Foreign Agent. This draft proposes a protocol for achieving this when the physical layer terminating at a point distant from the FA. In particular, this protocol applies to cdma2000 networks where the physical layer terminates at a Radio Network Node (RNN) and the FA resides inside a separate Packet Data Serving Node (PDSN). The PDSN is responsible for establishing, maintaining, and terminating the link layer to the Mobile Node. A RNN is responsible for relaying the link layer protocol between a Mobile Node and its corresponding PDSN. The interface between the RNN and the PDSN is called the RP interface. This interface requires mobility management for handling handoff from one RNN to another without interrupting end to end communication. It also requires the support of the link layer protocol encapsulation. "Mobile IP Extensions Rationalization (MIER)", Emad Qaddoura, Haseeb Akhtar, M Khalil, Raja Narayanan, 02/09/2000, <draft-ietf-mobileip-mier-03.txt> It is in the interest of the Mobile IP WG to conserve the usage of the type field since we see many drafts proposing new extensions for Mobile IP. Therefore there is a real need to find ways to limit the usage of the type field in the extensions structure. MIER describes a new extension structure to Mobile IP to make the extensions far more extensible. "Reverse Tunneling for Mobile IP, revised", G Montenegro, 10/11/2000, <draft-ietf-mobileip-rfc2344-bis-03.txt> Mobile IP uses tunneling from the home agent to the mobile node's care-of address, but rarely in the reverse direction. Usually, a mobile node sends its packets through a router on the foreign network, and assumes that routing is independent of source address. When this assumption is not true, it is convenient to establish a topologically correct reverse tunnel from the care-of address to the home agent. This document proposes backwards-compatible extensions to Mobile IP to support topologically correct reverse tunnels. This document does not attempt to solve the problems posed by firewalls located between the home agent and the mobile node's care-of address. "Generalized NAI Extension (GNAIE)", Pat Calhoun, Emad Qaddoura, Haseeb Akhtar, M Khalil, 10/02/2000, <draft-ietf-mobileip-gnaie-01.txt> The Mobile IP Extensions Rationalization (MIER) specification defines a new extension header format, that is intended to extend the Mobile IP extension address space. This document defines the Generalized Network Access Identifier (NAI) extension, which SHOULD be used by any Mobile IP extension specifying an extension containing an NAI. "Hierarchical MIPv6 mobility management", Claude Castelluccia, K Malki, Hesham Soliman, Ludovic Bellier, 10/05/2000, <draft-ietf-mobileip-hmipv6-00.txt> This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. Multiprotocol Label Switching (mpls)------------------------------------ "A Framework for MPLS", Ross Callon, George Swallow, N. Feldman, A Viswanathan, P. Doolan, A. Fredette, 09/22/1999, <draft-ietf-mpls-framework-05.txt> This document discusses technical issues and requirements for the Multiprotocol Label Switching working group. It is the intent of this document to produce a coherent description of all significant approaches which were and are being considered by the working group. Selection of specific approaches, making choices regarding engineering tradeoffs, and detailed protocol specification, are outside of the scope of this framework document. "Multiprotocol Label Switching Architecture", Ross Callon, A Viswanathan, E. Rosen, 08/10/2000, <draft-ietf-mpls-arch-07.txt> This internet draft specifies the architecture for Multiprotocol Label Switching (MPLS). "MPLS Label Stack Encoding", Dino Farinacci, Tony Li, A. Conta, Y Rekhter, Dan Tappan, E. Rosen, G. Fedorkow, 08/10/2000, <draft-ietf-mpls-label-encaps-08.txt> 'Multi-Protocol Label Switching (MPLS)' [1,2] requires a set of procedures for augmenting network layer packets with 'label stacks', thereby turning them into 'labeled packets'. Routers which support MPLS are known as 'Label Switching Routers', or 'LSRs'. In order to transmit a labeled packet on a particular data link, an LSR must support an encoding technique which, given a label stack and a network layer packet, produces a labeled packet. This document specifies the encoding to be used by an LSR in order to transmit labeled packets on PPP data links, on LAN data links, and possibly on other data links as well. On some data links, the label at the top of the stack may be encoded in a different manner, but the techniques described here MUST be used to encode the remainder of the label stack. This document also specifies rules and procedures for processing the various fields of the label stack encoding. "The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol", M. Suzuki, 01/11/2000, <draft-ietf-mpls-git-uus-04.txt> The purpose of this document is to specify the assignment of the information field and protocol identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet protocol. The assignment, that is specified in section 4 of this document, is designed for advanced B-ISDN signaling support of the Internet protocol, especially the B-ISDN signaling support for the connection that corresponds to the session in the Internet protocol which is clarified in section 2. This specification provides an indispensable framework for the implementation of long-lived session and QoS- sensitive session transfers over ATM. "Use of Label Switching on Frame Relay Networks Specification", Andy Malis, A. Conta, P. Doolan, 06/20/2000, <draft-ietf-mpls-fr-06.txt> This document defines the model and generic mechanisms for Multiprotocol Label Switching on Frame Relay networks. Furthermore, it extends and clarifies portions of the Multiprotocol Label Switching Architecture described in [ARCH] and the Label Distribution Protocol (LDP) described in [LDP] relative to Frame Relay Networks. MPLS enables the use of Frame Relay Switches as Label Switching Routers (LSRs). "VCID Notification over ATM link for LDP", Noritoshi Demizu, Y. Katsube, Hiroshi Esaki, K. Nagami, P. Doolan, 08/07/2000, <draft-ietf-mpls-vcid-atm-05.txt> The ATM Label Switching Router (ATM-LSR) is one of the major applications of label switching. Because the ATM layer labels (VPI and VCI) associated with a VC rewritten with new value at every ATM switch nodes, it is not possible to use them to identify a VC in label mapping messages. The concept of Virtual Connection Identifier (VCID) is introduced to solve this problem. VCID has the same value at both ends of a VC. This document specifies the procedures for the communication of VCID values between neighboring ATM-LSRs that must occur in order to ensure this property. "Carrying Label Information in BGP-4", Y Rekhter, E. Rosen, 01/06/2000, <draft-ietf-mpls-bgp4-mpls-04.txt> When BGP is used to distribute a particular route, it can be also be used to distribute an MPLS label which is mapped to that route [MPLS-ARCH]. This document specifies the way in which this is done. The label mapping information for a particular route is piggybacked in the same BGP Update message that is used to distribute the route itself. "LDP Specification", Bob Thomas, N. Feldman, P. Doolan, Loa Andersson, A. Fredette, 08/24/2000, <draft-ietf-mpls-ldp-11.txt> The architecture for Multi Protocol Label Switching (MPLS) is described in [ARCH]. A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document defines a set of such procedures called LDP (for Label Distribution Protocol) by which LSRs distribute labels to support MPLS forwarding along normally routed paths [LDPAPPLIC]. "Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)", Joan Cucchiara, James Luciani, Hans Sjostrand, 08/30/2000, <draft-ietf-mpls-ldp-mib-07.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). "MPLS using LDP and ATM VC Switching", Keith McCloghrie, Bruce Davie, George Swallow, Y Rekhter, E. Rosen, P. Doolan, Jeremy Lawrence, 06/16/2000, <draft-ietf-mpls-atm-04.txt> The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. "LDP State Machine", Eric Gray, Liwen Wu, Pierrick Cheval, Christophe Boscher, 01/20/2000, <draft-ietf-mpls-ldp-state-03.txt> In the current LDP specification [4], there is no state machine specified for processing LDP messages. We think that defining a common state machine is very important for interoperability between different LDP and CR-LDP implementations. This document provides state machine tables for ATM switch LSRs. We begin in section 2 by defining a list of terminologies. Then in section 3, we propose two sets of state machine tables for ATM switch LSRs which use downstream-on-demand mode, one method can be used for non-vc merge capable ATM LSRs, while the other one can be used for the vc-merge capable ATM LSRs. In section 4, we provides a state machine for downstream unsolicited mode ATM LSRs. We focus on the LDP state machines and the associated control blocks used for establishing and maintaining LSPs. We do not describe state machines for the 'LDP controller' which is in charge of LDP session initialization, address mapping messages management, routing interface, etc. which is defined in the LDP specification [4]. Even though the state machines in this document are specific for ATM-LSR, they can be easily adapted for other types of LSRs. "Constraint-Based LSP Setup using LDP", Bilel Jamoussi, 07/07/2000, <draft-ietf-mpls-cr-ldp-04.txt> Label Distribution Protocol (LDP) is defined in [1] for distribution of labels inside one MPLS domain. One of the most important services that may be offered using MPLS in general and LDP in particular is support for constraint-based routing of traffic across the routed network. Constraint-based routing offers the opportunity to extend the information used to setup paths beyond what is available for the routing protocol. For instance, an LSP can be setup based on explicit route constraints, QoS constraints, and other constraints. Constraint-based routing (CR) is a mechanism used to meet Traffic Engineering requirements that have been proposed by [2], [3] and [4]. These requirements may be met by extending LDP for support of constraint-based routed label switched paths (CR-LSPs). Other uses for CR-LSPs include MPLS-based VPNs [5]. More information about the applicability of CR-LDP can be found in [6]. This draft specifies mechanisms and TLVs for support of CR-LSPs using LDP. "RSVP-TE: Extensions to RSVP for LSP Tunnels", Der-Hwa Gan, Tony Li, George Swallow, Lou Berger, Vijay Srinivasan, Daniel Awduche, 08/24/2000, <draft-ietf-mpls-rsvp-lsp-tunnel-07.txt> This document describes the use of RSVP, including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS. Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels. A key application of LSP tunnels is traffic engineering with MPLS as specified in [3]. We propose several additional objects that extend RSVP, allowing the establishment of explicitly routed label switched paths using RSVP as a signaling protocol. The result is the instantiation of label- switched tunnels which can be automatically routed away from network failures, congestion, and bottlenecks. "MPLS Traffic Engineering Management Information Base Using SMIv2", A Viswanathan, C Srinivasan, Thomas Nadeau, 07/21/2000, <draft-ietf-mpls-te-mib-04.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multi-Protocol Label Switching (MPLS) [MPLSArch] [MPLSFW] based traffic engineering. "MPLS Support of Differentiated Services", Bruce Davie, Juha Heinanen, Pasi Vaananen, Liwen Wu, Francois Le Faucheur, Pierrick Cheval, Ram Krishnan, Shahram Davari, 08/14/2000, <draft-ietf-mpls-diff-ext-07.txt> This document defines a flexible solution for support of Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks. This solution allows the MPLS network administrator to select how Diff-Serv Behavior Aggregates (BAs) are mapped onto Label Switched Paths (LSPs) so that he/she can best match the Diff-Serv, Traffic Engineering and protection objectives within his/her particular network. For instance, this solution allows the network administrator to decide whether different sets of BAs are to be mapped onto the same LSP or mapped onto separate LSPs. "MPLS Loop Prevention Mechanism", Y. Katsube, Y. Ohba, E. Rosen, P. Doolan, 04/27/2000, <draft-ietf-mpls-loop-prevention-03.txt> This paper presents a simple mechanism, based on 'threads', which can be used to prevent MPLS from setting up label switched path (LSPs) which have loops. The mechanism is compatible with, but does not require, VC merge. The mechanism can be used with either the ordered downstream-on-demand allocation or ordered downstream allocation. The amount of information that must be passed in a protocol message is tightly bounded (i.e., no path-vector is used). When a node needs to change its next hop, a distributed procedure is executed, but only nodes which are downstream of the change are involved. "Framework for IP Multicast in MPLS", Bernard Sales, A. Acharya, Wim Livens, Dirk Ooms, Frederic Griffoul, Furquan Ansari, 05/02/2000, <draft-ietf-mpls-multicast-01.txt> 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. "MPLS Label Switch Router Management Information Base Using SMIv2", A Viswanathan, C Srinivasan, Thomas Nadeau, 07/13/2000, <draft-ietf-mpls-lsr-mib-06.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling a Multi-Protocol Label Switching (MPLS) [MPLSArch, MPLSFW] Label Switch Router (LSR). "ICMP Extensions for MultiProtocol Label Switching", Dan Tappan, Ronald Bonica, Der-Hwa Gan, 08/07/2000, <draft-ietf-mpls-icmp-02.txt> The current memo proposes extensions to ICMP that permit Label Switching Routers to append MPLS information to ICMP messages. "LDP Applicability", Bob Thomas, Eric Gray, 08/07/2000, <draft-ietf-mpls-ldp-applic-02.txt> Multiprotocol Label Switching (MPLS) is a method for forwarding packets that uses short, fixed-length values carried by packets, called labels, to determine packet nexthops [MPLS-ARCH]). A fundamental concept in MPLS is that two Label Switching Routers (LSRs) must agree on the meaning of the labels used to forward traffic between and through them. This common understanding is achieved by using a set of procedures, called a label distribution protocol, by which one LSR informs another of label bindings it has made. This document describes the applicability of a set of such procedures called LDP (for Label Distribution Protocol) [LDP] by wich LSRs distribute labels to support MPLS forwarding along normally routed paths. "Applicability Statement for CR-LDP", J.Ivan Ash, Eric Gray, Muckai Girish, Gregory Wright, Bilel Jamoussi, 07/07/2000, <draft-ietf-mpls-crldp-applic-01.txt> This Internet-Draft discusses the applicability of Constraint-Based LSP Setup using LDP [1]. It discusses possible network applications, extensions to Label Distribution Protocol (LDP) [2] required to implement constraint-based routing, guidelines for deployment and known limitations of the protocol. This document is a prerequisite to advancing CR-LDP on the standards track. "Applicability Statement for Extensions to RSVP for LSP-Tunnels", Alan Hannan, Daniel Awduche, X Xiao, 04/06/2000, <draft-ietf-mpls-rsvp-tunnel-applicability-01.txt> This memo discusses the applicability of 'Extensions to RSVP for LSP Tunnels' [1]. It highlights the protocol's principles of operation and describes the network context for which it was designed. Guidelines for deployment are offered and known protocol limitations are indicated. This document is intended to accompany the submission of 'Extensions to RSVP for LSP Tunnels' onto the Internet standards track. "LSP Modification Using CR-LDP", J.Ivan Ash, Bilel Jamoussi, Don Fedyk, Peter Ashwood-Smith, Y Lee, Li Li, D Skalecki, 10/09/2000, <draft-ietf-mpls-crlsp-modify-02.txt> After a CR-LSP is set up, its bandwidth reservation may need to be changed by the network operator, due to the new requirements for the traffic carried on that CR-LSP [2]. This contribution presents an approach to modify the bandwidth and possibly other parameters of an established CR-LSP using CR-LDP [3] without service interruption. The LSP modification feature can be supported by CR-LDP by use of the _modify_ value for the _action indicator flag_ in the LSPID TLV [3]. This feature has application in dynamic network resources management where traffic of different priorities and service classes is involved. "IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK", Bilel Jamoussi, Don Fedyk, Peter Ashwood-Smith, D Skalecki, 07/19/2000, <draft-ietf-mpls-te-feed-01.txt> One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. "LSP Hierarchy with MPLS TE", Y Rekhter, Kireeti Kompella, 09/25/2000, <draft-ietf-mpls-lsp-hierarchy-01.txt> To improve scalability of MPLS TE it may be useful to aggregate TE LSPs. The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a link into ISIS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. "MPLS/IP Header Compression ", Lou Berger, Jason Jeffords, 07/14/2000, <draft-ietf-mpls-hdr-comp-00.txt> This document describes a method for compressing the headers of IP datagrams that are being transported over MPLS. This work extends the existing IP and IP/UDP/RTP header compression techniques, as defined in [RFC2507] and [RFC2508], to operate over and to compress MPLS label stack entries. "MPLS/IP Header Compression over PPP", Lou Berger, Jason Jeffords, 07/14/2000, <draft-ietf-mpls-hdr-comp-over-ppp-00.txt> 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. "Link Management Protocol (LMP)", Lou Berger, Hal Sandick, Y Rekhter, John Drake, Debanjan Saha, Kireeti Kompella, Debashis Basak, Jonathan Lang, Krishna Mitra, 09/11/2000, <draft-ietf-mpls-lmp-00.txt> Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with bundled links consisting of a number of user component links and an associated control channel. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the component links. LMP will be used to maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network. "Framework for MPLS-based Recovery", Vishal Sharma, 09/11/2000, <draft-ietf-mpls-recovery-frmwrk-00.txt> Multi-protocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2] [3] [4] [5] [6] support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. "Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management Information Base Using SMIv2", A Viswanathan, C Srinivasan, Thomas Nadeau, 09/21/2000, <draft-ietf-mpls-ftn-mib-00.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining FEC-to-NHLFE mapping and corresponding actions for use with Multiprotocol Label Switching (MPLS). "Fault Tolerance for LDP and CR-LDP", Eric Gray, P. Brittain, Adrian Farrel, Philip Matthews, 10/13/2000, <draft-ietf-mpls-ldp-ft-00.txt> 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. "Generalized MPLS - Signaling Functional Description ", Peter Ashwood-Smith, 10/20/2000, <draft-ietf-mpls-generalized-signaling-00.txt> This document describes extensions to MPLS signaling required to support Generalized MPLS. Generalized MPLS extends MPLS to encompass time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming port or fiber to outgoing port or fiber). This document presents a functional description of the extensions. Protocol specific formats and mechanisms are currently included in this draft but are expected to be split out into separate, per protocol documents. "MPLS LDP Query Message Description", Peter Ashwood-Smith, Antonela Paraschiv, 10/23/2000, <draft-ietf-mpls-lsp-query-00.txt> This document describes the encoding and procedures for three new LDP messages, the Query Message and Query-Reply Message and Partial Query-Reply Message (the last one is almost identical to the Query- Reply message; therefore all references to the Query-Reply messages imply the Partial Query-Reply messages as well, unless otherwise specified). An LER sends a Query message when it needs to find out information about an LSP. The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for CR-LSPs. The queried data is encoded into the Query-Reply messages. The Query Message carries only the list of hops. Multicast Source Discovery Protocol (msdp)------------------------------------------ "Multicast Source Discovery protocol MIB", Bill Fenner, Dave Thaler, 07/19/2000, <draft-ietf-msdp-mib-04.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing Multicast Source Discovery Protocol (MSDP) [17] speakers. "Multicast Source Discovery Protocol (MSDP)", Dino Farinacci, Peter Lothberg, David Meyer, Y Rekhter, Hank Kilmer, Jeremy Hall, 07/19/2000, <draft-ietf-msdp-spec-06.txt> The Multicast Source Discovery Protocol, MSDP, describes a mechanism to connect multiple PIM-SM domains together. Each PIM-SM domain uses its own independent RP(s) and does not have to depend on RPs in other domains. "MSDP Traceroute", David Meyer, William Fenner, 03/16/2000, <draft-ietf-msdp-traceroute-00.txt> In order to diagnose problems with the Peer-RPF-Flooding mechanisms in the Multicast Source Discovery Protocol [MSDP], we introduce a method of tracing the path that an SA message should have taken, along with collecting statistics along that path. This occurs in a way similar to multicast traceroute [MTRACE], with each router appending information about this hop and forwarding the message towards the desired RP. This document is a product of the MSDP working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at msdp@network-services.uoregon.edu Message Tracking Protocol (msgtrk)---------------------------------- "Message Tracking Model and Requirements", Tony Hansen, Ken Lin, 07/17/2000, <draft-ietf-msgtrk-model-02.txt> Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document provides a model of message tracking that can be used for understanding the Internet-wide message infrastructure and to further enhance those capabilities to include message tracking, as well as requirements for proposed message tracking solutions. "SMTP Service Extension for Message Tracking", Tony Hansen, Eric Allman, 03/16/2000, <draft-ietf-msgtrk-protocol-00.txt> The Message Tracking Models and Requirements document [RFC-TRACK- MODEL] discusses the models that message tracking solutions could fol- low, along with requirements for a message tracking solution that can be used with the Internet-wide message infrastructure. This memo defines an extension to the SMTP service that provides a message tracking solu- tion that satisfies those requirements. Using the model document's ter- minology, it uses active enabling and active requests with request referrals. "Message Tracking Query Protocol", Tony Hansen, 07/20/2000, <draft-ietf-msgtrk-mtqp-00.txt> Customers buying enterprise message systems often ask: Can I track the messages? Message tracking is the ability to find out the path that a particular message has taken through a messaging system and the current routing status of that message. This document describes the Message Tracking Query Protocol that is used in conjunction with exten- sions to the ESMTP protocol to provide a complete message tracking solu- tion for the Internet. Network Access Server Requirements (nasreq)------------------------------------------- "Criteria for Evaluating Network Access Server Protocols", David Mitton, Mark Beadles, 06/08/2000, <draft-ietf-nasreq-criteria-05.txt> 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. Network Address Translators (nat)--------------------------------- "Traditional IP Network Address Translator (Traditional NAT)", Pyda Srisuresh, Kjeld Egevang, 04/10/2000, <draft-ietf-nat-traditional-04.txt> Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation, or NAPT is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a routing realm with private addresses to the external routing network with globally unique registered addresses. "Protocol Complications with the IP Network Address Translator (NAT)", Pyda Srisuresh, Matt Holdrege, 10/10/2000, <draft-ietf-nat-protocol-complications-05.txt> 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 impossible to capture all the applications that break with NAT in a single document. This document attempts to capture as much informa- tion as possible, but by no means a comprehensive coverage. We hope this coverage provides clues for applications not covered here. "NAT Friendly Application Design Guidelines", D. Senie, 07/10/2000, <draft-ietf-nat-app-guide-03.txt> 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. "Realm Specific IP: A Framework", G Montenegro, Michael Borella, David Grabelsky, Jeffrey Lo, 07/14/2000, <draft-ietf-nat-rsip-framework-05.txt> 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. "Realm Specific IP: Protocol Specification", Michael Borella, David Grabelsky, Jeffrey Lo, Kunihiro Tuniguchi, 07/11/2000, <draft-ietf-nat-rsip-protocol-07.txt> This document presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway. "RSIP Support for End-to-end IPSEC", G Montenegro, Michael Borella, 07/20/2000, <draft-ietf-nat-rsip-ipsec-04.txt> This document proposes mechanisms that enable 'Realm-Specific IP' (RSIP) to handle end-to-end IPSEC. "Framework for interfacing with Network Address Translator", Pyda Srisuresh, 07/12/2000, <draft-ietf-nat-interface-framework-01.txt> 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). "Finding an RSIP Server with SLP", G Montenegro, James Kempf, 02/16/2000, <draft-ietf-nat-rsip-slp-00.txt> Service Location Protocol (SLP) is an IETF standards track protocol specifically designed to allow clients to find servers offering particular services. Since RSIP clients require a mechanism to discover RSIP servers, SLP is a natural match for a solution. The document contains an SLP service type template that describes the advertisements made by RSIP servers for their services. The service type template is the basis for an IANA standard definition of the advertisements offered by RSIP servers, an important step toward interoperability. Network File System Version 4 (nfsv4)------------------------------------- "NFS version 4", Brent Callaghan, M. Eisler, Robert Thurlow, David Robinson, Spencer Shepler, D Noveck, C Beame, 06/16/2000, <draft-ietf-nfsv4-07.txt> NFS version 4 is a distributed file system protocol which owes heritage to NFS protocol versions 2 [RFC1094] and 3 [RFC1813]. Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the mount protocol. In addition, support for strong security (and its negotiation), compound operations, client caching, and internationalization have been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. Next Generation Transition (ngtrans)------------------------------------ "The 6bone registry", David Kessens, 07/19/2000, <draft-ietf-ngtrans-6bone-registry-03.txt> This proposal describes the proposed syntax of a new RIPE database object that describes the several IPv6 sites in the world. The object and resulting database collection will be used to facilitate the introduction of IPv6 in the Internet. "Overview of Transition Techniques for IPv6-only to Talk to IPv4-only Communication", K. Yamamoto, Munechika Sumikawa, 03/09/2000, <draft-ietf-ngtrans-translator-03.txt> This memo discusses translators to enable direct communication between IPv4 hosts and IPv6 hosts. Three translation mechanisms are described. From the address mapping point of view, the translators are categorized into four types and each feasibility is considered. This memo is based on a paper appeared in Proceedings of INET98[INET]. "Connection of IPv6 Domains via IPv4 Clouds", Brian Carpenter, Keith Moore, 09/05/2000, <draft-ietf-ngtrans-6to4-07.txt> This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution. "IPv6 Tunnel Broker", Alain Durand, Paolo Fasano, Ivano Guardini, Domenico Lento, 09/21/2000, <draft-ietf-ngtrans-broker-05.txt> The IPv6 global Internet as of today is mostly built using tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and ISPs can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g. the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting. "On overviewof the Introduction of IPv6 in the IPv4 Internet", K. Yamamoto, Henk Steenman, Marijke Kaat, Alain Durand, Wim Biemolt, George Tsirtsis, Ronald van der Pol, Yuji Sekiya, Tim Larder, 07/19/2000, <draft-ietf-ngtrans-introduction-to-ipv6-transition-04.txt> This document is a guide to the introduction of IPv6 in the IPv4 based Internet or Intranets. Several general issues to start IPv6 networking in a predominantly IPv4 world are discussed, such as IPv6 addresses, IPv6 DNS and routing issues. Short descriptions are given of the different translation and migration tools and mechanisms that translate between IPv6 and IPv4 and/or tunnel IPv6 over IPv4. The remainder of this document describes how IPv6 can be introduced in various environments, such as ISPs, Internet Exchanges and end user environments. Suggestions are given on the use of the different translation and migration tools in each environment. "A SOCKS-based IPv6/IPv4 Gateway Mechanism", Hiroshi Kitamura, 07/17/2000, <draft-ietf-ngtrans-socks-gateway-05.txt> 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. "6BONE Pre-Qualification for Address Prefix Allocation (6PAPA)", B. Fink, 01/19/2000, <draft-ietf-ngtrans-6bone-6papa-01.txt> This memo describes how the 6bone may be used as a prequalification step during the 'bootstrap' phase of sub-TLA assignment by the Regional Internet Registries (RIRs). "Dual Stack Transition Mechanism (DSTM)", F. Dupont, Jim Bound, Alain Durand, Laurent Toutain, Hossam AFIFI, 07/20/2000, <draft-ietf-ngtrans-dstm-02.txt> The initial deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4, within an IPv6 Network. Nodes will be able to be deployed with IPv6 addresses, but will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The Dual Stack Transition Method (DSTM) provides a set of mechanisms to assign temporary Global IPv4 Addresses to IPv6 nodes, use of dynamic tunnels within an IPv6 Network to carry IPv4 traffic, and a defined set of processes and architecture for the supporting infrastructure required for this transition mechanism. "An IPv6-to-IPv4 transport relay translator", K. Yamamoto, Jun-ichiro Hagino, 05/22/2000, <draft-ietf-ngtrans-tcpudp-relay-01.txt> 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. "IPv6 over IPv4 tunnels for home to Internet access", F. Dupont, 04/11/2000, <draft-ietf-ngtrans-hometun-00.txt> Many Internet access providers for residential customers provide only one dynamic IPv4 address to their clients. This document proposes in such cases to use an IPv6 over IPv4 tunnel with IPSec (this gives a static global routable address or prefix with security) and to implement the processing at the server end of unsolicited neighbor advertisements for overriding the IPv4 address at the client end when it changes. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", Philip Nesser II, 04/27/2000, <draft-ietf-ngtrans-ipv4survey-00.txt> 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. NNTP Extensions (nntpext)------------------------- "Network News Transport Protocol", Stan Barber, 07/17/2000, <draft-ietf-nntpext-base-10.txt> The Network News Transport Protocol has been in use in the Internet for a decade and remains one of the most popular protocols (by volume) in use today. This document is a replacement for RFC 977 and officially updates the protocol specification. It clarifies some vagueness in RFC 977, includes some new base functionality and provides a specific mechanism to add standardized extensions to NNTP. Individual Submissions (none)----------------------------- "IP Authentication using Keyed SHA1 with Data Padding", W. Simpson, Perry Metzger, 05/01/1996, <draft-simpson-ah-sha-kdp-00.txt> This document describes the use of keyed SHA1 with the IP Authentication Header. "Printer MIB v2", R. Turner, H. Lewis, Gary Gocek, 08/11/2000, <draft-ietf-printmib-mib-info-06.txt> This document provides definitions of models and manageable objects for printing environments. The objects included in this MIB apply to physical, as well as logical entities within a printing device. This MIB definition makes explicit references to the Host Resources MIB (RFC 2790 [28]), as well as the Interfaces Group of MIB-II (RFC 1213 [14]). "Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson, Martin Carpenter, Volker Wiegand, 09/19/2000, <draft-murray-auth-ftp-ssl-06.txt> This document describes a mechanism that can be used by FTP clients and servers to implement security and authentication using the TLS protocol defined by [RFC-2246] and the extensions to the FTP protocol defined by [RFC-2228]. It describes the subset of the extensions that are required and the parameters to be used; discusses some of the policy issues that clients and servers will need to take; considers some of the implications of those policies and discusses some expected behaviours of implementations to allow interoperation. This document is intended to provide TLS support for FTP in a similar way to that provided for SMTP in [RFC-2487]. "Definition of an Object Class to Hold LDAP Change Records", G. Good, 03/10/2000, <draft-good-ldap-changelog-01.txt> In order to support more flexible replication methods, it is desirable to specify some manner in which an LDAP client may retrieve a set of changes which have been applied to an LDAP server's database. The client, which may be another LDAP server, may then choose to update its own replicated copy of the data. This document specifies an object class which may be used to represent changes applied to an LDAP server. It also specifies a method for discovering the location of the container object which holds these change records, so that clients and servers have a common rendezvous point for this information. "Originator-Info Message Header", Chris Newman, 05/28/1998, <draft-newman-msgheader-originfo-05.txt> This proposal is an attempt to provide a standard header to indicate information about the message originator without implying that there is a deliverable mailbox or mandating that internal network information be revealed. The 'Originator-Info' header is intended to make the 'X-Sender' and 'X-X-Sender' headers obsolete. "NICS Network of Identifier and Credential Servers", G. Hoare, 01/17/1997, <draft-hoare-nics-00.txt> NICS is a proposed system which meets the requirements of large-scale, unique principal identification, for use in conjunction with an arbitrary set of security systems such as have been proposed by members of the IETF. This proposal outlines the motivation for the development of NICS, and gives a general description of its internal workings and interfaces with higher-level protocols. It should be emphasized up front that NICS is not a complete security system, nor does it aim to replace any existing components of the internet which already work. The design draws off the fact that many security systems already have flexible name schemes, and are therefore considered components which are used in conjunction with NICS to achieve an improved level of service, flexibility and reliability, while introducing many desirable features such as anonymous identifiers, self-optimization, and low-overhead operation. For the purpose of initial evaluation, the remainder of this paper is short and to the point, and requires a little work on the reader's side to understand the reasoning. Additional discussion is welcome on the mailing list. "Network Tuning for Efficiency and Throughput", L. Breit, 01/23/1997, <draft-breit-ntwrk-tuning-00.txt> Network tuning is usually performed after the network design is completed, but should also be done at intervals during the life cycle of the network. There are four basic areas that directly affect the efficiency of the network and its associated throughput: Frame and packet size optimization Segmentation avoidance or limitation Minimization of device delay Window sizing to avoid degradation This draft has been written to document for the internet community a basic overview of network tuning and its benefits. "DIAMETER Base Protocol", Allan Rubens, Erik Guttman, Pat Calhoun, Haseeb Akhtar, 09/28/2000, <draft-calhoun-diameter-17.txt> The DIAMETER base protocol is intended to provide a AAA framework for Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message format, transport, error reporting and security services to be used by all DIAMETER extensions and MUST be supported by all DIAMETER implementations. "Sieve: A Mail Filtering Language", T. Showalter, 08/10/2000, <draft-showalter-sieve-12.txt> This document describes a language for filtering e-mail messages at time of final delivery. It is designed to be implementable on either a mail client or mail server. It is meant to be extensible, simple, and independent of access protocol, mail architecture, and operating system. It is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box IMAP servers, as it has no variables, loops, or ability to shell out to external programs. "Internationalized Uniform Resource Identifiers (IURI)", Larry Masinter, M. Duerst, 03/13/2000, <draft-masinter-url-i18n-05.txt> A URI [RFC 2396] is a protocol element, defined as a sequence of characters chosen from a limited subset of the repertoire of ASCII characters. URIs are used both for transmission in network protocols and also as a representation in spoken and written human communication. This document defines a new protocol element, the IURI (Internationalized URI), defined as a sequence of characters from the repertoire of the UCS (Universal Character Set). It defines a mapping of IURIs to URIs and gives guidelines for the use and deployment of IURIs in various elements of software that deal with URIs. "HTTP Trust Mechanism for State Management", Eric Brunner, D. Jaye, 07/25/2000, <draft-jaye-http-trust-state-mgt-01.txt> This document describes an extension to the HTTP/1.1 state management mechanism described in [Kristol]. This mechanism, 'trust-labels', associates digitally signed labels with Set-Cookie or Set-Cookie2 headers. The labels allow additional semantics to attach to cookies and cookie processing, and the digital signatures allow trust models to be associated with processing rules for labeled cookies. The intent is to provide a mechanism that allows user agent implementors to implement evaluation of the authenticity and content of cookie-associated labels, and to implement additional processing rules for cookie handling. The intended use is browser determination of server privacy practices and acceptance, rejection, modification or redirection of cookies based on those practices. The more general use of trust model scoped, label semantic scoped processing of HTTP state artifacts is not precluded by this intended use. "Character Normalization in ITEF Protocols", M. Duerst, Mark Davis, 09/13/2000, <draft-duerst-i18n-norm-04.txt> 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. "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", M. Crispin, 10/10/2000, <draft-crispin-imapv-11.txt> The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server (see also [IMAP-DISC]). "ISO 7812/7816 Numbers and the Domain Name System (DNS)", D Eastlake, 07/07/2000, <draft-eastlake-card-map-07.txt> 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. "Handle System Overview", Larry Lannom, Sam Sun, 08/15/2000, <draft-sun-handle-system-05.txt> The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. This document provides an overview of the Handle System in terms of its namespace and service architecture, as well as its relationship to other Internet services such as DNS, LDAP/X.500, and URN. "Java LDAP Controls", R. Weltman, 10/16/2000, <draft-weltman-ldap-java-controls-05.txt> This document defines support for the Server Sorting Control, the Virtual List Control, the Persistent Search Control, and the Proxied Authorization Control in the java LDAP API. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. "LDAP Proxied Authentication Control", R. Weltman, 10/16/2000, <draft-weltman-ldapv3-proxy-05.txt> This document defines support for the Proxied Authentication Control. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. The Proxied Authentication Control allows a connection with sufficient privileges to assume the identity of another entry for the duration of an LDAP request. "Using the UTF-8 Character Set in the Domain Name System", S. Kwan, James Gilroy, 07/14/2000, <draft-skwan-utf8-dns-04.txt> The Doain Name System standard specifies that names are represented using the ASCII character encoding. This docuent expands that specification to allow the use of the UTF-8 character encoding, a superset of ASCII and a translation of the UCS-2 character encoding. "A Description of the MISTY1 Encryption Algorithm", M Matsui, H Ohta, 07/19/2000, <draft-ohta-misty1desc-02.txt> This document describes a secret-key cryptosystem MISTY1, which is block cipher with a 128-bit key, a 64-bit block and a variable number of rounds. It documents the algorithm description including key scheduling part and data randomizing part. "PGM Reliable Transport Protocol", Dino Farinacci, A. Lin, Tony Speakman, A. Tweedly, L Vicisano, Nidhi Bhaskar, Kelly Johnson, Rajitha Sumanasekera, 04/10/2000, <draft-speakman-pgm-spec-04.txt> Pragmatic General Multicast (PGM) is a reliable multicast transport pro- tocol for applications that require ordered or unordered, duplicate- free, multicast data delivery from multiple sources to multiple receivers. PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. PGM is specifically intended as a work- able solution for multicast applications with basic reliability require- ments. Its central design goal is simplicity of operation with due regard for scalability and network efficiency. "Delta encoding in HTTP", J Mogul, A.C. Hoffman, Y Goland, Fred Douglis, Anja Feldmann, Balachander Krishnamurthy, Daniel Hellerstein, 10/03/2000, <draft-mogul-http-delta-07.txt> Many HTTP requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called 'delta encoding.' This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. "Instance Digests in HTTP", J Mogul, Arthur van Hoff, 10/03/2000, <draft-mogul-http-digest-03.txt> HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1, may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems. "Multipath Issues in Unicast and Multicast Next-Hop Selection", Dave Thaler, Chris Hopps, 02/08/2000, <draft-thaler-multipath-05.txt> Various routing protocols, including OSPF [1] and ISIS, explicitly allow 'Equal-Cost Multipath' routing. Some router implementations also allow equal-cost multipath usage with RIP and other routing protocols. Using equal-cost multipath means that if multiple equal-cost routes to the same destination exist, they can be discovered and used to provide load balancing among redundant paths. The effect of multipath routing on a forwarder is that the forwarder potentially has several next-hops for any given destination and must use some method to choose which next-hop should be used for a given data packet. This memo summarizes current practices, problems, and solutions. "Common Internet Message Header Fields", J. Palme, 06/12/2000, <draft-palme-mailext-headers-03.txt> This memo contains tables of commonly occurring header fields in headings of e-mail messages. The document compiles information from other RFCs such as RFC 822, RFC 1036, RFC 1123, RFC 2156, RFC 1496, RFC 1766, RFC 2183, RFC 1864, RFC 2421 and RFC 2045. A few commonly occurring header fields which are not defined in RFCs are also included. For each header field, the memo gives a short description and a reference to the RFC in which the header field is defined. This document is a revision of RFC 2076. The following new header fields, not included in RFC 2076, have been added: Content-Alias, Disposition-Notification-Options, Disposition-Notification-To, Expiry- Date, For-Approval, List-Archive, List-Help, List-ID, List-Owner, List- Post, List-Software, List-Subscribe, List-Unsubscribe, Original- Recipient, PICS-Label, X-Envelope-From, X-Envelope-To, X-List-Host, X- Listserver, X-MIME-Autoconverted, X-No-Archive, X-Priority, X-UIDL. "Sieve: Vacation Extension", T. Showalter, 08/10/2000, <draft-showalter-sieve-vacation-04.txt> This document describes an extension to the Sieve mail filtering language for an autoresponder similar to that of the Unix 'vacation' command for replying to messages with certain safety features to prevent problems. "Printer Finishing MIB", H. Lewis, R. Bergman, 05/12/2000, <draft-ietf-printmib-finishing-09.txt> This document defines a printer industry standard SNMP MIB for the management of printer finishing device subunits. The finishing device subunits applicable to this MIB are an integral part of the Printer System. This MIB does not apply to a Finisher Device that is not connected to a Printer System. The Finisher MIB is defined as an extension of the Printer MIB [PrtMIB] and it is expected that the information defined in this document will be incorporated into a future update of the Printer MIB. "DIAMETER Resource Management Extensions", Pat Calhoun, N Greene, 09/28/2000, <draft-calhoun-diameter-res-mgmt-06.txt> DIAMETER is an authentication, authorization and accounting (AAA) protocol used for network access services, such as dial-up (NASREQ) and Mobile IP. Some DIAMETER servers maintain state information of active sessions on the access servers, which is used mostly to enforce some local policy decisions. This extension describes an extension to the DIAMETER protocol that allows the server to query for active session state information from access servers in order to rebuild state information should it be lost for any reason. "The Java SASL Application Program Interface", J Myers, R. Weltman, 03/01/2000, <draft-weltman-java-sasl-03.txt> This document defines a client-side and a server-side Java language interface for using the Simple Authentication and Security Layer (SASL) mechanisms for adding authentication support to connection- based protocols. The interface promotes sharing of SASL mechanism drivers and security layers between applications using different protocols. It complements but does not replace [SASL], which defines and exemplifies use of the SASL protocol in a language-independent way. "The audio/mpeg Media Type", Martin Nilsson, 08/28/2000, <draft-nilsson-audio-mpeg-03.txt> The audio layers of the MPEG-1 and MPEG-2 standards are in frequent use on the internet, but there is no uniform MIME type for these files. The intention of this draft is to standardize the use of audio/mpeg as its media type. "The application/smil Media Type", Philipp Hoschka, 10/23/2000, <draft-hoschka-smil-media-type-06.txt> This document specifies the Media Type for version 1 of the Synchronized Multimedia Integration Language (SMIL 1.0). SMIL allows integrating a set of independent multimedia objects into a synchronized multimedia presentation. "DIAMETER Framework Document", Glen Zorn, Ping Pan, Pat Calhoun, Haseeb Akhtar, 06/16/2000, <draft-calhoun-diameter-framework-08.txt> Current Internet Service Providers (ISPs) scale their networks by using the RADIUS protocol, which provides user Authentication, Authorization and Accounting (AAA) of Dial-up PPP clients. The recent work done in the Roaming Operations (ROAMOPS) Working Group was to investigate whether RADIUS could be used in a roaming network, and concluded that RADIUS was ill-suited for inter-domain purposes. The IETF has formed a new NAS Requirements Working Group, and part of their charter is to document the next generation NAS' AAA requirements. Recently, the Mobile-IP Working Group also documented their own AAA requirements that would help Mobile IP scale for Inter-Domain mobility. The DIAMETER protocol is a follow-on to the RADIUS protocol. DIAMETER addresses the known RADIUS deficiencies, and is intended for use with the NASREQ and Mobile IP application space. "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", Ravinder Chandhok, Geoffrey Wenger, 03/23/1999, <draft-chandhok-listid-04.txt> Software that handles electronic mailing list messages (servers and user agents) needs a way to reliably identify messages that belong to a particular mailing list. With the advent of list management headers [RFC2369] it has become even more important to provide a unique identifier for a mailing list regardless of the particular host that serves as the list processor at any given time. The List-Id header provides a standard location for such an identifier. In addition, a namespace for list identifiers based on fully qualified domain names is described. This namespace is intended to guarantee uniqueness for list owners who require it, while allowing for a less rigorous namespace for experimental and personal use. By including the List-Id field, list servers can make it easier for mail clients to provide automated tools for users to perform list functions. The list identifier can serve as a key to make many automated processing tasks easier, and hence more widely available. 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. "E.164 number and DNS", Patrik Faltstrom, 01/31/2000, <draft-faltstrom-e164-05.txt> This document discusses the use of DNS for storage of E.164 numbers. More specifically, how DNS can be used for identifying available services connected to one E.164 number. Routing of the actual connection using the service selected using these methods is not discussed. Discussion on this Internet-Draft is to be held on the mailing list ietf-e164-dns@imc.org, which is hosted by the Internet Mail Consortium. To subscribe, send an email to ietf-e164-dns-request@imc.org, with the text 'subscribe' as the only word in the body of the mail. There is an archive of the mailing list at <http://www.imc.org/ietf-e164-dns/>. "Transmission of IPv6 Packets over IEEE 1394 Networks", Kenji Fujisawa, 06/27/2000, <draft-fujisawa-ip1394-ipv6-04.txt> IEEE Std 1394-1995 is a standard for a High Performance Serial Bus. This document proposes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also proposes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network. "DIAMETER Mobile IP Extensions", C Perkins, Pat Calhoun, 09/28/2000, <draft-calhoun-diameter-mobileip-11.txt> This document specifies an extension to the DIAMETER base protocol that allows a DIAMETER server to authenticate, authorize and collect accounting information for services rendered to a mobile node. Combined with the Inter-Domain capability of the base protocol, this extension allows mobile nodes to receive service from foreign service providers. The DIAMETER Accounting extension will be used by the Foreign and Home agents to transfer usage information to the DIAMETER servers. "Simple Commerce Messaging Protocol (SCMP)Version 1 Message Specification", Tom Arnold, Jason Eaton, 06/16/2000, <draft-arnold-scmp-07.txt> 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. "IPSec Re-keying Issues", Tim Jenkins, 05/03/2000, <draft-jenkins-ipsec-rekeying-06.txt> 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. "Tree-based Reliable Multicast (TRAM)", Miriam Kadansky, Joe Wesley, Dah Ming Chiu, Joseph Provino, 01/10/2000, <draft-kadansky-tram-02.txt> 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. "Common Gateway Interface for SIP", Jonathan Rosenberg, H. Schulzrinne, Jonathan Lennox, 06/06/2000, <draft-lennox-sip-cgi-04.txt,.ps> In Internet telephony, there must be a means by which new services are created and deployed rapidly. In the World Wide Web, the Common Gateway Interface (CGI) has served as popular means towards programming web services. Due to the similarities between the Session Initiation Protocol (SIP) and the Hyper Text Transfer Protocol (HTTP), CGI seems a good candidate for service creation in a SIP environment. This draft proposes a SIP-CGI interface for providing SIP services on a SIP server. "Sieve -- IMAP flag Extension", Alexey Melnikov, 10/16/2000, <draft-melnikov-sieve-imapflags-04.txt> Recent discussions have shown that it is desirable to set different [IMAP] flags on message delivery. This can be done, for example, by a SIEVE interpreter that works as a part of a Mail Delivery Agent. This document describes an extension to the Sieve mail filtering language for setting [IMAP] flags. The extension allows to set both [IMAP] system flags and [IMAP] keywords. "Multicast Discovery of DNS Services", Bill Manning, Bill Woodcock, 07/24/2000, <draft-manning-multicast-dns-02.txt> This document describes a minimal extension to the method of a DNS query which allows unconfigured hosts to locate a local DNS server, or in the absence of a DNS server to nonetheless identify some local network services. "Tree Delete Control", Michael Armijo, 08/25/2000, <draft-armijo-ldap-treedelete-02.txt> This document defines an LDAPv3 control that deletes an entire subtree of a container entry. This control extends the scope of the LDAPv3 delete operation as defined in RFC 2251. This control is beneficial in extending the functionality of the LDAP protocol and may be useful in administration in an LDAP environment. "BGP Extended Communities Attribute", Dan Tappan, Srihari Ramachandra, 05/19/2000, <draft-ramachandra-bgp-ext-communities-04.txt> This document describes an extension to BGP [BGP-4] which may be used to provide flexible control over the distribution of routing information. "Analysis of an Equal-Cost Multi-Path Algorithm", Chris Hopps, 02/08/2000, <draft-hopps-ecmp-algo-analysis-04.txt> Equal-cost multi-path (ECMP) is a routing technique for routing packets along multiple paths of equal cost. The forwarding engine identifies paths by next-hop. When forwarding a packet the router must decide which next-hop (path) to use. This document gives an analysis of one method for making that decision. The analysis includes the performance of the algorithm and the disruption caused by changes to the set of next-hops. "Documenting Special Use IPv4 Address Blocks", Bill Manning, 05/01/2000, <draft-manning-dsua-03.txt> This document lists the existent special use prefixes from the IPv4 space that have been registered with the IANA and provides some suggestions for operational procedures when these prefixes are encountered. This document does not address IPv4 space that is not registered with the IANA for special use or address space that is reserved for future delegation in the operational Internet. "Goals for Voice Profile for Internet Messaging, Version 3", R. Miles, Lalie Di Silvestro, 03/14/2000, <draft-ema-vpimv3-goals-01.txt> This document describes the goals of Voice Profile for Internet Mail (VPIM), Version 3 and establishes a baseline of desired functionality against which proposed MIME profiles for Internet voice messaging can be judged. The primary goal for this version is to support interoperability with desktop clients. Other goals for this version of VPIM include backward compatibility, expanded interoperability with unified messaging systems, and conformance to Internet standards. This document does not include goals that were met fully by VPIM version 2 [VPIM2]. Different levels of desirability are indicated throughout the document. "Advance Internet Caller-ID Delivery Service", Lev Slutsman, 01/11/2000, <draft-slutsman-aicd-01.txt> The Internet Call Waiting (ICW) has recently become a standard 'check-list' service offered by many Telecommunications providers such as Nortel and Lucent. While differing in many details, all these schemes rely on the LEC provider ability to detect and signal the 'busy-line' state. This signal triggers the execution of the service logic that provides the desirable effect. As a result, the Internet Call Waiting is most meaningful when offered by LEC [6] but of limited interest for long-distance providers, such as AT&T, MCI, etc. In the broader prospective, ICW may be considered a member of the class of services that manage incoming calls by making use of an Internet connection. Of special interest the Long Distance Providers is a specific subclass of services that 'by-passes' LEC; the purpose of this paper is to begin the discussion of what can be implemented when LEC services are either not available or not desirable. To this end we introduce a service--Advance Internet Caller-ID Delivery Service--that comes 'close' to ICW and yet, does not rely on the terminating LEC. In addition, this service related to the PINT 'click-to-dial' service and could make use of the PINT protocol. The rest of this document is as follows: Section 2 describes the service offered to the end Subscriber. Section 3 describes the architecture requirements to support the Advance Intenet Calle-ID Delivery Service. Section 4 descibes the call flows for typical scenarios. Sections 5 and 6 respectively supply referneces and provide the author address. "Pre-filling a cache - A satellite overview", Ivan Lovric, Cedric Goutard, Eric Maschio-Esposito, 02/21/2000, <draft-lovric-francetelecom-satellites-01.txt> Today, satellites are becoming major vectors of the information diffusion on the Internet. Their use can prove to be fully useful for the cache pre-filling because they allow big volumes of data to be transferred at high speed (up to 45 Mb/s) and to be distributed simultaneously on several reception dishes. When having this pre- filling information on the cache, users can benefit from better access time to the stored pages. In this context, the satellite allows the quality of service for the end user to be improved by optimizing satellite links and by transferring large volumes of data directly only when the traffic on the network is low. "The VCDIFF Generic Differencing and Compression Data Format", Kiem-Phong Vo, David Korn, 03/10/2000, <draft-korn-vcdiff-01.txt> This memo describes a general and efficient data format suitable for encoding compressed and/or differencing data so that they can be easily transported among computers. "Load control of real-time traffic", David Partain, Zoltan Richard Turanyi, Lars Westberg, 04/19/2000, <draft-westberg-loadcntr-03.txt> The purpose of this memo is to present a new resource allocation scheme for DiffServ (DS) networks, called Load Control. The main purpose of Load Control is to provide a simple and scalable solution to the resource provisioning problem. Load Control addresses two particular issues: 1. Measurement-based access control, whereby a probe packet is sent along the forwarding path in a network to determine whether a flow can be admitted based upon the current congestion state of the network 2. A lightweight reservation of a certain amount of network resources. Load Control uses two-bit markers in packet headers to carry load information from core routers to edge devices. The scheme provides the capability of controlling the traffic load in the network without requiring signaling or any per-flow processing in the core routers. The complexity of Load Control is kept to a minimum to make implementation simple. "The UDP Lite Protocol", S. Pink, M. Degermark, Lars-Åke Larzon, 07/19/2000, <draft-larzon-udplite-03.txt> This document describes the UDP Lite Protocol, which is similar to classic UDP [RFC-768], but aimed at applications which can handle a partially damaged payload in lossy network environments. If this feature is not used, it is semantically identical to classic UDP. "VPIM Addressing", Glenn Parsons, 03/16/2000, <draft-ema-vpim-address-01.txt> This document lists the various VPIM email addresses that are currently in common use and defines several new address formats for special case usage. This draft is a part of the charter of the IETF VPIM BOF/WG. The VPIM WG home page is: http://www.ema.org/vpim "Using Microsoft Word to create Internet Drafts and RFC's", Tony Hain, M. Gahrns, 07/10/2000, <draft-hain-msword-template-02.txt> This document will describe the steps to configure the Microsoft Word application to produce documents in Internet Draft and RFC format. "Connection/Link Status Investigation (CSI) IPv6 Hop-by-Hop option and ICMPv6 messages Extension", Hiroshi Kitamura, 09/01/2000, <draft-kitamura-ipv6-hbh-ext-csi-02.txt> This document proposes a new mechanism called 'Connection/Link Status Investigation (CSI)'. It is designed to collect status information of nodes along the communication path. One new IPv6 Hop-by-Hop option (CSI option) and three new ICMPv6 messages (Status Request/Reply, and Status Report) are proposed as extensions for the CSI mechanism. The CSI mechanism is based on hop-by-hop data acquisition operations and realtime 'boomerang' action messages. It is simple and can investigate both outgoing and incoming paths between the source and the destination with minimum investigation packets. It can provide various new functions (e.g. realtime consumed bandwidth measurement, etc.). Since it has good characteristics, it is possible to innovate current investigation functions (e.g., 'traceroute', 'pathchar', etc.) This document describes specifications of the CSI mechanism and defines a set of basic data types. The CSI mechanism is designed as a generic framework mechanism. By defining new data types to collect, it can be easily applied to various advanced usages. "SNMP over TCP Transport Mapping", J. Schoenwaelder, 04/27/2000, <draft-irtf-nmrg-snmp-tcp-04.txt> This memo defines a transport mapping for using the Simple Network Management Protocol (SNMP) over TCP. The transport mapping can be used with any version of SNMP. This document extends the transport mappings defined in RFC 1906 "Rescap Profile for Mail User Agents", Paul Hoffman, 08/09/2000, <draft-hoffman-rescap-mua-03.txt> This document defines a profile of the rescap protocol [RESCAP-MAIN] for mail user agents (MUAs) and mail recipients. It describes the attributes that a mail sender might want or need to know about a particular mail recipient before sending a message. "The VND Tree for URL Scheme Names", Ian King, 07/24/2000, <draft-king-vnd-urlscheme-02.txt> This document describes the vnd scheme namespace, or 'tree,' which provides for vendor-specific URL scheme namespaces with relaxed registration requirements, which can be used with no concern for name collision. The namespace also implicitly provides identification of the originator of the URL scheme, in the event others become interested in the scheme. "Fast Handoffs in Mobile IPv4", Karim El Malki, H Soliman, 09/27/2000, <draft-elmalki-mobileip-fast-handoffs-03.txt> This draft describes a method to achieve Fast Handoffs in Mobile IPv4. Fast Handoffs are required in Mobile IPv4 in order to limit the period of service disruption experienced by a wireless Mobile Node when moving between Foreign Agents. This requirement becomes even more important when supporting real-time services. Fast Handoffs involve anticipating the movement of MNs by sending multiple copies of the traffic to potential Mobile Node movement locations (i.e. FAs). Both a flat and a Hierarchical Mobile IPv4 model are considered. The Hierarchical MIPv4 model in Regional Tunnel Management [1] already offers improvements to Mobile IP handoffs by providing local Home Agent functionality. Some additions are made to the operation of this existing Hierarchical model to achieve Fast Handoffs and limit or avoid triangle routing within the hierarchical domain. "ACTS Protocol and Timesetting Services", T. Glassey, 09/14/2000, <draft-glassey-acts-02.txt> The Automated Computer Time Service [ACTS] has been provided since 1988 for public users who need to synchronize computer clocks to the correct time to a Federally Provided timesource for security, audit, or just general synchronization purposes. In the current evolving EC aware landscape, the source of time used in best computing practices is more and more important to the overall dependability of the trust model. This document then, is filed for historical purposes on the already widely used, publicly available ACTS time service protocol. [AWTT] "A taxonomy of multicast security issues", Ran Canetti, Benny Pinkas, 08/21/2000, <draft-irtf-smug-taxonomy-01.txt> With the growth and commercialization of the Internet, the need for secure IP multicast is growing. In this draft we present a taxonomy of multicast security issues. We first sketch some multicast group parameters that are relevant to security, and outline the basic security issues concerning multicast in general, with emphasis on IP multicast. Next we suggest two 'benchmark' scenarios for secure multicast solutions. Lastly we review some previous works. "Geographic registration of HTML documents", A. Daviel, 09/27/2000, <draft-daviel-html-geo-tag-03.txt> This memo describes a method of registering HTML documents with a specific geographic location through means of embedded META tags. The content of the META tags gives the geographic position of the resource described by the HTML document in terms of Longitude, Latitude and optionally Elevation in a simple, machine-readable manner. This information may be used for automated resource discovery by means of an HTML indexing agent or search engine. "A revised signature mode for the Internet Key Exchange", Kanta Matsuura, Hideki Imai, 03/02/2000, <draft-matsuura-sign-mode-02.txt> Phase 1 of the Internet Key Exchange (IKE) [HC98] has several modes with different number of message passes. For those who want to save their bandwidth, three-pass Aggressive Mode is a good choice since it has minimal number of message passes in Phase 1. The public-key primitive method in Aggressive Mode provides significant security advantages over the other alternatives and should be the method of choice in many implementations. In this method, however, the responder must pay computational cost as expensive as modular exponentiation BEFORE identifying the initiator. This feature can be abused by malicious initiators for a Denial-of-Service (DoS) attack. The purpose of this document is to solve this problem in digital-signature method by using falling- together (FT) mechanism [MI98], [MI99] in conjunction with stateless-connection technique [AN97] and an appropriate use of Cookies [KS99]. "SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman, 10/04/2000, <draft-hoffman-rfc2487bis-04.txt> This document describes an extension to the SMTP service that allows an SMTP server and client to use transport-layer security to provide private, authenticated communication over the Internet. This gives SMTP agents the ability to protect some or all of their communications from eavesdroppers and attackers. "Traffic Engineering Extensions to OSPF", D Katz, Derek Yeung, 10/04/2000, <draft-katz-yeung-ospf-traffic-03.txt> This document describes extensions to the OSPF protocol to support Traffic Engineering, using opaque LSAs. "Registration of Charset and Languages Media Features Tags", Paul Hoffman, 07/07/2000, <draft-hoffman-char-lang-media-04.txt> This document contains the registration for two media feature tags: 'charset' and 'language'. These media features allow specification of character sets and human languages that can be understood by devices and the devices' users. The templates in this document are derived from [TAG-REG]. "The Host Identity Payload", Robert Moskowitz, 02/03/2000, <draft-moskowitz-hip-01.txt> This memo describes the Host Identity Payload (HIP) described in the HIP architecture [HIPARCH] and the protocol that uses it to establish a rapid authentication between two hosts. The various forms of the Host Identity, HI, HIGH, and ESEL are covered in detail and how they support the authentication and the establishment of Keying Material that can be used by ESP [ESP]. The basic state machine for HIP provides a HIP compliant host with the resiliency to avoid many Dos attacks. The basic HIP exchange for two public hosts shows the actual packet flow. Other HIP exchanges, including those that work across NATs are covered in the HIP implementation document [HIPIMPL]. Further information on the other components necessary for ESP and AH implementations is provided by [Thayer97a]. "Group Secure Association Key Management Protocol", H. Harney, E. Harder, Andrea Colegrove, Uri Meth, Rod Fleischer, 06/13/2000, <draft-harney-sparta-gsakmp-sec-02.txt,.ps> The Group Secure Association Key Management Protocol (GSAKMP) provides a security framework for creating cryptographic groups on a network. It provides mechanisms to disseminate group security policy, perform access control based upon PKI certificates, generate group keys, and recover from compromise. This framework addresses group scalability issues by facillitating delegation of process-intensive actions in a secure and controlled manner. "ACP 133 Common Content and LDAP", Kathy Dally, 09/25/2000, <draft-dally-acp133-and-ldap-01.txt> In Allied Communications Publication (ACP) 133 [1], an X.500 directory user schema, called Common Content, is specified for the Allied Directory. In order to enable Lightweight Directory Access Protocol (LDAP) access to the Allied Directory and to enable the general use by others of elements from the Common Content, this document specifies the encoding of the Common Content using the LDAP notation from Request for Comments (RFC) 2252 [2]. "Tags for the Identification of Languages", Harald Alvestrand, 10/19/2000, <draft-alvestrand-lang-tag-v2-05.txt> This document describes a language tag for use in cases where it is desired to indicate the language used in an information object, how to register values for use in this language tag, and a construct for matching such language tags. "Simple Operations on Subtrees (for LDAP)", Bruce Greenblatt, 08/21/2000, <draft-greenblatt-ldapext-sos-01.txt> This draft defines several new LDAP extensions. These extensions are operations that can manipulate an entire portion of Directory Infor- mation Tree at once (DIT). This draft does not presume any specific DIT structure or schema modifications. "Transport Adapter Layer Interface", J Keller, Dan Brendes, David Sprague, Robby Benedyk, 06/20/2000, <draft-benedyk-sigtran-tali-01.txt> This document proposes the interfaces of a Signaling Gateway, which provides interworking between the Switched Circuit Network (SCN) and an IP network. Since the Gateway is the central point of signaling information, not only does it provide transportation of signaling from one network to another, but it can also provide additional functions such as protocol translation, security screening, routing information, and seamless access to Intelligent Network(IN) services on both networks. The Transport Adapter Layer Interface (TALI) is the proposed interface, which provides TCAP, ISUP, and MTP messaging over TCP/IP. In addition, TALI provides SCCP Management (SCMG), MTP Primitives, dynamic registration of circuits, and routing of call control messages based on circuit location. "IETF Meeting Network Infrastructure Lore", N Bourbaki, 09/12/2000, <draft-ymbk-termroom-op-04.txt> Creating and running the 'terminal room' for an IETF meeting is tantamount to building, running, and dismantling a small computer center. Although this is a well-known area of operations, the unique environment and its ephemeral nature warrant passing on the lore in a mildly organized fashion. It is expected that this document will be updated regularly. However, it is not clear that this will ever be published as an RFC. As the IETF can ill afford failure of this service, it is assumed that the host and organizers have the experience and resources to build such environments, understand power facilities, cabling, WAN and LAN building, workstation provisioning, staffing, etc. So this document does not attempt to detail how to build computer facilities or carry out prudent project management. Rather it concentrates on the unique aspects of the IETF 'terminal room'. "SMIng - A new Structure of Management Information", Frank Strauss, 02/15/2000, <draft-irtf-nmrg-sming-02.txt> This memo presents a language for management information specifications. It eliminates known problems present in the current SMIv2 as specified in [2], [3], and [4]. Language extensibility features and a more efficient and programmer-friendly notation are introduced. Conversions from SMIv2 to SMIng and vice versa are also considered by this document. "A revised media feature set matching algorithm", G. Klyne, 04/07/2000, <draft-klyne-conneg-feature-match-02.txt> RFC 2533, 'A syntax for describing media feature sets', defines a format to express media feature sets that represent media handling capabilities. It also describes an algorithm for matching these feature sets, which may be used, for example, to determine whether the capabilities of a sender and receiver are compatible. This memo describes a revised form of the feature set matching algorithm, which incorporates lessons learned while implementing the original algorthm. It is anticipated that this revised algorithm description will be included in a future revision of RFC 2533. This memo does not affect any of the normative content of RFC 2533. "Distributed Core Multicast (DCM): a routing protocol for many small groups with application to mobile IP telephony", J. Le Boudec, Ljubica Blazevic, 06/21/2000, <draft-blazevic-dcm-mobility-01.txt> This document specifies a multicast routing protocol called Distributed Core Multicast (DCM). It is intended for use within a large single Internet domain network with a very large number of multicast groups with a small number of receivers. Such a case occurs, for example, when multicast addresses are allocated to mobile hosts, as a mechanism to manage Internet host mobility. For such networks, existing dense or sparse mode multicast routing algorithms do not scale well with the number of multicast groups. DCM is based on an extension of the centre-based tree approach [1], [2]. It uses several core routers, called Distributed Core Routers (DCRs) and a special protocol between them. DCM aims: (1) to avoid multicast group state information in backbone routers, (2) to avoid triangular routing across expensive backbone links, (3) to scale well with the number of multicast groups. We analyse how DCM can be used to route packets to mobile hosts in cellular IP telephony, where each mobile host is assigned a multicast address in every domain it visits. The benefits of multicasting-based approach to route packets to mobile hosts are low latency and no disruption during handover. "Realtime Traffic over Cellular Access Networks", Lars Westberg, Morgan Lindquist, 05/23/2000, <draft-westberg-realtime-cellular-02.txt> The draft discusses problems with transport of realtime traffic over cellular access channels and their implications for protocol enhancements. "RObust Checksum-based header COmpression (ROCCO)", M. Degermark, Hans Hannu, Lars-Erik Jonsson, Krister Svanbro, 03/13/2000, <draft-jonsson-robust-hc-04.txt,.ps> IP/UDP/RTP header compression [CRTP] can generate a large number of lost packets when used over links with significant error rates, especially when the round-trip time of the link is large. This document describes a more robust header compression scheme. The scheme is adaptable to the characteristics of the link over which it is used and also to the properties of the packet streams it compresses. Robustness against link-loss is achieved without decreasing compression efficiency. "A Method for Setting an Alternative Label Switched Paths to Handle Fast Reroute", Dimitry Haskin, Ram Krishnan, 05/16/2000, <draft-haskin-mpls-fast-reroute-04.txt> This document describes a method for setting an alternative label switched path to handle fast data packet reroute upon a failure in a primary label switched path in Multi-protocol Label Switching (MPLS) network. "The Congestion Manager", Srinivasan Seshan, Hari Balakrishnan, 03/14/2000, <draft-balakrishnan-cm-02.txt> 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. "Using PIM to Distribute MPLS Labels for Multicast Routes", Dino Farinacci, Tian-Bai Qian, Y Rekhter, E. Rosen, 07/12/2000, <draft-farinacci-mpls-multicast-02.txt> This document specifies a method of distributing MPLS labels [MPLS- ARCH, MPLS-MUL-FR] for multicast routes. The labels are distributed in the same PIM messages that are used to create the corresponding routes. The method is media-type independent, and therefore works for multi-access/multicast capable LANs, point-to-point links, and NBMA networks. "Mechanisms for end-2end native transport", Bernard Sales, Yves T''''Joens, C Zaccone, 03/14/2000, <draft-zaccone-nat-transport-02.txt> This document describes some mechanisms to enable an IP network to transport both the IP traffic of the local realm and the IP traffics of external realms in the native (non-tunneled) way [TRANSP-FRAM]. The methods, described in this document, provide to the routers of the operated network the necessary information enabling the delivery of IP traffics originated from the foreign realms the operator offer connectivity to. This information is derived by the currently available routing information routers have and is moreover provided to them by the mean of a local delivery mechanism. "Connectionless Multicast", Oliver Paridaens, Wim Livens, Dirk Ooms, 04/21/2000, <draft-ooms-cl-multicast-02.txt> This draft proposes a new mechanism for multipoint-to-multipoint (mp2mp) communication in IP networks, namely Connectionless Multicast (CLM). Instead of a group address, a list of member addresses is encoded in the data packets. The traditional Host Group Model [DEER] for IP multicast requires a globally unique address for each session. To support this model, multicast routing protocols create state per group in the routers. Like any connection oriented protocol, it suffers from scalability problems in backbone networks where the number of groups to be maintained can be huge. CLM does not have this problem, and additionally has some other advantages. Its limitation lies in the number of members per multicast session, not in the number of sessions. CLM will not replace the traditional multicast model. CLM offers an alternative for mp2mp communication in the cases that traditional multicast becomes problematic. The pros and cons of CLM are described and suggestions are made to alleviate the disadvantages. Furthermore different modes of operation are described: an end-to-end mode in close conjunction with SIP (Session Initiation Protocol [HAND]), as well as an interworking mode with PIM-SM and Simple Multicast. Both IPv4 and IPv6 are considered. "Accessing IN services from SIP networks", Vijay Gurbani, 05/04/2000, <draft-gurbani-iptel-sip-to-in-02.txt> In Internet telephony, the call control functions of a traditional circuit switch are replaced by a IP-based call controller that must provide features normally provided by the traditional switch, including operating as a SSP for IN features. A traditional switch is armed with an IN call model that provides it a means to reach out and make service decisions based on intelligence stored elsewhere. Internet call controllers, by contrast, do not have an IN call model. Furthermore, since there are many Internet call models with varying number of states than the IN call model, there has to be a mapping from the IN call model states to the equivalent states of the Internet call model if existing services are to be accessed transparently. To leverage the existing IN services from the Internet domain, this draft proposes a mapping from the states of the IN call model to the states of SIP, an Internet call signaling protocol. "Simple Phone Control Protocol (SPCP)", Masahiro Matsuda, Noriyuki Fukuyama, T Kanai, Masanobu Morinaga, 06/07/2000, <draft-kanai-spcp-02.txt> This specification defines Simple Phone Control Protocol (SPCP) as an application-level protocol, which allows network devices, such as PCs, to control IP telephones. This document explains the protocol specification, how to use SPCP, and how to configure a system that uses SPCP. "Voice Profile for Internet Mail - Version 3 A Simple Approach", Glenn Parsons, 03/16/2000, <draft-ema-vpim-simplev3-01.txt> This document proposes an alternative simple approach to VPIM v3. "Handle System Namespace and Service Definition", Larry Lannom, Sam Sun, Sean Reilly, 08/15/2000, <draft-sun-handle-system-def-03.txt> The Handle System is a general-purpose global name service that allows secured name resolution and administration over the public Internet. The Handle System manages handles, which are unique names for digital objects and other Internet resources. This document provides a detailed description of the Handle System namespace, data and service model, as well as its operation and authentication protocol. It assumes that readers are familiar with the basic concepts of the Handle System as i ntroduced in the overview document. "IP micro-mobility support using HAWAII", K. Varadhan, L. Salgarelli, Thomas La Porta, R. Ramjee, S. Thuel, 07/17/2000, <draft-ietf-mobileip-hawaii-01.txt> 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. "Paging support for IP mobility using HAWAII", Thomas La Porta, R. Ramjee, Li Li, 07/17/2000, <draft-ietf-mobileip-paging-hawaii-01.txt> This document defines extensions to the HAWAII IP micro-mobility protocol to enable paging. Paging facilitates efficient power management at the mobile host by allowing the host to update the network less frequently at the cost of providing the network with only approximate location information. The protocol extensions described here provide a means for the network to determine the exact location of a mobile host before delivering packets destined to the mobile host. "Security Requirements/Implementation Guidelines for Mobile IP using IP Security", Emad Qaddoura, Basavaraj Patil, Raja Narayanan, 05/23/2000, <draft-bpatil-mobileip-sec-guide-01.txt> The IP Security protocol is now well established and is being deployed in the global Internet. The security characteristics of IPSec can be used in Mobile IP networks to enable Mobile IP deployment on a wide area basis and in large networks. Mobile IP should leverage off of the developments of IP Security and Internet Key Exchange (IKE) rather than developing it's own security mechanisms. This draft proposes some concepts on how IP Security can be used to provide an alternative security framework for Mobile IP communications. It is intended to be an implementation guideline. "A Kerberos Security Model for SNMPv3", Ken Hornstein, Wesley Hardaker, 06/13/2000, <draft-hornstein-snmpv3-ksm-01.txt> This document describes a proposed Kerberos Security Model (KSM) for SNMP version 3 for use in the SNMP architecture [RFC2271]. It defines the Elements of Procedure for providing SNMP message level security with Kerberos [RFC1510]. "Definition of the DNS GL Resource Record used to encode Geographic Locations", A. Costanzo, 06/13/2000, <draft-costanzo-dns-gl-03.txt> This document defines the format of a new Resource Record (RR) namely GL for the Domain Naming System (DNS), and reserves a corresponding DNS type mnemonic and numerical code XX (decimal). This definition deals with associating geographical host location mappings to host names within a domain. "MIB Definition for PPP Over Ethernet (PPPoE)", Ross Wheeler, Bill Vroman, Rohit Verma, Janakiraman Senthilnathan, 10/18/2000, <draft-wheeler-info-pppoe-mib-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing networks using PPP over Ethernet Protocol. "UTF-5, a transformation format of Unicode and ISO 10646", M. Duerst, James Seng, Tim Tan, 01/28/2000, <draft-jseng-utf5-01.txt> 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. "Uniform Object Locator -- UOL", Jon Boynton, 08/08/2000, <draft-boynton-uol-02.txt> A Uniform Object Locator (UOL) provides a general-purpose identifier for 'human' interaction with object oriented data. UOL is designed to meet the recommendations for URI queries laid out in 'Uniform Resource Identifiers (URI) Generic Syntax' [RFC2396]. This document defines syntax and semantics of UOL, including both absolute and relative forms, and guidelines for their use; it revises features definitions, and examples, given in 'draft-boynton-uol-00' and updates the scheme to provide additional functionality. "An Effective way for Enhancement of TCP Performance in Wireless and Mobile Networks", Jian Ma, Fei Peng, 07/17/2000, <draft-fpeng-wecn-02.txt> TCP congestion control has been developed on the assumption that congestion in the network to be the only cause for packet loss. Thus, it drops its transmit window upon detecting a packet loss. In the presence of high erro rates and intermittent connective characteristic of wireless link, these results in an unnecessary reduction in link bandwidth utilization for packet losses are not mainly due to congestion. "IP over MIME", Donald Eastlake 3rd, 06/06/2000, <draft-eastlake-ip-mime-03.txt> The MIME encoding of IP packets is standardized so they can conveniently be sent via MAIL, HTTP, etc. This may be convenient for transmitting packets for analysis or for creating application level tunnels. "The Performance Transparency Protocol (PTP)", Michael Welzl, 05/22/2000, <draft-welzl-ptp-03.txt> Adaptive Internet applications need to know certain network performance parameters. Recent efforts have shown that it is possible for end-systems to determine quite a few of these parameters by probing the network, but the methods used are often time-consuming, mostly show network-unfriendly behaviour and in some cases the results are just not precise enough. We describe a protocol that allows end-systems to efficiently retrieve this information without putting much load onto the network or complexity in routers. "LDAP Authentication Response Control", Mark Smith, M. Wahl, R. Weltman, 10/20/2000, <draft-weltman-ldapv3-auth-response-02.txt> This document defines support for the Authentication Request Control and the Authentication Response Control. Controls are an LDAP protocol version 3 extension, to allow passing arbitrary control information along with a standard request to a server, and to receive arbitrary information back with a standard result. The Authentication Request Control may be submitted by a client in a bind request if authenticating with version 3 of the LDAP protocol. In the LDAP server's bind response, it may then include an Authentication Response Control. The response control contains the identity assumed by the client. This is useful when there is a mapping step or other indirection during the bind, so that the client can be told what LDAP identity was granted. Client authentication with certificates is the primary situation where this applies. Also, some SASL authentication mechanisms may not involve the client explicitly providing a DN. "Secure Remote Password SASL Mechanism", Keith Burdis, 09/13/2000, <draft-burdis-cat-srp-sasl-03.txt> This document describes an SASL mechanism based on the Secure Remote Password protocol. The mechanism includes mutual authentication and can provide a security layer with replay detection, integrity protection and/or confidentiality protection. "Intrusion Detection Message MIB", Glenn Mansfield, Dipankar Gupta, 01/31/2000, <draft-glenn-id-notification-mib-02.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines the contents of messages that will be exchanged among intrusion detection systems when an intrusion is detetcted. "Xdossier", M. Benitez, 05/31/2000, <draft-carrasco-xdossier-02.txt> This is an informational memo for Xdossier. A Xdossier is a data object designed for browsing with web browsers and mappable to XML. It is based on a directory structure containing files in several formats. "Referal extension to the Whois protocol", Mark Kosters, Patrik Faltstrom, 05/02/2000, <draft-faltstrom-whois-04.txt> This document presents extensions to the Whois protocol output format which enables a possibility for the server to send referal information to the Whois client. This referal mechanism can be used for example in a situation with a registrar/registry model, where the registrars all have their own Whois databases, and together they serve a whole TLD. It can also be used when implementing a root-whois service on top of all whois servers in the world, and this way enable the possibility of creating advanced proxy services. For the latter, a registration procedure is also suggested, where Whois services can be registered. Discussion on this Internet-Draft is to be held on the mailing list ietf-whois-ext@imc.org, which is hosted by the Internet Mail Consortium. To subscribe, send an email to ietf-whois-ext-request@imc.org, with the text 'subscribe' as the only word in the body of the mail. There is an archive of the mailing list at <http://www.imc.org/ietf-whois-ext/>. "LDAP Object Class for Holding Certificate Information", Bruce Greenblatt, 02/21/2000, <draft-greenblatt-ldap-certinfo-schema-02.txt> 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. "Geographic extensions for HTTP transactions", A. Daviel, 09/27/2000, <draft-daviel-http-geo-header-02.txt> This memo describes a method of adding simple geographic position information to HTTP transactions using extension headers. In the case of an HTTP request, the extensions indicate a geographic position or region that the requesting agent is interested in. This information may be used by a server to present appropriate position- dependant responses, such as search engine results, without the additional overhead of geographic query requests. In the case of an HTTP response, the extensions indicate a geographic position or region relevant to the resource described in the body of the response. This information may be used for automated resource discovery. "Defining the IETF", Scott Bradner, Paul Hoffman, 10/23/2000, <draft-hoffman-what-is-ietf-04.txt> Many RFCs refer to 'the IETF'. Many important IETF documents speak of the IETF as if it was an already-defined entity. However, no IETF document really defines well what the IETF is. This document gives a more concrete definition of 'the IETF' as it understood today. "SKiCal - an adaptation of iCalendar for describing public events", Greg FitzPatrick, Niclas Hjelm, Par Lannero, 05/30/2000, <draft-many-ical-ski-02.txt> This Memo defines the SKiCal format. SKiCal is a machine-readable and machine-understandable format for describing public events and other phenomena in time and space. SKiCal is based on and extends the iCalendar format as defined by RFC-2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar) [3]. SKiCal objects are basically iCalendar objects containing VEVENT components with the additions of new properties and property parameters. SKiCal takes the iCalendar paradigm further by addressing the commonalties of resource publishers in a wider domain than that of appointments and business meetings. SKiCal is suitable for events, businesses, retailers and services as well as publicly accessible resources within the sectors of tourism, sport, culture, education and entertainment. Several examples of real events are shown (See section 8) which demonstrate the flexibility and compactness of SKiCal. "IP Payload Compression Protocol (IPComp)", M. Thomas, R. Monsour, Roy Pereira, A. Shacham, 10/12/2000, <draft-shacham-ippcp-rfc2393bis-06.txt> This document describes a protocol intended to provide lossless compression for Internet Protocol datagrams in an Internet environment. "A proposal to apply ECN into Wireless and Mobile Networks", Jian Ma, Fei Peng, 07/17/2000, <draft-fpeng-ecn-02.txt> TCP congestion control has been developed on the assumption that congestion in the network to be the only cause for packet loss. Thus, it drops its transmit window upon detecting a packet loss. In the presence of high error rates and intermittent connective characteristic of wireless link, these results in an unnecessary reduction in link bandwidth utilization for packet losses are not mainly due to congestion. "XML Media Types", Daniel Kohn, Makoto Murata, Simon St.Laurent, 09/19/2000, <draft-murata-xml-09.txt> This document standardizes five new media types, text/xml, application/xml, text/xml-external-parsed-entity, application/xml-external-parsed-entity, and application/xml-dtd, for use in exchanging network entities which are related to the Extensible Markup Language (XML). This document also standardizes a convention (using the suffix '|xml') for naming media types outside of these five types when those media types represent XML entities. XML MIME entities are currently exchanged via the HyperText Transfer Protocol on the World Wide Web, are an integral part of the WebDAV protocol for remote web authoring, and are expected to have utility in many domains. "DIAMETER Accounting Extension", Glen Zorn, Pat Calhoun, Jari Arkko, Pamnkaj Patel, 09/28/2000, <draft-calhoun-diameter-accounting-08.txt> The DIAMETER protocol provides Authentication and Authorization for network access technologies, such as NASREQ, ROAMOPS and Mobile IP. The ROAMOPS WG has been working on an accounting data format, called Accounting Data Interchange Format (ADIF), as a method to transfer accounting information over a wide variety of transports. This extension describes how accounting records can be securely transmitted over the DIAMETER protocol. When combined with the Strong Security extension, accounting records MAY traverse intermediate proxies in a secure fashion and is compatible with the referral broker model. This extension allows for both real-time and batched accounting transfers. "Notification and Subscription for SLP", James Kempf, Jason Goldschmidt, 09/12/2000, <draft-kempf-srvloc-notify-04.txt> The Service Location Protocol provides mechanisms whereby service agent clients can advertise and user agent clients can query for services. The design is very much demand-driven, so that user agents only obtain service information when they specifically ask for it. There exists another class of user agent applications, however, that requires notification when a new service appears or disappears. In the RFC 2608 design, these applications are forced to poll the network to catch changes. In this document, we describe a protocol for allowing such clients to be notified when a change occurs, removing the need for polling. "ECML v1.1: Field Specifications for E-Commerce", Donald Eastlake 3rd, Ted Goldstein, 09/28/2000, <draft-eastlake-ecom-fields2-04.txt> Customers are frequently required to enter substantial amounts of information at an Internet merchant site in order to complete a purchase or other transaction, especially the first time they go there. A standard set of information fields is defined as the first version of an Electronic Commerce Modeling Language (ECML) so that this task can be more easily automated, for example by wallet software that could fill in fields. Even for the manual data entry case, customers will be less confused by varying merchant sites if a substantial number adopt these standard fields. In addition, some fields are defined for merchant to consumer communication. "Minimal Latency Secure Hand-off", Pat Calhoun, Emad Qaddoura, Haseeb Akhtar, N Asokan, 02/11/2000, <draft-calhoun-mobileip-min-lat-handoff-01.txt> The Mobile IP Working Group has been working on defining its AAA requirements, which currently supports a Key Distribution Center (KDC) model that issues temporary session keys for use between the mobility nodes. In order to support real-time traffic, the Mobile IP architecture also requires that hand-off be done in a quick and efficient manner, and has provisions to allow new foreign agents to retrieve the session keys from the AAA infrastructure. Although the AAA infrastructure can assist in the hand-off process, this is largely a mobility problem, and should be dealt with in the mobility protocol. This draft describes how the mobile node can assist in the hand-off process by carrying the foreign agent's keying information, providing the keys to new foreign agents (within the same administrative domain) while registering. This proposal is intended to decrease the latency involved in the hand-off process, thereby enabling seamless real time traffic over Mobile IP networks. This draft still allows the foreign agents to get keying information from the AAA infrastructure should that be necessary. At present, authentication in Mobile IP uses shared key cryptography. However, this proposal is general enough to be able to accommodate authentication based on public key digital signatures if and when it becomes feasible. "Attribute List Extension for the Service Location Protocol", Erik Guttman, 10/18/2000, <draft-guttman-svrloc-attrlist-ext-04.txt> The Service Location Protocol, Version 2 provides a mechanism for a service to be discovered in a single exchanged of messages. This exchange of messages does not presently include any of the service's attributes. This document specifies a SLPv2 extension which allows a User Agent to request a service's attributes be included as an extension to Service Reply messages. This will eliminate the need for multiple round trip messages for a UA to acquire all service information. "LDAP Bulk Update/Replication Protocol", Jim Sermersheim, Rod Harrison, Yulin Dong, 06/23/2000, <draft-rharrison-lburp-02.txt> The LDAP Bulk Update/Replication Protocol (LBURP) described in this document allows an LDAP client (a genuine client or an LDAP server acting as a client) to perform a bulk update to a replica on an LDAP server. The protocol groups a set of update operations using the LDAP framed protocol requests defined in [FRAMING] to notify the client that the update operations in the framed set are related. The update operations within the framed set are LDAPv3 extended operations each encapsulating a sequence number and one or more LDAPv3 update operations. The sequence number allows the server to process the update operations in the proper order even when they are sent asynchronously by the client, and the update operations can be grouped within the extended request to maximize the efficiency of client-server communication. The protocol may be used to initialize all of the entries in an LDAP replica or to incrementally update the existing entries in an LDAP replica. It is suitable for client utilities that need to efficiently initialize a replica with many entries or efficiently make a substantial set of update changes to a replica. It is also suitable as a protocol for replication between a single master replica and its slave replicas. "Extended Partial Response Protocol Enhancement to LDAP v3", Rod Harrison, 06/14/2000, <draft-rharrison-ldap-extpartresp-01.txt> This document describes the ExtendedPartialResponse, an element of LDAP v3 protocol which allows multiple responses to LDAP v3 extended requests. Extended partial responses are backward compatible with the existing LDAP v3 Extended Operation defined in [LDAPv3]. "SLP Scope and DA Configuration", James Kempf, Mikael Pahmp, Roger Holm, 02/17/2000, <draft-kempf-scope-rules-03.txt> RFC 2608, RFC 2610, and RFC 2614 provide rules for configuring SLP agents with scopes and DAs from the protocol, DHCP, and API view- points, respectively. The rules presented in these three documents, while not in conflict, are ambiguous in certain cases. There are also cases that fall into the cracks between the three documents. For example, if the mandatory byte is off in DHCP for scopes and there are no statically configured scopes, but there are DHCP scopes, should an agent use the DHCP scopes or not? This document specifies a sequence of steps that interoperable implementations of SLP must follow in order to obtain a clear and unambiguous scope and DA configuration. "Secure IP Multicast: Problem areas, Framework, and Building Blocks", M. Baugher, Ran Canetti, Thomas Hardjono, Peter Dinsmore, 09/21/2000, <draft-irtf-smug-framework-01.txt> This document provides a foundation for the research work done as the Secure Multicast Group (SMuG)of the IRTF. The document begins by introducing a Reference Framework and problem areas, and proceeds to identify functional building blocks for a secure multicast solution. The identified building blocks, their definition and realization will be the subject of future work of SmuG. "Orchestrally conducted Traffic ( OCT )", Heinrich Hummel, 04/18/2000, <draft-hummel-te-oct-02.txt> This draft proposes to engineer traffic such that we can speak of an Orchestrally Conducted Traffic (OCT): Any traffic stream (given by its source and destination nodes and by a priority class) may use several differently routed LSPs. Each, traffic stream ingress reports, periodically, the currently measured traffic load (in bitrate) to a common TE Conductor (TEC) who evaluates them as to forecast what traffic load change might occur in the immediate time ahead. Accordingly the TEC computes well synchronized likelihood values by which to take which route/LSP. These values will be such that any traffic stream will be served as good as possible, as often as possible, while equally ranked traffic streams are treated fair, higher ranked streams are prioritized and the network thruput is maximized. The TEC sends the likelihood values to the respective ingress node, who will distribute the received packets of the traffic stream to the pertaining LSPs accordingly. "Guidelines for Writing RFC Text on Security Considerations", E. Rescorla, Brian Korver, 06/19/2000, <draft-rescorla-sec-cons-01.txt> All RFCs are required by [RFC1543] to contain a Security Considera- tions section. The purpose of this is both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues. This memo is intended to provide guidance to RFC authors in service of both ends. This document is structured in three parts. The first is a combina- tion security tutorial and definition of common terms; the second is a series of guidelines for writing Security Considerations; the third is a series of examples. "Password Policy for LDAP Directories", Prasanta Behera, Ludovic Poitou, Valerie Chu, Jim Sermersheim, 07/11/2000, <draft-behera-ldap-password-policy-02.txt> Password policy is a set of rules that controls how passwords are used in LDAP directories. In order to improve the security of LDAP directories and make it difficult for password cracking programs to break into directories, it is desirable to enforce a set of rules on password usage. These rules are made to ensure that users change their passwords periodically, passwords meet construction requirements, the re-use of old password is restricted, and users are locked out after a certain number of failed attempts. "The management of MPLS LSPs for scalable QoS Service Provision", M Gibson, 03/14/2000, <draft-gibson-manage-mpls-qos-01.txt> There is an increasing use of real-time applications on IP networks. As these applications require certain QoS levels to operate acceptably there is a need for IP networks to guarantee such levels. This draft introduces a set of requirements that must be fulfilled in order that an MPLS network can support QoS-dependant IP flows as set out in the VoMPLS draft [2]. A candidate architecture that conforms to these requirements is then set out. The network consists of a session control layer, an IP Layer that is constrained through the use of MPLS tunnels, and a distributed management system to control those tunnels. The draft describes each of the essential components needed to implement such a network and suggests suitable technologies for each of them. "IMPROVING TOPOLOGY DATA BASE ACCURACY WITH LSP FEEDBACK VIA CR-LDP", Bilel Jamoussi, Don Fedyk, Peter Ashwood-Smith, Bilel Jamoussi, D Skalecki, 01/27/2000, <draft-ashw-mpls-te-feed-01.txt> One key component of traffic engineering is a concept known as constraint based routing. In constraint based routing a topology database is maintained on all participating nodes. This database contains a complete list of all the links in the network that participate in traffic engineering and for each of these links a set of constraints which those links can meet. Bandwidth, for example, is one essential constraint. Since the bandwidth available changes as new LSPs are established and terminated the topology database will develop inconsistencies with respect to the real network. It is not possible to increase the flooding rates arbitrarily to keep the database discrepancies from growing. We propose a new mechanism whereby a source node can learn about the successes or failures of its path selections by receiving feedback from the paths it is attempting. This fed-back information can be incorporated into subsequent route computations, which greatly improves the accuracy of the overall routing solution by significantly reducing the database discrepancies. "NAT and other Network 'Intelligence': Clearing Architectural Haze through the use of Fog Lamps", Eliot Lear, 04/14/2000, <draft-lear-foglamps-02.txt> In their workshop report the IAB once again sets forth its opinion on the use and impact of NAT devices, along with the complications of private network address space.[1,2,3] Therein they discuss the notion of 'transparency'. In this brief document we offer an alternative idea, and suggest its further study: device visibility. "DHCP Authentication Via Kerberos V", Bernard Aboba, J Trostle, Ted Lemon, Ken Hornstein, 10/05/2000, <draft-hornstein-dhc-kerbauth-03.txt> The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. In some circumstances, it is useful for the DHCP client and server to be able to mutually authenticate as well as to guarantee the integrity of DHCP packets in transit. This document describes how Kerberos V may be used in order to allow a DHCP client and server to mutually authenticate as well as to protect the integrity of the DHCP exchange. The protocol described in this document is capable of handling both intra-realm and inter-realm authentication. "Edge Mobility Architecture", Alan O''Neill, Scott Corson, George Tsirtsis, 07/19/2000, <draft-oneill-ema-02.txt> This draft outlines a system for domain-based routing and addressing support in handling edge mobility such as encountered in cellular systems and Internet roaming. The system includes novel features for IP session, address and localised host redirect route management which promise significant scaling benefits compared to other micro-mobility solutions. In addition, the system is closely integrated with the Mobile IP architecture for both signalling and data forwarding, so that a rich set of capabilities and Internet Services are possible, and incremental deployment of EMA is possible within and between AS's. The draft also suggests a specific protocol based on TORA for the implementation of such an architecture. It advocates the creation of a specific IETF working group to address an overall architecture for edge mobility routing, specific extensions to existing routing protocols to accomplish that architecture, and extensions to existing Internet technologies such as Mobile IP to support this architecture. "Multiple Destination option on IPv6(MDO6)", Imai Yuji, 09/25/2000, <draft-imai-mdo6-02.txt> The multiple Destination option on IPv6(MDO6) is an elastic multicast delivery system. MDO6 uses a list of final unicast addresses of each destination node that is embedded into an optional routing header, as the destination of a datagram. Routers on the multicast path could forward datagrams by looking up the next hop router for individual final unicast addresses with the existing unicast routing table. MDO6 has several advantages as follows. "WINS Lookup by DNS server (WINS-Lookup)", James Gilroy, Levon Esibov, 07/24/2000, <draft-levone-dns-wins-lookup-01.txt> WINS Lookup is a system that provides a limited gateway between the Domain Name System [RFC 1034] and the Windows Internet Name System [WINS]. Using WINS Lookup, a DNS server can resolve A and PTR type queries for names registered exclusively in WINS. This document describes the WINS Lookup system and the format of the WINS and WINSR resource records. "LDAPv3 Result Codes: Definitions and Appropriate Use", Mark Smith, Jim Sermersheim, Mike Just, Kris Leclair, 04/14/2000, <draft-just-ldapv3-rescodes-02.txt> 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. "Framework for end-2-end native transport", Bernard Sales, Yves T''''Joens, C Zaccone, 03/14/2000, <draft-zaccone-nat-transp-fram-01.txt> This document describes a framework for the transport of IP traffic from different routing realms inside a single network. In other words, this document describes a framework enabling a network operator to enable the parallel use of different IP routing realms within a single operated network. This framework may, for instance, be applied in the context of IPv4 private networks using an address reuse technology to offer internet connectivity or in the context of IPv4 and IPv6 interworking/migration. Till now, operating multiple realms within a single physical network was realised by the use of tunneling technologies. This document will introduce a non-tunnel based scheme for multiple realms interworking. "RSIP generic network architecture", Bernard Sales, Yves T''''Joens, C Zaccone, 03/14/2000, <draft-zaccone-nat-rsip-gen-arch-01.txt> Currently, the RSIP framework [RSIP-FRAM] focus its architecture on the typical scenario where hosts on a private realm are connected to an external realm by the mean of an unique gateway where the majority of the functionality's are concentrated. The aim of this document is to extend ths scope by describing a generic architecture. Furthermore, it tries to identify the functionality's of the system, their purposes as well as the way they interwork. The benefits of this extention are an increase of the robustness of the system and an opportunity to gain benefit of multiple connection towards one or more (multi-homing) external realms (ISPs). "Interdomain IP Communications with QoS, Authorization and Usage Reporting", Henry Sinnreich, Stephen Thomas, Steve Donovan, Diana Rawlins, 03/14/2000, <draft-sinnreich-interdomain-sip-qos-osp-01.txt> Commercial grade IP telephony requires linkage between call setup, end-to-end QoS setup, interdomain authorization and accounting. This draft considers the network model for inter-domain QoS for access and transit networks, the service models and policy implementation options. Also, interdomain authorization and accounting may require the trust services of a clearinghouse, to which the local policy server may outsource authorization for support for inter-domain accounting. The draft defines two options for QoS support for telephony: PSTN- style 'QoS Assured' or Internet-style 'QoS Enabled' service. Implementing the local policy or QoS deployment can also have two options: The more usual policy 'Pull Model' and the policy 'Push Model' that may be advantageous for large IP telephony gateway deployments. The draft illustrates the various combinations of QoS service and policy implementation for interdomain QoS with authorization and accounting. The inter-process communications between the SIP, SDP, RSVP and OSP protocol engines is illustrated. Future work for SIP/SDP and other extensions, QoS metric and policy is outlined to make interdomain QoS for IP telephony possible. "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS.", Bernard Sales, Oliver Paridaens, Yves T''''Joens, Ronnie Ekstein, 01/05/2000, <draft-ekstein-nasreq-protcomp-01.txt> 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. "Elliptic Curve KEYs and SIGs in the DNS", Donald Eastlake 3rd, R Schroeppel, 06/02/2000, <draft-schroeppel-dnsind-ecc-01.txt> A standard method for storing elliptic curve cryptographic keys and signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records. "COPS Extensions for RSVP Receiver Proxy", Keith McCloghrie, David Durham, Nitsan Elfassy, D Dutt, 07/20/2000, <draft-nitsan-cops-rsvp-proxy-02.txt> This document proposes an extension to COPS [RFC2748] and COPS Usage for RSVP [RFC2749] documents needed to support RSVP Receiver Proxy [RSVP-PROXY]. "Architectural Considerations for Providing Carrier Class Telephony Services Utilizing SIP-based Distributed Call Control Mechanisms", K.K. Ramakrishnan, Warren Marshall, 07/17/2000, <draft-dcsgroup-sip-arch-02.txt> This document provides an overview of a SIP-based Distributed Call Signaling (DCS) architecture to support carrier class packet-based voice, video, and other real time multimedia services. Companion documents [3,4,5,6] address a specific set of SIP 2.0 protocol extensions and usage rules that are necessary to implement the DCS architecture in an interoperable fashion. "SIP Extensions for Media Authorization", J.R Pickens, David Oran, D Evans, K.K. Ramakrishnan, Jonathan Fellows, Poornima Lalwaney, Burcak Beser, Flemming Andreasen, Bill Marshall, Ed Miller, Glenn Russell, Mike Mannette, Kurt Steinbrenner, 07/17/2000, <draft-dcsgroup-sip-call-auth-02.txt> This document describes the need for call authorization and offers a mechanism for call authorization that can be used for admission control and against denial of service attacks. "SIP Extensions for Caller Identity and Privacy", J.R Pickens, David Oran, K.K. Ramakrishnan, Jonathan Fellows, Poornima Lalwaney, Burcak Beser, Flemming Andreasen, Bill Marshall, Ed Miller, Glenn Russell, Kurt Steinbrenner, Doc Evans, Keith Kelly, 07/11/2000, <draft-dcsgroup-sip-privacy-02.txt> This document describes two extensions to the Session Initiation Protocol (SIP) [4]. The extensions allow callers and callees to maintain their privacy in an environment where one or more proxies serve as intermediaries which can provide the identity of the parties either directly or indirectly. The extensions allow the parties to be identified either by name or by type the latter of which can be used to identify some group of callers and callees. "IP proxy-to-proxy extensions for supporting Distributed Call State", J.R Pickens, David Oran, K.K. Ramakrishnan, Jonathan Fellows, Poornima Lalwaney, Burcak Beser, Flemming Andreasen, Bill Marshall, Ed Miller, Glenn Russell, Mike Mannette, Kurt Steinbrenner, Doc Evans, Keith Kelly, 07/13/2000, <draft-dcsgroup-sip-proxy-proxy-02.txt> In order to deploy a residential telephone service at very large scale across different domains, it is necessary for trusted elements owned by different service providers to exchange trusted information that conveys customer-specific information and expectations about the parties involved in the call. This document describes extensions to the Session Initiation Protocol (RFC2543) for supporting the exchange of customer information and billing information between trusted entities in the architecture described in (draft-dcsgroup- sip-arch-00.txt). "SIP Extensions for supporting Distributed Call State", Bill Marshall, 07/20/2000, <draft-dcsgroup-sip-state-02.txt> This document describes an extension to the Session Initiation Protocol (SIP) that enables proxies to distribute call state to user agents. The state information can be returned to the proxy when the user agent requests a change in the characteristics of the active call. By providing the ability to distribute state to the user agents where it can be securely stored, proxy servers can remain stateless for the duration of the call. This mechanism allows a proxy server to provide services that depend on call state, while still being stateless. "Multi-Protocol Lambda Switching: Combining MPLS Traffic Engineering Control With Optical Crossconnects", Rob Coltun, Y Rekhter, John Drake, Daniel Awduche, 07/24/2000, <draft-awduche-mpls-te-optical-02.txt> This document describes an approach to the design of control planes for optical crossconnects (OXCs), which leverages existing control plane techniques developed for MPLS Traffic Engineering. The proposed approach combines recent advances in MPLS traffic engineering control plane constructs with OXC technology to: (1) provide a framework for real-time provisioning of optical channels in automatically switched optical networks, (2) foster the expedited development and deployment of a new class of versatile OXCs, and (3) allow the use of uniform semantics for network management and operations control in hybrid networks consisting of OXCs and label switching routers (LSRs). The proposed approach is particularly advantageous for OXCs intended for data-centric optical internetworking systems. In such environments, it will help to simplify network administration. This approach also paves the way for the eventual incorporation of DWDM multiplexing capabilities in IP routers. "Dynamic Registration and Configuration Protocol (DRCP)", Anthony McAuley, Y. Shobatake, Sunil Madhani, S Das, S Baba, 07/24/2000, <draft-itsumo-drcp-01.txt> The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts [DHC]. DHCP was, however, designed for hosts on a fixed LAN, not for nodes roaming among commercial wireless networks. A Mobile IP [MIP] Foreign Agent gives some powerful plug and play capability for roaming hosts, especially when combined with some recent proposals [e.g., MIPA, MIPC, MIPD, MIPN, HAW, CEL, TIA]. Mobile IP functionality, however is not always needed and for some dynamic networks it may be undesirable to use Foreign Agents. This draft proposes a lightweight dynamic configuration protocol, called the Dynamic Registration and Configuration Protocol (DRCP). DRCP borrows heavily from DHCP and can switch to using DHCP protocol if only DHCP servers are present in the network; but adds features critical to roaming users. Most importantly, DRCP allows rapid configuration by moving address consistency checking from the critical path. Other new features allow: a) clients to know when to get a new address independent of the layer-2 access technology, b) efficient use of scarce wireless bandwidth, c) clients to be routers, d) dynamic addition or deletion of address pools to any DRCP node, and e) message exchange without broadcast. "ICMP Extension for One-Way Performance Metrics", Anwar Elwalid, Indra Widjaja, L Qian, 08/11/2000, <draft-elwalid-icmp-ext-01.txt> In this document we define two new ICMP message types. These new types of ICMP messages can be used as probe packets to support a variety of measurement applications. This draft gives detailed definition and format of these two new ICMP message types. It is in full conformance with the original RFC on ICMP [1], and complements the work of the IPPM working group [6][7][8]. The extension of ICMP for one-way traffic measurement is also useful for traffic engineering. "Enhancements to IP/UDP/RTP Header Compression", Stephen Casner, A. Tweedly, Dan Wing, P Ruddy, B Thompson, Tmima Koren, John Geevarghese, 03/14/2000, <draft-koren-avt-crtp-enhance-01.txt> This document describes enhancements to CRTP, the header compression algorithm for RTP streams described in [RFC2508]. Each enhancement addresses issues with RFC2508 in different deployment scenarios. Each section below provides a description of the proposed enhancement, the scenario where it is useful and the justification for its use. Each of these enhancements could be evaluated separately. The enhancements are applicable both for IPv4 and IPv6. The IPCP option ‘IP header compression’ (described in RFC2509) is also extended to negotiate using the CRTP enhancements. "RTP Prifile for RTCP-based Retransmission Request for Unicast session", S. McCanne, Matthew Podolsky, Koichi Yano, 03/15/2000, <draft-podolsky-avt-rtprx-01.txt> This document specifies a new RTP profile for retransmission of lost packets of unicast multimedia sessions. We refer to this profile as 'RTP/RX'. This profile follows RFC 1889 as it is for data exchange. Specifically for unicast session, it changes the RTCP interval and defines a new RTCP packet type for retransmission requests. This document also describes how retransmission requests and retransmission data may be sent within RTP. "Use SCTP as MEGACO Transport", C Sharp, R Stewart, Ian Rytina, Q Xie, 03/09/2000, <draft-xie-sctp4megaco-01.txt> This document discusses the use of the Simple Control Transmission Protocol (SCTP) [1], for carrying MEGACO [2] messages between an MGC and an MG. SCTP is currently being developed by IETF SIGTRAN Working Group. The framework architecture defined in RFC 2719 [3] can be used as a guideline for transporting MEGACO messages using SCTP. MEGACO implementations targeting for high capacity and high availability deployment can especially benefit from the stream capability, redundant network support, congestion avoidance, and strong security features provided by SCTP. "Guide to TV Broadcast URLs", C. Finseth, Gomer Thomas, 04/05/2000, <draft-finseth-guide-01.txt> This document provides a recommended methods for identifying resources within TV broadcast streams. These methods use the 'tv:' and 'lid:' URL/URI schemes. These schemes are defined in [1] and [2]. "Proposed Format For Presence Information", Greg Hudson, 02/11/2000, <draft-hudson-impp-presence-01.txt> This document proposes a syntax and initial tag set for presence information to be used in the IMPP protocol suite. The encoding is a subset of well-formed but not valid [XML] documents, such that it can be parsed either by a simple hand-written parser or by an XML implementation. "mSLP - Mesh-enhanced Service Location Protocol", H. Schulzrinne, Erik Guttman, Weibin Zhao, 10/09/2000, <draft-zhao-slp-da-interaction-09.txt> This document presents mSLP - the Mesh-enhanced Service Location Protocol, which enhances SLP with a fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange service registration information and maintain the same consistent data for shared scopes. mSLP improves the reliability and consistency of SLP directory services. It also greatly simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally. "Storing Vendor Information in the LDAP root DSE", Mark Meredith, 10/02/2000, <draft-mmeredith-rootdse-vendor-info-03.txt> This document specifies two LDAP attributes, vendorName and vendorVersion that MAY be included in the root DSE to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of [RFC-2251]. The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery. "OSPF Refresh and flooding reduction in stable topologies", Padma Pillay-Esnault, 05/15/2000, <draft-pillay-esnault-ospf-flooding-01.txt> This document describes extension to the OSPF protocol [1] to optimize flooding of Link State Advertisements (LSA) in stable topologies. The current behaviour of OSPF requires that all LSA be refreshed every 30 minutes regardless of the stability of the network except for Do Not Age (DNA) LSA [2]. This document proposes to generalize the use of DNA LSA so as to reduce protocol traffic in stable networks. "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", G Vaudreuil, 10/20/2000, <draft-vaudreuil-esmtp-binary2-03.txt> This memo defines two extensions to the SMTP service. The first extension enables a SMTP client and server to negotiate the use of an alternative to the DATA command, called 'BDAT', for efficiently sending large MIME messages. The second extension takes advantage of the BDAT command to permit the negotiated sending of MIME messages that employ the binary transfer encoding. This document is intended to update and obsolete RFC1830. "IPSEC Remote Access Protocol Evaluation Criteria", Bernard Aboba, 07/24/2000, <draft-aboba-ipsra-req-01.txt> This document describes criteria for evaluation of IPSEC Remote Access (IPSRA) protocols. In particular, this document focuses on criteria relevant to voluntary tunneling. "PPP EAP GSS Authentication Protocol", Bernard Aboba, 07/24/2000, <draft-aboba-pppext-eapgss-01.txt> 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. "DIAMETER NASREQ Extensions", Allan Rubens, William Bulley, Pat Calhoun, Jeff Haag, 09/28/2000, <draft-calhoun-diameter-nasreq-05.txt> This document describes the DIAMETER extension that is used for AAA in a PPP/SLIP Dial-Up and Terminal Server Access environment. This extension, combined with the base protocol, satisfies the requirements defined in the NASREQ AAA criteria specification and the ROAMOPS AAA Criteria specification. Given that it is expected that initial deployments of the DIAMETER protocol in a dial-up environment will include legacy systems, this extension was carefully designed to ease the burden of servers that must perform protocol conversion between RADIUS and DIAMETER. This is achieved by re-using the RADIUS address space, eliminating the need to perform attribute lookups. "DIAMETER Implementation Guidelines", Allan Rubens, William Bulley, Pat Calhoun, Jeff Haag, Haseeb Akhtar, 07/14/2000, <draft-calhoun-diameter-impl-guide-04.txt> The DIAMETER protocol is used for Authentication, Authorization and Accounting (AAA) for Mobile-IP, ROAMOPS and NASREQ. This document contains implementation guidelines that may be useful to DIAMETER protocol developers. "DIAMETER Strong Security Extension", William Bulley, Pat Calhoun, Stephen Farrell, 09/28/2000, <draft-calhoun-diameter-strong-crypto-05.txt> The DIAMETER base protocol defines message integrity and AVP encryption using symmetric transforms to secure the communication between two DIAMETER nodes. The base protocol also defines a DIAMETER proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. The ROAMOPS Working Group has defined a requirement that allows for the DIAMETER servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify, and/or be able to view sensitive information, within the message. The Mobile-IP and NASREQ Working Groups have stated that strong authentication is a requirement for AAA data, such as accounting records, for the purposes of non-repudiation. This DIAMETER extension specifies how strong AVP authentication, integrity and encryption can be done using asymmetric transforms, by encapsulating Cryptographic Message Syntax (CMS) data into DIAMETER AVPs. The CMS data can also be used to carry X.509 certificates. "Vendor Extensions for Service Location Protocol, Version 2", Erik Guttman, 10/16/2000, <draft-guttman-svrloc-vendor-ext-03.txt> The Service Location Protocol, Version 2 [1] contains a number of features which are left up to vendors. This document describes how each of these features can be used safely (with no possibility of name collisions). This document also describes how vendors can extend the protocol safely without requiring any IETF standardization work. Finally, this document defines a new extension to the SLPv2: The Vendor Opaque extension. "Multicast Address Allocation in Auto-Configured Networks", Bernard Aboba, Dave Thaler, 10/05/2000, <draft-thaler-zeroconf-multicast-02.txt> Today, with the rapid rise of home networking, there is an increasing need for auto-configuration mechanisms. This document describes how small networks without a multicast address allocation server may auto- allocate multicast addresses. "Transport of Layer 2 Frames Over MPLS", Andy Malis, Dan Tappan, Nasser El-Aawar, E. Rosen, K Hsu, Luca Martini, Dimitri Vlachos, Stephen Vogelsang, John Shirron, 09/11/2000, <draft-martini-l2circuit-trans-mpls-03.txt> This document describes methods for transporting the Protocol Data Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, Ethernet, and providing a SONET circuit emulation service across an MPLS network. "STRUCTURED DATA EXCHANGE FORMAT (SDXF)", Max Wildgrube, 10/23/2000, <draft-wildgrube-sdxf-08.txt> This specification describes an all-purpose interchange format for use as a file format or for net-working. Data is organized in chunks which can be ordered in hierarchical structures. This format is self-describing and cpu-independent. "LDAP Authentication Password Attribute", Kurt Zeilenga, 07/12/2000, <draft-zeilenga-ldap-authpasswd-03.txt> This document describes schema for storing information in support of user/password authentication in a LDAP [RFC2251] directory. The document defines the authPassword attribute type and related schema. The attribute type is used to store values derived from the user's password(s) (commonly using cryptographic strength one-way hash). authPassword is intended to used instead of clear text password storage mechanisms such as userPassword [RFC2256]. The values of authPassword may be used to support both LDAP 'simple' and SASL [RFC2222] password authentication mechanisms [RFC2829]. "LDAP Password Modify Extended Operation", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldap-passwd-exop-04.txt> The integration of LDAP [RFC2251] and external authentication services has introduced non-DN authentication identities and allowed for non-directory storage of passwords. As such, mechanisms which update the directory, such as Modify operation, cannot be used to change a user's password. This document describes an LDAP extended operation to allow allow modification of user passwords which is not dependent upon the form of the authentication identity nor the password storage mechanism used. "Host Identity Payload", Robert Moskowitz, 02/03/2000, <draft-moskowitz-hip-arch-01.txt> This memo describes the reasoning behind proposing a new namespace, the Host Identity, and a payload, between the Internetworking and Transport layers, to carry this identity. Herein is presented the basics of the current namespaces, strengths and weaknesses, and how a new namespace will add completeness to them. This new namespace's roles in the protocols are defined. "Basic Internet Security Model", Robert Smart, 01/04/2000, <draft-smart-sec-model-00.txt> The first step in creating a secure Internet is to build a model of the security requirements of the real world entities involved and how those real world entities act on the Internet through the agency of networked computers. This document presents a minimal model as a starting point for discussion. In this model: o The real world is composed of entities, each being: (a) an independent legal entity; or (b) a sub-entity of another entity (creating a multi-level hierarchy). o Running code is characterized by: (a) the entity that it acts on behalf of; and (b) the entity that controls the environment in which the code executes. o The environment can run on a bare unmanaged machine or it can be a virtual environment which is code controlled by another entity. o We can model communication between machines as a sequence of requests and assertions. The security question becomes: which requests to honour. What is known about the provenance of the requests and assertions is typically crucial. o Security can take place at different network layers and security information must be passed between the layers along with the data. "Stream URI Scheme", Fujikawa Kenji, Kutiya Shinobu, Tanaka Tsuyoshi, 01/04/2000, <draft-fujikawa-stream-uri-00.txt> This document describes the Stream Uniform Resource Identifier which allows Internet clients to have direct access to multimedia streams. "PHONECTL Protocol", Rick Dean, Ronnen Belkind, 09/13/2000, <draft-dean-phonectl-02.txt> The PHONECTL protocol allows remote control of an IP phone as an alternative to human keying. For example, a Palm sized computer could provide speed dialing and call screening for an embedded SIP ether- phone over infrared. PHONECTL is designed to be... * simple to fit inside a PDA and embedded phone * intermittent connection capable (i.e. optional for any part of the call) * more secure, where plain-text passwords need not be shared with the phone "NECP the Network Element Control Protocol", Peter Danzig, Gary Tomlinson, Anawat Chankhunthod, Chuck Neerdaels, Ted Schroeder, Alberto Cerpa, Jeremy Elson, Hooman Beheshti, Raj Jalan, 02/23/2000, <draft-cerpa-necp-02.txt> This document describes 'NECP', a lightweight protocol for signalling between servers and the network elements that forward traffic to them. It is intended for use in a wide variety of server applications, including for origin servers, proxies, and interception proxies. The network element may also be a range of devices, including so-called L4 or content-aware switches and load-balancing routers. NECP provides methods for network elements to learn about servers' capabilities, availability, and hints as to which flows can and can not be serviced. This allows network elements to perform load balancing across a farm of servers, redirection to interception proxies, and cut-through of flows that can not be served by the farm. "Cisco Systems' Simple Certificate Enrollment Protocol (SCEP)", C. Madson, Andy Nourse, X Liu, David McGrew, 08/11/2000, <draft-nourse-scep-03.txt> This document specifies the Cisco Simple Certificate Enrollment Protocol, a PKI communication protocol which leverages existing technology by using PKCS#7 and PKCS#10. SCEP is the evolution of the enrollment protocol developed by Verisign, Inc. for Cisco Systems, Inc. It now enjoys wide support in both client and CA implementations "Remote Network Monitoring MIB Extensions for Virtual Circuits Version 1.0", Robert Steinberger, 01/07/2000, <draft-steinberger-mib-vircir-00.txt> 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 to allow management of remote network monitoring in networks containing virtual circuits. "Foreign Agent Assisted Hand-off", Pat Calhoun, Tom Hiller, James Kempf, Ajoy Singh, Peter McCann, Sebastian Thalanany, Chandana Pairla, 09/27/2000, <draft-calhoun-mobileip-proactive-fa-02.txt> The Mobile IP protocol allows a Mobile Node to continue using the same home address even after changing its point of attachment to the Internet. This provides transparency to most existing applications that assume a fixed address and a fixed point of attachment. However, new applications, such as voice-over-IP, have additional real-time requirements such that a change in the point of attachment will cause a noticeable degradation of service unless additional steps are taken to reduce the latency of a handoff event. This specification proposes extensions to the Mobile IP protocol that may be used by Foreign Agents to set up a Mobile Node's visitor entry, and forward its packets, prior to receiving a formal Registration Request from the Mobile Node. This enables a very rapid establishment of service at the new point of attachment so that the effect of the handoff on real-time applications is minimized. "IP Version 6 Multicast Addressing Architecture", Brian Haberman, Dave Thaler, 03/13/2000, <draft-haberman-ipngwg-mcast-arch-01.txt> This specification defines the multicast addressing architecture of the IP Version 6 protocol. The updated multicast address architecture presented in this document allows for unicast prefix-based allocation of multicast addresses. It is an update of section 2.7 of the RFC 2373. "RTP Payload Load Format for ITU-T Recommendation G.722.1", Antony Crossman, 01/10/2000, <draft-crossman-avt-rtp-g7221-00.txt> ITU-T Recommendation G.722.1 [ ] is a wideband coder, it operates at one of two selectable bit rates, 24kbit/s or 32kbit/s. This document describes the payload format for including G.722.1 generated bit streams within an RTP packet [ ]. Also included here are the necessary details for the use of G.722.1 with MIME [ ] and SDP [ ]. "Interworking Between SIP/SDP and H.323", H. Schulzrinne, Karunesh Singh, 05/16/2000, <draft-singh-sip-h323-01.txt,.ps> This document describes the interworking between SIP and H.323, including the translation between H.245 and SDP. We list general requirements for such a translation and a solution which meets those requirements. We describe the call setup via message flows and pseudo code. "IP Based Telephone-to-Web Search Engine", Michael Gelman, 01/12/2000, <draft-gelman-phone2web-00.txt> This document presents a proposed search engine designed to link any 10 digit telephone number to any webpage(s) associated with the telephone number. The search engine will be accessed via existing web browsers and Internet infrastructure, using IP addresses instead of domain names. To use this search engine, 10 digit telephone numbers will entered directly into the browser in a common format, in the place of a URL. "Proxy Server Configuration Option for PPP IPCP", N. Ishikawa, Shinji Kobayashi, Yuko Onoe, Megumi Kondo, 01/12/2000, <draft-onoe-proxy-server-option-00.txt> Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links and is generally used to connect personal computers at home or portable terminals to the Internet using TCP/IPs over phone lines. This document extends the Proxy Server Configuration Option for PPP IPCP (Internet Protocol Control Protocol) and defines negotiation of primary and secondary proxy server addresses for Web browsing applications. With this option, redundant communications for notification of proxy server addresses can be avoided. Moreover, automatic and easy configuration of proxy servers can be realized for Internet beginners. "Cellular IP", Andrew Campbell, Andras Valko, Javier Gomez, Zoltan Richard Turanyi, Sanghyo Kim, Chieh-Yih Wan, 01/12/2000, <draft-ietf-mobileip-cellularip-00.txt> This document specifies a protocol that allows routing IP datagrams to a mobile host. The protocol is intended to provide local mobility and handoff support. It can interwork with Mobile IP [1] to provide wide area mobility support. Four fundamental design principles of the protocol are: (1) location information is stored in distributed data bases (2) location information referring to a mobile host is created and updated by regular IP datagrams originated by the said mobile host (3) location information is stored as soft state (4) location management for idle mobile hosts is separated from location management of hosts that are actively transmitting or receiving data. "W3C Composite Capability/Preference Profiles", Graham Klyne, 01/14/2000, <draft-klyne-conneg-w3c-ccpp-00.txt> This document suggests some possible areas for extending the IETF 'conneg' working group's capability description framework, described in [2,3,4]. The suggested areas for extension have been motivated by WWW Consortium (W3C) work on Composite Capability/Preference Profiles (CCPP) [5] that parallels some aspects of the IETF 'conneg' work. This is presented as a discussion document, with a view to maybe integrating some of these ideas into ongoing 'conneg' work, and to indicate some areas for ongoing collaboration between the IETF and W3C in the area of content description. "Control of Service Context using SIP Request-URI", Robert Sparks, Ben Campbell, 10/19/2000, <draft-campbell-sip-service-control-01.txt> In a conventional telephony environment, extended service applications often use call state information, such as calling party, called party, reason for forward, etc, to infer application context. In a SIP/2.0 call, much of this information may be either non- existent or unreliable. This draft proposes a mechanism to communicate context information to an application. Under this proposal, a client or proxy can communicate context through the use of a distinctive Request-URI. This draft continues with examples of how this mechanism could be used in a voice mail application. "BGRP: A Framework for Scalable Resource Reservation ", H. Schulzrinne, Ping Pan, Ellen Hahne, 01/19/2000, <draft-pan-bgrp-framework-00.txt> Resource reservation needs to accommodate the rapidly growing size and increasing service diversity of the Internet. This memo first defines the scaling problem in today's Internet backbone, and briefly discusses several existing resource management approaches. Then we will present a distributed approach and introduce a protocol, called the Border Gateway Reservation Protocol (BGRP), for inter-domain resource reservation that can scale in terms of message processing load, state storage and control message bandwidth. The main idea of our approach is to build a sink tree for each domain network. Each sink tree aggregates reservations from all data sources in the network. Sink tree initiation, maintenance and termination involve only backbone border routers. Within each domain, the network service providers manage network resource and direct user traffic independently. At the border routers, the service providers can use BGRP to setup domain-level reservation trunks base on bi- lateral agreement. Since routers only maintain the sink tree information, the total number of reservation states at each router scales, in the worst case, linearly with the number of domains in the Internet. For bandwidth reservation, BGRP relies on differentiated services for data forwarding. As a result, the number of packet classifier entries is small. To reduce the protocol message traffic, routers may reserve domain bandwidth beyond the current load so that sources can join or leave the tree or change their reservation without having to send messages all the way to the root for every such change. "A Protocol for Remotely Managing Sieve Scripts", Tim Martin, 02/14/2000, <draft-martin-managesieve-01.txt> Sieve scripts allow users to filter incoming email. Message stores are commonly sealed servers so users cannot log into them , yet users must be able to update their scripts on them. This document describes a protocol for securely managing Sieve scripts on a remote server. This protocol allows a user to have multiple scripts, and also alerts a user to syntactically flawed scripts. This an interim measure as it is hoped that eventually Sieve scripts will be stored on ACAP. This document is intended to proceed on the experimental track. "Multi-protocol Lambda Switching: Issues in Combining MPLS Traffic Engineering Control With Optical Cross-connects", Y Rekhter, John Drake, Daniel Awduche, Debashis Basak, 02/15/2000, <draft-basak-mpls-oxc-issues-01.txt> 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. "Private IP Encapsulation within IP (PIPE)", Bernhard Petri, 01/20/2000, <draft-petri-mobileip-pipe-00.txt> RFC 2003 specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. This is a means to alter the normal IP routing for datagrams, by delivering them to an intermediate destination that would otherwise not be selected by the (network part of the) IP Destination Address field in the original IP header. This draft allows to extend this encapsulation mechanism also for private IP addresses. "Call Model Integration Framework", Kumar Vemuri, 01/21/2000, <draft-vemuri-cmi-framework-00.txt> In this paper we study the problem of call model integration. Several call models are in common use. Most are customized for efficiency of operation and ease of access to features within specific domains. Access to features external to a given domain may be facilitated by overlaying the call model representation intrinsic to said external domain atop the base call model integral to the pre- specified base domain. "Intrusion Detection Message Exchange Format Comparison of SMI and XML Implementations", David Curry, Glenn Mansfield, 03/06/2000, <draft-mansfield-curry-idmef-xmlsmi-01.txt> The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to the management systems which may need to interact with them. The goals and requirements of the IDMEF are described in [3]. Two implementations of the IDMEF data format have been proposed: one using the Structure of Management Information (SMI) to describe an SNMP MIB, and the other using a Document Type Definition (DTD) to describe XML documents. Both representations appear to have their good and bad traits, and deciding between them is difficult. To arrive at an informed decision, the working group tasked the authors to identify and analyze the pros and cons of both approaches, and present the results in the form of an Internet-Draft. "MIB Object Dependency Expression (MODEX)", Frank DaCosta, 01/21/2000, <draft-dacosta-snmp-object-dependency-00.txt> An SNMP MIB models a managed device as if every one of its objects may be atomically read and changed. In reality, many of a device's objects may be interdependent. Typically such dependencies are either undocumented or simply noted in MIB comments or DESCRIPTION clauses. This draft defines a syntax to capture MIB object dependencies and proposes tools for real-world implementation. "Blocks eXtensible eXchange Service", Marshall Rose, M Gazzetta, 03/10/2000, <draft-mrose-blocks-service-01.txt> Blocks[1] is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This memo describes how to provision a Blocks service. To subscribe to the Blocks discussion list, send e-mail[9]; there is also a developers' site[10]. "The Blocks eXtensible eXchange Protocol Framework", Marshall Rose, 06/16/2000, <draft-mrose-blocks-protocol-04.txt> This memo describes a generic application protocol framework for connection-oriented, asynchronous request/response interactions. The framework permits multiplexing of independent request/response streams over a single transport connection, supporting both textual and binary messages. To subscribe to the Blocks discussion list, send e-mail[11]; there is also a developers' site[12]. "Blocks: Architectural Precepts", Marshall Rose, Carl Malamud, 03/10/2000, <draft-mrose-blocks-architecture-01.txt> Blocks is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This document, at present, focuses on the first model. To subscribe to the Blocks discussion list, send e-mail[17]; there is also a developers' site[18]. "The Blocks Simple Exchange Profile", Marshall Rose, 03/10/2000, <draft-mrose-blocks-exchange-01.txt> Blocks[1] is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management. This memo describes the Simple Exchange Profile (SEP) used to exchange objects, termed blocks, residing in an SEP datastore. To subscribe to the Blocks discussion list, send e-mail[5]; there is also a developers' site[6]. "Extended RETR - Extension to POP3", Anders Rundegren, 05/08/2000, <draft-rundegren-pop3-01.txt> This memo introduces an extension to the RETR command in the POP3 protocol. The extension makes it possible for an interrupted RETR command to be continued. This is particularly useful when downloading large messages over unstable connections. "Telnet Forwarding of X Windows Session Data", Jeffrey Altman, Peter Runestig, 04/07/2000, <draft-altman-telnet-fwdx-02.txt> This Internet-Draft describes a mechanism via which X Window System client applications to which a telnet session has been established may have their communications with the X Windows Server forwarded via the Telnet communications channel. This is desireable when the Telnet session is established through a Firewall or Network Address Translator which does not allow arbitrary connections to be created from the host machine to the client machine; or when the Telnet session is using an authenticated and encrypted channel and that same security is desired for the X Window System session data. X Window System client are authorized by the tunnel using X Display access control data. "Compatible Internationalized Domain Names Using Compression", Paul Hoffman, 03/10/2000, <draft-hoffman-idn-cidnuc-03.txt> This protocol describes a transformation method for representing non- ASCII characters in domain names in a fashion that is completely compatible with the current DNS. It meets the many requirements for internationalization of domain names. Note: this protocol is quite experimental and should not be deployed in the Internet until it reaches standards track in the IETF. "Netnews Administration System (NAS)", Philipp Grau, Vera Heinau, Heiko Schlichting, 05/23/2000, <draft-dfncis-netnews-admin-sys-01.txt> The Netnews Administration System (NAS) is a framework to simplify the administration and usage of network news on the Internet. Data for the administration of newsgroups and hierarchies are kept in a distributed hierarchical database, and are available through a client-server-protocol. The database is accessible by news servers and news administrators as well as by news readers. News servers can update their configuration automatically, administrators are able to get the data manually. News reader programs are able to get certain information from an NAS server, automatically or at a user's discretion, to provide detailed information about groups and hierarchies to the user. "Probabilistic Optimization of LKH-based Multicast Key Distribution Schemes ", D.P Sidhu, A Selcuk, Christopher McCubbin, 01/31/2000, <draft-selcuk-probabilistic-lkh-00.txt> Currently, the most efficient techniques for multicast key management are based on the Logical Key Hierarchy (LKH) scheme. In current practice, LKH trees are organized as balanced binary trees, which give a uniform O(log n) complexity for compromise recovery in an n- member group. In this draft, we propose organizing the LKH trees with respect to the members' compromise probabilities instead of keeping a balanced tree, in a spirit similar to data compression techniques such as Huffman and Shannon-Fano coding. We describe two such probabilistic algorithms which improve the performance of an LKH scheme by probabilistic organization of the tree. Preliminary simulation results show that significant gains can be obtained by these techniques. "IP and ARP over ISO 7816-3 ", Jim Rees, Scott Guthery, Youri Baudoin, Joachim Posegga, 02/01/2000, <draft-guthery-ip7816-00.txt> 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. "RIC Service Specifications", K. Fujikawa, 02/02/2000, <draft-fujikawa-ric-ss-00.txt> This draft specifies the specifications of link QoS, area QoS and specified and requested QoS by HQLIP and SRSVP, which are defined in Real Internet Consortium "Simple Resource ReSerVation Protocol (SRSVP)", K. Fujikawa, Y. Goto, 02/02/2000, <draft-fujikawa-ric-srsvp-00.txt> This draft describes Simple Resource ReSerVation Protocol (SRSVP), which implements multicasting, resource reservation and charging in the Internet. "Host Identity Payload", Robert Moskowitz, 02/03/2000, <draft-moskowitz-hip-impl-00.txt> This memo describes implementational aspects of HIP [HIP]. Particular attention is paid to items needed for HIP to span Addressing Realms (e.g. using NATs) and address reassignment. "H.323 and Firewalls: Problem Statement and Solution Framework", Melinda Shore, 02/03/2000, <draft-shore-h323-firewalls-00.txt> This paper attempts to describe in detail the problems associated with passing H.323 through firewalls and NAT devices, and discuss the appli- cability of a range of technologies currently available to solve these problems. We conclude that the only general solution to the problem is external application control of firewalls. "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", Hilarie Orman, Paul Hoffman, 08/10/2000, <draft-orman-public-key-lengths-01.txt> Implementors of systems that use public key cryptography to exchange symmetric keys need to make the public keys resistant to some predetermined level of attack. That level of attack resistance is the strength of the system, and the symmetric keys that are exchanged must be at least as strong as the system strength requirements. The three quantities, system strength, symmetric key strength, and public key strength, must be consistently matched for any network protocol usage. While it is fairly easy to express the system strength requirements in terms of a symmetric key length and to choose a cipher that has a key length equal to or exceeding that requirement, it is harder to choose a public key that has a cryptographic strength meeting a symmetric key strength requirement. This document explains how to determine the length of an asymmetric key as a function of the length of a symmetric key. Some rules of thumb for estimating equivalent resistance to large-scale attacks on various algorithms are given. The document also addresses how changing the sizes of the underlying large integers (moduli, group sizes, exponents, and so on) changes the time to use the algorithms for key exchange. "Steps for IPsec Interoperability Testing", Paul Hoffman, Michael Richardson, 09/12/2000, <draft-hoffman-ipsec-testing-01.txt> Bringing up IPsec gateways, clients and end systems is a hard task. There are the numerous configurations issues that occur when doing this. Techniques for diagnosing regular nodes may not yeild understandable results when one or both nodes have network security features. There is a further difficulty presented by the number of configuration options presented by a typical IPsec gateway implementation, and the lack of consistent diagnostics from gateways. The network administrator, field engineers and product support staff are faced with multiple indistinguishable failure modes: is the client unable to connect because of a network outage, or because the two products have never actually tested in that scenario? Or is the naive user unaware that they are behind a network address translator? "MPLS VPN Interworking", A. Iwata, M. Suzuki, Osamu Tabata, Junichi Sumimoto, Yutaka Ezaki, Masami Doukai, 02/08/2000, <draft-sumimoto-mpls-vpn-interworking-00.txt> We call virtual private networks (VPNs) based on Multiprotocol Label Switching (MPLS) 'MPLS VPN'. This document discusses motivation and a model of interworking among MPLS VPNs. It then proposes functional capabilities for the interworking such as realization of security, mapping of the QoS class, dynamic routing information distribution. Considering easy provisioning, we focus on an interworking where each MPLS network is once terminated and IP header look-up is executed at an egress/ingress Label Switching Router (LSR), and IP over ATM (RFC1483) is used for interworking connections. "Dynamic Allocation Guidelines for Network Prefix-based IPv6 Multicast Addresses", Brian Haberman, 03/13/2000, <draft-haberman-malloc-ipv6-prefix-01.txt> With the current multicast address architecture and the proposed multicast address architecture, a set of guidelines is needed for multicast address allocation servers to use in assigning IPv6 multicast addresses. The purpose of these rules is to reduce the possibility of address collision not only at layer 3, but also on devices at layer 2. "Caching Support in Standards-based RTSP/RTP Servers", R. Frederick, Alagu Periyannan, Jay Geagan, Mike Kellner, 03/15/2000, <draft-periyannan-rtsp-caching-01.txt> This document presents the issues facing streaming media caching. It proposes a set of mechanisms to enable streaming media caching between standards-based RTSP/RTP servers and proxies. Streaming media caching refers to the process through which streaming content is dynamically replicated closer to users so as to provide a better viewing experience. A list of RTSP enhancements and open issues are presented. This document is intended to be a starting point for discussion between various parties interested in standardizing the mechanism used by RTSP/RTP servers to enable streaming media caching. "INTERNET MESSAGE ACCESS PROTOCOL - MULTIAPPEND EXTENSION", M. Crispin, 06/09/2000, <draft-crispin-imap-multiappend-01.txt> This document describes the multiappending extension to the [IMAP] protocol. This extension provides substantial performance improvements for IMAP clients which upload multiple messages at a time to a mailbox on the server. A server which supports this extension indicates this with a capability name of 'MULTIAPPEND'. "Problems and Requirements of Some IP Applications Based on Spatial Location Information", Jussi Ruutu, Haitao Tang, John Loughney, 02/14/2000, <draft-tang-islf-req-00.txt> This Internet draft describes the basic problems that are needed to be solved for some IP applications based on spatial location information. The requirements on the system are also identified from these problems. "Control of Lightpaths in an Optical Network ", Sid Chaudhuri, Jennifer Yates, 02/14/2000, <draft-chaudhuri-ip-olxc-control-00.txt> This document details requirements and mechanisms for optical bandwidth management and restoration in a dynamically reconfigurable optical network. A management approach is described where IP algorithms and mechanisms are used to control optical resources, paving the way for the optical Internet. The proposal is specifically intended for optical internetworking in which IP routers are connected by the reconfigurable optical layer using lightpaths. However, it is assumed that the same methodology will be used for non-IP traffic as well. "Mobile IP with Location Registers (MIP-LR) ", C. Graff, Ravi Jain, Michael Bereschinsky, Thomas Raleigh, 02/14/2000, <draft-jain-miplr-00.txt> 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. "Extensions to IS-IS/OSPF and RSVP in support of MPL(ambda)S", Joe Lawrence, Ed Stern, Gregory Bernstein, Y Rekhter, John Drake, Alan Hannan, Daniel Awduche, Gisli Hjalmtysson, Kireeti Kompella, Debashis Basak, Satori Okamoto, Near Margalit, 02/14/2000, <draft-kompella-mpls-optical-00.txt> This document specifies extensions to the IS-IS, OSPF, and RSVP in support of Multiprotocol Lambda Switching (MPL(ambda)S). For motivations and the overall architecture of MPL(amda)S see [Awduche- 1]. For the set of required enhancements to IS-IS, OSPF, and RSVP see [Basak]. "Extending Change Password for Setting Kerberos Passwords", John Brezak, J Trostle, Michael Swift, 02/15/2000, <draft-trostle-win2k-cat-kerberos-set-passwd-00.txt> The Kerberos [1] change password protocol [2], does not allow for an administrator to set a password for a new user. This functionality is useful in some environments, and this proposal extends [2] to allow password setting. The changes are: adding new fields to the request message to indicate the principal which is having its password set, not requiring the initial flag in the service ticket, using a new protocol version number, and adding three new result codes. "NEC contribution on pre-Spirits ICW implementations", Shinji Ago, S Moeenuddin, S Hadvani, 02/15/2000, <draft-ago-spirits-icw-00.txt> 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. "Link Bundling in MPLS Traffic Engineering", Lou Berger, Y Rekhter, Kireeti Kompella, 09/29/2000, <draft-kompella-mpls-bundle-03.txt> In some cases a pair of Label Switching Routers (LSRs) may be connected by several (parallel) links. From the MPLS Traffic Engineering point of view for reasons of scalability it may be desirable to advertise all these links as a single link into OSPF and/or IS-IS. This document describes how to accomplish this. This document also defines corresponding signaling (RSVP-TE) support. "Finding a SIP Server With SLP ", Jonathan Rosenberg, James Kempf, 02/15/2000, <draft-kempf-sip-findsrv-00.txt> The Session Initiation Protocol (SIP) allows a user to communicate with a local SIP proxy and registrar, primarily for registration services and the execution of certain features. Currently, SIP allows for discovery of these servers through multicast or through static configuration. In many cases, it may be more useful for a SIP client to discover local SIP servers based on features supported by those servers. In this document, an alternate technique is specified based on Service Location Protocol (SLP). The document contains a short description of how to use SLP for service discovery, and a SIP service type template. The service type template defines the attributes and service URL for a SIP server advertisement, suitable for SIP clients to discover. "Soft Permanent LSPs for CR-LDP ", Juha Heinanen, 02/16/2000, <draft-heinanen-mpls-splsp-00.txt> This document extends CR-LDP with capability to establish Soft Permanent LSPs (SPLSPs). A SPLSP is an LSP which originates or terminates at a label switched interface of an MPLS node. "Client Certificate and Key Retrieval for IKE", Steve Bellovin, Robert Moskowitz, 02/16/2000, <draft-bellovin-ipsra-getcert-00.txt> (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. "Fault Tolerance for LDP and CR-LDP ", P. Brittain, Adrian Farrel, 02/16/2000, <draft-farrel-mpls-ldp-ft-00.txt> 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. "An LDAP Directory Schema Solution For Printers", K Jones, 02/18/2000, <draft-sun-ldap-print-schema-00.txt> This document describes an LDAP directory schema for print services. The intention is to build upon the work done by the Internet Printing Protocol (IPP) group and illustrate how to extend that solution with an additional class to support existing Sun Microsystems printing implementations. "Framework Architecture for Service in the PSTN/IN Requesting Internet Service (SPIRITS)", David Shrader, 02/21/2000, <draft-shrader-spirits-arch-00.txt> This document defines an architecture framework and functional requirements for Service in the PSTN/IN Requesting Internet Service (SPIRITS). The framework describes relationships between functional entities for interactions between the PSTN and SPIRITS Server and provides requirements for the SPIRITS protocol. This document is submitted to the IETF SPIRITS working group for discussion and comment. Discussion on this topic should be sent to the SPIRITS mailing list (spirits@lists.research.bell-labs.com). "Performance Analysis of Assured Forwarding", Raj Jain, C Liu, Mukul Goyal, Arian Durresi, 02/21/2000, <draft-goyal-diffserv-afstdy-00.txt,.ps> One desirable characteristics of any resource allocation (or differentiation) mechanism is that if many aggregates, each with its own reservation, are merged with other aggregates of the same class, each aggregate should get its reserved bandwidth and a fair share of the excess bandwidth. In particular, the performance of an aggregate should not be adversely affected by other aggregates and their congestion sensitivity. TCP flows are congestion sensitive while UDP flows are congestion insensitive in the sense that TCP flows reduce their traffic if any packets are lost. The goal of this study is to see if TCP flow aggregates will be punished for their good behavior in the presence of competing UDP flow aggregates in the same assured forwarding class. We identify several factors that affect the performance in the mixed environments and quantify their effects using a full factorial design of experiment methodology. "GKM Building Block: Group Security Association (GSA) Definition", M. Baugher, H. Harney, Thomas Hardjono, 09/28/2000, <draft-irtf-smug-gkmbb-gsadef-01.txt> This document provides a definition for Group Security Associations (GSA) for the support of group key management in IP multicast security. The reasoning behind the structure of the GSA is discussed, and a definition of the GSA is provided. "Telia/Nortel Pre-SPIRITS Implementation", Lewis Robart, Soren Nyckelgard, John Yoakum, 03/06/2000, <draft-nyckelgard-spirits-pre-impl-01.txt> This document describes services, architectures, and protocols for existing pre-SPIRITS implementations of arrangements through which PSTN services can request Internet applications. The services and architecture presented was outlined by Telia and then evolved and implemented by Telia in co-operation with Nortel Networks. "Getting SIP through Firewalls and NATs ", Jonathan Rosenberg, H. Schulzrinne, Dale Drew, 02/23/2000, <draft-rosenberg-sip-firewalls-00.txt> This document discusses the interaction of the Session Initiation Protocol (SIP) with with Network Address Translators (NATS) and firewalls. We show the difficulties in SIP traversing these devices, and we compare the solutions that might be used. "Generalized Key Distribution Extensions for Mobile IP", C Perkins, Pat Calhoun, 07/19/2000, <draft-perkins-mobileip-gen-key-02.txt> Recent proposals have suggested several kinds of key extensions for Mobile IP registration messages. These keys may be used between the mobile node and mobility agents, or between the mobility agents themselves. This document specifies generalized extension formats that can be useful for several kinds of key distributions. Each generalized extension format will have subtypes which indicate the specific format for the key distribution data. "LDP/CR-LDP Session Reestablishment -- I'll Be Back", Philip Matthews, 02/23/2000, <draft-matthews-mpls-ldp-ibb-00.txt> This contribution proposes modifications to the LDP and CR-LDP protocols that allow an LDP or CR-LDP session to be reestablished using a new TCP connection if the old TCP connection goes down unexpectedly. It also proposes that, in certain situations, an LSR continue to use the label bindings associated with a session for a short time after the session goes down, to allow forwarding to continue uninterrupted while the two peer LSRs attempt to reestablish the session. These modifications allow an LSR to easily implement hitless software upgrades and hitless activity switches. "RTP/I: An Application Level Real-Time Protocol for Distributed Interactive Media", Jerry Vogel, Martin Mauve, Volker Hilt, Christoph Kuhmuench, Wolfgang Effelsberg, 02/23/2000, <draft-mauve-rtpi-00.txt> This document specifies RTP/I, an application level real-time protocol for distributed interactive media. Typical examples of distributed interactive media are shared whiteboards, networked computer games and distributed virtual environments. RTP/I defines a standardized framing for the transmission of data and provides mechanisms that are universally needed for this media class. Thereby RTP/I enables the development of reusable functionality and generic services that can be employed for multiple distributed interactive media. Examples for this kind of functionality are the ability to record sessions, to support late coming participants, and to provide security services. RTP/I is a protocol that follows the ideas of application level framing and integrated layer processing. It has been designed to be independent of the underlying network and transport layers. To a large extend RTP/I has been inspired by the real-time transport protocol (RTP), which is used for continuous non-interactive media. This document is intended to stimulate the discussion on how to transport distributed interactive media over the Internet. There exists an RTP/I mailing list. Instructions on how to subscribe to this list can be found at the RTP/I homepage (http://www.informatik.uni-mannheim.de/informatik/pi4/projects/ RTPI/index.html). Feedback on this document should be addressed to the RTP/I mailing list or directly to the authors. "The Unidirectional Hypertext Transfer Protocol", Dean Blackketter, 02/24/2000, <draft-blackketter-uhttp-00.txt> This document describes the Unidirectional Hypertext Transfer Protocol, or UHTTP. UHTTP is a simple, robust, one-way data transfer protocol that is designed to efficiently deliver resource data in a one-way broadcast-only environment. This transfer protocol is appropriate for delivery of HTML and other content resources using IP multicast over television vertical blanking interval (IP/VBI) and other unidirectional transport systems. "The Local Identifier (lid:) URI Scheme", C. Finseth, Dean Blackketter, Dan Zigmond, Gomer Thomas, Michael Dolan, 02/24/2000, <draft-blackketter-lid-00.txt> This document describes the Local Identifier or 'lid:' URI scheme. "COPS Usage for Outsourcing Diffserv Resource Allocation", Stefano Salsano, 02/25/2000, <draft-salsano-issll-cops-odra-00.txt> This document introduces a new client type for the COPS protocol to support dynamic DiffServ admission control. The Policy Decision Point (PDP) acts as a 'Bandwidth Broker' for the Policy Enforcement Point (PEP) which is requesting resources. The use of the defined mechanism is suited for (but it is not limited to) the Integrated Services operation over Diffserv networks. "Integrated services over DiffServ network using COPS-ODRA", Stefano Salsano, Roberto Mameli, 02/25/2000, <draft-mameli-issll-is-ds-cops-00.txt> This document details the IntServ operation over a DiffServ network in the case of dynamic admission control procedure supported by the COPS protocol. An RSVP aware Edge Router uses the COPS protocol in order to query a Bandwidth Broker, which manages the resources within the DiffServ domain. This document relies on the COPS extensions proposed in the companion draft 'COPS usage for Outsourcing DiffServ Resource Allocation' [COPS-ODRA]. "The CCAPI (COPS Client Application Programming Interface)", Roberto Mameli, 02/25/2000, <draft-mameli-issll-cops-api-00.txt> This document focuses on the Admission Control functionality performed by the Edge Router in the IntServ/DiffServ interworking scenario described in [COPS-ISDS]. More precisely it describes the interaction between the RSVP and the COPS protocols in the Edge Router and introduces an API (Application Programming Interface) aimed at allowing the intercommunication between them. Anyway, the API described here is designed as a flexible interface, and should be able to support communication between a generic application and the COPS Client Type described in [COPS-ODRA]. "Multicast DNS Configuration Option", Bernard Aboba, Levon Esibov, Dave Thaler, 03/15/2000, <draft-aboba-dhc-mdns-conf-01.txt> This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the multicast DNS configuration. "Internationalisation of the Domain Name Service", Dan Oscarsson, 02/25/2000, <draft-oscarsson-i18ndns-00.txt> There is a very strong world-wide desire to use characters other than ASCII in the DNS, especially in domain names. This document updates the Domain Name System (DNS) [RFC1035] in a way that is compatible with the current DNS and specifies how international characters are handled. "Using National Bibliography Numbers as Uniform Resource Names ", Juna Hakala, 02/25/2000, <draft-hakala-nbn-00.txt> This document discusses how national bibliography numbers (persistent and unique identifiers assigned by the national libraries) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats].Much of the discussion below is based on the ideas expressed in RFC 2288 [Lynch]. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. "TCP RDMA option", D.R Cheriton, Costa Sapuntzakis, 02/25/2000, <draft-csapuntz-tcprdma-00.txt> 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. "MPLS control plane for Switched Optical Networks", Stephen Shew, M. Krishnaswamy, George Newsome, Joe Gajewski, Antonio Rodriguez-Moral, Michael Mayer, 02/28/2000, <draft-krishnaswamy-mpls-son-00.txt> The advent of switched multi-channel (WDM) optical networks using OXCs (Optical Cross-connects) presents many new opportunities for supporting faster and more flexible provision of IP services. Key to realizing such opportunities is providing the ability to automatically set-up and tear-down paths (optical channels) across the optical network, and provide means for IP services to leverage this capability. Therefore, it is necessary to establish supporting protocols and mechanisms. In this draft we study the requirements and mechanisms for optical network topology discovery, signaling path setup, data path computation, and optical channel set-up. We leverage MPLS and other IP based protocols as a basis for achieving the above objectives. "ACAP Profile for Sieve Script Access", R Gellens, 02/28/2000, <draft-gellens-acap-sieve-00.txt> The Sieve [SIEVE] language provides a very useful interoperable syntax for mail filtering. The Email Account Dataset Class [ACAP-EMAIL] provides an extensible and interoperable means of accessing and controlling Sieve scripts, but requires an ACAP [ACAP] server. This memo proposes a profile of ACAP which is suitable for accessing Sieve scripts, very easy to implement in clients and servers, and upwardly compatible with ACAP. "The SYS and AUTH POP Response Codes", R Gellens, 02/28/2000, <draft-gellens-pop-err-00.txt> RFC 2449 [POP-EXT] defined extended [POP3] response codes, to give clients more information about errors so clients can respond more appropriately. In addition to the mechanism, two initial response codes were defined (IN-USE and LOGIN-DELAY), in an attempt to differentiate between authentication failures related to user credentials, and other errors. In practice, these two response codes, while helpful, do not go far enough. This memo proposes two additional response codes: SYS and AUTH, which enable clients to unambiguously determine an optimal response to an authentication failure. In addition, a new capability (AUTH-RESP-CODE) is defined. "CDMA2000 Wireless Data Requirements for AAA", Tom Hiller, Pat Walsh, 09/27/2000, <draft-hiller-cdma2000-aaa-02.txt> This draft specifies cdma2000 wireless data AAA requirements associated with third generation wireless architecture that supports roaming among service providers for traditional PPP and Mobile IP services. The architecture is designed for use with a cellular network as an access medium. Sections 3, 4, present a brief high level review of the cdma2000 wireless data architecture. Section 5 presents cdma2000 AAA requirements. "RIPE DNS WG Guide To Setting Up a DNS Server ", Peter Koch, 02/28/2000, <draft-koch-ripe-dns-setup-guide-00.txt> This document is intended to guide novice and/or part time DNS zone administrators in getting their DNS zones up and running. It is not sufficiently detailed to replace a book about DNS. "On a Pre-SPIRITS Implementation in the KT Internet Call Waiting(ICW) Service", Sung Rhim, Jinkyung Hwang, 02/28/2000, <draft-rhim-spirits-kticw-00.txt,.ps> This document provides the pre-SPIRITS Internet Call Waiting(ICW) Service Implementation developed by Korea Telecom. The document describes the ICW service and service features, the architecture, and the protocols, and illustrates the example scenario. As such, this document contributes to the future SPIRITS architecture and protocol RFCs. "Extensions to OSPF/IS-IS for Optical Routing", Don Fedyk, Guoquang Wang, 02/29/2000, <draft-wang-ospf-isis-lambda-te-routing-00.txt> Real-time optical path setup is the fundamental requirement for agile optical networks and dynamic routing is a mechanism to propagate optical state information and calculate the available paths. OSPF/IS-IS are defined in [OSPF][ISIS]as an IGP routing protocol and this draft specifies the extensions to OSPF/IS-IS for support optical path routing computation. "Extensions to CR-LDP and RSVP-TE for Optical Path Set-up", Yanhe Fan, Peter Ashwood-Smith, 02/29/2000, <draft-fan-mpls-lambda-signaling-00.txt> Real-time optical path setup is a fundamental requirement for agile optical networks and signaling is a mechanism to achieve automatic fast path setup. Our objective is to define extensions to both CR- LDP and RSVP-TE that address this requirement. CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP], respectively, for path setup within a MPLS domain. In this draft, we specify mechanisms, TLVs and Objects required to support Optical Label Switched Path setup. "EURESCOM P909 contribution to PINT and SPIRITS Interaction between Internet and PSTN to request services from one domain to the other ", Valerie Blavette, Gianni Canal, Uwe Herzog, Carlo Licciardi, Stephane Tuffin, 02/29/2000, <draft-canal-p909-pint-spirits-00.txt> This document is intended to provide input to the IETF SPIRITS Working Group(SPIRITS WG) and to the IETF PINT Working Group (PINT WG) from the viewpoint of European network operators that are involved in EURESCOM P909 Project 'Enabling Technologies for IN Evolution and IN-Internet Integration'. The input is based on current results that were achieved in the project. As the project title says P909 project deals with IN-Internet integration issues. The project has defined an architecture for IN-Internet inte gration and it has selected and described some IN-Internet services which can be interesting from the business perspective and challenging from the technical perspective. Some of these services are 'officially' chartered in IETF: ICW in SPIRITS, Click-to-Dial (Request to Call) as well as proposed Conference Service in PINT. However, there are additional IN-Internet convergence services that P909 studies and that are included in this document only as examples. "Voice over MPLS Framework", Bruce Rosen, Lou Berger, John Hopkins, A. Chiu, Francois Le Faucheur, G Ash, Jason Jeffords, Antti Kankkunen, D Stacey, A Yelundur, 07/19/2000, <draft-kankkunen-vompls-fw-01.txt> This document provides a Framework for using MPLS as one underlying technology alternative for transporting VoIP based public voice services. The document defines a reference model for VoIP over MPLS, defines some specific applications for VoIP over MPLS and identifies potential further standardization work that is necessary to support these applications. The annexes of the document discuss the types of requirements that voice services set on the under laying transport infrastructure "Signaling Framework for Automated Provisioning and Restoration of Paths in Optical Mesh Networks", B. Rajagopalan, Bo Tang, Debanjan Saha, Krishna Bala, 03/01/2000, <draft-rstb-optical-signaling-framework-00.txt> This draft describes the issues that must be addressed in developing signaling mechanisms for automated establishment and restoration of paths in optical mesh networks. This draft is the first attempt at developing a framework for RSVP or CR-LDP-based signaling for interconnected optical networks. "RTP Payload Type Format to Enable Selective Retransmissions", Hidehiro Fukushima, Akihiro Miyazaki, Thomas Wiebke, Rolf Hakenberg, Carsten Burmeister, 07/17/2000, <draft-miyazaki-avt-rtp-selret-01.txt,.ps> This document describes a new RTP payload format and a new RTCP packet format to enable multiple selective retransmissions of generic media data. This payload format is especially applicable in a RTP-RX profile as described in [9]. While RTP is widely used for media streaming applications over the Internet, using it over unreliable links needs some further modifications to achieve a good quality of the media stream at the receiver. The aforementioned RTP-RX profile describes a generic retransmission mechanism to make RTP more reliable. This payload format description increases the reliability and decreases the bandwidth requirements of such a generic profile by introducing the concept of multiple selective retransmissions. "Reflections on the DNS, RFC 1591, and Categories of Domains", John Klensin, 03/02/2000, <draft-klensin-1591-reflections-00.txt> RFC 1591,'Domain Name System Structure and Delegation' [1] laid out the basic administrative design and principles for the allocation and administration of domains, from the top level down. It was written before the introduction of the world wide web and rapid growth of the Internet put significant market, social, and political pressure on domain name allocations. In recent years, 1591 has been cited by all sides in various debates, and attempts have been made by various bodies to update it or adjust its provisions, sometimes under pressures that have arguably produced policies that are less well thought out than the original. Some of those efforts have begun from misconceptions about the provisions of 1591 or the motivation for those provisions. This memo includes some thoughts about how 1591 might be interpreted and adjusted by the IANA and ICANN to better reflect today's world while retaining characteristics and policies that have proven to be effective in supporting Internet growth and stability. A variation on this memo has been submitted to ICANN as a comment on its evolving TLD policies. "Framework and Requirements for the Internet Intelligent Networks (IIN)", Vijay Gurbani, Lev Slutsman, G Ash, F Haerens, 03/03/2000, <draft-lslutsman-sip-iin-framework-00.txt> This document describes a framework for an Internet Intelligent Network (IIN) architecture which accommodates a service logic execution environment on a session initiation protocol (SIP) proxy, but at the same time is able to support the traditional PSTN IN-based architecture which uses a service control point (SCP) as a service execution environment. A large number of services, including traditional advanced 800 and other legacy services, as well as IN specific services (Internet Call Waiting (ICW) for ex ample) must be made available for the Internet. Implementation of such services requires a software support architecture that which addresses the following issues: 1)where and how to create the service logic; 2)what kind of software instrumentation should be used to write the service logic (e.g., CPL scripts, Parlay Group API's, or JAIN SIP API); and 3)where to run and how to trigger the service logic. Traditional PSTN architectures address these issues under the umbrella of IN. The traditional IN approach is subject to the parameters of the PSTN architectural and traditional legacy services constraints. Though it would be preferable to avoid being locked into these constraints, it is not possible to bypass them completely (this is especially true in instances when PSTN and IN networks are inter-working). Hence the draft proposes to support both a) 'IP-network-based IN' (e.g., use of script-based-methods such as CPL or CGI), and b) integration of traditional IN-based service logic (e.g., SCP-based) and SIP call control protocols. "Multiple Metrics for Traffic Engineering with IS-IS and OSPF", A. Ghanwani, Rajesh Balay, Don Fedyk, 03/03/2000, <draft-fedyk-isis-ospf-te-metrics-00.txt> This draft describes optional sub-TLVs that can be used to extend IGPs to support multiple metrics for use with traffic engineering. These optional extensions are an addendum to the existing work on traffic engineering extensions to OSPF and ISIS. While the current specifications allow advertising only one metric, the ability to advertise multiple metrics has proven to be very useful in similar systems. The encoding for the proposed optional sub-TLVs is also specified. "Best Current Practice for ISUP to SIP mapping", Gonzalo Camarillo, Adam Roach, 03/03/2000, <draft-camarillo-sip-isup-bcp-00.txt> This document describes a way to perform the mapping between two signalling protocols: SIP and ISUP. "Fast LIveness Protocol (FLIP) ", Ian Duncan, Hal Sandick, Brad Cain, Brian Haberman, Matt Squire, 03/03/2000, <draft-sandiick-flip-00.txt> Networks and network applications must be robust and reliable. For many applications and services, such as packetized voice, correcting a failure must be almost instantaneous. The first step in correcting a failure is, of course, detecting that it occurred. IP routing protocols and signaling protocols as well as many application layer protocols incorporate their own keepalive mechanisms to detect failures. Typically, these protocols detect failures on the order of seconds or tens of seconds. While there are some physical and link layer technologies that inherently supply link outage detection, not all link layers do this. In order to provide for fast failure detection over any type of lower layer, an IP layer fast keepalive protocol can be used. This draft describes such a protocol for quickly detecting when a network layer interface of a peer has failed. "Tunneling of SCTP over Single UDP Port", Rebecca Stewart, Lyndon Ong, Q Xie, 03/03/2000, <draft-ietf-sigtran-sctptunnel-00.txt> The Simple Control Transmission Protocol (SCTP) [1] provides a standard method for transporting messages over IP, with features such as multi-homing and multi-stream built into the protocol for additional reliability and real-time delivery. This memo defines a method for tunneling SCTP over a single UDP port in order to simplify initial implementations. This memo is intended to become an Experimental document and is not intended as a standard of any kind. "MPLS for SDH control", E. Mannie, 03/03/2000, <draft-mannie-mpls-sdh-control-00.txt> This document is an attempt to specify how MPLS could be used to control the establishment of SDH paths. It identifies the elements that could be switched in SDH, proposes a way to build labels for SDH 'intelligent' switching and discusses several problems. Annexes A and B are intended to specify how to support this specification using CR-LDP and TE-RSVP. "iSCSI (Internet SCSI)", D. Smith, Julian Satran, Kalman Meth, L Ore, Efri Zeidner, P Stamwitz, R Haagens, Costa Sapuntzakis, 07/11/2000, <draft-satran-iscsi-01.txt> 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 com- pliant with the requirements laid out in the SCSI Architecture Model - 2 [SAM2] document. "Compression of RSVP protocol's MESSAGE_ID_LIST objects", Franco Tommasi, Simone Molendini, 03/06/2000, <draft-tommasi-rsvp-list-compr-00.txt> This document describes a simple method for compressing lists of Message_Identifiers contained in MESSAGE_ID_LIST objects of the RSVP protocol, as defined in [RSVP2205] and [Berger2000]. This method helps to alleviate the scaling problem of the RSVP protocol. "Limiting Bundling Delays in RSVP", Franco Tommasi, Simone Molendini, 03/06/2000, <draft-tommasi-rsvp-bund-00.txt> This document discusses problems related to a fair use of Bundle messages in RSVP. Bundle messages are defined in [Berger2000]. A new Urgent flag in the MESSAGE_ID object is defined, and rules are given to set the Bundling timer Td. "Robust Header Compression using Keyword-Packets", Hidehiro Fukushima, Akihiro Miyazaki, Thomas Wiebke, Rolf Hakenberg, Carsten Burmeister, 05/11/2000, <draft-miyazaki-rohc-kwhc-01.txt,.ps> Header Compression has proven to be essential for using RTP over bandwidth limited links. While all of these links have only a limited bandwidth, some are additional extremely unreliable, e.g. wireless links. It is shown, that existing Header Compression schemes, that work well over reliable links, perform very bad, if many errors occur. This led to the development of a new robust Header Compression mechanism, that is introduced in this paper. The core idea is the definition of keyword packets, which reduces the amount of discarded packets at the decompressor. The Header Compression scheme, the used packet formats and the decompression algorithm, are described in detail. "Encrypted Hypertext Transfer Protocol -- UGGC/1.0", Miguel Farah, 03/06/2000, <draft-farah-uggc-protocol-00.txt> It's a known fact that web surfing has become a much more important activity in the net than what was expected six years ago. Anti-prying measures have been taken in other services (mail encryption, for example), but haven't been in WWW: anyone can spy at what another user is browsing at the moment by intercepting his packets and looking at their content ('sniffing'). This document proposes a method that guarantees it won't happen anymore, by discouraging the act of sniffing. A new URL, 'uggc', is defined, which is a sort of twin brother to 'http'. The former works in the very same way as the latter does, with the following exception: both URLs and the data travelling from the client to the server and vice versa are encrypted. The data retrieved is equivalent, once decrypted back. "New meaning of Keywords for use in RFCs to Indicate Requirement Levels", Miguel Farah, 03/07/2000, <draft-farah-new-keywords-01.txt> This memo defines new meanings for the keywords that indicate requirement levels. "DVB Cable Network Interface Unit MIB for EuroModem compliant Cable Modems ", Andrew Valentine, 03/06/2000, <draft-valentine-dubnetint-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines 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. This memo is a product of the DVB/DAVIC interoperability consortium. Comments are solicited and should be addressed to the author "A SIP Application Level Gateway for Network Address Translation", Billy Biggs, 03/06/2000, <draft-biggs-sip-nat-00.txt> This document describes an Application Level Gateway (ALG) for the Session Initiation Protocol (SIP) by which IP addresses in the SIP message and in the SDP body are statically mapped from one group to another. The SIP ALG is a specific case of an Application Level Gateway as described in [1]. Transparent use of SIP-based devices in a Network Address Translation (NAT) scenario requires that modifications be made to the SIP messages. These modifications are performed by the ALG. "Extensions to CR-LDP for Path Establishment in Optical Networks", B. Rajagopalan, Debanjan Saha, Z Tang, 03/06/2000, <draft-tang-crldp-optical-00.txt> This draft describes the extensions to the CR-LDP for establishing optical switched paths (OSP). This document does not advocate CR-LDP as the sole mechanism for setting up such paths. RSVP extensions for path set-up are described in [1]. "PPP Diffserv SLA Negotiation", Yves T''''Joens, Peter De Schrijver, C Zaccone, Jeremy De Clercq, 03/06/2000, <draft-declercq-ppp-ds-sla-negotiation-00.txt> This draft defines extensions to IPCP to allow dynamic negotiation and re-negotiation of a Diffserv-based Service Level Specification. This is achieved by introducing a new IPCP Option, and the concept of Suboption negotiation. "Architecture for Implementing Network Single Sign-On ", Vishal Goenka, 03/06/2000, <draft-goenka-single-sign-on-arch-00.txt> There are several different single sign-on (SSO) solutions offered by various software vendors today. All such solutions require applications to be written to a vendor specific API. In view of a lack of industry wide standard for SSO APIs, application developers find it almost impossible to SSO enable their applications to work with any vendor solution. This document presents alternative SSO implementation architecture that allows applications to be transparently enabled for SSO. Further, it allows different SSO solutions to interoperate with relatively little effort. "RSVP Extensions for Signaling Optical Paths", B. Rajagopalan, Bo Tang, Debanjan Saha, 03/07/2000, <draft-saha-rsvp-optical-signaling-00.txt> This document has two objectives. First, we identify signaling requirements for setting up and maintaining Optical Switched Paths (OSPs) in mesh-connected optical networks. We then propose extensions to RSVP to satisfy some of these requirements within the context of MPLS-based traffic engineering framework. "Transporting User Control Information in SIP REGISTER Payloads", H. Schulzrinne, Jonathan Lennox, 03/07/2000, <draft-lennox-sip-reg-payload-00.txt,.ps> Several newly developed languages and interfaces, such as the CPL and SIP CGI, allow users or administrators to specify how Internet telephony servers should process calls. There needs to be a method of transporting scripts for such languages between a client and a server. This document proposes using the payload of SIP REGISTER messages, and their responses, as one method to transport them. "Extensions to CR-LDP for VPNs", Z. Zhang, Srinivasan Balaji, Patty Houlik, 03/07/2000, <draft-zhang-crldp-ext-for-vpn-00.txt> This document proposes to add an optional VPN-ID TLV to CR-LDP label request message to identify the VPN that the request is meant for. "LDAP Schema for NDS ", Jim Sermersheim, 03/07/2000, <draft-sermersheim-nds-ldap-schema-00.txt> This document defines [LDAPV3] schema used by Novell Directory Services (referred to here as NDS). The syntaxes, attribute types and object classes defined in this document are unique to NDS and are meant to compliment those defined in [RFC2252], [RFC2256] and other RFCs and Internet Drafts. "MPLS Profiles ", Bob Thomas, George Swallow, Carol Iturralde, Eric Rosen, Lance Levine, 03/07/2000, <draft-rosen-mpls-profiles-00.txt> The MPLS protocol specifications provide a large number of options, and it can be difficult to know exactly which protocol messages, objects, and procedures must be supported in order to provide some particular application of MPLS, or in order to interoperate with some other implementation. This document specifies a number of MPLS 'Profiles'. Each Profile is a subset of the full MPLS functionality, specified in enough detail to ensure that two implementations of a given Profile will interoperate. This document also specifies which Profiles may be used for which purposes. In the future, it is hoped that specifications for the applications of MPLS will specify the Profiles that must be implemented in order to support the application. "Event Notification in SIP", Adam Roach, 03/07/2000, <draft-roach-sip-subscribe-notify-00.txt> This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide a generic and extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occured. Concrete uses of the mechanism described in this document may be standardized in the future. "Automatic Call Back Service in SIP ", Adam Roach, 03/07/2000, <draft-roach-sip-acb-00.txt> This document describes a proposed implementation of an Automatic Call Back (ACB) service using SIP. This service is somtimes refered to as 'camp on extension,' 'call again,' 'automatic redial,' and 'automatic recall.' "Crankback Routing Extensions for CR-LDP", A. Iwata, Gerald Ash, Norihito Fujita, 07/17/2000, <draft-fujita-mpls-crldp-crankback-01.txt> This draft proposes crankback routing extensions for CR-LDP signaling. Recently, several routing protocol extensions for advertising resource information in addition to topology information have been proposed for use in distributed constraint-based routing. In such a distributed routing environment, however, the information used to compute a constraint-based path may be out of date. This means that label requests may be blocked by links or nodes without sufficient resources. This draft specifies crankback routing extensions for CR-LDP so that the label request can be retried on an alternate path that detours around the blocked link or node upon a setup failure. Furthermore, the proposed crankback routing schemes can be also applied to end-to-end LSP restoration by indicating the location of the failure link or node. This would significantly improve the recovery ratio for failed LSPs, especially in situations where a large number of setup requests are triggered at the same time. "Traffic Engineering Extensions to OSPF Summary LSA ", A. Iwata, Norihito Fujita, 03/07/2000, <draft-fujita-ospf-te-summary-00.txt> Various Traffic Engineering extensions for OSPF have been proposed in [KATZ, OSPFEXT] and others. However, these are basically applicable only to intra-area Traffic Engineering since they do not support inter-area advertisements of the resource information. This draft proposes a new scheme for advertising the summarized resource information for Traffic Engineering outside the area. It also specifies a new LSA to achieve this advertisement. "A Framework for Service Differentiation in MPLS Networks ", Ravadurgam Ravikanth, Pasi Vaananen, Muckai Girish, 03/08/2000, <draft-vaananen-mpls-svc-diff-framework-00.txt> It has been recognized that the success of the MPLS depends on the ability to better support the multiservice traffic integration with some levels of service guarantees, which are not feasible to implement with the current destination prefix only based packet forwarding paradigms. The efficient support for these services throughout the network is expected to be possible using label based forwarding paradigm in the network. Through the use of either RSVP based or LDP/CR-LDP based signaling, MPLS can also provide certain QoS guarantees using the LSPs. The goal of this document is to define a framework for service differentiation in MPLS networks. We discuss a set of services that have been identified so far for IP, and describe the traffic management mechanisms in various network elements that are needed for enabling the implementation of these more advanced services in MPLS networks. "SS7 SCCP-User Adaptation Layer (SUA) ", Greg Sidebottom, Stephen Lorusso, John Loughney, 03/08/2000, <draft-loughney-sigtran-sua-00.txt> This Internet Draft defines a protocol for the transport of any SS7 SCCP-User signaling (e.g., TCAP, RANAP, etc.) over IP using the Simple Control Transport Protocol. Protocol elements are added to enable a seamless operation of the SCCP-User peers in the SS7 and IP domains. This protocol could be used between a Signaling Gateway (SG) and an IP- based signaling node (or an IP-resident Database). It is assumed that the SG receives SS7 signaling over a standard SS7 interface using the SS7 Signaling Connection Control Part (SCCP) to provide transport from the SS7 network to the SG. "Data Distribution Protocol (DDP)", Q Xie, Randall Stewart, 04/27/2000, <draft-xie-stewart-sigtran-ddp-01.txt> Data Distribution Protocol (DDP) provides a fault tolerant data transfer mechanism over IP networks. DDP uses a name-based addressing model which isolates a logical communication endpoint from its IP address(es), thus effectively eliminating the binding between the communication endpoint and its physical IP address(es) which normally constitutes a single point of failure. In addition, DDP defines each logical communication destination as a named group, providing full transparent support for server-pooling and load sharing. It also allows dynamic system scalability - members of a server pool can be added or removed at any time without interrupting the service. DDP is designed to take full advantage of the network level redundancy provided by the Simple Transmission Control Protocol (SCTP) [1]. But it can also use other transport protocol like TCP. Internally, DDP is made up of two parts, namely the Data Distribution Control Part (DDCP) and the Endpoint Name Resolution Part (ENRP). DDCP provides the user interface for name to address translation, load sharing management, and fault management. ENRP defines the fault tolerant name translation service. "XML Encoding of SPKI Certificates", Juha Paajarvi, 03/08/2000, <draft-paajarvi-xml-spki-cert-00.txt> This draft suggests a standard form for encoding SPKI certificates in XML as opposed to the original s-expression encoding defined in [SPKI]. The standard form is defined as an XML document type definition (DTD). The main emphasis is on the XML-encoding of an authorization certificate that is the basic SPKI certificate form. This draft provides also a brief introduction to XML and a short discussion about the benefits of choosing XML as the certificate encoding format. In addition, this draft discusses the problems of automatic processing of tags (attributes and authorizations transferred by a certificate are called tags in SPKI) when reducing certificates. An example of encoding Java permissions in an SPKI certificate is given to demonstrate the problem and, finally, a solution to this problem is suggested. "Java enhanced SIP (JES)", Mick O''Doherty, 03/08/2000, <draft-odoherty-sip-java-enhanced-00.txt> This document defines an extension to the SIP [2] protocol to do a number of things - to extend SIP messages to carry Java applets or Java Mobile Agents, to define a Java SIP API which will allow the Java applet or Java Mobile Agent to interact with the receiving host system and to extend the SIP protocol client so that the Java applet or Java Mobile Agent is run before any other actions are taken on the receipt of a message by the receiving host SIP client. "Some Comments on the Use of MPLS Traffic Engineering for SONET/SDH Path Establishment", Greg Bernstein, 03/08/2000, <draft-bernstein-mpls-sonet-00.txt> In [Awduche] the MPLS Traffic Engineering control plane was applied to the creation of light paths (optical circuits). Due to the general hierarchical capabilities of MPLS, and the flexibility of the label switching paradigm the same techniques used to apply the MPLS control plane to the optical layer can be used to apply it to the SONET/SDH path layer and in fact any form of circuit switching. This note discusses advantages of such an approach and some of the issues involved in its application. "Domain Per Hop Behavior Set Specification", Ron Cohen, Nitsan Elfassy, Arthur Zavalkovsky, 03/09/2000, <draft-ronc-domain-phb-set-specification-00.txt> This memo introduces the concept of Domain PHB sets. A Domain PHB set allow the network administrator to control and tune PHB parameters within its DS domain in an abstract form. Derivation of specific configuration parameters from the Domain PHB set is included as well. "Generic Registry-Registrar Protocol Requirements", Scott Hollenbeck, 10/09/2000, <draft-hollenbeck-grrp-reqs-05.txt> This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared Top Level Domain (TLD) registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models. "Small Group Multicast", R. Boivie, N. Feldman, 07/13/2000, <draft-boivie-sgm-01.txt> Multicast has become increasingly important with the emergence of network-based applications such as IP telephony and video conferencing. The Internet community has done a significant amount of work on IP multicast over the last decade [1-10] and as a result, there are a number of multicast applications that are used today on the Mbone, the multicast-capable virtual network that is layered on top of (portions of) the Internet [10]. However, while today's multicast schemes are scaleable in the sense that they can support very large multicast groups, there are scalability issues when a network needs to support a very large number of distinct multicast groups. This document describes a new scheme for multicast that complements the existing schemes. Whereas the existing schemes can support a limited number of very large multicast groups, the scheme described here can support a very large number of small multicast groups. "Framework for SIP Call Control Extensions", Ben Campbell, 07/14/2000, <draft-campbell-sip-cc-framework-01.txt> This document proposes that SIP call control features be added in a modular fashion, using an open-ended framework of extensions instead of a single extension. These extensions should be advertised and requested following previously defined negotiation techniques. The document continues to describe preferred call control extension design philosophy. "LDAP schema for Domain Per Hop Behavior Set", Ron Cohen, John Strassner, Yoram Snir, 03/09/2000, <draft-ronc-domain-phb-set-ldap-rep-00.txt> Domain PHB Sets are defined in [PHBSET]. A Domain PHB set allows the network administrator to control and tune PHB parameters within its DS domain in an abstract form. This memo defines the mapping of the [PHBSET] information model classes to a directory that uses LDAPv3 as its access protocol. This memo fits into the overall framework for representing, deploying, and managing QoS policies being developed by the Policy Framework Working Group. The memo complements the framework built by the core policy schema [PCORE] and the QoS policy schema [PQoS]. "ENUM Service Specific Provisioning: Principles of Operation", G Vaudreuil, Anne Brown, Gregory Vaudreuil, 04/27/2000, <draft-vaudreuil-enum-e164dir-01.txt> This document outlines the principles for the operation of a telephone number directory service. This service provides for the resolution of telephone numbers into Internet domain name addresses and service specific directory discovery. "Capacity Engineering of IP-based Networks with MPLS", William Lai, 07/19/2000, <draft-wlai-tewg-cap-eng-01.txt> Drawing from the experience and work done in ITU-T on traffic engineering, the feasibility of extending telecommunications network dimensioning methods to IP-based networks with MPLS is explored. This version of the document is preliminary, reporting work in progress. "SIP Precedence mapping to MLPP Interworking", James Polk, 03/09/2000, <draft-polk-sip-mlpp-mapping-00.txt> This document describes an extension to the Session Initiation Protocol [1] for direct interworking and interoperability with TDM-based Multi-Level Precedence and Preemption [2] Service Capability networks. This document will further include details and similar mechanisms to evolve and/or replace existing TDM-based MLPP network topologies with SIP-based Voice Signaling topologies with no loss of capability. Al- though additional mobility and capabilities can easily be realized with this complete topology architecture implemented. The author believes these additional Prioritization and Preemption capabilities will have wider deployment benefits without direct connectivity to MLPP networks. "BGP/MPLS VPNs", E Rosen, 07/17/2000, <draft-rosen-rfc2547bis-02.txt> This document describes a method by which a Service Provider may use an IP backbone to provide VPNs for its customers. MPLS is used for forwarding packets over the backbone, and BGP is used for distributing routes over the backbone. The primary goal of this method is to support the case in which a client obtains IP backbone services from a Service Provider or Service Providers with which it maintains contractual relationships. The client may be an enterprise, a group of enterprises which need an extranet, an Internet Service Provider, an application service provider, another VPN Service Provider which uses this same method to offer VPNs to clients of its own, etc. The method makes it very simple for the client to use the backbone services. It is also very scalable and flexible for the Service Provider, and allows the Service Provider to add value. "LDAP Client Update Protocol", Mark Smith, Michael Armijo, Olga Natkovich, 07/14/2000, <draft-natkovich-ldap-lcup-01.txt> This document defines the LDAP Client Update Protocol (LCUP). The protocol is intended to allow an LDAP client to synchronize with the content of a directory information tree (DIT) stored by an LDAP server and to be notified about the changes to that content. "Requirements for Policy Enabled MPLS", Steve Wright, Shai Herzog, Robert Jaeger, 03/09/2000, <draft-wright-policy-mpls-00.txt> This memo provides a brief overview of MPLS networks and policy- based network architectures. It proposes that MPLS networks be Policy-Enabled in order to facilitate easier administration. To facilitate further discussion, an Intra-net example of a policy- based MPLS network architecture is described. Example policies applicable to the MPLS network are discussed. A scenario of operation example is provided to illustrate some of the dynamics associated with Policy-Enabled MPLS networks. "Distributed Multipoint Conferences using SIP ", Jeff Mark, Kalon Kelley, 03/09/2000, <draft-mark-sip-dmcs-00.txt> This document describes a set of extensions to SIP, which allows distributed multipoint conferencing techniques. Building on prior work [1], we refine implementation strategies and advance additional services. We present refinements on existing multipoint call and transfer signaling techniques and introduce new services of merge and split. "Cooperative Route Filtering Capability for BGP-4", Y Rekhter, Enke Chen, 08/15/2000, <draft-chen-bgp-route-filter-01.txt> This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of route filters that the peer would use to constrain/filter its outbound routing updates to the speaker. "Simple Header Compression", George Swallow, Lou Berger, 03/09/2000, <draft-swallow-mpls-simple-hdr-compress-00.txt> MPLS allows packets to be forwarded based on a label lookup without inspection of the IP header at intermediate routers. This enables headers to be compressed in some applications. Label Switched Paths may be established through the use of RSVP. This draft describes a simple technique for header compression. It then proposes RSVP procedures for signaling header compression. "SMTP Service Extension for Slightly Differing Multicast Messages (SLIDE)", Andrew Ward, 06/16/2000, <draft-ward-esmtp-slide-03.txt> This memo defines an extension to the SMTP service [Klensin, et al 1995] to realize efficiency improvements in the relaying and delivery of slightly differing messages bound for more than one recipient, as specified by multiple RCPT TO commands. "RTP payload format for MPEG-4 Visual Advanced Profiles (scalable, core, main, N-bits)", Paul Christ, Christine Guillemot, 03/10/2000, <draft-guillemot-avt-mpeg4visual-00.txt> This document describes a payload format for the transport of MPEG-4 visual Elementary Streams, applicable for multimedia applications not restricted to the simple visual profile. It is an application of the format described in [1] to specialized cases of video which are applicable in the H.323 context (using for example MPEG-4 lay- ered streams). It is therefore intended to support advanced MPEG-4 visual profiles (simple scalable, core, main, N-bits profiles), by allowing protection against loss of key segments of the elementary streams. The simple scalable profile supports temporal and spatial scalability, features important for rate or congestion control on the Internet, especially in multicast. The core and the main visual profiles target multimedia applications on the Internet and allow, in addition to scalability, the usage of sprite objects and of arbitrary shape objects. "Multi-Router Zeroconf Network Requirements", Sangeeta Mukherjee, Cuneyt Akinlar, David Braun, 08/16/2000, <draft-akinlar-zeroconf-multirouter-01.txt> 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. "Mini-DHCP Election Option for DHCP", Sangeeta Mukherjee, Cuneyt Akinlar, David Braun, 03/10/2000, <draft-akinlar-zeroconf-minidhcp-option-00.txt> This drafts defines a new DHCP option for electing a primary mini- DHCP server from among multiple mini-DHCP servers running on a subnet in multi-router zeroconf networks. "Potential Pitfalls of the Use of ASN.1 in IETF Protocols", Tom Yu, 03/10/2000, <draft-yu-asn1-pitfalls-00.txt> A number of IETF protocols make use of Abstract Syntax Notation One (ASN.1), which is a very complex language for describing abstract types and values, in addition to several sets of encoding rules for those types and values. Some of these uses of ASN.1, particularly the Kerberos protocol [RFC1510] pose implementation problems. This document analyzes some of the likely problems associated with the use of ASN.1 in IETF protocols, and some possible reasons for these problems. "Framework for MPLS Based Recovery", Srinivas Makam, Vishal Sharma, 07/17/2000, <draft-makam-mpls-recovery-frmwrk-01.txt> Multi-protocol label switching (MPLS) [1] integrates the label swapping forwarding paradigm with network layer routing. To deliver reliable service, MPLS requires a set of procedures to provide protection of the traffic carried on different paths. This requires that the label switched routers (LSRs) support fault detection, fault notification, and fault recovery mechanisms, and that MPLS signaling [2] [3] [4] [5] [6] support the configuration of recovery. With these objectives in mind, this document specifies a framework for MPLS based recovery. "Firewall Control Protocol Framework and Requirements", Jonathan Rosenberg, J Kuthan, 06/15/2000, <draft-kuthan-fcp-01.txt> The purpose of this document is to collect and put under discussion requirements for a protocol allowing for decomposition of application-awareness from packet processing in firewalls. The protocol will be used by application-aware entities to control packet flows of applications traversing firewalls dynamically. This kind of control allows applications using session control protocols to traverse firewalls while still retaining restrictive packet filtering policy. Network management tools may also utilize the protocol to manage packet-processing policies. We suggest an extensible framework that may be used for management of arbitrary per-flow control states in network nodes. "A Path Protection/Restoration Mechanism for MPLS Networks", Srinivas Makam, Ken Owens, Vishal Sharma, Changcheng Huang, 07/11/2000, <draft-chang-mpls-path-protection-01.txt> It is expected that MPLS-based recovery could become a viable option for obtaining faster restoration than layer 3 rerouting. To deliver reliable service, however, multi-protocol label switching (MPLS)[1], [2] requires a set of procedures to provide protection of the traffic carried on the label switched paths (LSPs). This imposes certain requirements on the path recovery process [3], and requires procedures for the configuration of working and protection paths, for the communication of fault information to appropriate switching elements, and for the activation of appropriate switchover actions. This document specifies a mechanism for path protection switching and restoration in MPLS networks. "On the Design of Application Protocols", Marshall Rose, 06/16/2000, <draft-mrose-blocks-appldesign-02.txt> This memo describes the design principles for the Blocks eXtensible eXchange Protocol[35] (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous request-response interactions. BXXP permits multiplexing of independent request/response streams over a single transport connection, supporting both textual and binary messages. To subscribe to the Blocks discussion list, send e-mail[36]; there is also a developers' site[37]. "Network Information Model Requirements", David Durham, Walter Weiss, Andrea Westerinen, 07/14/2000, <draft-durham-nim-req-01.txt> 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. "Network based IP VPN Architecture Using Virtual Routers", Timon Sloane, Rick Bubenik, A. Young, B. Gleeson, Gregory Wright, Hamid Ould-Brahim, Richard Bach, 07/19/2000, <draft-ouldbrahim-vpn-vr-01.txt> This draft describes a network based VPN architecture using virtual routers. The VPN service is built based on the virtual router (VR) concept, which has exactly the same mechanisms as a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Within a VPN domain, an instance of routing is used to distribute VPN reachability information among VR routers. Any routing protocol can be used, and no VPN-related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Virtual routers can be deployed in different VPN configurations, direct VR to VR connectivity through layer-2 or by aggregating multiple VRs into a single VR combined with IP or MPLS based tunnels. This architecture accommodates different backbone deployment scenarios, e.g. where the service provider owns their own backbone, and where the service provider obtains backbone service from one or more other service providers. "Policy Management Scalability", Ken Owens, Hugh Mahon, Vijay Jadhwani, 03/10/2000, <draft-owens-policy-scalability-00.txt> Policy Management System (PMS) scalability and resource utilization are important aspects of Policy. Policy management requires centralized management. Scalability factors into the requirements since a centralized management system is not practical if it doesn't scale well to fit the management needs of the environment. The objectives for providing PMS scalability and resource utilization are provided in this draft. "Performance Monitoring in Photonic Networks in support of MPL(ambda)S", John Drake, W. Edwards, Luc Ceuppens, Dan Blumenthal, Jacek Chrostowski, 03/10/2000, <draft-ceuppens-mpls-optical-00.txt> Realizing the important role that photonic switches can play in data-centric networks, work has been going on within the IETF to combine the control plane of MPLS (more specifically traffic engineering) with the point-and-click provisioning capabilities of photonic switches [1]. This document outlines a proposal to expand this initiative to include DWDM, OADM and ATM systems. It also proposes to expand the work beyond simple establishment of optical paths and include optical performance monitoring and management. The combined path routing and performance information that will be carried and shared between these network elements will allow the elements or element management system (EMS) to adequately assess the 'health' of an optical path (which can be a wavelength or fiber strand). The routers and/or ATM switches at the edges of the photonic network will then use this information to dynamically manage the millions of wavelengths available in the photonic layer. "Usage of TRIP in Gateways for Exporting Phone Routes", Jonathan Rosenberg, Hussein Salama, 07/17/2000, <draft-rs-trip-gw-01.txt> This document describes a new application of the Telephony Routing over IP (TRIP) protocol. TRIP was engineered as a tool for inter- domain exchange of telephone routing information. However, it can also be used as a means for gateways and soft switches to export their routing information to a Location Server (LS), which may be co-resident with a proxy or gatekeeper. This LS can then manage those gateway resources. We discuss the motivations for this application, the reasons why other mechanims, such as the SIP REGISTER method, are not appropriate, and then show how a minimal subset of TRIP is needed for this application. "Network Survivability Considerations for Traffic Engineered IP Networks", Ken Owens, Vishal Sharma, Mathew Oommen, 03/13/2000, <draft-owens-te-network-survivability-00.txt> Network survivability refers to the capability of the network to maintain service continuity in the presence of faults within the network [1]. This can be accomplished by recovering from network failures rapidly and maintaining the required QoS for existing services after recovery. With the increasing sophistication of network technologies, survivability capabilities are becoming available at multiple layers, allowing for protection and restoration to occur at any layer of the network. This makes it important to: scrutinize the recovery features of different network layers, understand the pros and cons of performing recovery at each layer, and assess how the interactions between layers impact network survivability. With these objectives in mind, this draft examines the considerations for network survivability at different layers of the network. "ROCCO Conversational Video Profiles ", Lars-Erik Jonsson, Anton Martensson, Torbjorn Einarsson, 03/13/2000, <draft-martensson-rocco-video-00.txt> The Robust Checksum-based header Compression [ROCCO] scheme is a header compression scheme designed to work over error prone channels. The scheme is adaptable to the characteristics of the link over which it is used and also to the properties of the packet streams it compresses. This document describes a number of ROCCO profiles designed for conversational video over error prone channels. The profiles compress the size of the IP/UDP/RTP header down to a minimum of 2 octets. "A Common Terminology for Policy Management", Daniel Grossman, Francis Reichmeyer, John Strassner, Matt Condell, 03/13/2000, <draft-reichmeyer-polterm-terminology-00.txt> This memo defines a common vocabulary for describing concepts and components related to policy management. It is intended to be used to align terminology and concepts in architecture and framework documents that either address policy management or which specify components and services that are subject to policy management. "End to end authentication for LDP", Yves T''''Joens, Peter De Schrijver, 07/18/2000, <draft-schrijvp-mpls-ldp-end-to-end-auth-01.txt> This draft defines extensions to LDP to allow end to end authentication between the LER initiating a LSP and the LER terminating a LSP. The extensions require ordered control LDP and can also be applied to CR-LDP. "Lower Layer Guidelines for Robust Header Compression", Krister Svanbro, 03/13/2000, <draft-svanbro-rohc-lower-layer-guidelines-00.txt> This document describes lower layer guidelines for robust header compression (HC). The purpose of this document is to support the incorporation of robust header compression algorithms, as specified in the ROHC working group, into different systems such as those specified by 3GPP, 3GPP2, ETSI, etc. This document treats general guidelines as well as guidelines specific for cellular systems. "RTP payload format for MPEG-4 Visual Advanced Profiles (scalable, core, main, N-bits)", Paul Christ, Christine Guillemot, 03/13/2000, <draft-gc-avt-mpeg4visual-00.txt> This document describes a payload format for the transport of MPEG-4 visual Elementary Streams, applicable for multimedia applications not restricted to the simple visual profile. It is an application of the format described in [1] to specialized cases of video which are applicable in the H.323 context (using for example MPEG-4 lay- ered streams). It is therefore intended to support advanced MPEG-4 visual profiles (simple scalable, core, main, N-bits profiles), by allowing protection against loss of key segments of the elementary streams. The simple scalable profile supports temporal and spatial scalability, features important for rate or congestion control on the Internet, especially in multicast. The core and the main visual profiles target multimedia applications on the Internet and allow, in addition to scalability, the usage of sprite objects and of arbitrary shape objects. "MIME Type Registration of AMR Speech Codec", Petri Koskelainen, Jon Sjoberg, Ari Lakaniemi, B Wimmer, Bernard Hammer, 03/13/2000, <draft-lakaniemi-avt-mime-amr-00.txt> This document defines MIME-name audio/AMR and its parameters for Adaptive Multi Rate (AMR) speech codec to be used with RTP protocol. "RTP Payload Format for AMR", Petri Koskelainen, Ari Lakaniemi, B Wimmer, Tim Fingscheidt, 03/13/2000, <draft-lakaniemi-avt-rtp-amr-00.txt> This document specifies the encapsulation of AMR (Adaptive Multi- Rate) speech codec frames into payload of the Real-time Transport Protocol (RTP). The format enables encapsulation of one or several AMR speech frames into one RTP packet. Mode adaptation and discontinuous transmission (DTX) are also supported. "SMTP service extension for bulk email", J. Eriksson, 03/13/2000, <draft-eriksson-bulk-email-00.txt> This memo describes an SMTP extension to differentiate between ordinary and unsolicited (bulk) e-mail. This can in turn be used as a mailbox-by-mailbox opt-in or opt-out mechanism for allowing or disallowing bulk e-mail. "Spatial Location Protocol Location Server Authentication", Haitao Tang, James Polk, 03/13/2000, <draft-polk-slp-loc-auth-server-00.txt> This document describes the early considerations for a Spatial Location Server and issues that will need to be addressed when an IP Device that has determined its location (TBD in another document effort) requests, or is requested, to provide that information to a Spatial Location Server (SLS). "RTP payload format for AMR", A Lakaniemi, Magnus Westerlund, P Koskelainen, Johan Sjoberg, 07/18/2000, <draft-sjoberg-avt-rtp-amr-01.txt> This document describes a proposed real-time transport protocol (RTP) [8] payload format for AMR speech encoded [1] signals. The AMR payload format is designed to be able to interoperate with existing AMR transport formats. This document also includes a MIME type registration for AMR. The MIME type is specified for both real-time transport and storage. "Inter-Domain Multicast Forwarding (IDMF) ", A. Iwata, Masahiro Jibiki, 03/13/2000, <draft-jibiki-iwata-mboned-idmf-00.txt> 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. "Source-Specific Multicast for IP", Brad Cain, Hugh Holbrook, 03/13/2000, <draft-holbrook-ssm-00.txt> 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. "Issues for Megaco - Sigtran Interworking in ISDN Access Gateways", Jan Bouwen, Bart Van Doorselaer, Miek Dekeyser, 07/17/2000, <draft-bouwen-megaco-isdn-01.txt> 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. "PPP Internet Protocol Control Protocol Extensions for IP Subnet", Juha Heinanen, A. Lin, Petri Helenius, David Allan, 03/13/2000, <draft-helenius-ppp-subnet-00.txt> The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol 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. "CR-LDP Extensions for Interworking with RSVP-TE ", Gregory Wright, Sandra Ballarte, Tim Pearson, 03/14/2000, <draft-wright-mpls-er-interwork-00.txt> The development of two explicit routing protocols RSVP-TE[RSVP-TE] and CR-LDP[CR-LDP] within MPLS has created the need to allow interworking between the two MPLS. Explict routed (ER) label switch paths do not have a prior knowledge of the ER signaling method in use within the various links comprising a domain. In an integrated environment an ER path may crisscross between RSVP-TE and CR-LDP nodes numerous times. This document describes the procedures for the establishment of an RSVP-TE originated LSP transiting or terminating within a CR-LDP domain and the procedures for the establishment of a CR-LDP originated LSP terminating within an RSVP-TE domain. "Traffic Engineering & QoS Methods for IP-,ATM-,& TDMased Multiservice Networks", Gerald Ash, 07/07/2000, <draft-ash-te-qos-routing-01.txt> The draft describes, analyzes, and recommends traffic engineering (TE) methods which control a network's response to traffic demands and other stimuli, such as link failures or node failures. These TE methods include: *traffic management through control of routing functions, which include call routing (number/name translation to routing address), connection routing, QoS resource management, routing table management, and dynamic transport routing. *capacity management through control of network design. *TE operational requirements for traffic management and capacity management, including forecasting, performance monitoring, and short-term network adjustment. These TE methods are recommended for application across network types based on established practice and experience. "Source-Specific Protocol Independent Multicast", I Kouvelas, Nidhi Bhaskar, 03/14/2000, <draft-bhaskar-pim-ss-00.txt> Source-Specific PIM (PIM-SS) is a variant of PIM Sparse-Mode that only builds source specific shortest path trees. These trees are built directly on receiving group membership reports that request a given source. PIM-SS precludes the building of shared trees, effectively par- titioning the different source trees from one another. For this reason it is specifically suited for existing multicast applications for which there is expected and intended to be exactly one source. Source-Specific PIM can co-exist with PIM-SM. It uses a subset of PIM-SM messages and lends itself to incremental deployment. "RTP Payload Format for MPEG-4 Streams", Emmanuel Gouleau, C Roux, D Curet, P Clement, 03/14/2000, <draft-rgcc-avt-mpeg4flexmux-00.txt> This document describes an RTP payload format for the transportation of encoded and multiplexed MPEG-4 streams. MPEG-4 is a standard whose aims are to define a generic way to code natural or synthetic scenes. MPEG-4, among other things, supports a normative interface to Intel- lectual Property Management and Protection Systems. MPEG-4 also gives methods to synchronise and multiplex several MPEG-4 encoded streams. RTP, on the other hand, is a protocol that has been especially writ- ten for multimedia stream over the IP network, and to use RTP for the carriage of MPEG-4 data does make sense, enabling such applica- tions as Video on demand or Multicast Teleconferencing. "RTP Payload Format for AC-3 Audio", Ladan Gharai, 07/14/2000, <draft-gharai-ac3-01.txt> This document specifies a packetization scheme for encapsulating AC-3 audio streams into a payload format for the Real-Time Transport Protocol (RTP). "RTP Payload Format for Uncompressed HDTV Video Streams", Allison Mankin, Ismail Dalgic, Ladan Gharai, David Richardson, Raymond Yow, 03/14/2000, <draft-gharai-hdtv-video-00.txt> This document specifies a packetization scheme for encapsulating uncompressed HDTV as defined by SMPTE 274M and SMPTE 296M into a payload format for the Real-Time Transport Protocol (RTP). SMPTE 274M and SMPTE 296M define the analog and digital representation of HDTV with image formats of 1920*1080 and 1280*720, respectively. "Hierarchical Mobile IPv4/v6 and Fast Handoffs ", K Malki, Hesham Soliman, 03/14/2000, <draft-elmalki-soliman-hmipv4v6-00.txt> This draft provides a number of extensions to the Hierarchical MIPv4 model in [1] as well as a new Hierarchical MIPv6 model. A number of additions are made to Regional Tunnel Management in terms of Fast Handoffs and the avoidance of triangle routing within the hierarchical domain. A few extensions were also made for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will improve the performance of MIPv6 in terms of handoff speed and is well-suited to implement access control and handoffs between different access technologies. "The Policy Device Auxiliary MIB", Keith McCloghrie, John Seligson, Andrew Smith, Francis Reichmeyer, K Chan, Scott Hahn, Mike Fine, 07/19/2000, <draft-kzm-rap-pol-aux-mib-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes 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]. "Structure of Policy Provisioning Information (SPPI)", Keith McCloghrie, Mike Fine, 03/14/2000, <draft-kzm-rap-sppi-00.txt> RFC 2748 [COPS] defines the COPS protocol, and RFC 2749 [COPS-RSVP] describes how the COPS protocol is used to provide for the outsourcing of policy decisions for RSVP. Another usage of the COPS protocol, for the provisioning of policy, is introduced in [COPS-PR]. In this provisioning model, the policy information is viewed as a collection of Policy Rule Classes and Policy Rule Instances residing in a virtual information store, termed the Policy Information Base (PIB). Collections of related Policy Rule Classes are defined in a PIB module. PIB modules are written using an adapted subset of SNMP's Structure of Management Information (SMI) [SMI, TC, CONF]. It is the purpose of this document, the Structure of Policy Provisioning Information (SPPI), to define that adapted subset. "Link Management Protocol (LMP)", Lou Berger, Hal Sandick, Y Rekhter, John Drake, Debanjan Saha, Kireeti Kompella, Debashis Basak, Jonathan Lang, Krishna Mitra, 07/19/2000, <draft-lang-mpls-lmp-01.txt> Future networks will consist of photonic switches, optical crossconnects, and routers that may be configured with bundled links consisting of a number of user component links and an associated control channel. This draft specifies a link management protocol (LMP) that runs between neighboring nodes and will be used for both link provisioning and fault isolation. A unique feature of LMP is that it is able to isolate faults in both opaque and transparent networks, independent of the encoding scheme used for the component links. LMP will be used to maintain control channel connectivity, verify component link connectivity, and isolate link, fiber, or channel failures within the network. "RTSP Extensions:Additional Transports and Performance Enhancements", Sean Sheedy, 07/13/2000, <draft-sheedy-mmusic-rtsp-ext-01.txt> This document proposes enhancements to the RTSP protocol for broadcast quality non-IP based video- on-demand applications. Additional transports for non-IP delivery of media streams are proposed, along with control extensions to reduce latency. These proposals are based on nCUBE Corporation's and Oracle Corporation's experience with their existing media servers. "Foreign Agent Keys Encoded as Opaque Tokens for use in Hand-off Process", Pat Calhoun, Emad Qaddoura, Haseeb Akhtar, N Asokan, 03/15/2000, <draft-calhoun-mobileip-fa-tokens-00.txt> The Mobile IP Working Group has been working on defining its AAA requirements, which currently supports a Key Distribution Center (KDC) model that issues temporary session keys for use between the mobility nodes. In order to support real-time traffic, the Mobile IP architecture also requires that hand-off be done in a quick and efficient manner, and has provisions to allow new foreign agents to retrieve the session keys from the AAA infrastructure. "Extensions to RSVP for optical networking", John Drake, Jonathan Lang, Krishna Mitra, 03/15/2000, <draft-lang-mpls-rsvp-oxc-00.txt> Dynamically provisionable optical crossconnects (OXCs) will play an active role in future optical networks and the MPL(ambda)S control plane will be used to establish, teardown, and reroute optical trails through the network. This document specifies extensions to RSVP to address some of the unique requirements of such optical trails. Specifically, we propose extensions to RSVP that allow an upstream node to make a Label suggestion to a downstream node when establishing an optical trail and allow both directions of a bi- directional optical trail to be established simultaneously. A new message type is also defined so that an RSVP node can notify (possibly non-adjacent) RSVP nodes when network failures occur, without affecting the RSVP states of intermediate RSVP nodes. Finally, we propose a modification to allow bundle messages to be sent to non-adjacent RSVP nodes. "PIM-SM Rules for Support of Single-Source Multicast", Hal Sandick, Brad Cain, 03/15/2000, <draft-sandick-pimsm-ssmrules-00.txt> This document describes the minor changes in protocol processing rules for the PIM-SM [PIMSM] protocol to support source specific multicast (SSM) routing semantics over the SSM address range [EXPRESS][SSM]. Used in combination with IGMPv3 [IGMPV3], the SSM delivery model can be supported with current protocol implementations. IGMPv3 can be used for communicating source specific (S,G) channel memberships to local routers; PIM-SM can be used for construction of SSM forwarding trees. This document describes the processing rules for PIM-SM in the SSM address range to support construction of SSM delivery trees. "Transport Performance Metrics MIB ", Russell Dietz, 03/15/2000, <draft-dietz-tpm-mib-00.txt> 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. "Codec Capabilities Attribute for SDP", Burcak Beser, 03/15/2000, <draft-beser-mmusic-capabilities-00.txt> 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. "Use of IPSEC Transport Mode for Virtual Networks", J. Touch, 03/15/2000, <draft-touch-ipsec-vpn-00.txt> This document addresses the use of IPSEC to secure the virtual links of an overlay network. It addresses how IPSEC tunnel mode can conflict with dynamic routing in an overlay, due to the dependence of both the security association (SA) and the IP tunnel encapsulation header on the header of the incoming packet. An alternative is proposed, where IP tunnel encapsulation occurs as a separate initial step, followed by IPSEC transport mode on the result. The tunnel header is determined by the source header, and the SA is determined by the tunnel header. The result is consistent with dynamic routing in the overlay. This document discusses this alternative, and its impact on IPSEC. "MIME Type Registration of AMR Speech Codec", B Wimmer, Bernard Hammer, 07/18/2000, <draft-wimmer-amr-01.txt> This document defines MIME-name audio/AMR, encoding format definitions and its parameters for GSM Adaptive Multi Rate (AMR) speech codec for storage purpose. "IPv6 hooks for AAA registration and 'host routing' ", Erik Nordmark, 03/15/2000, <draft-nordmark-ipv6-aaa-hooks-00.txt> This document specifies extensions to IPv6 Neighbor Discovery that allow routers to ask hosts to periodically register. Two types of registrations are defined: to register with an AAA server using an AAA protocol, and to register with the routers using unsolicited Neighbor Advertisement messages to allow hosts to move between some links while keeping the same IPv6 address. In the latter case the routers would use the registrations to inject host routes in a 'local area'. The purpose of this document is to stimulate discussion on how to make IPv6 a good choice for wireless networks that have requirements on 'local' mobility and/or AAA functionality. "Compliance Checking and IPSEC Policy Management", J. Ioannidis, Angelos Keromytis, Matt Blaze, 03/15/2000, <draft-blaze-ipsp-trustmgt-00.txt> This draft describes an architecture for security policy management for IPSEC based on the principle of ``compliance checking.'' We describe a two-level policy hierarchy, in which security association policy is managed by a highly flexible policy language, which in turn provides input to packet policies that are managed by a fast packet filtering language. We provide a sample SA policy language, based on KeyNote, and describe interoperability issues for this architecture. "ICMP Traceback Messages", Steve Bellovin, 03/15/2000, <draft-bellovin-itrace-00.txt> It is often useful to learn the path that packets take through the Internet, especially when dealing with certain denial-of-service attacks. We propose a new ICMP [RFC792] message, emitted randomly by routers along the path and sent to the destination. "SS7 MTP2-User Peer-to-Peer Adaptation Layer", M Kalla, Ram Dantu, Greg Sidebottom, K Morneault, H Schwarzbauer, Tom George, 07/21/2000, <draft-george-sigtran-m2peer-02.txt> This Internet Draft defines a protocol supporting the transport of SS7 MTP Layer 3 signaling messages over IP using the services of the Stream Control Transmission Protocol (SCTP). This protocol would be used between SS7 Signaling Points employing the MTP Level 3 protocol. The SS7 Signaling Points may also employ standard SS7 links using the SS7 Message Transfer Part (MTP) Layer 2 to provide transport of MTP Layer 3 signaling messages. "Integration of Resource Management and SIP", K.K. Ramakrishnan, Warren Marshall, 06/09/2000, <draft-manyfolks-sip-resource-01.txt> This document discusses how network QoS and security establishment can be made a precondition to sessions initiated by the Session Initiation Protocol (SIP), and described by SDP. These preconditions require that the participant reserve network resources (or establish a secure media channel) before continuing with the session. We do not define new QoS reservation or security mechanisms; these pre- conditions simply require a participant to use existing resource reservation and security mechanisms before beginning the session. "Application Performance Measurement Capabilities MIB", Andy Bierman, 03/15/2000, <draft-bierman-rmonmib-apmcaps-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for classifying and characterizing the application performance measurement (APM) capabilities of various standard and proprietary APM techniques. "Local and Indirect Registration for Anchoring Handoffs", G Dommety, Tao Ye, 07/24/2000, <draft-dommety-mobileip-anchor-handoff-01.txt> In wide area deployment, the handoff latencies due to latencies in Mobile IP registrations, delay incurred due to setting up of dynamic keys, and latencies in setting up secure Tunnels could be high. This document proposes enchantments to reduce the latencies involved in such handoffs. It proposes enhancements to facilitate local registration, anchoring, and global indirect registration. "Kerberos V Authentication Mode for Uninitialized Klients", Poornima Lalwaney, Sasha Medvinsky, 07/10/2000, <draft-smedvinsky-dhc-kerbauth-01.txt> The Dynamic Host Configuration Protocol (DHCP) [1] includes an option that allows authentication of all DHCP messages, as specified in [2]. This document specifies a DHCP authentication mode based on Kerberos V tickets. This provides mutual authentication between a DHCP client and server, as well as authentication of all DHCP messages. "IP over Optical Networks - A Framework", B. Rajagopalan, James Luciani, Brad Cain, Bilel Jamoussi, Daniel Awduche, 07/18/2000, <draft-many-ip-optical-framework-01.txt> 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]. "Supplemental Packages for Megaco/H.248 ", Kenneth Chapman, C. Brown, Kevin Boyle, 03/16/2000, <draft-brown-supplpkgs-00.txt> This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services, and PSTN Per Trunk Signaling (PTS). "Dynamic Configuration of IPv4 link-local addresses", Stuart Cheshire, 03/16/2000, <draft-cheshire-ipv4-linklocal-00.txt> As the Internet Protocol continues to increase in popularity as a global communication system, it becomes increasingly valuable to be able to use familiar IP tools such as ftp for local communication as well. For example, two people with laptop computers with built-in wireless Ethernet may meet and wish to exchange files. It is desirable for these people to be able to use IP application software without the inconvenience of having to manually configure static IP addresses or set up a DHCP [RFC 2131] server. This draft describes a method by which a host may automatically configure an interface with an IP address in the 169.254/16 range that is valid for link-local communication on that interface. This is especially valuable in environments where no other configuration mechanism is available. "Application Performance Measurement MIB", Steven Waldbusser, 03/16/2000, <draft-waldbusser-rmonmib-apm-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP- based internets. In particular, it defines objects for measuring the application performance as experienced by end- users. "Multicast DNS", Bernard Aboba, Levon Esibov, Dave Thaler, 07/21/2000, <draft-aboba-dnsext-mdns-01.txt> Today, with the rise of home networking, there are an increasing number of small networks operating without a DNS server. In order to allow DNS name resolution in such environments, the use of a multicast DNS is proposed. "DHCP Lease Query", Richard Woundy, K. Kinnear, 03/16/2000, <draft-woundy-dhcpleasequery-00.txt> Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations 'glean' location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. "AAA for IPv6 Network Access", C Perkins, Thomas Eklund, N Asokan, Patrik Flykt, 03/16/2000, <draft-perkins-aaav6-00.txt> This document proposes a way for IPv6 nodes (clients) to offer credentials to a local AAA in order to be granted access to the local network. Whereas for IPv4 it is not clear that routers and DHCP will be equipped to handle such functions, we believe that it is more efficient and thus reasonable to expect such access controls to be exerted by IPv6 routers, possibly as part of performing their role as DHCPv6 relays. DHCPv6 servers and routers are expected to work in conjunction with AAA servers to determine whether or not the client's credentials are valid. "Third Party Call Control in SIP ", Jonathan Rosenberg, H. Schulzrinne, J Peterson, 03/16/2000, <draft-rosenberg-sip-3pcc-00.txt> This document discusses the usage of SIP for third party call control. Third party call control refers to the ability of one entity to create a call in which communications is actually between other parties. We present a SIP mechanism for accomplishing third party call control that does not require any extensions or changes to SIP. "Deployment of PIM-SO at Sprint ", C Diot, Robert Rockell, Leonard Giuliano, Supratik Bhattacharyya, 03/16/2000, <draft-bhattach-diot-pimso-00.txt> This document considers the requirements for implementing PIM Source- Only (PIM-SO) which will allow the creation of source-based multicast trees across multiple domains in the Internet. PIM-SO realizes the EXPRESS [HOLB99] multicast service model in which there is a single source for every multicast group, and group membership and addressing is based on a multicast group address (G) as well as the source's unicast address (S). Our short-term goal is to implement PIM-SO with minimal changes to the current multicast routing infrastructure by August 2000, and to provide proof of concept by deploying it on Sprintlab's experimental network. By the end of the year, we envisage that PIM-SO will be ready to be incorporated in Sprint's multicast backbone as a commercial point-to-multipoint service. "ISL Architectural Considerations", John Loughney, Soren Nyckelgard, 03/16/2000, <draft-nyckelgard-isl-arch-00.txt> As more and more wireless devices interact with IP networks, location becomes an important parameter in providing and accessing services. This draft strives to provide an architecture to answer the following questions: 1) How can a terminal obtain its coordinates? 2) Where should a terminal store or register its coordinates? 3) How can a called party obtain the calling party's coordinates? 4) How can a terminal 'advertise' its location information "Semantic Model for IPsec Policy Interaction ", John Zao, 03/16/2000, <draft-zao-policy-semantics-00.txt> This Internet Draft discusses three possible forms of interaction among IPsec Policies referred to as Policy Resolution, Policy Correlation and Policy Reconciliation. It also proposes two operators, Policy Composition (*) and Policy Difference (-), to deduce the results of policy interactions. The definitions of these operators establish an algebraic semantics of IPsec Policies based on partially ordered set theory. This formal semantics can be used to ensure consistency of IPsec Policy processing. "Mobile IP Session Identifier Extension", Peter McCann, Kent Leung, 03/16/2000, <draft-mccann-mobileip-sessionid-00.txt> The Network Access Identifier can be added to a Mobile IP registration request to identify the user and to allow the assignment of a dynamic home address. However, users may want to open several simultaneous sessions using the same NAI from the same or different devices and to obtain a unique IP address for each session. The Mobile IP Session Identifier Extension defined in this draft can be used to distinguish registration requests belonging to these various sessions. This draft also clarifies how a dynamic address is to be managed when and if the user returns to the home network that assigned the address. "Universal Mobile IP (UMIP) Location Management", Almon Tang, John Wang, 03/16/2000, <draft-wang-mobileip-umip-00.txt> Global roaming is one of the design objectives for next generation (3G) cellular networks. To efficiently support real-time applications for mobile users in these networks, signaling and payload traffic delays must be minimal. It has been identified that one of the sources causing long delays is triangle routing. That is, for example, in the registration process the registration requests have to be transmitted from a foreign agent in the visited network all the way to the home network every time the mobile node initiates a call or when the mobile node roams into a different visiting network [2]. "Mobility Management in a SIP Environment Requirements, Functions and Issues", H. Schulzrinne, Faramak Vakil, Y. Shobatake, S Baba, Ashutosh Dutta, Jyh-Cheng Chen, 04/11/2000, <draft-itsumo-sip-mobility-req-01.txt> 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. "Some Scenarios for an ISL Architecture", Mari Korkea-aho, 03/16/2000, <draft-korkea-aho-isl-scenarios-00.txt> Mobile devices place an importance of geo-location. Based upon a user's spatial location, certain applications and servers may differ as compared to other locations. This draft attempts to list some location service scenarios and their impact upon any architecture which serves location based services. "CR-LDP Extensions for Interworking with RSVP-TE", G Wright, Sandra Ballarte, Tim Pearson, 03/17/2000, <draft-wright-mpls-crldp-rsvpte-iw-00.txt> The development of two explicit routing protocols RSVP-TE[RSVP-TE] and CR-LDP[CR-LDP] within MPLS has created the need to allow interworking between the two MPLS. Explict routed (ER) label switch paths do not have a prior knowledge of the ER signaling method in use within the various links comprising a domain. In an integrated environment an ER path may crisscross between RSVP-TE and CR-LDP nodes numerous times. This document describes the procedures for the establishment of an RSVP-TE originated LSP transiting or terminating within a CR-LDP domain and the procedures for the establishment of a CR-LDP originated LSP terminating within an RSVP-TE domain. "IPsec Configuration Policy Model", Jamie Jason, 03/17/2000, <draft-jason-ipsp-config-policy-model-00.txt> This document presents an object-oriented model of low-level IPsec policy designed to: o facilitate agreement about the content and semantics of IPsec policy o enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec- enabled endpoints The schema described in this document models the IKE phase one parameters as described in [1] and the IKE phase two parameters for the IPsec Domain of Interpretation as described in [2, 3, 4, 5]. "Generic Tunneling Protocol (GTP)", C Perkins, Alessio Casati, 03/17/2000, <draft-casati-gtp-00.txt> 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. "Semantic Model for IPsec Policy Interaction", John Zao, 04/05/2000, <draft-zao-ipsec-policy-semantics-00.txt> This Internet Draft discusses three possible forms of interaction among IPsec Policies referred to as Policy Resolution, Policy Correlation and Policy Reconciliation. It also proposes two operators, Policy Composition (*) and Policy Difference (-), to deduce the results of policy interactions. The definitions of these operators establish an algebraic semantics of IPsec Policies based on partially ordered set theory. This formal semantics can be used to ensure consistency of IPsec Policy processing. "Referencing ISAN Identifiers with the Local Identifier (lid:) URI Scheme", C. Finseth, 04/05/2000, <draft-finseth-isanlid-00.txt> This document specifies a method to use when referencing ISAN identifiers with the local identifier ('lid:') URI scheme. By specifying such referencing, broadcasts can avoid the overhead of sending the same information multiple times and implementation overhead can be reduced. "The ViDe Reference Model for Internet-extensible H.323 Communications", Mary Yafchak, Tyler Johnson, 04/05/2000, <draft-johnson-yafchak-vide-h323-reference-model-00.txt> 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. "A Framework for Active Probes for Performance Monitoring", Dan Romascanu, C. Kalbfleisch, Robert Cole, 04/05/2000, <draft-cole-appm-00.txt> This memo discusses the use of 'active' probes within the context of remote performance monitoring. It discusses the importance of developing an 'active' probe monitoring capability within the Internet. It develops a framework for active probes in performance monitoring against the backdrop of previous, related work within the IETF. "AAA Protocols : Comparison between RADIUS, DIAMETER and COPS. ", Bernard Sales, Oliver Paridaens, Yves T''''Joens, Ronnie Ekstein, 04/06/2000, <draft-ekstein-aaa-protcomp-00.txt> 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. "RTCP Reporting Extensions", Ramon Caceres, Kevin Almeroth, Timur Friedman, Kamil Sarac, 07/14/2000, <draft-friedman-avt-rtcp-report-extns-01.txt> This document defines a format for extensions to the RTCP SR (sender report) and RR (receiver report) packets that are defined in the RTP specification. Within their 'reception report blocks', SR and RR packets are limited to reporting six specified statistics on any given data source. This document describes how other information can be reported in 'extended report blockS' that are stacked at the end of an SR or RR packet. Some specific block formats are provided here. For other formats that may be defined as the need arises, this document specifies a simple framework that they must adhere to. "Requirements for adding Optical Switch Support to GSMP", Avri Doria, Kenneth Sundell, 04/06/2000, <draft-doria-gsmp-req-olsr-00.txt> This memo provides an overview of the requirements on the GSMP protocol for support of optical switching. "PKCS #9:Selected Object Classes and Attribute Types v2.0", B. Kaliski, Magnus Nystrom, 07/12/2000, <draft-nystrom-pkcs9-v2-01.txt> This memo represents a republication of PKCS #9 v2.0 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The remainder of the text is taken from that specification. This memo provides a selection of object classes and attribute types for use in conjunction with public-key cryptography and LDAP [LDAP} accessibe directories. It also includes ASN.1 syntax for all constructs. "Deflate and Deflate-base64:Compression Content-Transfer-Encodings", Ned Freed, 04/07/2000, <draft-freed-newenc-00.txt> This document defines two additional content-transfer- encodings, deflate and deflate-base64. Adding these CTEs to MIME that provide facilities for loss-less, adaptive, general-purpose compression. The first of these, deflate, produces binary output, while the second, deflate-base64, produces the same sort of output as the base64 content- transfer-encoding defined in [RFC-2045]. "UMTS all-IP Mobility Management, Call and session control Procedures", Giuseppe Ricagni, Antonella Napolitano, 04/07/2000, <draft-ricagni-megaco-umts-all-ip-00.txt> This contribution contains a study aimed at investigating the possible protocols for multimedia call management in 3GPP All-IP networks, and at providing the shared technical background required to chose the most appropriate one. In this first version, call flows are described for multimedia calls using H.248 as the call control protocol and for a basic call (voice call) over UMTS IP network. Further versions of this document will investigate other protocols among those selected by 3GPP (H.248, H.323, SIP), and the advantages and drawbacks of each approach will be highlighted. The network reference model is the same one proposed by 3GPP for an all-IP UMTS Core Network. [2] "An IPv6-IPv4 Compatibility Aggregatable Global Unicast Address Format for Incremental Deployment of IPv6 Nodes Within Predominantly IPv4-based Intranets", Fred Templin, 09/25/2000, <draft-templin-ngtrans-v6v4compat-01.txt> This document specifies an IPv6-IPv4 compatibility aggregatable global unicast address format and its application for incremental IPv6 deployment for hosts and routers within predominantly IPv4-based Intranets. This document assumes that, during the IPv4 to IPv6 co- existence and transition phase, many sites will deploy IPv6 incrementally (not all at once) on hosts and routers within their pre-existing IPv4 interior routing domains; especially those sites which have large and complex pre-existing IPv4 infrastructures. In such cases, the address format and methods described in this document will enable IPv6 deployment for hosts and routers which do not share a common multiple access datalink with their default IPv6 gateways. "Sieve -- Subaddress Extension", Ken Murchison, 09/21/2000, <draft-murchison-sieve-subaddress-02.txt> On email systems that allow for 'subaddressing' or 'detailed addressing' (eg, 'ken+sieve@example.org'), it is sometimes desirable to make comparisons against these sub-parts of addresses. This draft defines an extension to the Sieve mail filtering language that allows users to compare against the user and detail parts of an address. "Sieve -- Regular Expression Extension", Ken Murchison, 07/13/2000, <draft-murchison-sieve-regex-02.txt> In some cases, it is desirable to have a string matching mechanism which is more powerful than a simple exact match, a substring match or a glob-style wildcard match. The regular expression matching mechanism defined in this draft should allow users to isolate just about any string or address in a message header or envelope. "Definitions of Managed Objects for Spatial Reuse Protocol (SRP) ", Stan Jedrysiak, 04/10/2000, <draft-jedrysiak-srp-mib-00.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing networks using SRP interfaces. "SIP INFO method for DTMF digit transport and collection", Tahsin Choudhuri, Chris Haun, Pat Sollee, Scott Orton, Steve Whynot, 04/10/2000, <draft-choudhuri-sip-info-digit-00.txt> This document describes the mechanism how SIP INFO method can be used by applications that require mid session signaling for transport and collection of DTMF digits. "Incorporaion of PGP Certificates into X.509v3 Certificates", Maxim Masiutin, 04/10/2000, <draft-masiutin-x509pgp-00.txt> There were currently no described provisions to convert from an X.509v3 certificate to a PGP Certificate and vice versa because of format of data being signed differ in these two standards. This document defines a new X.509v3 certificate extension called pgpKey that holds a verbatim PGP Certificate, making such conversion possible. This draft is being discussed on the 'x509pgp@egroups.com' mailing list. To join the list, send a message to <x509pgp-subscribe@egroups.com> Also, there is a Web site for the mailing list at <http://www.egroups.com/group/x509pgp> "LDUP Multiple Draft Conflict Resolution (MDCR)", Albert Langer, 04/10/2000, <draft-langer-ldup-mdcr-00.txt> Concurrent changes in a Multi-Master directory are a partially ordered tree. 'LDUP Update Reconciliation Procedures' (URP) uses timestamps to impose a strict linear order on this tree, and merges changes to fit that imposed order. Merged changes violate the semantics of the LDAP/X.500 data model. No specific 'modifierName' can be assigned to a merged change and requirements to support audit trails and access controls and not to break applications or impede future work on transactions cannot be met. The current LDUP requirements draft avoids dealing with these critical issues. "SIP-H.323 Interworking Requirements", Alan Johnston, Hemant Agrawal, Vipin Palawat, Radhika Roy, 04/11/2000, <draft-agrawal-roy-palawat-sip-h323-interworking-00.txt> This document describes the requirements for the logical entity known as the interworking function (IWF) that will allow for interworking between the SIP and H.323 system. "Megaco/H.248 R1 Package ", Vikas Bajaj, Kushanava Laha, 04/12/2000, <draft-hss-megaco-r1package-00.txt> This document is work in progress and defines the MF package in association with the Megaco/H.248 Protocol that can be used to control a Media Gateway (MG) from an external controller, called a Media Gateway controller (MGC). It is intended to satisfy the requirements in section 12 of the Megaco/H.248 requirement document [ ]. "Considerations on IP Spatial Location Protocol Requirements", Kaveh Pahlavan, Mika Ylianttila, Juha Makela, 04/12/2000, <draft-ylianttila-isl-prot-req-00.txt> This document addresses those requirements for IP spatial location protocol that emerges from the situation where mobile hosts (MH) use location information in the inter-domain mobility management. While IP spatial location protocol has many other usage cases, this document focuses on the requirements for mobile IP device that needs to know the whereabouts of IP subnetwork to be visited in order to prepare for handoff. Three inter-technology handoff (ITHO) scenarios and the related problems are presented, and the requirements for the system architecture, terminal and IP spatial location protocol are outlined. "Comfortable Service: A New Type of Integrated Services Based on Policed Priority Queuing ", Fujikawa Kenji, Fujimoto Yoshito, Ikeda Katsuo, Matsufuru Norio, Ohta Masataka, 04/12/2000, <draft-fujikawa-intserv-cs-00.txt> This draft defines Comfortable Service (CS), which realizes statistical end-to-end QoS guarantee in the Internet. CS is based on Policed Priority Queuing (PPQ) which processes packets in a constant time, and statistically guarantee the maximum time of queuing delay. "Definitions of Managed Objects for Open Provisioning Standard (OPS) in the Loop Access Environment", Ray Jamp, Yu-Jen Hsiao, 10/11/2000, <draft-anda-ops-mib-01.txt> This document specifies an Open Provisioning Standard (OPS) that addresses the needs of an Integrated Communications Network (ICN) for remote and automatic service turn-up and for the simplification of monitoring and fault management across multiple network elements within the Loop Access environment and within the Customer Premises Environment (CPE) environment. OPS extends the standard Simple Network Management Protocol (SNMP) Management Information Base (MIB) by defining voice/data integration and flow-through provisioning capabilities for the various devices within the ICN, such as Integrated Access Devices (IADs). OPS enables Carriers or Service Providers to control their Integrated Access Services (IAS) from the network management system in the Network Operation Center (NOC). Flow-through provisioning allows administrators to send provisioning commands to multiple network elements across the ICN. The provisioning commands are used to define or modify a customer's services and to turn those services on and off. Similarly, customer-initiated service requests as well as performance and fault management information for existing services can flow back to the carrier or service provider. "Administrator Address Attribute", M. Wahl, 04/19/2000, <draft-wahl-ldap-adminaddr-00.txt> Organizations running multiple directory servers need an ability for administrators to determine who is responsible for a particular server. This is conceptually similar to the 'sysContact' object of SNMP. "SIP INFO Method for Event Reporting", Viral Bharatia, Ellis Cave, Bert Culpepper, 04/19/2000, <draft-culpepper-sip-info-event-00.txt> This document describes the use of the SIP INFO Method for communicating mid-call events in SIP [1] sessions. Two new MIME types are described, according to the rules defined in RFC 2046 [2], for use in the INFO message. These media types can be used within a SIP INFO message to request, and report, event detection between SIP network entities. Emphasis is placed on DTMF signaling to communicate user indications when using SIP between a Media Gateway Controller (MGC) and a SIP application. "Flow control extensions to Mobile IP for 3G Wireless Networks", Srinivas Ramanathan, Rohit Verma, Ajoy Singh, Irfan Ali, Sebastian Thalanany, Umamaheswar Kakinada, 04/19/2000, <draft-singh-mobileip-fcext-00.txt> This draft proposes extensions to the mobile IP as used in third generation wireless network [7,1,14] to provide a flow control mechanism on a per-session basis for data sent from the packet data servicing node (PDSN) to a radio network node (RNN). This extension solves the problem of significant performance degradation when packets are dropped at the RNN due to channel setup latency and rate mismatch between the air interface and link between the RNN and PDSN (RP link). "Seamless IP Multicast Receiver Mobility Support", Jiang Wu, 04/20/2000, <draft-jiang-msa-00.txt> This document specifies protocol enhancements that allow seamless IP multicast datagram delivery to mobile nodes in the Internet. In order to receive IP multicast datagrams, mobile nodes are not required to be identified by their unicast IP addresses. For unicast communication using Mobile IP, each mobile node needs to have a unicast home address and a care-of address. Following a handover to another IP subnet, such a mobile node is able to receive IP multicast traffic after exchanging IGMP messages with the multicast routers on the currently visiting network. However, in the worst case, it takes an unreasonably long time (especially with respect to streaming media) to resume receiving multicast IP traffic in the visiting network. This draft specifies a Mobility Support Agent (MSA) protocol which provides a mechanism to help ensure seamless reception of IP multicast traffic despite a mobile node handover. This is possible because in advance of its handover, a mobile node pre-registers with the MSA on the next network to be visited. The MSA acts as a proxy for this mobile node and is thus able to set up all the necessary states for the seamless delivery of multicast traffic to this mobile node. "Simple Instant Messaging and Presence 1.1 Protocol", John Ramsdell, 05/15/2000, <draft-ramsdell-simp-protocol-01.txt> The MITRE Corporation released a open source Instant Messaging system in March of 2000 called Simple Instant Messaging and Presence Service. This document describes an update to the protocol used by that system. In this version of the protocol, messages can be digitally signed. While the system does not meet many of the requirements of the IMPP working group, it is provided as background information on existing Instant Messaging implementations. "Whois Export and Exchange Format", Rick Wesson, 08/24/2000, <draft-wesson-whois-export-02.txt> This memo presents a technique for using XML (Extensible Mark-up Language) as a source format exchanging WHOIS data related to Domain Registration Information and for the purpose of exporting Registrar data into a portable and verifiable format for ICANN mandated Registrar Data Escrow. Discussion on this Internet-Draft is to be held on the mailing list ietf-xml-whois@ar.com, which is hosted by the Alice's Registry, Inc. To subscribe, send an email to ietf-xml-whois-request@ar.com, with the text 'subscribe' as the only word in the body of the mail. There is an archive of the mailing list at [7] "Internet-Telephony Directory for Mapping E.164 to Internet Addresses ", R. F. Walters, David Peek, Douglas Ranalli, 04/21/2000, <draft-peek-enum-itd-00.txt> A holistic directory system is described which translates a standard E.164 telephone number into the Internet address information required to support IP-enabled communications applications such as real-time voice, voice-messaging, fax or unified-messaging. The proposed system utilizes two logical control tiers to implement the translation. The first logical control tier is patterned after a Top Level Domain (TLD) of the Internet Domain Name System (DNS). This first-tier provides a mechanism for locating the appropriate directory within the second logical tier of the Internet-Telephony directory system where authoritative Internet address information is stored for a given E.164 number. This first-tier is expected to conform to the regulatory and operational standards defined by the Internet Corporation for the Assignment of Names and Numbers (ICANN) for the operation of top-level domains. The second logical control tier provides a mechanism for accessing and managing authoritative Internet address information associated with an E.164 number. This tier consists of widely distributed DNS servers controlled by service providers, and corporate network operators. Distributed ownership of the second tier directories allows organizations to control the Internet address information associated with the E.164 numbers under their day-to-day control. "Comparison of DIAMETER Against AAA Network Access Requirements ", Pat Calhoun, 04/21/2000, <draft-calhoun-aaa-diameter-comp-00.txt> The AAA Working Group has completed a document that itemizes their requirements for Network Access Applications (NASREQ, Mobile IP, and ROAMOPS). This specification compares the DIAMETER protocol against the requirements, and is provided to the AAA Working Group as an official submission for an AAA protocol. "Lightpath attributes and related service definitions ", Jennifer Yates, Larry McAdams, 04/24/2000, <draft-mcadams-lightpath-attributes-00.txt> This document specifies the attributes and related service definitions that may be associated with lightpaths in an optical network. The document is currently being developed within the Optical Internetworking Forum (OIF) and is being presented to the IETF for informational purposes. "Instant Message and Presence Transfer Protocols", Greg Hudson, 05/04/2000, <draft-hudson-impp-transfer-proposal-01.txt> 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'. "Presence Information Data Format", Greg Hudson, 05/19/2000, <draft-hudson-impp-pidf-proposal-01.txt> This document specifies a simple, readable, and highly extensible presence information format to be used in the Instant Messaging and Presence Protocol suite. "Use of a Semantics Register with WebDAV Properties", E. Christian, 04/24/2000, <draft-christian-prop-semantics-00.txt> This document specifies a mechanism to associate a WebDAV ([WEBDAV]) property with an entry in a Semantics Register. A Semantics Register documents the meaning of properties in a formal manner and may be implemented with schema technologies such as Extensible Markup Language (XML) Schema ([XMLSCHEMA]) or Resource Description Framework (RDF) Schema ([RDFS]). Schema technologies expose the derivation of complex properties from simpler concepts, as demonstrated in the Basic Semantics Register ([BSR]) for data elements used in Electronic Data Interchange. Registering the meanings of properties in this manner can enhance interoperability across systems and throughout the long-term information life cycle. "Routing Information Exchange in Optical Networks", B. Rajagopalan, Debanjan Saha, D. Pendarakis, 04/25/2000, <draft-prs-optical-routing-00.txt,.ps> The objective of this draft is to describe mechanisms for exchanging routing information between IP routers and optical networks, and between optical sub-networks. Such information exchange would allow automated establishment of end-to-end paths in an optical network comprising of multiple sub-networks. Furthermore, it would allow optical network clients, specifically IP routers, to discover their remote peers dynamically. Determination of reachability could be the first step in dynamic provisioning of optical paths using signaling. (A postscript version of this draft with figures is available as draft-optical-routing-00.ps). "The Mini-DHCP Server", Bernard Aboba, 10/05/2000, <draft-aboba-dhc-mini-02.txt> Today, with the rapid rise of home networking, there is a need for simple mechanisms of IPv4 address allocation and name resolution. This document describes the behavior of the mini-DHCP server, a small scale DHCP server implementation that typically resides on the home gateway. As described in this document, the mini-DHCP server is capable of allocating addresses either in single or multi-segment networks. It is also capable of automatically detecting the presence of a full-fledged DHCP server, or other mini-DHCP servers, and shutting down as required. "ECN Interactions with IP Tunnels", K.K. Ramakrishnan, Sally Floyd, 04/27/2000, <draft-floyd-ecn-tunnels-00.txt> The encapsulation of IP packet headers in tunnels is used in many places, including IPsec and IP in IP [RFC2003]. Explicit Congestion Notification (ECN) is an experimental addition to the IP architecture that uses the ECN field in the IP header to provide an indication of the onset of congestion to applications. ECN provides this congestion indication to enable end-node adaptation to network conditions without the use of dropped packets [RFC 2481]. Currently, the ECN specification does not accommodate the constraints imposed by with some of these pre-existing specifications for tunnels. This document considers issues related to interactions between ECN and IP tunnels, and proposes two alternative solutions. "Fixing the iCalendar Registration Process", John Stracke, 04/28/2000, <draft-stracke-calsch-ical-reviewer-00.txt> This document discusses a problem with the [ICALENDAR] registration process, which gives the Method Reviewer too much power, and proposes a fix. "The Architecture of End to End Multihoming", Masataka Ohta, Manolo Sola, 04/28/2000, <draft-ohta-e2e-multihoming-00.txt> This memo describes the architecture of end to end multihoming. End to end multihoming does not burden routing system for multihoming. That is, even extensive use of end to end multihoming does not increase the number of entries in a global routing table. Traditionally with IPv4, multihoming capability is offered by an intelligent routing system, which, as is always the case with violating the end to end principle, lacks scalability on a global routing table size and robustness against link failures. On the other hand, with end to end multihoming, multihoming is supported by transport (TCP) or application layer (UDP etc.) of end systems and does not introduce any problem in the network and works as long as there is some connectivity between the end systems. Because end to end multihoming is performed in end systems, the architecture needs no routing protocol changes. Instead, APIs and applications must be modified to some extent. "BASE (Billing- and Accounting-System Exchange-Protocol) Protocol Specification ", Odo Maletzki, Thilo Dieckmann, Martin Grundmann, 04/28/2000, <draft-ioag-base-00.txt> The Billing and Accounting System Exchange (BASE) protocol is intended for use for the data transfer between the subsystems of a distributed billing and accounting system. It defines the communication between central billing engines (BEs) and one or more locally or remotely installed billing agents (BAs). BAs are used to supply the BEs with load data used for billing and accounting purposes. BEs are responsible for the process of billing and accounting as well as for the configuration of the BAs and their connected source systems. This document defines and describes the BASE protocol. "Preventing DDoS Smurf Attacks", vishal shah, 05/01/2000, <draft-vshah-ddos-smurf-00.txt> Host Requirements RFC1122 states that an ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded. By discarding all broadcast ICMP Echo Requests, the end user may lose valuable diagnostic capability. By forwarding some broadcast ICMP Echo Requests, the host may be used as launching platform for Smurf Attacks[1]. This draft describes a solution for selectively dropping broadcast ICMP Echo Requests based on whether the source address is within the network or from outside the network. Any host implementing this solution ensures that it does not participate in a Smurf attack irrespective of whether responding to broadcast ICMP Echo Requests is enabled or disabled on it. "LDAP Controls for Reply Signatures", R. Salz, 05/01/2000, <draft-salzr-ldap-repsig-00.txt> In many environments the final step of certificate issuance is publishing the certificate to a repository. Unfortunately, there is no way for a Certification Authority (CA) to have a secure application-level acknowledgement that the proper repository did, in fact, receive the certificate. This issue is of greater concern when considering the publication of Certificate Revocation Lists (CRLs) -- if an adversary manages to interpose itself between the CA and its intended repository, then clients could end up relying on outdated revocation lists. This document defines a set of controls so that an LDAP client, such as a CA, can receive a cryptographically secure acknowledgement that an LDAP server has received a request, and that the integrity of the server's reply has not been compromised. Whenever possible, the definitions here use mechanisms and datatypes defined by the IETF PKIX working group. This document references RFC 2459 [RFC2459]. Knowledge of the RFC is required for proper implementation of this document, although it should be possible to understand this document without much knowledge of that RFC. It is expected that future versions of this document will reference 2459's successor(s). "BGP-4 support for Traffic Engineering", Ben Abarbanel, Senthil Venkatachalam, 06/28/2000, <draft-abarbanel-idr-bgp4-te-01.txt> 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. "Conformance Test Specification for SCTP", Sunil Mahajan, 05/17/2000, <draft-mahajan-conformance-test-sctp-01.txt> This document presents the conformance test specification for SCTP prototcol (ver 07), which can be used to test SCTP implementations for conformance to the protocol definition. The list of test is exhaustive and covers almost all the categories of test, except few (test for timer calculation and congestion) which will be added in the next revision of the draft. This draft can also be used in conjunction with SCTP specification by implementor of protocol as implementors guide, as the pictorial representation of various scenarios help understand the protocol. Next revision of the draft will also cover the additions done to the protocol revision SCTP-09 and any subsequent RFC published by IETF. "SMTP Service Extensions for Transmission of Large and Binary Message Headers", Gregory Vaudreuil, 05/03/2000, <draft-vaudreuil-binaryheaders-00.txt> This memo defines two new service extensions to the SMTP service. The first service enables a SMTP server to indicate the maximum size RFC822 header it is willing to accept in a message. The second enables a SMTP client and server to negotiate the use of 8bit or or 8bit encoded binary contents within the message header. This memo specifies the algorithms necessary for the interworking between extended clients with a large and binary header and non-extended SMTP servers. It is expected this document may be split into three, 1) The ESMTP messageheader SIZE extension, 2) the ESMTP 8bit message header encoding extension, and 3) the registration of the "Usage Based Address Allocation Considered Harmful", Geoff Huston, Jun Murai, Masaki Hirabaru, Masataka Ohta, 05/03/2000, <draft-ohta-address-allocation-00.txt> The current usage based IPv4 address assignment policies might have prolonged the useful lifetime of IPv4 address space but this has to the detriment of the the end-to-end architecture of the Internet. This memo proposes the adoption of an address assignment strategy that releases large blocks of IPv4 address space into the Internet. The objective of this policy is to encourage healthy Internet deployment models with end-to-end transparency and association of permanent connectivity with a stable IP address. This is intended to encourage provider support for open transparent Internet service environments that can be sustained with the adoption of IPv6. "IP Mobility and the CDMA Radio Access Network: Applicability Statement for Soft Handoff", James Kempf, Phil Roberts, Peter McCann, 07/10/2000, <draft-kempf-cdma-appl-01.txt> Recently, there have been a variety of proposals submitted to the Mobile IP Working Group and to other IETF working groups for IP mobility solutions that seek to enhance or replace mobile IP. These proposals, often characterized as micromobility or fast handoff, are addressed primarily at the perceived need of multimedia sessions such as video or voice over IP for faster handoff between radio base stations, and are primarily directed at real time multimedia traffic in 3rd generation cellular access networks. In this paper, we discuss the design of CDMA radio access networks (RANs) and the applicability of IP mobility to soft handoff in a CDMA RAN. We attempt to show that given current IP routing algorithms and the constraints on a CDMA RAN, IP mobility solutions have little, if any, role to play in handoff within the RAN. In contrast, an IP mobility solution is likely to play a big role in fast handoff between RANs, also called hard handoff. While future developments in IP networking may change this situation, IP mobility in CDMA networks currently seems to apply only when the mobile node roams between disconnected RANs rather than between base stations within a RAN or between connected RANs. "Signed Headers in Mail and Netnews", Charles Lindsey, 05/04/2000, <draft-lindsey-usefor-signed-00.txt> The huge growth of Netnews/Usenet in recent years has been accompanied by many attempts to abuse the system by various forms of malpractice, particularly the forging of various headers, causing it to appear that articles came from parties other than those that actually injected them or conveyed some Approval that the real poster was not entitled to give. Insofar as Netnews is regularly gatwayed to and from Email systems, these problems also extend to the Email domain. This document provides a cryptographically secure means whereby it can be established beyond doubt that relevant headers of a Netnews article or an Email message have not been tampered with in transit, and that they were indeed originated by the person purporting to have done so. It seeks to supplement, rather than to supplant, the existing protocols for signing the bodies of articles and messages. [This proposal arises from the activities of the Usenet Format Working Group, which is charged with updating the Netnews standards. Comments are invited, preferably sent to the mailing list of the Group at usenet-format@landfield.com.] "L2TP Circuit Emulation Services Extension", Danny McPherson, Ravi Bhat, Andy Koscinski, Chi Ho, 06/02/2000, <draft-mcpherson-l2tp-es-01.txt> The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism for tunneling PPP sessions. This document proposes mechanisms by which the L2TP tunneling scheme can be used to provide circuit emulation support for layer 2 circuits (i.e. Frame Relay or ATM), as well as TDM circuits (i.e. DS1 or DS3). L2TP is used to provide tunneling support and each circuit is encapsulated over a session inside the Tunnel. An Encapsulation Services Protocol [RefESP] is used on top of the individual L2TP sessions to support the circuit emulation of layer 2 VCs or TDM circuits. The purpose of this document is to explain the L2TP modifications done to facilitate support of circuit emulation services, as well as to define the additional AVPs that can be used to provide the service. "On the use of HTTP as a Substrate for Other Protocols", Keith Moore, 10/17/2000, <draft-moore-using-http-01.txt> Recently there has been widespread interest in using Hypertext Transport Protocol (HTTP) as a substrate for other applications-level protocols. This document recommends technical particulars of such use, including use of default ports, URL schemes, and HTTP security mechanisms. "Telnet URL Transmission Option", David Croft, 05/05/2000, <draft-croft-telnet-url-trans-00.txt> This document defines an extension to the Telnet protocol by which compliant applications may exchange URL information to provide hyperlinks for the user. Comments are invited on both this protocol, and on this document itself. "Robust Header Compression using Update Packets ", Hung Tran, Erica Schnurr, Martin Gallant, 05/05/2000, <draft-tran-rohc-upd-packets-00.txt> This contribution describes a new header compression scheme whereby small update packets are sent from the compressor to the decompressor. This scheme maintains the same compressed header size even when the BER (Bit Error Rate) increases. Simulations show that this scheme will approach the ideal header compression scheme. The main advantage of our scheme is that it is logically simple. The compressor has total control of when the small update packets are to be sent. "OSPF Extensions to Support Inter-Area Traffic Engineering", Ben Abarbanel, Senthil Venkatachalam, 05/09/2000, <draft-venkatachalam-ospf-traffic-00.txt> This document describes the OSPF 'Traffic Engineering Summary LSA' and its support to enable traffic engineering across area boundaries. "Multiprotocol Label Switching Packet Classification Management Information Base Using SMIv2", A Viswanathan, C Srinivasan, Thomas Nadeau, 07/21/2000, <draft-nadeau-mpls-packet-classifier-mib-01.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for specifying packet classification and corresponding actions for use with Multiprotocol Label Switching (MPLS). "The SCSI Encapsulation Protocol (SEP) ", Andrew Wilson, 05/10/2000, <draft-wilson-sep-00.txt> This Internet-draft presents a protocol developed at Adaptec, Inc. as part of a proof-of-concept demonstration that Gigabit Ethernet can serve as a direct replacement for traditional storage interconnects. The draft discusses the scope of problems that the protocol addresses, the key design decisions that were made, and then documents the protocol details. "Definitions of Managed Objects for the Universal Serial Bus (USB) Interface", Benjamin Dolnik, 08/09/2000, <draft-dolnik-usb-mib-02.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Universal Serial Bus (USB) interfaces. "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", Michael Mealling, 09/27/2000, <draft-mealling-pin-urn-01.txt> This document describes a URN namespace that is engineered by Network Solutions, Inc for naming people and organizations. "WEB based Certificate Access Protocol-- WebCAP/1.0", Surendra Reddy, 05/19/2000, <draft-skreddy-pkix-webcap-00.txt> 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. A various certificate related information that includes certificates, CLs, and certification authority (CA) policy are retrieved from an integrated single authority access point specified in X.509 version 3 extensions. "Event Notification Protocol - ENP ", Surendra Reddy, 05/19/2000, <draft-skreddy-enp-protocol-00.txt> As the complexity of distributed applications increases, an increasing amount of processing is done using distributed processes, which typically execute without the direct supervision of an end user. The user must poll these processes periodically to check if they are completed successfully or not. This polling results in unnecessary wastage of network bandwidth as well as computing resources. The user generally cannot see intermediate results or progress reports for long running processes, they must wait till the process is completely finished before viewing the results. Thus the problem of monitoring events is central in distributed applications and protocols. A repeated need in such applications is receive notifications when a resource property value changes or event state changes. Current database systems provides mechanisms like constraints, triggers and active database rules. These facilities provides an automated means to ensure the database integrity or perform specific action when data changes. Need for such kind of requirement is fundamental is network applications "Triggering AAA from DHCP Relay Agents", George Tsirtsis, 05/19/2000, <draft-tsirtsis-dhc-aaa-ra-00.txt> Recently there has been interest in using DHCP for configuring clients accessing the Internet through some form of high-speed access technology such as cable or ADSL [DHC-AGENT]. In addition, although DHCP was initially designed for configuring fixed hosts, proposals are being made to enhance DHCP to support roaming/mobile clients [DHC-ENHANCE]. These two trends have put in evidence the need for a coupling between AAA and DHCP. Some initial requirements for DHCP/AAA have been proposed in [DHC-AAA]. This document proposes a different model in which AAA procedures are invoked not from a DHCP server but from a DHCP relay agent to make sure that ALL the Internet Access features supported by the PPP model can be replicated in a DHCP based Internet Access environment. "Security in the Instant Message and Presence Protocols", Greg Hudson, 05/22/2000, <draft-hudson-impp-security-00.txt> 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. "Source-Specific Protocol Independent Multicast in 232/8 ", Robert Rockell, Greg Shepherd, Ed Luczycki, 05/22/2000, <draft-shepherd-ssm232-00.txt> IP Multicast group 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 operational recommendations to ensure source- specific behavior within the 232/8 range. "ISO/IEC 9798-3 Authentication SASL Mechanism", Robert Zuccherato, Magnus Nystrom, 09/29/2000, <draft-zuccherato-9798-3-sasl-02.txt> This document defines a SASL [RFC2222] authentication mechanism based on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity authentication. This mechanism only provides authentication using X.509 certificates [X509]. It has no effect on the protocol encodings and does not provide integrity or confidentiality services. "NAT and IPSEC", Bernard Aboba, 07/12/2000, <draft-aboba-nat-ipsec-02.txt> Perhaps the most common use of IPSEC is in providing virtual private networking capabilities. One very popular use of VPNs is to provide tele-commuter access to the corporate Intranet. With NATs being increasingly deployed in home gateways, NAT-IPSEC incompatibilities have become a major barrier to deployment of IPSEC in one of its principal uses. This draft discusses the incompatibilities between NAT and IPSEC and suggests how IPSEC might be made more NAT friendly. "Application/w-xxx-forms Media Type", Dinkar Tiwari, 05/25/2000, <draft-tiwari-appl-wxxx-forms-00.txt> This document proposes to standardize application/w-xxx-forms, a media type for use in sending requests involving form-input from a browser to a http server. These requests are currently sent via the HyperText Transfer Protocol on the World Wide Web. "Policy-Based Load-Balancing in Traffic-Engineered MPLS Networks", Francis Reichmeyer, Steven Wright, Robert Jaeger, M Gibson, 05/26/2000, <draft-wright-mpls-te-policy-00.txt> This document considers the application of policy based traffic engineering techniques to load-balancing in MPLS networks. The objective is not to mandate a specific policy, but to (a) provide an example of a policy based approach to a traffic engineering problem and (b) elucidate a range of potential policies related to load balancing as a traffic engineering objective as guidance for the development of a Policy Information Base (PIB) for MPLS networks. "DNS Top Level Domain For Private Networks ", Simon Coffey, Sandy Strain, 05/26/2000, <draft-coffeystrain-privatednstld-00.txt> The document outlines the use of a top level DNS domain '.pri', for use within private networks. A reserved top level domain would allow private domain names to be chosen that would not conflict with current or future registered public domain names. "Registration of 'pages' Media Feature Tag", John Neystadt, 05/26/2000, <draft-neystadt-pages-media-00.txt> This document contains the registration for media feature tag: 'pages'. These media feature allow specification of number of pages of documents that can be understood by devices and the devices' users. The templates in this document are derived from [TAG-REG]. "Diffie-Hellman Group Exchange for the SSH Transport Layer Protocol", W. Simpson, Niels Provos, Markus Friedl, 05/26/2000, <draft-provos-secsh-dh-group-exchange-00.txt> This memo describes a new key exchange method for the SSH protocol. It allows the SSH server to propose to the client new groups on which to perform the Diffie-Hellman key exchange. The proposed groups need not be fixed and can change with time. "Proposed Modifications to the Service Location Protocol, Version 2", Erik Guttman, James Kempf, 07/06/2000, <draft-guttman-svrloc-slpv2bis-01.txt> SLPv2 [1] has been widely implemented but not all features of the protocol are in common use. If these features were deprecated from the specification the protocol would be simpler, yet still perform its core function. The changes proposed in this document could be the basis for a revision of SLPv2 as it is considered for advancement to Draft Standard. "Comparison of RADIUS Against AAA Network Access Requirements", Yves T''''Joens, Ronnie Ekstein, Marc De Vries, 05/30/2000, <draft-tjoens-aaa-radius-comp-00.txt> The AAA Working Group has completed a document that itemizes their requirements for Network Access Applications (NASREQ, Mobile IP, and ROAMOPS). This document compares the current RADIUS protocol to the Network Access AAA Evaluation Criteria, and illustrates where and how RADIUS can be improved to become unconditionally compliant to these requirements. This document is provided to the AAA Working Group as an official submission for an AAA protocol. "Textual Conventions for Transport Addresses", M. Daniele, J. Schoenwaelder, 05/30/2000, <draft-ops-taddress-mib-00.txt> This document contains a MIB module for commonly used transport layer 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. This work is output from the Operations and Management Area 'IPv6MIB' design team. "SIP enabled IN Services - an implementation report ", Vijay Gurbani, 05/30/2000, <draft-gurbani-iptel-sip-in-imp-00.txt> SIP [1] is an excellent vehicle for the converged network services of the future; of that there is no doubt. However, even in the near term, SIP is an equally powerful solution to bridge the PSTN and VoIP networks by its application to the IN (Intelligent Network) services domain. This Internet Draft details our experiences of applying SIP to the said domain. We use a SIP call controller to execute IN services by mapping IN call model states to those of the SIP protocol state machine [2]. [2] uses the notion of call model integration [3], an example of which is to use the IN call model as a canonical call model to map the protocol states of IP (Internet Protocol) based call controllers (SIP, H.323,...) to those of the IN call model. "Extensions to a Method for Transmitting PPP Over Ethernet (PPPoE)", Thomas Stoner, Che-Lin Ho, Dan Simone, Dave Carrel, 05/31/2000, <draft-carrel-info-pppoe-ext-00.txt> The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPPoE [2] describes how to build PPP sessions and encapsulate PPP packets over Ethernet. This document describes extensions to PPPoE. These extensions provide added functionality, but are optional and preserve compatibility. "A Framework for Synthetic Sources for Performance Monitoring ", Russell Dietz, Dan Romascanu, R. Cole, C. Kalbfleisch, 05/31/2000, <draft-cole-sspm-00.txt> This memo discusses the use of synthetic sources (or 'active' probes) within the context of remote performance monitoring. It discusses the importance of developing an 'active' probe monitoring capability within the Internet. It develops a framework for synthetic sources in performance monitoring against the backdrop of previous, related work within the IETF. It further reports on the broad agreements reached in the rperfman BOF held in Adelaide in March 2000 on furthering work in this area within the IETF. "Comparison of COPS Against AAA Network Access Requirements", Jesse Walker, David Durham, Hormuzd Khosravi, 06/01/2000, <draft-durham-aaa-cops-reqments-00.txt> The AAA Working Group has completed a document that itemizes their requirements for Network Access Applications (NASREQ, Mobile IP, and ROAMOPS). This specification compares the COPS protocol against the requirements, and is provided to the AAA Working Group as an official submission for an AAA protocol. "COPS Usage for AAA ", Avri Doria, David Durham, Walter Weiss, Hormuzd Khosravi, 06/01/2000, <draft-durham-aaa-cops-ext-00.txt> This document describes how COPS can be used as a general purpose Authentication, Authorization, and Accounting (AAA) Protocol. "A URN Namespace of Object Identifiers", Michael Mealling, 09/12/2000, <draft-mealling-oid-urn-02.txt> This document describes a URN namespace that contains Object Identifiers (OIDs). "COPS Over TLS", J. Walker, 06/02/2000, <draft-jwalker-cops-tls-00.txt> This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@iphighway.com mailing list. "CMS over COPS", J. Walker, 06/02/2000, <draft-jwalker-cops-cms-00.txt> This memo describes how to use TLS to secure COPS connections over the Internet. Please send comments on this document to the rap@iphighway.com mailing list. "Internationalized domain names divided by characters key", Deuk Jang, 08/10/2000, <draft-dkjang-idn-01.txt> This description addresses the method for using internationalized (multilingual) domain names under the current DNS. Further, the method for converting a internationalized domain name expressed in a native language, into a traditional US-ASCII domain name compatible in current DNS, is addressed. This method especially uses 'sequence of 36 characters' to convert all characters in IDN into US-ASCII. Finally, the way to use this method with lc2LDs are presented. "The Alternative Best-Effort Service", J. Le Boudec, Paul Hurley, 06/05/2000, <draft-hurley-alternative-best-effort-00.txt> Alternative Best-Effort (ABE) is a novel service for IP networks. It offers applications the choice between receiving a lower end-to-end delay and receiving more overall throughput. Every best effort packet is tagged as either green or blue. Green packets receive a low, bounded queueing delay. To ensure blue packets do not suffer as a result, green flows receive less throughput during bouts of congestion. "Firewall Control Requirements", P. Mart, P Sijben, Richard Swale, 06/05/2000, <draft-tiphon-foglamps-00.txt> This draft describes a set of requirements for a protocol between application level entities, acting as proxies, and packet filtering devices that implement policies determined by the application. The packet filters apply header translation and police flow rates. These requirements are considered initially in the context of IP telephony but may be extended further. "GENERAL NETWORK PROTOCOL (GNP)", Max Wildgrube, 06/05/2000, <draft-wildgrube-gnp-00.txt> This proposal describes a multi-purpose networking protocol. In the following it is named 'GNP' (General Network Protocol). "Enhancing TCP's Loss Recovery Using Early Duplicate Acknowledgment Response ", Sally Floyd, Mark Allman, Hari Balakrishnan, 06/05/2000, <draft-allman-tcp-lossrec-00.txt> This document proposes two new TCP mechanisms that can be used to more effectively recover lost segments when a connection's congestion window is small, or when a large number of segments are lost in a single transmission window. The first of these mechanisms, 'Limited Transmit', calls for sending a new data segment in response to each of the first two duplicate acknowledgments that arrive at the sender. The second mechanism is to reduce, in certain special circumstances, the number of duplicate acknowledgments required to trigger a fast retransmission. "The SELECT Protocol for Rating and Filtering", J. Palme, Johan Kaers, 06/05/2000, <draft-palme-select-00.txt,.ps> The SELECT protocol allows Internet users to supply their ratings of Internet documents, and to use ratings provided by other users to filter and select what to read In particular, SELECT supports so-called collaborative filtering. By this is meant that the filtering and selection for a particular user is made based on ratings provided by special groups of raters, such as peer groups, people with similar values, interests and expertise as the person for whom the selecting and filtering is done. The SELECT functionality is downwards compatible with PICS [PICS 1, PICS 2], but a major difference is that while PICS is mainly oriented towards keeping out unsuitable information from children (blackballing), SELECT is mainly oriented towards helping people find the best and most valuable information for them on the Internet (goldballing). A syntactical difference from PICS is that the encodings in SELECT are using the XML encoding format. "Calculation of protection paths and proxy interfaces in optical networks using OSPF", Dan Dovolsky, Igor Bryskin, 06/06/2000, <draft-dovolsky-bryskin-ospf-pathprotect-proxy-00.txt> The first part of this document describes a proposal about how to calculate non-overlapping primary and redundant path(s) in optical networks using the OSPF routing protocol and Traffic Engineering Extensions to OSPF, as defined in [KATZ]. The second part of the document introduces the concept of a Proxy Interface and describes a method to avoid unnecessary OSPF traffic activity in networks where adjacent nodes are interconnected via multiple interfaces. "Ethernet Encapsulation Extensions to Layer Two Tunneling Protocol ", Suhail Nanji, 06/06/2000, <draft-nanji-l2tp-eth-00.txt> The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for tunneling PPP [2] packets. This document describes an extension to L2TP which will allows for Ethernet frames to be transported over a session in an L2TP tunnel. These extensions provide added functionality, but are optional and preserve compatibility. Also, the same tunnel SHALL carry both PPP and Ethernet L2TP sessions if needed. "Firewall Redundancy Protocol Specification", Andreas Papp, 06/06/2000, <draft-papp-frp-spec-00.txt> Firewalls are used to get controlled and secure connection between networks, e.g. a company's internal network and the Internet. Preferably the firewall is the only link between the networks to be able to guarantee a certain level of security. The firewall is a critical node in the network and if it would fail the result is lost connection between the networks. To ensure reliability and connectivity we add redundancy, i.e. a number of parallel firewalls are installed which will act as backups for each other. "Multiprotocol Multicast Routing MIB", A Adams, William Siadak, Dave Thaler, 06/06/2000, <draft-thaler-idmr-multicast-routemib-00.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing IP Multicast Routing for IPv4 and IPv6, independent of the specific multicast routing protocol in use. "Protocol Independent Multicast MIB for IP ", A Adams, William Siadak, Dave Thaler, 06/06/2000, <draft-thaler-idmr-multiproto-pimmib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing the Protocol Independent Multicast (PIM) protocol for IPv4 and IPv6. "Mobile IP Agents as DHCP Proxies", S. Glass, 06/08/2000, <draft-glass-mobileip-agent-dhcp-proxy-00.txt> Since the inclusion of the Network Access Identifier (NAIs) into the mobile ip fabric, home agents have had a way to identify mobile nodes which do not have home IP addresses. After authenticating the registration request from such a mobile node, the home agent is then expected to assign a home addresses to the mobile node in the registration reply to be used on a semi-permanent basis. Unfortunately, no specific mechanism has yet been proposed. Ideally, as DHCP centralizes address management, a home agent should contact a DHCP server to allocate an address for the mobile node, thereby preserving DHCP as the central address maintainer. The technology does exist for a Home Agent to use DHCP controlled addresses, namely for the Home Agent to behave as a DHCP proxy agent. "Comparison of SNMPv3 Against AAA Network Access Requirements ", Bob Natale, 06/08/2000, <draft-natale-aaa-snmpv3-comp-00.txt> This document presents an overview of SNMPv3 compliance with the AAA protocol requirements for network access as stipulated in the 'Network Access AAA Evaluation Criteria' Internet Draft dated April 26, 2000 [1]. SNMPv3 protocol features and capabilities directly support many of the AAA requirements. In addition, the more sophisticated management model (see Section 5, below) now underlying SNMP -- which has evolved from the original model introduced in the late 1980s under the guidance of extensive use in the field -- enables the design, development, and deployment of more sophisticated management applications geared to the overall body of AAA protocol requirements (or sub-sets thereof). "Tunneling Multiplexed Compressed RTP in MPLS", Thomas Theimer, 06/09/2000, <draft-theimer-tcrtp-mpls-00.txt> This document describes a method to improve the bandwidth efficiency of voice transmission over an IP/MPLS network by combining RTP compression, PPP multiplexing and MPLS tunneling. This proposal does not require any additions or modifications to existing protocols, and therefore should be fully interoperable with existing implementations of RTP compression and PPP multiplexing. It only requires specific use of some attributes of MPLS signalling protocols to setup a pair of unidirectional MPLS tunnels providing a bidirectional link for compressed RTP over PPP. "Secure Online Domain Name System (DNS) Dynamic Update ", David Rine, Yeanchen Huang, Xunhua Wang, 06/09/2000, <draft-whr-dnsext-secure-online-update-00.txt> This document proposes an alternate architecture to enable secure online Domain Name System (DNS) dynamic updates. It is intended to enable a DNS zone to provide online dynamic update and at the same time, maintain the zone's security including role separation and intrusion tolerance against insider and outsider attacks. Threshold digital signature is used to implement the proposed architecture. "Management Information Base for QoS Extensions for Bridges based on the Differentiated Services Architecture", Andrew Smith, 06/12/2000, <draft-smith-bridge-qosmib-00.txt> This memo describes a SMIv2 MIB module for a device implementing bridging functions with Quality-of-Service mechanisms similar to those described for the Differentiated Services Architecture [DSARCH] which are described in detail by the Differentiated Services Router Conceptual Model [MODEL]. A MIB module for routers, the Diffserv MIB [DSMIB], has been developed that uses this model. The MIB module defined in this memo is designed to work in conjunction with that module: it defines usage for objects in that module and defines some new objects specific to MAC- layer bridges (a.k.a. Layer-2 switches). Specifically, if defines layer-2 classifier and packet marking functionality. "The Conclusion of the UUCP Mapping Project", Stan Barber, 06/21/2000, <draft-barber-uucp-project-conclusion-03.txt> The UUCP Mapping Project started in the early 1980s as a means to facilitate the exchange of electronic mail among sites using the UUCP store-and-forward transport mechanism. This UUCP software, originally part of the UNIX operating system became available on a variety of operating systems and platforms, from large mainframe to small home PC's. This was done by creating a single database of systems connected to each other via UUCP and then using path building software (such as pathalias) to determine the optimal path from one system to another. Email addresses using this system incorporated the use of the path as part of the address. "Open Base Station Transport (OBAST) Requirements", Phillip Neumiller, Q Xie, Randall Stewart, Peter Lei, John Loghney, 07/11/2000, <draft-neumiller-obast-reqs-01.txt> This document outlines the requirements for a set of open IP based protocols enabling seamless mobility across diverse radio access networks. This document begins by stating some architectural tenets upon which the requirements for the OBAST protocol set are based. Furthermore, what the authors currently believe to be the eventual desirable wireless Internet architecture is described. This architecture is shown to enable a common protocol set that we refer to as open base station transport (OBAST). "The IMXP Presence Service", Marshall Rose, Dave Crocker, Graham Klyne, 10/13/2000, <draft-mrose-imxp-presence-01.txt> This memo describes the IMXP presence service, addressed as the well-known endpoint 'imxp=presence'. The presence service is used to manage presence information for IMXP endpoints. "The IMXP Access Service", Marshall Rose, Dave Crocker, Graham Klyne, 10/13/2000, <draft-mrose-imxp-access-01.txt> This memo describes the IMXP access service, addressed as the well-known endpoint 'imxp=access'. The access service is used to control use of both the IMXP "The IMXP", Marshall Rose, Dave Crocker, Graham Klyne, 10/13/2000, <draft-mrose-imxp-core-01.txt> This memo describes IMXP, an extensible, asynchronous message relaying service for application layer programs. "OpenLDAP Root Service An experimental LDAP referral service", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldap-root-01.txt> The OpenLDAP Project is operating an experimental LDAP [RFC2251] referral service known as the 'OpenLDAP Root Service.' The automated system generates referrals based upon service location information published in DNS [RFC1034] SRV [RFC2782] resource records. This document describes this service. "Framework for the extension of the RADIUS(v2) protocol", Oliver Paridaens, Yves T''''Joens, Ronnie Ekstein, Marc De Vries, 06/13/2000, <draft-tjoens-aaa-radius-00.txt> This document describes a framework that allows for the extension of the RADIUS (v2) [1] protocol according to the following major design goals : o backward compatibility with the installed base of (proxy) RADIUS implementations o offering a transition path to improved procedures and a structural follow up of the RADIUS protocol o meeting the requirements imposed by [2] and allow for a flexible upgrading to future extensions necessary in any AAA related application "Privacy-enhanced Presence Protocol (PePP) ", Shingo Fujimoto, Koji Otani, Hiroyasu Sugano, Akinori Iwakawa, Takashi Ohno, 06/14/2000, <draft-sugano-impp-proposal-pepp-00.txt> This document describes a protocol designed for scalable and secure Instant Messaging and Presence Services. The protocol, Privacy enhanced Presence Protocol (PePP), has been developed for an experimental Presence Service and recently extended to satisfy a variety of requirements for the Internet-wide, interoperable standards. This is a protocol proposal for the IMPP Working Group. "XML DTD for ACAP - ACAP data interchange format", Alexey Melnikov, 06/15/2000, <draft-melnikov-acap-xml-00.txt> This document describes a XML DTD suitable for describing application configuration information or modifications made to configuration information. The file format is typically used to import and export configuration information between ACAP servers, or to describe a set of changes which are to be applied to a ACAP database or a set of ACAP databases. There are a number of situations where a common interchange format is desirable. For example, one might wish to export a copy of the contents of a ACAP server to a file, move that file to a different machine, and import the contents into a second ACAP server. In addition, well-defined interchange format facilitates the development of data import or migration tools. This document describes the interchange format that has the same objective for ACAP as [LDIF] has for LDAP. "Strawman IMPP Protocol Suite", John Stracke, 06/15/2000, <draft-stracke-impp-straw-protocol-00.txt> This document sets forth a strawman IMPP protocol suite. It is not asserted that this protocol suite is suitable for standardization, but it does have lessons to teach us as we develop the IMPP standard. "IN/Internet Interworking in Support of Software Switches ", Igor Faynberg, Hui-Lan Lu, Lev Slutsman, 06/15/2000, <draft-slutsman-softswitch-00.txt> The goal of this document is to identify and propose a new work item for the IETF. To this end, the document defines the term 'software switch' for the purposes of describing a mechanism by which existing PSTN Intelligent Network (IN) service control can be reused in IP networks. IP telephony is one application that can benefit from this mechanism, but there are other potential applications of interest (for example, Unified Messaging) which this draft does not address. Specifically, the document illustrates the role of the software switch in IP telephony. The document then narrows, for practical purposes, the scope of the software switch so as to identify an architecture and mechanism for interworking of Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). The so defined mechanism can be implemented as an application layer protocol, when architectural entities reside in different machines, or inter-process communications protocol, if they reside in the same machine. It is the proposal of this document to define at a minimum a meta-protocol (from which particular implementations can be derived) as a work item in the IETF. Some (but not all) parts of this work have already been discussed in the IETF. To help delineating the proposed work item, this Internet draft explains how it relates to the efforts of the existing IETF working groups that deal with the protocols for PSTN/Internet interworking (IPTEL, MEGACO, PINT, SPIRITS, and SIGTRAN) and ITU-T. "SIP Extensions for Presence", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-presence-00.txt> This document proposes an extension to SIP for subscriptions and notifications of user presence. Traditional SIP clients already make use of the REGISTER method to upload presence state to network servers, in order to enable call establishment. This extension allows that data to be published to subscribers. This is accomplished by defining two new SIP methods - SUBSCRIBE and NOTIFY, and by defining a new logical entity, the presence agent (PA), which handles subscriptions and notifications. "SIP Extensions for Presence Authorization ", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-qauth-00.txt> This document proposes a simple SIP extension that allows presence servers to query presence user agents for authorization for a subscription. "An XML Based Format for Watcher Information ", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-watcherinfo-00.txt> Watchers are defined as entities that request (i.e., subscribe to) presence information about a user. There is fairly complex state associated with this subscription, and this state is dynamic. As a result, it is possible, and indeed useful, to subscribe to the watcher information for a particular subscriber. In order to enable this, a format is needed to describe the state of watchers. This specification describes an XML document format for such state. "An XML Format for Presence Buddy Lists ", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-buddylist-00.txt> This document defines an XML format for a buddy list, which represents a list of other users a particular user would like to subscribe to. When a presence client starts up, it needs to initiate subscriptions to the users on the buddy list. By keeping this list in a standard XML format, the list can be stored locally, or retrieved remotely using HTTP or any other transfer protocol. The great advantage of storing it remotely is that a user can move from machine to machine, fetch their buddy list from a home server, and then subscribe to those users. This provides personal mobility for presence services. "The IMX Architecture Interoperability with America Online's Instant Messaging Services", Edwin Aoki, Andy Wick, 06/16/2000, <draft-aol-imx-00.txt> The ability to exchange instant messages and presence information provides users with a powerful mechanism for communicating in real-time. This document outlines an architecture for interoperability among Instant Messaging Systems which allows disparate systems to exchange messages and presence information while being relatively easy to implement and maintaining a high standard of security and scalability. "SIP Extensions for Instant Messaging", David Oran, Jonathan Rosenberg, C Huitema, Bernard Aboba, David Gurle, Jonathan Lennox, Dean Willis, Robert Sparks, Ben Campbell, H Schulzrinne, 06/16/2000, <draft-rosenberg-impp-im-00.txt> This document describes a SIP extension that supports Instant Messaging (IM). IM is supported in SIP with a single new method. We provide motivations on why SIP is an ideal platform for IM, why IM should be completely separated from presence, and exactly how to perform IM with SIP. "A Lightweight Presence Information Format (LPIDF) ", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-lpidf-00.txt> This document describes a data format, the Lightweight Presence Information Data Format (LPIDF) for conveying presence information. The format is based on RFC822 encoding of presence data. In fact, this encoding is exactly identical to the encoding used by the Session Initiation Protocol (SIP) in its registration messages. This simplifies the process of parsing and processing presence data in clients which use SIP for presence or communications services. LPIDF is one instantiation of an abstract presence data model also described here. "A Data Format for Presence Using XML ", Jonathan Rosenberg, 06/16/2000, <draft-rosenberg-impp-pidf-00.txt> This document describes an XML based data format for conveying presence information. The format is one instantiation of an abstract presence data model also described here. "Definitions of Managed Objects for Frame Relay Circuit Interfaces", Orly Nicklass, Robert Steinberger, 06/16/2000, <draft-steinberger-frsi-00.txt> 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 addition of Frame Relay Circuit Interfaces into the ifTable. This memo does not specify a standard for the Internet community. "Functional Requirements for Priority Services to Support Critical Communications", Harold Folts, Hiroyuki Ohno, 06/16/2000, <draft-folts-ohno-ieps-considerations-00.txt> This draft requests development of detailed specifications for the technical and operational requirements for an Internet-based International Emergency Preparedness Scheme (IEPS) as defined by ITU-T Recommendation E.106. Public telecommunications services have long had such a scheme, to ensure priority handling of telephone communications, such as during natural disasters. As a wide range of communication services increasingly rely upon the family of specifications related to Internet Protocol (IP), IETF work needs to include consideration and provision for supporting IEPS. This work needs to be addressed in two phases concurrently - 1) interface for transition from today's public switched telephone network (PSTN) to IP-based network telephony services, and 2) additional and enhanced capabilities, such as application-specific IEPS services. An Email list for discussion and a Web site for background and documents has been established to assist the work "Support for Multicast over 6to4 Networks", Dave Thaler, 07/21/2000, <draft-thaler-ngtrans-6to4-multicast-01.txt> 6to4 Tunneling allows isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration. This document defines support for IPv6 Multicast over 6to4 networks. "An Architecture and Protocol for Presence and Instant Messaging", Florencio Mazzoldi, Athanassios Diacakis, 06/19/2000, <draft-networkprojects-impp-proposal-01.txt> There is a growing number of people, on the Internet and elsewhere, that are interested in knowing when others are available, in order to communicate with them. A system that provides this information is known as Presence Service. Instant Messaging is the ability to communicate with someone in a rapid, conversational fashion. This usually involves short text messages, but it may be extended in different ways. This draft is a response to the efforts of the Instant Messaging and Presence Protocol (IMPP) group. It describes an architecture and protocols for Presence and Instant Messaging that meet the requirements of [RFC 2779]. This draft covers the basic functional modules needed to provide Presence and Instant Messaging services. It also provides the semantics for the interactions among this set of functional modules, along with the data format of the information exchanged. "Jabber", Jeremie Miller, 06/16/2000, <draft-miller-impp-jabber-00.txt> This memo provides a comprehensive description of the Jabber architecture, design principles, and protocol. "IP based Signaling Needs in Radio Access Networks", John Loughney, 06/16/2000, <draft-loughney-sigtran-ip-ran-00.txt> In developing IP-based Radio Access Networks, there are needs for reliable signaling. It is assumed that SCTP would provide the transport bearer for any signaling. This draft presents a general signaling architecture for IP-based Radio Access Networks. "LSP hierarchy with MPLS TE", Y Rekhter, Kireeti Kompella, 06/19/2000, <draft-kompella-lsp-hierarchy-00.txt> To improve scalability of MPLS TE it may be useful to aggregate TE LSPs. The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a link into ISIS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. "GSM SIM Authentication for Mobile IP", Henry Haverinen, 06/19/2000, <draft-haverinen-mobileip-gsmsim-00.txt> This document specifies a mechanism for generating Mobile IP authentication keys using the GSM Subscriber Identity Module (SIM). The mechanism uses new subtypes of the generalized key distribution extensions [1] for Mobile IP Registration Request and Registration Reply. After the authentication keys have been generated, the default Mobile IP authentication with these keys can be used (MD5 in prefix + suffix mode). The keys can be used for several subsequent registrations. However, there is a lifetime for these keys and before the lifetime expires, new keys can be generated with the same procedure. "Service Location Protocol Extension Assignments", Erik Guttman, 06/20/2000, <draft-guttman-svrloc-ext-ids-00.txt> SLPv2 [1] allows protocol extensions to be defined. Each must be assigned an extension ID. This document lists all extension IDs which have been assigned and describes the process by which further extension IDs may be acquired. "Mobile IP Regional Paging", Henry Haverinen, Jare Malinen, 06/20/2000, <draft-haverinen-mobileip-reg-paging-00.txt> This document specifies Mobile IP Regional Paging (MIRP), a small and link-layer independent extension to Mobile IP [2] with regional registrations [3], to support power-constrained operation in the mobile nodes and to reduce routing state information in the visited domain. The extension allows a mobile node to enter a power saving idle mode during which its location is known with the coarse accuracy defined by a paging area. Downlink routes to idle mobile nodes terminate in a paging foreign agent, which re-establishes them on demand by means of paging. This does not require snooping of data packets but is a natural extension to network-level routing. Optionally, the mobile node and the visited domain can agree on communication time slots used for Agent Advertisements and paging, to restrict link interface power-on time in the mobile node. "Dynamic Home Addressing in Mobile IP using Transient Tunnels", K. Varadhan, L. Salgarelli, Thomas La Porta, R. Ramjee, S. Thuel, 06/20/2000, <draft-thuel-mobileip-tt-00.txt> Dynamic home addressing has lately become a popular and viable approach for configuring mobile IP hosts. This draft introduces a method for these hosts to dynamically acquire a home address through DHCP when powering up in a foreign network, referred to as the Transient Tunneling (TT) procedure. Our procedure solves the problem that mobile hosts cannot rely on conventional broadcasting procedures to properly discover an addressing server in their home network. While leveraging the growing DHCP code-base, our procedure requires no changes to protocol standards and only minor changes to server implementations. In addition, its impact on host power-up latency is acceptable in conventional wide-area networks scenarios. Alternative solutions are discussed along with other issues related to dynamic addressing on mobile hosts such as wireless bandwidth usage. "Integration of Mobile IP and MPLS", Ren Zhong, 06/27/2000, <draft-zhong-mobile-ip-mpls-01.txt> Multiprotocol Label Switching (MPLS) combines the efficiency and simplicity of IP routing together with the high-speed switching of ATM. Mobile IP is a protocol that allows mobile users to maintain continuous IP network connectivity. In this document, we describe a scheme to integrate both the Mobile IP and MPLS protocols. The integration of both these protocols improves the scalability of the Mobile IP data forwarding process by leveraging on the features of MPLS which are fast switching, small state maintenance and high scalability. In addition, we have removed the need for IP-in-IP tunneling from Home Agent (HA) to Foreign Agent (FA) under this scheme. This document defines the signaling and control mechanisms required to integrate MPLS and Mobile IP. "Using XML to Exchange SMI Definitions", J. Schoenwaelder, Frank Strauss, 06/21/2000, <draft-irtf-nmrg-smi-xml-00.txt> This memo describes how the Extensible Markup Language (XML) can be used to exchange SMIv1, SMIv2 and SMIng definitions between XML enabled applications. "IEEE 802.1X RADIUS Usage Guidelines", Andrew Smith, Bernard Aboba, A. Young, Glen Zorn, Paul Congdon, Thomas Moore, Ashwin Palekar, Dave Halasz, John Roese, Andrea Li, 10/20/2000, <draft-congdon-radius-8021x-04.txt> IEEE 802.1X enables authenticated access to IEEE 802 media, including Ethernet, Token Ring, and 802.11 wireless LANs. Although RADIUS support is optional within IEEE 802.1X, it is expected that most IEEE 802.1X Authenticators will function as RADIUS clients. "Itinerant Internet Protocol", H Soliman, Chern Yap, Matthias Kraner, 08/14/2000, <draft-cnyap-iip-01.txt> This document specifies a protocol that allows any IP node to communicate with other IP nodes in the mobile environment without any fundamental changes to TCP/IP. Any mobile aware nodes are able to communicate with one another with standard IP routing. Mobile awareness is achieved by means of address updates through a query mechanism. Backward compatibility capability is supported via the means of one or more anchoring points that are put in place. "Multicast Security Policy", H. Harney, Peter Dinsmore, Patrick McDaniel, Atul Prakash, 06/23/2000, <draft-irtf-smug-mcast-policy-00.txt> Security is increasingly becoming a concern in applications built on multi-party communication. Centrally, protection of the application content from non-authorized or malicious parties is the fundamental goal of any security policy specification. This draft seeks to illuminate the design space of secure multicast communication policy. The security requirements of existing application policies are intended to be addressable by these policy dimensions. It is from an understanding of policy design space that the mechanisms for policy specification and enforcement can be derived. "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", Vince Fuller, Alvaro Retana, Danny McPherson, Russ White, 10/10/2000, <draft-retana-31bits-03.txt> With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. "RVP: A Presence and Instant Messaging Protocol", Lee-Tah Wong, Martin Calsyn, Sonu Aggarwal, Lisa Lippert, Robert Osborne, Peter Beebee, 06/23/2000, <draft-osborne-rvp-00.txt> Instant Messaging has recently emerged as a new and highly popular medium of communication over 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 ‘real time’. These are all special cases of the more general problem of Internet-wide notification. The RVP protocol, 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. RVP is related to the work done by the IETF Instant Messaging and Presence Protocol Working group (IMPP). This protocol is not intended to compete with the IMPP effort, but to inform the design process with an existing implementation. This document reflects the actual Microsoft Exchange 2000 implementation. "SCTP as a Transport for SIP", Jonathan Rosenberg, H. Schulzrinne, 06/23/2000, <draft-rosenberg-sip-sctp-00.txt> This document specifies a mechanism for usage of SCTP (the Stream Control Transmisson Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. "Mobile Virtual Private Network", Erica Sanchez, Vesselin Tzvetkov, 10/16/2000, <draft-tzvetkov-mvpn-01.txt,.ps> Mobile networks present several challenges and problems that current security mechanisms did not take in consideration in their specification, even though they continue to be a very good solutions for fixed networks, they can also undermine the performance of mobile environments. "TCP Performance over ADSL ", Shivkumar Kalyanaraman, Kalyan Kidambi, D Shekhar, 06/23/2000, <draft-shekhar-tcp-adsl-pilc-00.txt> This paper studies the performance of TCP over an ADSL (asymmetric) channel. We propose a simple new model, called the AMP model which in conjunction with the knowledge of TCP dynamics helps explain the effects of asymmetry and the limitations of proposed solutions. We propose implementation improvements to ack-regulation schemes proposed in earlier literature and perform an extensive simulation study of the effects of several parameter dimensions. This leads to some non-intuitive observations and understanding of performance limitations which can be captured in the AMP model. "Extensions to RSVP-TE for MPLS Path Protection", Srinivas Makam, Ken Owens, Bora Akyol, Changcheng Huang, 06/26/2000, <draft-chang-mpls-rsvpte-path-protection-ext-00.txt> To deliver reliable service, multi-protocol label switching (MPLS) requires a set of procedures to enable protection of the traffic carried on label switched paths (LSPs). Thus existing signaling mechanisms must be extended appropriately to support such functionality. Recently, RSVP-TE [1] has introduced extensions to RSVP to support the establishment of LSP tunnels. This draft extends RSVP-TE to support path protection [2] in MPLS. Specifically, we provide signaling support for establishing working and protection LSPs and for propagating fault notification upon LSP failure. "Preparation of text in RFC style", Max Wildgrube, 10/17/2000, <draft-wildgrube-preprfc-02.txt> This document contains a C program to convert a raw text (containing format commands similar to nroff) into a text which is in accordance with the demands of the RFC editors. You can download the newest program source, template and docu from following web site: www.pinpi.com/prep "MPLS Label Stack Encapsulation in IP", Rick Wilder, Y. Katsube, Tom Worster, Andrew Malis, 08/08/2000, <draft-worster-mpls-in-ip-02.txt> Several useful applications of MPLS tunnels based on LSPs with second level labels between non adjacent LSRs have been identified: IP-VPNs and VoIP over MPLS are just two examples. This tunnelling technique can easily be extended to non-MPLS core networks. This Internet-Draft explains the motivation for encapsulating MPLS messages in IP and provides the protocol specification of the encapsulation. "SDP media alignment in SIP", Goran Eriksson, Gonzalo Camarillo, Jan Holler, 06/27/2000, <draft-camarillo-sip-sdp-00.txt> This document defines an SDP media attribute. This attribute is intended to be used in conjunction with SIP in order to align different media streams belonging to a session. The use of this attribute allows sending media from a single media stream, encoded in different formats during the session, to different ports and host interfaces. "Source Only Multicast", Heinrich Hummel, 06/27/2000, <draft-hummel-pim-so-00.txt> This draft addresses several aspects of multicast services like IP- based TV but also like n-party conferences. It breaks with traditional concepts: An IP-based TV-broadcast's delivery tree shall be identified by the source address S and a Multicast-ID provided by S. The same shall apply to each from n well correlated point-to(n-1)point delivery trees of a small n-party conference. Consequently, a TV-host may send out more than one program and any user-host may participate in more than one conference. Mapping to a globally unique multicast group address G is not needed, would be complex, and does not work. QoS/Policy-Routing, the degree of state (Layer-3, Layer-3 plus MPLS- label, or no state), and several more aspects need to be respected HOMOGENEOUSLY all over the entire delivery tree. This cannot be provided by reverse path setup while depending on each receiver's guesses. Therefore, the tree (i.e. an initial tree as well as additional branches at a later time) must be established in downstream direction. No RP- and no BSR-routers are required. "Secure Internet Live Conferencing (SILC), Protocol Specification", Pekka Riikonen, 10/06/2000, <draft-riikonen-silc-spec-01.txt> This memo describes a Secure Internet Live Conferencing (SILC) protocol which provides secure conferencing services over insecure network channel. SILC is IRC [IRC] like protocol, however, it is not equivalent to IRC and does not support IRC. Strong cryptographic methods are used to protect SILC packets inside SILC network. Two other Internet Drafts relates very closely to this memo; SILC Packet Protocol [SILC2] and SILC Key Exchange and Authentication Protocols [SILC3]. "SILC Packet Protocol", Pekka Riikonen, 10/06/2000, <draft-riikonen-silc-pp-01.txt> This memo describes a Packet Protocol used in the Secure Internet Live Conferencing (SILC) protocol specified in the Secure Internet Live Conferencing, Protocol Specification Internet Draft [SILC1]. This protocol describes the packet types and packet payloads which defines the contents of the packets. The protocol provides secure binary packet protocol that assures that the contents of the packets are secured and authenticated. "SILC Key Exchange and Authentication Protocols", Pekka Riikonen, 10/06/2000, <draft-riikonen-silc-ke-auth-01.txt> This memo describes two protocols used in the Secure Internet Live Conferencing (SILC) protocol specified in the Secure Internet Live Conferencing, Protocol Specification internet-draft [SILC1]. The SILC Key Exchange (SKE) protocol provides secure key exchange between two parties resulting into shared secret key material. The protocol is based on Diffie Hellman key exchange algorithm and its functionality is derived from several key exchange protocols. SKE uses best parts of the SSH2 Key Exchange protocol, Station-To-Station (STS) protocol and the OAKLEY Key Determination protocol [OAKLEY]. The SILC Connection Authentication protocol provides user level authentication used when creating connections in SILC network. The protocol is transparent to the authentication data which means that it can be used to authenticate the user with, for example, passphrase (pre-shared- secret) or public key (and certificate). "Internet Security Association and Key Management Protocol (ISAKMP) Keep-Alive Message exchange", Vlado Zafirov, 07/06/2000, <draft-vlado-ipsec-keep-alive-01.txt> This memo describes a protocol utilizing ISAKMP protocol necessary for checking status of specific Ipsec tunnel. "Hierarchical MIPv6 mobility management", Claude Castelluccia, Ludovic Bellier, K Malki, Hesham Soliman, Ludovic Bellier, 09/13/2000, <draft-soliman-mobileip-hmipv6-01.txt> This draft introduces some extensions for MIPv6 and neighbour discovery to allow for the introduction of a hierarchical MIPv6 mobility management model. The proposed hierarchical mobility management for MIPv6 will reduce the amount of signalling to CNs and the HA and may also improve the performance of MIPv6 in terms of handoff speed. Moreover, HMIPv6 is well-suited to implement access control and handoffs between different access technologies. "Link Bundling in Optical Networks", B. Rajagopalan, Debanjan Saha, 10/02/2000, <draft-rs-optical-bundling-01.txt> In an optical mesh network, two adjacent optical cross connects (OXCs) may have multiple, parallel, discrete bandwidth links connecting them [1]. When a link state routing protocol is used, these links may all be bundled together and advertised in a single link state advertisement (LSA). This draft describes the requirements, and proposes a method for bundling optical links. The proposed method aims to reduce the number of routing adjacencies between neighboring nodes, and works in conjunction with a link management protocol (e.g., LMP [2]). The discussion in this draft is related specifically to OSPF. "Mapping the BXXP Framework onto TCP", Marshall Rose, 07/13/2000, <draft-mrose-bxxp-tcpmapping-01.txt> This memo describes how a BXXP session is mapped onto a single TCP connection. "The Blocks eXtensible eXchange Protocol Framework", Marshall Rose, 07/13/2000, <draft-mrose-bxxp-framework-01.txt> This memo describes a generic application protocol framework for connection-oriented, asynchronous request/response interactions. The framework permits multiplexing of independent request/response streams within the context of a single application user-identity, supporting both textual and binary messages. "On the Design of Application Protocols", Marshall Rose, 07/05/2000, <draft-mrose-bxxp-design-00.txt> This memo describes the design principles for the Blocks eXtensible eXchange Protocol (BXXP). BXXP is a generic application protocol framework for connection-oriented, asynchronous request/response interactions. The framework permits multiplexing of independent request/response streams over a single transport connection, supporting both textual and binary messages. "RTP Payload Format for Distributed Speech Recognition", Jeff Meunier, 07/06/2000, <draft-meunier-avt-rtp-dsr-00.txt> This document specifies an RTP payload format for encapsulating ETSI Standard ES 201 108 Distributed Speech Recognition (DSR) streams in the Real-Time Transport Protocol. "Explicit Route Multicast (ERM) ", Dino Farinacci, M. Shand, A. Tweedly, Joel Bion, 07/06/2000, <draft-shand-erm-00.txt> Conventional multicast builds a tree structure from the source of a multicast stream to the destinations of that stream. Multicast packets are forwarded from the sources down the tree by each intervening router. Each router contains state information to determine the next hop forwarding destination(s) for a packet. Where there are a large number of groups, this gives rise to a scaling problem. The amount of state to be stored in the routers becomes impossibly large. It is attractive to consider the use of multicast to provide applications such as n-way voice and video conferencing, which would require a very large number (perhaps millions) of relatively small (between 3 and 10 members) multicast groups. "SIP and SOAP", Neil Deason, 07/06/2000, <draft-deason-sip-soap-00.txt> This document describes an extension to the Session Initiation Protocol (SIP) [1] . The purpose of this extension is to provide an extremely generic and extensible framework through which SIP nodes can request additional services from remote nodes. Examples of such nodes include SIP Network Servers, SIP User Agents, SIP/PSTN Gateways, SIP/H.323 Gateways and SIP Enabled Application Service Brokers. It also a candidate for providing a remote procedure call mechanism for Call Processing Language (CPL) scripts [2] . This proposal is based upon a new SIP method, called SERVICE. The SERVICE method can carry a Simple Object Access Protocol (SOAP) [3] message as it's payload. SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. SOAP defines a framework for encoding request and response messages in XML. Typically SOAP uses HTTP as a transport protocol but this proposal enables SIP to be used instead. "Network Engineering Extensions (NEXT) for OSPFv3", Spencer Giacalone, 08/21/2000, <draft-giacalone-te-optical-next-01.txt> This memo defines extensions to OSPFv3 [2] to provide support for Network Engineering. This set of extensions is termed Network Engineering eXTensions for OSPFv3, or NEXT. The term network engineering was chosen to impart NEXT's wide scope of functionality. NEXT is intended to provide holistic and extremely rich state information to OSPFv3 routers. Using this information, various advanced topological and administrative decisions can be made. Please send comments to ospf@discuss.microsoft.com. "Alternative Certificate Formats for PKIX-CMP", Carlisle Adams, 07/06/2000, <draft-adams-cmpaltcert-00.txt> 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. "Source Specific Multicast", Heinrich Hummel, 07/06/2000, <draft-hummel-ssm-00.txt> This draft addresses several aspects of multicast services like IP- based TV but also like n-party conferences. It breaks with traditional concepts: An IP-based TV-broadcast's delivery tree shall be identified by the source address S and a Multicast-ID provided by S. The same shall apply to each from n well correlated point-to(n-1)point delivery trees of a small n-party conference. Consequently, a TV-host may send out more than one program and any user-host may participate in more than one conference. Mapping to a globally unique multicast group address G is not needed, would be complex, and does not work. QoS/Policy-Routing, the degree of state (Layer-3, Layer-3 plus MPLS- label, or no state), and several more aspects need to be respected HOMOGENEOUSLY all over the entire delivery tree. This cannot be provided by reverse path setup while depending on each receiver's guesses. Therefore, the tree (i.e. an initial tree as well as additional branches at a later time) must be established in downstream direction. No RP- and no BSR-routers are required. "LDAPv3: All Operational Attributes", Kurt Zeilenga, 10/19/2000, <draft-zeilenga-ldapv3bis-opattrs-01.txt> X.500 [X.500] provides a mechanism for clients to request all operational attributes be returned with entries provided in response to a search operation. This mechanism is often used by clients to discover which operatinal attributes are present in an entry. LDAP [RFC2251] does not provide a similar mechanism to clients. "Use of RSVP for Differentiated Services Signaling and Admission Control", C Radhakrishna, 07/06/2000, <draft-rk-diffserv-rsvp-sig-00.txt> This document describes the use of RSVP for admission control and signaling in differentiated services networks. A small subset of RSVP message objects are used to provide end-to-end dynamic QoS control in differentiated services networks. "SIP/IN Interworking", Doris Lebovits, 07/06/2000, <draft-lebovits-sip-in-00.txt> The goal of this document is to identify and propose a new work item for the IETF. This document describes the PSTN Intelligent Network (IN) Architecture support of Session Initiation Protocol (SIP) networks. The concept of the 'Soft-SSF' is introduced which acts as an overlay between the IP telephony call control and the Intelligent Network layer provided by the IN Service Switching Function (SSF) and the IN Service Control Function (SCF). This 'Soft-SSF' provides the necessary mapping between the SIP protocol state machine and the IN Basic Call State Model (BCSM). Also introduced is the Call Manager Function (CMF) which acts as a Mediation Node. The CMF entity is responsible for passing service related information to and from IN service layer, namely the SCF, and managing the service control relationship. As such, the CMF may contain a SSF-like functionality or subset thereof, to model the pre and post conditions that are required to interact with an SCF. The document specifically deals with the proposed standardized interfaces between the functional entities identified in the IN Network with associated functional entities represented in the SIP network. A mapping of parameters of the SIP protocol to the Intelligent Network Application Part Protocol(INAP) may be required for the support of the SIP Proxy Server call control protocol, states and events. Thereby enabling the Mediation Node (CMF) to model a SIP Proxy server. It is the proposal of this document to define the Mediation Node(CMF)to Soft SSF interface as a work item in the IETF as it is presently not a subject for standardization. "V5.2 extensions to the IUA protocol", Srinivasa Rao, Neeraj Khanchandani, Fahir Ergincan, 07/06/2000, <draft-rao-sigtran-v5ua-00.txt> This document defines a mechanism for backhauling of V5.2 messages over IP by extending the ISDN User Adaptation Layer Protocol (<draft-ietf-sigtran-iua-03.txt>). The document aims to become an Appendix to IUA and to be the base for a V5.2 implementation. "MPLS Label Stack Encapsulation in GRE ", Y Rekhter, Dan Tappan, Eric Rosen, 07/06/2000, <draft-rekhter-mpls-over-gre-00.txt> In certain cases it may be useful to carry MPLS packets through an IP tunnel. This document describes how to do that using existing standards. "TLS-based security model for SNMP", Moshe Rozenblit, 07/06/2000, <draft-rozenblit-snmpv3-tls-secmodel-00.txt> This memo defines a security model based on Transport Layer Security (TLS) [RFC 2246] for the Simple Network Management Protocol (SNMP). The security model can be used with any version of SNMP. When SNMPv3 [RFC 2571] is used this security model can be used with View-based Access Control Model (VACM) [RFC 2575]. This security model can be used only if TCP is used for transport. "General Considerations for Bandwidth Reservation in Protection", Li Mo, 07/06/2000, <draft-mo-mpls-protection-00.txt> Protection issues for MPLS LSP have been discussed in recent IETF meetings. Various drafts have different proposals on establishing the working and protection LSP ([1]-[5]). But how to reserve bandwidth for the protection LSP has not be discussed. If the bandwidth for the protection LSP is reserved in a similar fashion as that of the working LSP, the bandwidth utilization in the network would be very poor. In this draft, an algorithm for reserve bandwidth for protection LSP is presented which enables very efficient bandwidth reservation for single fault protection. "LDAPv3: Grouping of Related Operations", Kurt Zeilenga, 10/19/2000, <draft-zeilenga-ldap-grouping-01.txt> This document provides a general mechanism for grouping related LDAP operations. Grouping of operations may be used to support replication, proxies, and higher level operations such as transactions. This document describes a set of LDAP [RFC2251] extended operations and other protocol and schema elements to support grouping of related operations. Uses of this grouping mechanism will be detailed in separate documents (e.g. LDAP Transactions [LDAPT]). "Named References in LDAP Directories", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldap-namedref-00.txt> This document defines schema and protocol elements for representing and manipulating generic knowledge information in LDAP [RFC2251] directories. An attribute type 'ref' is used to store URIs [RFC1738] which may refer to LDAP and non-LDAP services. An object class 'referral' is used to construct entries in an LDAP directory which references to other directories or services. An control, ManageDsaIT, is defined to allow clients to manipulate referral objects as normal entries. The document describes procedures directory servers should follow when supporting these elements. "LDAPv3bis Suggestions: The LDAP URL Format ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2255-00.txt> LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory. "LDAPv3bis Suggestions: The String Representation of LDAP Search Filters ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2254-00.txt> The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing LDAP search filters. This document replaces RFC 1960, extending the string LDAP filter definition to include support for LDAP version 3 extended match filters, and including support for representing the full range of possible LDAP search filters. "LDAPv3bis Suggestions: UTF-8 String Representation of Distinguished Names ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2253-00.txt> The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name. "LDAPv3bis Suggestions: Summary of the X.500(96) User Schema for use with LDAPv3 ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2256-00.txt> This document provides an overview of the attribute types and object classes defined by the ISO and ITU-T committees in the X.500 documents, in particular those intended for use by directory clients. This is the most widely used schema for LDAP/X.500 directories, and many other schema definitions for white pages objects use it as a basis. This document does not cover attributes used for the administration of X.500 directory servers, nor does it include attributes defined by other ISO/ITU-T documents. "LDAPv3bis Suggestions: Authentication Methods for LDAP ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2829-00.txt> LDAP version 3 is a powerful access protocol for directories. It offers means of searching, fetching and manipulating directory content, and ways to access a rich set of security functions. In order to function for the best of the Internet, it is vital that these security functions be interoperable; therefore there has to be a minimum subset of security functions that is common to all implementations that claim LDAPv3 conformance. "COPS Usage for ODSI", Z. Zhang, Leah Zhang, James Fu, Nasir Ghani, 07/07/2000, <draft-ghani-odsi-cops-00.txt> 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. "Strong Password-Based Authentication Using Pseudorandom Moduli", R. Perlman, Charlie Kaufman, 07/07/2000, <draft-perlman-strong-pass-00.txt> This document specifies a new password-based protocol that can be used as the basis of mutual authentication, or downloading of a private key. The only thing the client needs to know is the user's password. The protocol is constructed such that an eavesdropper cannot do off-line password-guessing attacks. Someone stealing the server's database cannot directly impersonate the user, although they can do an off-line password-guessing attack on the contents. The protocol presented in this paper is similar in functionality, higher in performance at the server, but lower in performance at the client, to the extended EKE and SPEKE, and SRP schemes. Additional properties of this scheme are salt, no password-equivalent stored at the server, and prevention of servers on which the user has the same password from impersonating each other to the user. This document gives an overview of the approach, but not wire-formats, which are premature at this stage. The purpose of this document is to advertise this new scheme to various groups that might be interested (CAT, for a GSS-API mechanism, LDAP, for download of a private key). "A Simple Text Format for the Spatial Location Protocol (SLoP)", Rohan Mahy, 07/07/2000, <draft-mahy-spatial-simple-coord-00.txt> The Spatial Working Group is creating a Spatial Location Protocol (SLoP) [2] for requesting the spatial location of a target user or device. SLoP is designed to carry other formats that contain the spatial location. In many cases either the SLoP client and/or server could be a small mobile device with limited processing, memory, storage, and battery life. This proposal is a simple, text- based format to carry latitude, longitude, altitude, time, and accuracy. "Multicast Data Security Transformations: Requirements, Considerations, and Proposed Design", P. Cheng, Ran Canetti, Pankaj Rohatgi, 07/07/2000, <draft-irtf-smug-data-transforms-00.txt> In the framework document <draft-irtf-smug-framework-00.txt>, 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. "The Internet and ISPs ", Masataka Ohta, 07/07/2000, <draft-ohta-isps-00.txt> This memo gives definitions on the Internet and ISPs (Internet Service Providers). "Triggering and advertising lightpaths in an IP over optical network", Olivier Duroyon, Rudy Hoebeke, Hans De Neve, 07/07/2000, <draft-duroyon-te-ip-optical-00.txt> The objective of this draft is to propose an IP service model where lightpaths are dynamically triggered by the IP layer and subsequently advertised for IP routing. The network model assumes that several IP service domains, some of which represent different administrative entities, share the same optical backbone and focuses therefore primarily on an overlay model. Therefore, this draft intends to complement the IP over optical framework with respect to the overlay model. "Remote Monitoring MIB Extensions for Virtual Data Sources ", Andy Bierman, 07/07/2000, <draft-bierman-rmonmib-vds-mib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for defining virtual data monitoring sources for use with existing RMON MIBs. "Requiring DNS IN-ADDR Mapping", D. Senie, 07/07/2000, <draft-senie-inaddr-required-00.txt> The Domain Name Service has provision for providing mapping of IP addresses to host names. It is common practice to ensure both name to address, and address to name mappings are provided for networks. This practice, while documented, has never been documented as a requirement placed upon those who control address blocks. This document fills this gap. "LDAPv3bis Suggestions: Extension for Transport Layer Security ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2830-00.txt> This Internet Draft suggests a number of updates to the 'Lightweight Directory Access Protocol: Extension for Transport Layer Security' [RFC 2830]. This document is not intended to be published as an RFC but used to identify LDAPv3bis work items. "LDAPv3bis Suggestions: Lightweight Directory Access Protocol (v3) ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2251-00.txt> The protocol described in this document is designed to provide access to directories supporting the X.500 models, while not incurring the resource requirements of the X.500 Directory Access Protocol (DAP). This protocol is specifically targeted at management applications and browser applications that provide read/write interactive access to directories. When used with a directory supporting the X.500 protocols, it is intended to be a complement to the X.500 DAP. "LDAPv3bis Suggestions: Attribute Syntax Definitions ", Kurt Zeilenga, 07/07/2000, <draft-zeilenga-ldapv3bis-rfc2252-00.txt> The Lightweight Directory Access Protocol (LDAP) [1] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines a set of syntaxes for LDAPv3, and the rules by which attribute values of these syntaxes are represented as octet strings for transmission in the LDAP protocol. The syntaxes defined in this document are referenced by this and other documents that define attribute types. This document also defines the set of attribute types which LDAP servers should support. "An RTP Payload Format for Generic FEC with Uneven Level Protection", Adam Li, Fang Liu, John Villasenor, Jeong Park, Dong Park, 07/07/2000, <draft-li-ulp-00.txt> This document specifies a payload format for generic forward error correction to achieve uneven level protection (ULP) of media encapsulated in RTP. It is an extension to the forward error correction scheme specified in RFC 2733 [1], and it is also based on the exclusive-or (parity) operation. The payload format allows end systems to transmit using arbitrary protection length and levels, in additional to using arbitrary block lengths. It also allows for the both complete recovery of the critical payload and RTP header fields, and partial recovery when complete recovery is not possible due to the packet lost situation. This scheme is backward compatible with non-FEC capable hosts, and hosts that are only capable of FEC schemes specified in RFC2733 [1], so that receivers which do not wish to implement ULP forward error correction can just ignore the extensions. "MGCP User Interface Package", Marc Petit-Huguenin, Andy Huckridge, 07/07/2000, <draft-petithuguenin-mgcp-ui-pkg-00.txt> This document proposes a new MGCP[2] package to control the user interface of a feature phone. "A Framework for the delivery of MPEG-4 over IP-based Protocols", D. Singer, Peter Westerink, 07/07/2000, <draft-singer-mpeg4-ip-00.txt> This document forms an umbrella specification for the carriage and operation of MPEG-4 multimedia sessions over IP-based protocols, including RTP, RTSP, and HTTP, among others. It also serves to document the standard MIME types associated with MPEG-4. "MIME Type Registration for Motion JPEG 2000 ", D. Singer, 07/07/2000, <draft-singer-mjp2-00.txt> This document serves to register and document the standard MIME types associated with Motion JPEG 2000 files.. "Web Cache Coordination Protocol V1.0", David Forster, Martin Cieslak, 07/10/2000, <draft-forster-wrec-wccp-v1-00.txt> This draft documents the Web Cache Coordination Protocol (WCCP) V1.0. This protocol is used (a) to associate a single router with one or more web-caches for the purposes of transparent redirection of HTTP traffic, and (b) to allow one of the web-caches to dictate how the router distributes transparently-redirected traffic across the associated web-caches. This draft describes the interactions between a router and one or more web-caches. It does not describe the interactions between a group of associated web-caches or those between a web-cache and a web-server. "A proposal for the use of ECN bits with UDP flows", F. Dupont, Laurent Toutain, 07/10/2000, <draft-medina-ecn-udp-00.txt> This document contains a proposal for the use of ECN bits with UDP packets. For the moment, the presence of ECN bits in the IP header of UDP streams is useless. These bits could be used to identify IP/UDP/RTP encapsulated data at routers prior to header compression and other specific operations. "iSCSI (Internet SCSI) Requirements", Randy Haagens, 07/10/2000, <draft-haagens-ips-iscsireqs-00.txt> This document explains the motivation behind an efficient transport of SCSI commands on top of TCP/IP and describes scenarios where such a transport will be used. The document also enumerates and discusses requirements for supporting SCSI on top of IP. "Requirements for Demand-Driven Surrogate Origin Servers ", Mark Nottingham, 07/10/2000, <draft-nottingham-surrogates-00.txt> This document states requirements for demand-driven surrogate origin servers, also known as reverse proxies and Web accelerators. "Test Specification for MTP3 User Adaptation", Sunil Mahajan, Sachin Jindal, 07/10/2000, <draft-mahajan-test-spec-m3ua-00.txt> This document presents the test specification for M3UA (MTP3 User Adaptation) prototcol (ver 02), which can be used to test M3UA implementations for conformance to the protocol definition. The list of test is exhaustive and covers almost all the categories of test. This draft can also be used in conjunction with M3UA specification by implementor of protocol as implementors guide, as the pictorial representation of various scenarios help easy understanding of the protocol. Next revision of the draft will cover the additions done to the protocol revision M3UA-03 and any subsequent RFC published by IETF. "Service Principles when Public Circuit-Switched International Telecommunication Networks Interwork with IP-based Networks", Steven Lind, 07/10/2000, <draft-lind-itut-e370-00.txt> This document describes the current thinking of the collaborators of ITU-T Question 10/2, 'Management and development of PSTN-based telecommunication services,' about service principles when public circuit switched international telecommunication networks interwork with IP-based networks. This document contains most of the text (there has been some rearrangement of the text) from draft new Recommendation E.370 [1], starting from section 3 of this Internet Draft, which was determined to be stable at the March 2000 meeting of Study Group 2. It may be approved by the members of the ITU, subject to written comments received from those members, at a meeting of the Study Group (or its successor) in early 2001 (provisionally 23-26 January 2001). It is hoped that this document will further the collaborative efforts between Study Group 2 and the various working groups of the IETF. "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (MTP)", Kazuaki Tsuchiya, Hidemitsu Higuchi, Sunao Sawada, Shinji Nozaki, 07/10/2000, <draft-tsuchiya-mtp-00.txt> In the stage of the transition from IPv4 to IPv6 it is necessary that IPv4 nodes and IPv6 nodes can communicate directly. This memo proposes a mechanism which enables such direct communication for multicast, in addition to that for unicast defined in [SIIT] and [NAT-PT]. "Policy Configuration with SNMP", Jonathan Saperia, 07/10/2000, <draft-saperia-policysnmp-00.txt> This paper is an introduction to terms and principles of policy-based network configuration management that is based on work in the IETF. A generic model for the realization of policy-based network configuration management is presented based on these terms. The last portion, and focus of the paper, examines the current work of the SNMP Configuration Working Group in the IETF and maps that work to the previously defined terms and model. "RACE Protocol Draft Version 1.3 ", Charles Kilkenny, 07/10/2000, <draft-gfn-race-00.txt> This document describes the Rapid Application Communication and Emulation (RACE) Protocol. RACE provides a general framework for inter-application communication, messaging, and interoperability. "Possible abuse against IPv6 transition technologies", Jun-ichiro Hagino, 07/12/2000, <draft-itojun-ipv6-transition-abuse-01.txt> The document talks about possible abuse of IPv6 transition technologies, which may lead to denial-of-service (DoS) attacks and other problems. IPv6 transition technologies, namely IPv6 over IPv4 tunnelling specifications and some others, have room for abuse by malicious parties. Detailed descriptions and possible workarounds are supplied. "IPv4 Option for Somecast ", S. Jamin, David Helder, 07/11/2000, <draft-dhelder-somecast-00.txt> Somecast is a multi-point delivery technology that allows a packet to be sent to a set of destinations. Somecast delivery means that the network delivers one copy of a packet to each destination listed in the packet. Somecast can be used in small multi-user sessions, such as multimedia conferences and multiplayer games, or used with endhost multicast for larger sessions. This document describes a possible implementation of somecast in IPv4. Somecast is implemented by using an IPv4 header option that includes a list of up to 9 additional destination addresses. This document also describes how somecast can be incrementally deployed. "The Use of ENUM Services by Signaling Transport Protocols", John Loughney, 07/17/2000, <draft-loughney-enum-sigtran-01.txt> This draft proposes to use ENUM resolution to support signaling transport. This draft outlines the resolution E.164 numbers by NAPTR in DNS to a service location. Considerations need to be made for scalability, reliability and performance. "Extended IP Versions ", D Eastlake, 07/11/2000, <draft-eastlake-ext-ip-ver-00.txt> The current four bit Internet Protocol (IP) Version field provides for such a limited number of versions that very tight control must be exercised on their allocation as documented in [RFC 2780]. Provisions are specified whereby one value of that field is extended to provide ample easily allocated values. "Target Naming Scheme", Haitao Tang, 07/11/2000, <draft-tang-spatial-target-00.txt> This document proposes a framework and mechanism for target naming. Target naming is needed for SLoP speakers (SLoP server or client) to address targets via the SLoP protocol. "Extensions to the 'tel' and 'fax' URLs to Support Number Portability", James Yu, 07/11/2000, <draft-yu-tel-url-00.txt> Number portability (NP) allows the telephone subscribers to keep their telephone numbers when they change service provider, move to a new location, or change the subscribed services. The NP implementations in many countries presently support service provider portability for geographic numbers and non-geographical numbers. It has been identified that NP has impacts on several works-in-progress at the IETF. One of the impacts is to carry the NP related information in the SIP INVITE message. This document proposed the extensions to the 'tel' and 'fax' Uniform Resource Locators (URLs) to support NP so that they can be used to carry the NP related information in the Session Initiation Protocol (SIP) Request-URI. "Kerberized Internet Negotiation of Keys ", M. Thomas, Michael Thomas, 07/11/2000, <draft-thomas-kink-charter-00.txt> The KINK working group is chartered to create a standards track protocol to facilitate centralized key exchange in an application independent fashion. Participating systems will use the Kerberos architecture as defined in RFC 1510 for key management and the KINK protocol between applications. The goal of the working group is to produce a low latency, computationally efficient, easily managed, and cryptographically sound protocol that is flexible enough to be able to be extended for many applications. The focus of the initial working group will be keying IPsec security associations as defined in RFC 2401. The working group may consider means to key other protocols in the future, but the initial goal of the KINK working group is specifically targeted at producing a low latency and computationally efficient keying mechanism for IPsec. The working group will not be involved with, nor should it require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). "TCP Congestion Control with Appropriate Byte Counting ", Mark Allman, 07/11/2000, <draft-allman-tcp-abc-00.txt> This document proposed a small modification to the way TCP increases its congestion window. Rather than the traditional method of increasing the congestion window by a constant amount for each arriving acknowledgment, we suggest basing the increase on the number of previously unacknowledged bytes each ACK covers. This change improves the performance of TCP, as well as closes a security hole TCP receivers can use to induce the sender into increasing the sending rate too rapidly. "Label Aggregation Technique for LDP", Joseph Leung, Robert Rennison, Stephen Vogelsang, 07/12/2000, <draft-leu-mpls-ldp-label-aggregation-00.txt> The label distribution protocol specified in [1] describes a mechanism whereby one label switched router informs another of the meaning of labels used to forward traffic between and through them. This draft proposes a label aggregation technique to reduce the number of labels that need to be exchanged between two LSRs running LDP. This includes a method of signalling that LSRs are capable of label aggregation, determining when a label request can be aggregated on to an existing LSP and a method of signalling to upstream LSRs that the resulting label mapping is an aggregate. "Universal Mobile IP (UMIP) Intelligent Routing", Almon Tang, John Wang, 07/12/2000, <draft-wang-manet-umip-routing-00.txt> Global roaming is one of the design objectives for next generation 3G) cellular networks. To efficiently support real-time services for mobile users in these networks, delays in signaling and bearer traffic must be minimal. "SIP Extensions for Message Waiting Indication", Rohan Mahy, Ilya Slain, 07/12/2000, <draft-mahy-sip-message-waiting-00.txt> SIP [2] is very useful as a protocol for finding users and for rendezvous with those users. It is also very good at getting status and presence information which corresponds to those users (see the work of the PINT WG [3], and recent SIP-based proposals for Instant Messaging (IM) [4], and Presence [5]). This draft proposes using SIP with the SUBSCRIBE/NOTIFY methods [6] to carry message waiting status and message summaries from a messaging system to an interested User Agent. This proposal contains two message body definitions. The first is a simple text representation suitable for giving the status of a single folder. The second uses XML [7]; it can carry status for multiple message folders within an account, it is compatible with XSL [8] style sheets, and it can be extended later without breaking backwards compatibility. "MGC Recovery Package for Megaco/H248", Wayne Cutler, 07/12/2000, <draft-cutler-megaco-recvpkg-00.txt> This documents provides a proposed definition for a supplemental package to Megaco/H.248. The proposed package addresses support of functionality to enable a MGC to store information on a MG which can subsequently be retrieved thereby facilitating the appropriate (MGC) recovery action in the event of a MGC restart. "Hierarchical Mobile IPv6", Claude Castelluccia, Ludovic Bellier, 07/12/2000, <draft-castelluccia-mobileip-hmipv6-00.txt> In Mobile IPv6 a mobile node registers with its home agent and its correspondent hosts each time it changes care-of address. This draft presents a Hierarchical Mobile IPv6 proposal that reduces the number of signaling messages sent by a mobile host to its home agent and correspondent hosts and that reduces the signaling delay. Our proposal relies on the deployment of Mobility Networks that provide flexibility and scalability. "Extensions to OSPF and IS-IS in support of MPLS for SDH/SONET Control ", E. Mannie, Greg Bernstein, 07/12/2000, <draft-mannie-mpls-sdh-ospf-isis-00.txt> This document specifies and suggests extensions to the OSPF and IS- IS routing protocols in order to support the routing of dynamically established SDH/SONET circuits using the MPLS architecture. "PKCS #10: Certification Request Syntax Specification Version 1.7", B. Kaliski, Magnus Nystrom, 07/12/2000, <draft-nystrom-pkcs10-v1-7-00.txt> This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The remainder of the text is taken from that specification. "Extensions to SIIT and DSTM for enhanced routing of inbound packets", Erik Nordmark, Hesham Soliman, 07/12/2000, <draft-soliman-siit-dstm-00.txt> This document specifies a transition mechanism that combines both [SIIT] and DSTM mechanisms by adding some extensions to allow fast routing of inbound packets. This will result in a more decentralised and flexible tool to allow V6 only hosts to communicate with V4 only hosts. The proposed extensions will provide a way that allows SIIT routers to route packets addressed to a host running a single IPv6 stack with minimum delay which is suited to real time services. "SIP-H.323 Interworking Requirements", Alan Johnston, David Wang, Karunesh Singh, H Schulzrinne, Hemant Agrawal, Vipin Palawat, Radhika Roy, Charles Agboh, 07/12/2000, <draft-agrawal-sip-h323-interworking-reqs-00.txt> This document describes the requirements for the logical entity known as the interworking function (IWF) that will allow the interworking between the SIP(Session Initiation Protocol) and H.323 networks. "Securely Available Credentials", Stephen Farrell, Magnus Nystrom, 07/12/2000, <draft-farrell-sacred-00.txt> As the number, and more particularly the number of different types, of devices, connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This draft presents some requirements, a strawman framework and outlines a protocol for securely available credentials. "Fault Tolerance for LDP and CR-LDP ", Eric Gray, P. Brittain, Adrian Farrel, Philip Matthews, 07/12/2000, <draft-brittain-mpls-ldp-ft-00.txt> 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. "Policy Framework QoS Information Model for MPLS", Juergen Quittek, Makiko Yoshida, Marcus Brunner, 07/12/2000, <draft-isoyama-policy-mpls-info-model-00.txt> This document presents an information model for representing QoS policies for Multi-Protocol Label Switching (MPLS). The model is based on the Policy Framework QoS Information Model (QPIM) and the Policy Core Information Model (PCIM). These models are extended with new classes for controlling and managing the life-cycle of Label Switched Paths (LSPs) and for mapping of traffic onto existing LSPs. The control and management of LSP life-cycles includes mainly the creation, update, and deletion of LSPs and the assignment of QoS properties to LSPs. Even if this document is primarily intended to cover the QoS related MPLS areas, it also covers traffic engineering related policies. "Definitions of Managed Objects for SCSI over TCP", Mark Bakke, Jim Muchow, 08/07/2000, <draft-bakke-iscsimib-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for managing a client using the SCS over TCP (aka iSCSI) protocol. "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", E. Rosen, 07/13/2000, <draft-rosen-vpns-ospf-bgp-mpls-00.txt> [VPN] describes a method of providing a VPN service. That method allows a variety of different protocols to be used as the routing protocol between the Customer Edge (CE) router and the Provider Edge (PE) router. However, it does not fully specify the procedures which must be implemented within the Provider's network when OSPF is used as the PE/CE routing protocol. This document provides that specification. "OSP Authorization Token Header for SIP", Henry Sinnreich, Alan Johnston, Diana Rawlins, 07/13/2000, <draft-johnston-sip-osp-token-00.txt> This draft proposes a new SIP (Session Initiation Protocol) header OSP-Authorization-Token for carrying an OSP (Open Settlements Protocol) authorization token between domains. "IN- and PINT-related Requirements for SPIRITS Protocol", Igor Faynberg, Hui-Lan Lu, Lev Slutsman, Jorge Gato, 09/25/2000, <draft-faynberg-spirits-inpintreqs-01.txt> This Internet-Draft is written in response to the SPIRITS WG chairs' call for contributions to the future RFC on the SPIRITS protocol requirements. The goal of this document is to introduce the requirements pertinent to Intelligent Network (IN) and the (future) work of PSTN/Internet iNTernetworking (PINT) WG. To this end, the SPIRITS architecture has been slightly augmented to demonstrate the relation of PINT to SPIRITS as discussed at the Adelaide meeting. "A proposal for the provisioning of Call Completion Internet Busy using PINT and SPIRITS ", Jeremy Buller, 07/13/2000, <draft-buller-spirits-ccib-00.txt> 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 and SPIRITS working group. This Internet Draft describes an implementation architecture for co-operative services initiated from either the PSTN or Internet domains. It further describes how this architecture may be used in provision of a Call Completion Internet Busy (CCIB) aka Internet Call Waiting (ICW) service. "Mobility Support for IPv4 and IPv6 Interconnected Networks based on Dual-Stack Model", Jen-Chi Liu, Shiao Tsao, 07/13/2000, <draft-tsao-mobileip-duelstack-model-00.txt> To support IP mobility, mobile IPv4 was designed for IPv4 network and the mobility extension for IPv6 has been also drafted. However, mobile IPv4 and mobile IPv6 are not compatible to each other so that a mobile IPv4 host can not function properly while it changes its point of attachment to IPv6 networks and vice versa. The document specifies an architecture and mechanisms to solve mobility problems in IPv4 and IPv6 interconnected networks. The solution presents a dual stack model that implements a new address mapper on mobile hosts. The address mapper on a mobile host associates the home address in one protocol such as IPv4 with a care-of-address in the other protocol, i.e. IPv6. It dispatches IPv4/IPv6 packets to proper layers of the protocol stack, and provides transparent services to upper layers regardless of the attached networks. Therefore, the new architecture facilitates the mobility of hosts in IPv4 and IPv6 interconnected networks. "Criteria for Evaluating VPN Implementation Mechanisms", Jessica Yu, Vijay Srinivasan, Lianghwa Jou, Abbie Matthews, 07/13/2000, <draft-yu-vpn-criteria-00.txt> A variety of mechanisms for implementing Virtual Private Network (VPN) utilizing public IP network infrastructure have been proposed in [1,2,3,4] and more may be emerging. This document attempts to identify a set of criteria for evaluating such mechanisms. The criteria could be used by IETF for evaluating a VPN proposal before advancing it to standard track or by VPN Service Providers or enterprise network administrators for choosing which mechanism to use in order to implement their desired VPN networks. The mechanisms this criteria addresses are exclusively for implementing IP based VPNs, as oppose to non-IP based ones, such as Frame Relay based VPNs, etc. "A MIB for MPLS Traffic Engineered LSPs ", Kireeti Kompella, 07/13/2000, <draft-kompella-mpls-te-mib-00.txt> This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Traffic Engineered Multi-Protocol Label Switched Paths ([1], [2]). "AAA Usage for IP Telephony with QoS", Henry Sinnreich, Alan Johnston, Stephen Thomas, Steve Donovan, Diana Rawlins, 07/13/2000, <draft-sinnreich-aaa-interdomain-sip-qos-osp-00.txt> This draft specifies the AAA functions and message exchanges for interdomain SIP telephony call setup with QoS. Usage accounting is provided with clearing house support using the Open Settlement Protocol. Interdomain message exchanges use existing IETF protocols. The use of existing protocols is however modeled in the proposed AAA Architecture of the IETF AAAArch RG [1]. Though the approach has been developed specifically for IP telephony, using the AAA Architecture may allow a future AAA protocol to go beyond IP telephony to serve alike for other applications. "SONET/SDH Circuit Emulation Service Over MPLS (CEM)", Andy Malis, Andrew Vernon, K Hsu, Stephen Vogelsang, 07/13/2000, <draft-malis-sonet-ces-mpls-00.txt> This document describes a method for providing a SONET circuit emulation service across an MPLS network. "The Virtual Wire Per Domain behavior _ Analysis and Extensions ", G Mercankosk, 07/13/2000, <draft-mercankosk-diffserv-pdb-vw-00.txt> This document provides an analysis of the Virtual Wire Per Domain Behavior with limited extensions. The draft formalizes a model for the PDB by explicitly identifying key timing and decision variables and associated design parameters. It derives the necessary and sufficient conditions for creating and establishing a Virtual Wire flow. It provides methods for quantifying design parameters and setting decision parameters and discusses their extensions to incorporate variations in traffic characteristics. A pdf version of this document is available at http://www.ee.uwa.edu.au/~guven/vwpdb.pdf "Requirements for IPv6 dialup PPP operation ", K. Yamamoto, Jun-ichiro Hagino, 07/13/2000, <draft-itojun-ipv6-dialup-requirement-00.txt> The memo tries to identify design choices in IPv6 dialup PPP services by ISPs. "Interworking between SIP and INAP", H. Schulzrinne, Igor Faynberg, Hui-Lan Lu, Lev Slutsman, 07/20/2000, <draft-schulzrinne-sin-01.txt> The goal of this document is to identify a new IETF work item. The document defines the term 'soft switch' as a mechanism by which PSTN Intelligent Network (IN) service control can be accessed by VoIP gateways and associated SIP servers. The document mechanism for interworking of the Session Initiation Protocol (SIP) and Intelligent Network Application Part Protocol (INAP). "A RADIUS attribute for IPv6 dialup PPP with static address assignment ", K. Yamamoto, Jun-ichiro Hagino, 07/13/2000, <draft-itojun-ipv6-dialup-radius-00.txt> The memo defines RADIUS [Rigney, 2000] attribute for supporting IPv6 dialup PPP with static address assignment. "Traffic Engineering of Load Distribution ", Francis Reichmeyer, Steven Wright, Robert Jaeger, 07/13/2000, <draft-wright-load-distribution-00.txt> Online traffic load distribution for a single class of service has been explored extensively given that extensions to IGP can provide loading information to network nodes. To perform traffic engineering of load distribution for multi-service networks, or off line traffic engineering of single service networks, a control mechanism for provisioning bandwidth according to some policy must be provided. This draft identifies the mechanisms that affect load distribution and the controls for mechanisms that affect load distribution to enable policy based traffic engineering of the load distribution to be performed. This draft identifies the mechanisms that affect load distribution and the control for those mechanisms to enable policy based traffic engineering of load distribution. This draft also presents guidelines for the use of these load distribution mechanisms in the context of single IP network administration. "Mobile Networks Support in Mobile IPv6 ", Ted Ernst, Claude Castelluccia, Ludovic Bellier, H Lach, 07/13/2000, <draft-ernst-mobileip-v6-network-00.txt> This draft addresses the problems of routing datagrams to nodes located in an IPv6 mobile network. A mobile network is a network that is changing its point of attachment dynamically such as a network deployed in an aircraft, a boat, or a car. Mobile IPv6 [4] has been developed to support mobile nodes and is unable to support mobile networks efficiently. This draft discusses the Mobile IPv6 ability to support mobile networks and proposes to extend Mobile IPv6 with prefix scope binding updates to support mobile networks in the Internet. All datagrams bearing a destination address which prefix matches a home network prefix recorded in the binding cache are routed to the corresponding care-of address. "SIP Enabled Services to Support the Hearing Impaired", Jonathan Rosenberg, Henry Sinnreich, H. Schulzrinne, 07/13/2000, <draft-rosenberg-sip-hearingimpaired-00.txt> This document outlines a set of services enabled by the Session Initiation Protocol (SIP), that allow for access to voice services by people who are hearing impaired. SIP has gained much attention as a tool for voice communications on the Internet. Therefore, considerations for universal access of its services are important. This document does not propose any extensions or new capabilities to SIP, but rather a set of services enabled by it. "A Framework for Network-based VPNs ", M. Suzuki, 07/13/2000, <draft-suzuki-nbvpn-framework-00.txt> The objective of this draft is to clarify a framework for standardizing the mechanisms supporting interoperable network-based virtual private networks (NBVPNs). These are VPNs using IP facilities whose operation mechanisms are implemented within a network (or networks) and outsourced to one or more service providers. This draft first describes the assumed services of NBVPNs and clarifies the logical architecture model and reference model of NBVPN. Considering the assumed services, this draft further clarifies the NBVPN requirements for interfaces and MIBs in the reference model. It also surveys and discusses current technologies supporting NBVPNs such as tunneling, VPN identifier, routing, and QoS/SLA. Additionally it will, in future, provide outline of the interface and MIB specifications and present criteria for achieving interoperability. "Mapping the BXXP Framework onto SCTP", Marshall Rose, 07/13/2000, <draft-mrose-beep-sctpmapping-00.txt> This memo describes how a BXXP session is mapped onto the Stream Control Transmission Protocol. "Third party call control with SDP preconditions", Gonzalo Camarillo, 07/13/2000, <draft-camarillo-3pcc-qos-00.txt> This document describes how to perform third party call control in SIP when SDP preconditions are used. There are no new SIP extensions needed to accomplish this. The mechanism outlined is illustrated with an example in order to help understand it. "SIP Firewall Solution", Frederik Thernelius, 07/14/2000, <draft-thernelius-sip-firewall-solution-00.txt> This document describes a solution that is able to handle SIP signaling together with NAT enabled firewalls. The intent is to show that existing firewalls do not have to be replaced by 'SIP enabled' ones, instead they will only have to be reconfigured slightly. The main feature of this solution is using MGCP from a session control proxy to open/close holes in an RTP proxy which then enables RTP traffic to flow between interconnected networks. Worth noting is that this solution will not only work for SIP, it will also work for other protocols, such as H.323 or Real Audio. It does not even have to be RTP that is passed through the RTP proxy, though this draft assumes that the RTP stream is accompanied by RTCP. The solution will work for any protocol that wishes to open/close ports dynamically in the RTP proxy (maybe it should be called Forwarding Engine in the general case). "A TCP profile for W-CDMA: 3G wireless packet service. ", Hiroshi Inamura, Taro Ishikawa, 07/14/2000, <draft-inamura-docomo-00.txt> The third generation, 3G, wireless networks that enable high-speed data transfer are now being introduced. Internet access is one of the most important applications of such networks. TCP is one of the key technologies that enable Internet applications for such networks. A number of TCP optimization techniques have been studied to enhance the performance of TCP transmission for various wireless environments. "Requirements for support of Diff-Serv-aware MPLS Traffic Engineering", William Townsend, A. Chiu, Francois Le Faucheur, D Skalecki, Thomas Nadeau, 07/14/2000, <draft-lefaucheur-diff-te-reqts-00.txt> This document defines the requirements for support of Diff-Serv- aware MPLS Traffic Engineering on a per-Class-Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. A companion document [DIFF-TE-EXT] proposes actual extensions to OSPF, ISIS, RSVP and CR-LDP in order to meet those requirements. "Extensions to IS-IS, OSPF, RSVP and CR-LDP for support of Diff-Serv-aware MPLS Traffic Engineering ", William Townsend, A. Chiu, Francois Le Faucheur, D Skalecki, Thomas Nadeau, 07/14/2000, <draft-lefaucheur-diff-te-ext-00.txt> A companion document [DIFF-TE-REQTS] defines the requirements for support of Diff-Serv-aware MPLS Traffic Engineering on a per-Class- Type basis, as discussed in the Traffic Engineering Working Group Framework document [TEWG-FW]. This document proposes corresponding extensions to OSPF, ISIS, RSVP and CR-LDP for support of Traffic Engineering on a per-Class-Type basis. "IS-IS Extensions in Support of MPL(ambda)S", Y Rekhter, E. Mannie, John Drake, Debanjan Saha, Don Fedyk, Kireeti Kompella, Vishal Sharma, Greg Bernstein, Ayan Banerjee, 07/14/2000, <draft-kompella-isis-ompls-extensions-00.txt> This document specifies extensions to the IS-IS routing protocol in support of Multiprotocol Lambda Switching (MPL(ambda)S). "OSPF Extensions in Support of MPL(ambda)S", Y Rekhter, E. Mannie, John Drake, Debanjan Saha, Don Fedyk, Kireeti Kompella, Vishal Sharma, Greg Bernstein, Ayan Banerjee, 07/14/2000, <draft-kompella-ospf-ompls-extensions-00.txt> This document specifies extensions to the OSPF routing protocol in support of Multiprotocol Lambda Switching (MPL(ambda)S). "Taxonomy of xcast/sgm proposals", Dirk Ooms, 07/14/2000, <draft-ooms-xcast-taxonomy-00.txt> Recently several multicast mechanisms were proposed that scale better with the number of multicast sessions than traditional multicast does (DCM [BLAZ], SGM [BOIV], Somecast [HELD], MDO6 [IMAI], CLM [OOMS], ERM [SHAN], REUNITE [STOI]). These proposals are also known as Explict Multicast (xcast; explicit list of destinations) or Small Group Multicast (sgm; the main application being few-to-few communication). To stimulate and streamline the discussion this draft is an attempt to make a taxonomy of these mechanisms. "Enhanced DTMF Detection Package for Megaco/H.248", C. Brown, Sarah Cornel, 07/14/2000, <draft-cornel-megaco-enhancedd-00.txt> This document provides proposed definitions for a supplemental package for Megaco/H.248. This package addresses enhanced support of DTMF detection. "Requirements for Configuration Management of IP-based networks", Keith McCloghrie, Jonathan Saperia, Luis Sanchez, 07/18/2000, <draft-ops-ip-config-management-reqmnts-00.txt> This document is the output of a design team chartered with the identification of a global set of configuration management requirements for IP-based networks. "Common Radio Access Protocols Issues and Requirements", Yousuf Saifullah, Stefano Faccin, 07/14/2000, <draft-saifullah-craps-issues-req-00.txt> This paper discusses some of the issues that need to be considered in defining the CRAPS protocol set. It also specifies a set of requirements, which can be useful in the development of CRAPS. The issues are in consideration of some of the functionalities an existing cellular radio access network is required to provide. The document also discusses the issues, which are related to the new functional aspects of CRAPS. "A SPIRITS solution based on virtual SIP user agents", Soren Nyckelgard, Jorgen Bjorkner, 07/14/2000, <draft-bjorkner-spirits-vsua-00.txt> This document discusses events occurring in a telephony network that could be useful for call related services created in an Internet environment. It also shows one possible implementation of a SPIRITS protocol based on Session Initiation Protocol (SIP) [2]. The SPIRITS working group has not yet done any protocol decisions, so this draft is written for informative purpose showing that the introduction of virtual SIP user agents (SIP UAs) in a SPIRITS client makes it possible to realize the services described in the pre-spirits implementations document [3]. "Call Model For IP Telephony", Shehryar Qutub, Janusz Dobrowolski, Kumar Vemuri, Michel Grech, Musa Unmehopa, 07/14/2000, <draft-dobrowolski-call-model-00.txt> Several different call models are in common use today in conventional Telephony. IP Telephony is gaining wider acceptance. There is, as yet, no well-defined, widely accepted call model for this domain. In this draft, we study some of the issues associated with call models for IP Telephony, and suggest how a single call model representation may be selected to effectively represent call processing in this domain. "The application/osp-token MIME type ", Stephen Thomas, Butch Anton, Richard Brennan, 07/14/2000, <draft-thomas-sip-mime-osp-token-00.txt> The Open Settlement Protocol (OSP)[1], an open standard from the European Telecommunications Standards Institute, specifies a means by which IP telephony equipment in one administrative domain may request access to IP telephony equipment (including, but not limited to: Gateways, Proxy Servers, Gatekeepers, etc.) in another administrative domain. OSP grants such access by returning authorization tokens, which must then be passed to the destination IP telephony device during call signaling. In order to support access control via OSP, IP telephony signaling protocols must be capable of carrying these authorization tokens in an interoperable way. This memo defines just such a method for protocols, such as the Session Initiation Protocol[2], that can support carriage of MIME types during call signaling. This memo conforms to the requirements for MIME type registration defined in RFC 2048[3]. "SCTP Sockets Mapping", Kacheong Poon, Jonathan Wood, La Monte Yarroll, Q Xie, Randall Stewart, 07/14/2000, <draft-stewart-sctpsocket-sigtran-00.txt> This document describes a mapping of the Stream Control Transmission Protocol (SCTP) [SCTP] into a sockets API. The benefits of this mapping include compatibility for TCP applications, access to new SCTP features and a consolidate error and event notification scheme. "Source-Specific Multicast for IP ", Brad Cain, Hugh Holbrook, 07/14/2000, <draft-holbrook-ssm-arch-00.txt> 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. "Using IGMPv3 For Source-Specific Multicast", Brad Cain, Hugh Holbrook, 07/14/2000, <draft-holbrook-idmr-igmpv3-ssm-00.txt> This document describes changes to the Internet Group Management Protocol Version 3 (IGMPv3) [IGMPv3] to support source-specific multicast (SSM) [SSM]. "The Stream Cipher Encapsulating Security Payload", Mohammad Peyravian, David McGrew, Scott Fluhrer, 07/21/2000, <draft-mcgrew-ipsec-scesp-01.txt> This document specifies the use of an additive stream cipher as a confidentiality mechanism within the context of the IPSec Encapsulating Security Payload (ESP) defined by Kent and Atkinson [KA98b]. This transform fits into and extends the framework of ESP CBC-Mode Cipher Algorithms of Pereira and Adams [PA98], and can be used in conjunction with any ESP Authentication Algorithm. The advantages of the Stream Cipher ESP (SC/ESP) transform are twofold: it enables the use of faster ciphers, and the expansion of stream cipher ESP protected packets is less than that of CBC-Mode ESP protected packets. A detailed security analysis of additive encryption of Internet traffic and SC/ESP is being published separately [MF00]. "PF_KEY Extensions for Reducing Policy Information in Kernel", Jari Arkko, 07/14/2000, <draft-arkko-pfkey-reference-00.txt> PF_KEY is a generic key management API that can be used with IPsec. This document discusses the extension of the PF_KEY interface in order to lessen the need to store complicated IPsec policy data in kernel- mode implementations, and to make it possible for key management dae- mons reuse traffic pattern information already present in the kernel. "Web Cache Coordination Protocol V2.0 ", David Forster, Robert Wilson, Martin Cieslak, Gurumukh Tiwana, 07/14/2000, <draft-wilson-wrec-wccp-v2-00.txt> This document describes version 2.0 of the Web Cache Coordination Protocol (WCCP). The WCCP V2.0 protocol specifies interactions between one or more routers and one or more web-caches. The purpose of the interaction is to establish and maintain the transparent redirection of selected types of traffic flowing through a group of routers. The selected traffic is redirected to a group of web-caches with the aim of optimising resource usage and lowering response times. The protocol does not specify any interaction between the web-caches within a group or between a web-cache and a web-server. "Kerberized USM Keying", Keith McCloghrie, M. Thomas, 07/14/2000, <draft-thomas-snmpv3-kerbusm-00.txt> The KerbUSM MIB provides a means of leveraging a trusted third party authentication and authorization mechanism using Kerberos for SNMP V3 USM users and their associated VACM views. The MIB encodes the normal Kerberos AP-REQ and AP-REP means of both authenticating and creating a shared secret between the SNMP V3 Manager and Agent. "Extensions to RSVP-TE for Bi-directional Optical Path Setup", Leah Zhang, James Fu, Raymond Cheung, DAN Guo, 07/14/2000, <draft-sorrento-rsvp-bi-osp-00.txt> We propose an extension to RSVP-TE for setting up and maintaining Bi-directional Optical Switched Paths (BOSPs) in optical networks with symmetric traffic patterns. The requirement for wavelength continuity for some types of optical networks with no (or partial) wavelength conversion is also supported. It follows the framework of MPLS and extends the RSVP-TE to support the signaling for the provisioning of BOSPs. We introduce a new c-types for bi-directional LSPs in both Label Request object and Label object. Each LSR (OXC), upon receiving an RESV message for a BOSP, will allocate a pair of labels. One label is for the incoming port from the next hop and the other is for the incoming port from the previous hop. The labels here include fiber ID, wavelength ID and sub-channel ID (if applicable). This extension requires a minimum change to the existing RSVP-TE protocol. It avoids the problem of contention where two OXCs assign the same wavelength on a uni-directional link for two different sessions. This contention arises in both [4] and [5]. As a result, no additional mechanism for contention resolution is needed. "Randomness Requirements for Security", Steve Crocker, Jeffrey Schiller, D Eastlake, 07/17/2000, <draft-eastlake-randomness2-00.txt> Security systems today are built on increasingly strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. The sophisticated attacker of these security systems may find it easier to reproduce the environment that produced the secret quantities, searching the resulting small set of possibilities, than to locate the quantities in the whole of the number space. Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using traditional pseudo-random number generation techniques for choosing such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available. And it gives examples of how large such quantities need to be for some particular applications. "Multicast Micro-Mobility Protocol (MMM)", Vincent Magret, Vinod Choyi, 07/17/2000, <draft-magret-mobileip-mmm-00.txt> The document proposes an extension to Mobile IP [RFC2002] to offer a support of micro-mobility. Micro-mobility refers to the part of a mobile protocol allowing a mobile node to move without having to notify its home agent. The mobile node's home agent's notification is a concept defined by Mobile IP [RFC2002]. This protocol defines a service known as macro-mobility. The protocol defined in this Internet Draft specifies the messages and the operations required to extend Mobile IP. "Long-lived TCP connections", Muh-rong Yang, Vincent Magret, 07/17/2000, <draft-magret-pilc-lltcp-00.txt> This document specifies a protocol enhancement allowing TCP connec- tions to switch from an active state to an idle state during a wire- less link's outage. Within such state all timers are cancelled and packets' transmission is suspended. The protocol defines a mechanism by which the mobile station may detect a link failure and changes TCP connections' state to idle. This same mechanism allows the mobile host to detect connectivity regain. All TCP connections are then resumed. The protocol defines how the supervisor host, which can monitor the wireless link quality, can alert the fixed host of a failure of the wireless link. The fixed host can suspend the outgoing activity with the unreachable mobile node. When the fixed hosts start receiving packets from the mobile node, the activity can be resumed. This protocol increases the capacity of both parties involved in a communication that is carried via a wireless link to handled connec- tivity disruption without impacting the overall performance of the TCP connections. "Providing Emergency Call Services for SIP-based Internet Telephony", H. Schulzrinne, 07/17/2000, <draft-schulzrinne-sip-911-00.txt> If Internet Telephony is to offer a full replacement for traditional telephone services, it needs to provide emergency call services. In the United States, emergency calls are known as 911 services, based on the number dialed. This note desccribes some options for providing enhanced emergency service, i.e., emergency calls that allow emergency response centers to determine the address where the caller is located. This is made more difficult by the temporary nature of IP addresses, the large number of ISPs and their lack of legal responsibility for emergency services and the ability of many Internet terminals to be connected to the Internet at different locations. This note explores some of the requirements and design choices. "Internet General Packet Radio Service (IGPRS); Service description", C Perkins, Hossam AFIFI, 07/17/2000, <draft-afifi-igprs-00.txt> 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. "Low delay RTCP packet format for backward messages ", Shigeru Fukunaga, Hideaki Kimata, 07/17/2000, <draft-fukunaga-low-delay-rtcp-00.txt> This document describes a new RTCP packet format for carrying the backward messages for error recovery; such as MPEG-4 Visual upstream messages [2] and H.263 backward messages [3]. As these backward messages are requested to deliver in low delay, a new RTCP profile of low delay is defined. "Snapshot of E.164 Work - An Unofficial View", Andrew Gallant, 07/17/2000, <draft-gallant-enum-e164-snap-00.txt> This is an unofficial snapshot of some E.164 work. It includes some information on E.164-series ITU-T Recommendations, 'country code' assignments, and future pending decisions, meetings, and work. E.164 is an ITU-T Recommendation on international numbering for public telecommunication. All views expressed in this Internet Draft are unofficial and are not intended to represent those of any organization, corporation, or Administration. This Internet-Draft is an independent submission to the Telephone Number Mapping (enum) working group. Comments should be sent to the author. "Basic SLoP Architecture Proposal", John Loughney, Jose Costa-Requena, 07/17/2000, <draft-loughney-spatial-arch-00.txt> This Internet Draft proposes a basic architectural model which allows users to exchange spatial location information. "A Framework for Source-Specific IP Multicast Deployment", Supratik Bhattacharyya, 07/17/2000, <draft-bhattach-pim-ssm-00.txt> 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. "MSDP Specific Forwarding Extension for Inter-Domain Multicast Forwarding ", A. Iwata, Masahiro Jibiki, 07/17/2000, <draft-jibiki-iwata-msdp-idmf-00.txt> 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 Framework for Smooth Handovers with Mobile IPv6", C Perkins, Rajeev Koodli, 07/17/2000, <draft-koodli-mobileip-smoothv6-00.txt> During handover from one access router to another, a wireless mobile node may need to have a certain amount of state information passed from the Previous-Router to the new one. This document specifies extensions to Mobile IPv6 which allow additional control structures enabling the transfer of the necessary state during handovers. This state transfer allows the applications running on the mobile node to operate with reduced latency, minimal disruption, and reduced packet loss during handovers. "Application-layer Policy Enforcement at SIP Firewalls", Jon Peterson, 07/17/2000, <draft-jfp-sipfw-policy-00.txt> At the boundaries of some networks, administrators may want to implement policies that govern the application-layer traversal of SIP signaling. This document serves as an introduction to application- layer policies for SIP, discusses the architectures of network boundaries at which policies might be deployed, and provides examples of policies tailored to particular network services. "Extensible Proxy Services Framework ", Michael Condry, Hilarie Orman, Dave Farber, Gary Tomlinson, James Kempf, 07/17/2000, <draft-tomlinson-epsfw-00.txt> In today's Internet, caching proxies that intermediate between HTTP (and increasingly streaming media) clients and servers provide enhanced performance for Web page access. Both clients and servers are increasingly looking to the network for additional services that can't be provided directly on the client or server, and Web proxies are an attractive place for locating these services. In fact, some such services (content assembly for advertising) are already being offered by Web proxies for servers, but in a nonstandard way. This document describes the problem and solution requirements for a standardized, open and extensible service environment on caching proxies which enables them to provide general services that mediate, modify, and monitor object requests and responses. It introduces an architectural framework along with a set of core requirements necessary to design standardized implementations for this application domain, taking into account relevant IETF RFCs and IETF work-in-progress. The architecture and requirements described here are mindful of the success of end-to-end nature of Internet client/server interactions, and the consequences of the proposed architectural changes on end-to-end semantics are discussed. "Roaming Support with DNS", J Yu, John Loughney, 07/17/2000, <draft-loughney-enum-roaming-00.txt> This draft proposes a new service to support cellular roaming. It calls for a new service type, called 'roam' to be stored in DNS. This draft outlines the resolution of telephone numbering plans (E.214, E.212 and E.164, among others) by DNS to support cellular roaming. Considerations need to be made for scalability, reliability and performance. "An RTP Payload Format for Erasure-Resilient Transmission of Progressive Multimedia Streams", B Wimmer, Guenther Liebl, Frank Burkert, Juergen Pandel, Minh Nguyen, Gero Baese, 09/20/2000, <draft-lnt-avt-uxp-02.txt> This document specifies an efficient way to ensure erasure-resilient transmission of progressively encoded multimedia sources via RTP using Reed-Solomon codes. The level of erasure protection can be explicitly adapted to the importance of the respective parts in the source stream, thus allowing a graceful degradation of application quality with increasing packet loss rate on the network. Hence, this type of unequal erasure protection (UXP) schemes is intended to cope with the rapidly varying channel conditions on wireless access links to the Internet backbone. Nevertheless, backward compatibility to currently standardized non-progressive multimedia codecs is ensured, since equal erasure protection (EXP) represents a subset of generic UXP. By defining a comparably simple payload format, the proposed scheme can be easily integrated into the existing framework for RTP. "CC/PP exchange protocol based on SIP ", Masanobu Yuhara, Takashi Nishigaya, 07/18/2000, <draft-nishigaya-sip-ccpp-00.txt> This document proposes a SIP extension for CC/PP (Composite Capability/Preference Profiles) exchange. CC/PPex, proposed by W3C, is only usable for client-pull service like HTTP. It is not suitable for server initiated push services. Since traditional SIP already has a method to convey the limited terminal capabilities for multimedia calls, SIP naturally extends to support CC/PP. This extension allows various types of push services to know the terminal capabilities before delivering the contents to the push clients. This is accomplished by introducing some additional headers in the REGISTER/OPTIONS message that carry the same information as CC/PPex does. "IP/UDP/RTP Header Compression over AAL2", B Thompson, Tmima Koren, bruce Buffam, 07/18/2000, <draft-buffam-avt-crtp-over-aal2-00.txt> 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. "IPsec NAT-Traversal", T. Ylonen, Tero Kivinen, Markus Stenberg, Santeri Paavolainen, 07/18/2000, <draft-stenberg-ipsec-nat-traversal-00.txt> IPsec architecture is based on the concept of keeping data secure while it is being transported across a network. Therefore there are problems when packet headers change while in transmit across the network, by virtue of NAT devices. This draft details the changes needed in order to make both initial IKE negotiation and subsequent authenticated/encrypted communications across IPsec AH/ESP SAs work despite the changes in the headers, and possible protocol transformations. "SONET Synchronous Transport Signal over IP", Joe Lawrence, Jim Boyle, Craig White, 07/18/2000, <draft-boyle-sts-ip-00.txt> A proposal is made to carry Synchronous Transport Signal (STS-N) services over packetized networks, in particular over IP networks. This has the potential to dramatically lower the price, ease the provisioning and grooming, and improve managability of delivering these types of circuits. Two proposals are put forth for discussion on how STS services could be transported over an IP network. The first proposal, referred to as SPE1/IP, is to break OC-N signals down into their STS-1 blocks, identify the SPE components and packetize these for transmission across a packet network. The second proposal, referred to as STSc/IP breaks down the STS signal into the underlying concatenated services and transports configurable length segments of the signal to the far end of the data network. With either of these approaches, different STS-N services on a given port can be connected to different ports across the network and the network will groom them onto the most optimal path available. "MAPOS/PPP Tunneling mode", K. Murakami, Tetsuo Kawano, S Shimizu, Eddy Beier, 07/18/2000, <draft-shimizu-ppp-mapos-00.txt> This document specifies tunneling configuration over MAPOS networks. Using this mode, a MAPOS network can provide transparent point-to- point link for PPP over SONET/SDH (Packet over SONET/SDH, POS) without any additional overhead. "Architecture of Internationalized Domain Name System", Seungik Lee, Dongman Lee, Eunyong Park, Sungil Kim, Hyewon Shin, 07/18/2000, <draft-silee-idn-arch-00.txt> For restrict use of Domain Name System (DNS) for domain names with alphanumeric characters only, there needs a way to find an Internet host using multi-lingual domain names: Internationalized Domain Name System (IDNS). This document describes how multi-lingual domain names are handled in a new protocol scheme for IDNS servers and resolvers in architectural view and it updates the [RFC1035] but still preserves the backward compatibility with the current DNS protocol. "SIP for Telephones (SIP-T): Context and Architectures", Aparna Vemuri, Jon Peterson, 07/18/2000, <draft-vemuri-sip-t-context-00.txt> SIP-T (earlier referred to as the SIP-BCP-T) is a mechanism that uses SIP to facilitate the interconnection of the PSTN with IP. This document explains the context and the architectures in which SIP-T may be used. This document has to be studied in conjunction with the existing SIP-T (referred to in some older documents as SIP-BCP-T) literature. "Authenticating denial of existence in DNS with minimum disclosure (or; An alternative to DNSSEC NXT records) ", Simon Josefsson, 07/18/2000, <draft-jas-dnsext-no-00.txt> This draft present an alternative to NXT records, used to achieve authenticated denial of existence of a domain name, class and type. Problems with NXT records, as specified in RFC 2535, are identified, and one solution is presented. "Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); TIPHON Release 3; Network architecture and reference configurations ", P Sijben, 07/18/2000, <draft-tiphon-architecture-00.txt> The contents of this Internet Draft is a reprint of the body of the architecture document (DTS 02003 v0.10.8) of the TIPHON project. This document describes a functional architecture for the purposes of defining a voice over IP architecture that can interwork with the existing Switched Circuit Networks (SCN). The full document is publicly available and can be found at http://docbox.etsi.org/Tech-Org/TIPHON/Document/tiphon/07- drafts/wg2/DTS02003/ the current version is 0.10.8. Later versions will appear in the same directory. This full document describes protocol independent information flows and state diagrams on all the reference points. The next step in the TIPHON process will be the mapping of the reference points as defined in this document to existing standards. Since TIPHON does not intend to duplicate work so the project would appreciate assistance from IETF experts in the mapping of its information flows to the appropriate IETF protocols. Candidate protocols for the implementation of this architecture are SIP, MEGACOp and possibly others. "TIPHON architecture background ", P. Mart, P Sijben, Scott Cadzow, 07/18/2000, <draft-tiphon-background-00.txt> The background and objectives of the new ETSI project Tiphon architecture are described in this draft. The architecture is shown to be capable of use by a number of different signalling systems and session control protocols, including SIP and H.323. The opportunity exists for the IETF to help with the technology mappings for SIP to ensure inter-operation with other technologies through the TIPHON architecture. "BGP/IPsec VPN ", Yves T''''Joens, Peter De Schrijver, Jeremy De Clercq, 07/18/2000, <draft-declercq-bgp-ipsec-vpn-00.txt> This document describes a method by which a Service Provider may use an IP backbone to provide VPNs for its customers. IPsec tunnels are deployed through the backbone, and the forwarding of packets over the backbone relies on normal IP forwarding. BGP is used for distributing (private) routes over the backbone. This model is based on the model described in RFC 2547 [RFC2547], and the internet-draft that obsoletes it [RFC2547bis]. The main difference is that in this model IPsec is used as tunneling mechanism instead of MPLS. "Requirements for Session Description and Capability Negotiation", Joerg Ott, Carsten Bormann, Dirk Kutscher, 07/18/2000, <draft-kutscher-mmusic-sdpng-req-00.txt,.ps> This document defines some terminology and lists a set of requirements that are relevant for a framework for session description and endpoint capability negotiation in multiparty multimedia conferencing scenarios. This document is intended for discussion in the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. "GSM SIM Authentication Mode for IKE", Jyri Rinnemaa, 07/18/2000, <draft-rinnemaa-ipsra-gsmsimmode-00.txt> This document presents a challenge-response authentication method based on the GSM Subscriber Identity Module (SIM). The method is used for authenticating a remote IPSec user to a security gateway. The examples in the document are based on modified IKE main mode. In the authentication phase a shared secret is generated utilizing the GSM SIM and then used to authenticate the IKE exchange as well. "The LDAP URL Format", Tim Howes, Mark Smith, 07/18/2000, <draft-smith-ldapv3-url-update-00.txt> LDAP is the Lightweight Directory Access Protocol, defined in [1], [2] and [3]. This document describes a format for an LDAP Uniform Resource Locator. The format describes an LDAP search operation to perform to retrieve information from an LDAP directory, or, in the context of an LDAPv3 referral or reference, the format describes a service where an LDAP operation may be progressed. This document specifies the LDAP URL format for version 3 of LDAP and clarifies how LDAP URLs are resolved. This document also defines an extension mechanism for LDAP URLs, so that future documents can extend their functionality, for example, to provide access to new LDAPv3 extensions as they are defined. This document replaces RFC 2255. See Appendix A for a list of changes relative to RFC 2255. "Dynamic Call Screening Using a WAP Interface Caller ID Delivery and Call Disposition by Interworking SIP and the Wireless Application Protocol", John Reid, Jaya Reddy, 07/18/2000, <draft-reid-wapdcs-00.txt> This document describes a service concept implementation of a Dynamic Call Screening Service (DCS) made available to WAP endpoints. This work builds on an existing Internet Call Waiting (ICW) [1] platform to provide enhanced call screening and control capabilities via the WAP interface to wireless handsets. This extends the current ICW [1] service to provide a 'WAP Proxy' which supports call screening notification and automatic disposition capabilities. In this way the service evolves from an Internet Call Waiting service for wireline subscribers to a network-based user agent with which users can register to direct incoming call n otifications to any of several endpoint device types depending on their current preferences and availability. "The String Representation of LDAP Search Filters", Tim Howes, Mark Smith, 07/18/2000, <draft-smith-ldapv3-filter-update-00.txt> The Lightweight Directory Access Protocol (LDAP) [1] defines a network representation of a search filter transmitted to an LDAP server. Some applications may find it useful to have a common way of representing these search filters in a human-readable form. This document defines a human-readable string format for representing the full range of possible LDAP version 3 search filters, including extended match filters. This document replaces RFC 2254. See Appendix A for a list of changes relative to RFC 2254. "EMA Enhanced Mobile IPv6/IPv4 ", Alan O''Neill, Scott Corson, George Tsirtsis, 07/18/2000, <draft-oneill-ema-mip-00.txt> It is well recognised by all micro and macro-mobility routing protocols that Mobile IP (MIP) is likely to be used to support inter-domain mobility. It is also widely accepted that Mobile IP could be used as the basis for signalling between the mobile and the micro-mobility domains for simplicity of the mobile terminal and interoperability purposes. The Edge Mobility Architecture (EMA) defines a generic IP hand-over model which operates in conjunction with a Mobility Enhanced Routing (MER) protocol to provide large- scale, intra-domain, IP address mobility. The aim of this document is to describe the minimum MIP signalling requirements for EMA:MER, and to propose additional changes necessary to [MIPv6] and [MIPv4] for them to support EMA:MER. The document deals with mobiles moving inside and between EMA:MER domains as well as coming and going from/to non-EMA:MER domains, demonstrating EMA/MIP interoperability and inter-domain hand-overs. The document also demonstrates the benefits a mobile and an operator will see when a mobile host is within an EMA domain. "COPS Usage for MPLS/Traffic Engineering ", Steve Wright, Francis Reichmeyer, M Gibson, 07/18/2000, <draft-franr-mpls-cops-00.txt> This draft describes the application of the COPS for Provisioning (COPS-PR) protocol for managing MPLS and its traffic engineering functionality. A new COPS client type is described, the COPS-MPLS client type, and the use of the basic COPS messages by this client type is described. "RTP Payload Format for AMR", B Wimmer, Tim Fingscheidt, 07/18/2000, <draft-fingscheidt-avt-rtp-amr-00.txt> This document proposes a real-time transport protocol (RTP) [1] payload format for AMR speech encoded [2] signals. It supports all 8 modes of the AMR speech codec and is as well prepared for future extensions, such as AMR wideband. Mode adaptation and discontinuous transmission (DTX) are supported as well. The proposed payload format allows large flexibility with a minimum of bitrate overhead. One or multiple speech frames can be trans- mitted in a single packet. Redundant transmission of previously transmitted frames (or parts thereof) is possible as well as parity code transmission. With one speech frame per packet the additional parity code transmission allows reconstruction of N previous lost speech frames when N consecutive correct packets are buffered in the receiver. This means a very high robustness while the receiver buffer size can be chosen according to the application. For implementation of this draft, please consider also the requirements of [12]. "Description of Load-Balancing and Communication Protocols Used by GNU Queue", W Krebs, 07/18/2000, <draft-krebs-gnuqueue-protocol-00.txt> This document describes the protocols used by GNU Queue to communicate between GNU Queue processes. This includes protocols used to facilitate network load-balancing (including reporting to GNU Queue processes of host load averages, 'virtual load averages', and/or other information used to determine job routing), process input-output, and process control information (two-way signal and termination code reporting). GNU Queue is a load-balancing system that lets users control their remote jobs in an intuitive, transparent and nearly seamless way. This is done with local shell job control and signaling through Queue's proxy daemon mechanism. Queue can be used as a local replacement for rsh and ssh to hosts within a cluster under single administrative control. Queue also supports the more traditional email-based load-balancing and distributed batch-processing facilities using a number of criteria to decide where to send jobs. The homepage for GNU Queue is http://queue.sourceforge.net . "SIP for the establishment of xcast-based multiparty conferences ", Dirk Ooms, Bart Van Doorselaer, 07/18/2000, <draft-van-doorselaer-sip-xcast-00.txt> Explicit Multicast (xcast) is a multicast scheme that uses an explicit list of destinations instead of one logical multicast address. Explicit Multicast complements the existing multicast schemes in that it can efficiently support very large numbers of distinct (small) multicast groups and thus can play an important role in making multicast practical for applications such as multiparty IP telephony, various conferencing & collaborative applications, multiparty networked games, etc... This document explains how multiparty IP telephony conferences making use of xcast can be established by SIP carrying SDP. Some open issues will be identified and discussed. Possible extensions to SIP and SDP to streamline the use of xcast will be suggested as well. "Service Level Specification Semantics, Parameters and negotiation requirements.", Yves T''''Joens, Danny Goderis, 07/18/2000, <draft-tequila-diffserv-sls-00.txt> This document identifies the basic information to be handled by Service Level Specification (SLS, [RFC 2475], [DS-TERMS]) when considering the deployment of value-added IP service offerings over the Internet. Such IP service offerings can be provided together with a given quality of service (QoS), which is expected to be defined in such SLS, from a technical standpoint. Since these IP services are likely to be provided over the whole Internet, their corresponding QoS will be based upon a set of technical parameters that both customers and services providers will have to agree upon. From this perspective, this draft aims at listing (and promoting a standard formalism for) a set of basic parameters which will actually compose the elementary contents of a SLS. "Security Framework for Explicit Multicast ", Bernard Sales, Oliver Paridaens, Dirk Ooms, 07/18/2000, <draft-paridaens-xcast-sec-framework-00.txt> This document describes the general issues related to securing explicit multicast traffic. Explicit multicast is a mechanism aiming at providing multicast services for small groups of users. The distinctive characteristics of explicit multicast is that the sender specifies the list of receivers. This document reviews and discusses security issues related to the explicit IP multicast model, hence providing a general framework for securing explicit multicast IP traffic once the exact mechanism for achieving explicit IP multicast is specified. "Policy Information Model for MPLS Traffic Engineering ", Ritu Chadha, Haui-an Lin, 07/18/2000, <draft-chadha-policy-mpls-te-00.txt> The purpose of this draft is to describe an information model for representing MPLS traffic engineering policies. RFC 2702, 'Requirements for Traffic Engineering over MPLS', is used as a basis for determining the types of information that need to be represented in such an information model. The latter document describes the functional capabilities required to implement policies that facilitate efficient and reliable network operations in an MPLS domain. The information model described in this draft attempts to capture the information required to enable the functional capabilities described in RFC 2702. This information model could be used by a management system to optimize network performance through the necessary network provisioning actions. An overview of policy-based management is given in this document, along with a description of the relationship of this work to other information models that are being defined in the IETF Policy Framework working group. This is followed by a detailed description of the information model, and a number of examples illustrating its use. "Development Plan for Reissuing Existing LDAPv3 RFCs In CY2001", M. Wahl, 07/19/2000, <draft-wahl-ldapv3-2001plan-00.txt> The IESG prefers to avoid having RFCs linger in Proposed Standard Status. In general, RFCs which have demonstratable interoperability and usefulness should become Draft Standards, and eventually may become full Standards, as described in RFC 2026 [1] section 6.2. When a Proposed Standard RFC is reissued to become Draft, corrections, clarifications and other changes can be integrated into the update. However, if changes to the protocol are 'very significant', then the document needs to be issued as Proposed Standard again. This document describes an approach to reissue the core RFCs which describe LDAPv3, all of which are currently at Proposed Standard status. It also summarizes the status of other existing and upcoming standards-track LDAP RFCs. "Storing tunnel endpoint in the DNS ", Alain Durand, 07/19/2000, <draft-durand-ngtrans-tunnel-endpoint-00.txt> Tunnels in various forms (IPv6 in IPv4, IPv4 in IPv6,...) are key elements in many IPv6 transition scenarios. Tunnels can be either dynamically managed or manually configured. In this later case, managing tunnel endpoint is critical. This document describe a simple mechanism to store and retrieve those endpoint in the DNS. "ENUM Call Flows for VoIP Interworking ", Steven Lind, 07/19/2000, <draft-lind-enum-callflows-00.txt> This document provides illustrations of the use of ENUM functionality and identifies issues associated with such use. To accomplish this objective, the document presents service-level call flows for Voice over IP communication where interworking between the PSTN and IP-based networks are necessary to complete a call. Details are presented for simple calls made on a 'direct dial' basis. For more complicated calls, requiring number portability or freephone call processing, the issues are described with the intent of working through those issues in subsequent drafts. "Definition of Managed Objects for Synthetic Sources for Performance Monitoring algorithms", Dan Romascanu, R. Cole, C. Kalbfleisch, 07/19/2000, <draft-kalbfleisch-sspmmib-00.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it 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. "OPINIONS Open IP Network Infrastructure for Nomadic Services ", Gary Kenward, Bill Gage, 07/19/2000, <draft-gage-opinions-00.txt> This document outlines the issues facing nomadic communications in an IP-based environment. While cellular systems epitomise current concepts of mobility, there is an industry need to support similar functions in non-cellular environments as well. Unfortunately, solutions defined to-date by the cellular industry tend to be closely tied to the technology employed over the radio link (e.g. GSM, cdma2000, UMTS, EDGE). To facilitate discussion, this document begins with a high-level description of functional entities comprising an Open IP Network Infrastructure. It then defines an abstract model of the access link used to connect a mobile host to the network. Using these entities and model, we then go on to discuss the issues facing nomadic computing that could be usefully addressed by an IETF working group like CRAPS. "Quick handoff scheme in a 3G Wireless Network", Ajoy Singh, Sebastian Thalanany, 07/19/2000, <draft-thalanany-mobileip-qh-00.txt> This draft proposes a scheme to for a quick handoff of a mobile station (MS) from a source packet data-serving node (PDSN) to a target PDSN. The scheme utilizes the information available from the air-interface signaling messages necessary for the hard handoff over the wireless link. "MIME TYPE definition for IP in IP tunnels", Alain Durand, 07/19/2000, <draft-durand-ngtrans-tunnel-mime-type-00.txt> 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. "A LightWeight IP Encapsulation (LIPE) Scheme", M. Chuah, Enrique Hernandez-Valencia, 09/20/2000, <draft-chuah-avt-lipe-01.txt> Several application level compression/multiplexing solutions have been proposed in the IETF Audio/Video Transport (AVT) Working Group [1][2][9] to improve the transport efficiency of packet-voice traffic over IP-based networks. These approaches generally assume voice packets are RTP/UDP/IP encapsulated by the communicating end-points (e.g., IP phones, mobile terminal, media gateways, etc.). In some transport scenarios, using RTP/UDP encapsulation for voice packet is unnecessary as only the data transfer services provided by the IP layer are required, not the media control functions. "BGP/VPN: VPN Information Discovery for Network-based VPNs", B. Gleeson, Gregory Wright, Hamid Ould-Brahim, 07/19/2000, <draft-ouldbrahim-bgp-vpn-00.txt> VPN information can be piggybacked into BGP to allow a network-based VPN to auto-discover its membership and adequate information needed before any data exchange between private sites takes place across the backbone. Other drafts (e.g.[VPN-RFC2547]) also piggyback VPN information onto the backbone instance of BGP. However, [VPN- RFC2547] implicitly allows only for a single reachability mechanism (also BGP piggybacking) and a single tunneling mechanism (MPLS). This draft allows for the explicit indication of the reachability modes supported (e.g. piggybacking or virtual router) and the tunneling mechanisms supported, by a VPN device. The purpose of this draft is to define a common VPN information protocol that can be used for both piggybacking and virtual router schemes. It allows for the auto-discovery of the nodes in a particular VPN, the selection of the reachability mechanism to use, and the selection of the tunneling protocol to use. "A proposal to provide QoS capability for PPP", Giovanni Fiaschi, Gian Rolandelli, Fabio Poggi, 07/19/2000, <draft-fiaschi-qoscapability-ppp-00.txt> 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. "Spatial Location Protocol Requirements ", Brian Rosen, 07/19/2000, <draft-rosen-spatial-requirements-00.txt> This document describes requirements to be placed on the Spatial Location Protocol (SloP). "MPLS LDP Query Message Description", Peter Ashwood-Smith, Antonela Paraschiv, 07/19/2000, <draft-paraschiv-mpls-lsp-query-00.txt> This document describes the encoding and procedures for two new LDP messages, the Query Message and Query-Reply Message. An LER sends a Query message when it needs to find out information about an LSP. The Query message is sent for an established LSP. The Query message can be used for LDP LSPs as well as for CR-LSPs. The queried data is encoded into the Query-Reply message and partially into the Query Message. "Signaling Requirements at the Optical UNI", Osama Aboul-Magd, 07/20/2000, <draft-bala-mpls-optical-uni-signaling-00.txt> 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. "Functional requirements for the deployment of an IP VPN service offering", Christian Jacquenet, 07/20/2000, <draft-jacquenet-ip-vpn-needs-00.txt> This document aims at identifying the requirements which should be taken into consideration by a service provider, when considering the deployment of an IP VPN service offering. From this perspective, this document does not specify any technical means which could be used to deploy an IP VPN service offering, unlike the [VPN-FRAME] document. This document tries to express a service provider perspective, according to its own experience of IP-based service offerings, and to its own perception of the (constantly) evolving needs of the customers of such services. To some extent, this document can be viewed as a complementary taxonomy effort of the [TAXONOMY] draft. "iSCSI Security Protocol ", Eyal Felstaine, Yaron Klein, 07/20/2000, <draft-klein-iscsi-security-00.txt> The iSCSI Security Layer is an SSH based protocol for secure, iSCSI aware, network services over an insecure storage network. The protocol supports login, server authentication, integrity protection and encryption, thus enables application such as Virtual Private Storage Area Networks (VPSAN). Key exchange method, public key algorithm, symmetric encryption algorithm, message authentication algorithm, and hash algorithm are all negotiated. "An approach to enable directory transactions", Kannan Shivkumar, 07/20/2000, <draft-shivkumar-ldapext-dirtxn-00.txt> The directory is becoming an important part of the organization. As the data in the directory becomes more critical, it needs to be consistent. With more applications storing information in the directory, there is a need for transaction (atomic commit/rollback) services to be offered by the directory to ensure consistency. This document describes a mechanism to implement transaction service in a distributed replicated directory. It also describes the LDAP APIs that can be used to provide a standard interface for the transaction service. "Benchmarking Terminology and Methodology for Routers Supporting Resource Reservation ", Istvan Cselenyi, Gabor Feher, Krisztian Nemeth, 07/20/2000, <draft-feher-benchresres-00.txt> The purpose of this document is to define terminology and methodology specific to the performance benchmarking the resource reservation signaling capability of IP routers. In addition to defining the performance metrics and the tests, this document also describes specific formats for reporting the results of the tests. "Interoperability Test Profile", Brian Rosen, 07/20/2000, <draft-rosen-megaco-test-profile-00.txt> This document describes a profile for use in interoperability testing of the Megaco/H.248 protocol and a set of scenarios to try increasingly difficult mechanisms in the protocol. To support early phase testing, it is useful to define a simple, easy to implement set of characteristics that allow initial implementations to get very basic functions working. By implementing this profile, testing a variety of MGs against a variety of MGCs is possible. The test scenarios describe high-level behavior expected by the MGs and MGCs, but not explicit message sequences. Also included is a set of test messages that may be used to verify early stage MG/MGC functionality. They could be used to test parsers, and they can be used to assure that implementations have base functionality prior to testing with devices that may not produce the same messages. "Registration Revocation for Mobile IP", S. Glass, 07/20/2000, <draft-glass-mobileip-reg-revok-00.txt> During the original design of Mobile IP, the potential need for an administrative domain to be able to actively revoke a current Mobile IP registration was recognized. Due to the lack of a specific scenario requiring such a mechanism, it was decided that a passive mechanism, namely short registration lifetimes, and the denial of a subsequent registration from a MN, would be sufficient for this purpose. "Extensions to CR-LDP and RSVP-TE for setup of pre-established recovery tunnels", Loa Andersson, Fiffi Hellstrand, 07/20/2000, <draft-hellstrand-mpls-recovery-merge-00.txt> To protect an Explicit Routed Label Switched Path (ER-LSP) an explicitly routed LSP can be used as a recovery path. We consider a repair scheme where a Recovery LSP (R-LSP) spans one or several hops. After a switchover of traffic to the R-LSP we want to allow the traffic to merge onto the original LSP at the merging node downstream of the fault without causing any extra resource reservation. This merge operation differs in a number of details from that employed for a normal MP2P LSP. Our objective is to define extensions to both CR-LDP and RSVP-TE that address these differences. CR-LDP and RSVP-TE are defined in [CR-LDP] and [RSVP-TE], respectively, for path setup within a MPLS domain. In this draft we specify mechanisms required to support this merge. "Benchmarking Methodology for Devices Implementing Differentiated Services", Tony Bogovic, Sumit Khurana, Shobha Erramilli, 07/20/2000, <draft-khurana-bmwg-diffservm-00.txt> This document discusses and defines tests for performance characterization of network interconnect devices implementing support for Differentiated services. The metrics to be used for performance evaluation and the methodology for determining the metrics is explained, as also the format for reporting the results of the tests. It builds upon the test methodology described in RFC 2544. "Good Enough Header COmpression (GEHCO)", Tom Hiller, Peter McCann, 07/20/2000, <draft-hiller-rohc-gehco-00.txt> The Robust Header Compression Working Group has embarked upon the development and standardization of header compression schemes that perform well over links with high error rates and long round-trip times. The goal is that the schemes must perform well for cellular links built using technologies such as WCDMA, EDGE, and CDMA-2000. One way the group plans to achieve this is by maintaining connections with other standardization organizations developing cellular technology for IP, such as 3GPP and 3GPP-2, to ensure that its output fulfills their requirements and will be put to good use. Of particular importance to the 3GPP2 community is the spectral efficiency of IP/UDP/RTP header compression for the voice over IP application to mobiles. Currently, the ROHC Working Group is focusing on compression schemes where the uncompressed header is identical to the original header seen by the compressor. This may be categorized as transparent compression. Transparent compression results in additional header bytes being transported over-the-air. 3GPP2 carriers have indicated that no additional bytes may be transported over-the-air for voice over IP, that is, that voice over IP must have spectral efficiency comparable to legacy circuit transport over-the-air. This draft proposes a specific scheme, Good Enough Header Compression (GEHCO) that does not exactly reproduce the IP/UDP/RTP header, but is otherwise "VPN Masquerade Assist (VMA): An End-to-End Mechanism for Robust NAT Interoperation with IPSec's IKE and ESP Tunnel Mode", Jose Brustoloni, 07/20/2000, <draft-brustoloni-vma-00.txt> Linux's NAT (Network Address Translator) implementation is called IP Masquerade. Its "Stateless Prioritized Fair Queueing", R. Barnes, Jayanth Mysore, N Venkitaraman, R Srikant, 07/20/2000, <draft-venkitaraman-diffserv-spfq-00.txt> This document proposes a Per Hop Behavior(PHB) in the context of diffserv. We first propose a labeling procedure for the ingress router that labels packets in a manner that implicitly conveys the packet arrival rate information of each flow to the core router. Coupled with a simple forwarding procedure, this provides a fair allocation of bandwidth. We then propose other labeling procedures that add little computational complexity, but provide weighted fair allocation, minimum bandwidth assurances and support for intra-flow priorities. By appropriately designing the labeling algorithms, this PHB can be used to optimize the performance of a variety of flows. "LDP Extensions for Optical User Network Interface (O-UNI) Signaling", Osama Aboul-Magd, 07/20/2000, <draft-aboulmagd-mpls-ldp-optical-uni-00.txt> General requirements for signaling across the Optical UNI (O-UNI) are discussed in [1]. This draft describes extensions to the LDP protocol [2] to support those requirements. The LDP extensions described here address two areas: - The addition of new TLVs to support the attributes required for lightpath establishment at the O-UNI - Two new LDP messages to allow for the exchange of lightpath status information across the UNI. The content of this draft is expected to evolve as work progresses on the optical UNI. This draft is a work in progress. "Host Capability Negotiation: The RSVP HCAP Object", Y. Bernet, Syed Hamid, 07/20/2000, <draft-hamid-issll-hcap-00.txt> The DCLASS object is proposed in [DCLASS] to represent and carry Diffrentiated Services Code Points (DSCPs) within RSVP messages. The principle use of the DCLASS object is to carry DSCP information between a DS network and upstream nodes that may wish to mark packets with DSCP values. A network element in the DS network determines the value for DSCP which is further carried as a DCLASS object in RSVP RESV message to the sender host. "Handling BLSR with MPLS Traffic Engineering", Suresh Katukam, 07/20/2000, <draft-katukam-blsr-te-00.txt> This document outlines procedures needed when applying MPLS TE Control Plane to SONET/SDH Cross-Connects that use BLSR. "EF PHB Redefined", Anna Charny, 07/20/2000, <draft-charny-ef-definition-00.txt> This document proposes text aiming at providing clarification to RFC 2598. The primary motivation for this draft is that the definition of EF PHB given in RFC 2598 does not match the intuition of the EF PHB, and has been determined to be unimplementable in a manner compliant with the definition. In particular, no work-conserving scheduler, including all of the schedulers listed in the Implementation Examples section of RFC 2598, can comply with the definition given in that RFC. This draft gives a rigorous definition of EF PHB which in our opinion preserves the spirit of the EF PHB as intended by RFC 2598 while allowing a number of reasonable compliant implementations. The document also provides implementation guidance and lists several possible implementation examples which conform to the definition given in this draft. "Generalized GPS Extension (GGPSE)", Pat Calhoun, Emad Qaddoura, Haseeb Akhtar, M Khalil, 07/20/2000, <draft-mkhalil-mobileip-ggpse-00.txt> The Mobile IP Working Group is considering proposals to provide fast hand-off capabilities to the Mobile IP protocol. It is important that such proposals do not require usage additional bandwidth, such as required by frequent mobility agent advertisements. This specification allows a mobility agent to provide its coverage area, and the location of neighboring cells, allowing the Mobile Node to determine when it must initiate a hand-off. "A URN Namespace for Norman Walsh", Norman Walsh, 08/25/2000, <draft-nwalsh-urn-ndw-01.txt> This document describes a URN namespace that is engineered by Norman Walsh for naming personal resources such as XML Schema Namespaces, Schemas, Stylesheets, and other documents "Result Message for LDAP Controls", Michael Armijo, 07/20/2000, <draft-armijo-ldap-control-error-00.txt> LDAPv3 [1] allows for the extension of the protocol through the use of controls. These controls allow existing operations to be enhanced to provide additional functionality for directory operations. Complex controls are being established that are bringing up error conditions not anticipated in the LDAPv3 specifications. The purpose of this draft is to create new result codes specific to LDAP controls and to define guidelines for the use of these result codes. "Providing Quality of Service Indication by the BGP-4 Protocol: the QOS_NLRI attribute", Christian Jacquenet, 07/20/2000, <draft-jacquenet-qos-nlri-00.txt> For almost the last decade, value-added IP service offerings have been massively deployed over the Internet, thus yielding a dramatic development of the specification effort, as far as quality of service (QOS) in IP networks is concerned. Nevertheless, providing end-to-end quality of service by crossing administrative domains still remains an issue, mainly because: - quality of service policies may dramatically differ from one service provider to another; - the enforcement of a specific quality of service policy may also differ from one domain to another, although the definition of a set of basic and common quality of service indicators may be shared between the service providers. "Framework of COPS-PR Policy Information Base for Accounting Usage", Kwok Chan, Diana Rawlins, D Dutt, Amol Kulkarni, 07/21/2000, <draft-rawlins-acct-fr-pib-00.txt> This document establishes a flexible PIB framework for accounting. The accounting framework accommodates usage related data for accounting purposes needed for a wide variety of emerging technologies. The framework is re-usable and can be extended with additional accounting PIB modules to make it specific to certain client types. This document also contains examples of an accounting framework PIB module and an accounting PIB for diffserv. "Flooding optimizations in link-state routing protocols", M. Shand, Alex Zinin, 10/10/2000, <draft-zinin-flood-opt-01.txt> 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. "Calling Line Identification for VPIM Messages", Derrick Dunne, 07/21/2000, <draft-ema-vpim-clid-00.txt> This document describes a method for identifying the originating party of a VPIM message. "Framework Draft for Networked Appliances Using the Session Initiation Protocol", Stanley Moyer, 07/21/2000, <draft-moyer-sip-appliances-framework-00.txt,.ps> This document proposes the use of SIP for Network-capable appliances. It leverages the standard SIP capabilities to directly communicate with appliances even when they are behind firewalls, NATs or other entities that prevent direct end-to-end communication. When combined with the recently proposed Instant Messaging and Presence SIP extensions these techniques become even more powerful. "Policy-based Accounting ", Georg Carle, Sebastian Zander, Tanja Zseby, 07/21/2000, <draft-irtf-aaaarch-pol-acct-00.txt> This draft describes policy-based accounting which is aimed at the provisioning of flexibility for accounting architectures. Accounting policies describe the configuration of an accounting architecture in a standardized way. They are used to instrument the accounting architecture and can be exchanged between AAA entities in order to share configuration information. This draft describes building blocks and message sequences for policy-based accounting in AAA. Examples are given for the usage of accounting policies in different scenarios. Furthermore it is shown how accounting components can be integrated into the authorization framework. This draft does not propose a language for the description of accounting policies. It is rather assumed that a suitable policy language can be chosen from existing or upcoming standards. "The Isakmp Attribute Exchange Mode", Andrew Krywaniuk, 07/21/2000, <draft-krywaniuk-ipsec-attribute-exchange-00.txt> This document describes a simple method for exchanging attributes with the peer. "6to4-relay discovery and scaling ", Tony Hain, 07/21/2000, <draft-hain-6to4-scaling-00.txt> The mechanism for 6to4-router scaling described in the 6to4 draft [2][6to4] raises concerns when the matrix of IPv4 connected systems, communicating across to the native IPv6 connected systems, are on the order of tens to hundreds of millions. This document will address those concerns, offer additional mechanisms for resolving them, and identify the scenario for link-local addressing postulated in section 3.1. "Implementation Experience with APPID in Identity Policy Element", Ramesh Pabbati, Ralph Santitoro, 07/21/2000, <draft-santitoro-rap-policy-appids-00.txt> The identity policy element (PE) is part of the Policy Data Object [RFC 2750] which may be included in RSVP [RFC 2205] signaling messages. Policy elements with a P-type of AUTH_APP are used to identify applications and their attributes as defined in [RFC 2752]. "Implementation Experience with Policy Error Object in Identity Policy Element ", Ramesh Pabbati, Ralph Santitoro, 07/21/2000, <draft-santitoro-rap-policy-appids-00.txt> This document defines two new ErrorValues for the Policy Error Object, which is part of the Policy Data object [RFC2752]. These new ErrorValues are being defined because the ErrorValues defined in RFC 2752 are not extensive enough for a Policy server(PDP) to control application data flows. Hence this draft is defining two new ErrorValues to provide the host with additional information on the error that caused the RSVP reservation failure. "Generic Packet Tunneling in IPv6 - Bi-directional Tunneling Specification", A. Conta, 07/21/2000, <draft-conta-extensions-ipv6-tunnel-00.txt> This document defines extensions to the model and generic mechanisms specified in 'Generic Packet Tunneling in IPv6' [IPv6-TUNNEL]. These extensions apply specifically to bi-directional IPv6 tunnels. "IP Broadcast in Ad hoc Mobile Networks ", C Perkins, Elizabeth Royer, S Das, 07/21/2000, <draft-perkins-manet-bcast-00.txt> An ad hoc mobile network is a collection of nodes, each of which communicates over wireless channels and is capable of movement. Nodes participating in such an ad hoc network communicate on a peer-to-peer basis. Broadcast is often a desired form of communication in these networks, as it can enable both the dissemination of control information and the delivery of data packets. This document describes a method for providing broadcast communication in ad hoc networks. "IP Address Autoconfiguration for Ad Hoc Networks", C Perkins, Elizabeth Royer, S Das, 07/21/2000, <draft-perkins-manet-autoconf-00.txt> If a node lacks an IP address, it cannot yet participate in ad hoc networks as currently designed, because the connectivity in an ad hoc network is typically determined by mechanisms that depend upon using the IP address as the identifier for the nodes in the ad hoc network. In this document, we specify a mechanism by which a node in an ad hoc network may autoconfigure an IP address which is unique throughout the connected portion of the ad hoc network. "6to4 and DNS", Keith Moore, 07/21/2000, <draft-moore-6to4-dns-00.txt> This memo discusses several potential mechanisms for locating the DNS servers which provide 'reverse address lookup'of 6to4 addresses. Please note that this is a preliminary draft which only attempts to outline possible means of solving the problem, for purpose of discussion. This version of the proposal is NOT rigorously specified, and the author does not claim significant DNS expertise. Nevertheless, it is hoped that the proposal is significantly detailed to allow reviewers to make a first-order assessment of its viability. The assistance of a DNS expert in drafting future revisions of this proposal would be most welcome. "RTCP-based Feedback for Predictive Video Coding", Joerg Ott, Stephan Wenger, 07/21/2000, <draft-wenger-avt-rtcp-feedback-00.txt> Predictive video coding is not loss resilient. Any loss of coded data leads to annoying artifacts not only in the reproduced picture in which the loss occurred, but also in subsequent pictures. Error resilience can be achieved by spending bits to convey redundant information using source coding based mechanisms or transport based mechanisms. This can be done without the use of any feedback between the decoder(s) and the encoder. "LDAPv3 Data Model Definitions", M. Wahl, 07/21/2000, <draft-wahl-ldapv3-defns-00.txt> The Lightweight Directory Access Protocol (LDAP) is based on an underlying data model which is derived from X.500(1993). The data model is visible to LDAP clients through protocol interactions. This document defines the terms and their relationships which form the LDAPv3 data model. "IPSEC Policy Architecture", F Cuervo, Abdallah Rayhan, 07/21/2000, <draft-cuervo-ipsp-arch-00.txt> This document proposes an architecture for IPSec policy. The proposed architecture follows the functional decomposition of the policy frame- work [1]. The architecture addresses the mechanisms to facilitate the dynamic exchange of policy between the various architectural components. The issues discussed here covers the mechanisms for establishing IPSec route across multiple policy gateways through policy negotiation. This draft shall serve as a guideline for further development of IPSec Pol- icy. "IP VPN Policy Information Model", Mahadevan Iyer, R Kale, L Apsani, 07/24/2000, <draft-iyer-policy-ipvpn-info-model-00.txt> This document represents the object oriented information model for representing policy information associated with provisioning IP VPN services such as firewall, address translation, quality of service, encryption. This draft extends the core policy information model to cover the policies that need to be enforced to configure IP VPN services mentioned earlier. The information model defined in this document is independent of any implementation specifics related to the repository used to store the policy information. "IP Forwarding PIB", Hormuzd Khosravi, 07/24/2000, <draft-khosravi-ip-fwd-pib-00.txt> This document describes an IP Forwarding PIB. This document is based on the IP Forwarding Table MIB [RFC 2096]. "AAA Requirements for IP Telephony/Multimedia", Pat Calhoun, Matt Holdrege, James Kempf, Henrik Basilier, Tony Johansson, 07/24/2000, <draft-calhoun-sip-aaa-reqs-00.txt> 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. "IP over Optical Networks: A Summary of Issues", N Chandhok, 07/24/2000, <draft-osu-ipo-mpls-issues-00.txt,.ps> This draft presents a summary of issues related to transmission of IP packets over optical networks. This is a compilation of many drafts presented so far in IETF. The goal is to create a common document, which by including all the views and proposals will serve as a better reference point for further discussion. The novelty of this draft is that we try to cover all the main areas of integration and deployment of IP and optical networks including architecture, routing, signaling, management, and survivability. "iSCSI/VI/TCP proposal", Costa Sapuntzakis, 07/24/2000, <draft-csapuntz-ips-iscsivi-00.txt> The iSCSI contributors are currently considering the framing/delimiting of iSCSI messages in a TCP stream, especially with an eye towards being able to process segments in a TCP stream out-of-order. "Intercepting Location Updates", C.J. Lee, Glenn Morrow, Fayaz Kadri, 07/24/2000, <draft-lmk-mobileip-intercepting-update-00.txt> The base Mobile IP allows a host to transparently send datagrams to mobile nodes as it would to any other nodes. Datagrams addressed to the mobile are always routed via the Home Agent in the home network. However, as the mobile node moves away from its home network, it may no longer be topologically close to its home agent. Route optimization [MIP-OPTIM] has been proposed to allow a host to send packets to the mobile as a mobile node (MN) moves, without having to route the packets via the home agent each time. The mobile provides its current address to a host (or correspondent node, CN) that it is communicating with as it moves. The host updates the cache of the mobile location with this new address and tunnels datagrams (addressed to the mobile) to the current address of the mobile. However not all correspondent nodes are capable of tunneling IP datagrams as required by the route optimization mechanisms described in [MIP-OPTIM]. More importantly, disclosing the current location (or COA) of the mobile node to correspondent nodes is not always desirable, nor is the overhead of encapsulating datagram to the MN ideal. "Unique Features and Requirements for The Optical Layer Control Plane", John Strand, A. Chiu, 07/24/2000, <draft-chiu-strand-unique-olcp-00.txt> Advances in the Optical Layer control plane is critical to ensure tremendous amount of bandwidth generated by the DWDM technology be provided to upper layer services in a timely, reliable, and cost effective fashion. This document describes some unique features and requirements for the Optical Layer control plane that protocol designers need to take into consideration "TRIP Transit Network Selection", Dave Walker, To Do, Li Li, J Jiang, 07/24/2000, <draft-walker-iptel-trip-tns-00.txt> Conventional telephony signalling commonly uses E.164 addresses to route calls to their destination. However, selection of the signalling and media paths can be influenced by other considerations. Some such considerations may be user specified, and may differ from that which the network operator would normally choose. In some cases, support for such user-specified options may be required by national regulation. The choice of Transit Network (e.g. selection of long distance carrier) is such a case. This draft describes three ways that a Transit Network Selection (or TNS) mechanism can be added to the TRIP protocol. "S/MIME Version 3.1 Certificate Profile Addendum ", B. Ramsdell, 07/24/2000, <draft-ramsdell-smime31-cert-00.txt> In light of the expiration of the primary RSA patent, it is proposed that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST implement algorithms in the S/MIME profile. This draft will describe only the proposed changes to the S/MIME Version 3 Certificate Handling RFC [SMIMEV3CERT], and the rest of that RFC will remain identical. "S/MIME Version 3.1 Message Specification Addendum", B. Ramsdell, 07/24/2000, <draft-ramsdell-smime31-msg-00.txt> In light of the expiration of the primary RSA patent, it is proposed that the RSA algorithm replace the DSS and Diffie-Hellman as the MUST implement algorithms in the S/MIME profile. This draft will describe only the proposed changes to the S/MIME Version 3 Message Specification RFC [SMIMEV3MSG], and the rest of that RFC will remain identical. "Control Mechanisms for Traffic Engineering in Optical Networks", Jin-Ho Hahm, Mark Carson, KWANG IL LEE, 07/24/2000, <draft-hahm-te-optical-00.txt> WDM-based optical networks are becoming the core networks of the Internet transport infrastructure because of the plentiful bandwidth capacity they offer and their potential for real-time provisioning of bandwidth on demand. "Quality of Service Support in an OBAST Architecture", Steven Gilbert, Matthew Needham, Phillip Neumiller, 07/24/2000, <draft-needham-obast-qos-00.txt> This document outlines some of the fundamental requirements and issues related to the control and maintenance of quality of service (QoS) in an Open Base Station Transport (OBAST) architecture. It begins with a review of a baseline OBAST architecture, highlighting those elements that are particularly relevant to QoS provisioning, then discusses the requirements for QoS within this framework. In particular, the requirements for control and maintenance of QoS during mobility handoffs, and for support of adaptive applications, is addressed. "Simple Multicast Mobility Protocol (SMM)", Vincent Magret, Laurence Rose, 07/24/2000, <draft-rose-mobileip-smm-00.txt> The Simple Multicast Mobility Protocol (SMM) defines extensions and changes to Mobile IP [RFC2002] to extend the service offered by this protocol. The new features allows a new support of smooth handoffs. The service allows the support of both macro and micro mobility. The goal of the protocol is extend the services of mobile IP to cope with requirement coming from 'real-time' applications such a voice over IP. "P-MIP: Minimal Paging Extensions for Mobile IP", Andrew Campbell, X Zhang, J Castellanos, K Sawada, M Barry, 07/24/2000, <draft-zhang-pmip-00.txt> As the number of Mobile IP users grow so will the signaling overhead on the core IP network in support of mobility management. In cellular networks registration and paging techniques are used to minimize the signaling overhead and optimize the mobility management performance. Currently, Mobile IP supports registration but not paging. We believe that Mobile IP support for paging is important to improve the scalability of Mobile IP networks. Recently, a number of micro- mobility protocols [8] have been proposed that have built-in paging functions. These micro-mobility protocols are independent of the base Mobile IP protocol and interwork with Mobile IP [2] through mobile gateways. We take a different approach and propose a minimal set of paging extensions to the base Mobile IP called P-MIP. P-MIP is designed to reduce signaling load in the core Internet and power consumption of mobile nodes. In this draft, P-MIP, which assumes the use of foreign agents, is described and the construction of paging areas, movement detection, registration, paging and data handling are presented. "Notes on Path Computation in Constraint-Based Routing ", Daniel Awduche, Kireeti Kompella, 07/24/2000, <draft-kompella-te-pathcomp-00.txt> This draft presents some notes on Constraint-Based Routing. The main purpose is to standardize the terminology used, and define the semantics of the various constructs used in Constraint-Based Routing so that implementations from a wide variety of vendors will have (at least to the first order) similar results in path selection. A secondary goal is to define the semantics of optimization, which we define as the recalculation of routes that have already been computed and established. "Local Mobility Agents in IPv6", Kent Leung, G Dommety, Madhavi Subbarao, Raj Patil, 10/18/2000, <draft-dommety-mobileip-lma-ipv6-02.txt> Mobile IPv6 is better integrated into IPv6, thereby obviating the need for Foreign Agents (FA) in IPv6 [5]. In IPv6 most, if not all, ofthe functions of the Mobile IPv4 FA [1] are assumed by other parts of the Mobile IPv6 architecture. Specifically, all routers send Router Advertisements and the Mobile Node (MN) does its own detunneling and Routing Header processing. "QoS Architecture Based on Differentiated Services for Next Generation Wireless IP Networks", Jyh-Cheng Chen, 07/24/2000, <draft-itsumo-wireless-diffserv-00.txt> This document presents a QoS architecture framework with preliminary protocol specifications for next generation wireless IP networks. The architecture is based on differentiated services in that traffic are aggregated and forwarded in backbone network based on per hop behaviors. In the proposed architecture, there is at least one global server and several local nodes in each administration domain. The server is referred to as the QoS Global Server (or QGS), and local nodes are referred to as QoS local nodes (or QLN). QLNs are ingress nodes of the DS (Differentiated Service) domain. They reside generally in the edge of wired backbone networks. The QGS retains the global information of the domain, and informs QLNs what to do when traffic comes in. The mobile station (MS) has the QoS signaling with QGS only. Once the QoS signaling is done, the QGS updates the QoS profile in each QLN. The MS is then free to move within the same domain without other QoS signaling. The actual traffic generated by MS goes through QLN only. The QGS is in control plane and QLNs are in transport plane. By retaining the global information in central server and separating control and transport, the architecture is flexible, easy to add new services, and more efficient for mobile environment. "Triple-DES Support for the Kerberos 5 GSSAPI Mechanism", Kenneth Raeburn, 07/24/2000, <draft-raeburn-cat-gssapi-krb5-3des-00.txt> The MIT Kerberos 5 release version 1.2 includes support for triple-DES with key derivation [KrbRev]. Recent work by the EFF [EFF] has demonstrated the vulnerability of single-DES mechanisms to brute-force attacks by sufficiently motivated and well-funded parties. The GSSAPI Kerberos 5 mechanism definition [GSSAPI-KRB5] specifically enumerates encryption and checksum types, independently of how such schemes may be used in Kerberos. In the long run, a new Kerberos-based mechanism, which does not require separately enumerating for the GSSAPI mechanism each of the encryption types defined by Kerberos, appears to be a better approach. Efforts to produce such a specification are under way. "Multiple Virtual Router Partitioning Policy Information Base", Todd Anderson, 07/24/2000, <draft-anderson-mvr-pib-00.txt> This document defines a Policy Information Base (PIB) for partitioning a single switch into a set of virtual switches. ([SPPI] describes a structure for specifying policy information that can then be transmitted to a network device for the purpose of configuring policy at that device. The model underlying this structure is one of well defined policy rule classes and instances of these classes residing in a virtual information store called the Policy Information Base (PIB).) The partitioning PIB defined here is largely based on the Base Switch Partitioning MIB (MSF 00.069) [MSF-VSMIB]. However, unlike that MIB, this document does not provide a management interface for the switch as a whole but instead only specifies the ports and resources assigned to virtual switches. The management interface(s) to discover switch resources as a whole are outside the scope of this document. "Buffer Management for Smooth HandOvers in Mobile IPv6 ", C Perkins, Govind Krishnamurthi, Robert Chalmers, 07/24/2000, <draft-krishnamurthi-mobileip-buffer6-00.txt> An important issue to consider when supporting real-time applications like VoIP in mobile networks is the capability to provide smooth handoffs. A critical requirement for smooth handoffs is to minimize packet loss as a mobile node (MN) transitions between network links. This document defines a buffering mechanism for Mobile IPv6 by which an MN can request that the router on its current subnet buffers packets on its behalf while the MN completes registration procedures with the router of a new subnet. Once the registration is complete and the MN has a valid care-of address in the new network, the buffered packets can be forwarded from the previous router, thus reducing the possibility of packet loss during the transition. "IDMP: An Intra-Domain Mobility Management Protocol using Mobility Agents ", Anthony McAuley, Archan Misra, Ashutosh Dutta, Subir Das, Sajal Das, 07/24/2000, <draft-misra-mobileip-idmp-00.txt> This document introduces IDMP, a mobility protocol that supports routing of datagrams to a mobile node inside a mobility domain. A mobility domain essentially identifies a collection of IP subnets and networks that are aggregated together based on factors such as geographic proximity or administrative control. In addition to supporting basic redirection of packets to mobile nodes, IDMP also provides fast handoff support, with minimal packet losses due to mobility-related transients, and paging support to reduce the signaling burden on mobile nodes. IDMP uses two care-of addresses to manage mobility. The global care-of address identifies the mobile's current domain and remains unchanged as long as the mobile does not change domains. The local care-of address identifies the mobile's current point of attachment and changes every time a mobile node changes subnets. IDMP specifies two types of agents, Subnet Agents and Mobility Agents, to support this two-layer mobility hierarchy. By using two care-of addresses , IDMP removes the need for host-specific routing inside the domain and allows the use of multiple alternative protocols for supporting global mobility. "Exclusion Extension for Service Location Protocol v2", Michael Day, 07/24/2000, <draft-day-svrloc-exclusion-00.txt> The Service Location Protocol, Version 2 [1] allows the use of multicast discovery requests. Multicast discovery requests provide a fast way for an agent to discover services with no prior knowledge other than the service type. However, multicast discovery requests may need to be recast in order to ensure a complete set of discovery responses. When this is the case, it is useful to suppress duplicate responses. "Mobile IPv6 Regional Registrations", C Perkins, Jari Malinen, 07/24/2000, <draft-malinen-mobileip-regreg6-00.txt> This document describes Mobile IPv6 regional registration as an optional extension to Mobile IPv6. Regional registration introduces visited-domain mobility agent functionality for proxying a public care-of-address which remains the same while the mobile node moves in the visited domain. This reduces the binding update signaling latency for the mobile node and signaling load outside the visited domain. The protocol defines regional mobility capability negotiation, regional binding update signaling, and regional-aware data routing through a hierarchy of visited-domain mobility agents. The protocol allows for an arbitrary point in the visited-domain hierarchy to distribute the connection-state maintenance between several mobility agents. IPSec AH is used for securing the protocol as in basic Mobile IPv6. "Forward Secrecy Extensions for OpenPGP", Ben Laurie, Ian Brown, Adam Back, 08/25/2000, <draft-brown-pgp-pfs-01.txt> The confidentiality of encrypted data depends on the secrecy of the key needed to decrypt it. If one key is able to decrypt large quantities of data, its compromise will be disastrous. This memo describes three methods for limiting this vulnerability for OpenPGP messages: reducing the lifetime of confidentiality keys; one-time keys; and the additional use of lower-layer security services. "Traffic Engineering with Unnumbered Links", Y Rekhter, Kireeti Kompella, 09/28/2000, <draft-kompella-mpls-unnum-02.txt> Current signalling used by MPLS TE doesn't provide support for unnumbered links. This document defines procedures and extensions to the MPLS TE signalling that are needed in order to support unnumbered links. "OSPF Transient Blackhole Avoidance", Danny McPherson, Tony Przygienda, 07/24/2000, <draft-mcpherson-ospf-transient-00.txt> This document describes a simple, interoperable mechanism that can be employed in OSPF networks in order to decrease data loss associated ith deterministic blackholing of packets during transient network conditions. The mechanism proposed here requires no OSPF protocol changes and is completely interoperable with the existing OSPF specification. "Header Compression State Relocation in IP Mobile Networks", Rajeev Koodli, 07/24/2000, <draft-koodli-rohc-hc-relocate-00.txt> In networks with limited bandwidths, such as wireless cellular networks, compression of IP and transport headers may be employed to obtain better utilization of the available spectrum capacity. When header compression is used along with handoffs in such networks, the header compression context needs to be relocated from one IP access point (i.e., a router) to another in order to achieve seamless operation. In this document, we propose a mechanism to achieve this compression context relocation using IPv6 and Mobile IPv6. "Internet Concast Service ", K. Calvert, James Griffioen, 07/24/2000, <draft-calvert-concast-svc-00.txt> Concast is a many-to-one best-effort network service that allows a receiver to treat a group of senders as a single entity, in much the same way that IP multicast allows a sender to treat a group of receivers as one. Each concast datagram delivered to a receiver is derived from (possibly many) datagrams sent by different members of the concast group to that receiver, according to a 'merge specification'. Concast allows the semantics of this merging operation to vary to suit the needs of different applications. This document describes the concast service and presents a framework for defining merge semantics. It also describes the processing of concast datagrams by concast-capable routers and hosts. The concast signaling protocol (CSP), an integral part of the concast service, is specified in a separate document. "Policy-Based Differentiated Services on AIX", Ashish Mehra, 07/25/2000, <draft-mehra-diffserv-aix-00.txt,.ps> This draft presents a policy-based Differentiated Services [DSARCH] architecture that has been realized on the AIX operating system. We briefly motivate the benefits of supporting DiffServ functions on servers using policy-based networking, and outline the requirements for DiffServ-enabled servers. We then describe the policy-based DiffServ infrastructure we have developed for AIX. Experimental results using Web server workloads demonstrate the efficacy of the DiffServ mechanisms provided. We also outline ongoing work in deploying diffserv-capable AIX servers on Internet2. "RTP Payload Format for SONET over IP ", Jim Boyle, Gregory White, 07/25/2000, <draft-white-sonet-format-rtp-00.txt> This memo describes the mapping of a SONET payload into an RTP payload. This will be useful when providing a SONET path level service between IP end points. The SONET payload is extracted and inserted into a RTP packet 8000 times a second. This document describes the RTP header fields usage and is meant for use by implementers of SONET to IP codecs. "OSPF Stub Router Advertisement", Alvaro Retana, Danny McPherson, Alex Zinin, Russ White, Liem Nguyen, 07/25/2000, <draft-zinin-ospf-stub-adv-00.txt> In some cases, it is desirable not to route transit traffic via a specific OSPF router. However, OSPF [RFC2328] does not specify a standard way to accomplish this. This memo describes a backward- compatible technique that may be used by OSPF implementations to advertise unavailability to forward transit traffic or to lower the preference level for the paths through such a router. "TIFF-FX Extensions 1 ", L. McIntyre, Dave Abercrombie, William Rucklidge, 07/25/2000, <draft-mcintyre-fax-tiff-fx-extension-00.txt> This document is an internet draft for extensions to TIFF-FX [RFC XXXX], extension set 1. This draft describes extensions to RFC XXXX to enable new features or conditions to TIFF-FX. The features are described by a set of guidelines for all TIFF-FX extensions, and a set of 5 extension types which enable: increased resolutions and image widths, expanding Profile M from 3 layers to N layers, the use of shared resources as a general mechanism for sharing data across images and pages, a binary profile for JBIG2 coding, and an extension to Profile M for JBIG2 and colour tag coding. 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 <http://www.ietf.org/ipr.html>. "VI / TCP (Internet VI)", James Williams, Stephen DiCecco, 07/27/2000, <draft-dicecco-vitcp-00.txt> The Virtual Interface (VI) architecture [VIAR] describes a high performance design for interfacing distributed applications to accelerated protocol processing. VI seeks to improve the performance of such applications by reducing the latency and overheads associated with standard communications protocol stack processing. VI greatly reduces the processing overhead associated with traditional network architectures by providing applications a protected, directly accessible interface to network hardware - a Virtual Interface. This memo describes extensions to the VI Architecture designed to facilitate operation over TCP/IP. These extensions take the form of enhancements to the VI Provider Library API defined in the VI Architecture Developer's Guide [VIDG], and a 'VI Protocol' which supports VI functionality during operation over TCP/IP. The extensions to the VI Architecture which support operation over TCP/IP are intended to be fully compliant with the VI Architecture [VIAR] and its associated Developer's Guide [VIDG]. "Test Specification for MTP2 User Adaptation ", Sunil Mahajan, Sachin Jindal, 08/07/2000, <draft-mahajan-test-spec-m2ua-00.txt> This document presents the test specification for M2UA (MTP2 User Adaptation) prototcol (ver 03), which can be used to test M2UA implementations for conformance to the protocol definition. The list of test is exhaustive and covers almost all the categories of test. This draft can also be used in conjunction with M2UA specification by implementor of protocol as implementors guide, as the pictorial representation of various scenarios help easy understanding of the protocol. Next revision of the draft will cover the additions done to the protocol revision M2UA-04 and any subsequent RFC published by IETF. "ACCORD mobile multi-segment system: IP over ATM performance and QoS trial results evaluation ", Clementina Tocci, P Conforto, G Losquadro, 08/07/2000, <draft-tocci-ip-over-atm-00.txt> This document reports upon the ACCORD Trial activity which aims at investigating support of TCP/IP over mobile multi-segment system. IP based applications and IP over ATM measurements have been executed in order to obtain significant information about intersegment service mobility. "An Extended QoS Architecture Supporting Differentiated Resilience Requirements of IP Services", Andreas Kirstaedter, 08/07/2000, <draft-kirstaedter-extqosarch-00.txt> This document proposes an extension of the Quality of Service (QoS) architecture to support differentiated resilience requirements of IP services. Several architectures offering Quality of Service in IP-based networks are defined by the IETF community. The two most important of them are the Integrated Services (IntServ) model with the Resource Reservation Protocol (RSVP) as the recommended signaling protocol and the Differentiated Services (DiffServ) model. Recently, Multiprotocol Label Switching (MPLS) emerged introducing extended traffic engineering methods into IP and therefore also may support QoS. Due to the growing commercial importance of the Internet and the transport of mission-critical services, survivability became a main service requirement in addition to the traditional QoS. "SIP Servlet Delivery", Mick O''Doherty, 08/07/2000, <draft-odoherty-sip-servlet-delivery-00.txt> This document defines an extension to the SIP [2] protocol to combine some of the concepts introduced by the SIP Servlet API work [3] and by Java Enhanced SIP [4] "RFC1858 is not water-tight", Ian Miller, 08/07/2000, <draft-miller-rfc1858-cmts-00.txt> RFC1858 compliant filters can be vulnerable to a variant of the 'Tiny Fragment Attack' described in section 3.1 of the RFC. This document describes the attack and recommends corrective action. "EntrySelection control for LDAP modify and delete operations on multiple entries", S Haripriya, 08/28/2000, <draft-haripriya-ldapext-entryselect-01.txt> This document defines an LDAPv3 control that can select multiple entries in a subtree of a container entry for modification or deletion. This control extends the scope of the LDAPv3 modify and delete operations as defined in [RFC 2251]. This control is useful for modifying or deleting multiple entries on the basis of a single selection criterion. This may be useful for maintenance of an LDAP directory having a large number of objects. Example of Usage - This control can be used by client applications who have the need to modify or delete a large number of entries in an LDAP directory based on a selection criterion. One example of such a usage is when two departments in an organization merge. In this case the 'department' name or number given to a number of employees need to change, and all the employees in a given department are to be assigned the new 'department'. Here the EntrySelection control can be used to select the entries to be modified based on the 'department' value, and the modify operation can change the 'department' value for all the selected entries to the given value. "A simpler EF PHB Redefinition", Stefano Salsano, 08/07/2000, <draft-salsano-simpler-ef-00.txt> This document proposes text aiming at providing clarification to RFC 2598. As explained in [CHA], the primary motivation is that the definition of EF PHB given in RFC 2598 does not match the intuition of the EF PHB, and has been determined to be unimplementable in a manner compliant with the definition. [CHA] gives a new rigorous definition of EF PHB, using a recurrence equation that determines a bound for time at the which a packet must exit the node, given that the arriving times and the exit times of all packets are recorded. "An approach to enable directory transactions",, 08/07/2000, <draft-shivkumar-ldapext-dirtxn-00.txt> The directory is becoming an important part of the organization. As the data in the directory becomes more critical, it needs to be consistent. With more applications storing information in the directory, there is a need for transaction (atomic commit/rollback) services to be offered by the directory to ensure consistency. This document describes a mechanism to implement transaction service in a distributed replicated directory. It also describes the LDAP APIs that can be used to provide a standard interface for the transaction service. "Alarm MIB", Sharon Chisholm, 10/23/2000, <draft-chisholm-disman-active-alarm-01.txt> This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for maintaining a list of alarms currently active on a network element. "Using the SRP protocol as a key exchange method in Secure Shell ", Niels Moller, 08/08/2000, <draft-nisse-secsh-srp-00.txt> This memo describes an experimental method for authentication and keyexchange in the Secure Shell protocol. The main virtue of the SRP protocol [SRP] is that it provides authentication based on a small secret (typically a password). It is useful in situations where no authentic host key is known. For Secure Shell, it can be used as a bootstrapping procedure to get the host key of a server in a safe way. SRP also provides authentication of the user, which means that it might make sense to skip the secsh 'ssh-userauth'-service [SSH-USERAUTH] when using SRP. "Voice Messaging IMAP Client Behaviour", Glenn Parsons, Derrick Dunne, 08/08/2000, <draft-ema-vpim-cb-00.txt> This document defines the expected behaviour of an IMAP client to various aspects of a VPIM message. "SIP extension for tracking locations attempted ", David Oran, H. Schulzrinne, 08/08/2000, <draft-oran-sip-visited-00.txt> Proxying hides the destinations tried by the proxy. Since this information is sometimes useful to the requestor, this draft proposes a new optional SIP request header called Contacts-Tried listing the locations tried unsuccessfully during a search. "Root SIP Servlet", Mick O''Doherty, 08/08/2000, <draft-odoherty-root-sip-servlet-00.txt> This Internet draft builds on and refines the SIP Servlet API defined in [3]. The SIP Servlet API defines an API for SIP Clients that allows them, via a SIP Servlet engine, present messages to 'Servlets' which can then interact with the message and the Client to change the behavior of the CIP Client. "Radius Security Extensions using Kerberos v5", N Kaushik, 10/09/2000, <draft-kaushik-radius-sec-ext-04.txt> This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a Authentication and Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC2138 and RFC2139. "Multicast Domain Name Service", Bill Manning, Bill Woodcock, 08/08/2000, <draft-manning-dnsext-mdns-00.txt> This document describes a method by which DNS resolvers may reach multicast-capable DNS servers which may exist within a multicast local scope, by issuing a single UDP query to a static multicast address. "HTTP Authentication: Third-Party Authentication", James Smith, 08/09/2000, <draft-smith-http-third-party-authentication-00.txt> Existing HTTP authentication schemes require knowledge of the secret used to establish the client's identity be known in some manner by the site requiring the authentication. Some situations exist in which a site has a legitimate reason to authenticate a client but cannot be trusted with the information required to authenticate that client. The authentication scheme defined in this document allows a site to authenticate a client via a trusted third-party. "Scored Fair Metric Calculation", Spencer Giacalone, 08/09/2000, <draft-giacalone-scored-fair-metric-routing-00.txt> 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. "A Direct Congestion Control Scheme for Non-responsive Flow Control in Diff-Serv IP Networks", Jian Ma, Haitao Wu, Keping Long, Shiduan Cheng, 08/09/2000, <draft-wuht-diffserv-dccs-00.txt> This draft considers the potentially negative impacts of an increasing deployment of non-congestion-controlled or non-responsive traffic on the Internet. Traffic unresponsiveness could bring extremely unfairness against responsive TCP traffic and great service degradation. Differentiated Services (DS)[5,6], which has been proposed by IETF recently, aims to provide a scalable service differentiation in the Internet that can be used for differentiated payment. We argue that this could add the incentives of their customer to use unresponsive flow to achieve better service assurance against the competing traffic. "CAP Realtime iTIP-based Scheduling Profile (CRISP)", John Stracke, 08/21/2000, <draft-stracke-calsch-crisp-01.txt> This document sets forth a restricted profile of [CAP], one which supports no operations beyond the scheduling functionality of [iTIP]. The motivation is to permit use of CAP's real-time iTIP functionality without exposing the calendar access functionality (which may require stricter security controls than iTIP). "LDAPv3 Transactions", Kurt Zeilenga, 08/10/2000, <draft-zeilenga-ldap-txn-00.txt> LDAP [RFC2251] update operations have atomic properties upon individual entries. However, it is often desirable to update two or more entries as one atomic action, a transaction. Transactions are necessary to support a number of applications including resource provisioning and information replication. This document defines an LDAP extension to support transactions. "H.323 URL scheme definition", Orit Levin, 08/10/2000, <draft-levin-iptel-h323-url-scheme-00.txt> H.323 Specification [3] and H.225.0 [4] together define a system and a set of protocols for multimedia communications services over Packet Based Networks (PBN). H.225.0 [4] messages define means for carrying any standard URL (Uniform Resource Locators) in order to specify source and destination, involved in the call. Starting from H.323v.4, H.323 URL is defined in order to specify H.323 party involved in the call. This H323-URL definition has a form of user@host where user corresponds to endpoint's alias and host corresponds to its domain/zone/gatekeeper (in terms of [3]). The purpose of this document is to register the specified (and presented below) H.323 URL scheme within IANA. This will allow for improved resources use and integration over the Internet. "Operational measurements for Traffic Engineering", Brian Davies, Blaine Christian, Heidi Tse, 08/10/2000, <draft-christian-tewg-measurement-00.txt> This memo describes measurement in order to accomplish Traffic Engineering (TE) in IP networks. This document will aid vendors in their choice of information to provide; it will assist network operators in determining the appropriate information to request; and will demonstrate how measurements are used to accomplish TE. The objective of this memo is to describe TE measurement. This memo will also describe (in brief) some methods for using the variables and some methods for gathering the information. "Unified Memory Space Protocol Specification ", Alexander Bogdanov, 08/11/2000, <draft-bogdanov-umsp-00.txt> This document specifies Unified Memory Space Protocol (UMSP), which gives a capability of immediate access to memory of the remote nodes. "State transfer between Access Routes during Handoff", Alan O''Neill, Scott Corson, George Tsirtsis, 08/11/2000, <draft-oneill-handoff-state-00.txt> This draft aims to document an issue raised in the Mobile IP working group related to fast handoff between Access Routers. The fast handoff work aims to rapidly enable IP service at the new access router. In Mobile IP this implies that Binding Updates at the network layer enable forwarding of packets to the new access router. However, it may also imply other network layer activities because the IP service given to the MN may depend on state which is presently located in the old access router. This draft aims to document the issue through examples so that the IETF can resolve how to approach this issue. "Running IKE Phase 2 over Artificial Kerberos IKE SA", Tero Kivinen, 08/11/2000, <draft-kivinen-ike-over-kkmp-00.txt> This document defines how to create artificial IKE SA using kerberos. It defines how to calculate SKEYID, cookies and IV needed by the IKE SA from the Kerberos session key. After the artificial IKE SA is created, it can be used to run normal IKE [RFC-2409] phase 2 negotiations. Those negotiations include quick Mode (creating IPsec SA), new group mode, delete notifications, and error notifications. "RADIUS and IPv6", Bernard Aboba, Glen Zorn, David Mitton, 08/29/2000, <draft-aboba-radius-ipv6-02.txt> This document specifies the operation of RADIUS when run over IPv6 as well as the RADIUS attributes used to support IPv6 network access. A companion document, draft-itojun-ipv6-dialup-radius-0x.txt, describes scenarios in which these attributes may be used. "A list of possible PINT functions", Lawrence Conroy, Jeremy Buller, 08/11/2000, <draft-conroy-pint-act-00.txt> This Internet Draft is one of a pair written at the request of one of the SPIRITS Working Group co-chairs in order to elicit discussion on what extended functionality SPIRITS may be used to provide; the PINT work has similar requirements for a definition of the building blocks that might be used in future services (and so need to be supported by the protocol). This note provides the 'mirror image' of the associated SPIRITS draft, listing functional building blocks that may be executed in response to future PINT protocol requests. "A list of possible SPIRITS functions", Lawrence Conroy, Jeremy Buller, 08/11/2000, <draft-conroy-spirits-act-00.txt> This Internet Draft has been written at the request of one of the SPIRITS Working Group co-chairs in order to elicit discussion on what extended functionality SPIRITS may be used to provide. It has been requested that mapping to any specific protocol is not undertaken at this juncture. As such, only 'possible' functionality is identified and no mapping to existing protocol methods is given. This document is only intended to provide a basis for discussion and would be expected to form one aspect of the requirements for SPIRITS. As such the terminology used is deliberately and (we hope) suitably ambiguous. "LDAP Extension Style Guide", Bruce Greenblatt, 08/14/2000, <draft-greenblatt-ldapext-style-00.txt> Version 3 of the Lightweight Directory Access Protocol (LDAP) as defined in [1] provides a base set of services. Additionally, LDAP provides several mechanisms by which the base set of services may be enhanced to provide additional services. This document describes the different ways that LDAP may be enhanced, and how developers can decide which enhancement mechanism is best suited for their environment. It also discusses the positives and negatives for each LDAP enhancement mechanism "Low Interruption Mobile IP Handoff", Tom Hiller, Peter McCann, 08/14/2000, <draft-mccann-mobileip-limiph-00.txt> There are currently a number of proposals for different mechanisms intended to reduce the overhead of IP mobility management. Generally speaking, the goal of these proposals is twofold: first, to reduce the latency or interruption due to handoffs; and second, to reduce the signaling load on the Mobile IP Home Agent (and Correspondent Nodes, for the case of Mobile IPv6). These techniques are meant to improve the performance of real-time applications like voice or video over IP over wireless networks. By minimizing the period of interruption during a handoff from one point of attachment to another, the proposals attempt to minimize packet loss when these events occur. This draft argues that the best solution to this problem is a 'transparent' one that requires no changes to the Mobile IP clients in mobile nodes and that gives control over routing functionality to the operator of a wireless network. We review some of the existing proposals and describe in detail a new proposal that can provide for low interruption handoffs in a more transparent manner. "A Framework for the LSP Setup Across IGP Areas for MPLS Traffic Engineering", Sudheer Dharanikota, Senthil Venkatachalam, 08/15/2000, <draft-venkatachalam-interarea-mpls-te-00.txt> In this draft, we propose architecture for the inter-area LSP setup based on criteria (combination of constraints). We derive the architectural requirements for the routing protocols, signaling protocols and the MIBs to support such an idea. We also demonstrate how such a mechanism will reduce the crankback during LSP setup. A possible outline of the modifications to the CSPF algorithm and examples are presented. In the companion document [INTER_AREA_EXT] we elaborate on the extensions required for such architecture. "Administrative Requirements for Deployment of ENUM in North America", Penn Pfautz, 09/11/2000, <draft-pfautz-na-enum-01.txt> This document discusses a number of the administrative issues that must be resolved before effective deployment of ENUM[2,3] services in complex environments with number portability and multiple providers for using DNS for translation of E.164 (telephone) numbers. North America is examined critically because its environment may be more complex than most and because current deregulation trends may drive other countries/regions in similar directions. In particular the current mechanisms for number administration and number portability in North America will require establishment of a new administrative function for managing the domain name entries for ported numbers. "ZRIP: Zero-Configuration Routing Information Protocol", Sangeeta Mukherjee, Cuneyt Akinlar, David Braun, 08/16/2000, <draft-akinlar-zeroconf-zrip-00.txt> Zero-Configuration(Zeroconf) Networking is becoming highly popular with the proliferation of cheap network attached devices and computers. Zeroconf networks are a particular class of TCP/IP networks that may be established in the home, in small offices or for ad-hoc purposes. Zeroconf networks do not have and should not be expected to have user configurable network infrastructure such as DHCP, DNS and other administered services [4]. "Guidelines for IPv6 local experiments", Jun-ichiro Hagino, 09/06/2000, <draft-itojun-ipv6-local-experiment-01.txt> The memo defines how a (IPv6-wise) disconnected network should conduct local IPv6 experiment. The document tries to give guidelines for novice IPv6 experimenters, and tries to help them from falling into common pitfalls. "A Common Profile for Instant Messaging (CPIM)", Jonathan Rosenberg, Marshall Rose, C Huitema, G. Klyne, Dave Crocker, Hiroyasu Sugano, Robert Sparks, Florencio Mazzoldi, Athanassios Diacakis, 08/21/2000, <draft-mrose-impp-common-00.txt> This memo describes a common set of Instant Messaging formats and services, independent of underlying IM infrastructure. The profile meets the requirements specified in RFC 2779 using a minimalist approach allowing interoperation of a wide range of IM systems. "IPv4 over Mobile IPv6 for Dual Stack nodes", Alan O''Neill, Scott Corson, George Tsirtsis, 08/21/2000, <draft-tsirtsis-v4-over-mipv6-00.txt> In this document we show how IPv4 based communications can be supported by a dual stack mobile node that only supports Mobile IPv6 (MIPv6). The aim is to use MIPv6 for mobility services while the Mobile can still use its dual stack capabilities for IPv4 communications without the need for translation. "ICMP Blocked Notification", Eliot Lear, 08/21/2000, <draft-lear-icmp-blocked-00.txt> Since the introduction of private addresses[1] the use of NATs and firewalls has introduced not only inability to communicate using certain mechanisms, such as AH[2], ESP[3], and H.323[4], but also difficulty in determining the reason for the failed communication. This document specifies methods an intermediate device such as a router, a firewall, or a NAT may use to inform end hosts that a particular type of communication is not possible. It also recommends practices for both the frequency of transmission of such error notices, and their consumption by the end hosts. This document is an outgrowth of the 'foglamps' discussion that occurred within the IETF between late 1999 and 2000, and is not the product of a working group. "VPN-ID-Enhanced IPSec-VPN DOI for ISAKMP", Claudio Lordello, Udo Neustadter, 08/21/2000, <draft-lordello-ipsec-vpn-doi-00.txt> The IPSec DOI for ISAKMP defines identities for phase 2 exchanges that are suitable for a flat, unique address space. On the other hand, different VPN's cannot guarantee a non-overlapping address space among them. Therefore when security gateways on an ISP network negotiate IPSec SA's in the context of multiple VPN's, identifying traffic flows for this multiplicity of VPN's become an issue. Of course, an alternative would be to have multiple contexts of security gateways, one for each VPN. Unfortunately that would impose severe administrative challenges to an ISP, some of which are described later. Another alternative and a more appealing one would be to have a single security gateway with a single tunnel endpoint address, a single X.509 certificate, etc., that exists in a common context and is able to negotiate IPSec tunnels for any VPN with a presence in the security gateway. For the later to be possible however, it is required for this common security gateway to be able to negotiate phase 2 SA's on behalf of each one of these VPN's with overlapping address spaces. A second motivation for the later approach would be to simply negotiate IPSec tunnels for each VPN as a whole without implying any specific traffic flow. This specification describes an extended DOI for ISAKMP which, while inheriting the existing IPSec DOI in its entirety, defines extra types of phase 2 identities which include a VPN-ID field as an extra piece of tunnel identity, i.e., a qualifier for the IP addresses selectors. The VPN-ID is defined in RFC 2685. "A Framework for Moving IMPP Forward", Jonathan Rosenberg, M. Rose, C Huitema, G. Klyne, Dave Crocker, Robert Sparks, Florencio Mazzoldi, Athanassios Diacakis, 08/22/2000, <draft-rosenberg-impp-differences-00.txt> This document presents the summary of the findings of the IMPP group of nine that were selected to study the common components and fundamental differences among the three proposals. "Base 64, 32 and 16 Encodings ", Simon Josefsson, 08/22/2000, <draft-josefsson-base-encoding-00.txt> This draft serve as a canonical collection of base 16, base 32 and base 64 encoding descriptions "Packetnetwork Package for Megaco/H.248", S Scoggins, C Brown, 08/22/2000, <draft-scoggins-megaco-pktnetpkg-00.txt> This document provides a proposed package for bearer independent packet networks. "Dual Stack deployment using DSTM and 6to4", George Tsirtsis, 08/22/2000, <draft-tsirtsis-6to4-and-dstm-00.txt> It is desirable that most of IPv6 deployment is based on Dual Stack IPv4 and IPv6 nodes so that interoperability with the current IPv4 based Internet be seamless. The 6to4 transition mechanism offers a automated mechanisms for addressing an IPv6 site as well as interconnectivity with other IPv6 sites when no native IPv6 connectivity is available. DSTM provides a mechanism for dynamic IPv4 address allocation to Dual Stack nodes and a mechanism to send packets over a network that only supports IPv6 routing. By combining the two mechanisms we show how Dual Stack Intranets may be deployed with minimum need for IPv4 address space and no native IPv6 connectivity. "Content Language Headers", Harald Alvestrand, 08/22/2000, <draft-alvestrand-content-language-00.txt> This document defines a 'Content-language:' header, for use in the case where one desires to indicate the language of something that has RFC- 822-like headers, like MIME body parts or Web documents. It also preserves (but does not standardize) an extension to multipart/alternative for use when multiple language variants of a document are transmitted. "LDAP vCard Schema", F. Dawson, Doug Royer, 08/22/2000, <draft-royer-vcard-ldap-00.txt> The Lightweight Directory Access Protocol (LDAP) [LDAPV3] is gaining widespread acceptance as a method for accessing Internet directories. Many of the LDAP clients accessing these directories also provide support for emitting the directory information in the form of a vCard electronic business card object. "Generalized IP Handoff", Alan O''Neill, Scott Corson, George Tsirtsis, 08/22/2000, <draft-oneill-craps-handoff-00.txt> This draft describes a generalized IP handoff model that supports edge mobility such as that encountered in cellular systems and Internet roaming. The model is mobile-controlled and network- constrained. The model is generic in that it permits both planned and unplanned handoff (i.e. proactive and reactive) and supports both make-before-break and break-before-make link layers. It also supports movement within and between technologies, as well as within and between domains. Finally, it is -equally applicable to routed mobility and to tunneled mobile IP-based mobility. "FC over SCTP/IP (FC/SCTP/IP)", Douglas Otis, 09/22/2000, <draft-otis-fc-sctp-ip-01.txt> This specification incorporates an encapsulation scheme for Fibre- Channel (FC) using SCTP. The essential advantages for using SCTP compared to TCP as it relates to FC are as follows: - Headers contained within one frame. - Objects aligned at 32-bit boundaries. - Out of sequence frame processing. - Standard authentication. - Independent streams under common control. - Session restart. - Improved error detection. - Prevention of blind spoofing and denial of service attacks. - Standard Heartbeat and multi-homing. (optional) "Profiles and Parameters in ROHC", Hans Hannu, Lars-Erik Jonsson, Krister Svanbro, 08/23/2000, <draft-jonsson-rohc-profiles-00.txt> 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. "IKE Challenge/Response for Authenticated Cryptographic Keys (Revised) ", D. Piper, D. Harkins, 08/25/2000, <draft-harkins-ipsra-crack-00.txt> This memo describes a new IKE authentication method ([HC98]) which provides for mutual authentication when one side is using a legacy- based secret-key authentication technique such as RADIUS, SecurID, or OTP and the other side is using public-key authentication, with optional digital certificates. The generic protocol described herein is an open-ended IKE phase 1 exchange ([HC98]). The result of this exchange is a mutually authenticated IKE security association ([HC98]). The keys that are derived from this SA are also authenticated and thereby convey this state to any SA's created from it for any other security service, such as IPsec [Pip98]. "Graceful Restart mechanism for BGP", J. Scudder, Y Rekhter, Srihari Ramachandra, Enke Chen, Rex Fernando, 10/11/2000, <draft-ramachandra-bgp-restart-03.txt> This document proposes a mechanism for BGP that would help minimize the negative effects on routing caused by BGP restart. An End-of-RIB marker is specified and can be used to convey routing convergence information. A new BGP capability, termed 'Graceful Restart Capability', is defined which would allow a BGP speaker to express its ability to preserve forwarding state during BGP restart. Finally, procedures are outlined for temporarily retaining routing information across a TCP transport reset. "HTTP Delta Clusters and Templates", J Mogul, Fred Douglis, Daniel Hellerstein, 08/25/2000, <draft-mogul-http-dcluster-00.txt> HTTP 'Delta encoding,' the transmission of a compact encoding of the change between instances of a Web resource instead of retransmitting the entire new value, has been shown to be of potential value. Research has shown additional benefits if deltas can be computed between instances of different resources. This document describes a compatible extension to HTTP delta encoding to support 'clustering', where multiple resources (URLs) are treated as a pool, and the use of 'templates', where a large set of resource instances are most naturally described as deltas from a chosen template resource. "Bibliographic Protocol Level 1: Link Resolution and Metapage Retrieval", R. Cameron, Serban Tatu, 10/18/2000, <draft-cameron-tatu-bibp-01.txt> BibP (bibliographic protocol) links bibliographic identifiers of pub- lished works to bibliographic services for those works. Identifiers follow the Universal Serial Item Name (USIN) scheme, providing a scholar-friendly conventional notation for journal articles, books and institutional publications, as well as a generic framework that can scale to identify documents in any organized collection. A hierarchical resolution model emphasizes bibliographic services available through local libraries backed up by publisher-specified and global services. Resolution is achieved through existing DNS technology coupled with appropriate client-side support. Deployment of BibP clients with most of the popular web browsers is possible today; this paper presents one such client, written in JavaScript. "ROHC Initialization Headers", Mikael Degermark, 08/28/2000, <draft-degermark-rohc-initialization-00.txt> This is an individual contribution to the IETF ROHC WG. The document proposes a format for the initialization headers that establish the static (and dynamic) part of ROHC context. The method is intended to be general and extensible, and to deal well with IPv6 extension headers, headers used by Mobile IP, and IPSEC headers. All these headers must be dealt with according to the ROHC requirements, but are not handled by existing proposals. Comments should be sent to the ROHC WG, rohc@cdt.luth.se "Level3 MPLS Protocol Architecture", Craig Pierantozzi, Jim Boyle, Vanessa Springer, 08/29/2000, <draft-springer-te-level3bcp-00.txt> This paper discusses Traffic Engineering with Multi-Protocol Label Switching in the Level3 network. A brief overview of traffic engineering is given followed by constraints affecting Level3's design. The approach Level3 will use, which is LDP edge and an RSVP-TE core, is presented. Several architectures were considered when deciding upon a design. These methods are discussed as well as the reasons they were ultimately refuted. "OSPFv2 Metric Auto-Decay", Spencer Giacalone, 08/29/2000, <draft-giacalone-metric-auto-decay-routing-00.txt> This memo specifies mechanisms for automatically decaying OSPFv2 [1] metrics and router priorities in the event of partial, but potentially critical, system failures which do not cause interfaces to change basic state (they are opaque to transient data). These procedures, called metric auto-decay, allow OSPFv2 networks to gracefully bypass devices which have incurred partial/opaque system failures. "FTP Plus", Mike Saul, 08/29/2000, <draft-saul-ftp-plus-00.txt> The terminology used in this document is a bit television centric and thus may be somewhat unusual to the internet community. The reader is referred to a joint task force report of the Society of Motion Picture and Television Engineers (SMPTE) and the European Broadcast Union (EBU) [1] as background material. Also, this document may refer to itself as a "RSVP Extensions in Support of OIF Optical UNI Signaling", Eric Gray, 08/30/2000, <draft-gray-mpls-rsvp-oif-uni-ext-00.txt> This draft defines a signaling mechanism based on RSVP-TE ([2]) to support an Optical User Network Interface (UNI). This effort is in part driven by work in the OIF as well as the recent draft on signaling requirements for the optical UNI ([3]), and is consistent with recent work on Generalized MPLS (see [4], [5], [6], and [7]). The main function of this draft is to identify the relevant mechanisms in RSVP-TE (including further extensions) to satisfy functional requirements for an Optical UNI. This draft reflects ongoing work at the Optical Interworking Forum (OIF), however, not all of the concepts/requirements have been approved by the OIF. "TCP Message Boundary Option", Costa Sapuntzakis, 08/30/2000, <draft-csapuntz-tcpmsgbnd-00.txt> TCP does not have a mechanism for specifying message boundaries in a stream. This I-D describes a new TCP option and a new way of using the TCP urgent field to specify message boundaries in the stream. "Using International Standard Book Numbers as Uniform Resource Names", Juna Hakala, Hartmut Walravens, 08/30/2000, <draft-hakala-isbn-00.txt> This document discusses how International Standard Book Numbers (ISBN) can be supported within the URN framework and the syntax for URNs defined in RFC 2141 [Moats].Much of the discussion below is based on the ideas expressed in RFC 2288 [Lynch]. Chapter 5 contains a URN namespace registration request modelled according to the template in RFC 2611 [Daigle et al.]. "The LDAP Client Caching Proxy Model", K Vijay, 08/31/2000, <draft-knvijay-ldapext-clientcachingproxy-00.txt> This document describes an LDAP 'caching proxy' model for use on mobile clients. The caching proxy speeds up LDAP accesses by caching and enables access to LDAP directory content & execution of directory applications in offline mode. It includes a description of the model and identifies LDAP control extensions for proxy operation, cache- control & cache-management. "A Description of the Camellia Encryption Algorithm", Junko Nakajima, Shino Moriai, 08/31/2000, <draft-nakajima-camellia-00.txt> This document describes a secret-key cryptosystem, Camellia; it is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. "Uniform Resource Identifiers: Comprehensive Standard", Leslie Daigle, 09/01/2000, <draft-daigle-uri-std-00.txt> The pieces of the specification of Uniform Resource Identifiers (URIs), and subsets thereof, span several documents which have evolved independently over time. This memo provides the definitive overview of the (currently) relevant documentation. As such, it acts as a definition of the core standard for URIs, incorporating existing standards documents by reference. "OSPF, IS-IS, RSVP, CR-LDP Extensions to Support Inter-Area Traffic Engineering Using MPLS TE", Sudheer Dharanikota, Senthil Venkatachalam, 09/05/2000, <draft-dharanikota-interarea-mpls-te-ext-00.txt> 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]. "IPv6 SMTP operational requirements", Motonori Nakamura, Jun-ichiro Hagino, 09/05/2000, <draft-motonori-ipv6-smtp-requirement-00.txt> The memo lists operational requirements for IPv6 SMTP, and IPv6-capable MX DNS records. As we deploy IPv6 SMTP servers, it became apparent that we need certain configuration in IPv6-capable MX DNS record, for stable dual-stack (IPv4 and IPv6) SMTP operations. The document tries to clarify the problems we have in transition period between IPv4 SMTP and IPv6 SMTP, and operational requirements for stable IPv4/v6 SMTP operation. "An analysis of IPv6 anycast", Jun-ichiro Hagino, K Ettikan, 09/05/2000, <draft-itojun-ipv6-anycast-analysis-00.txt> The memo tries to identify the problems and issues in the use of IPv6 anycast [Hinden, 1998] . The goals of the draft are (1) to understand IPv6 anycast better, (2) to provide guidelines for people trying to deploy anycast services, and (3) to suggest updates to IPv6 anycast protocol specification. The document was made possible by input from ipngwg DNS discovery design team. "Address Prefix Based Outbound Route Filter for BGP-4 ", Srihari Ramachandra, Enke Chen, 09/05/2000, <draft-chen-bgp-prefix-orf-00.txt> This document defines a new Outbound Router Filter type for BGP, termed 'Address Prefix Outbound Route Filter', that can be used to perform address prefix based route filtering. This ORF-type supports prefix length or range based matching, wild-card based address prefix matching, as well as the exact address prefix matching for address families. "Using The ISSN (International Serial Standard Number)as URN (Uniform Resource Names) within an ISSN-URN Namespace ", Slawek Rozenfeld, 09/05/2000, <draft-rozenfeld-urn-issn-00.txt> This draft document presents how the ISSN - International Standard Serial Number - which is a persistent number for unique identification of serials widely recognised and used in the bibliographic world, can be supported within the URN framework as a specific URN namespace identifier. An ISSN URN resolution system using the ISSN identifier as Uniform resource Name within an ISN URN Namespace has been developed by the ISSN International Centre (ISSN-IC) and is operating as a demonstrator to evaluate all requirements to deploy it in an operational environment. "Using Kerberos as a key exchange method in Secure Shell", Joseph Salowey, 09/05/2000, <draft-salowey-secsh-kerbkeyex-00.txt> This memo describes two methods for using Kerberos [KRB5] for authentication and key exchange in the Secure Shell protocol. The first method uses Kerberos as a means to authenticate the Diffie-Hellman exchange described in [SSH-TRANSPORT]. The second method uses Kerberos for authentication and key-exchange. This memo also defines a new user authentication method which allows an authorization name and optional credentials to build upon the underlying authenticated key exchange. "IP Payload Compression Using ITU-T V.44 Packet Method ", John Border, Jeff Heath, 09/05/2000, <draft-heath-ipcomp-v44-00.txt> This document describes a compression method based on the data compression algorithm described in ITU-T Recommendation V.44 [V44]. Recommendation V.44 is a modem standard but Annex B, Clause B.1, of the recommendation describes the implementation of V.44 in packet networks (e.g. V.44 Packet Method). This document defines the the application of V.44 Packet Method to the IP Payload Compression Protocol [IPCOMP]. [IPCOMP] defines a method for applying lossless compression to the payload portion of Internet Protocol datagrams. V.44 Packet Method is based upon the LZJH data compression algorithm. Thoughout the remainder of this document the terms V.44 Packet Method and LZJH are synonomous. "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization ", David Balenson, David McGrew, Alan Sherman, 09/06/2000, <draft-irtf-smug-groupkeymgmt-oft-00.txt> We present and implement a scalable method for establishing group session keys for secure large, dynamic groups such as multicast sessions. Our method is based on a novel application of One-Way Function Trees (OFTs). The number of keys stored by group members, the number of keys broadcast to the group when new members are added or evicted, and the computational efforts of group members, are logarithmic in the number of group members. The method provides perfect forward and backward security: evicted members cannot read future messages, even with collusion by arbitrarily many evicted members, and newly admitted group members cannot read previous messages. In comparison with the Logical Key Hierarchy (LKH) of Wallner et al., our algorithm roughly halves the number of bits that need to be broadcast to members in order to re-key after a member is added or evicted. In addition, and unlike LKH, our algorithm has the option of being member contributory in that members can be allowed to contribute entropy to the group key. Running on a Pentium with 64 MB of RAM, our prototype has handled groups with up to 100,000 members. "Broadcast Trivial File Transfer Protocol", Paolo Casagranda, Luca Vignaroli, 09/06/2000, <draft-casagranda-vignaroli-btftp-00.txt> This document describes the Broadcast Trivial File Transfer Protocol (BTFTP), a protocol designed to be used as a datagram based, multicast enabled protocol with optional back-channel. The main purpose of the protocol is data and file transfer over broadcast, wireless channels (e.g. Digital Video Broadcasting channels, like terrestrial DVB-T and satellite DVB-S [ISO13818]) without the need of a back-channel (which is optional). The efficiency of the protocol over a satellite and terrestrial wireless link has been widely tested. "A Characters Codes Page for language names ", Andre Tremblay, 09/06/2000, <draft-tremblay-languages-names-codes-page-00.txt> A new Codes Page so to handle the languages names in the native characters set without need to multiples fonts to handle all languages Codes Pages. "Intra-Domain Group Key Management Protocol ", Brad Cain, Indermohan Monga, Thomas Hardjono, 09/06/2000, <draft-irtf-smug-intragkm-00.txt> This document describes a protocol for intra-domain group key management for IP multicast security, based on the framework of [HCD00]. In order to support multicast groups, the domain is divided into a number of administratively-scoped 'areas'. A host-member of a multicast group is defined to reside within one (and only one) of these areas. The purpose of placing host-members in areas is to achieve flexible and efficient key management, particularly in the face of the problem of changes (joining, leaving, ejections) in the membership of a multicast group. A separate administratively-scoped area control-group is defined for each (data) multicast group, for the express purpose of key management and other control-message delivery. "SCTP Dynamic Addition of IP addresses", Ian Rytina, Q Xie, Randall Stewart, Michael Tuexen, 09/11/2000, <draft-stewart-addip-sctp-sigtran-00.txt> This document describes an extension to the Stream Control Transmission Protocol (SCTP) [RFCXXXX] to provide a method to add or delete an IP address from a existing association. Also this document will provide a generic method for transmitting a reliable control chunk. The benefits of these extensions are a) uniform methods for the addition of control chunks that must be reliable and b) for machines with hot pluggable interface cards the ability to add (and or delete) IP addresses dynamically without forcing an association restart. "SCTP Unreliable Data Mode Extension", Chip Sharp, Ian Rytina, Q Xie, Randall Stewart, 09/11/2000, <draft-xie-usctp-sigtran-00.txt> This document describes an extension to the Stream Control Transmission Protocol (SCTP) [RFCXXXX] to provide unreliable data transfer services. The benefits of this extension includes unified congestion control over reliable and unreliable data streams, single association for multi-content data services, link level fault tolerance for unreliable data transfer, unreliable data stream multiplexing, etc. "SCTP Stream based flow control", Marshall Rose, P. Conrad, Michael Ramalho, Q Xie, Randall Stewart, 09/11/2000, <draft-stewart-srwnd-sctp-sigtran-00.txt> Taking advantage of the extensibility of SCTP, this document adds a standard method for SCTP to provide a stream based flow control mechanism. "MPLampS: Electricity over IP (with an MPLS control plane)", B. Rajagopalan, 09/11/2000, <draft-bala-mplamps-00.txt> Mostly Pointless Lamp Switching (MPLampS) is an architecture for carrying electricity over IP (with an MPLS control plane). MPLampS has the potential to dramatically lower the price, ease the distribution and usage, and improve manageability of delivering electricity. This draft is motivated by such drafts as SONET/SDH over IP/MPLS [2,3] (with apologies to their authors). Readers of the previous drafts have been observed scratching their heads and muttering, 'What next?'. This draft answers that question. This draft has also been written as a public service. It was recently announced that the routing area will consider work items of the form 'foo-over-MPLS'. There are possibly many who are wondering how to exploit this opportunity and write random drafts to achieve prominence in the MPLS area. This draft illustrates the key ingredients that go into producing any 'foo-over-MPLS' draft and may be used as a template for all such work. "Bi-mode Row-based ASCII-Compatible Encoding (BRACE), version 0.1.0", Adam Costello, 09/12/2000, <draft-costello-idn-brace-00.txt> BRACE is a reversible function from Unicode (UTF-16) text strings to host name labels. Host name labels are defined by RFCs 952 and 1123 as case-insensitive strings of ASCII letters, digits, and hyphens, neither beginning nor ending with a hyphen. RFC 1034 restricts the length of labels to 63 characters. "Presence and Instant Messaging Protocol (PRIM)", Shingo Fujimoto, Hiroyasu Sugano, Greg Hudson, John Ramsdell, Florencio Mazzoldi, Athanassios Diacakis, 09/12/2000, <draft-mazzoldi-prim-impp-00.txt> The first part of this document introduces PRIM from an architectural perspective, and discusses several common issues among the Presence and INSTANT MESSAGING protocols, such as name resolution, framing, access control and security. The second part details the different methods available in the PRESENCE and the INSTANT MESSAGING protocols. "Fast Handoffs in MIPv6", K Malki, Hesham Soliman, 09/12/2000, <draft-elmalki-handoffsv6-00.txt> This draft describes a method to achieve Fast Handoffs in Mobile IPv6. Fast Handoffs are required in Mobile IPv6 in order to limit the period of service disruption experienced by a wireless Mobile Node when moving between access routers. This requirement becomes even more important when supporting real-time services. Fast Handoffs involve anticipating the movement of MNs by sending multiple copies of the traffic to potential Mobile Node movement locations. Both flat and Hierarchical Mobile IPv6 models are considered. The Hierarchical MIPv6 mobility Management model in [1] already offers improvements to Mobile IP handoffs by providing a local Mobility Anchor Point (MAP) functionality. Some additions are made to the operation of this existing Hierarchical model to achieve Fast Handoffs. "Micro-IP for embedded systems", David Gothberg, 09/12/2000, <draft-gothberg-micro-ip-00.txt> This protocol is intended to provide easy communication between small embedded nodes and between those nodes and the Internet. Typically this means nodes in vehicles, home-appliances or nodes on computerised machinery. "VLAN Aggregation for Efficient IP Address Allocation", Barry Dykes, Danny McPherson, 09/18/2000, <draft-mcpherson-vlan-ipagg-00.txt> This document introduces the concept of VLAN [802.1Q] aggregation as it relates to IPv4 address allocation. A mechanism is described by which hosts that reside in the same physical switched infrastructure, but separate virtual broadcast domains, are addressed from the same IPv4 subnet and share a common default gateway IP address, thereby removing the requirement of a dedicated IP subnet for each virtual Local Area Network (LAN) or Metropolitan Area Network (MAN). Employing such a mechanism significantly decreases IPv4 address consumption in virtual LANs and MANs. It may also ease administration of IPv4 addresses within the network. "Socket API for IPv6 flow label field", Jun-ichiro Hagino, 09/18/2000, <draft-itojun-ipv6-flowlabel-api-00.txt> The draft outlines a socket API proposal for controlling the flow label field in the IPv6 header. The API uses the sin6_flowinfo member on the IPv6 socket address structure (sockaddr_in6). The draft is, at this moment, written separately from the IPv6 basic/advanced API RFCs [Gilligan, 2000; Stevens, 1999] , as there can be many discussion items. The ultimate goal of the draft is to be a part of the IPv6 basic/advanced API. "Socket API for IPv6 traffic class field", Jun-ichiro Hagino, 10/16/2000, <draft-itojun-ipv6-tclass-api-01.txt> The draft outlines a socket API proposal for controlling the traffic class field in the IPv6 header. The API uses ancillary data stream to manipulate the traffic class field, following practice in the IPv6 advanced API. The draft is, at this moment, written separately from the IPv6 basic/advanced API RFCs [Gilligan, 2000; Stevens, 1999] , as there can be many discussion items. The ultimate goal of the draft is to be a part of the IPv6 basic/advanced API. "ESP Encapsulation in UDP Packets", Ari Huttunen, Joern Sierwald, 09/18/2000, <draft-huttunen-ipsec-esp-in-udp-00.txt> This document defines a method to encapsulate ESP in UDP, and a method to negotiate this encapsulation using IKE. The primary motivation for such encapsulation is to allow ESP traffic pass through NATs. However, it is also possible to use it without NATs. This document defines methods for determining the need for UDP encapsulation, both in the presence of Basic NAT (i.e. without port translation) and in the presence of NAPT (with port translation). This is done by the receiver, based on the information available in standard IKE packets. ESPUDP in both tunnel mode and transport mode are defined. Tunnel mode ESPUDP through NAT is seen easier to implement, but transport mode ESPUDP can also be made to go through NAT. "Kerberized Internet Negotiation of Keys", Michael Thomas, 09/19/2000, <draft-thomas-kink-reqmt-00.txt> The KINK working group is chartered to create a standards track protocol to facilitate centralized key management for IPsec security associations as defined in RFC 2401, as an alternative to IKE (RFC 2409). Participating systems will use the Kerberos architecture as defined in RFC 1510 (and its successors) for key management. The goal of the working group is to produce a streamlined, fast, easily managed, and cryptographically sound protocol without requiring public key. The working group will not require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). "The DIAMETER API ", Pat Calhoun, James Kempf, David Frascone, 09/19/2000, <draft-kempf-diameter-api-00.txt> The Diameter authentication, authorization, and accounting (AAA) protocol provides support for peering AAA transactions across the Internet. This document describes a standardized API for the Diameter protocol. The API is defined in both the C and Java languages. In addition, a standardized file format is described for some Diameter configuration data. The intent of the API and standardized file formats is to foster source code portability across multiple programming platforms. "IRC-DIGEST Digest authentication for IRC ", James Hess, 09/21/2000, <draft-hess-sid-ircdigest-00.txt> This document specifies a method with-which Digest Authentication can be performed between two clients over the IRC protocol and specifies a way in which digest authentication may be used by an IRC server to validate the authorization of a client attempting to connect or gain operator privileges on the server without the revealing the 'password' being used in the process to a third party packet-sniffing the connection for the very purpose of discovering it. "High Level Logical Link Control (HLLC) ", Jorge Rodriguez, 09/21/2000, <draft-rodriguez-hllc-00.txt> The great advance in telecommunications techniques to increase the level of reliability on the physical layer (Packet Loss) has made a tremendous contribution to the way higher layer protocols are designed nowadays. The High-Level Logical Link Control (HLLC) is intended for use as a highly reliable and fast host-to-host protocol between hosts current packet-switched computer communication networks. This document describes the functions to be performed by the High-Level Logical Link Control, the program that implements it, and its interface to programs or users that require its services. "Requirements for Networked Appliances: Wide-Area Access, Control, and Interworking", Simon Tsang, H Schulzrinne, Stanley Moyer, Dave Marples, Arjun Roychowdhury, 09/21/2000, <draft-tsang-appliances-reqs-00.txt> Today, there are a variety of technologies available to network appliances and provide degrees of home automation and control. However, there is a lack of support for wide-area access control and interworking of these Networked Appliances (NA). The ability to provide such support will radically enhance people’s ability to provide exciting new services. This document outlines a set of requirements for providing such support. "Mobile Mesh Routing Protocol", Kevin Grace, 09/22/2000, <draft-grace-manet-mmrp-00.txt> The Mobile Mesh Routing Protocol (MMRP) is a robust, scalable, efficient mobile adhoc routing protocol based upon the "Securely Available Credentials - Requirements", Stephen Farrell, Alfred Arsenault, 09/22/2000, <draft-arsenault-sacred-reqs-00.txt> 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). "URN Namespace for Literate Programming: Anthony B. Coates URN-NID-abc", Anthony Coates, 10/18/2000, <draft-coates-urn-namespace-01.txt> This document describes a URN namespace for use in identifying XML namespaces for use with applications created by the author, Anthony B. Coates. In particular, the author develops applications for literate programming. "Assigned Numbers", Daniel Kohn, 09/22/2000, <draft-kohn-assigned-numbers-00.txt> This document replaces the static snapsnot of current assigned numbers used in previous documents with a link to <http://www.iana.org/numbers.html>. "Mobile Mesh Border Discovery Protocol", Kevin Grace, 09/22/2000, <draft-grace-manet-mmbdp-00.txt> 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. "Mobile Mesh Link Discovery Protocol", Kevin Grace, 09/22/2000, <draft-grace-manet-mmldp-00.txt> 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. "HTTP Cache Control Extensions for Direct Cache Manipulation", Mark Nottingham, 09/25/2000, <draft-nottingham-cache-extensions-00.txt> HTTP/1.1 provides for extensions to Cache-Control headers, which provide new methods of controlling caches. This document specifies extensions which allow content providers more precise control over shared caches. "A Model for CDN Peering", Mark Day, Brad Cain, Gary Tomlinson, 10/18/2000, <draft-day-cdnp-model-02.txt> There is wide interest in the technology for interconnecting content distribution networks (CDNs), variously called 'content peering' or 'CDN peering'. A common vocabulary helps the process of discussing such interconnection and interoperation. This document introduces CDNs and CDN peering, and proposes elements for such a common vocabulary. "Group Domain of Interpretation for ISAKMP", M. Baugher, Brian Weis, Thomas Hardjono, 09/25/2000, <draft-irtf-smug-gdoi-00.txt> 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. "Universal Service Protocol", Timur Shemsedinov, 09/25/2000, <draft-shemsedinov-usp-00.txt> This document contains the description of a call and response packets of protocol USP. The protocol is the maximum generalized way of coding of the complex hierarchical information, in its basis the principles of object-parametrical modeling are fixed. The protocol does not assume binding to any specific service and gives only basic rules structuring of any service protocols, given for creation, however USP was developed as RPC protocol, which responses should be multipart structures on similarity MIME, but with support of a multilevel enclosure and other expansions. Unfortunately, the majority of the modern protocols represent the information differently, it is caused by that they were created by the independent developers, in different time and for work in different operational systems. The reduction of the protocols to a common format of representation of the information will allow essentially to facilitate development of the new protocols and spelling new servers, will remove problems connected to any incompatibility, and will raise speed of processing of the information. I distinctly imagine to myself all complexities connected to the introduction USP, but standardization always brought more benefits, than problems. "iSCSI Message Boundary Detection Proposal", Matt Wakeley, 09/27/2000, <draft-wakeley-iscsi-msgbndry-00.txt> The iSCSI working group is currently considering the framing/delimiting of iSCSI messages in a TCP stream. This I-D presents a proposal to discover iSCSI message boundaries using the TCP urgent pointer. "Mobile IPv6 Neighborhood Routing for Fast Handoff", Carl Williams, Alper Yegin, Mohan Parthasarathy, 09/27/2000, <draft-yegin-mobileip-nrouting-00.txt> The Mobile IP working group is currently examining proposals to assist in minimizing the latency and packet loss due to handoffs when a Mobile IPv6 node moves from one point of attachment to another. One of the desires to reduce this latency and packet loss is a result of the strict requirements of real-time network services. This proposal specifies a solution whereby the mobile node sends a binding update with multiple care-of-addresses which match the current link and other links that the mobile node may possibly visit next. After receiving such a binding update, the correspondent nodes and home agent use a new routing header extension to route the packet that will be received by the mobile node at one of the possible care-of-addresses. Thus, the correspondent nodes and home agent can still communicate with the mobile node despite not knowing its exact location while the mobile node moves across links. The proposal presents no new networking entities and the resulting architecture describes a natural extension to the Mobile IPv6 protocol. "Content Distribution Network Peering Scenarios", Mark Day, Don Gilletti, 10/19/2000, <draft-day-cdnp-scenarios-01.txt> This document sets forth several logical and detailed scenarios to be considered when evaluating systems and protocols for CDN peering. "Flexible proxy of mail protocols", Kumar Khanna, 09/28/2000, <draft-khanna-proxy-mail-protocols-00.txt> 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. "RDMA / TCP", James Williams, 09/28/2000, <draft-williams-rdmatcp-00.txt> This document describes a format for encapsulating RDMA (remote direct memory access) information within a TCP data stream. No changes or modification to TCP of any sort are required. This is not intended to be a protocol, but rather a common format that may be shared by multiple client protocols, for instance VI/TCP and iSCSI. By using a common format it is hoped that design of NICs supporting these multiple protocols can be simplified. Sufficient information is included in the RDMA message format to allow determination of the protocol message units, as will as the ability to process an incoming RDMA request even if previous packets are missing and awaiting retransmission. In addition a CRC-32 is included in each segment to enhance the checksum coverage included in TCP. "Accounting Models for CDN Peering", R. Nair, Don Gilletti, John Scharber, 10/02/2000, <draft-gilletti-cdnp-accounting-models-01.txt> This document presents several conceptual and logical models for accounting activities between peered CDNs. This is a new piece of work intended to enumerate the issues and provide additional detail for use when deriving the ACCOUNTING PEERING SYSTEM for a CDN peering model. "Mapping Between Content-Types and URIs ", D Eastlake, 09/29/2000, <draft-eastlake-cturi-00.txt> Multipurpose Internet Mail Extension (MIME) Content-Type headers and Uniform Resource Identifiers (URIs) are both used, in different contexts, to label entities. A mapping is specified such that the union of their meaning can be expressed in either syntax. "CDN Peering Architectural Overview", Mark Green, Brad Cain, Gary Tomlinson, 10/23/2000, <draft-green-cdnp-gen-arch-01.txt> 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. "Megaco/H.248 Media Gateway Resources Discovery", LP Anquetil, Thomas Levy, 10/02/2000, <draft-levy-megaco-mgdiscovery-00.txt> This document addresses the need for a Media Gateway Controller (MGC) to be informed from the media resources of its Media Gateways (MG) in the context of the Megaco/H.248 protocol. The draft discusses alternative solutions for an effective media gateway resources discovery mechanism. The document is provided as an informational draft for discussion within the Megaco Working Group. "Lightweight Directory Access Protocol (v3):Technical Specification", J. Hodges, R Morgan, 10/03/2000, <draft-hodges-ldapbis-ldapv3-ts-00.txt> This document specifies the set of RFCs comprising LDAPv3, and documents the addressing of the 'IESG Note' attached to RFCs 2251 through 2256. "COPS usage for Mobile IP (MIP)", Abderrahmane Lakas, Muhammad Jaseemuddin, 10/03/2000, <draft-jaseem-rap-cops-mip-00.txt> Mobile IP is a protocol that is used to achieve transparent routing of IP packets to a mobile node. A mobile node obtains a care-of- address in the foreign network and registers that address with the home agent. The home agent as well as the foreign agent can apply policies to the mobile node registration. This draft defines COPS [1] usage for Mobile IPv4 [2]. It describes how COPS is used to control Mobile IP registration based on policies. It defines the interactions between the PEP and the PDP to handle Mobile IP registration messages. It also provides a guideline for mobility agents on how to use this COPS client with regards to the registration messages. "SCSI over IP", Douglas Otis, 10/10/2000, <draft-otis-scsi-ip-01.txt> This is an overview of SCSI over IP considerations leading to the FC-SCTP-IP draft and to suggest possible implementations of this FC- SCTP-IP draft. With two basic architectures covered, it is the intent to illustrate decisions leading to both simple FC encapsulation as well as native IP access. "Mail transfer reliability in Simple Mail Tranfer Protocol(SMTP)", Kumar Khanna, 10/03/2000, <draft-khanna-smtp-mail-transfer-reliability-00.txt> This draft discusses the issue which makes the data tranfer in SMTP protocol highly vulnerable to a 'resend' in case of a network disruption. We then discuss a means by which such a 'resend' can be avoided, by tranferring mail data only from the point of disruption. "The audio/ac3 Media Type", Jason Flaks, 10/03/2000, <draft-flaks-audio-ac3-00.txt> In recent years we have begun to see a convergence of Internet technologies with traditional media formats such as video and audio. It is therefore likely that movies and television with surround sound capabilities are soon to be dispersed around the Internet. AC-3 is standard multi-channel compression format for HDTV, DVD, and other video formats, but there is no uniform MIME type for these files "Enhanced Alerting Packages for Megaco/H.248", Kevin Boyle, C Brown, 10/03/2000, <draft-boyle-megaco-alerting-00.txt> This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for enhanced telephony services, specifically CLASS signaling services. This document is the updated version of the alerting and CLASS packages presented originally in draft-brown- megaco-supplpkgs-00.txt. "Supplemental Tones Packages for Megaco/H.248", Kevin Boyle, Sarah Cornel, C Brown, Stacy Doyle, Mehala Kumar, 10/03/2000, <draft-boyle-megaco-tonepkgs-00.txt> This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services. This document is the updated version of the tones packages presented originally in draft-brown-megaco-supplpkgs-00.txt. "Confirmation of SDP preconditions", Gonzalo Camarillo, 10/04/2000, <draft-camarillo-manyfolks-confirm-00.txt> This document describes certain functionality that is missing in the current 'Integration of Resource Management and SIP' [1] (a.k.a. manyfolks draft). An extension to add this functionality is outlined. This functionality is needed in general to provide richer signalling capabilities and can be employed in several scenarios. This draft describes its use in third party call control applications. If this extension is accepted it is foreseen that this draft would be merged with [1]. "Report of the First Megaco/H.248 Interop Event ", Brian Rosen, 10/05/2000, <draft-rosen-megaco-interop-1-report-00.txt> An interoperability test of the Megaco (RFC2885/6) protocol was held on August 28-31 in Durham, NH. An excellent turnout of many different independently developed implementations were present, and a great many of the tests were quite successful, including media flow in many cases, and several cases of testing a Media Gateway controller from one organization with two Media Gateways from different organizations. The primary purpose of the event was to assess the ability of independent development teams to create interoperable devices from the recent Proposed Standard RFCs 2885 [1] and 2886 [2]. While several discrepancies were found that resulted from differing interpretations of the documents, the level of compatibility exhibited at this first test was excellent. A secondary purpose of the event was to begin the process of moving the RFCs to draft standard status, which requires documentation of at least two implementations of each protocol element/feature. While this first event only used a subset of the protocol, quite a few of the elements and features were demonstrated by all implementations. This I-D describes the event and summarized the results. "SIP Registration", H. Schulzrinne, 10/05/2000, <draft-schulzrinne-sip-register-00.txt> SIP registration provides personal, pre-call terminal and service mobility. We describe the registration process in detail, considering different options for roaming users. "Signalling Unnumbered Links in RSVP-TE", Y Rekhter, Kireeti Kompella, 10/06/2000, <draft-kompella-mpls-rsvp-unnum-00.txt> 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. "HTTP host and port selection using URIs and SRV RRs A generic mechanism for resolving port conflicts between URIs and SRV RRs", M. Andrews, Thor Kottelin, 10/06/2000, <draft-andrews-http-srv-00.txt> Many of todays HTTP sites are virtual, that is they are hosted on a machine that is not known by the name the HTTP site is known by. This leads to the problem of how to rationally give these HTTP sites IP addresses. This has traditionally been done by using CNAMES [RFC1034][RFC1035] or by using explicit IP address records where CNAMES are illegal due to restrictions in the DNS. "Error Tolerant RTP Payload Format for AMR", Q Xie, Sanjay Gupta, 10/09/2000, <draft-xie-avt-et-rtp-amr-00.txt> This document defines the RTP payload format for *error tolerant* delivery of Adaptive Multi-Rate (AMR) speech frames over an RTP session. The flexibility on bandwidth requirements and the tolerance to bit errors of AMR codes are not only beneficial for 'over-the-air' wireless links, but are also very desirable for any Voice-over-IP applications. The design is focused on how to best facilitate these features of AMR codec in an IP environment. "RTFM: Implementing New Attributes", Nevil Brownlee, 10/10/2000, <draft-brownlee-implementing-new-attributes-00.txt> RFC 2724 presented an analysis and taxonomy of RTFM attributes, and proposed adding new attributes and new types of attribute. Many of those 'new' attributes, especially the distribution-valued attributes, have now had several years implementation experience. This document proposes that these attributes be implemented, i.e that the RTFM Architecture and Meter MIB RFCs be re-written to include them. "MPLS-based Layer 2 VPNs", Kireeti Kompella, 10/23/2000, <draft-kompella-mpls-l2vpn-01.txt> Virtual Private Networks (VPNs) based on Frame Relay or ATM circuits have been around a long time. While these VPNs work well, the costs of maintaining separate networks for Internet traffic and VPNs and the administrative burden of provisioning these VPNs have led Service Providers to look for alternative solutions. In this document, we present a VPN solution where from the customer's point of view, the VPN is based on Layer 2 circuits, but the Service Provider maintains and manages a single MPLS-based network for IP, MPLS IP VPNs, and Layer 2 VPNs. "ZONE and VIEW option records in DNS messages", B. Wellington, Michael Sawyer, Michael Graff, 10/10/2000, <draft-sawyer-dnsext-edns0-zone-option-00.txt> This document defines two new EDNS option codes used to specify what zone and view should be used in query messages to a remote DNS server. "Diversion Indication in SIP", S Levy, J Yang, Bryan Byerly, 10/10/2000, <draft-levy-sip-diversion-00.txt> This document proposes an extension to the Session Initiation Protocol (SIP). This extension provides the ability for the called SIP user agent to identify from whom the call was diverted and why the call was diverted. The extension defines a new general header, Diversion, which conveys the diversion information from other SIP user agents and proxies to the called user agent. This extension allows enhanced support for various features, including Unified Messaging, Third-Party Voicemail, and Automatic Call Distribution (ACD). SIP user agents and SIP proxies which receive diversion information may use this as supplemental information for feature invocation decisions. "SIP Record-Route/Route Hiding", Bryan Byerly, David Daiker, Shailandra Bhatnagar, 10/10/2000, <draft-byerly-sip-hide-route-00.txt> This document describes a proposed extension to SIP. This document proposes a mechansim to encrypt/hide Record-Route and Route entries in or to support confidentiality of SIP proxy routing information. The functionality of the Record-Route and Route headers are preserved. The introduction of this extension allows a set of trusted SIP proxies to cooperatively hide the route that SIP PDUs transit from untrusted proxies and user agents. "Use of CR-LDP or RSVP-TE to Extend 802.1Q Virtual LANs across MPLS Networks", Tissa Senevirathne, Paul Billinghurst, 10/13/2000, <draft-tsenevir-8021qmpls-01.txt> This document presents a discussion on possible methods for extending Layer 2 Virtual LANs across MPLS networks through the use of CR-LDP or RSVP. Special note is taken on extending 802.1Q Tagged VLANs across MPLS networks. A new Forward Equivalence class called VLAN Forwarding Equivalence class (VFEC) is defined. Creating traffic engineered LSP based on P bit of the 802.1Q Tag is also a key focus of this document. "SIP Authentication using CHAP-Password", D. Williams, Bryan Byerly, 10/10/2000, <draft-byerly-sip-radius-00.txt> This document describes a proposed extension to SIP. This document proposes using an alternative SIP authentication mechanism for use in Proxy-Authorization or Authorization headers in order to support SIP client Authentication using backend RADIUS servers. The introduction of this extension would allow a SIP proxy (or called SIP client) to authenticate a SIP client using a backend RADIUS server. "Signalling Unnumbered Links in CR-LDP ", A Kullberg, Y Rekhter, Kireeti Kompella, 10/11/2000, <draft-kompella-mpls-crldp-unnum-00.txt> 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. "MGCP Business Phone Packages", Ashok Srinath, Gil Levendel, Kent Fritz, Raghuraman Kalyanaram, 10/11/2000, <draft-srinath-mgcp-bus-packages-00.txt> This document describes a collection of MGCP packages that can be used to take advantage of the feature keys and displays on digital business phones and IP-Phones. These packages, when used in conjunction with the packages currently defined in RFC 2705 (Media Gateway Control Protocol Version 1.0), allow an MGCP call-agent to control these types of endpoints. "Instant Messaging using IMXP", M. Rose, G. Klyne, Dave Crocker, 10/18/2000, <draft-klyne-imxp-message-service-01.txt> This document describes how to provision an instant text messaging and presence service using IMXP. "A high-level application-oriented interface to the traffic flow measurement architecture", Juergen Quittek, Marcelo Pias, 10/13/2000, <draft-quittek-rtfm-generic-interface-00.txt> This memo specifies a high-level application-oriented interface to the Realtime Traffic Flow Measurement (RTFM) Architecture. The abstract interface models the RTFM architecture while hiding many of the details not relevant to an application programmer who want to integrate IP traffic measurements into an application. Particularly the interaction between manager, reader, and meter is hidden by the interface, and rule sets used for traffic measurement specification are replaced by simpler data structures. Furthermore, the RTFM interface supports complex actions like modifying a traffic measurement specification while it is already being applied. The interface is defined in an abstract way. It can be implemented by an application programming interface as well as by a network protocol. "HTTP Display and network connection characteristics", Mick O''Doherty, 10/13/2000, <draft-odoherty-http-display-and-connect-info-00.txt> This document defines an extension to the HTTP [2] protocol to allow a client/user agent describe its display and network connection characteristics to a server when making a request. As HTTP may be used by a client/user agent which does not have a display or does not want to make this information available, providing this information is optional. "EtherIP: Tunneling Ethernet Frames in IP Datagrams", Russ Housley, Scott Hollenbeck, 10/13/2000, <draft-housley-etherip-00.txt> This document describes a protocol for tunneling Ethernet frames in IP datagrams so that non-IP traffic can travel across an IP internet. "AAA Interface for IPv6 Handoff", Emad Qaddoura, Haseeb Akhtar, M Khalil, Krish Pillai, 10/16/2000, <draft-mkhalil-mobileip-ipv6-handoff-00.txt> This draft outlines a protocol to achieve minimal disruption during Mobile IPv6 handoff. Minimal disruption during handoff is required by Mobile IPv6 to reduce the window of data loss experienced by a MN (Mobile Node) when moving between access networks that may belong to same or different administrative domains. "SIP T.38 Call Flow Examples And Best Current Practice ", Jean-Francois Mule, 10/16/2000, <draft-mule-sip-t38callflows-00.txt> This document gives examples of SIP call flows for T.38 Internet fax communications (SIP, the Session Initiation Protocol is defined in RFC2543 [2] and T.38 is an ITU-T Recommendation [3]). Elements in these call flows include SIP User Agents, SIP Proxy Servers, and Gateways to the PSTN (Public Switch Telephone Network). This document introduces best current practices for T.38 fax calls: a call starts with audio capabilities, and, upon fax tone detection, T.38 fax capabilities are negotiated. The T.38 fax call scenarios include the detection of T.38 fax transmission by the receiving side, or the emitting side, or both (in the latter case, a 'glare' effect may appear). The current version of this document only covers the case when the fax tone is detected by the receiving side (other cases were left for discussion and may be included in the future). Call flow diagrams and message details are shown. A list of IANA defined SDP attribute names for T.38 is summarized in section 5. "Telnet Authentication Option", Theodore Ts''o, Jeffrey Altman, 10/17/2000, <draft-altman-rfc2941bis-00.txt> This document describes the authentication option to the telnet [1] protocol as a generic method for negotiating an authentication type and mode including whether encryption should be used and if credentials should be forwarded. While this document summarizes currently utilized commands and types it does not define a specific authentication type. Separate documents are to be published defining each authentication type. This document updates a previous specification of the telnet authentication option, RFC 2941 [2], to allow the AUTHENTICATION option to be used in conjunction with the START_TLS option [5]. "Telnet Authentication: Kerberos Version 5", Theodore Ts''o, Jeffrey Altman, 10/17/2000, <draft-altman-rfc2942bis-00.txt> This document describes how Kerberos Version 5 [1] is used with the telnet protocol. It describes an telnet authentication suboption to be used with the telnet authentication option [2]. This mechanism can also used to provide keying material to provide data confidentiality services in conjunction with the telnet encryption option [3]. This document updates a previous specification of the Telnet Authentication Kerberos 5 method, RFC 2942 [4], to allow Kerberos 5 Telnet authentication to be used in conjunction with the START_TLS option [5]. "Telnet Authentication: SRP ", Tom Wu, Jeffrey Altman, 10/17/2000, <draft-altman-rfc2944bis-00.txt> This document specifies an authentication scheme for the Telnet protocol under the framework descri