Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/1wg-charters-by-acronym.txt

Text File | 1997-11-02 | 346KB | 9,055 lines

2000
acap
aft
agentx
applmib
asid
atommib
avt
bmwg
bridge
calsch
cat
dhc
disman
dlswmib
dnsind
dnssec
drums
ediint
entmib
fax
find
frnetmib
ftpext
grip
http
hubmib
idmr
idr
ids
ifmib
intserv
ion
ip1394
ipcdn
ipngwg
ipp
ippcp
ippm
ipsec
isdnmib
isis
isn
issll
lsma
madman
manet
mboned
mhtml
mixer
mmusic
mobileip
mospf
mpls
ngtrans
nimrod
nntpext
oncrpc
openpgp
ospf
otp
pier
pint
pkix
pktway
poisson
pppext
printmib
ptopomib
qosr
radius
receipt
rip
rmonmib
roamops
rps
rsvp
rtfm
run
rwhois
sdr
secsh
snadlc
snanau
snmpv3
spki
ssh
stdguide
svrloc
tcpimpl
tcplw
tcpsat
tip
tls
tn3270e
trunkmib
udlr
upsmib
urlreg
urn
uswg
vgmib
vrrp
webdav
wts

The Internet and the Millennium Problem (2000)
----------------------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Erik Huizer <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Technical Advisor(s):
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe 2000 <your name> in body
     Archive:

Description of Working Group:

The Millenium problem

According to the trade press billions of dollars will be spend the
upcoming three years on the year 2000 problem, also called the
millenium problem (though the third millenium will only start in 2001).
This problem consists of the fact that many software packages and some
protocols use a two digit field for the year in a date field.  Most of
the problems seem to be in administrative and financial programs, some
of which have been written in archaic languages like Cobol. A lot of
organizations are now starting to make an inventory of which software
and tools they use will suffer from the millenium problem.

....and the Internet

With the increasing popularity of the Internet,
more and more organizations start to use the Internet as a serious
business tool.  This means that most organizations will want to analyse
the millenium problems due to the use of Internet protocols and popular
Internet software. In the trade press the first articles suggest that
the Internet will collapse at midnight the 31st of december 1999.

To counter these suggestions (that are obviously wrong) and to avoid
that all over the Internet people will redo the same inventory over and
over again the WG is to make an inventory of all important Internet
protocols and their most popular implementations with respect to the
millenium problem. Only software and protocols directly related to the
Internet will be considered.

The inventory will be published as an informational RFC. The RFC will
contain:

 o  Description of the year 2000 problems and when they will occur

 o  Summary of possible solutions and timelines for those solutions

 o  Inventory of the year 2000 problem in the most popular Internet
    protocols and their most popular implementations

 o  Suggested solutions to the problems noted in the inventory

 o  A disclaimer that the RFC does not pretend to be complete and that
    the proposed solutions should be tested before being relied upon (this
    for the US readers).

The WG will only meet once (in Memphis, April 1997), most of the work
will be done via the mailinglist.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 97 New     <draft-ietf-2000-issue-00.txt>
                The Internet and the Millenium Problem (Year 2000)


Application Configuration Access Protocol (acap)
------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     C Newman <[e-mail]>
     Matt Wall <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           anonymous IMAP: cyrus.andrew.cmu.edu:archive.ietf-acap

Description of Working Group:

The goal of this working group is to define, specify, and develop the
Application Configuration Access Protocol as a general access mechanism
for per-user and per-server structured lists of information. In
addition, the Working Group will specify how to use the protocol to
store specific structured lists, initially application configuration
options and addressbooks.

The Application Configuration Access Protocol is a proposed solution to
the problems of client configuration for users of the internet.

Given the increasing prevalence of network access points and rapidly
increasing numbers of users with diverse needs and settings, there is a
phenomenon of internet application users who typically connect from
more than one physical location and/or operating system to use the same
set of internet services and applications. These users must recreate
sets of personal configuration information for each system, session,
and location that they use. This may include information such as
application options and preferences; personal or shared user data such
as addressbooks, bookmarks, or subscription lists; or shared data for
internal client use, such as authorization group lists.

The products of this working group will be:

   * a formal specification for the protocol
   * formal specifications of datasets used by the protocol and related
     extensions to the protocol
   * an RFC intended to move to a Standard in a timely manner
   * a specification for extensibility of the protocol in the form of a
     framework document
   * additional informational and/or experimental RFCs as necessary to
     amplify and/or extend ACAP.

Note on goals and milestones: because the work of the ACAP WG is based
on the previous work done on IMSP, there is justification for a
somewhat more aggressive schedule than is customary.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 96 Aug 97  <draft-ietf-acap-spec-06.txt>
                ACAP -- Application Configuration Access Protocol

 Apr 97 New     <draft-ietf-acap-type-ext-00.txt>
                ACAP TYPE Extension

 Apr 97 New     <draft-ietf-acap-dewinter-dtype-00.txt>
                ACAP Datatyping and Datatyping Discovery

 Jun 97 Jun 97  <draft-ietf-acap-mlsf-01.txt>
                Multi-Lingual String Format (MLSF)

 Jun 97 New     <draft-ietf-acap-langtag-00.txt>
                Two Alternative Proposals for Language Taging in ACAP

 Jun 97 Aug 97  <draft-ietf-acap-anon-01.txt>
                Anonymous SASL Mechanism

 Jul 97 New     <draft-ietf-acap-authid-00.txt>
                ACAP Authorization Identifier Datasets

 Jul 97 New     <draft-ietf-acap-abook-00.txt>
                ACAP Personal Addressbook Dataset Class

 Jul 97 Jul 97  <draft-ietf-acap-options-01.txt>
                ACAP personal options dataset class


Authenticated Firewall Traversal (aft)
--------------------------------------

 Charter
 Last Modified: 28-Aug-97

 Current Status: Active Working Group

 Chair(s):
     Marcus Leech <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www.socks.nec.com/aftmail/

Description of Working Group:



 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 96 New     <draft-ietf-aft-socks-chap-00.txt>
                Challenge-Handshake Authentication Protocol for SOCKS V5

 Mar 97 New     <draft-ietf-aft-socks-cram-00.txt>
                Challenge-Response Authentication Method for SOCKS V5

 Mar 97 New     <draft-ietf-aft-socks-ssl-00.txt>
                Secure Sockets Layer for SOCKS Version 5

 Mar 97 Jul 97  <draft-ietf-aft-socks-pro-v5-01.txt>
                SOCKS Protocol Version 5

 Jul 97 New     <draft-ietf-aft-socks-ext-00.txt>
                Feature Discovery: A Generic Extension Mechanism for SOCKS
                Version 5


SNMP Agent Extensibility (agentx)
---------------------------------

 Charter
 Last Modified: 11-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Bob Natale <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       Subject: subscribe
     Archive:           ftp://ftp.fv.com/pub/agentx/

Description of Working Group:

Note: Dale Francisco of Stratacom <[e-mail]> is the WG editor.

The goal of this working group is to define standards-track technology
for SNMP Agent extensibility.  The resulting technology specification
will allow independently developed sub-agents to communicate with a
master-agent running on an Internet device.

The technology specification will consist of:

 o (mandatory) a platform-independent protocol which supports
    intra-agent communication within a device or local area network;

 o (optional) a MIB module, which, when implemented by a master-agent,
   allows an SNMP-based management application to monitor and control
   the intra-agent communication service; and,

 o (optional) a programmatic interface to the services offered by
   that protocol.

The working group is explicitly directed to develop a solution which is
adequate to achieve transparency with respect to whether a SNMP request
is processed by a master-agent and/or one or more sub-agents;
simultaneously, the working group is further directed to use good
engineering judgement is developing an approach with the smallest
reasonable "footprint" to achieve intra-agent communication.  As a
consequence, if the working group may choose to avoid complete
transparency, if, at its discretion, this proves too costly.  In this
case, the working group should document its decision for this
engineering trade-off.

Although the working group will solicit existing specifications and
experience in this area, it will produce a vendor-neutral technology
specification.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 96 Jun 97  <draft-ietf-agentx-ext-pro-04.txt>
                Agent Extensibility (AgentX) Protocol  Version 1

 May 97 New     <draft-ietf-agentx-mib-00.txt>
                Definitions of Managed Objects for Extensible SNMP Agents


Application MIB (applmib)
-------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Jonathan Saperia <[e-mail]>
     Cheryl Krupczak <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.emi-summit.com/applmib/applmib-archive

Description of Working Group:

The Application MIB Working Group is chartered to define a set of
managed objects for the monitoring and control of distributed
applications. Specifically, these managed objects will focus on
providing information about the configuration (including application
dependencies and associations between applications), fault (including
status information such as up, down, or degraded) and performance
(including resource utilization) of distributed applications.

The working group will only concern itself with the specification of
MIB objects in the management areas defined above. It will not
undertake to define details of implementation such as programming API's
for the access to this information.

The working group will consider existing MIB modules that define
objects with similar functions or modules which can be used in
conjunction with the Application MIB such as RFC 1514 (The Host
Resources MIB) and RFC 1697 (The RDBMS-MIB).

The activities of the working group will take place in two stages. The
first will focus on the development of a System Application MIB which
will not require applications to write additional instrumentation
code.  This generic information will serve as a base for the follow-on
Application MIB which will contain additional information that will
require applications to write additional instrumentation. The schedule
below describes the schedule for the development of the System
Application MIB.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jan 96 Oct 97  <draft-ietf-applmib-sysapplmib-09.txt>
                Definitions of System-Level Managed Objects for Applications

 Nov 96 Aug 97  <draft-ietf-applmib-mib-04.txt>
                Application Management MIB

 Nov 96 Sep 97  <draft-ietf-applmib-wwwmib-05.txt>
                Definitions of Managed Objects for WWW Services


Access, Searching and Indexing of Directories (asid)
----------------------------------------------------

 Charter
 Last Modified: 05-Aug-97

 Current Status: Active Working Group

 Chair(s):
     Tim Howes <[e-mail]>
     Patrik Faltstrom <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://terminator.rs.itd.umich.edu/ietf-asid/archive

Description of Working Group:

There is a clear need to provide and deploy a well managed
Directory Service for the Internet. A so-called White Pages Directory
Service providing people and organizational information, is especially
long overdue.  While the ultimate goal is a general Directory Service
for the Internet, this is too ambitious a goal to be tackled by a
single working group. Therefore ASID will keep a tight focus on access
and synchronization protocols for an Internet White Pages Directory
Service.

Other related working groups will be formed in the Applications Area
that will deal with other aspects of the Internet Directory Service.

Currently there are various protocols under development in the
Internet that aim to provide such a service: Internet X.500, WHOIS++,
NETFIND, CSO, RWHOIS, etc.  To allow these services to evolve to a
ubiquitous Internet Directory Service, a hybrid system that allows
interaction between the various different services is a requirement.

The ASID Working Group will define, evolve, and standardize protocols,
algorithms and access methods for a White Pages Directory Service on
the Internet.

The following protocols (some still under development, some completed
by other IETF working groups) will be considered by the working group:

 - Lightweight Directory Acces Protocols (LDAP and Connectionless
   LDAP)

 - User Friendly Naming (UFN) and User Friendly Searching (UFS)

 - The SOLO directory access and searching system

 - The WHOIS++ directory service

The following work items are handled by other groups, and as such are
outside the scope of this group. However their results are important
to the development of a White Pages Directory Service, and will be taken
into account:

 - The Hypertext Transfer Protocol (HTTP)

 - The UR* definitions

 - The NETFIND directory service

The group will focus on harmonizing, evolving and developing protocols
and algorithms that deal with access to and synchronization of Directory
Service, both ad hoc and standards-based, with a goal of converging here
possible towards a hybrid system that ties together various forms of
Directory Service.  Clearly, protocol-level integration is only part of
the solution.  But to keep this group tightly focused, harmonizing
directory information and service models will be tackled by other
working groups.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 95 Jul 97  <draft-ietf-asid-mime-direct-04.txt>
                A MIME Content-Type for Directory Information

 Jul 95 Oct 97  <draft-ietf-asid-ldap-cache-01.txt>
                A Simple Caching Scheme for LDAP and X.500 Directories

 Feb 96 May 97  <draft-ietf-asid-whois-url-01.txt>
                WHOIS++ URL Specification

 Mar 96 Oct 97  <draft-ietf-asid-ldapv3-attributes-08.txt>
                Lightweight Directory Access Protocol (v3):  Attribute Syntax
                Definitions

 Mar 96 Oct 97  <draft-ietf-asid-ldapv3-protocol-08.txt>
                Lightweight Directory Access Protocol (v3)

 May 96 Aug 97  <draft-ietf-asid-mime-vcard-03.txt>
                vCard MIME Directory Profile

 Jun 96 Sep 97  <draft-ietf-asid-ldapv3-dynamic-06.txt>
                Lightweight Directory Access Protocol (v3):  Extensions for
                Dynamic Directory Services

 Aug 96 Apr 97  <draft-ietf-asid-ldapv3-dn-03.txt>
                Lightweight Directory Access Protocol (v3): UTF-8 String
                Representation of Distinguished Names

 Aug 96 Sep 97  <draft-ietf-asid-ldap-domains-02.txt>
                Using Domains in LDAP/X.500 Distinguished Names

 Nov 96 Jun 97  <draft-ietf-asid-ldapv3-lang-02.txt>
                Use of Language Codes in LDAPv3

 Nov 96 Oct 97  <draft-ietf-asid-whois-schema-02.txt>
                WHOIS++ templates

 Nov 96 Aug 97  <draft-ietf-asid-inetorgperson-01.txt>
                Definition of the inetOrgPerson Object Class

 Nov 96 Jul 97  <draft-ietf-asid-ldif-02.txt>
                The LDAP Data Interchange Format (LDIF) - Technical
                Specification

 Nov 96 Mar 97  <draft-ietf-asid-whoispp-01.txt>
                Architecture of the WHOIS++ service

 Dec 96 Jul 97  <draft-ietf-asid-changelog-01.txt>
                Definition of an Object Class to Hold LDAP Change Records

 Feb 97 Mar 97  <draft-ietf-asid-ldapv3-simplepaged-01.txt>
                LDAP Control Extension for Simple Paged Results Manipulation

 Mar 97 New     <draft-ietf-asid-ldap-rpcschema-00.txt>
                Lightweight Directory Access Protocol:  Schema for Storing RPC
                Entries in a Directory Service

 Mar 97 Jul 97  <draft-ietf-asid-ldap-mult-mast-rep-01.txt>
                LDAP Multi-master Replication Protocol

 Mar 97 Aug 97  <draft-ietf-asid-ldapv3-url-04.txt>
                The LDAP URL Format

 Mar 97 Oct 97  <draft-ietf-asid-ldapv3-filter-03.txt>
                The String Representation of LDAP Search Filters

 Mar 97 New     <draft-ietf-asid-email-routing-ns-00.txt>
                LDAP-based Routing of SMTP Messages: Approach Used by Netscape

 Mar 97 New     <draft-ietf-asid-email-routing-su-00.txt>
                LDAP-based Routing of SMTP Messages: Approach at Stanford
                University

 Mar 97 New     <draft-ietf-asid-ldapv3-strong-00.txt>
                X.500 Strong Authentication Mechanisms for LDAPv3

 Mar 97 New     <draft-ietf-asid-schema-pilot-00.txt>
                A Summary of the Pilot X.500 Schema for use in LDAPv3

 Mar 97 Oct 97  <draft-ietf-asid-ldapv3schema-x500-03.txt>
                A Summary of the X.500(96) User Schema for use with LDAPv3

 Apr 97 New     <draft-ietf-asid-ldapv3-sorting-00.txt>
                LDAP Control Extension for Server Side Sorting of Search
                Results

 May 97 New     <draft-ietf-asid-ldapv3-referral-00.txt>
                Referrals and Knowledge References in LDAP Directories

 Jun 97 Sep 97  <draft-ietf-asid-ldapv3-tls-02.txt>
                Lightweight Directory Access Protocol (v3):  Extension for
                Transport Layer Security

 Jul 97 New     <draft-ietf-asid-ldap-dynatt-00.txt>
                Lightweight Directory Access Protocol:  Dynamic Attributes

 Jul 97 New     <draft-ietf-asid-ldapv3schema-vcard-00.txt>
                The vCard Schema For Use In LDAPv3

 Jul 97 New     <draft-ietf-asid-replica-req-00.txt>
                LDAP Replication Requirements

 Jul 97 Sep 97  <draft-ietf-asid-ldap-java-api-01.txt>
                The Java LDAP Application Program Interface

 Jul 97 Oct 97  <draft-ietf-asid-ldap-repl-info-01.txt>
                Schema for Replication Information

 Jul 97 New     <draft-ietf-asid-ldapv3-api-ext-00.txt>
                LDAP API Extensions for Sort and Simple Paged Results

 Jul 97 New     <draft-ietf-asid-rwhois-00.txt>
                Referral Whois Protocol (RWhois) 2.0

 Jul 97 New     <draft-ietf-asid-ldap-c-api-00.txt>
                The C LDAP Application Program Interface

 Sep 97 New     <draft-ietf-asid-ldap-java-controls-00.txt>
                Java LDAP Controls


AToM MIB (atommib)
------------------

 Charter
 Last Modified: 12-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Kaj Tesink <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Technical Advisor(s):
     Keith McCloghrie  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://thumper.bellcore.com/pub/Group.archive/atommib

Description of Working Group:

The AToM MIB Working Group is chartered to evaluate RFC 1695, a
Proposed Standard, with respect to the standards track.  As a part
of its evaluation, the working group will prepare a revised version and
recommend the appropriate level of standardization for this revision to
the IESG (i.e., that it be advanced to Draft Standard status, or that it
cycle at Proposed Standard status).

As a part of its evaluation, the AToM MIB Working Group may also define
additional sets of managed objects, to reflect growing experience and
industry requirements for management of:

 o ATM services

 o The Frame based UNI (F-UNI)

 o ATM tests

The objects defined by the working group will be consistent with the
Internet-standard Management framework.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 95 Aug 97  <draft-ietf-atommib-atm2-11.txt>
                Definitions of Supplemental Managed Objects for ATM Management

 Jul 95 Mar 97  <draft-ietf-atommib-atm2TC-06.txt>
                Definitions of Textual Conventions and OBJECT-IDENTITIES for
                ATM Management

 Jan 96 Jun 97  <draft-ietf-atommib-test-03.txt>
                Definitions of Tests for ATM Management

 Mar 96 Jun 97  <draft-ietf-atommib-acct-04.txt>
                Managed Objects for Controlling the Collection and Storage of
                Accounting Information for Connection-Oriented Networks

 Apr 96 Feb 97  <draft-ietf-atommib-atm1ng-03.txt>
                Definitions of Managed Objects for ATM Management

 Apr 96 May 97  <draft-ietf-atommib-perfhistTC-01.txt>
                Textual Conventions for MIB Modules Using Performance History
                Based on 15 Minute Intervals

 Apr 96 Jul 97  <draft-ietf-atommib-sonetng-02.txt>
                Definitions of Managed Objects for the SONET/SDH Interface Type

 Aug 96 Jun 97  <draft-ietf-atommib-atmacct-01.txt>
                Accounting Information for ATM Networks

 Nov 96 New     <draft-ietf-atommib-atmhist-00.txt>
                Managed Objects for Recording ATM Performance History Data
                Based on 15 Minute Intervals


Audio/Video Transport (avt)
---------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Stephen Casner <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://nic.es.net/pub/mailing-lists/mail-archive/rem-conf

Description of Working Group:

The Audio/Video Transport Working Group was formed to specify
experimental
     protocols for real-time transmission of audio and video over UDP
     and IP multicast.  The focus of this group is near-term and its
     purpose is to integrate and coordinate the current AVT
     efforts of existing research activities.  No standards-track
     protocols are expected to be produced because UDP transmission of
     audio and video is only sufficient for small-scale experiments
     over fast portions of the Internet.  However, the transport
     protocols produced by this working group should be useful on a
larger scale
     in the future in conjunction with additional protocols to access
     network-level resource management mechanisms.  Those mechanisms,
     research efforts now, will provide low-delay service and guard
     against unfair consumption of bandwidth by audio/video traffic.

     Similarly, initial experiments can work without any connection
     establishment procedure so long as a priori agreements on port
     numbers and coding types have been made.  To go beyond that, we
     will need to address simple control protocols as well.  Since IP
     multicast traffic may be received by anyone, the control
     protocols must handle authentication and key exchange so that the
     audio/video data can be encrypted.  More sophisticated connection
     management is also the subject of current research.  It is
     expected that standards-track protocols integrating transport,
     resource management, and connection management will be the result
     of later working group efforts.

     The AVT Working Group may design independent protocols specific to
each
     medium, or a common, lightweight, real-time transport protocol
     may be extracted.  Sequencing of packets and synchronization
     among streams are important functions, so one issue is the form
     of timestamps and/or sequence numbers to be used.  The working
group will
     not focus on compression or coding algorithms which are domain of
     higher layers.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 96 Jun 97  <draft-speer-avt-layered-video-02.txt>
                RTP usage with Layered Multimedia Streams

 Apr 96 Sep 97  <draft-ietf-avt-rtp-payload-04.txt>
                RTP Payload Format for H.263 Video Streams

 Aug 96 Feb 97  <draft-civanlar-bmpeg-01.txt>
                RTP Payload Format for Bundled MPEG

 Nov 96 Jul 97  <draft-ietf-avt-crtp-03.txt>
                Compressing IP/UDP/RTP Headers for Low-Speed Serial Links

 Nov 96 Jan 97  <draft-aboba-rtpscale-02.txt>
                Alternatives for Enhancing RTCP Scalability

 Mar 97 New     <draft-ietf-avt-rtp-mib-00.txt>
                Real-Time Transport Protocol Management Information Base

 Mar 97 Jul 97  <draft-ietf-avt-profile-new-01.txt,.ps>
                RTP Profile for Audio and Video Conferences with Minimal
                Control

 Apr 97 Jun 97  <draft-ietf-avt-mpeg-new-01.txt>
                RTP Payload Format for MPEG1/MPEG2 Video

 Jul 97 New     <draft-ietf-avt-qt-rtp-00.txt>
                RTP Payload Format for QuickTime Media Streams

 Jul 97 New     <draft-ietf-avt-dtmf-00.txt,.ps>
                RTP Payload for DTMF Digits

 Aug 97 New     <draft-ietf-avt-fec-00.txt>
                An A/V Profile Extension for Generic Forward Error Correction
                in RTP

 Aug 97 New     <draft-ietf-avt-info-repair-00.txt>
                Options for Repair of Streaming Media


Benchmarking Methodology (bmwg)
-------------------------------

 Charter
 Last Modified: 08-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Guy Almes <[e-mail]>
     Kevin Dubray <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ndtl.harvard.edu/pub/bmwg/mailing.list

Description of Working Group:

The major goal of the Benchmarking Methodology Working Group is to make
a series of recommendations concerning the measurement of the
performance characteristics of various internetworking technologies;
further, these recommendations may focus on the systems or services
that are built from these technologies.

Each recommendation will describe the class of equipment, system, or
service being addressed; discuss the performance characteristics that
are pertinent to that class; clearly identify a set of metrics that aid
in the description of those characteristics; specify the methodologies
required to collect said metrics; and lastly, present the requirements
for the common, unambiguous reporting of benchmarking results.

Because the demands of a class may vary from deployment to deployment,
this Working Group will not attempt to define acceptance criteria or
performance requirements.

Currently, there are two distinct efforts underway in the BMWG. The
first addresses the metrics and methodologies associated with
benchmarking network interconnect devices. The second effort (IPPM)
focuses on determining the practical benchmarks and procedures needed
in gaining insight for users and providers of IP Internet services.

An ongoing task is to provide a forum for the discussion and the
advancement of measurements designed to provide insight on the
operation internetworking technologies.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 96 Sep 97  <draft-ietf-bmwg-lanswitch-07.txt>
                Benchmarking Terminology for LAN Switching Devices

 Nov 96 Mar 97  <draft-ietf-bmwg-call-01.txt>
                Terminology for Cell/Call Benchmarking

 Nov 96 Aug 97  <draft-ietf-bmwg-ippm-treno-btc-01.txt>
                Empirical Bulk Transfer Capacity

 Nov 96 Aug 97  <draft-ietf-bmwg-ippm-framework-01.txt>
                Framework for IP Provider Metrics

 Nov 96 Aug 97  <draft-ietf-bmwg-ippm-delay-02.txt>
                A One-way Delay Metric for IPPM

 Dec 96 Aug 97  <draft-ietf-bmwg-mcast-02.txt>
                Terminology for IP Multicast Benchmarking

 Mar 97 Aug 97  <draft-ietf-bmwg-ippm-loss-01.txt>
                A Packet Loss Metric for IPPM

 Jul 97 New     <draft-ietf-bmwg-secperf-00.txt>
                Benchmarking Terminology for Network Security Devices


Bridge MIB (bridge)
-------------------

 Charter
 Last Modified: 11-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Fred Baker <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Bridge MIB Working Group is chartered to define a set of managed
objects that instrument devices that conform to the IEEE 802.1
standard for MAC-layer bridges.

This set of objects should be largely compliant with (and even draw
from) IEEE 802.1(b), although there is no requirement that any
specific object be present or absent.

The MIB object definitions produced will be for use by SNMP and will
be consistent with other SNMP objects, standards, and conventions.



 Internet-Drafts:

  No Current Internet-Drafts.


Calendaring and Scheduling (calsch)
-----------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Robert Moskowitz <[e-mail]>
     Anik Ganguly <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       [SUBSCRIBE/UNSUBSCRIBE in Message body]
     Archive:           http://www.imc.org/ietf-calendar/mail-archive/

Description of Working Group:

Calendaring and group scheduling products are well established for
organizational use, but they usually are limited to exchange of
information among users of the same system, usually within the
boundaries of a single organization. This working group will pursue
development of standards to enable different products to interoperate
and to work across organizational boundaries. This work will include
the development of MIME content types to represent common objects
needed for calendaring and group scheduling transactions and access
protocols between systems and between clients and servers. The working
group will also consider and recommend solutions to the security issues
concerning the exchange of calendar information between network
entities.

The group will exist to create standards that make calendaring and
scheduling software significantly more useful and to enable a new class
of solutions to be built that are only viable if open standards exist.
The Calendaring and Scheduling Working Group is chartered to focus on
Internet standards for three basic problems facing group scheduling and
calendaring users today. These include the following:

1. A standard content type for capturing calendar event and to-do
   information. The content type should be suitable as a MIME message
   entity that can be transferred over MIME based email systems or HTTP
   World Wide Web. The basic objects along with their representation
using
   MIME will be specified in the document entitled "Core Object
   Specification".

2. A standard peer-to-peer protocol for common calendaring and group
   scheduling transactions.  For example, these may include exchanging
   over the Internet, event-requests, reply to event-requests,
   cancellation notices for event-requests, requesting free/busy time
   and replying to free/busy time requests between different
   calendaring products.  The working group will undertake this work in
   two phases, with the first phase focusing on meeting requests and
   the second phase on free-busy time.  To the extent that the
   peer-to-peer protocol has requirements related to security, the
   working group will attempt to apply existing Internet standards for
   authentication, and to assure privacy and integrity of sensitive
   calendaring information.  The protocol for the interoperable
   transactions will be specified in a document called "Calendar
   Interoperability Protocol" in the milestone list.

