Internet Message Access Protocol (imap) --------------------------------------- Charter Current status: active working group Chair(s): Terry Gray Applications Area Director(s) John Klensin Erik Huizer Mailing lists: General Discussion:imap@cac.washington.edu To Subscribe: imap-request@cac.washington.edu Archive: ftp.cac.washington.edu:~/imap/imap_archive Description of Working Group: The Interactive Mail Access Protocol (IMAP) Working Group is chartered to refine and extend the current IMAP2 protocol as a candidate standard for a client-server Internet email protocol to manipulate remote mailboxes as if they were local. An explicit objective is to retain compatibility with the growing installed base of IMAP2-compliant software. It is expected that the resulting specification will replace both RFC 1176 and the more recent (as yet unplublished) IMAP2bis extensions document. The IMAP Working Group will also investigate how to provide for ``disconnected operation'' capabilities similar to the DMSP protocol (RFC 1056, with Informational Status) with a goal of making it possible for IMAP to replace DMSP. An email access protocol provides a uniform, operating system-independent way of manipulating message data (email or bulletin board) on a remote message store (repository). Mail user agents implementing such a protocol can provide individuals with a consistent view of the message store, regardless of what type of computer they are using, and regardless of where they are connected in the network. Multiple concurrent sessions accessing a single remote mailbox, and single sessions accessing multiple remote mailboxes are both possible with this approach. This differs from POP3 (RFC 1225) in that POP is a store-and-forward transport protocol that allows an MUA to retrieve pending mail from a mail drop (where it is then usually deleted automatically), whereas IMAP is focused on remote mailbox manipulation rather than transport. IMAP differs from various vendor-specific remote access approaches in that IMAP is an open protocol designed to scale well and accommodate diverse types of client operating systems. Security-related tasks include how to incorporate secure authentication mechanisms when establishing a session, and possible interactions with Privacy Enhanced Mail. It is expected that most of the work of this group will be conducted via email. A goal is to integrate and update RFC 1176 and the existing IMAP2bis draft, then submit the result as an Internet-Draft well before the November IETF meeting, which would then focus on detailed review of the text in preparation for submission as a Proposed Standard before the end of 1993. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 93 Oct 93 INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 2bis Feb 94 Mar 94 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 Notifications and Acknowledgements Requirements (notary) -------------------------------------------------------- Charter Current status: active working group Chair(s): Harald Alvestrand Ned Freed Applications Area Director(s) John Klensin Erik Huizer Area Advisor John Klensin Mailing lists: General Discussion:notifications@cs.utk.edu To Subscribe: notifications-request@cs.utk.edu Archive: Description of Working Group: The purpose of the NOTARY Working Group is to give the Internet e-mail user better tools to build a system where the sender of a message can find out what happened to it. Work items for this group: - Specify a reporting format that can be used for delivery, non-delivery and receipt reports. The format should conform to MIME, and be at least as informative as current examples of non-standardized non-delivery notifications. This format should be usable as-is in current E-mail products to replace the current, non-standardized and sometimes quite cryptic textual non-delivery reports. The drafts by Keith Moore and Greg Vaudreuil are taken as a working basis. (See the document list below for details.) - Specify a way for the sender to request that positive delivery reports should be generated for a message sent via SMTP. The draft by Keith Moore is taken as a working basis. - Generate an Informational document that gives advice on how to handle delivery notifications (positive and negative) and requests for them at boundaries to other mail systems, such as X.400 and PC LANs. Relationship to X.400 and X.400 gateways: While the intent of this work includes specification of an acknowledgement system that can be translated to work across the 821/822/MIME to X.400 boundary, the effort will focus on design from the former standpoint. That will be followed by changes in the successor to RFC 1327 to match these features, but those changes will be made as part of the RFC 1327 revision process, not by this working group. Of course, if any features specified by this WG turn out to be impossible to accomodate in the RFC 1327 revision, that would be cause for reviewing both sets of specifications. Additional item not on the agenda of this working group: - Specification of a way in which the sender can request that a receipt notification ("the recipient has read this message") be sent upon receipt of the message. The document should identify the controversial aspects of such a function, and should attempt to specify the function in a way that minimizes surprise at both the sending and receiving end, even in the face of varying local policies. However, the group will, as part of its work, make a recommendation to the IESG where and how such work should be tackled. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 93 Mar 94 SMTP Service Extension for Delivery Status Notifications Sep 93 Mar 94 MIME Content-Types For Delivery Status Notifications OSI Directory Services (osids) ------------------------------ Charter Current status: active working group Chair(s): Steve Kille Applications Area Director(s) John Klensin 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 New Connection-less Lightweight Directory Access Protocol TELNET (telnet) --------------- Charter Current status: active working group Chair(s): Steve Alexander Applications Area Director(s) John Klensin 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, and Compression. (3) Act as a clearing-house for all proposed RFCs that deal with the TELNET protocol. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 92 Nov 93 Telnet Authentication: Kerberos Version 5 Telnet TN3270 Enhancements (tn3270e) ------------------------------------ Charter Current status: active working group Chair(s): Robert Moskowitz <3858921@mcimail.com> Applications Area Director(s) John Klensin Erik Huizer Mailing lists: General Discussion:tn3270e@list.nih.gov To Subscribe: listserv@list.nih.gov In Body: sub tn3270e Archive: listserv@list.nih.gov Description of Working Group: The TN3270 Enhancements Working Group will document the current practices that provide limited support for 3270 devices over TELNET and will develop a specification that allows the 3270 family of devices, including printers, to function properly over TCP via TELNET. Topics such as authentication, which are being addressed by other working groups, are recognized as important to TN3270, but are beyond the scope of this effort. The specification will draw on work already done by the Internet community for supporting 3270 devices through TELNET. It will be based on appropriate portions of IBM's published documentation on 3270 display and printer data streams and LU function management. Finally, it will make use of existing TELNET facilities where possible. The working group will produce: an Informational RFC documenting current TN3270 terminal practices, an Experimental RFC describing an interim approach to printing and LU name selection (this will address the work that is already under way and implementations of this partial solution that are already in place), and a standards-track RFC specifying the TELNET protocols that support a fully functional 3270 display and printing environment. This RFC will supersede RFC 1041 and the Experimental RFC describing the interim approach to printing and LU name selection. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 93 Mar 94 TN3270 Enhancements Jul 93 Feb 94 TN3270 Extensions for LUname and Printer Selection X.400 Operations (x400ops) -------------------------- Charter Current status: active working group Chair(s): Alf Hansen Tony Genovese Applications Area Director(s) John Klensin 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 92 Oct 93 Operational Requirements for X.400 Management Domains in the GO-MHS Community Nov 92 Mar 94 Postmaster Convention for X.400 Operations Dec 92 Oct 93 C=US; A=IMX Jan 93 Dec 93 Using the Internet DNS to distribute RFC1327 Address Mapping Tables Address Lifetime Expectations (ale) ----------------------------------- Charter Current status: active working group Chair(s): Frank Solensky Tony Li IP: Next Generation Area Director(s) Scott Bradner Allison Mankin Mailing lists: General Discussion:ipv4-ale@ftp.com To Subscribe: ipv4-ale-request@ftp.com Archive: research.ftp.com:pub/ale/ Description of Working Group: The primary purpose of the Address Lifetime Expectations Working Group is to develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available technologies. The members of the working group will consider whether more stringent address allocation and utilization policies might provide additional time and, if so, recommend such policies. The working group will also investigate whether it is worthwhile to mount a serious effort to reclaim addresses and/or to renumber significant portions of the Internet. It will also weigh the benefit of other potential options against their expected cost and notify the responsible working groups or area directors of those proposals the ALE group considers worthy of their further attention. The working group will have several ongoing activities which will result in reports to the IETF community and the IPng Area Directors. One ongoing activity is to produce monthly predictions of the address space exhaustion timeframe, assessing the accuracy of these predictions and the data on which they are based. The group will also project the impact of various policy compliance data and possible policy recommendations. Another ongoing activity is to monitor the perceived utilization of address space and identify sources of poor utilization, set address utilization goals and to itemize possible policies to improve utilization. The group will also monitor the number of routes present in the Internet backbones, and identify sources of poor aggregation within the network, (in conjunction with the BGP deployment WG); and make necessary recommendations to insure continued operations. Internet-Drafts: No Current Internet drafts. Common Architecture for Next-Generation IP (catnip) --------------------------------------------------- Charter Current status: active working group Chair(s): Vladimir Sukonnik IP: Next Generation Area Director(s) Scott Bradner Allison Mankin Area Advisor Scott Bradner Mailing lists: General Discussion:catnip@world.std.com To Subscribe: catnip-request@world.std.com Archive: world.std.com:~/pub/catnip/* Description of Working Group: CATNIP is a new version of the IP protocol, converged with a compressed form of CLNP, and a form of Novell IPX that permits general interoperation. The objective is to provide common ground between the Internet, OSI, and the Novell protocols, as well as to advance the Internet technology to the scale and performance of the next generation of internetwork technology. CATNIP has been assigned the IP version number 7. The CATNIP proposal has evolved from the TP/IX protocol (RFC 1475) and the TUBA proposal (RFC 1347). The working group is chartered to review the CATNIP protocol, evaluate issues arising during product development and deployment planning, and to document problems and explanations for any parts of the coexistance with IPv4 not covered directly in the CATNIP-IPv4 interoperation design. CATNIP includes definitions covering the same ground as the TUBA project, and within the charter of the TUBA Working Group. This will be handled by coordination with the TUBA Working Group. The intent is to arrive at complete alignment between the TUBA work and the CLNP component in CATNIP. The group will also continue to be the forum for development of the RAP protocol and the TCP extensions while in experimental status; this work will need to be moved to the Transport and Routing Area(s) if it is to be advanced; this work is outside the charter of the IPng area. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 93 Mar 94 Common Architecture for Next-generation Internet Protocol Mar 94 New CATNIP: Common Architecture for the Internet Simple Internet Protocol Plus (sipp) ------------------------------------ Charter Current status: active working group Chair(s): Robert Hinden Steve Deering Paul Francis IP: Next Generation Area Director(s) Scott Bradner Allison Mankin Area Advisor Allison Mankin Mailing lists: General Discussion:sipp@sunroof.eng.sun.com To Subscribe: sipp-request@sunroof.eng.sun.com Archive: parcftp.xerox.com: pub/sipp Description of Working Group: Simple Internet Protocol Plus (SIPP) is one of the candidates being considered in the Internet Engineering Task Force (IETF) for the next version of the Internet Protocol (IP). The current version of IP is usually referred to as IPv4. The purpose of the working group is to finalize the SIPP and IPAE specifications, foster the early development and experimentation of this protocol, and to work toward having SIPP selected as the IETF's IPng. SIPP is a new version of IP which is designed to be an evolutionary step from IPv4. It is a natural increment to IPv4. It can be installed as a normal software upgrade in internet devices and is interoperable with the current IPv4. Its deployment strategy is designed to not have any "flag" days. SIPP is designed to run well on high performance networks (e.g., ATM) and at the same time is still efficient for low bandwidth networks (e.g., wireless). In addition, it provides a platform for new internet functionality that will be required in the near future. Background: The SIPP Working Group represents the evolution and merger of three different IETF working groups focused on developing an IPng. The first was called IP Address Encapsulation (IPAE) and was chaired by Dave Crocker and Robert Hinden. It proposed extensions to IPv4 which would carry larger addresses. Much of its work was focused on developing transition mechanisms. Somewhat later Steve Deering proposed a new protocol evolved from IPv4 called the Simple Internet Protocol (SIP). A working group was formed to work on this proposal which was chaired by Steve Deering and Christian Huitema. SIP had 64-bit addresses, a simplified header, and options in separate extension headers. After lengthy interaction between the two working groups and the realization that IPAE and SIP had a number of common elements and the transition mechanisms developed for IPAE would apply to SIP, the groups decided to merge and concentrate their efforts. The chairs of the new SIP Working Group were Steve Deering and Robert Hinden. In parallel to SIP, Paul Francis (formerly Paul Tsuchiya) had founded a working group to develop the "P" Internet Protocol (Pip). Pip was a new internet protocol based on a new architecture. The motivation behind Pip was that the opportunity for introducing a new internet protocol does not come very often and given that opportunity important new features should be introduced. Pip supported variable length addressing in 16-bit units, separation of addresses from identifiers, support for provider selection, mobility, and efficient forwarding. It included a transition scheme similar to IPAE. After considerable discussion among the leaders of the Pip and SIP Working Groups, they came to realize that the advanced features in Pip could be accomplished in SIP without changing the base SIP protocol as well as keeping the IPAE transition mechanisms. In essence it was possible to keep the best features of each protocol. Based on this the groups decided to merge their efforts. The new protocol was called Simple Internet Protocol Plus (SIPP). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 93 Mar 94 SIPP Neighbor Discovery Oct 93 Mar 94 DNS Extensions to support Simple Internet Protocol Plus (SIPP) Nov 93 Mar 94 IPAE: The SIPP Interoperability and Transition Mechanism Jan 94 New Simple Internet Protocol Plus (SIPP): Unicast Hierarchical Address Assignment Jan 94 Feb 94 Simple Internet Protocol Plus (SIPP): Routing and Addressing Jan 94 Mar 94 SIPP Security Architecture Jan 94 Apr 94 SIPP Authentication Header Jan 94 Mar 94 SIPP Encapsulating Security Payload (ESP) Feb 94 Mar 94 Simple Internet Protocol Plus (SIPP): DHCP Options and BOOTP Vendor Extensions Feb 94 New OSPF for SIPP Feb 94 New Simple Internet Protocol Plus (SIPP) Specification Mar 94 New SIPP Neighbor Discovery -- ICMP Message Formats Mar 94 New ICMP and IGMP for the Simple Internet Protocol Plus (SIPP) Mar 94 New Simple Internet Protocol Plus (SIPP): Automatic Host Address Assignment Mar 94 New Simple Internet Protocol Plus White Paper TCP/UDP Over CLNP-Addressed Networks (tuba) ------------------------------------------- Charter Current status: active working group Chair(s): Mark Knopper Peter Ford IP: Next Generation Area Director(s) Scott Bradner Allison Mankin 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 specifies their encapsulation 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 OSI IDRP for IP Over 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 CLNP, 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 New Host Group Extensions for CLNP Multicasting Mar 94 New Transition Plan for TUBA/CLNP Mar 94 New Tunneling the OSI Network Layer over IP (EON) Mar 94 New Suggested System ID Option for the ES-IS Protocol Mar 94 New Dynamic Assignment of OSI NSAP Addresses in the Internet Dynamic Host Configuration (dhc) -------------------------------- Charter Current status: active working group Chair(s): Ralph Droms Internet Area Director(s) Stev Knowles Claudio Topolcic 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 to investigate network configuration and reconfiguration management, and 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). Internet-Drafts: No Current Internet drafts. IP Over AppleTalk (appleip) --------------------------- Charter Current status: active working group Chair(s): John Veizades Internet Area Director(s) Stev Knowles Claudio Topolcic Mailing lists: General Discussion:apple-ip@apple.com To Subscribe: apple-ip-request@apple.com Archive: Description of Working Group: The IP Over AppleTalk 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 92 Feb 94 AppleTalk Management Information Base II IP Over Asynchronous Transfer Mode (atm) ---------------------------------------- Charter Current status: active working group Chair(s): Mark Laubach Internet Area Director(s) Stev Knowles Claudio Topolcic Mailing lists: General Discussion:atm@hpl.hp.com To Subscribe: atm-request@hpl.hp.com Archive: Send message to atm-request@hpl.hp.com Description of Working Group: The IP Over Asynchronous Transfer Mode 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 standards 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 standards 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) 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 93 Feb 94 Default IP MTU for use over ATM AAL5 Jan 94 New IP over ATM: A Framework Document Apr 94 New ATM Signaling Support for IP over ATM Internet Stream Protocol V2 (st2) --------------------------------- Charter Current status: active working group Chair(s): Luca Delgrossi Steve DeJarnett Internet Area Director(s) Stev Knowles Claudio Topolcic Mailing lists: General Discussion:st@ibminet.awdpa.ibm.com To Subscribe: st-request@ibminet.awdpa.ibm.com Archive: ibminet.awdpa.ibm.com:~/pub/st/st-archive Description of Working Group: The Stream Protocol Working Group was formed to clarify and refine the existing specification of the Stream Protocol, Version 2 (ST-II) contained in RFC 1190. Since ST is a protocol that is already used in audio-visual and reserved-resource applications and services, the focus of this group is near-term and its primary purpose is to provide a specification that corrects errors in the existing ST specification and makes it easier to implement ST in a manner that is likely to be interoperable with other ST implementations. The ST Working Group intends to address several areas of the ST specification including: a) the formal definition of states and state transitions; b) the removal of mechanisms which are too complicated as currently designed and which have not shown any use in practice; c) address the ambiguities caused by the current implementation subsets; d) definition of a clear IP encapsulation mechanism; e) minor revisions suggested by experience with ST. These modifications are expected to reduce implementation time and to improve the utility and interoperability of existing and future ST implementations. The working group may also provide guidance on the use of standard routing protocols to support ST and on the format and use of flow specifications. Finally, particular attention will be given to the specification of groups of streams as required for the efficient sharing of resources. Input from current ST developers and application developers will be solicited to help clarify issues that the working group should address. It is the goal of the ST Working Group to produce a refined ST specification that can be used to rapidly satisfy operational requirements. The result of this group is expected to be an Experimental RFC. It is not the intention of this Working Group to define a new communication or resource reservation protocol. ST is part of the ongoing IETF efforts to develop protocols that address resource reservation issues. It is possible that future IETF Working Groups will produce other operational protocol options in this area. Related work by other IETF Working Groups shall be carefully monitored to see if the actions of this Working Group should be revised. In particular it is expected that there will be interaction with the AVT Working Group relating to issues of running RTP over ST. Internet-Drafts: No Current Internet drafts. Point-to-Point Protocol Extensions (pppext) ------------------------------------------- Charter Current status: active working group Chair(s): Fred Baker Internet Area Director(s) Stev Knowles Claudio Topolcic Mailing lists: General Discussion:ietf-ppp@merit.edu To Subscribe: ietf-ppp-request@merit.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 layer protocols and options for PPP. The group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Sep 93 PPP over SONET/SDH Mar 93 Oct 93 PPP over ISDN Mar 93 Oct 93 PPP in Frame Relay Jul 93 Mar 94 PPP Bridging Control Protocol (BCP) Sep 93 Mar 94 The PPP Multilink Protocol (MP) Sep 93 Feb 94 The PPP NetBIOS Frames Control Protocol (NBFCP) Oct 93 New PPP Reliable Transmission Oct 93 New PPP Stacker LZS Compression Protocol Oct 93 Mar 94 The PPP Compression Control Protocol (CCP) Oct 93 New PPP Gandalf FZA Compression Protocol Oct 93 New PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC) Protocol Dec 93 New PPP Predictor Compression Protocol Jan 94 New PPP BSD Compression Protocol Feb 94 Mar 94 PPP Option for Data Encapsulation Selection Mar 94 Apr 94 PPP in HDLC-like Framing Mar 94 Apr 94 The Point-to-Point Protocol (PPP) Mar 94 New The Generic Athentication Protocol (GAP) Mar 94 New The Arbitrary Handshake Authentication (AHA) protocol Mar 94 New PPP Variable Resource Compression Mar 94 New PPP Kerberos Authentication Protocol (KAP) Apr 94 New Proposal for Callback Control Protocol (CBCP). Router Requirements (rreq) -------------------------- Charter Current status: active working group Chair(s): Frank Kastenholz Bill Manning Internet Area Director(s) Stev Knowles Claudio Topolcic Area Advisor Stev Knowles Mailing lists: General Discussion:rreq@rice.edu To Subscribe: rreq-request@rice.edu Archive: ftp.sesqui.net:/pub/rreq 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 RFCs, 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 document is still to be determined. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jan 94 Apr 94 Requirements for IP Routers ATM MIB (atommib) ----------------- Charter Current status: active working group Chair(s): Kaj Tesink Network Management Area Director(s) Marshall Rose Area Advisor Keith McCloghrie Mailing lists: General Discussion:atommib@thumper.bellcore.com To Subscribe: atommib-request@thumper.bellcore.com Archive: Description of Working Group: The AToM MIB Working Group is chartered to define sets of managed objects which will be useful in the management of ATM and SONET equipment, interfaces, networks, and/or services that conform to the relevant ATM and SONET specifications. The initial sets defined will be: - An interface-specific MIB for ATM interfaces, which is aligned with the managed objects for interface layering being defined by the Interfaces MIB Working Group. The working group should consider the ATM Forum's ILMI MIB for its suitability in this respect, plus any extensions necessary to instrument the layers between the ATM layer and the IP layer (e.g., AAL5). The latter should take into account the work of the IP over ATM Working Group (e.g., the ``Multi-Protocol over AAL5'' specification). - Managed objects for the monitoring and control of ATM PVCs and SVCs, both in ATM end-points and in ATM switches or networks. (Objects for ATM SVCs will be considered after completion of the work on ATM PVCs.) - Managed objects that instrument devices with SONET interfaces that conform with the relevant SONET specifications. This work should closely align to other trunk MIBs (DS1/E1 MIB, DS3/E3 MIB). The working group should consider the existing Internet-Draft SONET MIB for its suitability in this respect. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 93 Mar 94 Definitions of Managed Objects for ATM Management Version 7.0 Character MIB (charmib) ----------------------- Charter Current status: active working group Chair(s): Bob Stewart Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:char-mib@decwrl.dec.com To Subscribe: char-mib-request@decwrl.dec.com Archive: Description of Working Group: The Character MIB Working Group is chartered to prepare a recommendation to the IESG evaluating RFCs 1316-1318 (the Character MIBs) with respect to the standards track. The recommendation will document implementation, interoperability, and deployment experience. If these experiences suggest that changes should be made to the documents, new drafts may be prepared. The recommendation will report one of four outcomes for each RFC: - That the RFC should be advanced from Proposed to Draft status, without changes (if no problems are found); - That a draft prepared by the working group should replace the RFC, and be designated a Draft Standard (if only minor changes are made); - That a draft prepared by the working group should replace the RFC, and be designated a Proposed Standard (if major changes or feature enhancements are made); or, - That the RFC should be designated as Historic (if this technology is problematic). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 Mar 94 Character MIB Feb 94 Mar 94 Parallel-printer-like MIB Feb 94 Mar 94 RS-232-like MIB Interfaces MIB (ifmib) ---------------------- Charter Current status: active working group Chair(s): Ted Brunner Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:if-mib@thumper.bellcore.com To Subscribe: if-mib-request@thumper.bellcore.com Archive: thumper.bellcore.com:pub/tob/ifmib Description of Working Group: The Interfaces MIB Working Group is chartered to accomplish two tasks. First, to develop a collection of managed objects which model the relation between different entities in the data link and physical layers. The working group will explore different modeling approaches in order to develop a collection of objects which is both correct in the modeling sense and has an acceptable impact (if any) on the interfaces table from MIB-II and all media MIB modules on the standards track or under development by a working group. The objects defined by the working group will be consistent with the SNMP framework. Second, to prepare a recommendation to the IESG evaluating RFC 1229 (the interface-extensions MIB), RFC 1231 (the token-ring MIB), RFC 1304 (the SMDS MIB), and RFC 1398 (the ethernet-like MIB) with respect to the standards track. The recommendation will document implementation, interoperability, and deployment experience. If these experiences suggest that changes should be made to the documents, new drafts may be prepared. For RFCs 1229, 1231, and 1304, the recommendation will report one of four outcomes for each RFC: - that the RFC should be advanced from Proposed to Draft status, without changes (if no problems are found); -that a draft prepared by the working group should replace the RFC, and be designated a Draft Standard (if only minor changes are made); - that a draft prepared by the working group should replace the RFC, and be designated a Proposed Standard (if major changes or feature enhancements are made); or, - that the RFC should be designated as Historic (if this technology is problematic). For RFC 1398, the recommendation will report one of five outcomes: - that the RFC should be advanced from Draft to Full status, without changes (if no problems are found); - that a draft prepared by the working group should replace the RFC, and be designated a Standard (if only editorial changes are made); - that a draft prepared by the working group should replace the RFCs, and be designated a Draft Standard (if only minor changes are made); - that a draft prepared by the working group should replace the RFC, and be designated a Proposed Standard (if major changes or feature enhancements are made); or, - that the RFC should be designated as Historic (if this technology is problematic). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Feb 94 Management Information Base for Management of Network Connections Feb 94 New Definitions of Managed Objects for SMDS Interfaces Feb 94 New Definitions of Managed Objects for the Ethernet-like Interface Types Apr 94 New Definitions of Managed Objects for the Ethernet-like Interface Types Apr 94 New Definitions of Managed Objects for the Ethernet-like Interface Types Modem Management (modemmgt) --------------------------- Charter Current status: active working group Chair(s): Mark Lewis Network Management Area Director(s) Marshall Rose Area Advisor Steven Waldbusser Mailing lists: General Discussion:modemmgt@Telebit.com To Subscribe: majordomo@Telebit.com In Body: subscribe modemmgt Archive: ftp.telebit.com:~/pub/modemmgt Description of Working Group: The Modem Management Working Group is chartered to define a MIB module for dial-up modems and similar dial-up devices. This MIB module will provide a set of objects that are the minimum necessary to provide the ability to monitor and control those devices, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing specifications including the RS-232-like, Character, PPP and other related MIB modules. It will consider enterprise-specific MIB modules which support modem-like devices. The working group will also consider the TSB Study Group 14's work on an OSI CMIS/CMIP object definition for V series DCEs entitled ``Managed Object Template for V-Series DCE's.'' Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Mar 94 Modem MIB Relational Database Management Systems MIB (rdbmsmib) ----------------------------------------------------- Charter Current status: active working group Chair(s): Robert Purvy Network Management Area Director(s) Marshall Rose Area Advisor Marshall T Rose Mailing lists: General Discussion:rdbmsmib@indetech.com To Subscribe: rdbmsmib-request@indetech.com Archive: Description of Working Group: The Relational Database Management System (RDBMS) MIB Working Group is chartered to develop a set of managed objects for RDBMS implementations. These objects will be the minimum necessary to provide the ability to monitor and control these systems, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. At its discretion, the working group may also define a small number of unsolicited notifications (traps) which carry these managed objects. However, the working group recognizes that traps are used sparingly in the SNMP framework. The working group recognizes that the structure of RDBMS implementations varies widely, and shall take special care that its definitions reflect a generic and consistent architectural model of RDBMS management rather than the structure of particular RDBMS implementations, or operating system or platform-specific issues. However, because of the inherent architectural differences between different implementations, the working group may have to separate the MIB definitions common to all RDBMSs from the definitions which would apply only to some RDBMSs. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 Mar 94 RDBMS-MIB Remote LAN Monitoring (rmonmib) ------------------------------- Charter Current status: active working group Chair(s): Mike Erlinger Network Management Area Director(s) Marshall Rose Area Advisor Steven Waldbusser Mailing lists: General Discussion:rmonmib@jarthur.claremont.edu To Subscribe: rmonmib-request@jarthur.claremont.edu Archive: jarthur.claremont.edu:/pub/rmon Description of Working Group: The RMON Working Group is chartered to prepare a recommendation to the IESG evaluating RFC 1271 (the RMON MIB) with respect to the standards track. The recommendation will document implementation, interoperability, and deployment experience. If this experience suggests that changes should be made to the document, a new draft may be prepared. The recommendation will report one of four outcomes: - that RFC 1271 should be advanced from proposed to draft status, without changes (if no problems are found); - that a draft prepared by the working group, should replace RFC 1271, and be designated a draft standard (if only minor changes are made); - that a draft prepared by the working group, should replace RFC 1271, and be designated a proposed standard (if major changes or feature enhancements are made); or, - that RFC 1271 should be designated as historic (if this technology is problematic). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 New Remote Network Monitoring Management Information Base SNA DLC Services MIB (snadlc) ----------------------------- Charter Current status: active working group Chair(s): Shannon Nix Network Management Area Director(s) Marshall Rose Area Advisor Ken Key Mailing lists: General Discussion:snadlcmib@cisco.com To Subscribe: snadlcmib-request@cisco.com Archive: Description of Working Group: The SNA DLC Working Group is chartered to define a set of managed objects for the SDLC and LLC-2 data link controls for SNA networks. These objects will be the minimum necessary to provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing enterprise-specific MIB modules that define objects which support management of these devices. The group may choose to consider any work done by the IEEE in the area of managed object definition for LLC-2. It will also make sure that its work is aligned with the SNA NAU Services MIB Working Group, due to the close relationship between the devices being worked on by the two groups. The working group recognizes that managed objects for other SNA data link controls and related components (e.g., QLLC, System/370 Channel, Data Link Switching, and ESCON) may need to be identified in the future. These objects are out of scope for the current charter; however, once the Group completes its charter, a new charter identifying some or all of these components may be considered. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Mar 94 Definitions of Managed Objects for SNA Data Link Control: SDLC SNA NAU Services MIB (snanau) ----------------------------- Charter Current status: active working group Chair(s): Zbigniew Kielczewski Deirdre Kostick Network Management Area Director(s) Marshall Rose Area Advisor David Perkins Mailing lists: General Discussion:snanaumib@thumper.bellcore.com To Subscribe: snanaumib-request@thumper.bellcore.com Archive: thumper.bellcore.com:pub/tob/snanaumib/archive Description of Working Group: The SNA NAU Services MIB Working Group is chartered to define a set of managed objects for PU type 2.1 LEN nodes and LU type 6.2 devices for SNA networks. These objects will be the minimum necessary to provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing enterprise-specific MIB modules that define objects which support management of these devices. It will also make sure that its work is aligned with the SNA DLC Services MIB Working Group, due to the close relationship between the devices being worked on by the two groups. The working group recognizes that managed objects for other components may need to be identified in the future. For example, APPN End and Network Nodes are not included. These objects are out of scope for the current charter; however, once the group completes its charter, a new charter identifying some or all of these components may be considered. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 93 Feb 94 Definitions of Managed Objects for SNA NAUs Uninterruptible Power Supply (upsmib) ------------------------------------- Charter Current status: active working group Chair(s): Jeff Case Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:ups-mib@cs.utk.edu To Subscribe: ups-mib-request@cs.utk.edu Archive: ucs.utk.edu:~/pub/ups-mib/mail-archive Description of Working Group: This working group will produce a document that defines MIB objects for use in monitoring and (possibly) controlling both high-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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 93 Feb 94 UPS Management Information Base Process for Organization of Internet Standards (poised) ------------------------------------------------------- Charter Current status: active working group Chair(s): Steve Crocker None Director(s) Phill Gross Mailing lists: General Discussion:poised@cnri.reston.va.us To Subscribe: poised-request@cnri.reston.va.us Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/* 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. Internet-Drafts: No Current Internet drafts. Benchmarking Methodology (bmwg) ------------------------------- Charter Current status: active working group Chair(s): Jim McQuaid Operational Requirements Area Director(s) Scott Bradner Michael O'Dell 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. Internet-Drafts: No Current Internet drafts. CIDR Deployment (cidrd) ----------------------- Charter Current status: active working group Chair(s): Jessica Yu Vince Fuller Operational Requirements Area Director(s) Scott Bradner Michael O'Dell Mailing lists: General Discussion:bgpd@merit.edu To Subscribe: bgpd-request@merit.edu Archive: merit.edu: ~/pub/bgpd-archive Description of Working Group: The CIDR Deployment Working Group (CIDRD) will be a forum for coordinating the deployment, engineering, and operation of classless routing protocols and procedures on the global Internet. This activity will include, but not be limited to: - deployment of CIDR addressing and routing in the global Internet. Will include coordination of deployment of new exterior routing protocols, such as BGP4, which support CIDR. - develop mechanisms and procedures for sharing operational information to aim the operation. - development of procedures, policies, and mechanisms to improve the utilization efficiency of the IPv4 address space. - work on longer-term strategies for hierarchical, CIDR-based addressing and routing. Examples include class-A subnetting and provider block sub-allocation along geographical/topological boundaries as is done for 193.0.0.0 and 194.0.0.0 in Europe. Initially, this working group will be simply the reincarnation of the BGP Deployment Working Group under a new name. Internet-Drafts: No Current Internet drafts. Generic Internet Service Description (gisd) ------------------------------------------- Charter Current status: active working group Chair(s): Daniel Karrenberg Tony Bates Operational Requirements Area Director(s) Scott Bradner Michael O'Dell Mailing lists: General Discussion:giss-wg@ripe.net To Subscribe: giss-wg-request@ripe.net Archive: Description of Working Group: GISD collects short descriptions of Internet service aspects. Internet service in GISD means the interaction of Internet service providers among themselves and with their users. GISD aims to provide a common frame of reference and vocabulary to talk about an Internet service. For each aspect of the Internet service, it describes different options for service provision in use in the current Internet. GISD is merely descriptive and does not proscribe or mandate. The GISD document is intended to be a living document, collecting the work of many contributors. The GISD Working Group will update and revise the GISD document to assist network service providers in a better understanding and description of what Interent service means. - Update and revise the GISD document that lists the areas and aspects of interest to TCP/IP network service providers. - Identify additional GISD areas and aspects appropriate to GISD. - Identify areas of overlap with other IETF working groups. - Create a reference document of GISD terms. - Establish procedures to ensure the ongoing maintenance of the document and identify an organization willing to do it. Internet-Drafts: No Current Internet drafts. Operational Statistics (opstat) ------------------------------- Charter Current status: active working group Chair(s): Henry Clark J. Nevil Brownlee Operational Requirements Area Director(s) Scott Bradner Michael O'Dell Mailing lists: General Discussion:oswg-l@wugate.wustl.edu To Subscribe: oswg-l-request@wugate.wustl.edu Archive: wuarchive.wustl.edu:~doc/mailing-lists/oswg-l Description of Working Group: Today there exists 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. Internet-Drafts: No Current Internet drafts. Border Gateway Protocol (bgp) ----------------------------- Charter Current status: active working group Chair(s): Yakov Rekhter Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:bgp@ans.net To Subscribe: bgp-request@ans.net 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 92 Apr 94 A Border Gateway Protocol 4 (BGP-4) Sep 92 Feb 94 Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4) Sep 92 Dec 93 BGP4/IDRP for IP---OSPF Interaction Sep 92 Apr 94 Application of the Border Gateway Protocol in the Internet Oct 93 New Application of the Border Gateway Protocol and IDRP for IP in the Internet Nov 93 Jan 94 BGP-4 protocol document roadmap and implementation experience IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- Charter Current status: active working group Chair(s): Steve Deering Greg Minshall Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:mobile-ip@ossi.com To Subscribe: mobile-ip-request@ossi.com Archive: loki.ossi.com:/pub/mobile-ip/ 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). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 New IP Mobility Support Mar 94 New Integrated Mobility Extension Mar 94 New Local Care-Of Address Extension IS-IS for IP Internets (isis) ----------------------------- Charter Current status: active working group Chair(s): Ross Callon Chris Gunner Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:isis@merit.edu To Subscribe: isis-request@merit.edu Archive: Description of Working Group: The ISIS Working Group will develop additions to the existing OSI IS-IS routing protocol to support IP environments and dual (OSI and IP) environments. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 91 Mar 94 Integrated IS-IS Management Information Base Aug 93 New Multiple Levels of Hierarchy with IS-IS Mar 94 New Integrated ISIS Protocol Analysis Mar 94 New Experience with the Integrated ISIS Protocol Inter-Domain Multicast Routing (idmr) ------------------------------------- Charter Current status: active working group Chair(s): Tony Ballardie Paul Francis Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:idmr@cs.ucl.ac.uk To Subscribe: idmr-request@cs.ucl.ac.uk Archive: cs.ucl.ac.uk:/darpa/idmr-archive.Z Description of Working Group: Existing inter-domain multicast routing protocols are not scalable to a large internetwork containing very large numbers of active wide-area groups. The purpose of the IDMR Working Group, therefore, is to discuss proposed inter-domain multicast routing protocols, and put forward one (or a hybrid of several/all) as a Proposed Standard protocol to the IESG. Several proposals have been made to date, including Core-Based Tree (CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable Reverse Path Multicasting (SRPM). Some of the above have yet to be reviewed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 New IGMP Router Extensions for Routing to Sparse Multicast-Groups Oct 93 New IGMP Router Extensions for Routing to Dense Multicast-Groups Mar 94 New Protocol Independent Multicast (PIM): Motivation and Architecture Mar 94 New Protocol Independent Multicast (PIM), Sparse Mode Protocol Specification Mar 94 New Protocol Independent Multicast (PIM), Dense Mode Protocol Specification Inter-Domain Policy Routing (idpr) ---------------------------------- Charter Current status: active working group Chair(s): Martha Steenstrup Routing Area Director(s) Joel Halpern 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 Oct 93 Definitions of Managed Objects for the Inter-Domain Policy Routing Protocol (Version 1) Multicast Extensions to OSPF (mospf) ------------------------------------ Charter Current status: active working group Chair(s): John Moy Routing Area Director(s) Joel Halpern 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). Internet-Drafts: No Current Internet drafts. OSI IDRP for IP Over IP (ipidrp) -------------------------------- Charter Current status: active working group Chair(s): Sue Hares Routing Area Director(s) Joel Halpern 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 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 with 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 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 the BGP-OSPF interactions document and IDRP - ISIS interactions document. 4) IDRP for IP Usage document (standards track) Most of the IDRP for IP Usage document will reference the CIDR (supernetting document) Internet-Draft. Any additional terms or protocol definitions needed for IDRP for IP will also be specified here. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Nov 93 IDRP for SIP Open Shortest Path First IGP (ospf) ----------------------------------- Charter Current status: active working group Chair(s): John Moy Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:ospf@gated.cornell.edu To Subscribe: ospf-request@gated.cornell.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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Apr 94 OSPF Version 2 Management Information Base Feb 94 Apr 94 IP Forwarding Table MIB Mar 94 New OSPF Point-to-MultiPoint Interface RIP Version II (ripv2) ---------------------- Charter Current status: active working group Chair(s): Gary Malkin Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:ietf-rip@xylogics.com To Subscribe: ietf-rip-request@xylogics.com Archive: xylogics.com:gmalkin/rip/rip-arc Description of Working Group: RIP Version 2 and the Version 2 MIB was approved as a Proposed Standard in January 1993. They were published as RFC 1388 and RFC 1389. Since the mimimum required period has elapsed for a protocol to remain as a Proposed Standard, RIP V2 can now be considered for advancement to Draft Standard. The RIP Version 2 Working Group will prepare a recommendation to the IESG evalating the standards track status of RIP Version 2 and the RIP Version 2 MIB. The recommendation will document implementation, interoperability and deployment experience as required by RFC 1264 ``Routing Protocol Criteria.'' This group is chartered to prepare revisions of RFC 1388, RIP Version 2, RFC 1389, the RIP Version 2 MIB, and RFC 1387, analysis of the protocol if necessary. The RIP Version 2 Working Group is further chartered to evaluate the proposal for ``Routing over Demand Circuits using RIP'' for standards track consideration. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 New RIP Version 2 Carrying Additional Information Oct 93 New RIP Version 2 MIB Extension Dec 93 New RIP Version 2 Protocol Analysis Routing over Large Clouds (rolc) -------------------------------- Charter Current status: active working group Chair(s): Andy Malis Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:rolc@network.com To Subscribe: rolc-request@network.com Archive: nsco.network.com:~/rolc/rolc.arc Description of Working Group: Summary: This group is created to analyse and propose solutions to those problems that arise when trying to perform IP routing over large "shared media" networks. Examples of these networks include SMDS, Frame Relay, X.25, and ATM. Definition: Internetwork Layer: To avoid confusion with multiple meanings of "network" layer, we will use the term "Internetwork" layer to unambiguously refer to that layer at which IP runs. This is the layer at which IP routing functions. This is also the layer at which CLNP, Decnet, ... all run. Large Cloud: A collection of "end-points", be that routers or hosts, connected over a fabric such that communication can be established, in the absence of policy restrictions, between any two such entities. This communication within a cloud takes place using addressing and capabilities below the "InterNetwork" layer. The connectivity may or may not require circuit setup before communication. Such a collection is considered large if it is infeasible for all routing entities on such a "cloud" to maintain "adjacencies" with all others. Examples include, but are not limited to, ATM, Frame Relay, SMDS, and X.25 public services. Description of Working Group: The group will investigate the operation of IP routing protocols and services over "Large Clouds". Whenever possible, solutions shall be applicable to a range of "cloud" services. That is, the goal is a single solution applicable to multiple kinds of large "clouds", be they public or private, and independent of the specific technology used to realize the "cloud" (even a very large bridged ethernet). It is also an objective that solutions, where possible, apply to network layer protocols other than IP. The problems the group will cover are: A) The architectural implications of allowing direct communication between entities which do not share a common IP NET number. The group will also entertain proposals on the use of a common IP net number. If (as many believe) it is infeasible, an effort to document the difficulties will be made. B) The routing/information protocol required to allow direct communication between two entities which were not directly exchanging routing information. This will include address resolution. The solution must couple closely to routing. It must take into account realistic connectivity policies. C) Operation of existing protocols between peers on such clouds. Are any changes necessary or desirable? If changes are required, they will be proposed to the relevant working group. D) Consideration of how policy restrictions and constraints (such as access control and policy-based routing paths) affect A, B, and C. The group will also review the applicability of the work to ISDN and POTS. These technologies have a prima-facia difference, in that the number of simultaneous connections is much smaller. The implications of this for routing and relaying at the internetwork layer will need to be explored further. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New NBMA Next Hop Resolution Protocol (NHRP) Source Demand Routing (sdr) --------------------------- Charter Current status: active working group Chair(s): Deborah Estrin Tony Li Routing Area Director(s) Joel Halpern Mailing lists: General Discussion:sdrp@caldera.usc.edu To Subscribe: sdrp-request@caldera.usc.edu Archive: jerico.usc.edu:~/pub/sdrp Description of Working Group: The SDR Working Group is chartered to specify and promote the use of SDRP (Source Demand Routing Protocol) as an inter-domain routing protocol capability in conjunction with IDRP and BGP inter-domain routing protocols. The purpose of SDR is to support source-initiated selection of inter-domain routes, to complement the intermediate node selection provided by BGP/IDRP. The goal of the SDR Working Group is to release the components of SDR as IETF Prototypes and to obtain operational experience with SDR in the Internet. Once there is enough experience with SDR, the working group will submit the SDR components to the IESG for standardization. SDR has four components: packet formats for protocol control messages and encapsulation of user datagrams, processing and forwarding of user data and control messages, routing information distribution/collection and route computation, and configuration and usage. The group's strategy is to: 1. Define the format, processing and forwarding of user datagram and control messages so that SDR can be used very early on as an efficient means of supporting ``configured'' inter-domain routes. User packets are encapsulated along with the source route and forwarded along the ``configured'' route. Routes are static at the inter-domain level, but are not static in terms of the intra-domain paths that packets will take between specified points in the SDR route. The impact of encapsulation on MTU, ICMP, performance, etc., are among the issues that must be evaluated before deployment. 2. Develop simple schemes for a) collecting dynamic domain-level connectivity information, and b) route construction based on this information, so that those domains that want to can make use of a richer, and dynamic set of SDR routes. 3. In parallel with 1 and 2, develop usage and configuration documents and prototypes that demonstrate the utility of static-SDR and simple-dynamic-SDR. 4. After gaining some experience with the simple schemes for distribution, develop a second generation of information distribution and route construction schemes. The Group hopes to benefit from discussions with IDPR and NIMROD developers at this future stage because the issues faced are similar. 5. The Group will also investigate the addition of security options into the SDRP forwarding and packet format specifications. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 92 Mar 94 Source Demand Routing: Packet Format and Forwarding Specification (Version 1). Sep 93 New BGP SDRP_SPEAKERS Attribute Authorization and Access Control (aac) -------------------------------------- Charter Current status: active working group Chair(s): Clifford Neuman Security Area Director(s) Jeffrey Schiller Mailing lists: General Discussion:ietf-aac@isi.edu To Subscribe: ietf-aac-request@isi.edu Archive: prospero.isi.edu:~/pub/aac/* Description of Working Group: The goal of the Authorization and Access Control Working Group is to develop guidelines and an Application Program Interface (API) through which network accessible applications can uniformly specify access control information. This API will allow applications to make access control decisions when clients are not local users, might not be members of a common organization, and often not known to the service or application in advance. Several authentication mechanisms are in place on the Internet, but most applications are written with local applications in mind and no guidelines exist for supporting authorization and access control based on the output of such authentication mechanisms. The CAT working group developed the GSS-API, a common API to support authentication. The AAC Working Group will develop a common API that accepts the identity of a client (perhaps the output of the GSS-API), a reference to an object to be accessed, and optionally an indication of the operation to be performed. The API will return a list of authorized operations or a yes/no answer that can be easily used by the application. A second, longer term purpose of the working group will be to examine evolving mechanisms and architectures for authorization in distributed systems and to establish criteria which enable interworking of confidence and trust across systems. The working group will develop additional goals an milestones related to this purpose and will submit a revised charter once the appropriate goals and milestones are determined. To the extent possible this additional work will encourage evolution toward credential formats that more readily allow support for or translation across multiple mechanisms. Internet-Drafts: No Current Internet drafts. Commercial Internet Protocol Security Option (cipso) ---------------------------------------------------- Charter Current status: active working group Chair(s): Ron Sharp Security Area Director(s) Jeffrey Schiller 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 US Department of Defense. CIPSO will be designed to provide labeling for the commercial, US civilian and non-US 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. Internet-Drafts: No Current Internet drafts. Common Authentication Technology (cat) -------------------------------------- Charter Current status: active working group Chair(s): John Linn Security Area Director(s) Jeffrey Schiller 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 93 Nov 93 FTP Security Extensions Mar 94 New The Kerberos Version 5 GSS-API Mechanism Internet Protocol Security Protocol (ipsec) ------------------------------------------- Charter Current status: active working group Chair(s): James Zmuda Paul Lambert Security Area Director(s) Jeffrey Schiller 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. Internet-Drafts: No Current Internet drafts. Network Access Server Requirements (nasreq) ------------------------------------------- Charter Current status: active working group Chair(s): Allan Rubens John Vollbrecht Security Area Director(s) Jeffrey Schiller Mailing lists: General Discussion:nas-req@merit.edu To Subscribe: nas-req-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 (NASs) 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, PCs 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 94 New Remote Authentication Dial In User Service (RADIUS) Privacy-Enhanced Electronic Mail (pem) -------------------------------------- Charter Current status: active working group Chair(s): Stephen Kent Security Area Director(s) Jeffrey Schiller 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 issued first as Internet-Drafts.) Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Mar 94 PEM Security Services and MIME Oct 93 New An Alternative PEM MIME Integration DNS Security (dnssec) --------------------- Charter Current status: active working group Chair(s): James Galvin Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:dns-security@tis.com To Subscribe: dns-security-request@tis.com Archive: ftp.tis.com:/pub/dns-security Description of Working Group: The Domain Name System (DNS) Security Working Group (dnssec) will specify enhancements to the DNS protocol to protect the DNS against unauthorized modification of data and against masquerading of DNS data origin. That is, it will add data integrity and authentication capabilities to the DNS. The specific mechanism to be added to the DNS protocol will be a digital signature. The digital signature service will be added such that the DNS resource records will be signed and, by distributing the signatures with the records, remote sites can verify the signatures and thus have confidence in the accuracy of the records received. There are at least two issues to be explored and resolved. First, should the records be signed by the primary or secondary (or both) servers distributing the resource records, or should they be signed by the start of authority for the zone of the records. This issue is relevant since there are servers for sites that are not IP connected. Second, the mechanism with which to distribute the public keys necessary to verify the digital signatures must be identified. Two essential assumptions have been identified. First, backward compatibility and co-existence with DNS servers and clients that do not support the proposed security services is required. Second, data in the DNS is considered public information. This latter assumption means that discussions and proposals involving data confidentiality and access control are explicitly outside the scope of this working group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 Mar 94 Domain Name System Protocol Security Extensions MHS-DS (mhsds) -------------- Charter Current status: active working group Chair(s): Kevin Jordan Harald Alvestrand Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:mhs-ds@mercury.udev.cdc.com To Subscribe: mhs-ds-request@mercury.udev.cdc.com Archive: mercury.udev.cdc.com:~/pub/archives/mhs-ds-archive Description of Working Group: The MHS-DS Working Group works on issues relating to Message Handling Services use of Directory Services. The Message Handling Services are primarily X.400, but issues relating to RFC 822 use of Directory and Directory support for RFC 822 and X.400 interworking are in the scope of the group. Directory and Directory Services refer to the services based upon the CCITT X.500 recommendations and additional ISO standards, stable implementation agreements, and RFCs, as specified by the OSI-DS Working Group. The major aims of the MHS-DS Working Group are: 1. Define a set of specifications to enable effective, large-scale deployment of X.400. 2. Study issues associated with supporting X.400 communities which lack access to X.500 Directory, and define requirements for tools which: a) extract information from the X.500 Directory for use by non-X.500 applications, b) upload information into the X.500 Directory. 3. Coordinate a pilot project which deploys MHS information into the X.500 Directory and uses it to facilitate mail routing and address mapping. The results of this pilot will be documented, and experience gained from the project will be fed back into the Internet specifications created by the working group. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 92 Mar 94 Use of the Directory to support mapping between X.400 and RFC 822 Addresses Apr 92 Mar 94 MHS use of the Directory to support distribution lists Apr 92 Mar 94 A simple profile for MHS use of Directory Apr 92 Mar 94 Representing Tables and Subtrees in the Directory Apr 92 Mar 94 Representing the O/R Address hierarchy in the Directory Information Tree Apr 92 Mar 94 MHS use of Directory to support MHS Routing Minimal OSI Upper-Layers (thinosi) ---------------------------------- Charter Current status: active working group Chair(s): Peter Furniss Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:thinosi@ulcc.ac.uk To Subscribe: thinosi-request@ulcc.ac.uk Archive: pluto.ulcc.ac.uk:/ulcc/thinosi/thinosi-mail-archive.txt 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 standard 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, of the mapping of X Window System protocol over OSI upper-layers, is based on this principle. 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 the byte-stream specification, but to include DAP. The level of functionality of this is to be determined. An important aspect of the group's work is to find out if it is possible to produce useful and concise specifications 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 93 Mar 94 Octet sequences for upper-layer OSI to support basic communications applications Nov 93 New Use of upper-layer OSI protocols to support basic communications applications ONC Remote Procedure Call (oncrpc) ---------------------------------- Charter Current status: active working group Chair(s): Raj Srinivasan Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:oncrpc-wg@sunroof.eng.sun.com To Subscribe: oncrpc-wg-request@sunroof.eng.sun.com Archive: playground.sun.com: pub/oncrpc Description of Working Group: The purpose of the ONC-RPC Working Group is to update the RFCs that describe ONC RPC to reflect the current state of the deployed and accepted technology, and submit them for Internet standardization. ONC RPC is currently described in the following RFCs: RFC 1057: RPC: Remote Procedure Call Protocol Specification Version 2 RFC 1014: XDR: External Data Representation Standard The focus of the ONC-RPC Working Group is to document and standardize the current ONC RPC protocols. It not the intent of this working group to develop extensions to these protocols. However, once these tasks are completed, discussions of future enhancements are expected. These discussions could lead to a follow on working group. Background: ONC RPC is a Remote Procedure Call technology that originated in Sun Microsystems in the early 1980s. ONC RPC was modelled on Xerox's Courier RPC protocols. It has been widely deployed on platforms from most major workstation vendors. It has been implemented on MS-DOS, Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and practically all flavors of UNIX, among others. Sun Microsystems has given the ownership of ONC RPC and change control over the ONC RPC protocols to the IETF. Note: ONC stands for "Open Network Computing". Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 New RPC: Remote Procedure Call Protocol Specification Version 2 Mar 94 New XDR: External Data Representation Standard Service Location Protocol (svrloc) ---------------------------------- Charter Current status: active working group Chair(s): John Veizades Scott Kaplan Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:srv-location@ftp.com To Subscribe: srv-location-request@ftp.com 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 service 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 service 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 service location and then determine the correct action in their view whether it be to use current protocols to suggest a service location architecture or to design a new protocol to compliment current architectures. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Mar 94 Service Location Protocol Trusted Network File Systems (tnfs) ----------------------------------- Charter Current status: active working group Chair(s): Fred Glover Service Applications Area Director(s) Dave Crocker 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 Mar 93 A Specification of Trusted NFS (TNFS) Protocol Extensions Audio/Video Transport (avt) --------------------------- Charter Current status: active working group Chair(s): Stephen Casner Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: nic.es.net:pub/mailing-lists/mail-archive/rem-conf Description of Working Group: The Audio/Video Transport Working Group was formed to specify experimental protocols for real-time transmission of audio and video over UDP and IP multicast. The focus of this group is near-term and its purpose is to integrate and coordinate the current 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 Oct 93 Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications Dec 92 Oct 93 RTP: A Transport Protocol for Real-Time Applications Dec 92 Sep 93 Media Encodings Dec 92 Oct 93 Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Mar 93 Dec 93 Packetization of H.261 video streams Multiparty Multimedia Session Control (mmusic) ---------------------------------------------- Charter Current status: active working group Chair(s): Eve Schooler Abel Weinrib Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:confctrl@isi.edu To Subscribe: confctrl-request@isi.edu Archive: venera.isi.edu:~/confctrl/confcrtl.mail Description of Working Group: The demand for Internet teleconferencing has arrived, yet an infrastructure to support this demand is barely in place. Multimedia session control, defined as the management and coordination of multiple sessions and their multiple users in multiple media (e.g., audio, video), is one component of the infrastructure. The Multiparty Multimedia Session Control Working Group is chartered to design and specify a protocol to perform these functions. The protocol will provide negotiation for session membership, underlying communication topology and media configuration. In particular, the protocol will support a user initiating a multimedia multiparty session with other users (``calling'' other users) over the Internet by allowing a teleconferencing application on one workstation to explicitly rendezvous with teleconferencing applications running on remote workstations. Defining a standard protocol will enable session-level interoperability between different teleconferencing implementations. The focus of the working group is to design a session negotiation protocol that is tailored to support tightly-controlled conferences. The MBONE currently carries primarily loosely-controlled sessions, i.e., sessions with little to no interaction among members and with no arbitration facility, security, or coordination of quality-of-service options for time-critical media. Users may learn of available sessions using the ``sd'' utility or other out of band mechanisms (e.g., email). However, there is clearly also a need for tightly-controlled sessions that provide mechanisms for directly contacting other users to initiate a session and for negotiating conference parameters such as membership, media encodings and encryption keys. In addition, these sessions should support renegotiation during a session, for example to add or delete members or change the media encoding. It is possible that the protocol will, in the limiting case, also support loosely-controlled sessions. The main goal of the working group will be to specify the session control protocol for use within teleconferencing software over the Internet. The working group will focus on the aspects of the session control problem that are well understood, while keeping an eye on evolving research issues. Toward this end, the working group has made an inventory of existing conferencing systems and their session control protocols. The working group will document the requirements of the existing prototypes as a basis for the protocol development. The working group will iteratively refine the protocol based on implementation and operational experience. Furthermore, the working group will coordinate with other efforts related to multimedia conferencing, such as directory services for cataloguing users and conferences, the RTP and RTCP protocols developed by the Audio/Video Transport Working Group, resource reservation and management at the network level, and schemes for multicast address allocation. Internet-Drafts: No Current Internet drafts. RSVP - Resource Reservation Setup Protocol (rsvp) ------------------------------------------------- Charter Current status: active working group Chair(s): Robert Braden Lixia Zhang Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:rsvp@isi.edu To Subscribe: rsvp-request@isi.edu Archive: ftp.isi.edu:rsvp/rsvp.mail Description of Working Group: RSVP is a resource reservation setup protocol for the Internet. Its major features include (1) the use of 'soft state' in the routers, (2) receiver-controlled reservation requests, (3) flexible control over sharing of reservations and forwarding of subflows, and (4) the use of IP multicast for data distribution. The primary purpose of this working group is to evolve the RSVP specification and to introduce it into the Internet standards track. The working group will also serve as a meeting place and forum for those developing and experimenting with RSVP implementations. The task of the RSVP working group, creating a robust specification for real-world implementations of RSVP, will require liaison with two other efforts: (1) continuing R&D work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of realtime applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups. Internet-Drafts: No Current Internet drafts. TCP Large Windows (tcplw) ------------------------- Charter Current status: active working group Chair(s): David Borman Transport Area Director(s) Allison Mankin 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 e2e-interest@isi.edu mailing list. The TCP Large Windows Working Group is being resurrected for a one time meeting, to review and if appropriate, approve this new document. Internet-Drafts: No Current Internet drafts. Integrated Directory Services (ids) ----------------------------------- Charter Current status: active working group 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 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 Working Group will also contribute to the administrative and maintenance issues of directory service offerings by publishing guidelines on directory data integrity, maintenance, security, and privacy and legal issues for users and administrators of directories. IDS will also assume responsibility for the completion of the outstanding Directory Information Services Infrastructure (DISI) Internet-Drafts, which are all specific to X.500, 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Apr 94 A Revised Catalog of Available X.500 Implementations Integration of Internet Information Resources (iiir) ---------------------------------------------------- Charter Current status: active working group Chair(s): Chris Weider Kevin Gamiel 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Oct 93 Resource Transponders Mar 93 Oct 93 A Vision of an Integrated Internet Information Service Oct 93 New WAIS over Z39.50-1988 Nov 93 New Hypertext Transfer Protocol (HTTP) A Stateless Search, Retrieve and Manipulation Protocol Internet Anonymous FTP Archives (iafa) -------------------------------------- Charter Current status: active working group 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/mailing-lists/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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 93 Feb 94 How to Use Anonymous FTP Aug 93 New Publishing Information on the Internet with Anonymous FTP Aug 93 New Data Element Templates for Internet Information Objects Internet School Networking (isn) -------------------------------- Charter Current status: active working group Chair(s): Jennifer Sellers Arthur St. George User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:isn-wg@unmvma.unm.edu To Subscribe: listserv@unmvma.unm.edu In Body: subscribe isn-wg Archive: Description of Working Group: The Internet School Networking Working Group is chartered to address relevant issues related to the connection of primary/secondary schools worldwide to the Internet. The key audiences include network service providers and educational policy makers responsible for network access and use. The key areas of focus for this group are advocacy and articulation. 1. Advocacy. The ISN-WG will facilitate dialog between the primary/ secondary education community and the Internet engineering community in order to identify and fulfill the needs of the primary/secondary school community. 2. Articulation. Informed by the group's experience and with input from other IETF working groups, the ISN-WG will articulate solutions to the challenges a school may experience in seeking and gaining a connection to the Internet, as well as the benefits of such a connection. Advantages to Internet connectivity may be articulated by means of pointers to such services as user interfaces, directories, organizations, and training programs, as well as to other resources. Articulation will most often be in the form of periodic documents that address key issues of interest to the school networking community. Representative issues to be addressed by the WG include connectivity models, educational directories, and acceptable use policies. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 New K-12 Internetworking Guidelines Apr 94 New Acceptable Use Policy Definition Network Information Services Infrastructure (nisi) -------------------------------------------------- Charter Current status: active working group 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. A primary goal of the group is to facilitate the development of relationships between NICs that will result in the presentation of a seamless user support service. NISI will work with all NICs, including the InterNIC, to achieve the goal of a fully-functioning, cooperative mesh of worldwide NICs. In addition to creating policies for interaction, NISI will address areas such as common information formats, methods of access, user interface, and issues relating to security and privacy of Internet databases. Internet-Drafts: No Current Internet drafts. Network Training Materials (trainmat) ------------------------------------- Charter Current status: active working group Chair(s): Jill Foster Mark Prior 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: 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 mix of 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 IAFA style Data Elements 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. Internet-Drafts: No Current Internet drafts. Networked Information Retrieval (nir) ------------------------------------- Charter Current status: active working group Chair(s): Jill Foster Kevin Gamiel User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:nir@mailbase.ac.uk To Subscribe: mailbase@mailbase.ac.uk In Body: subscribe nir Archive: mailbase.ac.uk:~/pub/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 Working 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 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 NIR tools, 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.). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Mar 94 A Status Report on Networked Information Retrieval: Tools and Groups Uniform Resource Identifiers (uri) ---------------------------------- Charter Current status: active working group 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/mailing-lists/uri-archive Description of Working Group: The Uniform Resource Identifiers 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 standard representations of Uniform Resource Locators (URLs) 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, users and network-based tools to uniquely identify specific resources on the Internet, and 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 93 Apr 94 Uniform Resource Locators (URL) A Syntax for the Expression of Access Information of Objects on the Network May 93 Oct 93 Uniform Resource Names Apr 94 New Specification of Uniform Resource Characteristics Apr 94 New URN to URC resolution scenario User Documents Revisions (userdoc2) ----------------------------------- Charter Current status: active working group Chair(s): Ellen Hoffman Lenore Jackson User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:user-doc@merit.edu To Subscribe: user-doc-request@merit.edu Archive: Description of Working Group: The focus of the USERDOC2 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 USERDOC2 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 New RECENT INTERNET PUBLICATIONS, MARCH 1994-- A Select Bibliography of Internetworking Readings User Services (uswg) -------------------- Charter Current status: active working group Chair(s): Joyce K. Reynolds User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:us-wg@nic.near.net To Subscribe: us-wg-request@nic.near.net Archive: ftp.near.net:/mail-archives/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); and - Not duplicate existing or previous efforts. (2) Create working groups or other focus groups to carry out projects deemed worthy of pursuing. (3) Provide a forum in which user services providers can discuss and identify common concerns. Internet-Drafts: No Current Internet drafts. Whois and Network Information Lookup Service (wnils) ---------------------------------------------------- Charter Current status: active working group 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:~/archive/wnils 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Oct 93 Architecture of the Whois++ Index Service Apr 94 New Architecture of the WHOIS++ service