2000 acap aft agentx applmib asid atommib avt bmwg bridge calsch cat dhc disman dlswmib dnsind dnssec drums ediint entmib fax find frnetmib ftpext grip http hubmib idmr idr ids ifmib intserv ion ip1394 ipcdn ipngwg ipp ippcp ippm ipsec isdnmib isis isn issll lsma madman manet mboned mhtml mixer mmusic mobileip mospf mpls ngtrans nimrod nntpext oncrpc openpgp ospf otp pier pint pkix pktway poisson pppext printmib ptopomib qosr radius receipt rip rmonmib roamops rps rsvp rtfm run rwhois sdr secsh snadlc snanau snmpv3 spki ssh stdguide svrloc tcpimpl tcplw tcpsat tip tls tn3270e trunkmib udlr upsmib urlreg urn uswg vgmib vrrp webdav wts The Internet and the Millennium Problem (2000) ---------------------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Erik Huizer Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Technical Advisor(s): Scott Bradner Mailing Lists: General Discussion:2000@nic.surfnet.nl To Subscribe: listserv@nic.surfnet.nl In Body: subscribe 2000 in body Archive: Description of Working Group: The Millenium problem According to the trade press billions of dollars will be spend the upcoming three years on the year 2000 problem, also called the millenium problem (though the third millenium will only start in 2001). This problem consists of the fact that many software packages and some protocols use a two digit field for the year in a date field. Most of the problems seem to be in administrative and financial programs, some of which have been written in archaic languages like Cobol. A lot of organizations are now starting to make an inventory of which software and tools they use will suffer from the millenium problem. ....and the Internet With the increasing popularity of the Internet, more and more organizations start to use the Internet as a serious business tool. This means that most organizations will want to analyse the millenium problems due to the use of Internet protocols and popular Internet software. In the trade press the first articles suggest that the Internet will collapse at midnight the 31st of december 1999. To counter these suggestions (that are obviously wrong) and to avoid that all over the Internet people will redo the same inventory over and over again the WG is to make an inventory of all important Internet protocols and their most popular implementations with respect to the millenium problem. Only software and protocols directly related to the Internet will be considered. The inventory will be published as an informational RFC. The RFC will contain: o Description of the year 2000 problems and when they will occur o Summary of possible solutions and timelines for those solutions o Inventory of the year 2000 problem in the most popular Internet protocols and their most popular implementations o Suggested solutions to the problems noted in the inventory o A disclaimer that the RFC does not pretend to be complete and that the proposed solutions should be tested before being relied upon (this for the US readers). The WG will only meet once (in Memphis, April 1997), most of the work will be done via the mailinglist. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 97 New The Internet and the Millenium Problem (Year 2000) Application Configuration Access Protocol (acap) ------------------------------------------------ Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): C Newman Matt Wall Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:ietf-acap+@andrew.cmu.edu To Subscribe: ietf-acap-request+@andrew.cmu.edu Archive: anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap Description of Working Group: The goal of this working group is to define, specify, and develop the Application Configuration Access Protocol as a general access mechanism for per-user and per-server structured lists of information. In addition, the Working Group will specify how to use the protocol to store specific structured lists, initially application configuration options and addressbooks. The Application Configuration Access Protocol is a proposed solution to the problems of client configuration for users of the internet. Given the increasing prevalence of network access points and rapidly increasing numbers of users with diverse needs and settings, there is a phenomenon of internet application users who typically connect from more than one physical location and/or operating system to use the same set of internet services and applications. These users must recreate sets of personal configuration information for each system, session, and location that they use. This may include information such as application options and preferences; personal or shared user data such as addressbooks, bookmarks, or subscription lists; or shared data for internal client use, such as authorization group lists. The products of this working group will be: * a formal specification for the protocol * formal specifications of datasets used by the protocol and related extensions to the protocol * an RFC intended to move to a Standard in a timely manner * a specification for extensibility of the protocol in the form of a framework document * additional informational and/or experimental RFCs as necessary to amplify and/or extend ACAP. Note on goals and milestones: because the work of the ACAP WG is based on the previous work done on IMSP, there is justification for a somewhat more aggressive schedule than is customary. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 96 Aug 97 ACAP -- Application Configuration Access Protocol Apr 97 New ACAP TYPE Extension Apr 97 New ACAP Datatyping and Datatyping Discovery Jun 97 Jun 97 Multi-Lingual String Format (MLSF) Jun 97 New Two Alternative Proposals for Language Taging in ACAP Jun 97 Aug 97 Anonymous SASL Mechanism Jul 97 New ACAP Authorization Identifier Datasets Jul 97 New ACAP Personal Addressbook Dataset Class Jul 97 Jul 97 ACAP personal options dataset class Authenticated Firewall Traversal (aft) -------------------------------------- Charter Last Modified: 28-Aug-97 Current Status: Active Working Group Chair(s): Marcus Leech Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:aft@socks.nec.com To Subscribe: aft-request@socks.nec.com Archive: http://www.socks.nec.com/aftmail/ Description of Working Group: Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 96 New Challenge-Handshake Authentication Protocol for SOCKS V5 Mar 97 New Challenge-Response Authentication Method for SOCKS V5 Mar 97 New Secure Sockets Layer for SOCKS Version 5 Mar 97 Jul 97 SOCKS Protocol Version 5 Jul 97 New Feature Discovery: A Generic Extension Mechanism for SOCKS Version 5 SNMP Agent Extensibility (agentx) --------------------------------- Charter Last Modified: 11-Feb-97 Current Status: Active Working Group Chair(s): Bob Natale Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:agentx@fv.com To Subscribe: agentx-request@fv.com In Body: Subject: subscribe Archive: ftp://ftp.fv.com/pub/agentx/ Description of Working Group: Note: Dale Francisco of Stratacom is the WG editor. The goal of this working group is to define standards-track technology for SNMP Agent extensibility. The resulting technology specification will allow independently developed sub-agents to communicate with a master-agent running on an Internet device. The technology specification will consist of: o (mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network; o (optional) a MIB module, which, when implemented by a master-agent, allows an SNMP-based management application to monitor and control the intra-agent communication service; and, o (optional) a programmatic interface to the services offered by that protocol. The working group is explicitly directed to develop a solution which is adequate to achieve transparency with respect to whether a SNMP request is processed by a master-agent and/or one or more sub-agents; simultaneously, the working group is further directed to use good engineering judgement is developing an approach with the smallest reasonable "footprint" to achieve intra-agent communication. As a consequence, if the working group may choose to avoid complete transparency, if, at its discretion, this proves too costly. In this case, the working group should document its decision for this engineering trade-off. Although the working group will solicit existing specifications and experience in this area, it will produce a vendor-neutral technology specification. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 96 Jun 97 Agent Extensibility (AgentX) Protocol Version 1 May 97 New Definitions of Managed Objects for Extensible SNMP Agents Application MIB (applmib) ------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Jonathan Saperia Cheryl Krupczak Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:applmib@emi-summit.com To Subscribe: applmib-request@emi-summit.com Archive: ftp://ftp.emi-summit.com/applmib/applmib-archive Description of Working Group: The Application MIB Working Group is chartered to define a set of managed objects for the monitoring and control of distributed applications. Specifically, these managed objects will focus on providing information about the configuration (including application dependencies and associations between applications), fault (including status information such as up, down, or degraded) and performance (including resource utilization) of distributed applications. The working group will only concern itself with the specification of MIB objects in the management areas defined above. It will not undertake to define details of implementation such as programming API's for the access to this information. The working group will consider existing MIB modules that define objects with similar functions or modules which can be used in conjunction with the Application MIB such as RFC 1514 (The Host Resources MIB) and RFC 1697 (The RDBMS-MIB). The activities of the working group will take place in two stages. The first will focus on the development of a System Application MIB which will not require applications to write additional instrumentation code. This generic information will serve as a base for the follow-on Application MIB which will contain additional information that will require applications to write additional instrumentation. The schedule below describes the schedule for the development of the System Application MIB. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jan 96 Oct 97 Definitions of System-Level Managed Objects for Applications Nov 96 Aug 97 Application Management MIB Nov 96 Sep 97 Definitions of Managed Objects for WWW Services Access, Searching and Indexing of Directories (asid) ---------------------------------------------------- Charter Last Modified: 05-Aug-97 Current Status: Active Working Group Chair(s): Tim Howes Patrik Faltstrom Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-asid@umich.edu To Subscribe: ietf-asid-request@umich.edu Archive: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive Description of Working Group: There is a clear need to provide and deploy a well managed Directory Service for the Internet. A so-called White Pages Directory Service providing people and organizational information, is especially long overdue. While the ultimate goal is a general Directory Service for the Internet, this is too ambitious a goal to be tackled by a single working group. Therefore ASID will keep a tight focus on access and synchronization protocols for an Internet White Pages Directory Service. Other related working groups will be formed in the Applications Area that will deal with other aspects of the Internet Directory Service. Currently there are various protocols under development in the Internet that aim to provide such a service: Internet X.500, WHOIS++, NETFIND, CSO, RWHOIS, etc. To allow these services to evolve to a ubiquitous Internet Directory Service, a hybrid system that allows interaction between the various different services is a requirement. The ASID Working Group will define, evolve, and standardize protocols, algorithms and access methods for a White Pages Directory Service on the Internet. The following protocols (some still under development, some completed by other IETF working groups) will be considered by the working group: - Lightweight Directory Acces Protocols (LDAP and Connectionless LDAP) - User Friendly Naming (UFN) and User Friendly Searching (UFS) - The SOLO directory access and searching system - The WHOIS++ directory service The following work items are handled by other groups, and as such are outside the scope of this group. However their results are important to the development of a White Pages Directory Service, and will be taken into account: - The Hypertext Transfer Protocol (HTTP) - The UR* definitions - The NETFIND directory service The group will focus on harmonizing, evolving and developing protocols and algorithms that deal with access to and synchronization of Directory Service, both ad hoc and standards-based, with a goal of converging here possible towards a hybrid system that ties together various forms of Directory Service. Clearly, protocol-level integration is only part of the solution. But to keep this group tightly focused, harmonizing directory information and service models will be tackled by other working groups. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 95 Jul 97 A MIME Content-Type for Directory Information Jul 95 Oct 97 A Simple Caching Scheme for LDAP and X.500 Directories Feb 96 May 97 WHOIS++ URL Specification Mar 96 Oct 97 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions Mar 96 Oct 97 Lightweight Directory Access Protocol (v3) May 96 Aug 97 vCard MIME Directory Profile Jun 96 Sep 97 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services Aug 96 Apr 97 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names Aug 96 Sep 97 Using Domains in LDAP/X.500 Distinguished Names Nov 96 Jun 97 Use of Language Codes in LDAPv3 Nov 96 Oct 97 WHOIS++ templates Nov 96 Aug 97 Definition of the inetOrgPerson Object Class Nov 96 Jul 97 The LDAP Data Interchange Format (LDIF) - Technical Specification Nov 96 Mar 97 Architecture of the WHOIS++ service Dec 96 Jul 97 Definition of an Object Class to Hold LDAP Change Records Feb 97 Mar 97 LDAP Control Extension for Simple Paged Results Manipulation Mar 97 New Lightweight Directory Access Protocol: Schema for Storing RPC Entries in a Directory Service Mar 97 Jul 97 LDAP Multi-master Replication Protocol Mar 97 Aug 97 The LDAP URL Format Mar 97 Oct 97 The String Representation of LDAP Search Filters Mar 97 New LDAP-based Routing of SMTP Messages: Approach Used by Netscape Mar 97 New LDAP-based Routing of SMTP Messages: Approach at Stanford University Mar 97 New X.500 Strong Authentication Mechanisms for LDAPv3 Mar 97 New A Summary of the Pilot X.500 Schema for use in LDAPv3 Mar 97 Oct 97 A Summary of the X.500(96) User Schema for use with LDAPv3 Apr 97 New LDAP Control Extension for Server Side Sorting of Search Results May 97 New Referrals and Knowledge References in LDAP Directories Jun 97 Sep 97 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security Jul 97 New Lightweight Directory Access Protocol: Dynamic Attributes Jul 97 New The vCard Schema For Use In LDAPv3 Jul 97 New LDAP Replication Requirements Jul 97 Sep 97 The Java LDAP Application Program Interface Jul 97 Oct 97 Schema for Replication Information Jul 97 New LDAP API Extensions for Sort and Simple Paged Results Jul 97 New Referral Whois Protocol (RWhois) 2.0 Jul 97 New The C LDAP Application Program Interface Sep 97 New Java LDAP Controls AToM MIB (atommib) ------------------ Charter Last Modified: 12-Sep-97 Current Status: Active Working Group Chair(s): Kaj Tesink Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Technical Advisor(s): Keith McCloghrie Mailing Lists: General Discussion:atommib@thumper.bellcore.com To Subscribe: atommib-request@thumper.bellcore.com Archive: ftp://thumper.bellcore.com/pub/Group.archive/atommib Description of Working Group: The AToM MIB Working Group is chartered to evaluate RFC 1695, a Proposed Standard, with respect to the standards track. As a part of its evaluation, the working group will prepare a revised version and recommend the appropriate level of standardization for this revision to the IESG (i.e., that it be advanced to Draft Standard status, or that it cycle at Proposed Standard status). As a part of its evaluation, the AToM MIB Working Group may also define additional sets of managed objects, to reflect growing experience and industry requirements for management of: o ATM services o The Frame based UNI (F-UNI) o ATM tests The objects defined by the working group will be consistent with the Internet-standard Management framework. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 95 Aug 97 Definitions of Supplemental Managed Objects for ATM Management Jul 95 Mar 97 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management Jan 96 Jun 97 Definitions of Tests for ATM Management Mar 96 Jun 97 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection-Oriented Networks Apr 96 Feb 97 Definitions of Managed Objects for ATM Management Apr 96 May 97 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals Apr 96 Jul 97 Definitions of Managed Objects for the SONET/SDH Interface Type Aug 96 Jun 97 Accounting Information for ATM Networks Nov 96 New Managed Objects for Recording ATM Performance History Data Based on 15 Minute Intervals Audio/Video Transport (avt) --------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Stephen Casner Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf Description of Working Group: The Audio/Video Transport Working Group was formed to specify experimental protocols for real-time transmission of audio and video over UDP and IP multicast. The focus of this group is near-term and its purpose is to integrate and coordinate the current AVT efforts of existing research activities. No standards-track protocols are expected to be produced because UDP transmission of audio and video is only sufficient for small-scale experiments over fast portions of the Internet. However, the transport protocols produced by this working group should be useful on a larger scale in the future in conjunction with additional protocols to access network-level resource management mechanisms. Those mechanisms, research efforts now, will provide low-delay service and guard against unfair consumption of bandwidth by audio/video traffic. Similarly, initial experiments can work without any connection establishment procedure so long as a priori agreements on port numbers and coding types have been made. To go beyond that, we will need to address simple control protocols as well. Since IP multicast traffic may be received by anyone, the control protocols must handle authentication and key exchange so that the audio/video data can be encrypted. More sophisticated connection management is also the subject of current research. It is expected that standards-track protocols integrating transport, resource management, and connection management will be the result of later working group efforts. The AVT Working Group may design independent protocols specific to each medium, or a common, lightweight, real-time transport protocol may be extracted. Sequencing of packets and synchronization among streams are important functions, so one issue is the form of timestamps and/or sequence numbers to be used. The working group will not focus on compression or coding algorithms which are domain of higher layers. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 96 Jun 97 RTP usage with Layered Multimedia Streams Apr 96 Sep 97 RTP Payload Format for H.263 Video Streams Aug 96 Feb 97 RTP Payload Format for Bundled MPEG Nov 96 Jul 97 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links Nov 96 Jan 97 Alternatives for Enhancing RTCP Scalability Mar 97 New Real-Time Transport Protocol Management Information Base Mar 97 Jul 97 RTP Profile for Audio and Video Conferences with Minimal Control Apr 97 Jun 97 RTP Payload Format for MPEG1/MPEG2 Video Jul 97 New RTP Payload Format for QuickTime Media Streams Jul 97 New RTP Payload for DTMF Digits Aug 97 New An A/V Profile Extension for Generic Forward Error Correction in RTP Aug 97 New Options for Repair of Streaming Media Benchmarking Methodology (bmwg) ------------------------------- Charter Last Modified: 08-Jul-97 Current Status: Active Working Group Chair(s): Guy Almes Kevin Dubray Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:bmwg@baynetworks.com To Subscribe: bmwg-request@baynetworks.com Archive: ftp://ndtl.harvard.edu/pub/bmwg/mailing.list Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of various internetworking technologies; further, these recommendations may focus on the systems or services that are built from these technologies. Each recommendation will describe the class of equipment, system, or service being addressed; discuss the performance characteristics that are pertinent to that class; clearly identify a set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of benchmarking results. Because the demands of a class may vary from deployment to deployment, this Working Group will not attempt to define acceptance criteria or performance requirements. Currently, there are two distinct efforts underway in the BMWG. The first addresses the metrics and methodologies associated with benchmarking network interconnect devices. The second effort (IPPM) focuses on determining the practical benchmarks and procedures needed in gaining insight for users and providers of IP Internet services. An ongoing task is to provide a forum for the discussion and the advancement of measurements designed to provide insight on the operation internetworking technologies. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 96 Sep 97 Benchmarking Terminology for LAN Switching Devices Nov 96 Mar 97 Terminology for Cell/Call Benchmarking Nov 96 Aug 97 Empirical Bulk Transfer Capacity Nov 96 Aug 97 Framework for IP Provider Metrics Nov 96 Aug 97 A One-way Delay Metric for IPPM Dec 96 Aug 97 Terminology for IP Multicast Benchmarking Mar 97 Aug 97 A Packet Loss Metric for IPPM Jul 97 New Benchmarking Terminology for Network Security Devices Bridge MIB (bridge) ------------------- Charter Last Modified: 11-Feb-97 Current Status: Active Working Group Chair(s): Fred Baker Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:bridge-mib@pa.dec.com To Subscribe: bridge-mib-request@pa.dec.com Archive: Description of Working Group: The Bridge MIB Working Group is chartered to define a set of managed objects that instrument devices that conform to the IEEE 802.1 standard for MAC-layer bridges. This set of objects should be largely compliant with (and even draw from) IEEE 802.1(b), although there is no requirement that any specific object be present or absent. The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, standards, and conventions. Internet-Drafts: No Current Internet-Drafts. Calendaring and Scheduling (calsch) ----------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Robert Moskowitz Anik Ganguly Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-calendar@imc.org To Subscribe: ietf-calendar-request@imc.org In Body: [SUBSCRIBE/UNSUBSCRIBE in Message body] Archive: http://www.imc.org/ietf-calendar/mail-archive/ Description of Working Group: Calendaring and group scheduling products are well established for organizational use, but they usually are limited to exchange of information among users of the same system, usually within the boundaries of a single organization. This working group will pursue development of standards to enable different products to interoperate and to work across organizational boundaries. This work will include the development of MIME content types to represent common objects needed for calendaring and group scheduling transactions and access protocols between systems and between clients and servers. The working group will also consider and recommend solutions to the security issues concerning the exchange of calendar information between network entities. The group will exist to create standards that make calendaring and scheduling software significantly more useful and to enable a new class of solutions to be built that are only viable if open standards exist. The Calendaring and Scheduling Working Group is chartered to focus on Internet standards for three basic problems facing group scheduling and calendaring users today. These include the following: 1. A standard content type for capturing calendar event and to-do information. The content type should be suitable as a MIME message entity that can be transferred over MIME based email systems or HTTP World Wide Web. The basic objects along with their representation using MIME will be specified in the document entitled "Core Object Specification". 2. A standard peer-to-peer protocol for common calendaring and group scheduling transactions. For example, these may include exchanging over the Internet, event-requests, reply to event-requests, cancellation notices for event-requests, requesting free/busy time and replying to free/busy time requests between different calendaring products. The working group will undertake this work in two phases, with the first phase focusing on meeting requests and the second phase on free-busy time. To the extent that the peer-to-peer protocol has requirements related to security, the working group will attempt to apply existing Internet standards for authentication, and to assure privacy and integrity of sensitive calendaring information. The protocol for the interoperable transactions will be specified in a document called "Calendar Interoperability Protocol" in the milestone list. 3. A standard access protocol to allow for the management of calendars, events and to-dos over the Internet. This protocol will be specified in the document called "Calendar Access Protocol" in the milestone list. This working group effort should be developed and stabilized with a 6-9 months since there has been considerable prior work done in this area. This prior body of work includes: * Distributed Scheduling Protocol (CHRONOS) IETF Working Group * ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling and Appointments * MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and Calendaring and Scheduling Interoperabilty Specification (CSIS) * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's Specification * Versit vCalendar format The working group will focus on harmonizing, evolving and developing protocols and algorithms based on this work. The process is subject to extension if many new features are added, or more revision is needed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 97 Oct 97 Internet Calendaring and Scheduling Core Object Specification (iCalendar) Feb 97 Apr 97 Core Object Specification - Issues Document Feb 97 New Calendaring Interoperability over HTTP (CIH) Mar 97 New Real-time Protocol Requirements May 97 Oct 97 iCalendar Message-based Interoperability Protocol (iMIP) Jul 97 Oct 97 Internet Calendar Model Specification Jul 97 Oct 97 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries Common Authentication Technology (cat) -------------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): John Linn Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:cat-ietf@mit.edu To Subscribe: cat-ietf-request@mit.edu Archive: ftp://bitsy.mit.edu/cat-ietf/archive/ Description of Working Group: The goal of the Common Authentication Technology (CAT) Working Group is to provide distributed security services (including authentication, integrity, and confidentiality) to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms. By separating security implementation tasks from the tasks of integrating security data elements into caller protocols, those tasks can be partitioned and performed separately by implementors with different areas of expertise. This provides leverage for the IETF community's security-oriented resources, and allows protocol implementors to focus on the functions their protocols are designed to provide rather than on characteristics of security mechanisms. CAT seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies. In support of these goals, the working group pursues several interrelated tasks. We have defined a common service interface allowing callers to invoke security services in association-oriented environments, with an associated token format identifying the security mechanism being employed. A revision to this document set is currently being finalized in response to implementation experience. The CAT Working Group also defines underlying mechanisms to provide security services, and supports integration of security services into caller protocols. Related work areas include interface and mechanism extensions under consideration for message protection in store-and-forward environments and for authorization support. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 94 Oct 97 Independent Data Unit Protection Generic Security Service Application Program Interface (IDUP-GSS-API) Mar 95 Aug 97 Public Key Cryptography for Initial Authentication in Kerberos Mar 95 Mar 97 Generic Security Service API Version 2 : C-bindings Mar 95 Apr 97 Independent Data Unit Protection Generic Security Service Application Program Interface: C-bindings Jul 95 Jul 97 The Simple and Protected GSS-API Negotiation Mechanism Nov 95 Mar 97 Extended Generic Security Service APIs: XGSS-APIs Access control and delegation extensions Nov 96 Aug 97 Public Key Cryptography for Cross-Realm Authentication in Kerberos Feb 97 New Public Key Utilizing Tickets for Application Servers (PKTAPP) Mar 97 New Kerberos Change Password Protocol Mar 97 New Integrity Protection for the Kerberos Error Message Jul 97 New The Kerberos Network Authentication Service (V5) Jul 97 New FTP Authentication Using DSA Jul 97 New Encryption using KEA and SKIPJACK Sep 97 New Anonymous Credentials in Kerberos Sep 97 New Generic Security Service Application Program Interface, Version 2 Oct 97 New User to User Kerberos Authentication using GSS-API Preliminary Draft Oct 97 New Kerberos over IPv6 Dynamic Host Configuration (dhc) -------------------------------- Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): Ralph Droms Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:dhcp-v4@bucknell.edu To Subscribe: listserv@bucknell.edu In Body: subscribe listname Your Name Archive: Send email to listserv@bucknell.edu with HELP as the text. Description of Working Group: This working group will produce a protocol for automated allocation, configuration and management of IP addresses and TCP/IP protocol stack parameters. Specific functions to be included in the protocol include: o Automated allocation and recovery of IP addresses o Automated configuration of all TCP/IP stack parameters, as described in the Host Requirements documents o Interaction between DHCP and DNS dynamic update protocol (ddns) o Automated configuration of other host parameters such as application layer services o Inter-server communication for coordination of multiple servers o Mechanisms for the authentication of clients and servers A specification the Dynamic Host Configuration Protocol (DHCP) for IPv4 has been entered into the IETF standards track. As of 3/97, it has been accepted as a "Draft Standard". The working group is also developing a specification for DHCP for IPv6 (DHCPv6), which is currently available as an Internet Draft. More information on DHCP and the DHC WG can be found at http://www.bucknell.edu/~droms/dhcp. Other DHC Lists: General Discussion: dhcp-v4@bucknell.edu DHCP-DNS Interaction: dhcp-dns@bucknell.edu Implementation issues: dhcp-impl@bucknell.edu Bakeoff events: dhcp-bake@bucknell.edu Inter-server protocol: dhcp-serve@bucknell.edu DHCP for IPv6: dhcp-v6@bucknell.edu Implementation issues for DHCPv6: dhcp-v6impl@bucknell.edu Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 95 May 97 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Feb 96 May 97 Interaction between DHCP and DNS Feb 96 Aug 97 Authentication for DHCP Messages Feb 96 Jul 97 An Extension to the DHCP Option Codes Feb 96 Jul 97 An option for FQDNs in DHCP options Feb 96 Aug 97 Extensions for the Dynamic Host Configuration Protocol for IPv6 Aug 96 May 97 DHCP Options for Service Location Protocol Nov 96 Mar 97 The User Class Option for DHCP Nov 96 Jul 97 DHCP Option for IEEE 1003.1 POSIX Timezone Specifications Nov 96 Aug 97 An Inter-server Protocol for DHCP Dec 96 Aug 97 DHCP Relay Agent Information Option Mar 97 Aug 97 Multicast address allocation extensions options Mar 97 Aug 97 Multicast address allocation extensions to the Dynamic Host Configuration Protocol Mar 97 New DSCP: Dynamic Subnet Configuration Protocol Mar 97 New The Server Identification Option for DHCP Mar 97 New The Server Selection Option for DHCP Mar 97 Aug 97 Security Architecture for DHCP Apr 97 New An Inter-server Protocol for DHCP May 97 New The Named Pool Request Option for DHCP Jul 97 Oct 97 Netware/IP Domain Name and Information Jul 97 New Securing DHCP Jul 97 New Subnet Selection Option for DHCP Aug 97 New The Domain Search Option for DHCP Distributed Management (disman) ------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Randy Presuhn Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Technical Advisor(s): Bob Stewart Mailing Lists: General Discussion:disman@nexen.com To Subscribe: majordomo@nexen.com In Body: subscribe disman your_email_address Archive: Description of Working Group: The Distributed Management Working Group is chartered to define an initial set of managed objects for specific distributed network management applications and a framework in which these applications and others can be consistently developed and deployed. A distributed network manager is an application that acts in a manager role to perform management functions and in an agent role so that it can be remotely controlled and observed. Distributed network management is widely recognized as a requirement for dealing with today's growing internets. A manager application is a good candidate for distribution if it requires minimal user interaction, it would potentially consume a significant amount of network resources due to frequent polling or large data retrieval, or it requires close association with the device(s) being managed. The working group will limit its work to distributed network management applications where the communication mechanism used between managers (or the components of the management application) is SNMP. Future work (and other working groups) may be chartered to investigate other distribution techniques such as CORBA or HTTP. The objects defined by the working group will be consistent with the SNMP framework. The working group will especially keep security considerations in mind when defining the interface to distributed management. The working group will complete these tasks: o Define a Threshold Monitoring MIB o Define a Script MIB o Define a Distribution Management Framework and MIB This last MIB is required in order to keep distributed managers from adding to the management problem. This MIB will allow distributed managers of many types to be controlled in a consistent way including controlling their "management domain" (the set of devices upon which they act), the relationships between the management applications or components, and to some extent the scheduling of their operation. The working group will consider existing definitions, including: o RFC1451, The Manager to Manager MIB which was being considered by the SNMPv2 working group o the RMON working group's work in this area o the SNMP Mid-Level-Manager MIB which is now an expired Internet-Draft o the work of the Application MIB working group It is recognized that the scope of this working group is narrow relative to the potential in the area of distributed network management. This is intentional in order to increase the likelihood of producing useful, quality specifications in a timely manner. However, we will keep in mind and account for potential related or future work when developing the framework including: o Event and alarm logging and distribution o Historical data collection/summarization o Topology discovery Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Mar 97 Definitions of Managed Objects for the Delegation of Management Scripts Jan 97 New Distributed Management Framework Apr 97 May 97 Event MIB Apr 97 Jun 97 Expression MIB Apr 97 May 97 Management Target MIB Apr 97 May 97 Notification MIB Data Link Switching MIB (dlswmib) --------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Shannon Nix Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Technical Advisor(s): Deirdre Kostick Mailing Lists: General Discussion:aiw-dlsw-mib@networking.raleigh.ibm.com To Subscribe: aiw-dlsw-mib-request@networking.raleigh.ibm.com Archive: ftp://host name/pub/standards/aiw/maillogs/mib.mail Description of Working Group: The DLSw MIB Working Group is chartered to define a set of managed objects for devices that support Data Link Switching (DLSw) version 1. DLSw is a method for encapsulating SNA (System Network Architecture) or NetBIOS (Network Basic Input Output Services) traffic in TCP/IP. DLSw is intended to aid in the transport of SNA and NetBIOS traffic across WANs. The objects will be the minimum necessary to provide the ability to monitor and control DLSw devices, supporting fault isolation, configuration and performance management. The set of objects will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing enterprise-specific MIB modules that define objects which support management of these devices. The working group recognizes that managed objects for later versions of DLSw may need to be identified in the future. These objects are out of scope for the current (i.e., 1995) charter; however, once the working group completes its charter, a new charter identifying some or all of these components may be considered. Internet-Drafts: No Current Internet-Drafts. DNS IXFR, Notification, and Dynamic Update (dnsind) --------------------------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Randy Bush Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:namedroppers@internic.net To Subscribe: namedroppers-request@internic.net Archive: ftp://rs.internic.net/archives/namedroppers Description of Working Group: The DNS Incremental Transfer, Notification, and Dynamic Update Working Group is concerned with three areas of future DNS protocol development: 1. Incremental Zone Transfer - As the sizes of some zone files have grown quite large, it is believed that a protocol addition to allow the transfer of only the changed subset of a zone will reduce net traffic and the load on critical servers. 2. Change Notification - There can be large time intervals during which at least one secondary has data that is inconsistent with the primary. The proposed ``notify'' mechanism (where the primary sends a message to known secondaries) facilitates fast convergence of servers vis-a-vis consistency of data in the zones. 3. Dynamic Update - The need to frequently update small portions of a large zone and to have those updates propagate is perceived. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 95 May 97 Classless IN-ADDR.ARPA delegation Nov 96 Apr 97 The Kitchen Sink Resource Record Jan 97 Oct 97 Negative Caching of DNS Queries (DNS NCACHE) Jul 97 Oct 97 Test and Example Top Level Domain Names Aug 97 Oct 97 Local DNS Names Domain Name System Security (dnssec) ------------------------------------ Charter Last Modified: 28-Aug-96 Current Status: Active Working Group Chair(s): James Galvin Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:dns-security@tis.com To Subscribe: dns-security-request@tis.com Archive: ftp://ftp.tis.com/pub/lists/dns-security Description of Working Group: The Domain Name System Security Working Group (DNSSEC) will ensure enhancements to the secure DNS protocol to protect the dynamic update operation of the DNS. Specifically, it must be possible to detect the replay of update transactions and it must be possible to order update transactions. Clock synchronization should be addressed as well as all of the dynamic update specification. Some of the issues to be explored and resolved include o scope of creation, deletion, and updates for both names and zones o protection of names subject to dynamic update during zone transfer o scope of KEY resource record for more specific names in wildcard scope o use of or relationship with proposed expiration resource record One essential assumption has been identified: data in the DNS is considered public information. This assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 94 Aug 97 Mapping Autonomous Systems Number into the Domain Name System Feb 96 Mar 97 Detached Domain Name System Information Mar 97 New The DNS Inverse Key Domain Jun 97 New Storage of Diffie-Hellman Keys in the Domain Name System Jul 97 Aug 97 Domain Name System Security Extensions Sep 97 New DSA KEYs and SIGs in the Domain Name System Sep 97 New Storing Certificates in the Domain Name System Sep 97 New Indirect Keys in the Domain Name System Detailed Revision/Update of Message Standards (drums) ----------------------------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): C Newman Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:drums@cs.utk.edu To Subscribe: drums-request@cs.utk.edu Archive: ftp://cs.utk.edu/pub/drums/mail-archive/ Description of Working Group: The goal of this working group is to develop and review revised versions of RFC 821 and RFC 822, incorporating the revisions in RFC 974, RFC 1123, and RFC 1651. In addition, the group will review other RFCs related to messaging, and determine the applicability of each of these to the future direction of the messaging in the Internet. The group may choose to incorporate, deprecate, or write applicability statements for such documents, as necessary to produce a clear statement of requirements for overall interoperability of Internet electronic mail. The documents produced by the working group are intended to be submitted to the IESG for consideration as Internet Standards. Items appropriate for inclusion in documents produced by the working group include corrections, clarifications, and amplifications to reflect existing practice or to address problems which have been identified through experience with Internet mail protocols. New functionality is expressly inappropriate. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 95 Aug 97 Simple Mail Transfer Protocol Mar 96 Oct 97 Augmented BNF for Syntax Specifications: ABNF Nov 96 Aug 97 Mail and Netnews Header Registration Procedure Nov 96 Jun 97 Message Format Standard Oct 97 New Use of Reply-To in Internet E-Mail messages Electronic Data Interchange-Internet Integration (ediint) --------------------------------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Rik Drummond Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-ediint@imc.org To Subscribe: ietf-ediint-request@imc.org In Body: subscribe Archive: http://www.imc.org/edi/lists/ietf-ediint Description of Working Group: Electronic Data Interchange (EDI) is a set of protocols for conducting highly structured inter-organization exchanges, such as for making purchases or initiating loan requests. The initial RFC1767 defined the method for packaging the EDI X12 and UN/EDIFACT transactions sets in a MIME envelope. However, several additional requirements for obtaining multi- vendor, inter-operable service, over and above how the EDI transactions are packaged, have come to light since the effort concluded. These currently revolve around security issues such as EDI transaction integrity, privacy and non- repudiation in various forms. Additional requirements that mimic many of the heading fields found in X.435 EDI messages (e.g.; Interchange Sender, Interchange Recipient, interchange Control Reference, Communications Agreement ID, and Syntax Identifier) are also needed to support exchanges by point-to-point, FTP and SMTP protocols. Standards in these and other areas are necessary to ensure inter- operability between EDI packages over Internet. Various technologies already exist for these additional features and the primary requirement is to review and select a common set of components for use by the EDI community when it sends EDI over the Internet. In effect, the effort is to provide an EDI over the Internet Informational and Applicability Statement Document. Deliverables: The group will produce Four documents: 1) An Informational document describing the requirements for interoperable EDI, with sufficient background material to give an explanation for the EDI community of the Internet-related issues. 2) A Applicability Statement describing how current Internet standards can be used to achieve this functionality for MIME and SMTP. 3) A Applicability Statement describing how current Internet standards can be used to achieve this functionality for Process-to-Process (real-time) EDI. 4) Security Issues for Inter-organizational EDI over Internet. Additional Administrative information: Editor: Chuck Shih John DesJardins Marc Blanchet First Readers: Rik Drummond Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 96 Jul 97 Requirements for Inter-operable Internet EDI Oct 96 Jul 97 MIME-based Secure EDI Entity MIB (entmib) ------------------- Charter Last Modified: 11-Feb-97 Current Status: Active Working Group Chair(s): Keith McCloghrie Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:entmib@cisco.com To Subscribe: majordomo@cisco.com In Body: subscribe entmib your_email_address Archive: ftp://ftp.cisco.com/entmib/entmib Description of Working Group: The goal of this working group is to standardize a set of managed objects representing logical and physical entities and the relationships between them. Logical entities can occur when a single agent supports multiple instances of one MIB, such as RFCs 1253, 1493, 1516 or 1525, where each instance represents a single (logical) device/entity. Physical entities are the actual physical components on which the logical entities operate; typically, the physical components exist in a hierarchy. The set of objects will be consistent with the SNMP framework and existing SNMP standards. The scope of this MIB should allow an NMS to interrogate a standard SNMP context and thereby discover what logical and physical entities exist, how to access the MIB information of each logical entity, and the relationships between the various entities. The MIB should support both a single agent or multiple agents in one physical entity. The Working Group should adopt a minimalist approach for the (initial) MIB so as to maximize the chance of success, e.g., read-only. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 97 Sep 97 Entity MIB Extesions for Persistent Component Identification Internet Fax (fax) ------------------ Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Dave Crocker James Rafferty Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-fax@imc.org To Subscribe: ietf-fax-request@imc.org In Body: In Body: subscribe Archive: http://www.imc.org/ietf-fax/ Description of Working Group: Facsimile (fax) serves as a reliable, inexpensive global communications service. As the Internet becomes pervasive, integrating fax and Internet services is appealing in terms of cost savings and opportunities for functional enhancements. This working group will pursue a review and specification for enabling standardized messaging-based fax over the Internet. It will also develop informal requirements for fax<->Internet gateways as a first step toward devising standards for session-based fax over the Internet. The messaging-based (via e-mail) service will be specified first, since it should produce useful results for the least additional technical effort. Facsimile/Internet integration can be considered in terms of two user service models, in order of increasing technical difficulty: o Messaging (as with electronic mail) having high latency o Session-based, for observed delivery, with or without capabilities negotiation Within these models, a real-time (telephone network replacement) based service is considered to be a subset of the session-based model. For interconnecting fax services over the dial-up telephone network and carriage of facsimile message data over the Internet, two types of interface systems are required: o Internet/Dial-up Fax gateway, moving data from the Internet to classic or Internet-aware dial-up fax products and services o Dial-up/Internet Fax gateway, moving data from classic or Internet-aware dial-up fax products and services to the Internet The dominant fax communications mode in use today is a session-based connection operating in real-timeover the dial up telephone network; hence an Internet-based direct replacement service would potentially save significant long- distance telephone charges. However, it is believed that from a technical standpoint this service is the most difficult task to produce over the Internet, whereas an messaging-based service is likely to be the simplest. In addition, it is anticipated that the two services will ultimately utilize at least some common technical components. Therefore, this working group will initially review and specificy messaging-based fax over the Internet, using as much existing practice as possible. The working group will take the following steps to specify a core fax-related messaging service over the Internet: Terminology: Develop a shared set of terminology and definitions, to ensure a common framework for participants having differing backgrounds in Internet protocols and facsimile telecommunication. Data Representations: Review existing facsimile- related Internet data specifications and accept, modify, replace or augment them, with particular attention to their encapsulation, such as via MIME. Addressing and transport: Specify the mechanisms for addressing and receipt notification for facsimile data carried via Internet mail. For session-oriented operation, the following specification will be created, as a basis for further work: Operational constraints: Detail the operational constraints for achieving session-oriented use of messaging, tailored for timely delivery with the sender waiting for delivery confirmation. Existing protocols and data specifications will be used as much as possible. The working group will take note of quality of service issues. The working group will coordinate its activities with other facsimile- related standards bodies. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 97 Sep 97 Tag Image File Format (TIFF) - Application F Mar 97 Oct 97 File Format for Internet Fax Jul 97 Sep 97 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration Aug 97 New SMTP Service Extension for Immediate Delivery Sep 97 Oct 97 PSTN and fax address format in e-mail services v3.4 Sep 97 New Tag Image File Format (TIFF) - image/tiff-f MIME Sub-type Registration Oct 97 New PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL Common Indexing Protocol (find) ------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Roland Hedberg Patrik Faltstrom Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:find@bunyip.com To Subscribe: majordomo@bunyip.com In Body: in body: subscribe find Archive: ftp://ftp.bunyip.com/pub/mailing-lists/find Description of Working Group: On the Internet, several more or less localized directory services have evolved over the last couple of years. Also 2 global directory services have been deployed, X.500 and Whois++. To be able to find something or someone, one needs to know what service to use, and what server to query. One step towards the solution of this problem is to define one and only one common indexing protocol which all directory services can use when passing indexing information. When a user queries one server it should be possible for that user to get a referral to another server and even another service, if the two servers have exchanged index information. For this to work, one common protocol must be developed. The idea is to expand on the Centroid ideas used by Whois++, to allow it to be used for other services than Whois++. At the very least, a localized service should be able to be polled by an indexing server using the Common Indexing Protocol (CIP). To be specific, three specifications are to be presented: o An interface spec, where one says how you present a query and what the referrals you get back look like o A server interface spec, where one says that the CIP will be able to include information presented in this format o An engine spec, which specifies that this is how one support the functionality using Centroids a la Whois++. The task for this working group is to create the Common Indexing Protocol so it is (1) usable for other distributed directory services such as X.500, (2) allows the use of non-distributed directory services such as CCSO in the distributed directory service, and (3) addresses needs such as replication to make the protocol itself more stable. Just because the Common Indexing Protocol is already in use by Whois++, but not published, the first task of this group is to publish version 1 of the Common Indexing Protocol as is. After that, the protocol must be extended according to the specification below. This will result in version 2 of the protocol. Other topics to be addressed potentially include: o Incremental updates of indices o Support for the UTF-FSS encoding of UNICODE o Guidelines for building an effective mesh of indexing servers o Administrative protocols and procedures such as server registration o Security between directory services The working group will work in very close cooperation with the working groups ASID and IDS in the IETF. The working group will use the following Internet-Drafts as input: o Architecture of the Whois++ Index Service, Chris Weider o How to interact with a Whois++ mesh, Patrik Faltstrom Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Sep 97 A Tagged Index Object for use in the Common Indexing Protocol Feb 97 New A CIP-based Centroid Exchange for LDAP Mar 97 Oct 97 CIP Index Object Format for SOIF Objects Apr 97 Jul 97 Hierarchical Extensions to the Common Indexing Protocol May 97 New Registration Procedures for SOIF Template Types Jun 97 New CIP Transport Protocols Jun 97 New MIME Object Definitions for the Common Indexing Protocol (CIP) Jun 97 New The Architecture of the Common Indexing Protocol (CIP) Frame Relay Service MIB (frnetmib) ---------------------------------- Charter Last Modified: 12-Sep-97 Current Status: Active Working Group Chair(s): James Watt Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Technical Advisor(s): Fred Baker Mailing Lists: General Discussion:frs-mib@newbridge.com To Subscribe: frs-mib-request@newbridge.com Archive: Description of Working Group: The Frame Relay Service MIB Working Group is chartered to define an initial set of managed objects which will be useful for customer network management of a provider's Frame Relay Service. The working group will consider existing definitions, including the Frame Relay Forum's work in this area. The objects defined by the working group will be consistent with the SNMP framework. The working group will coordinate with both the Frame Relay Forum and the ATM MIB Working Group. The working group is chartered to complete four tasks: a) consider revisions to the existing FRS MIB (currently published as a Proposed Standard in RFC 1604) in light of implementation experience, changes to the interface MIBs (e.g. IF-MIB, DS1-MIB, DS3-MIB, FR-DTE-MIB, creation of the DS0 and DS0 Bundle MIB modules), and evolution of the relevant non-IETF standards, b) prepare a Recommendation to the Area Director as to the appropriate disposition of the (updated) FRS MIB, i.e. that it be advanced to Draft Standard status or that it cycle at Proposed Status, c) develop a set of managed objects to provide the instrumentation required to manage switched-virtual circuits in a frame-relay environment. d) develop a set of managed objects to provide the instrumentation required to manage connections that terminate on a mixture of ATM and Frame Relay interfaces, i.e. interworked connections. These objects will be the minimum necessary to provide the ability to monitor and control interworked connections and shall use existing definitions (e.g. IF-MIB, FRS-MIB, ATM-MIB, etc.) to instrument the interfaces and the "native" parts of the connections. In all cases, the working group will keep the Frame Relay and ATM Forums informed of its progress and will actively solicit input from those Fora. All output of the group will be consistent with the existing SNMPv2c framework and standards, including the SNMPv2c Structure of Management Information (SMI). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 96 Jul 97 Management Information Base for Frame Relay Data Compression Oct 96 New Management Information Base for Frame Relay DTE Extensions for SVC's over Frame Relay Nov 96 Mar 97 Definitions of Managed Objects for Frame Relay Service Feb 97 New Frame Relay Service Extensions MIB for Switched PVCs Extensions to FTP (ftpext) -------------------------- Charter Last Modified: 16-Oct-97 Current Status: Active Working Group Chair(s): Paul Hethmon Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:ftp-wg@hethmon.com To Subscribe: ftp-wg-request@hethmon.com In Body: subscribe Archive: http://w3.hethmon.com/ftpext/ Description of Working Group: 1. Recommend changes to the FTP protocol to support users of languages other than English. 2. Define a new command for a uniform directory listing between platforms. This command will provide an alternative to the existing LIST and NLST commands which has a common format between all FTP implementations and which also provides the ability to represent non-ASCII filenames. 3. Make recommendations for standards-track protocol extensions to support IPv6 in FTP. The group will evaluate RFC 1639 and recommend, revise, or redo as appropriate. 4. Define a mechanism for ftp clients and servers to transmit information regarding extensions supported and not supported. 5. Propose extensions, and/or review proposals submitted by others, to improve the security of FTP. 6. Define a standardized method of checkpoint/restart which works for the stream transfer mode. 7. Define a means of file transfer between a client and server (as opposed to a client mediating a transfer between two servers) which does not require the IP addresses of the endpoints to be transmitted in the FTP protocol. 8. Produce an informational document describing the SIZE and MDTM commands as currently used. The following issues are specifically omitted from the working group's charter, but may be added by the Area Directors if time permits, once the above goals have been acheived. 1. Compression of files for transmission. 2. Internationalization of charset conversion for transmission. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Aug 97 Extended Directory Listing and Restart Mechanism for FTP Nov 96 Jun 97 Internationalization of the File Transfer Protocol Mar 97 New REST Command and Extensions to FTP Jun 97 Jul 97 Feature negotiation mechanism for the File Transfer Protocol G and R for Security Incident Processing (grip) ----------------------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Louis Mamakos Barbara Fraser K.P. Kossakowski Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: Michael O'Dell Mailing Lists: General Discussion:grip-wg@uu.net To Subscribe: grip-wg-request@uu.net Archive: Description of Working Group: The full name of this working group is Guidelines and Recommendations for Security Incident Processing. This working group is co-chartered by the Security Area. The purpose of the GRIP Working Group is to provide guidelines and recommendations to facilitate the consistent handling of security incidents in the Internet community. Guidelines will address technology vendors, network service providers, response teams in their roles assisting organizations in resolving security incidents. These relationships are functional and can exist within and across organizational boundaries. The working group will produce two quality documents: 1) Guidelines for security incident response teams. 2) Guidelines for vendors (this will include both technology producers and network service providers). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 95 Sep 97 Expectations for Computer Security Incident Response Oct 97 New Security Expectations for Internet Service Providers HyperText Transfer Protocol (http) ---------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Larry Masinter Dave Raggett Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:http-wg@cuckoo.hpl.hp.com To Subscribe: http-wg-request@cuckoo.hpl.hp.com In Body: subscribe http-wg Your Full Name Archive: http://www.ics.uci.edu/pub/ietf/http/hypermail Description of Working Group: Note: This working group is jointly chartered by the Applications Area and the Transport Services Area. The HTTP Working Group will work on the specification of the Hypertext Transfer Protocol (HTTP). HTTP is a data access protocol currently run over TCP and is the basis of the World-Wide Web. The initial work will be to document existing practice and short-term extensions. Subsequent work will be to extend and revise the protocol. Directions which have already been mentioned include: o improved efficiency, o extended operations, o extended negotiation, o richer metainformation, and o ties with security protocols. Note: the HTTP working group will not address HTTP security extensions as these are expected to be the topic of another working group. Background information The initial specification of the HTTP protocol was kept in hypertext form and a snapshot circulated as an Internet draft between 11/93 and 5/94. A revision of the specification by Berners-Lee, Fielding and Frystyk Nielsen has been circulated as an Internet draft between 11/94 and 5/95. An overview of the state of the specifications and a repository of pointers to HTTP resources may be found at http://www.w3.org/hypertext/WWW/Protocols/Overview.html Once established, the working group will expand and complete that document to reflect HTTP/1.0 as it has been implemented by World-Wide Web clients and servers prior to November 1994. The resulting specification of HTTP/1.0 will be published for review as an Internet-Draft and, if deemed appropriate, will be submitted to the IESG for consideration as a Proposed Standard or Informational RFC. In parallel with the above effort, the working group will consider enhancements/restrictions to the current practice in order to form a specification of the HTTP protocol suitable for eventual consideration as a proposed standard. Also in parallel with the above efforts, the working group will engage in defining (or selecting from various definitions) a next-generation protocol for hypertext transfer (HTTPng). A description of HTTP/1.0 as it is generally practiced currently on the Internet has been submitted to become an Informational RFC. The working group is considering enhancements/restrictions to the current practice in order to form a specification of the HTTP protocol suitable for eventual consideration as a proposed standard. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 95 Jul 97 PEP - an Extension Mechanism for HTTP Feb 96 Sep 97 Transparent Content Negotiation in HTTP Oct 96 Jul 97 Feature Tag Registration Procedures Feb 97 Jul 97 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 Mar 97 New Problem with HTTP/1.1 Warning header, and proposed fix Mar 97 Sep 97 The User Agent Hint Response Header Mar 97 Oct 97 HTTP State Management Mechanism (Rev1) Mar 97 New HTTP Connection Management May 97 Oct 97 HTTP Trust Mechanism for State Management Jun 97 Jul 97 Scenarios for the Delivery of Negotiated Content using HTTP Jun 97 New HTTP/1.1 305 and 306 Response Codes Jul 97 Jul 97 Feature Tag Scenarios Jul 97 Aug 97 Specification of HTTP/1.1 OPTIONS messages Jul 97 New An Extension to HTTP : Digest Access Authentication Sep 97 New Format and Example of HTTP/1.1 Requirements Summary Sep 97 New The Alternates Header Field Oct 97 New Hypertext Transfer Protocol -- HTTP/1.1 IEEE 802.3 Hub MIB (hubmib) --------------------------- Charter Last Modified: 11-Feb-97 Current Status: Active Working Group Chair(s): Dan Romascanu Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:hubmib@hprnd.rose.hp.com To Subscribe: hubmib-request@hprnd.rose.hp.com Archive: ftp://ftp.rose.hp.com/pub/hubmib Description of Working Group: This working group will produce a document describing MIB objects for use in managing Ethernet-like hubs. A hub is defined as a multiport repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd edition, Sept. 1990). These hub MIB objects may be used to manage non-standard repeater-like devices, but defining objects to describe vendor-specific properties of non-standard repeater-like devices is outside the scope of this working group. The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, conventions, and definitions. In order to minimize the instrumentation burden on managed agents, the MIB definitions produced by the working group will whereever feasible be semantically consistent with the managed objects defined in the IEEE Standard 802.3u, Section 30, "10 Mb / s & 100 Mb / s Management". The working group will produce a document describing MIB objects for use in management of connectivity boxes that include Ethernet ports with a behavior consistent to the repeater ports defined by the 802.3 Standards. The repeater ports will be mapped to the internal box structure that may inlude one or more repeater units that conform to the IEEE 802.3/ISO 8802-3 CSMA/CD standard. If so, all instrumentation variables will be backward compatible with the existing hardware implementations that comply to the IEEE 802.3 repeaters. The mapping model defined by this MIB module may be used by other type of non-802.3 units (e.g. 802.12 repeaters) to map their own port management objects to the multiple repeaters inside a connectivity box. Consistent with the IETF policy regarding the treatment of MIB definitions produced by other standards bodies, the working group may choose to consider only a subset of those objects in the IEEE specification and is under no obligation to consider (even for ``Optional'' status) all objects defined in the IEEE specification. Moreover, when justified by special operational needs of the community, the Working Group may choose to define additional MIB objects that are not present in the IEEE specification. Although the definitions produced by the working group should be architecturally consistent with MIB-II and related MIBs wherever possible, the charter of the working group does not extend to perturbing the conceptual models implicit in MIB-II or related MIBs in order to accommodate 802.3 hubs. In particular, to the extent that the notion of a ``port'' in an 802.3 hub is not consistent with the notion of a network ``interface'' as articulated in MIB-II, it shall be modelled independently by objects defined in the working group. Because the structure of 802.3 hub implementations varies widely, the working group shall take special care that its definitions reflect a generic and consistent architectural model of hub management rather than the structure of particular hub implementations. The IEEE hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable units as groups of ports so that the port numbering would match a modular hardware implementation). Because the working group charter does not extend to consideration of fault-tolerant, highly-available systems in general, its treatment of these groups of ports in an 802.3 hub (if any) shall be specific to hub management and without impact upon other portions of the MIB. The working group is further chartered at its discretion to define an SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An 802.3 Medium Attachment Unit (MAU) attaches a repeater port or Ethernet-like interface to the local network medium. The scope of this work may include several types of MAU units: 10BASE-5 (thick coax), 10BASE-2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber optic). Managed objects defined as part of the MAU MIB task may, for example, represent such information as MAU type, link status, and jabbering indications. The working group is further chartered to define an SNMP MIB for the management of the 100Base-T hubs, MAUs and interfaces, or to propose aditions / changes to existing MIB modules that deal with IEEE 802.3 hubs, MAUs or interfaces in order to extend their support to 100Base-T. In case when those MIB modules are the result of the work of another working group in the NM Area, the proposal will be submited to the directorate and the respective WG. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 95 Mar 97 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2 Inter-Domain Multicast Routing (idmr) ------------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Tony Ballardie Bill Fenner Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:idmr@cs.ucl.ac.uk To Subscribe: idmr-request@cs.ucl.ac.uk Archive: http://www.jnx.com/~pusateri/idmr Description of Working Group: Existing inter-domain multicast routing protocols are not scalable to a large internetwork containing very large numbers of active wide-area groups. The purpose of the IDMR Working Group, therefore, is to discuss proposed inter-domain multicast routing protocols, and put forward one (or a hybrid of several) as a Proposed Standard to the IESG. Several proposals have been made to date, including Core-Based Tree (CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable Reverse Path Multicasting (SRPM). Some of the above have yet to be reviewed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 94 Mar 97 Protocol Independent Multicast MIB Jul 94 Jul 97 Internet Group Management Protocol MIB Jul 94 Mar 97 IP Multicast Routing MIB Aug 95 Oct 97 Internet Group Management Protocol, Version 2 Jan 96 May 97 Protocol Independent Multicast Version 2, Dense Mode Specification Feb 96 Oct 97 Distance Vector Multicast Routing Protocol Apr 96 New Core Based Tree (CBT) Multicast Border Router Specification Jul 97 New Core Based Trees (CBT) Multicast Routing MIB Aug 97 Oct 97 Border Gateway Multicast Protocol (BGMP): Protocol Specification Sep 97 New Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification Inter-Domain Routing (idr) -------------------------- Charter Last Modified: 04-Jun-97 Current Status: Active Working Group Chair(s): Susan Hares Y Rekhter Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:idr@merit.edu To Subscribe: idr-request@merit.edu Archive: ftp://ftp.merit.edu/mail.archives/idr Description of Working Group: The main list for this working group is bgp@ans.net, but there is also an IDRP-specific mailing list: - List: idrp@merit.edu - To Subscribe: idrp-request@merit.edu - Archive: merit.edu:/pub/archive/idrp The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter-Domain Routing Protocol (IDRP) as scalable inter-autonomous system routing protocols capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 (IPv4). IDRP is seen as a protocol that will support IPv4 as well as the next generation of IP (IPv6). The working group will plan a smooth transition between BGP-4 and IDRP. Documents: 1) BGP-4 (standards track) This document contains the specification of the BGP protocol that enables it to be used as a protocol for exchange of ``inter-autonomous system information'' among routers to support forwarding of IPv4 packets across multiple autonomous systems. 2) BGP-4 MIB (standards track) This document contains the MIB definitions for BGP-4. 3) IDRP for IPv4/IPv6 (standards track) This document contains the appropriate adaptations of the IDRP protocol definition that enables it to be used as a protocol for exchange of ``inter-autonomous system information'' among routers to support forwarding of IPv4 or IPv6 packets across multiple autonomous systems. 4) IDRP MIB (standards track) This document contains the MIB definitions for IDRP. 5) BGP/IDRP -- OSPF Interactions (standards track) This document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP - OSPF interactions, and IDRP - IS-IS interaction documents. 6) BGP/IDRP Usage (standards track) Most of BGP/IDRP Usage document will reference the CIDR (supernetting) RFCs and related Internet-Drafts. IDRP Usage will contain a sample policy configuration language and examples on how to use IDRP in the Internet today. 7) BGP-4 to IDRP v6 Transition (standards track) This document will provide information on how to transition between BGP-4 and IDRP v6 networks. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 94 Jun 97 A Border Gateway Protocol 4 (BGP-4) Nov 95 Mar 96 Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Feb 97 Jul 97 A Framework for Inter-Domain Route Aggregation Jul 97 New Using a Dedicated AS for Sites Homed to a Single Provider Jul 97 New Route Aggregation Tutorial Sep 97 Sep 97 Multiprotocol Extensions for BGP-4 Sep 97 New Capabilities Negotiation with BGP-4 Integrated Directory Services (ids) ----------------------------------- Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): Sri Sataluri Linda Millington Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-ids@umich.edu To Subscribe: ietf-ids-request@umich.edu Archive: ftp://terminator.rs.itd.umich.edu/ietf-ids/archive Description of Working Group: The Integrated Directory Services (IDS) Working Group is chartered to facilitate the integration and interoperability of current and future directories into a unified Internet directory service. This work will unite directories based on a heterogeneous set of directory services protocols (X.500, WHOIS++, etc.). In addition to specifying technical requirements for the integration, the IDS Working Group will also contribute to the administrative and maintenance issues of directory service offerings by publishing guidelines on directory data integrity, maintenance, security, and privacy and legal issues for users and administrators of directories. The IDS Working Group will pay special attention to the creation of an Internet White Pages Directory Service and will sponsor and track projects to achieve this goal and specifically take steps to facilitate wide-spread experimentation of the protocols evolving in the ASID Working Group. The IDS Working Group will work on applications of directory technology and will track ongoing applications projects. The IDS Working Group will assume responsibility for the creation and maintenance of on-line catalogs of directory services implementations. These catalogs will be periodically published as Informational RFCs. The IDS Working Group will take up the unfinished tasks of the WHIP - White Pages Requirements Working Group - that was constituted at the Seattle IETF. The WHIP Working Group set out to define the basic requirements for a Simple Internet White Pages Service. The IDS Working Group will liaise with the groups working on development and deployment of the various directory service protocols. The IDS Working Group is a combined effort of the Applications Area and the User Services Area of the IETF. Ongoing Activities: Track emerging directory service protocols in order to identify the need for specifying standards for interworking with other service protocols Liaise with groups working on deployment and development of directory services to locate and fix interoperability problems. Identify unfilled needs of directory service offerers, administrators, and users. Catalogs maintained on-line, with occasional publication as RFCs: RFC due On-line version Name Dec 95 Jun 95 A Catalog of WHOIS++ Implementations. -- Patrick Faltstrom (first issue) Dec 95 Jul 95 The On-line X.500 Directory Implementations Catalog (on-line version of RFC 1632). -- Chris Apple and Ken Rossen Pilot Projects reporting to this group: The Long Bud Project -- Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing (RFC 1802) Co-ordinator: Kevin Jordan Lifetime: Jan 94 - Dec 96 The Internet Nomenclator Project Co-ordinator: Joann Ordille Lifetime: Jun 95 - Jun 97 The Internet Whois++ Project Co-ordinator: Patrick Faltstrom Lifetime: Jun 95 - Jun 97 The Internet X.500 (1993) Directory Project Co-ordinator: Vincent Berkhout Lifetime: Dec 95 - Dec 97 The Schema Registry project - identifying and publishing X.500 schema elements used on the Internet Co-ordinator: Sri Sataluri Lifetime: November 94 - Nov 96 Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 95 New Introducing a Directory Service Dec 95 May 97 The CCSO Nameserver (Ph) Architecture May 96 Apr 97 Best Current Practice for the Internet White Pages Service Jun 96 Aug 97 Simple Nomenclator Query Protocol (SNQP) Sep 96 Aug 97 Internet Nomenclator Project Nov 96 Sep 97 Naming Plan for Internet Directory-Enabled Applications Interfaces MIB (ifmib) ---------------------- Charter Last Modified: 02-Sep-97 Current Status: Active Working Group Chair(s): Theodore Brunner Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:if-mib@thumper.bellcore.com To Subscribe: if-mib-request@thumper.bellcore.com Archive: ftp://thumper.bellcore.com/pub/tob/ifmib Description of Working Group: The Interfaces MIB working group is reactivated and chartered to accomplish one task: to prepare a recommendation to the IESG evaluating RFC 1573 with respect to the standards track. The recommendation will document implementation, interoperability, and deployment experience. If this experiences suggests that changes should be made to the documents, new drafts may be prepared. The recommendation will report one of four outcomes: that the RFC should be advanced from proposed to draft status, without changes (if no problems are found); that a draft prepared by the working group, should replace the RFC, and be designated a draft standard (if only minor changes are made); that a draft prepared by the working group, should replace the RFC, and be designated a proposed standard (if major changes or feature enhancements are made); or, that the RFC should be designated as historic (if this technology is problematic). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jan 96 Oct 97 The Interfaces Group MIB Jun 96 Jun 97 Definitions of Managed Objects for System and Interface Testing Integrated Services (intserv) ----------------------------- Charter Last Modified: 13-May-97 Current Status: Active Working Group Chair(s): C. Partridge John Wroclawski Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:int-serv@isi.edu To Subscribe: int-serv-request@isi.edu Archive: ftp://ftp.isi.edu/int-serv/int-serv.mail Description of Working Group: Recent experiments demonstrate the capability of packet switching protocols to support Integrated Services --- the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. These experiments suggest that expanding the Internet service model would better meet the needs of these diverse applications. The purpose of this working group is to specify this enhanced service model and then to define and standardize certain interfaces and requirements necessary to implement the new service model. The working group will focus on defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure. Enhancements to individual protocols (e.g., adding additional routing information to routing protocols, or choosing IP queueing disciplines for routers) will be left to other working groups, except in those rare cases where detailed definitions of behavior are critical to the success of the enhanced architecture. Extending the Internet service model raises a series of questions. The working group will focus on the three problems listed below: (1) Clearly defining the services to be provided. The first task faced by this working group is to define and document the enhanced Internet service model. (2) Defining the application service, router scheduling and (general) subnet interfaces. The working group must define at least three high-level interfaces: that expressing the application's end-to-end requirements, that defining what information is made available to individual routers within the network, and the additional expectations (if any) the enhanced service model has for subnet technologies. The working group will define these abstract interfaces, and will coordinate with and advise IP over "subnet" working groups (such as IP over ATM) in this. (3) Developing router validation requirements which can ensure that the proper service is provided. We assume that the Internet will continue to contain a heterogeneous set of routers, running different routing protocols and using different forwarding algorithms. The working group will seek to define a minimal set of additional router requirements which ensure that the Internet can support the new service model. Rather than presenting specific scheduling and admission control algorithms which must be supported, these requirements will likely take the form of behavioral tests which measure the capabilities of routers in the integrated services environment. This approach is used because no single algorithm seems likely to be appropriate in all circumstances at this time. The working group will coordinate with the Benchmarking Working Group (BMWG). We expect to generate three RFCs as a product of performing these tasks. An important aspect of this working group's charter is in coordination with the development of IP Next Generation. The working group will be reviewed in November 1995 to determine if it should be re-chartered as is or modified to reflect IPng developments, in particular, but also operational and commercial developments. The IESG deems the great significance of this working group to merit this unusual review. In addition, because many of the integrated services concepts are new, the working group may produce Informational RFCs explaining specific algorithms that may be appropriate in certain circumstances, and may host some educational meetings to assist both IETF members and members of the larger Internet community to understand the proposed enhancements to IP. The working group proposes to hold regular meetings beyond those held at the IETF meetings. APPENDIX - Integrated Services Working Group Management Plan The general chair is Craig Partridge (BBN). The co-chairs are Dave Clark (MIT), Scott Shenker (XEROX), and John Wroclawski (MIT). The dual reasons for this management structure are: (1) The working group will have do considerably more outreach into the larger networking community than the typical IETF working group. For instance, one of the important tasks is to convince the larger public that IP is suitable for integrated services. So we need management manpower to do outreach. (2) The working group has a lot of work to do and swiftly. Even though we plan to spin off working groups as fast as we can, a lot of key architectural decisions will need to be made in one place (e.g., by this working group) if the final architecture is to be sound. So we need management manpower just to keep the working group moving. So Craig has primary responsibility for keeping the working group moving, and Dave, Scott, and John have primary responsibility for outreach to different communities (and titles sufficient to show they can speak for the working group). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 97 Oct 97 A Measurement Based Admission Control Algorithm for Controlled-Load Service with a Reference Implementation Framework Oct 97 New Integrated Services Management Information Base Internetworking Over NBMA (ion) ------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): A. Malis George Swallow Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:ion@nexen.com To Subscribe: ion-request@nexen.com In Body: In Body: subscribe Archive: ftp://ftp.nexen.com/pub/ion Description of Working Group: Note: This Working Group is jointly chartered by the Routing Area. The Routing Area Director: Joel Halpern (jhalpern@newbridge.com) Motivation The Internetworking Over NBMA Working Group was formed to combine the work of two previous working groups, IP Over ATM (ipatm) and Routing Over Large Clouds (rolc), because these two groups were often working very closely together on similar, if not identical, problems and solutions. The group will be evolutionary, not revolutionary; it will continue the work in the previous groups on the NBMA Next Hop Resolution Protocol (NHRP), IPv4 over ATM, and IPv6 over ATM. Description This WG will focus on the issues involved in internetworking network layer protocols over NBMA (non-broadcast multiple access) subnetwork technologies, such as ATM, Frame Relay, SMDS, and X.25 private and public networks. The group will endeavor to make all its solutions applicable to the entire range of network layer protocols and NBMA subnetworks. We recognize, however, that there will be cases where specific optimizations to IPv4, IPv6, and particular subnetwork technologies will result in better service to the user. The group will focus on protocols for encapsulation, multicasting, addressing, address resolution and neighbor discovery, interactions with and optimization of internetworking-layer routing protocols when run over NBMA subnetworks, and protocol-specific network management support, as appropriate. The working group will submit these protocols for standardization. The working group may also produce experimental and informational documents, including "Best Current Practices" guidelines, as required. For ATM, the WG will continue the ipatm WG's transition from the LIS model described in RFC 1577 to the generalized NHRP model developed by the rolc WG, including a transition plan for existing networks. The working group will coordinate its activities with the following other working groups: 1) Integrated Services over Specific Lower Layers (issll), for coordinating Quality of Service (QoS) issues and the implementation of IP integrated services capabilities (RSVP, the service models, etc.) over NBMA networks. 2) IP Next Generation (ipng), for IPv6 over ATM coordination. The working group will also coordinate its work with other relevant standards bodies (e.g., ATM Forum, Frame Relay Forum, ANSI T1S1, ITU-T) and make recommendations to these organizations regarding the requirements for IP internetworking where the current published subnetwork standards, practices, or functionality do not meet the needs of internetworking. The working group will not develop subnetwork layer standards. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Sep 97 Management Information Base for Frame Relay DTEs Mar 93 Oct 97 NBMA Next Hop Resolution Protocol (NHRP) Mar 95 Jul 97 NHRP Protocol Applicability Statement Sep 95 Oct 97 Classical IP and ARP over ATM Nov 95 Jul 97 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 Feb 96 Oct 97 Server Cache Synchronization Protocol (SCSP) Mar 96 Oct 97 ATM Signalling Support for IP over ATM - UNI Signalling 4.0 Update Apr 96 New IPv6 over Non-Broadcast Multiple Access (NBMA) networks Jul 96 Jan 97 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) Jul 96 May 97 Multiprotocol Interconnect over Frame Relay Nov 96 May 97 Classical IP to NHRP Transition Nov 96 May 97 Inverse Address Resolution Protocol Nov 96 Sep 97 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks Feb 97 New NHRP for Destinations off the NBMA Subnetwork Feb 97 Aug 97 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM Apr 97 New A Distributed ATMARP Service Using SCSP Apr 97 Oct 97 A Distributed NHRP Service Using SCSP Jul 97 New ILMI-Based Server Discovery for ATMARP Jul 97 New ILMI-Based Server Discovery for MARS Jul 97 New A Distributed MARS Service Using SCSP Jul 97 New Intra-area IP unicast among routers over legacy ATM Aug 97 New ILMI-Based Server Discovery for NHRP Oct 97 New IPv6 over ATM Networks IP Over IEEE 1394 (ip1394) -------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Tony Li Myron Hattig Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:ip1394@mailbag.intel.com To Subscribe: listserv@mailbag.intel.com In Body: subscribe ip1394 Archive: listserv@mailbag.intel.com. In body, get ip1394 LOGyymm Description of Working Group: The goal of the IP1394 Working Group is to define how the Internet Protocol (IPv4 & IPv6) is supported over IEEE 1394 Serial Bus. IEEE 1394 Serial Bus (1394) is specified by IEEE Std 1394-1995 and the draft standard IEEE P1394a. The IP1394 working group intends for the specification to be utilized by devices with a broad range of capabilities. These devices are expected to include (but not be limited to) both traditional equipment such as computers, as well as equipment that has not traditionally been networked, such as consumer electronics (e.g. TVs & VCRs). Unlike most other data link protocols, IEEE 1394 provides the capability for isochronous as well as asynchronous transmission. This capability can have a significant impact on how IP is supported on 1394. The IP1394 working group will prepare an architecture document and appropriate protocol documents for the usage of these unique link layer properties. Both IPv4 and IPv6 will be addressed, although in separate documents. The IP1394 working group is chartered to deliver the documents described below. The working group will maintain informal liaison with other standards groups and industry organizations doing related work. Some of these documents may depend upon facilities not currently standardized in 1394. If necessary, working group members will work within the IEEE standards process to request modification or extension of existing IEEE standards (or standards in development). The deliverable documents are as follows: - An architecture document detailing the interactions between 1394 asynchronous and isochronous transmissions, resource reservation and multicast. - An IPv4 over 1394 document covering the encapsulation and framing of IPv4 unicast, multicast and broadcast packets over asynchronous and isochronous 1394, including address resolution. - An IPv6 over 1394 document covering the encapsulation and framing of IPv6 unicast, multicast and broadcast packets over asynchronous and isochronous 1394, including neighbor discovery. - A media-specific MIB for managing 1394 interfaces. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 97 Oct 97 Ipv4 over IEEE 1394 IP over Cable Data Network (ipcdn) ---------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Mike St. Johns Masuma Ahmed Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:ipcdn@terayon.com To Subscribe: ipcdn-request@terayon.com Archive: ftp://ftp.terayon.com/pub/ipcdn Description of Working Group: The goal of the IPCDN WG is to define how the Internet Protocol (IP) is to be supported on a Cable Television (CATV) Data Network. The working group will prepare a framework and requirements document describing a typical CATV infrastructure and how an IP based network might be architected to utilize this infrastructure. It will also address the service interface between IP and the CATV Data Network. The architecture document will discuss the technical details related to the differences between symmetric and asymmetric CATV Data Networks. A terms of reference document will also be published. Currently, there are no standards available for supporting IP over a CATV Data Network. The IEEE 802.14 WG is chartered to specify the physical layer and data link layer protocols for the CATV Data Network. However, this does not address the issue of mapping higher level protocols onto the hybrid fiber coax (HFC) access networks. The IPCDN WG will define a specification of how IP is mapped onto HFC access networks. Both IPv4 and IPv6 will be addressed, although in separate documents. The following topics will be discussed: multicast, broadcast, address mapping and resolution (for IPv4) and neighbor discovery (for IPv6). The IPCDN WG will also address issues related to network management, especially as they concern HFC access networks. It is expected that other services (i.e. DHCP, RSVP, IPSEC, etc.) will operate unmodified. Also, depending on the capabilities provided by cable data network service, specific mappings of RSVP service classes to lower layer services might be desirable. If additional capabilities become necessary, these will be directed to the appropriate group. The IPCDN WG will also keep informed on what other groups in the industry are doing as it relates to the work of this working group. The WG is chartered to deliver the following set of documents: - informational RFCs covering the framework, architecture, requirements and terms of reference for Cable Data Networks. - an IPv4-over-HFC access network document covering the mapping of IP over RF channels, encapsulation and framing of IPv4 packets, IP to modem and/or PC address resolution, multicast, and broadcast. - an IPv6-over-HFC access network document covering the mapping of IP over RF channels , encapsulation and framing of IPv6 packets, IP to modem and/or PC address resolution, neighbor discovery, multicast, and broadcast. - a media-specific mib for managing HFC spectrum. - a mib for managing cable data network service including management of IP over cable data network. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 97 Sep 97 Cable Device Management Information Base for MCNS compliant Cable Modems and Cable Modem Termination Systems Jul 97 Sep 97 Radio Frequency (RF) Interface Management Information Base for MCNS compliant RF interfaces Jul 97 New IP Over Cable Data Networks - Terms of Reference Jul 97 New Logical IP Subnetworks over IEEE 802.14 Services Aug 97 New Logical IP Subnetworks over MCNS Data Link Services IPNG (ipngwg) ------------- Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): Bob Hinden Steve Deering Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:ipng@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com In Body: in body: subscribe ipng Archive: ftp://playground.sun.com/pub/ipng/mail-archive Description of Working Group: Editor: Bob Hinden (hinden@eng.sun.com) The next generation of the Internet Protocol (IPv6) is intended to support Internet traffic for many years into the future by providing enhancements over the capabilities of the existing IPv4 service. This working group will produce specifications for the core functionality of that service. The working group shall carry out the recommendations of the IPng Area Directors as outlined at the July 1994 IETF and in ``The Recommendation for the IP Next Generation Protocol,'' Internet-Draft, (draft-ipng-recommendation-00.txt), September 1994. The working group shall use the following documents as the basis of its work: - Simple Internet Protocol Plus (SIPP) Specification (128 bit version) - SIPP Addressing Architecture - An Architecture for IPv6 Unicast Address Allocation - Simple SIPP Transition (SST) Overview - SIPP Program Interfaces for BSD Systems - SIPP Security Architecture - SIPP Authentication Header - SDRP Routing Header for SIPP-16 - IP Next Generation Overview - ICMP and IGMP extensions for SIPP - FTP Operation Over Big Address Records (FOOBAR) - DNS Extensions to support SIPP Enhancements to be considered: - Large Packets: Consider extensions for support of datagrams which are larger than 64K. - Source Routing: The working group shall consider enhanced source routing capabilities for IPng. - Tunneling: Complete specification of IPng in IPng tunneling. - Address format and assignment plan: The working group shall review the details of address structure as specified in [SIPP-16] and shall repair any deficiencies with respect to current or near-term addressing requirements, assuming a fixed, 16-byte size. The specification shall provide a mechanism for supporting multiple additional formats, for possible enhancement to incorporate other popular addressing schemes. - Routing Structure: In completing the addressing details, the working group shall ensure that routing according to current, CIDR-like schemes can be supported comfortably. - Autoconfiguration: Coordinate with the IPng Address Autoconfiguration Working Group. - Transition: The working group shall coordinate with the related transition and conversion efforts (ngtrans, tacit, nosi, etc.) to ensure that the base specification provides the facilities required for the transition from IPv4. - Security: A set of base documents for IPng security shall be completed. This shall include algorithms for authentication and privacy carried as IPng extension headers and include an initial selection of required encryption and key management algorithms and a facility to support other optional algorithms. The working group should also examine IPng firewall issues and if necessary develop specific firewall frameworks. - Minimum MTU: Consider a larger minimum MTU. - Header Compression: Consider ways to abbreviate the IPng header in the contexts of native IPng, multiple IPng packets in a flow, and encapsulated IPng. - TCP/UDP: The IPng Working Group will specify the procedures for hosts to compute and verify TCP/UDP pseudo-headers. Any other changes to TCP beyond making TCP work with IPng are out of scope of the working group and should be dealt with by a TCPng Working Group. The IPng Working Group will coordinate with other groups, including Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR, Security, Applications, Network Management, IP over ATM, etc. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 95 Jun 97 Generic Packet Tunneling in IPv6 Specification Jun 96 Jan 97 Link Local Addressing and Name Resolution in IPv6 Jun 96 Jul 97 IPv6 Router Alert Option Oct 96 Jul 97 IPv6 Multicast Address Assignments Dec 96 Jul 97 IP Version 6 over PPP Feb 97 Jun 97 Management Information Base for IP Version 6: Textual Conventions and General Group Feb 97 Mar 97 Management Information Base for IP Version 6: ICMPv6 Group Feb 97 Mar 97 Management Information Base for IP Version 6: UDP and TCP Groups Feb 97 New GSE - An Alternate Addressing Architecture for IPv6 Mar 97 Sep 97 Transmission of IPv6 Packets over FDDI Networks Mar 97 Sep 97 Transmission of IPv6 Packets over Ethernet Networks Mar 97 New Synthesis of Routing Goop and AAAA Records in IPv6 Mar 97 New IP Version 6 Addressing Architecture Mar 97 Sep 97 Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Mar 97 Jul 97 Router Renumbering for IPv6 May 97 Jul 97 An IPv6 Aggregatable Global Unicast Address Format May 97 Oct 97 IP Version 6 Addressing Architecture May 97 Jul 97 IPv6 Testing Address Allocation Jun 97 New IP Version 6 Management Information Base for the Transmission Control Protocol Jun 97 New IP Version 6 Management Information Base for the User Datagram Protocol Jun 97 Oct 97 Transmission of IPv6 Packets over Token Ring Networks Jul 97 New TLA and NLA Assignment Rules Jul 97 Jul 97 IPv6 Name Lookups Through ICMP Jul 97 New Neighbor Discovery for IP Version 6 (IPv6) Jul 97 New IPv6 Stateless Address Autoconfiguration Jul 97 New Internet Protocol, Version 6 (IPv6) Specification Jul 97 New Site prefixes in Neighbor Discovery Oct 97 New Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Internet Printing Protocol (ipp) -------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Steve Zilles Carl-Uno Manros Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:ipp@pwg.org To Subscribe: ipp-request@pwg.org Archive: ftp://ftp.pwg.org/pub/pwg/ipp/ Description of Working Group: There is currently no universal standard for printing. Several protocols are in use, but each has limited applicability and none can be considered the prevalent one. This means that printer vendors have to implement and support a number of different protocols and protocol variants. There is a need to define a protocol which can cover the most common situations for printing on the Internet. The goal of this working group is to develop requirements for Internet Printing and to describe a model and semantics for Internet Printing. The further goal is to define a new application level Internet Printing Protocol for the following core functions: - for a user to find out about a printer's capabilities - for a user to submit print jobs to a printer - for a user to find out the status of a printer or a print job - for a user to cancel a previously submitted job The Internet Print Protocol is a client-server type protocol which should allow the server side to be either a separate print server or a printer with embedded networking capabilities. The focus of this effort is optimized for printers, but might be applied to other output devices. These are outside the scope of this working group. The working group will also define a set of directory attributes that can be used to ease finding printers on the network. The Internet Print Protocol will include mechanisms to ensure adequate security protection for materials to be printed, including at a minimum mechanisms for mutual authentication of client and server and mechanisms to protect the confidentiality of communications between client and server. Finally, the IPP working group will produce recommendations for interoperation of LPR clients with IPP servers, and IPP clients with LPR servers. These recommendations will include instructions for both the translation of the LPR protocol onto IPP and the translation of the IPP protocol onto LPR. However, there is no expectation to provide new IPP features to LPR clients, nor is there an explicit requirement to translate LPR extensions to IPP, beyond those features available in the 4.2BSD UNIX implementation of LPR, and which are still useful today. Other capabilities that will be examined for future versions include: - security features for authentication, authorization, and policies - notifications from the server to the client - accounting Subjects currently out of scope for this working group are: - protection of intellectual property rights - fax input - scanning The working group shall strive to coordinate its activities with other printing-related standards bodies, without the need to be strictly bound by their standards definitions. These groups are: - ISO/IEC JTC 1/SC 18/WG 4 on Document Printing Application (ISO/IEC 10175 parts 1 - 3) - The Object Management Group (OMG) on OMG Printing Facility (in development) - IEEE (POSIX System Administration - Part 4: Printing Interfaces) - X/Open (Printing Systems Interoperabilty Specification) - The Printer Working Group Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Oct 97 Requirements for an Internet Printing Protocol Mar 97 Oct 97 Internet Printing Protocol/1.0: Model and Semantics Mar 97 Jun 97 Internet Printing Protocol/1.0: Directory Schema Jun 97 Jul 97 Internet Printing Protocol/1.0: Security Jul 97 Jul 97 Mapping between LPD and IPP Protocols Jul 97 Oct 97 Internet Printing Protocol/1.0: Protocol Specification Jul 97 Aug 97 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP) IP Payload Compression Protocol (ippcp) --------------------------------------- Charter Last Modified: 21-Jul-97 Current Status: Active Working Group Chair(s): Naganand Doraswamy Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:ippcp@external.cisco.com To Subscribe: mailer@cisco.com In Body: subscribe/unsubscribe ippcp [email_addr] in body Archive: ftp://ftp-eng.cisco.com/ippcp/ippcp Description of Working Group: Lossless data compression has commonly been deployed in layers below IP (PPP being one example). However, the anticipated deployment of higher-layer encryption protocols (e.g., IPSec) threatens to reduce the effectiveness of lower-layer compression techniques since encrypted data cannot be compressed. The IP Payload Compression Protocol Working Group will develop protocol specifications that make it possible to perform lossless compression on individual payloads before the payload is processed by a protocol that encrypts it. These specifications will allow for compression operations to be performed prior to the encryption of a payload by such protocols as IPSec. The Working Group will focus on the compression of independent payloads (i.e., independent datagrams) in a stateless manner. By stateless, we mean that decompression of a received packet does not rely on correct reception or correct ordering of previous packets. The immediate problem the Working Group will address is the development of a payload compression protocol for use in conjunction with IPSec. The working group will develop its specifications to support both IPv4 and IPv6. Although the primary motivation for this WG is the need to compress packets when IPSec is used, the WG will develop an architecture that does not preclude its use with other potential protocols or the absence of IPSec. The working group will identify and document the mechanisms that allow two communicating parties to negotiate the use of compression as well as the compression format to be employed. The Working Group will consider defining extensions to ISAKMP to support the negotiation of compression parameters. Use of ISAKMP as the immediate effort shall not preclude compression in the absence of IPsec. Alternate negotiation mechanisms (or even static negotiation), if appropriate, shall be identified and extended as needed to accommodate the use of payload compression functionality. Since compression will be negotiated, existing implementations of IP will interoperate with implementations that support compression. The output of this WG will consist of a base architectural document that provides the framework for how compression will be done (i.e., defines the compression "shim"), together with one or more documents giving specific compression algorithms and formats. The architectural document will describe how different compression algorithms can be negotiated and supported, but the documenting of specific compression algorithms will be done elsewhere (i.e., in standalone documents). A registration mechanism for various compression formats will be specified as part of the base protocol. If possible, an existing registration mechanism for compression formats shall be used (e.g., Compression Control Protocol options of PPP). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 97 Oct 97 IP Payload Compression Protocol (IPComp) IP Performance Metrics (ippm) ----------------------------- Charter Last Modified: 21-Oct-97 Current Status: Active Working Group Chair(s): Guy Almes Vern Paxson Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:ippm@advanced.org To Subscribe: ippm-request@advanced.org Archive: ftp://ftp.advanced.org/pub/IPPM/archive Description of Working Group: The IPPM WG will develop a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics will be designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgement (i.e. define "good" and "bad"), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG will define specific metrics, cultivate technology for the accurate measurement and documentation of these metrics, and promote the sharing of effective tools and procedures for measuring these metrics. It will also offer a forum for sharing information about the implementation and application of these metrics, but actual implementations and applications are understood to be beyond the scope of this working group. Internet-Drafts: No Current Internet-Drafts. IP Security Protocol (ipsec) ---------------------------- Charter Last Modified: 01-Nov-97 Current Status: Active Working Group Chair(s): Theodore Ts'o Robert Moskowitz Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ipsec@tis.com To Subscribe: ipsec-request@tis.com Archive: ftp://ftp.tis.com/pub/lists/ipsec Description of Working Group: Rapid advances in communication technology have accentuated the need for security in the Internet. The IP Security Protocol Working Group (IPSEC) will develop mechanisms to protect client protocols of IP. A security protocol in the network layer will be developed to provide cryptographic security services that will flexibly support combinations of authentication, integrity, access control, and confidentiality. The protocol formats for the IP Authentication Header (AH) and IP Encapsulating Security Payload (ESP) will be independent of the cryptographic algorithm. The preliminary goals will specifically pursue host-to-host security followed by subnet-to-subnet and host-to-subnet topologies. Protocol and cryptographic techniques will also be developed to support the key management requirements of the network layer security. The Internet Key Management Protocol (IKMP) will be specified as an application layer protocol that is independent of the lower layer security protocol.The protocol will be based on the ISAKMP/Oakley work begun in: draft-ietf-ipsec-isakmp-05.txt, draft-ietf-ipsec-oakley-01.txt, and draft-ietf-ipsec-isakmp-oakley-00.txt A follow on work item may incorporate mechanisms based on SKIP as defined in: draft-ietf-ipsec-skip-07.txt and related documents.Flexibility in the protocol will allow eventual support of Key Distribution Centers (KDC), such as are used by Kerberos. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 95 Jul 97 Internet Security Association and Key Management Protocol (ISAKMP) Feb 96 Jul 97 The OAKLEY Key Determination Protocol May 96 New The ESP Triple DES Transform Jun 96 Oct 97 IP Authentication Header Jun 96 Jul 97 The resolution of ISAKMP with Oakley Nov 96 Oct 97 The Internet IP Security Domain of Interpretation for ISAKMP Nov 96 Mar 97 Inline Keying within the ISAKMP Framework. Jan 97 New Implementation of Virtual Private Network (VPNs) with IP Security Apr 97 New The ESP RC5-CBC Algorithm May 97 New The ESP CAST128-CBC Algorithm May 97 Aug 97 A revised encryption mode for ISAKMP/Oakley May 97 New The ESP DES-CBC Transform Jul 97 Jul 97 IP Security Document Roadmap Jul 97 New The Use of HMAC-SHA-1-96 within ESP and AH Jul 97 New The Use of HMAC-MD5-96 within ESP and AH Jul 97 New The ESP DES-CBC Cipher Algorithm With Explicit IV Jul 97 New ESP with Cipher Block Chaining (CBC) Jul 97 New The ESP ARCFOUR Algorithm Jul 97 New The ESP DES-XEX3-CBC Transform Jul 97 New The ESP Blowfish-CBC Algorithm Using an Explicit IV Jul 97 New The ESP 3DES-CBC Algorithm Using an Explicit IV Jul 97 New The ESP IDEA-CBC Algorithm Using Explicit IV Jul 97 Oct 97 IP Encapsulating Security Payload (ESP) Jul 97 New The ESP CAST5-128-CBC Transform Oct 97 New The ESP CBC-Mode Cipher Algorithms Oct 97 New The ISAKMP Configuration Mode ISDN MIB (isdnmib) ------------------ Charter Last Modified: 12-Sep-97 Current Status: Active Working Group Chair(s): Ed Alcoff Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Technical Advisor(s): Fred Baker Mailing Lists: General Discussion:isdn-mib@cisco.com To Subscribe: isdn-mib-request@cisco.com Archive: ftp://ftp-eng.cisco.com/ftp/isdn-mib/isdn-mib Description of Working Group: The goal of the working group is to define the minimal set of managed objects for SNMP-based management of ISDN interfaces. ISDN interfaces are supported on a variety of equipment (for data and voice) including terminal adapters, bridges, hosts, and routers. The set of objects will be consistent with the SNMP framework and existing SNMP standards. The working group will solicit any existing enterprise-specific MIB modules to use as input to the standard MIB. The scope of the MIB is to support remote configuration and administration; support all ISDN interfaces and switch types; provide statistical information of ISDN call activity; a table of ISDN call history; and SNMP traps specific to ISDN call activity. RFC 1573 shall be used to define interface layering issues. Internet-Drafts: No Current Internet-Drafts. IS-IS for IP Internets (isis) ----------------------------- Charter Last Modified: 20-Oct-94 Current Status: Active Working Group Chair(s): Doug Montgomery Chris Gunner Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:isis@merit.edu To Subscribe: isis-request@merit.edu Archive: Description of Working Group: The IS-IS for IP Internets Working Group will develop additions to the existing OSI IS-IS routing protocol to support IP environments and dual OSI and IP environments. Internet-Drafts: No Current Internet-Drafts. Internet School Networking (isn) -------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Jodi Ito Sepideh Boroumand User Services Area Director(s): Joyce K. Reynolds User Services Area Advisor: Joyce K. Reynolds Mailing Lists: General Discussion:isn-wg@nasa.gov To Subscribe: listmanager@nasa.gov In Body: subscribe isn-wg Archive: Description of Working Group: The Internet School Networking Working Group is chartered to address issues related to the connection of primary and secondary schools worldwide to the Internet. The key audiences include network service providers and educational policy makers responsible for network access and use. The key areas of focus for this group are advocacy and articulation. 1. Advocacy. The ISN Working Group will facilitate dialog between the primary and secondary education community and the Internet engineering community in order to identify and fulfill the needs of the primary and secondary school community. 2. Articulation. Informed by the group's experience, and with input from other IETF working groups, the ISN Working Group will articulate solutions to the challenges a school may experience in seeking and gaining a connection to the Internet, as well as the benefits of such a connection. Advantages to Internet connectivity may be articulated by means of pointers to such services as user interfaces, directories, organizations, and training programs, as well as to other resources. Articulation will most often be in the form of periodic documents that address key issues of interest to the school networking community. Representative issues to be addressed by the group include connectivity models, educational directories, and acceptable use policies. Internet-Drafts: No Current Internet-Drafts. Integrated Services over Specific Link Layers (issll) ----------------------------------------------------- Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): John Wroclawski Eric Crawley Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:issll@mercury.lcs.mit.edu To Subscribe: issll-request@mercury.lcs.mit.edu Archive: ftp://mercury.lcs.mit.edu/pub/issll/mail/ Description of Working Group: The ISSLL Working Group defines specifications and techniques needed to implement Internet Integrated Services capabilities within specific network technologies. The Internet Integrated Services design, developed within the IETF by working groups such as INTSERV and RSVP, specifies extensions to the IP architecture which allow applications to request and receive a specific level of service from the internetwork, as alternatives to the current IP best-effort service class. The work of these groups has resulted in technology-independent protocols and specifications. Focused engineering work to define the mapping of these universal specifications onto specific subnetwork technologies is now required. At minimum, the following points must be addressed for each candidate technology: - Service mappings. Service mappings define the way that the link layer technology is used to provide a particular IntServ traffic management service, such as controlled-load or guaranteed-delay. - Setup protocol mappings. Setup protocol mappings define how an internet- level setup protocol such as RSVP is implemented or mapped onto the link layer technology. - Adaptation protocols. Adaptation protocols are used to augment the native capabilities of the link-layer technology, when this is necessary to support required Integrated Services functions. - Statements of non-applicability. Statements of non-applicability describe which Integrated Service capabilities are not supported by the link layer technology under consideration. The ISSLL WG will carry out this work for all technologies with perceived market demand and of sufficient interest to its members. To ensure timely progress on each work item the WG will employ an administrative structure based on technology coordinators, as described below. The WG expects to coordinate its activities across technologies whenever technical commonality between layer two media is apparent. The WG chairs hold primary responsibility for this coordinating role. WG Outputs: The WG is expected to produce standards-track RFC's, informational RFC's and "best-current-practices" guidelines, as required. The need for standards-track RFC's is limited both because the work of the group is focused on the engineering of existing protocols to existing link layer technologies, and because in certain cases information and guidelines will better serve the needs of a rapidly evolving technology. Operational Structure: Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows: A technical coordinator will be identified and selected for each media technology adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that media, working with and motivating the document editors, and evangelizing the group's work within the community and relevant external organizations such as the IEEE and ATM Forum. Since many link layer media continue to evolve, and since that evolution may be influenced by the work of the ISSLL WG, it is expected that each technology work item will be divided into short term tasks, medium term tasks, and ongoing monitoring, as follows: - Short term tasks focus on using the existing technology as best as possible with no changes whatsoever. This work will accept whatever limits are imposed the link-level and IP-level technology, with the goal of creating the best solution possible within a 6-9 month timeframe. - Medium term tasks focus on planned changes to the technology that are currently being standardized and may not yet be widely available Ideally this work would conclude just as the changes become available in the market. In general a 1-1.5 year timeframe is appropriate for these tasks. - Monitoring focuses on tracking and advising on changes being made by others to a link layer technology, to allow it to better support the Integrated Services models and protocols. Generally, these efforts would be conducted as informal activities, rather than work items within the WG structure. The exception would be when formal cooperation between the WG and an external effort was required. In addition to the normal responsibilities of IETF working group chairs, the ISSLL chairs hold primary responsibility for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group. Relationship to Other Working Groups: The ISSLL WG maintains a close working relationship with the INTSERV and RSVP WG's. Particularly, ISSLL may wish to feed back information about the effectiveness or limitations of RSVP and INTSERV work in the context of a specific technology to these groups for review. ISSLL is also expected to interact with other WG's as needed to aid in the use of particular media (e.g. IPATM, PPPEXT). Coordinators for initially important technologies: ATM Sue Thomson, set@bellcore.com Low-Speed Serial Carsten Bormann, cabo@informatik.uni-bremen.de Ethernet Token Ring Wayne Pace, pacew@raleigh.ibm.com Frame Relay Cable Modems Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 96 Jul 97 Providing integrated services over low-bitrate links Jun 96 Aug 97 Interoperation of Controlled-Load and Guaranteed-Service with ATM Jul 96 Jul 97 SBM (Subnet Bandwidth Manager): A Proposal for Admission Control over IEEE 802-style networks Sep 96 Jul 97 The Multi-Class Extension to Multi-Link PPP Sep 96 May 97 A Framework for Providing Integrated Services Over Shared and Switched LAN Technologies Dec 96 Jun 97 Integrated Services over IEEE 802.1D/802.1p Networks Mar 97 Jul 97 PPP in a real-time oriented HDLC-like framing May 97 New Network Element Service Specification for Low Speed Networks Jul 97 New RSVP over ATM Implementation Requirements Jul 97 New A Framework for Integrated Services and RSVP over ATM Jul 97 New Integrated Service Mappings on IEEE 802 Networks Large Scale Multicast Applications (lsma) ----------------------------------------- Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): Jon Crowcroft Michael Myjak Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Technical Advisor(s): Allison Mankin Mailing Lists: General Discussion:lsma@gmu.edu To Subscribe: lsma-request@gmu.edu Archive: Description of Working Group: Note: Allyn Romanow is also an Area Technical Advisor. This group focuses on the needs of applications that require real-time or near real-time communications to support a large number of simulation processes (virtual entities). These applications have been analyzed by the U.S. Department of Defense to require IP multicast support for 10K simultaneous groups, for upwards of 100K virtual entities in a global sized WAN by the year 2000. The concrete example application is the Distributed Interactive Simulation work of the DIS Interoperability and Standards workshops and standardized as IEEE 1278 - 1995. The concrete example application is the Distributed Interactive Simulation work of the DIS Interoperability and Standards workshops and standardized as IEEE 1278 - 1995. Future simulation implementations will use the High Level Architecture (HLA) work sponsored by the U.S. Defense Modeling and Simulation Office, and which is currently being standardized by the newly formed Simulation Interoperability Standards Organization (SISO). The WG aims to provide documentation on how the IETF multicast protocols, conference management protocols, transport protocols and multicast routing protocols are expected to support the example application. The result of this WG will be two Informational documents that we hope will be used as input and advice by a number of IETF working groups, among them IDMR, ION, MBONED, MMUSIC, and by working groups being developed on Reliable Multicast Applications and QOS Routing. The document editors for the informational documents will be Steve Seidensticker for "Scenarios" and Mark Pullen for "Limitations". The Scenarios document will describe the environment in which distributed simulation applications operate. It will provide realistic example scenarios of small, medium and large simulation exercises. The Limitations product will document the limitations of current IETF products as they pertain to distributed applications. This document will offer concise examples of how distributed applications demonstrate these limitations and to the extent possible, offer potential solutions to the identified limitations. The documents will attempt to provide specific numbers for the demands placed on protocol or infrastructure, and for the limits that protocols impose on the applications. The group will assess the need for new protocols to support the requirements it identifies, and the Limitations document will report on this assessment. One recommendation it expects to document is for development of a virtual reality transfer protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Jul 97 Scenarios and Appropriate Protocols for Distributed Interactive Simulation Nov 96 Mar 97 Limitations of Internet Protocol Suite for Distributed Simulation in the Large Multicast Environment Jul 97 New Taxonomy of Communication Requirements for Large-scale Multicast Applications Mail and Directory Management (madman) -------------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Steve Kille Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:madman@innosoft.com To Subscribe: mailserv@innosoft.com In Body: subscribe ietf-madman Archive: innosoft.com:~/ietf-madman/archive.txt Description of Working Group: This working group is chartered to review the MIBs produced by the madman group while in the Network Management Area (RFCs 1565, 1566, and 1567 which were produced in January, 1994). The aim of this re-activation is to review and update these MIBs in the light of operational experience. This will lead to editorial and clarification changes, and updates driven by operational requirements based on experience. There have been a number of commerical and research implementations of these MIBs. The MIBs have also been adopted by the Electronic Mail Association, who have made input to the MADMAN work. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 95 Aug 97 Mail Monitoring MIB Nov 95 Aug 97 Network Services Monitoring MIB Dec 95 Aug 97 Directory Server Monitoring MIB Aug 97 New Message Tracking MIB Mobile Ad-hoc Networks (manet) ------------------------------ Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Joseph Macker Scott Corson Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:manet@itd.nrl.navy.mil To Subscribe: majordomo@itd.nrl.navy.mil In Body: subscribe manet Archive: Description of Working Group: A "mobile ad-hoc network" is an autonomous system of mobile routers (and associated hosts) connected by wireless links--the union of which form an arbitrary graph. The routers are free to move randomly and organize themselves arbitrarily; thus, the network's wireless topology may change rapidly and unpredictably. Such a network may operate in a standalone fashion, or may be connected to the larger Internet. The focus of the working group will be to standardize an intra-domain unicast routing protocol which efficiently reacts to topological changes while maintaining effective routing. The goal is to support networks scaling up to hundreds of routers. If this proves successful, future work may include development of other protocols to support additional routing functionality. The working group will examine the security issues around this protocol. They will consider the intended usage environments, and the threats that are (or are not) meaningful within that environment. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 97 New Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations Oct 97 New Mobile Ad Hoc Networking Terminology MBONE Deployment (mboned) ------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): David Meyer Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Technical Advisor(s): Scott Bradner Mailing Lists: General Discussion:mboned@ns.uoregon.edu To Subscribe: majordomo@ns.uoregon.edu Archive: ftp://ftp.uoregon.edu/mailing-lists/mboned* Description of Working Group: The MBONE Deployment Working Group will be a forum for coordinating the deployment, engineering, and operation of multicast routing protocols and procedures in the global Internet. This activity will include, but not be limited to: - Deployment of multicast routing in the global Internet. - Receive regular reports on the current state of the deployment of mbone technology. Create "practice and experience" documents that capture the experience of those who have deployed and are deploying various MBONE technologies (e.g. PIM, DVMRP, CBT). - Based on reports and other information, provide feedback to IDMR. - Develop mechanisms and procedures to aid in the transition to native multicast, where appropriate. - Develop mechanisms and procedures for sharing operational information to aid in operation of the global MBONE. - Development of guidelines to improve the use of administratively scoped multicast addresses. - Develop mechanisms and procedures for creating and maintaining a MBONE topology database. This working group will initially interact closely with IDMR. It is believed that, once hierarchical multicast routing systems are specified and deployed, the working groups will diverge somewhat. Finally, note that in the below 'Goals & Milestones', the type of RFC will be subject to discussions within the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 96 Aug 97 Multicast pruning a necessity Nov 96 Jun 97 Administratively Scoped IP Multicast Jan 97 Oct 97 Introduction to IP Multicast Routing Feb 97 Jun 97 Some Issues for an Inter-domain Multicast Routing Protocol Feb 97 New Guidelines for Rate Limits on the MBONE Feb 97 New PIM Multicast Border Router (PMBR) specification for connecting PIM-SM domains to a DVMRP Backbone Mar 97 New Multicast Debugging Handbook MIME Encapsulation of Aggregate HTML Documents (mhtml) ------------------------------------------------------ Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Einar Stefferud Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:mhtml@segate.sunet.se To Subscribe: listserv@segate.sunet.se In Body: subscribe mhtml Archive: ftp://segate.sunet.se/lists/mhtml/ Description of Working Group: World Wide Web documents are most often written using Hyper Text Markup Language (HTML). HTML is notable in that it contains "embedded content"; that is, HTML documents often contain pointers or links to other objects (images, external references) which are to be presented to the recipient. Currently, these compound structured Web documents are transported almost exclusively via the interactive HTTP protocol. The MHTML working group has developed three Proposed Standards (RFCs 2110, 2111 and 2112) which permit the transport of such compound structured Web documents via Internet mail in MIME multipart/related body parts. The Proposed Standards are intended to support interoperability between separate HTTP-based systems and Internet mail systems, as well as being suitable for combined mail/HTTP browser systems. It is beyond the scope of this working group to come up with standards for document formats other than HTML Web documents. However, the Proposed Standards so far produced by the working group have been designed to allow other such formats to use similar strategies. The MHTML WG is currently INACTIVE while first implementations are under way. To support implementation efforts, the WG Editor maintains an Informational Internet-Draft ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-06.txt which provides additional useful information for implementors. This Informational Draft also discusses Web page formatting choices that affect their efficient use through disconnected channels such as mail. It will become an Informational RFC after implementation experience has been collected. Until then, this informational draft will be kept current and available in the IETF Internet-Drafts library. The MHTML Mailing List remains open for discussion of any issues that may arise during implementation, and to collect information about successful interoperable and interworkable implementations in anticipation of progression to Draft-Standard Status. From May to October, 1997, the working group will Monitor Implementation progress and discuss issues, periodically Update Draft of Informational Document. The editors of this group are: Main editor: Jacob Palme Associate editor: Alex Hopmann Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 96 Jul 97 Sending HTML in E-mail, an informational supplement to RFC ???: MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML) Jul 97 Oct 97 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) Jul 97 New Content-ID and Message-ID Uniform Resource Locators Sep 97 New The MIME Multipart/Related Content-type MIME - X.400 Gateway (mixer) ---------------------------- Charter Last Modified: 26-Apr-96 Current Status: Active Working Group Chair(s): Urs Eppenberger Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:ietf-mixer@innosoft.com To Subscribe: mailserv@innosoft.com In Body: subscribe ietf-mixer Archive: ftp://ftp.innosoft.com/ietf-mixer/ Description of Working Group: RFC 1327 describes mappings to enable interworking between e-mail systems using RFC 822 and e-mail systems using CCITT X.400(88). RFC 1327 is a Proposed Standard and up for review. A specially formed review team has proposed to integrate RFC 1494, RFC 1495, outcome of the NOTARY group (support for delivery notifications in SMTP) and align it with X.400(92). The name of the specification is MIXER which stands for Mime Internet X.400 Enhanced Relay. The working group will review the MIXER draft, refine it as needed and move the document to Proposed Standard. The goal is to concentrate the work in a single document. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 95 Mar 97 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME Jul 95 Apr 97 Mapping between X.400 and RFC-822/MIME Message Bodies Nov 95 Sep 96 X.400 image body parts Nov 95 Feb 97 A MIME body part for FAX Nov 95 Feb 97 A MIME body part for ODA Jan 96 Feb 97 Carrying PostScript in X.400 and MIME Jan 97 New MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail Jan 97 Jul 97 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) Feb 97 Jul 97 Use of an X.500/LDAP directory to support MIXER address mapping Aug 97 New Representing Tables and Subtrees in the X.500 Directory Aug 97 New Representing the O/R Address hierarchy in the X.500 Directory Information Tree Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Last Modified: 03-Sep-97 Current Status: Active Working Group Chair(s): Ruth Lang Eve Schooler Mark Handley Joerg Ott Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:confctrl@isi.edu To Subscribe: confctrl-request@isi.edu Archive: ftp://ftp.isi.edu/confctrl/confctrl.mail Description of Working Group: The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is chartered to develop Internet standards track protocols to support Internet teleconferencing sessions. MMUSIC's focus is on supporting the loosely-controlled conferences that are pervasive on the MBone today. However, the WG also will ensure that its protocols are general enough to be used in managing tightly-controlled sessions. To date, MMUSIC has drafted protocols for: - distributing session descriptions -- Session Description Protocol (SDP) and Session Announcement Protocol (SAP), - providing security for session announcements -- SAP Security, - controlling on-demand delivery of real-time data -- Real-Time Stream Protocol (RTSP), - initiating sessions and inviting users -- Session Initiation Protocol (SIP), and - managing tightly-controlled sessions -- Simple Conference Control Protocol (SCCP). In addition, the WG has drafted two informational documents: the first describes the architectural framework for MMUSIC, and the second describes interoperability scenarios for ITU- and Internet-based teleconferencing systems. The WG's protocols reflect coordination with other IETF efforts related to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will collaborate with liaisons to ITU standards bodies and industry consortiums as appropriate to ensure interoperable standards (e.g., SIP/SAP/SDP with ITU H.323 and H.332). The WG has defined two sets of goals -- immediate goals to be accomplished over the next several months, and longer-term goals which will be reviewed and possibly revised after the immediate goals are met. The immediate goals include bringing several protocols to Proposed Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce Informational RFCs for the informational drafts listed above. The longer-term goals are to bring the remaining protocols to Proposed Standard status (SIP, SAP Security, SAP), to investigate the requirements for a next-generation session description protocol, and to continue the development of SCCP. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 95 Sep 97 SDP: Session Description Protocol Nov 96 Oct 97 Real Time Streaming Protocol (RTSP) Dec 96 Aug 97 SIP: Session Initiation Protocol Mar 97 Oct 97 Specification of Security in SAP Using Public Key Algorithms May 97 New SIP URL Scheme Sep 97 New The Internet Multimedia Conferencing Architecture IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): Erik Nordmark Jim Solomon Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:mobile-ip@smallworks.com To Subscribe: majordomo@smallworks.com In Body: subscribe mobile-ip Archive: ftp://ftp.smallworks.com/mobile-ip.archive Description of Working Group: The Mobile IP Working Group is chartered to develop or adopt architectures and protocols to support mobility within the Internet. In the near-term, protocols for supporting transparent host ``roaming'' among different subnetworks and different media (e.g., LANs, dial-up links, and wireless communication channels) shall be developed and entered into the Internet standards track. The work is expected to consist mainly of new and/or revised protocols at the (inter)network layer, but may also include proposed modifications to higher-layer protocols (e.g., transport or directory). However, it shall be a requirement that the proposed solutions allow mobile hosts to interoperate with existing Internet systems. In the longer term, the group may address, to the extent not covered by the mobile host solutions, other types of internet mobility, such as mobile subnets (e.g., a local network within a vehicle), or mobile clusters of subnets (e.g., a collection of hosts, routers, and subnets within a large vehicle, like a ship or spacecraft, or a collection of wireless, mobile routers that provide a dynamically changing internet topology). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 94 Aug 97 Route Optimization in Mobile IP Jan 96 Aug 97 Mobility Support in IPv6 Jan 97 New Firewall Traversal for Mobile IP: Goals and Requirements Jan 97 Aug 97 Reverse Tunneling for Mobile IP Mar 97 New Firewall Traversal for Mobile IP: Guidelines for Firewalls and Mobile IP entities Multicast Extensions to OSPF (mospf) ------------------------------------ Charter Last Modified: 11-Jan-96 Current Status: Active Working Group Chair(s): John Moy Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:mospf@gated.cornell.edu To Subscribe: mospf-request@gated.cornell.edu Archive: Description of Working Group: This working group will extend the OSPF routing protocol so that it will be able to efficiently route IP multicast packets. This will produce a new (multicast) version of the OSPF protocol, which will be as compatible as possible with the present version (packet formats and most of the algorithms will hopefully remain unaltered). Internet-Drafts: No Current Internet-Drafts. Multiprotocol Label Switching (mpls) ------------------------------------ Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): George Swallow Vijay Srinivasan Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:mpls@external.cisco.com To Subscribe: mpls-request@cisco.com In Body: in body: subscribe (unsubscribe) Archive: ftp://ftpeng.cisco.com/mpls/mpls Description of Working Group: Problem Statement: Recently the use of label-swapping based forwarding ("label switching") in conjunction with network layer routing has attracted much attention. Several vendors have proposed techniques based on this paradigm. Among the problems this paradigm is expected to address are the following: 1. Scalability of network layer routing Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies. 2. Greater flexibility in delivering routing services Using labels to identify particular traffic which are to receive special services, e.g. QoS. Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding. 3. Increased performance Using the label-swapping paradigm to optimize network performance. 4. Simplify integration of routers with cell switching based technologies a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain), b) by making information about physical topology available to Network Layer routing procedures, and c) by employing common addressing, routing, and management procedures. High Level Requirements 1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered. 2. The solution must be compatible with existing internetwork technologies and routing protocols. 3. The solution should be capable of operating independently of the underlying routing protocol. It has been observed that considerable optimizations can be achieved in some cases by small enhancements of existing protocols. Such enhancements will be considered in the case of IETF standard routing protocols, and if appropriate, coordinated with the relevant working group. 4. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations. 5. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks. 6. Routing protocols that could be used in conjuction with MPLS could be based on distributed computation. As such, during routing transients these protocols may construct forwarding paths that contain loops. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops. 7. The standard must clearly state how the protocol operates in a hierarchical network. 8. Scalability issues will be considered and analyzed. Very scalable solutions will be sought. For example, in the case of ATM technologies, the solution will attempt to conserve VC usage. Charter Statement: Currently, none of the solutions that that employ label-swapping based forwarding ("label switching") in conjunction with network layer routing are based on standard technology. In order to be able to achieve the benefits of this new technology, a standard solution is necessary. The working group is responsible for standardizing a base technology for using label swapping forwarding paradigm (label switching) in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,... This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, use of labels to support higher layer resource reservation and QoS mechanisms, and definition of host behaviors. Objectives: 1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing with forwarding based on label-swapping. 2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing with forwarding based on label-swapping. 3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing) with forwarding based on label-swapping. 4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths different from the one constructed by destination-based forwarding with forwarding based on label-swapping. 5. Specify standard procedures of carrying label information over various link level technologies. 6. Specify a standard way to use the ATM user plane a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.) ATM control plane and/or standard ATM hardware b) Specify a 'label swapping' control plane c) Take advantage of possible mods/improvements in ATM hardware, for example the ability to merge VCs 7. Discuss support for QOS (e.g. RSVP). 8. Define standard protocol(s) to allow direct host (e.g. server) participation. Coordination: The working group will coordinate its activities with other working groups as appropriate. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 97 Aug 97 A Framework for Multiprotocol Label Switching Aug 97 New A Proposed Architecture for MPLS Next Generation Transition (ngtrans) ------------------------------------ Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Bob Fink Robert Gilligan Tony Hain Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: Michael O'Dell Mailing Lists: General Discussion:ngtrans@sunroof.eng.sun.com To Subscribe: majordomo@sunroof.eng.sun.com In Body: include Archive: ftp://playground.sun.com/pub/ngtrans Description of Working Group: The purpose of this group is to design the mechanisms and procedures to support the transition of the Internet from IPv4 to IPv6. The work of the group will fall into three areas: 1. Define the processes by which the Internet will be transitioned from IPv4 to IPv6. As part of this effort, the group will produce a document explaining to the general Internet community what mechanisms will be employed in the transition, how the transition will work, the assumptions about infrastructure deployment inherent in the operation of these mechanisms, and the types of functionality that applications developers will be able to assume as the protocol mix changes over time. 2. Define and specify the mandatory and optional mechanisms that vendors are to implement in hosts, routers, and other components of the Internet in order for the transition to be carried out. Dual protocol stack, encapsulation and header translation mechanisms must all be defined, as well as the interaction between hosts using different combinations of these mechanisms. The specifications produced will be used by people implementing these IPv6 systems. 3. Articulate a concrete operational plan for transitioning the Internet from IPv4 to IPv6. The result of this work will be a transition plan for the Internet that network operators and Internet subscribers can execute. The group will use the Simple SIPP Transition (SST) overview document, draft-ietf-sipp-sst-overview-00.txt, as the starting point for its work on the IPv6 transition. The group will work closely with the main IPng Working Group (IPNGWG) and the IPng Address Configuration Working Group (ADDRCONF). The group will co-ordinate with the TACIT group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Jun 97 A proposal for an IPv6 site database object Jul 97 New Site prefixes in Neighbor Discovery New Internet Routing and Addressing Architecture (nimrod) --------------------------------------------------------- Charter Last Modified: 23-Aug-95 Current Status: Active Working Group Chair(s): J. Noel Chiappa Isidro Castineyra David Bridgham Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:nimrod-wg@bbn.com To Subscribe: nimrod-wg-request@bbn.com Archive: ftp://bbn.com/pub/nimrod-wg/nimrod-wg.archive Description of Working Group: The goal of the working group is to design, specify, implement and test a flexible new routing and addressing architecture suitable for very large scale internets. The basic architecture for computation of routes will be based on distribution of network topology maps, with source-specified route selection, and unitary (i.e., not hop-by-hop) computation of routes. The architecture will provide a single homogeneous framework for all routing, including both inter-domain and intra-domain. It will include a new network component naming abstraction hierarchy, starting from network attachment points, and based on actual connectivity, but taking into consideration policy requirements. These new names will be variable length, with a variable number of levels of abstraction; they will not appear in most packets, though. Actual packet forwarding will be based both on retained non-critical state in the switches (via flow setup for long-lived communications), and both classical address-only, as well as source-route type instructions, in individual packets (for datagram applications which send only one, or a very few, packets). Although the general design and algorithms will be usable in any internetworking protocol family, the initial detailed protocol specifications and implementation are currently planned for deployment with IPv4, but support for another packet format may be substituted or added, depending on the situation in the Internet in the future. Interoperabilty with existing unmodified IPv4 hosts will be achieved by re-interpreting the existing source and destination fields in IPv4 packets as endpoint identifiers. A substantial effort to take into account support for mobility, multicast and resource allocation will be made when designing the Nimrod architecture; provided that so doing is neither impossible because of incomplete work outside the scope of Nimrod, nor the cause of very substantial delays in the first iteration of the protocol design. Internet-Drafts: No Current Internet-Drafts. NNTP Extensions (nntpext) ------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Ned Freed Stan Barber Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:ietf-nntp@academ.com To Subscribe: ietf-nntp-request@academ.com Archive: http://www.academ.com/academ/nntp/ietf Description of Working Group: Network News Transfer Protocol (NNTP), defined in RFC 977, was released to the world in March 1986. It was designed to do two things for the "netnews" computer conferencing system: 1. Provide access to the netnews article database on a network server for "reader" client programs. The situation everyone wanted was access to netnews throughout a network, without having to actually run the netnews server software and keep a local copy of the article database (a sizeable resource commitment, even then). 2. Provide the means for interactive server to server article transfer over the Internet. The netnews system uses a "flood broadcast" mechanism to distribute articles to all sites, which as a consequence of its operation, creates many duplicate copies of any given article. These duplicates account for the netnews system's high reliability and speed in distributing articles, but they must be each eliminated at the receiving site, to avoid infinite replication. Originally, netnews was developed by the UUCP Network community, and used "batched" file transfer over modems and telephone lines to transmit articles from site to site. This mechanism did not allow for interrogating the remote system's database to see if the articles to betransmitted were already at the destination (a common case). NNTP's principal server to server article transfer mechanism allows for this interrogation of the receiver, and thus saves both network bandwidth and processing time on the remote. Unfortunately, NNTP's original design had limitations which have become apparent over the decade since its release. For example, NNTP's server to server article transfer performance over the wide area Internet suffers because there are at least two protocol round-trips per article transfer, which does not allow two NNTP servers to continuously stream the articles that must be transferred between them, and thereby make full use of the available bandwidth (moderated by TCP's congestion control mechanisms). Also, a number of extensions to the protocol are now in common use (and yet more have been proposed), but most such extensions are only documented in the source code that implements them, or in associated release notes - not in the NNTP standard. Such extensions would benefit from IETF community review, and proper specification. Where there is widespread interest in a particular kind of extension, the internet user community would benefit from consensus among implementors prior to deployment, as to the particulars of that extension. The IETF NNTP extensions Working Group shall: 1. Revise and publish a standards-track successor to RFC 977 that removes ambiguities from the original document, defines a mechanism for adding extensions to the protocol, and provides a mechanism for the server to inform the client of the extensions which it supports. 2. Include in the same document some reasonable group of existing commonly used extensions forming a new base functionality for NNTP. 3. Upon completion of the RFC977 successor document, and presuming that proposals for extensions to the NNTP protocol have been submitted for consideration by IESG, the working group may be asked by the IESG Applications Area Directors to review one or more extensions for NNTP. Part of the purpose of such a review will be to test the newly established mechanism for adding protocol extensions. The first concern of this working group shall be for the interoperability of the various NNTP implementations, and therefore for clear and explicit specification of the protocol. It is very important that we document the existing situation before taking up any new work. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 97 Sep 97 Network News Transport Protocol Oct 97 New Common NNTP Extensions ONC Remote Procedure Call (oncrpc) ---------------------------------- Charter Last Modified: 13-May-97 Current Status: Active Working Group Chair(s): Theodore Ts'o Steve Nahm Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:oncrpc-wg@sunroof.eng.sun.com To Subscribe: oncrpc-wg-request@sunroof.eng.sun.com Archive: ftp://playground.sun.com/pub/oncrpc Description of Working Group: The Open Network Computing Remote Procedure Call Working Group was originally formed to update the RFCs that describe ONC RPC to reflect the current state of the deployed and accepted technology, and submit them for Internet standardization. RFCs have been submitted for the three core ONC technologies: RPC (RFC1831), RPC Binding (RFC 1833) and XDR (RFC1832). During this work, IESG identified the area of security as requiring improvement prior to standardizing the core RPC technologies (RPC and RPC Binding). Therefore, the Working Group shall develop and define a security mechanism for ONC RPC which shall, at the minimum, allow for strong authentication of client and server principals. The core RPC technologies will be unblocked from the standards track once such a mechanism is approved as a Proposed Standard, provided that its design does not require changes to the core RPC technologies. The basis for the work will be the RPCSEC_GSS Protocol Specification, draft-ietf-oncrpc-rpcsec_gss.00.txt. The document editor will be Michael Eisler. Background: ONC RPC is a Remote Procedure Call technology that originated in Sun Microsystems in the early 1980s. ONC RPC was modelled on Xerox's Courier RPC protocols. It has been widely deployed on platforms from most major workstation vendors. It has been implemented on MS-DOS, Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and practically all flavors of UNIX, among others. Sun Microsystems has delegated change control for the ONC RPC protocols for the purposes of making an Internet Standard to the IETF (see RFC 1790). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 94 Oct 97 Authentication Mechanisms for ONC RPC Jun 96 Apr 97 RPC: Remote Procedure Call Protocol Specification Version 2 An Open Specification for Pretty Good Privacy (openpgp) ------------------------------------------------------- Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): John Noerenberg Charles Breed Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ietf-open-pgp@imc.org To Subscribe: ietf-open-pgp-request@imc.org In Body: Only the word subscribe Archive: http://www.imc.org/ietf-open-pgp/mail-archive/ Description of Working Group: PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application. The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols. Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users. Security Issues: The whole purpose of Open-PGP is to provide security services. Internet-Drafts: No Current Internet-Drafts. Open Shortest Path First IGP (ospf) ----------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): John Moy Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:ospf@gated.cornell.edu To Subscribe: ospf-request@gated.cornell.edu Archive: ftp://gated.cornell.edu/pub/lists/ospf Description of Working Group: The OSPF Working Group will develop and field-test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 95 Mar 97 OSPF for IPv6 Dec 95 May 97 The OSPF Opaque LSA Option Nov 96 May 97 OSPF Standardization Report Mar 97 Jun 97 The OSPF NSSA Option Aug 97 New The OSPF Address Resolution Advertisement Option Oct 97 New OSPFv2 Domain Of Interpretation (DOI) for ISAKMP Oct 97 New SPF over ATM and Proxy PAR One Time Password Authentication (otp) -------------------------------------- Charter Last Modified: 08-Jun-95 Current Status: Active Working Group Chair(s): Neil Haller Ran Atkinson Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ietf-otp@bellcore.com To Subscribe: ietf-otp-request@bellcore.com Archive: ftp://ftp.bellcore.com/pub/ietf-otp/archive Description of Working Group: One form of attack on computing systems connected to the Internet is eavesdropping on network connections to obtain login id's and passwords of legitimate users [RFC 1704]. Bellcore's S/KEY(TM) one-time password system was designed to counter this type of attack, called a replay attack [RFC 1760]. Several one-time password implementations compatible with Bellcore's S/KEY (TM) system exist. These implementations are increasingly widely deployed in the Internet to protect against passive attacks. The object of this working group is to write a standards track RFC for one-time password technology, using the technology in the Bellcore S/KEY system and related interoperable packages (e.g., logdaemon, NRL OPIE) as the basis for the group's effort. The standards-track RFC will enhance multi-vendor interoperability in one-time password authentication technologies and thereby help reduce security risks in the Internet. General authentication servers are outside the scope of this working group. The ``S/Key-0'' system being considered for use in Kerberos is outside the scope of this working group. The standards-track specification will describe how this one-time password technology can be used with at least the MD4, MD5, and SHA algorithms. The standard one-time password dictionary from RFC 1760 will be reused in order to maintain backwards compatibility with the various deployed systems, however, support for hexadecimal format passwords will also be mandatory to implement. The standard might specify passphrase quality checks for the secret passphrase. The standard will be specified so as to eliminate any possible conflict with the Bellcore trademark on the term ``S/Key.'' An Informational RFC might also be issued that describes conventions for the UNIX commands relating to one-time passwords, including command(s) to securely update a remote one-time password. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 96 Sep 97 OTP Extended Responses Nov 96 Jan 97 OTP Verification Examples Jan 97 Sep 97 A One-Time Password System Procedures for Internet/Enterprise Renumbering (pier) ----------------------------------------------------- Charter Last Modified: 03-Jan-96 Current Status: Active Working Group Chair(s): Roger Fajman Bill Manning Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:pier@isi.edu To Subscribe: pier-request@isi.edu Archive: ftp://ftp.isi.edu/pier-archive Description of Working Group: PIER will fill the niche between the ADDRCONF, CIDRD, DHCP, SERV-LOC, and other working groups as needed in identifying processes and procedures, tools and techniques for renumbering in both the IPv4 and IPv6 environments. Since IPv6 is still in development, the main focus will be IPv4 environments. Emphasis will be placed on identifying the places where hardcoded IP addresses are used and documenting those places. If there are viable alternatives to hardcoded IP addresses, the working group will document those as well. The end results of these investigations will be a series of documents on renumbering issues and recommendations on what actions might be taken to address those issues where there is no currently viable alternative. These recommendations will be to other working groups and/or areas regarding possible improvements to protocols that would aid in renumbering. The PIER working group will not develop such protocols itself. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 New IP Addresses in Applications PSTN and Internet Internetworking (pint) ---------------------------------------- Charter Last Modified: 28-Aug-97 Current Status: Active Working Group Chair(s): Steve Bellovin Igor Faynberg Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:pint@lists.research.bell-labs.com To Subscribe: pint-request@lists.research.bell-labs.com In Body: subscribe your-email-addres Archive: http://www.bell-labs.com/mailing-lists/pint/ Description of Working Group: The PSTN/Internet Interfaces (PINT) WG addresses connection arrangements through which Internet applications can request and enrich PSTN (Public Switched Telephone Network) telephony services. An example of such services is a Web-based Yellow Pages service with the ability to initiate PSTN calls between customers and suppliers. This working group has six main objectives: * Study architecture and protocols needed to support services in which a user of the Internet requests initiation of a telephone (i.e., PSTN- carried) call to a PSTN terminal (i.e., telephone, FAX machine). The protocols are not to support any form of third-party call control or, for that matter, any type of call control; their role is rather to securely carry call requests to the PSTN. Specific services to be considered initially are Click-to-Dial, Click-to-Fax, Click-to-Fax-Back, and Web access to voice content delivered over the PSTN. * Produce an informational RFC that describes current practices for supporting the services in question. * Based on the existing practice and agreed on improvements, develop a standards track RFC that specifies a Service Support Transfer Protocol (SSTP) between Internet applications or servers and PSTN Intelligent Network Service Nodes (or any other node that implement the Service Control Function). SSTP is an application-specific transport protocol operating over TCP. * Consider security issues relating to prividing functions of this type. In particular understand any threats posed by this technology and resolve them, and any other security issues in the proposed standard. * Based on the existing practice and agreed on improvements, develop a standards track RFC for a relevant MIB (SSTP MIB) to support the service management protocol between Internet applications and the PSTN Service Management System. The SSTP MIB is to conform to SNMP standards. * Consider extensions of the above architecture and protocols to support a wider range of PSTN Intelligent Network (IN) based services. Internet-Drafts: No Current Internet-Drafts. Public-Key Infrastructure (X.509) (pkix) ---------------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Stephen Kent Warwick Ford Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ietf-pkix@tandem.com To Subscribe: listserv@tandem.com In Body: subscribe ietf-pkix Archive: ftp://ftp.tandem.com/ietf/mailing-lists/current Description of Working Group: Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems. The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM). Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL). The task of the working group will be to develop Internet standards needed to support an X.509-based PKI. The goal of this PKI will be to facilitate the use of X.509 certificates in multiple applications which make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model). Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications. Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project. The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include: o Alternatives for CA-to-CA certification links and structures, including guidelines for constraints o Revocation alternatives, including profiling of X.509 v2 CRL extensions o Certificate and CRL distribution options (X.500-based, non-X.500-based) o Guidelines for policy definition and registration o Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and key-pair updating o Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.) o Generation of client key pairs by the PKI Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 96 Oct 97 Internet Public Key Infrastructure X.509 Certificate and CRL Profile Jun 96 Oct 97 Internet Public Key Infrastructure Certificate Management Protocols Mar 97 Oct 97 Internet Public Key Infrastructure Operational Protocols - LDAPv2 Mar 97 Oct 97 Internet Public Key Infrastructure Certificate Policy and Certification Practices Framework Jul 97 New Internet Public Key Infrastructure Jul 97 New Internet Public Key Infrastructure Part V: Time Stamp Protocols Aug 97 Oct 97 Internet Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet Public Key Infrastructure Certificates Sep 97 Oct 97 Internet Public Key Infrastructure Operational Protocols: FTP and HTTP Oct 97 New Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP PacketWay (pktway) ------------------ Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Danny Cohen Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:pktway@isi.edu To Subscribe: http://WWW.ERC.MsState.Edu/packetway/mail-list.html In Body: use above URL to subscribe/unsubscribe Archive: ftp://ftp.isi.edu/pktway/pktway.mail Description of Working Group: Due to dramatic increases in circuits speed the traditional system buses are limited in length (e.g., PCI is limited to 8") and cannot provide the traditional system-wide support. Therefore, the system-wide connectivity is provided by a high performance networks operating in very close quarters, having the generic name System Area Networks (SANs). Many vendors today use such SANs inside computer platforms to connect processors to IO devices, processors to memory, and processors to processors. Most existing SANs are proprietary, and don't interoperate with each other, not unsimilar to the early stages of LAN development. In order to be able to interconnect Massively Parallel Processing systems (MPPs) and to interconnect workstations into MPP-like clusters there is a need to unify the SANs and to provide means for interoperability among them. PktWay is designed to provide a uniform interface for a wide variety of SANs, such that the higher levels (such as IP) would be able to use SANs in a uniform manner. An IP driver for PktWay would be able to use PktWay between heterogeneous processors as if they were all on a single SAN. PktWay would be designed to provide interoperability among closely located heterogeneous processors at high speed. Pktway will sacrifice scalability and some generality for high performance. Hence, PktWay will supplement IP for high performance and for fine granularity of processors. 802.1, the link level control protocol is above LANs, such as the various Ethernets, FDDI, and Token Ring, at Level-2, and below IP, at Level-3. Similarly, PktWay will be above the various SANs (such as RACEway and Paragon) and below IP. PktWay will define separately: * End-to-End protocol (and packet format) * Router-to-Router protocol (and packet format) * Resource discovery and allocation The members of the PktWay Working Group will design, specify, document, propose, implement, and evaluate the above three protocols that define the PktWay operation. The members of the working group will also produce reference software for PktWay. Based on initial reactions it is expected that the working group will include members from academia, government, and industry, covering the software, hardware, and communication aspects of PktWay. INTELLECTUAL PROPERTY All the work that has been performed until now on PktWay is in the public domain. The PktWay Working Group will only handle public domain information. All the members of the PktWay Working Group will be notified that the working group cannot guard any trade secrets, nor limit the distribution of any proprietary information presented to it. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 95 Oct 97 The End-to-End (EEP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters Oct 97 New Part-1 of The Router-to-Router (RRP) PacketWay Protocol for High-Performance Interconnection of Computer Clusters Process for Organization of Internet StandardS ONg (poisson) ------------------------------------------------------------ Charter Last Modified: 24-Jul-97 Current Status: Active Working Group Chair(s): Erik Huizer General Area Director(s): Fred Baker General Area Advisor: Fred Baker Mailing Lists: General Discussion:poised@tis.com To Subscribe: poised-request@tis.com Archive: ftp://ftp.tis.com/pub/lists/poised/poised.yymm Description of Working Group: The POISED working group in 1993-1994 established the basis of the IETF process in its current form. Poised95 established a base set of documents to describe the essentials of the IETF process. POISSON will concern itself with extending the set of RFC documents that describe the IETF process. The name POISSON: The tricky part of describing the IETF process, certainly in the fast changing world of the Internet, is that when you describe the process in too much detail, the IETF loses its flexibility, when you describe to little it becomes unmanageable. This is therefore a slippery subject, hence the name POISSON, which is French for fish. The French word also serves to indicate the international aspect of the WG. Furthermore the IETF operates by concensus, which sometimes seems to have a POISSON distribution. The POISSON WG will work on the following items: - WG and Area procedures; This is to become a BCP document that describes the procedures that the IETF has for WG formation and operation, and for Area Directors. This is an essential formalisation and update of RFC1603. The document should additionally include issues like: - WG editor definition - WG chair (de)selection - WG ethics Proposed editors: Scott Bradner and Erik Huizer - Standards process; The standards process document as produced by Poised95 is not yet complete. The document needs to be updated with specific regard to the standards document structure categorization and publication. Proposed editor: Scott Bradner - Nomcom procedures; The Nomcom procedures document as produced by Poised95 may need updating as a result of nomcom experience early 1997. If this is the case, the POISSON WG will take it upon itself to update the document. If not the POISSON WG will not work on this. Proposed editor: Jim Galvin - Code of conduct; based on the Internet-draft: draft-odell-code-of-conduct-00.txt the POISSON WG will produce a code of conduct for the IETF. Proposed editor: Mike O'Dell Furthermore, the POISSON WG will review documents that are related to the IETF standards process (but that will not be produced by the POISSON WG itself) when available. Such documents may include: - IETF Charter; This needs to be written by the IETF chair. It is essentially a short mission statement like document that contains references to other Poised documents for further details. - IESG Charter; This document will be written by the IESG. - IAB Charter; The IAB needs to revise its charter (RFC1601). - ISOC Bylaws and Articles of Incorporation; These need to be published as RFC(s). - The IRTF charter. POISSON will meet in San Jose and Memphis to try and gauge a rough consensus on these issues and develop guidelines and drafts for the appropriate documents. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Sep 97 IETF Working Group Guidelines and Procedures Jul 97 Aug 97 IAB and IESG Selection, Confirmation, and Recall Process: Operation of the Nominating and Recall Committees Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Karl Fox Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:ietf-ppp@merit.edu To Subscribe: ietf-ppp-request@merit.edu Archive: ftp://merit.edu/pub/ietf-ppp-archive Description of Working Group: The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The working group is defining the use of other network layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition, it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 New PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol Feb 95 Mar 97 The PPP Internet Protocol Control Protocol (IPCP) Mar 95 Jul 96 PPP Extensible Authentication Protocol (EAP) Nov 95 Feb 97 PPP EAP RSA Public Key Authentication Protocol Feb 96 Jul 97 PPP LCP Extensions Jun 96 Jul 97 Point-to-Point Tunneling Protocol--PPTP Sep 96 Oct 97 Layer Two Tunneling Protocol 'L2TP' Feb 97 Jul 97 Mobile-IPv4 Configuration Option for PPP IPCP Mar 97 New Semi Connected Mode for PPP links Mar 97 New Proposal for a PPP Network Layer Entity Selection Protocol Mar 97 Sep 97 PPP over AAL5 Mar 97 New Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI Mar 97 Jul 97 PPP LCP CallBack Jun 97 Oct 97 Layer Two Tunneling Protocol 'L2TP' Security Extensions for Non-IP networks Jul 97 New The PPP DES Encryption Protocol, Version 2 (DESE-bis) Jul 97 New The PPP Triple-DES Encryption Protocol (3DESE) Jul 97 Sep 97 PPP Over FUNI Jul 97 New PPP LCP Self Describing Padding Oct 97 New Layer Two Tunneling Protocol 'L2TP' Management Information Base Oct 97 Oct 97 PPP EAP TLS Authentication Protocol Oct 97 New PPP over SONET/SDH Printer MIB (printmib) ---------------------- Charter Last Modified: 21-Jul-97 Current Status: Active Working Group Chair(s): Chris Wellens Llyod Young Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:pmp@pwg.org To Subscribe: majordomo@pwg.org In Body: In body: subscribe pmp Archive: http://www.pwg.org/hypermail/pmp/ Description of Working Group: The Printer MIB Working Group is chartered to develop a set of managed objects for networked printers. These objects will be the minimum necessary to provide the ability to monitor and control these systems, providing fault, configuration and performance management, and will be consistent with the SNMP framework and existing SNMP standards. At its discretion, the working group may also define a small number of unsolicited notifications (traps) which carry these managed objects. However, the working group recognizes that traps are used sparingly in the SNMP framework. The working group recognizes that the area of networked printers is quite diverse. However, the working group is specifically confined to defining managed objects that instrument critical information about: - printer engine - interpreters - media - input sources - output destinations - I/O interfaces Further, the working group is specifically prohibited from defining managed objects that define instrumentation about: - other marking technologies (e.g., those that mark onto film) - fonts - spooling - print job management Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Oct 97 Printer MIB Apr 97 Sep 97 Job Monitoring MIB - V0.85 Physical Topology MIB (ptopomib) -------------------------------- Charter Last Modified: 11-Feb-97 Current Status: Active Working Group Chair(s): Ken Jones Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:ptopo@3com.com To Subscribe: ptopo-request@3com.com Archive: ftp ftp.3com.com (login: ptopo, passwd: ptopo) Description of Working Group: Document Editor: Gilbert Ho (Gilbert_Ho@3mail.3com.com) The goals of this working group are: o to agree on and document the common framework/model for discussing physical topology o to standardize a set of managed objects that provide physical topology information o to document media specific mechanisms to communicate topology information. The managed objects should provide sufficient information to allow a management workstation to navigate across a set of agents in order to learn the topology of arbitrarily large networks, and these objects should be as independent as possible from the specific underlying networking media which comprise the network. These objects will be the minimum necessary to provide the ability to support the physical topology discovery, and will be consistent with the SNMP framework and existing SNMP standards. In defining these objects, it is anticipated that the working group will leverage existing work for representing port-based information, such as in the Repeater MIB (RFC 1516 or later) and may also leverage work in the entity MIB for describing logical and physical relationships. The working group will define the general requirements for topology mechanisms in order to support the proposed MIB. It will also identify existing topology mechanisms for common LAN media types and may propose new topology mechanisms for LAN media types where required. It is a goal of the common topology MIB to allow the use of either standard or proprietary topology mechanisms within the underlying media. At this time, it is not a goal of the working group to support the collection or representation of logical topology information, such as VLAN configuration or subnet structure. It is anticipated that this could be an area for future work items, so some consideration will be given to extensibility of the models and to the MIB. However, this consideration must not be allowed to impede progress on the primary focus of physical connectivity. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 97 Sep 97 Physical Topology MIB Aug 97 Sep 97 Physical Topology Discovery Protocol and MIB QoS Routing (qosr) ------------------ Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Hal Sandick Eric Crawley Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:qosr@newbridge.com To Subscribe: qosr-request@newbridge.com Archive: Description of Working Group: This working group is chartered to define a framework and techniques for Quality of Service (QoS) Routing in the Internet. QoS Routing allows the network to determine a path that supports the QoS needs of one or more flows in the network. The path chosen may not be the "traditional shortest path" that is typically computed based on current metrics and policies. The group's work will focus on how to select and maintain packet forwarding paths capable of meeting specific service class objectives. In particular, the techniques will specify what extensions and adaptations to routing and QoS setup protocols are required to support QoS routing and new packet handling techniques that may be needed to avoid packet loops for QoS flows. While it is not intended, this may also spawn the development of new routing protocols that can specifically address QoS routing. The WG will identify topics and issues in QOS routing which require additional research. The WG needs to work closely with other routing protocol working groups such as OSPF, IDR, BGP, and IDMR. A close relationship with the RSVP,IntServ, and ISSLL working groups is also needed to understand the QoS signalling and specification. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Jul 97 A Framework for QoS-based Routing in the Internet Remote Authentication Dial-In User Service (radius) --------------------------------------------------- Charter Last Modified: 03-Jan-96 Current Status: Active Working Group Chair(s): Carl Rigney Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:ietf-radius@livingston.com To Subscribe: ietf-radius-request@livingston.com In Body: subscribe ietf-radius Archive: ftp://ftp.livingston.com/pub/radius/archive Description of Working Group: Background: The original specification for and implementation of RADIUS was written by Steve Willens of Livingston Enterprises in response to a need outlined by the earlier NASREQ working group, and has been deployed by multiple vendors over the past 3 years. No other working group appears to be addressing the topic of communicating authentication and authorization information between a Network Access Server and a central authentication & authorization server, and general consensus is that standardization of such a protocol would be extremely useful. This working group will produce four documents: 1) By early '96, an informational RFC documenting the RADIUS protocol already deployed for use by a Network Access Server (NAS) to communicate with a remote Authentication & Authorization database server, with minor amendments reflecting field experience of several implementations over several years at hundreds of sites. 2) By February '96, an informational RFC describing RADIUS Accounting. 3) By early '97, a full standard RFC documenting the RADIUS protocol, addressing any operational or security issues raised concerning the informational RFC. This document will obsolete goal 1. (If the Internet-Draft for goal 1 is deemed suitable by the IESG for release as a Proposed Standard instead of informational, then goals 1 and 3 will be merged.) 4) Starting in February '96 and concluding in '97, a RADIUS Extensions RFC documenting extensions for additional functionality within the RADIUS framework, which will be interoperable with the base RADIUS defined in the document for goal 3. The intent in goals 1 through 3 are to document the protocol as it exists and is used currently, in such a way as to allow interoperable implementations to be written from the RFC. Minor modifications to enhance interoperability or operation based on field experience are suitable, major overhauls are outside the scope of this working group's charter. Goal 4 is to provide a mechanism for additional features deemed widely useful to be added to the existing framework, for example to provide better support for EAP. Clearly outside the scope of the charter are the following: 1) NAS Standardization is outside the scope. We're defining standard RADIUS, not a standard encompassing everything about network access servers. This effort does not require NASes to implement RADIUS; it just defines how the RADIUS Protocol works on NASes that do implement RADIUS. 2) RADIUS is not intended as a NAS management protocol; SNMP already exists for that. 3) Management of the Authentication/Authorization database itself is outside the scope. 4) Alternative transport protocols such as IPX or IPv6 appear straightforward, but will not be addressed in this effort. 5) The flexibility and generality of RADIUS have led to its use for other applications, but this Working Group is addressing only those uses involving user dial-in to Network Access Servers. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Jul 97 Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS Nov 96 Aug 97 RADIUS Attributes for Tunnel Protocol Support Jan 97 May 97 Extensible Authentication Protocol Support in RADIUS Jan 97 New RADIUS Extensions Jul 97 New RADIUS Accounting Interim Accounting Record Extension Aug 97 New RADIUS Accounting Client MIB Aug 97 New RADIUS Accounting Server MIB Aug 97 New RADIUS Authentication Client MIB Aug 97 New RADIUS Authentication Server MIB Oct 97 New RADIUS Attributes for MS-CHAP Support Receipt Notifications for Internet Mail (receipt) ------------------------------------------------- Charter Last Modified: 26-Apr-96 Current Status: Active Working Group Chair(s): Ned Freed Urs Eppenberger Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:receipt@cs.utk.edu To Subscribe: receipt-request@cs.utk.edu Archive: ftp://cs.utk.edu/pub/receipt/mail-archive Description of Working Group: There is a wide interest of e-mail users to know if and when a message has been shown to a (human) recipient. This functionality is available for a number of PC e-mail systems and within X.400. The receipt working group will specify the necessary extensions to support this functionality within the Internet Mail environment and optionally also specify the necessary mappings for MIXER gateways. The result of this work will be a Proposed Standard specifying: o The mechanism used for requesting that the recipient issue a read-receipt. o The format used for transferring read-receipts. o The advice on the privacy and security issues involved in read-receipts. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 95 Oct 97 An Extensible Message Format for Message Disposition Notifications Routing Information Protocol (rip) ---------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): G. Malkin Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:ietf-rip@baynetworks.com To Subscribe: ietf-rip-request@baynetworks.com In Body: subscribe ietf-rip Archive: ftp://xylogics.com/pub/users/gmalkin/rip/rip-arc Description of Working Group: The RIP Working Group was formed from the RIP Version 2 Working Group, which was originally chartered to create the RIP-2 standard. Since several other RIP-related efforts are also occuring within the IETF, it was decided to create a single working group to handle them all. The RIP Working Group is chartered to guide the following proposals and develop the following projects through the IETF standards track: - ``RIP Version 2'' (RFC 1723) - ``RIP Version 2 MIB Extension'' (RFC 1724) - ``Extensions to RIP to Support Demand Circuits'' (RFC 1582) - ``RIP-II Cryptographic Authentication'' (Internet-Draft) Additionally, the RIP Working Group will handle the RIPng protocol which, in its first incarnation, will contain the minimum modifications to RIP-2 necessary to handle IPng. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 New RIP Version 2 MIB Extension Oct 97 New RIPv2 Domain Of Interpretation (DOI) for ISAKMP Remote Network Monitoring (rmonmib) ----------------------------------- Charter Last Modified: 29-Sep-97 Current Status: Active Working Group Chair(s): Andy Bierman Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Technical Advisor(s): Steven Waldbusser Mailing Lists: General Discussion:rmonmib@cisco.com To Subscribe: rmonmib-request@cisco.com Archive: ftpeng.cisco.com/ftp/rmonmib/rmonmib Description of Working Group: The RMON MIB Working Group is chartered to define a set of managed objects for remote monitoring of networks. These objects will be the minimum necessary to provide the ability to monitor multiple network layers of traffic in remote networks; providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing MIB modules that define objects which support similar management, e.g., RFC 1271 and RFC 1513 and efforts in other areas, e.g., the accounting and operational statistics activities. It is possible that this RMON will not be backwards compatible with existing RMON RFCs, but the reasons for any such incompatibility will be well documented. The following list of features for this RMON has been previously discussed in relation to existing RMON functionality and is included to focus these RMON activities. It is recognized that other issues may be considered and that certain of the following issues may not be part of the final specification: 1) Protocol-type distribution through all seven layers of the ISO model. 2) Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa. 3) Mechanisms that enable the detection of duplicate addresses or address changes. 4) The relationship of the Manager-to-Manager MIB in SNMPv2 and associated RMON alarm related activities. 5) Host Table for the Network Layer and the Transport Layer. 6) Provide a simple mechanism for the specification of event/trap destinations 7) Address the issue of the filter mechanism being constrained by bit-to-bit packet matching, which presents a problem with variable- length packets. 8) Consider how RMON could benefit network security, for example: using the RMON History to provide an accountability and audit trail up to the Transport Layer. 9) Provide performance metrics for the client-server environment. 10) Concerns of hardware implementation should be considered. For example, optimization of the filter and capture group could reduce the cost of the CPU and improve performance. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 96 Oct 97 Remote Network Monitoring MIB Extensions for Switch Networks Version 1.0 Nov 96 Oct 97 Remote Network Monitoring MIB Protocol Identifiers (Version 2) Feb 97 Sep 97 Remote Network Monitoring Management Information Base for High Capacity Networks Roaming Operations (roamops) ---------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): G. Zorn Pat Calhoun Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Technical Advisor(s): Michael O'Dell Mailing Lists: General Discussion:roamops@tdmx.rutgers.edu To Subscribe: roamops-request@tdmx.rutgers.edu In Body: include Archive: ftp://ftp-no.rutgers.edu/misc/IETF/roamops Description of Working Group: The purpose of this group is to develop or adopt procedures, mechanisms and protocols to support user roaming among groups of Internet service providers (ISPs). This is different from, but related to, the work of the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in that the roamops group is not concerned with the movement of hosts or subnets, but of users. In the near term, the goals of the group will be to produce an architectural document describing the basic mechanisms required to support user roaming. A repository for documentation describing current roaming implementations will also be maintained. In addition, the group will address interoperability among ISPs and roaming users by standardizing such items as network usage data exchange (including the content, format and protocols involved), phone book attributes and exchange/update protocols, inter-ISP authentication mechanisms and exploring in depth the security issues involved with roaming. This work is expected to consist mainly of new or revised procedures and application-layer protocols. Any and all business issues regarding the operation of an ISP roaming network (such as settlement, business and billing methods) are specifically NOT in the scope of the roamops Working Group and will not be discussed. The group will work closely with other IETF Working Groups (including mobileip, radius, nasreqng saag and cat) to identify issuesto which the roamops group should attend, as well as to assure their work does not make roaming unnecessarily difficult or impossible. The utmost goal of the group will to make sure, by any means necessary, that it produces documents of high quality that are useful to the IETF community. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 96 Jul 97 Dialup Roaming Requirements Nov 96 Sep 97 The Network Access Identifier Mar 97 Aug 97 Session Record Accounting in Roaming Mar 97 Sep 97 Guidelines for the Operation of RADIUS Proxies in Roaming Oct 97 New Secure Radius Server Operation Guidelines for Dial Roaming Routing Policy System (rps) --------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Daniel Karrenberg Cengiz Alaettinoglu Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:rps@isi.edu To Subscribe: rps-request@isi.edu Archive: ftp://ftp.isi.edu/rps Description of Working Group: The Routing Policy System Working Group will (1) define a language, referred to as Routing Policy Specification Language (RPSL), for describing routing policy constraints; (2) define a simple and robust distributed registry model for publishing routing policy constraints; and (3) define a set of tools for analysing registered policy constraints, for checking global consistency, for generating router configurations, and for diagnosing operational routing problems. It is expected that RPSL will enter the standards track. The RPSL will be routing protocol independent as well as router configuration format independent to support various routing protocols such as BGP, IDRP, SDRP, and various router technologies. The RPSL will be backward compatible with RIPE-181 whenever possible; the registry model will be based on the RIPE database. The working group will focus on inter-domain routing protocols, but will also instigate, review, or (if appropriate) produce additional RFCs to support other protocols such as multicasting and resource reservation. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Aug 97 Routing Policy Specification Language (RPSL) Mar 97 Aug 97 A strategy for the transition from RIPE-181 to RPSL Mar 97 New Application of Routing Policy Specification Language (RPSL) on the Internet Resource Reservation Setup Protocol (rsvp) ------------------------------------------ Charter Last Modified: 13-May-97 Current Status: Active Working Group Chair(s): Lixia Zhang Bob Braden Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:rsvp@isi.edu To Subscribe: rsvp-request@isi.edu Archive: ftp://ftp.isi.edu/rsvp/rsvp.mail Description of Working Group: RSVP is a resource reservation setup protocol for the Internet. Its major features include: (1) the use of ``soft state'' in the routers, (2) receiver-controlled reservation requests, (3) flexible control over sharing of reservations and forwarding of subflows, and (4) the use of IP multicast for data distribution. The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internet standards track. The working group will also serve as a meeting place and forum for those developing and experimenting with RSVP implementations. The task of the RSVP Working Group, creating a robust specification for real-world implementations of RSVP, will require liaison with two other efforts: (1) continuing research and development work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of real-time applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 95 Aug 97 RSVP Cryptographic Authentication Jun 96 Mar 97 RSVP Extensions for Policy Control Feb 97 Jun 97 RSVP Extensions for CIDR Aggregated Data Flows Mar 97 New Designing Tunnels for Interoperability with RSVP Mar 97 Aug 97 Open Outsourcing Policy Service (OOPS) for RSVP Apr 97 New Partial Service Deployment in the Integrated Services Architecture Jun 97 New RAPI -- An RSVP Application Programming Interface Jul 97 New Protocol for Exchange of PoliCy Information (PEPCI) Oct 97 New RSVP Management Information Base Realtime Traffic Flow Measurement (rtfm) ---------------------------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Gregory Ruth Nevil Brownlee Sig Handelman Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Scott Bradner Mailing Lists: General Discussion:rtfm@auckland.ac.nz To Subscribe: majordomo@auckland.ac.nz In Body: subscribe rtfm your-email-address Archive: ftp://ftp.auckland.ac.nz/pub/rtfm/archive Description of Working Group: This working group has three main objectives: * Consider current issues in traffic flow measurement, such as - Security issues relating to both traffic measuring devices and to the data they produce. - Policy issues relating to traffic measurement and usage accounting, for example any requirements these may place on emerging network protocols - Existing work in traffic flow measurement, including that of IETF Working Groups such as bmwg/ippm, rsvp and rmonmib, as well as that by vendors and independent researchers * Produce an improved Traffic Flow Model considering at least the following needs: - wider range of measurable quantities, e.g. those relating to IPv6, and to class of service - simpler ways to specify flows of interest - better ways to control access to measured flow data - strong focus on data reduction capabilities - efficient hardware implementation * Develop the RTFM Architecture and Meter MIB as 'standards track' documents with the IETF. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Jul 97 RTFM Working Group - New Attributes for Traffic Flow Measurement Mar 97 Sep 97 Traffic Flow Measurement: Meter MIB Sep 97 New Traffic Flow Measurement: Architecture Responsible Use of the Network (run) ------------------------------------ Charter Last Modified: 26-Sep-97 Current Status: Active Working Group Chair(s): G. Malkin Sally Hambridge User Services Area Director(s): Joyce K. Reynolds User Services Area Advisor: Joyce K. Reynolds Mailing Lists: General Discussion:ietf-run@mailbag.intel.com To Subscribe: listserv@mailbag.intel.com In Body: subscribe ietf-run Firstname Lastname Archive: ftp://ftp.intel.com/pub/ietf-run Description of Working Group: Reflecting the needs of the Internet community, the IETF sees a need to create an guide for Internet users about mass unsolicited email and Netnews postings. The Working Group will develop an FYI RFC on mass unsolicited email and posts, as well as an FYI RFC on responsible advertising. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Jul 97 DON'T SPEW A Set of Guidelines for Mass Unsolicited Mailings and Postings (Spam*) RWhois Operational Development (rwhois) --------------------------------------- Charter Last Modified: 23-Aug-95 Current Status: Active Working Group Chair(s): Scott Williamson Mark Kosters Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:rwhois@internic.net To Subscribe: rwhois-request@internic.net In Body: subscribe rwhois Archive: ftp://rs.internic.net/put/rwhois/rwhois-archive Description of Working Group: The RWhois Operational Development Working Group will be a forum for coordinating the deployment, engineering and operation of the RWhois protocol to replace the current centralized whois model. The minimum attribute set will be defined to ensure that all delegated registries maintain the required information. Required user authentication will be defined to allow remote registration with RWhois servers. Operational procedures will be established to ensure that all delegated servers conform to a set of minimum standards. If necessary the RWhois protocol specification will be updated to reflect changes in requirments identifed during the working group tenure. Internet-Drafts: No Current Internet-Drafts. Source Demand Routing (sdr) --------------------------- Charter Last Modified: 19-Feb-97 Current Status: Active Working Group Chair(s): Deborah Estrin Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:sdrp@catarina.usc.edu To Subscribe: sdrp-request@catarina.usc.edu Archive: ftp://catarina.usc.edu/pub/sdrp Description of Working Group: The SDR Working Group is chartered to specify and promote the use of SDRP (Source Demand Routing Protocol) as an inter-domain routing protocol capability in conjunction with IDRP and BGP inter-domain routing protocols. The purpose of SDR is to support explicit selection of inter- domain routes, to complement the implicit hop-hy-hop route selection provided by BGP/IDRP. The group is also chartered to specify and promote the use of a similar protocol for IPv6, referred to as the Explicit Routing Protocol (ERP). The goal of the SDR Working Group is to release the components of SDR as ``experimental'' IETF protocols and to obtain operational experience with SDR in the Internet. Once there is enough experience with SDR, the working group will submit the SDR components to the IESG for standardization. SDR has four components: packet formats for protocol control messages and encapsulation of user datagrams, processing and forwarding of user data and control messages, routing information distribution/collection and route computation, configuration and usage. The group's strategy is to: (1) Define the format, processing and forwarding of user datagram and control messages so that SDR can be used very early on as an efficient means of supporting ``configured'' inter-domain routes. User packets are encapsulated along with the source route and forwarded along the ``configured'' route. Routes are static at the inter-domain level, but are not static in terms of the intra-domain paths that packets will take between specified points in the SDR route. The impact of encapsulation on MTU, ICMP, performance, etc., are among the issues that must be evaluated before deployment. (2) Develop simple schemes for collecting (a) dynamic domain-level connectivity information and (b) route construction based on this information, so that those domains that want to can make use of a richer, and dynamic set of SDR routes. (3) Apply the experience with SDR design and implementation to the design and implementation of ERP. (4) Develop SDR and ERP deployment plans. (5) In parallel with (1), (2) and (3) , develop usage and configuration documents and prototypes that demonstrate the utility of static-SDR and simple-dynamic-SDR and ERP. (6) After gaining some experience with the simple schemes for distribution, develop a second generation of information distribution and route construction schemes. The group hopes to benefit from discussions with IDPR and NIMROD developers at this future stage because the issues faced are similar. The route distribution and construction mechanisms are common to both ERP and SDRP. (7) Investigate the use of SDRP and ERP alternate routing as a mechanism for supporting reservation traffic (e.g., based on RSVP). This will require that we address integration of SDRP/ERP and multicast routing (e.g., running PIM over SDRP/ERP), as well as the interface between SDRP/ERP and RSVP. Moreover, we will investigate the construction of SDRP/ERP routes that make use of some dynamic control information, in additional to the more traditional hop count. (8) The group will also investigate the addition of security options into the SDRP/ERP forwarding and packet format specifications. (9) Coordinate with the IDR and IPng Working Groups. Internet-Drafts: No Current Internet-Drafts. Secure Shell (secsh) -------------------- Charter Last Modified: 26-Feb-97 Current Status: Active Working Group Chair(s): Perry Metzger Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ietf-ssh@clinet.fi To Subscribe: majordomo@clinet.fi In Body: subscribe ietf-ssh@clinet.fi in body Archive: Description of Working Group: The goal of the working group is to update and standardize the popular SSH protocol. SSH provides support for secure remote login, secure file transfer, and secure TCP/IP and X11 forwardings. It can automatically encrypt, authenticate, and compress transmitted data. The working group will attempt to assure that the SSH protocol o provides strong security against cryptanalysis and protocol attacks, o can work reasonably well without a global key management or certificate infrastructure, o can utilize existing certificate infrastructures (e.g., DNSSEC, SPKI, X.509) when available, o can be made easy to deploy and take into use, o requires minimum or no manual interaction from users, o is reasonably clean and simple to implement. The resulting protocol will operate over TCP/IP or other reliable but insecure transport. It is intended to be implemented at the application level. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Oct 97 SSH Transport Layer Protocol Mar 97 Oct 97 SSH Authentication Protocol Mar 97 Oct 97 SSH Connection Protocol Oct 97 New SSH Protocol Architecture SNA DLC Services MIB (snadlc) ----------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Shannon Nix Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Technical Advisor(s): Ken Key Mailing Lists: General Discussion:snadlcmib@cisco.com To Subscribe: snadlcmib-request@cisco.com Archive: Description of Working Group: The SNA DLC Services MIB Working Group is chartered to define a set of managed objects for the SDLC and LLC-2 data link controls for SNA networks. These objects will be the minimum necessary to provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing enterprise-specific MIB modules that define objects which support management of these devices. The group may choose to consider any work done by the IEEE in the area of managed object definition for LLC-2. It will also make sure that its work is aligned with the SNA NAU Services MIB Working Group, due to the close relationship between the devices being worked on by the two groups. The working group recognizes that managed objects for other SNA data link controls and related components (e.g., QLLC, System/370 Channel, Data Link Switching, and ESCON) may need to be identified in the future. These objects are out of scope for the current charter; however, once the group completes its charter, a new charter identifying some or all of these components may be considered. Internet-Drafts: No Current Internet-Drafts. SNA NAU Services MIB (snanau) ----------------------------- Charter Last Modified: 08-Oct-97 Current Status: Active Working Group Chair(s): Robert Moore Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:snanaumib@external.cisco.com To Subscribe: snanaumib-request@cisco.com Archive: ftp://ftp.cisco.com/snanaumib/mail-archive Description of Working Group: The SNA NAU MIB Working Group is chartered to define a set of managed objects for SNA Network Accessible Units. These objects will provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group has completed MIBs for base SNA NAU functions, for LU Type 6.2 or APPC (Advanced Program-to-Program Communication), and for APPN (Advanced Peer-to-Peer Networking). MIBs for Dependent LU Requester (DLUR) and for HPR (High Performance Routing) are nearing completion. The working group is currently working on a MIB for APPN Extended Border Node (EBN). The working group will make sure that its work is aligned with the SNA DLC MIB Working Group, due to the close relationship between the devices being worked on by the two groups. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 May 97 Definitions of Managed Objects for HPR Nov 96 May 97 Definitions of Managed Objects for DLUR Sep 97 New Definitions of Managed Objects for Extended Border Node SNMP Version 3 (snmpv3) ----------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Russ Mundy Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: Michael O'Dell Mailing Lists: General Discussion:snmpv3@tis.com To Subscribe: snmpv3-request@tis.com Archive: ftp://ftp.tis.com/pub/ietf/snmpv3 Description of Working Group: The SNMPv3 Working Group is chartered to prepare recommendations for the next generation of SNMP. The goal of the Working Group is to produce the necessary set of documents that will provide a single standard for the next generation of core SNMP functions. During the past several years, there have been a number of activities aimed at incorporating security and other improvements to SNMP. Unfortunately, strongly held differences on how to incorporate these improvements into SNMP prevented the SNMPV2 Working Group from coming to closure on a single approach. As a result, two different approaches (commonly called V2u and V2*) have emerged. The Security and Administrative Framework Evolution for SNMP Advisory Team (the Advisory Team) was formed to provide a single recommended approach for SNMP evolution. The technical starting point for this Working Group will be the recommended approach provided by the Advisory Team. This approach provides for the convergence of concepts and technical elements of V2u and V2*. The SNMPv3 Working Group is not starting new work and will use as many concepts, technical elements and documentation as practical from the V2u and V2* activities. Previous delays in providing a single standard for the next generation of SNMP core functions dictate that the Working Group move forward as quickly as possible to document and publish Internet Drafts and RFC's. To this end, the Working Group will make use of as much existing documentation as practical. Additionally, functional changes beyond those needed to provide a single approach will be strongly discouraged. Timely completion of a single approach for SNMPv3 is crucial for the continued success of SNMP. Recognizing the need for prompt completion, the following objectives are provided to the Working Group: - accommodate the wide range of operational environments with differing management demands; - facilitate the need to transition from previous, multiple protocols to SNMPv3; - facilitate the ease of setup and maintenance activities. Note: SNMPv3 planned specifications: SNMPv3 Modules and Interface Definitions SNMPv3 Message Processing and Control Module Specification SNMPv3 Security Model Module Specification SNMPv3 Local Processing Mosule Specification SNMPv3 Proxy Specification Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 97 Oct 97 An Architecture for Describing SNMP Management Frameworks Apr 97 May 97 Local Processing Model for version 3 of the Simple Network Management Protocol (SNMPv3) May 97 Oct 97 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) May 97 Jun 97 User-based Security Model for version 3 of the Simple Network Management Protocol (SNMPv3) Jun 97 Oct 97 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) Jul 97 Oct 97 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) Jul 97 Oct 97 SNMPv3 Applications Simple Public Key Infrastructure (spki) --------------------------------------- Charter Last Modified: 30-Jan-97 Current Status: Active Working Group Chair(s): Steve Bellovin Perry Metzger Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:spki@c2.net To Subscribe: majordomo@c2.net In Body: In Body: subscribe spki [email address] Archive: Description of Working Group: Many Internet protocols and applications which use the Internet employ public key technology for security purposes and require a public key infrastructure to manage public keys. The task of the working group will be to develop Internet standards for an IETF sponsored public key certificate format, associated signature and other formats, and key acquisition protocols. The key certificate format and associated protocols are to be simple to understand, implement, and use. For purposes of the working group, the resulting formats and protocols are to be known as the Simple Public Key Infrastructure, or SPKI. The SPKI is intended to provide mechanisms to support security in a wide range of internet applications, including IPSEC protocols, encrypted electronic mail and WWW documents, payment protocols, and any other application which will require the use of public key certificates and the ability to access them. It is intended that the Simple Public Key Infrastructure will support a range of trust models. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Jul 97 Simple Public Key Certificate Mar 97 New SPKI Requirements Site Security Handbook (ssh) ---------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Barbara Fraser User Services Area Director(s): Joyce K. Reynolds User Services Area Advisor: Joyce K. Reynolds Mailing Lists: General Discussion:ssh@cert.org To Subscribe: ssh-request@cert.org Archive: ftp://info.cert.org/pub/ietf/ssh Description of Working Group: The Site Security Handbook Working Group is chartered to create two documents: (1) a revised handbook that will help system and network administrators develop their own site-specific policies and procedures to deal with computer security problems and their prevention and (2) a new handbook for users. The text of these documents will be developed from the existing RFC 1244, plus needed revisions and additions. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Oct 97 Users' Security Handbook Guide for Internet Standards Writers (stdguide) ----------------------------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Greg Scott Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: Michael O'Dell Mailing Lists: General Discussion:stdguide@midnight.com To Subscribe: majordomo@midnight.com In Body: subscribe stdguide Archive: ftp://ftp.midnight.com/pub/stdguide-archive Description of Working Group: This working group will provide a forum for implementers, testers, and users of current Internet standard protocols to provide feedback on the standards themselves; i.e., on what aspects of the documents defining the standards have assisted or hindered the implementation, test, and use of those protocols. The purpose of the group is to collect this information, much of which survives today as word-of-mouth knowledge in the Internet community, and present it as a BCP document. This document will cover definitions, guidelines, and a list of heuristic rules for avoiding common mistakes in writing Internet protocol standards documents. Note: This working group is jointly chartered by the Operational Requirements Area and the User Services Area. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 96 May 97 Guide for Internet Standards Writers Service Location Protocol (svrloc) ---------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): John Veizades Erik Guttman Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Thomas Narten Mailing Lists: General Discussion:srvloc@corp.home.net To Subscribe: srvloc-request@corp.home.net Archive: http://www.srvloc.org/mail_archive Description of Working Group: The Service Location Protocol is a decentralized, lightweight, scalable and extensible protocol for service discovery within a site. It allows but does not require centralized administration. Even when security, administrative policies or convenience require centralization (say in large enterprise deployments) the protocol requires very little administration. The protocol limits its use of multicast and broadcast as much as possible to conserve network bandwidth. Moreover, the protocol is extensible to arbitrary service advertisement and discovery and supports multiple languages and character set encodings. The working group will document procedures for discovering services, and standardize "service:" schemes, which are definitions for resource and service URLs. The focus of the working group will be on completing various documents which describe how to do service discovery and how to standardize service definitions which will be advertised and discovered. - Interactions between Service Location Protocol and other enterprise naming and directory service protocols will be explored, defined, and standardized. - Schemes for popular services will be discussed, and standardization efforts with other working groups explored as needed. - Operational experiences and security procedures will be discussed and documented as best current practice. - Service Type attribute definitions will be standardized by registering a 'Service Template' with IANA. This document will also describe how Service Types and Directory Schemas can be made interoperable. The Service Location Protocol can then be used to populate a directory service dynamically. - An Application Programmers Interface has been developed to allow a uniform mechanism for applications to make use of Service Location Protocol functions, which will be supplied as an informational document. - The Service Location Protocol itself will be revised and improved on, continuing it along the standards track. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 96 Oct 97 Finding Stuff (How to discover services) Jul 96 Feb 97 Service Location Modifications for IPv6 Nov 96 Oct 97 Service Templates and service: Schemes Nov 96 Mar 97 An API for Service Location Feb 97 Oct 97 Advertising Services (Providing information to support service discovery) Feb 97 Oct 97 The 'wp:' and 'yp:' Abstract Service Types Jul 97 New Wide Area Network Service Location Jul 97 New Conversion of LDAP Schemas to and from SLP Templates Jul 97 New Definition of lpr: URLs for use with Service Location TCP Implementation (tcpimpl) ---------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Steve Alexander Vern Paxson Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:tcp-impl@engr.sgi.com To Subscribe: majordomo@engr.sgi.com Archive: ftp://ftp.sgi.com/other/tcp-impl/mail.archive Description of Working Group: The objective of this group is to decide how to best address known problems in existing implementations of the current TCP standard(s) and practices. The overall goal is to improve conditions in the existing Internet by enhancing the quality of current TCP/IP implementations. It is hoped that both performance and correctness issues can be resolved by making implementors aware of the problems and their solutions. In the long term, it is felt that this will provide a reduction in unnecessary traffic on the network, the rate of connection failures due to protocol errors, and load on network servers due to time spent processing both unsuccessful connections and retransmitted data. This will help to ensure the stability of the global Internet. Examples of detected problems: o TCPs that retransmit all unacknowledged data at a single time. This behavior greatly adds to Internet load, at a time when the network is already under stress. The combination can lead to congestion collapse. o TCPs that misinitialize the congestion window, leading to potentially enormous bursts of traffic when new connections begin. Such burstiness can greatly stress Internet routers. In the BOF, it was generally agreed that problems of this class need to be fixed. Scope: The scope of this group must be carefully defined in order to ensure timely progress. To this end, TCP issues that still remain areas of research are considered out of scope for the WG. For example new improvements in congestion control algorithms are not within the WG scope. The WG will solicit input from the End-To-End research group of the IRTF on questions of whether a TCP implementation issue is considered research. The major objectives of this group will be to : Produce a compilation of known problems and their solutions. This will raise awareness of these issues. Determine if any problems found are the result of ambiguities in the TCP specification. If necessary, produce a document which clarifies the specification. Catalog existing TCP test suites, diagnostic tools, testing organizations, and procedures that can be used by implementors to improve their code, and produce a document enumerating them. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 97 Jul 97 Known TCP Implementation Problems Jul 97 New Some Testing Tools for TCP Implementors TCP Large Windows (tcplw) ------------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): David Borman Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:tcplw@bsdi.com To Subscribe: tcplw-request@bsdi.com Archive: Description of Working Group: The TCP Large Windows Working Group is chartered to produce a specification for the use of TCP on high-delay, high-bandwidth paths. To this end, this working group recommended ``TCP extensions for long-delay paths'' (RFC 1072), and ``TCP Extension for High-Speed Paths'' (RFC 1185) be published jointly as a Proposed Standard. Deficiencies in the technical details of the documents were identified by the End-to-End Research Group of the IRTF. Rather than progress the standard with known deficiencies, the IESG tasked the End-to-End Research Group to fix and merge these two documents into a single protocol specification document. This review was done on the e2e-interest@isi.edu mailing list. The TCP Large Windows Working Group is being resurrected for a one time meeting, to review and if appropriate, approve this new document. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 97 New TCP Extensions for High Performance TCP Over Satellite (tcpsat) --------------------------- Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): Aaron Falk Transport Area Director(s): Scott Bradner Allyn Romanow Transport Area Advisor: Allyn Romanow Mailing Lists: General Discussion:tcp-over-satellite@listserv.trw.com To Subscribe: majordomo@listserv.trw.com In Body: inbody: subscribe tcp-over-satellite Archive: Description of Working Group: Satellites are being used to extend the Global Internet geographically and will be more ubiquitous in the next decade with the deployment of several proposed services capable of providing greater than T1 access to individual users anywhere in the world. Yet, satellite links have a unique combination of characteristics that can affect the throughput of TCP traffic. Because of the high-bandwidth delay product, slow start and congestion control algorithms behave much differently when the path includes a satellite link than exclusively terrestrial ones. The TCP over Satellite Working Group shall produce an informational RFC which describes the issues affecting TCP throughput over satellite links. It identifies the domains in which each issue applies, including network topology, satellite orbit (LEO, MEO, GEO), and link rates; fixes, both protocol and implementation, that ameliorate reduced throughput; and areas for further research. The purpose of including this information is to direct the research community to the areas in which show promise, not to perform the research or even advocate the results. Scope: The scope of this working group will include consideration of the following for inclusion in the Informational RFC: o Transport layer issues affecting TCP over satellite links o Existing TCP options o Compliant implementations which have some known improved performance over satellite links o Recommendation of well understood protocol changes o Identification of protocol changes that are potentially promising but require more further investigation in order to be well understood SECURITY The working group will consider in depth security issues that are relevant, describing risks and indicating how they may be addressed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 97 New Enhancing TCP Over Satellite Channels using Standard Mechanisms Transaction Internet Protocol (tip) ----------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Jim Lyon Keith Evans Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:tip@tandem.com To Subscribe: listserv@tandem.com In Body: in message body: subscribe tip Archive: Description of Working Group: The task of the TIP working group is to develop an Internet standard two-phase commit protocol specification, to enable heterogeneous Transaction Managers to agree on the outcome of a distributed transaction, based upon the Internet-Draft TIP protocol specification . [Note that since references a modified version of the Session Control Protocol (SCP), the TIP WG will also be responsible for progression of SCP to Proposed Internet Standard.] In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed (committed or aborted), even in the face of failures. This behaviour is achieved via the use of distributed transactions, employing a two-phase commit protocol (2-pc). The use of distributed transactions greatly simplifies distributed applications programming, since the number of possible outcomes is reduced from many to two, and failure recovery is performed automatically by the transaction service (Transaction Manager). Key requirements to be met are, 1) the 2-pc protocol be independent of the application-to-application communications protocol, such that it may be used with any application protocol (especially HTTP), and 2) the 2-pc protocol be simple to implement and have a small working footprint (to encourage ubiquitous implementation and offer wide applicability). The first work item of the group is to develop a requirements document, which describes at least one complete scenario in which the TIP protocol is intended to be used, and describes the requirements on the protocol with regards to: - Simplicity - Overhead/Performance - Security The protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases. The Internet-Draft document is to be used as the input base document for the development of this 2-pc protocol specification. Due to extreme differences in the approach, the group will not consider the CORBA OTS specification as a solution to its requirements. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Oct 97 Transaction Internet Protocol Version 2.0 May 97 New Session Control Protocol V 2.0 Transport Layer Security (tls) ------------------------------ Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): Win Treese Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:ietf-tls@consensus.com To Subscribe: ietf-tls-request@consensus.com Archive: http://www.imc.org/ietf-tls/mail-archive Description of Working Group: Note: This Working Group is jointly chartered by the Transport Area. The Transport Area Director: Allison Mankin Several methods of providing a secure and authenticated channel between hosts on the Internet above the transport layer have appeared. The objective of this proposed working group is to write standards track RFC(s) for protocols using the currently available Internet drafts as a basis. The SSL, PCT and SSH protocols are examples of mechanisms of establishing a secure channel for general purpose or special purpose Internet applications running over a reliable transport, usually TCP. The TLS working group is a focused effort on providing security features at the transport layer, rather than general purpose security and key management mechanisms. The standard track protocol specification will provide methods for implementing privacy, authentication, and integrity above the transport layer. The work currently under way in the area of secure IP is outside the scope of this working group. Also, general authentication mechanism discussions are outside the focus of this group. However, best efforts will be made to utilize as much as possible of the already existing technologies and methodologies in the IETF and other places to solve common problems, such as key management. The group may also produce an informational RFC to describe conventions for the interface to a Socket (or transport) layer secure library to build specific applications as well as TCP port number conventions for running secure versions of network applications. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Jul 97 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) Nov 96 Oct 97 The TLS Protocol Version 1.0 Telnet TN3270 Enhancements (tn3270e) ------------------------------------ Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): Ed Bailey Michael Boe Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Technical Advisor(s): Robert Moskowitz Mailing Lists: General Discussion:tn3270e@list.nih.gov To Subscribe: listserv@list.nih.gov In Body: sub tn3270e Archive: listserv@list.nih.gov Description of Working Group: Present specifications for access to 3270 and 5250 based applications over TCP/IP require improvement to become more commercially viable. Security, Service Location, Response Time, and Session Balancing are improvement examples. The WG will drive to update and extend the standards specifications proposed in rfc1647 and rfc1205 so that they fully support 3270 and 5250 style access to host (S/390 and AS/400) applications respectively in today's environments. Consideration will be given to work already in progress on protocols for accessing 3270 and 5250 based applications over TCP/IP. Three protocol documents will be produced. Deliverables 1. A revised version of rfc1647 (tn3270e) including clarifications of the protocol, and security considerations. The revised rfc1647 will be submitted to the IESG for advancement of the tn3270e protocol to draft standard status. Currently it is a proposed standard. 2. A new standards track document defining options for the tn3270e protocol. Such options are: IPDS printing, response time monitoring, error reporting, session balancing, service location, and security. 3. A new standards track document defining enhancements to the tn5250 protocol. This new protocol will be called tn5250e. This is not Display Station Passthrubut printing, LU assignment, service location, and security. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 97 New TN3270 Enhancements Jun 97 Sep 97 Base Definitions of Managed Objects for TN3270E Using SMIv2 Jul 97 Oct 97 Definitions of Managed Objects for TN3270E Response Time Collection Using SMIv2 DS1/DS3 MIB (trunkmib) ---------------------- Charter Last Modified: 29-Jul-97 Current Status: Active Working Group Chair(s): Fred Baker Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Mailing Lists: General Discussion:trunk-mib@external.cisco.com To Subscribe: trunk-mib-request@cisco.com Archive: Description of Working Group: This working group will consider revisions to the DS1 and DS3 MIBs (currently published as Proposed Standards in RFC-1232 and RFC-1233) in preparation for their consideration as Draft Standards. Consistent with the IETF standards process, the working group is chartered to consider only those changes to the DS1 and DS3 MIBs that are based on implementation experience or on the need to align with relevant ANSI T1M1 standards. In this context, the working group will thoroughly document the implementation or alignment rationale for each considered change. All changes made by the working group will be consistent with the existing SNMP framework and standards --- in particular, those provisions of RFC-1155 regarding addition and deprecation of objects in standard SNMP MIBs. This working group will be a short-lived activity, involving a single meeting, and will conclude its business no later than June 1992. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 95 Jun 97 Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types Oct 95 Jun 97 Definitions of Managed Objects for the DS3/E3 Interface Type Feb 96 Jun 97 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type UniDirectional Link Routing (udlr) ---------------------------------- Charter Last Modified: 29-Jan-97 Current Status: Active Working Group Chair(s): Walid Dabbous Yongguang Zhang Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:udlr@sophia.inria.fr To Subscribe: udlr-request@sophia.inria.fr Archive: ftp://zenon.inria.fr/rodeo/udlr/archive.txt Description of Working Group: Note: An alternate site for UDLR's files is: ftp://irl.cs.ucla.edu/pub/udlr High bandwidth, unidirectional transmission to low cost, receiver-only hardware is becoming an emerging network fabric, e.g. broadcast satellite links or some cable links. Two cases for unidirectional links support may be envisaged: 1. unidirectional links on top of bidirectional underlying network (wired Internet) 2. bidirectional islands connected via unidirectional links. In both cases, the integration of unidirectional links may require changes to the routing protocols in order to preserve dynamic routing across these links. A short term solution (i.e. to solve the first case) is to adopt current protocols with possible modifications. A long term solution (i.e. for the second case) is to propose, design and implement protocols that remove assumed link symmetry (e.g. by supporting 2-way metrics). There have been several proposed approaches for the short term case. The first is based on the modification of the common routing protocols (RIP, OSPF, DVMRP) in order to support unidirectional links. The second is to add a layer between the network interface and the routing software to emulate bi-directional links through tunnels. The purpose of the UDLR Working Group, therefore, is to study these approaches and suggest a short term solution to provide dynamic routing (including multicast) in the presence of unidirectional links. Internet-Drafts: No Current Internet-Drafts. Uninterruptible Power Supply (upsmib) ------------------------------------- Charter Last Modified: 06-Mar-97 Current Status: Active Working Group Chair(s): Jeffrey Case Operations and Management Area Director(s): John Curran Michael O'Dell Operations and Management Area Advisor: John Curran Mailing Lists: General Discussion:ups-mib@cs.utk.edu To Subscribe: ups-mib-request@cs.utk.edu Archive: ucs.utk.edu:~/pub/ups-mib/mail-archive Description of Working Group: This working group will produce a document that defines MIB objects for use in monitoring and (possibly) controlling both high- and low-end UPSs and related systems (e.g., power distribution systems or power conditioning systems). Related devices may be addressed in this effort to the extent that the primary focus on UPSs is not compromised. The MIB object definitions produced will be for use by SNMP and will be consistent with existing SNMP standards and framework. At its discretion, the working group may fulfill its charter by the development of distinct MIB definitions for UPS systems of differing capabilities, but the number of MIB definitions produced by the working group will not exceed two. At its discretion, the working group may produce an additional document defining traps that support the management of UPSs. Although the working group may choose to solicit input or expertise from other relevant standards bodies, no extant standards efforts or authorities are known with which alignment of this work is required. Because the structure of UPS implementations varies widely, the working group shall take special care that its definitions reflect a generic and consistent architectural model of UPS management rather than the structure of particular UPS implementations. Internet-Drafts: No Current Internet-Drafts. Uniform Resource Locator Registration Procedures (urlreg) --------------------------------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Rich Petke Ian King Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:ietf-url@imc.org To Subscribe: ietf-url-request@imc.org In Body: subscribe in message body Archive: http://www.imc.org/ietf-url/ Description of Working Group: This working group exists for the purpose of creating two documents: The first document, a BCP RFC, will be the process for registering new URL schemes. The second document, an Informational RFC, will be a guideline for the creators of new URL schemes. The purpose of this guideline will be to help ensure that new URL schemes: - Consistently implement the general syntax of URLs as specified in the URL Generic Syntax and Semantics RFC. - Are compatible with existing URL schemes. - Have clearly specified character encoding rules. - Have a well defined set of operations specified for them. - Properly address security considerations. The following issues are considered beyond the scope of this working group and shall not be addressed by it: - Modifications to the URL Generic Syntax and Semantics RFC. - Specific URL schemes, previously proposed or not, except as test cases for the guidelines document. - UR* schemes other than URLs. Justification for working group: RFC 1738 defined URL schemes for a number of protocols popular at the time that it was written. Many URL schemes for protocols not addressed in RFC 1738 have been proposed since the publication of that RFC. Due to the absence of guidelines for the development of new URL schemes, some of these recently proposed schemes lack completeness. Further, while some of these schemes are now on the standards track, no mechanism for the registration of these new schemes has yet been specified. The output of this working group is needed in order to help ensure the overall integrity and consistency of URLs in the future. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 97 New Guidelines for new URL Schemes Uniform Resource Names (urn) ---------------------------- Charter Last Modified: 29-Oct-97 Current Status: Active Working Group Chair(s): John Curran Leslie Daigle Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Harald Alvestrand Mailing Lists: General Discussion:urn-ietf@bunyip.com To Subscribe: majordomo@bunyip.com In Body: In body of message: subscribe urn-ietf Archive: ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive Description of Working Group: The goal of this working group is to define both a Uniform Resource Name (URN) framework and an initial set of components that fit this framework. URNs are persistent identifiers for information resources. The output of this Working Group will comply with RFC 1737, which defines URNs and gives requirements for them. The framework will define the mechanics for enabling global scope, persistence, and legacy support requirements of URNs; requirements for namespaces to support this structure will also be defined. Although the framework will allow URNs to be defined that vary in terms of degree of scalability and persistance, ensuring "user friendliness" of all resultant identifiers is beyond the scope of this group. This WG will define the framework for URNs, at least one resolution registry system, and at least one namespace. RFCs describing additional material will also be developed (per the milestones, below). Input documents: o A Framework for the Assignment and Resolution of Uniform Resource Names o Resolution of Uniform Resource Identifiers using the Domain Name System o Requirements for URN Resolution Systems Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Sep 97 Architectural Principles of Uniform Resource Name Resolution Mar 97 Mar 97 Namespace Identifier Requirements for URN Services Mar 97 Aug 97 URI Resolution Services Necessary for URN Resolution Apr 97 Sep 97 Using Existing Bibliographic Identifiers as Uniform Resource Names May 97 May 97 URN Syntax May 97 Jul 97 A URN Namespace for IETF Documents User Services (uswg) -------------------- Charter Last Modified: 24-Oct-97 Current Status: Active Working Group Chair(s): Joyce K. Reynolds User Services Area Director(s): Joyce K. Reynolds User Services Area Advisor: Joyce K. Reynolds Mailing Lists: General Discussion:uswg@isi.edu To Subscribe: uswg-request@isi.edu Archive: ftp://ftp.near.net/mail-archives/us-wg* Description of Working Group: The User Services Working Group of the IETF provides a regular forum for people interested in all levels of user services to identify and initiate projects designed to improve the quality of information available to users of the Internet. Actual projects themselves are handled by separate groups, usually through IETF working groups, or through liaisons with international organizations such as TERENA's (Trans-European Research and Education Network Association) Information Services and User Support. (1) Meet on a regular basis to consider projects designed to improve services to users. In general, projects should: - Clearly address user assistance needs; - Produce an end-result (e.g., a document, a program plan, etc.); - Have a reasonably clear approach to achieving the end-result (with an estimated time for completion); and - Not duplicate existing or previous efforts. (2) Create working groups or other focus groups to carry out projects deemed worthy of pursuing. (3) Provide a forum in which user services providers can discuss and identify common concerns. This is an active, on-going working group in the USV area of the IETF. It is the spawning ground for establishing other working groups in this area. Internet-Drafts: No Current Internet-Drafts. 100VG-AnyLAN MIB (vgmib) ------------------------ Charter Last Modified: 12-Sep-97 Current Status: Active Working Group Chair(s): Jeff Johnson Internet Area Director(s): Jeffrey Burgan Thomas Narten Internet Area Advisor: Jeffrey Burgan Technical Advisor(s): Kaj Tesink Mailing Lists: General Discussion:vgmib@hprnd.rose.hp.com To Subscribe: vgmib-request@hprnd.rose.hp.com Archive: ftp://rosegarden.external.hp.com/pub/vgmib Description of Working Group: The 100VG-AnyLAN MIB Working Group is chartered to develop a set of managed objects for IEEE 802.12 network interfaces and repeaters. These objects will be the minimum necessary to provide the ability to monitor and control these network interfaces and repeaters, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider as an important input Section 13 (Layer Management Functions and Services), and Annex E (GDMO Specifications for Demand Priority Managed Objects) in the current IEEE 802.12 Draft, and will monitor and track the progress of that draft as it moves toward IEEE standardization. Furthermore, the working group will follow the guidelines in the SNMPv2 SMI for mapping GDMO managed objects for use with the Internet Network Management Framework. In addition, the working group will solicit vendor-specific MIB modules to use as input to the working group. This working group will produce two documents: Definitions of Managed Objects for IEEE 802.12 Interfaces Definitions of Managed Objects for IEEE 802.12 Repeater Devices For the repeater portion of the MIB, the working group will make sure that its work is aligned with the 802.3 Repeater MIB Working Group to ensure that the two working groups produce a consistent framework for the management of repeater devices. As a result, development of the repeater portion of the MIB will be done concurrently with, but independently from, the interfaces portion of the MIB. Furthermore, the goals and milestones associated with the repeater portion of the MIB are dependent upon the goals and milestones of the 802.3 Repeater MIB Working Group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 95 May 97 Definitions of Managed Objects for IEEE 802.12 Repeater Devices Virtual Router Redundancy Protocol (vrrp) ----------------------------------------- Charter Last Modified: 28-Oct-97 Current Status: Active Working Group Chair(s): Bob Hinden Routing Area Director(s): Joel Halpern Routing Area Advisor: Joel Halpern Mailing Lists: General Discussion:vrrp@drcoffsite.com To Subscribe: listserv@drcoffsite.com w In Body: subscribe vrrp Archive: ftp://ftp.ietf.org/ietf-mail-archive/vrrp/* Description of Working Group: The purpose of this working group is to define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. A virtual router redundancy protocol is a protocol which allows several routers on a multiaccess link to utilize the same virtual IP address. One router will be elected as a master with the other routers acting as backups in case of the failure of the master router. The primary motivation to using a virtual router redundancy protocol is that host systems may be configured (manually or via DHCP) with a single default gateway, rather than running an active routing protocol. The protocol should also support the ability to load share traffic when both routers are up. The goals of this working group are: 1. Define and develop a standard virtual router redundancy protocol for IPv4 and IPv6. 2. Develop VRRP MIB(s). 3. Separate specifications will be developed for IPv4 and IPv6. 4. Determine whether static (configuration based) load sharing is adequate or if some amount of dynamic load sharing is required. 5. Working group will examine security issues to determine what security threats it is appropriate for the VRRP protocol to handle and include the appropriate mechanisms in the VRRP protocol. 6. The internet draft "Virtual Router Redundancy Protocol" will be use as the basis of virtual router redundancy protocol. The working group will also consider other internet drafts related to this topic allowing for issues regarding change control, security, running code, etc. 7. Intellectual property issues regarding the technology to develop a virtual router redundancy protocol will be identified and addressed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 Oct 97 Virtual Router Redundancy Protocol WWW Distributed Authoring and Versioning (webdav) ------------------------------------------------- Charter Last Modified: 27-Oct-97 Current Status: Active Working Group Chair(s): Jim Whitehead Applications Area Director(s): Keith Moore Harald Alvestrand Applications Area Advisor: Keith Moore Mailing Lists: General Discussion:w3c-dist-auth@w3.org To Subscribe: w3c-dist-auth-request@w3.org In Body: Subject of subscribe Archive: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/ Description of Working Group: This working group will define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs. The HTTP protocol contains functionality which enables the editing of web content at a remote location, without direct access to the storage media via an operating system. This capability is exploited by several existing HTML distributed authoring tools, and by a growing number of mainstream applications (e.g. word processors) which allow users to write (publish) their work to an HTTP server. To date, experience from the HTML authoring tools has shown they are unable to meet their user's needs using the facilities of the HTTP protocol. The consequence of this is either postponed introduction of distributed authoring capability, or the addition of nonstandard extensions to the HTTP protocol. These extensions, developed in isolation, are not interoperable. An ad-hoc group has analyzed the functional needs of several organizations, and has developed requirements for distributed authoring and versioning. These requirements encompass the following capabilities, which shall be considered by this working group: IN-SCOPE: *Locking: lock, lock status, unlock *Name space manipulation: copy, move/rename, resource redirection (e.g. 3xx response codes) *Containers: creation, access, modification, container-specific semantics *Attributes: creation, access, modification, query, naming *Notification of intent to edit: reserve, reservation status, release reservation *Use of existing authentication schemes *Access control *Unprocessed source retrieval *Informing proxies of an action's impact *Versioning: *Checkin/Checkout *History graph *Differencing *Automatic Merging *Naming and accessing resource versions Further information on these requirements can be found in the document, "Requirements for Distributed Authoring and Versioning on the World Wide Web". While the scope of activity of this working group may seem rather broad, in fact much of the functionality under consideration is well understood, and has been previously considered. This working group will leverage off of previous work when it is applicable. Discussion of the security issues concerning distributed authoring and versioning are essential to the creation of a protocol which implements this functionality. Though the feature set described above bears a resemblance to the capabilities provided by a network file system, the intent of this working group is not to create a replacement distributed file system (e.g. NFS, CIFS). The WEBDAV emphasis on collaborative authoring of resources which are not necessarily stored in a file system, and which have associated metadata in the form of links and attributes, differentiate WEBDAV from a distributed file system. Many decisions have been made to reduce the scope of effort of this working group. It is the intent of this working group to avoid the inclusion of the following functionality, unless it proves impossible to create a useful set of distributed authoring capabilities without it: NOT IN SCOPE: *Definition of core attribute sets, beyond those attributes necessary for the implementation of distributed authoring and versioning functionality *Creation of new authentication schemes *HTTP server to server communication protocols *Distributed authoring via non-HTTP protocols (except email) *Implementation of functionality by non-origin proxies Eventually, it is desirable to provide access to WEBDAV capability by disconnected clients, or by clients whose only connectivity is via email. However, given the scope of developing requirements and specifications for disconnected operation, the initial target user group of fully connected clients, and the desire to work swiftly, the working group will address this issue by ensuring the protocol specification does not preclude a future body from developing an interoperability specification for disconnected operation via email. Deliverables The final output of this working group is expected to be three documents: 1. A scenarios document, which gives a series of short descriptions of how distributed authoring and versioning functionality can be used, typically from an end-user perspective. Ora Lassila, Nokia, currently visiting with the World Wide Web Consortium, is editor of this document. 2. A requirements document, which describes the high-level functional requirements for distributed authoring and versioning, including rationale. Judith Slein, Xerox, is editor of this document. 3. A protocol specification, which describes new HTTP methods, headers, request bodies, and response bodies, to implement the distributed authoring and versioning requirements. Del Jensen, Novell, is editor of this document. The most recent versions of these documents are accessible via links from the WEBDAV Web page. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 96 New HTTP-based Distributed Content Editing Scenarios Feb 97 Sep 97 Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web Jul 97 Oct 97 Extensions for Distributed Authoring and Versioning on the World Wide Web -- WEBDAV Oct 97 New WebDAV Tree Operations Web Transaction Security (wts) ------------------------------ Charter Last Modified: 23-Aug-95 Current Status: Active Working Group Chair(s): Charlie Kaufman Security Area Director(s): Jeffrey Schiller Security Area Advisor: Jeffrey Schiller Mailing Lists: General Discussion:www-security@nsmx.rutgers.edu To Subscribe: www-security-request@nsmx.rutgers.edu Archive: http://www-ns.rutgers.edu/www-security Description of Working Group: The goal of the Web Transaction Security Working Group is to develop requirements and a specification for the provision of security services to Web transaction, e.g., transactions using HyperText Transport Protocol (HTTP). This work will proceed in parallel to and independently of the development of non-security features in the HTTP Working Group. The working group will prepare two documents for submission as Internet Drafts; an HTTP Security Requirements Specification, and an HTTP Security Protocol Specification. The latter will be submitted as a Standards Track RFC. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 94 Mar 97 The Secure HyperText Transfer Protocol Feb 96 Mar 97 Security Extensions For HTML