3. A standard access protocol to allow for the management of calendars,
   events and to-dos over the Internet. This protocol will be specified
   in the document called "Calendar Access Protocol" in the milestone
   list.

   This working group effort should be developed and stabilized with a
   6-9 months since there has been considerable prior work done in this
   area. This prior body of work includes:

   * Distributed Scheduling Protocol (CHRONOS) IETF Working Group
   * ISO/IEC SC18 Distributed Office Application for Calendaring,
     Scheduling and Appointments
   * MHS Alliance Calendaring and Scheduling Interoperability Protocol
     (CSIP)
   * X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA)
     and Calendaring and Scheduling Interoperabilty Specification
     (CSIS)
   * X/Open Consortium Calendaring and Scheduling (XCS) Implementor's
     Specification
   * Versit vCalendar format


   The working group will focus on harmonizing, evolving and developing
   protocols and algorithms based on this work. The process is subject
   to extension if many new features are added, or more revision is
   needed.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 97 Oct 97  <draft-ietf-calsch-ical-04.txt>
                Internet Calendaring and Scheduling Core Object Specification
                (iCalendar)

 Feb 97 Apr 97  <draft-ietf-calsch-ical-issues-01.txt>
                Core Object Specification - Issues Document

 Feb 97 New     <draft-ietf-calsch-cih-00.txt>
                Calendaring Interoperability over HTTP (CIH)

 Mar 97 New     <draft-ietf-calsch-rtreq-00.txt>
                Real-time Protocol Requirements

 May 97 Oct 97  <draft-ietf-calsch-imip-02.txt>
                iCalendar Message-based Interoperability Protocol (iMIP)

 Jul 97 Oct 97  <draft-ietf-calsch-mod-02.txt>
                Internet Calendar Model Specification

 Jul 97 Oct 97  <draft-ietf-calsch-itip-01.txt>
                iCalendar Transport-Independent Interoperability Protocol
                (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries


Common Authentication Technology (cat)
--------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Linn <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://bitsy.mit.edu/cat-ietf/archive/

Description of Working Group:

The goal of the Common Authentication Technology (CAT) Working Group is
to provide distributed security services (including authentication,
integrity, and confidentiality) to a variety of protocol callers in a
manner which insulates those callers from the specifics of underlying
security mechanisms.

By separating security implementation tasks from the tasks of
integrating security data elements into caller protocols, those tasks
can be partitioned and performed separately by implementors with
different areas of expertise. This provides leverage for the IETF
community's security-oriented resources, and allows protocol
implementors to focus on the functions their protocols are designed to
provide rather than on characteristics of security mechanisms. CAT
seeks to encourage uniformity and modularity in security approaches,
supporting the use of common techniques and accommodating evolution of
underlying technologies.

In support of these goals, the working group pursues several
interrelated tasks. We have defined a common service interface allowing
callers to invoke security services in association-oriented
environments, with an associated token format identifying the security
mechanism being employed. A revision to this document set is currently
being finalized in response to implementation experience. The CAT
Working Group also defines underlying mechanisms to provide security
services, and supports integration of security services into caller
protocols. Related work areas include interface and mechanism
extensions under consideration for message protection in
store-and-forward environments and for authorization support.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 94 Oct 97  <draft-ietf-cat-idup-gss-08.txt>
                Independent Data Unit Protection Generic Security Service
                Application Program Interface  (IDUP-GSS-API)

 Mar 95 Aug 97  <draft-ietf-cat-kerberos-pk-init-04.txt>
                Public Key Cryptography for Initial Authentication in Kerberos

 Mar 95 Mar 97  <draft-ietf-cat-gssv2-cbind-04.txt>
                Generic Security Service API Version 2 : C-bindings

 Mar 95 Apr 97  <draft-ietf-cat-idup-cbind-03.txt>
                Independent Data Unit Protection Generic Security Service
                Application Program Interface: C-bindings

 Jul 95 Jul 97  <draft-ietf-cat-snego-06.txt>
                The Simple and Protected GSS-API Negotiation Mechanism

 Nov 95 Mar 97  <draft-ietf-cat-xgssapi-acc-cntrl-02.txt>
                Extended Generic Security Service APIs: XGSS-APIs Access
                control and delegation extensions

 Nov 96 Aug 97  <draft-ietf-cat-kerberos-pk-cross-02.txt>
                Public Key Cryptography for Cross-Realm Authentication in
                Kerberos

 Feb 97 New     <draft-ietf-cat-pktapp-00.txt>
                Public Key Utilizing Tickets for Application Servers (PKTAPP)

 Mar 97 New     <draft-ietf-cat-kerb-chg-password-00.txt>
                Kerberos Change Password Protocol

 Mar 97 New     <draft-ietf-cat-kerberos-err-msg-00.txt>
                Integrity Protection for the Kerberos Error Message

 Jul 97 New     <draft-ietf-cat-kerberos-revisions-00.txt>
                The Kerberos Network Authentication Service (V5)

 Jul 97 New     <draft-ietf-cat-ftpdsaauth-00.txt>
                FTP Authentication Using DSA

 Jul 97 New     <draft-ietf-cat-ftpkeasj-00.txt>
                Encryption using KEA and SKIPJACK

 Sep 97 New     <draft-ietf-cat-kerberos-anoncred-00.txt>
                Anonymous Credentials in Kerberos

 Sep 97 New     <draft-ietf-cat-rfc2078bis-00.txt>
                Generic Security Service Application Program Interface, Version
                2

 Oct 97 New     <draft-ietf-cat-user2user-00.txt>
                User to User Kerberos Authentication using GSS-API Preliminary
                Draft

 Oct 97 New     <draft-ietf-cat-krb5-ipv6-00.txt>
                Kerberos over IPv6


Dynamic Host Configuration (dhc)
--------------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Ralph Droms <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Thomas Narten  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe listname Your Name
     Archive:           Send email to [e-mail] with HELP as the text.

Description of Working Group:

This working group will produce a protocol for automated allocation,
configuration and management of IP addresses and TCP/IP protocol stack
parameters. Specific functions to be included in the protocol include:

o Automated allocation and recovery of IP addresses

o Automated configuration of all TCP/IP stack parameters, as described
  in the Host Requirements documents

o Interaction between DHCP and DNS dynamic update protocol (ddns)

o Automated configuration of other host parameters such as application
  layer services

o Inter-server communication for coordination of multiple servers

o Mechanisms for the authentication of clients and servers

A specification the Dynamic Host Configuration Protocol (DHCP) for IPv4
has been entered into the IETF standards track. As of 3/97, it has been
accepted as a "Draft Standard". The working group is also developing a
specification for DHCP for IPv6 (DHCPv6), which is currently available
as an Internet Draft.

More information on DHCP and the DHC WG can be found at
http://www.bucknell.edu/~droms/dhcp.

Other DHC Lists:

General Discussion:               [e-mail]
DHCP-DNS Interaction:             [e-mail]
Implementation issues:            [e-mail]
Bakeoff events:                   [e-mail]
Inter-server protocol:            [e-mail]
DHCP for IPv6:                    [e-mail]
Implementation issues for DHCPv6: [e-mail]

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 95 May 97  <draft-ietf-dhc-dhcpv6-10.txt>
                Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

 Feb 96 May 97  <draft-ietf-dhc-dhcp-dns-04.txt>
                Interaction between DHCP and DNS

 Feb 96 Aug 97  <draft-ietf-dhc-authentication-04.txt>
                Authentication for DHCP Messages

 Feb 96 Jul 97  <draft-ietf-dhc-options-opt127-03.txt>
                An Extension to the DHCP Option Codes

 Feb 96 Jul 97  <draft-ietf-dhc-fqdn-opt-03.txt>
                An option for FQDNs in DHCP options

 Feb 96 Aug 97  <draft-ietf-dhc-v6exts-07.txt>
                Extensions for the Dynamic Host Configuration Protocol for IPv6

 Aug 96 May 97  <draft-ietf-dhc-slp-02.txt>
                DHCP Options for Service Location Protocol

 Nov 96 Mar 97  <draft-ietf-dhc-userclass-01.txt>
                The User Class Option for DHCP

 Nov 96 Jul 97  <draft-ietf-dhc-timezone-03.txt>
                DHCP Option for IEEE 1003.1 POSIX Timezone Specifications

 Nov 96 Aug 97  <draft-ietf-dhc-interserver-02.txt>
                An Inter-server Protocol for DHCP

 Dec 96 Aug 97  <draft-ietf-dhc-agent-options-02.txt>
                DHCP Relay Agent Information Option

 Mar 97 Aug 97  <draft-ietf-dhc-multopt-01.txt>
                Multicast address allocation extensions options

 Mar 97 Aug 97  <draft-ietf-dhc-mdhcp-02.txt>
                Multicast address allocation extensions to the Dynamic Host
                Configuration Protocol

 Mar 97 New     <draft-ietf-dhc-dyn-subnet-conf-00.txt>
                DSCP: Dynamic Subnet Configuration Protocol

 Mar 97 New     <draft-ietf-dhc-sio-00.txt>
                The Server Identification Option for DHCP

 Mar 97 New     <draft-ietf-dhc-sso-00.txt>
                The Server Selection Option for DHCP

 Mar 97 Aug 97  <draft-ietf-dhc-security-arch-01.txt>
                Security Architecture for DHCP

 Apr 97 New     <draft-ietf-dhc-interserver-alt-00.txt>
                An Inter-server Protocol for DHCP

 May 97 New     <draft-ietf-dhc-namedpool-00.txt>
                The Named Pool Request Option for DHCP

 Jul 97 Oct 97  <draft-ietf-dhc-netware-options-01.txt>
                Netware/IP Domain Name and Information

 Jul 97 New     <draft-ietf-dhc-securing-dhc-00.txt>
                Securing DHCP

 Jul 97 New     <draft-ietf-dhc-subsel-00.txt>
                Subnet Selection Option for DHCP

 Aug 97 New     <draft-ietf-dhc-domsrch-00.txt>
                The Domain Search Option for DHCP


Distributed Management (disman)
-------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Randy Presuhn <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Technical Advisor(s):
     Bob Stewart  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe disman your_email_address
     Archive:

Description of Working Group:

The Distributed Management Working Group is chartered to define an
initial set of managed objects for specific distributed network
management applications and a framework in which these applications and
others can be consistently developed and deployed. A distributed
network manager is an application that acts in a manager role to
perform management functions and in an agent role so that it can be
remotely controlled and observed.

Distributed network management is widely recognized as a requirement
for dealing with today's growing internets. A manager application is a
good candidate for distribution if it requires minimal user
interaction, it would potentially consume a significant amount of
network resources due to frequent polling or large data retrieval, or
it requires close association with the device(s) being managed.

The working group will limit its work to distributed network management
applications where the communication mechanism used between managers
(or the components of the management application) is SNMP. Future work
(and other working groups) may be chartered to investigate other
distribution techniques such as CORBA or HTTP. The objects defined by
the working group will be consistent with the SNMP framework. The
working group will especially keep security considerations in mind when
defining the interface to distributed management.

The working group will complete these tasks:

   o Define a Threshold Monitoring MIB
   o Define a Script MIB
   o Define a Distribution Management Framework and MIB

This last MIB is required in order to keep distributed managers from
adding to the management problem. This MIB will allow distributed
managers of many types to be controlled in a consistent way including
controlling their "management domain" (the set of devices upon which
they act), the relationships between the management applications or
components, and to some extent the scheduling of their operation.

The working group will consider existing definitions, including:

   o RFC1451, The Manager to Manager MIB which was being considered by
     the SNMPv2 working group

   o the RMON working group's work in this area

   o the SNMP Mid-Level-Manager MIB which is now an expired
     Internet-Draft

   o the work of the Application MIB working group

It is recognized that the scope of this working group is narrow
relative to the potential in the area of distributed network
management. This is intentional in order to increase the likelihood of
producing useful, quality specifications in a timely manner. However,
we will keep in mind and account for potential related or future work
when developing the framework including:

   o Event and alarm logging and distribution
   o Historical data collection/summarization
   o Topology discovery

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Mar 97  <draft-ietf-disman-script-mib-01.txt>
                Definitions of Managed Objects for the Delegation of Management
                Scripts

 Jan 97 New     <draft-ietf-disman-framework-00.txt>
                Distributed Management Framework

 Apr 97 May 97  <draft-ietf-disman-event-mib-01.txt>
                Event MIB

 Apr 97 Jun 97  <draft-ietf-disman-express-mib-02.txt>
                Expression MIB

 Apr 97 May 97  <draft-ietf-disman-mgt-target-mib-01.txt>
                Management Target MIB

 Apr 97 May 97  <draft-ietf-disman-notify-mib-01.txt>
                Notification MIB


Data Link Switching MIB (dlswmib)
---------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Shannon Nix <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Technical Advisor(s):
     Deirdre Kostick  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://host name/pub/standards/aiw/maillogs/mib.mail

Description of Working Group:

The DLSw MIB Working Group is chartered to define a set of managed
objects for devices that support Data Link Switching (DLSw) version 1.
DLSw is a method for encapsulating SNA (System Network Architecture) or
NetBIOS (Network Basic Input Output Services) traffic in TCP/IP. DLSw
is intended to aid in the transport of SNA and NetBIOS traffic across
WANs. The objects will be the minimum necessary to provide the ability
to monitor and control DLSw devices, supporting fault isolation,
configuration and performance management. The set of objects will be
consistent with the SNMP framework and existing SNMP standards.

The working group will consider existing enterprise-specific MIB
modules that define objects which support management of these devices.

The working group recognizes that managed objects for later versions of
DLSw  may need to be identified in the future.  These objects are out
of scope for the current (i.e., 1995) charter; however, once the
working group completes its charter, a new charter identifying some or
all of these components may be considered.

 Internet-Drafts:

  No Current Internet-Drafts.


DNS IXFR, Notification, and Dynamic Update (dnsind)
---------------------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Randy Bush <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://rs.internic.net/archives/namedroppers

Description of Working Group:

The DNS Incremental Transfer, Notification, and Dynamic Update Working
Group is concerned with three areas of future DNS protocol
development:

 1. Incremental Zone Transfer - As the sizes of some zone files have
grown
    quite large, it is believed that a protocol addition to allow the
    transfer of only the changed subset of a zone will reduce net
traffic
    and the load on critical servers.

 2. Change Notification - There can be large time intervals during which
    at least one secondary has data that is inconsistent with the
primary.
    The proposed ``notify'' mechanism (where the primary sends a message
    to known secondaries) facilitates fast convergence of servers
    vis-a-vis consistency of data in the zones.

 3. Dynamic Update - The need to frequently update small portions of a
    large zone and to have those updates propagate is perceived.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 95 May 97  <draft-ietf-dnsind-classless-inaddr-03.txt>
                Classless IN-ADDR.ARPA delegation

 Nov 96 Apr 97  <draft-eastlake-kitchen-sink-02.txt>
                The Kitchen Sink Resource Record

 Jan 97 Oct 97  <draft-ietf-dnsind-ncache-08.txt>
                Negative Caching of DNS Queries (DNS NCACHE)

 Jul 97 Oct 97  <draft-ietf-dnsind-test-tlds-04.txt>
                Test and Example Top Level Domain Names

 Aug 97 Oct 97  <draft-ietf-dnsind-local-names-02.txt>
                Local DNS Names


Domain Name System Security (dnssec)
------------------------------------

 Charter
 Last Modified: 28-Aug-96

 Current Status: Active Working Group

 Chair(s):
     James Galvin <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.tis.com/pub/lists/dns-security

Description of Working Group:

The Domain Name System Security Working Group (DNSSEC) will ensure
enhancements to the secure DNS protocol to protect the dynamic update
operation of the DNS. Specifically, it must be possible to detect the
replay of update transactions and it must be possible to order update
transactions. Clock synchronization should be addressed as well as all
of the dynamic update specification.

Some of the issues to be explored and resolved include

o scope of creation, deletion, and updates for both names and zones

o protection of names subject to dynamic update during zone transfer

o scope of KEY resource record for more specific names in wildcard
  scope

o use of or relationship with proposed expiration resource record

One essential assumption has been identified: data in the DNS is
considered public information. This assumption means that discussions
and proposals involving data confidentiality and access control are
explicitly outside the scope of this working group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 94 Aug 97  <draft-ietf-dnssec-as-map-05.txt>
                Mapping Autonomous Systems Number into the Domain Name System

 Feb 96 Mar 97  <draft-ietf-dnssec-ddi-02.txt>
                Detached Domain Name System Information

 Mar 97 New     <draft-ietf-dnssec-in-key-00.txt>
                The DNS Inverse Key Domain

 Jun 97 New     <draft-ietf-dnssec-dhk-00.txt>
                Storage of Diffie-Hellman Keys in the Domain Name System

 Jul 97 Aug 97  <draft-ietf-dnssec-secext2-01.txt>
                Domain Name System Security Extensions

 Sep 97 New     <draft-ietf-dnssec-dss-00.txt>
                DSA KEYs and SIGs in the Domain Name System

 Sep 97 New     <draft-ietf-dnssec-certs-00.txt>
                Storing Certificates in the Domain Name System

 Sep 97 New     <draft-ietf-dnssec-indirect-key-00.txt>
                Indirect Keys in the Domain Name System


Detailed Revision/Update of Message Standards (drums)
-----------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     C Newman <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://cs.utk.edu/pub/drums/mail-archive/

Description of Working Group:

The goal of this working group is to develop and review revised
versions of RFC 821 and RFC 822, incorporating the revisions in RFC
974, RFC 1123, and RFC 1651.

In addition, the group will review other RFCs related to messaging, and
determine the applicability of each of these to the future direction of
the messaging in the Internet. The group may choose to incorporate,
deprecate, or write applicability statements for such documents, as
necessary to produce a clear statement of requirements for overall
interoperability of Internet electronic mail.

The documents produced by the working group are intended to be
submitted to the IESG for consideration as Internet Standards.

Items appropriate for inclusion in documents produced by the working
group include corrections, clarifications, and amplifications to
reflect existing practice or to address problems which have been
identified through experience with Internet mail protocols. New
functionality is expressly inappropriate.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 95 Aug 97  <draft-ietf-drums-smtpupd-06.txt>
                Simple Mail Transfer Protocol

 Mar 96 Oct 97  <draft-ietf-drums-abnf-05.txt>
                Augmented BNF for Syntax Specifications: ABNF

 Nov 96 Aug 97  <draft-ietf-drums-MHRegistry-01.txt>
                Mail and Netnews Header Registration Procedure

 Nov 96 Jun 97  <draft-ietf-drums-msg-fmt-02.txt>
                Message Format Standard

 Oct 97 New     <draft-ietf-drums-kre-reply-to-00.txt>
                Use of Reply-To in Internet E-Mail messages


Electronic Data Interchange-Internet Integration (ediint)
---------------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Rik Drummond <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe
     Archive:           http://www.imc.org/edi/lists/ietf-ediint

Description of Working Group:

Electronic Data Interchange (EDI) is a set of protocols for conducting
highly structured inter-organization exchanges, such as for making
purchases or initiating loan requests.  The initial RFC1767 defined the
method for packaging the EDI X12 and UN/EDIFACT transactions sets in a
MIME envelope.  However, several additional requirements for obtaining
multi- vendor, inter-operable service, over and above how the EDI
transactions are packaged, have come to light since the effort
concluded. These currently revolve around security issues such as EDI
transaction integrity, privacy and non- repudiation in various forms.
Additional requirements that mimic many of the heading fields found in
X.435 EDI messages (e.g.; Interchange Sender, Interchange Recipient,
interchange Control Reference, Communications Agreement ID, and Syntax
Identifier) are also needed to support exchanges by point-to-point, FTP
and SMTP protocols.  Standards in these and other areas are necessary
to ensure inter- operability between EDI packages over Internet.
Various technologies already exist for these additional features and
the primary requirement is to review and select a common set of
components for use by the EDI community when it sends EDI over the
Internet.  In effect, the effort is to provide an EDI over the Internet
Informational and Applicability Statement Document.


Deliverables:

The group will produce Four documents:

   1) An Informational document describing the requirements
      for interoperable EDI, with sufficient background
      material to give an explanation for the EDI community
      of the Internet-related issues.

   2) A Applicability Statement describing how current
      Internet standards can be used to achieve this
      functionality for MIME and SMTP.

   3) A Applicability Statement describing how current
      Internet standards can be used to achieve this
      functionality for Process-to-Process (real-time) EDI.

  4) Security Issues for Inter-organizational EDI over
      Internet.

Additional Administrative information:

Editor:
        Chuck Shih <[e-mail]>
    John DesJardins <[e-mail]>
    Marc Blanchet <[e-mail]>
        First Readers: Rik Drummond <[e-mail]>

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 96 Jul 97  <draft-ietf-ediint-req-03.txt>
                Requirements for Inter-operable Internet EDI

 Oct 96 Jul 97  <draft-ietf-ediint-as1-04.txt>
                MIME-based Secure EDI


Entity MIB (entmib)
-------------------

 Charter
 Last Modified: 11-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Keith McCloghrie <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe entmib your_email_address
     Archive:           ftp://ftp.cisco.com/entmib/entmib

Description of Working Group:

The goal of this working group is to standardize a set of managed
objects representing logical and physical entities and the
relationships between them. Logical entities can occur when a single
agent supports multiple instances of one MIB, such as RFCs 1253, 1493,
1516 or 1525, where each instance represents a single (logical)
device/entity. Physical entities are the actual physical components on
which the logical entities operate; typically, the physical components
exist in a hierarchy. The set of objects will be consistent with the
SNMP framework and existing SNMP standards.

The scope of this MIB should allow an NMS to interrogate a standard
SNMP context and thereby discover what logical and physical entities
exist, how to access the MIB information of each logical entity, and
the relationships between the various entities. The MIB should support
both a single agent or multiple agents in one physical entity. The
Working Group should adopt a minimalist approach for the (initial) MIB
so as to maximize the chance of success, e.g., read-only.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 97 Sep 97  <draft-bierman-entmib-compid-01.txt>
                Entity MIB Extesions for Persistent Component Identification


Internet Fax (fax)
------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Dave Crocker <[e-mail]>
     James Rafferty <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       In Body:             subscribe
     Archive:           http://www.imc.org/ietf-fax/

Description of Working Group:

Facsimile (fax) serves as a reliable, inexpensive global communications
service.  As the Internet becomes pervasive, integrating fax and
Internet services is appealing in terms of cost savings and
opportunities for functional enhancements.  This working group will
pursue a review and specification for enabling standardized
messaging-based fax over the Internet.   It  will also develop informal
requirements for fax<->Internet gateways as a first step toward
devising standards for session-based fax over the Internet.  The
messaging-based (via e-mail)  service will be specified first, since it
should produce useful results for the least additional technical
effort.

Facsimile/Internet integration can be considered in terms of two user
service models, in order of increasing technical difficulty:

o    Messaging (as with electronic mail) having high latency
o    Session-based, for observed delivery, with or without
     capabilities negotiation

Within these models, a real-time (telephone network replacement) based
service is considered to be a subset of the session-based model.

For interconnecting fax services over the dial-up telephone network and
carriage of facsimile message data over the Internet, two types of
interface systems are required:

o    Internet/Dial-up Fax gateway, moving data from the Internet to
     classic or Internet-aware dial-up fax products and services

o    Dial-up/Internet Fax gateway, moving data from classic or
     Internet-aware dial-up fax products and services to the Internet

The dominant fax communications mode in use today is a session-based
connection operating in  real-timeover the dial up telephone network;
hence an Internet-based direct replacement service would potentially
save significant long- distance telephone charges.  However, it is
believed that from a technical standpoint this service is the most
difficult task to produce over the Internet, whereas an messaging-based
service is likely to be the simplest.    In addition, it is anticipated
that the two services will ultimately utilize at least some common
technical components.  Therefore, this working group will initially
review and specificy messaging-based fax over the Internet, using as
much existing practice as possible.

The working group will take the following steps to specify a core
fax-related messaging service over the Internet:

     Terminology:  Develop a shared set of terminology and definitions,
     to ensure a common framework for participants having differing
     backgrounds in Internet protocols and facsimile
     telecommunication.

     Data Representations:  Review existing facsimile- related Internet
     data specifications and accept, modify, replace or augment them,
     with particular attention to their encapsulation, such as via
     MIME.

     Addressing and transport:  Specify the mechanisms for addressing
     and receipt notification for facsimile data carried via Internet
     mail.

For session-oriented operation, the following specification will be
created, as a basis for further work:

     Operational constraints:  Detail the operational constraints for
     achieving session-oriented use of messaging, tailored for timely
     delivery with the sender waiting for delivery confirmation.
     Existing protocols and data specifications will be used as much as
     possible.

The working group will take note of quality of service
issues.

The working group will coordinate its activities with other
facsimile- related standards bodies.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 97 Sep 97  <draft-ietf-fax-tiff-04.txt>
                Tag Image File Format (TIFF) - Application F

 Mar 97 Oct 97  <draft-ietf-fax-tiffplus-02.txt>
                File Format for Internet Fax

 Jul 97 Sep 97  <draft-ietf-fax-tiff-reg-02.txt>
                Tag Image File Format (TIFF) - image/tiff MIME Sub-type
                Registration

 Aug 97 New     <draft-ietf-fax-smtp-session-00.txt>
                SMTP Service Extension for Immediate Delivery

 Sep 97 Oct 97  <draft-ietf-fax-addressing-01.txt>
                PSTN and fax address format in e-mail services v3.4

 Sep 97 New     <draft-ietf-fax-tiff-f-reg-00.txt>
                Tag Image File Format (TIFF) - image/tiff-f           MIME
                Sub-type Registration

 Oct 97 New     <draft-ietf-fax-itudc-00.txt>
                PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL


Common Indexing Protocol (find)
-------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Roland Hedberg <[e-mail]>
     Patrik Faltstrom <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       in body: subscribe find
     Archive:           ftp://ftp.bunyip.com/pub/mailing-lists/find

Description of Working Group:

On the Internet, several more or less localized directory services have
evolved over the last couple of years. Also 2 global directory services
have been deployed, X.500 and Whois++. To be able to find something or
someone, one needs to know what service to use, and what server to
query.

One step towards the solution of this problem is to define one and only
one common indexing protocol which all directory services can use when
passing indexing information. When a user queries one server it should
be possible for that user to get a referral to another server and even
another service, if the two servers have exchanged index information.

For this to work, one common protocol must be developed. The idea is to
expand on the Centroid ideas used by Whois++, to allow it to be used
for other services than Whois++. At the very least, a localized service
should be able to be polled by an indexing server using the Common
Indexing Protocol (CIP). To be specific, three specifications are to be
presented:

 o An interface spec, where one says how you present a query and what
   the referrals you get back look like

 o A server interface spec, where one says that the CIP will be able
   to include information presented in this format

 o An engine spec, which specifies that this is how one support the
   functionality using Centroids a la Whois++.

The task for this working group is to create the Common Indexing
Protocol so it is (1) usable for other distributed directory services
such as X.500, (2) allows the use of non-distributed directory services
such as CCSO in the distributed directory service, and (3) addresses
needs such as replication to make the protocol itself more stable.

Just because the Common Indexing Protocol is already in use by Whois++,
but not published, the first task of this group is to publish version 1
of the Common Indexing Protocol as is. After that, the protocol must be
extended according to the specification below. This will result in
version 2 of the protocol.

Other topics to be addressed potentially include:

 o Incremental updates of indices

 o Support for the UTF-FSS encoding of UNICODE

 o Guidelines for building an effective mesh of indexing servers

 o Administrative protocols and procedures such as server registration

  o Security between directory services

The working group will work in very close cooperation with the working
groups ASID and IDS in the IETF.

The working group will use the following Internet-Drafts as input:

 o Architecture of the Whois++ Index Service, Chris Weider
    <draft-ietf-wnils-whois-03.txt>
 o How to interact with a Whois++ mesh, Patrik Faltstrom
    <draft-ietf-wnils-whois-mesh-01.txt>


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Sep 97  <draft-ietf-find-cip-tagged-03.txt>
                A Tagged Index Object for use in the Common Indexing Protocol

 Feb 97 New     <draft-ietf-find-ldapc-00.txt>
                A CIP-based Centroid Exchange for LDAP

 Mar 97 Oct 97  <draft-ietf-find-cip-soif-02.txt>
                CIP Index Object Format for SOIF Objects

 Apr 97 Jul 97  <draft-ietf-find-cip-hierarchy-01.txt>
                Hierarchical Extensions to the Common Indexing Protocol

 May 97 New     <draft-ietf-find-soif-registry-00.txt>
                Registration Procedures for SOIF Template Types

 Jun 97 New     <draft-ietf-find-cip-trans-00.txt>
                CIP Transport Protocols

 Jun 97 New     <draft-ietf-find-cip-mime-00.txt>
                MIME Object Definitions for the Common Indexing Protocol  (CIP)

 Jun 97 New     <draft-ietf-find-cip-arch-00.txt>
                The Architecture of the Common Indexing Protocol (CIP)


Frame Relay Service MIB (frnetmib)
----------------------------------

 Charter
 Last Modified: 12-Sep-97

 Current Status: Active Working Group

 Chair(s):
     James Watt <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Technical Advisor(s):
     Fred Baker  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The Frame Relay Service MIB Working Group is chartered to define an
initial set of managed objects which will be useful for customer
network management of a provider's Frame Relay Service. The working
group will consider existing definitions, including the Frame Relay
Forum's work in this area.  The objects defined by the working group
will be consistent with the SNMP framework.

The working group will coordinate with both the Frame Relay Forum and
the ATM MIB Working Group.

The working group is chartered to complete four tasks:

 a) consider revisions to the existing FRS MIB (currently published as
    a Proposed Standard in RFC 1604) in light of implementation
    experience, changes to the interface MIBs (e.g. IF-MIB, DS1-MIB,
    DS3-MIB, FR-DTE-MIB, creation of the DS0 and DS0 Bundle MIB
    modules), and evolution of the relevant non-IETF standards,

 b) prepare a Recommendation to the Area Director as to the appropriate
    disposition of the (updated) FRS MIB, i.e. that it be advanced to
    Draft Standard status or that it cycle at Proposed Status,

 c) develop a set of managed objects to provide the instrumentation
    required to manage switched-virtual circuits in a frame-relay
    environment.

 d) develop a set of managed objects to provide the instrumentation
    required to manage connections that terminate on a mixture of ATM
    and Frame Relay interfaces, i.e. interworked connections. These
    objects will be the minimum necessary to provide the ability to
    monitor and control interworked connections and shall use existing
    definitions (e.g. IF-MIB, FRS-MIB, ATM-MIB, etc.) to instrument the
    interfaces and the "native" parts of the connections.

In all cases, the working group will keep the Frame Relay and ATM
Forums informed of its progress and will actively solicit input from
those Fora.

All output of the group will be consistent with the existing SNMPv2c
framework and standards, including the SNMPv2c Structure of Management
Information (SMI).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 96 Jul 97  <draft-ietf-frnetmib-dcp-02.txt>
                Management Information Base for Frame Relay Data Compression

 Oct 96 New     <draft-ietf-frnetmib-dte-svc-00.txt>
                Management Information Base for Frame Relay DTE Extensions for
                SVC's over Frame Relay

 Nov 96 Mar 97  <draft-ietf-frnetmib-frs-mib-01.txt>
                Definitions of Managed Objects for Frame Relay Service

 Feb 97 New     <draft-ietf-frnetmib-spvc-00.txt>
                Frame Relay Service Extensions MIB for Switched PVCs


Extensions to FTP (ftpext)
--------------------------

 Charter
 Last Modified: 16-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Paul Hethmon <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe
     Archive:           http://w3.hethmon.com/ftpext/

Description of Working Group:

1. Recommend changes to the FTP protocol to support users of
   languages other than English.

2. Define a new command for a uniform directory listing between
   platforms. This command will provide an alternative to the existing
   LIST and NLST commands which has a common format between all FTP
   implementations and which also provides the ability to represent
   non-ASCII filenames.

3. Make recommendations for standards-track protocol extensions to
   support IPv6 in FTP. The group will evaluate RFC 1639 and recommend,
   revise, or redo as appropriate.

4. Define a mechanism for ftp clients and servers to transmit
   information regarding extensions supported and not supported.

5. Propose extensions, and/or review proposals submitted by others,
   to improve the security of FTP.

6. Define a standardized method of checkpoint/restart which works
   for the stream transfer mode.

7. Define a means of file transfer between a client and server
   (as opposed to a client mediating a transfer between two servers)
   which does not require the IP addresses of the endpoints to
   be transmitted in the FTP protocol.

8. Produce an informational document describing the SIZE and MDTM
   commands as currently used.

The following issues are specifically omitted from the working group's

charter, but may be added by the Area Directors if time permits,
once the above goals have been acheived.

1. Compression of files for transmission.

