Internet Message Extensions (822ext) Charter Chair(s): Gregory Vaudreuil Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-822@dimacs.rutgers.edu To Subscribe: ietf-822-request@dimacs.rutgers.edu Archive: cnri.reston.va.us:~/ietf.mail.archives/822ext/* Description of Working Group: This Working Group was chartered to extend the RFC 822 Message format to facilitate multi-media mail and alternate character sets. RFCs 1341 and RFC 1342 document the Multi-Media Extensions for Internet Mail. The Working Group will work to progress MIME to Draft Standard status and provide a forum for the review of standards track content-type specifications and the review of character set extensions to MIME. Goals and Milestones: Done Review the Charter, and refine the Group's focus. Decide whether this is a worthwhile effort. Done Discuss, debate, and choose a framework for the solution. Assign writing assignments, and identify issues to be resolved. Done Review exiting writing, resolve outstanding issues, identify new work, and work toward a complete document. Done Post a first Internet Draft. Done Review and finalize the draft document. Done Submit the document as a Proposed Standard. Done Post an Internet Draft for the use of Japanese Characters for Internet Mail. Done Post a revised version of the MIME document as an Internet Draft. Mar 93 Submit the revised MIME document to the IESG for consideration as a Draft Standard. Mar 93 Submit the Japanese Character set specification as an Informational document. Internet Accounting (acct) Charter Chair(s): Cyndi Mills Gregory Ruth Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:accounting-wg@wugate.wustl.edu To Subscribe: accounting-wg-request@wugate.wustl.edu Archive: Description of Working Group: The Internet Accounting Working Group has the goal of producing standards for the generation of accounting data within the Internet that can be used to support a wide range of management and cost allocation policies. The introduction of a common set of tools and interpretations should ease the implementation of organizational policies for Internet components and make them more equitable in a multi-vendor environment. In the following accounting model, this Working Group is primarily concerned with defining standards for the Meter function and recommending protocols for the Collector function. Individual accounting applications (billing applications) and organizational policies will not be addressed, although examples should be provided. Meter $<$--$>$ Collector $<$--$>$ Application $<$--$>$ Policy First, examine a wide range of existing and hypothetical policies to understand what set of information is required to satisfy usage reporting requirements. Next, evaluate existing mechanisms to generate this information and define the specifications of each accounting parameter to be generated. Determine the requirements for local storage and how parameters may be aggregated. Recommend a data collection protocol and internal formats for processing by accounting applications. This will result in an Internet-Draft suitable for experimental verification and implementation. In parallel with the definition of the draft standard, develop a suite of test scenarios to verify the model. Identify candidates for prototyping and implementation. \newpage Goals and Milestones: Done Policy models examined. Done Internet Accounting Background Working Draft written. Done Collection Protocols Working Papers written. Done Internet Accounting Background final draft submitted to the IESG for consideration as an Informational RFC. Done Collection protocol recommendation. Done Architecture submission as Internet-Draft. Done Post the Accounting Meter MIB as an Internet-Draft. Jan 93 Architecture document submitted to the IESG for consideration as a Proposed Standard. Jan 93 Submit the Accounting Meter MIB to the IESG for consideration as a Proposed Standard. Alert Management (alertman) Charter Chair(s): Louis Steinberg Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:alert-man@merit.edu To Subscribe: alert-man-request@merit.edu Archive: Status: concluded Description of Working Group: The Alert Management Working Group is chartered with defining and developing techniques to manage the flow of asynchronously generated information between a manager (NOC) and its remote managed entities. The output of this group should be fully compatible with the letter and spirit of SNMP (RFC 1067) and CMOT (RFC 1095). Goals and Milestones: Done Develop, implement, and test protocols and mechanisms to prevent a managed entity from burdening a manager with an unreasonable amount of unexpected network management information. This will focus on controlling mechanisms once the information has been generated by a remote device. May 90 Develop, implement, and test mechanisms to prevent a managed entity from generating locally an excess of alerts to be controlled. This system will focus on how a protocol or MIB object might internally prevent itself from generating an unreasonable amount of information. Done Write an RFC detailing the above, including examples of its conforment use with both SNMP traps and CMOT events. Dec 90 Write an RFC detailing the above. Since the implementation of these mechanisms is protocol dependent, the goal of this RFC would be to offer guidance only. It would request a status of ``optional''. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1224 E May 91 Techniques for Managing Asynchronously Generated Alerts IP over AppleTalk (appleip) Charter Chair(s): John Veizades Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:apple-ip@apple.com To Subscribe: apple-ip-request@apple.com Archive: Description of Working Group: The Macintosh Working Group is chartered to facilitate the connection of Apple Macintoshes to IP internets and to address the issues of distributing AppleTalk services in an IP internet. Goals and Milestones: Done Post an Internet-Draft the current set of protocols used to connect Macintoshes to IP internets. Done Submit the AppleTalk MIB to the IESG for consideration as a Proposed Standard. Jan 93 Submit the IP over Appletalk document to the IESG for consideration as a Proposed Standard. IP over Asynchronous Transfer Mode (atm) Charter Chair(s): Robert Hinden Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:atm@sun.com To Subscribe: atm-request@sun.com Archive: Send message to atm-request@sun.com Description of Working Group: The IP over ATM Working Group will focus on the issues involved in running internetworking protocols over Asynchronous Transfer Mode (ATM) networks. The final goal for the Working Group is to produce standards for the TCP/IP protocol suite and recommendations which could be used by other internetworking protocol standards (e.g., ISO CLNP and IEEE 802.2 Bridging). The Working Group will initially develop experimental protocols for encapsulation, multicasting, addressing, address resolution, call set up, and network management to allow the operation of internetwork protocols over an ATM network. The Working Group may later submit these protocols for standardization. The Working Group will not develop physical layer standards for ATM. These are well covered in other standard groups and do not need to be addressed in this Group. The Working Group will develop models of ATM internetworking architectures. This will be used to guide the development of specific IP over ATM protocols. The Working Group will also develop and maintain a list of technical unknowns that relate to internetworking over ATM. These will be used to direct future work of the Working Group or be submitted to other standard or research groups as appropriate. The Working Group will coordinate its work with other relevant standards bodies (e.g., ANSI T1S1.5) to insure that it does not duplicate their work and that its work meshes well with other activities in this area. The Working Group will select among ATM protocol options (e.g., selection of an adaptation layer protocol) and make recommendations to the ATM standards bodies regarding the requirements for internetworking over ATM where the current ATM standards do not meet the needs of internetworking. Goals and Milestones: Done First Meeting. Establish detailed goals and milestones for Working Group. Done Post an Internet-Draft for a mechanism for IP over ATM. (Multi-Protocol Interconnect over ATM AAL5) Done Submit the Multi-Protocol Interconnect over ATM AAL5 to the IESG as a Proposed Standard. Mar 93 Post Internet-Draft for ``Internet Requirements for ATM Signaling''. Jul 93 Submit ``Internet Requirements for ATM Signaling'' to the IESG for consideration as an Informational Document. Audio/Video Transport (avt) Charter Chair(s): Stephen Casner Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: nic.es.net:~/ietf/rem-conf/av-transport-archive 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 AV transport 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. Goals and Milestones: Done Define the scope of the Working Group, and who might contribute. Our first step will be to solicit contributions of potential protocols from projects that have already developed packet audio and video. From these contributions we will distill the appropriate protocol features. Done Conduct a teleconference Working Group meeting using a combination of packet audio and telephone. The topic will be a discussion of issues to be resolved in the process of synthesizing a new protocol. Done Review contributions of existing protocols, and discuss which features should be included and tradeoffs of different methods. Make writing assignments for first-draft documents. Done Post an Internet-Draft of the lightweight audio/video transport protocol. Mar 93 Submit to the IESG the Audio/Video Transport protocol for publication as an Experimental Protocol. Border Gateway Protocol (bgp) Charter Chair(s): Yakov Rekhter Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:iwg@rice.edu To Subscribe: iwg-request@rice.edu Archive: Description of Working Group: Develop the BGP protocol and BGP technical usage within the Internet, continuing the current work of the Interconnectivity Working Group in this regard. Goals and Milestones: Ongoing Coordinate the deployment of BGP in conformance with the BGP usage document in a manner that promotes sound engineering and an open competitive environment. Take into account the interests of the various backbone and mid-level networks, the various vendors, and the user community. Done Complete development of Version 2 of the Border Gateway Protocol (BGP). Done Develop a mature BGP technical usage document that allows us to build Inter-AS routing structures using the BGP protocol. Done Develop a MIB for BGP Version 3. Done Work with the Security Area to enhance the provision for security in BGP. Done Develop a BGP usage document describing how BGP can be used as part of a network monitoring strategy. Done Post an Internet-Draft specifying multicast extensions to BGP. Done Post the specfication of BGP 4 as an Internet-Draft. Done Post an Internet-Draft specifying a MIB for BGP Version 4. Jan 93 Submit the multicast extensions to BGP to the IESG as a Proposed Standard. Jan 93 Submit the specification for BGP Version 4 to the IESG for consideration as a Proposed Standard. Jan 93 Submit the BGP Version 4 MIB to the IESG for consideration as a Proposed Standard. BGP Deployment and Application (bgpdepl) Charter Chair(s): Jessica Yu Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:bgpd@merit.edu To Subscribe: bgpd-request@merit.edu Archive: merit.edu:~/pub/bgpd-archive Description of Working Group: The major purpose of this Group is to coordinate BGP deployment and application in the current Internet. It intends to create a forum for BGP users to share BGP deployment experiences and also provide a channel for users to communicate with router vendors who implemented or who are implementing BGP. It also intends to discuss BGP policy application and coordinate policy implementation in the current internet routing environment which includes defining the usage of policy, defining a mechanism to share policy information, etc. Goals and Milestones: Ongoing Facilitate the deployment of BGP as widely as possible. Define the issues and the needs of policy routing in the current Internet architecture. Discuss how BGP policy routing capability applies to Internet policy routing needs. A document may be generated on this topic. Dec 92 Post as an Internet-Draft, a report of BGP deployment status. Mar 93 Post an Internet-Draft, defining a mechanism to share policy information between Administrative Domains. Benchmarking Methodology (bmwg) Charter Chair(s): Scott Bradner Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:bmwg@harvard.edu To Subscribe: bmwg-request@harvard.edu Archive: 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 different classes of network equipment and software services. Each recommendation will describe the class of equipment or service, discuss the performance characteristics that are pertinent to that class, specify a suite of performance benchmarks that test the described characteristics, as well as specify the requirements for common reporting of benchmark results. Classes of network equipment can be broken down into two broad categories. The first deals with stand-alone network devices such as routers, bridges, repeaters, and LAN wiring concentrators. The second category includes host dependent equipment and services, such as network interfaces or TCP/IP implementations. Once benchmarking methodologies for stand-alone devices have matured sufficiently, the Group plans to focus on methodologies for testing system-wide performance, including issues such as the responsiveness of routing algorithms to topology changes. Goals and Milestones: Once the community has had time to comment on the definitions of devices and performance criteria, a second document will be issued. This document will make specific recommendations regarding the suite of benchmark performance tests for each of the defined classes of network devices. Done The document will also define various classes of stand-alone network devices such as repeaters, bridges, routers, and LAN wiring concentrators as well as detail the relative importance of various performance criteria within each class. Done Issue a document that provides a common set of definitions for performance criteria, such as latency and throughput. Bridge MIB (bridge) Charter Chair(s): Fred Baker Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:bridge-mib@nsl.dec.com To Subscribe: bridge-mib-request@nsl.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. Goals and Milestones: Done Publish initial proposal. Done Submit an Internet-Draft. Done Submit draft for RFC publication. Mar 93 Publish a draft revision to RFC 1286 that reflects implementation experience and the result of alignments with IEEE work as an Internet-Draft. Mar 93 Publish a draft SNMP MIB that instruments functions specific to source routed bridges as an Internet-Draft. Apr 93 Submit a draft MIB for source routing bridge functions to the IESG for consideration as a Proposed Standard. Common Authentication Technology (cat) Charter Chair(s): John Linn Security Area Director(s) Steve Crocker Mailing lists: General Discussion:cat-ietf@mit.edu To Subscribe: cat-ietf-request@mit.edu Archive: bitsy.mit.edu:~/cat-ietf/archive Description of Working Group: The goal of the Common Authentication Technology Working Group is to provide strong authentication 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 will pursue several interrelated tasks. We will work towards agreement on a common service interface allowing callers to invoke security services, and towards agreement on a common authentication token format, incorporating means to identify the mechanism type in conjunction with which authentication data elements should be interpreted. The CAT Working Group will also work towards agreements on suitable underlying mechanisms to implement security functions; two candidate architectures (Kerberos V5, based on secret-key technology and contributed by MIT, and X.509-based public-key Distributed Authentication Services being prepared for contribution by DEC) are under current consideration. The CAT Working Group will consult with other IETF working groups responsible for candidate caller protocols, pursuing and supporting design refinements as appropriate. Goals and Milestones: Done Progress Internet-Draft and RFC publication of mechanism-level documents to support independent, interoperable implementations of CAT-supporting mechanisms. Done Preliminary BOF session at IETF meeting, discussions with Telnet and Network Printing Working Groups. Done Distribute Generic Security Service Application Program Interface (GSS-API) documentation through Internet-Draft process. Done First IETF meeting as full Working Group: review Charter distribute documents, and status of related implementation, integration, and consulting liaison activities. Schedule follow-on tasks, including documentation plan for specific CAT-supporting security mechanisms. Oct 91 Update mechanism-independent Internet-Drafts in response to issues raised, distribute additional mechanism-specific documentation including Distributed Authentication Services architectural description and terms/conditions for use of the technology documented therein. Nov 91 Second IETF meeting: Review distributed documents and status of related activities, continue consulting liaisons. Discuss features and characteristics of underlying mechanisms. Define scope and schedule for follow-on work. Dec 91 Submit service interface specification to to the IESG for consideration as a Proposed Standard. Character MIB (charmib) Charter Chair(s): Bob Stewart Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:char-mib@decwrl.dec.com To Subscribe: char-mib-request@decwrl.dec.com Archive: Status: concluded Description of Working Group: The Character MIB Working Group is chartered to define a MIB for Character Stream Ports that attach to such devices as terminals and printers. The Working Group must first decide what it covers and what terminology to use. The initial thought was to handle terminals for terminal servers. This directly generalizes to terminals on any host. From there, it is a relatively close step to include printers, both serial and parallel. It also seems reasonable to go beyond ASCII terminals and include others, such as 3270. All of this results in the suggestion that the topic is Character Stream Ports. An important model to define is how character ports relate to network interfaces. Some (a minority) terminal ports can easily become network interfaces by running SLIP, and may slip between those states. Given the basic models, the Group must select a set of common objects of interest and use to a network manager responsible for character devices. Since the goal is an experimental MIB, it may be possible to agree on a document in 3 to 9 months. Most of the Group's business can be conducted over the Internet through email. Goals and Milestones: Done Mailing list discussion of Charter and collection of concerns. Done Discussion and final approval of Charter; discussion on models and terminology. Make writing assignments. Done First draft document, discussion, additional drafts, special meeting? Done Review latest draft and if OK, give to IESG for publication as RFC. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1316 PS Apr 92 Definitions of Managed Objects for Character Stream Devices RFC1317 PS Apr 92 Definitions of Managed Objects for RS-232-like Hardware Devices RFC1318 PS Apr 92 Definitions of Managed Objects for Parallel-printer-like Hardware Devices Chassis MIB (chassis) Charter Chair(s): Bob Stewart Jeffrey Case Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:chassismib@cs.utk.edu To Subscribe: chassismib-request@cs.utk.edu Archive: Description of Working Group: This Working Group will produce a document describing MIB objects for use in a ``chassis'' --- which is a collection of traditionally discrete network devices packaged in a single cabinet and power supply. A chassis may comprise, for example, combinations of layer 1 repeater elements, MAC layer bridges, or internetwork layer routers. The Working Group is chartered to produce up to three distinct documents that define extensions to the SNMP MIB: (1) The Working Group is chartered to define MIB objects that represent the mapping of the logical functions of traditional network devices onto particular, physical hardware resources within the chassis. These MIB definitions will not address any aspects of the network functions comprised by a chassis box that are shared with an analogous collection of discrete network devices. (2) The Working Group is chartered, at its option, to define MIB objects that instrument the operational state of a power supply element in a chassis. (3) The Working Group is chartered, at its option, to define MIB objects that represent aggregated information about collections of network devices (e.g., aggregate information about devices attached to a particular LAN), provided that this MIB specification is not specific to chassis implementations of such networks and is also readily implementable for analogous collections of discrete network devices. The MIB object definitions produced will be for use by SNMP and will be consistent with existing SNMP standards and framework. 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 chassis implementations varies widely, the Working Group shall take special care that its definitions reflect a generic and consistent architectural model of chassis management rather than the structure of particular chassis implementations. Should the Working Group elect to define objects representing aggregated information about collections of network devices, those efforts will not compromise the operational robustness of the SNMP that depends on its realization of management system function as closely as possible to centers of responsible authority. Goals and Milestones: Done Discuss the Charter and define the scope of the Working Group. In particular, review all contributed MIBs and agreement on plan for producing baseline document(s). Done Post the first draft of the Chassis MIB specification as an Internet-Draft. Jan 93 Submit the Chassis MIB to the IESG as a Proposed Standard. Distributed Scheduling Protocol (chronos) Charter Chair(s): Paul Linder Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:chronos@boombox.micro.umn.edu To Subscribe: chronos-request@boombox.micro.umn.edu Archive: /pub/chronos @boombox.micro.umn.edu Status: concluded Description of Working Group: The Chronos protocol Working Group is chartered to define a protocol for the management of calendars, appointments and schedules over the Internet. In defining this protocol, several questions must be addressed. The role of the calendar administrator must be defined. Differing levels of security need to be specified to allow maximum functionality yet still allow privacy and flexibility. The scope of the protocol should also be evaluated; how much burden should we put on the server, on the client? Additionally the behavior of multiple chronos servers must be analyzed. This protocol should be able to be developed and stabilized within 6-8 months, since there is already a draft specification to work from. The process is subject to extension if many new features are added, or more revision is needed. Goals and Milestones: Jan 91 Review first draft document, determine necessary revisions. Follow up discussion will occur on mailing list. Prototype implementations. Feb 91 Make document an Internet Draft. Continue revisions based on comments received over e-mail. Mar 91 Spring IETF meeting. Review final draft and if OK, give to IESG for publication as RFC. Begin implementations. Jul 91 Revise document based on implementations. Ask IESG to make the revision a Draft Standard. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Connection IP (cip) Charter Chair(s): Claudio Topolcic Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:cip@bbn.com To Subscribe: cip-request@bbn.com Archive: Status: concluded Description of Working Group: This Working Group is looking at issues involved in connection-oriented (or stream- or flow-oriented) internet level protocols. The long-term intent is to identify the issues involved, to understand them, to identify algorithms that address them, and to produce a specification for a protocol that incorporates what the Working Group has learned. To achieve this goal, the Group is defining a two year collaborative research effort based on a common hardware and software base. This will include implementing different algorithms that address the issues involved and performing experiments to compare them. On a shorter time-line, ST is a stream-oriented protocol that is currently in use in the Internet. A short-term goal of this Working Group is to define a new specification for ST, called ST-2, inviting participation by any interested people. MCHIP and the Flow Protocol have also been discussed because they include relevant ideas. Goals and Milestones: Done Define common hardware and software platform. Done Produce a new specification of ST. Done Implement hardware and software platform. May 91 Implement experimental modules and perform experiments. May 92 Produce a specification of a next generation connection oriented protocol. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1190 E Oct 90 Experimental Internet Stream Protocol, Version 2 (ST-II) Commercial Internet Protocol Security Option (cipso) Charter Chair(s): Ron Sharp Security Area Director(s) Steve Crocker Mailing lists: General Discussion:cipso@wdl1.wdl.loral.com To Subscribe: cipso-request@wdl1.wdl.loral.com Archive: archive-server@wdl1.wdl.loral.com Description of Working Group: The Commercial Internet Protocol Security Option Working Group is chartered to define an IP security option that can be used to pass security information within and between security domains. This new security option will be modular in design to provide developers with a single software environment which can support multiple security domains. The CIPSO protocol will support a large number of security domains. New security domains will be registered with the Internet Assigned Numbers Authority (IANA) and will be available with minimal difficulty to all parties. There is currently in progress another IP security option referred to as IPSO (RFC 1108). IPSO is designed to support the security labels used by the U.S. Department of Defense. CIPSO will be designed to provide labeling for the commercial, U.S. civilian and non-U.S. communities. The Trusted Systems Interoperability Group (TSIG) has developed a document which defines a structure for the proposed CIPSO option. The Working Group will use this document as a foundation for developing an IETF CIPSO specification. Goals and Milestones: Ongoing Review outstanding comments/issues from mailing list. Continue the process to advance the Draft Standard to a Standard. Done Review and approve the Charter for the IETF CIPSO Working Group. Review revised TSIG CIPSO Specification. Done Review outstanding comments/issues from mailing list. Continue work on specification and prepare it for submission as an Internet-Draft by the end of May. Jul 91 Review outstanding comments/issues from mailing list. The specification will be submitted to the IESG for consideration as a Proposed Standard. Mar 92 Submit specification to the IESG for consideration as a Draft Standard. There must be at least two interoperable implementations by this time. DECnet Phase IV MIB (decnetiv) Charter Chair(s): Jonathan Saperia Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:phiv-mib@jove.pa.dec.com To Subscribe: phiv-mib-request@jove.pa.dec.com Archive: Status: concluded Description of Working Group: The DECNet Phase IV MIB Working Group will define MIB elements in the experimental portion of the MIB which correspond to standard DECNet Phase IV objects. The Group will also define the access mechanisms for collecting the data and transforming it into the proper ASN.1 structures to be stored in the MIB. In accomplishing our goals, several areas will be addressed. These include: Identification of the DECNet objects to place in the MIB, identification of the tree stucture and corresponding Object ID's for the MIB elements, Generation of the ASN.1 for these new elements, development of a proxy for non-decnet based management platforms, and a test implementation. Goals and Milestones: Done Review and approve the Charter and description of the Working Group, making any necessary changes. At that meeting, the scope of the work will be defined and individual working assignments will be made. Done Mailing list discussion of Charter and collection of concerns. Done Review first draft document, determine necessary revisions. Follow up discussion will occur on mailing list. If possible, prototype implementation to begin after revisions have been made. Done Make document an Internet Draft. Continue revisions based on comments received at meeting and over e-mail. Begin `real' implementations. Done Review final draft and if OK, give to IESG for publication as RFC. Jul 91 Revise document based on implementations. Ask IESG to make the revision a Draft Standard. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1289 PS Dec 91 DECnet Phase IV MIB Extensions Distributed File Systems (dfs) Charter Chair(s): Peter Honeyman Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:dfs-wg@citi.umich.edu To Subscribe: dfs-wg-request@citi.umich.edu Archive: Description of Working Group: Trans- and inter-continental distributed file systems are upon us. The consequences to the Internet of distributed file system protocol design and implementation decisions are sufficiently dire that we need to investigate whether the protocols being deployed are really suitable for use on the Internet. There's some evidence that the opposite is true, e.g., some distributed file systems protocols don't checksum their data, don't use reasonable MTUs, don't offer credible authentication or authorization services, don't attempt to avoid congestion, etc. Accordingly, a Working Group on DFS has been formed by the IETF. The Working Group will attempt to define guidelines for ways that distributed file systems should make use of the network, and to consider whether any existing distributed file systems are appropriate candidates for Internet standardization. The Working Group will also take a look at the various file system protocols to see whether they make data more vulnerable. This is a problem that is especially severe for Internet users, and a place where the IETF may wish to exert some influence, both on vendor offerings and user expectations. Goals and Milestones: May 90 Generate an RFC with guidelines that define appropriate behavior of distributed file systems in an internet environment. Dynamic Host Configuration (dhc) Charter Chair(s): Ralph Droms Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:host-conf@sol.bucknell.edu To Subscribe: host-conf-request@sol.bucknell.edu Archive: sol.bucknell.edu:~/dhcwg Description of Working Group: The purpose of this Working Group is the investigation of network configuration and reconfiguration management. We will determine those configuration functions that can be automated, such as Internet address assignment, gateway discovery and resource location, and those which cannot be automated (i.e., those that must be managed by network administrators). Goals and Milestones: Write a bootp extensions document. Done We will identify (in the spirit of the Gateway Requirements and Host Requirements RFCs) the information required for hosts and gateways to: Exchange Internet packets with other hosts, Obtain packet routing information, Access the Domain Name System, and Access other local and remote services. Done We will summarize those mechanisms already in place for managing the information identified by Objective 1. Done We will suggest new mechanisms to manage the information identified by Objective 1. Done Having established what information and mechanisms are required for host operation, we will examine specific scenarios of dynamic host configuration and reconfiguration, and show how those scenarios can be resolved using existing or proposed management mechanisms. Directory Information Services Infrastructure (disi) Charter Chair(s): Chris Weider User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:disi@merit.edu To Subscribe: disi-request@merit.edu Archive: pub/disi-archive@merit.edu Status: concluded Description of Working Group: The Directory Information Services (pilot) Infrastructure Working Group is chartered to facilitate the deployment in the Internet of Directory Services based on implementations of the X.500 standards. It will facilitate this deployment by producing informational RFCs intended to serve as a Directory Services ``Administrator's Guide''. These RFCs will relate the current usage and scope of the X.500 standard and Directory Services in North America and the world, and will contain information on the procurement, installation, and operation of various implementations of the X.500 standard. As the various implementations of the X.500 standard work equally well over TCP/IP and CLNP, the DISI Working Group shall not mandate specific implementations or transport protocols. The DISI Working Group is an offshoot of the OSI Directory Services Group, and, accordingly, is a combined effort of the OSI Integration Area and User Services Area of the IETF. The current OSIDS Working Group was chartered to smooth out technical differences in information storage schema and difficulties in the interoperability and coherence of various X.500 implementations. The DISI Group is concerned solely with expanding the Directory Services infrastructure. As DISI will be providing infrastructure with an eye towards truly operational status, DISI will need to form liaisons with COSINE, Paradise, and perhaps the RARE WG3. As a final document, the DISI Working Group shall write a Charter for a new working group concerned with user services, integration, maintenance, and operations of Directory Services, the Internet Directory User Services Group. Goals and Milestones: Done Submit an Internet-Draft on `Catalog of available X.500 Implementations' Done Submit to the IESG the `Catalog of available X.500 Implementations' as an informational document. Done Submit an Internet-Draft on `Executive Introduction to X.500' Done Submit to the IESG the `Executive Introduction to X.500' as an informational document. Done Submit an Internet-Draft on `A Technical Overview of Directory ervices and X.500'. Done Submit to the IESG the `Technical Overview of Directory Services and X.500' as an informational document. Done First IETF Meeting: review and approve the Charter making any changes necessary. Examine needs and resources for the documentation to be produced, using as a first draft a document produced by Chris Weider, Merit, which will be brought to the IETF. Assign writing assignments. Further work will be done electronically. Done Submit as an Internet-Draft the `Advanced Usages' paper. Jul 92 Submit as an Internet-Draft the `How to get registered' paper. Nov 92 Submit to the IESG the `How to get registered' paper as an informational document. Nov 92 Submit to the IESG the `Advanced Usages' paper as an informational document. Nov 92 Submit as an Internet-Draft the `Pilot Projects Catalog' paper. Nov 92 Submit as an Internet-Draft the `Where do I belong in the Directory' paper. Mar 93 Submit to the IESG the `Pilot Projects Catalog' as an informational document. Mar 93 Submit to the IESG the `Where do I belong in the Directory' paper as an informational document. Mar 93 Submit as an Internet-Draft the `Guide to setting up a DSA'. Jul 93 Submit to the IESG the `Guide to setting up a DSA' as an informational document. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 New A Survey of Advanced Usages of X.500 RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1292 Jan 92 A Catalog of Available X.500 Implementations RFC1308 Mar 92 Executive Introduction to Directory Services Using the X.500 Protocol RFC1309 Mar 92 Technical Overview of Directory Services Using the X.500 Protocol Domain Name System (dns) Charter Chair(s): Rob Austein Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:namedroppers@nic.ddn.mil To Subscribe: namedroppers-request@nic.ddn.mil Archive: nicfs.nic.ddn.mil:~/namedroppers/*.Z Description of Working Group: The DNS Working Group is concerned with the design, operation, and evolution of the Domain Name System within the Internet. As the Internet continues to grow, we expect to serve as a focal point for work on scaling problems within the current framework, work on protocol evolution as new mechanisms become necessary, and documentation of current practice for DNS implementors and administrators. We are also responsible for oversight of DNS activities by other groups within the IETF to the extent that we review the impact such work will have on the DNS and make recomendations to the working groups and IESG as necessary. Since some of these are ongoing tasks, we do not expect the working group to disband anytime soon. Several issues are of particular concern at this time: Scaling. The DNS is the victim of its own success. The global DNS namespace has grown to the point where administering the top levels of the tree is nearly as much work as the old NIC host table used to be. We need to work on ways to distribute the load. Some of the solutions are likely to be technical, some political or economic; we still treat the top-level DNS service the way we did when DARPA was footing the bill, and the funding for that service is in the process of going away. Security. The DNS is a zero-security system; it is not even as strong as the IP layer above which it operates. As a result, accidental spoofing (cache pollution) is an all-too-frequent occurance. We need to make the DNS more robust against accidental corruption, and must provide at least an optional authentication mechanism for that portion of the community that wants one. At the same time, we must not cripple the existing system by drasticly increasing its bandwidth consumption or by mandating use of cryptographic techniques that would preclude worldwide distribution of DNS software. The global DNS database is exactly that, an existing world-wide database representing hosts on six continents and (at least) forty-five countries. A solution that does not take this into account is not acceptable. Management. We have a draft document describing MIB extensions to manage the DNS. We also need to specify a standard way to dynamically create and destroy DNS records; SNMP may be an appropriate tool for this task, but we haven't yet specified enough of the details to know for certain. We need to examine the impact that a dynamic update mechanism will have on the DNS, with particular attention to security and scaling issues. IPv7/Routing. As the fur starts flying in the battle between the IPv7 proponants and the new-routing-architecture proponants, we expect that groups on both sides will need some amount of support from the DNS. Such support is likely to be minimal and straightforward, but these proposals are likely to need "rush service" for whatever support they require. So the working group needs to monitor these activities, stay involved, and generally do what it can to make sure that DNS support is not a bottleneck. We also need to examine the impact that any proposed IPv7 system would have on the DNS, since the DNS database and protocols have special provision for IP addresses. Goals and Milestones: Post an Internet Draft of an operations guide for DNS Software. Post as an Internet Draft an implementation catalog for DNS software. Post an Internet Draft a description of the Responsible Person Record. Post an Internet draft specifying the addition of network naming capability to the DNS. Submit the DNS operators guide to the IESG for review as an Informational document. Submit the DNS implementation catalogue to the IESG for review as an Informational document. Submit to the IESG the document for load balancing in the DNS as an Informational document. Submit the responsible person record to the IESG for consideration as a proposed standard. Ongoing Monitor and offer technical support to the various groups working on the next version of IP. Post an Internet Draft of the "Big Zone" policy recommendations for root and first-level zone adminstraton. Submit the "Big Zone" policy document to the IESG for consideraton as a policy statement. Submit the specification for network naming to the IESG for consideration as a proposed standard. Done Post the DNS MIB as an Internet Draft. Feb 93 Submit the DNS MIB to the IESG for consideration as a Proposed Standard. Mar 93 Post an Internet Draft specifying the dynamic resource record creation and deletion. Mar 93 Submit to the IESG the incremental zone transfer mechanism as a Proposed Standard. Mar 93 List and prioritize the WG's goals, and pick a subset that is appropriate to pursue at the present time. Jun 93 Post an Internet Draft for adding load balancing capability to the DNS. Nov 93 Submit the proposal for dynamic resource record creation/deletion to the IESG for consideration as a Proposed Standard. Ethernet MIB (ethermib) Charter Chair(s): Frank Kastenholz Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:enet_mib@ftp.com To Subscribe: enet_mib-request@ftp.com Archive: not available Status: concluded Description of Working Group: This Working Group is charged with resolving the outstanding conformance issues with the Ethernet MIB in preparation for its elevation from Proposed to Draft Standard status. Specifically, this Working Group shall: (1) Develop a document explaining the rationale for assigning MANDATORY status to MIB variables which are optional in the relevant IEEE 802.3 specification (the technical basis for the Internet Ethernet MIB). This shall not be a standards-track document. (2) Develop an implementation report on the Ethernet MIB. This report shall cover MIB variables which are implemented in both Ethernet interface chips, and in software (i.e., drivers), and discuss the issues pertaining to both. This report shall also summarize field experience with the MIB variables, especially concentrating on those variables which are in dispute. This document shall not be a standards-track document. While the Ethernet MIB is progressing through the standardization process, this document shall be periodically updated to reflect the latest implementation and operational experience. (3) Work to reconcile the differences regarding MANDATORY and OPTIONAL MIB variables with the IEEE 802.3 Management Specification. (4) Extend explicit invitations to the members, reviewers, and participants of the IEEE 802.3 committee to participate in the Working Group's efforts. This will ensure that as much Ethernet and IEEE 802.3 expertise as possible is available. (5) Maintain a liaison with the IEEE 802.3 committee. All documents produced by the Working Group will be forwarded to the IEEE 802.3 committee for their consideration as contributions to their efforts. (6) Modify the ``grouping'' of variables in the MIB, in the light of the implementation and operational experience gained, in order to effect the desired conformance groupings. This Working Group is chartered to make only changes to the MIB that fall into the following categories: (1) Division of variables into MIB groups. This may necessitate adding or deleting groups and conceptual tables and moving variables among said groups and conceptual tables. Doing so may require the addition or deletion of variables necessary to support the conceptual tables (e.g., the ...Table, ...Entry, and ...Index types of variables). These changes may be necessary to align the MIB with the work of other standards bodies, the needs of implementors, and the needs of network managers in the Internet. (2) Changing the conformance requirements of the MIB groups in order to align the MIB with the work of other standards bodies, the needs of implementors, and the needs of network managers in the Internet. (3) Deleting variables from the MIB on the basis of implementation and operational experience showing that the variables are either unimplementable or have little practical operational value. The Working Group is explicitly barred from making changes to the definition or syntax of objects nor may the Working Group add objects to the MIB except as may be required by Point 1 above. Goals and Milestones: Done Draft Variable Status Rationale document. Done Develop Implementation Report. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1369 Oct 92 Implementation Notes and Experience for The Internet Ethernet MIB RFC1398 DS Feb 93 Definitions of Managed Objects for the Ethernet-like Interface Types IP over FDDI (fddi) Charter Chair(s): Dave Katz Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:FDDI@merit.edu To Subscribe: FDDI-request@merit.edu Archive: Status: concluded Description of Working Group: The IP over FDDI Working Group is chartered to create Internet Standards for the use of the Internet Protocol and related protocols on the Fiber Distributed Data Interface (FDDI) medium. This protocol will provide support for the wide variety of FDDI configurations (e.g., dual MAC stations) in such a way as to not constrain their application, while maintaining the architectural philosophy of the Internet protocol suite. The Group will maintain liaison with other interested parties (e.g., ANSI ASC X3T9.5) to ensure technical alignment with other standards. This Group is specifically not chartered to provide solutions to mixed media bridging problems. Goals and Milestones: Done Write a document specifying the use of IP on a single MAC FDDI station. Aug 90 Write a document specifying the use of IP on dual MAC FDDI stations. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1188 DS Oct 90 A Proposed Standard for the Transmission of IP Datagrams over FDDI Networks RFC1390 S Jan 93 Transmission of IP and ARP over FDDI Networks FDDI MIB (fddimib) Charter Chair(s): Jeffrey Case Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:fddi-mib@CS.UTK.EDU To Subscribe: fddi-mib-request@CS.UTK.EDU Archive: Description of Working Group: The FDDI MIB Working Group is chartered to define a MIB for FDDI devices that is consistent with relevant FDDI specifications produced by ANSI. All definitions produced by this Working Group will be consistent with the SNMP network management framework and other internet-standard MIBs for SNMP. Goals and Milestones: Done ``Final'' initial draft of required get/set variables. Done Initial implementations of required get/set variables. Done Revised ``final'' draft of required get/set variables. Done Adoption of draft of required get/set variables. Mar 92 Submit the FDDI MIB to the IESG for consideration as a Proposed or Draft Standard depending on the magnitude of changes to RFC 1285. Done Hold a meeting at the November IETF Plenary. Dec 92 Post an Internet-Draft aligned with current the current ANSI document factoring in implementation experience with RFC 1285. Host Resources MIB (hostmib) Charter Chair(s): Steven Waldbusser Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:hostmib@andrew.cmu.edu To Subscribe: hostmib-request@andrew.cmu.edu Archive: Description of Working Group: The Host Resources MIB Working Group is chartered to produce exactly one document that defines SNMP MIB objects that instrument characteristics common to all internet hosts. The goal of this work is to address the urgent operational need in the internet community for management of host systems. Owing to this urgency, the Working Group will focus exclusively on the alignment of existing MIB technology in order to achieve common solutions in a timely manner. For purposes of this effort, the term ``internet host'' is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although the work of the Group does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. The single MIB produced shall instrument attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. The methodology of this Working Group is to focus entirely on the alignment of existing, enterprise-specific MIBs for SNMP that are relevant to its task. The Group will work towards its goal by distillation and generalization of these existing MIBs into a single, common MIB definition. Owing to the urgent operational need for managing host systems, this effort will not be comprehensive in scope. Rather, the MIB produced by this Group will be confined to critical information about hardware and software configuration, processor and memory use, and data storage capacities, backup, and use. Owing to the lack of a well-understood and accepted architecture, the Working Group will not address in any way, mechanisms that could be used to monitor or control the use of licensed software products. All definitions produced by the Group will be consistent with the SNMP network management framework and all other internet-standard MIBs for SNMP. Wherever possible, the definitions produced will make use of or align with relevant work in progress with chartered working groups of the IETF. Also, wherever possible, the Working Group will take into consideration pre-existing, stable work produced by other, accredited standards bodies. Goals and Milestones: Done First Working Group meeting. Discuss the initial proposed document. Done Post an Internet-Draft describing the Host Resources MIB. Done Hold an interim meeting to discuss the current document. Done Meet at the IETF plenary to identify changes necessary for Working Group closure. Dec 92 Submit the Host Resources MIB to the IESG as a Proposed Standard. IEEE 802.3 Hub MIB (hubmib) Charter Chair(s): Keith McCloghrie Donna McMaster Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:hubmib@synoptics.com To Subscribe: hubmib-request@synoptics.com Archive: sweetwater.synoptics.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 are 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, wherever feasible, be semantically consistent with the managed objects defined in the IEEE draft standard P802.3K, ``Layer Management for Hub Devices.'' The Working Group will base its work on the draft that is the output of the July 1991 IEEE 802 plenary meeting. The Working Group will take special cognizance of Appendix B of that specification that sketches a possible realization of the relevant managed objects in the SNMP idiom. 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 unites 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: 10BASE5 (thick coax), 10BASE2 (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. Goals and Milestones: Done Distribute first draft of documents and discuss via E-mail. Done Working Group meeting as part of IETF to review documents. Done Distribute updated documents for more E-mail discussion. Done Review all documents at IETF meeting. Hopefully recommend advancement with specified editing changes. Done Documents available with specified changes incorporated. Done Submit the Repeater MIB to the IESG for consideration as a Proposed Standard. Nov 92 Post the Media Access Unit MIB Definition as an Internet-Draft. Apr 93 Submit the Media Access Unit MIB to the IESG for consideration as a Proposed Standard. Internet Anonymous FTP Archives (iafa) Charter Chair(s): Peter Deutsch Alan Emtage User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:iafa@cc.mcgill.ca To Subscribe: iafa-request@cc.mcgill.ca Archive: archive.cc.mcgill.ca:~/pub/iafa-archive Description of Working Group: The Internet Anonymous FTP Archives Working Group is chartered to define a set of recommended standard procedures for the access and administration of anonymous ftp archive sites on the Internet. Such a set of procedures will provide a framework for: (a) Allowing the inexperienced Internet user the ability to more easily navigate the hundreds of publically accessible archive sites. (b) Allowing users and network-based tools to retrieve specific site information such as access policies, contact information, possible areas of information specialization, archived package descriptions, etc., in a standardized manner. Particular emphasis will be placed on the possible impact of these procedures on the FTP site administrators. Attention will be paid to the impact of newer archive indexing and access tools on the operation of such archive sites. A set of suggestions will be offered to allow archive site administrators to better integrate their offerings with such tools as they are developed. The security of the anonymous FTP site configuration will also be considered to be an integral part of this document. It is expected that remote management of the archives will be adequately handled by existing network management procedures. Goals and Milestones: Done First IETF Meeting: review and approve the Charter making any changes deemed necessary. Examine the scope of the recommended procedures and impact on site administrators. Assign writing assignments for the first draft of the documents. Mar 92 Review first draft and determine necessary revisions. Follow up discussion will occur on mailing list. Jun 92 Make document an Internet-Draft. Continue revisions based on comments at IETF and on the mailing list. Nov 92 Fourth IETF meeting. Review final drafts and if OK, give to IESG for publication as an RFC. TCP Client Identity Protocol (ident) Charter Chair(s): Mike St. Johns Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ident@nri.reston.va.us To Subscribe: ident-request@nri.reston.va.us Archive: cnri.reston.va.us:~/ietf.mailing.lists/ident/* Description of Working Group: The TCP Client Identity Protocol Working Group is chartered to define a protocol for returning the identity of the user initiating a TCP connection. When a client on host A initiates a TCP connection to host B, host B may query a server on host A to determine the identity of the client on host A. The primary purpose of this protocol is to record the identity of requesters initiating a connection. This work is a clarification and standardization of the Experimental Protocol currently published as RFC 931. Goals and Milestones: Done Review implementations, and resolve outstanding issues in preparation for Draft Standard. Done Post an Internet-Draft of the revised RFC 931 Identity Server Protocol. Done Submit the Identity Server Protocol to the IESG for consideration as a Proposed Standard. Inter-Domain Multicast Routing (idmr) Charter Chair(s): Tony Ballardie Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion: To Subscribe: Archive: Description of Working Group: No description available Goals and Milestones: Inter-Domain Policy Routing (idpr) Charter Chair(s): Martha Steenstrup Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:idpr-wg@bbn.com To Subscribe: idpr-wg-request@bbn.com Archive: Description of Working Group: The Inter Domain Policy Routing Working Group is chartered to develop an architecture and set of protocols for policy routing among large numbers of arbitrarily interconnected administrative domains. Goals and Milestones: Done Write an architecture document. Done Draft Protocol Specification of key elements of the protocol. Done Develop a prototype implementation of the protocols. Done Submit the IDPR Specification to the IESG as a Proposed Standard. Integrated Directory Services (ids) Charter Chair(s): Chris Weider Tim Howes User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:ids@merit.edu To Subscribe: ids-request@merit.edu Archive: merit.edu:~/pub/ids-archive Description of Working Group: The Integrated Directory Services Working Group (IDS) is chartered to facilitate the integration and interoperability of current and future directory services into a unified directory service. This work will unite directory services based on a heterogeneous set of directory services protocols (X.500, WHOIS++, etc.). In addition to specifying technical requirements for the integration, the IDS 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. IDS will also assume responsibility for the completion of the outstanding Directory Information Services Infrastructure (DISI) Internet-Drafts, which are all specific to the X.500 protocol, and for the maintenance of FYI 11, ``A catalog of available X.500 implementations''. IDS will need to liase 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. Goals and Milestones: Ongoing Track emerging directory service protocols to specify standards for interoperation with existing protocols. Ongoing Liase with groups working on deployment and development of directory services to locate and fix interoperability problems. Ongoing Identify unfilled needs of directory service offerers, administrators, and users. Mar 93 Submit to the IESG the DISI ``Advanced Usages of X.500'' paper as an informational document. Mar 93 Submit to the IESG the DISI ``X.500 Pilot Project Catalog'' paper as an informational document. Mar 93 Submit to the IESG the 1993 revision of FYI 11, ``A catalog of available X.500 implementations'' as an informational document. Mar 93 Submit as an Internet-Draft a ``Specifications for interoperability between WHOIS++ and X.500''. Jul 93 Submit as an Internet-Draft a ``Guide to administering a directory service'', which covers data integrity, maintenance, privacy and legal issues, and security. Jul 93 Submit as an Internet-Draft a ``Catalog of available WHOIS++ implementations''. Nov 93 Submit to the IESG the ``Specifications for interoperability between WHOIS++ and X.500'' as a standards document. Nov 93 Submit as an Internet-Draft a ``User's guide to directory services on the Internet''. Mar 94 Submit to the IESG the ``Guide to administering a directory service'' as an informational document. Mar 94 Submit to the IESG the 1994 revision of FYI 11. Mar 94 Submit to the IESG the ``Catalog of available WHOIS++ implementations'' as an informational document. Integration of Internet Information Resources (iiir) Charter Chair(s): Chris Weider User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:iiir@merit.edu To Subscribe: iiir-request@merit.edu Archive: merit.edu:~/pub/iiir-archive Description of Working Group: The Integration of Internet Information Resources Working Group (IIIR) is chartered to facilitate interoperability between Internet Information Services, and to develop, specify, and align protocols designed to integrate the plethora of Internet information services (WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified information service'' (VUIS). Such protocols would include (but are not limited to) update protocols for distributed servers, a `query routing protocol' to pass queries between existing services, protocols for gateways between existing and future services, and standard exchange formats (perhaps based on Z39.50) for cross-listing specific information. Also, where necessary, IIIR will create technical documentation for protocols used for information services in the Internet. Goals and Milestones: Ongoing Track emerging Internet information services in order to specify technical requirements for their integration into the VUIS. Ongoing Liaise with other groups working on deployment and integration of Internet information services: e.g., The Coalition for Networked Information, RARE Working Group 3, etc. Ongoing Create specifications for interoperability between Internet information systems. Mar 93 Post an Internet Draft on 'A vision of integrated information resources'. Mar 93 Post an Internet Draft on 'Taxonomy of Internet Information Services'. Jul 93 Submit final version of 'A vision of integrated information resources' to the IESG as an informational RFC. Jul 93 Submit final version of 'Taxonomy of Internet Information Services' to the IESG as an informational RFC. Nov 93 Post an Internet-Draft defining common exchange formats. Nov 93 Post an Internet Draft defining a Query Routing Protocol. Mar 94 Submit final version of common exchange format to the IESG as a Proposed Standard. Jul 94 Submit final version of Query Routing Protocol to the IESG as a Proposed Standard. IP Address Encapsulation (ipae) Charter Chair(s): Dave Crocker Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:ip-encaps@sunroof.eng.sun.com To Subscribe: ip-encaps-request@sunroof.eng.sun.com Archive: parcftp.xerox.com:~/pub/ip-encaps/ Description of Working Group: The IPAE Working Group seeks to develop a capability for extending IP to support larger addresses while minimizing impact on the installed base of IP users. An enhancement to the current system is mandatory due to the limitations of the current 32 bit IP addresses. IPAE seeks to upgrade the current system, rather than to replace the Internet Protocol. The approach taken will be to sandwhich a small addressing layer, above IP but below TCP or UDP, with the new layer having its own IP Protocol-ID. This special layer will thereby encapsulate new, larger, globally-unique addresses for source and destination, as well as any other fields of information that are considered essential. The specificaton effort will attend to issues of transition and coexistance, among unmodified ``IP'' hosts and hosts which support ``IPAE'' hosts The IPAE approach will develop a framework to organize the Internet into areas called ``IP Addressing Commonwealths'' within which 32-bit IP addresses are unique and are part of a larger, globally-unique Internet addressing scheme. It is a goal of this effort to avoid requiring any router within a Commonwealth to be modified, but any host wishing full Internet connectivity will need to support IPAE eventually. Further, any system wishing to support full IPAE addresses will need to be modified, including network management software. Goals and Milestones: Done Review and approve the Charter at the first Working Group meeting. Done Post the initial IPAE specification as an Internet-Draft. Aug 92 Post the initial ``Addressing'' specification as an Internet-Draft. Sep 92 Post the ``Implementation and Transition'' specification as an Internet-Draft. Done Post the report to the IESG as an Internet-Draft. Done Present work of the IPAE Working Group to the IETF. IP Authentication (ipauth) Charter Chair(s): Jeffrey Schiller Security Area Director(s) Steve Crocker Mailing lists: General Discussion:awg@bitsy.mit.edu To Subscribe: awg-request@bitsy.mit.edu Archive: Status: concluded Description of Working Group: To brainstorm issues related to providing for the security and integrity of information on the Internet, with emphasis on those protocols used to operate and control the network. To propose open standard solutions to problems in network authentication. Goals and Milestones: RFC specifying an authentication format which supports multiple authentication systems. Document discussing the cost/benefit tradeoffs of various generic approaches to solving the authentication problem in the Internet context. Document to act as a protocol designers guide to authentication. RFC proposing A Key Distribution System (emphasis on ``A'' as opposed to ``THE''). MIT's Kerberos seems the most likely candidate here. Internet-Drafts: No Current Internet drafts. RFC's: None to date. OSI IDRP for IP over IP (ipidrp) Charter Chair(s): Sue Hares Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:idrp-for-ip@merit.edu To Subscribe: idrp-for-ip-request@merit.edu Archive: merit.edu:~/pub/archive/idrp Description of Working Group: The IDRP for IP over IP Working Group is chartered to standardize and promote the use of IDRP (ISO Inter-Domain Routing Protocol) as a scalable inter- autonomous system routing protocol capable of supporting Policy Based Routing for TCP/IP internets. The objective is to take IDRP, as it is defined by ISO standards, and to define backward compatible extensions and/or network adaptation layers to enable this protocol to be used in the TCP/IP internets. If any ISO standardization efforts overlap this area of work, it is intended that the ISO work will supersede the standards proposed by this Group. 1) IDRP for IP over IP document (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 IP packets across multiple autonomous systems. 2) IDRP MIB document (standards track) This document contains the MIB Definitions for IDRP. These MIB Definitions are done in two parts; IDRP General MIB, and IDRP for IP MIB. An appendix is planned; IDRP For IP GDMO 3) IDRP - OSPF Interactions (standards track) This document will specify the interactions between IDRP and OSPF. This document will be based on a combination of BGP-OSPF interactions document and IDRP - ISIS interaction document. 4) IDRP for IP Usage document (standards track) Most of the IDRP for IP Usage will reference the CIDR (Supernetting document) Internet Draft. Any additional terms or protocol definitions needed for IDRP for IP will also be specified here. Goals and Milestones: Done IDRP for IP submitted for Internet-Draft. Jun 92 IDRP MIB document submitted for Internet-Draft. Jun 92 IDRP - OSPF Interactions document submitted for Internet-Draft. Jun 92 IDRP Usage document submitted for Internet-Draft. Nov 92 IDRP for IP submitted to the IESG for Proposed Standard. Nov 92 IDRP Usage document submitted to the IESG for Proposed Standard. Nov 92 IDPR MIB Submitted to the IESG for Proposed Standard. Nov 92 IDRP - OSPF Interactions document submitted to the IESG for Proposed Standard. IP OSI Mutual Encapsulation (ipiso) Charter Chair(s): Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion: To Subscribe: Archive: Status: proposed Description of Working Group: No description available Goals and Milestones: Internet-Drafts: No Current Internet drafts. RFC's: None to date. IP over Large Public Data Networks (iplpdn) Charter Chair(s): George Clapp Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:iplpdn@nri.reston.va.us To Subscribe: iplpdn-request@nri.reston.va.us Archive: cnri.reston.va.us:~/ietf.mail.archives/iplpdn/* Description of Working Group: The IP over Large Public Data Networks Working Group will specify the operation of the TCP/IP protocol suite over Public Data Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay. The Working Group will develop and define algorithms for the resolution of IP addresses and for the routing of IP datagrams over large, potentially global, public data networks. The IP over SMDS Working Group has defined the operation of the Internet protocols when SMDS is used to support relatively small virtual private networks, or Logical IP Subnets (LISs). Issues arising from public and global connectivity were delegated to the IPLPDN Working Group. The IPLPDN Working Group will also continue the work of the Private Data Network Routing Working Group (PDNROUT) on X.25 PDNs. This work will be extended to include call management and the use of the ISDN B channels for the transport of IP datagrams. Address resolution and routing over Frame Relay will also be discussed. Goals and Milestones: Address resolution of Internet addresses to SMDS E.164 addresses, to ISDN E.164 addresses, to X.121 addresses, and to Frame Relay Data Link Connection Identifiers (DLCIs). The algorithm(s) may be defined in either a single or in multiple documents. Routing of IP datagrams across very large internets implemented SMDS and on other PDNs. Management of ISDN and of X.25 connections and the use of the ISDN B and D channels. Done Establish priorities and dates of completion for documents. Internet Protocol Security Protocol (ipsec) Charter Chair(s): Al Hoover Paul Lambert Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ipsec@ans.net To Subscribe: ipsec-request@ans.net Archive: ftp.ans.net:~/pub/archive/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 Security Protocol (IPSP) 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 key management will be specified as an application layer protocol that is independent of the lower layer security protocol. The protocol will initially support public key based techniques. Flexibility in the protocol will allow eventual support of Key Distribution Center (KDC - such as Kerberos) and manual distribution approaches. Goals and Milestones: Mar 93 Post as an Internet-Draft the IP Security Protocol. Jul 93 Post as an Interenet-Draft the specification for Internet Key Management. Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update Protocol as needed. Mar 94 Report on Pilot implementation of the Internet Key Management Protocol. Update Internet-Draft as needed. Jul 94 Submit the IP Security Protocol to the IESG for consideration as a Proposed Standard. Jul 94 Submit the Key Management Protocol to the IESG for consideration as a Proposed Standard. ISIS for IP Internets (isis) Charter Chair(s): Ross Callon Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:isis@merit.edu To Subscribe: isis-request@merit.edu Archive: Description of Working Group: The IETF ISIS Working Group will develop additions to the existing OSI IS-IS Routing Protocol to support IP environments and dual (OSI and IP) environments. Goals and Milestones: Done Liaison with the IS-IS editor for OSI in case any minor changes to IS-IS are necessary. Done Develop an extension to the OSI IS-IS protocols which will allow use of IS-IS to support IP environments, and which will allow use of IS-IS as a single routing protocol to support both IP and OSI in dual environments. Done Post a revision of the IS-IS as an Internet-Draft. Mar 93 Submit the revised IS-IS to the IESG as a Draft Standard. Mar 93 Submit the IS-IS MIB to the IESG as a Proposed Standard. Internet School Networking (isn) Charter Chair(s): John Clement Arthur St. George Connie Stout User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:isn-wg@unmvma.unm.edu To Subscribe: listserv@unmvma.unm.edu body: sub isn-wg Archive: Description of Working Group: The Internet School Networking Working Group is chartered to facilitate the connection of the United States' K-12 (Kindergarten-12th Grade) schools, public and private, to the Internet, and school networking in general. It is critically important that national networking for K-12 education proceed along established lines of protocol, using existing network structures. The Working Group's first priority will be to establish guidelines for specialized user interfaces. K-12 networking will also require other support services, such as directories, online and hotline help, specialized training programs and collaborative projects with instructional and curriculum groups, disciplinary groups and postsecondary institutions. While the initial focus is school networking in the U.S., the Working Group will coordinate its efforts with similar activities in other countries and regions of the world. Goals and Milestones: Done Meet for the first time at IETF and establish approval of Charter. Examine the status of projects in process when Working Group was created. Begin work on list of deliverables. Jan 92 Release X.500 ``K-12 People Directory'' version in collaboration with Merit. Develop plans and milestones for K-12 Resources Directory. Mar 92 First draft of information packet document for computing directors to assist them in connecting K-12 schools. First draft of user interface guideline statement. May 92 Release X.500 K-12 Resource Directory version in collaboration with Merit. Present final draft guideline statement. Internet User Population (iup) Charter Chair(s): Craig Partridge User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:ietf@venera.isi.edu To Subscribe: ietf-request@venera.isi.edu Archive: Status: concluded Description of Working Group: To devise and carry out an experiment to estimate the size of the Internet user population. Goals and Milestones: Done Prepare an article for publication in a networking magazine. Done Write a description of the experimental procedure. Done Write an RFC that gives the results of the experiment. Internet-Drafts: No Current Internet drafts. RFC's: None to date. LAN Manager (lanman) Charter Chair(s): David Perkins Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:lanmanwg@cnd.hp.com To Subscribe: lanmanwg-request@cnd.hp.com Archive: Status: concluded Description of Working Group: This working group is chartered to define and maintain the MIB and relevant related mechanisms needed to allow management of workgroup PCs and servers that are using the Microsoft Lan Manager protocols. These protocols provide file and print service and mechanisms for development of application server-client systems such as ones for mail or SQL database. Goals and Milestones: Define an upwards compatible MIB for LAN Manager version 2.x. Work to influence Microsoft, the developer of LAN Manager, to add/change APIs so that MIB developed can be consistant in style and information content with MIBs developed by other MIB Working Groups. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Automated Internet Mailing List Services (list) Charter Chair(s): David Lippke Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-list-wg@utdallas.edu To Subscribe: ietf-list-wg-request@utdallas.edu Archive: pub/ietf-list-wg@ftp.utdallas.edu Status: concluded Description of Working Group: This Working Group will concern itself with ``list servers'', i.e., advanced mail exploders/reflectors which provide services such as automated subscription, archive maintenance, and coordination with similar systems on the network. The Group will initially focus its activities towards establishing a baseline user interface. Although most current systems support a command set patterned after Eric Thomas' BITNET LISTSERV, there is wide variance in the options supported and in the general patterns of interaction. This results in a great deal of user confusion. The Working Group's interface definition will address this by establishing a set of commands, options, interactions, and procedures which will (hopefully) be supported by all list servers as a subset of their full repertoire. As a part of the user interface work, the Group will also define an authentication service for users' list server transactions. Toward this end, and to address the privacy issue, the Group will consult with the Security Area Advisory Group (SAAG). The second phase of the Group's work will be to provide for the interconnection and coordination of list servers. Experience with the BITNET LISTSERV has shown that it is important for users be able to view the collection of list servers on the network as an integrated whole. Ideally, users should only have to deal with their local mailing list service---which knows where all public lists are, what they are, and is able to act on the user's behalf with respect to them. Interconnecting list servers allows this ``integrated user view'' to be created and also lets issues such as traffic minimization, timely distribution, and load sharing to be more easily addressed. Consequently, the Working Group will define the conceptual models, communication methods, and extensions to prior work which are necessary to bring this interconnection and coordination about. It is anticipated that further work on issues of authentication and privacy will continue in parallel with the ``integration'' effort --- perhaps manifesting itself as a separate RFC which extends the user interface definition produced during the first phase. Goals and Milestones: Submit interconnection/coordination definition document to the IESG for publication as a Proposed Standard. Done Review the Group's Charter and begin work on the user interface definition. Nov 91 Resolve outstanding issues with the user interface definition and prepare document for IESG submission. Begin work to address the interconnection/coordination issue. Jan 92 Submit user interface definition document to IESG as a Proposed Standard. Mar 92 Focus the interconnection/coordination work. Finalize and document settled issues. Internet-Drafts: No Current Internet drafts. RFC's: None to date. MIME-MHS Interworking (mimemhs) Charter Chair(s): Steve Thompson Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:mime-mhs@surfnet.nl To Subscribe: mime-mhs-request@surfnet.nl Archive: Description of Working Group: MIME, (Multipurpose Internet Mail Extensions) is currently a Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. With the introduction of MIME as a Proposed Standard it is now possible to define mappings between RFC-822 content-types and X.400 body parts. The MIME-MHS Interworking Working Group is chartered to develop these mappings, providing an emphasis on both interworking between Internet and MHS mail environments and also on tunneling through these environments. These mappings will be made in the context of an RFC-1148bis environment. Goals and Milestones: Done Post an Internet-Draft describing MIME-MHS Interworking. Done Post an Internet-Draft describing the ``core'' set of Registered conversions for bodyparts. Jul 92 Submit a completed document to the IESG describing MIME-MHS Interworking as a Proposed Standard. Jul 92 Submit the ``core'' bodyparts document to the IESG as a Proposed Standard. Multi-Media Bridging (mmb) Charter Chair(s): Jeffrey Fitzgerald Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:mmbwg@fibercom.com To Subscribe: mmbwg-request@fibercom.com Archive: Status: concluded Description of Working Group: The Multi-Media Bridge Working Group has the task of addressing the function of multi-media bridges within TCP/IP networks. This is viewed as necessary at this time because of the proliferation of these devices. The first goal of the Group is to document the multi-media bridge technology and point out the issues raised by having these devices in a TCP/IP internet. If there are problems which can be addressed the Group will work towards resolving them and documenting the solutions. Goals and Milestones: Done Finalize Charter of Group. Aug 91 Document mulit-media bridging technology and its affect on TCP/IP Internets. Aug 91 Document issues to be addressed by Working Group. Internet-Drafts: No Current Internet drafts. RFC's: None to date. IP Routing for Wireless/Mobile Hosts (mobileip) Charter Chair(s): Steve Deering Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:mobile-ip@parc.xerox.com To Subscribe: mobile-ip-request@parc.xerox.com Archive: parcftp.xerox.com:~/pub/mobile-ip/mail-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. 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). Goals and Milestones: Done Review and approve the Charter, making any changes deemed necessary. Nov 92 Post an Internet-Draft documenting the Mobile Hosts protocol. Mar 93 Review the Charter of the Mobile IP Working Group for additional work required to facilitate non-host mobility. Mar 93 Submit the Mobile Host Protocol to the IESG as a Proposed Standard. Multicast Extensions to OSPF (mospf) Charter Chair(s): Steve Deering Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:mospf@comet.cit.cornell.edu To Subscribe: mospf-request@comet.cit.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). Goals and Milestones: Done Become familiar with the IGMP protocol as documented in RFC 1112. Survey existing work on multicast routing, in particular, Steve Deering's paper ``Multicast Routing in Internetworks and Extended LANs''. Identify areas where OSPF must be extended to support multicast routing. Identify possible points of contention. Done Review outline of proposed changes to OSPF. Identify any unresolved issues and, if possible, resolve them. Done We should have a draft specification. Discuss the specification and make any necessary changes. Discuss implementation methods, using as an example, the existing BSD OSPF code, written by Rob Coltun of the University of Maryland. Done Report on implementations of the new multicast OSPF. Fix any problems in the specification that were found by the implementations. Feb 92 Submit the MOSPF Specification to the IESG as a Proposed Standard. SNMP over a Multi-protocol Internet (mpsnmp) Charter Chair(s): Theodore Brunner Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:snmp-foo@thumper.bellcore.com To Subscribe: snmp-foo-request@thumper.bellcore.com Archive: thumper.bellcore.com:~/pub/snmp-foo/archive Description of Working Group: Within the SNMP management framework, the philosophy is to place the burden of management processing on managers, not on agents. As the Internet evolves to accommodate multiple protocol suites, there may be SNMP agents in the Internet that do not support the recommended method of exchanging SNMP messages using UDP/IP. In these instances, the proper model for managing a multiprotocol internet should be that agents must only be required to support one method of exchanging SNMP messages (i.e., encapsulation of SNMP messages in *one* of the protocol suites of the multi-protocol internet), and the managers support as many encapsulation methods as needed (potentially, all) to communicate with all resources it manages. The SNMP over a Multi-protocol Internet Working Group is chartered to identify and provide solutions for communication between SNMP agents and managers in those configurations where the recommended method of exchanging SNMP messages using UDP/IP cannot be used; i.e., where a managed resource supports a single protocol suite that protocol is not UDP/IP but another protocol suite of the multi-protocol internet (for example, OSI, AppleTalk, or XNS/IPX). Questions to be considered include: What are the appropriate protocol suites to consider? What is the appropriate method of encapsulating SNMP? What are the addressing considerations for SNMP messages What new MIB Modules are required? What (positive) effect can SNMP-based management have on resource-sharing among multiple protocols? Goals and Milestones: Done Post an Internet-Draft describing operation of SNMP over OSI. Done Post an Internet-Draft describing operation of SNMP over IPX. Done Post an Internet-Draft describing operation of SNMP over Appletalk. Done Submit a document describing the operation of SNMP over OSI as a Proposed Standard. Done Submit a document describing the operation of SNMP over IPX as a Proposed Standard. Done Submit a document describing the operation of SNMP over Appletalk as a Proposed Standard. Management Services Interface (msi) Charter Chair(s): Oscar Newkerk Sudhanshu Verma Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:msiwg@decwrl.dec.com To Subscribe: msiwg-request@decwrl.dec.com Archive: Status: concluded Description of Working Group: The objective of the Management Services Interface Working Group is to define a management services interface by which management applications may obtain access to a heterogeneous, multi-vendor, multi-protocol set of manageable objects. The service interface is intended to support management protocols and models defined by industry and international standards bodies. As this is an Internet Engineering Task Force Working Group, the natural focus is on current and future network management protocols and models used in the Internet. However, the interface being defined is expected to be sufficiently flexible and extensible to allow support for other protocols and other classes of manageable objects. The anticipated list of protocols includes Simple Network Management Protocol (SNMP), OSI Common Management Information Protocol (CMIP), CMIP Over TCP (CMOT), Manufacturing Automation Protocol and Technical Office Protocol CMIP (MAP/TOP CMIP) and Remote Procedure Call (RPC). Goals and Milestones: Done Initial version of the Internet Draft placed in the Internet-Drafts directory Done Revised version of the draft from editing meetings placed in the Internet-Drafts directory Aug 90 Initial implementation of the prototype available for test. Done Revised draft based on the implementation experience submitted to the RFC editor. Internet-Drafts: No Current Internet drafts. RFC's: None to date. IP MTU Discovery (mtudisc) Charter Chair(s): Jeff Mogul Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:mtudwg@decwrl.dec.com To Subscribe: mtudwg-request@decwrl.dec.com Archive: Status: dormant Description of Working Group: The MTU Discovery Working Group is chartered to produce an RFC defining an official standard for an IP MTU Discovery Option. ``MTU Discovery'' is a process whereby an end-host discovers the smallest MTU along a path over which it is sending datagrams, with the aim of avoiding fragmentation. Goals and Milestones: Done Decide if the proposal in RFC 1063 is sufficient, or if there are flaws to be corrected, or possible improvements to be made. Or, decide that it is unwise to create an official standard. Ongoing Encourage the participation of gateway implementors, since the MTU discovery process affects the design and performance of IP gateways. Done Encourage sample implementations of end-host and gateway portions of MTU Discovery for popular software (BSD-derived kernels, primarily). Encourage rapid implementation by major gateway vendors, since this option is relatively useless without widespread support. Done Unless the proposal in RFC 1063 is acceptable, write a new RFC describing a different approach. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1191 PS Nov 90 Path MTU Discovery Network Access Server Requirements (nasreq) Charter Chair(s): Allan Rubens John Vollbrecht Security Area Director(s) Steve Crocker Mailing lists: General Discussion:auth-acct@merit.edu To Subscribe: auth-acct-request@merit.edu Archive: Description of Working Group: The Network Access Server Requirements Working Group has as its primary goal, to identify functions and services that should be present in IP Network Access Servers (NAS's) and to specify the standards that provide for these functions and services. The term ``Network Access Server'' is used instead of the more conventional term ``Terminal Server'' as it more accurately describes the functions of interest to this Group. A ``Network Access Server'' is a device that provides for the attachment of both traditional ``dumb terminals'' and terminal emulators as well as workstations, PC's or routers utilizing a serial line framing protocol such as PPP or SLIP. A NAS is viewed as a device that sits on the boundary of an IP network, providing serial line points of attachment to the network. A NAS is not necessarily a separate physical entity; for example, a host system supporting serial line attachments is viewed as providing NAS functionality and should abide by NAS requirements. This Group will adopt (or define, if need be) a set of standard protocols to meet the needs of organizations providing network access. The immediate needs to be addressed by the Group are in the areas of authentication, authorization, and accounting (AAA). In general, this Group will select a set of existing standards as requirements for a NAS. If necessary, the Group will identify areas of need where internet standards don't already exist and new standardization efforts may be required. Initially the Group will independently investigate the two cases of character and frame oriented access to the NAS. This investigation will be aimed at determining what work is being done, or needs to be done, in this and other working groups in order to be able to define the set of NAS requirements. While the ultimate goal of this Group is to produce a NAS Requirements document, it may be necessary to define standards as well. This initial investigation will help determine what the goals of this Group need to be. The Group will also work with appropriate Working Groups to define required NAS standards that fall into the areas of these other groups. Goals and Milestones: Done NAS Requirements Document posted as an Internet-Draft. Nov 92 Post an Internet-Draft on Character oriented Authentication, Authorization, and Accounting(AAA). Nov 92 Post an Internet-Draft on frame oriented AAA requirements. Nov 93 Submit the NAS Requirements document to the IESG as a Proposed Standard. Network Database (netdata) Charter Chair(s): Daisy Shen Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-ndb@ucdavis.edu To Subscribe: ietf-ndb-request@ucdavis.edu Archive: Description of Working Group: The Network Database Working Group is chartered to define a standard interface among databases on TCP/IP networks. The Working Group will address the issue of database connectivity in a distributed environment which allows authorized users remote access to databases. It will be designed as a client/server model based on TCP/IP as its communication protocol. Several problems must be resolved that are associated with the network database protocol, such as management of multiple threads between clients and servers, management of multiple servers, management of data buffers, data conversions, and security. Additional related problems will be covered as the discussion goes on. Therefore, the description and the schedule can be revised. This Working Group is independent from the SQL access group; however, there may be some overlapping interest. The SQL access group is welcome to join IETF's discussions and share information in both directions. If both groups find that merging two efforts into one will speed up the process, the merge can be done in the future. For now, this Working Group works on issues according to its own schedule and efforts. Goals and Milestones: Done Review and approve the Charter, making any changes necessary. Examine needs, resources for this network database protocol and define the scope of work. Begin work on a framework for the solution. Assign writing assignments for first draft of the document. Done First draft to be completed. Done Review first draft document, determine necessary revisions. Discuss problems remained unsolved from the first IETF meeting. Done Continue revisions based on comments received at meeting and e-mail. Start making document an Internet-Draft. Mar 92 Review final draft. If it is OK, give it to IESG for publication as RFC. Jun 92 Revise document based on implementations. Ask IESG to make the revision a Draft Standard. Network Fax (netfax) Charter Chair(s): Mark Needleman Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:netfax@stubbs.ucop.edu To Subscribe: netfax-request@stubbs.ucop.edu Archive: /pub/netfax@stubbs.ucop.edu Status: concluded Description of Working Group: The Network Fax Working Group is chartered to explore issues involved with the transmission and receipt of facsimilies across TCP/IP networks and to develop recommended standards for facsimile transmission across the Internet. The Group is also intended to serve as a coordinating forum for people doing experimentation in this area to attempt to maximize the possibility for interoperability among network fax projects. Among the issues that need to be resolved are what actual protocol(s) will be used to do the actual data transmission between hosts, architectural models for the integration of fax machines into the existing internet, what types of data encoding should be supported, how IP host address to phone number conversion should be done and associated issues of routing, and development of a gateway system that will allow existing Group 3 and Group 4 fax machines to operate in a network environment. It is expected that the output of the Working Group will be one or more RFC's documenting recommended solutions to the above questions and possibly also describing some actual implementations. The life of the Working Group is expected to be 18-24 months. It is also hoped that some fax vendors, as well as the networking community and fax gateway developers, will be brought into the effort. Goals and Milestones: Done Review and approve Charter making any changes deemed necessary. Refine definition of scope of work to be accomplished and initial set of RFC's to be developed. Begin working on framework for solution. Done Continue work on definition of issues and protocols. Work to be conducted on mailing list. Done First draft of RFC to be completed. To be discussed at IETF meeting and revised as necessary. Done Continue revisions based on comments received and submit to IESG for publication as RFC. Mar 92 Overlapping with activities listed above may be implementations based on ideas and work done by the Working Group. If so revise RFC to include knowledge gained from such implementations. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1314 PS Apr 92 A File Format for the Exchange of Images in the Internet Networked Information Retrieval (nir) Charter Chair(s): Jill Foster George Brett User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:nir@cc.mcgill.ca To Subscribe: nir-request@cc.mcgill.ca Archive: archives.cc.mcgill.ca:~/pub/mailing-lists/nir Description of Working Group: As the network has grown, along with it there has been an increase in the number of software tools and applications to navigate the network and make use of the many, varied resources which are part of the network. Within the past year and a half we have seen a wide spread adoption of tools such as the ARCHIE servers, the Wide Area Information Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW). In addition to the acceptance of these tools there are also diverse efforts to enhance and customize these tools to meet the needs of particular network communities. There are many organizations and associations that have recently begun to focus on the proliferating resources and tools for networked information retrieval (NIR). The Networked Information Retrieval Group will be a cooperative effort of three major players in the field of NIR: IETF, RARE, and the Coalition for Networked Information (CNI) specifically tasked to collect and disseminate information about the tools and to discuss and encourage cooperative development of current and future tools. The NIR Working Group intends to increase the useful base of information about networked information retrieval (NIR) tools, their developers, interested organizations, and other activities that relate to the production, dissemination, and support of NIR tools, to produce documentation that will enable user services organizations to provide better support for NIRtools, to develop materials that will assist the support and training of end users and to evolve in the future as necessary to meet and anticipate changes in the field (i.e., NIR tools, protocols, network topology, etc.) Goals and Milestones: Done Review and comment on proposed charter. Discuss Applications Template and Organizational Template. Sep 92 Post an Internet-Draft containing the Applications and Organizational Templates. Oct 92 Post an Internet-Draft of the ``Consumer Report'' with introductory material and completed templates. Dec 92 Submit ``Consumer Report'' to the IESG for publication as an Informational RFC. Network Information Services Infrastructure (nisi) Charter Chair(s): April Marine Pat Smith User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:nisi@merit.edu To Subscribe: nisi-request@merit.edu Archive: Description of Working Group: The NISI Working Group will explore the requirements for common, shared Internet-wide network information services. The goal is to develop an understanding for what is required to implement an information services ``infrastructure'' for the Internet. The work will begin with existing NIC functions and services and should build upon work already being done within the Internet community. It should address areas such as common information formats, methods of access, user interface, and issues relating to security and privacy of Internet databases. Goals and Milestones: Done Complete draft for phase 2 suggesting cooperative agreements for NICs. Done Review draft for phase 1 and begin discussions for completing the second phase which is to define a basic set of `cooperative agreements' which will allow NICs to work together more effectively to serve users. Done Revised draft document ready for Working Group review. Document defines NIC functions and suggests some standardizations for NIC services, as well as offers new mechanisms for exchanging information between NICs. Done Document submitted as Internet-Draft for comment from a wider Internet audience. Done Working Group discussed current Internet-Draft and suggested minor revisions. Decision made to continue Working Group activity beyond this document. Done First document released as informational RFC. Outline and discuss new NISI tasks at IETF meeting. Done Write a document explaining the security issues of privacy and accuracy in Internet databases. Publish as an informational RFC. Network Joint Management (njm) Charter Chair(s): Gene Hastings Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:njm@merit.edu To Subscribe: njm-request@merit.edu Archive: Description of Working Group: There is a need for many different kinds of efforts to deal with operational and front line engineering issues, including helping the disparate organizations work with each other. This is an attempt to solidify some of those topics. This does not make any pretense of being exhaustive. Area of interest: Operational issues and developments of the Internet. Membership: Operations and engineering personnel from national backbone and mid-level networks. Other groups with responsibility for production oriented services such as security oriented groups. Associated Technical groups: Groups which will have an interest in, and input to the Agenda of this Group will include the IAB and its task forces, and groups within FARNET. In particular FARNET has now several technical issues of concern, such as the selection of standard inter-network services for debugging (like maps and standard SNMP communities), and the specification of standard network statistics to be taken (of special concern is the ubiquitous ability to collect those statistics). Meeting Times: Members of the Group will represent organizations with production responsiblities. Most work will be carried on via email or teleconferencing. Goals and Milestones: Network News Transport Protocol (nntp) Charter Chair(s): Eliot Lear Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-nntp@turbo.bio.net To Subscribe: ietf-nntp-request@turbo.bio.net Archive: Description of Working Group: This Group will study and review the issues involved with netnews transport over the Internet. Originally released as an RFC in February of 1986, NNTP is one of the widest implementations of an elective status protocol. As of this writing, the protocol has just passed its fifth birthday, not having been updated once. Over the years several enhancements have been suggested, and several have even been implemented widely. The intent of this Working Group will be to encode the more popular and plausible enhancements into an Internet standard. Included in the initial list of changes to be considered are the following: (1) User level and site designated authentication methods; (2) Binary transfer capability; (3) Minimization of line turnaround; and (4) Stronger article selection capability. It is expected that public domain software will be released concurrently with an RFC, demonstrating the protocol enhancements. Goals and Milestones: Done Define scope of work. Done Submit Internet-Draft for review and comment. Done Possibly meet at USENIX for further comment. Done Meet at IETF for further comment. Aug 91 Submit RFC to IESG. NOC-Tool Catalogue Revisions (noctool2) Charter Chair(s): Robert Enger Darren Kinley User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:noctools@merit.edu To Subscribe: noctools-request@merit.edu Archive: Description of Working Group: The NOC-Tools Working Group will update and revise their catalog to assist network managers in the selection and acquisition of diagnostic and analytic tools for TCP/IP Internets. - Update and revise the reference document that lists what tools are available, what they do, and where they can be obtained. - Identify additional tools available to assist network managers in debugging and maintaining their networks that were inadvertently omitted in previous NOCTools catalog. - Identify additional new or improved tools that have become apparent since the last compilation of the reference document. - Arrange for the central (or multi-point) archiving of these tools in order to increase their availability. - Establish procedures to ensure the ongoing maintenance of the reference and the archive, and identify an organization willing to do it. Goals and Milestones: Done Review Internet tool needs and updates/corrections for the ``Son of NOCTools'' catalog. Discussion of additional input to the catalog. Done Draft of catalog will be prepared, draft to be reviewed and modified. Initiate IETF Internet-Draft review process by submission of a ``Son of NOCTools'' catalog draft to IESG Secretary. Done Follow-up with final amendments to the document and the submission of the catalog to RFC Editor as an FYI RFC for publication. NOC-Tools (noctools) Charter Chair(s): Robert Enger User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:noctools@merit.edu To Subscribe: noctools-request@merit.edu Archive: Status: concluded Description of Working Group: The NOC-Tools Working Group will develop a catalog to assist network managers in the selection and acquisition of diagnostic and analytic tools for TCP/IP Internets. Goals and Milestones: Identify tools available to assist network managers in debugging and maintaining their networks. Publish a reference document listing what tools are available, what they do, and where they can be obtained. Arrange for the central (or multi-point) archiving of these tools in order to increase their availability. Establish procedures to ensure the ongoing maintenance of the reference and the archive, and identify an organization willing to do it. Identify the need for new or improved tools as may become apparent during the compilation of the reference document. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1147 Apr 90 FYI on a Network Management Tool Catalog: Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices Network OSI Operations (noop) Charter Chair(s): Susan Hares Cathy Wittbrodt Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:noop@merit.edu To Subscribe: noop-request@merit.edu Archive: merit.edu:~/pub/noop-archive Description of Working Group: The Working Group is chartered to work on issues related to the deployment of CLNP in the Internet. The first area of this Group's work has been the learning necessary to start deploying OSI in internet networks. This phase includes planning for OSI deployment by creating routing plans for regional networks and education on using OSI routing protocols. This first area of the Group's work will be on-going as we continue to deploy OSI in the Internet. This step has lead to people deploying OSI for Pilot projects and demonstrations of OSI. The second step of deploying OSI will be the transition of OSI from a pilot service to a production service. During this phase we will work on specifying the network debugging tools and test beds. We will need to track the level of OSI support in the Internet. We will need to provide documentation for new users of OSI on the Internet. Goals and Milestones: Ongoing Provide a forum to discuss OSI routing plans by email or in group discussions. Jan 92 Post as an Internet-Draft, a tutorial for CLNP OSI routing protocols, including ES-IS, CLNP, IS-IS, and IDRP. Apr 92 Post as an Internet-Draft, a requirements document specifying what OSI network tools are needed on every host and router. Jul 92 Post as an Internet-Draft, a collection of regional Routing and Addressing plans. Done Post as an Internet-Draft, a list of OSI Network Utilities available in the public domain and from vendors. This list will be passed over to the NOC tools Group effort for joint publication. Jul 92 Post as an Internet-Draft, a description of OSI network layer debugging methods. Done Post as an Internet-Draft, a list of OSI Network Layer NOC tools available in the public domain and from vendors. This list will be passed over to the NOC tools Group effort for joint publication. Jul 92 Submit to the IESG for Proposed Standard, a requirements document specifying what network tools are needed on every OSI host and router. Aug 92 Submit to the IESG as an Informational RFC, a description of OSI network layer debugging methods. Network Printing Protocol (npp) Charter Chair(s): Glenn Trewitt Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:print-wg@pa.dec.com To Subscribe: print-wg-request@pa.dec.com Archive: Description of Working Group: The Network Printing Working Group has the goal of pursuing those issues which will facilitate the use of printers in an internetworking environment. In pursuit of this goal it is expected that we will present one or more printing protocols to be considered as standards in the Internet community. This Working Group has a number of specific objectives. To provide a draft RFC which will describe the LPR protocol. To describe printing specific issues on topics currently under discussion within other Working Groups (e.g., Security and Dynamic Host Configuration), to present our concerns to those Working Groups, and to examine printing protocols which exist or are currently under development and assess their applicability to Internet-wide use, suggesting changes if necessary. Goals and Milestones: Done Review and approve the Charter, making any changes deemed necessary. Review the problems of printing in the Internet. Done Write draft LPR specification. Done Discuss and review the draft LPR specification. Discuss long-range printing issues in the Internet. Review status of Palladium print system at Project Athena. Done Submit final LPR specification including changes suggested at the May IETF. Discuss document on mailing list. Done Submit LPR specification as an RFC and standard. Jul 90 Write description of the Palladium printing protocol (2.0) in RFC format. Aug 90 Discuss and review the draft Palladium RFC. Office Document Architecture (oda) Charter Chair(s): Peter Kirstein Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-osi-oda@cs.ucl.ac.uk To Subscribe: ietf-osi-oda-request@cs.ucl.ac.uk Archive: Description of Working Group: The ODA Working Group will develop guidelines for the use of the Office Document Architecture for the exchange of Compound documents including formattable text, bit-map graphics and geometric graphics according to the ODA Standard. It will consider also Intercept Standards for other document content types it considers vital - e.g., spreadsheets. The Working Group will define how to use both SMTP and X.400 for interchange of ODA documents. It will maintain close liaison with the SMTP and X.400 Working Groups. This Working Group will review the availability of ODA implementations, in order to mount a Pilot Testbed for processable compound document interchange. Finally, it will set up and evaluate such a testbed. Goals and Milestones: Ongoing Coordinate ODA Pilot. Ongoing Review and propose additional enhancements of ODA. Done Inaugural meeting. Done Produce a paper stating what ODA standards or profiles still need completing. Done Produce paper on what pilot implementations can be provided. Jul 91 Produce paper on what scale and type of Pilot Testbed should be organised. Jun 92 Provide first feedback on the ODA Pilot. OSI Internet Management (oim) Charter Chair(s): Lee LaBarre Brian Handspicker Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:oim@mbunix.mitre.org To Subscribe: oim-request@mbunix.mitre.org Archive: Status: concluded Description of Working Group: This Working Group will specify management information and protocols necessary to manage IP-based and OSI-based LANs and WANs in the Internet based on OSI Management standards and drafts, NIST Implementors Agreements and NMF Recommendations. It will also provide input to ANSI, ISO, NIST and NMF based on experience in the Internet, and thereby influence the final form of OSI International Standards on management. Goals and Milestones: Develop implementors agreements for implementation of CMIP over TCP and CMIP over OSI. Develop extensions to common IETF SMI to satisfy requirements for management of the Internet using OSI management models and protocols. Develop extensions to common IETF MIB-II to satisfy requirements for management of the Internet using OSI management models and protocols. Develop prototype implementations based on protocol implementors agreements, IETF OIM Extended SMI and Extended MIB. Promote development of products based on OIM agreements. Provide input to the ANSI, ISO, NIST and NMF to influence development of OSI standards and implementors agreements. Completion of the following drafts: Implementors Agreements, Event Management, SMI Extensions, MIB Extensions, OSI Management Overview, Guidelines for the Definition of Internet Managed Objects. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1095 DS Apr 89 Common Management Information Services and Protocol over TCP/IP CMOT RFC1214 PS Apr 91 OSI Internet Management: Management Information Base Operational Statistics (opstat) Charter Chair(s): Bernhard Stockman Phillip Gross Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:oswg-l@wugate.wustl.edu To Subscribe: oswg-l-request@wugate.wustl.edu Archive: Description of Working Group: Today there exist a variety of network management tools for the collection and presentation of network statistical data. Different kinds of measurements and presentation techniques makes it hard to compare data between networks. There exists a need to compare these statistical data on a uniform basis to facilitate cooperative management, ease problem isolation and network planning. The Working Group will try to define a model for network statistics, a minimal set of common metrics, tools for gathering statistical data, a common statistical database storage format and common presentation formats. Collecting tools will store data in a given format later to be retrieved by presentation tools displaying the data in a predefined way. Goals and Milestones: Done Agreement on a model. Done Survey for most useful and popular metrics. Done Survey for most useful and popular presentation formats. Dec 90 Identify similar efforts being performed by other groups. Done Define a common minimal set of metrics. Mar 91 Propose a MIB for metrics not already there. Done Define a common storage format to facilitate data sharing. Done Define common presentation formats to make data comparable. Mar 91 Develop outline, and make writing assignments for paper (Opstat1) documenting March 1991 milestones. May 91 Complete paper Opstat1. May 91 Possible mid-term meeting to review Opstat1. May 91 Submit Opstat1 as Internet-Draft. Jul 91 Approve paper Opstat1 for submission as RFC; decide standards-track or Informational? Jul 91 Define a new collection of tools based on defined metrics, defined storage formats and defined presentation formats. Jul 91 Propose old tools to be retrofitted. Jul 91 Develop outline and make writing assignments for paper (Opstat2) on new tools and retrofitted tools. Sep 91 Complete paper Opstat2. Sep 91 Possible mid-term meeting to review Opstat2. Sep 91 Submit Opstat2 as Internet-Draft. Dec 91 Approve paper Opstat2 for submission as RFC; decide standards-track or Informational? Operational Requirements Area Directorate (orad) Charter Chair(s): Bernhard Stockman Philip Gross Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:orad@sdsc.edu To Subscribe: orad-request@sdsc.edu Archive: Description of Working Group: No description available Goals and Milestones: OSI Directory Services (osids) Charter Chair(s): Steve Hardcastle-Kille Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-osi-ds@cs.ucl.ac.uk To Subscribe: ietf-osi-ds-request@cs.ucl.ac.uk Archive: Description of Working Group: The OSI-DS Group works on issues relating to building an OSI Directory Service using X.500 and its deployment on the Internet. Whilst this Group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. Goals and Milestones: Ongoing Maintain a Schema for the OSI Directory on the Internet. Ongoing Liaisons should be established as appropriate. In particular: RARE WG3, NIST, CCITT/ISO IEC, North American Directory Forum. Done Definition of a Technical Framework for Provision of a Directory Infrastructure on the Internet, using X.500. This task may later be broken into subtasks. A series of RFCs will be produced. Done Study the relationship of the OSI Directory to the Domain Name Service. OSI General (osigen) Charter Chair(s): Robert Hagens Ross Callon OSI Integration Area Director(s) <> Mailing lists: General Discussion:ietf-osi@cs.wisc.edu To Subscribe: ietf-osi-request@cs.wisc.edu Archive: janeb.cs.wisc.edu:/pub/archives/ietf-osi Status: concluded Description of Working Group: Help facilitate the incorporation of the OSI protocol suite into the Internet, to operate in parallel with the TCP/IP protocol suite. Facilitate the co-existence and interoperability of the TCP/IP and OSI protocol suites. Goals and Milestones: Done Specify an addressing format (from those available from the OSI NSAP addressing structure) for use in the Internet. Coordinate addressing format with GOSIP version 2 and possibly other groups. Review the OSI protocol mechanisms proposed for the upcoming Berkeley release 4.4. Coordinate efforts with Berkeley. Review GOSIP. Open liaison with Government OSI Users Group (GOSIUG) for feedback of issues and concerns that we may discover. Determine what should be used short-term for (i) intra-domain routing; and (ii) inter-domain routing. For interoperability between OSI end systems and TCP/IP end systems, there will need to be application layer gateways. Determine if there are any outstanding issues here. Review short-term issues involved in adding OSI gateways to the Internet. Preferably, this should allow OSI and/or dual gateways to be present by the time that Berkeley release 4.4 comes out. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1139 PS Jan 90 Echo function for ISO 8473 Assignment of OSI NSAP Addresses (osinsap) Charter Chair(s): Richard Colella OSI Integration Area Director(s) <> Mailing lists: General Discussion:ietf-osi-nsap@osi3.ncsl.nist.gov To Subscribe: ietf-osi-nsap-request@osi3.ncsl.nist.gov Archive: Status: concluded Description of Working Group: The OSI NSAP Guidelines Working Group will develop guidelines for NSAP assignment and administration (AKA, the care and feeding of your NSAPs). Assuming use of existing NSAP address standards, there are two questions facing an administration: \begin{itemize} \item Do I want to be an administrative authority for allocating NSAPs? \begin{itemize} \item how do I become an administrative authority? \begin{itemize} \item what organizations should expect to be an ``administrative authority'' in the GOSIP version 2.0 address structure? \item where do I go to become an administrative authority? \end{itemize} \item what are the administrative responsibilities involved? \begin{itemize} \item defining and implementing assignment procedures? \item maintaining the register of NSAP assignments. \item what are the advantages/disadvantages of being an administrative authority? \end{itemize} \end{itemize} \item Whether NSAPS are allocated from my own or some other administrative authority, what are the technical implications of allocating the substructure of NSAPs? \begin{itemize} \item what should be routing domains? \begin{itemize} \item implications of being a separate routing domain (how it will affect routes, optimality of routes, firewalls and information hiding). \item organizing routing domains by geography versus by organization versus by network topology.... \end{itemize} \item within any routing domain, how should areas be configured? \begin{itemize} \item (same implications as above). \end{itemize} \end{itemize} \end{itemize} Goals and Milestones: Done Have the paper published as an RFC. Done Produce a paper describing guidelines for the acquisition and administration of NSAP addresses in the Internet. Dec 90 Have the paper incorporated, in whole or in part, into the ``GOSIP User Guide'' and the FNC OSI Planning Group document. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1237 PS Jul 91 Guidelines for OSI NSAP Allocation in the Internet OSI X.400 (osix400) Charter Chair(s): Rob Hagens OSI Integration Area Director(s) <> Mailing lists: General Discussion:ietf-osi-x400@cs.wisc.edu To Subscribe: ietf-osi-x400-request@cs.wisc.edu Archive: janeb.cs.wisc.edu:/pub/archives/ietf-osi-x400 Status: concluded Description of Working Group: The IETF OSI X.400 Working Group is chartered to identify and provide solutions for problems encountered when operating X.400 in a dual protocol internet. This Charter includes pure X.400 operational issues as well as X.400 $<$-$>$ RFC 822 gateway (ala RFC 987) issues. Goals and Milestones: Jul 90 Develop a scheme to alleviate the need for static RFC 987 mapping tables. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Open Shortest Path First IGP (ospf) Charter Chair(s): Mike Petry John Moy Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:ospfigp@trantor.umd.edu To Subscribe: ospfigp-request@trantor.umd.edu Archive: 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. Goals and Milestones: Done Design the routing protocol, and write its specification. Done Develop multiple implementations, and test against each other. Done Obtain performance data for the protocol. Done Make changes to the specification (if necessary) and publish the protocol as a Draft Standard RFC. Gather operational experience with the OSPF protocol and submit the document as a Standard. Private Data Network Routing (pdnrout) Charter Chair(s): CH Rokitansky Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:pdn-wg@bbn.com To Subscribe: pdn-request@bbn.com Archive: Status: concluded Description of Working Group: The DoD INTERNET TCP/IP protocol suite has developed into a de facto industry standard for heterogenous packet switching computer networks. In the US, several hundreds of INTERNET networks are connected together; however the situation is completely different in Europe. \vspace{.15in} The only network which could be used as a backbone to allow interoperation between the many local area networks in Europe, now subscribing to the DoD INTERNET TCP/IP protocol suite, would be the system of Public Data Networks (PDN). However, so far, no algorithms have been provided to dynamically route INTERNET datagrams through X.25 public data networks. Therefore, the goals of the Public Data Network Routing Working Group are the development, definition and specification of required routing and gateway algorithms for an improved routing of INTERNET datagrams through the system of X.25 Public Data Networks (PDN) to allow worldwide interoperation between TCP/IP networks in various countries. In addition, the application and/or modification of the developed algorithms to interconnect local TCP/IP networks via ISDN (Integrated Services Digital Network) will be considered. Goals and Milestones: Done Application of the INTERNET Cluster Addressing Scheme to Public Data Networks. Done Development of hierarchical VAN-gateway algorithms for worldwide INTERNET network reachability information exchange between VAN-gateways. Done Assignment of INTERNET/PDN-cluster network numbers to national public data networks. (Mapping between INTERNET network numbers and X.121 Data Network Identification Codes (DNICs)). Done Assignment of INTERNET/PDN-cluster addresses to PDN-hosts and VAN-gateways according to the developed hierarchical VAN-gateway algorithms. Done Definition of the PDN-cluster addressing scheme as an Internet standard. Done Delayed TCP/IP header compression by VAN-gateways and PDN-hosts. Done Provide a testbed for worldwide interoperability between local TCP/IP networks via the system of X.25 public data networks (PDN). Done Implementation of the required algorithms and protocols in a VAN-Box. Done Interoperability between ISO/OSI hosts on TCP/IP networks through PDN. Done Consideration of INTERNET Route Servers. Done Interoperability between local TCP/IP networks via ISDN. Done Development of Internetwork Management Protocols for worldwide cooperation and coordination of network control and network information centers. Done Specification of an X.121 Address resolution protocol. Done Specification of an X.25 Call Setup and Charging Determination Protocol. Done Specification of an X.25 Access and Forwarding Control Scheme. Done Specification of routing metrics taking X.25 charges into account. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Privacy-Enhanced Electronic Mail (pem) Charter Chair(s): Stephen Kent Security Area Director(s) Steve Crocker Mailing lists: General Discussion:pem-dev@tis.com To Subscribe: pem-dev-request@tis.com Archive: pem-dev-request@tis.com Description of Working Group: PEM is the outgrowth of work by the Privacy and Security Research Group (PSRG) of the IRTF. At the heart of PEM is a set of procedures for transforming RFC 822 messages in such a fashion as to provide integrity, data origin authenticity, and optionally, confidentiality. PEM may be employed with either symmetric or asymmetric cryptographic key distribution mechanisms. Because the asymmetric (public-key) mechanisms are better suited to the large scale, heterogeneously administered environment characteristic of the Internet, to date only those mechanisms have been standardized. The standard form adopted by PEM is largely a profile of the CCITT X.509 (Directory Authentication Framework) recommendation. PEM is defined by a series of documents. The first in the series defines the message processing procedures. The second defines the public-key certification system adopted for use with PEM. The third provides definitions and identifiers for various algorithms used by PEM. The fourth defines message formats and conventions for user registration, Certificate Revocation List (CRL) distribution, etc. (The first three of these were previously issued as RFCs 1113, 1114 and 1115. All documents have been revised and are being issed first as Internet Drafts.) Goals and Milestones: Done Submit first, third, and fourth documents as Internet-Drafts. Ongoing Revise Proposed Standards and submit to IESG for consideration as Draft Standard, and repeat for consideration as Internet Standard. Done Submit second document as Internet-Draft. Done First IETF Working Group meeting to review Internet-Drafts. Done Submit revised Internet-Drafts based on comments received during Working Group meeting, from pem-dev mailing list, etc. Done Submit Internet-Drafts to IESG for consideration as Proposed Standards. Done Post an Internet Draft of the MIME/PEM Interaction specification. Apr 93 Submit the PEM/MIME Specification to the IESG for consideration as a Proposed Standard. P. Internet Protocol (pip) Charter Chair(s): Paul Tsuchiya Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:pip@thumper.bellcore.com To Subscribe: pip-request@thumper.bellcore.com Archive: thumper.bellcore.com:~/pub/tsuchiya/pip-archive Description of Working Group: The PIP Working Group is chartered to develop an IPv7 proposal using the basic ideas of Pip as described in the Pip overview. Pip is designed on one hand to be very general, being able to handle many routing/addressing/flow paradigms, but on the other hand to allow for relatively fast forwarding. Pip has the potential to allow for better evolution of the internet. In particular, it is hoped that we will be able to advance routing, addressing, and flow techniques without necessarily having to change hosts (once hosts are running Pip). While the Pip overview demonstrates a number of powerful mechanisms, much work remains to be done to bring Pip to a full specification. This work includes, but is not limited to: specifying the header format; specifying a basic set of error messages (PCMP messages); specifying the Pip forwarding rules; specifying host interface messages (particularly the directory service query response); specifying rules for host Pip header construction; specifying modifications to existing protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying Pip MAX MTU Discovery techniques; and specifying a transition strategy for Pip. Over the near-term, the goal of the PIP Working Group will be to produce these specifications and supporting documentation. Over the long-term, up to the point where Pip is definitively rejected as IPv7, it is expected that the PIP Working Group will oversee implementations and testing of the Pip specifications. Except to the extent that the PIP Working Group modifies existing protocols for operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the PIP Working Group will not work on routing/addresing/flow architectures. Goals and Milestones: Done Review and approval of the Charter for the PIP Working Group. Done Post as an Internet-Draft a description of the Pip Packet Format and Forwarding Engine, the Pip Control Message Protocol (PCMP), the Pip Host Interface Message Protocol, and the Pip MTU Discovery Protocol. Oct 92 Post as an Internet-Draft a description of the modifications to BGP IV for Pip, the Modifications to OSPF for Pip, the modifications to DNS for Pip, the modifications to ARP for Pip, the Address assignment in Pip, and the Pip transition strategy. Done Presentation and review of the PIP specification by the IESG. If acceptable, the first Working Group meeting will be held. Process for Organization of Internet Standards (poised) Charter Chair(s): Steve Crocker Not Assigned to an Area Director(s) <> Mailing lists: General Discussion:poised@nri.reston.va.us To Subscribe: poised-request@nri.reston.va.us Archive: cnri.reston.va.us:~/poised/current Description of Working Group: The goal of this Working Group is to examine the Internet standards process and the responsibilities of the IAB, with attention to the relationship between the IAB and IETF/IESG. The need for this Working Group was suggested during discussions at the July 1992 IETF. This led to a request from the Internet Society president to form such a Working Group. The Working Group will consider the following matters: 1. Procedures for making appointments to the Internet Architecture Board. 2. Procedures for resolving disagreements among IETF, IESG and IAB in matters pertaining to the Internet Standards. 3. Methods for assuring that for any particular Internet Standard, procedures have been followed satisfactorily by all parties so that everyone with an interest has had a fair opportunity to be heard. The Working Group will begin with a review of the procedures for making IAB appointments as documented in RFC 1358 and a review of the standards-making process documented in RFC 1310. The Working Group has a goal of issuing a final report in time for IESG consideration and publication as an RFC before the ISOC Board Trustee's meeting in December 1992. Given the compressed timescale, the Working Group will conduct most of its deliberations by electronic mail on the POISED Working Group mailing list. There will also be a preliminary report and discussions at the November 1992 IETF meeting in Washington, DC. This will be a normal IETF Working Group, i.e., the mailing list and all discussions will be completely open. Goals and Milestones: Done Review and approval of the Charter for the POISED Working Group. Done Gather initial set of issues and write a preliminary report. Oct 92 Post as an Internet-Draft the initial recommendations to the ISOC Board. Done Open discussion and presentation of the work of the POISED Working Group at Washington D.C. IETF meeting. Dec 92 Submit the recommendations document to the IESG for posting as an Informational RFC. This document will be subsequently transmitted to the ISOC Board. Point-to-Point Protocol Extensions (pppext) Charter Chair(s): Brian Lloyd Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:ietf-ppp@ucdavis.edu To Subscribe: ietf-ppp-request@ucdavis.edu 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 level 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. Goals and Milestones: Router Discovery (rdisc) Charter Chair(s): Steve Deering <> Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:gw-discovery@gregorio.stanford.edu To Subscribe: gw-discovery-request@gregorio.stanford.edu Archive: Status: concluded Description of Working Group: The Router Discovery Working Group is chartered to adopt or develop a protocol that Internet hosts may use to dynamically discover the addresses of operational neighboring gateways. The group is expected to propose its chosen protocol as a standard for gateway discovery in the Internet. The work of this group is distinguished from that of the Host Configuration Working Group in that this group is concerned with the dynamic tracking of router availability by hosts rather than the initialization of various pieces of host state (which might include router addresses) at host-startup time. Goals and Milestones: Ongoing Gather implementation and operational experience, revise the specification to reflect lessons learned, and submit the protocol for Draft Standard. Done Created Working Group; established and advertised mailing list. Initiated email discussion to identify existing and proposed protocols, for router discovery. Done Held first meeting in Palo Alto. Reviewed 9 candidate protocols, and agreed on a hybrid of cisco's GDP and an ICMP extension proposed by Deering. Done Held second meeting in Tallahassee. Reviewed the proposed protocol and discussed a number of open issues. Done Held third meeting in Pittsburgh. Discussed and resolved several issues that had been raised by email since the last meeting. Draft specification of router discovery protocol to be ready by next meeting. Experimental implementations to be started. Done Meet in Vancouver. Review draft specification, and determine any needed revisions. Evaluate results of experimental implementations and assign responsibility for additional experiments, as required. Submit the specification for publication as a Proposed Standard shortly after the meeting. Done Revise specification as necessary, based on field experience. Ask the IESG to elevate the protocol to Draft Standard status. Disband. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1256 PS Sep 91 ICMP Router Discovery Messages RIP Version II (ripv2) Charter Chair(s): Gary Malkin Routing Area Director(s) Bob Hinden Mailing lists: General Discussion:ietf-rip@xylogics.com To Subscribe: ietf-rip-request@xylogics.com Archive: xylogics.com:gmalkin/rip/rip-arc Status: concluded Description of Working Group: The RIP Version 2 Working Group is chartered to expand the RIP protocol, as defined in RFC 1058. The expansion will include the addition of subnet masks to the routing entries. The expansion may also include authentication, AS numbers, next hop address, MTU, or linkspeed. Since all routing protocols are required to have a MIB, one will be defined. The primary issue is the maintainance of backwards compatibility, which must be preserved. The purpose of improving RIP is to make a simple, widely available protocol more useful. It is not intended that RIP-II be used in places where OSPF would be far better suited. Goals and Milestones: Given successful implementation experience, advancement of RIP-II to Draft Standard. Submission of MIB into the standards track. Final meeting to achieve closure on any pending issues. Done Review of RIP-II Internet-Draft to ensure the additions are useful and backwards compatible. Also ensure that the additions cannot cause routing problems. Done Final review of RIP-II Internet-Draft and submission into the standards track. First review of RIP-II MIB. Done Review of implementations. Final review of MIB. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1387 Jan 93 RIP Version 2 Protocol Analysis RFC1388 PS Jan 93 RIP Version 2 Carrying Additional Information RFC1389 PS Jan 93 RIP Version 2 MIB Extension Remote LAN Monitoring (rmonmib) Charter Chair(s): Mike Erlinger <> Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:rmonmib@jarthur.claremont.edu To Subscribe: rmonmib-request@jarthur.claremont.edu Archive: Status: concluded Description of Working Group: The LAN Monitoring MIB Working Group is chartered to define an experimental MIB for monitoring LANs. The Working Group must first decide what it covers and what terminology to use. The initial thought was to investigate the characteristics of some of the currently available products (Novell's LANtern, HP's LanProbe, and Network General's Watch Dog). From this investigation MIB variables will be defined. In accomplishing our goals several areas will be addressed. These include: identification of the objects to place in the MIB, identification of the tree structure and corresponding Object ID's for the MIB elements, generation of the ASN.1 for these new elements, and a test implementation. Goals and Milestones: Done Mailing list discussion of Charter and collection of concerns. Done Discussion and final approval of Charter; discussion and agreement on models and terminology. Make writing assignments. Done Discussion of the first draft document. Begin work on additional drafts if needed. Mar 91 Review latest draft of the first document and if OK give to IESG for publication as an RFC. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1271 PS Nov 91 Remote Network Monitoring Management Information Base Router Requirements (rreq) Charter Chair(s): Philip Almquist Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:ietf-rreq@Jessica.Stanford.edu To Subscribe: ietf-rreq-request@Jessica.Stanford.edu Archive: Description of Working Group: The Router Requirements Working Group has the goal of rewriting the existing Router Requirements RFC, RFC-1009, and a) bringing it up to the organizational and requirement explicitness levels of the Host Requirements RFC's, as well as b) including references to more recent work, such as OSPF and BGP. The Working Group will also instigate, review, or (if appropriate) produce additional RFCs on related topics. To date, Group members have produced draft documents discussing the operation of routers which are in multiple routing domains (3 papers), TOS, and a routing table MIB. The purposes of this project include: - Defining what an IP router does in sufficient detail that routers from different vendors are truly interoperable. - Providing guidance to vendors, implementors, and purchasers of IP routers. The Working Group has decided that, unlike RFC-1009, the Router Requirements document should not discuss Link Layer protocols or address resolution. Instead, those topics should be covered in a separate Link Layer Requirements document, applicable to hosts as well as routers. Whether this Group will create the Link Layer Requirements is still to be determined. Goals and Milestones: Done First Internet-Draft version. Done Second Internet-Draft version. Done Third Internet-Draft version. Done Fourth Internet-Draft version. Oct 91 Final Internet-Draft version. Nov 91 Submission for Proposed Standard. Special Host Requirements (shr) Charter Chair(s): Bob Stewart Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:ietf-hosts@nnsc.nsf.net To Subscribe: ietf-hosts-request@nnsc.nsf.net Archive: Status: concluded Description of Working Group: The Special-purpose Host Requirements Working Group is chartered to clarify application of the Host Requirements RFCs (1122 and 1123) to systems that are technically hosts but are not intended to support general network applications. These special-purpose hosts include, for example, terminal servers (a ``Telnet host''), or file servers (an ``FTP host'' or an ``NFS host''). The Host Requirements RFCs address the typical, general-purpose system with a variety of applications and an open development environment, and give only passing consideration to special-purpose hosts. As a result, suppliers of special-purpose hosts must bend the truth or make excuses when users evaluate their products against the Requirements RFCs. Users must then decide whether such a product is in fact deficient or the requirements truly do not apply. This process creates work and confusion, and undermines the value of the RFCs. The commercial success of the Internet protocols and their use in increasingly unsophisticated environments exacerbates the problem. The Working Group must define principles and examples for proper functional subsets of the general-purpose host and specifically state how such subsets affect the requirements. The Working Group must determine the balance between an exhaustive list of specific special-purpose hosts and philosphy that remains subject to debate. For the most part, it should be possible to base decisions on existing experience and implementations. The special-purpose requirements will be stated as differences from the existing RFCs, not replacements, and will refer rather than stand alone. Since they define strict subsets of the Host Requirements RFCs, the Special-purpose Host Requirements appear to be an easier job and can be developed and stabilized within 8-12 months. Most of the Group's business can be conducted over the Internet through email. Goals and Milestones: Jan 90 Revised document. Feb 90 Third IETF Meeting: make document an Internet Draft. Continue revisions based on comments received at meeting and over e-mail. Done Mailing list discussion of Charter and collection of concerns. Done First IETF Meeting: discussion and final approval of Charter; discussion and agreement on approach, including models, format, level and type of detail. Make writing assignments. Oct 90 First draft document. Nov 90 Second IETF Meeting: review first draft document, determine necessary revisions. Follow up discussion on mailing list. Apr 91 Final draft document. May 91 Fourth IETF meeting: review final draft and if OK, give to IESG for publication as RFC. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Simple Internet Protocol (sip) Charter Chair(s): Christian Huitema Steve Deering Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:sip@caldera.usc.edu To Subscribe: sip-request@caldera.usc.edu Archive: Description of Working Group: SIP is another candidate for IPv7. The purpose of the Working Group is to finalize the SIP family of protocol, and to foster the early development and experimentation of this protocol. There are two major characteristics of the SIP proposal: it is very much a continuation of IP, and it aims at maximum simplicity. A short hand definition of SIP could be ``64 bits IP with useless overhead removed''. Following the IP model, SIP uses globally-unique addresses, hierarchically structured for efficient routing. SIP addresses are 64 bits long, which we believe adequate to scale the Internet up to, say, thousands of internet-addressable devices in every office, every residence, and every vehicle in the world. The quest of simplicity in SIP has been described as parallel to the RISC philosophy. The minimal SIP header contains only those fields which are necessary to achieve our goal: routing packets efficently in a very large internet. As a result of this design philosophy, the SIP header is much simpler than the IP header. Simplicity facilitates high-performance implementation and increases the likelihood of correct implementation. Contrary to several other IPv7 candidates, the SIP effort is focused mostly on the description of the final state, not on the description of the transition. This is due to a coordination with the IPAE working group, which has already engaged an intensive study of transition problems, with SIP in mind as a final state. Goals and Milestones: Done Post the complete SIP specification as an Internet-Draft. This specification shall include the header format, the address format, ICMP and IGMP, the fragmentation protocol, the source route protocol, and the the requirements SIP imposes on higher layer protocols and lower later protocols, e.g., ARP. Jan 93 Post an Internet-Draft specifing the SIP addressing and routing architecture. Include discussion of multicast and mobile host support as well as a discussion of how policy routing can be supported. Detail the changes required to OSPF, BGP, and RIP. Jan 93 Post as an Internet-Draft a specification for the SIP MIB. Detail the operation of SNMP over SIP. Jan 93 Make available a public domain implementation of SIP for the UNIX-BSD socket environment. Jan 93 Make available a public domain version of modified TCP and UDP for the UNIX-BSD socket environment. Mar 93 Post as an Internet-Draft a report on the initial implementation and experience with SIP. Jun 93 Incorporate security into SIP. Jun 93 Specify in detail the changes to the routing protocols needed for SIP. IP over Switched Megabit Data Service (smds) Charter Chair(s): George Clapp Michael Fidler Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:smds@nri.reston.va.us To Subscribe: smds-request@nri.reston.va.us Archive: /ietf.mail.archives/ip-lpdn.mail.archive Status: concluded Description of Working Group: The SMDS Working Group is chartered to investigate and to specify the manner in which the Internet and the newly defined public network service, Switched Multi-megabit Data Service, will interact. The group will discuss topics such as addressing, address resolution, network management, and routing. Goals and Milestones: Specify clearly an efficient interworking between the Internet and SMDS. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1209 DS Mar 91 The Transmission of IP Datagrams over the SMDS Service Internet Mail Extensions (smtpext) Charter Chair(s): John Klensin Ned Freed Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-smtp@dimacs.rutgers.edu To Subscribe: ietf-smtp-request@dimacs.rutgers.edu Archive: dimacs.rutgers.edu:~/pub/ietf/* Description of Working Group: The SMTP Extensions Working Group is chartered to develop extensions to the base SMTP protocol (RFC821) to facilitate the more efficient transmission of 8 bit text and binary data. Among the extensions to be considered to SMTP are the elimination of the ASCII text character restriction and line length restriction to allow the sending of arbitrary 8 bit character sets, and the definition of mechanisms to facilitate binary transmission, and extensions to the negotiation sequence to facilitate batch transmission. Goals and Milestones: Done Review the Charter of the Group. Determine if changes to SMTP are necessary. Discuss the needs for backward compatability, and interoperability. This discussion will be held by email. Done Discuss the elimination of the 7 bit restrictions in SMTP, and the implications of removing this restriction in terms of interoperation. Done Discuss the issues involved with binary transmission. Determine whether a ``binary'' mode should be pursued, and whether the SMTP line length restriction should be eliminated. Done Write a document specifying the changes to SMTP agreed to by the Group. Post as an Internet-Draft. Done Review and finalize the SMTP Extensions document. Done Submit the SMTP Extensions document as a Proposed Standard. Simple Network Management Protocol (snmp) Charter Chair(s): Marshall Rose Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:snmp-wg@nisc.nyser.net To Subscribe: snmp-wg-request@nisc.nyser.net Archive: Status: concluded Description of Working Group: Oversee development of SNMP-related activity, especially the Internet-standard SMI and MIB. This Working Group is ultimately responsible for providing workable solutions to the problems of network management for the Internet community. Goals and Milestones: Ongoing Coordinate the development of various experimental MIBs. Aug 90 Finish SNMP Authorization draft. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1155 S May 90 Structure and Identification of Management Information for TCP/IP-based Internets RFC1157 S May 90 A Simple Network Management Protocol (SNMP) RFC1156 S May 90 Management Information Base for Network Management of TCP/IP-based internets RFC1158 PS May 90 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1161 E Jun 90 SNMP over OSI RFC1162 Jun 90 Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) Management Information Base RFC1212 S Mar 91 Concise MIB Definitions RFC1213 S Mar 91 Management Information Base for Network Management of TCP/IP-based internets: MIB-II RFC1215 Mar 91 A Convention for Defining Traps for use with the SNMP RFC1229 PS May 91 Extensions to the Generic-Interface MIB RFC1230 PS May 91 IEEE 802.4 Token Bus MIB RFC1231 PS May 91 IEEE 802.5 Token Ring MIB RFC1233 May 91 Definitions of Managed Objects for the DS3 Interface Type RFC1232 May 91 Definitions of Managed Objects for the DS1 Interface Type RFC1238 E Jun 91 CLNS MIB - for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) RFC1284 PS Dec 91 Definitions of Managed Objects for the Ethernet-like Interface Types RFC1283 E Dec 91 SNMP over OSI RFC1298 Feb 92 SNMP over IPX RFC1304 PS Feb 92 Definitions of Managed Objects for the SIP Interface Type SNMP Authentication (snmpauth) Charter Chair(s): Jeffrey Schiller Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:awg@bitsy.mit.edu To Subscribe: awg-request@bitsy.mit.edu Archive: Status: concluded Description of Working Group: To define a standard mechanism for authentication within the SNMP. Goals and Milestones: May 90 Write an RFC specifying procedures and formats for providing standardized authentication within the SNMP. Internet-Drafts: No Current Internet drafts. RFC's: None to date. SNMP Security (snmpsec) Charter Chair(s): James Galvin Keith McCloghrie Security Area Director(s) Steve Crocker Mailing lists: General Discussion:snmp-sec-dev@tis.com To Subscribe: snmp-sec-dev-request@tis.com Archive: snmp-sec-dev-request@tis.com Description of Working Group: Enhancements to the SNMP network management framework are being contemplated within the SNMP Version 2 Working Group of the IETF. The SNMP Security Working Group is chartered to consider changes to RFCs 1351, 1352, 1353 that may be required either for consistency with this SNMP evolution effort or to reflect implementation experience with the current specifications. Goals and Milestones: Done Publish Internet-Draft specifications. Done Submit specification to IESG for consideration as a Proposed Standard. Done At the November IETF meeting, review and discuss feedback from implementation experience of the present specifications and requirements from the evolution of the SNMP Framework. Done Publish updated SNMP Security documents as Internet-Drafts. Feb 93 Submit the SNMP Security Documents to the IESG for consideration as a Draft Standard. SNMP Version 2 (snmpv2) Charter Chair(s): Bob Stewart Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:snmp2@thumper.bellcore.com To Subscribe: snmp2-request@thumper.bellcore.com Archive: thumper.bellcore.com:~/pub/davin/snmp2-archive Description of Working Group: This Working Group is chartered to consider technical contributions to the SNMP evolution process and to produce a single recommendation as to which contributions (or combinations or modifications thereof) should define the next generation SNMP network management framework. The announced deadline for technical contributions to the SNMP evolution process is September 10, 1992. Any individual interested in contributing to this process should prepare and submit his/her contribution according to the requirements for detail, completeness, copyright, and format set forth in the original announcement. This Working Group is under no obligation to consider contributions that do not meet these basic requirements or contributions that are not submitted by the contribution deadline. This Working Group has the option of (a) rejecting any or all contributions as the basis for positive evolution, (b) accepting any or all contributions as candidates for standardization, or (c) modifying or combining any or all contributions to produce consensus proposals for standardization. The product of the Working Group will be a single recommendation to the IESG identifying those submitted specifications (or modifications thereof), if any, whose standardization as part of the SNMP framework is agreed to be warranted and desirable. The Working Group will not be chartered to produce tutorial, explanatory, advisory, or informational documents of any kind. In its deliberations, the Working Group will take special cognizance of architectural principles on which the historic success of SNMP has rested: (1) The SNMP framework minimizes the overall cost of a manageable network by minimizing the cost and complexity of those management system components that are most numerous. (2) The SNMP framework fosters ubiquity of deployment by admitting the widest possible range of implementation strategies. (3) The SNMP framework fosters operational robustness by realizing management system function as closely as possible to centers of responsible authority. (4) The SNMP framework fosters operational robustness by locating control of resources consumed by the management activity (e.g., bandwidth, processing) as closely as possible to centers of responsible authority. Moreover, the deliberations of the Working Group will take special cognizance of at least two aspects of evolutionary logistics: (1) A single transition from existing SNMP technology to the next stage of SNMP evolution is highly desirable; multi-stage or protracted transitions are less desirable. (2) Minimizing the number of distinct management technologies concurrently deployed in the Internet is highly desirable. Consistent with the community desire for timely, deliberate progress, the Working Group may be disbanded at the time of the IETF plenary meeting in the Spring of 1993 regardless of whether or not it has produced the single recommendation required by its Charter. This Working Group is not chartered to consider security aspects of the SNMP framework, as these are addressed as a matter of course by an existing IETF working group. Goals and Milestones: Done Post as an Internet-Draft the technical proposals to the SNMP Evolution Working Group. Done Closing date for technical proposals. Done First Working Group meeting. Done Working Group meeting in Washington DC IETF Plenary. Mar 93 Working Group meeting at the IETF Plenary. Mar 93 Submit a proposal to the IESG for consideration as a Proposed Standard. Internet Security Policy (spwg) Charter Chair(s): Richard Pethia Security Area Director(s) Steve Crocker Mailing lists: General Discussion:spwg@nri.reston.va.us To Subscribe: spwg-request@nri.reston.va.us Archive: Status: concluded Description of Working Group: The Security Policy Working Group (SPWG) is chartered to create a proposed Internet Security Policy for review, possible modification, and possible adoption by the Internet Activities Board. The SPWG will focus on both technical and administrative issues related to security, including integrity, authentication and confidentiality controls, and the administration of hosts and networks. Among the issues to be considered in this Working Group are: \begin{itemize} \item Responsibilities and obligations of users, database administrators, host operators, and network managers. \vspace{.2in} \item Technical controls which provide protection from disruption of service, unauthorized modification of data, unauthorized disclosure of information and unauthorized use of facilities. \vspace{.2in} \item Organizational requirements for host, local network, regional network and backbone network operators. \vspace{.2in} \item Incident handling procedures for various Internet components. \end{itemize} Goals and Milestones: Done Review and approve the Charter making any necessary changes. Begin work on a policy framework. Assign work on detailing issues for each level of the hierarchy with first draft outline. Done Revise and approve framework documents. Begin work on detailing areas of concern, technical issues, legal issues, and recommendations for each level of the hierarchy. Done Prepare first draft policy recommendation for Working Group review andmodification. Done Finalize draft policy and initiate review following standard RFC procedure. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1281 Nov 91 Guidelines for the Secure Operation of the Internet Site Security Policy Handbook (ssphwg) Charter Chair(s): J. Paul Holbrook Joyce K. Reynolds Security Area Director(s) Steve Crocker Mailing lists: General Discussion:ssphwg@cert.sei.cmu.edu To Subscribe: ssphwg-request@cert.sei.cmu.edu Archive: Status: concluded Description of Working Group: The Site Security Policy Handbook Working Group is chartered to create a handbook that will help sites develop their own site-specific policies and procedures to deal with computer security problems and their prevention. Among the issues to be considered in this group are: \begin{enumerate} \item Establishing official site policy on computer security: \begin{itemize} \item Define authorized access to computing resources. \item Define what to do when local users violate the access policy. \item Define what to do when local users violate the access policy of a remote site. \item Define what to do when outsiders violate the access policy. \item Define actions to take when unauthorized activity is suspected. \end{itemize} \item Establishing procedures to prevent security problems: \begin{itemize} \item System security audits. \item Account management procedures. \item Password management procedures. \item Configuration management procedures. \end{itemize} \item Establishing procedures to use when unauthorized activity occurs: \begin{itemize} \item Developing lists of responsibilities and authorities: site management, system administrators, site security personnel, response teams. \item Establishing contacts with investigative agencies. \item Notification of site legal counsel. \item Pre-defined actions on specific types of incidents (e.g., monitor activity, shut-down system). \item Developing notification lists (who is notified of what). \end{itemize} \item Establishing post-incident procedures \begin{itemize} \item Removing vulnerabilities. \item Capturing lessons learned. \item Upgrading policies and procedures. \end{itemize} \end{enumerate} Goals and Milestones: Done Review, amend, and approve the Charter as necessary. Examine the particular customer needs for a handbook and define the scope. Continue work on an outline for the handbook. Set up an SSPHWG ``editorial board for future writing assignments for the first draft of document. Done Finalize outline and organization of handbook. Partition out pieces to interested parties and SSPHWG editorial board members. Done Pull together a first draft handbook for Working Group review and modification. Oct 90 Finalize draft handbook and initiate IETF Internet Draft review process, to follow with the submission of the handbook to the RFC Editor for publication. Oct 90 Finalize draft handbook and initiate IETF Internet Draft review process, to follow with the submission of the handbook to the RFC Editor forpublication. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1244 Jul 91 Site Security Handbook Service Location Protocol (svrloc) Charter Chair(s): John Veizades Scott Kaplan Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:srv-location@apple.com To Subscribe: srv-location-request@apple.com Archive: apple.com:~/pub/srv-location/svr-loc-archive Description of Working Group: The Service Location Working Group is chartered to investigate protocols to find and bind to service entities in a distributed internetworked environment. Issues that must be addressed are how such a protocol would interoperate with existing directory based services location protocols. Protocols that would be designed by this Group would be viewed as an adjunct to directory service protocols. These protocols would be able to provide a bridge between directory services and current schemes for service location. The nature of the services location problem is investigative in principle. There is no mandate that a protocol should be drafted as part of this process. It is the mandate of this Group to understand the operation of services location and then determine the correct action in their view whether it be to use current protocols to suggest a services location architecture or to design a new protocol to compliment current architectures. Goals and Milestones: Done Open discussion and determine if a Working Group should be formed. Done Continue discussion trying to refine the problem statement and possible resolutions. Jul 91 Do we take the RFC track or do we write a report on our conclusion and leave it at that? TCP Large Windows (tcplw) Charter Chair(s): David Borman Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:tcplw@cray.com To Subscribe: tcplw-request@cray.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 RFC 1072 ``TCP extensions for long-delay paths'' and RFC 1185 ``TCP Extension for High-Speed Paths'' 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 eze-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. Goals and Milestones: Done Review the TCP Extended Window Size proposal from the IRSG End to End Research Group and if acceptable, recommend it for standards status. TELNET (telnet) Charter Chair(s): Steve Alexander Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:telnet-ietf@cray.com To Subscribe: telnet-ietf-request@cray.com Archive: Description of Working Group: The TELNET Working Group will examine RFC 854, ``Telnet Protocol Specification'', in light of the last six years of technical advancements, and will determine if it is still accurate with how the TELNET protocol is being used today. This Group will also look at all the TELNET options, and decide which are still germane to current day implementations of the TELNET protocol. (1) Re-issue RFC 854 to reflect current knowledge and usage of the TELNET protocol. (2) Create RFCs for new TELNET options to clarify or fill in any missing voids in the current option set. Specifically: - Environment variable passing - Authentication - Encryption - Compression (3) Act as a clearing-house for all proposed RFCs that deal with the TELNET protocol. Goals and Milestones: Done Write an environment option. Done Post an Internet-Draft describing the authentication option. Dec 90 Post an Internet-Draft describing the encryption option. Mar 91 Rewrite RFC 854. Done Submit the authentication option to the IESG as an Experimental Protocol. Jul 93 Submit the encryption option to the IESG as an Experimental Protocol. Topology Engineering (tewg) Charter Chair(s): TBD <> Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:tewg@devvax.tn.cornell.edu To Subscribe: tewg-request@devvax.tn.cornell.edu Archive: Status: concluded Description of Working Group: The Topology Engineering Working Group monitors and coordinates connections between networks, particularly routing relationships. \begin{itemize} \item Monitor interconnectivity among national and international backbones and mid-level networks. \vspace{.2in} \item Monitor interconnection policies with a view of moving toward a common scheme for managing interconnectivity. \vspace{.2in} \item Act as a forum where network engineers and representatives of groups of networks can come together to coordinate and tune their interconnections for better efficiency of the Internet as a whole. \end{itemize} Goals and Milestones: Ongoing Reports to the Internet community will be given reflecting what we learn each quarter. This periodic report will be of use to the IETF, to FARnet, and to the CCIRN members. Dec 90 An immediate project is to produce an RFC which will help mid-level networks when changing their interconnectivity. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Minimal OSI Upper-Layers (thinosi) Charter Chair(s): Peter Furniss Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:thinosi@ulcc.ac.uk To Subscribe: thinosi-request@ulcc.ac.uk Archive: pluto.ulcc.ac.uk:~/ulcc/thinosi Description of Working Group: The OSI upper-layer protocols (above Transport) are rich in function and specified in large, complex and numerous documents. However, in supporting a particular application, the protocol actually used is only a subset of the whole. An implementation is not required to support features it never uses, and it is or should be possible to have relatively lightweight implementations specialized for a particular application or group of applications with similar requirements. The application protocol could be an OSI application-layer standards or a protocol originally defined for TCP/IP or other environment. It will be easier to produce such implementations if the necessary protocol is described concisely in a single document. An implementation based on this principle, of the mapping of X Window System protocol over OSI upper-layers exists. The Working Group is chartered to produce two documents ``Skinny bits for byte-stream'' a specification of the bit (octet) sequences that implement the OSI upper-layer protocols (Session, Presentation and ACSE) as needed to support an application that requires simple connection, and byte-stream read and write. This will be based on the octet sequences needed to support X. This will not be expected to be provide a full equivalent of TCP, nor to cover specific standardized protocols. ``Skinny bits for Directory'' a specification of the bit sequences needed for the Directory Access Protocol - in the same style as a), but to include DAP. The level of functionality of this is to be determined. An important aspect of the Group's work is find out if it is possible to produce useful and concise specification of this kind. A minor part is to think of better names. The Group will also encourage the deployment of X/osi implementations and interworking experiments with it. Goals and Milestones: May 93 Post an Internet-Draft for ``Skinny bits for Byte-Stream''. Aug 93 Post an Internet-Draft for ``Skinny Bits for Directory''. Dec 93 Submit the ``Skinny Bits for Byte-Stream'' specification to the IESG for consideration as a Proposed Standard. Mar 94 Submit the ``Skinny Bits for Directory'' specification to the IESG for consideration as a Proposed Standard. Trusted Network File Systems (tnfs) Charter Chair(s): Fred Glover Transport and Services Area Director(s) Dave Borman Mailing lists: General Discussion:tnfs@wdl1.wdl.loral.com To Subscribe: tnfs-request@wdl1.wdl.loral.com Archive: archive-server@wdl1.wdl.loral.com Description of Working Group: The Trusted Network File System Working Group is chartered to define protocol extensions to the Network File System (NFS) Version 2 protocol which support network file access in a Multilevel Secure (MLS) Internet environment. MLS functionality includes Mandatory Access Control (MAC), Discretionary Access Control (DAC), authentication, auditing, documentation, and other items as identified in the Trusted Computer System Evaluation Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents. The primary objective of this Working Group is to specify extensions to the NFS V2 protocol which support network file access between MLS systems. It is intended that these extensions should introduce only a minimal impact on the existing NFS V2 environment, and that unmodified NFS V2 clients and servers will continue to be fully supported. Transferring information between MLS systems requires exchanging additional security information along with the file data. The general approach to be used in extending the NFS V2 protocol is to transport additional user context in the form of an extended NFS UNIX style credential between a Trusted NFS (TNFS) client and server, and to map that context into the appropriate server security policies which address file access. In addition, file security attributes are to be returned with each TNFS procedure call. Otherwise, the NFS V2 protocol remains essentially unchanged. The Trusted System Interoperability Group (TSIG) has already developed a specification which defines a set of MLS extensions for NFS V2, and has also planned for the future integration of Kerberos as the authentication mechanism. The TNFS Working Group should be able to use the TSIG Trusted NFS document as a foundation, and to complete the IETF TNFS specification within the next 3-6 months. Goals and Milestones: Mar 91 Verify the interoperability of TNFS implementations at the 1992 NFS Connectathon. Done Review and approve the TNFS Working Group Charter, review revised TSIG TNFS Specification, and publish a proposed standard following the July meeting. Jul 91 Review revised TSIG TNFS Specification. Oct 91 Review outstanding comments/issues from mailing list. Oct 91 Make any final revisions to TNFS document based on comments, issues, and interoperability testing. Nov 91 Publish a Proposed Standard following the July meeting. Mar 92 Request IESG to make the revised document a Draft Standard. Network Training Materials (trainmat) Charter Chair(s): Ellen Hoffman Jill Foster User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:us-wg@nnsc.nsf.net To Subscribe: us-wg-request@nnsc.nsf.net Archive: Description of Working Group: Widespread familiarity with global network services and competence in using them brings benefit to individual users, enriches the information skills and resources of the community and optimises the return in investment in networked services. The Network Training Materials Working Group is chartered to enable the research community to make better use of the networked services. Towards this end, the Working Group will work to provide a comprehensive package of ``mix and match'' training materials for the broad academic community which will: 1) enable user support staff to train users to use the networked services and 2) provide users with self-paced learning material. In the first instance, it will not deal with operational training. This Working Group is the IETF component of a joint RARE/IETF group working on Network Training Materials. The Working Group will create a catalogue of existing network training materials (using the TopNode cataloguing fields where appropriate), identify the gaps in Network Training Materials and work to identify the problems associated with hands on training workshops using networked services providing a real service. Goals and Milestones: Mar 93 First Working Group meeting. Review and approve the Charter with a review of documents and materials to be written. x Jul 93 Post the catalogue of training materials as an Internet-Draft. Dec 93 Submit the catalogue of training materials to the IESG for review and publication as an informational RFC. Transmission Mib (transmib) Charter Chair(s): John Cook Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:trans-wg@nisc.nyser.net To Subscribe: trans-wg-request@nisc.nyser.net Archive: Status: concluded Description of Working Group: The objective of the Transmission Architecture Working Group is to drive the development, documentation and testing of MIB objects for the physical and data-link layers of the OSI model. The Working Group attempts to consolidate redundant MIB variables from new specifications into a universal structure. Goals and Milestones: Ongoing Provide a forum for vendors and users of MAC layer communications equipment. Ongoing Form sub-Working Groups of experts to define object for the following at the data-link layer: X.25, Ethernet, Token, FDDI and T1. Done Form a core group to evaluate the work of the sub-Working Groups. Ongoing Act as a liaison between sub-Working Groups and the network management protocol Working Groups, including SNMP, OIM, IEEE 802.1, etc. Internet-Drafts: No Current Internet drafts. RFC's: None to date. Token Ring Remote Monitoring (trmon) Charter Chair(s): Michael Erlinger Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:rmonmib@lexcel.com To Subscribe: rmonmib-request@lexcel.com Archive: Description of Working Group: The Token Ring Remote Monitoring MIB Working Group is chartered to produce a new MIB specification that extends the facilities of the existing Remote Monitoring (RMON) MIB (RFC 1271) for use in monitoring IEEE 802.5 Token Ring networks. The Token Ring RMON MIB extensions will be developed in the same architectural framework as the existing Ethernet-based RMON MIB. The original RMON MIB architecture was designed with the intention of incorporating MIB extensions devoted to monitoring other network media types. This Token Ring activity is the first attempt at such integration. In creating the Token Ring Extensions the Working Group will, wherever possible, conform to terminology and concepts defined by relevant IEEE standards. It may be that a MIB devoted to monitoring may need to expand on the IEEE objects and definitions. Such modifications will be accompanied by a detailed rationale. All work produced by the Token Ring Remote Monitoring Working Group will be consistent with the existing SNMP network management framework and standards. Goals and Milestones: Done Discussion and agreement on models and terminology. Comparison of RMON architecture and Token Ring requirements. Assign author and editor responsibilities. Done Working Group meeting at San Diego IETF. Mar 92 Post Internet-Draft of the Token Ring Monitoring MIB. Done Working Group meeting at Cambridge IETF. Nov 92 Submit the Token Ring MIB to the IESG as a Proposed Standard. DS1/DS3 MIB (trunkmib) Charter Chair(s): Tracy Cox Fred Baker Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:trunk-mib@saffron.acc.com To Subscribe: trunk-mib-request@saffron.acc.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. Goals and Milestones: Done Post a draft version of the new DS1 MIB to the Internet-Drafts Directory. Done Post a revised version of the DS3 MIB to the Internet-Drafts Directory. Done Submit the DS1 document for the Network Management Directorate Review. Done Submit the DS3 MIB to the Network Management Directorate for review. Done Submit the DS1 MIB to the IESG for Draft Standard Status. Done Submit the DS3 MIB to the IESG for approval as a Draft Standard. TCP/UDP over CLNP-addressed Networks (tuba) Charter Chair(s): Mark Knopper Peter Ford Internet Area Director(s) Philip Almquist Stev Knowles Dave Piscitello Mailing lists: General Discussion:tuba@lanl.gov To Subscribe: tuba-request@lanl.gov Archive: Description of Working Group: The TUBA Working Group will work on extending the Internet Protocol suite and architecture by increasing the number of end systems which can be effectively addressed and routed. The TUBA effort will expand the ability to route Internet packets by using addresses which support more hierarchy than the current Internet Protocol (IP) address space. TUBA specifies the continued use of Internet Transport Protocols, in particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets. This will allow the continued use of Internet application protocols such as FTP, SMTP, Telnet, etc. An enhancement to the current system is mandatory due to the limitations of the current 32 bit IP addresses. TUBA seeks to upgrade the current system by a transition from the use of the Internet Protocol version 4 to ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access Point address space. In addition to protocol layering issues and ``proof of concept'' work, the TUBA approach will place significant emphasis on the engineering and operational requirements of a large, global, multilateral public data network. TUBA will work to maximize interoperatability with the routing and addressing architecture of the global CLNP infrastructure. The TUBA Working Group will work closely with the IETF NOOP and IPRP-for-IP Working Groups to coordinate a viable CLNP based Internet which supports the applications which Internet users depend on such as Telnet, FTP, SMTP, NFS, X, etc. The TUBA Working Group will also work collaboratively with communities which are also using the CLNP protocol, and will consider issues such as interoperability, applications coexisting on top of multiple transports, and the evolution of global public connectionless datagram networks, network management and instrumentation using CLNP and TUBA, and impact on routing architecture and protocols given the TUBA transition. The TUBA Working Group will consider how the TUBA scheme will support transition from the current IP address space to the future NSAP address space without discontinuity of service, although different manufacturers, service providers, and sites will make the transition at different times. In particular, the way in which implementations relying on current 32 bit IP addresses will migrate must be considered. TUBA will ensure that IP addresses can be assigned, for as long as they are used, independently of geographical and routing considerations. One option is to embed IP addresses in NSAP addresses, possibly as the NSAP end-system identifier. Whatever scheme is chosen must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA strategy will require a new mapping in the DNS from NAMEs to NSAP addresses. The rationale RFC (RFC-1347) documents issues of transition and coexistence, among unmodified ``IP'' hosts and hosts which support ``TUBA'' hosts. Hosts wishing full Internet connectivity will need to support TUBA. Goals and Milestones: Done Post Initial TUBA rational and discussion as an RFC. (RFC 1347) Done Post the Initial TUBA DNS specification. (RFC 1348) Done Review and approve the Charter. Done Post the TUBA CLNP profile as an Internet-Draft. Done Post an Routing and Addressing specification as an Internet-Draft, coordinated with the Network OSI Operations Working Group and the IDRP for IP Working Group. Nov 92 Post a summary report on TUBA deployment in the Internet. Done Present the results of Working Group deliberations at the November IETF meeting. Nov 92 Post an Internet-Draft on the changes required to Internet applications affected by the deployment of TUBA. Nov 92 Post an Internet-Draft covering the methodologies, instrumentation, address administration, routing coordination and related topics. Nov 92 Post as an Internet-Draft a revision to RFC 1347 reflecting lessons learned in the Working Group deliberation. User Connectivity (ucp) Charter Chair(s): Dan Long Operational Requirements Area Director(s) Phill Gross Bernard Stockman Mailing lists: General Discussion:ucp@nic.near.net To Subscribe: ucp-request@nic.near.net Archive: Description of Working Group: The User Connectivity Working Group will study the problem of how to solve network users' end-to-end connectivity problems. Goals and Milestones: Done Define the issues that must be considered in establishing a reliable service to users of the Internet who are experiencing connectivity problems. Write a document, addressing the above issues, which describes a workable mechanism for solving User Connectivity Problems. Address the above issues. Submit this document into the RFC pipeline as appropriate. Uninterruptible Power Supply (upsmib) Charter Chair(s): Jeff Case Network Management Area Director(s) J.R. Davin 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) control of both high-end 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. Goals and Milestones: Done Hold Interim Working Group meeting to review draft. Done Post initial draft MIB to Internet-Drafts. Mar 93 Meet at March IETF meeting to reach closure on MIB document. Apr 93 Submit the UPS MIB to the IESG for consideration as a Proposed Standard. Uniform Resource Identifiers (uri) Charter Chair(s): Jim Fullton Alan Emtage User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:uri@bunyip.com To Subscribe: uri-request@bunyip.com Archive: archives.cc.mcgill.ca:~/pub/uri-archive Description of Working Group: The Uniform Resource Identifiers Archives Working Group is chartered to define a set of standards for the encoding of system independent Resource Location and Identification information for the use of Internet information services. This Working Group is expected to produce a set of documents that will specify standardized representations of Uniform Resource Locators (URLs) which specify a standardized method for encoding location and access information across multiple information systems. Such standards are expected to build upon the document discussed at the UDI BOF session held during the 24th IETF meeting in Boston, Unique Resource Serial Numbers (URSNs) which specify a standardized method for encoding unique resource identification information for Internet resources and Uniform Resource Identifiers (URIs), which specify a standardized method for encoding combined resource identification and location information systems to be used for resource discovery and access systems in an Internet environment. Such a set of standards will provide a framework that: allows the Internet user to specify the location and access information for files and other resources on the Internet, allows users and network-based tools to uniquely identify specific resources on the Internet, and allows the creation and operation of resource discovery and access systems for the Internet. The security of such resource discovery services will also be considered to be an integral part of the work of this Group. Goals and Milestones: Done Review and approve the Charter making any changes deemed necessary. Examine the scope of the recommended documents. Review the first draft of a proposal for Uniform Resource Locators already available. Mar 93 Submit URL document as an Internet-Draft. Review additional draft documents and determine necessary revisions. Follow up discussion will occur on mailing list. Nov 93 Submit the URL document to the IESG for publication as a Proposed Standard RFC. User Documents (userdoc) Charter Chair(s): Ellen Hoffman Lenore Jackson User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:user-doc@nnsc.nsf.net To Subscribe: user-doc-request@nnsc.nsf.net Archive: Status: concluded Description of Working Group: The USER-DOC Working Group will prepare a bibliography of on-line and hard copy documents/reference materials/training tools addressing general networking information and ``how to use the Internet''. (Target audience: those individuals who provide services to end users and end users themselves.) \begin{itemize} \item Identify and categorize useful documents/reference materials/training tools. \item Publish both an on-line and hard copy of this bibliography. \item Develop and implement procedures to maintain and update the bibliography. Identify the organization or individual(s) who will accept responsibility for this effort. \item As a part of the update process, identify new materials for inclusion into the active bibliography. \item Set up procedures for periodic review of the bibliograhy by USWG. \end{itemize} Goals and Milestones: Done Format for the bibliography will be decided as well as identification of ``sources of information'' (e.g., individuals, mailing lists, bulletins, etc.) Done Draft bibliography will be prepared Done Draft to be reviewed and installed in the Internet-Drafts Directory Done Bibliography submitted as an FYI RFC Internet-Drafts: No Current Internet drafts. RFC's: None to date. User Documents Revisions (userdoc2) Charter Chair(s): Ellen Hoffman Lenore Jackson User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:user-doc@nnsc.nsf.net To Subscribe: user-doc-request@nnsc.nsf.net Archive: Description of Working Group: The focus of the USER-DOC2 Working Group is on identifying and locating documentation about the Internet. A major activity is the revision of an existing bibliography of on-line and hard copy documents/reference materials/training tools addressing general networking information and ``How to use the Internet'' (RFC 1175, FYI 3). This effort will also be used to help locate documentation produced by other organizations and examine the means by which such documents are made available on the Internet. The target audience is those individuals who provide services to end users and end users themselves. The Group is also developing a new FYI RFC document designed as a very short bibliography targeted at novice users. The USER-DOC2 Working Group will: (1) Identify and categorize useful documents, reference materials, training tools, and other publications about the Internet, particularly those available on-line. (2) Publish on-line and hard copies of the bibliography(s) produced and other reference material on documentation as needs are identified. (3) Develop and implement procedures to maintain and update the bibliography and investigate methods to provide the information in an on-line format. (4) As a part of the update process, identify new materials for inclusion into the active bibliography and identify additional needs which are required for locating documentation and other publications. (5) Review procedures for periodic review of the bibliography by the User Services Working Group. (6) Examine methods for delivering documentation and work with providers to improve the availability of basic Internet documentation. Goals and Milestones: Done Identify new ``sources of information'' (e.g., individuals, mailing lists, bulletins, etc.) Review existing document and obtain comments from others in USWG about needed revisions at the San Diego IETF. Done Publish Internet-Draft of the short bibliography for novice users. Done Submit the revised FYI document to the IESG for publication as an RFC. Done Post a revised version of FYI3, ``A bibliography of Internetworking Information'' as an Internet-Draft. Apr 93 Submit the revised FYI3 to the IESG for publication as an Informational RFC. Internet User Glossary (userglos) Charter Chair(s): Tracy LaQuey Parker Gary Malkin User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:usergloss@xylogics.com To Subscribe: usergloss-request@xylogics.com Archive: xylogics.com:gmalkin/usergloss/usergloss-arc Status: concluded Description of Working Group: The Internet User Glossary Working Group is chartered to create an Internet glossary of networking terms and acronyms for the Internet community. Goals and Milestones: Done Review Internet user needs and format for a glossary. Discussion of current ideas about the glossary and the outline development. Finalize outline and organization of the glossary. Done Draft of glossary will be prepared, draft to be reviewed and modified. Second pass draft of glossary. Draft to be reviewed and modified, finalize draft glossary. Initiate IETF Internet-Draft review process by submission of Userglos draft to IETF Secretary. Follow-up with the submission of the glossary to RFC Editor as an FYI RFC. Done Examine the particular Internet user needs for a glossary and define the scope. Review, amend, and approve the Charter as necessary. Discussion of Userglos Working Group Chair nominations submitted by USWGers. Internet-Drafts: No Current Internet drafts. RFC's: RFC Stat Published Title ------- -- ---------- ----------------------------------------- RFC1392 Jan 93 Internet Users' Glossary User Services (uswg) Charter Chair(s): Joyce K. Reynolds User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:us-wg@nnsc.nsf.net To Subscribe: us-wg-request@nnsc.nsf.net Archive: nnsc.nsf.net:~/nsfnet/us-wg* Description of Working Group: The User Services Working Group provides a regular forum for people interested in user services to identify and initiate projects designed to improve the quality of information available to end-users of the Internet. (Note that the actual projects themselves will be handled by separate groups, such as IETF working groups created to perform certain projects, or outside organizations such as SIGUCCS. (1) Meet on a regular basis to consider projects designed to improve services to end-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); - 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. Goals and Milestones: Ongoing This is an oversight group with continuing responsibilities. Whois and Network Information Lookup Service (wnils) Charter Chair(s): Joan Gargano User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:ietf-wnils@ucdavis.edu To Subscribe: ietf-wnils-request@ucdavis.edu Archive: ucdavis.edu:~/pub/ietf-wnils-archive Description of Working Group: The Network Information Center (NIC) maintains the central NICNAME database and server, defined in RFC 954, providing online look-up of individuals, network organizations, key nodes, and other information of interest to those who use the Internet. Other distributed directory information servers and information retrieval tools have been developed and it is anticipated more will be created. Many sites now maintain local directory servers with information about individuals, departments and services at that specific site. Typically these directory servers are network accessible. Because these servers are local, there are now wide variations in the type of data stored, access methods, search schemes, and user interfaces. The purpose of the Whois and Network Information Lookup Service (WNILS) Working Group is to expand and define the standard for WHOIS services, to resolve issues associated with the variations in access and to promote a consistent and predictable service across the network. Goals and Milestones: Done Review and approve the Charter making any changes deemed necessary. Examine the particular functional needs for expanded whois directory service. Begin work on a framework for recommendations. Assign writing assignments for first draft of document. Done Post the Whois and Network Information Lookup Service Recommendations document as an Internet-Draft. Dec 92 Submit the Whois and Network Information Lookup Service Recommendations document to the IESG as an Informational document. Dec 92 Post a revised WHOIS protocols specification as an Internet-Draft. Dec 92 Submit the revised WHOIS protocol documents to the IESG as Draft Standards. X.25 Management Information Base (x25mib) Charter Chair(s): Dean Throop Network Management Area Director(s) J.R. Davin Mailing lists: General Discussion:x25mib@dg-rtp.dg.com To Subscribe: x25mib-request@dg-rtp.dg.com Archive: dg-rtp.dg.com:~/x25mib/Current.Mail Description of Working Group: This Working Group will produce a set of three documents that describe the Management Information Base for X.25. The first document will specify the objects for the X.25 Link Layer. The second document will specify the objects for the X.25 Packet Layer. The third document will specify the objects for managing IP over X.25. The Working Group need not consider the Physical Layer because the ``Definition of Managed Objects for RS-232-like Hardware Devices'' already defines sufficient objects for the Physical Layer of a traditional X.25 stack. Any changes needed at the Physical Layer will be addressed as part of that activity. The X.25 object definitions will be based on ISO documents 7776 and 8208 however nothing should preclude their use on other similar or interoperable protocols (i.e., implementations based on CCITT specifications). The objects in the Link and Packet Layer documents, along with the RS-232-like document, should work together to define the objects necessary to manage a traditional X.25 stack. These objects will be independent of any client using the X.25 service. Both of these documents assume the interface table as defined in MIB-II contains entries for the Link and Packet Layer interfaces. Thus these documents will define tables of media specific objects which will have a one to one mapping with interfaces of ifType ddn-x25, rfc877-x25, or lapb. The objects for the IP to X.25 convergence functions will be defined analogously with the ipNetToMedia objects in MIB II. The Working Group will endeavor to make each layer independent from other layers. The Link Layer will be independent of any Packet Layer protocol above it and should be capable of managing an ISO 7776 (or similar) Link Layer provider serving any client. Likewise the X.25 Packet Layer objects should be independent of the Link Layer below it and should be capable of managing an ISO 8208 (or similar) Packet Layer serving any client. The Working Group will also produce a third document specifying the objects for managing IP traffic over X.25. These objects will reside in their own table but will be associated with the X.25 interfaces used by IP. These objects will not address policy decisions or other implementation specific operations associated with X.25 connection management decisions except as explicitly described in existing standards. These objects will manage the packet flow between IP and the X.25 Packet Layer specifically including observation of packet routing and diagnosis of error conditions. Progress on the Link and Packet Layer documents will not depend on progress of the IP over X.25 document. The IP over X.25 document will proceed on a time available basis after work on the Link and Packet Layer documents and as such the Link and Packet Layers may be completed before the IP over X.25 work. All documents produced will be for use by SNMP and will be consistent with other SNMP objects, conventions, and definitions (such as Concise MIB format). To the extent feasible, the object definitions will be consistent with other network management definitions. In particular ISO/IEC CD 10733 will be considered when defining the objects for the X.25 Packet Layer. Goals and Milestones: Done Working Group meeting as part of IETF to review documents. Done Distribute first draft of documents and discuss via E-mail. Done Distribute updated documents for more E-mail discussion. Done Submit the LAPB MIB to the IESG for consideration as a Proposed Standard. Done Submit the X.25 Packet Layer MIB to the IESG for consideration as a Proposed Standard. Nov 92 Submit the Multiprotocol over X.25 MIB to the IESG for consideration as a Proposed Standard. X.400 Operations (x400ops) Charter Chair(s): Alf Hansen Tony Genovese Applications Area Director(s) Russ Hobby Erik Huizer Mailing lists: General Discussion:ietf-osi-x400ops@cs.wisc.edu To Subscribe: ietf-osi-x400ops-request@cs.wisc.edu Archive: Description of Working Group: X.400 management domains are being deployed today on the Internet. There is a need for coordination of the various efforts to insure that they can interoperate and collectively provide an Internet-wide X.400 message transfer service connected to the existing Internet mail service. The overall goal of this Group is to insure interoperability between Internet X.400 management domains and the existing Internet mail service. The specific task of this Group is to produce a document that specifies the requirements and conventions of operational Internet PRMDs. Goals and Milestones: Done Initial meeting, produce internal outline. Done Working draft, circulate to interested people. Jul 91 Internet-Draft available. Dec 91 Document ready for publication.