Access/Synchronization of the Internet Directories (asid) --------------------------------------------------------- Charter Current status: active working group Chair(s): Tim Howes Applications Area Director(s): John Klensin Erik Huizer Area Advisor Erik Huizer Mailing lists: General Discussion:ietf-asid@umich.edu To Subscribe: ietf-asid-request@umich.edu Archive: ftp://terminator.rs.itd.umich.edu/ietf-asid/archive Description of Working Group: There is a clear need to provide and deploy a well managed Directory Service for the Internet. A so-called White Pages Directory Service providing people- and organizational- information, is especially long overdue. While the ultimate goal is a general Directory Service for the Internet, this is too ambitious a goal to be tackled by a single working group. Therefore ASID will keep a tight focus on access and synchronization protocols for an Internet White Pages Directory Service. Other related working groups will be formed in the Applications Area that will deal with other aspects of the Internet Directory Service. Currently there are various protocols under development in the Internet that aim to provide such a service: Internet X.500, WHOIS++, NETFIND, CSO, RWHOIS, etc. To allow these services to evolve to a ubiquitous Internet Directory Service, a hybrid system that allows interaction between the various different services is a requirement. The ASID Working Group will define, evolve, and standardize protocols, algorithms and access methods for a White Pages Directory Service on the Internet. The following protocols (some still under development, some completed by other IETF working groups) will be considered by the working group: - Lightweight Directory Acces Protocols (LDAP and Connectionless LDAP) - User Friendly Naming (UFN) and User Friendly Searching (UFS) - The SOLO directory access and searching system - The WHOIS++ directory service The following work items are handled by other groups, and as such are outside the scope of this group. However their results are important to the development of a White Pages Directory Service, and will be taken into account: - The Hypertext Transfer Protocol (HTTP) - The UR* definitions - The NETFIND directory service The group will focus on harmonizing, evolving and developing protocols and algorithms that deal with access to and synchronization of Directory Service, both ad hoc and standards-based, with a goal of converging where possible towards a hybrid system that ties together various forms of Directory Service. Clearly, protocol-level integration is only part of the solution. But to keep this group tightly focused, harmonizing directory information and service models will be tackled by other working groups. Internet-Drafts: No Current Internet-Drafts. Electronic Data Interchange (edi) --------------------------------- Charter Current status: active working group Chair(s): Dave Crocker Applications Area Director(s): John Klensin Erik Huizer Area Advisor John Klensin Mailing lists: General Discussion:ietf-edi@byu.edu To Subscribe: listserv@byu.edu In Body: sub ietf-edi Archive: ftp.sterling.com:edi/lists Description of Working Group: Electronic Data Interchange (EDI) is a set of protocols for conducting highly structured inter-organization exchanges, such as for making purchases. The working group will produce specifications for the use of EDI standards over the Internet, with an initial focus on the transport of EDI via Internet e-mail. The EDI community is large, diverse and well-established. This working group effort is explicitly NOT intending to specify or modify any of the details of EDI protocols themselves. Instead, it will focus on the requirements for proper carriage of EDI over the Internet, attending only to issues of encapsulation, addressing, security and the like. Initial efforts by the working group will focus on two deliverables: specification for the carriage of various EDI content via MIME-based e-mail, and a discussion document, considering issues in the use of EDI over the Internet. The usage document will cover such issues as addressing and security. Internet-Drafts: No Current Internet-Drafts. 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 e-mail 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 e-mail access protocol provides a uniform, operating system-independent way of manipulating message data (e-mail 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 e-mail. 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 1993 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 ------ ------- ------------------------------------------ Feb 94 Aug 94 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 Jun 94 Jun 94 IMAP4 Authentication mechanisms Jun 94 New IMAP4 COMPATIBILITY WITH IMAP2 AND IMAP2BIS Jun 94 New SYNCHRONIZATION OPERATIONS FOR DISCONNECTED IMAP4 CLIENTS Aug 94 New DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4 Internet White Pages Requirements (whip) ---------------------------------------- Charter Current status: active working group Chair(s): Tony Genovese Applications Area Director(s): John Klensin Erik Huizer Area Advisor Erik Huizer Mailing lists: General Discussion:wps@SURFnet.nl To Subscribe: wps-request@SURFnet.nl Archive: ftp.es.net:/pub/ietf/wps Description of Working Group: At the Seattle IETF in March 1994, a BOF was held on the establishment of a Simple Internet White Pages Service (SIWPS). A basic model was proposed, and further work was defined. One of the requested work items was a definition of the basic requirements for such a service. This working group is chartered to produce a single Informational RFC capturing these basic requirements. It will do so without prejudice to existing solutions or implementations. The requirements document should only contain the basic requirements for a SIWPS. The list is not meant to be exhaustive, but rather should provide a set of minimum requirements to guide the overall structure of white pages service effort; these requirements can be used by related IETF working groups to start to define the Internet white pages service. The working group is meant to be short-lived and to produce only the one document. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 94 New A Specification for the Simple Internet White Pages Service. MHS-DS (mhsds) -------------- Charter Current status: active working group Chair(s): Kevin Jordan Harald Alvestrand Applications Area Director(s): John Klensin Erik Huizer 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, and (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 A simple profile for MHS use of Directory Apr 92 Sep 94 Representing Tables and Subtrees in the X.500 Directory Apr 92 Sep 94 Representing the O/R Address hierarchy in the X.500 Directory Information Tree Apr 92 Sep 94 Use of the X.500 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 Jul 94 MHS use of Directory to support MHS Routing Jun 93 Aug 94 Introducing Project Long Bud: Internet Pilot Project for the Deployment of X.500 Directory Information in Support of X.400 Routing Mail Extensions (mailext) ------------------------- Charter Current status: active working group Chair(s): C. Allan Cargille Applications Area Director(s): John Klensin Erik Huizer Area Advisor John Klensin Mailing lists: General Discussion:mailext@cs.wisc.edu To Subscribe: listserv@cs.wisc.edu In Body: subscribe mailext Your Full Name Archive: Description of Working Group: The Mail Extensions Working Group will review, refine as needed, and then make a recommendation on standardization of several recent proposals for standards-track compatible extensions to SMTP (via the Service Extensions mechanism), MIME (via new Content Subtypes), and MIME-MHS (via MIME Content Subtypes and usage rules). It will also act as the review body for several documents that clarify and provide applicability statements about the use of Internet mail: that work will ultimately lead to an update for the mail-related section of RFC 1123. Part of that effort involves RARE WG-MSG documents that address the Internet's installed electronic mail infrastructure. Since such documents should not be processed in RARE alone, this working group will act as the IETF focus for reviewing them. Initial drafts of all of the documents that the working group is expected to review have already been, or will soon be, published. The working group will be starting with documents that have been prepared as individual (or spontaneous design team) contributions. It is not expected to initiate new work. On the other hand, it is expected to make explicit "not ready for standardization" or "inappropriate for standardization" recommendations if that is appropriate. The working group will be initialized with the following Internet- Drafts or their successors, listed alphabetically. A major purpose of its first meeting is to prune or add to this list. draft-freed-ftbp-00.txt draft-freed-smtp-pipeline-00.txt draft-houttuin-mailservers-02.txt draft-rare-msg-a-bombs-00.txt draft-rare-msg-c-bombs-00.txt draft-vaudreuil-smtp-binary-04.txt draft-vaudreuil-smtp-stream-00.txt Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 93 New Characters and character sets for various languages Oct 93 Aug 94 SMTP Service Extensions for Transmission of Large and Binary MIME Messages Dec 93 New Tags for the identification of languages Jul 94 Sep 94 SMTP 521 reply code Aug 94 New SMTP Service Extension for Checkpoint/Restart Aug 94 New SMTP Service Extension for Command Pipelining 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 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 to the successor of 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 working group turn out to be impossible to accomodate in the RFC 1327 revision, that would be cause for reviewing both sets of specifications. Additional items 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 Jul 94 An Extensible Message Format for Delivery Status Notifications Aug 94 New Multipart/Report 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 Jul 94 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 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: No Current Internet-Drafts. 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 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 Working Group), and make necessary recommendations to insure continued operations. Internet-Drafts: No Current Internet-Drafts. 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 Apr 94 SIPP Program Interfaces for BSD Systems 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 Jul 94 Simple Internet Protocol Plus (SIPP): Addressing Architecture Jan 94 Sep 94 IPv6 Security Architecture Jan 94 Aug 94 IPv6 Authentication Header Jan 94 Apr 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 Jul 94 Simple Internet Protocol Plus (SIPP) Specification (128-bit address version) 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 Jul 94 New Simple SIPP Transition (SST) Overview Common Architecture for Next Generation IP (catnip) --------------------------------------------------- Charter Current status: active working group Chair(s): Vladimir Sukonnik Internet Area Director(s): Stev Knowles Claudio Topolcic 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 DNS IXFR, Notification, and Dynamic Update (dnsind) --------------------------------------------------- Charter Current status: active working group Chair(s): Randy Bush Internet Area Director(s): Stev Knowles Claudio Topolcic Mailing lists: General Discussion:namedroppers@internic.net To Subscribe: namedroppers-request@internic.net Archive: ftp.merit.edu:/internet/documents/ietf/dns Description of Working Group: The DNS Incremental Transfer, Notify, and Dynamic Update Working Group is concerned with three areas of future DNS protocol development: Incremental Zone Transfer - As the sizes of some zone files have grown quite large, it is believed that a protocol addition to allow the transfer of only the changed subset of a zone will reduce net traffic and the load on critical servers. Change Notification - There can be large time intervals during which at least one secondary has data that is inconsistent with the primary. The proposed ``notify'' mechanism (where the primary sends a message to known secondaries) facilitates fast convergence of servers vis-a-vis consistency of data in the zones. Dynamic Update - The need to frequently update small portions of a large zone and to have those updates propagate is perceived. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 94 New Dynamic Updates in the Domain Name System (DNS): Architecture and Mechanism Jul 94 New Implementation of Domain Name System (DNS) Dynamic Updates 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 (ipatm) ------------------------------------------ Charter Current status: active working group Chair(s): Mark Laubach Internet Area Director(s): Stev Knowles Claudio Topolcic Mailing lists: General Discussion:ip-atm@hpl.hp.com To Subscribe: ip-atm-request@hpl.hp.com Archive: Send message to ip-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 ------ ------- ------------------------------------------ Apr 94 Jul 94 ATM Signaling Support for IP over ATM Internet Stream Protocol V2 (st2) --------------------------------- Charter Current status: active working group Chair(s): Lou Berger Luca Delgrossi 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 Internet Stream Protocol V2 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-II 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-II specification and makes it easier to implement ST-II in a manner that is likely to be interoperable with other ST-II implementations. The group intends to address several areas of the ST-II 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-II. These modifications are expected to reduce implementation time and to improve the utility and interoperability of existing and future ST-II implementations. The working group may also provide guidance on the use of standard routing protocols to support ST-II, 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-II developers and application developers will be solicited to help clarify issues that the working group should address. It is the goal of the group to produce a refined ST-II 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-II 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-II. 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 Apr 94 PPP in Frame Relay Sep 93 May 94 The PPP Multilink Protocol (MP) Sep 93 Jun 94 The PPP NetBIOS Frames Control Protocol (NBFCP) Oct 93 Sep 94 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 Sep 94 PPP BSD Compression Protocol Feb 94 Sep 94 PPP LCP Option for Data Encapsulation Selection Mar 94 New The Generic Athentication Protocol (GAP) Mar 94 New The Arbitrary Handshake Authentication (AHA) protocol Mar 94 May 94 PPP Magnalink Variable Resource Compression Mar 94 New PPP Kerberos Authentication Protocol (KAP) Apr 94 Jul 94 Proposal for Callback Control Protocol (CBCP). Jul 94 New The PPP AppleTalk Control Protocol (ATCP) Jul 94 New The PPP Banyan Vines Control Protocol (BVCP) Jul 94 New PPP Kerberos version 4 Authentication Protocol (KAPv4) 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 publishing the existing draft as an Historic RFC, then updating it to include references to more recent work, such as OSPF, BGP, multicast, etc. Unlike other groups, this is recognized as an on-going effort that should result in a series of drafts. It is expected that a revised requirements draft will be published on a regular basis. 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 Service Location Protocol (svrloc) ---------------------------------- Charter Current status: active working group Chair(s): John Veizades Scott Kaplan Internet Area Director(s): Stev Knowles Claudio Topolcic Mailing lists: General Discussion:srv-location@ftp.com To Subscribe: srv-location-request@ftp.com Archive: Description of Working Group: The Service Location Protocol 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 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 Jul 94 Service Location Protocol TCP/UDP Over CLNP-Addressed Networks (tuba) ------------------------------------------- Charter Current status: active working group Chair(s): Mark Knopper Peter Ford Internet Area Director(s): Stev Knowles Claudio Topolcic 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 IPv4 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 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 IPv4 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 May 94 Host Group Extensions for CLNP Multicasting Mar 94 Jul 94 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 May 94 Jun 94 CLNP Path MTU Discovery May 94 New Integrated Network Layer Security Protocol For TUBA May 94 New TUBA Mobility Support Jul 94 New Extensions to MIB-II for TUBA/CLNP systems 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 Standard 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 Standard to Standard 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 Jul 94 Management Information Base for Management of Network Connections Jul 94 New IEEE 802.5 MIB Sep 94 New IEEE 802.5 Station Source Routing MIB Printer MIB (printmib) ---------------------- Charter Current status: active working group Chair(s): Joel Gyllenskog Network Management Area Director(s): Marshall Rose Area Advisor Steven Waldbusser Mailing lists: General Discussion:pmi@hpbs907.boi.hp.com To Subscribe: pmi-request@hpbs907.boi.hp.com Archive: ftp://ftpboi.external.hp.com:/pub/snmpmib Description of Working Group: The Printer MIB Working Group is chartered to develop a set of managed objects for networked printers. These objects will be the minimum necessary to provide the ability to monitor and control these systems, providing fault, configuration and performance management, and will be consistent with the SNMP framework and existing SNMP standards. At its discretion, the working group may also define a small number of unsolicited notifications (traps) which carry these managed objects. However, the working group recognizes that traps are used sparingly in the SNMP framework. The working group recognizes that the area of networked printers is quite diverse. However, the working group is specifically confined to defining managed objects that instrument critical information about: - printer engine - interpreters - media - input sources - output destinations - I/O interfaces Further, the working group is specifically prohibited from defining managed objects that define instrumentation about: - other marking technologies (e.g., those that mark onto film) - fonts - spooling - print job management Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 94 Aug 94 Printer MIB Remote Network 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@cs.hmc.edu To Subscribe: rmonmib-request@cs.hmc.edu Archive: jarthur.cs.hmc.edu:/pub/rmon Description of Working Group: The RMON MIB Working Group is chartered to define a set of managed objects for remote monitoring of networks. These objects will be the minimum necessary to provide the ability to monitor multiple network layers of traffic in remote networks; providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing MIB modules that define objects which support similar management, e.g., RFC 1271 and RFC 1513 and efforts in other areas, e.g., the accounting and operational statistics activities. It is possible that this RMON will not be backwards compatible with existing RMON RFCs, but the reasons for any such incompatibility will be well documented. The following list of features for this RMON has been previously discussed in relation to existing RMON functionality and is included to focus these RMON activities. It is recognized that other issues may be considered and that certain of the following issues may not be part of the final specification: 1) Protocol-type distribution through all seven layers of the ISO model. 2) Address mapping - Network Layer to Data Link (MAC) Layer and vice-versa. 3) Mechanisms that enable the detection of duplicate addresses or address changes. 4) The relationship of the Manager-to-Manager MIB in SNMPv2 and associated RMON alarm related activities. 5) Host Table for the Network Layer and the Transport Layer. 6) Provide a simple mechanism for the specification of event/trap destinations 7) Address the issue of the filter mechanism being constrained by bit-to-bit packet matching, which presents a problem with variable- length packets. 8) Consider how RMON could benefit network security, for example: using the RMON History to provide an accountability and audit trail up to the Transport Layer. 9) Provide performance metrics for the client-server environment. 10) Concerns of hardware implementation should be considered. For example, optimization of the filter and capture group could reduce the cost of the CPU and improve performance. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 Jun 94 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 Services MIB Working Group is chartered to define a set of managed objects for the SDLC and LLC-2 data link controls for SNA networks. These objects will be the minimum necessary to provide the ability to monitor and control those devices, providing fault, configuration, and performance management, and will be consistent with the SNMP framework and existing SNMP standards. The working group will consider existing enterprise-specific MIB modules that define objects which support management of these devices. The group may choose to consider any work done by the IEEE in the area of managed object definition for LLC-2. It will also make sure that its work is aligned with the SNA NAU Services MIB Working Group, due to the close relationship between the devices being worked on by the two groups. The working group recognizes that managed objects for other SNA data link controls and related components (e.g., QLLC, System/370 Channel, Data Link Switching, and ESCON) may need to be identified in the future. These objects are out of scope for the current charter; however, once the group completes its charter, a new charter identifying some or all of these components may be considered. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Jun 94 Definitions of Managed Objects for SNA Data Link Control: SDLC Jul 94 New Definitions of Managed Objects for SNA Data Link Control: LLC 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 ------ ------- ------------------------------------------ Jul 94 New Definitions of Managed Objects for APPC Process for Organization of Internet Standards (poised) ------------------------------------------------------- Charter Current status: active working group Chair(s): Steve Crocker Mel Pleasant None Director(s): Paul Mockapetris Mailing lists: General Discussion:poised@tis.com To Subscribe: poised-request@tis.com Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/* Description of Working Group: In 1992 and 1993, the POISED effort revised the responsibilities of the IESG and IAB and instituted a selection process for filling positions on these bodies. The ISOC Trustees gave interim approval to these arrangements and asked that we revisit, revise and formalize the arrangements after two rounds of selection had been completed. The POISED Working Group will now review the current rules, propose charters and rules for the IESG, IETF, IAB, IRSG, and IRTF, and submit them to the ISOC Trustees after approval by the IETF. There appears to be general consensus that the current assignments of responsibility and the selection process are working moderately well, so it is not anticipated that there will be large changes. Nonetheless, some issues have been raised and need review. Among these are: o There is a complex interplay between the IETF area structure and the selection process for the IESG. The IESG has the power to create, split, merge and remove areas, but the nominations committee has the responsibility to fill positions. The IESG needs some flexibility to balance work loads, use its people effectively, and meet the changing needs of the IETF. The current rules are not completely clear as to how to handle all of the likely situations; these need to be spelled out and agreed to. o The nominations committee has non-voting liaisons from the IESG and IAB. Both nominations committees also had current IAB or IESG members, who volunteered and were selected at random, as voting members. It has been suggested that current IESG and IAB members carry too much weight in the deliberations and should be barred from serving on the nominations committee. o The selection and role of the nominations committee chair is somewhat unclear. In particular, what power does the chair have to deal with unresponsive committee members and/or to resolve disputes? o At what point, if any, does the nominations committee's list of candidates become public. This ties in with the apparent double- standard of how publically incumbents vs. non-incumbents announce their candidacy. o The way to handle interim appointments is not clear. Two specific issues are: who appoints interim members (and is ``ratification'' required), and how long does interim appointees serve? o When the nominations committee has completed its work, it informs the IAB and the ISOC Trustees. The procedures for doing so need to be spelled out. At issue is when the nominations become public, whether the community at large is invited to comment, and what to do if there is difficulty in filling any of the positions. o There is currently no specific mechanism for the IAB to use to provide architectural guidance to working groups before the RFC submission stage. POISED may discuss whether such a mechanism is necessary, and if so, what that mechanism looks like. o The role of the IRTF and research groups has not yet been defined. o Should there be a regular mechanism for convening a POISED Working Group in the future? o The ISOC Trustees require that the procedures adopted meet with the approval of counsel and the insurance carriers in order to protect the Society from exposure. The procedures, rules, etc. adopted by the community will most likely be satisfactory to counsel, but input and review from counsel is essential. In its deliberations, POISED may produce new documents (e.g., an IETF Charter -- if the lack of such a charter delays the POISED effort), and it may request changes to existing documents (e.g., ``The IAB Charter'' [RFC 1601], ``The Internet Standards Process -- Version 2'' [RFC 1602], and ``IETF Working Group Guidelines and Procedures'' [RFC 1603]). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 94 New Procedure to Select and Confirm Individuals Serving on the IAB and IESG 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 will be a forum for coordinating the deployment, engineering, and operation of classless routing protocols and procedures in 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): David Sitman Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Mailing lists: General Discussion:gisd-wg@ripe.net To Subscribe: majordomo@ripe.net In Body: subscribe gisd-wg Archive: ftp://ftp.ripe.net/ripe/archives/gisd-wg/current 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. Network Status Reports (netstat) -------------------------------- Charter Current status: active working group Chair(s): Gene Hastings Operational Requirements Area Director(s): Scott Bradner Michael O'Dell Mailing lists: General Discussion: To Subscribe: Archive: Description of Working Group: The Network Status Reports Working Group reports on the status of various parts of the Internet. The group is semi-pertinent, and therefore does not have goals and milestones like other working groups do. 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 make 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. IP Routing for Wireless/Mobile Hosts (mobileip) ----------------------------------------------- Charter Current status: active working group Chair(s): Kannan Alagappan 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. In the longer term, the group may address, to the extent not covered by the mobile host solutions, other types of internet mobility, such as mobile subnets (e.g., a local network within a vehicle), or mobile clusters of subnets (e.g., a collection of hosts, routers, and subnets within a large vehicle, like a ship or spacecraft, or a collection of wireless, mobile routers that provide a dynamically changing internet topology). Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 Sep 94 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 IS-IS for IP Internets Working Group will develop additions to the existing OSI IS-IS routing protocol to support IP environments and dual OSI and IP environments. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 91 Jul 94 Integrated IS-IS Management Information Base Jan 93 Jul 94 Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments Mar 94 Jul 94 Integrated ISIS Protocol Analysis Mar 94 Jul 94 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) as a Proposed Standard to the IESG. Several proposals have been made to date, including Core-Based Tree (CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable Reverse Path Multicasting (SRPM). Some of the above have yet to be reviewed. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 New Protocol Independent Multicast (PIM), Dense Mode Protocol Specification Mar 94 New Protocol Independent Multicast (PIM): Motivation and Architecture Mar 94 New Protocol Independent Multicast (PIM), Sparse Mode Protocol Specification Jul 94 New Internet Group Management Protocol MIB Jul 94 New IP Multicast Routing MIB Jul 94 New Protocol Independent Multicast MIB 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: No Current Internet-Drafts. Inter-Domain Routing (idr) -------------------------- Charter Current status: active working group Chair(s): Sue Hares Yakov Rekhter Routing Area Director(s): Joel Halpern Mailing lists: General Discussion:bgp@ans.net To Subscribe: bgp-request@ans.net Archive: merit.edu:/pub/archive/bgp Description of Working Group: The main list for this working group is "bgp@ans.net", but there is also an IDRP-specific mailing list: - List: idrp@merit.edu - To Subscribe: idrp-request@merit.edu - Archive: merit.edu:/pub/archive/idrp The Inter-Domain Routing Working Group is chartered to standardize and promote the Border Gateway Protocol Version 4 (BGP-4) and ISO Inter- Domain Routing Protocol (IDRP) as scalable inter-autonomous system routing protocols capable of supporting policy based routing for TCP/IP internets. The objective is to promote the use of BGP-4 to support IP version 4 (IPv4). IDRP is seen as a protocol that will support IPv4 as well as the next generation of IP (IPv6). The working group will plan a smooth transition between BGP-4 and IDRP. Documents: 1) BGP-4 (standards track) This document contains the specification of the BGP protocol that enables it to be used as a protocol for exchange of ``inter- autonomous system information'' among routers to support forwarding of IPv4 packets across multiple autonomous systems. 2) BGP-4 MIB (standards track) This document contains the MIB definitions for BGP-4. 3) IDRP for IPv4 over IPv4 (standards track) This document contains the appropriate adaptations of the IDRP protocol definition that enables it to be used as a protocol for exchange of ``inter-autonomous system information'' among routers to support forwarding of IPv4 packets across multiple autonomous systems. 4) IDRP MIB (standards track) This document contains the MIB definitions for IDRP. 5) BGP/IDRP -- OSPF Interactions (standards track) This document will specify the interactions between BGP/IDRP and OSPF. This document will be based on a combination of the BGP -- OSPF interactions, and IDRP -- IS-IS interaction documents. 6) BGP/IDRP for IPv4 Usage (standards track) Most of IDRP for IPv4 Usage will reference the CIDR (supernetting) RFCs and related Internet-Drafts. IDRP for IPv4 Usage will contain a sample policy configuration language, and examples on how to use IDRP for IPv4 in the Internet today. 7) IDRP for IPv6 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 the forwarding of IPv6 packets across multiple autonomous systems. 8) IDRP for IP Next Generation Usage The IDRP for IPv6 Usage document will contain instructions on how to run IDRP for IPv6 over IPv4 and IPv6. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 92 Aug 94 BGP4/IDRP for IP---OSPF Interaction Aug 94 New Guidelines for creation, selection, and registration of an Autonomous System (AS) 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. New Internet Routing and Addressing Architecture (nimrod) --------------------------------------------------------- Charter Current status: active working group Chair(s): J. Noel Chiappa Isidro Castineyra Routing Area Director(s): Joel Halpern Mailing lists: General Discussion:nimrod-wg@bbn.com To Subscribe: nimrod-wg-request@bbn.com Archive: bbn.com:/pub/nimrod-wg/nimrod-wg.archive Description of Working Group: The goal of the working group is to design, specify, implement and test a flexible new routing and addressing architecture suitable for very large scale internets. The basic architecture for computation of routes will be based on distribution of network topology maps, with source-specified route selection, and unitary (i.e., not hop-by-hop) computation of routes. The architecture will provide a single homogeneous framework for all routing, including both inter-domain and intra-domain. It will include a new network component naming abstraction hierarchy, starting from network attachment points, and based on actual connectivity, but taking into consideration policy requirements. These new names will be variable length, with a variable number of levels of abstraction; they will not appear in most packets, though. Actual packet forwarding will be based both on retained non-critical state in the switches (via flow setup for long-lived communications), and both classical address-only, as well as source-route type instructions, in individual packets (for datagram applications which send only one, or a very few, packets). Although the general design and algorithms will be usable in any internetworking protocol family, the initial detailed protocol specifications and implementation are currently planned for deployment with IPv4, but support for another packet format may be substituted or added, depending on the situation in the Internet in the future. Interoperabilty with existing unmodified IPv4 hosts will be achieved by re-interpreting the existing source and destination fields in IPv4 packets as endpoint identifiers. A substantial effort to take into account support for mobility, multicast and resource allocation will be made when designing the Nimrod architecture; provided that so doing is neither impossible because of incomplete work outside the scope of Nimrod, nor the cause of very substantial delays in the first iteration of the protocol design. Internet-Drafts: No Current Internet-Drafts. 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 Jul 94 OSPF Version 2 Management Information Base Feb 94 Jul 94 IP Forwarding Table MIB Mar 94 New OSPF Point-to-MultiPoint Interface May 94 New Extending OSPF to support demand circuits Aug 94 Sep 94 OSPF MD5 Authentication 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 ``RIP Version 2'' (RFC 1388), ``RIP Version 2 MIB'' (RFC 1389), and the analysis document (RFC 1387) 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 Jul 94 RIP Version 2 Carrying Additional Information Oct 93 Aug 94 RIP Version 2 MIB Extension Dec 93 Apr 94 RIP Version 2 Protocol Analysis Jul 94 Jul 94 RIP Version 2 Protocol Applicability Statement 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@maelstrom.timeplex.com To Subscribe: rolc-request@maelstrom.timeplex.com Archive: cnri.reston.va.us:/ietf-mail-archive/rolc/ 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, etc. run. Large cloud: A collection of ``end-points'' be they 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. 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 network number. The group will also entertain proposals on the use of a common IP network 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 Aug 94 NBMA Next Hop Resolution Protocol (NHRP) May 94 New NBMA Address Resolution Protocol (NARP) 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 collecting dynamic domain-level connectivity information, and 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). Jul 94 New SDRP Route Construction 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 Programming 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 and 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 May 94 FTP Security Extensions Mar 94 Jul 94 The Kerberos Version 5 GSS-API Mechanism Jul 94 New The Simple Public-Key GSS-API Mechanism (SPKM) DNS Security (dnssec) --------------------- Charter Current status: active working group Chair(s): James Galvin Security Area Director(s): Jeffrey Schiller 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 Security Working Group (DNSSEC) will specify enhancements to the DNS protocol to protect the DNS against unauthorized modification of data and against masquerading of 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, backwards 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 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: merit.edu:/pub/nas-req-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. 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 do not 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 Jun 94 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 Jul 94 PEM Security Services and MIME Jun 94 Jul 94 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted Aug 94 New Privacy Enhancement for Internet Electronic Mail: Part V: ANSI X9.17-Based Key Management Trusted Network File Systems (tnfs) ----------------------------------- Charter Current status: active working group Chair(s): Fred Glover Security Area Director(s): Jeffrey Schiller 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 supports 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 introduce only a minimal impact on the existing NFS V2 environment, and that unmodified NFS V2 clients and servers 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. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 May 94 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 AVT efforts of existing research activities. No standards-track protocols are expected to be produced because UDP transmission of audio and video is only sufficient for small-scale experiments over fast portions of the Internet. However, the transport protocols produced by this working group should be useful on a larger scale in the future in conjunction with additional protocols to access network-level resource management mechanisms. Those mechanisms, research efforts now, will provide low-delay service and guard against unfair consumption of bandwidth by audio/video traffic. Similarly, initial experiments can work without any connection establishment procedure so long as a priori agreements on port numbers and coding types have been made. To go beyond that, we will need to address simple control protocols as well. Since IP multicast traffic may be received by anyone, the control protocols must handle authentication and key exchange so that the audio/video data can be encrypted. More sophisticated connection management is also the subject of current research. It is expected that standards-track protocols integrating transport, resource management, and connection management will be the result of later working group efforts. The AVT Working Group may design independent protocols specific to each medium, or a common, lightweight, real-time transport protocol may be extracted. Sequencing of packets and synchronization among streams are important functions, so one issue is the form of timestamps and/or sequence numbers to be used. The working group will not focus on compression or coding algorithms which are domain of higher layers. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 92 Jul 94 RTP: A Transport Protocol for Real-Time Applications Mar 93 Sep 94 Packetization of H.261 video streams Integrated Services (intserv) ----------------------------- Charter Current status: active working group Chair(s): Craig Partridge Scott Shenker John Wroclawski David Clark Transport Area Director(s): Allison Mankin Mailing lists: General Discussion:int-serv@isi.edu To Subscribe: int-serv-request@isi.edu Archive: ftp.isi.edu:int-serv/int-serv.mail Description of Working Group: Recent experiments demonstrate the capability of packet switching protocols to support Integrated Services --- the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. These experiments suggest that expanding the Internet service model would better meet the needs of these diverse applications. The purpose of this working group is to specify this enhanced service model and then to define and standardize certain interfaces and requirements necessary to implement the new service model. The working group will focus on defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure. Enhancements to individual protocols (e.g., adding additional routing information to routing protocols, or choosing IP queueing disciplines for routers) will be left to other working groups, except in those rare cases where detailed definitions of behavior are critical to the success of the enhanced architecture. Extending the Internet service model raises a series of questions. The working group will focus on the three problems listed below: (1) Clearly defining the services to be provided. The first task faced by this working group is to define and document the enhanced Internet service model. (2) Defining the application service, router scheduling and (general) subnet interfaces. The working group must define at least three high-level interfaces: that expressing the application's end-to-end requirements, that defining what information is made available to individual routers within the network, and the additional expectations (if any) the enhanced service model has for subnet technologies. The working group will define these abstract interfaces, and will coordinate with and advise IP over "subnet" working groups (such as IP over ATM) in this. (3) Developing router validation requirements which can ensure that the proper service is provided. We assume that the Internet will continue to contain a heterogeneous set of routers, running different routing protocols and using different forwarding algorithms. The working group will seek to define a minimal set of additional router requirements which ensure that the Internet can support the new service model. Rather than presenting specific scheduling and admission control algorithms which must be supported, these requirements will likely take the form of behavioral tests which measure the capabilities of routers in the integrated services environment. This approach is used because no single algorithm seems likely to be appropriate in all circumstances at this time. The working group will coordinate with the Benchmarking Working Group (BMWG). We expect to generate three RFCs as a product of performing these tasks. An important aspect of this working group's charter is in coordination with the development of IP Next Generation. The working group will be reviewed in November 1995 to determine if it should be re-chartered as is or modified to reflect IPng developments, in particular, but also operational and commercial developments. The IESG deems the great significance of this working group to merit this unusual review. In addition, because many of the integrated services concepts are new, the working group may produce Informational RFCs explaining specific algorithms that may be appropriate in certain circumstances, and may host some educational meetings to assist both IETF members and members of the larger Internet community to understand the proposed enhancements to IP. The working group proposes to hold regular meetings beyond those held at the IETF meetings. APPENDIX - Integrated Services Working Group Management Plan The general chair is Craig Partridge (BBN). The co-chairs are Dave Clark (MIT), Scott Shenker (XEROX), and John Wroclawski (MIT). The dual reasons for this management structure are: (1) The working group will have do considerably more outreach into the larger networking community than the typical IETF working group. For instance, one of the important tasks is to convince the larger public that IP is suitable for integrated services. So we need management manpower to do outreach. (2) The working group has a lot of work to do and swiftly. Even though we plan to spin off working groups as fast as we can, a lot of key architectural decisions will need to be made in one place (e.g., by this working group) if the final architecture is to be sound. So we need management manpower just to keep the working group moving. So Craig has primary responsibility for keeping the working group moving, and Dave, Scott, and John have primary responsibility for outreach to different communities (and titles sufficient to show they can speak for the working group). Internet-Drafts: No Current Internet-Drafts. Minimal OSI Upper-Layers (thinosi) ---------------------------------- Charter Current status: active working group Chair(s): Peter Furniss Transport Area Director(s): Allison Mankin 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 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 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: ftp.isi.edu:~/confctrl/confcrtl.mail Description of Working Group: The demand for Internet multimedia 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 agreement protocol that supports tightly-controlled conferences in addition to the loosely-controlled ones currently carried on the MBone. Loosely-controlled sessions have little to no interaction among members, thus limiting their ability to provide security or coordination of session attributes (e.g., quality-of-service options for time-critical media, floor control for media flows). Users may learn of loosely-controlled sessions using the ``sd'' utility or other out of band mechanisms (e.g., e-mail, WWW). However, there is clearly also a need for more tightly-controlled sessions that provide mechanisms for directly contacting other users to initiate a conference 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. 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 cataloging 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. ONC Remote Procedure Call (oncrpc) ---------------------------------- Charter Current status: active working group Chair(s): Raj Srinivasan Transport Area Director(s): Allison Mankin 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 Open Network Computing Remote Procedure Call 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 ``RPC: Remote Procedure Call Protocol Specification Version 2'' (RFC 1057), and ``XDR: External Data Representation Standard'' (RFC 1014). The focus of the ONC-RPC Working Group is to document and standardize the current ONC RPC protocols. It is 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 plans to give the ownership of ONC RPC and change control over the ONC RPC protocols to the IETF. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 94 May 94 RPC: Remote Procedure Call Protocol Specification Version 2 Mar 94 Sep 94 XDR: External Data Representation Standard May 94 New Authentication Mechanisms for ONC RPC Jun 94 New Binding Protocols for ONC RPC Version 2 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 research and development work on RSVP in the DARTnet research community, and (2) the parallel IETF working group that is considering the service model for integrated service. Although RSVP is largely independent of the service model, its design does depend upon the overall integrated service architecture and the requirements of real-time applications. As an additional task, RSVP will maintain coordination with the IPng-related working groups. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 93 Jul 94 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification 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 ``TCP extensions for long-delay paths'' (RFC 1072), and ``TCP Extension for High-Speed Paths'' (RFC 1185) be published jointly as a Proposed Standard. Deficiencies in the technical details of the documents were identified by the End-to-End Research Group of the IRTF. Rather than progress the standard with known deficiencies, the IESG tasked the End-to-End Research Group to fix and merge these two documents into a single protocol specification document. This review was done on the e2e-interest@isi.edu mailing list. The TCP Large Windows Working Group is being resurrected for a one time meeting, to review and if appropriate, approve this new document. Internet-Drafts: No Current Internet-Drafts. Integrated Directory Services (ids) ----------------------------------- Charter Current status: active working group Chair(s): Linda Millington Sri Sataluri 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 ``A catalog of available X.500 implementations'' (FYI 11). 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: No Current Internet-Drafts. 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 Aug 94 Resource Transponders Mar 93 Aug 94 A Vision of an Integrated Internet Information Service Aug 93 May 94 Publishing Information on the Internet with Anonymous FTP Aug 94 New Using the Z39.50 Information Retrieval Protocol in the Internet Environment Internet School Networking (isn) -------------------------------- Charter Current status: active working group Chair(s): Jennifer Sellers 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 issues related to the connection of primary and secondary schools worldwide to the Internet. The key audiences include network service providers and educational policy makers responsible for network access and use. The key areas of focus for this group are advocacy and articulation. 1. Advocacy. The ISN Working Group will facilitate dialog between the primary and secondary education community and the Internet engineering community in order to identify and fulfill the needs of the primary and secondary school community. 2. Articulation. Informed by the group's experience, and with input from other IETF working groups, the ISN Working Group will articulate solutions to the challenges a school may experience in seeking and gaining a connection to the Internet, as well as the benefits of such a connection. Advantages to Internet connectivity may be articulated by means of pointers to such services as user interfaces, directories, organizations, and training programs, as well as to other resources. Articulation will most often be in the form of periodic documents that address key issues of interest to the school networking community. Representative issues to be addressed by the group include connectivity models, educational directories, and acceptable use policies. Internet-Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 94 Jul 94 K-12 Internetworking Guidelines Apr 94 Apr 94 Acceptable Use Policy Definition Network Information Services Infrastructure (nisi) -------------------------------------------------- Charter Current status: active working group Chair(s): April Marine 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: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 94 New Network Information Center Guidelines 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@nic.near.net To Subscribe: us-wg-request@nic.near.net Archive: ftp.near.net:/mail-archives/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 optimizes 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. Uniform Resource Identifiers (uri) ---------------------------------- Charter Current status: active working group Chair(s): Larry Masinter 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 specify standard representations of Uniform Resource Locators (URLs) for encoding location and access information across multiple information systems, 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 standards are expected to build upon the document discussed at the UDI BOF session held during the 24th IETF meeting in Boston 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 Sep 94 Uniform Resource Locators (URL) May 93 Aug 94 Uniform Resource Names Mar 94 New Requirements for Uniform Resource Names Apr 94 New Specification of Uniform Resource Characteristics Apr 94 New URN to URC resolution scenario Jun 94 Aug 94 Functional Requirements for Internet Resource Locators Jul 94 New Encoding and Use of Uniform Resource Characteristics Aug 94 New Relative Uniform Resource Locators 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 maintains the central ``NICNAME'' database and server, defined in RFC 954, providing on-line 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 Aug 94 Architecture of the Whois++ Index Service Jul 93 Jul 94 Whois and Network Information Lookup Service Whois++ Apr 94 Aug 94 Architecture of the WHOIS++ service Aug 94 New How to interact with a Whois++ mesh