2. Internationalization of charset conversion for transmission.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Aug 97  <draft-ietf-ftpext-mlst-02.txt>
                Extended Directory Listing and Restart Mechanism for FTP

 Nov 96 Jun 97  <draft-ietf-ftpext-intl-ftp-02.txt>
                Internationalization of the File Transfer Protocol

 Mar 97 New     <draft-ietf-ftpext-restart-00.txt>
                REST Command and Extensions to FTP

 Jun 97 Jul 97  <draft-ietf-ftpext-feat-01.txt>
                Feature negotiation mechanism for the File Transfer Protocol


G and R for Security Incident Processing (grip)
-----------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Louis Mamakos <[e-mail]>
     Barbara Fraser <[e-mail]>
     K.P. Kossakowski <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     Michael O'Dell  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The full name of this working group is Guidelines and Recommendations
for Security Incident Processing.

This working group is co-chartered by the Security Area.

The purpose of the GRIP Working Group is to provide guidelines and
recommendations to facilitate the consistent handling of security
incidents in the Internet community. Guidelines will address technology
vendors, network service providers, response teams in their roles
assisting organizations in resolving security incidents. These
relationships are functional and can exist within and across
organizational boundaries.

The working group will produce two quality documents:

1) Guidelines for security incident response teams.

2) Guidelines for vendors (this will include both technology producers
   and network service providers).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 95 Sep 97  <draft-ietf-grip-framework-irt-08.txt>
                Expectations for Computer Security Incident Response

 Oct 97 New     <draft-ietf-grip-isp-00.txt>
                Security Expectations for Internet Service Providers


HyperText Transfer Protocol (http)
----------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Larry Masinter <[e-mail]>
     Dave Raggett <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe http-wg Your Full Name
     Archive:           http://www.ics.uci.edu/pub/ietf/http/hypermail

Description of Working Group:

Note: This working group is jointly chartered by the Applications Area
      and the Transport Services Area.

The HTTP Working Group will work on the specification of the Hypertext
Transfer Protocol (HTTP). HTTP is a data access protocol currently run
over TCP and is the basis of the World-Wide Web. The initial work will
be to document existing practice and short-term extensions. Subsequent
work will be to extend and revise the protocol. Directions which have
already been mentioned include:

 o improved efficiency,
 o extended operations,
 o extended negotiation,
 o richer metainformation, and
 o ties with security protocols.

Note: the HTTP working group will not address HTTP security extensions
as these are expected to be the topic of another working group.

Background information

The initial specification of the HTTP protocol was kept in hypertext
form and a snapshot circulated as an Internet draft between 11/93 and
5/94. A revision of the specification by Berners-Lee, Fielding and
Frystyk Nielsen has been circulated as an Internet draft between 11/94
and 5/95. An overview of the state of the specifications and a
repository of pointers to HTTP resources may be found at

  http://www.w3.org/hypertext/WWW/Protocols/Overview.html

Once established, the working group will expand and complete that
document to reflect HTTP/1.0 as it has been implemented by World-Wide
Web clients and servers prior to November 1994. The resulting
specification of HTTP/1.0 will be published for review as an
Internet-Draft and, if deemed appropriate, will be submitted to the
IESG for consideration as a Proposed Standard or Informational RFC.

In parallel with the above effort, the working group will consider
enhancements/restrictions to the current practice in order to form a
specification of the HTTP protocol suitable for eventual consideration
as a proposed standard.

Also in parallel with the above efforts, the working group will engage
in defining (or selecting from various definitions) a next-generation
protocol for hypertext transfer (HTTPng).

A description of HTTP/1.0 as it is generally practiced currently on the
Internet has been submitted to become an Informational RFC. The working
group is considering enhancements/restrictions to the current practice
in order to form a specification of the HTTP protocol suitable for
eventual consideration as a proposed standard.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 95 Jul 97  <draft-ietf-http-pep-04.txt, .ps>
                PEP - an Extension Mechanism for HTTP

 Feb 96 Sep 97  <draft-ietf-http-negotiation-04.txt>
                Transparent Content Negotiation in HTTP

 Oct 96 Jul 97  <draft-ietf-http-feature-reg-02.txt>
                Feature Tag Registration Procedures

 Feb 97 Jul 97  <draft-ietf-http-rvsa-v10-02.txt>
                HTTP Remote Variant Selection Algorithm -- RVSA/1.0

 Mar 97 New     <draft-ietf-http-warning-00.txt>
                Problem with HTTP/1.1 Warning header, and proposed fix

 Mar 97 Sep 97  <draft-ietf-http-uahint-01.txt>
                The User Agent Hint Response Header

 Mar 97 Oct 97  <draft-ietf-http-state-man-mec-04.txt,.ps>
                HTTP State Management Mechanism (Rev1)

 Mar 97 New     <draft-ietf-http-connection-00.txt>
                HTTP Connection Management

 May 97 Oct 97  <draft-ietf-http-jaye-trust-state-01.txt>
                HTTP Trust Mechanism for State Management

 Jun 97 Jul 97  <draft-ietf-http-negotiate-scenario-01.txt>
                Scenarios for the Delivery of Negotiated Content using HTTP

 Jun 97 New     <draft-cohen-http-305-306-responses-00.txt>
                HTTP/1.1 305 and 306 Response Codes

 Jul 97 Jul 97  <draft-ietf-http-feature-scenarios-01.txt>
                Feature Tag Scenarios

 Jul 97 Aug 97  <draft-ietf-http-options-02.txt>
                Specification of HTTP/1.1 OPTIONS messages

 Jul 97 New     <draft-ietf-http-digest-aa-rev-00.txt>
                An Extension to HTTP : Digest Access Authentication

 Sep 97 New     <draft-ietf-http-req-sum-00.txt>
                Format and Example of HTTP/1.1 Requirements Summary

 Sep 97 New     <draft-ietf-http-alternates-00.txt>
                The Alternates Header Field

 Oct 97 New     <draft-ietf-http-v11-spec-rev-00.txt,.ps>
                Hypertext Transfer Protocol -- HTTP/1.1


IEEE 802.3 Hub MIB (hubmib)
---------------------------

 Charter
 Last Modified: 11-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Dan Romascanu <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.rose.hp.com/pub/hubmib

Description of Working Group:

This working group will produce a document describing MIB objects for
use in managing Ethernet-like hubs. A hub is defined as a multiport
repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s
Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd
edition, Sept. 1990). These hub MIB objects may be used to manage
non-standard repeater-like devices, but defining objects to describe
vendor-specific properties of non-standard repeater-like devices is
outside the scope of this working group. The MIB object definitions
produced will be for use by SNMP and will be consistent with other SNMP
objects, conventions, and definitions.

In order to minimize the instrumentation burden on managed agents, the
MIB definitions produced by the working group will whereever feasible
be semantically consistent with the managed objects defined in the IEEE
Standard 802.3u, Section 30, "10 Mb / s & 100 Mb / s Management".

The working group will produce a document describing MIB objects for
use in management of connectivity boxes that include Ethernet ports
with a behavior consistent to the repeater ports defined by the 802.3
Standards. The repeater ports will be mapped to the internal box
structure that may inlude one or more repeater units that conform to
the IEEE 802.3/ISO 8802-3 CSMA/CD standard. If so, all instrumentation
variables will be backward compatible with the existing hardware
implementations that comply to the IEEE 802.3 repeaters.

The mapping model defined by this MIB module may be used by other type
of non-802.3 units (e.g. 802.12 repeaters) to map their own port
management objects to the multiple repeaters inside a connectivity
box.

Consistent with the IETF policy regarding the treatment of MIB
definitions produced by other standards bodies, the working group may
choose to consider only a subset of those objects in the IEEE
specification and is under no obligation to consider (even for
``Optional'' status) all objects defined in the IEEE specification.
Moreover, when justified by special operational needs of the community,
the Working Group may choose to define additional MIB objects that are
not present in the IEEE specification.

Although the definitions produced by the working group should be
architecturally consistent with MIB-II and related MIBs wherever
possible, the charter of the working group does not extend to
perturbing the conceptual models implicit in MIB-II or related MIBs in
order to accommodate 802.3 hubs. In particular, to the extent that the
notion of a ``port'' in an 802.3 hub is not consistent with the notion
of a network ``interface'' as articulated in MIB-II, it shall be
modelled independently by objects defined in the working group.

Because the structure of 802.3 hub implementations varies widely, the
working group shall take special care that its definitions reflect a
generic and consistent architectural model of hub management rather
than the structure of particular hub implementations.

The IEEE hub Management draft allows an implementor to separate the
ports in a hub into groups, if desired (i.e., a vendor might choose to
represent field-replaceable units as groups of ports so that the port
numbering would match a modular hardware implementation). Because the
working group charter does not extend to consideration of
fault-tolerant, highly-available systems in general, its treatment of
these groups of ports in an 802.3 hub (if any) shall be specific to hub
management and without impact upon other portions of the MIB.

The working group is further chartered at its discretion to define an
SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An
802.3 Medium Attachment Unit (MAU) attaches a repeater port or
Ethernet-like interface to the local network medium. The scope of this
work may include several types of MAU units: 10BASE-5 (thick coax),
10BASE-2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F
(fiber optic). Managed objects defined as part of the MAU MIB task may,
for example, represent such information as MAU type, link status, and
jabbering indications.

The working group is further chartered to define an SNMP MIB for the
management of the 100Base-T hubs, MAUs and interfaces, or to propose
aditions / changes to existing MIB modules that deal with IEEE 802.3
hubs, MAUs or interfaces in order to extend their support to 100Base-T.
In case when those MIB modules are the result of the work of another
working group in the NM Area, the proposal will be submited to the
directorate and the respective WG.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 95 Mar 97  <draft-ietf-hubmib-mau-mib-04.txt>
                Definitions of Managed Objects for IEEE 802.3 Medium Attachment
                Units (MAUs) using SMIv2


Inter-Domain Multicast Routing (idmr)
-------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Tony Ballardie <[e-mail]>
     Bill Fenner <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www.jnx.com/~pusateri/idmr

Description of Working Group:

Existing inter-domain multicast routing protocols are not scalable to
  a large internetwork containing very large numbers of active
  wide-area groups.  The purpose of the IDMR Working Group, therefore,
  is to discuss proposed inter-domain multicast routing protocols, and
  put forward one (or a hybrid of several) as a Proposed Standard
  to the IESG.

  Several proposals have been made to date, including Core-Based Tree
  (CBT) multicasting, Core-Based Join (CBJ) multicasting, and Scalable
  Reverse Path Multicasting (SRPM).  Some of the above have yet to be
  reviewed.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 94 Mar 97  <draft-ietf-idmr-pim-mib-03.txt>
                Protocol Independent Multicast MIB

 Jul 94 Jul 97  <draft-ietf-idmr-igmp-mib-05.txt>
                Internet Group Management Protocol MIB

 Jul 94 Mar 97  <draft-ietf-idmr-multicast-routmib-05.txt>
                IP Multicast Routing MIB

 Aug 95 Oct 97  <draft-ietf-idmr-igmp-v2-07.txt>
                Internet Group Management Protocol, Version 2

 Jan 96 May 97  <draft-ietf-idmr-pim-dm-spec-05.txt>
                Protocol Independent Multicast Version 2, Dense Mode
                Specification

 Feb 96 Oct 97  <draft-ietf-idmr-dvmrp-v3-05.txt,.ps>
                Distance Vector Multicast Routing Protocol

 Apr 96 New     <draft-ietf-idmr-cbt-br-spec-00.txt>
                Core Based Tree (CBT) Multicast Border Router Specification

 Jul 97 New     <draft-ietf-idmr-cbt-mib-00.txt>
                Core Based Trees (CBT) Multicast Routing MIB

 Aug 97 Oct 97  <draft-ietf-idmr-gum-01.txt>
                Border Gateway Multicast Protocol (BGMP): Protocol
                Specification

 Sep 97 New     <draft-ietf-idmr-pim-sm-specv2-00.txt,.ps>
                Protocol  Independent  Multicast-Sparse   Mode   (PIM-SM):
                Protocol Specification


Inter-Domain Routing (idr)
--------------------------

 Charter
 Last Modified: 04-Jun-97

 Current Status: Active Working Group

 Chair(s):
     Susan Hares <[e-mail]>
     Y Rekhter <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.merit.edu/mail.archives/idr

Description of Working Group:

The main list for this working group is [e-mail], but there is
also an IDRP-specific mailing list:

- List: [e-mail]

- To Subscribe: [e-mail]

- Archive: merit.edu:/pub/archive/idrp

The Inter-Domain Routing Working Group is chartered to standardize and
promote the Border Gateway Protocol Version 4 (BGP-4) and ISO
Inter-Domain Routing Protocol (IDRP) as scalable inter-autonomous
system routing protocols capable of supporting policy based routing for
TCP/IP internets.   The objective is to promote the use of BGP-4 to
support IP version 4 (IPv4).  IDRP is seen as a protocol that will
support IPv4 as well as the next generation of IP (IPv6).

The working group will plan a smooth transition between BGP-4 and
IDRP.

Documents:

1) BGP-4 (standards track)

   This document contains the specification of the BGP protocol that
   enables it to be used as a protocol for exchange of ``inter-autonomous
   system information'' among routers to support forwarding
   of IPv4 packets across multiple autonomous systems.

2) BGP-4 MIB (standards track)

   This document contains the MIB definitions for BGP-4.

3) IDRP for IPv4/IPv6 (standards track)

   This document contains the appropriate adaptations of the IDRP
   protocol definition that enables it to be used as a protocol for
   exchange of ``inter-autonomous system information'' among routers to
   support forwarding of IPv4 or IPv6 packets across multiple
   autonomous systems.

4) IDRP MIB (standards track)

   This document contains the MIB definitions for IDRP.

5) BGP/IDRP -- OSPF Interactions (standards track)

   This document will specify the interactions between BGP/IDRP and
   OSPF. This document will be based on a combination of the BGP - OSPF
   interactions, and IDRP - IS-IS interaction documents.

6) BGP/IDRP Usage (standards track)

   Most of BGP/IDRP Usage document will reference the CIDR
   (supernetting) RFCs and related Internet-Drafts. IDRP Usage will
   contain a sample policy configuration language and examples on how
   to use IDRP in the Internet today.

7) BGP-4 to IDRP v6 Transition (standards track)

   This document will provide information on how to transition between
   BGP-4 and IDRP v6 networks.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 94 Jun 97  <draft-ietf-idr-bgp4-06.txt>
                A Border Gateway Protocol 4 (BGP-4)

 Nov 95 Mar 96  <draft-ietf-idr-bgp4-mib-02.txt>
                Definitions of Managed Objects for the Fourth Version of Border
                Gateway Protocol (BGP-4)

 Feb 97 Jul 97  <draft-ietf-idr-aggregation-framework-01.txt>
                A Framework for Inter-Domain Route Aggregation

 Jul 97 New     <draft-ietf-idr-as-dedicated-00.txt>
                Using a Dedicated AS for Sites Homed to a Single Provider

 Jul 97 New     <draft-ietf-idr-aggregation-tutorial-00.txt>
                Route Aggregation Tutorial

 Sep 97 Sep 97  <draft-ietf-idr-bgp4-multiprotocol-01.txt>
                Multiprotocol Extensions for BGP-4

 Sep 97 New     <draft-ietf-idr-bgp4-cap-neg-00.txt>
                Capabilities Negotiation with BGP-4


Integrated Directory Services (ids)
-----------------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Sri Sataluri <[e-mail]>
     Linda Millington <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://terminator.rs.itd.umich.edu/ietf-ids/archive

Description of Working Group:

The Integrated Directory Services (IDS) Working Group is chartered to
facilitate the integration and interoperability of current and future
directories into a unified Internet directory service. This work will
unite directories based on a heterogeneous set of directory
services protocols (X.500, WHOIS++, etc.).

In addition to specifying technical requirements for the integration,
the IDS Working Group will also contribute to the administrative and
maintenance issues of directory service offerings by publishing
guidelines on directory data integrity, maintenance, security, and
privacy and legal issues for users and administrators of directories.

The IDS Working Group will pay special attention to the creation of an
Internet White Pages Directory Service and will sponsor and track
projects to achieve this goal and specifically take steps to facilitate
wide-spread experimentation of the protocols evolving in the ASID
Working Group.

The IDS Working Group will work on applications of directory technology
and will track ongoing applications projects.  The IDS Working Group
will assume responsibility for the creation and maintenance of on-line
catalogs of directory services implementations.  These catalogs will be
periodically published as Informational RFCs.

The IDS Working Group will take up the unfinished tasks of the WHIP -
White Pages Requirements Working Group - that was constituted at the
Seattle IETF.  The WHIP Working Group set out to define the basic
requirements for a Simple Internet White Pages Service.

The IDS Working Group will liaise with the groups working on
development and deployment of the various directory service protocols.

The IDS Working Group is a combined effort of the Applications Area and
the User Services Area of the IETF.

Ongoing Activities:

  Track emerging directory service protocols in order to identify the
  need for specifying standards for interworking with other service
  protocols

  Liaise with groups working on deployment and development of directory
  services to locate and fix interoperability problems.

  Identify unfilled needs of directory service offerers,
  administrators, and users.

Catalogs maintained on-line, with occasional publication as RFCs:

   RFC due   On-line version          Name

   Dec 95    Jun 95 A Catalog of WHOIS++ Implementations.
                    -- Patrick Faltstrom (first issue)
   Dec 95    Jul 95 The On-line X.500 Directory Implementations Catalog
                    (on-line version of RFC 1632).
                    -- Chris Apple and Ken Rossen

Pilot Projects reporting to this group:

    The Long Bud Project -- Internet Pilot Project for the
    Deployment of X.500 Directory Information in Support of
    X.400 Routing (RFC 1802)
    Co-ordinator: Kevin Jordan
    Lifetime: Jan 94 - Dec 96

    The Internet Nomenclator Project
    Co-ordinator: Joann Ordille
    Lifetime: Jun 95 - Jun 97

    The Internet Whois++ Project
    Co-ordinator: Patrick Faltstrom
    Lifetime: Jun 95 - Jun 97

    The Internet X.500 (1993) Directory Project
    Co-ordinator: Vincent Berkhout
    Lifetime: Dec 95 - Dec 97

    The Schema Registry project - identifying and publishing X.500
    schema elements used on the Internet
    Co-ordinator: Sri Sataluri
    Lifetime: November 94 - Nov 96

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 95 New     <draft-ietf-ids-x500-intro-dir-00.txt>
                Introducing a Directory Service

 Dec 95 May 97  <draft-ietf-ids-ph-03.txt>
                The CCSO Nameserver (Ph) Architecture

 May 96 Apr 97  <draft-ietf-ids-ds-bcp-04.txt>
                Best Current Practice for the Internet White Pages Service

 Jun 96 Aug 97  <draft-ietf-ids-snqp-01.txt>
                Simple Nomenclator Query Protocol (SNQP)

 Sep 96 Aug 97  <draft-ietf-ids-inp-02.txt>
                Internet Nomenclator Project

 Nov 96 Sep 97  <draft-ietf-ids-dirnaming-02.txt>
                Naming Plan for Internet Directory-Enabled Applications


Interfaces MIB (ifmib)
----------------------

 Charter
 Last Modified: 02-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Theodore Brunner <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Thomas Narten  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://thumper.bellcore.com/pub/tob/ifmib

Description of Working Group:

The Interfaces MIB working group is reactivated and chartered to
accomplish one task: to prepare a recommendation to the IESG evaluating
RFC 1573 with respect to the standards track.

The recommendation will document implementation, interoperability, and
deployment experience.  If this experiences suggests that changes should
be made to the documents, new drafts may be prepared.

The recommendation will report one of four outcomes: that the RFC should
be advanced from proposed to draft status, without changes (if no
problems are found); that a draft prepared by the working group, should
replace the RFC, and be designated a draft standard (if only minor
changes are made); that a draft prepared by the working group, should
replace the RFC, and be designated a proposed standard (if major changes
or feature enhancements are made); or, that the RFC should be designated
as historic (if this technology is problematic).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jan 96 Oct 97  <draft-ietf-ifmib-mib-06.txt>
                The Interfaces Group MIB

 Jun 96 Jun 97  <draft-ietf-ifmib-testmib-03.txt>
                Definitions of Managed Objects for System and Interface Testing


Integrated Services (intserv)
-----------------------------

 Charter
 Last Modified: 13-May-97

 Current Status: Active Working Group

 Chair(s):
     C. Partridge <[e-mail]>
     John Wroclawski <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/int-serv/int-serv.mail

Description of Working Group:

Recent experiments demonstrate the capability of packet switching
protocols to support Integrated Services --- the transport of audio,
video, real-time, and classical data traffic within a single network
infrastructure.  These experiments suggest that expanding the Internet
service model would better meet the needs of these diverse applications.
The purpose of this working group is to specify this enhanced service model
and then to define and standardize certain interfaces and requirements
necessary to implement the new service model.

The working group will focus on defining a minimal set of global
requirements which transition the Internet into a robust
integrated-service communications infrastructure.  Enhancements to
individual protocols (e.g., adding additional routing information to
routing protocols, or choosing IP queueing disciplines for routers)
will be left to other working groups, except in those rare cases where
detailed definitions of behavior are critical to the success of the
enhanced architecture.

Extending the Internet service model raises a series of questions.
The working group will focus on the three problems listed below:

    (1) Clearly defining the services to be provided. The first task faced
    by this working group is to define and document the enhanced Internet
    service model.

    (2) Defining the application service, router scheduling and (general)
    subnet interfaces.  The working group must define at least three
    high-level interfaces: that expressing the application's end-to-end
    requirements, that defining what information is made available to
    individual routers within the network, and the additional expectations
    (if any) the enhanced service model has for subnet technologies.  The
    working group will define these abstract interfaces, and will coordinate
    with and advise IP over "subnet" working groups (such as IP over ATM)
    in this.

    (3) Developing router validation requirements which can ensure that
    the proper service is provided.  We assume that the Internet will
    continue to contain a heterogeneous set of routers, running different
    routing protocols and using different forwarding algorithms.  The
    working group will seek to define a minimal set of additional router
    requirements which ensure that the Internet can support the new
    service model. Rather than presenting specific scheduling and admission
    control algorithms which must be supported, these requirements will likely
    take the form of behavioral tests which measure the capabilities of
    routers in the integrated services environment. This approach is used
    because no single algorithm seems likely to be appropriate in all
    circumstances at this time.  The working group will coordinate with
    the Benchmarking Working Group (BMWG).

We expect to generate three RFCs as a product of performing these tasks.

An important aspect of this working group's charter is in coordination
with the development of IP Next Generation.  The working group will
be reviewed in November 1995 to determine if it should be re-chartered
as is or modified to reflect IPng developments, in particular, but also
operational and commercial developments.  The IESG deems the great
significance of this working group to merit this unusual review.

In addition, because many of the integrated services concepts are new,
the working group may produce Informational RFCs explaining specific
algorithms that may be appropriate in certain circumstances, and may host
some educational meetings to assist both IETF members and members of the
larger Internet community to understand the proposed enhancements to IP.

The working group proposes to hold regular meetings beyond those held at
the IETF meetings.

APPENDIX - Integrated Services Working Group Management Plan

The general chair is Craig Partridge (BBN).  The co-chairs are Dave Clark
(MIT), Scott Shenker (XEROX), and John Wroclawski (MIT).

The dual reasons for this management structure are:

    (1) The working group will have do considerably more outreach into the
    larger networking community than the typical IETF working group.  For
    instance, one of the important tasks is to convince the larger public
    that IP is suitable for integrated services.  So we need management
    manpower to do outreach.

    (2) The working group has a lot of work to do and swiftly.  Even though
    we plan to spin off working groups as fast as we can, a lot of key
    architectural decisions will need to be made in one place (e.g., by
    this working group) if the final architecture is to be sound.  So we
    need management manpower just to keep the working group moving.

So Craig has primary responsibility for keeping the working group moving,
and Dave, Scott, and John have primary responsibility for outreach to
different communities (and titles sufficient to show they can speak for
the working group).


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 97 Oct 97  <draft-ietf-intserv-control-flow-01.txt>
                A Measurement Based Admission Control Algorithm for
                Controlled-Load Service with a Reference Implementation
                Framework

 Oct 97 New     <draft-ietf-intserv-v2-mib-00.txt>
                Integrated Services Management Information Base


Internetworking Over NBMA (ion)
-------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     A. Malis <[e-mail]>
     George Swallow <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       In Body: subscribe
     Archive:           ftp://ftp.nexen.com/pub/ion

Description of Working Group:

Note: This Working Group is jointly chartered by the Routing Area.
The Routing Area Director:  Joel Halpern ([e-mail])

Motivation

The Internetworking Over NBMA Working Group was formed to combine the
work of two previous working groups, IP Over ATM (ipatm) and Routing
Over Large Clouds (rolc), because these two groups were often working
very closely together on similar, if not identical, problems and
solutions.  The group will be evolutionary, not revolutionary; it will
continue the work in the previous groups on the NBMA Next Hop
Resolution Protocol (NHRP), IPv4 over ATM, and IPv6 over ATM.

Description

This WG will focus on the issues involved in internetworking network
layer protocols over NBMA (non-broadcast multiple access) subnetwork
technologies, such as ATM, Frame Relay, SMDS, and X.25 private and
public networks.  The group will endeavor to make all its solutions
applicable to the entire range of network layer protocols and NBMA
subnetworks.  We recognize, however, that there will be cases where
specific optimizations to IPv4, IPv6, and particular subnetwork
technologies will result in better service to the user.

The group will focus on protocols for encapsulation, multicasting,
addressing, address resolution and neighbor discovery, interactions
with and optimization of internetworking-layer routing protocols when
run over NBMA subnetworks, and protocol-specific network management
support, as appropriate.  The working group will submit these
protocols for standardization.

The working group may also produce experimental and informational
documents, including "Best Current Practices" guidelines, as
required.

For ATM, the WG will continue the ipatm WG's transition from the LIS
model described in RFC 1577 to the generalized NHRP model developed by
the rolc WG, including a transition plan for existing networks.

The working group will coordinate its activities with the following
other working groups:

1) Integrated Services over Specific Lower Layers (issll), for
   coordinating Quality of Service (QoS) issues and the implementation
   of IP integrated services capabilities (RSVP, the service models,
   etc.) over NBMA networks.

2) IP Next Generation (ipng), for IPv6 over ATM coordination.

The working group will also coordinate its work with other relevant
standards bodies (e.g., ATM Forum, Frame Relay Forum, ANSI T1S1,
ITU-T) and make recommendations to these organizations regarding the
requirements for IP internetworking where the current published
subnetwork standards, practices, or functionality do not meet the
needs of internetworking.

The working group will not develop subnetwork layer standards.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 93 Sep 97  <draft-ietf-iplpdn-frmib-dte-11.txt>
                Management Information Base for Frame Relay DTEs

 Mar 93 Oct 97  <draft-ietf-rolc-nhrp-12.txt>
                NBMA Next Hop Resolution Protocol (NHRP)

 Mar 95 Jul 97  <draft-ietf-ion-nhrp-appl-02.txt>
                NHRP Protocol Applicability Statement

 Sep 95 Oct 97  <draft-ietf-ion-ipatm-classic2-03.txt>
                Classical IP and ARP over ATM

 Nov 95 Jul 97  <draft-ietf-ion-mib-04.txt>
                Definitions of Managed Objects for Classical IP and ARP Over
                ATM Using SMIv2

 Feb 96 Oct 97  <draft-ietf-ion-scsp-02.txt>
                Server Cache Synchronization Protocol (SCSP)

 Mar 96 Oct 97  <draft-ietf-ion-sig-uni4.0-05.txt>
                ATM Signalling Support for IP over ATM - UNI Signalling 4.0
                Update

 Apr 96 New     <draft-ietf-ion-ipv6-00.txt>
                IPv6 over Non-Broadcast Multiple Access (NBMA) networks

 Jul 96 Jan 97  <draft-ietf-ion-nhrp-mib-01.txt>
                Definitions of Managed Objects for the NBMA Next Hop Resolution
                Protocol (NHRP)

 Jul 96 May 97  <draft-ietf-ion-fr-update-03.txt>
                Multiprotocol Interconnect over Frame Relay

 Nov 96 May 97  <draft-ietf-ion-transition-02.txt>
                Classical IP to NHRP Transition

 Nov 96 May 97  <draft-ietf-ion-inarp-update-01.txt>
                Inverse Address Resolution Protocol

 Nov 96 Sep 97  <draft-ietf-ion-mars-mib-03.txt>
                Definitions of Managed Objects for Multicast over UNI 3.0/3.1
                based ATM Networks

 Feb 97 New     <draft-ietf-ion-r2r-nhrp-00.txt>
                NHRP for Destinations off the NBMA Subnetwork

 Feb 97 Aug 97  <draft-ietf-ion-intralis-multicast-01.txt>
                Intra-LIS IP multicast among routers over ATM using Sparse Mode
                PIM

 Apr 97 New     <draft-ietf-ion-scsp-atmarp-00.txt>
                A Distributed ATMARP Service Using SCSP

 Apr 97 Oct 97  <draft-ietf-ion-scsp-nhrp-02.txt>
                A Distributed NHRP Service Using SCSP

 Jul 97 New     <draft-ietf-ion-discov-atmarp-00.txt>
                ILMI-Based Server Discovery for ATMARP

 Jul 97 New     <draft-ietf-ion-discov-mars-00.txt>
                ILMI-Based Server Discovery for MARS

 Jul 97 New     <draft-ietf-ion-scsp-mars-00.txt>
                A Distributed MARS Service Using SCSP

 Jul 97 New     <draft-ietf-ion-intra-area-unicast-00.txt>
                Intra-area IP unicast among routers over legacy ATM

 Aug 97 New     <draft-ietf-ion-discov-nhrp-00.txt>
                ILMI-Based Server Discovery for NHRP

 Oct 97 New     <draft-ietf-ion-ipv6-atm-00.txt>
                IPv6 over ATM Networks


IP Over IEEE 1394 (ip1394)
--------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Tony Li <[e-mail]>
     Myron Hattig <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ip1394
     Archive:           [e-mail]. In body, get ip1394 LOGyymm

Description of Working Group:

The goal of the IP1394 Working Group is to define how the Internet
Protocol (IPv4 & IPv6) is supported over IEEE 1394 Serial Bus. IEEE
1394 Serial Bus (1394) is specified by IEEE Std 1394-1995 and the draft
standard IEEE P1394a. The IP1394 working group intends for the
specification to be utilized by devices with a broad range of
capabilities. These devices are expected to include (but not be limited
to) both traditional equipment such as computers, as well as equipment
that has not traditionally been networked, such as consumer electronics
(e.g. TVs & VCRs).

Unlike most other data link protocols, IEEE 1394 provides the
capability for isochronous as well as asynchronous transmission. This
capability can have a significant impact on how IP is supported on
1394. The IP1394 working group will prepare an architecture document
and appropriate protocol documents for the usage of these unique link
layer properties. Both IPv4 and IPv6 will be addressed, although in
separate documents.

The IP1394 working group is chartered to deliver the documents
described below. The working group will maintain informal liaison with
other standards groups and industry organizations doing related work.
Some of these documents may depend upon facilities not currently
standardized in 1394. If necessary, working group members will work
within the IEEE standards process to request modification or extension
of existing IEEE standards (or standards in development).

The deliverable documents are as follows:

- An architecture document detailing the interactions between 1394
  asynchronous and isochronous transmissions, resource reservation and
  multicast.

- An IPv4 over 1394 document covering the encapsulation and framing of
  IPv4 unicast, multicast and broadcast packets over asynchronous and
  isochronous 1394, including address resolution.

- An IPv6 over 1394 document covering the encapsulation and framing of
  IPv6 unicast, multicast and broadcast packets over asynchronous and
  isochronous 1394, including neighbor discovery.

- A media-specific MIB for managing 1394 interfaces.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 97 Oct 97  <draft-ietf-ip1394-ipv4-04.txt,.ps>
                Ipv4 over IEEE 1394


IP over Cable Data Network (ipcdn)
----------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Mike St. Johns <[e-mail]>
     Masuma Ahmed <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.terayon.com/pub/ipcdn

Description of Working Group:

The goal of the IPCDN WG is to define how the Internet Protocol (IP) is
to be supported on a Cable Television (CATV) Data Network. The working
group will prepare a framework and requirements document describing a
typical CATV infrastructure and how an IP based network might be
architected to utilize this infrastructure. It will also address the
service interface between IP and the CATV Data Network. The
architecture document will discuss the technical details related to the
differences between symmetric and asymmetric CATV Data Networks. A
terms of reference document will also be published.

Currently, there are no standards available for supporting IP over a
CATV Data Network. The IEEE 802.14 WG is chartered to specify the
physical layer and data link layer protocols for the CATV Data Network.
However, this does not address the issue of mapping higher level
protocols onto the hybrid fiber coax (HFC) access networks. The IPCDN
WG will define a specification of how IP is mapped onto HFC access
networks. Both IPv4 and IPv6 will be addressed, although in separate
documents. The following topics will be discussed:

   multicast, broadcast, address mapping and resolution (for IPv4) and
   neighbor discovery (for IPv6).

The IPCDN WG will also address issues related to network management,
especially as they concern HFC access networks. It is expected that
other services (i.e. DHCP, RSVP, IPSEC, etc.) will operate unmodified.
Also, depending on the capabilities provided by cable data network
service, specific mappings of RSVP service classes to lower layer
services might be desirable. If additional capabilities become
necessary, these will be directed to the appropriate group.

The IPCDN WG will also keep informed on what other groups in the
industry are doing as it relates to the work of this working group.

The WG is chartered to deliver the following set of documents:

  -  informational RFCs covering the framework, architecture,
     requirements and terms of reference for Cable Data Networks.

  -  an IPv4-over-HFC access network document covering the mapping
     of  IP over RF channels, encapsulation and framing of  IPv4 packets,
     IP to modem and/or PC address resolution, multicast, and broadcast.

  -  an IPv6-over-HFC access network document covering the mapping
     of  IP over RF channels , encapsulation and framing of  IPv6 packets,
     IP to modem and/or PC address resolution, neighbor discovery,
     multicast, and broadcast.

 -   a media-specific mib for managing HFC spectrum.

 -   a mib for managing cable data network service including
     management of IP over cable data network.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 97 Sep 97  <draft-ietf-ipcdn-cable-device-mib-01.txt>
                Cable Device Management Information Base for MCNS compliant
                Cable Modems and Cable Modem Termination Systems

 Jul 97 Sep 97  <draft-ietf-ipcdn-rf-interface-mib-01.txt>
                Radio Frequency (RF) Interface Management Information Base for
                MCNS compliant RF interfaces

 Jul 97 New     <draft-ietf-ipcdn-tor-00.txt>
                IP Over Cable Data Networks - Terms of Reference

 Jul 97 New     <draft-ietf-ipcdn-ipover-802d14-00.txt>
                Logical IP Subnetworks over IEEE 802.14 Services

 Aug 97 New     <draft-ietf-ipcdn-ip-over-mcns-00.txt>
                Logical IP Subnetworks over MCNS Data Link Services


IPNG (ipngwg)
-------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Bob Hinden <[e-mail]>
     Steve Deering <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       in body: subscribe ipng
     Archive:           ftp://playground.sun.com/pub/ipng/mail-archive

Description of Working Group:

Editor: Bob Hinden ([e-mail])

The next generation of the Internet Protocol (IPv6) is intended to
support Internet traffic for many years into the future by providing
enhancements over the capabilities of the existing IPv4 service. This
working group will produce specifications for the core functionality of
that service.  The working group shall carry out the recommendations of
the IPng Area Directors as outlined at the July 1994 IETF and in ``The
Recommendation for the IP Next Generation Protocol,'' Internet-Draft,
(draft-ipng-recommendation-00.txt), September 1994.

The working group shall use the following documents as the basis of its
work:

  - Simple Internet Protocol Plus (SIPP) Specification (128 bit version)

  - SIPP Addressing Architecture

  - An Architecture for IPv6 Unicast Address Allocation

  - Simple SIPP Transition (SST) Overview

  - SIPP Program Interfaces for BSD Systems

  - SIPP Security Architecture

  - SIPP Authentication Header

  - SDRP Routing Header for SIPP-16

  - IP Next Generation Overview

  - ICMP and IGMP extensions for SIPP

  - FTP Operation Over Big Address Records (FOOBAR)

  - DNS Extensions to support SIPP

Enhancements to be considered:

  - Large Packets: Consider extensions for support of datagrams which
are
    larger than 64K.

  - Source Routing: The working group shall consider enhanced source
    routing capabilities for IPng.

  - Tunneling:  Complete specification of IPng in IPng tunneling.

  - Address format and assignment plan: The working group shall review
the
    details of address structure as specified in [SIPP-16] and shall
    repair any deficiencies with respect to current or near-term
    addressing requirements, assuming a fixed, 16-byte size.  The
    specification shall provide a mechanism for supporting multiple
    additional formats, for possible enhancement to incorporate other
    popular addressing schemes.

  - Routing Structure: In completing the addressing details, the working
    group shall ensure that routing according to current, CIDR-like
    schemes can be supported comfortably.

  - Autoconfiguration: Coordinate with the IPng Address
Autoconfiguration
    Working Group.

  - Transition: The working group shall coordinate with the related
    transition and conversion efforts (ngtrans, tacit, nosi, etc.) to
    ensure that the base specification provides the facilities required
    for the transition from IPv4.

  - Security: A set of base documents for IPng security shall be
    completed.  This shall include algorithms for authentication and
    privacy carried as IPng extension headers and include an initial
    selection of required encryption and key management algorithms and a
    facility to support other optional algorithms.  The working group
    should also examine IPng firewall issues and if necessary develop
    specific firewall frameworks.

  - Minimum MTU: Consider a larger minimum MTU.

  - Header Compression: Consider ways to abbreviate the IPng header in
the
    contexts of native IPng, multiple IPng packets in a flow, and
    encapsulated IPng.

  - TCP/UDP: The IPng Working Group will specify the procedures for
hosts
    to compute and verify TCP/UDP pseudo-headers.  Any other changes to
    TCP beyond making TCP work with IPng are out of scope of the working
    group and should be dealt with by a TCPng Working Group.

The IPng Working Group will coordinate with other groups, including
Mobile IP, IPng Address Autoconfiguration, OSPF, IS-IS, RIPv2, IDR,
Security, Applications, Network Management, IP over ATM, etc.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 95 Jun 97  <draft-ietf-ipngwg-ipv6-tunnel-07.txt>
                Generic Packet Tunneling in IPv6 Specification

 Jun 96 Jan 97  <draft-ietf-ipngwg-linkname-01.txt>
                Link Local Addressing and Name Resolution in IPv6

 Jun 96 Jul 97  <draft-ietf-ipngwg-ipv6router-alert-03.txt>
                IPv6 Router Alert Option

 Oct 96 Jul 97  <draft-ietf-ipngwg-multicast-assgn-04.txt>
                IPv6 Multicast Address Assignments

 Dec 96 Jul 97  <draft-ietf-ipngwg-ipv6-over-ppp-02.txt>
                IP Version 6 over PPP

 Feb 97 Jun 97  <draft-ietf-ipngwg-ipv6-mib-02.txt>
                Management Information Base for IP Version 6:  Textual
                Conventions and General Group

 Feb 97 Mar 97  <draft-ietf-ipngwg-ipv6-icmp-mib-01.txt>
                Management Information Base for IP Version 6:  ICMPv6 Group

 Feb 97 Mar 97  <draft-ietf-ipngwg-ipv6-udp-tcp-mib-01.txt>
                Management Information Base for IP Version 6:  UDP and TCP
                Groups

 Feb 97 New     <draft-ietf-ipngwg-gseaddr-00.txt>
                GSE - An Alternate Addressing Architecture for IPv6

 Mar 97 Sep 97  <draft-ietf-ipngwg-trans-fddi-net-03.txt>
                Transmission of IPv6 Packets over FDDI Networks

 Mar 97 Sep 97  <draft-ietf-ipngwg-trans-ethernet-03.txt>
                Transmission of IPv6 Packets over Ethernet Networks

 Mar 97 New     <draft-ietf-ipngwg-dns-rr-rgadd-00.txt>
                Synthesis of Routing Goop and AAAA Records in IPv6

 Mar 97 New     <draft-ietf-ipngwg-ipv6-arch-00.txt>
                IP Version 6 Addressing Architecture

 Mar 97 Sep 97  <draft-ietf-ipngwg-esd-analysis-01.txt>
                Separating Identifiers and Locators in Addresses:  An Analysis
                of the GSE Proposal for IPv6

 Mar 97 Jul 97  <draft-ietf-ipngwg-router-renum-01.txt>
                Router Renumbering for IPv6

 May 97 Jul 97  <draft-ietf-ipngwg-unicast-aggr-02.txt>
                An IPv6 Aggregatable Global Unicast Address Format

 May 97 Oct 97  <draft-ietf-ipngwg-addr-arch-v2-03.txt>
                IP Version 6 Addressing Architecture

 May 97 Jul 97  <draft-ietf-ipngwg-testv2-addralloc-01.txt>
                IPv6 Testing Address Allocation

 Jun 97 New     <draft-ietf-ipngwg-ipv6-tcp-mib-00.txt>
                IP Version 6 Management Information Base for the Transmission
                Control Protocol

 Jun 97 New     <draft-ietf-ipngwg-ipv6-udp-mib-00.txt>
                IP Version 6 Management Information Base for the User Datagram
                Protocol

 Jun 97 Oct 97  <draft-ietf-ipngwg-trans-tokenring-03.txt>
                Transmission of IPv6 Packets over Token Ring Networks

 Jul 97 New     <draft-ietf-ipngwg-tla-assignment-00.txt>
                TLA and NLA Assignment Rules

 Jul 97 Jul 97  <draft-ietf-ipngwg-icmp-namelookups-01.txt>
                IPv6 Name Lookups Through ICMP

 Jul 97 New     <draft-ietf-ipngwg-discovery-v2-00.txt>
                Neighbor Discovery for IP Version 6 (IPv6)

 Jul 97 New     <draft-ietf-ipngwg-addrconf-v2-00.txt>
                IPv6 Stateless Address Autoconfiguration

 Jul 97 New     <draft-ietf-ipngwg-ipv6-spec-v2-00.txt>
                Internet Protocol, Version 6 (IPv6) Specification

 Jul 97 New     <draft-ietf-ipngwg-site-prefixes-00.txt>
                Site prefixes in Neighbor Discovery

 Oct 97 New     <draft-ietf-ipngwg-icmp-v2-00.txt>
                Internet Control Message Protocol (ICMPv6) for the Internet
                Protocol Version 6 (IPv6) Specification


Internet Printing Protocol (ipp)
--------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Steve Zilles <[e-mail]>
     Carl-Uno Manros <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.pwg.org/pub/pwg/ipp/

Description of Working Group:

There is currently no universal standard for printing. Several
protocols are in use, but each has limited applicability and none can
be considered the prevalent one.  This means that printer vendors have
to implement and support a number of different protocols and protocol
variants.  There is a need to define a protocol which can cover the
most common situations for printing on the Internet.

The goal of this working group is to develop requirements for Internet
Printing and to describe a model and semantics for Internet Printing.

The further goal is to define a new application level Internet Printing
Protocol for the following core functions:

 - for a user to find out about a printer's capabilities
 - for a user to submit print jobs to a printer
 - for a user to find out the status of a printer or a print job
 - for a user to cancel a previously submitted job

The Internet Print Protocol is a client-server type protocol which
should allow the server side to be either a separate print server or a
printer with embedded networking capabilities. The focus of this effort
is optimized for printers, but might be applied to other output
devices.  These are outside the scope of this working group.

The working group will also define a set of directory attributes that
can be used to ease finding printers on the network.

The Internet Print Protocol will include mechanisms to ensure adequate
security protection for materials to be printed, including at a minimum
mechanisms for mutual authentication of client and server and
mechanisms to protect the confidentiality of communications between
client and server.

Finally, the IPP working group will produce recommendations for
interoperation of LPR clients with IPP servers, and IPP clients with
LPR servers.  These recommendations will include instructions for both
the translation of the LPR protocol onto IPP and the translation of the
IPP protocol onto LPR.  However, there is no expectation to provide new
IPP features to LPR clients, nor is there an explicit requirement to
translate LPR extensions to IPP, beyond those features available in the
4.2BSD UNIX implementation of LPR, and which are still useful today.

Other capabilities that will be examined for future versions include:

 - security features for authentication, authorization, and policies
 - notifications from the server to the client
 - accounting

Subjects currently out of scope for this working group are:

 - protection of intellectual property rights
 - fax input
 - scanning

The working group shall strive to coordinate its activities with other
printing-related standards bodies, without the need to be strictly
bound by their standards definitions. These groups are:

 - ISO/IEC JTC 1/SC 18/WG 4 on Document Printing Application (ISO/IEC
   10175 parts 1 - 3)
 - The Object Management Group (OMG) on OMG Printing Facility (in
   development)
 - IEEE (POSIX System Administration - Part 4: Printing Interfaces)
 - X/Open (Printing Systems Interoperabilty Specification)
 - The Printer Working Group

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Oct 97  <draft-ietf-ipp-req-01.txt>
                Requirements for an Internet Printing Protocol

 Mar 97 Oct 97  <draft-ietf-ipp-model-06.txt>
                Internet Printing Protocol/1.0: Model and Semantics

 Mar 97 Jun 97  <draft-ietf-ipp-dir-schema-01.txt>
                Internet Printing Protocol/1.0: Directory Schema

 Jun 97 Jul 97  <draft-ietf-ipp-security-01.txt>
                Internet Printing Protocol/1.0: Security

 Jul 97 Jul 97  <draft-ietf-ipp-lpd-ipp-map-01.txt>
                Mapping between LPD and IPP Protocols

 Jul 97 Oct 97  <draft-ietf-ipp-protocol-02.txt>
                Internet Printing Protocol/1.0: Protocol Specification

 Jul 97 Aug 97  <draft-ietf-ipp-rat-01.txt>
                Rationale for the Structure of the Model and Protocol for the
                Internet Printing Protocol (IPP)


IP Payload Compression Protocol (ippcp)
---------------------------------------

 Charter
 Last Modified: 21-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Naganand Doraswamy <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Thomas Narten  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe/unsubscribe ippcp [email_addr] in body
     Archive:           ftp://ftp-eng.cisco.com/ippcp/ippcp

Description of Working Group:

Lossless data compression has commonly been deployed in layers below IP
(PPP being one example). However, the anticipated deployment of
higher-layer encryption protocols (e.g., IPSec) threatens to reduce the
effectiveness of lower-layer compression techniques since encrypted
data cannot be compressed.  The IP Payload Compression Protocol Working
Group will develop protocol specifications that make it possible to
perform lossless compression on individual payloads before the payload
is processed by a protocol that encrypts it. These specifications will
allow for compression operations to be performed prior to the
encryption of a payload by such protocols as IPSec.

The Working Group will focus on the compression of independent payloads
(i.e., independent datagrams) in a stateless manner. By stateless, we
mean that decompression of a received packet does not rely on correct
reception or correct ordering of previous packets.

The immediate problem the Working Group will address is the development
of a payload compression protocol for use in conjunction with IPSec.
The working group will develop its specifications to support both IPv4
and IPv6. Although the primary motivation for this WG is the need to
compress packets when IPSec is used, the WG will develop an
architecture that does not preclude its use with other potential
protocols or the absence of IPSec.

The working group will identify and document the mechanisms that allow
two communicating parties to negotiate the use of compression as well
as the compression format to be employed. The Working Group will
consider defining extensions to ISAKMP to support the negotiation of
compression parameters. Use of ISAKMP as the immediate effort shall not
preclude compression in the absence of IPsec.  Alternate negotiation
mechanisms (or even static negotiation), if appropriate, shall be
identified and extended as needed to accommodate the use of payload
compression functionality. Since compression will be negotiated,
existing implementations of IP will interoperate with implementations
that support compression.

The output of this WG will consist of a base architectural document
that provides the framework for how compression will be done (i.e.,
defines the compression "shim"), together with one or more documents
giving specific compression algorithms and formats. The architectural
document will describe how different compression algorithms can be
negotiated and supported, but the documenting of specific compression
algorithms will be done elsewhere (i.e., in standalone documents). A
registration mechanism for various compression formats will be
specified as part of the base protocol. If possible, an existing
registration mechanism for compression formats shall be used (e.g.,
Compression Control Protocol options of PPP).






 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 97 Oct 97  <draft-ietf-ippcp-protocol-01.txt>
                IP Payload Compression Protocol (IPComp)


IP Performance Metrics (ippm)
-----------------------------

 Charter
 Last Modified: 21-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Guy Almes <[e-mail]>
     Vern Paxson <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.advanced.org/pub/IPPM/archive

Description of Working Group:

The IPPM WG will develop a set of standard metrics that can be applied
to the quality, performance, and reliability of Internet data delivery
services.  These metrics will be designed such that they can be
performed by network operators, end users, or independent testing
groups. It is important that the metrics not represent a value judgement
(i.e. define "good" and "bad"), but rather provide unbiased quantitative
measures of performance.

Functions peripheral to Internet data delivery services, such as
NOC/NIC services, are beyond the scope of this working group.

The IPPM WG will define specific metrics, cultivate technology for the
accurate measurement and documentation of these metrics, and promote
the sharing of effective tools and procedures for measuring these
metrics.  It will also offer a forum for sharing information about the
implementation and application of these metrics, but actual
implementations and applications are understood to be beyond the scope
of this working group.

 Internet-Drafts:

  No Current Internet-Drafts.


IP Security Protocol (ipsec)
----------------------------

 Charter
 Last Modified: 01-Nov-97

 Current Status: Active Working Group

 Chair(s):
     Theodore Ts'o <[e-mail]>
     Robert Moskowitz <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.tis.com/pub/lists/ipsec

Description of Working Group:

Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP. A
security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality.

The protocol formats for the IP Authentication Header (AH) and IP
Encapsulating Security Payload (ESP) will be independent of the
cryptographic algorithm. The preliminary goals will specifically pursue
host-to-host security followed by subnet-to-subnet and host-to-subnet
topologies.

Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security. The
Internet Key Management Protocol (IKMP) will be specified as an
application layer protocol that is independent of the lower layer
security protocol.The protocol will be based on the ISAKMP/Oakley work
begun in:

    draft-ietf-ipsec-isakmp-05.txt,

    draft-ietf-ipsec-oakley-01.txt, and

    draft-ietf-ipsec-isakmp-oakley-00.txt

A follow on work item may incorporate mechanisms based on SKIP as
defined in:

    draft-ietf-ipsec-skip-07.txt


and related documents.Flexibility in the protocol will allow eventual
support of Key Distribution Centers (KDC), such as are used by
Kerberos.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 95 Jul 97  <draft-ietf-ipsec-isakmp-08.txt,.ps>
                Internet Security Association and Key Management Protocol
                (ISAKMP)

 Feb 96 Jul 97  <draft-ietf-ipsec-oakley-02.txt>
                The OAKLEY Key Determination Protocol

 May 96 New     <draft-ietf-ipsec-ciph-des3-00.txt>
                The ESP Triple DES Transform

 Jun 96 Oct 97  <draft-ietf-ipsec-auth-header-02.txt>
                IP Authentication Header

 Jun 96 Jul 97  <draft-ietf-ipsec-isakmp-oakley-04.txt>
                The resolution of ISAKMP with Oakley

 Nov 96 Oct 97  <draft-ietf-ipsec-ipsec-doi-05.txt>
                The Internet IP Security Domain of Interpretation for ISAKMP

 Nov 96 Mar 97  <draft-ietf-ipsec-inline-isakmp-01.txt>
                Inline Keying within the ISAKMP Framework.

 Jan 97 New     <draft-ietf-ipsec-vpn-00.txt>
                Implementation of Virtual Private Network (VPNs) with IP
                Security

 Apr 97 New     <draft-ietf-ipsec-ciph-rc5-cbc-00.txt>
                The ESP RC5-CBC Algorithm

 May 97 New     <draft-ietf-ipsec-ciph-cast128-cbc-00.txt>
                The ESP CAST128-CBC Algorithm

 May 97 Aug 97  <draft-ietf-ipsec-revised-enc-mode-01.txt>
                A revised encryption mode for ISAKMP/Oakley

 May 97 New     <draft-ietf-ipsec-ciph-des-derived-00.txt>
                The ESP DES-CBC Transform

 Jul 97 Jul 97  <draft-ietf-ipsec-doc-roadmap-01.txt>
                IP Security Document Roadmap

 Jul 97 New     <draft-ietf-ipsec-auth-hmac-sha196-00.txt>
                The Use of HMAC-SHA-1-96 within ESP and AH

 Jul 97 New     <draft-ietf-ipsec-auth-hmac-md5-96-00.txt>
                The Use of HMAC-MD5-96 within ESP and AH

 Jul 97 New     <draft-ietf-ipsec-ciph-des-expiv-00.txt>
                The ESP DES-CBC Cipher Algorithm With Explicit IV

 Jul 97 New     <draft-ietf-ipsec-cbc-00.txt>
                ESP with Cipher Block Chaining (CBC)

 Jul 97 New     <draft-ietf-ipsec-ciph-arcfour-00.txt>
                The ESP ARCFOUR Algorithm

 Jul 97 New     <draft-ietf-ipsec-ciph-desx-00.txt>
                The ESP DES-XEX3-CBC Transform

 Jul 97 New     <draft-ietf-ipsec-ciph-blowfish-cbc-00.txt>
                The ESP Blowfish-CBC Algorithm Using an Explicit IV

 Jul 97 New     <draft-ietf-ipsec-ciph-3des-expiv-00.txt>
                The ESP 3DES-CBC Algorithm Using an Explicit IV

 Jul 97 New     <draft-ietf-ipsec-ciph-idea-cbc-00.txt>
                The ESP IDEA-CBC Algorithm Using Explicit IV

 Jul 97 Oct 97  <draft-ietf-ipsec-esp-v2-01.txt>
                IP Encapsulating Security Payload (ESP)

 Jul 97 New     <draft-ietf-ipsec-ciph-cast-div-00.txt>
                The ESP CAST5-128-CBC Transform

 Oct 97 New     <draft-ietf-ipsec-ciph-cbc-00.txt>
                The ESP CBC-Mode Cipher Algorithms

 Oct 97 New     <draft-ietf-ipsec-isakmp-mode-cfg-00.txt>
                The ISAKMP Configuration Mode


ISDN MIB (isdnmib)
------------------

 Charter
 Last Modified: 12-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Ed Alcoff <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Technical Advisor(s):
     Fred Baker  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp-eng.cisco.com/ftp/isdn-mib/isdn-mib

Description of Working Group:

The goal of the working group is to define the minimal set of managed
objects for SNMP-based management of ISDN interfaces. ISDN interfaces
are supported on a variety of equipment (for data and voice) including
terminal adapters, bridges, hosts, and routers. The set of objects will
be consistent with the SNMP framework and existing SNMP standards.

The working group will solicit any existing enterprise-specific MIB
modules to use as input to the standard MIB. The scope of the MIB is to
support remote configuration and administration; support all ISDN
interfaces and switch types; provide statistical information of ISDN
call activity; a table of ISDN call history; and SNMP traps specific to
ISDN call activity. RFC 1573 shall be used to define interface layering
issues.

 Internet-Drafts:

  No Current Internet-Drafts.


IS-IS for IP Internets (isis)
-----------------------------

 Charter
 Last Modified: 20-Oct-94

 Current Status: Active Working Group

 Chair(s):
     Doug Montgomery <[e-mail]>
     Chris Gunner <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

The IS-IS for IP Internets Working Group will develop additions to the
existing OSI IS-IS routing protocol to support IP environments and dual OSI
and IP environments.

 Internet-Drafts:

  No Current Internet-Drafts.


Internet School Networking (isn)
--------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Jodi Ito <[e-mail]>
     Sepideh Boroumand <[e-mail]>

 User Services Area Director(s):
     Joyce K. Reynolds  <[e-mail]>

 User Services Area Advisor:
     Joyce K. Reynolds  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe isn-wg <optional email address>
     Archive:

Description of Working Group:

The Internet School Networking Working Group is chartered to address
issues related to the connection of primary and secondary schools
worldwide to the Internet. The key audiences include network service
providers and educational policy makers responsible for network access
and use. The key areas of focus for this group are advocacy and
articulation.

1. Advocacy. The ISN Working Group will facilitate dialog between the
   primary and secondary education community and the Internet
   engineering community in order to identify and fulfill the needs of
   the primary and secondary school community.

2. Articulation. Informed by the group's experience, and with input
   from other IETF working groups, the ISN Working Group will
   articulate solutions to the challenges a school may experience in
   seeking and gaining a connection to the Internet, as well as the
   benefits of such a connection. Advantages to Internet connectivity
   may be articulated by means of pointers to such services as user
   interfaces, directories, organizations, and training programs, as
   well as to other resources. Articulation will most often be in the
   form of periodic documents that address key issues of interest to
   the school networking community. Representative issues to be
   addressed by the group include connectivity models, educational
   directories, and acceptable use policies.

 Internet-Drafts:

  No Current Internet-Drafts.


Integrated Services over Specific Link Layers (issll)
-----------------------------------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Wroclawski <[e-mail]>
     Eric Crawley <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://mercury.lcs.mit.edu/pub/issll/mail/

Description of Working Group:

The ISSLL Working Group defines specifications and techniques needed
to implement Internet Integrated Services capabilities within specific
network technologies.

The Internet Integrated Services design, developed within the IETF by
working groups such as INTSERV and RSVP, specifies extensions to the
IP architecture which allow applications to request and receive a
specific level of service from the internetwork, as alternatives to
the current IP best-effort service class.  The work of these groups has
resulted in technology-independent protocols and specifications.
Focused engineering work to define the mapping of these universal
specifications onto specific subnetwork technologies is now required.

At minimum, the following points must be addressed for each candidate
technology:

- Service mappings.  Service mappings define the way that the link layer
  technology is used to provide a particular IntServ traffic management
  service, such as controlled-load or guaranteed-delay.

- Setup protocol mappings.  Setup protocol mappings define how an
internet-
  level setup protocol such as RSVP is implemented or mapped onto the
link
  layer technology.

- Adaptation protocols.  Adaptation protocols are used to augment the
  native capabilities of the link-layer technology, when this is
  necessary to support required Integrated Services functions.

- Statements of non-applicability.  Statements of non-applicability
describe
  which Integrated Service capabilities are not supported by the link
  layer technology under consideration.

The ISSLL WG will carry out this work for all technologies with
perceived
market demand and of sufficient interest to its members.  To ensure
timely
progress on each work item the WG will employ an administrative
structure
based on technology coordinators, as described below.  The WG expects to
coordinate its activities across technologies whenever technical
commonality between layer two media is apparent.  The WG chairs hold
primary responsibility for this coordinating role.

WG Outputs:

The WG is expected to produce standards-track RFC's, informational RFC's
and "best-current-practices" guidelines, as required.  The need for
standards-track RFC's is limited both because the work of the group is
focused on the engineering of existing protocols to existing link layer
technologies, and because in certain cases information and guidelines
will better serve the needs of a rapidly evolving technology.

Operational Structure:

Due to the scope of the task and the need for parallel progress on
multiple work items, the WG effort is organized as follows:

A technical coordinator will be identified and selected for each media
technology adopted as a work item by the group.  This person will be
responsible for coordinating the technical efforts of the group with
respect to that media, working with and motivating the document
editors, and evangelizing the group's work within the community and
relevant external organizations such as the IEEE and ATM Forum.

Since many link layer media continue to evolve, and since that evolution
may be influenced by the work of the ISSLL WG, it is expected that each
technology work item will be divided into short term tasks, medium term
tasks, and ongoing monitoring, as follows:


- Short term tasks focus on using the existing technology as best
as possible with no changes whatsoever.  This work will accept whatever
limits are imposed the link-level and IP-level technology, with the
goal of creating the best solution possible within a 6-9 month
timeframe.

- Medium term tasks focus on planned changes to the technology that are
currently being standardized and may not yet be widely available
Ideally this work would conclude just as the changes become available
in the market.  In general a 1-1.5 year timeframe is appropriate for
these
tasks.

- Monitoring focuses on tracking and advising on changes being made by
others to a link layer technology, to allow it to better support the
Integrated Services models and protocols.  Generally, these efforts
would
be conducted as informal activities, rather than work items within the
WG
structure.  The exception would be when formal cooperation between the
WG
and an external effort was required.

In addition to the normal responsibilities of IETF working group chairs,
the ISSLL chairs hold primary responsibility for selection of
coordinators,
identifying areas of technical commonality and building cross-technology
efforts within the group.

Relationship to Other Working Groups:

The ISSLL WG maintains a close working relationship with the INTSERV
and RSVP WG's.  Particularly, ISSLL may wish to feed back information
about the effectiveness or limitations of RSVP and INTSERV work in the
context of a specific technology to these groups for review.  ISSLL is
also expected to interact with other WG's as needed to aid in the use
of particular media (e.g. IPATM, PPPEXT).

Coordinators for initially important technologies:

   ATM                 Sue Thomson, [e-mail]
   Low-Speed Serial    Carsten Bormann, [e-mail]
   Ethernet
   Token Ring          Wayne Pace, [e-mail]
   Frame Relay
   Cable Modems

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 96 Jul 97  <draft-ietf-issll-isslow-02.txt>
                Providing integrated services over low-bitrate links

 Jun 96 Aug 97  <draft-ietf-issll-atm-mapping-03.txt>
                Interoperation of Controlled-Load and Guaranteed-Service with
                ATM

 Jul 96 Jul 97  <draft-ietf-issll-is802-sbm-04.txt>
                SBM (Subnet Bandwidth Manager):  A Proposal for Admission
                Control over IEEE 802-style networks

 Sep 96 Jul 97  <draft-ietf-issll-isslow-mcml-02.txt>
                The Multi-Class Extension to Multi-Link PPP

 Sep 96 May 97  <draft-ietf-issll-is802-framework-02.txt>
                A Framework for Providing Integrated Services Over Shared and
                Switched LAN Technologies

 Dec 96 Jun 97  <draft-ietf-issll-802-01.txt>
                Integrated Services over IEEE 802.1D/802.1p Networks

 Mar 97 Jul 97  <draft-ietf-issll-isslow-rtf-01.txt>
                PPP in a real-time oriented HDLC-like framing

 May 97 New     <draft-ietf-issll-isslow-svcmap-00.txt>
                Network Element Service Specification for Low Speed Networks

 Jul 97 New     <draft-ietf-issll-atm-imp-req-00.txt, .ps>
                RSVP over ATM Implementation Requirements

 Jul 97 New     <draft-ietf-issll-atm-framework-00.txt>
                A Framework for Integrated Services and RSVP over ATM

 Jul 97 New     <draft-ietf-issll-is802-svc-mapping-00.txt>
                Integrated Service Mappings on IEEE 802 Networks


Large Scale Multicast Applications (lsma)
-----------------------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Jon Crowcroft <[e-mail]>
     Michael Myjak <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Technical Advisor(s):
     Allison Mankin  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

Note: Allyn Romanow <[e-mail]> is also an Area Technical
Advisor.


This group focuses on the needs of applications that require real-time
or near real-time communications to support a large number of
simulation processes (virtual entities). These applications have been
analyzed by the U.S. Department of Defense to require IP multicast
support for 10K simultaneous groups, for upwards of 100K virtual
entities in a global sized WAN by the year 2000.

The concrete example application is the Distributed Interactive
Simulation work of the DIS Interoperability and Standards workshops and

standardized as IEEE 1278 - 1995.

The concrete example application is the Distributed Interactive
Simulation work of the DIS Interoperability and Standards workshops and
standardized as IEEE 1278 - 1995.  Future simulation implementations
will use the  High Level Architecture (HLA) work sponsored by the U.S.
Defense Modeling and Simulation Office, and which is currently being
standardized by the newly formed Simulation Interoperability Standards
Organization (SISO).

The WG aims to provide documentation on how the IETF multicast
protocols, conference management protocols, transport protocols and
multicast routing protocols are expected to support the example
application.  The result of this WG will be two Informational documents
that we hope will be used as input and advice by a number of IETF
working groups, among them IDMR, ION, MBONED, MMUSIC, and by working
groups being developed on Reliable Multicast Applications and QOS
Routing.

The document editors for the informational documents will be Steve
Seidensticker for "Scenarios" and Mark Pullen for "Limitations".

The Scenarios document will describe the environment in which
distributed simulation applications operate. It will provide realistic
example scenarios of small, medium and large simulation exercises.  The
Limitations product will document the limitations of current IETF
products as they pertain to distributed applications. This document
will offer concise examples of how distributed applications demonstrate
these limitations and to the extent possible, offer potential solutions
to the identified limitations.

The documents will attempt to provide specific numbers for the demands
placed on protocol or infrastructure, and for the limits that protocols
impose on the applications.

The group will assess the need for new protocols to support the
requirements it identifies, and the Limitations document will report on
this assessment.  One recommendation it expects to document is for
development of a virtual reality transfer protocol.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Jul 97  <draft-ietf-lsma-scenarios-01.txt>
                Scenarios and Appropriate Protocols for Distributed Interactive
                Simulation

 Nov 96 Mar 97  <draft-ietf-lsma-limitations-01.txt>
                Limitations of Internet Protocol Suite for Distributed
                Simulation in the Large Multicast Environment

 Jul 97 New     <draft-ietf-lsma-requirements-00.txt>
                Taxonomy of Communication Requirements for Large-scale
                Multicast Applications


Mail and Directory Management (madman)
--------------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Steve Kille <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ietf-madman <email address>
     Archive:           innosoft.com:~/ietf-madman/archive.txt

Description of Working Group:

This working group is chartered to review the MIBs produced by the
madman group while in the Network Management Area (RFCs 1565, 1566,
and 1567 which were produced in January, 1994).

The aim of this re-activation is to review and update these MIBs in
the light of operational experience. This will lead to editorial and
clarification changes, and updates driven by operational requirements
based on experience.

There have been a number of commerical and research implementations of
these MIBs. The MIBs have also been adopted by the Electronic Mail
Association, who have made input to the MADMAN work.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 95 Aug 97  <draft-ietf-madman-mail-monitor-mib-05.txt>
                Mail Monitoring MIB

 Nov 95 Aug 97  <draft-ietf-madman-nsm-mib-06.txt>
                Network Services Monitoring MIB

 Dec 95 Aug 97  <draft-ietf-madman-dsa-mib-1-04.txt>
                Directory Server Monitoring MIB

 Aug 97 New     <draft-ietf-madman-trackmib-00.txt>
                Message Tracking MIB


Mobile Ad-hoc Networks (manet)
------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Joseph Macker <[e-mail]>
     Scott Corson <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe manet
     Archive:

Description of Working Group:

A "mobile ad-hoc network" is an autonomous system of mobile routers (and
associated hosts) connected by wireless links--the union of which form
an
arbitrary graph. The routers are free to move randomly and organize
themselves arbitrarily; thus, the network's wireless topology may change
rapidly and unpredictably.  Such a network may operate in a standalone
fashion, or may be connected to the larger Internet.

The focus of the working group will be to standardize an intra-domain
unicast routing protocol which efficiently reacts to topological changes
while maintaining effective routing.  The goal is to support networks
scaling up to hundreds of routers.  If this proves successful, future
work
may include development of other protocols to support additional routing
functionality.

The working group will examine the security issues around this protocol.
They will consider the intended usage environments, and the threats that
are (or are not) meaningful within that environment.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 97 New     <draft-ietf-manet-issues-00.txt>
                Mobile Ad hoc Networking (MANET): Routing Protocol Performance
                Issues and Evaluation Considerations

 Oct 97 New     <draft-ietf-manet-term-00.txt>
                Mobile Ad Hoc Networking Terminology


MBONE Deployment (mboned)
-------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     David Meyer <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Technical Advisor(s):
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.uoregon.edu/mailing-lists/mboned*

Description of Working Group:

The MBONE Deployment Working Group will be a forum for coordinating the
deployment, engineering, and operation of multicast routing protocols
and procedures in the global Internet. This activity will include, but
not be limited to:

  - Deployment of multicast routing in the global Internet.

  - Receive regular reports on the current state of the
    deployment of mbone technology. Create "practice and
    experience" documents that capture the experience of those
    who have deployed and are deploying various MBONE
    technologies (e.g. PIM, DVMRP, CBT).

  - Based on reports and other information, provide feedback to
    IDMR.

  - Develop mechanisms and procedures to aid in the transition to
    native multicast, where appropriate.

  - Develop mechanisms and procedures for sharing operational
    information to aid in operation of the global MBONE.

  - Development of guidelines to improve the use of
    administratively scoped multicast addresses.

  - Develop mechanisms and procedures for creating and
    maintaining a MBONE topology database.

This working group will initially interact closely with IDMR. It is
believed that, once hierarchical multicast routing systems are
specified and deployed, the working groups will diverge somewhat.
Finally, note that in the below 'Goals & Milestones', the type of RFC
will be subject to discussions within the working group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jul 96 Aug 97  <draft-ietf-mboned-pruning-02.txt>
                Multicast pruning a necessity

 Nov 96 Jun 97  <draft-ietf-mboned-admin-ip-space-03.txt>
                Administratively Scoped IP Multicast

 Jan 97 Oct 97  <draft-ietf-mboned-intro-multicast-03.txt>
                Introduction to IP Multicast Routing

 Feb 97 Jun 97  <draft-ietf-mboned-imrp-some-issues-02.txt>
                Some Issues for an Inter-domain Multicast Routing Protocol

 Feb 97 New     <draft-ietf-mboned-limit-rate-guide-00.txt>
                Guidelines for Rate Limits on the MBONE

 Feb 97 New     <draft-ietf-mboned-pmbr-spec-00.txt, .ps>
                PIM Multicast Border Router (PMBR) specification for connecting
                PIM-SM domains to a DVMRP Backbone

 Mar 97 New     <draft-ietf-mboned-mdh-00.txt>
                Multicast Debugging Handbook


MIME Encapsulation of Aggregate HTML Documents (mhtml)
------------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Einar Stefferud <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe mhtml <full name>
     Archive:           ftp://segate.sunet.se/lists/mhtml/

Description of Working Group:

World Wide Web documents are most often written using Hyper Text Markup
Language (HTML). HTML is notable in that it contains "embedded
content"; that is, HTML documents often contain pointers or links to
other objects (images, external references) which are to be presented
to the recipient. Currently, these compound structured Web documents
are transported almost exclusively via the interactive HTTP protocol.
The MHTML working group has developed three Proposed Standards (RFCs
2110, 2111 and 2112) which permit the transport of such compound
structured Web documents via Internet mail in MIME multipart/related
body parts.

The Proposed Standards are intended to support interoperability between
separate HTTP-based systems and Internet mail systems, as well as being
suitable for combined mail/HTTP browser systems.

It is beyond the scope of this working group to come up with standards
for document formats other than HTML Web documents.  However, the
Proposed Standards so far produced by the working group have been
designed to allow other such formats to use similar strategies.

The MHTML WG is currently INACTIVE while first implementations are
under way.  To support implementation efforts, the WG Editor maintains
an Informational Internet-Draft
ftp://ftp.dsv.su.se/users/jpalme/draft-ietf-mhtml-info-06.txt which
provides additional useful information for implementors.  This
Informational Draft also discusses Web page formatting choices that
affect their efficient use through disconnected channels such as mail.
It will become an Informational RFC after implementation experience has
been collected.  Until then, this informational draft will be kept
current and available in the IETF Internet-Drafts library.

The MHTML Mailing List remains open for discussion of any issues that
may arise during implementation, and to collect information about
successful interoperable and interworkable implementations in
anticipation of progression to Draft-Standard Status.


From May to October, 1997, the working group will Monitor
Implementation progress and discuss issues, periodically Update Draft
of Informational Document.



The editors of this group are:

Main editor:       Jacob Palme <[e-mail]>
Associate editor: Alex Hopmann <[e-mail]>

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 96 Jul 97  <draft-ietf-mhtml-info-06.txt>
                Sending HTML in E-mail, an informational supplement to RFC ???:
                MIME E-mail Encapsulation of Aggregate HTML Documents (MHTML)

 Jul 97 Oct 97  <draft-ietf-mhtml-rev-02.txt>
                MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)

 Jul 97 New     <draft-ietf-mhtml-cid-v2-00.txt>
                Content-ID and Message-ID Uniform Resource Locators

 Sep 97 New     <draft-ietf-mhtml-rel-v2-00.txt>
                The MIME Multipart/Related Content-type


MIME - X.400 Gateway (mixer)
----------------------------

 Charter
 Last Modified: 26-Apr-96

 Current Status: Active Working Group

 Chair(s):
     Urs Eppenberger <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ietf-mixer
     Archive:           ftp://ftp.innosoft.com/ietf-mixer/

Description of Working Group:

RFC 1327 describes mappings to enable interworking between e-mail
systems using RFC 822 and e-mail systems using CCITT X.400(88). RFC 1327
is a Proposed Standard and up for review. A specially formed review
team has proposed to integrate RFC 1494, RFC 1495, outcome of the NOTARY
group (support for delivery notifications in SMTP) and align it with
X.400(92). The name of the specification is MIXER which stands for Mime
Internet X.400 Enhanced Relay.  The working group will review the MIXER
draft, refine it as needed and move the document to Proposed Standard.

The goal is to concentrate the work in a single document.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 95 Mar 97  <draft-kille-mixer-rfc1327bis-05.txt>
                MIXER (Mime Internet X.400 Enhanced Relay):  Mapping between
                X.400 and RFC 822/MIME

 Jul 95 Apr 97  <draft-ietf-mixer-bodymap-07.txt>
                Mapping between X.400 and RFC-822/MIME Message Bodies

 Nov 95 Sep 96  <draft-ietf-mixer-images-01.txt>
                X.400 image body parts

 Nov 95 Feb 97  <draft-ietf-mixer-fax-01.txt>
                A MIME body part for FAX

 Nov 95 Feb 97  <draft-ietf-mixer-oda-01.txt>
                A MIME body part for ODA

 Jan 96 Feb 97  <draft-ietf-mixer-postscript-01.txt>
                Carrying PostScript in X.400 and MIME

 Jan 97 New     <draft-ietf-mixer-mail11-00.txt>
                MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11
                mail

 Jan 97 Jul 97  <draft-ietf-mixer-rfc1664bis-01.txt>
                Using the Internet DNS to Distribute MIXER Conformant Global
                Address Mapping (MCGAM)

 Feb 97 Jul 97  <draft-ietf-mixer-directory-02.txt>
                Use of an X.500/LDAP directory to support MIXER address mapping

 Aug 97 New     <draft-ietf-mixer-subtrees-00.txt>
                Representing Tables and Subtrees in the X.500 Directory

 Aug 97 New     <draft-ietf-mixer-infotree-00.txt>
                Representing the O/R Address hierarchy in the X.500 Directory
                Information Tree


Multiparty Multimedia Session Control (mmusic)
----------------------------------------------

 Charter
 Last Modified: 03-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Ruth Lang <[e-mail]>
     Eve Schooler <[e-mail]>
     Mark Handley <[e-mail]>
     Joerg Ott <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/confctrl/confctrl.mail

Description of Working Group:

The Multiparty MUltimedia SessIon Control (MMUSIC) Working Group (WG) is
chartered to develop Internet standards track protocols to support
Internet teleconferencing sessions. MMUSIC's focus is on supporting the
loosely-controlled conferences that are pervasive on the MBone today.
However, the WG also will ensure that its protocols are general enough
to be used in managing tightly-controlled sessions.

To date, MMUSIC has drafted protocols for:

- distributing session descriptions -- Session Description Protocol
  (SDP) and Session Announcement Protocol (SAP),

- providing security for session announcements -- SAP Security,

- controlling on-demand delivery of real-time data -- Real-Time Stream
  Protocol (RTSP),

- initiating sessions and inviting users -- Session Initiation Protocol
  (SIP), and

- managing tightly-controlled sessions -- Simple Conference Control
  Protocol (SCCP).

In addition, the WG has drafted two informational documents: the first
describes the architectural framework for MMUSIC, and the second
describes interoperability scenarios for ITU- and Internet-based
teleconferencing systems.

The WG's protocols reflect coordination with other IETF efforts related
to multimedia conferencing (e.g., AVT, RSVP). In addition, the WG will
collaborate with liaisons to ITU standards bodies and industry
consortiums as appropriate to ensure interoperable standards (e.g.,
SIP/SAP/SDP with ITU H.323 and H.332).

The WG has defined two sets of goals -- immediate goals to be
accomplished over the next several months, and longer-term goals which
will be reviewed and possibly revised after the immediate goals are met.
The immediate goals include bringing several protocols to Proposed
Standard (SDP, RTSP), or Experimental RFC status (SAP), and to produce
Informational RFCs for the informational drafts listed above. The
longer-term goals are to bring the remaining protocols to Proposed
Standard status (SIP, SAP Security, SAP), to investigate the
requirements for a next-generation session description protocol, and to
continue the development of SCCP.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 95 Sep 97  <draft-ietf-mmusic-sdp-04.txt,.ps>
                SDP: Session Description Protocol

 Nov 96 Oct 97  <draft-ietf-mmusic-rtsp-05.txt,.ps>
                Real Time Streaming Protocol (RTSP)

 Dec 96 Aug 97  <draft-ietf-mmusic-sip-03.txt,.ps>
                SIP: Session Initiation Protocol

 Mar 97 Oct 97  <draft-ietf-mmusic-sap-sec-03.txt,.ps>
                Specification of Security in SAP Using Public Key Algorithms

 May 97 New     <draft-ietf-mmusic-sip-url-00.txt, .ps>
                SIP URL Scheme

 Sep 97 New     <draft-ietf-mmusic-confarch-00.txt>
                The Internet Multimedia Conferencing Architecture


IP Routing for Wireless/Mobile Hosts (mobileip)
-----------------------------------------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Erik Nordmark <[e-mail]>
     Jim Solomon <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe mobile-ip
     Archive:           ftp://ftp.smallworks.com/mobile-ip.archive

Description of Working Group:

The Mobile IP Working Group is chartered to develop or adopt
architectures and protocols to support mobility within the Internet.
In the near-term, protocols for supporting transparent host ``roaming''
among different subnetworks and different media (e.g., LANs, dial-up
links, and wireless communication channels) shall be developed and
entered into the Internet standards track.  The work is expected to
consist mainly of new and/or revised protocols at the (inter)network
layer, but may also include proposed modifications to higher-layer
protocols (e.g., transport or directory).  However, it shall be a
requirement that the proposed solutions allow mobile hosts to
interoperate with existing Internet systems.

In the longer term, the group may address, to the extent not covered by
the mobile host solutions, other types of internet mobility, such as
mobile subnets (e.g., a local network within a vehicle), or mobile
clusters of subnets (e.g., a collection of hosts, routers, and subnets
within a large vehicle, like a ship or spacecraft, or a collection of
wireless, mobile routers that provide a dynamically changing internet
topology).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 94 Aug 97  <draft-ietf-mobileip-optim-06.txt>
                Route Optimization in Mobile IP

 Jan 96 Aug 97  <draft-ietf-mobileip-ipv6-03.txt>
                Mobility Support in IPv6

 Jan 97 New     <draft-ietf-mobileip-ft-req-00.txt>
                Firewall Traversal for Mobile IP: Goals and Requirements

 Jan 97 Aug 97  <draft-ietf-mobileip-tunnel-reverse-04.txt>
                Reverse Tunneling for Mobile IP

 Mar 97 New     <draft-ietf-mobileip-firewall-trav-00.txt>
                Firewall Traversal for Mobile IP: Guidelines for Firewalls and
                Mobile IP entities


Multicast Extensions to OSPF (mospf)
------------------------------------

 Charter
 Last Modified: 11-Jan-96

 Current Status: Active Working Group

 Chair(s):
     John Moy <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This working group will extend the OSPF routing protocol so that it
will be able to efficiently route IP multicast packets. This will
produce a new (multicast) version of the OSPF protocol, which will be
as compatible as possible with the present version (packet formats and
most of the algorithms will hopefully remain unaltered).

 Internet-Drafts:

  No Current Internet-Drafts.


Multiprotocol Label Switching (mpls)
------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     George Swallow <[e-mail]>
     Vijay Srinivasan <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       in body: subscribe (unsubscribe)
     Archive:           ftp://ftpeng.cisco.com/mpls/mpls

Description of Working Group:

Problem Statement:

Recently the use of label-swapping based forwarding ("label switching")
in conjunction with network layer routing has attracted much attention.
Several vendors have proposed techniques based on this paradigm. Among
the problems this paradigm is expected to address are the following:

1.  Scalability of network layer routing

    Using labels as a means to aggregate forwarding information, while
    working in the presence of routing hierarchies.

2.  Greater flexibility in delivering routing services

    Using labels to identify particular traffic which are to receive
    special services, e.g. QoS.

    Using labels to provide forwarding along an explicit path different
    from the one constructed by destination-based forwarding.

3.  Increased performance

    Using the label-swapping paradigm to optimize network performance.

4.  Simplify integration of routers with cell switching based
    technologies

    a) making cell switches behave as peers to routers (thus reducing
       the number of routing peers that a  router has to maintain),

    b) by making information about physical topology available to
       Network Layer routing procedures, and

    c) by employing common addressing, routing, and management
       procedures.

High Level Requirements

1.  The solution should be general with respect to data link
    technologies. Specific optimizations for particular media will be
    considered.

2.  The solution must be compatible with existing internetwork
    technologies and routing protocols.

3.  The solution should be capable of operating independently of the
    underlying routing protocol.  It has been observed that
    considerable optimizations can be achieved in some cases by small
    enhancements of existing protocols.  Such enhancements will be
    considered in the case of IETF standard routing protocols, and if
    appropriate, coordinated with the relevant working group.

4.  The solution should support a wide range of forwarding
    granularities associated with a given label, from a single
    application flow to a group of topologically related destinations.

5.  The solution should support operations, administration, and
    maintenance facilities at least as extensive as those supported in
    IP networks.

6.  Routing protocols that could be used in conjuction with MPLS
    could be based on distributed computation. As such, during routing
    transients these protocols may construct forwarding paths that
    contain loops. The protocols defined by MPLS must provide protocol
    mechanism(s) to either prevent the formation of loops and/or
    contain the amount of (networking) resources that could be consumed
    due to the presence of such loops.

7.  The standard must clearly state how the protocol operates in a
    hierarchical network.

8.  Scalability issues will be considered and analyzed.  Very scalable
    solutions will be sought.  For example, in the case of ATM
    technologies, the solution will attempt to conserve VC usage.

Charter Statement:

Currently, none of the solutions that that employ label-swapping based
forwarding ("label switching") in conjunction with network layer
routing are based on standard technology. In order to be able to
achieve the benefits of this new technology, a standard solution is
necessary.

The working group is responsible for standardizing a base technology
for using label swapping forwarding paradigm (label switching) in
conjunction with network layer routing and for the implementation of
that technology over various link level technologies, which may include
Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as
Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and protocols for the distribution of labels
between routers, encapsulations, multicast considerations, use of
labels to support higher layer resource reservation and QoS mechanisms,
and definition of host behaviors.


Objectives:

1.  Specify standard protocol(s) for maintenance and distribution of
label
    binding information to support unicast destination-based routing
with
    forwarding based on label-swapping.

2.  Specify standard protocol(s) for maintenance and distribution of
label
    binding information to support multicast routing with
    forwarding based on label-swapping.

3.  Specify standard protocol(s) for maintenance and distribution of
label
    binding information to support hierarchy of routing knowledge (e.g.,
    complete segregation of intra and inter-domain routing) with
forwarding
    based on label-swapping.

4.  Specify standard protocol(s) for maintenance and distribution of
label
    binding information to support explicit paths different from the one
    constructed by destination-based forwarding with forwarding based on
    label-swapping.

5.  Specify standard procedures of carrying label information over
various
    link level technologies.

6.  Specify a standard way to use the ATM user plane

    a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.)
       ATM control plane and/or standard ATM hardware
    b) Specify a 'label swapping' control plane
    c) Take advantage of possible mods/improvements in ATM
       hardware, for example the ability to merge VCs

7.  Discuss support for QOS (e.g. RSVP).

8.  Define standard protocol(s) to allow direct host (e.g. server)
    participation.

Coordination:

The working group will coordinate its activities with other working
groups as appropriate.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 97 Aug 97  <draft-ietf-mpls-framework-01.txt>
                A Framework for Multiprotocol Label Switching

 Aug 97 New     <draft-ietf-mpls-arch-00.txt>
                A Proposed Architecture for MPLS


Next Generation Transition (ngtrans)
------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Bob Fink <[e-mail]>
     Robert Gilligan <[e-mail]>
     Tony Hain <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     Michael O'Dell  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       include
     Archive:           ftp://playground.sun.com/pub/ngtrans

Description of Working Group:

The purpose of this group is to design the mechanisms and procedures to
support the transition of the Internet from IPv4 to IPv6.

The work of the group will fall into three areas:

 1. Define the processes by which the Internet will be transitioned
    from IPv4 to IPv6.  As part of this effort, the group will produce
    a document explaining to the general Internet community what
    mechanisms will be employed in the transition, how the transition
    will work, the assumptions about infrastructure deployment inherent
    in the operation of these mechanisms, and the types of
    functionality that applications developers will be able to assume
    as the protocol mix changes over time.

 2. Define and specify the mandatory and optional mechanisms that
    vendors are to implement in hosts, routers, and other components of
    the Internet in order for the transition to be carried out. Dual
    protocol stack, encapsulation and header translation mechanisms
    must all be defined, as well as the interaction between hosts using
    different combinations of these mechanisms. The specifications
    produced will be used by people implementing these IPv6 systems.

 3. Articulate a concrete operational plan for transitioning the
    Internet from IPv4 to IPv6.  The result of this work will be a
    transition plan for the Internet that network operators and
    Internet subscribers can execute.

The group will use the Simple SIPP Transition (SST) overview
document, draft-ietf-sipp-sst-overview-00.txt, as the starting point for
its work on the IPv6 transition.

The group will work closely with the main IPng Working Group (IPNGWG)
and the
IPng Address Configuration Working Group (ADDRCONF). The group will
co-ordinate with the TACIT group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Jun 97  <draft-ietf-ngtrans-6bone-registry-01.txt>
                A proposal for an IPv6 site database object

 Jul 97 New     <draft-ietf-ngtrans-header-trans-00.txt>
                Site prefixes in Neighbor Discovery


New Internet Routing and Addressing Architecture (nimrod)
---------------------------------------------------------

 Charter
 Last Modified: 23-Aug-95

 Current Status: Active Working Group

 Chair(s):
     J. Noel Chiappa <[e-mail]>
     Isidro Castineyra <[e-mail]>
     David Bridgham <dab=[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://bbn.com/pub/nimrod-wg/nimrod-wg.archive

Description of Working Group:

The goal of the working group is to design, specify, implement and test a
flexible new routing and addressing architecture suitable for very large
scale internets.  The basic architecture for computation of routes will
be based on distribution of network topology maps, with source-specified
route selection, and unitary (i.e., not hop-by-hop) computation of routes.

The architecture will provide a single homogeneous framework for all
routing, including both inter-domain and intra-domain.  It will include a
new network component naming abstraction hierarchy, starting from network
attachment points, and based on actual connectivity, but taking into
consideration policy requirements.  These new names will be variable
length, with a variable number of levels of abstraction; they will not
appear in most packets, though.

Actual packet forwarding will be based both on retained non-critical
state in the switches (via flow setup for long-lived communications), and
both classical address-only, as well as source-route type instructions, in
individual packets (for datagram applications which send only one, or a very
few, packets).

Although the general design and algorithms will be usable in any
internetworking protocol family, the initial detailed protocol
specifications and implementation are currently planned for deployment
with IPv4, but support for another packet format may be substituted or
added, depending on the situation in the Internet in the future.
Interoperabilty with existing unmodified IPv4 hosts will be achieved by
re-interpreting the existing source and destination fields in IPv4
packets as endpoint identifiers.

A substantial effort to take into account support for mobility,
multicast and resource allocation will be made when designing the Nimrod
architecture; provided that so doing is neither impossible because of
incomplete work outside the scope of Nimrod, nor the cause of very
substantial delays in the first iteration of the protocol design.


 Internet-Drafts:

  No Current Internet-Drafts.


NNTP Extensions (nntpext)
-------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Ned Freed <[e-mail]>
     Stan Barber <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www.academ.com/academ/nntp/ietf

Description of Working Group:

Network News Transfer Protocol (NNTP), defined in RFC 977, was released
to the world in March 1986. It was designed to do two things for the
"netnews" computer conferencing system:

1. Provide access to the netnews article database on a network server
   for "reader" client programs.

   The situation everyone wanted was access to netnews throughout a
   network, without having to actually run the netnews server software
   and keep a local copy of the article database (a sizeable resource
   commitment, even then).

2. Provide the means for interactive server to server article transfer
   over the Internet.

   The netnews system uses a "flood broadcast" mechanism to distribute
   articles to all sites, which as a consequence of its operation,
   creates many duplicate copies of any given article. These duplicates
   account for the netnews system's high reliability and speed in
   distributing articles, but they must be each eliminated at the
   receiving site, to avoid infinite replication.

Originally, netnews was developed by the UUCP Network community, and
used "batched" file transfer over modems and telephone lines to
transmit articles from site to site. This mechanism did not allow for
interrogating the remote system's database to see if the articles to
betransmitted were already at the destination (a common case). NNTP's
principal server to server article transfer mechanism allows for this
interrogation of the receiver, and thus saves both network bandwidth
and processing time on the remote.

Unfortunately, NNTP's original design had limitations which have become
apparent over the decade since its release. For example, NNTP's server
to server article transfer performance over the wide area Internet
suffers because there are at least two protocol round-trips per article
transfer, which does not allow two NNTP servers to continuously stream
the articles that must be transferred between them, and thereby make
full use of the available bandwidth (moderated by TCP's congestion
control mechanisms).

Also, a number of extensions to the protocol are now in common use (and
yet more have been proposed), but most such extensions are only
documented in the source code that implements them, or in associated
release notes - not in the NNTP standard. Such extensions would benefit
from IETF community review, and proper specification. Where there is
widespread interest in a particular kind of extension, the internet
user community would benefit from consensus among implementors prior to
deployment, as to the particulars of that extension.

The IETF NNTP extensions Working Group shall:

1. Revise and publish a standards-track successor to RFC 977 that
   removes ambiguities from the original document, defines a mechanism
   for adding extensions to the protocol, and provides a mechanism for
   the server to inform the client of the extensions which it
   supports.

2. Include in the same document some reasonable group of existing
   commonly used extensions forming a new base functionality for NNTP.

3. Upon completion of the RFC977 successor document, and presuming that
   proposals for extensions to the NNTP protocol have been submitted
   for consideration by IESG, the working group may be asked by the
   IESG Applications Area Directors to review one or more extensions
   for NNTP.

   Part of the purpose of such a review will be to test the newly
   established mechanism for adding protocol extensions.

The first concern of this working group shall be for the
interoperability of the various NNTP implementations, and therefore for
clear and explicit specification of the protocol. It is very important
that we document the existing situation before taking up any new work.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 97 Sep 97  <draft-ietf-nntpext-base-02.txt>
                Network News Transport Protocol

 Oct 97 New     <draft-ietf-nntpext-imp-00.txt>
                Common NNTP Extensions


ONC Remote Procedure Call (oncrpc)
----------------------------------

 Charter
 Last Modified: 13-May-97

 Current Status: Active Working Group

 Chair(s):
     Theodore Ts'o <[e-mail]>
     Steve Nahm <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://playground.sun.com/pub/oncrpc

Description of Working Group:

The Open Network Computing Remote Procedure Call Working Group was
originally formed to update the RFCs that describe ONC RPC to reflect
the current state of the deployed and accepted technology, and submit
them for Internet standardization.  RFCs have been submitted for the
three core ONC technologies: RPC (RFC1831), RPC Binding (RFC 1833)
and XDR (RFC1832).

During this work, IESG identified the area of security as requiring
improvement prior to standardizing the core RPC technologies (RPC and
RPC Binding).  Therefore, the Working Group shall develop and define
a security mechanism for ONC RPC which shall, at the minimum, allow
for strong authentication of client and server principals.  The core
RPC technologies will be unblocked from the standards track once
such a mechanism is approved as a Proposed Standard, provided
that its design does not require changes to the core RPC technologies.

The basis for the work will be the RPCSEC_GSS Protocol Specification,
draft-ietf-oncrpc-rpcsec_gss.00.txt.

The document editor will be Michael Eisler.

Background:

ONC RPC is a Remote Procedure Call technology that originated in Sun
Microsystems in the early 1980s. ONC RPC was modelled on Xerox's
Courier RPC protocols. It has been widely deployed on platforms from
most major workstation vendors. It has been implemented on MS-DOS,
Microsoft Windows, Microsoft Windows NT, Mac, VMS, MVS, and
practically all flavors of UNIX, among others. Sun Microsystems has
delegated change control for the ONC RPC protocols for the purposes
of making an Internet Standard to the IETF (see RFC 1790).

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 94 Oct 97  <draft-ietf-oncrpc-auth-04.txt>
                Authentication Mechanisms for ONC RPC

 Jun 96 Apr 97  <draft-ietf-oncrpc-remote-03.txt>
                RPC: Remote Procedure Call Protocol Specification Version 2


An Open Specification for Pretty Good Privacy (openpgp)
-------------------------------------------------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Noerenberg <[e-mail]>
     Charles Breed <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       Only the word subscribe
     Archive:           http://www.imc.org/ietf-open-pgp/mail-archive/

Description of Working Group:

PGP, or Pretty Good Privacy, first appeared on the Internet in 1991.
It has enjoyed significant popularity amongst the Internet Community.

PGP is used both for protecting E-mail and File Storage. It presents
a way to digitally sign and encrypt information "objects." As such
it is well suited for any store and forward application.

The goal of the OpenPGP working group is to provide IETF standards for
the algorithms and formats of PGP processed objects as well as providing
the MIME framework for exchanging them via e-mail or other transport
protocols.

Because there is a significant installed base of PGP users, the
working group will consider compatibilty issues to avoid
disenfranchising the existing community of PGP users.

Security Issues:

The whole purpose of Open-PGP is to provide security services.

 Internet-Drafts:

  No Current Internet-Drafts.


Open Shortest Path First IGP (ospf)
-----------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Moy <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://gated.cornell.edu/pub/lists/ospf

Description of Working Group:

The OSPF Working Group will develop and field-test an SPF-based
Internal Gateway Protocol.  The specification will be published and
written in such a way so as to encourage multiple vendor
implementations.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 95 Mar 97  <draft-ietf-ospf-ospfv6-04.txt>
                OSPF for IPv6

 Dec 95 May 97  <draft-ietf-ospf-opaque-01.txt>
                The OSPF Opaque LSA Option

 Nov 96 May 97  <draft-ietf-ospf-stdreport-02.txt>
                OSPF Standardization Report

 Mar 97 Jun 97  <draft-ietf-ospf-nssa-update-02.txt>
                The OSPF NSSA Option

 Aug 97 New     <draft-ietf-ospf-ara-00.txt>
                The OSPF Address Resolution Advertisement Option

 Oct 97 New     <draft-ietf-ospf-doi-00.txt>
                OSPFv2 Domain Of Interpretation (DOI) for ISAKMP

 Oct 97 New     <draft-ietf-ospf-atm-00.txt>
                SPF over ATM and Proxy PAR


One Time Password Authentication (otp)
--------------------------------------

 Charter
 Last Modified: 08-Jun-95

 Current Status: Active Working Group

 Chair(s):
     Neil Haller <[e-mail]>
     Ran Atkinson <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.bellcore.com/pub/ietf-otp/archive

Description of Working Group:

One form of attack on computing systems connected to the Internet is
eavesdropping on network connections to obtain login id's and passwords
of legitimate users [RFC 1704]. Bellcore's S/KEY(TM) one-time password
system was designed to counter this type of attack, called a replay
attack [RFC 1760]. Several one-time password implementations compatible
with Bellcore's S/KEY (TM) system exist. These implementations are
increasingly widely deployed in the Internet to protect against passive
attacks.

The object of this working group is to write a standards track RFC for
one-time password technology, using the technology in the Bellcore
S/KEY system and related interoperable packages (e.g., logdaemon, NRL
OPIE) as the basis for the group's effort. The standards-track RFC will
enhance multi-vendor interoperability in one-time password
authentication technologies and thereby help reduce security risks in
the Internet.

General authentication servers are outside the scope of this working
group. The ``S/Key-0'' system being considered for use in Kerberos is
outside the scope of this working group.

The standards-track specification will describe how this one-time
password technology can be used with at least the MD4, MD5, and SHA
algorithms. The standard one-time password dictionary from RFC 1760
will be reused in order to maintain backwards compatibility with the
various deployed systems, however, support for hexadecimal format
passwords will also be mandatory to implement. The standard might
specify passphrase quality checks for the secret passphrase. The
standard will be specified so as to eliminate any possible conflict
with the Bellcore trademark on the term ``S/Key.''

An Informational RFC might also be issued that describes conventions
for the UNIX commands relating to one-time passwords, including
command(s) to securely update a remote one-time password.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Sep 96 Sep 97  <draft-ietf-otp-ext-04.txt>
                OTP Extended Responses

 Nov 96 Jan 97  <draft-ietf-otp-ver-01.txt>
                OTP Verification Examples

 Jan 97 Sep 97  <draft-ietf-otp-02.txt>
                A One-Time Password System


Procedures for Internet/Enterprise Renumbering (pier)
-----------------------------------------------------

 Charter
 Last Modified: 03-Jan-96

 Current Status: Active Working Group

 Chair(s):
     Roger Fajman <[e-mail]>
     Bill Manning <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/pier-archive

Description of Working Group:

PIER will fill the niche between the ADDRCONF, CIDRD, DHCP, SERV-LOC,
and other working groups as needed in identifying processes and
procedures, tools and techniques for renumbering in both the IPv4 and
IPv6 environments.  Since IPv6 is still in development, the main focus
will be IPv4 environments.  Emphasis will be placed on identifying the
places where hardcoded IP addresses are used and documenting those
places. If there are viable alternatives to hardcoded IP addresses, the
working group will document those as well. The end results of these
investigations will be a series of documents on renumbering issues and
recommendations on what actions might be taken to address those issues
where there is no currently viable alternative. These recommendations
will be to other working groups and/or areas regarding possible
improvements to protocols that would aid in renumbering. The PIER
working group will not develop such protocols itself.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 New     <draft-ietf-pier-applications-00.txt>
                IP Addresses in Applications


PSTN and Internet Internetworking (pint)
----------------------------------------

 Charter
 Last Modified: 28-Aug-97

 Current Status: Active Working Group

 Chair(s):
     Steve Bellovin <[e-mail]>
     Igor Faynberg <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe  your-email-addres
     Archive:           http://www.bell-labs.com/mailing-lists/pint/

Description of Working Group:

The PSTN/Internet Interfaces (PINT) WG addresses connection
arrangements through which Internet applications can request and enrich
PSTN (Public Switched Telephone Network) telephony services.  An
example of such services is a Web-based Yellow Pages service with the
ability to initiate PSTN calls between customers and suppliers.

This working group has six main objectives:

* Study architecture and protocols needed to support services in which a
  user of the Internet requests initiation of a telephone (i.e., PSTN-
  carried) call to a PSTN terminal (i.e., telephone, FAX machine).
  The protocols are not to support any form of third-party call control
or,
  for that matter, any type of call control; their role is rather to
  securely carry call requests to the PSTN. Specific services to be
  considered initially are Click-to-Dial, Click-to-Fax,
Click-to-Fax-Back,
  and Web access to voice content delivered over the PSTN.

* Produce an informational RFC that describes current practices for
  supporting the services in question.

* Based on the existing practice and agreed on improvements, develop a
  standards track RFC that specifies a Service Support Transfer Protocol
  (SSTP) between Internet applications or servers and PSTN Intelligent
  Network Service Nodes (or any other node that implement the Service
  Control Function).  SSTP is an application-specific transport protocol
  operating over TCP.

* Consider security issues relating to prividing functions of this
  type. In particular understand any threats posed by this technology
  and resolve them, and any other security issues in the proposed
standard.

* Based on the existing practice and agreed on improvements, develop a
  standards track RFC for a relevant MIB (SSTP MIB) to support the
service
  management protocol between Internet applications and the PSTN Service
  Management System. The SSTP MIB is to conform to SNMP standards.

* Consider extensions of the above architecture and protocols to support
a
  wider range of PSTN Intelligent Network (IN) based services.

 Internet-Drafts:

  No Current Internet-Drafts.


Public-Key Infrastructure (X.509) (pkix)
----------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Stephen Kent <[e-mail]>
     Warwick Ford <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe <email address> ietf-pkix
     Archive:           ftp://ftp.tandem.com/ietf/mailing-lists/current

Description of Working Group:

Many Internet protocols and applications which use the Internet employ
public-key technology for security purposes and require a public-key
infrastructure (PKI) to securely manage public keys for
widely-distributed users or systems.  The X.509 standard constitutes a
widely-accepted basis for such an infrastructure, defining data formats
and procedures related to distribution of public keys via certificates
digitally signed by certification authorities (CAs).  RFC 1422
specified the basis of an X.509-based PKI, targeted primarily at
satisfying the needs of Internet Privacy Enhanced Mail (PEM).  Since
RFC 1422 was issued, application requirements for an Internet PKI have
broadened tremendously, and the capabilities of X.509 have advanced
with the development of standards defining the X.509 version 3
certificate and version 2 certificate revocation list (CRL).

The task of the working group will be to develop Internet standards
needed to support an X.509-based PKI.  The goal of this PKI will be to
facilitate the use of X.509 certificates in multiple applications which
make use of the Internet and to promote interoperability between
different implementations choosing to make use of X.509 certificates.
The resulting PKI is intended to provide a framework which will support
a range of trust/hierarchy environments and a range of usage
environments (RFC1422 is an example of one such model).

Candidate applications to be served by this PKI include, but are not
limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec
protocols, Internet payment protocols, and www protocols.  This project
will not preclude use of non-infrastructural public-key distribution
techniques nor of non-X.509 PKIs by such applications.  Efforts will be
made to coordinate with the IETF White Pages (X.500/WHOIS++) project.

The group will focus on tailoring and profiling the features available
in the v3 X.509 certificate to best match the requirements and
characteristics of the Internet environment.
Other topics to be addressed potentially include:

 o Alternatives for CA-to-CA certification links and structures,
   including guidelines for constraints

 o Revocation alternatives, including profiling of X.509 v2 CRL
   extensions

 o Certificate and CRL distribution options (X.500-based,
   non-X.500-based)

 o Guidelines for policy definition and registration

 o Administrative protocols and procedures, including certificate
   generation, revocation notification, cross-certification, and
   key-pair updating

 o Naming and name forms (how entities are identified, e.g., email
   address, URN, DN, misc.)

 o Generation of client key pairs by the PKI

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 96 Oct 97  <draft-ietf-pkix-ipki-part1-06.txt>
                Internet Public Key Infrastructure   X.509 Certificate and CRL
                Profile

 Jun 96 Oct 97  <draft-ietf-pkix-ipki3cmp-05.txt>
                Internet Public Key Infrastructure     Certificate Management
                Protocols

 Mar 97 Oct 97  <draft-ietf-pkix-ipki2opp-04.txt>
                Internet Public Key Infrastructure  Operational Protocols -
                LDAPv2

 Mar 97 Oct 97  <draft-ietf-pkix-ipki-part4-02.txt>
                Internet Public Key Infrastructure Certificate Policy and
                Certification Practices Framework

 Jul 97 New     <draft-ietf-pkix-ipki6np-00.txt>
                Internet Public Key Infrastructure

 Jul 97 New     <draft-ietf-pkix-ipki5tsp-00.txt>
                Internet Public Key Infrastructure Part V:  Time Stamp
                Protocols

 Aug 97 Oct 97  <draft-ietf-pkix-ipki-kea-01.txt>
                Internet Public Key Infrastructure   Representation of Key
                Exchange Algorithm (KEA) Keys in Internet Public Key
                Infrastructure Certificates

 Sep 97 Oct 97  <draft-ietf-pkix-opp-ftp-http-01.txt>
                Internet Public Key Infrastructure Operational Protocols:  FTP
                and HTTP

 Oct 97 New     <draft-ietf-pkix-ocsp-00.txt>
                Internet Public Key Infrastructure Online Certificate Status
                Protocol - OCSP


PacketWay (pktway)
------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Danny Cohen <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Thomas Narten  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      http://WWW.ERC.MsState.Edu/packetway/mail-list.html
         In Body:       use above URL to subscribe/unsubscribe
     Archive:           ftp://ftp.isi.edu/pktway/pktway.mail

Description of Working Group:

Due to dramatic increases in circuits speed the traditional system
buses are limited in length (e.g., PCI is limited to 8") and cannot
provide the traditional system-wide support. Therefore, the system-wide
connectivity is provided by a high performance networks operating in
very close quarters, having the generic name System Area Networks
(SANs).

Many vendors today use such SANs inside computer platforms to connect
processors to IO devices, processors to memory, and processors to
processors. Most existing SANs are proprietary, and don't interoperate
with each other, not unsimilar to the early stages of LAN development.

In order to be able to interconnect Massively Parallel Processing
systems (MPPs) and to interconnect workstations into MPP-like clusters
there is a need to unify the SANs and to provide means for
interoperability among them.

PktWay is designed to provide a uniform interface for a wide variety of
SANs, such that the higher levels (such as IP) would be able to use
SANs in a uniform manner. An IP driver for PktWay would be able to use
PktWay between heterogeneous processors as if they were all on a single
SAN.

PktWay would be designed to provide interoperability among closely
located heterogeneous processors at high speed. Pktway will sacrifice
scalability and some generality for high performance. Hence, PktWay
will supplement IP for high performance and for fine granularity of
processors.

802.1, the link level control protocol is above LANs, such as the
various Ethernets, FDDI, and Token Ring, at Level-2, and below IP, at
Level-3.

Similarly, PktWay will be above the various SANs (such as RACEway and
Paragon) and below IP.

PktWay will define separately:

        * End-to-End protocol (and packet format)

        * Router-to-Router protocol (and packet format)

        * Resource discovery and allocation


The members of the PktWay Working Group will design, specify, document,
propose, implement, and evaluate the above three protocols that define
the PktWay operation.

The members of the working group will also produce reference software
for PktWay.

Based on initial reactions it is expected that the working group will
include members from academia, government, and industry, covering the
software, hardware, and communication aspects of PktWay.

INTELLECTUAL PROPERTY

All the work that has been performed until now on PktWay is in the
public domain. The PktWay Working Group will only handle public domain
information. All the members of the PktWay Working Group will be
notified that the working group cannot guard any trade secrets, nor
limit the distribution of any proprietary information presented to it.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 95 Oct 97  <draft-ietf-pktway-protocol-eep-spec-02.txt>
                The End-to-End (EEP) PacketWay Protocol for High-Performance
                Interconnection of Computer Clusters

 Oct 97 New     <draft-ietf-pktway-protocol-rrp1-spec-00.txt>
                Part-1 of The Router-to-Router (RRP) PacketWay Protocol for
                High-Performance Interconnection of Computer Clusters


Process for Organization of Internet StandardS ONg (poisson)
------------------------------------------------------------

 Charter
 Last Modified: 24-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Erik Huizer <[e-mail]>

 General Area Director(s):
     Fred Baker  <[e-mail]>

 General Area Advisor:
     Fred Baker  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.tis.com/pub/lists/poised/poised.yymm

Description of Working Group:

The POISED working group in 1993-1994 established the basis of the IETF
process in its current form. Poised95 established a base set of
documents to describe the essentials of the IETF process. POISSON will
concern itself with extending the set of RFC documents that describe
the IETF process.

The name POISSON:

The tricky part of describing the IETF process, certainly in the fast
changing world of the Internet, is that when you describe the process
in too much detail, the IETF loses its flexibility, when you describe
to little it becomes unmanageable. This is therefore a slippery
subject, hence the name POISSON, which is French for fish. The French
word also serves to indicate the international aspect of the WG.

Furthermore the IETF operates by concensus, which sometimes seems to
have a POISSON distribution.

The POISSON WG will work on the following items:

- WG and Area procedures; This is to become a BCP document that
  describes the procedures that the IETF has for WG formation and
  operation, and for Area Directors. This is an essential formalisation
  and update of RFC1603. The document should additionally include
  issues like:

    -       WG editor definition

    -       WG chair (de)selection

    -       WG ethics

  Proposed editors: Scott Bradner and Erik Huizer

- Standards process; The standards process document as produced by
  Poised95 is not yet complete. The document needs to be updated with
  specific regard to the standards document structure categorization
  and publication.

  Proposed editor: Scott Bradner

- Nomcom procedures; The Nomcom procedures document as produced by
  Poised95 may need updating as a result of nomcom experience early
  1997. If this is the case, the POISSON WG will take it upon itself to
  update the document. If not the POISSON WG will not work on this.

  Proposed editor: Jim Galvin

- Code of conduct; based on the Internet-draft:
  draft-odell-code-of-conduct-00.txt the POISSON WG will produce a code
  of conduct for the IETF.

  Proposed editor: Mike O'Dell

Furthermore, the POISSON WG will review documents that are related to
the IETF standards process (but that will not be produced by the
POISSON WG itself) when available. Such documents may include:

- IETF Charter; This needs to be written by the IETF chair. It is
  essentially a short mission statement like document that contains
  references to other Poised documents for further details.

- IESG Charter; This document will be written by the IESG.

- IAB Charter; The IAB needs to revise its charter (RFC1601).

- ISOC Bylaws and Articles of Incorporation; These need to be published
  as  RFC(s).

- The IRTF charter.


POISSON will meet in San Jose and Memphis to try and gauge a rough
consensus on these issues and develop guidelines and drafts for the
appropriate documents.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Sep 97  <draft-ietf-poisson-wg-guide-01.txt>
                IETF Working Group Guidelines and Procedures

 Jul 97 Aug 97  <draft-ietf-poisson-nomcom-02.txt>
                IAB and IESG Selection, Confirmation, and Recall Process:
                Operation of the Nominating and Recall Committees


Point-to-Point Protocol Extensions (pppext)
-------------------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Karl Fox <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://merit.edu/pub/ietf-ppp-archive

Description of Working Group:

The Point-to-Point Protocol (PPP) was designed to encapsulate multiple
protocols.  IP was the only network layer protocol defined in the
original documents.  The working group is defining the use of other
network layer protocols and options for PPP. The group will define the
use of protocols including: bridging, ISO, DECNET (Phase IV and V),
XNS, and others.  In addition, it will define new PPP options for the
existing protocol definitions, such as stronger authentication and
encryption methods.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 93 New     <draft-ietf-pppext-hpppc-00.txt>
                PPP Hewlett-Packard Packet-by-Packet Compression (HP PPC)
                Protocol

 Feb 95 Mar 97  <draft-ietf-pppext-ipcp-network-01.txt>
                The PPP Internet Protocol Control Protocol (IPCP)

 Mar 95 Jul 96  <draft-ietf-pppext-eap-auth-02.txt>
                PPP Extensible Authentication Protocol (EAP)

 Nov 95 Feb 97  <draft-ietf-pppext-eaprsa-04.txt>
                PPP EAP RSA Public Key Authentication Protocol

 Feb 96 Jul 97  <draft-ietf-pppext-lcpext-ds-02.txt>
                PPP LCP Extensions

 Jun 96 Jul 97  <draft-ietf-pppext-pptp-02.txt>
                Point-to-Point Tunneling Protocol--PPTP

 Sep 96 Oct 97  <draft-ietf-pppext-l2tp-07.txt>
                Layer Two Tunneling Protocol 'L2TP'

 Feb 97 Jul 97  <draft-ietf-pppext-ipcp-mip-02.txt>
                Mobile-IPv4 Configuration Option for PPP IPCP

 Mar 97 New     <draft-ietf-pppext-scm-00.txt>
                Semi Connected Mode for PPP links

 Mar 97 New     <draft-ietf-pppext-nles-00.txt>
                Proposal for a PPP Network Layer Entity Selection Protocol

 Mar 97 Sep 97  <draft-ietf-pppext-aal5-02.txt>
                PPP over AAL5

 Mar 97 New     <draft-ietf-pppext-l2tp-aal5-funi-00.txt>
                Layer Two Tunneling Protocol (L2TP) over AAL5 and FUNI

 Mar 97 Jul 97  <draft-ietf-pppext-callback-ds-01.txt>
                PPP LCP CallBack

 Jun 97 Oct 97  <draft-ietf-pppext-l2tp-sec-02.txt>
                Layer Two Tunneling Protocol 'L2TP' Security Extensions for
                Non-IP networks

 Jul 97 New     <draft-ietf-pppext-des-encrypt-v2-00.txt>
                The PPP DES Encryption Protocol, Version 2 (DESE-bis)

 Jul 97 New     <draft-ietf-pppext-3des-encrypt-00.txt>
                The PPP Triple-DES Encryption Protocol (3DESE)

 Jul 97 Sep 97  <draft-ietf-pppext-funi-02.txt>
                PPP Over FUNI

 Jul 97 New     <draft-ietf-pppext-padding-ds-00.txt>
                PPP LCP Self Describing Padding

 Oct 97 New     <draft-ietf-pppext-l2tp-mib-00.txt>
                Layer Two Tunneling Protocol 'L2TP' Management Information Base

 Oct 97 Oct 97  <draft-ietf-pppext-eaptls-02.txt>
                PPP EAP TLS Authentication Protocol

 Oct 97 New     <draft-ietf-pppext-pppsonet-scrambler-00.txt>
                PPP over SONET/SDH


Printer MIB (printmib)
----------------------

 Charter
 Last Modified: 21-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Chris Wellens <[e-mail]>
     Llyod Young <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       In body: subscribe pmp
     Archive:           http://www.pwg.org/hypermail/pmp/

Description of Working Group:

The Printer MIB Working Group is chartered to develop a set of managed
objects for networked printers. These objects will be the minimum
necessary to provide the ability to monitor and control these systems,
providing fault, configuration and performance management, and will be
consistent with the SNMP framework and existing SNMP standards.

At its discretion, the working group may also define a small number of
unsolicited notifications (traps) which carry these managed objects.
However, the working group recognizes that traps are used sparingly in
the SNMP framework.

The working group recognizes that the area of networked printers is
quite diverse. However, the working group is specifically confined to
defining managed objects that instrument critical information about:

- printer engine

- interpreters

- media

- input sources

- output destinations

- I/O interfaces

Further, the working group is specifically prohibited from defining
managed objects that define instrumentation about:

- other marking technologies (e.g., those that mark onto film)

- fonts

- spooling

- print job management

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Oct 97  <draft-ietf-printmib-mib-info-03.txt>
                Printer MIB

 Apr 97 Sep 97  <draft-ietf-printmib-job-monitor-06.txt>
                Job Monitoring MIB - V0.85


Physical Topology MIB (ptopomib)
--------------------------------

 Charter
 Last Modified: 11-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Ken Jones <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp ftp.3com.com (login: ptopo, passwd: ptopo)

Description of Working Group:

Document Editor: Gilbert Ho ([e-mail])


The goals of this working group are:

   o to agree on and document the common framework/model for
     discussing physical topology
   o to standardize a set of managed objects that provide physical
     topology information
   o to document media specific mechanisms to communicate topology
     information.

The managed objects should provide sufficient information to allow a
management workstation to navigate across a set of agents in order to
learn the topology of arbitrarily large networks, and these objects
should be as independent as possible from the specific underlying
networking media which comprise the network. These objects will be the
minimum necessary to provide the ability to support the physical
topology discovery, and will be consistent with the SNMP framework and
existing SNMP standards.

In defining these objects, it is anticipated that the working group
will leverage existing work for representing port-based information,
such as in the Repeater MIB (RFC 1516 or later) and may also leverage
work in the entity MIB for describing logical and physical
relationships.

The working group will define the general requirements for topology
mechanisms in order to support the proposed MIB.  It will also identify
existing topology mechanisms for common LAN media types and may propose
new topology mechanisms for LAN media types where required.  It is a
goal of the common topology MIB to allow the use of either standard or
proprietary topology mechanisms within the underlying media.

At this time, it is not a goal of the working group to support the
collection or representation of logical topology information, such as
VLAN configuration or subnet structure.  It is anticipated that this
could be an area for future work items, so some consideration will be
given to extensibility of the models and to the MIB.  However, this
consideration must not be allowed to impede progress on the primary
focus of physical connectivity.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 97 Sep 97  <draft-ietf-ptopomib-mib-01.txt>
                Physical Topology MIB

 Aug 97 Sep 97  <draft-ietf-ptopomib-pdp-01.txt>
                Physical Topology Discovery Protocol and MIB


QoS Routing (qosr)
------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Hal Sandick <[e-mail]>
     Eric Crawley <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This working group is chartered to define a framework and techniques
for Quality of Service (QoS) Routing in the Internet. QoS Routing
allows the network to determine a path that supports the QoS needs of
one or more flows in the network. The path chosen may not be the
"traditional shortest path" that is typically computed based on current
metrics and policies. The group's work will focus on how to select and
maintain packet forwarding paths capable of meeting specific service
class objectives. In particular, the techniques will specify what
extensions and adaptations to routing and QoS setup protocols are
required to support QoS routing and new packet handling techniques that
may be needed to avoid packet loops for QoS flows. While it is not
intended, this may also spawn the development of new routing protocols
that can specifically address QoS routing. The WG will identify topics
and issues in QOS routing which require additional research.

The WG needs to work closely with other routing protocol working groups
such as OSPF, IDR, BGP, and IDMR. A close relationship with the
RSVP,IntServ, and ISSLL working groups is also needed to understand the
QoS signalling and specification.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Jul 97  <draft-ietf-qosr-framework-01.txt>
                A Framework for QoS-based Routing in the Internet


Remote Authentication Dial-In User Service (radius)
---------------------------------------------------

 Charter
 Last Modified: 03-Jan-96

 Current Status: Active Working Group

 Chair(s):
     Carl Rigney <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ietf-radius
     Archive:           ftp://ftp.livingston.com/pub/radius/archive

Description of Working Group:

Background:

The original specification for and implementation of RADIUS was written
by Steve Willens of Livingston Enterprises in response to a need
outlined by the earlier NASREQ working group, and has been deployed by
multiple vendors over the past 3 years.

No other working group appears to be addressing the topic of
communicating authentication and authorization information between a
Network Access Server and a central authentication & authorization
server, and general consensus is that standardization of such a
protocol would be extremely useful.

This working group will produce four documents:

1) By early '96, an informational RFC documenting the RADIUS protocol
   already deployed for use by a Network Access Server (NAS) to
   communicate with a remote Authentication & Authorization database
   server, with minor amendments reflecting field experience of several
   implementations over several years at hundreds of sites.

2) By February '96, an informational RFC describing RADIUS Accounting.

3) By early '97, a full standard RFC documenting the RADIUS protocol,
   addressing any operational or security issues raised concerning the
   informational RFC. This document will obsolete goal 1.  (If the
   Internet-Draft for goal 1 is deemed suitable by the IESG for release as
   a Proposed Standard instead of informational, then goals 1 and 3 will
   be merged.)

4) Starting in February '96 and concluding in '97, a RADIUS Extensions
   RFC documenting extensions for additional functionality within the
   RADIUS framework, which will be interoperable with the base RADIUS
   defined in the document for goal 3.

The intent in goals 1 through 3 are to document the protocol as it
exists and is used currently, in such a way as to allow interoperable
implementations to be written from the RFC.  Minor modifications to
enhance interoperability or operation based on field experience are
suitable, major overhauls are outside the scope of this working group's
charter.  Goal 4 is to provide a mechanism for additional features
deemed widely useful to be added to the existing framework, for example
to provide better support for EAP.

Clearly outside the scope of the charter are the following:

1) NAS Standardization is outside the scope.  We're defining standard
   RADIUS, not a standard encompassing everything about network access
   servers.  This effort does not require NASes to implement RADIUS; it
   just defines how the RADIUS Protocol works on NASes that do
   implement RADIUS.

2) RADIUS is not intended as a NAS management protocol; SNMP already
   exists for that.

3) Management of the Authentication/Authorization database itself is
   outside the scope.

4) Alternative transport protocols such as IPX or IPv6 appear
   straightforward, but will not be addressed in this effort.

5) The flexibility and generality of RADIUS have led to its use for
   other applications, but this Working Group is addressing only those
   uses involving user dial-in to Network Access Servers.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Jul 97  <draft-ietf-radius-tunnel-imp-03.txt>
                Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS

 Nov 96 Aug 97  <draft-ietf-radius-tunnel-auth-02.txt>
                RADIUS Attributes for Tunnel Protocol Support

 Jan 97 May 97  <draft-ietf-radius-eap-02.txt>
                Extensible Authentication Protocol Support in RADIUS

 Jan 97 New     <draft-ietf-radius-ext-00.txt>
                RADIUS Extensions

 Jul 97 New     <draft-ietf-radius-acct-interim-00.txt>
                RADIUS Accounting Interim Accounting Record Extension

 Aug 97 New     <draft-ietf-radius-acc-clientmib-00.txt>
                RADIUS Accounting Client MIB

 Aug 97 New     <draft-ietf-radius-acc-servmib-00.txt>
                RADIUS Accounting Server MIB

 Aug 97 New     <draft-ietf-radius-auth-clientmib-00.txt>
                RADIUS Authentication Client MIB

 Aug 97 New     <draft-ietf-radius-auth-servmib-00.txt>
                RADIUS Authentication Server MIB

 Oct 97 New     <draft-rfced-info-zorn-00.txt>
                RADIUS Attributes for MS-CHAP Support


Receipt Notifications for Internet Mail (receipt)
-------------------------------------------------

 Charter
 Last Modified: 26-Apr-96

 Current Status: Active Working Group

 Chair(s):
     Ned Freed <[e-mail]>
     Urs Eppenberger <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://cs.utk.edu/pub/receipt/mail-archive

Description of Working Group:

There is a wide interest of e-mail users to know if and when a message
has been shown to a (human) recipient. This functionality is available
for a number of PC e-mail systems and within X.400. The receipt working
group will specify the necessary extensions to support this
functionality within the Internet Mail environment and optionally also
specify the necessary mappings for MIXER gateways.

The result of this work will be a Proposed Standard specifying:

o The mechanism used for requesting that the recipient issue a read-receipt.

o The format used for transferring read-receipts.

o The advice on the privacy and security issues involved in read-receipts.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 95 Oct 97  <draft-ietf-receipt-mdn-06.txt>
                An Extensible Message Format for Message Disposition
                Notifications


Routing Information Protocol (rip)
----------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     G. Malkin <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ietf-rip <your email address>
     Archive:           ftp://xylogics.com/pub/users/gmalkin/rip/rip-arc

Description of Working Group:

The RIP Working Group was formed from the RIP Version 2 Working
Group, which was originally chartered to create the RIP-2 standard.
Since several other RIP-related efforts are also occuring within
the IETF, it was decided to create a single working group to handle
them all.

The RIP Working Group is chartered to guide the following proposals
and develop the following projects through the IETF standards track:

  - ``RIP Version 2'' (RFC 1723)

  - ``RIP Version 2 MIB Extension'' (RFC 1724)

  - ``Extensions to RIP to Support Demand Circuits'' (RFC 1582)

  - ``RIP-II Cryptographic Authentication'' (Internet-Draft)

Additionally, the RIP Working Group will handle the RIPng protocol
which, in its first incarnation, will contain the minimum modifications
to RIP-2 necessary to handle IPng.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 New     <draft-ietf-rip-mib-00.txt>
                RIP Version 2 MIB Extension

 Oct 97 New     <draft-ietf-rip-doi-00.txt>
                RIPv2 Domain Of Interpretation (DOI) for ISAKMP


Remote Network Monitoring (rmonmib)
-----------------------------------

 Charter
 Last Modified: 29-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Andy Bierman <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Technical Advisor(s):
     Steven Waldbusser  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftpeng.cisco.com/ftp/rmonmib/rmonmib

Description of Working Group:

The RMON MIB Working Group is chartered to define a set of managed
objects for remote monitoring of networks.  These objects will be
the minimum necessary to provide the ability to monitor multiple
network layers of traffic in remote networks; providing fault,
configuration, and performance management, and will be consistent
with the SNMP framework and existing SNMP standards.

The working group will consider existing MIB modules that define
objects which support similar management, e.g., RFC 1271 and
RFC 1513 and efforts in other areas, e.g., the accounting and
operational statistics activities.  It is possible that this RMON
will not be backwards compatible with existing RMON RFCs, but the
reasons for any such incompatibility will be well documented.

The following list of features for this RMON has been previously
discussed in relation to existing RMON functionality and is included
to focus these RMON activities.  It is recognized that other issues
may be considered and that certain of the following issues may not
be part of the final specification:

1) Protocol-type distribution through all seven layers of the ISO
   model.

2) Address mapping - Network Layer to Data Link (MAC) Layer and
vice-versa.

3) Mechanisms that enable the detection of duplicate addresses or
   address changes.

4) The relationship of the Manager-to-Manager MIB in SNMPv2 and
   associated RMON alarm related activities.

5) Host Table for the Network Layer and the Transport Layer.

6) Provide a simple mechanism for the specification of event/trap
   destinations

7) Address the issue of the filter mechanism being constrained by
   bit-to-bit packet matching, which presents a problem with variable-
   length packets.

8) Consider how RMON could benefit network security, for example:
   using the RMON History to provide an accountability and audit
   trail up to the Transport Layer.

9) Provide performance metrics for the client-server environment.

10) Concerns of hardware implementation should be considered.  For
example,
   optimization of the filter and capture group could reduce the cost of
   the CPU and improve performance.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 96 Oct 97  <draft-ietf-rmonmib-smon-04.txt>
                Remote Network Monitoring MIB Extensions for Switch Networks
                Version 1.0

 Nov 96 Oct 97  <draft-ietf-rmonmib-rmonprot-v2-03.txt>
                Remote Network Monitoring MIB Protocol Identifiers (Version 2)

 Feb 97 Sep 97  <draft-ietf-rmonmib-hcrmon-02.txt>
                Remote Network Monitoring Management Information Base for High
                Capacity Networks


Roaming Operations (roamops)
----------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     G. Zorn <[e-mail]>
     Pat Calhoun <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Technical Advisor(s):
     Michael O'Dell  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       include
     Archive:           ftp://ftp-no.rutgers.edu/misc/IETF/roamops

Description of Working Group:

The purpose of this group is to develop or adopt procedures, mechanisms
and protocols to support user roaming among groups of Internet service
providers (ISPs).  This is different from, but related to, the work of
the IP Routing for Wireless/Mobile Hosts Working Group (mobileip) in
that the roamops group is not concerned  with the movement of hosts or
subnets, but of users.  In the near term, the goals of the group will
be to produce an architectural document describing the basic mechanisms
required to support user roaming.  A repository for documentation
describing current roaming implementations will also be maintained.

In addition, the group will address interoperability among ISPs and
roaming users by standardizing such items as network usage data
exchange (including the content, format and protocols involved), phone
book attributes and exchange/update protocols, inter-ISP authentication
mechanisms and exploring in depth the security issues involved with
roaming.  This work is expected to consist mainly of new or revised
procedures and application-layer protocols.

Any and all business issues regarding the operation of an ISP roaming
network (such as settlement, business and billing methods) are
specifically NOT in the scope of the roamops Working Group and will not
be discussed.

The group will work closely with other IETF Working Groups (including
mobileip, radius, nasreqng saag and cat) to identify issuesto which the
roamops group should attend, as well as to assure their work does not
make roaming unnecessarily difficult or impossible.

The utmost goal of the group will to make sure, by any means necessary,
that it produces documents of high quality that are useful to the IETF
community.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 96 Jul 97  <draft-ietf-roamops-roamreq-05.txt>
                Dialup Roaming Requirements

 Nov 96 Sep 97  <draft-ietf-roamops-nai-07.txt>
                The Network Access Identifier

 Mar 97 Aug 97  <draft-ietf-roamops-actng-03.txt>
                Session Record Accounting in Roaming

 Mar 97 Sep 97  <draft-ietf-roamops-auth-03.txt>
                Guidelines for the Operation of RADIUS Proxies in Roaming

 Oct 97 New     <draft-ietf-roamops-sec-00.txt>
                Secure Radius Server Operation Guidelines for Dial Roaming



Routing Policy System (rps)
---------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Daniel Karrenberg <[e-mail]>
     Cengiz Alaettinoglu <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/rps

Description of Working Group:

The Routing Policy System Working Group will (1) define a language,
referred to as Routing Policy Specification Language (RPSL), for
describing routing policy constraints; (2) define a simple and robust
distributed registry model for publishing routing policy constraints;
and (3) define a set of tools for analysing registered policy
constraints, for checking global consistency, for generating router
configurations, and for diagnosing operational routing problems. It is
expected that RPSL will enter the standards track.

The RPSL will be routing protocol independent as well as router
configuration format independent to support various routing protocols
such as BGP, IDRP, SDRP, and various router technologies. The RPSL will
be backward compatible with RIPE-181 whenever possible; the registry
model will be based on the RIPE database.

The working group will focus on inter-domain routing protocols, but
will also instigate, review, or (if appropriate) produce additional
RFCs to support other protocols such as multicasting and resource
reservation.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Aug 97  <draft-ietf-rps-rpsl-03.txt,.ps>
                Routing Policy Specification Language (RPSL)

 Mar 97 Aug 97  <draft-ietf-rps-transition-01.txt>
                A strategy for the transition from RIPE-181 to RPSL

 Mar 97 New     <draft-ietf-rps-appl-rpsl-00.txt, .ps>
                Application of Routing Policy Specification Language (RPSL) on
                the Internet


Resource Reservation Setup Protocol (rsvp)
------------------------------------------

 Charter
 Last Modified: 13-May-97

 Current Status: Active Working Group

 Chair(s):
     Lixia Zhang <[e-mail]>
     Bob Braden <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.isi.edu/rsvp/rsvp.mail

Description of Working Group:

RSVP is a resource reservation setup protocol for the Internet. Its
major features include: (1) the use of ``soft state'' in the routers, (2)
receiver-controlled reservation requests, (3) flexible control over
sharing of reservations and forwarding of subflows, and (4) the use of
IP multicast for data distribution.

The primary purpose of this working group is to evolve the RSVP
specification and to introduce it into the Internet standards track.
The working group will also serve as a meeting place and forum for
those developing and experimenting with RSVP implementations.

The task of the RSVP Working Group, creating a robust specification for
real-world implementations of RSVP, will require liaison with two other
efforts: (1) continuing research and development work on RSVP in the
DARTnet research
community, and (2) the parallel IETF working group that is considering
the service model for integrated service. Although RSVP is largely
independent of the service model, its design does depend upon the
overall integrated service architecture and the requirements of
real-time applications. As an additional task, RSVP will maintain
coordination with the IPng-related working groups.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 95 Aug 97  <draft-ietf-rsvp-md5-05.txt>
                RSVP Cryptographic Authentication

 Jun 96 Mar 97  <draft-ietf-rsvp-policy-ext-02.txt, .ps>
                RSVP Extensions for Policy Control

 Feb 97 Jun 97  <draft-ietf-rsvp-cidr-ext-01.txt>
                RSVP Extensions for CIDR Aggregated Data Flows

 Mar 97 New     <draft-ietf-rsvp-tunnels-interop-00.txt>
                Designing Tunnels for Interoperability with RSVP

 Mar 97 Aug 97  <draft-ietf-rsvp-policy-oops-01.txt,.ps>
                Open Outsourcing Policy Service (OOPS) for RSVP

 Apr 97 New     <draft-ietf-rsvp-partial-service-00.txt>
                Partial Service Deployment in the Integrated Services
                Architecture

 Jun 97 New     <draft-ietf-rsvp-rapi-00.txt, .ps>
                RAPI -- An RSVP Application Programming Interface

 Jul 97 New     <draft-ietf-rsvp-pepci-00.txt>
                Protocol for Exchange of PoliCy Information (PEPCI)

 Oct 97 New     <draft-ietf-rsvp-v2-mib-00.txt>
                RSVP Management Information Base


Realtime Traffic Flow Measurement (rtfm)
----------------------------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Gregory Ruth <[e-mail]>
     Nevil Brownlee <[e-mail]>
     Sig Handelman <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Scott Bradner  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe rtfm  your-email-address
     Archive:           ftp://ftp.auckland.ac.nz/pub/rtfm/archive

Description of Working Group:

This working group has three main objectives:

* Consider current issues in traffic flow measurement, such as

  - Security issues relating to both traffic measuring devices
    and to the data they produce.

  - Policy issues relating to traffic measurement and usage
    accounting, for example any requirements these may place on
    emerging network protocols

  - Existing work in traffic flow measurement, including that of
    IETF Working Groups such as bmwg/ippm, rsvp and rmonmib, as
    well as that by vendors and independent researchers

* Produce an improved Traffic Flow Model considering at least the
  following needs:

  - wider range of measurable quantities, e.g. those relating to
      IPv6, and to class of service
  - simpler ways to specify flows of interest
  - better ways to control access to measured flow data
  - strong focus on data reduction capabilities
  - efficient hardware implementation

* Develop the RTFM Architecture and Meter MIB as 'standards track'
  documents with the IETF.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Jul 97  <draft-ietf-rtfm-new-traffic-flow-02.txt>
                RTFM Working Group - New Attributes for Traffic Flow
                Measurement

 Mar 97 Sep 97  <draft-ietf-rtfm-meter-mib-02.txt>
                Traffic Flow Measurement:  Meter MIB

 Sep 97 New     <draft-ietf-rtfm-architecture-00.txt>
                Traffic Flow Measurement:  Architecture


Responsible Use of the Network (run)
------------------------------------

 Charter
 Last Modified: 26-Sep-97

 Current Status: Active Working Group

 Chair(s):
     G. Malkin <[e-mail]>
     Sally Hambridge <[e-mail]>

 User Services Area Director(s):
     Joyce K. Reynolds  <[e-mail]>

 User Services Area Advisor:
     Joyce K. Reynolds  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe ietf-run Firstname Lastname
     Archive:           ftp://ftp.intel.com/pub/ietf-run

Description of Working Group:

Reflecting the needs of the Internet community, the IETF sees a need to
create an  guide for Internet users about mass unsolicited email and
Netnews postings.  The Working Group will develop an FYI RFC on
mass unsolicited email and posts, as well as an FYI RFC on responsible
advertising.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Jul 97  <draft-ietf-run-spew-01.txt>
                DON'T SPEW     A Set of Guidelines for Mass Unsolicited
                Mailings and Postings (Spam*)


RWhois Operational Development (rwhois)
---------------------------------------

 Charter
 Last Modified: 23-Aug-95

 Current Status: Active Working Group

 Chair(s):
     Scott Williamson <[e-mail]>
     Mark Kosters <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe rwhois
     Archive:           ftp://rs.internic.net/put/rwhois/rwhois-archive

Description of Working Group:

The RWhois Operational Development Working Group will be a forum
for coordinating the deployment, engineering and operation of the
RWhois protocol to replace the current centralized whois model. The
minimum attribute set will be defined to ensure that all delegated
registries maintain the required information. Required user
authentication will be defined to allow remote registration with RWhois
servers. Operational procedures will be established to ensure that all
delegated servers conform to a set of minimum standards. If necessary
the RWhois protocol specification will be updated to reflect changes in
requirments identifed during the working group tenure.


 Internet-Drafts:

  No Current Internet-Drafts.


Source Demand Routing (sdr)
---------------------------

 Charter
 Last Modified: 19-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Deborah Estrin <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://catarina.usc.edu/pub/sdrp

Description of Working Group:

The SDR Working Group is chartered to specify and promote the use of SDRP
(Source Demand Routing Protocol) as an inter-domain routing protocol
capability in conjunction with IDRP and BGP inter-domain routing
protocols.  The purpose of SDR is to support explicit selection of inter-
domain routes, to complement the implicit hop-hy-hop route selection
provided by BGP/IDRP.  The group is also chartered to specify and promote
the use of a similar protocol for IPv6, referred to as the Explicit
Routing Protocol (ERP).

The goal of the SDR Working Group is to release the components of SDR as
``experimental'' IETF protocols and to obtain operational experience with
SDR in the Internet.  Once there is enough experience with SDR, the
working group will submit the SDR components to the IESG for
standardization.

SDR has four components: packet formats for protocol control messages
and encapsulation of user datagrams, processing and forwarding of user
data and control messages, routing information distribution/collection
and route computation, configuration and usage.


The group's strategy is to:

(1) Define the format, processing and forwarding of user datagram and
control messages so that SDR can be used very early on as an efficient
means of supporting ``configured'' inter-domain routes.  User packets
are encapsulated along with the source route and forwarded along the
``configured'' route.  Routes are static at the inter-domain level, but
are not static in terms of the intra-domain paths that packets will
take between specified points in the SDR route. The impact of
encapsulation on MTU, ICMP, performance, etc., are among the issues that
must be evaluated before deployment.

(2) Develop simple schemes for collecting (a) dynamic domain-level
connectivity information and (b) route construction based on this
information, so that those domains that want to can make use of a
richer, and dynamic set of SDR routes.

(3) Apply the experience with SDR design and implementation to the
design and implementation of ERP.

(4) Develop SDR and ERP deployment plans.

(5) In parallel with (1), (2) and (3) , develop usage and configuration
documents and prototypes that demonstrate the utility of static-SDR and
simple-dynamic-SDR and ERP.

(6) After gaining some experience with the simple schemes for
distribution, develop a second generation of information distribution
and route construction schemes.  The group hopes to benefit from
discussions with IDPR and NIMROD developers at this future stage because
the issues faced are similar.  The route distribution and construction
mechanisms are common to both ERP and SDRP.

(7) Investigate the use of SDRP and ERP alternate routing as a mechanism
for supporting reservation traffic (e.g., based on RSVP).  This will
require that we address integration of SDRP/ERP and multicast routing
(e.g., running PIM over SDRP/ERP), as well as the interface between
SDRP/ERP and RSVP.  Moreover, we will investigate the construction of
SDRP/ERP routes that make use of some dynamic control information, in
additional to the more traditional hop count.

(8) The group will also investigate the addition of security options
into the SDRP/ERP forwarding and packet format specifications.

(9) Coordinate with the IDR and IPng Working Groups.

 Internet-Drafts:

  No Current Internet-Drafts.


Secure Shell (secsh)
--------------------

 Charter
 Last Modified: 26-Feb-97

 Current Status: Active Working Group

 Chair(s):
     Perry Metzger <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe [e-mail] in body
     Archive:

Description of Working Group:

The goal of the working group is to update and standardize the popular
SSH protocol. SSH provides support for secure remote login, secure file
transfer, and secure TCP/IP and X11 forwardings. It can automatically
encrypt, authenticate, and compress transmitted data.  The working
group will attempt to assure that the SSH protocol

 o  provides strong security against cryptanalysis and protocol attacks,

 o  can work reasonably well without a global key management or
    certificate infrastructure,

 o  can utilize existing certificate infrastructures (e.g., DNSSEC,
    SPKI, X.509) when available,

 o  can be made easy to deploy and take into use,

 o  requires minimum or no manual interaction from users,

 o  is reasonably clean and simple to implement.

The resulting protocol will operate over TCP/IP or other reliable but
insecure transport. It is intended to be implemented at the application
level.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Oct 97  <draft-ietf-secsh-transport-02.txt>
                SSH Transport Layer Protocol

 Mar 97 Oct 97  <draft-ietf-secsh-userauth-02.txt>
                SSH Authentication Protocol

 Mar 97 Oct 97  <draft-ietf-secsh-connect-02.txt>
                SSH Connection Protocol

 Oct 97 New     <draft-ietf-secsh-architecture-00.txt>
                SSH Protocol Architecture


SNA DLC Services MIB (snadlc)
-----------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Shannon Nix <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Technical Advisor(s):
     Ken Key  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

     The SNA DLC Services MIB Working Group is chartered to define a set of
      managed
     objects for the SDLC and LLC-2 data link controls for SNA
     networks.  These objects will be the minimum necessary to provide
     the ability to monitor and control those devices, providing fault,
     configuration, and performance management, and will be consistent
     with the SNMP framework and existing SNMP standards.

     The working group will consider existing enterprise-specific MIB modules
     that define objects which support management of these devices.  The
     group may choose to consider any work done by the IEEE in the
     area of managed object definition for LLC-2.  It will also make sure
     that its work is aligned with the SNA NAU Services MIB Working Group,
     due to the close relationship between the devices being worked on by
     the two groups.

     The working group recognizes that managed objects for other SNA data
     link controls and related components (e.g., QLLC, System/370 Channel,
     Data Link Switching, and ESCON) may need to be identified in the
     future.  These objects are out of scope for the current charter;
     however, once the group completes its charter, a new charter
     identifying some or all of these components may be considered.

 Internet-Drafts:

  No Current Internet-Drafts.


SNA NAU Services MIB (snanau)
-----------------------------

 Charter
 Last Modified: 08-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Robert Moore <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.cisco.com/snanaumib/mail-archive

Description of Working Group:

The SNA NAU MIB Working Group is chartered to define a set of managed
objects for SNA Network Accessible Units.  These objects will provide the
ability to monitor and control those devices, providing fault,
configuration, and performance management, and will be consistent with
the SNMP framework and existing SNMP standards.

The working group has completed MIBs for base SNA NAU functions, for LU
Type 6.2 or APPC (Advanced Program-to-Program Communication), and for
APPN (Advanced Peer-to-Peer Networking).  MIBs for Dependent LU Requester
(DLUR) and for HPR (High Performance Routing) are nearing completion.
The working group is currently working on a MIB for APPN Extended Border
Node (EBN).

The working group will make sure that its work is aligned with the SNA
DLC MIB Working Group, due to the close relationship between the devices
being worked on by the two groups.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 May 97  <draft-ietf-snanau-hprmib-02.txt>
                Definitions of Managed Objects for HPR

 Nov 96 May 97  <draft-ietf-snanau-dlurmib-02.txt>
                Definitions of Managed Objects for DLUR

 Sep 97 New     <draft-ietf-snanau-ebnmib-00.txt>
                Definitions of Managed Objects for Extended Border Node


SNMP Version 3 (snmpv3)
-----------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Russ Mundy <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     Michael O'Dell  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.tis.com/pub/ietf/snmpv3

Description of Working Group:

The SNMPv3 Working Group is chartered to prepare recommendations for
the next generation of SNMP. The goal of the Working Group is to
produce the necessary set of documents that will provide a single
standard for the next generation of core SNMP functions.

During the past several years, there have been a number of activities
aimed at incorporating security and other improvements to SNMP.
Unfortunately, strongly held differences on how to incorporate these
improvements into SNMP prevented the SNMPV2 Working Group from coming
to closure on a single approach. As a result, two different approaches
(commonly called V2u and V2*) have emerged.

The Security and Administrative Framework Evolution for SNMP Advisory
Team (the Advisory Team) was formed to provide a single recommended
approach for SNMP evolution.  The technical starting point for this
Working Group will be the recommended approach provided by the Advisory
Team.

This approach provides for the convergence of concepts and technical
elements of V2u and V2*.  The SNMPv3 Working Group is not starting new
work and will use as many concepts, technical elements and
documentation as practical from the V2u and V2* activities.  Previous
delays in providing a single standard for the next generation of SNMP
core functions dictate that the Working Group move forward as quickly
as possible to document and publish Internet Drafts and RFC's.  To this
end, the Working Group will make use of as much existing documentation
as practical. Additionally, functional changes beyond those needed to
provide a single approach will be strongly discouraged.

Timely completion of a single approach for SNMPv3 is crucial for the
continued success of SNMP.  Recognizing the need for prompt completion,
the following objectives are provided to the Working Group:

- accommodate the wide range of operational environments with
  differing management demands;

- facilitate the need to transition from previous, multiple protocols
  to SNMPv3;

- facilitate the ease of setup and maintenance activities.


Note: SNMPv3 planned specifications:

    SNMPv3 Modules and Interface Definitions
    SNMPv3 Message Processing and Control Module Specification
    SNMPv3 Security Model Module Specification
    SNMPv3 Local Processing Mosule Specification
    SNMPv3 Proxy Specification

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Apr 97 Oct 97  <draft-ietf-snmpv3-next-gen-arch-06.txt>
                An Architecture for Describing SNMP Management Frameworks

 Apr 97 May 97  <draft-ietf-snmpv3-lpm-01.txt>
                Local Processing Model for version 3 of the Simple Network
                Management Protocol (SNMPv3)

 May 97 Oct 97  <draft-ietf-snmpv3-v3mpc-model-06.txt>
                Message Processing and Dispatching for the Simple Network
                Management Protocol (SNMP)

 May 97 Jun 97  <draft-ietf-snmpv3-usec-01.txt>
                User-based Security Model for version 3 of the Simple Network
                Management Protocol (SNMPv3)

 Jun 97 Oct 97  <draft-ietf-snmpv3-acm-04.txt>
                View-based Access Control Model (VACM) for the Simple Network
                Management Protocol (SNMP)

 Jul 97 Oct 97  <draft-ietf-snmpv3-usm-03.txt>
                User-based Security Model (USM) for version 3 of the Simple
                Network Management Protocol (SNMPv3)

 Jul 97 Oct 97  <draft-ietf-snmpv3-appl-04.txt>
                SNMPv3 Applications


Simple Public Key Infrastructure (spki)
---------------------------------------

 Charter
 Last Modified: 30-Jan-97

 Current Status: Active Working Group

 Chair(s):
     Steve Bellovin <[e-mail]>
     Perry Metzger <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       In Body: subscribe spki [email address]
     Archive:

Description of Working Group:

Many Internet protocols and applications which use the Internet employ
public key technology for security purposes and require a public key
infrastructure to manage public keys.

The task of the working group will be to develop Internet standards
for an IETF sponsored public key certificate format, associated
signature and other formats, and key acquisition protocols.  The key
certificate format and associated protocols are to be simple to
understand, implement, and use. For purposes of the working group, the
resulting formats and protocols are to be known as the Simple Public
Key Infrastructure, or SPKI.

The SPKI is intended to provide mechanisms to support security in a
wide range of internet applications, including IPSEC protocols,
encrypted electronic mail and WWW documents, payment protocols, and
any other application which will require the use of public key
certificates and the ability to access them. It is intended that the
Simple Public Key Infrastructure will support a range of trust models.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Jul 97  <draft-ietf-spki-cert-structure-02.txt>
                Simple Public Key Certificate

 Mar 97 New     <draft-ietf-spki-cert-req-00.txt>
                SPKI Requirements


Site Security Handbook (ssh)
----------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Barbara Fraser <[e-mail]>

 User Services Area Director(s):
     Joyce K. Reynolds  <[e-mail]>

 User Services Area Advisor:
     Joyce K. Reynolds  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://info.cert.org/pub/ietf/ssh

Description of Working Group:

The Site Security Handbook Working Group is chartered to create two
  documents: (1) a revised handbook that will help system and network
  administrators develop their own site-specific policies and procedures
  to deal with computer security problems and their prevention and (2) a
  new handbook for users.  The text of these documents will be developed
  from the existing RFC 1244, plus needed revisions and additions.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Oct 97  <draft-ietf-ssh-users-03.txt>
                Users' Security Handbook


Guide for Internet Standards Writers (stdguide)
-----------------------------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Greg Scott <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     Michael O'Dell  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe stdguide
     Archive:           ftp://ftp.midnight.com/pub/stdguide-archive

Description of Working Group:

This working group will provide a forum for implementers, testers, and
users of current Internet standard protocols to provide feedback on the
standards themselves; i.e., on what aspects of the documents defining
the standards have assisted or hindered the implementation, test, and
use of those protocols.

The purpose of the group is to collect this information, much of which
survives today as word-of-mouth knowledge in the Internet community,
and present it as a BCP document. This document will cover definitions,
guidelines, and a list of heuristic rules for avoiding common mistakes
in writing Internet protocol standards documents.

Note: This working group is jointly chartered by the Operational
Requirements Area and the User Services Area.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Aug 96 May 97  <draft-ietf-stdguide-ops-04.txt>
                Guide for Internet Standards Writers


Service Location Protocol (svrloc)
----------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Veizades <[e-mail]>
     Erik Guttman <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Thomas Narten  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www.srvloc.org/mail_archive

Description of Working Group:

The Service Location Protocol is a decentralized, lightweight, scalable
and extensible protocol for service discovery within a site.  It allows
but does not require centralized administration.  Even when security,
administrative policies or convenience require centralization (say in
large enterprise deployments) the protocol requires very little
administration. The protocol limits its use of multicast and broadcast
as much as possible to conserve network bandwidth.  Moreover, the
protocol is extensible to arbitrary service advertisement and discovery
and supports multiple languages and character set encodings.

The working group will document procedures for discovering services,
and standardize "service:" schemes, which are definitions for resource
and service URLs.

The focus of the working group will be on completing various documents
which describe how to do service discovery and how to standardize
service definitions which will be advertised and discovered.

 - Interactions between Service Location Protocol and other enterprise
   naming and directory service protocols will be explored, defined,
   and standardized.

 - Schemes for popular services will be discussed, and standardization
   efforts with other working groups explored as needed.

 - Operational experiences and security procedures will be discussed
   and documented as best current practice.

 - Service Type attribute definitions will be standardized by
   registering a 'Service Template' with IANA.   This document will
   also describe how Service Types and Directory Schemas can be made
   interoperable.  The Service Location Protocol can then be used to
   populate a directory service dynamically.

 - An Application Programmers Interface has been developed to allow
   a uniform mechanism for applications to make use of Service Location
   Protocol functions, which will be supplied as an informational
   document.

 - The Service Location Protocol itself will be revised and improved
   on, continuing it along the standards track.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 96 Oct 97  <draft-ietf-svrloc-discovery-05.txt>
                Finding Stuff (How to discover services)

 Jul 96 Feb 97  <draft-ietf-svrloc-ipv6-01.txt>
                Service Location Modifications for IPv6

 Nov 96 Oct 97  <draft-ietf-svrloc-service-scheme-03.txt>
                Service Templates and service:  Schemes

 Nov 96 Mar 97  <draft-ietf-svrloc-api-01.txt>
                An API for Service Location

 Feb 97 Oct 97  <draft-ietf-svrloc-advertising-03.txt>
                Advertising Services  (Providing information to support service
                discovery)

 Feb 97 Oct 97  <draft-ietf-svrloc-wpyp-01.txt>
                The 'wp:' and 'yp:' Abstract Service Types

 Jul 97 New     <draft-ietf-svrloc-wasrv-00.txt>
                Wide Area Network Service Location

 Jul 97 New     <draft-ietf-svrloc-template-conversion-00.txt>
                Conversion of LDAP Schemas to and from SLP Templates

 Jul 97 New     <draft-ietf-svrloc-lpr-scheme-00.txt>
                Definition of lpr:  URLs for use with Service Location


TCP Implementation (tcpimpl)
----------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Steve Alexander <[e-mail]>
     Vern Paxson <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.sgi.com/other/tcp-impl/mail.archive

Description of Working Group:

The objective of this group is to decide how to best address known
problems in existing implementations of the current TCP standard(s) and
practices.  The overall goal is to improve conditions in the existing
Internet by enhancing the quality of current TCP/IP implementations. It
is hoped that both performance and correctness issues can be resolved
by making implementors aware of the problems and their solutions.  In
the long term, it is felt that this will provide a reduction in
unnecessary traffic on the network, the rate of connection failures due
to protocol errors, and load on network servers due to time spent
processing both unsuccessful connections and retransmitted data.  This
will help to ensure the stability of the global Internet.

Examples of detected problems:

o TCPs that retransmit all unacknowledged data at a single time.
  This behavior greatly adds to Internet load, at a time when
  the network is already under stress.  The combination can
  lead to congestion collapse.

o TCPs that misinitialize the congestion window, leading to
  potentially enormous bursts of traffic when new connections
  begin.  Such burstiness can greatly stress Internet routers.

In the BOF, it was generally agreed that problems of this class need
to be fixed.

Scope:

The scope of this group must be carefully defined in order to ensure
timely progress. To this end, TCP issues that still remain areas of
research are  considered out of scope for the WG.  For example new
improvements in congestion control algorithms are not within the WG
scope. The WG will solicit input from the End-To-End research group of
the IRTF on questions of whether a TCP implementation issue is
considered research.

The major objectives of this group will be to :

Produce a compilation of known problems and their solutions.  This will
raise awareness of these issues.

Determine if any problems found are the result of ambiguities in the
TCP specification.  If necessary, produce a document which clarifies
the specification.

Catalog existing TCP test suites, diagnostic tools, testing
organizations, and procedures that can be used by implementors to
improve their code, and produce a document enumerating them.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Mar 97 Jul 97  <draft-ietf-tcpimpl-prob-01.txt>
                Known TCP Implementation Problems

 Jul 97 New     <draft-ietf-tcpimpl-tools-00.txt>
                Some Testing Tools for TCP Implementors


TCP Large Windows (tcplw)
-------------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     David Borman <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     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
[e-mail] mailing list.

The TCP Large Windows Working Group is being resurrected for a one
time meeting, to review and if appropriate, approve this new document.


 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Feb 97 New     <draft-ietf-tcplw-high-performance-00.txt>
                TCP Extensions for High Performance


TCP Over Satellite (tcpsat)
---------------------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Aaron Falk <[e-mail]>

 Transport Area Director(s):
     Scott Bradner  <[e-mail]>
     Allyn Romanow  <[e-mail]>

 Transport Area Advisor:
     Allyn Romanow  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       inbody: subscribe tcp-over-satellite
     Archive:

Description of Working Group:

Satellites are being used to extend the Global Internet geographically
and will be more ubiquitous in the next decade with the deployment of
several proposed services capable of providing greater than T1 access
to individual users anywhere in the world.

Yet, satellite links have a unique combination of characteristics that
can affect the throughput of TCP traffic. Because of the high-bandwidth
delay product, slow start and congestion control algorithms behave much
differently when the path includes a satellite link than exclusively
terrestrial ones.


The TCP over Satellite Working Group shall produce an informational RFC
which describes the issues affecting TCP throughput over satellite
links. It identifies the domains in which each issue applies, including
network topology, satellite orbit (LEO, MEO, GEO), and link rates;
fixes, both protocol and implementation, that ameliorate reduced
throughput; and areas for further research. The purpose of including
this information is to direct the research community to the areas in
which show promise, not to perform the research or even advocate the
results.

Scope:

The scope of this working group will include consideration of the
following for inclusion in the Informational RFC:

 o Transport layer issues affecting TCP over
   satellite links
 o Existing TCP options
 o Compliant implementations which have some known
   improved performance over satellite links
 o Recommendation of well understood protocol changes
 o Identification of protocol changes that are potentially promising
   but require more further investigation in order to be well understood

SECURITY

The working group will consider in depth security issues that are
relevant, describing risks and indicating how they may be addressed.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 97 New     <draft-ietf-tcpsat-stand-mech-00.txt>
                Enhancing TCP Over Satellite Channels using Standard Mechanisms


Transaction Internet Protocol (tip)
-----------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Jim Lyon <[e-mail]>
     Keith Evans <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       in message body: subscribe tip
     Archive:

Description of Working Group:

The task of the TIP working group is to develop an Internet standard
two-phase commit protocol specification, to enable heterogeneous
Transaction Managers to agree on the outcome of a distributed
transaction, based upon the Internet-Draft TIP protocol specification
<draft-lyon-itp-nodes-01.txt>.  [Note that since
<draft-lyon-itp-nodes-01.txt> references a modified version of the
Session Control Protocol (SCP), the TIP WG will also be responsible for
progression of SCP to Proposed Internet Standard.]

In many applications where different nodes cooperate on some work,
there is a need to guarantee that the work happens atomically. That is,
each node must reach the same conclusion as to whether the work is to
be completed (committed or aborted), even in the face of failures. This
behaviour is achieved via the use of distributed transactions,
employing a two-phase commit protocol (2-pc). The use of distributed
transactions greatly simplifies distributed applications programming,
since the number of possible outcomes is reduced from many to two, and
failure recovery is performed automatically by the transaction service
(Transaction Manager).

Key requirements to be met are, 1) the 2-pc protocol be independent of
the application-to-application communications protocol, such that it
may be used with any application protocol (especially HTTP), and 2) the
2-pc protocol be simple to implement and have a small working footprint
(to encourage ubiquitous implementation and offer wide applicability).

The first work item of the group is to develop a requirements document,
which describes at least one complete scenario in which the TIP
protocol is intended to be used, and describes the requirements on the
protocol with regards to:

 - Simplicity
 - Overhead/Performance
 - Security

The protocols developed by this working group will be analyzed for
potential sources of security breach. Identified threats will be
removed from the protocol if possible, and documented and guarded
against in other cases.

The Internet-Draft document <draft-lyon-itp-nodes-01.txt> is to be used
as the input base document for the development of this 2-pc protocol
specification.

Due to extreme differences in the approach, the group will not consider
the CORBA OTS specification as a solution to its requirements.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Oct 97  <draft-lyon-itp-nodes-03.txt>
                Transaction Internet Protocol    Version 2.0

 May 97 New     <draft-evans-v2-scp-00.txt>
                Session Control Protocol V 2.0


Transport Layer Security (tls)
------------------------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Win Treese <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www.imc.org/ietf-tls/mail-archive

Description of Working Group:

Note: This Working Group is jointly chartered by the Transport Area.
The Transport Area Director:  Allison Mankin <[e-mail]>

Several methods of providing a secure and authenticated channel
between hosts on the Internet above the transport layer have appeared.
The objective of this proposed working group is to write standards
track RFC(s) for protocols using the currently available Internet
drafts as a basis.  The SSL, PCT and SSH protocols are examples of
mechanisms of establishing a secure channel for general purpose or
special purpose Internet applications running over a reliable
transport, usually TCP.

The TLS working group is a focused effort on providing security
features at the transport layer, rather than general purpose security
and key management mechanisms.  The standard track protocol
specification will provide methods for implementing privacy,
authentication, and integrity above the transport layer.

The work currently under way in the area of secure IP is outside the
scope of this working group. Also, general authentication mechanism
discussions are outside the focus of this group. However, best efforts
will be made to utilize as much as possible of the already existing
technologies and methodologies in the IETF and other places to solve
common problems, such as key management.

The group may also produce an informational RFC to describe conventions
for
the interface to a Socket (or transport) layer secure library to build
specific applications as well as TCP port number conventions for running
secure versions of network applications.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Jul 97  <draft-ietf-tls-kerb-cipher-suites-01.txt>
                Addition of Kerberos Cipher Suites to Transport Layer Security
                (TLS)

 Nov 96 Oct 97  <draft-ietf-tls-protocol-04.txt>
                The TLS Protocol  Version 1.0


Telnet TN3270 Enhancements (tn3270e)
------------------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Ed Bailey <[e-mail]>
     Michael Boe <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Technical Advisor(s):
     Robert Moskowitz  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       sub tn3270e <first_name> <last_name>
     Archive:           [e-mail]

Description of Working Group:

Present specifications for access to 3270 and 5250 based applications
over
TCP/IP require improvement to become more commercially viable. Security,
Service Location, Response Time, and Session Balancing are improvement
examples.

The WG will drive to update and extend the standards specifications
proposed
in rfc1647 and rfc1205 so that they fully support 3270 and 5250 style
access
to host (S/390 and AS/400) applications respectively in today's
environments.

Consideration will be given to work already in progress on protocols for
accessing 3270 and 5250 based applications over TCP/IP.

Three protocol documents will be produced.

Deliverables

1. A revised version of rfc1647 (tn3270e) including clarifications of
the
protocol, and security considerations.  The revised rfc1647 will be
submitted
to the IESG for advancement of the tn3270e protocol to draft standard
status.
Currently it is a proposed standard.

2. A new standards track document defining options for the tn3270e
protocol.
Such options are:  IPDS printing,  response time monitoring, error
reporting,
session balancing, service location, and security.

3. A new standards track document defining enhancements to the tn5250
protocol.
This new protocol will be called tn5250e. This is not Display Station
Passthrubut printing, LU assignment, service location, and security.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 May 97 New     <draft-ietf-tn3270e-ver2-enhance-00.txt>
                TN3270 Enhancements

 Jun 97 Sep 97  <draft-ietf-tn3270e-tn3270-mib-03.txt>
                Base Definitions of Managed Objects for TN3270E Using SMIv2

 Jul 97 Oct 97  <draft-ietf-tn3270e-rt-mib-01.txt>
                Definitions of Managed Objects for TN3270E Response Time
                Collection Using SMIv2


DS1/DS3 MIB (trunkmib)
----------------------

 Charter
 Last Modified: 29-Jul-97

 Current Status: Active Working Group

 Chair(s):
     Fred Baker <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:

Description of Working Group:

This working group will consider revisions to the DS1 and DS3 MIBs
(currently published as Proposed Standards in RFC-1232 and RFC-1233) in
preparation for their consideration as Draft Standards.

Consistent with the IETF standards process, the working group is
chartered to consider only those changes to the DS1 and DS3 MIBs that
are based on implementation experience or on the need to align with
relevant ANSI T1M1 standards. In this context, the working group will
thoroughly document the implementation or alignment rationale for each
considered change.

All changes made by the working group will be consistent with the
existing SNMP framework and standards --- in particular, those
provisions of RFC-1155 regarding addition and deprecation of objects
in standard SNMP MIBs.

This working group will be a short-lived activity, involving a single
meeting, and will conclude its business no later than June 1992.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 95 Jun 97  <draft-ietf-trunkmib-ds1-mib-06.txt>
                Definitions of Managed Objects for the DS1, E1, DS2 and E2
                Interface Types

 Oct 95 Jun 97  <draft-ietf-trunkmib-ds3-mib-05.txt>
                Definitions of Managed Objects for the DS3/E3 Interface Type

 Feb 96 Jun 97  <draft-ietf-trunkmib-ds0-mib-04.txt>
                Definitions of Managed Objects for the DS0 and DS0 Bundle
                Interface Type


UniDirectional Link Routing (udlr)
----------------------------------

 Charter
 Last Modified: 29-Jan-97

 Current Status: Active Working Group

 Chair(s):
     Walid Dabbous <[e-mail]>
     Yongguang Zhang <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://zenon.inria.fr/rodeo/udlr/archive.txt

Description of Working Group:

Note: An alternate site for UDLR's files is: ftp://irl.cs.ucla.edu/pub/udlr


High bandwidth, unidirectional transmission to low cost, receiver-only
hardware is becoming an emerging network fabric, e.g. broadcast
satellite links or some cable links.

Two cases for unidirectional links support may be envisaged:

 1. unidirectional links on top of bidirectional underlying network
    (wired Internet)
 2. bidirectional islands connected via unidirectional links.

In both cases, the integration of unidirectional links may require
changes to the routing protocols in order to preserve dynamic routing
across these links. A short term solution (i.e. to solve the first
case) is to adopt current protocols with possible modifications. A long
term solution (i.e. for the second case) is to propose, design and
implement protocols that remove assumed link symmetry (e.g. by
supporting 2-way metrics).

There have been several proposed approaches for the short term case.
The first is based on the modification of the common routing protocols
(RIP, OSPF, DVMRP) in order to support unidirectional links.  The
second is to add a layer between the network interface and the routing
software to emulate bi-directional links through tunnels.

The purpose of the UDLR Working Group, therefore, is to study these
approaches and suggest a short term solution to provide dynamic routing
(including multicast) in the presence of unidirectional links.

 Internet-Drafts:

  No Current Internet-Drafts.


Uninterruptible Power Supply (upsmib)
-------------------------------------

 Charter
 Last Modified: 06-Mar-97

 Current Status: Active Working Group

 Chair(s):
     Jeffrey Case <[e-mail]>

 Operations and Management Area Director(s):
     John Curran  <[e-mail]>
     Michael O'Dell  <[e-mail]>

 Operations and Management Area Advisor:
     John Curran  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ucs.utk.edu:~/pub/ups-mib/mail-archive

Description of Working Group:

This working group will produce a document that defines MIB objects
for use in monitoring and (possibly) controlling both high- and
low-end UPSs and related systems (e.g., power distribution systems or
power conditioning systems). Related devices may be addressed in
this effort to the extent that the primary focus on UPSs is not
compromised.

The MIB object definitions produced will be for use by SNMP and will
be consistent with existing SNMP standards and framework.

At its discretion, the working group may fulfill its charter by the
development of distinct MIB definitions for UPS systems of differing
capabilities, but the number of MIB definitions produced by the
working group will not exceed two.

At its discretion, the working group may produce an additional
document defining traps that support the management of UPSs.

Although the working group may choose to solicit input or expertise
from other relevant standards bodies, no extant standards efforts or
authorities are known with which alignment of this work is required.

Because the structure of UPS implementations varies widely, the
working group shall take special care that its definitions reflect a
generic and consistent architectural model of UPS management rather
than the structure of particular UPS implementations.


 Internet-Drafts:

  No Current Internet-Drafts.


Uniform Resource Locator Registration Procedures (urlreg)
---------------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Rich Petke <[e-mail]>
     Ian King <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       subscribe in message body
     Archive:           http://www.imc.org/ietf-url/

Description of Working Group:

This working group exists for the purpose of creating two documents:
The first document, a BCP RFC, will be the process for registering
new URL schemes.  The second document, an Informational RFC, will be
a guideline for the creators of new URL schemes.  The purpose of this
guideline will be to help ensure that new URL schemes:

  - Consistently implement the general syntax of URLs as specified in
the
    URL Generic Syntax and Semantics RFC.
  - Are compatible with existing URL schemes.
  - Have clearly specified character encoding rules.
  - Have a well defined set of operations specified for them.
  - Properly address security considerations.

The following issues are considered beyond the scope of this working
group and shall not be addressed by it:

  - Modifications to the URL Generic Syntax and Semantics RFC.
  - Specific URL schemes, previously proposed or not, except as test
    cases for the guidelines document.
  - UR* schemes other than URLs.


Justification for working group:

RFC 1738 defined URL schemes for a number of protocols popular at the
time that it was written.  Many URL schemes for protocols not addressed
in RFC 1738 have been proposed since the publication of that RFC.

Due to the absence of guidelines for the development of new URL schemes,
some of these recently proposed schemes lack completeness.  Further,
while some of these schemes are now on the standards track, no mechanism
for the registration of these new schemes has yet been specified.

The output of this working group is needed in order to help ensure the
overall integrity and consistency of URLs in the future.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Oct 97 New     <draft-ietf-urlreg-guide-00.txt>
                Guidelines for new URL Schemes


Uniform Resource Names (urn)
----------------------------

 Charter
 Last Modified: 29-Oct-97

 Current Status: Active Working Group

 Chair(s):
     John Curran <[e-mail]>
     Leslie Daigle <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Harald Alvestrand  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       In body of message: subscribe urn-ietf
     Archive:           ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive

Description of Working Group:

The goal of this working group is to define both a Uniform Resource
Name (URN) framework and an initial set of components that fit this
framework.

URNs are persistent identifiers for information resources.  The output
of this Working Group will comply with RFC 1737, which defines URNs and
gives requirements for them.  The framework will define the mechanics
for enabling global scope, persistence, and legacy support requirements
of URNs; requirements for namespaces to support this structure will
also be defined.   Although the framework will allow URNs to be defined
that vary in terms of degree of scalability and persistance, ensuring
"user friendliness" of all resultant identifiers is beyond the scope of
this group.

This WG will define the framework for URNs, at least one resolution
registry system, and at least one namespace.  RFCs describing
additional material will also be developed (per the milestones,
below).

Input documents:

 o A Framework for the Assignment and Resolution of Uniform Resource
   Names <draft-daigle-urnframework-00.txt>

 o Resolution of Uniform Resource Identifiers using the Domain Name
   System <draft-daniel-naptr-01.txt>

 o Requirements for URN Resolution Systems
   <draft-girod-urn-res-require-00.txt>

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Sep 97  <draft-ietf-urn-req-frame-04.txt>
                Architectural Principles of Uniform Resource Name Resolution

 Mar 97 Mar 97  <draft-ietf-urn-nid-req-01.txt>
                Namespace Identifier Requirements for URN Services

 Mar 97 Aug 97  <draft-ietf-urn-resolution-services-03.txt>
                URI Resolution Services Necessary for URN Resolution

 Apr 97 Sep 97  <draft-ietf-urn-biblio-02.txt>
                Using Existing Bibliographic Identifiers as Uniform Resource
                Names

 May 97 May 97  <draft-ietf-urn-syntax-05.txt>
                URN Syntax

 May 97 Jul 97  <draft-ietf-urn-ietf-02.txt>
                A URN Namespace for IETF Documents


User Services (uswg)
--------------------

 Charter
 Last Modified: 24-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Joyce K. Reynolds <[e-mail]>

 User Services Area Director(s):
     Joyce K. Reynolds  <[e-mail]>

 User Services Area Advisor:
     Joyce K. Reynolds  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://ftp.near.net/mail-archives/us-wg*

Description of Working Group:

The User Services Working Group of the IETF provides a regular forum
for people interested in all levels of user services to identify and
initiate projects designed to improve the quality of information
available to users of the Internet.  Actual projects themselves are
handled by separate groups, usually through IETF working groups, or
through liaisons with international organizations such as TERENA's
(Trans-European Research and Education Network Association)
Information Services and User Support.

(1) Meet on a regular basis to consider projects designed to improve
    services to users.  In general, projects should:

    - Clearly address user assistance needs;

    - Produce an end-result (e.g., a document, a program plan, etc.);

    - Have a reasonably clear approach to achieving the end-result
         (with an estimated time for completion); and

    - Not duplicate existing or previous efforts.

(2) Create working groups or other focus groups to carry out projects
    deemed worthy of pursuing.

(3) Provide a forum in which user services providers can discuss and
    identify common concerns.

This is an active, on-going working group in the USV area of the IETF.
It is the spawning ground for establishing other working groups in
this area.

 Internet-Drafts:

  No Current Internet-Drafts.


100VG-AnyLAN MIB (vgmib)
------------------------

 Charter
 Last Modified: 12-Sep-97

 Current Status: Active Working Group

 Chair(s):
     Jeff Johnson <[e-mail]>

 Internet Area Director(s):
     Jeffrey Burgan  <[e-mail]>
     Thomas Narten  <[e-mail]>

 Internet Area Advisor:
     Jeffrey Burgan  <[e-mail]>

 Technical Advisor(s):
     Kaj Tesink  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           ftp://rosegarden.external.hp.com/pub/vgmib

Description of Working Group:

The 100VG-AnyLAN MIB Working Group is chartered to develop a set of
managed objects for IEEE 802.12 network interfaces and repeaters.
These objects will be the minimum necessary to provide the ability to
monitor and control these network interfaces and repeaters, and will be
consistent with the SNMP framework and existing SNMP standards.

The working group will consider as an important input Section 13 (Layer
Management Functions and Services), and Annex E (GDMO Specifications
for Demand Priority Managed Objects) in the current IEEE 802.12 Draft,
and will monitor and track the progress of that draft as it moves
toward IEEE standardization. Furthermore, the working group will follow
the guidelines in the SNMPv2 SMI for mapping GDMO managed objects for
use with the Internet Network Management Framework. In addition, the
working group will solicit vendor-specific MIB modules to use as input
to the working group.

This working group will produce two documents:

     Definitions of Managed Objects for IEEE 802.12 Interfaces

     Definitions of Managed Objects for IEEE 802.12 Repeater Devices

For the repeater portion of the MIB, the working group will make sure
that its work is aligned with the 802.3 Repeater MIB Working Group to
ensure that the two working groups produce a consistent framework for
the management of repeater devices. As a result, development of the
repeater portion of the MIB will be done concurrently with, but
independently from, the interfaces portion of the MIB. Furthermore, the
goals and milestones associated with the repeater portion of the MIB
are dependent upon the goals and milestones of the 802.3 Repeater MIB
Working Group.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Jun 95 May 97  <draft-ietf-vgmib-repeater-dev-04.txt>
                Definitions of Managed Objects for IEEE 802.12 Repeater Devices


Virtual Router Redundancy Protocol (vrrp)
-----------------------------------------

 Charter
 Last Modified: 28-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Bob Hinden <[e-mail]>

 Routing Area Director(s):
     Joel Halpern  <[e-mail]>

 Routing Area Advisor:
     Joel Halpern  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail] w
         In Body:       subscribe vrrp <your_name>
     Archive:           ftp://ftp.ietf.org/ietf-mail-archive/vrrp/*

Description of Working Group:

The purpose of this working group is to define and develop a standard
   virtual router redundancy protocol for IPv4 and IPv6.  A virtual
   router redundancy protocol is a protocol which allows several routers
   on a multiaccess link to utilize the same virtual IP address.  One
   router will be elected as a master with the other routers acting as
   backups in case of the failure of the master router.  The primary
   motivation to using a virtual router redundancy protocol is that host
   systems may be configured (manually or via DHCP) with a single
default
   gateway, rather than running an active routing protocol.  The
protocol
   should also support the ability to load share traffic when both
   routers are up.

 The goals of this working group are:

   1. Define and develop a standard virtual router redundancy protocol
      for IPv4 and IPv6.

   2. Develop VRRP MIB(s).

   3. Separate specifications will be developed for IPv4 and IPv6.

   4. Determine whether static (configuration based) load sharing is
      adequate or if some amount of dynamic load sharing is required.

   5. Working group will examine security issues to determine what
      security threats it is appropriate for the VRRP protocol to handle
      and include the appropriate mechanisms in the VRRP protocol.

   6. The internet draft "Virtual Router Redundancy Protocol"
      <draft-hinden-vrrp-00.txt> will be use as the basis of virtual
      router redundancy protocol.  The working group will also consider
other
      internet drafts related to this topic allowing for issues
regarding
      change control, security, running code, etc.

   7. Intellectual property issues regarding the technology to
      develop a virtual router redundancy protocol will be identified
      and addressed.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 Oct 97  <draft-ietf-vrrp-spec-03.txt>
                Virtual Router Redundancy Protocol


WWW Distributed Authoring and Versioning (webdav)
-------------------------------------------------

 Charter
 Last Modified: 27-Oct-97

 Current Status: Active Working Group

 Chair(s):
     Jim Whitehead <[e-mail]>

 Applications Area Director(s):
     Keith Moore  <[e-mail]>
     Harald Alvestrand  <[e-mail]>

 Applications Area Advisor:
     Keith Moore  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
         In Body:       Subject of subscribe
     Archive:           http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/

Description of Working Group:

This working group will define the HTTP extensions necessary to enable
distributed web authoring tools to be broadly interoperable, while
supporting user needs.

The HTTP protocol contains functionality which enables the editing of
web content at a remote location, without direct access to the storage
media via an operating system. This capability is exploited by several
existing HTML distributed authoring tools, and by a growing number of
mainstream applications (e.g. word processors) which allow users to
write (publish) their work to an HTTP server. To date, experience from
the HTML authoring tools has shown they are unable to meet their user's
needs using the facilities of the HTTP protocol. The consequence of this
is either postponed introduction of distributed authoring capability, or
the addition of nonstandard extensions to the HTTP protocol. These
extensions, developed in isolation, are not interoperable.

An ad-hoc group has analyzed the functional needs of several
organizations, and has developed requirements for distributed authoring
and versioning. These requirements encompass the following capabilities,
which shall be considered by this working group:

IN-SCOPE:

*Locking: lock, lock status, unlock

*Name space manipulation: copy, move/rename, resource redirection (e.g.
 3xx response codes)

*Containers: creation, access, modification, container-specific
 semantics

*Attributes: creation, access, modification, query, naming

*Notification of intent to edit: reserve, reservation status, release
 reservation

*Use of existing authentication schemes

*Access control

*Unprocessed source retrieval

*Informing proxies of an action's impact

*Versioning:

   *Checkin/Checkout

   *History graph

   *Differencing

   *Automatic Merging

   *Naming and accessing resource versions

Further information on these requirements can be found in the document,
"Requirements for Distributed Authoring and Versioning on the World Wide
Web". <http://www.ics.uci.edu/~ejw/authoring/webdav-req-00.html>

While the scope of activity of this working group may seem rather
broad, in fact much of the functionality under consideration is well
understood, and has been previously considered. This working group will
leverage off of previous work when it is applicable. Discussion of the
security issues concerning distributed authoring and versioning are
essential to the creation of a protocol which implements this
functionality.

Though the feature set described above bears a resemblance to the
capabilities provided by a network file system, the intent of this
working group is not to create a replacement distributed file system
(e.g. NFS, CIFS). The WEBDAV emphasis on collaborative authoring of
resources which are not necessarily stored in a file system, and which
have associated metadata in the form of links and attributes,
differentiate WEBDAV from a distributed file system.

Many decisions have been made to reduce the scope of effort of this
working group. It is the intent of this working group to avoid the
inclusion of the following functionality, unless it proves impossible to
create a useful set of distributed authoring capabilities without it:

NOT IN SCOPE:

*Definition of core attribute sets, beyond those attributes necessary
for the implementation of distributed authoring and versioning
functionality

*Creation of new authentication schemes

*HTTP server to server communication protocols

*Distributed authoring via non-HTTP protocols (except email)

*Implementation of functionality by non-origin proxies

Eventually, it is desirable to provide access to WEBDAV capability by
disconnected clients, or by clients whose only connectivity is via
email. However, given the scope of developing requirements and
specifications for disconnected operation, the initial target user
group of fully connected clients, and the desire to work swiftly, the
working group will address this issue by ensuring the protocol
specification does not preclude a future body from developing an
interoperability specification for disconnected operation via email.

Deliverables

The final output of this working group is expected to be three
documents:

1. A scenarios document, which gives a series of short descriptions of
   how distributed authoring and versioning functionality can be used,
   typically from an end-user perspective. Ora Lassila, Nokia, currently
   visiting with the World Wide Web Consortium, is editor of this
   document.

2. A requirements document, which describes the high-level functional
   requirements for distributed authoring and versioning, including
   rationale. Judith Slein, Xerox, is editor of this document.

3. A protocol specification, which describes new HTTP methods,
   headers, request bodies, and response bodies, to implement the
   distributed authoring and versioning requirements. Del Jensen,
Novell,
   is editor of this document.

The most recent versions of these documents are accessible via links
from the WEBDAV Web page.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Nov 96 New     <draft-ietf-webdav-scenarios-00.txt>
                HTTP-based Distributed Content Editing Scenarios

 Feb 97 Sep 97  <draft-ietf-webdav-requirements-03.txt>
                Requirements for a Distributed Authoring and Versioning
                Protocol for the World Wide Web

 Jul 97 Oct 97  <draft-ietf-webdav-protocol-04.txt>
                Extensions for Distributed Authoring and Versioning on the
                World Wide Web -- WEBDAV

 Oct 97 New     <draft-ietf-webdav-depth-00.txt>
                WebDAV Tree Operations


Web Transaction Security (wts)
------------------------------

 Charter
 Last Modified: 23-Aug-95

 Current Status: Active Working Group

 Chair(s):
     Charlie Kaufman <[e-mail]>

 Security Area Director(s):
     Jeffrey Schiller  <[e-mail]>

 Security Area Advisor:
     Jeffrey Schiller  <[e-mail]>

 Mailing Lists:
     General Discussion:[e-mail]
     To Subscribe:      [e-mail]
     Archive:           http://www-ns.rutgers.edu/www-security

Description of Working Group:

The goal of the Web Transaction Security Working Group is to develop
requirements and a specification for the provision of security services
to Web transaction, e.g., transactions using HyperText Transport Protocol
(HTTP). This work will proceed in parallel to and independently of the
development of non-security features in the HTTP Working Group. The
working group will prepare two documents for submission as Internet
Drafts; an HTTP Security Requirements Specification, and an HTTP
Security Protocol Specification. The latter will be submitted as a
Standards Track RFC.

 Internet-Drafts:

Posted Revised       I-D Title  <Filename>
------ ------- ------------------------------------------
 Dec 94 Mar 97  <draft-ietf-wts-shttp-04.txt>
                The Secure HyperText Transfer Protocol

 Feb 96 Mar 97  <draft-ietf-wts-shtml-03.txt>
                Security Extensions For HTML